The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]



"Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +/
Сообщение от opennews (??), 23-Фев-20, 09:46 
После анализа выпущенного проектом OpenBSD исправления уязвимости в гипервизоре VMM, выявленной на прошлой неделе, обнаруживший проблему исследователь...

Подробнее: https://www.opennet.ru/opennews/art.shtml?num=52418

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по времени | RSS]


1. Скрыто модератором  +6 +/
Сообщение от Аноним (1), 23-Фев-20, 09:46 
Ответить | Правка | Наверх | Cообщить модератору

3. Скрыто модератором  –2 +/
Сообщение от A.Stahl (ok), 23-Фев-20, 10:03 
Ответить | Правка | Наверх | Cообщить модератору

39. Скрыто модератором  –6 +/
Сообщение от псевдонимус (?), 23-Фев-20, 16:17 
Ответить | Правка | Наверх | Cообщить модератору

46. Скрыто модератором  +4 +/
Сообщение от A.Stahl (ok), 23-Фев-20, 16:42 
Ответить | Правка | Наверх | Cообщить модератору

61. Скрыто модератором  +1 +/
Сообщение от псевдонимус (?), 23-Фев-20, 18:48 
Ответить | Правка | Наверх | Cообщить модератору

63. Скрыто модератором  +1 +/
Сообщение от Аноним (-), 23-Фев-20, 19:17 
Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

32. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +1 +/
Сообщение от Аноним (32), 23-Фев-20, 15:54 
> кошмар, ужас то какой, и как теперь с этим жить

Придётся кричать о своей супмер-мега неуязвимости ещё громче, повторять эту мантру чаще, и поливать окружающих фeкалиями ещё активнее, если это возможно.

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

50. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  –2 +/
Сообщение от EnemyOfDemocracy (?), 23-Фев-20, 16:53 
Ну линуксоиды же кричат, что линукс готов для десктопа.
Ответить | Правка | Наверх | Cообщить модератору

53. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +2 +/
Сообщение от отоларинголог (?), 23-Фев-20, 17:20 
откройте рот... так, закройте. Не вижу патологии, мешающей вам тоже кричать.
Ответить | Правка | Наверх | Cообщить модератору

56. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +5 +/
Сообщение от Аноним (-), 23-Фев-20, 17:47 
> откройте рот... так, закройте. Не вижу патологии, мешающей вам тоже кричать.

Не в рот нужно было глядеть, а в кошелек - главные кричатели и объявители "года линукса" делают это почему-то с макоси.

А вообще, прикольно - новость о внутренней шняге гипервизора в (опен)БСД. Набежали линухоиды и под вопли "Это не линукс? А почему не линукс? И чем линукс не лучше ваших бздей?" засра#ли все обсуждение.
ЧСХ - спросишь "зачем вы вообще приперлись в новость о бсд" - внятного ответа (т.е. не в стиле "да ты виндузятник! И вообще!") не будет.

Ответить | Правка | Наверх | Cообщить модератору

73. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +/
Сообщение от Аноним (73), 23-Фев-20, 20:30 
> лавные кричатели и объявители "года линукса" делают это почему-то с макоси.

Красивый перевод стрелок. Но нет.

Ответить | Правка | Наверх | Cообщить модератору

74. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +1 +/
Сообщение от Аноним (-), 23-Фев-20, 20:45 
>> лавные кричатели и объявители "года линукса" делают это почему-то с макоси.
> Красивый перевод стрелок.

С чего и куда, пингвиненок?

> Но нет.

Главное, усиленно мотать головой, повторяя "не-не-не-нееее-вы-вссссееее-вреееетииии!"?

https://itsfoss.com/linux-foundation-head-uses-macos/
> Linux Foundation Head Calls 2017 ‘Year of the Linux Desktop’… While Running Apple’s macOS Himself

https://developers.redhat.com/blog/tag/os-x/
> Senior Solutions Architect, Red Hat
> By Rarm Nagalingam February 12, 2020
> I have a problem. My daily laptop is a MacBook Pro, which is great unless you want to dual boot into Linux and develop on containers
>

Ответить | Правка | Наверх | Cообщить модератору

75. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +/
Сообщение от Аноним (75), 23-Фев-20, 20:57 
Эти рожи к линуксу относятся только попытками купоны стричь :). Особенно доставил синьор архитект с характерной фамилией :D
Ответить | Правка | Наверх | Cообщить модератору

87. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +/
Сообщение от Аноним (87), 23-Фев-20, 21:43 
>> Главное, усиленно мотать головой, повторяя "не-не-не-нееее-вы-вссссееее-вреееетииии!"?
> Эти рожи к линуксу относятся только попытками купоны стричь :). Особенно доставил синьор архитект с характерной фамилией :D

Ага. Что там какой-то CEO Linux Foundation начиная с
> https://training.linuxfoundation.org/training/a-beginners-gu.../

и продолжая поддержкой
containerd, CII, DPDK и прочих 100+ проектов
https://www.linuxfoundation.org/projects/directory/

и grep -iR "linux.*foundation" linux-5.5.5|wc -l                            
    1044

Что там каой-то RH, кторый уже много лет как "основной двигатель десктопного прогресса" в виде ПШШШаудио, системды и гнома?

Если Пингви-Няши опеннета, с их удивительно гибким и пластичным мировозрением - "это правильный линуксоид, этот тоже пойдет … а вот этот, этот и этот - не, не, фу-фу-фу!" сказали "не считается!", значит оно так и есть :D


Ответить | Правка | Наверх | Cообщить модератору

97. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +/
Сообщение от Аноним (97), 23-Фев-20, 23:03 
> Ага. Что там какой-то CEO Linux Foundation начиная с

Угу. Некое достаточно левое тело.

> и продолжая поддержкой containerd, CII, DPDK и прочих 100+ проектов
>  https://www.linuxfoundation.org/projects/directory/

Угу, еще давайте изучим чем президент сорсфоржа пользуется.

>     1044

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

> Что там каой-то RH, кторый уже много лет как "основной двигатель десктопного
> прогресса" в виде ПШШШаудио, системды и гнома?

ИМХО, лучшее что у шапки есть из подобного - core dev'ы графики, а вовсе не. Но они есть не только в шапке. Ну и на мое имхо, гном какая-то странная фигня. Впрочем, майкрософт вон тоже в странную фигню вдарился.

> этот - не, не, фу-фу-фу!" сказали "не считается!", значит оно так и есть :D

Ну это жирно слишком, не пойдет, попробуй потоньше.

Ответить | Правка | Наверх | Cообщить модератору

172. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  –1 +/
Сообщение от Аноним (172), 29-Фев-20, 08:46 
> новость о внутренней шняге гипервизора в (опен)БСД. Набежали линухоиды

Линукс на серверах и десктопах, а опенка держим на маршрутизатора.

Так что покричать на Тео и внедряемые им дыры в защите памяти имеем.

Ответить | Правка | К родителю #56 | Наверх | Cообщить модератору

2. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +2 +/
Сообщение от Аноним (2), 23-Фев-20, 09:54 
Ну не полность так не полностью.
Ответить | Правка | Наверх | Cообщить модератору

4. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +10 +/
Сообщение от Аноним (4), 23-Фев-20, 10:06 
Не многовато ли внимания сабжу? Все разумные люди и так знают, чего он стоит. А вот netbsd и правда молодцы, и я не помню чтобы они мерзко себя вели.
Ответить | Правка | Наверх | Cообщить модератору

7. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +1 +/
Сообщение от Аноним (7), 23-Фев-20, 10:34 
>Все разумные люди и так знают, чего он стоит.

Откуда, если сообщения об уязвимостях только сейчас пошли?

Ответить | Правка | Наверх | Cообщить модератору

10. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +1 +/
Сообщение от Аноним (4), 23-Фев-20, 11:19 
Факап с libressl был очень массивным, и последующие заявления разрабов не красили. Что-то мне подсказывает, что предпосылки были и раньше, например эти их глупые подколки в сторону гпл странно выглядят… Видимо, не зря автора попросили из проекта.
Ответить | Правка | Наверх | Cообщить модератору

11. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +/
Сообщение от Аноним (11), 23-Фев-20, 11:54 
Что за факап?
Ответить | Правка | Наверх | Cообщить модератору

16. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +/
Сообщение от Аноним (4), 23-Фев-20, 12:56 
https://www.agwa.name/blog/post/libressls_prng_is_unsafe_on_...
Ответить | Правка | Наверх | Cообщить модератору

21. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +/
Сообщение от Аноним (11), 23-Фев-20, 14:15 
И в чём факап?
Ответить | Правка | Наверх | Cообщить модератору

22. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +/
Сообщение от Аноним (4), 23-Фев-20, 14:21 
В том, что автор опенка заявил, будто у него всё норм, а линуксоиды сами виноваты и пусть сами исправляют, если им надо. Напомню, что библиотека позиционировалась как более безопасная замена openssl (и появилась на волне хайпа эпических уязвимостей openssl).
Ответить | Правка | Наверх | Cообщить модератору

27. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  –2 +/
Сообщение от пох. (?), 23-Фев-20, 15:12 
> и появилась на волне хайпа эпических уязвимостей openssl

Скопипастив в себя абсолютно все, вявленные после форка. Вот ни одна, почему-то, не найдена и не исправлена ими заранее.

Как обычно у этих людей. Не умеют они ни в code review, ни в самостоятельно писать безопасный код - как ни врали про обратное.

Ответить | Правка | Наверх | Cообщить модератору

45. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  –2 +/
Сообщение от ssh (ok), 23-Фев-20, 16:37 
> Как обычно у этих людей. Не умеют они ни в code review, ни в самостоятельно писать безопасный код - как ни врали про обратное.

По факту, тут твоего кода тоже никто не видел и ревью не получал. ;\ Так что заканчивай павлинить.

Ответить | Правка | Наверх | Cообщить модератору

93. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +/
Сообщение от Аноним (93), 23-Фев-20, 22:49 
> Вот ни одна, почему-то, не найдена и не исправлена ими заранее.

Мсье ткнуть в CVE, затрагивающие OpenSSL и не затрагивающие LibreSSL, или он сам справится и возьмёт слова назад?

Ответить | Правка | К родителю #27 | Наверх | Cообщить модератору

101. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +/
Сообщение от ssh (ok), 24-Фев-20, 02:03 
> Мсье ткнуть в CVE, затрагивающие OpenSSL и не затрагивающие LibreSSL, или он сам справится и возьмёт слова назад?

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

Ответить | Правка | Наверх | Cообщить модератору

117. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +/
Сообщение от пох. (?), 24-Фев-20, 12:21 
вы ж читать все равно не умеете, чего вам тыкать.

Там полторы проблемы, проявляющиеся при странных обстоятельствах, обычно - если на обоих концах засланные казачки. Вот проблема что инициализация prng заменена return 1  - это не проблема, это технологическое отверстие.

А в остальном пока вот так:  Port of Edlinger's Fix for CVE-2019-1563 from OpenSSL 1.1.1 (old license)
- продолжают переть все что плохо лежит. (интересно. у фиксов бывает еще и "лицензия"? )

(да, там тоже в основном высосанная из пальца проблема, но нашли и исправили ее - не они)

P.S. а из их же по[д]делки openssh надысь пришлось удалять вот такое:
-       if ((SSLeay() ^ OPENSSL_VERSION_NUMBER) & ~0xff0L)
-               fatal("OpenSSL version mismatch. Built against %lx, you "
-                   "have %lx", (u_long)OPENSSL_VERSION_NUMBER, SSLeay());
вот если это был не казачок засланный - то кто это был? С учетом return 1.

Ответить | Правка | К родителю #93 | Наверх | Cообщить модератору

57. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  –2 +/
Сообщение от Аноним (-), 23-Фев-20, 17:52 
> В том, что автор опенка заявил, будто у него всё норм, а
> линуксоиды сами виноваты и пусть сами исправляют, если им надо.

Цитируем:
> “The way it is forking is just not what any program using libssl/libcrypto
> does. The ‘danger’ only exists in that specific choice of operations, yet no > piece of software does that,”

...
> "The LibreSSL-portable releases are still being handed out as trials,
> precisely to get reports like this and then fix them," De Raadt explained.

Но да, если уж не различать между автором и основателем, то все остальное - вообще мелочи

Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

58. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  –1 +/
Сообщение от Аноним (4), 23-Фев-20, 17:56 
Так этого и нет по ссылке. Что ты там цитируешь?
Ответить | Правка | Наверх | Cообщить модератору

59. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  –1 +/
Сообщение от Аноним (-), 23-Фев-20, 18:04 
> Так этого и нет по ссылке.

Там и "автор опенка заявил, будто у него всё норм, а линуксоиды сами виноваты" тоже нет.
> Что ты там цитируешь?

Процитированные (а не взятые из выдуманного диалога в голове анонима) высказывания Тео, вестимо.
https://threatpost.com/overblown-libressl-prng-vulnerability.../
https://www.securityweek.com/openbsd-downplays-prng-vulnerab...

Ответить | Правка | Наверх | Cообщить модератору

60. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  –1 +/
Сообщение от Аноним (4), 23-Фев-20, 18:27 
Именно это он и сказал, я наблюдал ситуацию в реальном времени. С тех пор не могу воспринимать всерьёз.
Ответить | Правка | Наверх | Cообщить модератору

77. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  –1 +/
Сообщение от Аноним (75), 23-Фев-20, 21:01 
> Именно это он и сказал, я наблюдал ситуацию в реальном времени. С
> тех пор не могу воспринимать всерьёз.

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

Ответить | Правка | Наверх | Cообщить модератору

102. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +1 +/
Сообщение от ssh (ok), 24-Фев-20, 02:08 
> В этом месте они таки забили последний гвоздь в крышку своего хайпа про улучшенную безопасность

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

Ответить | Правка | Наверх | Cообщить модератору

105. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +/
Сообщение от Аноним (-), 24-Фев-20, 02:52 
> Как не посмотришь на их движ, все заняты своим делом, никакого хайпа.

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

Ответить | Правка | К родителю #102 | Наверх | Cообщить модератору

108. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +/
Сообщение от ssh (ok), 24-Фев-20, 07:59 
> Если результат их занятий делом выглядит так как тот тестовый пример -
> грош ему цена в базарный день, имхо. Потому что эта шляпа
> в результате подведет еще глупее чем оригинал, с такими то плюхами
> в и без того стремном апи.

Они в полном праве заниматься чем им вздумается. Я говорил лишь о том, что никакого хайпа там нет.

Ответить | Правка | К родителю #105 | Наверх | Cообщить модератору

131. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +/
Сообщение от пох. (?), 24-Фев-20, 15:03 
они в полном праве хоть на кожанной флейте дудеть - а мы в полном праве считать их бестолковыми др..ами, загадившими при этом поляну так, что теперь уже ничего хорошего там не вырастает.

Ответить | Правка | К родителю #108 | Наверх | Cообщить модератору

146. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +/
Сообщение от ssh (ok), 24-Фев-20, 23:10 
> они в полном праве хоть на кожанной флейте дудеть - а мы

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

Ответить | Правка | К родителю #131 | Наверх | Cообщить модератору

149. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +/
Сообщение от Аноним (-), 25-Фев-20, 12:21 
> Они в полном праве заниматься чем им вздумается. Я говорил лишь о
> том, что никакого хайпа там нет.

Ну не знаю, пиару поразвели вполне себе. И вообще, в чем пойнт кивать что секурити типа goal? Для того чтобы потом вот так? Единственное что демонстрирует этот код - у кодера наглухо не было defensive thinking. Он просто не думал, а что будет, если. А потом еще и стрелки перевел.

Ответить | Правка | К родителю #108 | Наверх | Cообщить модератору

152. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +/
Сообщение от ssh (ok), 25-Фев-20, 12:58 
> Ну не знаю, пиару поразвели вполне себе. И вообще, в чем пойнт
> кивать что секурити типа goal? Для того чтобы потом вот так?

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

Ну и опять, они поставили себе целью безопасность, ОК, разве был доклад, о том, что цель достигнута?


Ответить | Правка | К родителю #149 | Наверх | Cообщить модератору

155. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +/
Сообщение от Аноним (-), 26-Фев-20, 07:21 
> Имхо огромная разница между пиаром и хайпом.

Да ну ладно? Хайп это всего лишь особо наглый и шумный вид пиара, так что они близнецы-братья.

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

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

> Ну и опять, они поставили себе целью безопасность, ОК, разве был доклад,
> о том, что цель достигнута?

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

Ответить | Правка | К родителю #152 | Наверх | Cообщить модератору

156. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +/
Сообщение от ssh (ok), 26-Фев-20, 08:25 
> Да ну ладно?

Ну это... всякий хайп это пиар, но не наоборот. ;)

> Ну вы тоже можете рекламу пропустить. Не отменяет того факта что это реклама. А когда она еще и действительности не соответствует - это уже заведомо ложная информация. И имеет свойство в конце концов портить репутацию.
> А когда она еще и действительности не соответствует - это уже заведомо ложная информация. И имеет свойство в конце концов портить репутацию.

Повторюсь, я считаю, что внутри сообщества, они в праве декларировать что угодно. Мне не встречались банеры аля "OpenBSD ставят только Отцы! И ты, ставь и не сцы!" Поэтому наезды обещали и обманули, мимо кассы. Участник чувствующий себя обмануты покидает сообщество и примыкает к другому проекту.

> Если они поставили себе целью безопасность, как у них вообще попадает такой фееричный г0вн0код в проект?

Что поделаешь, мир не прост, а идеальный код, здесь только мистер пох. умеет.
Облажались, исправятся. У них сейчас довольно много проектов, возможно поэтому качество кода и поплыло. Подозреваю, что когда Тео говорил об перманентном аудите, OpenSMTP ещё и не было.

Ответить | Правка | К родителю #155 | Наверх | Cообщить модератору

165. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +/
Сообщение от Аноним (-), 26-Фев-20, 12:52 
> Участник чувствующий себя обмануты покидает сообщество и примыкает к другому проекту.

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

> Что поделаешь, мир не прост, а идеальный код, здесь только мистер пох. умеет.

Спору нет. И все же увиденное как-то было не про security in mind у кодера :(

> Облажались, исправятся.

К этому есть предпосылки?

> У них сейчас довольно много проектов, возможно поэтому качество
> кода и поплыло. Подозреваю, что когда Тео говорил об перманентном аудите,
> OpenSMTP ещё и не было.

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

Ответить | Правка | К родителю #156 | Наверх | Cообщить модератору

168. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +/
Сообщение от ssh (ok), 26-Фев-20, 16:47 
> Ну, во всяком случае, говоря за себя - я теперь при выборе софта дважды подумаю насколько программы от проекта openbsd реально соответствуют декларациям.

Выбор решений сейчас та еще боль, вне зависимости от OpenBSD или нет.

> К этому есть предпосылки?

А почему нет, имхо Тео довольно последователен в своих действиях. Будем надеяться.

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

Сейчас вроде уже починили. :P

Ответить | Правка | К родителю #165 | Наверх | Cообщить модератору

76. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  –1 +/
Сообщение от Аноним (75), 23-Фев-20, 20:59 
> И в чём факап?

Наверное, в том что с секурити вышло хуже чем у openssl? Для проекта рассказывающего про безопасность это, извините, падение рожей в чан с дерьмом, без вариантов. Потому что сделать хуже чем в openssl - это еще талант в написании несекурного кода иметь надо!

Ответить | Правка | К родителю #21 | Наверх | Cообщить модератору

112. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  –1 +/
Сообщение от Аноним (112), 24-Фев-20, 11:39 
Какой такой обсёр в дебиане? Пруф можно?
Ответить | Правка | Наверх | Cообщить модератору

128. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +/
Сообщение от Аноним84701 (ok), 24-Фев-20, 12:58 
> Какой такой обсёр в дебиане? Пруф можно?

https://www.schneier.com/blog/archives/2008/05/random_number...

Ответить | Правка | Наверх | Cообщить модератору

118. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +/
Сообщение от пох. (?), 24-Фев-20, 12:26 
>> И в чём факап?
> Наверное, в том что с секурити вышло хуже чем у openssl? Для

это не дыра, не дыра, не дыра! (Харя Тео, Харя, Харя!)

В openssl, кстати, бывало и вот такое:
#if defined(OPENSSL_SYS_VXWORKS)
int RAND_poll(void)
{
    return 0;
}
#endif
то есть на тех системах, где нельзя обеспечить хотя бы видимость рандома - честно об этом сообщаем вызывающему коду. Не смог обработать - пусть аварийно завершается, а не сливает инфу васянам.

Но нет, libressl на такое пойтить не могла - это ж сразу бы заметили, когда куча софта начала бы падать там, где нормально работала с openssl.

Ответить | Правка | К родителю #76 | Наверх | Cообщить модератору

92. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +2 +/
Сообщение от Тфьу (?), 23-Фев-20, 22:06 
Они выкидывали куски кода со словами - все что сложно нам не нужно, при этом не понимая и не пытаясь разобраться зачем там этот код. Результат оказался закономерен. Сам по себе баг был не столь значителен, однако же он явно показал уровень и бздунов и результата их работы. Примерно та же история что и с обсером в дебиане.
Ответить | Правка | К родителю #21 | Наверх | Cообщить модератору

94. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  –1 +/
Сообщение от Аноним (93), 23-Фев-20, 22:57 
Даже автор заметки прямо пишет:

> However, it is evidence of a design flaw not in the cryptographic library, but in the operating system. Unfortunately, Linux provides no reliable way to detect that a process has forked, and exposes entropy via a device file instead of a system call.

То есть разработчики OpenBSD/LibreSSL столкнулись с несовершенством Linux в пререлизной версии либы, исправили эту проблему к релизу, но пингвинофанатики всё равно называют это факапом. Ну так мы вам тогда столько факапов в одном только ядре найдём...

Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

96. Скрыто модератором  +4 +/
Сообщение от Тфьу (?), 23-Фев-20, 23:02 
Ответить | Правка | Наверх | Cообщить модератору

106. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  –1 +/
Сообщение от Аноним (106), 24-Фев-20, 02:59 
> То есть разработчики OpenBSD/LibreSSL столкнулись с несовершенством Linux в пререлизной
> версии либы,

В каком месте "идиотская реализация апи" с уберстремными допущениями в процессе является "несовершенством Linux"? У openssl апи и так то хромые на обе ноги, а если это еще и вот так имплементить - безопасТность начнет переть из всех щелей.

И таки
1) "Linux provides no reliable way to detect that a process has forked" звучит весьма странно.
2) Оригинал "улучшенного" кода проблемой как я понимаю не страдал.
3) Таки уже и через сискол. Но не все версии.

> столько факапов в одном только ядре найдём...

Ну, найдите.

Ответить | Правка | К родителю #94 | Наверх | Cообщить модератору

132. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +/
Сообщение от пох. (?), 24-Фев-20, 15:10 
> 2) Оригинал "улучшенного" кода проблемой как я понимаю не страдал.

в оригинале проблема была мелкой. И никому кроме белок-истерическ, скорее всего, неопасной - просто рандом был не совсем уж непредсказуемо проинициализирован, если не получилось прочитать тоже заведомо не совсем непредсказуемый /dev/urandom (то есть и изначально требования были невысокие).

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

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

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

Ответить | Правка | Наверх | Cообщить модератору

150. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +/
Сообщение от Аноним (75), 25-Фев-20, 12:37 
> в оригинале проблема была мелкой. И никому кроме белок-истерическ, скорее всего, неопасной

"Скорее всего" - тоже так себе в случае крипто. В дебиане вон пропатчили так разок. Круто было резко все рекеить или реинсталить, аж 2 раза.

> - просто рандом был не совсем уж непредсказуемо проинициализирован, если не
> получилось прочитать тоже заведомо не совсем непредсказуемый /dev/urandom (то есть и
> изначально требования были невысокие).

Тут еще вопрос как требования openssl'щиков и требования юзеров либы совпадают. Это тоже еще совсем не факт.

> заменен return 1, чтобы не палиться что с этой поделкой что-то
> работает не так как надо.

Ну, отлично, блин. И главное перевести стрелки на Linux - ну я даже не знаю. А тот кто такой код накатал, типа, security guru, чтоли? Или он в отключке это кодил? Судя по коду - таки да :\

Ответить | Правка | Наверх | Cообщить модератору

151. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +/
Сообщение от Аноним (151), 25-Фев-20, 12:41 
> До сих пор, кстати, скорее всего, неисправленный - потому что авторы о
> нем не в курсе.

О, кста, хорошо что напомнил: я тут DJB баг задолжал. Это все ж поинтереснее чем эти криптомакаки.

Ответить | Правка | К родителю #132 | Наверх | Cообщить модератору

13. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  –5 +/
Сообщение от Аноним (13), 23-Фев-20, 12:11 
Они ничего не делают вот и не могут везти себя мерзко.
Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

65. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  –2 +/
Сообщение от Аноним (65), 23-Фев-20, 19:40 
Мерзко ведут себя как раз именно они.
Да и историю про Тео и появление опенка мы все помним.
Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

68. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +5 +/
Сообщение от Аноним (-), 23-Фев-20, 20:04 
> историю про Тео

какую именно? там где он переехал в др. страну как трус дабы избежать армии? или его истерики и бабские визги со скандалами? или то как его за чсв и отвратительное поведение попросили на выход из netbsd? какую именно историю?

Ответить | Правка | Наверх | Cообщить модератору

72. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +/
Сообщение от Аноним (-), 23-Фев-20, 20:28 
> там где он переехал в др. страну как трус дабы избежать армии?

Че, не мог даже, как все приличные люди-не-лохи, дать на лапу или задействовать связи родаков? Ну тогда да, рофллол!

Ответить | Правка | Наверх | Cообщить модератору

95. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  –1 +/
Сообщение от Аноним (93), 23-Фев-20, 23:00 
Есть некоторая разница между «попросили» и «без предупреждения лишили commit bit одного из основателей». Там обе стороны были хороши.
Ответить | Правка | К родителю #68 | Наверх | Cообщить модератору

98. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  –1 +/
Сообщение от Аноним (97), 23-Фев-20, 23:10 
> Есть некоторая разница между «попросили» и «без предупреждения лишили
> commit bit одного из основателей». Там обе стороны были хороши.

А потом пришел Торвальдс и сделал commit bit obsolete :)

Ответить | Правка | Наверх | Cообщить модератору

5. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  –3 +/
Сообщение от б.б. (?), 23-Фев-20, 10:09 
> Уязвимость выявил Максим Виллард (Maxime Villard), автор применяемых в NetBSD

происки конкурентов :)

типа "у вас ошибка там, там и там. ищите!" :)

Ответить | Правка | Наверх | Cообщить модератору

31. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +5 +/
Сообщение от Аноним (32), 23-Фев-20, 15:51 
Видимо, Макс рассчитывал, что имеет дело с профессиональными программистами, которые увидят суть проблемы без резжёвывания.
Ответить | Правка | Наверх | Cообщить модератору

66. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +/
Сообщение от Аноним (65), 23-Фев-20, 19:42 
Видимо, кто-то не понимает, что публичные багрепорты так не делаются.
Ответить | Правка | Наверх | Cообщить модератору

69. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +2 +/
Сообщение от Аноним (-), 23-Фев-20, 20:07 
> Видимо, кто-то не понимает, что публичные багрепорты так не делаются.

Багрепорт как багрепорт. Просто кодеры из опенки по сравнению с Максом детвора детворой. Зато визгу от openbsd и хайпа на весь мир. Хотя последние несколько месяцев какая-то контора показала, что баги в нутрях опёнка довольно примитивные. NetBSD и то будет защищённее (даже согласно статам на cvedetails).

Ответить | Правка | Наверх | Cообщить модератору

78. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +/
Сообщение от Аноним (-), 23-Фев-20, 21:03 
> последние несколько месяцев какая-то контора показала, что баги в нутрях опёнка
> довольно примитивные. NetBSD и то будет защищённее (даже согласно статам на cvedetails).

У более приличных проектов их, видите ли, instrumentation отлавливает нынче. Но навернуть тесты и fuzzing канительнее чем песенки про всяких лохов сочинять.

Ответить | Правка | Наверх | Cообщить модератору

71. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +9 +/
Сообщение от Аноним (-), 23-Фев-20, 20:23 
Просто тут видно невооруженным глазом разницу в уровне профессионализма между Maxime Villard'ом (из NetBSD) и детворой из OpenBSD.

In vmm_update_pvclock():


6868    pvclock_gpa = vcpu->vc_pvclock_system_gpa & 0xFFFFFFFFFFFFFFF0;  <-- controlled by the guest
6869    if (!pmap_extract(vm->vm_map->pmap, pvclock_gpa, &pvclock_hpa))
6870        return (EINVAL);
6871    pvclock_ti = (void*) PMAP_DIRECT_MAP(pvclock_hpa);
6872
6873    /* START next cycle (must be odd) */
6874    pvclock_ti->ti_version =
6875        (++vcpu->vc_pvclock_version << 1) | 0x1;

Three things are wrong:

  1) The RO protections are not enforced, so the guest could have data be
     written to a GPA it can only access as RO.

  2) If 'pvclock_ti' crosses a page, its second half could point to an HPA
     that doesn't belong to the guest. The guest can therefore, to some
     limited extent, overwrite host kernel memory.

  3) The pmap is not locked, so if the GPA gets unmapped and its
     corresponding HPA recycled, there is a small window where the (new)
     content of the HPA can get overwritten.

There is, in fact, a fourth case. Watch closely. On AMD CPUs the NPTs are
a regular pmap. The higher half of the GPA space is therefore mapped to
host kernel memory as KVA. Given that there is no check on PG_u here, the
guest can just put a host KVA in pvclock_gpa, and have its content be
overwritten. This gives write-where ability for the guest.

The OpenBSD kernel does not perform full ASLR, in that the PTE space and
direct map are at static addresses (contrary to eg NetBSD where everything
is randomized). These addresses are known. The guest can therefore use the
static address of the direct map for example to write at whatever HPA by
issuing the following instruction:

    wrmsr(KVM_MSR_SYSTEM_TIME, PMAP_DIRECT_MAP(hpa) | 1);

This means the guest can overwrite whatever host kernel memory, and can
control *where* to write. I have tested this, and it works.

The guest can also choose *what* to write, because it just so happens that
'vc_pvclock_version' is the number of VMEXITs that occurred with pvclock
enabled, and the guest can reliably craft this value. So this is not just
a write-where, this is a full guest-to-host write-what-where.

Had there been proper ASLR, it still could have been somewhat bypassable,
because VMD does a pass-through of RDMSR on AMD CPUs (??), which can leak
HPAs such as HSAVE_PA.

(Speaking about direct map, notice how an alignment bug in locore0.S
causes the first 2MB of .text to be writable on Intel CPUs. So there is a
static address that maps the kernel .text as writable.)

There are additional assorted bugs and vulns that could be used to some
degree:

  - On AMD CPUs the CPL check on XSETBV VMEXITs must be performed by
    software. VMD forgot to do that, so from guest-userland, we can control
    the XCR0 that guest-kernel will use.

  - This XSETBV issue actually has an additional ramification. Right now
    OpenBSD doesn't check that the guest XCR0 is a subset of the host XCR0,
    which means that the guest can use more FPU states than the host allows.
    It looks like this check was lost when fixing another bug I reported one
    year ago which could cause guest-to-host DoS.

  - The TLB handling of guest pages is broken, in that the INVEPT
    instructions in the host could be issued on the wrong CPUs. This means
    that if UVM decides to swap out a guest page, the guest could still
    access it via stale TLB entries. On AMD CPUs, there is no TLB handling
    at all (??).

  - vmx_load_pdptes is broken.

In order to make this whole thing less of a security joke, I would suggest
the following:

  - Fix TLB handling, sanitize the GPAs, lock the pages correctly.
  - Don't pass-through RDMSR.
  - Fix the XSETBV issues.
  - Provide *real* ASLR: randomize the PTE space and the direct map.
  - Fix the alignment bug in the direct map to not map the text as writable.

Maxime Villard

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


>[оверквотинг удален]
> Module name:    src
> Changes by:    mortimer@cvs.openbsd.org    2020/02/15 15:59:55
>
> Modified files:
>     sys/arch/amd64/amd64: vmm.c
>
> Log message:
> Add bounds check on addresses passed from guests in pvclock.
>
> Fixes an issue where a guest can write to host memory by passing bogus addresses.

I'm a bit confused here. It is not because the GPAs are contiguous that the
HPAs are too. If the structure crosses a page, the guest still can write to
host memory.

Вот тебе и ку-ка-ре-ку самая безопасная в мире ОС OpenBSD ку-ка-ре-ку. Добавить тут особенно нечего... Ах, да, Макс уже тонко троллирует ребят из OpenBSD, используя фразы а-ля


In order to make this whole thing less of a security joke

Ответить | Правка | К родителю #66 | Наверх | Cообщить модератору

89. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +/
Сообщение от Аноним (89), 23-Фев-20, 21:45 
Как "так" не делаются?

Вот репорт:
https://marc.info/?l=openbsd-tech&m=158176939604512&w=2

Я даже не знаю, как тут подробнее разжевать. Начать с алфавита английского языка, что ли?

Ответить | Правка | К родителю #66 | Наверх | Cообщить модератору

120. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +/
Сообщение от пох. (?), 24-Фев-20, 12:33 
> Видимо, кто-то не понимает, что публичные багрепорты так не делаются.

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

Желательно не ранее чем через пятнадцать лет после того как уговоришь этот патч принять.

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


Ответить | Правка | К родителю #66 | Наверх | Cообщить модератору

6. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +1 +/
Сообщение от анонимчик (?), 23-Фев-20, 10:23 
Чтото многовато дыр в самой безопасной bsd... А я еще хотел ее зающатт после void.
А чтож там во всяких фряхах происходит?
Ответить | Правка | Наверх | Cообщить модератору

8. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  –2 +/
Сообщение от б.б. (?), 23-Фев-20, 10:48 
vmm заюзать? по-моему, медленный он какой-то
Ответить | Правка | Наверх | Cообщить модератору

80. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +1 +/
Сообщение от Аноним (-), 23-Фев-20, 21:09 
> vmm заюзать? по-моему, медленный он какой-то

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

Ответить | Правка | Наверх | Cообщить модератору

12. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  –3 +/
Сообщение от Аноним (12), 23-Фев-20, 11:59 
Фряха в этом вопросо обходится без помощи разрабов из NetBSD. Подпишитесь на их рассылку - будете получать уведомления о выявленных уязвимостях и просто ошибках, если вам интересно.
Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

121. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +/
Сообщение от пох. (?), 24-Фев-20, 12:37 
> Фряха в этом вопросо обходится без помощи разрабов из NetBSD.

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

> Подпишитесь на их рассылку - будете получать уведомления о выявленных уязвимостях

а как получать уведомления о невыявленных?

> и просто ошибках, если вам интересно.

нет.

Ответить | Правка | Наверх | Cообщить модератору

14. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +/
Сообщение от Аноним (13), 23-Фев-20, 12:15 
Если верить графикуhttps://upload.wikimedia.org/wikipedia/commons/thumb/7/75/Bs...
то дрегонфлай бзд самая безопасная. По тому как самая не нужная.
Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

17. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +/
Сообщение от Аноним (4), 23-Фев-20, 13:01 
Вообще, стрекоза няшная. Если сможешь побороть ежеминутные паники (в дефолтном конфиге), у тебя будет шанс попробовать себя в патчении дров и софта. Самая интересная наверное. Правда фс страшновато доверять ценные данные.
Ответить | Правка | Наверх | Cообщить модератору

153. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +/
Сообщение от Аноним (-), 25-Фев-20, 16:12 
> Правда фс страшновато доверять ценные данные.

А он что, так плох?

Ответить | Правка | Наверх | Cообщить модератору

154. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +/
Сообщение от Аноним (4), 25-Фев-20, 16:19 
Пару месяцев назад завезли fsck, в hammer2. Но если посыпется, ты её не исправишь никак. В теории сыпаться не должна, конечно. Ну, вот такое, btrfs же как-то пользовались. Главное, не забывать про бэкапы.
Ответить | Правка | Наверх | Cообщить модератору

157. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +/
Сообщение от Аноним (-), 26-Фев-20, 10:40 
> Пару месяцев назад завезли fsck, в hammer2. Но если посыпется, ты её
> не исправишь никак. В теории сыпаться не должна, конечно. Ну, вот
> такое, btrfs же как-то пользовались. Главное, не забывать про бэкапы.

В btrfs оно по задумке осыпаться не должно. Метаданные если девайсов более 1 в RAID1, иначе DUP (2 копии на 1 девайсе). И данные и метаданные как CoW пишется, старое не уничтожается и если вдруг не прокатило, неудачный хвост можно просто отбросить, получив более старое, но валидное состояние.

