Здравствуйте, chaotic-kotik, Вы писали:

CK>Установил свежую убунту 17.04 на свой Dell XPS 13 Skylake без всяких проблем. В 17.04, несмотря на то что это не LTS релиз, все достаточно хорошо работает

А в соседнем треде

Автор: Gattaka
Дата: 17.04.17

банальная десктопная видеокарта так и не завелась

Здравствуйте, Grizzli, Вы писали:

G>А может ты гей порно любишь? Это тоже может быть известно Майкрософт.

Спасибо. Теперь я знаю больше о противниках 10ки.

Здравствуйте, Vetal_ca, Вы писали:
V_>Не было и вот, внезапно, внедряет вредоносный код без спросу в оплаченную винду с целью рекламы (спама)
Вы заплатили деньги не за Винду, а за право ею пользоваться. Это не ваша Винда, это Винда Микрософта. Он что хочет, то и делает. А вы наслаждайтесь.

Здравствуйте, rising_edge, Вы писали:

_>Вы заплатили деньги не за Винду, а за право ею пользоваться. Это не ваша Винда, это Винда Микрософта. Он что хочет, то и делает. А вы наслаждайтесь.

Нет, это их винда

На моей подконтрольной территории весь десктоп это примерно четверть Win7, четверть допиленной (обезплиточенной) Win 8.1

Остальное Linux Mint

Рабочая инфраструктура ориентирована на уход от Windows

Основная проблема это MS Office и его полноценная замена.

Здравствуйте, vsb, Вы писали:

ARK>>Совершенно верно. Нет смысла, чтобы зависимости у разных приложений были общими. Никакие зависимости вообще не нужны. Есть программа и всё.
vsb>Смысл в том, чтобы обновления безопасности приходили на все программы сразу, а не на каждую по отдельности. На среднем компьютере, ну пусть 1000 программ, которые работают с HTTPS и в зависимостях, соответственно, тянут OpenSSL. Как ты думаешь, что будет быстрей — обновить OpenSSL в одном экземпляре, или ждать, пока авторы этих программ зачешутся, обновят свои программы (а половина уже давно умерли), мейнтейнеры это всё дело опакетят и лет через 7 может приедет тебе обновление.

1000 программ работающих через HTTPS на среднем компьютере? А ты не ошибся случае порядка на два? Потому как на среднем компьютере скорее всего вообще нет даже 1000 любых программ.

И потом что ещё за мейнтейнеры? Зачем они нужны при подобной схеме установки ПО? )

Здравствуйте, vsb, Вы писали:

ARK>>Совершенно верно. Нет смысла, чтобы зависимости у разных приложений были общими. Никакие зависимости вообще не нужны. Есть программа и всё.

vsb>Смысл в том, чтобы обновления безопасности приходили на все программы сразу, а не на каждую по отдельности. На среднем компьютере, ну пусть 1000 программ, которые работают с HTTPS и в зависимостях, соответственно, тянут OpenSSL. Как ты думаешь, что будет быстрей — обновить OpenSSL в одном экземпляре, или ждать, пока авторы этих программ зачешутся, обновят свои программы (а половина уже давно умерли), мейнтейнеры это всё дело опакетят и лет через 7 может приедет тебе обновление.

Это понятно. Но есть и другая сторона медали. Принудительное обновление какого-то компонента без ведома самой программы может запросто сломать эту программу. Обновил и думаешь — а не развалилось ли что? Еще лучше, если API слегка изменилось — в результате программа вроде работает, но иногда происходит что-то странное. И так везде — что же _точно_ работает, никто не знает. В этом весь линупс. Лично я предпочел бы подождать обновления от автора программы, если она дохлая — взять аналог, если аналога нет или нужна конкретно эта — просто плюнул бы и продолжил использовать то, что есть.

Здравствуйте, chaotic-kotik, Вы писали:

CK>Здравствуйте, Ops, Вы писали:

Ops>>А с пакетами как-то иначе? Да они поди откажутся с новой версией работать, пока их самих не обновят. Ну, или собирай все из исходников под новую либу.

CK>Если посмотреть любое приложение через objdump -p, то ты увидишь soname каждой его зависимости:

CK>

