The OpenNET Project / Index page

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



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

Оглавление

Проект Debian начал общее голосование по вопросу поставки проприетарных прошивок, opennews (??), 27-Авг-22, (0) [смотреть все]

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


6. "Проект Debian начал общее голосование по вопросу поставки пр..."  +11 +/
Сообщение от Тот_Самый_Анонимус (?), 27-Авг-22, 22:35 
Они уже огласили правильный вариант, который если не выберут, то голосование будет проводиться снова и снова?
Ответить | Правка | Наверх | Cообщить модератору

7. "Проект Debian начал общее голосование по вопросу поставки пр..."  –9 +/
Сообщение от kusb (?), 27-Авг-22, 22:41 
Ubuntu это дебиан
Alt Linux это тоже дебиан, там apt-get.
Ответить | Правка | Наверх | Cообщить модератору

14. "Проект Debian начал общее голосование по вопросу поставки пр..."  +4 +/
Сообщение от Аноним (8), 27-Авг-22, 22:57 
> Alt Linux это тоже дебиан

С дуба упал?! Альт спочковался от Мандривы, которая на Красношапке. Сейчас Альт - самостоятельный дистр.

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

30. "Проект Debian начал общее голосование по вопросу поставки пр..."  –5 +/
Сообщение от Аноним (30), 27-Авг-22, 23:54 
> Сейчас Альт - самостоятельный дистр

ага, как манжара

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

40. "Проект Debian начал общее голосование по вопросу поставки пр..."  –8 +/
Сообщение от kusb (?), 28-Авг-22, 00:42 
>> Alt Linux это тоже дебиан
> С дуба упал?! Альт спочковался от Мандривы, которая на Красношапке. Сейчас Альт
> - самостоятельный дистр.

Проекту Debian расскажете.

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

171. "Проект Debian начал общее голосование по вопросу поставки пр..."  +/
Сообщение от Аноним (-), 29-Авг-22, 01:17 
Альт не имеет ничего общего с дебианом. У них очень странный гибрид где высокоуровневая координация это apt но бэкэнд на основе rpm. Это гибрид тех и других. Спорный вопрос хорошо ли это, потому что в этой технологии в результате никто не разбирается кроме полутора извращенцев и их биолдовых роботов.
Ответить | Правка | Наверх | Cообщить модератору

174. "Проект Debian начал общее голосование по вопросу поставки пр..."  +/
Сообщение от Аноним (174), 29-Авг-22, 04:57 
так они с Suse пример брали, как будто что-то новое
Ответить | Правка | Наверх | Cообщить модератору

193. "Проект Debian начал общее голосование по вопросу поставки пр..."  +/
Сообщение от kusb (?), 29-Авг-22, 13:46 
Я правда знаю,я из-за этого и назвал Alt, а не Devuan какой-нибудь.
Ответить | Правка | К родителю #171 | Наверх | Cообщить модератору

195. "Проект Debian начал общее голосование по вопросу поставки пр..."  +/
Сообщение от Аноним (-), 29-Авг-22, 16:20 
> Я правда знаю,я из-за этого и назвал Alt, а не Devuan какой-нибудь.

Ты сказал что alt это дебиан. Это не соответствует действительности. Дебиан и его сообщество не имеют никакого отношения к альту. Пакетная база Debian ими не используется. А то что они apt взяли - мало ли кто и чего взял. Это не дебиан ни на уровне политик, ни на уровне технологий.

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

325. "Проект Debian начал общее голосование по вопросу поставки пр..."  +/
Сообщение от kusb (?), 08-Сен-22, 08:59 
Это было нечто близкое к шутке. Я знал что он не дебиан, поэтому и приплёл его.
Ответить | Правка | Наверх | Cообщить модератору

175. "Проект Debian начал общее голосование по вопросу поставки пр..."  –1 +/
Сообщение от I.F.K. (?), 29-Авг-22, 06:35 
>> Alt Linux это тоже дебиан
> С дуба упал?! Альт спочковался от Мандривы, которая на Красношапке. Сейчас Альт
> - самостоятельный дистр.

От Мандривы ли?

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

178. "Проект Debian начал общее голосование по вопросу поставки пр..."  +/
Сообщение от ryoken (ok), 29-Авг-22, 07:38 
Таки от Mandrake Linux. Мандривы тогда ещё не существовало, когда Alt появился.
Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

15. "Проект Debian начал общее голосование по вопросу поставки пр..."  +4 +/
Сообщение от Alex (??), 27-Авг-22, 22:59 
Alt не debian хоть и apt-get а пакеты RPM!
Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

29. "Проект Debian начал общее голосование по вопросу поставки пр..."  +2 +/
Сообщение от Аноним (30), 27-Авг-22, 23:53 
а как кнопка может быть дебианом?
Ответить | Правка | Наверх | Cообщить модератору

31. "Проект Debian начал общее голосование по вопросу поставки пр..."  +/
Сообщение от Аноним (31), 27-Авг-22, 23:56 
и какие принципиальные отличия rpm от deb? именно как формата распространения бинарных файлов

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

42. "Проект Debian начал общее голосование по вопросу поставки пр..."  +4 +/
Сообщение от Аноним (8), 28-Авг-22, 00:58 
- несовместимость различных версий RPM
- несовместимости spec-файлов в RPM между дистрибутивами
- несовместимости пакетных зависимостей в RPM

В DEB такого нету.

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

72. "Проект Debian начал общее голосование по вопросу поставки пр..."  –1 +/
Сообщение от n00by (ok), 28-Авг-22, 07:43 
Формат файлов - это tar, gz, вот это вот всё.
Ответить | Правка | Наверх | Cообщить модератору

172. "Проект Debian начал общее голосование по вопросу поставки пр..."  +/
Сообщение от Аноним (-), 29-Авг-22, 01:18 
DEB и RPM так то тоже форматы файлов.
Ответить | Правка | Наверх | Cообщить модератору

188. "Проект Debian начал общее голосование по вопросу поставки пр..."  +/
Сообщение от n00by (ok), 29-Авг-22, 09:43 
Ну да. И вопрос задали про формат. А ему в ответ про несовместимость сборочных сценариев. Как видим, принципиальных отличий у форматов нет, кроме как наличие экспертов.
Ответить | Правка | Наверх | Cообщить модератору

196. "Проект Debian начал общее голосование по вопросу поставки пр..."  +/
Сообщение от Аноним (290), 29-Авг-22, 16:30 
> Ну да. И вопрос задали про формат. А ему в ответ про
> несовместимость сборочных сценариев. Как видим, принципиальных отличий у форматов нет,
> кроме как наличие экспертов.

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

В результате это совершенно разные экосистемы на всех уровнях, от штатных тулзов и форматов до тех кто в этом разбирается. Дебианщик отстроит пакет для убунты, кноппикса, или там Mint какого. Но для альта - not a chance. Тулсет совсем другой.

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

203. "Проект Debian начал общее голосование по вопросу поставки пр..."  +/
Сообщение от n00by (ok), 29-Авг-22, 16:55 
Формат файла - это, условно, заголовок, где перечислены составные части (входящие в архив файлы) и собственно сами части, обработанные алгоритмом сжатия. spec файл не описывает формат rpm, это сценарий сборки.
Ответить | Правка | Наверх | Cообщить модератору

211. "Проект Debian начал общее голосование по вопросу поставки пр..."  –1 +/
Сообщение от Аноним (-), 29-Авг-22, 17:12 
> Формат файла - это, условно, заголовок, где перечислены составные части (входящие в
> архив файлы) и собственно сами части, обработанные алгоритмом сжатия.

И в этом аспекте deb и rpm таки тоже разные.

> spec файл не описывает формат rpm, это сценарий сборки.

Однако в дебиане вообще нет spec-файлов и deb-пакеты билдуются иначе и другими тулзами. Соответственно, точек пересечения - нет. Кроме того факта что они, видите ли, припахали вон ту тулсу делать вон ту (изначально ей несвойственную) работу. На чем совпадения и заканчиваются.

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

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

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

214. "Проект Debian начал общее голосование по вопросу поставки пр..."  +/
Сообщение от n00by (ok), 29-Авг-22, 17:31 
>> Формат файла - это, условно, заголовок, где перечислены составные части (входящие в
>> архив файлы) и собственно сами части, обработанные алгоритмом сжатия.
> И в этом аспекте deb и rpm таки тоже разные.

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

>> spec файл не описывает формат rpm, это сценарий сборки.
> Однако в дебиане вообще нет spec-файлов и deb-пакеты билдуются иначе и другими
> тулзами. Соответственно, точек пересечения - нет. Кроме того факта что они,
> видите ли, припахали вон ту тулсу делать вон ту (изначально ей
> несвойственную) работу. На чем совпадения и заканчиваются.