Так что угрохать его до вида когда fsck потребуется не так просто. Для фоновой проверки смонтированной ФС пускается scrub. Ну и по факту fsck нужен ... когда-то, в каких-то экзотичны случаях :). А эта штука как, выдерживает какие-нибудь издевательства уже? Btrfs на сейчас более-менее переживает всякие извращенские случаи и стремные железки.

Ответить | Правка | Наверх | Cообщить модератору

18. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  –6 +/
Сообщение от лютый жабби (?), 23-Фев-20, 13:03 
"А я еще хотел ее зающатт после void."

Смешно. БЗДы на годы отстают от линуксов и разрыв увеличивается.
Поставь CENTOS, включи и настрой selinux и расслабься.

Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

19. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +12 +/
Сообщение от анонн (ok), 23-Фев-20, 13:37 
> и разрыв увеличивается.

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

Ответить | Правка | Наверх | Cообщить модератору

23. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  –7 +/
Сообщение от Аноним (23), 23-Фев-20, 14:40 
Докера нету. ТензорФлова тоже нету. Кубернетеса тоже нету. IntelliJ IDEA Ultimate Edition тоже нету. Android Studio тоже нету. Людям, перешедшим с линукса на bsd, добавляется новая перманентная головная боль "а есть ли это в бзд? а портировали ли?"

У бзд перед линуксом я вижу только одно гигантское преимущество: capitalism-friendly-лицензия без бессмысленных 1980-хиппи-лозунгов и кучи ограничений (id est несвобод).

Ответить | Правка | Наверх | Cообщить модератору

24. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +1 +/
Сообщение от anonymous (??), 23-Фев-20, 15:00 
А не потому ли BSD отстаёт, что в Linux с лицензиями как-то покошернее? В частности, лицензия в Linux частично заставляет участников делиться друг с другом результатами труда.
Ответить | Правка | Наверх | Cообщить модератору

28. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +1 +/
Сообщение от Аноним (23), 23-Фев-20, 15:13 
> в Linux с лицензиями как-то покошернее?

Docker: ASL 2.0
TensorFlow: ASL 2.0
Kubernetes: ASL 2.0
IntelliJ IDEA Ultimate Edition: проприетарная, открытая часть на ASL 2.0
Android Studio: ASL 2.0

Где здесь Ж-П-Эль? Ж-П-Эльнутый софт типа coreutils легко можно заменить бзд-альтернативами. Ну а киллер-софт, которого в бзд нет, не имеет к Ж-П-Эль никакого отношения.

Ответить | Правка | Наверх | Cообщить модератору

82. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +/
Сообщение от Аноним (82), 23-Фев-20, 21:18 
> Где здесь Ж-П-Эль? Ж-П-Эльнутый софт типа coreutils легко можно заменить бзд-альтернативами.
> Ну а киллер-софт, которого в бзд нет, не имеет к Ж-П-Эль никакого отношения.

Так это ж образцовая корпоративщина, вот дежурное корпоративное жлобство и запплаилось :)

Ответить | Правка | Наверх | Cообщить модератору

113. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +/
Сообщение от anonymous (??), 24-Фев-20, 11:41 
> Где здесь Ж-П-Эль?

А где здесь Linux? Docker -- это лишь frontend к Linux namespaces/cgroups/прочее. Аналогично Kubernetes. Linux -- это всё-таки то, поверх чего работает это ПО, а не само это ПО.

Ответить | Правка | К родителю #28 | Наверх | Cообщить модератору

29. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +/
Сообщение от Аноним (7), 23-Фев-20, 15:16 
Нет, не поэтому. Кому нужно не делиться - либо просто проигнорят линукс и вложатся в BSD, либо насрут на лицензии, ибо судебный процесс против них разорит кого угодно из мелких GPL-копирастов (крупные копирасты прежде чем против них судиться тоже 100 раз подумают).
Ответить | Правка | К родителю #24 | Наверх | Cообщить модератору

114. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +/
Сообщение от anonymous (??), 24-Фев-20, 11:44 
> просто проигнорят линукс и вложатся в BSD

Вот они потратили свои человекочасы в BSD, сделали закрытую систему. Вот ещё кто-то вложил человекочасы в BSD и сделал закрытую систему. И ещё кто-то. И так 100500 раз. И все жертвуют в upstream минимум, потому что могут распространять в закрытой форме (а значит надо лишить конкурентов приемущества и не жертвовать в upstream).

А если проиграть тоже самое в GPL, то можно заметить, что компании вынуждены обмениваться результатами. И выгоднее всего это делать через upstream (чтобы самому не сопровождать свои огромные patchset-ы).

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

Ну, а ссылки можно? Я вот помню разные судебные процессы. Как выясняется нередко суд объясняет компаниям, что авторское право нужно уважать.

Ответить | Правка | Наверх | Cообщить модератору

44. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +3 +/
Сообщение от Аноним (-), 23-Фев-20, 16:36 
> А не потому ли BSD отстаёт, что в Linux с лицензиями как-то
> покошернее? В частности, лицензия в Linux частично заставляет участников делиться друг с другом результатами труда.

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

Ответить | Правка | К родителю #24 | Наверх | Cообщить модератору

81. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +/
Сообщение от Аноним (82), 23-Фев-20, 21:16 
> Китайцев - блобиками для загрузки или забиванием на причуды белых человеков,

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

> Теслу - обещанием (6 лет как) совсем скоро поделиться, гугла, амазону, клаудфлар
> и прочих облачносервеников - похвалой за активное подмахивание?

А теперь запустим греп по репе линуха на предмет этих "жадин". Так, что такое? Патчи шлют?! :)

Ответить | Правка | Наверх | Cообщить модератору

90. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +1 +/
Сообщение от Аноним (90), 23-Фев-20, 21:54 
>> Китайцев - блобиками для загрузки или забиванием на причуды белых человеков,
> Да ну ладно, даже какой-нить allwinner вываливает сорцы. Правда там такие сорцы, что годятся только подивиться на то какие вещества китайские разработчики используют, но все же.

И че там с квалкомом и прочей блоботней? Срочным порядком уже открылись? Или опять "не очень то и хотелось"?

>> Теслу - обещанием (6 лет как) совсем скоро поделиться, гугла, амазону, клаудфлар и прочих облачносервеников - похвалой за активное подмахивание?
> А теперь запустим греп по репе линуха на предмет этих "жадин". Так, что такое? Патчи шлют?! :)

Это как с ext2/3 патчами от гугла (Которые вроде как есть. В гугле. А всем остальным - ну … оказывается лицензия позовляет зажать) - т.е. сугубо добровольное открытие кода?

А теперь, для полноты понимания, прочитаем уже наконец GPLv2. И заглянем в FAQ, раздел "вебсервисы". И расскажем на опеннете поподробнее, чем именно GPLv2 для клаудфлари, амазона и (сервисной части) гугла отличается от BSD!

Ответить | Правка | Наверх | Cообщить модератору

99. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +/
Сообщение от Аноним (-), 23-Фев-20, 23:17 
> И че там с квалкомом и прочей блоботней? Срочным порядком уже открылись?

В смысле? Квалком прям в майнлайн потоки крапа и льет дофига времени подряд. Другое дело что это не касается мутных прошивок сотовых модемов и прочего барахла, да и сам дизайн SoC там такой что там linux это так, до кучи, GUI к квалковскому модему, который ежели захочет то может и запустит мордочку на лине, а ежели не захочет - то и не запустит. Ну вот такая вот стебная у них архитектурка :)

> Или опять "не очень то и хотелось"?

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

> Это как с ext2/3 патчами от гугла (Которые вроде как есть.

Интересно, это пох в гриме или вы там однояйцевые близнецы? :)

> ну … оказывается лицензия позовляет зажать)
> - т.е. сугубо добровольное открытие кода?

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

> А теперь, для полноты понимания, прочитаем уже наконец GPLv2. И заглянем в
> FAQ, раздел "вебсервисы". И расскажем на опеннете поподробнее, чем именно GPLv2
> для клаудфлари, амазона и (сервисной части) гугла отличается от BSD!

Вот конкретно в этом случае может особо и ничем. Но распостранять все это уже ой.

Ответить | Правка | Наверх | Cообщить модератору

26. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +2 +/
Сообщение от Аноним (7), 23-Фев-20, 15:11 
>Докера нету. Кубернетеса тоже нету. IntelliJ IDEA Ultimate Edition тоже нету. Android Studio тоже нету.

То, что этого г***а нет - это достоинства, а не недостатки.

>ТензорФлова тоже нету.

TensorFlow не поддерживает ничего, кроме проприетарной вендор-залоченной куды. Есть фреймворки на OpenCL. Для них внезапно нужен работающий OpenCL. На который даже у линукс-сообщества нет ресурсов. Один плюс - меса - юзерспейсная либа, которая может меняться независимо для каждой программы, разрабатывать её можно без перезапуска драйвера и иксов. Надеюсь что у меня когда-нибудь дойдут руки запилить атомики для радеона, чтобы hashcat работал.

Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

33. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  –3 +/
Сообщение от Аноним (32), 23-Фев-20, 15:55 
> То, что этого г***а нет - это достоинства, а не недостатки.

То есть невозможность использования в >70% серверных use case — это достоинство?

Ответить | Правка | Наверх | Cообщить модератору

40. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +/
Сообщение от Аноним (-), 23-Фев-20, 16:19 
>> То, что этого г***а нет - это достоинства, а не недостатки.
> То есть невозможность использования в >70% серверных use case — это достоинство?

https://docs.saltstack.com/en/latest/ref/modules/all/salt.mo...
но вы там держитесь


Ответить | Правка | Наверх | Cообщить модератору

41. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +/
Сообщение от Анонимemail (41), 23-Фев-20, 16:21 
Зачем тебе андроид студио и идея на сервере?
Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

47. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +1 +/
Сообщение от Анонимemail (41), 23-Фев-20, 16:46 
Какие 70% сервер кэйс ты о чем? На сервера ideшки не ставят. 70% сервер кэйсов это шлюзы, фаирволы, почта, терминалы, впны. Описанные тобой вещи - это смузихлебная инфраструктура для сайтов в лэндинг стиле на js. Шарфик небось фиолетовый носишь? Борода чёткая? Залитая коооффффееем в барбершопке?
Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

64. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  –2 +/
Сообщение от Аноним (64), 23-Фев-20, 19:30 
Re:Для них внезапно нужен работающий OpenCL. На который даже у линукс-сообщества нет ресурсов

ubuntu@host:~$ uname -a
Linux ubuntu 5.5.5-050505-lowlatency #202002191432 SMP PREEMPT Wed Feb 19 19:47:19 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

ubuntu@host:~$ clinfo
Number of platforms:                 1
  Platform Profile:                 FULL_PROFILE
  Platform Version:                 OpenCL 2.1 AMD-APP (3052.0)
  Platform Name:                 AMD Accelerated Parallel Processing
  Platform Vendor:                 Advanced Micro Devices, Inc.
  Platform Extensions:                 cl_khr_icd cl_amd_event_callback cl_amd_offline_devices


  Platform Name:                 AMD Accelerated Parallel Processing
