Миниум без 3 эмоджи не прокатит.

С новым ядром не работает встроенная сетевая карта Realtek r8169. Причём после переагрузки со старым ядром тоже не работает до тех пор, пока полностью не выключишь питание. Откатился на 5.3.0.

Вы о чом дяденька йуэсби всегда работало и работает как надо.

В гугл по строчке slow USB linux kernel bug.

Как лет десять назад запилили неблокирующееся ядро, так до сих пор то тут, то там появляются сообщения, что при более-менее большом объеме данных при копировании через USB (скажем, от 2-4 ГБ и выше) скорость со временем начинает падать до десятков килобайт в секунду.

Помню, баг с проблемой ввода-вывода (а он затрагивал не только USB) искали довольно долго и объявляли, что он исправлен, несколько раз. Потом решили, что дело в том, что слишком много система могли вызвать такой эффект и типа само при переписывании исправится. Вот все жду…

Ну, по сути, ядру при запуске передаётся адрес/путь PID 1 проги (init), и уже init начинает рулить процессами, так вот этот init можно частично в ядро перенести и конфиг для служб уже класть на hdd/ssd раздел, всё это по причине популярности контейнеризации, где своя systemd / init уже по сути то и не нужна, в контейнере живёт один процесс, который и нужно стартовать, и управлять им тупо через докер (или его замену, не суть важно)

Твое желание противоречит Unix-way (Благородному пути Юникса). Ядро - это коллекция аппаратных и виртуальных драйверов. Демоны процессов - это не драйвера, это служебные утилиты. И они могут быть какими угодно. Вот например, Поттеринг запилил однажды аналог Windows-ского init, назвав его sistemD.

Патч 44мб" это как? Ядро в /boot/vmlin.. само ядро весит чуть более 5мб.

У тебя заранее скомпилированный и зжатый образ BzImage. А тут говорят об исходных кодах. Исходники ядра уже в сжатом состоянии весят ок. 90 Мбайт.

Какого виндоусовского, упрлся? Макосовского, а не виндовского «launchctl»

А может просто rfkill надо было ковырнуть?

Удваиваю, я про это и писал. Более того, инит теперь будет работать в пространстве ядра. А зачем, спрашивается? Если и так в системд находят критические уязвимости, то так мы их притащим прямо в ядро и это будет еще печальней. Я вобще считаю, что чем более критична часть системы, тем меньше в ней должно быть кода. Ибо чем меньше кода — тем меньше дыр и багов. Ядро и так больше чем на половину состоит из драйверов, а если мы еще инит туда вопхнем, выйдет монструозный комбайн. По вышеизложеным причинам, мне последнее время интересна концепция микроядра, но пока, к сожалению нет практически применимых UNIX систем на основе микроядер.

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

ты зачем подтвердил это? Это же тупо копипаста с опеннета

Так нет запрета на то ,чтобы копировать статьи с других сайтов

Другие сайты иногда обижаются, когда у них воруют.

Другие сайты иногда обижаются, когда у них воруют.

Ты дебил? Забанься.

Другие сайты иногда обижаются, когда у них воруют.

Указывают ссылку откуда была взята эта информация

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

Ты понимаешь, о чем я говорю? Зачем увеличивать число дыр в самом критичном компоненте системы? Пусть они бодут в менее опасных местах. Ядро не должно быть свалкой. И чем больше кода, тем больше дыр. Следовательно, зачем в ядре много кода? Чем меньше дыр будет в пространстве ядра, то есть с повышенными привелегиями, тем лучше.

И чем больше кода, тем больше дыр

Это диванный теоретинг. Далеко не все потенциальные дыры люди находят, и ещё меньше дыр люди эксплуатируют. А высокая производительность - вот она, лапки протяни.

Это диванный теоретинг. Далеко не все потенциальные дыры люди находят…