Да знаю, что там как-то иначе билдуется. Мне надо было на ядро накинуть пару патчей и собрать, результат я получил, но смысл сделанного не понял. Тогда как spec и тем более ebuild я могу более-менее осмысленно написать. Полагаю, проблема тогда была не в deb, а просто мне было лень разбираться в непривычном. Ну и мне удобнее, когда оно всё в одном файле.

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

У меня в Gentoo устанавливаются rpm, которые собираю с другой Gentoo, при этом зависимости обрабатываются совсем другой штукой. И какие-то «левые» rpm (Яндекс Браузер) устанавливаются. А то что какая Rosa Tresh вращается на Красной Шляпе и от неё зависит - ну так у них и доля на рынке упала с 3% до 1%, по данным CNews. :) тогда как местный дериватив Debian тут в гору идёт.

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

217. "Проект Debian начал общее голосование по вопросу поставки пр..."  –1 +/
Сообщение от Аноним (-), 29-Авг-22, 17:54 
> Не удивлюсь, что поля в заголовке, как и алгоритмы сжатия различаются.

Deb и RPM весьма разные по структуре вещи.

> Но про это пока никто не написал, и вряд ли эта разница
> принципиальна (чем и интересовался спрашивающий).

Кроме того что это совершенно независимые форматы? И обвев вокруг, без коего оно не пакетный манагер а архиватор позорный :). Есть довольно большая разница между "вывалить файло в диру" и "зарегистрировать этот факт с потребным описанием". Чтобы потом иметь возможность ремува этого, понимание какие файлы и когда (не)трогать, какие хуки когда вызвать и все такое. И вот это все у вон той парочки весьма раное так изначально.

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

В ядре для этого сейчас вообще есть make bindeb-pkg. Смысл в том что билдсистема ядра отстроив оное - пнет билд пакета дебиана его тулсами, отстроив валидный пакет. Который потом достаточно корректно ставится/сносится. С апдейтом initrd, регистрацией опции в бутлоадере и прочим добром. И да, если хочется раскурить полный маршрут, путь довольно длинный. Но таки я отстроил минимальный deb пакет "голыми руками" (для этого надо tar, xz и ar). Для редхатобразных кернел тоже так умеет, но в работу их тулсов по части пакетов я не вхож. Это совсем другие тулсы. Технически deb это архив AR (лол) в котором 2 тарбола, один с данными, второй с метаданными. У редхата rpm это какой-то tar.gz + добавочные хидеры, как его голыми руками кроить я не знаю, не интересовался (за это спасибо отвратительным пакетным менеджерам редхата).

> Тогда как spec и тем более ebuild я могу более-менее осмысленно написать.

Для того чтобы ехать из A в B не обязательно уметь проектировать ДВС...

> Полагаю, проблема тогда была не в deb, а просто мне было лень разбираться в непривычном.

Вполне вероятно. Я разобрался - в случае deb.

> Ну и мне удобнее, когда оно всё в одном файле.

Смотря как далеко идет это "все". Окей, вон та виртуалка на 6 гигз - "вообще совсем все", операционка, либы, кернелы, модули, гуй, DE, офис и цать програм... . Но нифига не гранулярно. Вы или качаете 6 гигз, или - нифига. А пойнт пакетного менеджера в том чтобы вместо монолитной чушки модульность была. Так то пакет с тем же кернелом, вот именно самим ядром и модулем это 1 DEB файл на выходе будет. Он как правило самодостаточный даже - кернел как таковой ни на ком не depends, чего б ему?

> У меня в Gentoo устанавливаются rpm, которые собираю с другой Gentoo, при
> этом зависимости обрабатываются совсем другой штукой. И какие-то «левые» rpm
> (Яндекс Браузер) устанавливаются.

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

> CNews. :) тогда как местный дериватив Debian тут в гору идёт.

Если это про альтлинукс, он не дериватив Debian ни в одном глазу. И на лично мой вкус он может идти известным курсом, в отличие от сабжа.

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

250. "Проект Debian начал общее голосование по вопросу поставки пр..."  +/
Сообщение от _kp (ok), 30-Авг-22, 02:59 
> Формат файлов - это tar, gz, вот это вот всё.

Ага, форматы файлов..
Вот распакуете и tar, и RPM и DEB, и устаноте, даже без проблем.

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

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

275. "Проект Debian начал общее голосование по вопросу поставки пр..."  +/
Сообщение от n00by (ok), 30-Авг-22, 10:16 
>> Формат файлов - это tar, gz, вот это вот всё.
> Ага, форматы файлов..

Перечитайте, пожалуйста, вопрос.

> Вот распакуете и tar, и RPM и DEB, и устаноте, даже без
> проблем.
> Но, не замечаете, что чего то не хватает?

