Мы сейчас о юзерспейс уровне приложений говорим, или о драйверах?
Код, способный вызвать cernel panic на любой системе — это urgent issue в багтрекере данной системы, вне зависимости от того, какое приложение его вызвало.
MacOS не подверженна данной уязвмиости. Я только что спокойно открыл в Safari приведенную выше ссылку и спокойно закрыл Safari. Да safari страл жрать ресурсы, однако система (и другие пользователи системы) продолжили работу.
Watchdog'и используемые на многопользовательских системах быстро прибили бы такой процесс.
Имеем Windows с Safari. Заведя пользователя на специально сформированную страницу вызываем отказ системы (BSOD Windows).
Натуральная DoS.
Не должно существовать фрагметов кода, вызывающих BSoD под win или panic под линем.
Если бы непривелигированный пользователь под линуксом мог вызывать panic всей системы, миллионы школьников уже валили бы большу часть шаред хостинга не использующего виртуализацию.
По идее ни одна софтина не должна быть в состоянии вызывать аварийный останов системы. Если она способна — в системе где-то уязвимость. Серьезная. Позволяющая, фактически DOS атаку.
Представьте, что подобные «ошибки» есть в нескольких софтинах, включая системы виртуализации. А потом Вяся Пупкин тыкает по ссылочке с хабра на виртуальном десктопе в облаке Amazon вырубая все облако. Вы и тогда скажете, что это проблема Safari?
Да, и что? Я же не писал, что нужно ВСЕ указывать как зависимости на soшки?
Вообще мы разводим очередной холивар ИМХО и не сможем друг-друга убедить ну никак. Смысла продолжать думаю нет :) RPM vs DEB война идет на форумах с 90х годов и конца и края ей не видно.
Есть RHEL. В котором 14 лет в (например) mysql 4.0 бекпортят секурити патчи, при
этом версия мускуля не изменяется (ABI не изменяется), обновляется только версия пакета.
Есть бесплатный RHEL в виде Scientific Linux/CentOS.
Зачем обновлять версию софта или за что-то обязательно платить?
>> Мейнтейнер должен (постараться) гарантировать работу не при «наличии файла в системе», а при «наличии установленной в системе функциональности». А единственный способ нормально обеспечить это находится именно на уровне пакетов.
Феерический бред.
Вы вообще пакеты собирать пробовали?
При сборке бинарника линкукется конкретная версия версия (конкретный файлк). Какой — подсмотреть можно с помощью ldd. Причем тут «функциональность» — вообще не понятно никак.
>>Если изменение ABI уже предсказуемо (наш пакет работает на Python 2.5/2.6, но не работает на 2.7), то зависимость ровно так же и описывается.
Т.е. маинтейнер пакета в дебияне должен вручную проверять не сломали ли ABI зависимости? O_o?
Написал я python>=2.3. В 2.4 ABI сломали — Бага.
Написал я python = 2.4, А в 2.5 ABI не сломали, но пакет конфликтует — Бага.
И все это, из за невозможности сослаться в зависимостях на конкретную soшку.
>> Возможно, вы проецируете свойственное для редхатоидов на дебианоиды. В дебиане подобная ситуация является… ну, нонсенсом, ошибкой мейнтейнера, серьёзной проблемой.
Оба пакета могут лежать в абсолютно разных репозиторях с разными маинтейнерами которые знать не знают друг про друга.
>> Например, какой-нибудь метапакет «modern-linux-desktop» может зависеть от любого пакета «www-browser»
Это вы сейчас к чему? O_o Мета-пакеты есть и отлично живут в RHEL/CentOS.
>> Что я могу сказать… без обид, но мне абсолютно не жаль бизнесы ваших «многих знакомых». С таким «апатичным» подходом к жизни они уже обречены.
Зачем менять работающую систему? ЗАЧЕМ?
— Она написана на python 2.3.
— Она написана 10 лет назад
— Она на 100% выполняет свои задачи
Зачем менять и ломать? Ради понтов?
Попробуйте заикнуться о 3х летнем TTL автору софта для автономного телескопа или точки наблюдения за погодой, автору софта для банального терминала по приему бабла, автору софта по работе банкоматов — я посмотрю куда они вас пошлют и как на долго.
>> «зато в этом ноутбуке более энергоёмкий и менее производительный процессор!»
Ага. расскажите-ка, зачем вместо того, что-бы указать в завимостях «libxxxx.so версии yy для i386» в deb дистрибутивах указывается «пакет xxxx» или «пакет xxx версии y»?
В первом случае пакет может обновиться и сломать вам ABI, в другом обновиться и не сломать, но ваша завимиость будет требовать именно эту версию. Еще хуже, если «libxxx.so» нужной версии поставляет другой пакет, в котором не написали «provides xxxx».
А какие недостатки у «file-based», если по вашему это «более энергоемкий и менее производительный» O_O? Если, конечно, дебиянщики не знают как работет yum, то тогда вполне возможно они так и считают.
>>При выходе следующего stable-релиза сервер может обновиться до него — и заново отсчитываем три года…
Обновить? Продакшн? У меня заряжена продакшен система с софтом умеющим только python 2.3, php 4 или mysql 3.x. Или апач соответствующей версии. Что мне после обновления делать? Разыскивать по сторонним репам и заново восстанавливать завимимости?
>> Настроенный сервер может крутиться и обновляться годами без ошибок.
так и пишите, 3 года, потом обновление и перенастройка сервисов. Вообще шаги дебиян-сообщества по сокарщению срока поддержки вызывают у многих знакомых ужас и переползание в сторону убунты-сервера, у которого срок жизни значительно дольше.
Воопервых apt и rpm сравнивать очень странно. Или deb и rpm или apt и yum.
Во вторых чем более продуманы зависимости? O_o? в deb дистрах они package-based, в отлчии от file-based в rpm, что приводит к тому, что пакеты вынуждены указывать provides.
В третьих «годами» — это сильно сказано про deb, при учете, что срок жизни debian релиза всего 3 года.
Вообще судя по всему вы просто не умеете готовить RHEL.
Код, способный вызвать cernel panic на любой системе — это urgent issue в багтрекере данной системы, вне зависимости от того, какое приложение его вызвало.
Watchdog'и используемые на многопользовательских системах быстро прибили бы такой процесс.
Поведение Win отличается в корне — полный крах.
Имеем Windows с Safari. Заведя пользователя на специально сформированную страницу вызываем отказ системы (BSOD Windows).
Натуральная DoS.
Не должно существовать фрагметов кода, вызывающих BSoD под win или panic под линем.
Если бы непривелигированный пользователь под линуксом мог вызывать panic всей системы, миллионы школьников уже валили бы большу часть шаред хостинга не использующего виртуализацию.
По идее ни одна софтина не должна быть в состоянии вызывать аварийный останов системы. Если она способна — в системе где-то уязвимость. Серьезная. Позволяющая, фактически DOS атаку.
Представьте, что подобные «ошибки» есть в нескольких софтинах, включая системы виртуализации. А потом Вяся Пупкин тыкает по ссылочке с хабра на виртуальном десктопе в облаке Amazon вырубая все облако. Вы и тогда скажете, что это проблема Safari?
Пакет с дырой в RHEL 4 (версии не обновлялись с 2005 года) в студию!
>>мало ли что там майнтайнер подложил
Есть Scientific Linux — это RHEL пересобранный CERN'ом. Если уж вы им не доверяете…
Вообще мы разводим очередной холивар ИМХО и не сможем друг-друга убедить ну никак. Смысла продолжать думаю нет :) RPM vs DEB война идет на форумах с 90х годов и конца и края ей не видно.
Есть RHEL. В котором 14 лет в (например) mysql 4.0 бекпортят секурити патчи, при
этом версия мускуля не изменяется (ABI не изменяется), обновляется только версия пакета.
Есть бесплатный RHEL в виде Scientific Linux/CentOS.
Зачем обновлять версию софта или за что-то обязательно платить?
Феерический бред.
Вы вообще пакеты собирать пробовали?
При сборке бинарника линкукется конкретная версия версия (конкретный файлк). Какой — подсмотреть можно с помощью ldd. Причем тут «функциональность» — вообще не понятно никак.
Т.е. маинтейнер пакета в дебияне должен вручную проверять не сломали ли ABI зависимости? O_o?
Написал я python>=2.3. В 2.4 ABI сломали — Бага.
Написал я python = 2.4, А в 2.5 ABI не сломали, но пакет конфликтует — Бага.
И все это, из за невозможности сослаться в зависимостях на конкретную soшку.
>> Возможно, вы проецируете свойственное для редхатоидов на дебианоиды. В дебиане подобная ситуация является… ну, нонсенсом, ошибкой мейнтейнера, серьёзной проблемой.
Оба пакета могут лежать в абсолютно разных репозиторях с разными маинтейнерами которые знать не знают друг про друга.
>> Например, какой-нибудь метапакет «modern-linux-desktop» может зависеть от любого пакета «www-browser»
Это вы сейчас к чему? O_o Мета-пакеты есть и отлично живут в RHEL/CentOS.
>> Что я могу сказать… без обид, но мне абсолютно не жаль бизнесы ваших «многих знакомых». С таким «апатичным» подходом к жизни они уже обречены.
Зачем менять работающую систему? ЗАЧЕМ?
— Она написана на python 2.3.
— Она написана 10 лет назад
— Она на 100% выполняет свои задачи
Зачем менять и ломать? Ради понтов?
Попробуйте заикнуться о 3х летнем TTL автору софта для автономного телескопа или точки наблюдения за погодой, автору софта для банального терминала по приему бабла, автору софта по работе банкоматов — я посмотрю куда они вас пошлют и как на долго.
Ага. расскажите-ка, зачем вместо того, что-бы указать в завимостях «libxxxx.so версии yy для i386» в deb дистрибутивах указывается «пакет xxxx» или «пакет xxx версии y»?
В первом случае пакет может обновиться и сломать вам ABI, в другом обновиться и не сломать, но ваша завимиость будет требовать именно эту версию. Еще хуже, если «libxxx.so» нужной версии поставляет другой пакет, в котором не написали «provides xxxx».
А какие недостатки у «file-based», если по вашему это «более энергоемкий и менее производительный» O_O? Если, конечно, дебиянщики не знают как работет yum, то тогда вполне возможно они так и считают.
>>При выходе следующего stable-релиза сервер может обновиться до него — и заново отсчитываем три года…
Обновить? Продакшн? У меня заряжена продакшен система с софтом умеющим только python 2.3, php 4 или mysql 3.x. Или апач соответствующей версии. Что мне после обновления делать? Разыскивать по сторонним репам и заново восстанавливать завимимости?
>> Настроенный сервер может крутиться и обновляться годами без ошибок.
так и пишите, 3 года, потом обновление и перенастройка сервисов. Вообще шаги дебиян-сообщества по сокарщению срока поддержки вызывают у многих знакомых ужас и переползание в сторону убунты-сервера, у которого срок жизни значительно дольше.
Во вторых чем более продуманы зависимости? O_o? в deb дистрах они package-based, в отлчии от file-based в rpm, что приводит к тому, что пакеты вынуждены указывать provides.
В третьих «годами» — это сильно сказано про deb, при учете, что срок жизни debian релиза всего 3 года.
Вообще судя по всему вы просто не умеете готовить RHEL.
Последний раз сталкивался с провайдером который что-либо отрубал в 2006 году.
Закрытые трекеры следят за ratio. Кто не следит, публикует магнеты (см, например пайратбэй)
Возможно вы не в курсе о DHT, Magnet ссылках в торентах и возможности работы торент сетей вообще без трекеров?