Number of devices:                 1
  Device Type:                     CL_DEVICE_TYPE_GPU
  Vendor ID:                     1002h
  Board name:                     Vega 10 XT [Radeon RX Vega 64]
  Device Topology:                 PCI[ B#9, D#0, F#0 ]
  Max compute units:                 56
  Max work items dimensions:             3
    Max work items[0]:                 1024
    Max work items[1]:                 1024
    Max work items[2]:                 1024
  Max work group size:                 256
  Preferred vector width char:             4
  Preferred vector width short:             2
  Preferred vector width int:             1
  Preferred vector width long:             1
  Preferred vector width float:             1
  Preferred vector width double:         1
  Native vector width char:             4
  Native vector width short:             2
  Native vector width int:             1
  Native vector width long:             1
  Native vector width float:             1
  Native vector width double:             1
  Max clock frequency:                 1301Mhz
  Address bits:                     64
  Max memory allocation:             7287183769
  Image support:                 Yes
  Max number of images read arguments:         128
  Max number of images write arguments:         8
  Max image 2D width:                 16384
  Max image 2D height:                 16384
  Max image 3D width:                 2048
  Max image 3D height:                 2048
  Max image 3D depth:                 2048
  Max samplers within kernel:             26751
  Max size of kernel argument:             1024
  Alignment (bits) of base address:         1024
  Minimum alignment (bytes) for any datatype:     128
  Single precision floating point capability
    Denorms:                     Yes
    Quiet NaNs:                     Yes
    Round to nearest even:             Yes
    Round to zero:                 Yes
    Round to +ve and infinity:             Yes
    IEEE754-2008 fused multiply-add:         Yes
  Cache type:                     Read/Write
  Cache line size:                 64
  Cache size:                     16384
  Global memory size:                 8573157376
  Constant buffer size:                 7287183769
  Max number of constant args:             8
  Local memory type:                 Scratchpad
  Local memory size:                 65536
  Max pipe arguments:                 16
  Max pipe active reservations:             16
  Max pipe packet size:                 2992216473
  Max global variable size:             7287183769
  Max global variable preferred total size:     8573157376
  Max read/write image args:             64
  Max on device events:                 1024
  Queue on device max size:             8388608
  Max on device queues:                 1
  Queue on device preferred size:         262144
  SVM capabilities:                
    Coarse grain buffer:             Yes
    Fine grain buffer:                 Yes
    Fine grain system:                 No
    Atomics:                     No
  Preferred platform atomic alignment:         0
  Preferred global atomic alignment:         0
  Preferred local atomic alignment:         0
  Kernel Preferred work group size multiple:     64
  Error correction support:             0
  Unified memory for Host and Device:         0
  Profiling timer resolution:             1
  Device endianess:                 Little
  Available:                     Yes
  Compiler available:                 Yes
  Execution capabilities:                
    Execute OpenCL kernels:             Yes
    Execute native function:             No
  Queue on Host properties:                
    Out-of-Order:                 No
    Profiling :                     Yes
  Queue on Device properties:                
    Out-of-Order:                 Yes
    Profiling :                     Yes
  Platform ID:                     0x7fcfc4305d50
  Name:                         gfx900
  Vendor:                     Advanced Micro Devices, Inc.
  Device OpenCL C version:             OpenCL C 2.0
  Driver version:                 3052.0 (HSA1.1,LC)
  Profile:                     FULL_PROFILE
  Version:                     OpenCL 2.0
  Extensions:                     cl_khr_fp64 cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_int64_base_atomics cl_khr_int64_extended_atomics cl_khr_3d_image_writes cl_khr_byte_addressable_store cl_khr_fp16 cl_khr_gl_sharing cl_amd_device_attribute_query cl_amd_media_ops cl_amd_media_ops2 cl_khr_image2d_from_buffer cl_khr_subgroups cl_khr_depth_images cl_amd_copy_buffer_p2p cl_amd_assembly_program

Более того, Linux еще и HPC могет:

ubuntu@host:~$ rocminfo
ROCk module is loaded
ubuntu is member of video group
=====================    
HSA System Attributes    
=====================    
Runtime Version:         1.1
System Timestamp Freq.:  1000.000000MHz
Sig. Max Wait Duration:  18446744073709551615 (0xFFFFFFFFFFFFFFFF) (timestamp count)
Machine Model:           LARGE                              
System Endianness:       LITTLE                            

==========              
HSA Agents              
==========              
*******                  
Agent 1                  
*******                  
  Name:                    AMD Ryzen 7 2700 Eight-Core Processor
  Marketing Name:          AMD Ryzen 7 2700 Eight-Core Processor
  Vendor Name:             CPU                                
  Feature:                 None specified                    
  Profile:                 FULL_PROFILE                      
  Float Round Mode:        NEAR                              
  Max Queue Number:        0(0x0)                            
  Queue Min Size:          0(0x0)                            
  Queue Max Size:          0(0x0)                            
  Queue Type:              MULTI                              
  Node:                    0                                  
  Device Type:             CPU                                
  Cache Info:              
    L1:                      32768(0x8000) KB                  
  Chip ID:                 0(0x0)                            
  Cacheline Size:          64(0x40)                          
  Max Clock Freq. (MHz):   3200                              
  BDFID:                   0                                  
  Internal Node ID:        0                                  
  Compute Unit:            16                                
  SIMDs per CU:            0                                  
  Shader Engines:          0                                  
  Shader Arrs. per Eng.:   0                                  
  WatchPts on Addr. Ranges:1                                  
  Features:                None
  Pool Info:              
    Pool 1                  
      Segment:                 GLOBAL; FLAGS: KERNARG, FINE GRAINED
      Size:                    49319512(0x2f08e58) KB            
      Allocatable:             TRUE                              
      Alloc Granule:           4KB                                
      Alloc Alignment:         4KB                                
      Acessible by all:        TRUE                              
    Pool 2                  
      Segment:                 GLOBAL; FLAGS: COARSE GRAINED      
      Size:                    49319512(0x2f08e58) KB            
      Allocatable:             TRUE                              
      Alloc Granule:           4KB                                
      Alloc Alignment:         4KB                                
      Acessible by all:        TRUE                              
  ISA Info:                
    N/A                      
*******                  
Agent 2                  
*******                  
  Name:                    gfx900                            
  Marketing Name:          Vega 10 XT [Radeon RX Vega 64]    
  Vendor Name:             AMD                                
  Feature:                 KERNEL_DISPATCH                    
  Profile:                 BASE_PROFILE                      
  Float Round Mode:        NEAR                              
  Max Queue Number:        128(0x80)                          
  Queue Min Size:          4096(0x1000)                      
  Queue Max Size:          131072(0x20000)                    
  Queue Type:              MULTI                              
  Node:                    1                                  
  Device Type:             GPU                                
  Cache Info:              
    L1:                      16(0x10) KB                        
  Chip ID:                 26751(0x687f)                      
  Cacheline Size:          64(0x40)                          
  Max Clock Freq. (MHz):   1301                              
  BDFID:                   2304                              
  Internal Node ID:        1                                  
  Compute Unit:            56                                
  SIMDs per CU:            4                                  
  Shader Engines:          4                                  
  Shader Arrs. per Eng.:   1                                  
  WatchPts on Addr. Ranges:4                                  
  Features:                KERNEL_DISPATCH
  Fast F16 Operation:      FALSE                              
  Wavefront Size:          64(0x40)                          
  Workgroup Max Size:      1024(0x400)                        
  Workgroup Max Size per Dimension:
    x                        1024(0x400)                        
    y                        1024(0x400)                        
    z                        1024(0x400)                        
  Max Waves Per CU:        40(0x28)                          
  Max Work-item Per CU:    2560(0xa00)                        
  Grid Max Size:           4294967295(0xffffffff)            
  Grid Max Size per Dimension:
    x                        4294967295(0xffffffff)            
    y                        4294967295(0xffffffff)            
    z                        4294967295(0xffffffff)            
  Max fbarriers/Workgrp:   32                                
  Pool Info:              
    Pool 1                  
      Segment:                 GLOBAL; FLAGS: COARSE GRAINED      
      Size:                    8372224(0x7fc000) KB              
      Allocatable:             TRUE                              
      Alloc Granule:           4KB                                
      Alloc Alignment:         4KB                                
      Acessible by all:        FALSE                              
    Pool 2                  
      Segment:                 GROUP                              
      Size:                    64(0x40) KB                        
      Allocatable:             FALSE                              
      Alloc Granule:           0KB                                
      Alloc Alignment:         0KB                                
      Acessible by all:        FALSE                              
  ISA Info:                
    ISA 1                    
      Name:                    amdgcn-amd-amdhsa--gfx900          
      Machine Models:          HSA_MACHINE_MODEL_LARGE            
      Profiles:                HSA_PROFILE_BASE                  
      Default Rounding Mode:   NEAR                              
      Default Rounding Mode:   NEAR                              
      Fast f16:                TRUE                              
      Workgroup Max Size:      1024(0x400)                        
      Workgroup Max Size per Dimension:
        x                        1024(0x400)                        
        y                        1024(0x400)                        
        z                        1024(0x400)                        
      Grid Max Size:           4294967295(0xffffffff)            
      Grid Max Size per Dimension:
        x                        4294967295(0xffffffff)            
        y                        4294967295(0xffffffff)            
        z                        4294967295(0xffffffff)            
      FBarrier Max Size:       32                                
*** Done ***            
...

Пилить вам шура свою бздю еще лет 100 пока она догонит сегодняшний Linux

Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

70. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +1 +/
Сообщение от Аноним (-), 23-Фев-20, 20:20 
> Re:Для них внезапно нужен работающий OpenCL. На который даже у линукс-сообщества нет ресурсов
> Более того, Linux еще и HPC могет:
> неформатированная толком портянка на 10 страниц
> Пилить вам шура свою бздю еще лет 100 пока она догонит сегодняшний Linux

Пукать линуксоидам и пукать еще лет 100 в каждой бсдшной новости:
http://www.peregrine.hpc.uwm.edu/ganglia/
https://uwm.edu/hpc/specifications-3/
> Jobs are scheduled using the SLURM resource manager
> All nodes run the FreeBSD operating system

https://www.freshports.org/sysutils/condor/


Ответить | Правка | Наверх | Cообщить модератору

107. Скрыто модератором  –1 +/
Сообщение от Аноним (64), 24-Фев-20, 07:40 
Ответить | Правка | Наверх | Cообщить модератору

125. Скрыто модератором  +/
Сообщение от Аноним (-), 24-Фев-20, 12:54 
Ответить | Правка | Наверх | Cообщить модератору

115. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  –1 +/
Сообщение от anonymous (??), 24-Фев-20, 11:50 
А если в top500 заглянуть? Или в Российский (как там его, не помню:) top100/top50? Или в green500? Да вообще в любой рейтинг суперкомпьютеров?
Ответить | Правка | К родителю #70 | Наверх | Cообщить модератору

122. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +/
Сообщение от пох. (?), 24-Фев-20, 12:41 
> А если в top500 заглянуть? Или в Российский (как там его, не
> помню:) top100/top50? Или в green500? Да вообще в любой рейтинг суперкомпьютеров?

и о чем это говорит, кроме того что схватили что a) было ближе b) потому что пофиг, на самом деле, что хватать, от линуха используется кусок загрузчика и полтора драйвера ?

А сэр Крэй, увы, мертв.

Ответить | Правка | Наверх | Cообщить модератору

137. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +/
Сообщение от anonymous (??), 24-Фев-20, 16:13 
Там очень грызутся за FLOPSы на тестах. Если бы *BSD давал больше на тестах, то выбрали бы его. Но выбрали Linux.
Ответить | Правка | Наверх | Cообщить модератору

143. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +/
Сообщение от пох. (?), 24-Фев-20, 19:10 
и какое отношение они имеют - к загрузчику этих тестов? Именно - никакого.
Поэтому используют то, что ближе лежало и к чему много дешевых админов.

А в этой вашей беэсде gcc нет - как тесты собирать, я вас спрашиваю?

Ответить | Правка | Наверх | Cообщить модератору

148. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +/
Сообщение от anonymous (??), 25-Фев-20, 11:25 
> и какое отношение они имеют - к загрузчику этих тестов?

Я, конечно, не знаю как вы делали свои кластеры, но когда запускали кластеры, там было важно вообще всё: диспатчер syscall-ов, полноценная поддержка mellanox-овых IB-карт, lustrefs/orangefs/..., работа планировщиков, управление памятью, управление питанием, управление прерываниями и многое-многое другое вплоть до всяких мелочей, вроде IPC namespaces и inotify (что уже требовалось для сопровождения, а не для скорости).

И ядро пересобиралось тонну раз в попытках получить наибольшую производительность.

> А в этой вашей беэсде gcc нет - как тесты собирать, я вас спрашиваю?

Это шутка?

Ответить | Правка | Наверх | Cообщить модератору

158. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +/
Сообщение от Аноним (-), 26-Фев-20, 10:53 
> Поэтому используют то, что ближе лежало и к чему много дешевых админов.

Что лучше работает по сумме факторов, то и используют.

> А в этой вашей беэсде gcc нет - как тесты собирать, я вас спрашиваю?

Бздюки со шлангом вообще забавные ребята. Сперва вопили что компилить быстрее. Но в HPC всем нас рать сколько это компилится, там важнее сколько считается. И естественно эта выходка очков симпатий бздям не прибавила. Как и тормозизм с gcc 4.2. Вот зачем кому-то апстрим который может факапнуть по линии ключевого тулса?

Ответить | Правка | К родителю #143 | Наверх | Cообщить модератору

166. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +/
Сообщение от анонн (ok), 26-Фев-20, 13:39 
>> А в этой вашей беэсде gcc нет - как тесты собирать, я вас спрашиваю?
> Бздюки со шлангом вообще забавные ребята. Сперва вопили что компилить быстрее.
> Но в HPC всем нас рать сколько это компилится, там важнее сколько
> считается. И естественно эта выходка очков симпатий бздям не прибавила. Как
> и тормозизм с gcc 4.2. Вот зачем кому-то апстрим который может факапнуть по линии ключевого тулса?

Наверное затем же, зачем кому-то очередное Очень Ценное Мнение очередного анонима, факапающего (зато с умным и уверенным видом и Чуйством Cобственной Важности) по линии ключевых пунктов обсуждаемого предмета?


$ pkg rquery -x %n_%v-%R "^gcc.*"
gcc_9_4-FreeBSD
gcc-arm-embedded_8.2.20181220_1-FreeBSD
gcc-ecj_4.5-FreeBSD
gcc10-devel_10.0.1.s20200216-FreeBSD
gcc48_4.8.5_11-FreeBSD
gcc6_6.5.0_3-FreeBSD
gcc6-aux_20180516_1,1-FreeBSD
gcc7_7.5.0-FreeBSD
gcc8_8.3.0_3-FreeBSD
gcc8-devel_8.3.1.s20200214-FreeBSD
gcc9_9.2.0_1-FreeBSD
gcc9-devel_9.2.1.s20200215-FreeBSD
gccmakedep_1.0.3-FreeBSD


$ pkg search gcc
aarch64-gcc-6.4.0_8            Cross GNU Compiler Collection for aarch64
aarch64-gcc6-6.5.0             Cross GNU Compiler Collection for aarch64
aarch64-xtoolchain-gcc-0.4_1   Pre seeded toolchain to cross build FreeBSD base
...
i386-gcc-6.4.0_8               Cross GNU Compiler Collection for i386
i386-gcc6-6.5.0                Cross GNU Compiler Collection for i386
...
mingw32-gcc-4.8.1_4,1          FSF gcc-4 for Windows cross-development
mips-gcc-6.4.0_8               Cross GNU Compiler Collection for mips
mips-gcc6-6.5.0                Cross GNU Compiler Collection for mips
..
powerpc-gcc9-9.2.0             Cross GNU Compiler Collection for powerpc
powerpc64-gcc-6.4.0_8          Cross GNU Compiler Collection for powerpc64
powerpc64-gcc6-6.5.0           Cross GNU Compiler Collection for powerpc64
...
riscv64-gcc-8.3.0              Cross GNU Compiler Collection for riscv64
riscv64-gcc9-9.2.0             Cross GNU Compiler Collection for riscv64
...
riscv64-xtoolchain-gcc-0.4_1   Pre seeded toolchain to cross build FreeBSD base
sparc64-gcc-6.4.0_8            Cross GNU Compiler Collection for sparc64
sparc64-gcc6-6.5.0             Cross GNU Compiler Collection for sparc64


Ответить | Правка | Наверх | Cообщить модератору

170. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +/
Сообщение от пох. (?), 26-Фев-20, 18:01 
а там не надо лучше - там надо "как-то загрузиться".

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

c clang все хорошо - он-то нормально работает. И не имеет троянца, запрещающего написать лучший оптимизатор. Но макака наберет же ж g++, и обломится, цоманд нот фоунд, как в этой вашей фребеэсде без компилятора живут?

> Как и тормозизм с gcc 4.2.

кому не нравился - ставил любой другой - 4.2 был нужен для сборки самой системы, и это подстава, извини, ни разу не от bsd, а от твоих любимцев, изменивших лицензию и добавивших троянские .so - вот ведь, действительно, чем надо заниматься, не компилятор же улучшать. А то ж кто-нибудь действительно мог написать оптимизатор, с pgcc/egcs такое уже было, приходилось потом с жалобным хныканьем "интегрировать" то, что и сами ниасиливали десять лет, и другим мешали делать.

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

С мурзилиным кодом мы это уже проходили.

Ответить | Правка | Наверх | Cообщить модератору

126. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +/
Сообщение от Аноним (-), 24-Фев-20, 12:54 
> А если в top500 заглянуть? Или в Российский (как там его, не
> помню:) top100/top50? Или в green500? Да вообще в любой рейтинг суперкомпьютеров?

То использование в вышеприведенном кластере сразу резко станет неправдой?


Ответить | Правка | К родителю #115 | Наверх | Cообщить модератору

135. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +/
Сообщение от anonymous (??), 24-Фев-20, 16:10 
Нет, просто подчеркнёт идентичность этого случая.
Ответить | Правка | Наверх | Cообщить модератору

136. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +/
Сообщение от anonymous (??), 24-Фев-20, 16:11 
s/идентичность/единичность/ (автозамена)
Ответить | Правка | Наверх | Cообщить модератору

30. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +4 +/
Сообщение от Аноним (30), 23-Фев-20, 15:40 
>Докера нету. ТензорФлова тоже нету. Кубернетеса тоже нету. IntelliJ IDEA Ultimate Edition тоже нету. Android Studio тоже нету

Зачем это надо людям, не являющимися быдлокодерами?

Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

34. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  –2 +/
Сообщение от Аноним (32), 23-Фев-20, 15:58 
Микросервисная архитектура — это возрождение принципа unix way, когда каждая программа делает одно дело, и делает хорошо.

Ну и автомасштабирование и автоматическое распределение ресурсов, конечно, не актуально для сервиса с полутора пользователями, но вот когда речь идёт о более-менее серъёзных нагрузках — must have.

Ответить | Правка | Наверх | Cообщить модератору

48. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +2 +/
Сообщение от Анонимemail (41), 23-Фев-20, 16:47 
Видел, как такие, как вы, пихают ping в 200мб образ джокера. Ну о че. Микросервис.
Ответить | Правка | Наверх | Cообщить модератору

138. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +/
Сообщение от anonymous (??), 24-Фев-20, 16:14 
А что мешало им сделать на порядки меньше? Может ручки? Микросервисность тут не при чём.
Ответить | Правка | Наверх | Cообщить модератору

86. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +/
Сообщение от Аноним (-), 23-Фев-20, 21:43 
> Микросервисная архитектура — это возрождение принципа unix way,

Но только если делается людьми, а не вебмакаками. Так иногда бывает, но довольно редко: вебмакаки дешевле и массовее. Проблема в том что принцип "как заплачено, так и зафигачено" не отменяли.

Ответить | Правка | К родителю #34 | Наверх | Cообщить модератору

133. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +1 +/
Сообщение от пох. (?), 24-Фев-20, 15:16 
люди не будут оборачивать микросервис эмулятором операционной системы.
Они запустят его как обычный процесс в существующей.

Поэтому "так" - не бывает. А вебмакаки выбирают доскер, потому что ничему больше не научились.

> принцип "как заплачено, так и зафигачено" не отменяли.

как будто макакам так мало платят...

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

Ответить | Правка | Наверх | Cообщить модератору

159. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +/
Сообщение от Аноним (-), 26-Фев-20, 10:58 
> люди не будут оборачивать микросервис эмулятором операционной системы.
> Они запустят его как обычный процесс в существующей.

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

> Поэтому "так" - не бывает. А вебмакаки выбирают доскер, потому что ничему
> больше не научились.

Вебмакаки на то и вебмакаки. Гугл вон даже постебался в go и логотип яп нарисовал нормальный, сразу видно кто целевая аудитория :)

>> принцип "как заплачено, так и зафигачено" не отменяли.
> как будто макакам так мало платят...

Смотря с чем сравнивать. Вон на биржах индусы готовы кодить за $5 в час, если не меньше. Вроде бы не дофига, чтоли. Нет, конечно бывает и тема лебедев, но на 1 такого - пара сотен макак уровня индусов.

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

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

Ответить | Правка | Наверх | Cообщить модератору

171. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +/
Сообщение от пох. (?), 26-Фев-20, 18:10 
> Смотря какие у них были цели. Изначально так логичнее, но могут быть
> дополнительные соображения типа миграции с железки на железку и проч.

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

> Вебмакаки на то и вебмакаки. Гугл вон даже постебался в go и
> логотип яп нарисовал нормальный, сразу видно кто целевая аудитория :)

так они и в документации открытым текстом писали, кто она.
Типа, хорошие разработчики хотели многовато жрат, поэтому их заставили написать то, что позволит их поувольнять и нанять дешевых, по $5.

> Смотря с чем сравнивать. Вон на биржах индусы готовы кодить за $5
> в час, если не меньше. Вроде бы не дофига, чтоли. Нет,

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

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

> Ну дык. Экзекьюторы нынче довольно редкий вид. Ну так получилось, увы.

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

Ответить | Правка | Наверх | Cообщить модератору

173. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +/
Сообщение от Аноним (173), 02-Мрт-20, 16:44 
> и чем тут доскер сам по себе поможет? Правильно, ничем. Виртуализация - это не про него.

Ну как, если софт вместе со всем потребным барахлом переезжает - он таки взлетит на другой железке, независимо от того что там за ос и в каком состоянии. Это конечно форменное go'пничество, но так делают и это имеет свой пойнт. А доскер - лишь 1 из вариантов как это делать. Даже у поцтеринга есть своя запускалка контейнеров, наконец.

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

У них этих и так толпа, пихон "не тормозит", вот и устали докупать сервера. Пришлось go сделать. А логотип - макаку, наверное постеснялись :)

> я бы нанял, на соточку, но что-то мне подсказывает, что lizardfs они
> мне до приемлемого состояния не починят.

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

> да вон в ШриЛанке палача-то пять лет не могли найти,

Эх, бида-бида. А можно туда вебмакак все же отправить? А то вдруг все ж найдут? :)

Ответить | Правка | Наверх | Cообщить модератору

175. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +/
Сообщение от пох. (?), 02-Мрт-20, 17:06 
> Ну как, если софт вместе со всем потребным барахлом переезжает

то это не про докер.

> Даже у поцтеринга есть своя запускалка контейнеров, наконец.

есть, но там тоже никто никуда не переезжает, все уже приехали.

Вот виртуалки со всеми доскерами внутри, целиком - у меня отлично переезжают, причем - автоматически. У мэйлcpy, кстати, не переезжают -
===
2020-02-26 в 19:36:18 нам пришлось корректно остановить Вашу ВМ и перенести ее на другой гипервизор, т.к. на исходном гипервизоре возникла проблема. В 19:44:30 ВМ была запущена.
===
- видимо, это потому, что у меня-то немодная-немолодежная vmware, а у них стильный-современный kvm с ceph и другим модным тормозным и ненадежным фуфлом.
Но докер тут совершенно не нужен.

>> да вон в ШриЛанке палача-то пять лет не могли найти,
> Эх, бида-бида. А можно туда вебмакак все же отправить?

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

Ответить | Правка | Наверх | Cообщить модератору

124. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +2 +/
Сообщение от пох. (?), 24-Фев-20, 12:51 
> Микросервисная архитектура — это возрождение принципа unix way, когда каждая программа
> делает одно дело, и делает хорошо.

одно и хорошо - делает jail. Обеспечивает изоляцию программы, и больше ничего.
А ваша псевдомикросервисная архитектура, внезапно, делает миллион и плохо.  И s stands for security, ага.

И банальная docker registry - казалось бы, продукт от самих виликих разработчиков самого доскера - не умеет корректно завершать работу, потому что вопреки этими же разработчиками написанному (и тут же мгновенно забытому) правилу, там не одна программа, а зоопарк, с наколенным планировщиком. Как и в 99% менее показательных образцов. unixway тут и не пахнет. Обычное неосиляторство разработчиков сделать софт, просто работающий в стандартной операционной системе, требующее "контейнер" чтобы донести всю мусорку до прода не рассыпав. Пакетный менеджер это ведь так сложно, особенно при "разработке" на модных язычках, тянущих гигабайты в хомяк.

> Ну и автомасштабирование и автоматическое распределение ресурсов, конечно, не актуально

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

> для сервиса с полутора пользователями, но вот когда речь идёт о
> более-менее серъёзных нагрузках — must have.

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

Ответить | Правка | К родителю #34 | Наверх | Cообщить модератору

160. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  –1 +/
Сообщение от Аноним (-), 26-Фев-20, 11:07 
> одно и хорошо - делает jail. Обеспечивает изоляцию программы, и больше ничего.

Угу, сколько-сколько там назад отдельную конфигурацию сети то смогли? И таки насколько полная абстракция? А то если уж изолировать программу - наверное, нечего ей в основной сети хоста шарахаться, равно как и видеть то что ее не касается.