Не замечал, мне всего хватало.

> Зависимые пакеты ручками ставить? Все несколько тысяч?

Для разруливания зависимостей можно создать файлик типа /etc/portage/sets/steam

А что бы жизнь мёдом не казалась, попробуйте установить AMDuProf в систему с Wayland и посмотрите, как пакетник «решит» проблемы с зависимостями. :)

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

Я пока из конфликтов вижу в основном священную войну deb versus rpm. Плюс у людей подчас какой-то бзик, что расширение решает, и deb пакет при желании нельзя установить куда-то ещё, что возможность конвертировать при помощи alien не существует и прочие подобные странные идеи. Вы и вон тот Аноним пишете в целом правильно, но неискушённый читатель из всего этого делает свои неверные выводы, и в итоге разносит по Сети какой-то хаос.

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

71. "Проект Debian начал общее голосование по вопросу поставки пр..."  +/
Сообщение от n00by (ok), 28-Авг-22, 07:40 
В Gentoo можно собрать rpm, а про deb не знаю. А так тот же rar-архив, только вид сбоку. ;)
Ответить | Правка | К родителю #31 | Наверх | Cообщить модератору

197. "Проект Debian начал общее голосование по вопросу поставки пр..."  +1 +/
Сообщение от Аноним (290), 29-Авг-22, 16:34 
> В Gentoo можно собрать rpm, а про deb не знаю. А так
> тот же rar-архив, только вид сбоку. ;)

Угу, попробуй rar архив установить в винде чтобы он в списке установленных программ прорезался. Что, не очень получается? А, ну вот поэтому MSI это инсталлер, а RAR - архивер. MSI это такая жалкая, глючная, кривая и дико оверинженернутая пародия на пакетный менеджер. Правда майкрософт все понял как обычно по своему.

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

209. "Проект Debian начал общее голосование по вопросу поставки пр..."  +1 +/
Сообщение от n00by (ok), 29-Авг-22, 17:05 
>> В Gentoo можно собрать rpm, а про deb не знаю. А так
>> тот же rar-архив, только вид сбоку. ;)
> Угу, попробуй rar архив установить в винде чтобы он в списке установленных
> программ прорезался. Что, не очень получается?

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

Этот раздел упорядочен следующим образом:

    Создание типа файла, известного оболочке
    Описания обработчика типов файлов
    Связанные разделы

https://docs.microsoft.com/ru-ru/windows/win32/shell/fa-file...

И нет, это не намёк, что на «слабо» я делать не буду. Я просто не хочу таким заниматься, и даже когда писал под Винду от подобной работы отлынивал. ;) Там это кто угодно может прочитать и сделать. Это не Linuх, где выучил bash плюс пару приёмов риторики и уже можешь разрабатывать ОС.

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

212. "Проект Debian начал общее голосование по вопросу поставки пр..."  +1 +/
Сообщение от Аноним (-), 29-Авг-22, 17:24 
> Регистрация типа файла — это первый шаг при создании сопоставления файлов, что
> делает этот тип файла известным для оболочки.

Как бы тебе культурно объяснить, каким курсом следовало бы отправить твои виндовые замашки в контексте линуха? Для пакетного менеджера Linux вообще пофиг есть какие либо mime регистрации на тип данных или нет. Это как максимум влияет на просмотр файликов в каком-нибудь манагере архивов, но пакетник и без всего этого знает зачем его позвали, откуда файло тянуть и какой он формат желает. Это implied knowledge. Ты не можешь попросить debian начать жрать rpm в его пакетнике без очень серьезной перепиловки пакетника. И в этот момент оно уже совершенно точно более не дебиан на чисто технологическом уровне.

> Однако без обработчиков типов файлов оболочка не может предоставлять пользователю
> информацию из файла и о ней.

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

Ну вот например. Программа при установке может создать файлы динамически. Или допустим при установке новой версии мы не хотим перетирать вон те 5 файлов, допустим, конфиг/данные юзера. Где это все в RAR вообще описано? А, нигде и надо самому изобрести? Ну да, кто сказал что на основе RAR нельзя сделать пакетный менеджер? Но RAR как формат будет subset вон той штуки, полная спецификация потребует устаканить договоренности которых в RAR не было.

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

> И нет, это не намёк, что на «слабо» я делать не буду.

Я это и не просил, просто пытался показать ключевые отличия.

