LINUX.ORG.RU

Дмитрий Завалишин рассказал о себе, своих взглядах на софт и, конечно, об ОС «Фантом»

 , ,


1

2

В Компьютерре-онлайн опубликовано интервью с Дмитрием Завалишиным - создателем ядра операционной системы «Фантом», в которой программы работают «вечно», программировать можно без учёта сохранения данных, а программы легко обмениваются сложными объектными структурами.

Из интересных подробностей:

  • Ядро «Фантома» уже практически готово, частично реализована графическая среда.
  • Под «Фантомом» будет запускаться код, написанный для Unix или Linux, но его придётся модифицировать (к примеру, из-за отсутствия XWindow).
  • Завалишин не любит GPL и считает, что «если уж отдавать, то не ставить условий».
  • Если всё пойдёт по плану, то в «Фантоме» можно будет реализовать интерфейс, где значок программы и её окно - это один и тот же объект, а окна можно будет чуть ли не отправлять по электронной почте.

Тех, кто осилит прочесть все 50 тысяч знаков ждут всякие бонусы в виде баек про времена ЕС ЭВМ и рассказа о том, как в DZ делают системы датчиков для «Мосводоканала».

>>> Интервью



Проверено: anonymous_incognito ()
Последнее исправление: anonymous_incognito (всего исправлений: 1)

Ответ на: комментарий от simple_best_world_web_master

mpd тут никаким боком: он сам предоставляет определенный интерфейс (команды), и за его пределы ты никак не выйдешь.

farafonoff ★★
()
Ответ на: комментарий от simple_best_world_web_master

Да, именно эта болезнь, правда я предложил использовать уже

существующие методы, а не городить новые. Я против самого зоопарка.


Создание, отладка и пр полезных протоколов в юниксе - это фактически генетические алгоритмы(ака эволюция по дарвину). Стремление зоопарк разумно прорядить - позволяет выделить наиболее приспособленные.

Стремление убрать зоопарк == развитие остановится. И дело кончится тем что эволюция сметет в конце концов весь юникс(линукс) целиком заменив его на другую/ более приспособленную систему.

Вы считаете что это будет хорошо? Ну сделайте систему с «одним протоколом» и пусть она дохнет. :) А при попытке навязать в моем(нашем) юниксе «единый протокол для всего-всего-всего» пойдете лесом и вплавь :):):)

«нет ничего более постоянного, чем временное».


И что? Хотите идеальную ос(протокол, ЯП) чтобы на нее молиццо? ;) которую вы конечно 10 лет будуте продумывать и обслюнявливать чтобы найти идеальное решение для всенх проблем :)

Нет ничего более постоянного, чем временное, И ЭТО ХОРОШО1111 :) Так как чаще всего «не временного» решения для задачи не существует. А существует ИЛЛЮЗИЯ существования красивого идеального «не-временного» решения :)

И практика показывает,

что приживаются самые примитивные решения, нежели более

проработанные, что заставляет меня сильно грустить.


Потому, в том числе, что проработанное решение доставляет ГОРАЗДО больше гемороя чем примитивное, в глобальном масштабе. Так как «проработаное» решение сложно в том числе обойти когда такая необходимость возникает. А она возникает всегда, проработать решение можно исходя только из текущих знаний. А не исходя из знаний будущих - будущего то никто не знает.

kernel ★★☆
()
Ответ на: комментарий от simple_best_world_web_master

Это же к счастью! Представь ситуацию когда нужно быстро написать что-то, пригодное к использованию. По этому побеждают технологии с самым низким порогом вхождения.

farafonoff ★★
()
Ответ на: комментарий от simple_best_world_web_master

А если программа перебирает возможное расположение файла, и сисколл постоянно валится с ошибкой, это все надо пользователю показать? Обработка ошибок внутри программы по возможности и есть лучший вариант. Бывают ошибки которые нет смысла обрабатывать, лучше просто вылететь с коредампом.

farafonoff ★★
()
Ответ на: комментарий от www_linux_org_ru

вся эта завалишинская затея была для того, чтобы вместо файлов были образы памяти прикладных программ; ...


Мне вдруг пришло в голову что история повторяет себя. Была такая система - Multics :):):) До юникса.