CK>Dynamic Section:
CK>  NEEDED               libXrandr.so.2
CK>  NEEDED               libX11.so.6
CK>  NEEDED               libm.so.6
CK>  NEEDED               libc.so.6
CK>

CK>При этом, если на диске будет лежать libm.so.7, будет использована эта библиотека и ничего не сломается, т.к. инкремент версии в данном случае означает, что изменения интерфейса библиотеки — обратно совместимы.

Как раз _не_ означает. Смена номера — несовместимое изменение, libm.so.7 не зацепится, если в зависимостях есть libm.so.6. Для совместимого используется один из нескольких вариантов:
— Старая версия кладётся в виде отдельного compat-пакета, который можно не ставить
— Старая версия (с меньшим номером) является переходником к новой версии
— Номер не меняется, но через symbol versioning делается, что новые приложения начинают использовать по-новому ту же версию.

Рекомендованным сейчас является именно symbol versioning — поэтому сейчас видим что-то вроде

$ ls -la /lib/x86_64-linux-gnu/libc.so.6
lrwxrwxrwx 1 root root 12 бер 21 22:06 /lib/x86_64-linux-gnu/libc.so.6 -> libc-2.23.so

несмотря на то, что от первой libc.so.6 прошло уже лет 20.

СК> Security update не имзеняет интерфейс, поэтому soname библиотеки будет таким же как и раньше (имя файла при этом может отличаться).

Обычно и имя файла не меняется.

Здравствуйте, AlexRK, Вы писали:

ARK>>>Совершенно верно. Нет смысла, чтобы зависимости у разных приложений были общими. Никакие зависимости вообще не нужны. Есть программа и всё.

vsb>>Смысл в том, чтобы обновления безопасности приходили на все программы сразу, а не на каждую по отдельности. На среднем компьютере, ну пусть 1000 программ, которые работают с HTTPS и в зависимостях, соответственно, тянут OpenSSL. Как ты думаешь, что будет быстрей — обновить OpenSSL в одном экземпляре, или ждать, пока авторы этих программ зачешутся, обновят свои программы (а половина уже давно умерли), мейнтейнеры это всё дело опакетят и лет через 7 может приедет тебе обновление.

ARK>Это понятно. Но есть и другая сторона медали. Принудительное обновление какого-то компонента без ведома самой программы может запросто сломать эту программу. Обновил и думаешь — а не развалилось ли что? Еще лучше, если API слегка изменилось — в результате программа вроде работает, но иногда происходит что-то странное.

Если это security update, то API не меняется, версия пакета остаётся той же (меняется ревизия от майнтейнера) и проблемы нет.
Если это смена API, то меняется версия библиотеки, и уже поэтому нужна переделка пакета, без неё обновление не пройдёт.
В любом случае у майнтейнера есть чёткие правила, как такие вещи можно делать, не вводя поломки, и все крупные дистрибутивы их вменяемо используют.

ARK> И так везде — что же _точно_ работает, никто не знает. В этом весь линупс.

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

Более того, винда творит то же самое, но на уровне собственных компонентов. Когда ты программу собрал 15 лет назад с использованием user32.dll, это полностью аналогично тому, как если бы ты её собрал с libuser.so.1993; но разница в том, что у тебя нет возможности проверить, что же именно там натворили (что добавили, что изменили).

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

А тут тебе аналогичное — для 99% случаев — предоставляет сборщик дистрибутива. И даже совсем сторонние программы, вроде Skype, нормально поверх этого живут — значит, поломок API нет.

Здравствуйте, netch80, Вы писали:

N>Если это security update, то API не меняется, версия пакета остаётся той же (меняется ревизия от майнтейнера) и проблемы нет.
N>Если это смена API, то меняется версия библиотеки, и уже поэтому нужна переделка пакета, без неё обновление не пройдёт.
N>В любом случае у майнтейнера есть чёткие правила, как такие вещи можно делать, не вводя поломки, и все крупные дистрибутивы их вменяемо используют.

В общем, опять "доверие майнтейнеру". С точки зрения теории надежности — дополнительная потенциальная точка отказа.

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

Угу. Поставил калькулятор — а он за собой рекурсивно притащил 10 гигов дерьма. При том, что он из этой кучи Г заюзал одну функцию TrimString.