> Я просто не хочу таким заниматься, и даже когда писал под
> Винду от подобной работы отлынивал. ;) Там это кто угодно может
> прочитать и сделать. Это не Linuх, где выучил bash плюс пару
> приёмов риторики и уже можешь разрабатывать ОС.

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

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

213. "Проект Debian начал общее голосование по вопросу поставки пр..."  +/
Сообщение от Аноним (-), 29-Авг-22, 17:31 
А, еще 1 штука. Pre/post install скрипты всякие и т.п.. MSI это все тоже умеет. Криво и мучительно, но все же. Это иногда важно. Без этого "пакетный менеджер" может жестко уткнуться на простой и тупой проблеме.

В дебиане это все довольно развито. Можно внешние хуки регать. Так что качнув воооон тот дистро кернел оно потом сперва initrd ему в пару сгенерит, а потом еще что-то может. Ну там в меню бутлоадера вот именно ЭТОТ кернел вписать 1 из опций. Или вон тот kernel-flasher может на втрамбовать при установке пакета  кернел на отдельный партишн (в эмбедовке). Хоть пакет так сам по себе изначально и не умел - а platform knowledge ему привили где-то сбоку. И так далее. Покажи это RAR'ом, да? MSI наверное можешь потрепыхаться, если с катушек быстрее не слетишь.

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

219. "Проект Debian начал общее голосование по вопросу поставки пр..."  +/
Сообщение от n00by (ok), 29-Авг-22, 17:58 
Хуки при установке ядра - классная штука, руткитчики одобрят, года Джо перестанет быть Неуловимым.
Ответить | Правка | Наверх | Cообщить модератору

228. "Проект Debian начал общее голосование по вопросу поставки пр..."  +/
Сообщение от Аноним (228), 29-Авг-22, 19:04 
> Хуки при установке ядра - классная штука, руткитчики одобрят,
> года Джо перестанет быть Неуловимым.

Маленький нюанс: если кто это все может, у него в системе уже есть рут. А с ним и более 9000 других способов достичь аналогичного эффекта, начиная с LD_PRELOAD ламерского и далее со всеми остановками. Ну там другой пакет с ядром поставить, может даже самособраным, и проч.

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

Если вон тот момент интересует, видите ли секурбут есть, бутлоадер должен чекать что подпись ядра - вот именно моя и валидная. Ну а ядро по иерархии модули. Тогда руткит/буткит пролетит.

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

278. "Проект Debian начал общее голосование по вопросу поставки пр..."  +/
Сообщение от n00by (ok), 30-Авг-22, 10:33 
>> Хуки при установке ядра - классная штука, руткитчики одобрят,
>> года Джо перестанет быть Неуловимым.
> Маленький нюанс: если кто это все может, у него в системе уже
> есть рут.

А большой нюанс в том, что безопасность - это не некая булева переменная, при случайном значении false требующая лечь на спинку и поднять лапки. Это такой процесс, то есть её требуется обеспечивать. Если эту задачу начать изучать, то на каком-то из начальных этапов окажется, что бит «исполняемый» появился не на пустом месте, и возможность выполнить файл без такого бита - сразу требует сдаться кверху лапками, по вон той вышеприведённой «логике». :) на практике почему-то так мало кто делает, всего лишь вводят дополнительные проверки и запреты.

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

291. "Проект Debian начал общее голосование по вопросу поставки пр..."  +/
Сообщение от Аноним (-), 30-Авг-22, 23:05 
> А большой нюанс в том, что безопасность - это не некая булева
> переменная, при случайном значении false требующая лечь на спинку и поднять лапки.

Не вижу большой разницы, 9000 способов у рута поиметь меня или аж целые 9001. Вот тут реально ничего не меняется особо. Зато привносит очень крутой бенефит: пакет ничего не знает как его потом реально могут применить, а админ/имплементер системы может основательно оверрайднуть дефолтное поведение. И флешануть вон тем довеском кернел вооооооооон туда. Само по себе это лишь продолжение запроса "установить кернел" уточненное для "вот именно этой системы и ее особенностей". Альтернативы какие были? Не апдейтить кернел? Так можно в 20 раз больше вулнов собрать. Общеизвестных. И вот там уже рут для их эксплуатации может и не требоваться. Значит безопасность от этого все же скорее выиграет чем проиграет. А юзер с рутом найдет более 9000 иных способов трахнуть систему. Без рута, разумеется, свой хук прописать не получится. Да и даже пакет поставить, для начала.

Кстати MSI тоже подобное умеет, как минимум всякие постинсталл хуки. Просто оно там криво, мучительно и глючно, да еще работает через раз, поэтому кодеры сетаперов в сколь-нибудь активном проекте самые "за@#$ные жизнью" на вид.