В ней «вместо файлов были образы памяти прикладных программ», строгая типизация и полно всего. Это была ОГРОМНАЯ сложнаяя система. «Совершенствовать ее было все равно что пиннать дохлого кита» (C)имхо Кен Томпсон. Эта байка есть в любом более менее серьезном файле по истории юникс. Разрабы настолько этот ужас возненавидели, что собрались и использовали опыт разработки «большого дохлого кита» для разработки простой и понятной ОС. В которой постулировалось что МЫ НЕ ЗНАЕМ. ;) И не будем никого учить.

Кстати понятно откуда этот бред у Завалишина. Его мозг застрял в эпохе ДО ИЗОБРЕТЕНИЯ юникса :):):) Так как в советском ИТ именно с ОС всегда была напряженка гораздо больших сравнительных масштабов чем со всем остальным. Для компутера в ракете ОС ненужна. По этому «школа разработки ОС» ссср застряли во временах древних, и относились к любым ОС как к ненужному для тру-кодеров в машкодах на тумблерах излишеству. Аналогичное отношение в советской школе ИТ например к компутерным сетям на базе коммутации пакетов. Типа ненадежное говно, отстой не для серьезных пацанов, ядерными ракетами не порулишь :):):)

А несерьезные пацаны перенимали отношение старших товарищей :)

kernel ★★☆
()
Ответ на: комментарий от sin_a

Меня тоже заинтересовало, но я умею:


Много чести лезть в поисковик когда очередной ххх считает что некий термин должны знать все, а если не знают то лезть и узнавать. :)

kernel ★★☆
()
Ответ на: комментарий от kernel

> Мне вдруг пришло в голову что история повторяет себя. Была такая система - Multics :):):) До юникса.

В ней «вместо файлов были образы памяти прикладных программ», строгая типизация и полно всего.

В Multics была иерархическая ФС. Вообще, почти все возможности Multics есть в современном Unix :)

tailgunner ★★★★★
()
Ответ на: комментарий от kernel

> Мне вдруг пришло в голову что история повторяет себя. Была такая система - Multics :):):) До юникса. В ней «вместо файлов были образы памяти прикладных программ», строгая типизация и полно всего.

Знаю, что была, и вспоминал ее. Вот только насчет строгой типизации БОЛЬШИЕ сомнения — те машинки работали еще на ферритовых сердечниках :-)

А сейчас на терабайтовых дисках и гигабайтовой памяти че-то можно и отдать под поддержку типизации.

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

И завалишин вероятно обломается, так как для 2 нужно даже не «все как

в яве», а «все как в хаскеле».


Он обломается по более фундаментальным причинам. Тот же Микрософт проще говоря «успешен» не потому что там «гуру программирования». Если хочется быть гуру-визионерам со своим «видением» и навязывать свою гениалоьную идею - так дорога не в «гуру программирования» а в манагеры, телепроповедники и бизнесмены :)

И как только я слышу «как в хаскеле» на уровне ОС, я хватаюсь за пистолет :)

Теперь по делу: нужно что-то среднее между 1 и 2. Т.е. идущая из

70-х динамическая типизация точно изжила себя в большом

программировании.


Не нужно чтото среднее! Каждый проект сам пусть решает на чем ему там писать и как сношатся со своей типизацией :)

Пока я вижу что всю эту типизацию аля хацкелл и прочий ФП любят люди просто определенного склада ума. Плохо то что они считают свой склад ума единственно правильным, а всех остальных расово генетрически неполноценными, при том что реально людей с таким складом ума даже среди программеров единицы. :)

То есть «динамическая типизация точно изжила себя в большом программировании» это модный фанатский лозунг. Может быть обоснованный, но я в этом сомневаюсь.

В программировнии в 20 строк и в принципах взаимодействия с ОС она

еще держится; этому есть объективные причины, но видимо надо ее

потеснить.


Пока я вижу что есть группа безумны фанатов на лоре, у которых разве что пена изо рта не течет ;), которые кричат «хацкелл - будущие111», «а когда наши танки войдут в город, все будет на хацкеле а всех несогласных в биореактор».
Вот такие люди пока защищают идею типизации :) Вы с ними ? ;) Ну это, я за вас рад :)

С тем же примером про фильмы: допустим, я копирую у знакомого фильм, но у меня нет к нему кодека; строгая ОС должна не разрешить его вообще скопировать — но это конечно маразм; более реалистично наличие неких метаданных, которые позволяют сказать «вот на этой ФС есть такие-то фильмы с неразрешенными зависимостями»

kernel ★★☆
()
Ответ на: комментарий от www_linux_org_ru

и еще, тогда (по ограниченности железа) такого зоопарка не было, всех вполне устраивло даже не «сканирование шрифтов и плагинов», а просто прописывание их в конфиге

а щас все избаловались, памяти и дисков дохрена, блондинок тоже дохрена... так что можно и пересмотреть кое-что

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

Знаю, что была, и вспоминал ее. Вот только насчет строгой типизации

БОЛЬШИЕ сомнения — те машинки работали еще на ферритовых сердечниках :-)


Про аппаратную строгую типизацию поросите кого-нибудь рассказать. Фанат строгой типизации это тип мозга - существовавший во все времена :)

Хотя да - в мультиксе не помню насчет именно строгой типизации переменных, но вот разные извращенные типы файлов(памяти, там была хитрая система) этого было сколько угодно. Например файл как множество записей на уровне ОС с соотв API.

А сейчас на терабайтовых дисках и гигабайтовой памяти че-то можно и

отдать под поддержку типизации.


Потребность у определенного класса людей вкрутить строгую типизацию и *всех* программистов ею анально изнасиловать «ради всеобщего блага» :) была *всегда*. «вот сделаем строгую типизацию и будет счастье111» :)

kernel ★★☆
()
Ответ на: комментарий от tailgunner

В Multics была иерархическая ФС.


Там была какая то гораздо более хитрая система, имхо. То что некоторые ее части походили на иерархическую FS ничего не значит :)

Вообще, почти все возможности Multics есть в современном Unix :)


Что как раз и показывает что придумать «все и разом» идея идиотская сама по себе. Даже если автор прав и «все и разом» когда нибудь комунибудь понадобится :)

kernel ★★☆
()
Ответ на: комментарий от kernel

> Пока я вижу что есть группа безумны фанатов на лоре, у которых разве что пена изо рта не течет ;), которые кричат «хацкелл - будущие111», «а когда наши танки войдут в город, все будет на хацкеле а всех несогласных в биореактор». Вот такие люди пока защищают идею типизации :) Вы с ними ? ;) Ну это, я за вас рад :)

и вот тут тебя понесло по кочкам в полный бред

посмотри хотя бы мои посты в темах про хаскель (хинт: там полно стеба над ним), да и тут я предлагал динамическую типизацию всего лишь потеснить.

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

и вот тут тебя понесло по кочкам в полный бред


Я предупредил когда я хватаюсь за пистолет :)

посмотри хотя бы мои посты в темах про хаскель (хинт: там полно стеба

над ним), да и тут я предлагал динамическую типизацию всего лишь потеснить.


Я считаю что на уровне ОС ее точно теснить совершенно незачем. Просто потому что ОС «не знает» ничего про программы кроме самых общих вещей. И не должна знать - так как это все ужасно усложняет.

Конечно есть специальные применения и отдельные механизмы. Вот на уровне отдельных отрываемых механизмов - это и сейчас делают в той или иной форме.

И какие будут твои конкрентные предложения? Что бы ты хотел типизировать нединамически?

kernel ★★☆
()
Ответ на: комментарий от www_linux_org_ru

2. Объект копируется на другую фантомОС приятелю, у которого шрифта нет


ИЧСХ Завалишин-like подходы были весьма модны до распостранения сетей и до распостранения необходимости передавать файлы на компутер друга с *другой* ОС.

Собственно как только вся эта типизация выходит из 100% контролируемой среды - например из процесса в памяти, оно все тут же идет лесом.По этому появляются попытки распостранить тотальный контроль сначала на ОС и другие программы, а потом и на всю сеть. В том числе в виде «все БУДЕТ процессом в пямяти» :)

Классическая мегаломания между прочим - подчинить всех что бы они не мешали своим не укладывающимся в схему поведением. ;):):)

kernel ★★☆
()
Ответ на: комментарий от kernel

> Я считаю что на уровне ОС ее точно теснить совершенно незачем. Просто потому что ОС «не знает» ничего про программы кроме самых общих вещей. И не должна знать - так как это все ужасно усложняет.

Если ты посмотришь мои посты, увидишь, что я либо писал «ОС!=ядро», либо обтекаемо говорил «на уровне взаимодействия с ОС»

