Осмелюсь оспорить Ваше возражение. Есть только две причины не мудрить с заголовком. Первая — это лицензия на формат PNG — если лицензия не позволяет инкапсулировать этот формат, то, разумеется, нет смысла расширять формат SSP. Вторая причина несерьёзная — добавление одного байта к заголовку увеличивает размер файла.
Тем не менее, с точки зрения практического успеха алгоритма, лучше сразу избавиться от ситуации, когда он даст результаты, прямо противоположные от ожидаемых. Просто поверьте мне, ведь Вы не знаете, кто будет использовать Ваш алгоритм, а люди бывает весьма неадекватные. Приведу простой пример: мифический юзер Вася Пупкин потестировал Ваш алгоритм на своей коллекции картинок, в результате чего её размер увеличился. После этого Вася начинает на каждом углу незаслуженно критиковать Ваш алгоритм. Оно Вам надо?
Наконец, если Вы решите доработать или модифицировать алгоритм, то в «лишнем» байте можно хранить версию этого алгоритма, чтобы программа распаковки знала как обрабатывать изображение.
Я не настаиваю, просто делюсь наблюдениями из личного опыта работы с различными протоколами.
Простите, а то что на картинке i53.tinypic.com/2dr7u51.png размер изображения вырос, это не опечатка?
Если не опечатка, то может быть имеет смысл в этом случае сохранять исходное изображение?
К примеру, добавить байт в заголовок формата SSP, определяющий была ли картинка пожата. В будущем этот байт может пригодиться для расширений алгоритма.
Россия — большая страна. К своему стыду, о Стартап-Уикенде узнал только сейчас из этой статьи. Не знаю, если бы узнал раньше, нашёл ли время и финансы (по крайней мере на авиабилет до Москвы и обратно) для участия.
Впрочем, речь не об этом. Удручает обстоятельство, что подавляющее большинство названных Вами проектов направлено на создание услуг в Сети. Проектов, предлагающих продукты, а не услуги, ничтожно мало. Интернет хорош для продвижения и распространения продуктов, а строить очередную социальную сеть на текущий момент бесперспективно — крупные игроки уже затянули пользователей в свои сети и отпускать из своих цепких лап не собираются. Игра на этом поле — огромный риск для инвестора.
Наконец, это только кажется, что идея стоит много, а реализация мало. Есть поговорка: «Рубль тому, кто придумал, 10 рублей тому, кто создал, 100 рублей тому, кто продал». Жизнь показывает, что эта поговорка работает. Отсюда вывод, что выгоднее продавать самому и за деньгами к инвестору приходят не от хорошей жизни.
Хотите создать удачный стартап? Приносите инвестору не идею, а продукт, который не знаете как продать.
Все преимущества от 12 мегапикселей нивелируются отсутствием нормальной оптики. Поначалу меня удивляло, почему старенький 3-х мегапиксельный фотоаппарат делает снимки на порядок лучше чем, 6-мегапиксельные телефоны. Посему вопрос — имеет ли смысл биться над усовершенствованием CMOS-сенсоров? Не лучше ли озаботиться усовершенствованием телефонной оптики?
Ещё интересно, почему производители телефонов не посмотрят в сторону использования гироскопов?
Телефоном фотографируют преимущественно с рук, а значит дрожание неизбежно. Имхо, гироскопом можно несколько исправить ситуацию.
Такую штуку, только кнопок чуть поболе, мы сделали командой из чётырех человек в 2003 году.
За основу был взят CDMA модем компании Bellwave и GPS навигатор австралийской компании (название запамятовал).
Аппаратную часть проектировал и собирал инженер из Белоруссии, интерфейс разработал и реализовал другой человек, программу для центра экстренной помощи писал третий, а на мне была задача обработки данных от GPS ресивера и передача позиции в центр экстренной помощи.
Наш проект оказался неудачным благодаря высокому энергопотреблению — CDMA модем + GPS ресивер очень жадно кушали батарейку, так что терялся смысл носить с собой это устройство.
Статья великолепная, но глаз зацепился за одну цитату:
Linux OS и Android имеют заметные различия в userland и в концепции построения и работы приложений, именно поэтому в самом Google явно говорят, что «Android is not Linux».
Не вижу особого смысла вывода текста в графическом режиме. Разве лишь только для того, чтобы поместить больше информации на экране.
Давайте раз и навсегда покончим с этим вопросом. Если Вы пишите свою ОС, то написав графическую систему, у вас не хватит желания писать файловую систему. И не будет времени её спроектировать.
Далее, графическая оболочка будет более проста в реализации при условии, что Вы не разрабатываете протокол взаимодействия с этой графической системой, а пишите по готовой спецификации.
Отсюда следует, что примитивный вывод текстовой информации в графическом режиме — не нужен. В этом плане хорошим примером может служить протокол X11R6, который, по сути, позволяет исполнять графические программы на устройстве, где нет видеокарты.
Пожалуй, мне нечего добавить по этому поводу. Если я Вас не убедил — увы.
Мотивация простая — незнание. Я не шучу. Человек, обладающий достаточными знаниями, никогда не возьмётся за написание операционной системы, поскольку:
— в этом нет смысла, рынок ОС давно поделен;
— это не под силу одному человеку.
Но заметьте, я никого не призывал писать операционную систему, а просто дал советы тем, кто решил это сделать.
Простите, уже за полночь. Я благодарен Вам и всем отписавшимся в этой теме за проявленное внимание к этой статье. К сожалению, завтра буду вдали от интернета, поэтому никому не отвечу. Честно говоря, меня приятно удивила реакция сообщества. Ещё раз всем спасибо.
POSIX API может быть и не самый лучший интерфейс, к тому же в старых стандартах ещё и имеет проблемы с многопоточнотью. В этом плане мне видится интересным путь использования интерфейсов, нечто вроде COM технологии.
Однако, давайте будем реалистами. Система, под которую придётся заново писать весь софт — нежизнеспособна. Разработчики и компании, имеющие значительные ресурсы и большую пользовательскую базу, могут себе позволить экспериментировать. Можно постепенно добавлять функциональность, не ломая совместимость со стандартами или ломая очень осторожно. Вспомните, сколько шума произвели расширения общепринятых Unix стандартов компанией Microsoft, когда остальным разработчиками приходилось под них подстраиваться. О том, что может себе позволить великан, пигмею даже мечтать вредно.
Попробую пояснить: представьте реакцию сообщества, если кто-то неизвестный из ниоткуда заявит, что написал «принципиально новую ОС», ни с чем не совместимую, под которую нет программного обеспечения. Может с десяток соратников и соберёт, но даже 10 человек погоды не сделают. Вероятность успеха ничтожна.
Если человек задаёт такие вопросы, то эта статья не для него. Статья для молодых программистов, решивших написать ОС.
Кстати, компьютер может выводить текст и в сокет, и в последовательное устройство, и в JTAG интерфейс. В идеальном случае можно вообще не затруднять себя написанием вывода текста на графическое устройство, а просто передать его на другую систему.
Очень интересная идея с хранилищем данных. С удовольствием послушаю Ваше видение интерфейса взаимодействия с таким хранилищем.
Совместимость — это бич. Крупная компания может позволить себе инвестировать в средства R&D. Кустарь одиночка — нет.
Планировщик. А знаете, в этом вопросе я с Вами полностью согласен и даже могу представить систему без планировщика. И такую систему вполне реально построить на основе синхронных IPC. Фишка в том, что в любой современной системе процессор большую часть времени проводит в режиме низкого энергопотребления. Если каждую подсистему представить в виде черного ящика, который получает запрос, обрабатывает его, передаёт дальше, получает ответ, отрабатывает, отвечает на запрос, то планировщик не нужен. Одна лишь беда при таком подходе — придётся верифицировать пользовательские приложения, иначе любой бесконечный цикл переведёт систему в «режим бессмысленного энергопотребления».
Как Вам нравятся три уровня: символьные устройства, блочные устройства, сервисы?
Всё это умеет слоиться, как в Windows NT, но проще и понятнее для программиста.
Зарезервируйте несколько системных вызовов для протокола обмена с графической системой.
Далее, осуществляете обмен графической системой по этим протоколам. Здесь очень большое поле для творчества.
Трудный вопрос, если честно. Написать ОС — мечта юношеских лет. Конечно, хотелось бы достигнуть коммерческого успеха, но если не выйдет, значит такая судьба, значит что-то сделал не так.
Может быть меня сейчас побьют, но в Hurd я разочаровался, после того как тестировал его около 10 лет назад на ноутбуке. В нормальной системе, большую часть времени процессор находится в режиме низкого энергопотребления (HLT) и лишь прерывания выводят его из состояния «сна». Hurd же всё время что-то делал, благодаря чему вентилятор охлаждения процессора всё разгонялся и разгонялся. Даже мальчишка может понять, что такого быть не должно.
Писать ОС брался несколько раз и все попытки заканчивались остыванием интереса, благодаря тому, что не было соответствующих знаний в этой области. Потом случайно наткнулся на L4 Fiasco и заинтересовался этим микроядром. Наконец, когда увидел L4Ka::Pistachio, понял, что это идеал. За годы работы с Pistachio ни разу не разочаровался в нём.
Что касается minix3 — я уважаю Таненбаума, он отличный архитектор и прекрасный учитель, но я поклоняюсь L4 и верю, что это микроядро вскоре будет оценено по достоинству.
Тем не менее, с точки зрения практического успеха алгоритма, лучше сразу избавиться от ситуации, когда он даст результаты, прямо противоположные от ожидаемых. Просто поверьте мне, ведь Вы не знаете, кто будет использовать Ваш алгоритм, а люди бывает весьма неадекватные. Приведу простой пример: мифический юзер Вася Пупкин потестировал Ваш алгоритм на своей коллекции картинок, в результате чего её размер увеличился. После этого Вася начинает на каждом углу незаслуженно критиковать Ваш алгоритм. Оно Вам надо?
Наконец, если Вы решите доработать или модифицировать алгоритм, то в «лишнем» байте можно хранить версию этого алгоритма, чтобы программа распаковки знала как обрабатывать изображение.
Я не настаиваю, просто делюсь наблюдениями из личного опыта работы с различными протоколами.
Если не опечатка, то может быть имеет смысл в этом случае сохранять исходное изображение?
К примеру, добавить байт в заголовок формата SSP, определяющий была ли картинка пожата. В будущем этот байт может пригодиться для расширений алгоритма.
Впрочем, речь не об этом. Удручает обстоятельство, что подавляющее большинство названных Вами проектов направлено на создание услуг в Сети. Проектов, предлагающих продукты, а не услуги, ничтожно мало. Интернет хорош для продвижения и распространения продуктов, а строить очередную социальную сеть на текущий момент бесперспективно — крупные игроки уже затянули пользователей в свои сети и отпускать из своих цепких лап не собираются. Игра на этом поле — огромный риск для инвестора.
Наконец, это только кажется, что идея стоит много, а реализация мало. Есть поговорка: «Рубль тому, кто придумал, 10 рублей тому, кто создал, 100 рублей тому, кто продал». Жизнь показывает, что эта поговорка работает. Отсюда вывод, что выгоднее продавать самому и за деньгами к инвестору приходят не от хорошей жизни.
Хотите создать удачный стартап? Приносите инвестору не идею, а продукт, который не знаете как продать.
Ещё интересно, почему производители телефонов не посмотрят в сторону использования гироскопов?
Телефоном фотографируют преимущественно с рук, а значит дрожание неизбежно. Имхо, гироскопом можно несколько исправить ситуацию.
За основу был взят CDMA модем компании Bellwave и GPS навигатор австралийской компании (название запамятовал).
Аппаратную часть проектировал и собирал инженер из Белоруссии, интерфейс разработал и реализовал другой человек, программу для центра экстренной помощи писал третий, а на мне была задача обработки данных от GPS ресивера и передача позиции в центр экстренной помощи.
Наш проект оказался неудачным благодаря высокому энергопотреблению — CDMA модем + GPS ресивер очень жадно кушали батарейку, так что терялся смысл носить с собой это устройство.
Пожалуй, названная Вами причина не самая главная.
Давайте раз и навсегда покончим с этим вопросом. Если Вы пишите свою ОС, то написав графическую систему, у вас не хватит желания писать файловую систему. И не будет времени её спроектировать.
Далее, графическая оболочка будет более проста в реализации при условии, что Вы не разрабатываете протокол взаимодействия с этой графической системой, а пишите по готовой спецификации.
Отсюда следует, что примитивный вывод текстовой информации в графическом режиме — не нужен. В этом плане хорошим примером может служить протокол X11R6, который, по сути, позволяет исполнять графические программы на устройстве, где нет видеокарты.
Пожалуй, мне нечего добавить по этому поводу. Если я Вас не убедил — увы.
— в этом нет смысла, рынок ОС давно поделен;
— это не под силу одному человеку.
Но заметьте, я никого не призывал писать операционную систему, а просто дал советы тем, кто решил это сделать.
Простите, уже за полночь. Я благодарен Вам и всем отписавшимся в этой теме за проявленное внимание к этой статье. К сожалению, завтра буду вдали от интернета, поэтому никому не отвечу. Честно говоря, меня приятно удивила реакция сообщества. Ещё раз всем спасибо.
POSIX API может быть и не самый лучший интерфейс, к тому же в старых стандартах ещё и имеет проблемы с многопоточнотью. В этом плане мне видится интересным путь использования интерфейсов, нечто вроде COM технологии.
Однако, давайте будем реалистами. Система, под которую придётся заново писать весь софт — нежизнеспособна. Разработчики и компании, имеющие значительные ресурсы и большую пользовательскую базу, могут себе позволить экспериментировать. Можно постепенно добавлять функциональность, не ломая совместимость со стандартами или ломая очень осторожно. Вспомните, сколько шума произвели расширения общепринятых Unix стандартов компанией Microsoft, когда остальным разработчиками приходилось под них подстраиваться. О том, что может себе позволить великан, пигмею даже мечтать вредно.
Попробую пояснить: представьте реакцию сообщества, если кто-то неизвестный из ниоткуда заявит, что написал «принципиально новую ОС», ни с чем не совместимую, под которую нет программного обеспечения. Может с десяток соратников и соберёт, но даже 10 человек погоды не сделают. Вероятность успеха ничтожна.
Разумеется, всё вышесказанное — IMHO.
Кстати, компьютер может выводить текст и в сокет, и в последовательное устройство, и в JTAG интерфейс. В идеальном случае можно вообще не затруднять себя написанием вывода текста на графическое устройство, а просто передать его на другую систему.
Очень интересная идея с хранилищем данных. С удовольствием послушаю Ваше видение интерфейса взаимодействия с таким хранилищем.
Совместимость — это бич. Крупная компания может позволить себе инвестировать в средства R&D. Кустарь одиночка — нет.
Планировщик. А знаете, в этом вопросе я с Вами полностью согласен и даже могу представить систему без планировщика. И такую систему вполне реально построить на основе синхронных IPC. Фишка в том, что в любой современной системе процессор большую часть времени проводит в режиме низкого энергопотребления. Если каждую подсистему представить в виде черного ящика, который получает запрос, обрабатывает его, передаёт дальше, получает ответ, отрабатывает, отвечает на запрос, то планировщик не нужен. Одна лишь беда при таком подходе — придётся верифицировать пользовательские приложения, иначе любой бесконечный цикл переведёт систему в «режим бессмысленного энергопотребления».
Как Вам нравятся три уровня: символьные устройства, блочные устройства, сервисы?
Всё это умеет слоиться, как в Windows NT, но проще и понятнее для программиста.
Далее, осуществляете обмен графической системой по этим протоколам. Здесь очень большое поле для творчества.
Некоторые идеи по этому поводу можно найти здесь: almandrykin.ya.ru/replies.xml?item_no=1053
Кстати, я попытался перевести community.livejournal.com/l4os/743.html
Оригинал здесь: i30www.ira.uka.de/aboutus/inmemoriam/liedtke/
Может быть меня сейчас побьют, но в Hurd я разочаровался, после того как тестировал его около 10 лет назад на ноутбуке. В нормальной системе, большую часть времени процессор находится в режиме низкого энергопотребления (HLT) и лишь прерывания выводят его из состояния «сна». Hurd же всё время что-то делал, благодаря чему вентилятор охлаждения процессора всё разгонялся и разгонялся. Даже мальчишка может понять, что такого быть не должно.
Писать ОС брался несколько раз и все попытки заканчивались остыванием интереса, благодаря тому, что не было соответствующих знаний в этой области. Потом случайно наткнулся на L4 Fiasco и заинтересовался этим микроядром. Наконец, когда увидел L4Ka::Pistachio, понял, что это идеал. За годы работы с Pistachio ни разу не разочаровался в нём.
Что касается minix3 — я уважаю Таненбаума, он отличный архитектор и прекрасный учитель, но я поклоняюсь L4 и верю, что это микроядро вскоре будет оценено по достоинству.