> Это такой процесс, то есть её требуется обеспечивать. Если эту
> задачу начать изучать, то на каком-то из начальных этапов окажется, что
> бит «исполняемый» появился не на пустом месте,

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

>  и возможность выполнить файл без такого бита - сразу требует сдаться кверху лапками,
> по вон той вышеприведённой «логике». :)

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

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

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

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

299. "Проект Debian начал общее голосование по вопросу поставки пр..."  +/
Сообщение от n00by (ok), 31-Авг-22, 07:57 
>> А большой нюанс в том, что безопасность - это не некая булева
>> переменная, при случайном значении false требующая лечь на спинку и поднять лапки.
> Не вижу большой разницы, 9000 способов у рута поиметь меня или аж
> целые 9001. Вот тут реально ничего не меняется особо.

Решает тот факт, что разницу видят профи: 0-day, 1-day, public, «продают школьники».

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

310. "Проект Debian начал общее голосование по вопросу поставки пр..."  +/
Сообщение от Аноним (-), 01-Сен-22, 22:19 
> Решает тот факт, что разницу видят профи: 0-day, 1-day, public, «продают школьники».

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

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

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

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

Если верить вам, вон те штуки с squashfs должны быть супер секурны. Там же вообще хрен чего обновишь. На практике разумеется хрен: общеизветные веши там просто живут "эфемерно", только в оперативочке, им нормалек. Их коллеги сканят себе подобных и даже если с пары девайсов вылетели при ребуте, и черт с ним, через некоторое время бот опять найдет их и заново заразит, ему не лень, он железный, а то что не удалось перманентно прописаться - и хрен с ним. Поэтому такие штуки могут быть бестелесными и при этом - жить в сети "вечно", без очевидной возможности выбить их насовсем. Это вполне валидный концепт, опробованый еще MSBLAST'ом древним, и с тех пор используемый довольно много кем. И это даже хуже школьника - приходит само, если дыра в принципе есть, от каникул не зависит, и вообще.

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

321. "Проект Debian начал общее голосование по вопросу поставки пр..."  +/
Сообщение от n00by (ok), 02-Сен-22, 10:36 
>> Решает тот факт, что разницу видят профи: 0-day, 1-day, public, «продают школьники».
> Еще раз, при наличии рута есть более 9000 других способов нагадить в
> системе, некоторые из них знают даже школьники.

Тогда я перефразирую. Вы сами лично сколько поймали руткитов?

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

216. "Проект Debian начал общее голосование по вопросу поставки пр..."  +/
Сообщение от n00by (ok), 29-Авг-22, 17:45 
>> Регистрация типа файла — это первый шаг при создании сопоставления файлов, что
>> делает этот тип файла известным для оболочки.
> Как бы тебе культурно объяснить, каким курсом следовало бы отправить твои виндовые
> замашки в контексте линуха?

Да никак не надо объяснять, я немножко и так в курсе, что в Линуксе творится с документацией :) и почему на неё ссылки дают крайне редко.

> Для пакетного менеджера Linux вообще пофиг есть
> какие либо mime регистрации на тип данных или нет. Это как
> максимум влияет на просмотр файликов в каком-нибудь манагере архивов, но пакетник
> и без всего этого знает зачем его позвали, откуда файло тянуть
> и какой он формат желает. Это implied knowledge. Ты не можешь
> попросить debian начать жрать rpm в его пакетнике без очень серьезной
> перепиловки пакетника.

То есть задача из разряда «сел и написал». Другое дело, что именно для Debian такое не надо.

> И в этот момент оно уже совершенно точно более
> не дебиан на чисто технологическом уровне.

«Лишь бы не как в Венде» - это идеология. Может она и правильная, но это другой вопрос.

>[оверквотинг удален]
>> И нет, это не намёк, что на «слабо» я делать не буду.
> Я это и не просил, просто пытался показать ключевые отличия.
>> Я просто не хочу таким заниматься, и даже когда писал под
>> Винду от подобной работы отлынивал. ;) Там это кто угодно может
>> прочитать и сделать. Это не Linuх, где выучил bash плюс пару
>> приёмов риторики и уже можешь разрабатывать ОС.
> Ну как бы писать пакетный менеджер на баше занятие очень так себе.
> Да и как показывает практика большая часть юзеров винды вообще ни
> на что не способны, кроме как пальцы гнуть. На этом фоне
> даже башевый скрипткидь сойдет за гения мысли.

