Post B4YO6PgzLvXPIeG3A8 by q66@gts.q66.moe
(DIR) More posts by q66@gts.q66.moe
(DIR) Post #B4YO6PgzLvXPIeG3A8 by q66@gts.q66.moe
2 likes, 1 repeats
i don't get people whose response to all the init nonsense discourse as of late is "actually traditional init is nice, see, you can just go and modify these shell scripts"no it's notit's inflexible, annoying, harder to use, and harder to make out what's going on whenever things get more than very very basicif there's something really bad about the bsds it's the crusty rc systema supervision system (ideally a dependency-based one) can be far nicer, more flexible, more readable, and actually meeting what most people expect out of a computer these daysi don't wanna go to systemd, i sure as hell don't wanna go back to the old days either, we can do way better
(DIR) Post #B4YQRxH7t4klRdYohE by domi@donotsta.re
1 likes, 0 repeats
@q66 “actually traditional init is nice, see, you can just go and modify these shell scripts”no it’s notnominally i’d agree that traditional inits are missing a bunch of things, but. live and let live, please.the most painful part about this whole discourse is that a bunch of folks are fighting about what’s better, while this depends solely on personal preference (and for some people and some applications traditional init may actually be sufficient)i just want to use my toys and be happy about it ;~;
(DIR) Post #B4YUcltYwDkd9Ux5Lk by q66@gts.q66.moe
0 likes, 0 repeats
@domi i mean, everyone can use whatever they prefer, nothing against thatit's just that it feels like this is all the same stuff that eventually caused systemd to become the default choiceand i don't mean people using "traditional" inits or whatever because again, i'm not here to deny anyone thatbut "this is fine and gotta be fine for everyone" kinda attitudes which i still see lots
(DIR) Post #B4YUcm4uG2pDigG920 by domi@donotsta.re
0 likes, 0 repeats
@q66 what I wanted to highlight is that in response to people having said attitude, you expressed the same attitude but 180° on the opinionI absolutely agree that “this is gotta be fine for everyone” is just plain wrong. hell, i wrote a blogpost about this exactly a few days ago.
(DIR) Post #B4YUpGMNUqhL70O1iq by q66@gts.q66.moe
2 likes, 0 repeats
@domi well, that's fair enough i guess, sorryit's hard to not fall into that
(DIR) Post #B4YUr5gU9wvOa5fBFg by domi@donotsta.re
0 likes, 0 repeats
@q66 oh, i’m aware :neocat_pat:
(DIR) Post #B4YXUIOH3FtFBty1Ee by navi@social.vlhl.dev
1 likes, 0 repeats
@q66 > a supervision system (ideally a dependency-based one) can be far nicer, more flexible, more readable, and actually meeting what most people expect out of a computer these daysi mean openrc is both, dependency based, provides supervision, and makes it so the most common init scripts consist of only about 3 variable definitions and nothing elsebut it's also a init script under the hood, so if anyone is so inclined, they can go and modify things, replace the default start() with custom logic, or keep the default start and add extra things on start_pre(), stop_post(), whateverthis duality and flexibility is what made me like it so, enough to step up and take maintainershipimo openrc is very much "doing better" while still being shell, though i do appreciate the different directions other init systems went for a lot too
(DIR) Post #B4Ybu4UBlqH7PdHQ2K by overeducatedredneck@bitbang.social
0 likes, 0 repeats
@q66 If you're subtooting me, supervision systems are something I'm going to follow up about. "traditional init is all we need" wasn't my point (and honestly, you weren't my target audience, you are one of the small number of people who knows more about init than I do).At the same time, BSD inits work great for my needs. They're consistent and predictable, which is more important to me than flexible.(dinit is pretty nice. I wish it wasn't C++, but nothing's perfect.)
(DIR) Post #B4Ybu4ft4LdHzuklGq by q66@gts.q66.moe
0 likes, 0 repeats
@overeducatedredneck what am i supposed to be subtooting?dinit being c++ is very good, have you ever written asynchronous event loops in c (not to mention that it's *much* safer that way)
(DIR) Post #B4Ybu4qAS7r8VnYyIK by overeducatedredneck@bitbang.social
0 likes, 0 repeats
@q66 I've written them in C, go, rust and python, but not C++. I typically avoid C++ as I find it to be a big mess, but yeah, C is harder to get right than the others. I'll go do some RTFS on dinit, then.I posted a blog post yesterday doing a code read of the OpenBSD /etc/rc file. Mostly as a document I can point people at for building a basic understanding of init, with a bit of focus on what needs to be understood for doing system recovery work.
(DIR) Post #B4Ybu519nGe93shkQK by q66@gts.q66.moe
0 likes, 0 repeats
@overeducatedredneck it just gives you whatever c gives you and a mostly usable language on topsure it has its deal of crusty nonsense but i don't see a reason to write c over c++ for most things pretty much everunless your hobby is writing hash tables and fighting bugs caused by missing type system
(DIR) Post #B4Ybu5ANF01FWT16n2 by overeducatedredneck@bitbang.social
0 likes, 0 repeats
@q66 I use C as portable assembly language, for legacy codebases and ecosystems (eg: my wayland compositor is in C to match wlroots).I'm in the camp that thinks C++ devs should stop writing C++, integrate rust and migrate over (not rewrite from scratch, just new dev in rust, and migrate opportunistically). But doing something like init in rust would be painful due to the rust devs being unable to settle down and become a stable base language.
(DIR) Post #B4Ybu5LMa8oG4Y9sv2 by q66@gts.q66.moe
1 likes, 0 repeats
@overeducatedredneck rust has an unusable ecosystem of dependencyslop, generates massive binaries, and is borderline unreadable without a big pile of tooling, no thanks