> А ваша псевдомикросервисная архитектура, внезапно, делает миллион и плохо.  И s
> stands for security, ага.

По сравнению с убермонстрами где цать мегов php (жаб, хомяков, гадюк, рубей) навалены одной кучей и спасибо если там нет откровенных eval/remote include/system() с юзеровскими данными - может даже и ничего, кстати. Конечно, вебманки что ни дай они в г-но превратят, общий уровень квалификации способствует. Вон мозилла сказочный 0day прям на JS забабахать смогла. Повопив про безопасный ЯП, безопасный просмотрщик PDF, blah-blah-blah.

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

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

Ответить | Правка | Наверх | Cообщить модератору

169. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +/
Сообщение от пох. (?), 26-Фев-20, 17:47 
> Угу, сколько-сколько там назад отдельную конфигурацию сети то смогли?

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

Но "прогресс", к сожалению, не остановить. Вменяемые уходят, а набигающие продолжают набигать.

> По сравнению с убермонстрами где цать мегов php (жаб, хомяков, гадюк, рубей) навалены одной
> кучей и спасибо если там нет откровенных eval/remote include/system() с юзеровскими данными -
> может даже и ничего, кстати.

И в чем разница если они все навалены в доскере той же кучей и еще кривым планировщиком что-то регулярно исполняют?
И кто обещал что нет eval какого-нибудь мусора - б-жественная благодать доскера от него гарантирует?

> Первое что в таком случае надо оптимизировать - уволить архитекта к дьяволу.

да, жалкий неудачник - вот если бы проектировал докера в докере в докере - вот тогда было бы чудо, ресурсов оно бы вообще не требовало (косит в сторону кластера соседнего отдела - в принципе, оно так и есть - с тридцать хостов, расход памяти сотня гигабайт, зато cpu - 0. Вот это норм архитекторы, ящетаю. Жаль что CPU 0 означает, что никакой пользы компании этот прожорливый монстр не приносит. Память и место на дисках, к сожалению, нажрал уже на пяток миллионов ржублей. Оно тоже не используется, естественно, при cpu=0, но сожрано. Затобесплатно!)

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

Ответить | Правка | Наверх | Cообщить модератору

174. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  –1 +/
Сообщение от Аноним (-), 02-Мрт-20, 16:54 
> Это как раз феерический бред и кривой код впридачу. Совершенно не
> нужен - если, конечно, не докер в докере в докере запускать.

Вот лично мне например совершенно не надо чтобы "изолированная" программа шарахалась по остальной системе. Нафиг мне такая "изоляция" вообще? Я так чрутом мог дохрена лет назад, с известно какой секурити. И если изоляция не имеет ничего внятного предложить, она такая идет лесом.

> И в чем разница если они все навалены в доскере той же
> кучей и еще кривым планировщиком что-то регулярно исполняют?

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

> И кто обещал что нет eval какого-нибудь мусора - б-жественная благодать доскера
> от него гарантирует?

Нет, но это несколько уменьшает последствия. Во всяком случае вот так сразу мусор все же не умыкнет еще и почту, подломив какой-нибудь форум или вику.

> оно так и есть - с тридцать хостов, расход памяти сотня
> гигабайт, зато cpu - 0.

Ну, вот видишь, вместо рака стала грыжа :)

> на пяток миллионов ржублей. Оно тоже не используется, естественно, при cpu=0,
> но сожрано. Затобесплатно!)

Ну лоханулись, что поделать, можно было поставить самый минимальный проц, видимо.

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

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

Ответить | Правка | Наверх | Cообщить модератору

176. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +/
Сообщение от пох. (?), 02-Мрт-20, 17:24 
> Вот лично мне например совершенно не надо чтобы "изолированная" программа шарахалась по остальной
> системе. Нафиг мне такая "изоляция" вообще?

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

> Я так чрутом мог дохрена лет назад, с известно какой секурити.

от б-жественного доскера та сесурити взлетает сразу же до небес, ну да, конечно. А не появляется, наоборот, стопиццот векторов атаки, которые ты и проанализировать-то ниасилил. Попробуй-ка вылези из chroot "пооверрайдив кусок запускающего процесса", как недавно проделали с доскером.

> И если изоляция не имеет ничего внятного предложить, она такая идет лесом.

а, ну тут я согласен - доскер в качестве изоляции - идет лесом.
Он даже той, что chroot позволял, нормальной предложить не может.

s stands for security

Ответить | Правка | Наверх | Cообщить модератору

177. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +/
Сообщение от Аноним (-), 02-Мрт-20, 18:32 
>> Это как раз феерический бред и кривой код впридачу. Совершенно не
>> нужен - если, конечно, не докер в докере в докере запускать.
> Вот лично мне например совершенно не надо чтобы "изолированная" программа шарахалась по остальной системе. Нафиг мне такая "изоляция" вообще? Я так чрутом мог
> дохрена лет назад, с известно какой секурити. И если изоляция не
> имеет ничего внятного предложить, она такая идет лесом.

Очередное Очень Ценное Мнение. Еще бы в предмете обсуждения разбирался - совсем бы хорошо было.
То что прилепили недавно (всего 11 лет назад) - VNET, это витруализации сетевога стека на уровне ядра. А привязывать к отдельному loopback с отдельной подсетью, опуская проброс с хоста на подсеть и обратно - никто не запрещал.

Ответить | Правка | К родителю #174 | Наверх | Cообщить модератору

35. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +3 +/
Сообщение от анонн (ok), 23-Фев-20, 16:00 
> Докера нету. ТензорФлова тоже нету. Кубернетеса тоже нету. IntelliJ IDEA Ultimate Edition

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

Ну и
$ pkg rquery %n-%v docker intellij-ultimate py37-tensorflow
docker-18.09.5_1 (Клиент, естественно)
intellij-ultimate-2019.3
py37-tensorflow-1.14.0_5

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

поправил, не благодарите

Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

37. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  –6 +/
Сообщение от Аноним (32), 23-Фев-20, 16:03 
> "на годы отстают от линуксов", потому что "тут идет перечисление сугубо линуксяных технологий, щедро сдобренное смузи".

Не позорьтесь, пожалуйста. Называть докер и кубу "смузи-технологиями" — признак человека, далёкого от системного администрирования.
k8s или openshift (в зависимости от задач) — основа практически любой крупной серверной инфраструктуры.

Ответить | Правка | Наверх | Cообщить модератору

38. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +/
Сообщение от анонн (ok), 23-Фев-20, 16:05 
>> "на годы отстают от линуксов", потому что "тут идет перечисление сугубо линуксяных технологий, щедро сдобренное смузи".
> Не позорьтесь, пожалуйста. Называть докер и кубу "смузи-технологиями" — признак человека, далёкого от системного администрирования.

А записать докер не в сугубо (и жестко завязаное на) линуксячьи технологии (и проигнорировать следующее в скобках "а закинуть тот же дебиан в VM и рулить докерами и кубернетсами оттуда - не позволяет религия") - признак какого человека? Зелененького и толстенького?

> системного администрирования.

И как знают все, кроме этого (и 1С бухгалтерии) больше ничего серьезного с капутерами делать нельзя …

Ответить | Правка | Наверх | Cообщить модератору

127. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +/
Сообщение от пох. (?), 24-Фев-20, 12:57 
> А записать докер не в сугубо (и жестко завязаное на) линуксячьи технологии

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

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

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