Там юзеры честно называют себя юзерами. Я писал не про них. Любой программер, кого я там видел, умеет читать MSDN и решит вон ту задачу про rar.

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

Это либо тролли зарабатывают себе шилдик Most Valuable Partner, либо профессиональные админы putty.exe. Простым пользователям тут делать нечего - не их тематика. Да и кодерам, в общем-то, тоже.

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

224. "Проект Debian начал общее голосование по вопросу поставки пр..."  +/
Сообщение от Аноним (224), 29-Авг-22, 18:47 
> Да никак не надо объяснять, я немножко и так в курсе, что
> в Линуксе творится с документацией :) и почему на неё ссылки дают крайне редко.

Размахивать перед линуксоидом доками на MSI - "бессмысленно и беспощадно". Ты же не думашеь что я буду строить MSI-пакеты, право? Я видел как это делается и эта идея вызывает у меня дикий ужас. Там все очень криво и оверинженернуто, поэтому что что в линухе я за полчаса сделаю, там будет кодинга на неделю и столько же дебага.

> То есть задача из разряда «сел и написал». Другое дело, что именно
> для Debian такое не надо.

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

> «Лишь бы не как в Венде» - это идеология. Может она и правильная, но это другой вопрос.

Я видел what it takes по части msi и проникся суеверным ужасом, спасибо. Но между нами, DEB и RPM, кажется, появились куда как ДО msi. А майкрософт лишь неумело собезьянил. Так же как UAC это такой крайне кривой и проблемный вариант того же sudo.

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

Через месяцок-другой интенсивного кодинга и тестирования, без этого оно не будет уметь "менеджмент пакетов" в его нормальном понимании. И даже так оно УГ будет, пакетники годами учились решать характерные проблемы, не тот случай когда пришел увидел победил, потом будут баги и особенности жестко иметь дофига времени, окажется что вон те хотели вот так но вы это не умеете, а по другому криво или не реализуется... ну в общем будет куита уровня slackware или в лучшем случае packman арчевского, но уж точно не мощный тулкит с обвесом уровня DEB и RPM.

> Это либо тролли зарабатывают себе шилдик Most Valuable Partner, либо профессиональные админы
> putty.exe. Простым пользователям тут делать нечего - не их тематика. Да и кодерам,
> в общем-то, тоже.

Возможно. Хотя я даже пару MVP видал живьем, и они вроде на такую фигню не разменивались. Но на технологическом уровне у меня на них дичайшая аллергия, на самых концептуальных уровнях. Мы хотим видеть мир очень разным...

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

280. "Проект Debian начал общее голосование по вопросу поставки пр..."  +/
Сообщение от n00by (ok), 30-Авг-22, 10:38 
>> Да никак не надо объяснять, я немножко и так в курсе, что
>> в Линуксе творится с документацией :) и почему на неё ссылки дают крайне редко.
> Размахивать перед линуксоидом доками на MSI - "бессмысленно и беспощадно". Ты же
> не думашеь что я буду строить MSI-пакеты, право?

Я думаю, что привёл достаточно информации, что бы закрыть вопрос «попробуй rar архив установить в винде чтобы он в списке установленных программ прорезался» и более к нему не возвращаться. Если не понятно: не надо меня просить что-то сделать, а потом возмущаться что риторика не работает, поскольку решение существует и тривиально.

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

292. "Проект Debian начал общее голосование по вопросу поставки пр..."  +/
Сообщение от Аноним (-), 30-Авг-22, 23:14 
> Я думаю, что привёл достаточно информации, что бы закрыть вопрос «попробуй rar
> архив установить в винде чтобы он в списке установленных программ прорезался»
> и более к нему не возвращаться. Если не понятно: не надо
> меня просить что-то сделать, а потом возмущаться что риторика не работает,
> поскольку решение существует и тривиально.

Мой пойнт был: чтобы использовать RAR архивы как именно пакетный менеджмент, придется это основательно допилить. В чистом виде он для этого не годится. Чтобы это было вот именно пакетным менеджером, потребуется устаканить какой-то понимаемый на обоих сторонах формат метаданных, out of band по отношению к данным.

Простой пример:
Вася делает пакет, он хочет записать /usb/bin/wtf.
Петя делает пакет, который тоже хочет /usb/bin/wtf положить.

Нормальный пакетник это видите ли поймает - и кинет ошибку, сообщив что вы юзаете кривой конфликтующий пакет, и будет понятно что из вон той парочки кто-то облажался (в дистре типа сабжа это на 99% проблемы майнтайнеров, до юзера это обычно не доходит). А теперь вон тот номер с RAR'ом плиз :). Умеет ли так MSI я честно гря не помню, у них хранение инфо о установленом довольно кривое и проблемное по жизни. Вплоть до того что прогу нельзя снести если ее инсталяшный MSI видите ли снесли (хранить весь пакет как источник этого инфо крайне неэффективно по месту).

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

300. "Проект Debian начал общее голосование по вопросу поставки пр..."  +/
Сообщение от n00by (ok), 31-Авг-22, 08:06 
>[оверквотинг удален]
>> меня просить что-то сделать, а потом возмущаться что риторика не работает,
>> поскольку решение существует и тривиально.
> Мой пойнт был: чтобы использовать RAR архивы как именно пакетный менеджмент, придется
> это основательно допилить. В чистом виде он для этого не годится.
> Чтобы это было вот именно пакетным менеджером, потребуется устаканить какой-то понимаемый
> на обоих сторонах формат метаданных, out of band по отношению к
> данным.
> Простой пример:
> Вася делает пакет, он хочет записать /usb/bin/wtf.
> Петя делает пакет, который тоже хочет /usb/bin/wtf положить.

Это возможно разрулить, если мыслить не в рамках «пакетов». Оба приложения получат свой /usb/bin/wtf. Один из вариантов решения предложен в NixOS (мне он не очень нравится).

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

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

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

311. "Проект Debian начал общее голосование по вопросу поставки пр..."  +/
Сообщение от Аноним (311), 01-Сен-22, 22:29 
> Это возможно разрулить, если мыслить не в рамках «пакетов».

А мне нравится мышление в именно пакетах, это делает систему модулярной и адекватной в управлении. А не как в винде - мол, can't find wtf.dll - но вы там сами думайте где она качается. Никаких чеков валидности выноса "msvcrt100500" оно тоже не предоставляет, там есть десяток непонятных "блаблабла рантайм" в списке установленого, но надо ли еще этот хлам хоть кому или нет - поди разберись, "depends" ms'овский хлам же не умеет нормально, так что угадайте сами, отвалится у вас что при сносе этого или нет.

> Оба приложения получат свой /usb/bin/wtf.

Это в принципе валидная опция, но это превращает систему в помойку по типу винды. Ну например, как и откуда мы знаем какие версии /usr/bin/wtf - апдейченые и фикшеные, а какие нет? А, вынести это все на плечи вебмакак и раздолбайских кодеров? Спасибо я на примере винды видел что при этом можно получить - и что-то я назад в винду вообще совсем не хочу. Потому что поддержание винды и софта в ней в сколь-нибудь секурном и апдейченом виде это mission impossible, а самое умное что MS смог придумать это "стор". Обойдусь без таких "благодетелей" на мою голову. Майнтайнеры с заранее заявлеными полисями гораздо предсказуемее.

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

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

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

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

76. "Проект Debian начал общее голосование по вопросу поставки пр..."  +/
Сообщение от Аноним (76), 28-Авг-22, 08:04 
> пакеты RPM

Стандартные пакеты rpm Альт считает сломанными. Поэтому если чего-то нет в репах Альта, пляски с бубном гарантированы. Особенно в свете того, что Альт зачем-то любит переименовывать стандартные пакеты, причем иногда в названиях использует верхний и нижний регистр. Ну его.

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

117. "Проект Debian начал общее голосование по вопросу поставки пр..."  +2 +/
Сообщение от Аноним (8), 28-Авг-22, 11:32 
Проблема RPM в том, что нет стандарта ни на сам RPM, ни на спеки пакета, ни на зависимости.
Ответить | Правка | Наверх | Cообщить модератору

119. "Проект Debian начал общее голосование по вопросу поставки пр..."  +1 +/
Сообщение от Аноним (8), 28-Авг-22, 11:35 
> стандартные пакеты

Вкусите для начала: rpm.org (aka rpm4) и rpm5.org - кто из них стандарт?!

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

133. "Проект Debian начал общее голосование по вопросу поставки пр..."  +2 +/
Сообщение от userd (ok), 28-Авг-22, 13:33 
> Стандартные пакеты rpm...

Если под стандартом понимается LSB, то проблем не встречал.
Другое дело, что из всей проприетари, с которой мне приходилось сталкиваться, в рамки LSB умещался только крипто-про. Прочей проприетари, ориентирующейся на RH RPM нужна перепаковка (epm repack).

> Поэтому если чего-то нет в репах Альта...

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

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

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

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




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

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