N>Более того, винда творит то же самое, но на уровне собственных компонентов. Когда ты программу собрал 15 лет назад с использованием user32.dll, это полностью аналогично тому, как если бы ты её собрал с libuser.so.1993; но разница в том, что у тебя нет возможности проверить, что же именно там натворили (что добавили, что изменили).

Ну, до стабильности виндового API линуксу и, тем более, его прикладным пакетам — как до Китая рачком. Такое сравнение неуместно.

N>А тут тебе аналогичное — для 99% случаев — предоставляет сборщик дистрибутива. И даже совсем сторонние программы, вроде Skype, нормально поверх этого живут — значит, поломок API нет.

ИМХО, при таком раскладе риск получить проблемы все же больше, чем при "авторском" обновлении.

Здравствуйте, AlexRK, Вы писали:

N>>Если это security update, то API не меняется, версия пакета остаётся той же (меняется ревизия от майнтейнера) и проблемы нет.
N>>Если это смена API, то меняется версия библиотеки, и уже поэтому нужна переделка пакета, без неё обновление не пройдёт.
N>>В любом случае у майнтейнера есть чёткие правила, как такие вещи можно делать, не вводя поломки, и все крупные дистрибутивы их вменяемо используют.
ARK>В общем, опять "доверие майнтейнеру". С точки зрения теории надежности — дополнительная потенциальная точка отказа.

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

N>>В этом вся винда. Потому что раскопать, что собрано из чего и почему, у тебя нет возможности. В линуксах — есть.
ARK>Угу. Поставил калькулятор — а он за собой рекурсивно притащил 10 гигов дерьма. При том, что он из этой кучи Г заюзал одну функцию TrimString.

Таких "калькуляторов" на unix не встречал. На Windows — только на моей памяти было несколько, а если бы я под ней работал постоянно, то видел бы сотни.

N>>Более того, винда творит то же самое, но на уровне собственных компонентов. Когда ты программу собрал 15 лет назад с использованием user32.dll, это полностью аналогично тому, как если бы ты её собрал с libuser.so.1993; но разница в том, что у тебя нет возможности проверить, что же именно там натворили (что добавили, что изменили).
ARK>Ну, до стабильности виндового API линуксу и, тем более, его прикладным пакетам — как до Китая рачком. Такое сравнение неуместно.

Полностью уместно — представленное в libc API не меняется.

N>>А тут тебе аналогичное — для 99% случаев — предоставляет сборщик дистрибутива. И даже совсем сторонние программы, вроде Skype, нормально поверх этого живут — значит, поломок API нет.
ARK>ИМХО, при таком раскладе риск получить проблемы все же больше, чем при "авторском" обновлении.

Практика показывает обратное — "автор" скорее скажет "мне пофиг на версию 3.3, у меня нет сил/желания её лечить, даже исходников не осталось, всем срочно перейти на 5.2". Та же MS рисует это постоянно — вон уже XP даже не латается.

Здравствуйте, netch80, Вы писали:

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

Раздутый говнософт с "уровнями вложенности библиотек" не нужен.

ARK>>Угу. Поставил калькулятор — а он за собой рекурсивно притащил 10 гигов дерьма. При том, что он из этой кучи Г заюзал одну функцию TrimString.
N>Таких "калькуляторов" на unix не встречал. На Windows — только на моей памяти было несколько, а если бы я под ней работал постоянно, то видел бы сотни.

Хм. И что же это, например? Порты линупсовых утилит, тянущие за собой всякие gtk? Убого, да. Впрочем, на линуксе еще хуже — целый wine.

ARK>>Ну, до стабильности виндового API линуксу и, тем более, его прикладным пакетам — как до Китая рачком. Такое сравнение неуместно.
N>Полностью уместно — представленное в libc API не меняется.

А апи драйверов тоже не меняется?
https://www.phoronix.com/scan.php?page=news_item&px=Linux-Kernel-Stable-API-ABI

N>Практика показывает обратное — "автор" скорее скажет "мне пофиг на версию 3.3, у меня нет сил/желания её лечить, даже исходников не осталось, всем срочно перейти на 5.2". Та же MS рисует это постоянно — вон уже XP даже не латается.