> (и проигнорировать следующее в скобках "а закинуть тот же дебиан в
> VM и рулить докерами и кубернетсами оттуда - не позволяет религия")

эффективность решения не позволяет. Особенно если и так уже система работает внутри какой-нибудь виртуализации.

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

Ответить | Правка | Наверх | Cообщить модератору

43. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +2 +/
Сообщение от Анонимemail (41), 23-Фев-20, 16:31 
Систомно администрирую. Нужен esxi, pfsense (это на базе фряхи), routerOS, win server, ad, терпинальный сервер, 1с,exim, dovecot, ms sql, MySQL, postgresql, bacula, zabbix, apache, rsybc, syslogd. Ваши кубернетесы нужны далеко не всем.
Ответить | Правка | К родителю #37 | Наверх | Cообщить модератору

67. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +3 +/
Сообщение от xm (ok), 23-Фев-20, 20:00 
> Ваши кубернетесы нужны далеко не всем.

Да, по правде сказать, вообще мало кому. Просто модно вот и носятся с ними как с писанной торбой.
Впрочем, волна уже пошла на откат.

Ответить | Правка | Наверх | Cообщить модератору

129. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  –2 +/
Сообщение от пох. (?), 24-Фев-20, 12:59 
>> Ваши кубернетесы нужны далеко не всем.
> Да, по правде сказать, вообще мало кому.

но модный современный софт в другом виде скоро просто запускаться не будет.

> Впрочем, волна уже пошла на откат.

хорошо у вас в параллельной вселенной

впрочем, неумение разработчиков не только в пакетные менеджеры, но и в stateless архитектуры еще некоторое время будет нас спасать.

Ответить | Правка | Наверх | Cообщить модератору

85. Скрыто модератором  +/
Сообщение от Аноним (-), 23-Фев-20, 21:31 
Ответить | Правка | К родителю #43 | Наверх | Cообщить модератору

20. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  –1 +/
Сообщение от анонимчик (?), 23-Фев-20, 13:43 
> "А я еще хотел ее зающатт после void."
> Смешно. БЗДы на годы отстают от линуксов и разрыв увеличивается.
> Поставь CENTOS, включи и настрой selinux и расслабься.

когда-то bsd было прогрессивнее linux. симметричная многодачаность, джайлы, когда еще докера в проекте не было. что сейчас вдруг bsd стало отсталым? вроде проблемы обычно были только с GUI

Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

25. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +/
Сообщение от anonymous (??), 23-Фев-20, 15:00 
> когда еще докера в проекте не было

Зато OpenVZ был (хоть и отставал сильно по ядрам).

Ответить | Правка | Наверх | Cообщить модератору

62. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +1 +/
Сообщение от псевдонимус (?), 23-Фев-20, 18:57 
>> когда еще докера в проекте не было
> Зато OpenVZ был (хоть и отставал сильно по ядрам).

Линуксоиды благополучно закопали эту нормальную контейнеризацию с нормальной изоляцией. Так им и надо.


Ответить | Правка | Наверх | Cообщить модератору

84. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  –2 +/
Сообщение от Аноним (82), 23-Фев-20, 21:26 
> Линуксоиды благополучно закопали эту нормальную контейнеризацию с нормальной изоляцией.
> Так им и надо.

Да они сами себя закопали, с своими кривыми кастомными ядрами они такие никому не уперлись. По мере пришествия virtio стало проще нормальный виртуализатор взять там где крепкая изоляция нужна, и менее долбанутые контейнеры там где столько не надо. А ниша ovz внезапно превратилась в null pointer.

Ответить | Правка | Наверх | Cообщить модератору

134. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +1 +/
Сообщение от пох. (?), 24-Фев-20, 15:21 
наоборот - тем что сдуру вернули в апстрим большую часть разработки, которую и используют теперь "нормальные виртуализаторы". А сами остались с тем кодом, который апстрим бы не взял, поскольку он был сложным и не позволял "порежьте поменьше, в экран не влазит, и каждый заверните в салфеточку", и не сумели угнаться за stable api is nonsense.

Ответить | Правка | Наверх | Cообщить модератору

161. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  –1 +/
Сообщение от Аноним (-), 26-Фев-20, 11:18 
> наоборот - тем что сдуру вернули в апстрим большую часть разработки, которую
> и используют теперь "нормальные виртуализаторы".

Что это за фигня? Вот лично моя претензия, по которой я это никогда не буду эксплуатировать - нужда сношаться с какими-то левыми ядрами. Где секуритификсы абы как, по версиям безумно лагают, и все это у них было, в общем то, всегда. По поводу чего прожЭкт являл собой nightmare администрации и майнтенанса. Пока full virt был тяжелым и тормозным и конкурентов толком не было, этот кактус койкак грызли. Но постепенно пришел virtio, виртуализаторы конкретно полегчали и разогнались, и камасутра с глючными кривыми впсками где админов надо просить модуль вгрузить и с секурити вечно полный швах (у блэкхэтов есть сплойты на ovz) всех таки достала. Ну и произошло вот такое разделение.

И таки именно сервисам в контейнерах не надо то что имел предложить ovz, это надо хостерам и ко, а те вместе с клиентами таки заманались.

> А сами остались с тем кодом, который апстрим бы не взял, поскольку он был сложным и не
> позволял "порежьте поменьше, в экран не влазит, и каждый заверните в
> салфеточку", и не сумели угнаться за stable api is nonsense.

Там дело даже не в коде. А в том что если вы делаете админам и клиентам неудобно, от вас при первой же подвернувшейся возможности таки избавятся, при первом намеке на альтернативные пути решения проблем. И эра ovz закончилась просто потому что он уже как таковой не предлагает более дешевые хостинги, зато предлагает дохрена технических проблем на ровном месте. Ну и кому это вот так надо? Поклонникам Мазоха? Их немного.

Ответить | Правка | Наверх | Cообщить модератору

164. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +1 +/
Сообщение от пох. (?), 26-Фев-20, 11:53 
> Вот лично моя претензия

это либо тараканы некормленные, либо fud.

Ядро от великого непогрешимого - ничуть не менее левое. А даже и более, поскольку им же и ясно сказано - "стабильное - в твоем дистрибутиве". Никаким суперсекьюрити там и тем более не пахнет - одно пофиксят, другое испортят.
Версия - так тебе на цифирки др-ть или работать? Мне совершенно похрен, какие там цифирки, оно либо делает то что мне надо, либо нет. Лет на пять той openvz вполне хватило. Дальше начались проблемы с железом и с модными технологиями, поддерживаемыми только модными ведрами.

> Но постепенно пришел virtio

ничего что в нем те самые патчи openvz?

> И таки именно сервисам в контейнерах не надо то что имел предложить ovz

конечно не надо - ни fine-grained управления ресурсами им не надо, которого до ovz просто не было, любая программа могла в одиночку выжрать либо всю пропускную способность диска, либо всю вычислительную мощность всех ядер, до которых ей дали дотянуться, даже полноценный idle priority был левым патчем с некоторыми ограничениями, ни изоляции им не надо, вообще ничего им не надо, контейнеры, как известно - это чтоб помойку из хомяка девелопера до прода или васянского десктопа донести кое-как, не рассыпав половину на пол.

А дешевые быстрые массхостинги нынче модно поднимать на вмвари. Деньги на лицензию брать, понятно, в тумбочке, там их откуда-то взялось много.  Или, в Роиссе, к примеру, на hyper-v. Чтоб никому не платить. Зато можно самому грузить модули! Правда, зачем их самому грузить, большинство васянов не очень понимают, но очень этому рады.

Ответить | Правка | Наверх | Cообщить модератору

140. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +/
Сообщение от псевдонимус (?), 24-Фев-20, 17:25 
>> Линуксоиды благополучно закопали эту нормальную контейнеризацию с нормальной изоляцией.
>> Так им и надо.
> Да они сами себя закопали, с своими кривыми кастомными ядрами они такие
> никому не уперлись. По мере пришествия virtio стало проще нормальный виртуализатор
> взять там где крепкая изоляция нужна, и менее долбанутые контейнеры там
> где столько не надо. А ниша ovz внезапно превратилась в null
> pointer.

Не от шапки -- значит кривое. Все с тобой ясно.

Ответить | Правка | К родителю #84 | Наверх | Cообщить модератору

144. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +/
Сообщение от пох. (?), 24-Фев-20, 19:13 
не от шапки - значит, stable api is nonsense и будет поломано через час после того как разработчик снова починит. Поэтому да, кривое - в смысле, работать не будет.

А почему - какая, в общем-то, разница?

Ответить | Правка | Наверх | Cообщить модератору

162. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +/
Сообщение от Аноним (162), 26-Фев-20, 11:33 
> Не от шапки -- значит кривое. Все с тобой ясно.

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

Ответить | Правка | К родителю #140 | Наверх | Cообщить модератору

36. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  –3 +/
Сообщение от Аноним (32), 23-Фев-20, 16:00 
> когда-то bsd было прогрессивнее linux. симметричная многодачаность, джайлы, когда еще докера в проекте не было. что сейчас вдруг bsd стало отсталым?

С того, что сравнивать докер с jail — это как сравнивать грузовик с велосипедом. Изоляция на уровне cgroups и namespaces — это только вишенка на торте. Главное — унифицированный механизм упаковки и распространения образов, который сделал докер лучшим (и, практически, единственным) пакетным менеджером для серверов.

Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

51. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +1 +/
Сообщение от Аноним (-), 23-Фев-20, 16:55 
https://bsdstore.ru
https://bastille.readthedocs.io/en/latest/index.html
Ответить | Правка | Наверх | Cообщить модератору

52. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +/
Сообщение от Аноним (-), 23-Фев-20, 17:18 
> https://bastille.readthedocs.io/en/latest/index.html

И в чем принципиальная разница с ezjail, qjail, cbsd, iocage, iocell, (и сколько их там былое еще, доделанных и не очень)?

Ответить | Правка | Наверх | Cообщить модератору

54. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +2 +/
Сообщение от пох. (?), 23-Фев-20, 17:28 
угу. именно. Изоляция на уровне собирания ее из (насквозь дырявых, by design) костылей и подпорок, раскиданных по разным подсистемам ведра - это вишенка на тортике из коровьих лепех.

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

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

Ответить | Правка | К родителю #36 | Наверх | Cообщить модератору

139. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  –2 +/
Сообщение от Аноним (139), 24-Фев-20, 16:18 
Потому что эта штука из костылей и подпорок работает, и для ее использования не надо собирать троллейбус из буханки хлеба и километровых шелл-скриптов. Все понятно любому джуну.

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

Ответить | Правка | Наверх | Cообщить модератору

145. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +1 +/
Сообщение от пох. (?), 24-Фев-20, 19:26 
для ее использования надо собирать целых три троллейбуса. Один - следит за тем чтобы сам доскер запустился и сделал это вовремя (иначе можно поиметь проблем с контейнерами, зависящими от внешних адресов или правильного порядка старта других контейнеров), другой - за тем что внутри доскера - потому что в любом прожекте на доскерхабе посложнее ping - там внутри наколеночный обмотанный не изолентой а малярным скточем (джун не видит разницы, а тот ближе лежал) имитатор инита (штатные нарочно проверяют "не под докером ли мы запускаемся" и отказываются работать), имитатор крона (вы легко найдете на стековерфлоу двестиписят причин почему нельзя просто запускать крон в докере - кстати, они высосаны из пальца) и, возможно, еще и smtp сервер, хотя и клиента было бы много.
И, наконец, третий следит за тем чтобы работало то, ради чего все это затеяно - не "контейнеры", которые нахрен никому не нужны, а сервисы.

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

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

А stateless архитектуры (только не "микросервисные", потому что мощности нехватало, а не была куча лишней) у нас были, к примеру, в 2008м. С почти авто-масштабированием (как только "авто"прикрутишь новый сервер к стойке) и прочими фуфелами. Внезапно, это можно сделать силами трех админов за небольшую зарплату и в свободное от подпирания костылей время.

Но разработчиков там больно пороли, если собранный ими rpm "забывал" принести необнаруживаемую автоматикой зависимость. Поэтому никаких оберток эта штука не требовала.

Ответить | Правка | Наверх | Cообщить модератору

49. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +1 +/
Сообщение от Аноним (2), 23-Фев-20, 16:52 
> что сейчас вдруг bsd стало отсталым?

Нет Wayland и systemd

Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

83. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  –3 +/
Сообщение от Аноним (82), 23-Фев-20, 21:23 
> Нет Wayland и systemd

ЧСХ, графические дрова они пилять не умеют, как впрочем и иксы.  И как только шляпники и те кто рядом забьют на иксы болт - попробуйте догадаться что случится дальше. Вижу два варианта: неспешно тонуть на неподдерживаемой лодке или собезьянить у пингвина в очередной раз.

Ответить | Правка | Наверх | Cообщить модератору

91. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +/
Сообщение от Аноним (-), 23-Фев-20, 22:05 
>> Нет Wayland и systemd
> ЧСХ, графические дрова они пилять не умеют, как впрочем и иксы.  

ЧСХ - аноним опять ни*рена не разбирается, но мнение имеет:
https://www.phoronix.com/scan.php?page=news_item&px=FreeBSD-...
> FreeBSD Looks At Making Wayland Support Available By Default

Written by Michael Larabel in BSD on 22 December 2017 at 08:05 PM EST. 39 Comments
https://twitter.com/johalun/status/830178649554837504/photo/1
https://pbs.twimg.com/media/C4VjE7PVYAAIG8S?format=jpg&name=...
> Johannes Lundberg
> #FreeBSD update. Got everything I need now to run my #Wayland desktop.
>  Feb 10, 2017

Ответить | Правка | Наверх | Cообщить модератору

103. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  –2 +/
Сообщение от Аноним (-), 24-Фев-20, 02:45 
> ЧСХ - аноним опять ни*рена не разбирается, но мнение имеет:
> https://www.phoronix.com/scan.php?page=news_item&px=FreeBSD-...

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

Ответить | Правка | Наверх | Cообщить модератору

123. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +1 +/
Сообщение от Аноним (-), 24-Фев-20, 12:43 
>> ЧСХ - аноним опять ни*рена не разбирается, но мнение имеет:
>> https://www.phoronix.com/scan.php?page=news_item&px=FreeBSD-...
> Во, а через некоторое время они look'ать начнут гораздо активнее,

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

Или это инсайдерская инфа, типа вейланд уже почти готов и поэтому пришла пора переписать его с ноля?

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

Фанаты вяленого уже лет 10 предсказывают послезавтрашний иксокапец.
"BSD RIP" от местных вангователей тоже слышим непрерывно второй десяток лет
Но как оказалось - частое повторение и громкие вопли почему-то не меняют реальность, да и с предсказаниями развития технологий и проектов у анонимов тоже туговато - как с тем же "BTRFS уже совсем скоро все зарулит!!Вот!" усиленно выдаваемое анонимом еще лет 6 назад - что не помешало Шапке выкинуть поддержку из RHEL 8.

Ответить | Правка | Наверх | Cообщить модератору

141. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +/
Сообщение от Аноним (-), 24-Фев-20, 18:29 
> Во, а через некоторое время они look'ать начнут гораздо активнее, или про
> них все забудут, когда прохудившийся иксовый титаник окончательно уйдет на дно,
> благо прорех там хоть отбавляй и все что надо редхатовцам это выключить свои насосы.

Вместо придумывания образных сравнений лучше бы ознакомился с предметом.


Ответить | Правка | К родителю #103 | Наверх | Cообщить модератору

163. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  –1 +/
Сообщение от Аноним (-), 26-Фев-20, 11:47 
> Вместо придумывания образных сравнений лучше бы ознакомился с предметом.

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

Ответить | Правка | Наверх | Cообщить модератору

167. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +/
Сообщение от Аноним (-), 26-Фев-20, 13:56 
>> Вместо придумывания образных сравнений лучше бы ознакомился с предметом.
> А я с ним вполне себе знаком, с точностью до конкретных рож
> пилящих этот код. Но вы можете тешить себя мыслями что это аноним гонит, а не шляпоинтельские чуваки решили от иксов отделаться, конечно :)

https://github.com/freedesktop/xorg-xserver/graphs/contribut...
Смотрим тех, кто из долговременно активных коммитеров (по другому гитхаб похоже показать не умеет - там есть еще тройка закоммитивших недавно по тыще-другой строк - совсем не интелредгадчиков ))) закоммитил 1000+ строк за последние 4 года:
Одна "рожа" из бродкома, одна (Jon Turney) - непонятно, но вряд ли интел и редгад.
Одна - целый Кейт Паккард.
Из 6 "долговременных" топов.
Т.е. аноним то ли не знал, то ли соврал^W нафантазировал и сам поверил.

Ответить | Правка | Наверх | Cообщить модератору

116. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +/
Сообщение от анонимчик (?), 24-Фев-20, 12:15 

> Нет Wayland и systemd

мне нравится wayland, а вот systemd не используя на домашнем. в работе приходилось для запускалки демонов и вачдог. раньше для этого monit использовал.

Ответить | Правка | К родителю #49 | Наверх | Cообщить модератору

142. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +/
Сообщение от Аноним (-), 24-Фев-20, 18:34 
Толсто.

На самом деле вейланд нужен а системд ненужен.

Ответить | Правка | К родителю #49 | Наверх | Cообщить модератору

15. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +1 +/
Сообщение от llol (?), 23-Фев-20, 12:32 
Ну и что, что он зомби, зато он встал и пошёл, llol :))
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Спонсоры:
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2021 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру