Представлен (https://lists.debian.org/debian-hurd/2019/07/msg00001.html) релиз Debian GNU/Hurd 2019, редакции дистрибутива Debian 10.0 "Buster" (https://www.opennet.ru/opennews/art.shtml?num=51041), сочетающей программное окружение Debian c ядром GNU/Hurd. Репозиторий Debian GNU/Hurd включает примерно 80% пакетов от общего размера архива Debian, в том числе портированы Firefox и Xfce 4.12.Debian GNU/Hurd и Debian GNU/KFreeBSD являются единственными платформами Debian, созданными на базе ядра, отличного от Linux. Платформа GNU/Hurd не вошла в число официально поддерживаемых архитектур Debian 10, поэтому релиз Debian GNU/Hurd 2019 выпущен отдельно и имеет статус неофициального выпуска Debian. Готовые сборки, снабжённые специально созданным графическим инсталлятором, и пакеты в настоящее время доступны только для архитектуры i386. Для загрузки подготовлены (https://cdimage.debian.org/cdimage/ports/current-hurd-i386/) установочные образы NETINST, CD и DVD, а также образ для запуска в системах виртуализации.
GNU Hurd представляет собой ядро, развиваемое в качестве замены ядра Unix и оформленное в виде набора серверов, работающих поверх микроядра GNU Mach и реализующих различные системные сервисы, такие как файловые системы, сетевой стек, система управления доступом к файлам. Микроядро GNU Mach предоставляет IPC-механизм, используемый для организации взаимодействия компонентов GNU Hurd и построения распределённой мультисерверной архитектуры.
В новом выпуске:
- Добавлена поддержка LLVM;
- Реализована опциональная поддержка TCP/IP стека LwIP (http://savannah.nongnu.org/projects/lwip/);- Добавлен транслятор ACPI, который пока используется только для выключения после завершения работы системы;
- Представлен арбитр шины PCI, который может оказаться полезным для корректного упрваления доступом к PCI;
- Добавлены новые оптимизации, затрагивающие режим прикрепления защищённых ресурсов (protected payload, походит на capabilities в Linux), управление подкачкой страниц памяти, диспетчеризацию сообщений и gsync-синхронизацию.
URL: https://news.ycombinator.com/item?id=20374239
Новость: https://www.opennet.ru/opennews/art.shtml?num=51048
Оно ещё шевелится?Лет 7 назад пинал палочкой в виртулбоксе- было совершенно неюзабельно,а щас?
Возьми да попробуй, нам расскажешь.
В виртуалке оно хотя бы загружаться может (правда не знаю насчет виртуалбокса, а вот под QEMU вполне). Но с поддержкой реального современного железа пока все туго.
И будет туго. Потому что заинтересованных в развитии и существовании этого самого Hurd - ничтожно малое количество в отношении к тем, кто активно _использует_ и пилит опенсорс. Можно считать, что проект джаст фор фан и/или исследовательский, не более.
> И будет туго. Потому что заинтересованных в развитии и существовании этого самого
> Hurd - ничтожно малое количество в отношении к тем, кто активно"делает и продаёт несовместимое железо", вы хотели сказать?
Не хотели? Ну, и ладно.
>опенсорс.
>джаст фор фан
>не более.ОМФГ.
>несовместимое...с чем? С поделкой полутора нердов?
>>несовместимое
> ...с чем? С поделкой полутора нердов?Полтора-два-три прОцента тоже мучаются.
_Некоторые_ покупальщики "игроваго" железа бегают по этим граблям: у них _аж_ дебиан не ставится.
>у них _аж_ дебиан не ставитсяЭто как раз нормально. Есть более подходящие для использования с современным железом и фирменными драйверами дистрибутивы.
#>>>> "делает и продаёт несовместимое железо", вы хотели сказать?>>у них _аж_ дебиан не ставится
>Есть более подходящие для использования с современным железом
> и фирменными драйверами дистрибутивы.Снова здорово.
А! Так это у тебя раз в пол-года дебиан не ставится?!
Это всё объясняет.
>раз в пол-года дебиан не ставится?!Зачем он мне? Мне для энтерпрайза RHEL за глаза хватает.
Прошлую версию Debian Hurd я пробовал установить на реальном железе - не взлетело. На процессе установки зависало. Но проект нужный. Надо ещё раз попробовать установить.
>Но проект нужный.Кому? И для каких целей?
технически система микроядра и системных серверов может быть куда более гибкой чем все юникс системы вместе взятые. и при этом более производительна, но все упирается в людей. если бы фирмам нужен был такой софт они бы давно его схватили. фишка в том, что линукс взлетел раньше и поддержка им железа , да количество софта общирней. никто не хочет вкладываться. а идея оч неплоха. а насчет стабильней оно или нет... ну в теории должно быть так, но на практике тут тоже куча серверов , которые должны обрабатывать кучу запросов программ. короче как говорится от багов никто не застрахован. но как проект чисто научный оч неплох.
>технически система микроядра и системных серверов может быть куда более гибкой чемТолько в вашем теоретическом мaнямирке. В реальности микроядра это свалка палок и навоза. За пределами какой-то одной очень специфичной и нишевой задачи ни одно из современных микроядер не юзабельно. Систему общего назначения на них не построить.
>Систему общего назначения на них
> не построить.То, что никто... пока B))) не смог этого сделать, не означает...
#нувыпонели
Ну вот когда сделают тогда и поговорим. А до тех пор не стоит распространять мифы про превосходство миркроядер.
> Ну вот когда сделают тогда и поговорим. А до тех пор не
> стоит распространять мифы про превосходство миркроядер.То есть аргументов против #25 не было и нет.
Впрочем, как и у самого #25 - аргументов "за".Вы не соскакивайте -- продолжайте "дискусс". Аудитория вукатайке.
> ни одно из современных микроядер не юзабельно. Систему общего назначения на них не построить.
>> Систему общего назначения на них не построить.Посмотрите Genode OS.
[i]и при этом более производительна, но все упирается в людей.[/i] - почему в людей-то? по моему опыту в случае если все ядро работает в одном адресном пространстве, то расходы на передачу данных внутри подсистем ядра по определению ниже, чем если ядро выполнено как микроядро и набор модулей, каждый из которых выполняется в своем адресном пространстве.предполагаю, что в современном мире реализация систем на базе микроядра и сервисов всегда будет медленней, чем в случае монолитного ядра.
"легкость" микроядра и "тяжеловестность" обычного. и этим все сказано. в стандарте микроядро будет чуток шустрее)) да если на него навесить столько же сколько сейчас на ядре линукс то тут уже и неясно кто шустрее)) в любом случае пока не проверишь на реальном железе не узнаешь. но предполагаю , что на встраиваемых устройствах было бы неплохо. на счет серваков... ну тут вилами по воде.. ))
[i]в стандарте микроядро будет чуток шустрее))[/i] - а толку от этого? в микроядре функциональность ядра минимальна - в итоге Вы будете работать минимум времени с [i]чуток[/i] более быстрым микроядром и значительную часть будете работать с существенно более медленными серверами. И каждый из серверов тоже будут работать минимум времени с чуток более быстрым микроядром.Я работаю в embedded - там все хуже, так как ресурсов значительно меньше. Последнее, что я бы втаскивал туда, так это микроядро. Но embedded бывает разный - может быть кто-то и использует что-то подобное.
Были штуки вроде микроядра L4, вполне-себе работоспособное
Открой для себя стрекозу,которая в отличии от сабжа не только работает на реальном железе,но и имеет свои плюсы вроде файловой системы.Сабж же вообще не понять для чего делается и с такими темпами,он ёщё через 30 лет до приемлимого состояния не дотянет.
технически система микроядра и системных серверов может быть куда более гибкой чем все юникс системы вместе взятые. и при этом более производительна, но все упирается в людей. если бы фирмам нужен был такой софт они бы давно его схватили. фишка в том, что линукс взлетел раньше и поддержка им железа , да количество софта общирней. никто не хочет вкладываться. а идея оч неплоха. а насчет стабильней оно или нет... ну в теории должно быть так, но на практике тут тоже куча серверов , которые должны обрабатывать кучу запросов программ. короче как говорится от багов никто не застрахован. но как проект чисто научный оч неплох.
Багрепорт?
Обязательно напишу. Сейчас надо в магистратуру поступать.
Уже развили, называется Fuchsia.
Это будет внутренний Гугл-проект для Гугл-инфраструктуры. Как иОС для Эппла. Не интересно.
Э! Шаталь, свободное от проприетарного не отличаешь?
Это предсмертная агония. Оно, к сожалению, намертво гвоздями-соточкой прибито к 32 битам, проще написать заново, чем портировать. Официальная позиция разработчиков, если что.
>Официальная позиция разработчиков, если что.Врёшь, как дышишь.
"" 64 bit support ... kernel part is done "" --https://www.gnu.org/software/hurd/open_issues/64-bit_port.html
Попробовал поставить в KVM. Поставилось. В консоли шевелится. Иксы стартуют, но в иксах не работает мышка никак. Так что для десктопа даже в виртуалке не готово, а для серверов оно и никогда не было нужно. Если хочется маргинальщины, то поставь OpenBSD, оно хоть и жутко тормозит, но работает и может в качестве десктопа юзаться
>> Если хочется маргинальщины, то поставь OpenBSDТогда уже OpenIndiana.
Тогда уже фряха - точно лучше и первого и второго.
А с каких пор фряха - маргинальщина?
Нужно переписать с нуля на Rust.
Rust лицензирован на MIT / Apache
И это как-то мешает писать на нем программы и лицензировать их под gpl?
Да, это позволяет закрыть среду разработки (Rust) в будущем и остаться без инструмента.
Это будет самоубийством для языка. Никто так делать не будет. К тому же форки всегда останутся
Словом, пока не появится фронтенд Rust в GCC, закладываться на него не стоит.
>Да, это позволяет закрыть среду разработки (Rust) в будущем и остаться без инструмента.Каким образом? Больные на голову гпльщики уже не знают какую чушь нести.
Всего два вопроса:
Как закрыть код, уже открытый?
Как владельцу гпл-кода лицензия помешает закрыть будущие версии?
> Как закрыть код, уже открытый?Купите(наймите) всех ключевых разработчиков и смените лицензию проекта. Все, код закрыт. Дальше дарагие бздуны будут разбираться в оставшемся - до освоения Галактики.
> Как владельцу гпл-кода лицензия помешает закрыть будущие версии?
Никак, на то он и владелец. Так что думайте буйной головкой и смотрите копирайты, прежде чем отсылать свой многабукав патч. Стоит-ли там FSF или Вася Пупкин, который мог выбрать GPL потому что чо, прикольно - а может и ножичком полоснуть...
>Как закрыть код, уже открытый?Элементарно, Ватсон! Cделать из бздунского кода закрытый форк - как два пальца. Все изменения/несовместимости добавлять в закрытую ветку.
> Элементарно, Ватсон! Cделать из бздунского кода закрытый форк - как два пальца.
> Все изменения/несовместимости добавлять в закрытую ветку.Как это сделает уже открытый код закрытым?
>> Элементарно, Ватсон! Cделать из бздунского кода закрытый форк - как два пальца.
>> Все изменения/несовместимости добавлять в закрытую ветку.
> Как это сделает уже открытый код закрытым?Никак.
Но ты ж не перестанешь работать на проприертарщиков, да-а?
И пропагандировать, шо так и надо, нет?" Гутт, Вольдемар, гутт! "
гпльщики - это сектанты-фанатики из мира IT
В мире гпл есть два типа фанатиков. Одни за гпл. Другие против. Первые адекватнее.
> В мире гпл есть два типа фанатиков. Одни за гпл. Другие против.
> Первые адекватнее.А "в мире" свободных опсорсников-пермиссивщиков, дружильщиков с капрорациями, ....
...всё наоборот. Два мира -- два наоборота.---""In Soviet Russia, TV watches you.""
> В мире гпл есть два типа фанатиков. Одни за гпл. Другие против.
> Первые адекватнее.Значит, ГПЛьщики делят мир на тех, кто за ГПЛ и всех остальных, кто автоматически против.
Причем тех, кому по* или кто вообще не слышал о каких-то лицензиях, в их мире не существует, это все на самом деле противники!
При этом они скромно считают себя адекватнее всех остальных, тех кто не за, а значит против.
Это многое объясняет, спасибо.
А еще гпльщики верят в особый рай. Все участники этого рая будут сидеть у ног Ричарда Столлмана и...
Дальше не придумал )
Бред. Никто в здравом уме не станет закрывать ЯП. Измышление больного воображения хомячков Столлмана.
Нет, не позволяет.
Тогда надо переписать Раст под ГЛП
> Rust лицензирован на MIT / ApacheТ.е. написать свой, правильный компилятор под AGPL нельзя, под страхом посмертного отключения от интернета? o_O
Или кто-то путает реализацию ЯП, то есть сам компилятор и непосредственно ЯП?
Можно, кому это надо - тот и напишет.
> Или кто-то путает реализацию ЯП, то есть сам компилятор и непосредственно ЯП?Да! И это разработчики rust. И их друзья ****окодеры из МоФоКо.
Каждая новая мозила требует каждого нового rustc, не совместимого...
...в каких-то очень(!) важных местах с предыдущим $(CURRENT - 0.01)...Реализация яп, говоите, стандарт яп, говорите? Хех!1...
>> Или кто-то путает реализацию ЯП, то есть сам компилятор и непосредственно ЯП?
> Да! И это разработчики rust. И их друзья ****окодеры из
> МоФоКо.
> Каждая новая мозила требует каждого нового rustc, не совместимого...
> ...в каких-то очень(!) важных местах с предыдущим $(CURRENT - 0.01)...
> Реализация яп, говоите, стандарт яп, говорите? Хех!1...Хех, не знаю. Что-то мне это напоминает, когда реализация ЯП и является его стандартом:
https://www.bell-labs.com/usr/dmr/www/primevalC.html
/*C compiler, part 2
Copyright 1972 Bell Telephone Laboratories, Inc.
*/
Но вот никак не пойму, что именно :(
Хорошая идея!
и sysvinit на rust надо переписать
sysvinit уже на могильный камень переписали. Может, стоит остановиться?
Через 100 лет археологи откопают этот камень, и полетят новости по миру об открытии сгинувшей супер-технологичной цивилизации.
//Troll mode enabled
А rust переписать на rustd
А Rust переписать на C. Многоходовочка!
Так есть же redox про это уже, с микроядром и активно пилится.
Там же вроде самый главный чел ушёл недавно, просто надоело. Если у них всё хорошо, то я только рад.
Redox тоже нужен. Нужно больше альтернатив. А то после Линуса придут какие-нибудь поехавший сжв, а переехать-то и некуда будет.
> просто надоелоУверен?
> Redox тоже нужен.
> А то после Линуса придут какие-нибудь поехавший сжв,
> а переехать-то и некуда будет.Так ведь Раст пилят как раз те самые "поехавшие сжв", ты не знал разве?
Оно мертворожденное. До сих пор даже драйвера ХДД нет, вообще никакого.
Бери и переписывай.
Как закончишь, доложишь лично мне.
Так точно.
+
>Нужно переписать с нуля на Rust.Не забываем, что GNU/HURD это проект FSF. Поэтому неплохо бы узнать отношение FSF к Rust сначала. Я не нашёл их официального мнения. Но сомневаюсь, что оно одобрительно.
>>переписать с нуля
>проект FSF. Поэтому неплохо бы узнать отношение FSF кНу, прочитай https://www.gnu.org/philosophy/free-sw.html
в конце-то концов. Напрягись!
> Ну, прочитай https://www.gnu.org/philosophy/free-sw.html
> в конце-то концов. Напрягись!Сам иди и прочитай, ты сам явно этого не делал: там про Rust (т.е. про то, о чём задан был вопрос) ничего не сказано. Только овердохуа букаф про какую-то "свободу". #troll_mode_on Непохоже вообще, чтобы это сомнительное околофилософское эссе писали реальные практикующие программисты. Чувствуется стиль гуманитариев-троечников. #troll_mode_off
> Нужно переписать с нуля на Rust.Начинай!
А в чем проблема? Щас создаст репо на гитшлаке и зальет туда README.md
C CoCk.md придется немного погодить, "в разработке".Дальше, как известно, любой прекрасный проект подхватывает и начинает развивать комьюнити, состоящее исключительно из трансгендерных разработчиков индоарабского происхождения, питающихся исключительно праной и далеких от мирских неприятностей.
Где найти Debian GNU/kFreeBSD? Все ссылки на сайте мертвые. На зеркале только 32-битная
https://mirror.yandex.ru/debian-ports/
Где? Ткни носом плиз.
Что мертво умереть не может. Ценности меньше чем у reactos и plan b
Вы сильно ошибаетесь, если Вы не видите ценности в этом проекте - это Ваше очень ценное мнение, ведь Вы очень сильны в открытых проектах и Всем нужна Ваша неоценимая помощь в развитии их проектов. В общем Ваше мнение очень важно для нас ... оставайтесь на линии.А теперь по делу: Этот проект реализуется и весьма неплохо, другое дело что скорость его реализации не велика так как правильная разработка микро ядра что бы все микро сервисы работали это Вам не разработка монолитного ядра.... Поэтому на реальных микро ядрах очень и очень мало ОС которые бы нормально работали. Даже в таком состоянии Он (Debian GNU/Hurd) более пригоден для повседневного использования чем многие ОС и выше Вами упомянутые ОС.
>Ценности меньше чем у reactosСерьёзно? У ReactOS являющегося бесеплатной, нативной альтернативой Окошек - малая ценность?
what the fuck im reading
>Debian GNU/Hurd и Debian GNU/KFreeBSD являются единственными платформами Debian, созданными на базе ядра, отличного от LinuxИ ведь не соврали. Gentoo kFreeBSD - не Debian.