мне это интересно обдумать скорее ради контраста с типизацией в программах (там совсем другая картина), хотя...

что мне *возможно* хочется от ядра и железа — это единое адресное пространство, допустим через метод типа NaCl и железные команды верификации любого джампа и ретурна на адрес, кратный 16

Конечно есть специальные применения и отдельные механизмы. Вот на уровне отдельных отрываемых механизмов - это и сейчас делают в той или иной форме.

И какие будут твои конкрентные предложения? Что бы ты хотел типизировать нединамически?

это уже завтра, щас я торможу

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от kernel

> Собственно как только вся эта типизация выходит из 100% контролируемой среды - например из процесса в памяти, оно все тут же идет лесом.По этому появляются попытки распостранить тотальный контроль сначала на ОС и другие программы, а потом и на всю сеть. В том числе в виде «все БУДЕТ процессом в пямяти» :)

да, проблема в том, что внешняя среда не персистентна в принципе :-)

но подход managed-объектов можно ослабить и в этом виде попытаться реанимировать — реализовать что-то типа исчисления «насколько объект полон»

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от darkshvein

> Вауу. И сколько же, мм хотя бы десятков человек поддерживает его проект? Неет, не за деньги, а именно потому что он того стоит и представляет из себя что то интересное.

А сколько человек пилит Plan9? Многие просто не в состоянии осознать всю красоту идеи и кидаются какашками. Это примерно как при переходе с винды на линукс - срабатывает типичный синдром утенка

simple_best_world_web_master
()
Ответ на: комментарий от alphex_kaanoken

> или там все будет на жабке ?

Тогда еще раз перечитай интервью.

ошибка в jvm (а это неудивительно) и привет системе.

Ты говоришь так, словно багов в x86 небывает (а они есть)

были другие данные, там же все в одном адрес спейсе так ? контекст свитчей нет - ровно об этом говорил фрик завалишин.

Я тебе просто показал, что драйвера в юзерспейсе возможны, а теперь представь, что это единственный контекст

Какой ты смелый поколе некомпетентный - я даже комментировать не хочу это.

«если вы уверены, что разговариваете с полным идиотом, то знайте, что у вашего оппонента аналогичное мнение». Мне тоже порой кажется, что я пишу это зря, но таки попробую.

о боже мой! я ему одно, а он мне другое, еще раз - файлов нет, как мне на хост с нормальной ос передать - транслировать в файл? а как с носителя читать ? имплементить транслятор фс - теже файлы и будут, просто кто то «ниасилил» удобность такой вещи как файл, вот и несет всякую чушь.

Мальчик, ты вообще в курсе про трансляторы, а? Как оно и зачем?

Если тебе надо передать _ДАННЫЕ_ в какую-то легаси-систему вроде венды или линупса, которые не понимают БОЖЕСТВЕННОЙ СУТИ - да, транслировать файл, а что еще можно сделать с устаревшими системами? Причем ТЫ сам волен выбирать формат для этих данных, можешь сохранять хоть в txt, хоть в pdf, ограничений формата не происходит, ты сам все контролируешь. А вот в «удобных файлах» такой свободы уже не будет, ты чем-то жертвуешь, красивая идеология трансляторов будет заменена на пачку конверторов, что и есть в линупсе. Надо прочитать файлы? А тоже непроблема - любое приложение будет читать любые форматы файлов, причем если приложение написано 10 лет назад, а новый формат появился 2 дня назад, то с идеей трансляторов это старое приложение будет полностью поддерживать новый формат. Но тебе этой красоты не понять, лучше изобрести еще пачку файловых форматов, плохо совместимых между собой.

Я спокоен, очень спокоен, просто называю вещи своими именами, идиотов идиотами, фриков фриками, поделки поделками, попилы попилами и тд и тп

Где ты увидел попилы - я не знаю, а идиота я пока вижу только в тебе (а ты во мне - это зеркально)

simple_best_world_web_master
()
Ответ на: комментарий от www_linux_org_ru

> тогда уж вообще Data::File

Кстате, не надо смеяться, возможно все такие типы данных и будут наследоваться от чего-то вроде RawData, которые можно сериализовать в файл

это такой же неотъемлемый компонент фильма, как шрифт — компонент фотошопного документа

И это великолепно! Таким образом нету никаких зависимостей, но не только между пакетами, но и документами.