Ну, лично моя практика "20 лет использования компьютера в домашних условиях" показывает, что никакие обновления библиотек на стопитцотом уровне вложенности не нужны. Иногда по мере необходимости запускаю даже проги из 90-х — всё (нужное мне) работает. Понимаю, что это все не аргумент, просто если имеешь дело с неподдерживаемым софтом — то ссзб. Все эти мейнтейнеры только "оттягивают конец" — рано или поздно (скорее рано) прилетит вовсе не security update, а API update, и брошенная автором программа превратится в говно.

Здравствуйте, alex_public, Вы писали:

vsb>>Смысл в том, чтобы обновления безопасности приходили на все программы сразу, а не на каждую по отдельности. На среднем компьютере, ну пусть 1000 программ, которые работают с HTTPS и в зависимостях, соответственно, тянут OpenSSL. Как ты думаешь, что будет быстрей — обновить OpenSSL в одном экземпляре, или ждать, пока авторы этих программ зачешутся, обновят свои программы (а половина уже давно умерли), мейнтейнеры это всё дело опакетят и лет через 7 может приедет тебе обновление.

_>1000 программ работающих через HTTPS на среднем компьютере? А ты не ошибся случае порядка на два? Потому как на среднем компьютере скорее всего вообще нет даже 1000 любых программ.

Чистый абсолютно минимальный rhel:

[root@home ~]# find / -type f -executable | wc -l
2756

Если какую-нибудь гному водрузить, будет на порядок больше.

_>И потом что ещё за мейнтейнеры? Зачем они нужны при подобной схеме установки ПО? )

А у кого я буду брать программы? У неизвестного васи? Не буду.

Здравствуйте, AlexRK, Вы писали:

vsb>>Смысл в том, чтобы обновления безопасности приходили на все программы сразу, а не на каждую по отдельности. На среднем компьютере, ну пусть 1000 программ, которые работают с HTTPS и в зависимостях, соответственно, тянут OpenSSL. Как ты думаешь, что будет быстрей — обновить OpenSSL в одном экземпляре, или ждать, пока авторы этих программ зачешутся, обновят свои программы (а половина уже давно умерли), мейнтейнеры это всё дело опакетят и лет через 7 может приедет тебе обновление.

ARK>Это понятно. Но есть и другая сторона медали. Принудительное обновление какого-то компонента без ведома самой программы может запросто сломать эту программу. Обновил и думаешь — а не развалилось ли что?

Не может. Ни одна вменяемая библиотека не будет ломать API в минорном обновлении. А невменяемыми никто не пользуется.

ARK>Еще лучше, если API слегка изменилось — в результате программа вроде работает, но иногда происходит что-то странное. И так везде — что же _точно_ работает, никто не знает. В этом весь линупс.

Никогда с таким не сталкивался и не слышал, чтобы кто-то сталкивался. В принципе тебе и на венде могут такое подсунуть, CreateFile начнёт работать как DeteleFile. В вероятность этого я поверю куда больше, чем в историю про линукс.

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

Я думаю и такие дистрибутивы есть. Но мне больше нравится традиционная модель.

Здравствуйте, AlexRK, Вы писали:

N>>Которая в разы надёжнее, чем производитель финальной софтины, которому трижды облом, что где-то на тридесятом уровне вложенности библиотек есть дыра (он, скорее всего, об этом и не узнает).
ARK>Раздутый говнософт с "уровнями вложенности библиотек" не нужен.

Отлично, значит, Windows не нужна.

ARK>>>Угу. Поставил калькулятор — а он за собой рекурсивно притащил 10 гигов дерьма. При том, что он из этой кучи Г заюзал одну функцию TrimString.
N>>Таких "калькуляторов" на unix не встречал. На Windows — только на моей памяти было несколько, а если бы я под ней работал постоянно, то видел бы сотни.
ARK>Хм. И что же это, например? Порты линупсовых утилит, тянущие за собой всякие gtk? Убого, да. Впрочем, на линуксе еще хуже — целый wine.

Нет, это были чисто виндовые разработки. Просто на всяких RAD, из которых Delphi было ещё самым приличным.

ARK>>>Ну, до стабильности виндового API линуксу и, тем более, его прикладным пакетам — как до Китая рачком. Такое сравнение неуместно.
N>>Полностью уместно — представленное в libc API не меняется.
ARK>А апи драйверов тоже не меняется?
ARK>https://www.phoronix.com/scan.php?page=news_item&px=Linux-Kernel-Stable-API-ABI

