О шароваре и десктопном Линуксе

[thedeemon]

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

Да нет у него никаких перспектив.

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

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

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

Типичные слова линуксоеда: "Если бы люди умели пользоваться vim, grep, sed, awk, то миллионы программных продуктов так никогда и не были бы созданы (C) кто-то умный". В том-то и беда. Именно так теряется 95% аудитории - основная масса юзеров не будет тратить по полгода на изучение этих ваших vim, grep, sed, awk, perl и bash. Им нужна программа с красивым окошком и кнопкой "сделать п%$дато", а не набирать в консоли "ps aux | grep dmz | awk '{ print $3, " ", $2 }' | sort | tail -n 5 | awk '{ print $2 }' | xargs kill -9". Нужен простой и удобный в использовании софт, решающий конкретные задачи рядовых и не очень пользователей. Такие программы будут только там, где будут коммерческие разработчики, которые смогут их продавать за доступные хоум-юзерам деньги. А для такого софта дистрибуция в исходниках никак не годится.

Вот есть, например, Маки. Там дистрибуция и установка программ в бинарной форме была отточена отлично, оттого куча удобного, приятного и радующего пользователей софта, за который те с радостью платят деньги. Есть винда, где я компилю в Win7 бинарник с минимумом зависимостей, и он прекрасно работает и в Висте, и в ХР, и даже в Win98. В нем я могу реализовать какую-то пусть не идеальную, но работающую защиту от взлома, и спокойно его продавать. А вот понадобилось мне недавно простейшую консольную прогу запустить на хостинге с этим вашим линупсом, так нет - нужного компилятора там не стоит и прав нет поставить, просто собранный бинарник не работает из-за другой версии GLIBC, а статически собранный - не работает, потому что ядро, дескать, слишком старое, хотя и там и там 2.6.чего-то. При таком подходе я буду продолжать делать шаровары для винды и мака, а линуксоеды пусть дальше довольствуются своими поделками.

Comments

[stepancheg.livejournal.com]

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

[stepancheg.livejournal.com]

По сравнению с какой операционной системой?

[stepancheg.livejournal.com]

Мой рабочий компьютер — MacOS X. Если на нём компилировать программу в два потока в течение 10 минут, система начинает сильно зависать на 5 секунд, примерно раз в минуту.

Если в MacOS X делать создавать высокую дисковую активность (например, копировать файл), то MacOS X также может начать тупить, но это сложнее воспроизвести.

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

Навскидку, одна из проблем Windows — не POSIX. Серверная программа, которую я пишу на работе, должна работать под Linux, FreeBSD, MacOS X и Windows. Поддержка совместимости с Windows обходится мне в разы дороже, чем поддержка всех остальных операционных систем.

У Windows страшные API, этих API много, все они сложные, и они друг друга исключают. Например, в POSX есть poll, он работает с файловыми дескрипторами. В Linux есть epoll, он тоже работает с файловыми дескрипторами, и это простая замена poll. В Windows poll работает только с сокетами. Есть WaitForMultipleObjects, но он, то ли не работает с сокетами, то ли работает как-то через жопу. Ну то есть есть отдельный API для сокетов, и отдельный API для файлов.

Windows, фактически, одноплатформенная система (т. е. i386/x86_64), линукс работает на десятках платформ.

В линуксе есть Shell как язык программирования, с помощью которого можно быстро решать простые задачи. В Windows таких простых инструментов нет.

Плюс в Windows есть реестр — и это большая проблема.

В общем, не знаю я, что не так в Windows. Раз в месяц приходит письмо, что наш внутренний сервер перезагружается. Наверное, это от технологического несовершенства. Наши сервера под Linux/FreeBSD не перезагружаются месяцами, а то и годами.

[thedeemon.livejournal.com]

>Мой рабочий компьютер — MacOS X. Если на нём компилировать программу в два потока в течение 10 минут, система начинает сильно зависать на 5 секунд, примерно раз в минуту.

Если в MacOS X делать создавать высокую дисковую активность (например, копировать файл), то MacOS X также может начать тупить, но это сложнее воспроизвести.

В приведенном выше интервью чел жаловался на подобные же проблемы в Линуксе, их-то он и пытался исправить.

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

Реестр иногда приносит проблемы, зато хотя бы имеет единую предсказуемую структуру с единым API. В Линухе каждая программа хранит настройки как заблагорассудится.

А сервер ваш может быть банально перезагружается при установке апдейтов. Моя виста на ноуте тоже раз в 2-3 недели просит перезагрузиться для их установки.

В общем, пока не убедил. ;)

[stepancheg.livejournal.com]

Спорить можно до бесконечности. Давай тут остановимся и останемся при своих мнениях.

[thedeemon.livejournal.com]

Да, если возникнет один дистрибутив - стандарт де-факто, тогда шанс появится.

подсказка

[nealar.livejournal.com]

Такой производитель железа называется Apple. Правда, линуксовое ядро их уже не устроит. Старьё.

Re: подсказка

[stepancheg.livejournal.com]

Вы плохо понимаете, о чём говорите.

Re: подсказка

[nealar.livejournal.com]

Ну так объясните мне ;)

Re: подсказка

[stepancheg.livejournal.com]

Линуксовое ядро не было выбрано Apple не потому, что оно "старьё" (я писал выше, что технологически Linux гораздо лучше MacOS X), а потому что лицензия GPL накладывает слишком много обязательств на компанию, которая собирается его использовать. Принципиальная разница между Apple и этой другой компанией будет в том, что наработки этой другой компании могут быть использованы бесплатно. Как, например, есть CentOS, копия коммерческого дистрибутива Red Hat, но нет бесплатной и с исходниками копии MacOS X Server.

Re: подсказка

[nealar.livejournal.com]

Про лицензию всё понятно. Очевидно, что линуксовое ядро "как есть" они взять не могли. Но юникслайк какой-нибудь вполне могли подобрать. Оченно похожий. К примеру, BSD/OS и FreeBSD в какой-то мере кодом обмениваются. Только ядра такого замечательного у них бы не было, потому что линуксовое им бы ни под каким видом не уступили.
Проблемы у этой второй компании будут именно в том, что тот_продукт_который_они_лично_продадут_юзеру уже сделан еплом. То есть, налицо конкурентный недостаток. А для тех, кто мог бы бесплатно использовать их наработки, это преимущество, да.
То есть, фирма пытается сесть между стульев Apple и Red Hat.

Re: подсказка

[stepancheg.livejournal.com]

Apple можно победить меньшей ценой и более широкой поддержкой оборудования.

Red Hat принципиально не занимается десктопами.

Re: подсказка

[nealar.livejournal.com]

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

Re: подсказка

[stepancheg.livejournal.com]

Нельзя их победить поддержкой оборудования

Я имел в виду поддержку в широком смысле слова. В MacOS X можно синхронизировать песни в iTunes только с iPod и iPhone.

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

Re: подсказка

[nealar.livejournal.com]

То есть, речь не только о драйверах. Тогда у линухов, действительно, есть шанс. Они более пофигистичны в смысле "что к чему цеплять", нету центральной идеологии. то даёт болmше возможностей.

Re: подсказка

[nealar.livejournal.com]

Особенно прошу объяснений, почему монолитное ядро - не старьё.

Re: подсказка

[stepancheg.livejournal.com]

Вы опять не понимаете, о чём говорите.

Если мы говорим о теории, то микроядра тоже уже устарели — они слишком дороги, и будущее за виртуальными машинами, см. Singularity. Managed environment позволяет добиться большей производительности, чем монолитные ядра (не говоря уж о микроядрах), и при этом предоставляет тот же уровень безопасности, что и микроядра.

Если мы говорим о практике, то насколько я знаю, в MacOS X большинство частей операционной систсемы сделано не внешними процессами, а прямо в компилено в ядро, т. е. микроядерность не используется. Опять же, говорят, что архитектура Mach устарела, и что L4Ka, например, работает быстрее.

При этом падает MacOS X чаще Linux, потому что написано хуже.

Re: подсказка

[nealar.livejournal.com]

Если мы говорим о теории, то микроядра тоже уже устарели — они слишком дороги, и будущее за виртуальными машинами, см. Singularity. Managed environment позволяет добиться большей производительности, чем монолитные ядра (не говоря уж о микроядрах), и при этом предоставляет тот же уровень безопасности, что и микроядра.
Где бы про это почитать? Если Вы настолько хорошо понимаете, о чём говорите, как Вам кажется, то микроядро получается тупиковой веткой - оно появилось позже виртуальных машин. И технически реализуется, кмк, сложнее.
насколько я знаю, в MacOS X большинство частей операционной систсемы сделано не внешними процессами, а прямо в компилено в ядро
Что Вы называете "частями операционной системы"?
говорят, что архитектура Mach устарела, и что L4Ka, например, работает быстрее
Наверняка устарела. Прикиньте, сколько ей уже лет. Но я вот так вот сходу не сумею назвать _совсем_не_устаревшую_ архитектуру, которая используется в серьёзных масштабах. А если мы уж говорим о лунксе и виндах....
L4Ka
А что это?
При этом падает MacOS X чаще Linux
ЩИТО?

Re: подсказка

[stepancheg.livejournal.com]

Если Вы настолько хорошо понимаете, о чём говорите, как Вам кажется, то микроядро получается тупиковой веткой - оно появилось позже виртуальных машин. И технически реализуется, кмк, сложнее.

Конкретных ссылок дать не могу.

Микроядрам десятки дет. Виртуальным машинам в ядре от силы — 10. Виртуальные машины в ядре стали возможны сравнительно недавно, когда на компьютеры стали ставить быстрые процессоры и много памяти.

Я думаю, что качественно сделанные виртуальные машины сложнее, чем качественно сделанные микроядра.

Что Вы называете "частями операционной системы"?

Например, драйвер файловой системы, сетевой стек.

L4Ka
А что это?

http://lmgtfy.com/?q=l4ka

падает MacOS X чаще Linux

Программы, которые я пишу, работали на десятках серверов. Не припомню, чтобы линукс падал (хотя это, конечно, возможно). Мой домашний ноутбук с линуксом вообще не перезагружался уже полгода, наверное.

Kernel panic на MacOS X я видел на всех трёх имеющихся у меня в наличии ноутбуках Apple/MacOS X, разных моделей.

Это при том, что MacOS X работает только на проверенном железе, сделанном по заказу Apple, а Linux работает на чём угодно.

Re: подсказка

[nealar.livejournal.com]

Виртуальные машины в ядре стали возможны сравнительно недавно, когда на компьютеры стали ставить быстрые процессоры и много памяти.
Чем виртуальная_машина_в_ядре отличается от виртуальной_машины_вне_ядра? Не понимаю.
Я думаю, что качественно сделанные виртуальные машины сложнее, чем качественно сделанные микроядра.
Возможно. Я просто навскидку прикинул, как выглядит тупейшее микроядро и тупейшая виртуальная машина. Ясно, что от реальности это далеко.
Kernel panic на MacOS X я видел на всех трёх имеющихся у меня в наличии ноутбуках Apple/MacOS X, разных моделей.
У меня ровно обратный опыт. Видел панику под линуксом и под BSD. Под макосью - ни разу. Под линуксом, если очень постараюсь, даже могу изобразить сценарий воспроизводимого бага (не уверен, что именно паники, всё-таки, редко вижу линукс).
А, нуиещё, мои программы на серверах работают нормально. Обычно всё крошится на десктопе. Просто потому, что на сервера, как правило, не тащат всякого малонужного барахла.

L4Ka
А что это?

http://lmgtfy.com/?q=l4ka
И что это? Там не написано. Есть ссылки "скачать" и "читать документацию".

Re: подсказка

[stepancheg.livejournal.com]

Чем виртуальная_машина_в_ядре отличается от виртуальной_машины_вне_ядра? Не понимаю

Ничем. Но виртуальная машина в ядре обязательно должна выдавать максимальную производительность, иначе операционная система будет медленно работать. Виртуальной машине вне ядра можно тормозить (как, например, тормозила JVM 10 лет назад), потому что большая часть работы выполняется не кодом виртуальной машины.

И что это?

Это архитектура (и реализация) микроядра.

Re: подсказка

[nealar.livejournal.com]

Виртуальная машина в принципе не может выдавать "максимальную производительность", потому что виртуализация - это всегда оверхед. Но это никому и не нужно, ибо "тормозить" - понятие субъективное: у некоторых и виста тормозит. Работу с совсем хардкорными (железными) вещами в ВМ не положат, поэтому, ядро с тормозной ВМ, может быть, даже не будет глючить.
Это архитектура (и реализация) микроядра.
Так ведь этих реализаций сколько угодно. Уверен, что есть и лучше. По скорости переключения контекста http://odin-os.sf.net уделывает всех, ну и где операционки, сделанные на ней?

Re: подсказка

[stepancheg.livejournal.com]

виртуализация - это всегда оверхед

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

уделывает всех, ну и где операционки, сделанные на ней

Качественного микроядра недостаточно для того, чтобы все резко начали пользоваться операционной системой, и вы это, наверное, понимаете. Тогда неясно, в чём вопрос.