и там *должен* быть столь нелюбимый завалишиным Data::File

главное наследование, а что там на самом низшем уровне - не так и важно, хоть файлом обзови (правда мне сложно представить набор фреймов видео/звука, их опции, параметры навигации, текстовые индексы, субтитры и прочее как отдельный файл, а если брать на низший уровень понятие «контейнер» - да, идея пропадает)

simple_best_world_web_master
()
Ответ на: комментарий от farafonoff

> mpd тут никаким боком: он сам предоставляет определенный интерфейс (команды), и за его пределы ты никак не выйдешь.

мпд предоставляет достаточно чистый интерфейс управления, никаких лишних привязок, а как следствие - десятки, если не сотни морд к нему, начиная от простых консольных плееров, заканчивая будильниками с голосовыми системами, на совершенно разных тулкитах.

simple_best_world_web_master
()
Ответ на: комментарий от kernel

> А при попытке навязать в моем(нашем) юниксе «единый протокол для всего-всего-всего» пойдете лесом и вплавь :):):)

Отжеж, А ТЕКСТОВЫЕ ПАЙПЫ РАБОТАЮТ!!!!!!!11 Ибо завещано САМИМ ВЕЛИКИМ так!!!11111

В самом деле, большие ли сейчас проблемы с этим? Но ведь протокол (текстовый) вроде как один и всем хватает

А существует ИЛЛЮЗИЯ существования красивого идеального «не-временного» решения :)

Я скорее верю в ниасиляторов, которые не смогли заимплементить более сложный вариант.

simple_best_world_web_master
()
Ответ на: комментарий от kernel

>Может быть обоснованный, но я в этом сомневаюсь.

Не обоснованный. Просто ее готовить тоже почти никто не умеет. «Доказано библиотеками руби».

r ★★★★★
()
Ответ на: комментарий от farafonoff

> Представь ситуацию когда нужно быстро написать что-то, пригодное к использованию. По этому побеждают технологии с самым низким порогом вхождения.

Ага, а потом десятки лет разгребаем такие выхлопы, лепим к ним костыли и с сильным трудом закапываем. Примеры все знают.

Благо завалишин предлагает для таких людей сильно упростить жизнь, переложив много работы на системные библиотеки, кодить надо будет меньше, возможность появления ошибок тоже снижается

simple_best_world_web_master
()
Ответ на: комментарий от farafonoff

> и сисколл постоянно валится с ошибкой, это все надо пользователю показать? Обработка ошибок внутри программы по возможности и есть лучший вариант. Бывают ошибки которые нет смысла обрабатывать, лучше просто вылететь с коредампом.

Ну я еще помню огромные портянки таких сообщений в msdos, но саму идею это не отменяет. Сам же говоришь, что надо порой с коредампом вылететь, чем пытаться что-то исправить, а кто примет такое решение, если не пользователь/оболочка? Опционально запустится отправлялка дампа разработчикам.

simple_best_world_web_master
()
Ответ на: комментарий от simple_best_world_web_master

Отжеж, А ТЕКСТОВЫЕ ПАЙПЫ РАБОТАЮТ!!!!!!!11 Ибо завещано САМИМ ВЕЛИКИМ

так!!!11111


1111:):):):)11111 [да,да - хочу и буду писать много смайликов, восклицательных знаков и больших букв. А то задрали уже - тут смалики неприняты, там неприняты. Пошли на ^%$1111 :)]

Пайпы и файлы работают именно потому что просты и тупы до невозможности. Ничего не решают за «потребителя» - приложение. Просто поток байтов. Как он и хранится в файлах или памяти. Пайпы это просто тупой способ передать поток байтов в неком упрощенном случае.

Даже при такой простоте файлы используются гораздо чаще пайпов, а пайпы давно вытеснены в нишу локальными сокетами. А текстовость фактически так и осталась только в области где она более менее удобна, а не «везде».

В самом деле, большие ли сейчас проблемы с этим? Но ведь протокол

(текстовый) вроде как один и всем хватает


С чем проблемы? Какой еще *один* протокол, вы в своем уме?

Я скорее верю в ниасиляторов, которые не смогли заимплементить более сложный вариант.


Вот я и говорю - у вас ЧСВ овер много К. Которое мешает развеятся иллюзиям.

kernel ★★☆
()
Ответ на: комментарий от simple_best_world_web_master

