А вот system V init DNS-запросов не делает.

[vitus_wagner]

А systemd делает, и поэтому его можно удаленно уронить.

Comments

[pishu]

делал до этого патча

[filin]

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

кто эти мистические "они"?

[pishu]

Кого конкретно вы имеете ввиду?

[astarsan]

Но блин зачем локальному systemd вообще куда то в сеть лезть? Блин накрутили опять черте-что.

[vitus_wagner]

Архитектура такая - монстроидальный демон, который делает всё.

[avnik]

systemd-resolved там далеко не essential часть, можно выключить и использовать скажем resolvconf, или даже просто выключить совсем.

[vitus_wagner]

Выключить нужно весь systemd. Поскольку все остальное там с таким же качеством.

[avnik]

Ну меня _в принципе_ устраивает systemd. Если будет что-то, кушающее его систему юнитов, но менее корявое. Или просто что-то лучшее -- То я немедленно, сразу туда перейду.

[develop7]

им это всё божья роса

[galeonis]

Хорошо, но мало, вот если бы он например еще и grub крешил-было бы вообще замечательно.

[vitus_wagner]

grub это сам по себе systemd такой. Жутко переусложненная конструкция.

На мой взгля, лучшим загрузчиком для Linux является syslinux,

[galeonis]

Тем более, классика "жаба и гадюка" всегда актуальна и востребована.

[livelight]

Пора уже и грубу послать кому-нибудь DNS-запрос, а то что он как бедный родственник?!

[avnik]

syslinux не очень много FS умеет, и выбор ядер/конфигураций там тоже ограничен насколько я помню.

/me например рад умению груба грузиться с zfs. (Хотя как выяснилось -- оно ломается на большом количестве хардлинков)

[vitus_wagner]

А зачем загрузчику уметь слишком много файловых систем? Что мешает иметь /boot раздел, да хоть и с fat, благо при наличии uefi все равно придется иметь fat-раздел для загрузки, и ядро с initrd туда вполне влезет.

[avnik]

в случае raid этих /boot становится больше одного, что тоже доставляет радости.

И да, uefi заставляет иметь еще раздел с fat кроме /boot с нормальной fs.
(и да -- пихать ядра на раздел uefi -- это путь поттеринга)

[edo-rus.livejournal.com]

ну это не аргумент, если П. чистит зубы по утрам - нужно бросить чистить зубы?

почему не стоит хранить ядро на uefi разделе?

[avnik]

Во первых у меня некоторое недоверие к фат
Во вторых -- у меня количество ядер/инитрд может стремиться к количеству поколений системы (обычно их конечно меньше, но за пару месяцев набегает 10-15 ядер, и раза так в три больше инитрд -- дольше двух месяцев я обычно поколения не держу). И у меня есть желание чтобы они читались непосредственно из /nix/store а не с отдельного fat, или даже с отдельного dataset на zfs (что меня тоже расстраивает, хотя и меньше)

[vitus_wagner]

Это клинический случай. 99% пользователей Linux делают не так.
Во-первых, у них бывает ровно одно ядро, максимум два, и при получении security update из дистрибутива он старое ядро заменяет
(и проблемы мейнтейнера дистрибутива сделать так, чтобы все оборудование на новом ядре завелось).
Во-вторых, кому нужна zfs, используют системы где она родная, а не левым патчем.

У меня у самого, правда, был случай, когда возникла необходимость грузиться с 2Тб раздела на ext3 или ext4 (я не помню, какая версия ext в тот момент была актуальна) и возможности переразбить не было.

[avnik]

zfs нет в апстриме ядра исключительно из-за лицензионной казуистики.

> и при получении security update из дистрибутива он старое ядро заменяет

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

[edo-rus.livejournal.com]

zfs нет в апстриме ядра исключительно из-за лицензионной казуистики.

может быть.
но из-за этого zol далеко не так хорошо протестирован, как ext2/3/4 или xfs.

[edo-rus.livejournal.com]

по-моему fat отличная система для бутлоадера, главное - простая.

если же у вас бутлоадер/ядро/initrd лежат на zfs - кто-то должен уметь этот zfs прочитать

[vitus_wagner]

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

[edo-rus.livejournal.com]

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


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

процитирую статью с хабра (https://habrahabr.ru/post/314412/):
при выставлении в настройках BIOS загрузки с диска прошивка UEFI сначала ищет на нём EFI-раздел, а затем пытается исполнить файл по строго фиксированному адресу на этом разделе: /EFI/Boot/BOOTX64.EFI

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