Драйвера — это внутриядерное и оно как раз меняется заметно. Для производителей ядерных драйверов дистрибутивщики держат LTS линии ядра, между которыми надо прыгать не чаще, чем раз в 2-4 года (что равно аналогичному темпу в Windows)

N>>Практика показывает обратное — "автор" скорее скажет "мне пофиг на версию 3.3, у меня нет сил/желания её лечить, даже исходников не осталось, всем срочно перейти на 5.2". Та же MS рисует это постоянно — вон уже XP даже не латается.

ARK>Ну, лично моя практика "20 лет использования компьютера в домашних условиях" показывает, что никакие обновления библиотек на стопитцотом уровне вложенности не нужны. Иногда по мере необходимости запускаю даже проги из 90-х — всё (нужное мне) работает. Понимаю, что это все не аргумент, просто если имеешь дело с неподдерживаемым софтом — то ссзб. Все эти мейнтейнеры только "оттягивают конец" — рано или поздно (скорее рано) прилетит вовсе не security update, а API update, и брошенная автором программа превратится в говно.

API update не происходит в пределах стабильной ветки дистрибутива.

Здравствуйте, netch80, Вы писали:

N>Отлично, значит, Windows не нужна.

Начиная с 8 версии — да, не нужна.

N>Нет, это были чисто виндовые разработки. Просто на всяких RAD, из которых Delphi было ещё самым приличным.

Странно. Я вот 20 лет сижу на винде и не то что сотен — даже и десятков таких не припомню. Единичные примеры видел, в основном угребищные порты с других платформ (для которых почти всегда есть лучшие нативные варианты). Наверное, это какой-то узкоспециализированный промышленный софт? Про RAD тоже как-то спорно, на том же Delphi написан Total Commander, очень компактная и быстрая утилита.

N>API update не происходит в пределах стабильной ветки дистрибутива.

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

Здравствуйте, AlexRK, Вы писали:

N>>Отлично, значит, Windows не нужна.
ARK>Начиная с 8 версии — да, не нужна.

Многие с тобой не согласятся.

N>>Нет, это были чисто виндовые разработки. Просто на всяких RAD, из которых Delphi было ещё самым приличным.

ARK>Странно. Я вот 20 лет сижу на винде и не то что сотен — даже и десятков таких не припомню. Единичные примеры видел, в основном угребищные порты с других платформ (для которых почти всегда есть лучшие нативные варианты). Наверное, это какой-то узкоспециализированный промышленный софт? Про RAD тоже как-то спорно, на том же Delphi написан Total Commander, очень компактная и быстрая утилита.

Total Commander — редкий случай, когда автор умеет писать, но всё равно использует Delphi

N>>API update не происходит в пределах стабильной ветки дистрибутива.
ARK>То есть если аффтар либы сначала поменял апи, а потом через некоторое время исправил уязвимость, то эта уязвимость будет существовать до конца стабильной ветки? (а потом насильно обновленная заброшенная программа все равно превратится в говно? )

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

Здравствуйте, Kesular, Вы писали:

K>У меня как раз сегодня апдейт час с лишним занимался онанизмом с системным диском.

Откуда такие интимные подробности? Ты им свечку держал?

Здравствуйте, Vetal_ca, Вы писали:

V_>Засаботировали Автокад и Maya, накатили creators update и скатились в низкоквалифицированный мир 3D от индусов?

Ты бы хоть вник в тему, сначала. Речь здесь идёт о W7, вообще-то.

Здравствуйте, Grizzli, Вы писали:

G>Микрософт сама это спровоцировала, выпустив на w7 w8 и прочие систему телеметрии. В итоге пользователи предпочитают вообще не ставить обновления (т.к. в каждом рефреше новые адреса для телеметрии), чем словить трояна от Микрософта.

И, кстати, ставить опасность утечки статистики о кликах по окошкам, выше опасности взлома всей системы через хорошо известные уязвимости, для которых публично доступны эксплоиты, протестуя тем самым против "троянов" от MS, называется: "назло маме отморожу уши".

Здравствуйте, Grizzli, Вы писали:

G>Смотри список того, что они собирают (Микрософт публиковал его). а дальше можно сделать выводы, какие тебе еще то пруфы нужны?

Покажи этот список. Цитатой или ссылкой, pls.