Ага, а потом десятки лет разгребаем такие выхлопы, лепим к ним

костыли и с сильным трудом закапываем. Примеры все знают.


Именно так и делаем. И когда такие как ты приходят через 10 лет с «идеальным решением», смеемся им в лицо и посылаем лесом. Бугагага. :):):) И они утираются, посылаются и идут лесом. Так как внедрять их «идеальное» решение некуда. Все уже занято. Ниши - нету. Занято костылями настолько плотно прибитыми, что эти костыли исчезают только с нишей.

И все что таким «разработчика идеальных решений» остается - это злобно ненавидеть и шипеть на форумах, ага. Строя из себя непризнанных «гениев». При чем «гениев» можно строить сколько угодно долго - все равно проверять на практике «гениальность» их решений никто не будет. А по этому можно обещать самые фанастические вещи. Вроде суперпроцессора и суперос :):):)

kernel ★★☆
()
Ответ на: комментарий от kernel

> Про аппаратную строгую типизацию поросите кого-нибудь рассказать.

Говно ненужное :)

Фанат строгой типизации это тип мозга - существовавший во все времена :)

Не, это единственный здравый подход к делу %)

tailgunner ★★★★★
()
Ответ на: комментарий от kernel

>> В Multics была иерархическая ФС.

Там была какая то гораздо более хитрая система, имхо.

Насколько я помню историю, это была иерархическая ФС с отображением файлов в память.

То что некоторые ее части походили на иерархическую FS ничего не значит :)

Unix хватило копирования этих «некоторых частей» :)

tailgunner ★★★★★
()
Ответ на: комментарий от simple_best_world_web_master

>А сколько человек пилит Plan9?

Достаточно. Просто они не кричат на каждом шагу «Мы делаем Русскую/Нерусскую Операционную Систему». Не ждут распилов, похвал, новых разрабов, которые за них всё сделают. Они занимаются своим делом.

Оцените, сколько человеко/лет потрачено на разработку BSD, Linux. Вы согласны ещё 15 лет пилить свой призрак не имея нужное количество разработчиков и денег?

anonymous
()
Ответ на: комментарий от kernel

> Пока я вижу что есть группа безумны фанатов на лоре, у которых разве что пена изо рта не течет ;), которые кричат «хацкелл - будущие111», «а когда наши танки войдут в город, все будет на хацкеле а всех несогласных в биореактор».

<flame> Нет! Dependent types и Agda2 - будущее!!! А всякие статически недотипизированные Хаскеллы годятся только для прототипирования и мелких проектов. </flame>

pitekantrop ★★★
()
Ответ на: комментарий от simple_best_world_web_master

>Многие просто не в состоянии осознать всю красоту идеи и кидаются какашками.

Кроме красоты должно быть удобство использования как для юзверей, так и для программистов, а также общая логичность конструкции на практике т.е. чтобы оно работало и писать под него не двойным раком69

darkshvein ☆☆
()
Ответ на: комментарий от kto_tama

>> единое адресное пространство всех процессов

утопия

объясни почему (и да, у меня сомнения в том, что ты меня полностью прочитал)

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от simple_best_world_web_master

>Ты говоришь так, словно багов в x86 небывает (а они есть)

быстро сравнивать объем микрокода цпу и объем кода jvm - дальше думать логически, если не получается пробовать еще раз и так до просветления.

Я тебе просто показал, что драйвера в юзерспейсе возможны, а теперь представь, что это единственный контекст

даже если все драйвера в одном контексте, то будут контекст свитчи в микроядро - это очевидно, ну а если все драйвера в одном контексте (оно ж на С будет) то надежность этой системы полное г, уехал стеком или замемсетил код другого треда-драйвера - и вуаля.

Мальчик, ты вообще в курсе про трансляторы, а? Как оно и зачем?

Оно спасибо за комплимент, но я к сожалению уже давно не мальчик и про трансляторы знаю, а вы про архитектуру ОС и про общие принципы не знаете, это видно из того что мне тут понаписано в ответ.

Где ты увидел попилы - я не знаю, а идиота я пока вижу только в тебе (а ты во мне - это зеркально)

С точки зрения технически грамотных специалистов, все то что говорит фрик завалишин, и как он это говорит и как отвечает - выглядит как минимум смешным, да и логически если подумать, ОС с нуля, причем не просто ОС а general purpose OS с нуля - это вообще полный бред, в том числе и с экономической точки зрения. А если оно пиарится и, наверное, продвигается в русиш попилоИТ - то очевидно что это попил. Но мне кажется что завалишин просто идиот и ему нравится много говорить и строить из себя важного кренделя.

По поводу все на жабке - там говорилось про поддержку сей и прочего, что как бы говорит нам, и при этом одно адрестное пространство.

Впрочем, из тех кто повелся видно что люде «не в теме» ОС строения. Ибо сама идея стара как мир, а то как она преподносится это полный ФГМ.

alphex_kaanoken ★★★
()
Ответ на: комментарий от pitekantrop

А всякие статически недотипизированные Хаскеллы

мы вообще-то говорим об ОС; завалишин, при том, что он четко не описывает идею, попытался, дать программе больше гарантий относительно окружения — что фактически означает какую-то статическую типизацию

понятно, что дать безусловные гарантии (как он пиарит это в статье) можно только с помощью такой строгости, что это будет маразмом; но можно попытаться спасти подход, рассмотрев типизацию в духе «если... то...» ________________________________________________________________

а хаскель действительно недотипизированный — попробуй описать на нем тип фильма Film:

существуют такие натуральные и неизвестные во время компиляции m,n (это размеры кадра), что Film является последовательностью из двумерных массивов размерности m,n

на с++ есть хорошее приближение:

template<const int& m, const int& n> class Frame {
    /// тут обертка над std::vector для организации двумерного массива
}

template<const int& m, const int& n> struct Film {
    std::vector< Frame<m,n> > value;
}

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

> мы вообще-то говорим об ОС; завалишин, при том, что он четко не описывает идею, попытался, дать программе больше гарантий относительно окружения — что фактически означает какую-то статическую типизацию

Сомневаюсь, что люди, для которых Жаба - венец творения, могут создать что-то путное.

на с++ есть хорошее приближение

Помню, обсуждали это уже на ЛОРе, причём ты и начал.

Прикольная фишка, но это нифига не зависимые типы, так что С++ по сравнению с Agda тоже недотипизированный.

pitekantrop ★★★
()
Ответ на: комментарий от pitekantrop

возможно фильмы лучше непонятного рядовому прогеру скалярного произведения

Сомневаюсь, что люди, для которых Жаба - венец творения, могут создать что-то путное.

я тоже

но это нифига не зависимые типы, так что С++ по сравнению с Agda тоже недотипизированный.

а по длине кода (включая сюда длину кода верифицируемого ЯП) и по возможностям?

что бы ты такое предложил сделать, что на агде пишется легко, а на с++ заставит попотеть?

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от pitekantrop

Сомневаюсь, что люди, для которых Жаба - венец творения, могут создать что-то путное.

блин копирайт на афоризму оформляй!!!!!! вещь сказал!!!

erfea ★★★★★
()
Ответ на: комментарий от simple_best_world_web_master

Все эти морды одинаковы. Сам интерфейс мпд предполагает 5-6 кнопок, плейлист и дерево каталогов. Попробуй например вместо плоского плейлиста сделать древовидный, и поймешь, что за ограничения протокола тебе не выйти.

farafonoff ★★
()
Ответ на: комментарий от simple_best_world_web_master

Мы не выхлопы разгребаем а _пользуемся_. Причем прямо сейчас. Да, я предпочитаю временное решение прямо сейчас, чем глобальное и надежное через год.

farafonoff ★★
()
Ответ на: комментарий от simple_best_world_web_master

программист должен поделить все ошибки на восстановимые и невосстановимые. Если программист ПРЕДПОЛАГАЛ ту или иную ошибку (файл не найден, соединение разорвано), надо записать в лог и восстановиться, иначе надо выдать пользователю максимум информации и выйти из программы.

farafonoff ★★
()
Ответ на: комментарий от simple_best_world_web_master

Форматы файлов изобретаются не для того чтобы усложнить жизнь, они решают вполне реальные задачи. Сравни например pdf и odf. Они предназначены для документов, но ни в коем разе не могут заменить друг друга. Иными словами, если я открою документ через твои трансляторы, отредактирую и сохраню, и вдруг потеряю все шрифты и картинки, потому что мой редактор написан 10 лет назад, кому мне жаловаться?

farafonoff ★★
()
Ответ на: комментарий от darkshvein

Дык все для пользователей и программистов создается, а не ради абстрактной красоты. Пользователи получат унифицированный функционал, а автор очередного плеера сможет сосредоточится на тех задачах, ради которого он его создавал, а не хоткеях или автосохранялках.

simple_best_world_web_master
()
Ответ на: комментарий от simple_best_world_web_master

Дык все для пользователей и программистов создается, а не ради абстрактной красоты. Пользователи получат унифицированный функционал, а автор очередного плеера сможет сосредоточится на тех задачах, ради которого он его создавал, а не хоткеях или автосохранялках.

Блин смешно аж, такое упрощение жизни программиста, ведущее к жуткой залаганости и прожорливости ПО... Игра не стоит свеч, лучше пусть кодеры работают все же, а не полагаются на систему сделавшую за них всю работу, да еще и такой ценой.

erfea ★★★★★
()
Ответ на: комментарий от alphex_kaanoken

> быстро сравнивать объем микрокода цпу и объем кода jvm - дальше думать логически, если не получается пробовать еще раз и так до просветления.

На кишки jvm я смотрел, ты наверное будешь удивлен, то большая часть написана на самой жабе, а вот кода микропроцессора я не видел - как сравнить?

(оно ж на С будет) то надежность этой системы полное г, уехал стеком или замемсетил код другого треда-драйвера - и вуаля.

на жабе же

а вы про архитектуру ОС и про общие принципы не знаете, это видно из того что мне тут понаписано в ответ

Ох, зря я зачитывался osdev(er), наверное там вранье пишут. Нехорошие люди такие.

С точки зрения технически грамотных специалистов, все то что говорит фрик столлман, и как он это говорит и как отвечает - выглядит как минимум смешным, да и логически если подумать, ОС GNU с нуля, причем не просто ОС а general purpose OS с нуля - это вообще полный бред, в том числе и с экономической точки зрения.

fixed

А если оно пиарится и, наверное, продвигается в русиш попилоИТ - то очевидно что это попил. Но мне кажется что завалишин просто идиот и ему нравится много говорить и строить из себя важного кренделя.

А если он просто разработчиков ищет, ну или просто сочуствующих?

По поводу все на жабке - там говорилось про поддержку сей и прочего, что как бы говорит нам, и при этом одно адрестное пространство.

Я не завалишин, тут ничего сказать не могу. Возможно решать он будет это через JNI, возможно что-то свое изобретет.

Впрочем, из тех кто повелся видно что люде «не в теме» ОС строения. Ибо сама идея стара как мир, а то как она преподносится это полный ФГМ.

Ну по крайней мере с точки зрения юзера (который не будет терять документы) и разработчика, которому писать кода меньше - это красиво, согласен?

simple_best_world_web_master
()
Ответ на: комментарий от farafonoff

> Все эти морды одинаковы. Сам интерфейс мпд предполагает 5-6 кнопок, плейлист и дерево каталогов. Попробуй например вместо плоского плейлиста сделать древовидный, и поймешь, что за ограничения протокола тебе не выйти.

Виджеты головного мозга? 5-6 кнопок? Какие же? Будет ли кнопка «отслеживать изменения статуса ICQ-юина и скачивать музыку из него», дабы слушать теже треки, что и моя подруга? MDP очень даже подойдет. Будет ли кнопка «посмотреть обложки» с возможностью потыкать на треки на ней? MDP очень даже подойдет для проигрывания и такой музыки. Или «открыть слова», дабы подпевать? Ведь создание мешапов никто не запрещал, а даже наоборот, приветствуют? Будет ли кнопка «начать скробблить в ластик» или «отпостить в жуйку»? Нужна ли кнопка «ознакомление», дабы когда я суну в плейлист 20 гигов новой музыки мне не приходилось минут 10 бегать по трекам и знакомится с ними?

Хочешь древовидный список? Да никаких проблем! Представь себе обложки альбомов, из котороых свисают нити-исполнители, а из них нити-треки? Или года, потом исполнители, потом альбомы-треки? Или медальки от 1 до 10, отражающие рейтинг трека в каком-то коммунити? Строить такое дерево можно очень долго, 10 полей данных дает 3628800 вариантов построения. Тебе мало?

Заметь - это все проблемы интерфейса, а не самого приложения, задача которого проста - играть музыку.

simple_best_world_web_master
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.