Создатель самобытного дистрибутива Adelie Linux, использующего стандартную Си-библиотеку Musl, систему инициализации OpenRC и пакетный менеджер APK, объявил об успешном портировании системного менеджера systemd для работы с библиотекой Musl. Несмотря на то, что реализация имеет статус начальной, она уже достаточно стабильна и демонстрирует трёхкратное сокращение времени загрузки, по сравнению с использованием OpenRC...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=61818
Пришло время переписать системду на ржавчину.
> Пришло время переписать системду на ржавчину.С 2021 года уже работа идёт https://github.com/systemd/systemd/pull/19598
Чел из микрософта и тут совершает саботаж
> С 2021 года уже работа идёт https://github.com/systemd/systemd/pull/19598И, в 2024 году у типа-системного ЯП - оказывается, есть ломовые проблемы с динамической линковкой, и все что оно реально умело нормально - линковать 6-метровые хелловорлды на манер игогошки. А шаг в сторону - и полны штаны гуано сразу. Так что с динамической линковкой швах. И баги на эту тему. В тулчейне. В 2024 году. Нет, это не опечатка, оказывается так можно было, назвать себя системными - но не решить самые базовые проблемы за почти 15 лет.
>И, в 2024 году у типа-системного ЯП - оказывается, есть ломовые проблемы с динамической линковкой,делали с прицелом на монолитное ядро. и они уже близко.
>> И, в 2024 году у типа-системного ЯП - оказывается, есть ломовые
>> проблемы с динамической линковкой,
> делали с прицелом на монолитное ядро. и они уже близко.Да вот - что-то 1 из 2 майнтайнеров "Rust for Linux" сдриснул цитируя "нетехнические моменты". Бардак и хаос в процессе разработки тулчейна, и его истошное костылирование кривой хтонью это и правда не столько технический, сколько манагерский факап. Управление проектом - в ауте. Не может хипстота с горящими глазами в ЭТО нормально.
>Да вот - что-то 1 из 2 майнтайнеров "Rust for Linux" сдриснул цитируя "нетехнические моменты".ничё, ничё. токсик диды не вечные. еще сами будуть бегать и просить вернутся когда на пенсию захотят 🤣
>>Да вот - что-то 1 из 2 майнтайнеров "Rust for Linux" сдриснул цитируя "нетехнические моменты".
> ничё, ничё. токсик диды не вечные. еще сами будуть бегать и просить
> вернутся когда на пенсию захотят 🤣С дела всей жизни - на пенсию как правило не хотят. И уж тем более не просят о таком "счастье". Это у тебя, ненавидящего свою работу и считающую это неприятной обязаловкой это - мечта. А для тех это - их хучший ночной кошмар.
Советским инженерам никто не объяснял, что можно сделать свое хобби - своей работой. И делать то что нравится - еще и получая за это деньги. А так то круто придумано, разве нет? Ну а если вам такая опция недоступна - вам можно только посочувствовать. Несчастные люди, в общм то - рабы.
>что можно сделать свое хобби - своей работой. И делать то что нравится - еще и получая за это деньгивот-вот. этим хоббиистам не следует забывать что они таки на работе и получают деньги за работу,
и от кого они эти деньги получают тоже.
> вот-вот. этим хоббиистам не следует забывать что они таки на работе и
> получают деньги за работу, и от кого они эти деньги получают тоже.Торвальдс получает деньги - потому что лучший в своем деле. И врядли это изменится в ближайшее время.
И не, это не та вакансия куда можно просто посадить васяна из-за ворот - и получить тот же результат. Как максимум роль потянут пару дружков Торвальдса, типа K-H. Но они от Торвальдса не сильно отличаются так то по взглядам.
...а компанию, если что, свободный человек может и сменить. И вот уж Торвальдсу все двери будут открыты.
>И не, это не та вакансия куда можно просто посадить васяна из-за ворот - и получить тот же результат.так никто и не спорит.
но и гугл/майкрософт не благотворительные организации>Торвальдс получает деньги
>И вот уж Торвальдсуа причем тут Торвальдс, если выпендривается совсем другой чел, а сам то Линус совсем не против.
> все что оно реально умело нормально - линковать 6-метровые хелловорлды на манер игогошкипроверил хеллоуворлд игогошечки: 1.4мб, и это full static, даже libc не требуется для работы
p.s. если надо меньше - upx приходит на помощь (он официально поддерживается), тут уже 612кб всего
>> все что оно реально умело нормально - линковать 6-метровые хелловорлды на манер игогошки
> проверил хеллоуворлд игогошечки: 1.4мб, и это full static, даже libc не требуется
> для работыЭто все круто, но САБЖ обычно имеет смысл в всяких ультра-минимальных системах. Типа опенврты какой, где каждый килобайт на счету. И таки - гошные бинари обычно libc таки импортят.
> p.s. если надо меньше - upx приходит на помощь (он официально поддерживается),
> тут уже 612кб всегоУх, да! Надо еще и RAM жрать - ибо это вообще на корню зарубает sharing памяти процессов и либ. Но в общем то по этой причине софт на игого в штуках типа openwrt где musl уместен - мягко говоря не в фаворе.
А системд так то и сам по себе для чего-то типа openwrt'шных мыльниц великоват и тяжеловат даже на сишке, если что.
И glibc с musl тоже нужно переписать на rust.Ведь у них фатальный недостаток.
Переписывать не надо )
https://github.com/redox-os/relibc
> Переписывать не надо )
> https://github.com/redox-os/relibcА системду они уже портировали? И что они вообще делают с тем фактом что у хруста динамическая линковка в полной дж@ппе? Там вон очень колоритный тредик на гитхабе.
И да, как вы там говорите? В хрусте нет UB? А там в треде написано нечто сильно другое: оказывается разные crate либ могут динамически линкануть 1 и ту же либу - только это будет UB. Вот прям так! Системщики, my аss...
Изначальный Rust надо переписать на Rust. Он имеет фатальный недостаток - придуман людьми, которые не знали Rust на момент его создания.
> Изначальный Rust надо переписать на Rust.Ты не поверишь, но уже))
Изначальный компилятор раста был на окамле. А потом переписали на раст (rustc).
Основной бекенд сейчас llvm (c++), но есть еще cranelift, который тоже написан на rust.
Не-не-не!
Я про компилятор. Я про сам язык.
Rust создавали люди, которые не знали Rust. А значит он ущербен сам по себе с точки зрения безопасности и функционала.
> Не-не-не!
> Я про компилятор. Я про сам язык.
> Rust создавали люди, которые не знали Rust. А значит он ущербен сам по себе с точки зрения безопасности и функционала.Хм.. СИ создавали люди которые в глаза видели только Би и PDP-11/20.
Значит ли что он "ущербен сам по себе"?ps твой вопрос настолько тупой, что я даже теряюсь в догадках, осознаешь ли ты этот факт или нет.
Похоже, кто то не может в сарказм и юмор. Совсем не может.)
> Ты не поверишь, но уже))
> Изначальный компилятор раста был на окамле. А потом переписали на раст (rustc).
> Основной бекенд сейчас llvm (c++), но есть еще cranelift, который тоже написан на rust.Теперь еще расскажите на чем там у вас линкер. Ибо без линкера вы бинарник сгенерить нормально таки - не сможете. И да, с этим судя по вон тому треду на гитхабе ЛОМОВЫЕ проблемы системного уровня. Вот прямо в 2024 году.
> Теперь еще расскажите на чем там у вас линкер.
> Ибо без линкера вы бинарник сгенерить нормально таки - не сможете.Насколько помню lld.
А чего спрашиваешь?> И да, с этим судя по вон тому треду на гитхабе ЛОМОВЫЕ проблемы системного уровня.
От того что ты напишешь КАПСОМ проблема не станет ломовой)
Там прямо указано как это решить и думаю в будущем это исправят.> Вот прямо в 2024 году
Да, прикинь.
Это же тебе не наовнячить код побыстрому, тут люди думают, а потом делают.
> Насколько помню lld.А это точно? Там случаем не gcc'шный ld окажется ненароком?
> А чего спрашиваешь?
Есть подозрения что он немного не на хрусте, что так, что сяк.
> От того что ты напишешь КАПСОМ проблема не станет ломовой)
Однако когда какая-то лабуда называет себя "системным яп" имеючи такие проблемы - это какой-то фуксией с игогошиками пованивает. С теми же перспективами проектов на этом, ага.
> Там прямо указано как это решить и думаю в будущем это исправят.
Ну вот когда исправят - тогда и приходите. А покамест там вообще - UB. Да, тот с которым вы боролись. И если ваши же пики точеные вам же в окорок и воткнут - нормуль? :)
> Это же тебе не наовнячить код побыстрому, тут люди думают, а потом делают.
А по синтаксису и не скажешь. Выглядит как куча костылей, если честно. Как и решение такого уровня проблем в 2024 году.
> А это точно? Там случаем не gcc'шный ld окажется ненароком?blog.rust-lang.org/2024/05/17/enabling-rust-lld-on-linux.html
статья за май, думаю сейчас уже перешли, но проверять мне лень> Есть подозрения что он немного не на хрусте, что так, что сяк.
А какая разница?
Вон шланг и ллвм написаны на плюсах.
Но зато как написаны opennet.ru/opennews/art.shtml?num=60707> Однако когда какая-то лабуда называет себя "системным яп" имеючи такие проблемы - это какой-то фуксией с игогошиками пованивает. С теми же перспективами проектов на этом, ага.
Ну как то СИ называют системным?
Язык у которого 2 числа сложит без UB невозможно.
Так что думаю и раст можно.> Ну вот когда исправят - тогда и приходите. А покамест там вообще - UB. Да, тот с которым вы боролись. И если ваши же пики точеные вам же в окорок и воткнут - нормуль?
Если бы ты читал доку раста (и понял ее) то ты мог бы заметить, что Раст стремится к отсутствию UB только в safe коде.
И у них это пока получается - в доке перечислен список потенциальных проблем в unsafe doc.rust-lang.org/reference/unsafety.html
Так что я согласен на пики в окорок, а тебе оставлю второй стул в гузно.> А по синтаксису и не скажешь. Выглядит как куча костылей, если честно.
Синтаксис это дело привычки.
Вон у гугла гошники и фортовики осиливают Раст за месяц-два.
Понимаю что для многих даже это невозможно, но мы же не будем на них ориентироваться.> Как и решение такого уровня проблем в 2024 году.
А есть предложения лучше?
Ну чтобы сложение 2 чисел не было UB в системном языке?
> blog.rust-lang.org/2024/05/17/enabling-rust-lld-on-linux.html
> статья за май, думаю сейчас уже перешли, но проверять мне леньЭто, конечно, замечательно - через 15 лет разработки у господ какой-то брейнфак в самых базовых вещах. Может, им поменьше хайповать и побольше пользоваться мозгом? Особенно на фазе архитектуры, которой в синтаксисе этой хрени вообще не замечено.
>> Есть подозрения что он немного не на хрусте, что так, что сяк.
> А какая разница?
> Вон шланг и ллвм написаны на плюсах.Ну вот такая. Крутой яп. Который не может сам себя обслуживать. В отличие от сей и плюсов.
> Ну как то СИ называют системным?
А у него нет проблем с динамической линковкой, внезапно.
> Язык у которого 2 числа сложит без UB невозможно.
> Так что думаю и раст можно.При том что профачены все мыслимые аспекты актуальные для именно системщины? Это называется wishful thinking :)
> Если бы ты читал доку раста (и понял ее) то ты мог
> бы заметить, что Раст стремится к отсутствию UB только в safe коде.Начались всякие отмазки. Но с вашим гнилым пиаром вам таки вами же наточеные пики в ваши же окорока сейчас и натыкают. И не то чтобы незаслуженно. Хайп на секурити вообще редко заканчивается чем-то хорошим для его обладателя. Ибо - вы не сможете обеспечить то что обещали.
> И у них это пока получается - в доке перечислен список потенциальных
> проблем в unsafe doc.rust-lang.org/reference/unsafety.htmlЯ такие же пасквили и для си могу почитать :)
> Так что я согласен на пики в окорок, а тебе оставлю второй стул в гузно.
Фига! Адепты садо-мазо, я вам нового адепта нашел! Забирайте в оборот!
> Синтаксис это дело привычки.
А также вопрос архитектуры - и ее отсутствия. В этом смысле авторы сишки по сути гении, сумели довольно много простым синтаксисом. А эти костылят тулчейн и синтаксис буквально постоянно, это очень далеко от "гении". Мягко говоря.
> Вон у гугла гошники и фортовики осиливают Раст за месяц-два.
Гугл уже успел показать успехи в системщине - в виде фуксии. Те и пошли осиливать - за свой счет уже в основном. И где гугл фортовиков вообще взял? Или вы про "все полтора"?!
> Понимаю что для многих даже это невозможно, но мы же не будем
> на них ориентироваться.Я пока не понимаю на что вон то ориентируется кроме хайпожорства. Но хайп закончится, а дальше что?
> А есть предложения лучше?
> Ну чтобы сложение 2 чисел не было UB в системном языке?Это то лечится пуском статических анализаторов. А вот UB с динамической линковкой... эээ...
> через 15 лет разработкиО! У нас тут свидетель 15 лет разработки!
> В отличие от сей и плюсов.
gcc пишут на плюсах как раз из-за убогости си.
llvm тоже на плюсах
На си остались только древние поделия, которым до "оптимизирующего компилятора" как до луны.> Начались всякие отмазки.
Хаха, отмазки. Просто хейтерочки с IQ комнатной температуры, которые не в состоянии осилить даже растбук, вначале придумывают что-то, а потом начинают доказывать что в расте этого нет или наоборот есть.
Плавали, знаем. Еще с версии 1.0 местные отбитые клоуны целые списки писали. Ты их опровергаешь примерами, а в следующей новости все тоже самое.> Но с вашим гнилым пиаром вам таки вами же наточеные пики в ваши же окорока сейчас и натыкают.
Но дырявость дыряшки это не отменяет. Благодаря нам весь мир узнал какое си дырявое омно. И если хочешь хоть какой-то безопасности - то держись от си подальше.
Даже если раст не взлетит, что уже вряд ли, но придет другой безопасный язык, который ее окончательно закопает - это будет уже шикарная победа.> Ибо - вы не сможете обеспечить то что обещали.
Утверждает анон с опенька. Который даже не знает что мы обещали. Ничего нового))
> Это то лечится пуском статических анализаторов
Ахаха! Ну ты даешь. А чего вы 30+ лет не запускали статические анализаторы?)) Даже хотя бы последние лет 15.
Все равно как не дырища в ядре - то overflow и за границы вышли, то размер буфера не смогли посчитать, то дважды переменную обнулили.Линтер ему поможет...
Вот целая куча дыреней в OpenSSL/LibreSSL www.opennet.ru/opennews/art.shtml?num=58622
- чтение из области вне границ буфера
- Use-after-free
- двойное освобождение памяти
- некорректное разыменование указателя
- разыменование указателя NULL (x2)
ну и еще одна логическая проблема, которая решается нормальными типами в нормальных языкахПри этом ворнинги включены, оба проекта обмазаны санитайзерами по самое немогу - и memory, и thread, и еще куча других github.com/openssl/openssl/actions/runs/4124496105 Там даже фаззинг какой-то есть.
И что?) Помогли, сынку, тебе твои анализаторы?) Как тогда они смогли собрать практически полное булщит-бинго?Не помогут вам линтеры. Вы просто необучаемые.
Даже Торвальдс недавно сказал что "прошло 33 года, а у нас проблемы с базовым мемори менеджментом"
> О! У нас тут свидетель 15 лет разработки!Да, я почему-то думал что сначала надо решать вон те проблемы, а хайповать - потом.
> gcc пишут на плюсах как раз из-за убогости си.
Однако до недавних пор его писали на сях.
> llvm тоже на плюсах. На си остались только древние поделия, которым до
> "оптимизирующего компилятора" как до луны.Ну как бы плюсы мощнее. Но они тоже со временем наслоения скелетов в шкафу огребли. Однако они как раз логичный путь апгрейда для сишников. А хруст - ни два ни полтора.
> Хаха, отмазки. Просто хейтерочки с IQ комнатной температуры, которые не в состоянии
> осилить даже растбук, вначале придумывают что-то, а потом начинают доказывать что
> в расте этого нет или наоборот есть.Да сами свой маркетинговый булшит читайте, пока этот кал даже линковку нормально разрулитьва не умеет, и это 15 лет спустя. Для меня это выглядит напрасной тратой времени пока. Может когда это и изменится, если господа придут в адекват и займутся делом вместо хайпа. Дельные идеи то в яп есть. Но на их месте я бы все же переархитектил синтаксис нахрен.
> Плавали, знаем. Еще с версии 1.0 местные отбитые клоуны целые списки писали.
> Ты их опровергаешь примерами, а в следующей новости все тоже самое.Не вижу куда вы там сплавали с этой фигней. Как максимум годится для апликушатины уровня игого, а когда что-то сверх того - вон фуксики и приплыли как раз к логичному финалу.
> Но дырявость дыряшки это не отменяет. Благодаря нам весь мир узнал какое
> си дырявое омно. И если хочешь хоть какой-то безопасности - то
> держись от си подальше.Ну вот и не запускайте кернелы на сишке. Редоксом вон пользуйтесь! :). Заодно посмотрим сможете ли вы коментить хотя-бы на опеннет, чтоли.
> Даже если раст не взлетит, что уже вряд ли, но придет другой
> безопасный язык, который ее окончательно закопает - это будет уже шикарная победа.Ну, блин, говорить гоп не перепрыгнув это прекрасно, но попахивает 70 годами строительства коммунизма уж очень. А поттом фигакс, капитализм! :)
>> Ибо - вы не сможете обеспечить то что обещали.
> Утверждает анон с опенька. Который даже не знает что мы обещали. Ничего нового))А таки я вашу "экспертизу" и ее уровень чувствую. Дальше цитирования маркетингового булшита вы ни на что не способны. И понимания как это работает у вас нет. Хайпонашка с пустым мозгом.
>> Это то лечится пуском статических анализаторов
> Ахаха! Ну ты даешь. А чего вы 30+ лет не запускали статические анализаторы?))Того что 30+ лет назад - диды были такие же раздолбаи, как вы сейчас. И примерно так же про безопасность вещали, внезапно. Если вам повезет, и вы не помрете, через 30 лет почитаете это же самое - про себя! :)
> границы вышли, то размер буфера не смогли посчитать, то дважды переменную обнулили.
Так что вам не дает пользоваться безопасным редсдохом? :)
> Вот целая куча дыреней в OpenSSL/LibreSSL www.opennet.ru/opennews/art.shtml?num=58622
Да там такие обезьяны с гранатой что им, имхо, даже на питоне хорошо не будет. Хотя не, почему, eval() они где-нибудь впихнут исправно.
> ну и еще одна логическая проблема, которая решается нормальными типами в нормальных языкахЖаль что UB с линковкой ими не решается, а при этом остальное уже не так уж и важно. Есть такая фигня - приоритеты. А хрустики полируют ботинки - при том что суперценный окорок вообще совсем без штанов. И толку с начищеных ботинок, если панталоны на огородном пугале - дают вам фору?
> При этом ворнинги включены, оба проекта обмазаны санитайзерами по самое немогу -
Это ему не поможет. Там с общей квалификацией кодеров проблемы. Я за то чтобы их на хруст согнать, и посмотрим на эту вашу безопасность. А, вы уже что-то там вещаете про то что гарантии только на safe? Ну это не страшно, вон те господа вам отлично репутацию сольют. А мы им поможем, ибо самое приятное в техдолге - это его возврат! :)
> Не помогут вам линтеры. Вы просто необучаемые.
> Даже Торвальдс недавно сказал что "прошло 33 года, а у нас проблемы
> с базовым мемори менеджментом"А у вон тех через 15 лет проблемы с динамической линковкой и UB. Так и живем. Каждый год кто-то носится с серебряными пулями. Каждый год оказывается что материал пуль немного приукрасили.
> Однако до недавних пор его писали на сях.Ага, а начинали вообще с волосатого паскаля.
И что? Это просто еще раз показывает что дыряшка дно - пришлось переползать хотя бы на плюсы.> Ну как бы плюсы мощнее. Но они тоже со временем наслоения скелетов в шкафу огребли. Однако они как раз логичный путь апгрейда для сишников. А хруст - ни два ни полтора.
Мощнее в чем? В кол-ве init'ов))?
Forrest Gump learns C++.gif> Да сами свой маркетинговый булшит читайте, пока этот кал даже линковку нормально разрулитьва не умеет, и это 15 лет спустя. Для меня это выглядит напрасной тратой времени пока.
Хахаха, так ты никто и на твое мнение всем плевать.
Ты можешь пользоваться или идти на Хурд.
Ну или сделать форк и переписать как тебе угодно - синтаксис сделать лучше.
Вон Crab какой-то был, да вроде протух.> Ну вот и не запускайте кернелы на сишке. Редоксом вон пользуйтесь! :).
Неа, мы лучше кернел перепишем)
Заодно дидов в дом престарелых отправим.> Того что 30+ лет назад - диды были такие же раздолбаи, как вы сейчас. И примерно так же про безопасность вещали, внезапно. Если вам повезет, и вы не помрете, через 30 лет почитаете это же самое - про себя! :)
Может быть.
Но что-то с этим надо делать. Например лупить компилятором по корявкам, которыми овнокод пишут.> Жаль что UB с линковкой ими не решается, а при этом остальное уже не так уж и важно.
Да, конечно, линковка это самое важное.
Можешь про это написать еще 100 раз)> А, вы уже что-то там вещаете про то что гарантии только на safe?
Если бы у тебя был могз, то ты бы знал что гарантии всегда были только в safe.
> Ну это не страшно, вон те господа вам отлично репутацию сольют. А мы им поможем, ибо самое приятное в техдолге - это его возврат! :)
Ну пока ты тут носишься только с линковкой и обсираешься.
Но поживем увидим.> А у вон тех через 15 лет проблемы с динамической линковкой и UB. Так и живем. Каждый год кто-то носится с серебряными пулями.
Ну проблема пока только у тебя. Другим разработчикам все ок.
> Каждый год оказывается что материал пуль немного приукрасили.
Даже пуля из железа будет лучше чем из овна.
>А по синтаксису и не скажешьТакой же уродливый, как и си. А ведь могли сделать красивым, как Ocaml
>А это точно? Там случаем не gcc'шный ld окажется ненароком?пора бы тебе знать, дружочек, что у gcc нет своего линкера. они всю дорогу пользуются линкером из GNU Binutils.
Хм... А когда перепишут без шимов и прослоек типа minigw для WinAPI/СОМ+?
w/o PWM ?>прослоек типа minigw для WinAPI/СОМ+?
Вам systemd для Винды? Поттеринг работает над этим...
> w/o PWM ?
>> прослоек типа minigw для WinAPI/СОМ+?
> Вам systemd для Винды? Поттеринг работает над этим...Таки, похоже, майкрософт серьезно намылился на Linux перейти. Представляете себе морды проприетарщиков если им такую шляпу сгрузят в очередной винде? Скажут "нам лениво писать ведро и драверы, сгрузим на вон тех!". А какоенить NT API они никому и не обещали официально! :)
Azure Linux уже сушествует
То есть по сути glibc представляет собой вендролок с рядом спорных технических и идеологических решений. Но "хейтеры systemd" и свидетели NIH-синдрома естественно пытаются это заболтать, превратить тему в помойку.
> То есть по сути glibc представляет собой вендролок с рядом спорных технических
> и идеологических решений. Но "хейтеры systemd" и свидетели NIH-синдрома естественно попытаются
> это заболтать, превратить тему в помойку.Когда у фанатиков системды нет против грамотных "хейтеров systemd" аргкментов, они начинают кричать про наличие "хейтеров systemd" и про забалтывания, превращая тему в помойку, зачастую заранее, когда никаких хейтеров ещё и нет, упреждающий удар, когда-предстоит-драка-бей-первым-style! xD
Вот специально взял "хейтеры systemd" в кавычки, но кому-то когнитивная слепота помешала их разглядеть и заставила выдать машинальную реакцию.А почему ты не захотел обсудить вендорлок glibc? systemd ведь вендорлок.
> Вот специально взял "хейтеры systemd" в кавычки, но кому-то когнитивная слепота помешала
> их разглядеть и заставила выдать машинальную реакцию.
> А почему ты не захотел обсудить вендорлок glibc? systemd ведь вендорлок.Потому что мне нравится когда ты нелепо оправдываешься, а не вестись на поводу того что ты предлагаешь. ;)
>> Вот специально взял "хейтеры systemd" в кавычки, но кому-то когнитивная слепота помешала
>> их разглядеть и заставила выдать машинальную реакцию.
>> А почему ты не захотел обсудить вендорлок glibc? systemd ведь вендорлок.
> Потому что мне нравится когда ты нелепо оправдываешься, а не вестись на
> поводу того что ты предлагаешь. ;)Я не предлагал тебе влезть с бестолковым комментарием, а спрогнозировал, что забалтывание вопроса произойдёт:
"Но "хейтеры systemd" и свидетели NIH-синдрома естественно пытаются это заболтать, превратить тему в помойку."
дядька, когда я в шеллскрипт насовал кучу башизмов, это вендорлок баша или мои кривые руки?
Вендорлок. Потому что если бы баш этого не позволял ты бы так не написал.
А если я насовал в Python-скрипт кучу питонизмов, это вендорлок Питона или мои кривые руки? ;)
> А если я насовал в Python-скрипт кучу питонизмов, это вендорлок Питона или
> мои кривые руки? ;)Там еще в каждой версии - свой, отдельный, маленький вендорлок. Иерархия вендорлоков в природе, однако.
> дядька, когда я в шеллскрипт насовал кучу башизмов, это вендорлок баша или
> мои кривые руки?Я не баш-программист, что бы давать экспертную оценку. Разделяю мнение одного знакомого, что лучше бы в Linux командным интерпретатором был Perl. Тогда бы заметно отличалось от Windows. ;)
Это не вендорлок, а зрелость, которая диктует делать быстро и достаточно хорошо, а не бороться с ограничениями POSIX sh ради гипотетической поддержки полутора архаичных систем, где твой код никогда в жизни не будет выполняться. Если так сильно не хочешь расстраивать маму и бабушку, пиши явно в зависимостях bash и используй суффикс .bash в названиях файлов вместо .sh.
glibc - нарушение спецификации из коробки, хоть и с возможностью приведения к соотвествию.
а systemd - это результат подзапоздавшей "крепкой руки" freedektop и отсутствия спецификации.
например, вместо условно org.freedesktop.ResolverService, мы на шине имеем io.systemd1.resolve(иль что то такоеч не помню уже).
что как бы ломает всю концепцию dbus целиком, ибо механизмов апкаста нет и заставить io.systemd1.resolve предоставлять org.freedesktop.ResolverService нельзя.
ровно, как и заместо обращения в условный /run/System/UserSessions, gnome-shell лазает по /run/systemd/ЧтоТоТам/sessions.
> например, вместо условно org.freedesktop.ResolverService, мы на шине имеем io.systemd1.resolve(иль
> что то такоеч не помню уже).В случае системды вообще весь d-bus так то - опциональщина. И по минимуму он работает совсем без dbus в системе. И уж тем более услуги его ресольва что-то там - в том же дебиане networkd зачастую даже и не ставить можно, не говоря о том что ничто не требует запускать это.
Я пользуюсь системд - но не нетворкд. И эти проблемы меня определенно забавляют. А если какой-то левый софт на кривые интерфейсы дбаса завязан - с ним горя будет что так что сяк. Дбас вообще весьма так себе штука, он даже рестартануть без реебута всей ос не в состоянии.
>В случае системды вообще весь d-busв чате "ру тех. поддержки sd" человек рассказывал, что после падения dbus, система почти целиком встает.
насколько правда - не уверена, на системах без графики, dbus у меня еще не падал на системах с sd.
>Дбас вообще весьма так себе штука, он даже рестартануть без реебута всей ос не в состоянии.вполне себе штука.
но, судя по всему, когда его разрабатывали, полагали, что в системе будет только 1 провайдер конкретной службы и все интерфейсы пропишет freedesktop .. а в результате у нас io.systemd1.
зачем может понадобиться рестартать dbus, мне не ясно, при проблемах с шиной, reload достаточно.
>>В случае системды вообще весь d-bus
> в чате "ру тех. поддержки sd" человек рассказывал, что после падения dbus,
> система почти целиком встает.Это возможно даже правда. Если dbus уж был, sd им будет пользоваться, и dbus сам по себе - очень кривая штука. И да, если он упадет - он не может корректно рестартануть. Ну вот такие гении dbus писали. Системд тут "виноват" в основном тем что пользуется этим.
В свое время была иниицатива сделать другую системную шину. При том - подперев ядром. Это кстати было бы удобно - ибо у ядра есть с дюжину интерфейсов от ioctl до sysfs/procfs/configfs/прочие *fs, netlink нескольких видов, uevent, ... в общем за годы знатный бардачелло отрос. При том в большей части интерфейсов нет энумерации.
Ну то-есть кидая условный ioctl вы вообще понятия не имеете, умеет так система или нет, вы его просто фигачите, и молитесь чтобы это сработало. Получить априорное знание capabilities этой системы, с этим ядром? Не, что вы, как можно. Это не фича интерфейса.
Но увы, заглохло это дело. Ибо делали юзермодовые редхатчики, ядерщики волком смотрели на то что получилось, и самопальный модуль, и таки в майлайн не попало. Хотя какой-то унифицированый интерфейс, с подпором кернелом и кернелом как один из bus talkers, имхо, пригодится бы.
> насколько правда - не уверена, на системах без графики, dbus у меня
> еще не падал на системах с sd.А таки - sd можно запускать на системах где dbus вообще совсем не установлен. Тогда и той проблемы нет. Если dbus нет - он не может упасть, sd на него и не уповает тогда.
>>Дбас вообще весьма так себе штука, он даже рестартануть без реебута всей ос не в состоянии.
> вполне себе штука.Увы, у него довольно много кривостей и глупостей в реализации. Настолько что см выше, пытались переделать менее криво, но - увы - не срослось.
> но, судя по всему, когда его разрабатывали, полагали, что в системе будет
> только 1 провайдер конкретной службы и все интерфейсы пропишет freedesktop ..
> а в результате у нас io.systemd1.Ну вот там тупняки есть. Хотя коронный тупняк это то что рестарт брокера по нормальному ну вот не предусмотрен.
> зачем может понадобиться рестартать dbus, мне не ясно, при проблемах с шиной,
> reload достаточно.Ну мало ли - упал он, или кильнули случайно, обновили его пакетником, или что там. Даже sd сам по себе - может сам себя re-exec после апдейта, сделав сериализацию состояния, стартанув новый себя и де-сериализовав состояние, так что - вот обновленный SD без ребутов ОС. А на dbus такая благодать не распостраняется. И это позор. В целом кривость оного сподигла пару альтернативных реализаций брокера так то.
> glibc - нарушение спецификации из коробки, хоть и с возможностью приведения к
> соотвествию.Какой именно?
Вот Musl - "нарушение". Статическая линковка запрещена Linux Standard Base Core Specification for X86-64, Table 7-1 Non Conforming Instructions не допускает syscall в приложениях.
POSIX, общемировой.
что там в линуксе напридумывали - исключительно проблемы линуксоидов, имхо.
> POSIX, общемировой.
> что там в линуксе напридумывали - исключительно проблемы линуксоидов, имхо.Как раз для "линуксоидов" с этим проблем не вижу. Например, я использую mremap() по полной; проблема возникнет у желающих перенести код в другую ОС (другая -- это не Windows, где есть NtMapViewOfSection и прочее).
А вот если я делаю (свобода же!) замену glibc - тогда оно "не соответствует" LSB (как и в влучае с Musl из новости). Таким образом получается вендорлок.
>зачастую заранее, когда никаких хейтеров ещё и нет, упреждающий удар, когда-предстоит-драка-бей-первым-style!Вот у растоманов точно такой же подход. Превентивно вспоминают про "военов супротив Раста".
> Вот у растоманов точно такой же подход. Превентивно вспоминают про "военов супротив Раста".Эээ?
Обычно если в какой-то теме типа
"во всех дистрибутивах линукс уязвимость с получением рута, по причине того что умственно отсталый б-ло-кодер не смог посчитать размер буфера",
написать простой и невинный коммент, например "типи-кал СИшка", то сразу начинают вспоминать раст (хотя ты про него вообще слова не сказал).
И какая-то агрессия сразу проявляется.
Вам никто не мешает создать свою C библиотеку.
Вам никто не мешает форкнуть GLibC в сво. C библиотеку.
Вам никто не мешает стать мейнтейнером GLibC, если вы сможете доказать свою пользу проекту.
Вам никто не мешает вырастить животных и из шкур сделать себе шубы собственноручно.
Вам никто не мешает из руд выплавить нужные вам металлы.
Вам никто не мешает собственноручно построить дом из собственноручно созданных материалов.
Только так вы можете принести пользу человечеству.)
> Вам никто не мешает вырастить животных и из шкур сделать себе шубы
> собственноручно.
> Вам никто не мешает из руд выплавить нужные вам металлы.Все зависит от условий. Дебиану не нравилось что glibc делал - они и делали свой eglibc. А если вас производитель шуб стал считать за лопуха и разводить как кроликов - ну вот и выбирайте, хотите вы делегировать эту задачу на этих условиях вон тем - или нафиг? Вопрос то - в соотношениях.
> Вам никто не мешает создать свою C библиотеку.
> Вам никто не мешает форкнуть GLibC в сво. C библиотеку.
> Вам никто не мешает стать мейнтейнером GLibC, если вы сможете доказать свою
> пользу проекту.Какой-то набор мантр.
Вообще-то, новость о том, что systemd не собирается со "своей Си библиотекой" и потребовала доработки.
>Но "хейтеры systemd" и свидетели NIH-синдромаВот не пойму, кого ты этой фразой имел ввиду: которые за красных, за белых?
Имел ввиду, что в контексте данной новости отношение к systemd не важно. Важнее, что это один из ключевых компонентов ОС, и требует glibc. Распространённость systemd помогла найти заинтересованных, потому адаптировали и под Musl. В случаях с другим ПО рядовой майнтайнер дистрибутивов вряд ли справится, если не найдёт готовых патчей.
> То есть по сути glibc представляет собой вендролок с рядом спорных технических
> и идеологических решений. Но "хейтеры systemd" и свидетели NIH-синдрома естественно пытаются
> это заболтать, превратить тему в помойку.Если так рассуждать, то, в принципе, почти что угодно является - вендорлоком.
В каких-нибудь BSDшных libc - уникальные для них функции, которая не часть какого либо стандарта на тот момент - были много лет назад. Является это вендорлоком?
Если копнуть libc типа msvcrt* - то там уникальных для этого вендора функций более чем. Это тоже в каком-то роде вендорлок.
Да что там, если сабжевый libc хорошенько изучить - там тоже каких-нибудь функций за пределами стандарта пожалуй - окажется.
Тут на самом деле факап наполовину в стандартах: они очень сильно "lag behind". И получается что системщину одним только стандартным libc и стандартным C - ну вот такое себе весьма. Если вообше.
А я не так рассуждаю, как мне приписывается. systemd для Linux, а не для BSD. systemd требует glibc. Почти 10 лет ушло на адаптацию.
> А я не так рассуждаю, как мне приписывается. systemd для Linux, а
> не для BSD. systemd требует glibc.А софт для BSD требовал либо функции в libc, либо добавочные либы. По тем же причинам. Так что это довольно древний вид спорта так то. Более того - часть этого даже со временем бывает втягивают в новую версию стандарта. Но, конечно, сильно опосля.
> Почти 10 лет ушло на адаптацию.
КМК оно просто не сказать что сильно кому-то надо было. Ну никто и не спешил.
Например, могла бы быть некая linux.so - шлюзы для вызовов ядра, плюс мелочи для удобств. glibc могла бы предоставлять требуемое стандартом и быть опциональным компонентом. Но нет, GNU is Not Unix, где каждая программа делает одно и делает это хорошо.
> Например, могла бы быть некая linux.so - шлюзы для вызовов ядра,А это все зачем? Есть стандартный libc для этого. Если кто хочет сильно нестандартного он может syscall() сам забацать. То что в нее нестандартных фич напихали бонусом к стандарту, второй вопрос. Так и другие делали, и BSD, и винда, и даже андроид какой-нить с bionic своим. Glibc точно не выервый кто до этого допер.
Залезать в сильную специфику конкретной ОС надо не так уж много кому. И это как правило махровая системщина. Systemd - махровая системщина. Он юзает 100500 фич специфичных для Linux, и никогда и не собарался быть сам по себе портабельным. Если это кому-то надо, им придется, вероятно, либо вывесить dummy затычки, которые реально не работают - ну, если у вас в ОС нет seccomp, а в юните указана изоляция юнита оным, то чего? Вы можете либо обломаться, либо соврать что типа-сработало, хотя оно конечно не. А какие еще опции есть? Musl в целом - достаточно недоразвитая либа, опять же.
А линух понимает стандарты веьма расширено если что. Скажем можно ставить разные приоритеты тредам 1 процесса. Не совсем по POSIX зато можно что-то осмысленное делать.
Или uart'у можно выставить не только фиксированые бауды, но и произвольный, и если драйвер умеет - оно будет. Поэтому FTDI'ка заводится на своих 3 000 000 битов. А вот попробуйте это в какой-нибудь немолодой BSD вообще запросить?! Будете на своем B115200 пехать, подумаешь, в 20+ раз медленнее...
> плюс мелочи для удобств. glibc могла бы предоставлять требуемое стандартом и быть
> опциональным компонентом.А она и представляет - superset стандарта. Крмое стандарта есть - extras. На которые некий софт, вот, уповает. А musl - минимальный, и там этого ессно быть не обязано. Системщина часто вылезает за пределы стандартов.
Если посмотреть man 2, там довольно много чего "conforms to - this feature is Linux specific". У линукса давно есть интерфейсы за пределами стандартных. Парился ли musl этим - вопрос сильно отдельный.
> Но нет, GNU is Not Unix, где каждая программа делает одно и делает это хорошо.
Эти самые юниксы - померли нахрен. И то как работал sysv init в моем понимании уж точно хорощим не было, особенно по сравнению с sd.
"она уже достаточно стабильна и демонстрирует трёхкратное сокращение времени загрузки, по сравнению с использованием OpenRC"Эпопея с systemd циклически повторяется. А помните, вот так вот и начинался звездёжь про systemd? ))
К слову, сравнивал системы на systemd где можно было относительно беспроблемно поставить openrc, так вот с openrc загружалось быстрее. ;)
такой же результат на десктопе(был дебиан, поставила альпайн).к слову, после обновления до 11го дебиана с sd рабочих компов, некоторые зависали на какое-то время при выключении, некоторые тупо не грузились.
после переустановки с сохранением /home, оно заработало, но выключалось так же медленно.
это хоть и лучше, чем было с sysv, но почему у всех так глазки горят с опенрц слезть ..
умеет то же самое; с нативными сервисами ( т.е. не шелл-скриптами, а теми самыми "сервисами в пару строк в декларативном стиле", коими так хвастал поттеринг, через openrc-run ) грузится даже быстрее, чем systemd и раза эдак.. в 3 быстрее, чем со скриптами, ибо, как выяснилось после настройки tomoyo на дестопе, вместо того, что б дергать каждый раз 100500 скриптов, 1 процесс openrc-run проходится по всему init.d; менеджмент сервисов, аля "тут - с завода, тут - юзер покрутил, там - временные" сделать так же легко, как в sd, во время сборки передается RC_SERVICE_PATH, в котором по дефолту {/usr/local, /usr}/etc/init.d и RC_CONF_PATH, с теми же путями, но для conf.d; в настройку параметром cgroups умеет, в авторестарт и прочее тоже умеет через стандартный супервизор; уже даже юзерский инстанс пилят.
я даже с чем-то типо mount-сервисов эксперементировала, кстати.
тип, лежит /etc/init.d/.mount. , делаешь симлинк /etc/init.d/.mount. -> mount.MyMount, пишешь в /etc/conf.d/mount.MyMount набор директив(вроде тогда все взяла из sd.mount, переделав в snake-case и немного поменяв имена), потом rc-service mount.MyMount start и оно работало.
даже генератор с fstab был, который на sysinit генерил сервисов, конфигов им, ложил в /run/{init,conf}.d (из /usr/local/etc/{init,conf}.d туда сделала симлинки, ибо мне было перекомпилировать openrc), добавлял новоприбывшие сервисы во, вложенный в boot, ранлевел mounts и перегружал список зависимостей, после чего все монтировалась на boot. если при выключении ничего не менялось, он их ложил в /etc из /run и при старте уже не трогал до того момента, как при выключении опять будут изменения.
и оно тоже работало!
man сделала даже, первый раз был, когда писала man'ы.
по сравнению со стандартным localmount, оно отрабатывало быстрее, ибо все монтировалось и размонтировалось параллельно. при том, система зависимостей для других сервисов не ломалась - был shim-сервис, который убеждался, что ранлевел mounts запущен и предоставлял localmount.
но потом у меня кончился отпуск и как бы все, стало некогда.
> но почему у всех так глазки горят с опенрц слезть ..Потому что молодняк тупо не умеет не во что, кроме как плакаться и попрошайничать готовые юниты к системде, запуганные мифами про душные длинные инопланетные партянки на баше, которые до седых йаиц никому не разгрести.
Зато теперь ходим строем под песенки краношляпы с подачи засланного из M$ казачка и в освободившееся время льём ушаты гoвeн на тех, кто не такой как мы.
имхо, не хватает опенрц "маркетинга", адекватных манов и подачи этих фишек.
как минимум, сейчас почти везде используется ini, json и имена в паскальной нотации, в то время, как openrc использует кебабскую и вместо безопасного чтения, делает source на файлы(т.е. исполнение рандомного кода через конфиг без MACa - как здрасьте).
+ после изучения кода, стало как-то грустно, ибо комбинирование С с шеллом приводит к.. к какой-то фигне. например, мы дергаем отдельный бинарь, тратим время на форк (а это реально много, даже в случае с dash и подобными) ради вывода сообщения "то-то - стартует", вместо переписывания небиблиотечной части einfo на шелл и делания этого обернутым printf(который в большинстве случаев встроенный) с ansi-кодами в функцию или лучше, в алиас(ибо функции в шеллах где-то 20% замедления дают).
вообще вот этого не понимаю, как и awk, sed, прочих .. смысл дергать доп. бинарь, заморачиваться с разными его реализациями, когда можно использовать встроенную утилиту, получив тот же эффект?
вещи-то элементарные, а прирост будет разительный.
еще есть косяки и неоптимизированные моменты в самом openrc-run. что как бы тоже критично.
вообще, я это все сделать сама хотела, но на гитхабе зарегаться так и не вышло (после регистрации - аккаунт не доступен), а через багтрекер дебиана особо большие изменения в апстрим не прокинешь.
>[оверквотинг удален]
> функции в шеллах где-то 20% замедления дают).
> вообще вот этого не понимаю, как и awk, sed, прочих .. смысл
> дергать доп. бинарь, заморачиваться с разными его реализациями, когда можно использовать
> встроенную утилиту, получив тот же эффект?
> вещи-то элементарные, а прирост будет разительный.
> еще есть косяки и неоптимизированные моменты в самом openrc-run. что как бы
> тоже критично.
> вообще, я это все сделать сама хотела, но на гитхабе зарегаться так
> и не вышло (после регистрации - аккаунт не доступен), а через
> багтрекер дебиана особо большие изменения в апстрим не прокинешь.А вам на ум не приходило, что проблема "небезопасности" каких-либо портянок это проблема рукопопости составителя портянок, а решением её должно было быть повышение грамотности составителей портянок, а не ональное огораживание в блоботу и лишние абстракции с нагромождением лишних сущностей, дабы меньше было понятно что там в потрохах, при повышении сложностей и дополнительных точек отказа, но чтобы любок мaкaк мог бездумно жмакать там, где доселе его на пушечный выстрел к взаимодействиям с этой частью системы не подпускали?! )
Проблема не только в "небезопасности".
А том что каждый камак-башпортянщик лепит какую-то свою особенную конфигурацию.
И когда приходит другой одмин, ему вначале нужно разобраться что наомнячил коллега, а потом только исправлять.Вместо этого появился стандарт, с которым разобраться и легче, и и только один раз.
Потому что у бизнеса нет времени на такие разбирательства.
Камаки-портянщики конечно расстроились. Исчезла незаменимость и появилась заменяемость... так и уволить могут!
Но туда им и дорога))
Так не надо воровать чужое издание , они даже не догадываться на сколько все сложно/зависимо шаг в лево и конец великого ммм
так "стандарт" был 100 лет в обед, у openrc чуть ли не с самого начала был openrc-run. потом новый супервизор ему добавили в качестве бекенда.
не поняла, что вы хотели сказать.
я не говорю, что шелл - плохо.
я говорю, что "дидам" пора завязываиь делать 100500 форков
>А вам на ум не приходило, что проблема "небезопасности" каких-либо портянок это проблема рукопопости составителя портянок, а решением её должно было быть повышение грамотности составителей портянок, а не ональное огораживание в блоботуКакие блобы - код systemd открыт, нет никаких блобов. И да, проблема баш портянок - это проблема существования такого уродливого инструмента как баш. Костыли из grep, sed, awk, проблемы даже с массивами(sic!), не говоря про словари и более сложные типы данных, и вечная порнография с экранированием, грозящая проникновением злобных хакеров, плюс ужасающий синткасис в виде if fi, case esac, всякие однобуквенные флажки, которые забываются, если не писать их каждый день.
"проблема плохого кода на питоне/расте/джаве - это существование такого уродливого инструмента, как питон/раст/джава"
лол.
>проблемы даже с массивамикакие у Вас проблеиы?
>Костыли из grep, sed, awk,это вовсе ничего общего с башем не имеет. особенно, если мы говорим конкретно о баше, а не любом посикс-шелле.
>грозящая проникновением злобных хакеровгрозят Вам проникновением Ваши руки, растущие.. судя по всему, не из плеч.
>забываются"я забыл, как использовать тернарники в С#, но виноват злой микрософт, а не я"
Ну, вообще как-то даже странно сомневаться в том, что проблемы "плохого кода на python'е" - в ОЧЕНЬ большой степени проблема именно что "плохого изначального дизайна" языка и попыток этот самый дизайн улучшить.
Да и скажем NPE в java'е - это вот оно и есть.
А bash с его "экосистемой" по современным представлениям о яп(с)ву - "одна большая проблема" и есть.
>экосистемойвся экосистема описана в man'е.
на самом деле, можно довольно большие скрипты писать и даже довольно производительные, отказавшись от использования сторонних утилит и коммандной подстановки.
точно так же можно и в случае с посикс шеллом.
как мне кажется, главный прикол его именно в стандартизации.
если Вы напишете скрипт для питона или программу на cs - Вы повисните на их рантайме.
в случае же с чистым шеллом - он есть в posix и Окнах. и все, на чем Вам придется зависеть - это вещи для "основной функциональности", например, в случае генератора uki - objcopy(binutils/llvm), sbsign/peutil.
по сути, так же, как и в случае с питоном(у него, если что, 90% подобного функционала на себя берут С-либы) или, например, иногда, go(продолжая пример с генератором uki: sbctl, довольно известная программа, точно так же зависет на objcopy, да еще и исключительно gnu-версии).
разница в том, что на шелле нормально писать сложнее, ибо банально неразвитая экосистема.
у меня, например, сейчас есть довольно большая либа под posix sh и препроцессор, уже не просто добавляющих функций, а довольно сильно меняющий синтаксис. и такой код уже кратно быстрее обычного: на выходе коммандной подстановки нет и сторонних вызовов нет.
у функций при этом 4 способа обмена информацией:
1. код выхода(может быть только 1/0)
2. значение(которое в обычных скриптах летит в stdout, после чего перехватывается через $() в форкнутом шелле).
3. stdout/stderr(оно юзеру летит).
вообще, уже готово много всякого,
но это все пока в разработке, код в закрытой репе.
4. исключения(для более подробной информации о причине еденичного кода).
в планах так же 3 "бэкенда":
MSIL, sh и кастомный рантайм(который я сейчас пишу).
но это пока все в разработке, код в закрытой репе.
когда будет готово, код выложу, может, новость тут напишу даже.
>>экосистемой
> вся экосистема описана в man'е.
> на самом деле, можно довольно большие скрипты писать и даже довольно производительные,
> отказавшись от использования сторонних утилит и коммандной подстановки.Уф. Так если-б проблема в "производительности" была...
Полбеды, что оно хрупкое by design (plaintext, однако) - так оно еще и необслуживаемое в большинстве случаев, а "на сладкое" у тебя будет 33 ведра legacy в котором здесь у тебя "-c" - command, там - comment, а тут вот и вовсе config, запомните-это-дети-патамучта-понять-это-невозможно!
Не то, чтобы на нем _нельзя_ было писать хорошие, быстрые, long-maintained программы - можно, и даже пишут - просто делать это сложнее-и-дороже, чем практически на всем остальном, что приходит в голову.
Как-то так.
>если Вы напишете скрипт для питона или программу на cs - Вы повисните на их рантайме.Соберите программу статически, будет вам один бнарник, который можно будет просто скопировать.
>вся экосистема описана в man'е.Вто время, когда у условного ocaml в экосистеме есть куча всего, типа библиотек для tui, многопоточности, парсинга всевозможных форматов топа html, библиотек для работы с сетью, работы с ошибками, то что есть у баша? Напишите на баше граббер,который рекурсивно в многопотоке сканнирует сайт, обрабатывает ошибки и выводит результат в виде html.
>>проблемы даже с массивами
>какие у Вас проблеиы?Вы видимо никогда на баше сложные скрипты не писали, поскольку иначе очень быстро столкнётесь с ситуацией, когда очевидный код является неправильным, а правильный код - неочевидным. Вот, например https://www.shellcheck.net/wiki/SC2207. И подобных примеров - навалом, один факт существования shellcheck чего стоит
>это вовсе ничего общего с башем не имеетЛюбой другой вариант, хоть перл, хоть пхп, хоть питон из коробки даёт поддержку регулярных выражений, а так же работу машинночитаемыми данными типа json. В старых баш портянках даже из xml данные будут выковыривать с помощью данного набора утилит, и малейшее изменение форматирования и код разламывается.
>"я забыл, как использовать тернарники в С#, но виноват злой микрософт, а не я"Тернарные операторы - это зло, поскольку любой нетривиальный код с ними превращается в нечитаемую кашу. Правильную реализацию можно посмотреть в любом функциональном языке, где if является выражением, а не инстуркцией. Так что мелкософт действительно злой.
>Вы видимо никогда на баше сложные скрипты не писалиВы, видимо, писать не умеете.
исходя из ссылки Выше, именно такие выводы и получаются.
работа граммера и расширение с массивами прописаны в posix, довольно подробно.
прочитайте один раз абзац и больше не будете с таким сталкиваться.
>В старых баш портянкахидите и расскажите их авторам.
xml разбирать средствами чистого шелла пока не приходилось, json - вполне. и ничего сложного в этом нет. работает, при том, быстро.>Тернарные операторы - это зло
а вот Вы - код на cs точно не писали и похоже, даже не видели :)
>работа граммера и расширение с массивами прописаны в posix, довольно подробно.
>прочитайте один раз абзац и больше не будете с таким сталкиваться.Вы так говорите, словно у меня никаких других дел нет, кроме как помнить как там безопасно в баше с массивами работать, к тому же кросплатформенно, чтобы ещё и на всяких маках запускалось. Когда регулярно используется хотя бы три разных языка, то чтение костылей в очередном языке крайне напрягают, ведь нигде кроме баша таких проблем нет.
>xml разбирать средствами чистого шелла пока не приходилось, json - вполне. и ничего сложного в этом нет. работает, при том, быстро.Код в студию. Только давайте чистый баш, без всяких jq и аналогов
>а вот Вы - код на cs точно не писали и похоже, даже не видели :)Даю вам подсказку - первая же проблема это ассоциативность оператора, вторая - форматирование. И если в тернарном операторе прописать хотя бы три условия, то это будет нечитаемо.
> с подачи засланного из M$ казачкаФанаты MS Лёню называют засланным казачком IBM, Debian и лично от Патрика (интересно, его приплели потому, что он Бохх?) в стан MS, чтобы он заменил все сервисы MS опенсорсными. Они ссылаются на то, что якобы уже есть сборки винды с SystemD для управления сервисами."Кто-то где-то знает когол-то, кто знает кого-то из тестировщиков винды, которому стало плохо от systemd на винде." - в общем, "ОБС информирует со ссылкой на надежный анонимный источник".
> Потому что молодняк тупо не умеет не во что, кроме как плакаться и попрошайничать готовые юниты к системдеА что там просить? Пара строчек и инит готов.
> после переустановки с сохранением /home, оно заработало, но выключалось так же медленно.Как известно, дело мастера боится... ;). И тут вы расписались что вы - ну вот не это.
> это хоть и лучше, чем было с sysv, но почему у всех
> так глазки горят с опенрц слезть ..Можно я побуду немного резким сегодня и назову вещи своими именами? Это - наколенная лабуда, не решающая большую часть проблем оригинала, зато создающая много новых проблем.
Про именно это Генри Форд сказал что если бы он спросил своих покупателей что они хотят, они бы ему ответили - "более быстрых лошадей". А он, вот, массовыми автомобилями занялся. История повторяется по спирали, OpenRC - это более быстрые лошади. Но уже есть - автомобили.
Это - шаг вперед. Даже если их приходится чинить. Даже если требуется ТО. Даже если расходники стоят денег. Даже если это добавляет неких знаний, а колеса не чинятся имнно кувалдой, в сарае, а шиномонтаж все ж контора чуть попродвинутее.
> умеет то же самое; с нативными сервисами ( т.е. не шелл-скриптами, а
> теми самыми "сервисами в пару строк в декларативном стиле",Это кусок блевотной скриптоты. Который НЕ умеет то же самое если сравнить фичи с системдой без скидок. Более того, с унификацией, диагностикой и логами, тулсами показывающими состояние системы и дельту от апстрима и проч.
> коими так хвастал поттеринг, через openrc-run ) грузится даже быстрее, чем systemd
А как там с...
1) Изоляцией от ОС, включая ту при которой при сборке окружения в процессе станет недоступен шелл и проч? Не, httpd совершенно точно шелл для нормальной работы не требует.2) Диагностикой и логингом? Если что-то не стартует, что насчет редиректа stdout/stderr в логгер, вместе с треком успеха сисколов и ЗАПИСИ ЭТОГО В ЛОГИ?
3) В системд можно посмотреть дельту относительно ванильного дистра 1 командой. Это круто, если мне "чей-то" сервак достался на порулить. А в этой штуке?
4) Эта же тулса покажет текущий статус сервисов. А соседняя - кто тормозит при загрузке ОС больше всех. То что вы не умеете RTFM и не научились это юзать - не вина системды.
5) И вот на удивление, у системды очень качественная документация. Если не лениться, 1 раз в жизни ее таки прочитать, то - все логично, просто и понятно.
> раз 100500 скриптов, 1 процесс openrc-run проходится по всему init.d; менеджмент
> сервисов, аля "тут - с завода, тут - юзер покрутил,Это - увы -КОННОзавод. А народ в целом хотел уже - авто с конвейера, познав как это можно было. Имеючи на то причины. И да, необучашек из bulk индустрии мы таки - выпрем. Увы и ах.
> параметром cgroups умеет, в авторестарт и прочее тоже умеет через стандартный
> супервизор; уже даже юзерский инстанс пилят.Простите а этот супервизор умеет мониторить что процесс не сдох? Даже если он не сетевой? Т.е. что процесс реально что-то делает?
Видите ли, знакомый девопс нарисовал вон тому сервису, висшему раз в пару месяцев хз почему - вачдог апи, и теперь в таком случае системд видит что пингов вачдога нет и сам его рестартит. И заняло у него это - 10 минут. А народ был очень рад решению дурной грабли. С вашей хренью так получится?
Более того. У sd есть крутая интеграция с пакетниками. Когда системные девфолты в usr но легко перекрываются админсими файлами в /etc и на уровне полисей договорились что пакетник рулит только usr, а etc никогда не трогает. Поэтому с одной стороны система может предложить дефолты, с другой - пакетники не будут покушаться на админские оверрайды при апгрейдах.
А в openrc такие вещи - как?
...
> но потом у меня кончился отпуск и как бы все, стало некогда.А когда у меня чертова куча тазиков, да еще всякий кастом, я как раз хочу кастомные сервисы запилить быстро, сердито, решив системные проблемы и - с документацией на случай непоняток. Системд мне это обеспечивает. Равно как и решение целой кипы дурных системных проблем.
А альпин по своему забавный но и по своему дурацкий. С их мусолм это грабель кусок, увы.
>Можно я побуду немного резким сегоднялучше б Вы не в "правдоруба" играли, а дали тех. аргументов. ибо что отвечать на сказки про лошадей - я без понятия.
>Более того, с унификацией, диагностикой и логами, тулсами показывающими состояние системы и дельту от апстрима и проч.это что за набор слов? мало того, мысль сформировать сил не хватило, да еще и ерунду сказали. идите и почитайте, что такое унификация .. это не когда de приходится лазать во внутреннем мусоре службы(/run/systemd) и биндиться на io.systemd1. это когда есть документ и разработчик может сделать хоть /run/VasyaD, не поломав апи.
>А как там с...
1) это лиункс-специфичная фишка.
openrc работает на любых posip-совместимых ос.
2) openrc - сервисный менеджер. он на себя обязанности пакетного брать не должен ни в каком виде.
3) да, оба супервизора openrc именно это и делают. после чего можно либо поискав по файлу из /var/log, либо, воспользовашись logread из logbookd, написать logread -u SrviceName.
4) это есть в логе загрузки.
кто у Вас там и во что "не научился" - не знаю .. а вот Вы в матчасть - уж точно.
5) и? я где-то о документации писала? или это у Вас уже рефлекс, про писать про хорошую документацию?
в openrc не хуже.>Это - увы -КОННОзавод.
это - увы - кто-то форумом ошибся ..
про коней идите рассказывайте автолюбителям.>Простите а этот супервизор умеет мониторить что процесс не сдох? Даже если он не сетевой? Т.е. что процесс реально что-то делает?
если вы о "зомби-процессах", да, умеет, помечая таковые, как inactive.
>С вашей хренью так получится?лол, это уже на троллинг похоже.
бывайте, госпадин и попросите systemd рассказать Вам про правила русского языка.
> лучше б Вы не в "правдоруба" играли, а дали тех. аргументов.Мне нравится такой настрой. Но - сложный топик. Могу сказать за себя. Я имплеменчу кастомные системы. Ине стало проще запиливать кастомные сервисы и переносить юниты из ОС отличных от моей.
Еще Поттеринг на LinuxPlumbers разок получил пожелания и заимплеменетил хотелки эмбедеров. Теперь есть API вачдога/нотификаций, реакция на сбои юнита, вплоть до пуска юнита-"handler'а". И иные типовые вещи, "first boot", "reset to factory defaults", продвинутая изоляция сервисов несколькими строками конфига. То что раньше все велосипедили сами. Остальным в этом направлении все время что-то мешало. Задолбало велосипедить!
> ибо что отвечать на сказки про лошадей - я без понятия.
Однако по моему очень хорошая аналогия. Системд решил ДЕСЯТКИ задолбавших, типовых проблем системщины. OpenRC... не понимаю "зачем?" и "чем лучше других?". Ни два ни полтора: делает все сложнее, но половину упомянутых аспектов не адресует нормально как я понимаю.
Потуги сохранять unix way в ТОМ закоулке имеют цену. Ломовые проблемы сборки изолированых от основной ОС окружений, потому что задача - изолировать арену нового процесса от остальной ОС. Я не хочу чтобы у e.g. httpd был доступ в шелл, системные утилы и проч.
> это что за набор слов? мало того, мысль сформировать сил не хватило,
> да еще и ерунду сказали. идите и почитайте, что такое унификацияА таки рулить RHELобразным, DEBобразным и проч более похоже в базовых вещах стало.
> .. это не когда de приходится лазать во внутреннем мусоре службы(/run/systemd)Это вообще - на совести DE.
> и биндиться на io.systemd1. это когда есть документ и разработчик может
> сделать хоть /run/VasyaD, не поломав апи.Э не, вопрос в соглашениях. Попробуйте сделать что-то иное вместо /proc и /sys "не поломав апи". Пусть /vasya вместо /proc будет, не?! Теперь объясните это утилитам, м? :)
> 1) это лиункс-специфичная фишка. openrc работает на любых posip-совместимых ос.
Не собираюсь обрубать свои возможности до самой медленной овцы в стаде.
> 2) openrc - сервисный менеджер. он на себя обязанности пакетного брать не
> должен ни в каком виде.Systemd тоже не берет. Но допер регламентировать что системные дефолты в /usr а оверрайды в /etc. Первый из. Алилуя. И теперь пакетники не пытаются стирать админские оверрайды. От типа пакетника не зависит, сугубо соглашения.
> 3) да, оба супервизора openrc именно это и делают. после чего можно
Делают что именно? У системды есть апи, описанное в документации. Можно в него слать сообщения. Индицирующие что процесс - живой. При отсутствии таковых - упс, сбой сервиса, принимаются настроенные меры. Такой себе древовидный вачдог. А сам sd и кернел - аппаратным вачдогом мониторятся, если они отвалятся, ребут хардварным вачдогом.
Аналогично - нотификации. Прога может отсигналить когда она считает что она РЕАЛЬНО стартанула. И sd для типа сервиса "notify" будет запускать тех кто depends только тогда. Скажем если БД надо минуту на взлет, глупо запускать ее клиенты ДО ее реального взлета, когда она может начать запросы разруливать. И так далее.
> либо поискав по файлу из /var/log, либо, воспользовашись logread из logbookd,
> написать logread -u SrviceName.ИМХО у системд journald и systemctl стройнее сделаны. Journald можно и не юзать если не хочется, но меня помойка в /var/log достала! Там еще logrotate и проч надо, иначе отрастет до небес. Куча мелкой назойливой конфигурации. На каждую прогу. В journald настроил глобальные лимиты, 1 раз. Все! Базы крупней этого не растут. Удобно, логично, работает, может integrity check.
> 4) это есть в логе загрузки. кто у Вас там и во что "не научился" - не знаю
> .. а вот Вы в матчасть - уж точно.А таки системд первый кто всерьез озаботился привнесением хоть какого-то порядка в логи, и возможности траблшутинга.
> рефлекс, про писать про хорошую документацию? в openrc не хуже.
Думаю что отвечать на наезды не есть хорошая идея. Но вы можете закинуть пруфлинк на эту документацию, я таки проверю насколько оно "не хуже".
> это - увы - кто-то форумом ошибся ..
> про коней идите рассказывайте автолюбителям.А вы можете попробовать рассказать какие бенефиты есть у OpenRC относительно ситсемды.
> если вы о "зомби-процессах", да, умеет, помечая таковые, как inactive.
Нет, я про процесс, который, например - не сетевой как таковой. Но его живость в системе - критична, иначе система не котируется. У системды апи вачдога есть, и мне разок девопс показал как за 10 минут его в вооооон тот сервис приделать. А в OpenRC что-то сравнимое есть вообще?
> лол, это уже на троллинг похоже.
> бывайте, госпадин и попросите systemd рассказать Вам про правила русского языка.Ну тогда тут для симметрии с автомобилистами - отсыл на грамота.ру ;)
>выяснилось после настройки tomoyo на дестопеМандатный доступ? Как там оно - живо? Где мануалы брал?
да, живее всех живих.
мануалы по первой ссылке в гугле: tomoyo.sourceforge.net/2.6/
Разработчики FreeBSD уже доказали, что это все по большей части перестановка мебели:
https://wiki.freebsd.org/BootTime
> Разработчики FreeBSD уже доказали, что это все по большей части перестановка мебели:
> https://wiki.freebsd.org/BootTimeЭто им не поможет. С их управлением системой - они либо таки придут в адекват и родят что-то подобное. Или - улетят на совсем задворки истории. Куда-то в районе слаки, только поскольку ниша уже занята - как вам жирный кус пирога в виде 0.1% от доли слаки? Ну и 1-2 особо жадных пропертария которые с вами не поделятся.
>>> сокращение времени загрузки
>> Разработчики FreeBSD уже доказали, что это все по большей части перестановка мебели:
>> https://wiki.freebsd.org/BootTime
> Это им не поможет. С их управлением системой - они либо таки придут в адекват и родят что-то подобное. Или - улетят наКакой многословный эвфемизм для "Нищитаица! это другое!" (ну или много бла-бла мимо темы, зато с выпуском метана в сторону БЗДей) ... хм, Балабол294, ты вернулся?
> Какой многословный эвфемизм для "Нищитаица! это другое!" (ну или много бла-бла мимо
> темы, зато с выпуском метана в сторону БЗДей) ... хм, Балабол294,
> ты вернулся?Какой характерный подрыв окороков. Но это никак не облегчит вашу участь. Технически то вам крыть нечем.
И вон те либо прожмутся, либо их пошлют оставшиеся полтора прода, и перестанут давать гранты. Ибо уже показано как можно было. На меньшее уже мало кто согласится. Фарш невозможно провернуть назад.
> Какой характерный подрыв окороков. Но это никак не облегчит вашу участь. Технически
> то вам крыть нечем.Какая характерная проекция.
Но технически и по теме - опять 0 (впрочем, ничего иного от Балабола294 и не ожидалось). Зато да, дополнительный выхлоп метанчика с сероводородиком в сторону "ненавистных бздей" (которые тут так, в качестве примера-демки и вполне могли быть заменены на какой нить дистр пянгвинчика) и пускание соплей пузырями.
Правильно я угадал.
> И вон те либо прожмутся, либо их пошлют оставшиеся полтора прода, иТвое занудное балабольство мимо темы слишком уныло, осиль уже чтение комментов (а потом и новостей и прочего) "целиком", что ли.
> Какая характерная проекция.Вам с вашими проекциями - виднее.
> в сторону "ненавистных бздей" (которые тут так, в качестве примера-демки и
> вполне могли быть заменены на какой нить дистр пянгвинчика) и пускание
> соплей пузырями. Правильно я угадал.Я думаю что с заменой фри на более нормальные решения я тоже не промазал. Вон тот системный менеджмент - удел совсем луддитов уже, увы и ах. И вот тут господам придется выбирать как они свое будущее видят.
>> И вон те либо прожмутся, либо их пошлют оставшиеся полтора прода, и
> Твое занудное балабольство мимо темы слишком уныло, осиль уже чтение комментов (а
> потом и новостей и прочего) "целиком", что ли.А что тут мимо темы? В этой вашей BSD нет ничерта сравнимого с сабжем. Совсем. Никак. И это "фича" только для совсем уж луддитов. Для остальных это такая же фича как отсутствие лифта в 20-этажном доме. Да, конечно, можно ответить "зато в лифте не застрянешь!". Но...
> /etc/rc.d/netif takes ~1300 ms, including a 1-second sleep(1).
> /etc/rc.d/rtsold takes ~1050 ms, including a 1-second sleep(1).Напоминает бородатый анекдот:
Чтобы программа отрабатывала на 10 сек быстрее, а вы получили премию - просто уберите sleep(10), который вы в неё заведомо вписали
Никогда не напрягала загрузка в три минуты. Да у некоторых машин от нажатия кнопки "Power" до появления меню GRUB'а проходит больше...
Ждем теперь системди в ЭлпайнЛинукс.
Все меньше остается девственников СистемФайв.
Разве-что БиЭсДи, на там то-же смотрю присматриваются к огрызкам.
Да и сами огрызающиеся свои щупальца тянут куда не нужно...
> Ждем теперь системди в ЭлпайнЛинукс.
> Все меньше остается девственников СистемФайв.
> Разве-что БиЭсДи, на там то-же смотрю присматриваются к огрызкам.
> Да и сами огрызающиеся свои щупальца тянут куда не нужно...Пичаль для девственников будет, когда в Gentoo вкорячив systemd выкинут openrc на мороз. ))
Системд видимо, не было только в профиле с Мускулом. Теперь может быть будет, но от этого этот профиль не станет более перспективным. Мускул с мультилиб вообще плохо работает и дальше ембедовок не пролезет.
> Системд видимо, не было только в профиле с Мускулом. Теперь может быть
> будет, но от этого этот профиль не станет более перспективным. Мускул
> с мультилиб вообще плохо работает и дальше ембедовок не пролезет.Мускул это MySQL, а musl это - мюсли! ;)
Спасибо за ликбез,а то я тут решил поумничать.)
Перейдём на Guix;
Будем собирать OwnLFS со старым добрым SysVinit и раздельным /usr.
> Перейдём на Guix;
> Будем собирать OwnLFS со старым добрым SysVinit и раздельным /usr.Это на тот истеричный sjw-раковник, который люто бешено газифицировал лужи, когда была травля Столлмана? ))
Тем не менее, Guiх среди одобренных Светлейшим дистрибутивов.
> Перейдём на Guix;
> Будем собирать OwnLFS со старым добрым SysVinit и раздельным /usr.Ага! Вон там коннозаводчики до сих пор коней разводят. Наверное, назло Генри Форду! И пусть эти, с конвейером, подавятся! :)
> Разве-что БиЭсДи, на там то-же смотрю присматриваются к огрызкамИдее портировать лаунчд из макоси в фряху уже лет 100500.
А воз и ныне там...
Очевидно, Фряшный инит не хуже Эппеловского.
Дык уже и так было 2 рабочих порта launchd, один порт systemd и примеры использования nosh и OpenRC в TrueOS и GhostBSD.
В итоге просто стали искать бутылочное горлышко:
https://wiki.freebsd.org/BootTime
Те кто топят за системди уже давно заткнулись про то что оно "быстрее грузицо" :)
Там в основном сейчас напирают на "пром стандарт ди факто жи!" (С) и увы это близко к истине.
Для неграмотных - у бсд своя система инициализации, не от SySV ...
Но так как в нашей ойте всегда побеждает худшее решение ... какой то вариант системди, а то и он сам в бсдях вполне может появится :)
Ждём порт на FreeBSD Libc.
Пора докидывать оперативы в vm-ки с Alpine?
> Пора докидывать оперативы в vm-ки с Alpine?Ага, и резать время лимитов на простой затупляющих сервисов systemd
> Ага, и резать время лимитов на простой затупляющих сервисов systemdО, это и десктопная/ноутбучная боль. Нахрена там такие дефолты?
Дефолты для серверов, где аккуратный останов одного сервиса может занимать минуты. Пока всех клиентов из очереди обслужит, пока все кэши на диск скинет, пока все соединения закроет, вот уже и минута прошла, а то и двадцать. Линукс на десктопах и ноутбуках как был, так и остался шуткой в пределах статпогрешности.
systemd необходимо в bios, чтобы порадовать ловастиков ржавчины
К моменту создания systemd UEFI уже давно был )
Штобэ они BIOS начали переписывать?
Оно уже давно есть в BMC.
Я вот одного понять не могу: что это за повсеместный фетиш такой на скорость загрузки системы? Какая к хренам разница, за 7 секунд загрузится или за 20?
это как с rust и прочими.. мозгов нет, почему что-то было сделано раньше опред. образом - не понимают, зато бегут все "улучшать".
в итоге улучшают так, что все старые проблемы остаются, но сверху присыпаются "сахарком".
самое забавное, что сейчас развивающиеся иниты, вроде openrc и dinit, sd в скорости загрузки как раз обгоняют.
при том, в функционале, как сервисные менеджеры, не уступают(по крайней мере, openrc, про dinit не уверена).
> это как с rust и прочими.. мозгов нет, почему что-то было сделано раньше опред. образом - не понимают, зато бегут все "улучшать".Как раз понимают что раньше было сделано так потому что не было раста.
>> это как с rust и прочими.. мозгов нет, почему что-то было сделано раньше опред. образом - не понимают, зато бегут все "улучшать".
> Как раз понимают что раньше было сделано так потому что не было
> раста.Не, на самом деле кошка права, однако теперь современные эффективные коддеры пользуются наработками дидов в плане того, что те ужимались по ресурсам и всячески оптимизировали, но нынешнее поколение пользователей привыкшее к жору ресурсов в мобилках и на десктопных виндах от всяких фонариков и калькуляторов привыкнет и к жирнософту на линуксах.
А поэтому можно взять по-старому скроенные экономные софтины и обернуть их в несколько уровней абсракций и затолкать их в жирные рантаймы попутно ещё обновляя атомарно, а то что-то места жрётся мало в системе.Зато вся эта заботливо созданная дидами экономия даёт возможность современным лоботрясам говнякать на скриптоте и совершенно не разбираться на низком уровне в том как работает железо на котором должно запускаться их поделие, отсюда и мода на отношение к работе software as gas и прочие модные штуки. Диды же десятилетиями экономили, а теперь вон сколько модной новой оперативки, накопителей и процессорного времени зря простаивает, нипарядок! xD
> те ужимались по ресурсам и всячески оптимизировали,У них выбора не было.
Точнее был, но они зачастую принимали самые дурацкие решения, типа "давайте сэкономим целый байт и будем использовать null-terminated строки!".
А потом десятилетиями выгребать овно.> нынешнее поколение пользователей привыкшее к жору ресурсов в мобилках и на десктопных виндах от всяких фонариков и калькуляторов привыкнет и к жирнософту на линуксах.
Пользователь просто привык к качаству.
А на линуксах даже жирнософт (привет гном!) просто дрмовый.
Вообще под линукс пользовательский софт отстойный, хороше примеры можно пересчитать по пальцам одной руки.> Зато вся эта заботливо созданная дидами экономия даёт
Просто тонны CVE, включая абсолютно дибильные типа "нажал 28 раз backspace и зашел в систему без пароля.
В ядре Memory Corruption это топовая проблема, в несколько раз обгоняющая Overflow.
https://www.cvedetails.com/product/47/Linux-Linux-Kernel.htm...> возможность
престарелым дидам фиксить баги годами.
Можно сидеть на проекте, фиксить CVE, попутно создавать CVE, получать зарплату..
Красота!> Диды же десятилетиями экономили, а теперь вон сколько модной новой оперативки, накопителей и процессорного времени
Угу, примерное как сейчас, старые деды и бабки рассказывают "стирать руками лучше, эл-во экономится".
Потому что если твое время стоит ничего, то можно и экономить.
А если ты его ценишь - то пользуешься результатами прогресса.ps самое смешное что на расте люди пишут сверхпроизводительные программы типа драйверов для видяхи.
Неосиляторы не могут понять, что скорость и низкоуровневость будут сравнимы с дыряшкой.
А надежность - существенно выше.
> Вообще под линукс пользовательский софт отстойный, хороше примеры можно пересчитать по
> пальцам одной руки.Да, хороший софт под линукс работает в вайне)
>[оверквотинг удален]
> зашел в систему без пароля.
> В ядре Memory Corruption это топовая проблема, в несколько раз обгоняющая Overflow.
> https://www.cvedetails.com/product/47/Linux-Linux-Kernel.htm...
>> возможность
> престарелым дидам фиксить баги годами.
> Можно сидеть на проекте, фиксить CVE, попутно создавать CVE, получать зарплату..
> Красота!
>> Диды же десятилетиями экономили, а теперь вон сколько модной новой оперативки, накопителей и процессорного времени
> Угу, примерное как сейчас, старые деды и бабки рассказывают "стирать руками лучше,
> эл-во экономится".Нет, тут не предлагается стирать ручками, тут предлагается не стирать каждый раз одну пару носков в промышленной стиралке, которая жрёт вагон энергии, а вы, батенька пытаетесь в подмену тезисов, не стоит так делать, тут же не дураки сидят! ж;)
> тут же не дураки сидят!Заявление настолько же смелое, насколько оторванное от реальности.
>Зато вся эта заботливо созданная дидами экономия даёт возможность современным лоботрясамНе наговоривайте на дидов. Они либо портили память в си либо скриптили на всяких ужасах типа баша, перла, а потом и питона.
появился руст - осталось так же.
"не включая мозги" и не понимая, как работать с памятью, писать по-прежнему нельзя, brck - это Вам не clr и даже не jvm .. раст и течет, и небезопасно работает с памятью, точно так же, как и С.
+ сейчас там процветает ситуация, как в ноде, питоне и подобных: 100500 зависимостей почти у любого приложения и еще сотня у каждой из них(утрирую, конечно, но от правды не далеко), уже даже cargo научился в команду audit.
без unsafe-кода не обходится почти ничего, кроме совсем простых программ.
попробовав руст, а позже перейдя на С, никаких плюсов, кроме удобной системы сборки, более развитых механизмов сокрытия и крейтов/модулей не увидела.
компилится оно раза в 2 медленнее и, судя по словам дебиановских меинтейнеров, пакетить руст-программы сложно.
при том, у С есть довольно большой и по непонятной мне причине, часто игнорируемый плюс: c99 описан в POSIX, как и огромная часть libc. следовательно, компилиться и работать оно будет везде, при правельном подходе.
в случае в рустом - мне пару раз код приходилось переписывать после обновления компилятора.
Просто шикарный спич типового хейтерочка:> "не включая мозги" и не понимая, как работать с памятью
Понимая лучше чем дыряшчники. Потому что у тех, у кого не понимает, прога даже не скомпилится.
> раст и течет, и небезопасно работает с памятью, точно так же, как и С.
Ложь. Сишники как не умели не портить память 40 лет назад, так и сейчас не умеют.
А раст как раз позволяет безопасно работает с памятью.
"To date, there have been zero memory safety vulnerabilities discovered in Android’s Rust code." на 1.5 ляма строк расткода.
security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html> без unsafe-кода не обходится почти ничего, кроме совсем простых программ.
Еще одно лживое заявление.
Тут даже новость была "Только 20% крейтов содержат unsafe" www.opennet.ru/opennews/art.shtml?num=61251
И "в большинстве случаев использование "unsafe" обусловлено вызовом кода, написанного на других языках или обращения к библиотекам на С/C++"> попробовав руст, а позже перейдя на С, никаких плюсов, кроме удобной системы сборки, более развитых механизмов сокрытия и крейтов/модулей не увидела.
Ты просто неосиялатор значит.
> компилится оно раза в 2 медленнее
Разумеется! Потому что компилятор делает еще кучу проверок и анализа, а не просто перегоняет любой омнокод в машкоды.
> c99 описан в POSIX, как и огромная часть libc
с99 это уже окаменелое омно. Даже консервативное ядро перешло на с11
> следовательно, компилиться и работать оно будет везде, при правельном подходе.
Но не везде одинаково)) А потом ищи где другой компилятор по другому обрабатывает очередное UB в сишном коде.
> в случае в рустом - мне пару раз код приходилось переписывать после обновления компилятора.
Для этого нужно почитать доку и просто фиксировать Edition. Тогда ничего не ломается.
В сишке, кстати, такое тоже бывает. Обновляешь компилятор, в него добавили новые warning, которые становятся ошибками, потому что у тебя разумеется включен -Werror... и все, приехали, нужно исправлять.
И это абсолютно нормальная ситуация.
>Просто шикарный спич типового хейтерочкаэто когда в технической дискуссии переходят на личности, "хейтерочков" и "дыряшничеков"(о ком это вообще?).
>раст как раз позволяет безопасно работает с памятью.руст считает, что утечка памяти - это [вполне безопасное и нормальное поведение](https://doc.rust-lang.org/book/ch15-06-reference-cycles.html). собственно, это действительно так, но в таком случае не надо рассказывать про
>не умели не портитьпо поводу..
>20%и
>новость былани в новости, ни в оригинале с сайта нет "списка тестируемых".
можно взять 10 крейтов, предоставляющих системные апи и 90 для парсинга 100500 форматов, регекспов, тд. тп.
поэтому, судить по этому бессмысленно.
я из своего опыта сказала.
писала ради эксперемента шелл с доступом к большому кол.-ву системных апи.>обращения к библиотекам на С/C++"
это ничего не меняет, надеюсь, Вы понимаете.
>Разумеется! Потому что компилятор делает еще кучу проверок и
нет, не поэтому, вот из faq:
>Rust provides high level abstractions that compile down into efficient machine code, and those translations take time to run, especially when optimizing.он сначала переделывает программу в llvm'овский байткод со встроенными доп. апи, а потом llvm это все разгребает.
brck не много всего проверяет, чуть ли ни на равне с условным gcc, ибо больше во время сборки не напроверяешь.>А потом ищи где другой компилятор по другому обрабатывает очередное UB в сишном коде.
в соответствии со стандартом.
если поведение отличается от стандартного, его, как правило, легко привести к стандартному.
речь тут была о том, что, условно, код с гну-расширений Вы под любым компилятором не скомпилите.
а код, например, соответствующий с99 и использующий стандартизированные апи - скомпилите.
может, надо будет что-то покрутить в опциях, но
это уже дело того, кому надо будет, а не Ваше. Ваше дело - соблюдать принятую во всем мире спецификацию.>Для этого нужно почитать доку и просто фиксировать Edition
в итоге - нашли уязвимость, новый баг, крит. ошибку, а Вы - на "фиксированном эдишн", дергаете какое-то апи, до этого не дерганное, сталкиваетесь с ним, понимаете, что пора обновляться.. и Вас ждет увлекательный квест по переписыванию кода.
я в курсе, что это зачастую несложно, но, тем не менее. пример бага тоже не с горы взят - в какой-то там версии была пофикшена проблема с float'ами, при том, выпилены некоторые апи.
и мне код, их использующих, надо было переписывать.
в то время, как в случае с .NET - у меня еще 3 года минимум бы было, а в случае с POSIX С - четкого бинда на версию стандарта и.. 20? 40? 60 лет? вот, недавно собирала под новым gcc код, написанный под POSIX2001 - все прекрасно. 20 лет прошло.
> дыряшничековФанатиков "дырявой сишки"
> руст считает, что утечка памяти - это [вполне безопасное и нормальное поведение]
Да, потому что утечка памяти не приводит к ее порче.
> ни в новости, ни в оригинале с сайта нет "списка тестируемых"
Я думал это очевидно почему нет списка...
"As of May 2024, there are about 145,000 crates; of which, approximately 127,000 contain significant code. Of those 127,000 crates, 24,362 make use of the unsafe keyword, which is 19.11% of all crates. And 34.35% make a direct function call into another crate that uses the unsafe keyword."Предлагаете засунуть в статью список 127k крейтов?))
Числа озвучены. Было 145к, из них 127к содержат significant code.> он сначала переделывает программу в llvm'овский байткод со встроенными доп. апи, а потом llvm это все разгребает.
Ты не поверишь, но с любым языком, компилируемом llvm, происходит точно также.
А у gcc, кстати, тоже есть внутреннее представление, в которое она перегоняет код.> в соответствии со стандартом.
У вас в стандарте прописано что это UB. Про расширения вообще речь не идет.
> а код, например, соответствующий с99 и использующий стандартизированные апи - скомпилите.И этот код может выдавать разные результаты даже на одном компиляторе разных версий. А на разных компиляторах - тем более.
> если поведение отличается от стандартного, его, как правило, легко привести к стандартному.
Для этого нужно вначале найти то, что оно работает не так как нужно и только потом можно исправлять ошибку.
И скорее всего вам об этом сообщат пользователи.> в итоге - нашли уязвимость, новый баг, крит. ошибку, а Вы - на "фиксированном эдишн"
Баги и крит. ошибки фиксят для всех edition. И в этом случае таки придется исправлять.
А что если в вашей системе старый gcc и нашли баг?
Тоже самое - или у вас будет баг, или вам придется исправлять.
>предлагаете засунутьда. или хотя бы сгруппировать как-то.
либо убирайте циферки обратно в кармашек. без конкретики - смысла в них нет в этом контексте.>Ты не поверишь, но с любым языком, компилируемом llvm, происходит точно также.
и что? это не было притензией. это я сказала, почемы Вы по поводу "проверок" не правы.
представления gcc тоже ничего с темой общего не имеют.>У вас в стандарте прописано что это UB.
кто у Вас UB? смена компилятора?
интерфейс прописан. о UB gcc, например, предупреждает.
достаточно сделать
#define _POSIX_C_SOURCE TargetSpec
и компилировать с --pendatic-errors, -std=c99, -Werror.>И скорее всего вам об этом сообщат пользователи.
если прочитать man по своему компилятору, скорее всего, сообщать будет он, перед коммитом.
>Баги и крит. ошибки фиксят для всех edition.
тогда норм, не знала.
> это я сказала, почемы Вы по поводу "проверок" не правы.Раст в процессе компиляции (речь про rustc, т.е. задолго до передачи результатов llvm) строит
- AST (ну это и так понятно) и валидирует его
- HIR
- THIR
- MIR
На каждом этапе делаются различные оптимизации и проверки, в том числе проверки borrow checker'а
И потом только MIR "конвертируется" в LLVM IR и передается для сборки бинарника.
Почитайте rustc-dev-guide.rust-lang.org/borrow_check.html и соседние пункты, там расписан порядок работы rustc ДО llvm> кто у Вас UB?
Напр. порядок выполнения операций это UB.
Вот простейший пример UB
int main() {
int i=7;
i = i++ * i++;
return i;
}И результат выполнения на последний версиях 4 компиляторов godbolt.org/z/hjhdG1fnE
4 компилятора и два варианта результатов. При этом ворнинг дает только шланг))
А теперь удачи портировать ваш "переносимый" код.Или unsigned integer overflow это UB. Прям по стандарту.
Напр. в ядре - пришлось добавить специальный флаг для фиксирования поведения (и чтобы быдлокод с UB работал предсказуемо). Но это костыль. Потому что получается код, который работает правильно только с конкретным компилятором и флагами.
> Напр. порядок выполнения операций это UB.
> Вот простейший пример UB
> int main() {
> int i=7;
> i = i++ * i++;
> return i;
> }А как тут может получиться 51 ?!
Отличный вопрос! Нужно смотреть асмвыхлоп.
Более того, GCC 4.7 (его к сожалению уже дропнули из godbolt) - тоже выдавал 51, GCC 4.8 - уже 56.
А какой-то другой компилятор - 64.
godbolt.org/z/s3Kve4chYЗдорово, правда?! (с)
Просто кажется, что не все пользователи си понимают что такое UB и как оно может обработаться компилятором.
Очевидно же. Сначала выполняется присваивание, а потом инкременты. Я правда не уверен, что ТАКОЕ поведение соответствует стандарту, но уже ничему не удивлюсь.
> Очевидно же. Сначала выполняется присваивание, а потом инкременты.Но вроде у нас все компиляторы для одно языка. А результаты разные.
> Я правда не уверен, что ТАКОЕ поведение соответствует стандарту, но уже ничему не удивлюсь.
Тут есть несколько вариантов. Нарпример в "стандарте"
- этого нет (что сомнительно так писаки наплодили сотни страниц)
- оно UB и "может случится все что угодно"
- оно IB и объясняется "мы тут всем коммитетом хз как правильно.. любитесь как хотите, пусть компиляторо писатели как-нибудь сделают"В итоге каждый создатель компилятора делает как-нибудь.
> Но вроде у нас все компиляторы для одно языка. А результаты разные.Добро пожаловать в "прекрасный мир надежного системного языка"))
> Тут есть несколько вариантов
Тут именно оно UB
Можно открыть стандарт, напр. с11
6.5.16 Assignment operators
"The evaluations of the operands are unsequenced"6.5 Expressions
"If a side effect on a scalar object is unsequenced relative to either a different side effect on the same scalar object or a value computation using the value of the same scalar object, the behavior is undefined."И всё.
Оно может тебе хоть ноль вернуть. Или -1.
Потому что компилятор, считая что UB в программе быть не может, просто выкинул этот кусок кода.> В итоге каждый создатель компилятора делает как-нибудь.
Да. Именно так. Более того, обновив компилятор, можно получить другое поведение.
Как же прекрасно, что у нас есть целый ISO стандарт! Не то что у некоторых...
Как же хорошо, что у нас есть много разных компиляторов! Не то что у некоторых...
Как же хорошо, что написанные программы везде компилируются и везде работают одина... упс...
Фа...какая плохая очепятка.
Разумеется signed integer overflow.
3.4.3
EXAMPLE An example of undefined behavior is the behavior on integer overflow.
об этом точно так же предупреждают компиляторы.
и clang, и gcc.
> об этом точно так же предупреждают компиляторы.Не всегда.
#include <limits.h>
#include <stdio.h>int square(int num) {
return num * num;
}int main() {
int a = 0;
for (int i = 0; i < INT_MAX; i++) {
a = square(i);
}
return a;
}https://godbolt.org/z/7xb9PK7r1
GCC 14.1
Флаги -fsanitize=undefined -Werror --pedantic-errors - именно то, что вы писали выше
И ни одного ворнинга! А переполнение вот оно))
>ДО llvmну и? я к тому, что время тратится именно на 10 преобразований, не на какие-то магические проверки.
>UB ...
>варнинг дает только clangне знаю, что по ссылке - оно на телефоне у меня не запускается, только код показывает.
вот я компилю с ноута Ваш пример:
gcc -fsanitize=undefined -Werror --pendatic-errors -O2 test.c
и вижу
test.c:4:17: error: multiple unsequenced modifications to 'i' [-Werror,-Wunsequenced]+ редактор(micro) об этом написал еще на этапе сохранения, подсветив строку.
>Или unsigned integer overflow это UB.и..? почитайте, как с ними работать и когда, либо избегайте.
"быдлокод" есть везде и работает он "не очень" везде.
> вот я компилю с ноута Ваш примерРазумеется, потому что это синтетический пример.
> и..? почитайте, как с ними работать и когда, либо избегайте.
Как вы можете с ним работать, если результат непредсказуем?
Как только в программе появляется UB, то она перестает быть strictly conforming program.
Компилятор в праве вообще выкинуть этот код.> "быдлокод" есть везде и работает он "не очень" везде.
Ядро лиукса приходится собирать с -fwrapv, потому что там этого быдлокода столько, что без однозначного поведения оно просто начинает работать некорректно.
А где в распрекрасном стандарте описан fwrapv?)
Поверх стандарта вы наворачиваете костыли в виде опций компиляции, чтобы его исправить.
И это все только про один тип UB. А их дофига.C99 List of Undefined Behavior (193 Cases)
gist.github.com/Earnestly/7c903f481ff9d29a3dd1
Вот напишите хоть сколько-то значимую программу без них.
хм.. в принципе-то, логично.
но, как по мне, уж лучше б они свой стандарт запилили, описывающий обработку всех этих случаев с опред. опциями и сделали бы референс.
в принципе, у меня даже есть пара идей на этот счет.. возможно, что-то сделать осилю, когда будет отпуск.
>почитайте, как с ними работать и когда, либо избегайте.Подскажите, как мне избежать его в чужом коде, например в ядре?
>руст считает, что утечка памяти - это [вполне безопасное и нормальное поведениеДля избежания этого нужны зависимые типы. Но их осилит ещё меньшее количество людей чем раст. Если кому интересно, могут посмотреть в сторону ats.
>руст считает, что утечка памяти - это [вполне безопасное и нормальное поведениеМожно подумать, что в си лучше.
можно голову включить и прочитать переписку?
человек Выше говорил про "порчу памяти" в Си и то, что в расте ее нет.
вы действительно не понимаете в чём разница? Если есть утечка, программу надо периодически перезапускать, в зможно раз в неделю. Если есть порча, то программу в в принципе небезопасно запускать, так как она может в любой момент испортить любые данные. Если не хотите утечек, берите gc
> при том, у С есть довольно большой и по непонятной мне причине,
> часто игнорируемый плюс: c99 описан в POSIX, как и огромная часть
> libc. следовательно, компилиться и работать оно будет везде, при правельном подходе.Ключевое тут - "при правельном подходе".
> в случае в рустом - мне пару раз код приходилось переписывать после
> обновления компилятора.Кто мешает использовать LTS версии?
>без unsafe-кода не обходится почти ничего, кроме совсем простых программ.Поздравляю, вы не осилили раст. Куча, подбных вам сишников так и не поняв афинных типов пошли портить память сырыми указателями. Всё как всегда.
>и, судя по словам дебиановских меинтейнеровЕщё одни неосиляторы. Они мало того, что опакетить несколько библиотек не могут, так ещё и их дистрибутивы буквально пачками набиты cve разных сортов.
"все неосиляторы, все не понимают, все тупые, все всё неосилили!!!"
самое смешное, что даже ссылок никаких.
в итоге выходит:
в крупнейших дистрибутивах(в rhel тоже, да) есть проблемы с поставкой rust-софта; комунити всех, кто посмел усомниться в их обьекте обожания, помоями поливает(аноним выше хотя бы ссылок дал и тех. аргументы привел) и обьявляет "неосиляторами"; у языка проблемы со стандартизацией.зачем мне тогда раст?
если крупнейшие игроки что-то там "не осилили" - это проблема инструмента, а не их. так устроен реальный мир.
> в крупнейших дистрибутивах(в rhel тоже, да) есть проблемы с поставкой rust-софта; комунити
> всех, кто посмел усомниться в их обьекте обожания, помоями поливает(аноним выше
> хотя бы ссылок дал и тех. аргументы привел) и обьявляет "неосиляторами";
> у языка проблемы со стандартизацией.Потому что называя вещи своими именами - вокруг яп собралось комьюнити горластого но не шибко компетентного нубья с синдромом утенка. И почему-то уверены что если прочитали маны на кучку закорюк то это имеет самоценность само по себе.
А еще каждый мнит себя офигеть прожектманагером. Ну и вот - отменеджили, в непонятно какое месиво где каждую версию зачем-то синтаксис телепают, а между делом оказывается - что есть жирнющие факапы с самыми базовыми вещами типа динамической линковки.
Между прочим из дебиана bcachefs'овские тулсы тоже вылетели. Из-за хруста, который видите ли тулчайном не собирается. Надо именно распоследний, иначе - упс!
> "все неосиляторы, все не понимают, все тупые, все всё неосилили!!!"Когда люди несут какую-то чушь, которая описана на первых страницах растбука.. то да.
Просто представь что тебе начнут рассказывать "СИ и С++ плохие - в них плохо работает сборщик мусора".
А на замечание, что ʼего там вообще нет и не былоʼ, будут бычится "я ваши мануалы читать не собираюсь".> самое смешное, что даже ссылок никаких.
Вот тебе ссылка (уже кстати кидали), что 80% крейтов обходятся без unsafe, при выборке из 127 тысяч.
opennet.ru/opennews/art.shtml?num=61251> в крупнейших дистрибутивах(в rhel тоже, да) есть проблемы с поставкой rust-софта;
"самое смешное, что даже ссылок никаких" (с)
ты же понимаешь, что в эту игру можно играть вдвоем)> у языка проблемы со стандартизацией.
А какие проблемы со стандартизацией, если сейчас есть одна реализация?
Конечно не уровень сишки, где программа "два числа сложить" не будет strictly conforming.
Ну и сишка была стандартизована через много лет после создания K&R.> зачем мне тогда раст?
Без понятия. Я даже не знаю кто ты.
Может ты пишешь на ПХП сайтики, или на Хаскеле научные работы и тебе раст вообще не упал.
А может ты вообще пришла сюда просто потролить.
Фишка в том что если у тебя телефон на андроиде уже есть раст код, больше 1.5 лямов строк.> если крупнейшие игроки что-то там "не осилили" - это проблема инструмента, а не их. так устроен реальный мир.
Гугл осилил, амазон осилил, Клаудфаря, letsencript тоже.. про каких крупнейших игроков речь?
Там даже виндузятники какие-то попытки делают и у них что-то получается.Ты понимаешь, что если язык попадет хотя бы в хром (ну т.е уже security.googleblog.com/2023/01/supporting-use-of-rust-in-chromium.html), то это значит что он попал в продукт у котрого больше миллиарда пользователей?
прикол в том, что на Вас никто не "бычился" .. а Вы - вполне себе.
если бы мне что-то "начали рассказывать", я бы на свой счет эти слова не принимала :)>Гугл осилил, амазон осилил, Клаудфаря,
у них сервера на чем? думайте.
юзерский софт писать на чем угодно можно, особенно, подобный хрому(у которого из вариантов установки - бинарь, snap и flatpak).
"ссылок" с моей стороны особо не будет - как уже сказала ранее(или не Вам?), информация из комнаты в матриксе.
могу, разве что, напомнить о причине отказа от поставки вспомогательных утилит БичФС.
>в крупнейших дистрибутивах(в rhel тоже, да) есть проблемы с поставкой rust-софтаВ этих ваших крупнейших дистрибутивах шаг влево, шаг в право - приравнивается к побегу, с расстрелом на месте. Посмотрите, как там любой софт ставить - первым делом будет подключение своего собственного репозитория. И не важно что это - docker, rust, node, php или что-то ещё. В нормальных дистрибутивах, типа NixOS проблем нет никаких.
предлагаю в этом контексте, "нормальные дистрибутивы" оставить школьникам для уроков информатики .. и руководстоваться правилами реального мира.
Кто виноват, что крупнейшие дистрибутивы не могут поставить две разные версии библиотек? Неужели раст? А до раста кто - питон?
> предлагаю в этом контексте, "нормальные дистрибутивы" оставить школьникам для уроков информатики
> .. и руководстоваться правилами реального мира.В реальном мире:
Шляпа двигает OSTree + Flatpack.
Убунта -- Snap Core + Snap App.
Один этузазист -- DistroBox.
--
А тем временем NixOS по портированным на неё проектам обогнала даже AUR.
Как понимать "портированном"? Количество "пакетов"? Вроде бы, объясняется это существенным процентом библиотек на Haskell.
> Как понимать "портированном"?Адаптированном под особенности NixOS.
> Количество "пакетов"?
AUR:
74853 проекта
93418 пакетовnixpkgs stable:
96213 проектов
114653 пакета> Вроде бы, объясняется это существенным процентом библиотек на Haskell.
В AUR их нет?
Про AUR не знаю, сколько там, а в Gentoo eix dev-haskell/* выдаёт всего лишь "Найдено 505 совпадение". Общее количество, кстати, примерно "Найдено 19057 совпадение" (это не точно, поскольку не с руки отключать 3 мелких оверлея, они добавляют навскидку сотню). Но это включает acct-group/*, то есть это не "пакетировано", а вспомогательное для создания групп.
> Про AUR не знаю, сколько там, а в Gentoo eix dev-haskell/* выдаёт
> всего лишь "Найдено 505 совпадение". Общее количество, кстати, примерно "Найдено 19057
> совпадение" (это не точно, поскольку не с руки отключать 3 мелких
> оверлея, они добавляют навскидку сотню). Но это включает acct-group/*, то есть
> это не "пакетировано", а вспомогательное для создания групп.В nixpkgs есть Package sets: haskellPackages - 18116 пакетов.
В AUR по слову haskell нашлось 187 пакетов, а в основных репах арча - 1164 пакета.
Ну вычти их из общего числа пакетов - в никсе всё равно больше выходит.
Мне неясна вся эта арифметика ради арифметики. У меня из 19057 "пакетов" установлено 1700, из которых часть фиктивные. Если же считать не по именам, а по номерам версий, при желании можно и миллион получить.
> мозгов нет, почему что-то было сделано раньше опред. образом - не понимаютКак раз понимают.
У дидов был проц с производительностью как у нынешних принтеров.
Хотя вру, проц в моем уже старом лазерном HP мощнее моего первого компа раза два наверное.
Еще и оперативы больше в 4 раза))А сейчас нужно что-то стандартное. Чтобы новый админ не разбирался в вонючих портянках предыдущего.
И этим стандартом стал systemd.
Локалхостникам-нетакусикам этого не понять, они будут прдлить свои скриптики, просто потому что им это нравится.
Тем же кому нужно работать с инфраструктурой это не интересно. Им работать нужно, а не прдлиться.
> У дидов был проц с производительностью как у нынешних принтеров.Смеёшься? :)
По сравнению с теми PDP - проц в твоих наручных смартватчах - просто топ супер! :)
Наивно полагаешь, если есть systemd, то не, как ты выражаешься, напердоить скрипиков на Баше и др. скриптовых? Ещё как можно постараться. Только тогда новоиспечённому админу придётся ещё более туго. Будет вникать, откуда это они из там Сюстемды стартуют.
если в линукс, стандарт - это просто "кто первый встал - того тапки"; de, лазающие по /run/systemd и io.systemd1.<...> на шине, то.. до десктопа еще, как до Китая.
>этим стандартом стал systemd.этот "стандарт" был задолго до systemd и назывался openrc.
и самое инетересное, он и то с портабельностью справлялся лучше: Вы могли на систему с любым инитом поставить openrc-run и у Вас б openrc'шные сервисы работали.
может, не так быстро, как на openrc, из-за большего кол.-ва форков, но работали бы.
>это как с rust и прочими.. мозгов нет, почему что-то было сделано раньше опред. образом - не понимают, зато бегут все "улучшать".Не нужно понимать почему были выбраны костыли в виде strcpy перезаписывающего память, fork который может вернуть -1 и kill, который может принять -1, макропроцессор бещ гигиены для того, чтобы хотеть это убрать.
Да это адепты systemD рапространяли около 15-ти лет назад. Якобы systemD быстрее загружается чем SysV init. Как всегда врали. Подозреваю, что и до моего рождения деды измеряли скорость загрузки ОС.Да впрочем с появлением твердотельных дисков такой параметр, как скорость загрузки стал некритичен.
СДВГ. Пока 20 секунд будет грузиться средний пользователь устанет и забудет зачем он загружает ноутбук или пк
А, ну вот для таких и пусть делают отдельные специализированные дистрибутивы. Где скорость загрузки во главу угла.
Современный ПК выходит из сна за пару секунд.
…А, мы же про линукс, да.
Да пусть хоть 10 с просыпается. Главное, чтоб успешно проснулся.PS Обратите внимание, сколько Virtualbox виртуалку восстанавливает из остановленного состояния. И ничего, дожидаемся.
> Какая к хренам разница, за 7 секунд загрузится или за 20?Особенно по сравнению с временем инициализации фирмвари.
Я рабочий комп вообще не выключаю.
Ребут раз в месяц после апдейта.
у меня после аптайма в ~14 дней на гноме, либо dbus, либо accounts service, либо провайдер secrets api сходят с ума до перезапуска пользовательской сессии, просто переставая отвечать по шине(или полное зависание всего, если речь о самой шине).
у Вас de какое?
> у меня после аптайма в ~14 дней на гноме, либо dbus, либо
> accounts service, либо провайдер secrets api сходят с ума до перезапуска
> пользовательской сессии, просто переставая отвечать по шине(или полное зависание всего,
> если речь о самой шине).
> у Вас de какое?Windows 10 LTSC 21H2 😉
С другой стороны.
У меня есть компы на Убунте 20.04, они месяцами работают.
>> пользовательской сессии, просто переставая отвечать по шине(или полное зависание всего,
>> если речь о самой шине).
>> у Вас de какое?
> Windows 10 LTSC 21H2 😉
> С другой стороны.Кто о чем а бздюки - о маздайке. И именно поэтому мы вас и ваши вэи с удовольствием спустим в унитаз. И не будем рассматривать вас как пример как это делать надо было.
> У меня есть компы на Убунте 20.04, они месяцами работают.
А чего им не работать то? Все эти блаблабла от нефанатов системды - это как раз контрпродуктивный маркетинговый булшит и wishful thinking адептов проигравшего эволюцию направления. Сколько обезьяна в зоопарке не будет орать про злую участь, и нечестную игру безволосых коллег - а суть дела не изменится, и сторонами вокруг решетки они не поменяются.
> Кто о чем а бздюки - о маздайке. И именно поэтому мы
> вас и ваши вэи с удовольствием спустим в унитаз. И не
> будем рассматривать вас как пример как это делать надо было.Когда твой десктопный Линукс догонит хотя бы МакОСь?
> А чего им не работать то?
Ну вот например:
После недавнего апдейта ядра и glibc в бубунте почему-то начал заполняться своп на 100%.
До апдейта почти не использовался, а после ...
На стабильность это не влияет, но осадочек неприятный.
>> будем рассматривать вас как пример как это делать надо было.
> Когда твой десктопный Линукс догонит хотя бы МакОСь?Без понятия: мне это не интересно. Моя цель - идти своей дорогой, решать свои задачи, ворочая свои воркфлоу без masters лучше меня знающих как мне збс. Linux мне это обеспечивает, а макось - нет. Мне удобно ворочать 1 семейством технологий на десктопе, одноплатниках, серверах, виртуалках, ... макось никогда не обеспечит мне это, ее хозяевам это не интересно.
А что эппл из себя представляет я вижу на примере ифона и аппстора. Мне не по пути с поработителями, увы и ах. Мы хотим - разного. На самых базовых уровнях мироздания.
>> А чего им не работать то?
> Ну вот например:
> После недавнего апдейта ядра и glibc в бубунте почему-то начал заполняться своп на 100%.Ну вот тут я могу только погадать на кофейной гуще. Ибо у меня такого в дебиане нет. А если бы было - я бы вычислил в чем фокус.
> До апдейта почти не использовался, а после ...
> На стабильность это не влияет, но осадочек неприятный.Хызы, для меня линух работает уже почти 20 лет - и мне нормуль. Правда да, порой я не обламываюсь крутануть шестеренки за сценой. Но это особенность опенсорса такая.
> Хызы, для меня линух работает уже почти 20 лет - и мне
> нормуль. Правда да, порой я не обламываюсь крутануть шестеренки за сценой.
> Но это особенность опенсорса такая.20 лет и ни единого разрыва!
> у меня после аптайма в ~14 дней на гноме, либо dbus, либо accounts service, либо провайдер secrets api сходят с ума до перезапуска пользовательской сессии,В MXLinux и его прародителе Antix (DE под крысой) такого 100% нет, рабочие станции (на которых чего только не грузят) по пол года работают легко, может было бы и больше если б админы насильно не перегружали после апдейта кернела
>> у меня после аптайма в ~14 дней на гноме, либо dbus, либо accounts service, либо провайдер secrets api сходят с ума до перезапуска пользовательской сессии,
> В MXLinux и его прародителе Antix (DE под крысой) такого 100% нет,
> рабочие станции (на которых чего только не грузят) по пол года
> работают легко, может было бы и больше если б админы насильно
> не перегружали после апдейта кернелаПодтверждаю, но это не проблема systemd, хотя это ещё то поделие, это либо проблема дистра, либо гнома. У меня Debian под Xfce с большими аптаймами тоже не тёк и не бесновался.
windowmaker, вполне без проблем месяцок-другой жил.
Практически разницы нет, но маркетолухи скажут что скорость загрузки уменьшилась на 185%.
Тем, у кого одна ОС на все случаи жизни, конечно без разницы, включил один раз и на несколько лет забыл про то, что такое загрузка системы.
А если нужно запускать по тысяче виртуалок в день, то даже экономия в долю секунды загрузки сильно облегчает жизнь.
лолкак сказать, что в день запускаешь не больше десятка виртуалок, не говоря, что в день запускаешь не больше десятка виртуалок.
при тысяче разделов в день ты для начала в ио рогом упрешься, а не в мифические преимущества системди.
>при тысяче разделов в день ты для начала в ио рогом упрешьсяВ часе 3600 секунд. Можно запустить тысячу виртуалок в час, и останется ещё 23 часа на всё остальное
Любые оптимизации - это хорошо для пользователей.
>Какая к хренам разницаУ владельцев SSD загрузится меньше, чем за 7, а у владельца HDD больше, чем за 20. Для этого и нужен systemd. Чтобы с SSD загружалось быстрее, а с HDD - медленнее.
Потом владельцы SSD придут на опеннет, начнут что-то там балакать про луддитов и смеяться, но когда на SSD найдётся якобы стёртое порно, ну или ключи от криптокошелька, им будет уже не так смешно.
>>Какая к хренам разница
> У владельцев SSD загрузится меньше, чем за 7, а у владельца HDD
> больше, чем за 20. Для этого и нужен systemd. Чтобы с
> SSD загружалось быстрее, а с HDD - медленнее.
> Потом владельцы SSD придут на опеннет, начнут что-то там балакать про луддитов
> и смеяться, но когда на SSD найдётся якобы стёртое порно, ну
> или ключи от криптокошелька, им будет уже не так смешно.Я вам страшную тайну открою, жизнь на HDD в линуксах есть. Не только для файлопомоек, а именно работы систем, да не столетних, а вполне себе относительно современных. И ничего, работать можно, а вот с малым количеством ОЗУ печально сейчас.
Перфекционизм.
От этого зависит частота воспроизведения писка компа при цикличном ребуте. Вдруг кому важно.
Ну нельзя же было линуксойедам продать "декларативную кофнигурацию, унифицированный инит, упрощение обслуживания, больмень консистентный интерфейс, стабильную работу" и вот это вот все? А вот "раньше загружалось за 30 секунд - сейчас за 5 - LINUX СТАЛ В ШЕСТЬ РАЗ ЛУЧШЕ!!!" - получилось.
Что же вы ноете тогда, когда современный сайт минуту грузится? Подождать что ли не можете?
Пока нода с кубером стартанет, да? Пока страница загрузится...
Те, кто сношается с Musl являются бздунами, либо они отстаивают позиции лицензий "Обществееного достояния". Они слабовольные, без сильного копилефт.
> Они слабовольные, без сильного копилефт.Они по настоящему свободные.
В отличие от комми-куколдов из секты мозолееда.
>> Они слабовольные, без сильного копилефт.
> Они по настоящему свободные.Поэтому они свободно пользуются наработками от MacOS, PlayStation и пейсбучными, ага! ;)
> В отличие от комми-куколдов из секты мозолееда.Зато "комми-куколды" каждый раз кекают с того как у копрокопротивленцев горит дупло от того что человеку пофиг на общественное мнение и он делает что хочет и когда хочет, тогда как остальные ходят строем под дуду копрорастов.
Самый ценный софт распространяется под свободными лицензиями.Под раковыми комми - только древние проекты, которые слишком большие, чтобы их переписать.
Особенно если их просто можно использовать.Можно видеть что кол-во проектов под GPL снижается
medium.com/@WhiteSourceSoft/open-source-licensing-trends-2017-vs-2016-c3e5a5f0086b
anarc.at/blog/2017-09-04-supposed-decline-copyleft/
И это за 2017. В 2024 ситуация еще лучше.> Зато "комми-куколды" каждый раз кекают с того как у копрокопротивленцев горит дупло от того что человеку пофиг на общественное мнение
Да, конечно им пофиг.
Можно например грызть мозоли. Или оправдывать сношения с детьми...> и он делает что хочет и когда хочет
Так это не про ЖоПЛь, тут тебе борода сказал "твой код заражен раком" и все.
> остальные ходят строем под дуду копрорастов.
В ядре линукс 80% кода от корпорастов.
Корпы проталкивают туда раст или системмд несмотря на GPL.
А копротивленцы могут только ныть и кушать то, что им корпораты приготовили.
> Или оправдывать сношения с детьми...Где в случае RMS такое было, или факты на стол или звездобол?!
>> Или оправдывать сношения с детьми...
> Где в случае RMS такое было, или факты на стол или звездобол?!Если он сам, на своем сайте пишет "Many years ago I posted that I could not see anything wrong about sex between an adult and a child, if the child accepted it."
значит что он так думал.Но потом передумал. Наверное что-то случилось)
stallman.org/archives/2019-jul-oct.html#14_September_2019_(Sex_between_an_adult_and_a_child_is_wrong)
Нет, они последний бастион от окончательного превращения в неудачные аналоги Виндуз и МакОС.
Как будто, GLibc либо способствует, либо препятствует такому превращению дистров. В отношении данного вопроса - индифферентно.
Вот сейчас не понял, Адели был один из нескольких свободных от системд и его компонентов дистром, и тут такое. Видимо Адели в скором будущем можно вычеркнуть из systemd free list. Жаль.
> Вот сейчас не понял, Адели был один из нескольких свободных от системд
> и его компонентов дистром, и тут такое. Видимо Адели в скором
> будущем можно вычеркнуть из systemd free list. Жаль.Вот только сейчас понял что узнал о дистре из самой новости.
Musl для корпорастов, которых от (L)GPL корёжит. Не ведитесь.
По собственному выбору - не ведёмся. Но в некоторые места он пропихнут. Кстати, кто вкурсе, OpenWRT можно собрать с GLibc?
> Musl для корпорастовОн еще для тех, кто не хочет быть вендорлокнутым, чтоб не случилось, - "Упс, у вас версия глибса не та, отказываемся работать", ну и еще тем кто понимает, в чем достоинство статики
Пришло время написать радикально упрощенный аналог system и везде заменить systemd на него
Наконец-то ты решился. Только побыстрее пиши.
На Баше
> На БашеНа баше уже давно есть ;)
Ну тут же кого-то не устраивает, что имеющийся не умеет обрабатывать юниты.
> Ну тут же кого-то не устраивает, что имеющийся не умеет обрабатывать юниты.Они просто не знают как парсить ini файлы в шелах
А вам не кажется что тот "любитель КЕД" который делал скрин что то мутное намутил с кнопками окна и главное зачем?
Ну это его дело. Кеды слава богу позволяют.
Поменял тему и/или расположение кнопок... Потому что может.)
Полезное. Но если переписать systemd с нуля, соблюдая все API, то это уже не systemd. А какой-нибудь systemd-ng.
>Но если переписать systemd с нуля, соблюдая все APIКод системд больше двух миллионов строк кода, там просто вчитаться и понять что да как работает уже история успеха, которой можно не один месяц хвастаться в ИТ компаниях за рюмкой чая.
Ну, вот рядом чуваки на 80к строк сломались и решили что проще переписать, чем читать)
systemd-ngЭто наверное что то хорошее.
а вообще не понимаю "ненавистники systemd" это же стандарт как usb.
> а вообще не понимаю "ненавистники systemd" это же стандарт как usb.Ну так были целые войны стандартов VHS vs Betamax, FireWire и USB, HD DVD и Blu-Ray...
Ну и программные ХОрн против вейланда, H.264, против AV1..А людишкам только дай повод разбиться на групки, чтобы хейтить противоположную.
Буквально хлебом не корми)
> Ну и программные ХОрн против вейланда,Прям война прошлого с будущим. Но ее исход всем известен. Либо будущее наступит, либо нет, но тогда то - совсем п.ц!
> H.264, против AV1..
Это не война, это избиение, у AV1 картинка лучше на битрейте в 2 раза ниже. Воевать пытаются 265/266 и какие там еще за wtfvc я забыл. Но кому они с ТЕМИ условиями теперь нужны?
>это же стандарт как usbГде комитет по стандартизации? А вообще, стандартизация предполагает написание спецификаций, по которым имеют возможность появиться конкурирующие реализации.
> а вообще не понимаю "ненавистники systemd" это же стандарт как usb.Есть еще прогрессивные изобретатели, не желающие ходить строем и в одной и той же юниформе.
Кстати, можно ссылочку на "стандард" ?
От того что девопсы и юзвери повелись на фэйковую быстроту загрузки и заботу о не умных людях чтоб они ненароком в императивщину не ударились, это еще не конец стандартизированного мира
стандарт - это когда есть четкий документ, четкий план поддержки и процедцра его принятия, см. POSIX, или спеку freedesktop.
а не когда у нас на шине висит io.systemd1.<...>, приложениям для доступа к апи приходится лазать в /run/systemd, а единственный документ, uapi spec, мало того, что описывает полтора сервиса, так еще и составлялся не из парадигмы "придумали, описали, сделали свой референс", а "задокументировали свою реализацию"
Ну наконец то Alpine нормальным станет
Alpine или Adelie?
Чем это лучше "rc_parallel=1"?
> Чем это лучше "rc_parallel=1"?Чем Феррари с эмблемкой коня лучше настоящего отборного мустанга лучшей породы?! Ну, вот, тем. Каждой эпохе свои средства передвижения.
>Создатель самобытного дистрибутива Adelie LinuxПосмотрел ради интереса на версии пары пакетов - python и php. Оба древние, с cve. Молодцы, не отстают от дебиана.
сюрприз открою: в дебиане фиксы безопасности бэкпортируют.. надо на источник смотреть, не версию ..
описанные Вами пакеты сейчас в stable-security
>сюрприз открою: в дебиане фиксы безопасности бэкпортируютДа ладно. Только вы учтите, что при обновлении безопаснотси растёт номер патча. А теперь, следите за цифрами: в buster php 7.3.31, в то время как последняя версия в ветке 7.3.33. Вывод - дебианщики не осилили скопировать два патча из апстрима, не говоря уже про бекпортирование уязвимостей, исправленных после прекращения версии 7.3.
>трёхкратное сокращение времени загрузкиС 3 минут до 1?
Расмкажите ему уже о runit и dinit.
Dinit хорош, нравится. Активно развивается.
> Расмкажите ему уже о runit и dinit.Да че там рассказывать в 2000 видел впервые программиста он там все др*чил на winrary и windowsbi ) Я тогда подумал но не настолько же это круто) и все как то измудренно говорил)
systemd самая распространенная.)
> пока одна из компаний не выразила готовность
> профинансировать завершение работы над портома теперь ZOGадка - угадайте эту щедрую компанию с одного раза.
У этих отщепенцев есть LUA в ядре. Вот пусть на нем и пишут