> Почему нельзя выпустить апдейт? Просто тупой апдейт. Зачем ждать полгода?
Нереально для большинства актуальных Linux дистрибутивов. Ехали зависимости через зависимости. Ехали shared библиотеки через shared библиотеки.

>>37133
Для прикладного софта не актуально, он в 99% не будет требовать самых свежих библиотек. А если вдург потребует - почему бы блеать не включить в апдейт эти самые библиотеки?
И вообще, в жопу эту пакетную систему. Она просто убивает всю десктопность. Запилите как в макоси, а всякую системную ерунду через апт обновляйте сколько влезет. Сделайте епта!

>>37136
Ну сделай.

>>37138
Что за хамство? Сам бери да и делай, раз тебе надо.

>Для прикладного софта не актуально, он в 99% не будет требовать самых свежих библиотек.
Ты это скажи разработчикам прикладного софта, который под Linux в большинстве случаев представляет собой либо очередной "супер-мега-плеер-на-питоне-который-неудачно-косит-под-windows-only-аналог", либо монстрообразное черт знает что, разобраться в котором давно не могут и сами разработчики.

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

>И вообще, в жопу эту пакетную систему. Она просто убивает всю десктопность.
Да, но без нее в Linux вообще был лютый ад и содомия.

>Запилите как в макоси, а всякую системную ерунду через апт обновляйте сколько влезет.
Во-первых, это не "кошерно" с точки зрения ололо разработчиков opensource ПО. Во-вторых, как раз обновление системной ерунды еще быстрее столкнется с "зависимости через зависимости".

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

Нормальный драйвер для железа все равно будет писать никто иной как его производитель. И, если "железо" это не стандартное говно, типа вебкамеры или принтера, то такой драйвер будет закрытым. По вполне очевидным причинам. И как закрытый компонент будет нормально уживаться с системой, в которой все делают исходя из того, что в случае чего этот компонент просто переделают, пересобирут, доделают, запатчат и т.д.? Разработчики выпускают новую версия X сервера? Со старым драйверами он не работает. Разработчики выпускают новый Gnome? Он требует новый X сервер, который не работает с существующими драйверами. Ну и так далее по всем фронтам. Чего уж говорить про закрытый софт под Linux, который часто тупо поставляется в комплекте с системой на которой он точно будет работать.

А все потому, что зоопарк, быдлокод, отсутствие хоть какой-то стабильности и прогнозируемости. А еще распыленность и отсутствие нормальной прибыльности для разработчиков. Поэтому ведь не в том, что ломают - ломают и в Windows (сколько всего сломали в Windows Vista и 7, ух), ломают и в Mac OS X, однако там ломают совсем по-другому. Во-первых мало (по сравнению с Linux), во-вторых об этом известно заранее и есть возможность подготовиться (документация, куча бета и релиз-кандидатов для разработчиков перед выпуском), а в-третьих эти изменения, со временем, будут у большей части пользователей - никто не сделает новый дистрибутив, в котором захочет оставить все "по старому", раздробив варианты решений под которые прийдется плясать разработчику ПО.

>>37139
Мне не надо, меня дебиановкая система управления пакетами и линуксячий подход к библиотекам худо-бедно устраивает. Это >>37136-пассажир хочет чтоб фигакс!, и было красиво.

>>37142
> Ты это скажи разработчикам прикладного софта, который под Linux в большинстве случаев представляет собой либо очередной "супер-мега-плеер-на-питоне-который-неудачно-косит-под-windows-only-аналог", либо монстрообразное черт знает что, разобраться в котором давно не могут и сами разработчики.
И при чем здесь совместимость?
>А эти самые библиотеки будут нужны не только ему
И?

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

Ну а насчет закрытого софта, как такового - это не проблема линупса. Никто не запрещает писать закрытые программы, и их пишут, и иногда даже нормально пишут. Те же WingIDE или хром (не путать с хромиумом) - обычный софт, никаких проблем с ним нет.
Вообще, проблема надумана. Если рандомный автор софта, которым я пользуюсь, вдруг сделает свою программу закрытой, я этого даже не замечу - ведь я все равно ставлю бинарный пакет. Другое дело, что стандартизация базовой системы с основным набором библиотек и установка программ, как в макоси - это очевидный путь развития и к нему рано или поздно придут. Он просто лучше во всех отношениях.
Алсо не отвечайте на этот пост, пожалуйста. Я знаю, что вы не послушаете. Засранцы.

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

