Чем привязка к linux хуже привязки к РС?

всё больше софта не следует стандартам POSIX, становится linux-зависимым

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

Кто сказал, что они игнорируются?
Более того — привязка к линуксу является одним из камней в огород systemd.
Ты не слышал про Debian GNU/Hurd?
Как видишь, подавляющее количество софта не привязано к линуксовому ядру.
И БСДшное ядро прикручивали.
И всё это работает.
А systemd не работает.

всё больше софта не следует стандартам POSIX, становится linux-зависимым

Нормальный софт не использует системное API, а использует готовые кроссплатформенные библиотеки.

В то же время здесь куча регистрантов на говно исходит от зависимостей пакета от boost или Qt, например.

Ты не слышал про Debian GNU/Hurd?

Есть еще Debian с kfreebsd, и даже гента с аналогичным ядром.

Чем привязка к ядру Linux хуже, чем привязка к glibc?

В Debian GNU/Hurd используется glibc.

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

что всё больше софта ... становится linux-зависимым

Поржал. И много прикладного софта работает только под Линуксом? Я всё пропустил и вендекапец уже настал?

больше софта не следует стандартам POSIX

Что значит не следует? У линукса есть какой-нибудь альтернативный NativeAPI, как у винды? Просто POSIX не покрывает такие вещи, как работу со звуком, видео и сетью на низком уровне. Потому они специфичны для каждого ядра

glibc

Ядро должно быть одно в единицу времени. А остальные либы — ставь сколько хочешь. Не нравится glibc? Поставь рядом что-то ещё если какому-то софту нужно что-то другое.
А 2 ядра рядом не поставишь.

А 2 ядра рядом не поставишь.

Почему нет? Закинуть в /boot и переключаться в grub при ребуте.

при ребуте.

Ты меня троллишь? Тогда будешь послан нахрен, только прямым текстом.
Ядро в один момент времени загружено одно.
Библиотек может быть загружено много.
Поэтому привязка к конкретному ядру — плохо (и поэтому нормальный софт этого избегает).
А привязка к библиотекам — нормально.

Компренде?

Поэтому привязка к конкретному ядру — плохо

Я тут исключительно мимопроходил, но что делать, если софту нужна фича, которая есть лишь в одном ядре?

Не писать такой софт? Или сначала написать эту фичу во все остальные ядра?

Надо кровь из носа постараться обойти эту необходимость каким-то образом.
А если это невозможно, то быть готовым к тому, что эта программа окажется за бортом.
Все любят портируемый код. Его писать сложнее, но оно того стоит.
Что ты скажешь о программе, работающей на линуксовом ядре 3.14, но неработающей на любом другом? Вряд ли что-то хорошее.

Надо кровь из носа постараться обойти эту необходимость каким-то образом.

И писать костыли для обхода вместо готового решения?

Да, если костыли окажутся более универсальными.
Никому не нужна программа, работающая только здесь и сейчас.
Это, кстати, одна из причин почему винда такая живучая — они тянут с собой груз совместимости за ого-го сколько лет.
Как ты думаешь сколько промилле занимала бы винда ломай они совместимость с каждой новой версией?
То-то же.

Надо кровь из носа постараться обойти эту необходимость каким-то образом.

Сказать легче, чем сделать. Иногда — сильно легче. Говоря общими словами, если какой-то интерфейс используется, то он зачем-то используется.

Если он используется для опциональных вещей, то всё хорошо: ./configure --disable-shit да #ifdef ENABLE_SHIT. А если для реализации основной функциональности — то всё плохо.

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

Мы готовы.

Что ты скажешь о программе, работающей на линуксовом ядре 3.14, но неработающей на любом другом?

Зависит от того, почему возникло такое требование. И ещё зависит от того, удовлетворит ли меня перспектива сидеть на ядре версии 3.14.

Я тут исключительно мимопроходил, но что делать, если софту нужна фича, которая есть лишь в одном ядре?

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

Не писать такой софт? Или сначала написать эту фичу во все остальные ядра?

Писать, но не навязывать его использование :)

Совместимость ради совместимости? Зачем изгаляться ради трех с половиной задротов с полумертвыми ОСями?

Сильно задуматься о нужности этой фичи.