Это и есть диванный теоретинг. Во-первых, чем больше кода, тем проще добустить в нем ошибку, в том числе и ошибку в безопасности. И тем труднее ее найти. Во-вторых, чем меньше кода, тем проще его поддерживать. И в-третьих — а нахрен в ядре система инициализации? Можешь мне объяснить? Зачем нужен комбайн? Я уже говорил, что ядро и так больше чем на половину состоит из драйверов. В этих драйверах уже находили дыры. На ЛОРе даже была новость. Если в ядре еще будет система инициализации, это будет конец. И вообще, про принцип KISS ты слышал, теоретик?

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

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

Новый год же был месяц назад… Пойди, в проруби искупайся, что ли…

Очередной диванный теоретинг

Диванные теоретики, наяривающие на чистоту и минимализм

Неопровержимые аргументы! В пользу того, что ты сам — диванный теоретик. Этот высер очередной раз подтверждает эту точку зрения. Я тебе привел логические доводы и сослался на конкретные вещи, а ты рассказываешь мне, какой я теоретик. Раньше ты казался адекватней. И вобще, разговор изначально был про то, стоит ли встраивать систему инициализации в ядро. Тут прискакал ты и начал про «теоретинг». Шикарная логическая цепочка вышла!

Если ты не понял, я все еще жду от тебя внятной аргументации. Но, чесно говоря, я уже теряю надежду.

Я тебе привел логические доводы

Ты привёл очевидности типа «чем сложнее механизм, тем вероятнее он сломается». Но в сложных механизмах есть объективная потребность, так же как и в массе всяких штук в ядре Linux.

Я не говорю, что любое усложнение — смертный грех. Но когда простую вещь делают сложной без разумной на то причине, в этом ничего хорошего нет. Включение в ядро системы инициализации, на мой взгляд, неоправданное усложнение и противоречие с философией UNIX. Что это за масса всяких штук в ядре Linux и в чем непостижимый сакральный смысл размещения их всех в ядре? Например, что забыли в ядре драйвера для китайских сетевух, кардридеров и прочего железа? Лично я считаю, что запихивание в ядро драйверов — это уже усложнение, причем неоправданное.

пишут же не боги

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

Ввиду всего вышесказанного, не теряю надежды на проект Hurd. Но, похоже, пациент скорее мертв, чем жив. Повезет еще, если его наработки помогут при создании другой, похожей, системы.

когда это кого либо останавливало? все же троллят тео

поныть все могут, где репорт?

Ядро ж опционально собирается. Не хочешь - не включай инит при сборке, делов то

В новую версию принято 15505

Каждый релиз столько исправлений, там уже по идее всё должно быть вылизано акт котовы бубенцы, сколько же там кода!?

когда это кого либо останавливало?

Да, к сожалению…

Уже больше 20 миллионов. Примерно 56% — драйвера. Даже в новости: «Около 44% всех представленных в 5.5 изменений связаны с драйверами устройств».

Ясно понятно, как считаете, стоит обновляться или погодить пока?

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

Хорошо. Но НАХЕРА там инит? Ты можешь мне обьяснить смысл включения инита в ядро? Даже если можно скомпилировать без него, у большинства стоит ядро по-умолчанию для дистрибутива.

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

Возможность совершения действия никак не аргументирует целесообразность этого действия. Нужен ответ на вопрос «Зачем?», а не «Можно ли?».

Благодарю, я пока в этих вопросах нуб, но я учусь:).

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

minix3 чем не угодил?

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

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

Darwin

Ты петросян?

Ты просил Unix и микроядро

Я просил практически применимые системы. а таковых, к сожаленю, не наблюдается.

Я имел ввиду возможность практического применения системы.

Хорошо тогда поясни смысл следующей цитаты:

Новости Debian GNU/Hurd 07 Июля 2019

Выпущен Debian GNU/Hurd 2019!

С огромным удовольствием команда Debian GNU/Hurd сообщает о выпуске Debian GNU/Hurd 2019.

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

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

Реализация, предложенная в харде, не единственная возможная реализация микроядра.

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

Линус практик если он не видит смысла в микроядре, может не надо его, это микроядро.

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

sistemD

К логопеду, быдло.

Опенсорс сам такое не потянет, тут только если самсунго-гуглы сделают и поделятся

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