> По остальным пунктам ты банально сгущаешь краски.
Прости, но я вынужден сказать "толсто". Есть причина почему Debian Stable - это окаменелое говно мамонта, Fedora - глюкодром, а во всяких Arch Linux вообще что-то ломается чаще, чем чиниться. И причина эта как раз описана выше.

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

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

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

> Исключения - видеокарты и некоторые вайфай-карты
Т.е. одни из наиболее важных комплектующих, да.

> Ну а насчет закрытого софта, как такового - это не проблема линупса
Пока разработчики Linux based OS будут себя в этом убеждать, то и не будет нормальной ситуации с драйверами и качественным ПО, потому что это как раз проблема Linux.

> Никто не запрещает писать закрытые программы, и их пишут, и иногда даже нормально пишут
Естественно, но чаще всего их написание/работа идет в разрез с работой остального ПО/компонентов системы, что либо вызывает лишние проблемы в работе, либо лютые глюки. Поэтому это ПО либо жестко ставит в системные требования конкретную версию конкретного дистрибутива (например, только Debian Stable), либо вообще поставляется сразу с дистрибутивом, либо вообще продается в виде программно-аппаратного комплекса (сервер с настроенной системой и собственно этим ПО).

>я этого даже не замечу - ведь я все равно ставлю бинарный пакет
Еще как заметишь, ПО в репозитории обслуживают мейнтейнеры дистрибутива, собирая его с теми изменениями, которые считают нужными для своего дистрибутива. Закрытое ПО обсуживает сугубо его разработчик. Историю с IceWeasel напомнить? А если бы FireFox был закрыт или лицензирован чуть-чуть иначе? Соснули бы гордые пользователи Debian.

> это очевидный путь развития и к нему рано или поздно придут
Не прийдут, ни в Windows, ни Linux. Это слишком "по другому", по отношению к их многолетнему опыту и сложившейся практике, иначе бы уже все давно реализовали, но вместо этого в той же Windows при установке, к примеру, игры нужно ставить вагоны костылей в виде Microsoft Windows C++ Redistributable и все считают, что это нормально и заебись. Очевидные пути и нормальные решения далеко не всегда используются и применяются, если ты не заметил, иначе с какого перепугу еще существует реестр в Windows?

>>37159
> Алсо не отвечайте на этот пост, пожалуйста.
Я же просил. Что ты за человек такой?

>>37167
Плохой, очевидно же, недавно вот в даже одной джаббер-конференции забанили.

>>37175
> в даже одной джаббер-конференции забанили
Сам виноват

>>37176
Что поделать, модераторы уж слишком баттхертящие попались.

>>37132
Машины неплохие, но не новые. Материнки не топовые, а с зарезанными частотами шин. И дело даже не в них и не частоте, а в количестве и шустрости оперативки (DDR1 256 на одной и 768 на другой) - Гномик всё съел. Отсюда своп и дикие тормоза. Юнити тормозит не меньше.

По поводу апдейтов. Лично для меня лучше всего rolling-release, как у Arch. Но тут надо постоянно обновляться, скажем, раз в месяц (что могут далеко не все). Если это делать раз в год, есть вероятность, что что-нибудь полетит. И такая схема совсем не катит для рабочих серверов.