Задумался. Пришёл к выводу, что нужна. Дальше?

Все важные фичи

Для кого важные? Для тебя — может быть. Однако готов поспорить, что ты не знаешь и десяти процентов того, что происходит в системе «под капотом», пока ты читаешь ЛОР. Отсюда можно сделать вывод, что твоё мнение о важности нерелевантно.

Совместимость ради совместимости? Зачем изгаляться ради трех с половиной задротов с полумертвыми ОСями?

1%, ага.

А о навязывании мы с тобой уже говорили: Форкнем Debian? (комментарий)

Я ждал такого комментария. Да, 1%. Дальше что?

Задумался. Пришёл к выводу, что нужна. Дальше?

ок, рассказывай тогда, почему sy***d не может без cgroups и как другие ядра принципиально не умеют решать те же задачи другими способами

Однако готов поспорить, что ты не знаешь и десяти процентов того, что происходит в системе «под капотом», пока ты читаешь ЛОР.

Можешь спорить. Всё равно ты неправ )

Я ждал такого комментария. Да, 1%. Дальше что?

Если ждал, то мог заготовить развёрнутый ответ.

Чем привязка к ядру linux хуже привязки к Open^WNet^WFreeBSD?

ок, рассказывай тогда, почему sy***d не может без cgroups и как другие ядра принципиально не умеют решать те же задачи другими способами

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

Всё равно ты неправ )

Unbalanced parentheses. Закрывающая скобка не является заменой аргументации, ну ты понял...

зачем, если есть высокоуровневое кроссплатформенное API? привязка к реализации - не комильфо.

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

Смеялись всем отделом. Так и вижу заказчика которому нужна программа которая работает потом, но зато везде, даже там где ему не нужно.

Поэтому они специфичны для каждого ядра

для всего этого тоже есть стандарты.

Вот свежий пример, почему: синхронизировать время с time.yandex.ru (комментарий)

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

Какой развернутый ответ? Предлагаешь мне доказывать очевидное или поспорить самому с собой?

завтра она перестанет работать на актуальных системах.

Сфигали?

Ядро в один момент времени загружено одно.

man гипервизор.

Да не, уже давно работает на линуксе и не чешется. Потребности в поддержке других ОС не испытывает.

они тянут с собой груз совместимости за ого-го сколько лет.

Слышал эти сказки, много раз слышал.

программа, работающая только здесь и сейчас.

Вот это точно про винду, и поэтому она «такая живучая».

высокоуровневое кроссплатформенное API

Под «библиотеками» я именно это и имел ввиду. Низкоуровневое системное API, коим и является POSIX — удел системных утилит.

Вот свежий пример, почему: синхронизировать время с time.yandex.ru (комментарий)

Но там просто использование возможностей systemd. Никто не мешает использовать ntpd вместо реализации, которая в systemd. Пока что никто не мешает :3

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

И поэтому надо писать программу подо все мыслимые ОС (иначе некросплатформенно), вовлекать новых спецов по Haiku, заводить отдел QA по Colibri OS... И все для обеспечения мизерного риска, что заказчик через 20 лет перейдет на FreeBSD. Ты в детстве менингитом не болел, не?

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

какие мы непонятливые, а ещё кто-то что-то про 10% заявлял...

Ой-ё...

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

для всего этого тоже есть стандарты.

Документация к API на стандарт как-то не тянет. Если говорить про аудио-видео, то там есть стандарты на форматы представления, но и они часто имеют разные названия в разных API

Нормальный софт не использует системное API, а использует готовые кроссплатформенные библиотеки.

Нормальный софт использует кроссплаформенное системное API, а эти Ваши библиотеки засуньте себе за ненужностью.

Ядро в один момент времени загружено одно.

Формально ты гонишь.

Чем привязка к системд хуже чем стистемд? Не знаю.

З.ы. мне уже давно все равно, работает ведь.

Что ты скажешь о программе, работающей на линуксовом ядре 3.14, но неработающей на любом другом?

А что ты скажешь о программе, работающей на lib-2.0 но не работающей на lib-1.9.9?

Когда же эти жалкие людишки поймут, что писать надо на GLib и не думать о платформе вообще?