И хватит срач разводить на пустом месте. Есть реальная проблема. Линукс скоро скатится в сраное говно: мантейнеры дистров едва поспевают за революциями Иксов (hal'ы, udev'ы, policykit'ы всякие там) из за которых постоянно отваливаются системы автомонтирования устройств, разные драйверы и т.п. А ядро скоро лопнет по причине большого объёма и трудностей с поддержанием этого объёма в стабильном сосотоянии. Даёшь микроядра! (Ох и вбросил :3)

>>37159
>видеокарты — одни из наиболее важных комплектующих

В игрушки играть?

>>37180
Не нужно ничего изобретать. Добрый дядя Джобс все уже давно за нас придумал. Просто реализуйте.

>>37185 И что же он придумал?

>>37186
Систему, в которой все прекрасно.

>>37180
> Даёшь микроядра!
Что ж вы HURD не пилите, сволочи?! Ах, на готовенькое придти и потом обосрать всегда проще, понимаю.

>>37185
У меня от Джобса ПАТЕНТНОЕ ПРАВО.

>>37190
Архитектура макос не является тайной или объектом патентного права.

>>37188
Я не умею.

У МакОси та же архитектура, что и у Линукса - Unix. И дело не в ней. Эппл просто с умом использовал всякие свистоперделки. В итоге получилась достаточно неплохая система. И хотя системных ресурсов она кушает будь здоров, эти самые ресурсы идут как неотъемлимая часть системы (собственное железо). Единственный минус (хот и оправданный немного) - жуть как дорого.

>>37199
> У МакОси та же архитектура, что и у Линукса - Unix. И дело не в ней.
Охуеть.

>И хотя системных ресурсов она кушает будь здоров
Угу, угу, только почему-то она без тормозов может работать (нормально работать) на одноядерном атоме с недоразумением GMA950 в качестве аппаратного ускорителя интерфейса. Так что же она жрет?

>>37202
Да не обращай внимания на этих всезнаек. Макось - замечательная система с абстракциями только там, где они нужны. Это вам не венды/линупсы, где одна абстракцию на другой и третьей погоняет.

>>37200
Трололо? Ты не знал, что МакОсь прямой потомок Юникса, а Линукс клон всё того же Юникса?

>>37202
>на одноядерном атоме с недоразумением GMA950
Я что-то не догоняю... это ты про iPad? Тогда я тебя обрадую. Там не Атом, а АРМ, и не ГМА, а PowerVR, и даже иОС не то же самое, что МакОС.
>Так что же она жрет?
Если мы всё ещё про МакОсь - жрёт она Core2 Duo + 2GB RAM + nVidia... хорошо куашетю Но благодаря тому, что МакОсь продаётся только с Маками в комплекте, в которых всё это есть, то всё летает.

>>37203
А в МакОси тоже абстракция на абстракции. Но сдело всё с умом и большими деньгами. В Линуксе было бы тоже всё замечательно, будь у него центр, который бы принимал решения. А так - сообщество, которое постоянно колбасит на разные технологии и нет единого мнения. Как результат - кучи дистрибутивов, каждый со своими прибабахами.

>>37235
>МакОсь прямой потомок Юникса
Википедия утверждает, что ты не прав.

Ядро макоси основано на микроядре Mach (клон ядра unix'а), с заимствованиями кода из NeXTSTEP и FreeBSD.

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

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

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

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

>>37236
>Википедия утверждает, что ты не прав.
Копай глубже, Люк. Английская вики:
The Mac OS X operating system, developed from Mac OS Classic family, and NeXTSTEP, which was UNIX-based.
Фряха потомок Юникса.
НекстСтеп тоже потомок Юникса
И потом я не только ядро имел в виду, а вообще всю ось.

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

Пример: XFCE. Раньше он монтировал флешки через HAL (иди UDev, не важно), потом HAL из деистрибутива выпилили. Некоторое время всё было как-то через одно место. Потом появился Policykit без какой-либо документации. И чтобы монтирование заработало надо было запускать XFCE командой ck-launch-session, назначение которой было мало понятно. Внятной документации к ней не было и ни на одном форуме никто так и смог ответить что это за хрень. Завтра что-нибудь ещё придумают на замену механизму, который и так отлично работал.

>>37237
Стандарты и соответствие им - это хорошо. Но важно, чтобы стандарты были общими, а не свои у каждого. От количество всяких "стандартов" просто крышу срывает.

У Гугла HTML5 и у Эппла HTML5, но кодек видео у каждого свой (не договорились, блджад) и у каждого это стандарт. Есть стандарт HTTP, но Гугл уже пилит свой стандарт на замену. Есть стандарт Джаббер, но Гугл Толк его "дополнил" своим стандартом видео, а Скайп вообще плевал на всех.

А всякие патентные проблемы этих "стандартов" вызывают лишь идиотскую улыбку, так как патентуют в основном колёса и весьма успешно. Чего стоит патент (Майкрософта, кажется) просто на принцип автоматического обновления программы через интернет - с этим они пытались наезжать на Apt и RPM!

>>37235
> Трололо? Ты не знал, что МакОсь прямой потомок Юникса, а Линукс клон всё того же Юникса?
Ох вау, школьник открыл для себя мир операционных систем, и теперь делится своими знаниями с окружающими. Ну надо же.

>>37238
> Фряха потомок Юникса.
Друзья, но это же пиздец. Оно называет линукс клоном юникса, а фряху - прямым потомком. Забаньте этого дегенерата, оно же не умеет анализировать информацию, додумывая то, что не успело нагуглить.

Прекратите оперировать словом Unix, если вы не знаете, что это такое.

>>37243
А если знаем, можно не прекращать?

BSD произошел от Unix. В конечном итоге ядро BSD избавилось от остатков кода Unix и стало полностью свободным. Разумеется, моя любимая ветка ядра BSD это FreeBSD. У меня даже футболка есть со старым логотипом FreeBSD. Внезапно хорошая футболка с шелкографией, вот уже 5 лет ей и хоть бы что.

>>37246
С таким же успехом от юникс произошли все юникс-подобные клоны.

>>37247

Насколько я помню историю, няша, BSD с самого начала содержал код Unix, то есть строился на нем.

>>37235
Не нужно пытаться отвечать на то, чего я не говорил. Я сказал все вполне однозначно: одноядерный Atom и GMA950, в данном случае, интегрированные в mini-ITX материнские платы производства Intel. Так вот, если ты не знал, то Mac OS вполне может работать и за пределами Apple-labeled железа, при должном желании и совпадении звезд на небе (т.е. наличии драйверов). Зачем это нужно - вопрос уже другой, но сам факт абсолютно соответствует действительности. Так вот, используя эти mini-ITX системы, вполне можно собрать некий неттоп под управлением Mac OS, который, по какой-то мистической причине, будет работать куда лучше, чем под "обычными" ОС (Windows XP, Windows 7, Ubuntu). И да, работать нормально оно будет и с 1 Гб оперативной памяти, но наличие 2 Гб сделает работу куда приятнее. Такие решения где только не описывались (включая заграничные интернеты и Хабрахабр), однако я все это делал и проверял лично своими руками. Такие дела.

Ну и кроме того, Mac OS X вполне официально работает на старых Mac Mini, в которых стояли и Core Solo, и Core Duo (обычные, не Core 2 Duo). И таки в них очень долго стояли разные сорты GMA убожества от Intel. Да, по слухам, в следующей Mac OS X 10.7 Lion ограничат минимальный процессор на уровне Core Duo или Core 2 Duo (при этом, ограничение, как обычно, можно будет снять одной строкой в текстовом файле), однако не из-за требований самой ОС, а скорее из-за общих требований к производительности системы для работы с прикладным ПО - чтобы разработчики (например, в том же Mac App Store) знали, с чем они работают, а пользователи не баттхертили от попыток одновременно поназапускать кучу современного софта на старых машинках, как они это делали раньше.

>>37248
> BSD с самого начала содержал код Unix, то есть строился на нем.
Во-первый, няша, не путай BSD и FreeBSD (макось брала окружение именно с FreeBSD). Во-вторых, последняя - это попытка переписать коммерческий юникс с нуля, в нем нет ни одной строчки этого самого юникса, равно как и в линупсе. Следовательно, это всего лишь клон, а не потомок.
Потомки - это чпукс и солярка.

Холивар на холиваре и холиваром погоняет.

В вас не осталось ни строчки кода ДНК первого человека, вы тормозите на решении дифференциальных уравнений и глючите при попытке принять ИСТИННОГО БОГА!

Скиньте кто-нибудь книжку по ядру FreeBSD 4. Не могу найти

>>37280
> В вас не осталось ни строчки кода ДНК первого человека
Няша, гугл подсказывает, что ДНК человека всего на 2-3% отличается от ДНК шимпанзе. Поменьше умничай.

>>37282
>ДНК человека всего на 2-3% отличается от ДНК шимпанзе.
Вот, а ДНК первого человека отличалось на 99.3%! Видите, как мы деградировали с тех пор?

>>37283
Ты что, тупой? В Индии корова - это священное животное!

>>37284
Это ты — тупой. Катамаран не перископ.

А зачем вейланд-то?

>>37417
Предполагается, что выкинув кучу ненужного на десктопе обратная совместимость с дремучими терминалами, встроенная работа по сети и ещё куча всего кода и сплавив икс-сервер с оконным менеджером в один процесс, мы освободим много-много оперативной памяти и тактов процессора, избавившись, заодно, и от кучи глюков, вызванных сложностью архитектуры xoeg'а.

>>37420 я правильно понимаю, что опенбокс, например, работать с ним не будет, если оконный менеджер встроен с графическим сервером?

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

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