"If you hate systemd so much, then write your own init" they said...

[-]

Apprehensive_Milk520@reddit

I'll never understand why everyone seems to think it is a world of either this or that - let the war begin and the best (whatever) win.

I do not care for systemd, but that doesn't mean I think it shouldn't exist, or that it sucks or that everyone should jump ship for init. It is rather instead a matter of personal preference, one from having long used GNU/Linux before systemd ever came on the scene. And init is a better fit for my aged hardware. To each his own, I don't see why it necessary to take sides and wage war.

I think your initiative to write your own init is truly laudable - what a great learning experience! And that's how most things open source start - some hobbyist daring to create an alternative or something new. I'm certain that's how systemd started life.

It's how the Linux kernel began, after all...

[-]

blackcain@reddit

initd has never been a great system. I say that as a person who started on Unix as a teen in the mid 80s and spent 20 years doing professional systems administration in super sensitive embedded IT department where we wrote our own runlevels. Systemd would have been amazing back then.

Some people just have a rose tinted view of these things and forget. It's like X11, the amount of time I used to look through those X11 library books looking a things back in the 90s. JFC..

[-]

preparationh67@reddit

Truth, switch over machines from initd to systemd and it was night and day. I've yet to actually see a systemd complaint that isn't either a meme, purely ideological, or simply a skill issue.

[-]

UPPERKEES@reddit

What's wrong with systemd?

[-]

dnu-pdjdjdidndjs@reddit

If we're being real its dbus and varlink infestation which both must die but reddit isnt ready for this conversation

[-]

UPPERKEES@reddit

Why?

[-]

dnu-pdjdjdidndjs@reddit

dbus is insecure, slow, and has a terrible ipc format that is badly typed

varlink is json

also async in c is just a terrible idea and meanwhile rust is finding ways to stop deadlocks at compile time

[-]

Top-Rub-4670@reddit

We all agree that dbus sucks, and there are dozens of alternatives that nobody uses.

Safely passing messages between processes is something that is so basic, and so intrinsic to operating systems that it really should have been handled by the kernel. But reddit isn't ready for this conversation either.

[-]

dnu-pdjdjdidndjs@reddit

Wake me up when linux has capabilities based time slice sharing ipc

[-]

MelioraXI@reddit

Haven't you heard, its cool to hate on it.

Though, playing around with Artix on a VM and OpenRC, it is interesting how much slimmer it is and quicker but lot of manual quirks when you're used with all the out-of-the-box stuff systemd provides.

[-]

UPPERKEES@reddit

Yes, it's indeed popular to hate on systemd. That seems to be the only reason for many.

[-]

aigars2@reddit

Great and couldn't care less.

[-]

nekokattt@reddit

who shat in your cornflakes this morning?

[-]

Niwrats@reddit

death to systemd! all hail init system freedom!

[-]

UPPERKEES@reddit

Why?

[-]

Niwrats@reddit

first, some of us are born rebels, and we want to rebel against something. second, init system freedom is about having options, which seems like a good cause.

[-]

UPPERKEES@reddit

You do have options... Distros chose systemd because it's the best. But you can still go for something else, if you really want to.

[-]

VividGiraffe@reddit

More it was chosen because it has IBM backing it. Personally I don’t mind it at all, but let’s be real.

[-]

UPPERKEES@reddit

What are you talking about? Most distros use systemd because it works very well. IBM has no influence on all those distros.

[-]

sparky8251@reddit

The init wars also clearly show it wasnt just "lets do systemd because" as well. Systemd won on its merits, end of story. I don't know why its so hard for people to grasp though sadly...

[-]

UPPERKEES@reddit

Systemd does it best, that's why it's used everywhere. There is no conspiracy. If there is, share some hard facts.

[-]

sparky8251@reddit

What? I said it "won on its merits, end of story". Why are you acting like I'm saying its bad?

[-]

UPPERKEES@reddit

Ah, I thought you were the same guy I was talking to in this threat. But no. You're not the IBM conspiracy guy. We agree.

[-]

Niwrats@reddit

this is like saying that PCs come with windows because it is the best option. you can still go linux, if you really want to.

[-]

dnu-pdjdjdidndjs@reddit

Arguably windows is the best for normal users and before like 4 years ago it very obviously was the best for nearly all use cases

[-]

UPPERKEES@reddit

No it's not. A distro shouldn't have to go through the trouble to support more than one init. But there are distros that support non systemd setups. Feel free to use it if you enjoy pain.

[-]

Key_River7180@reddit

i once made an init in awk... it is much worse than this thing.

[-]

Se1d228@reddit (OP)

My init is not ideal too, old inits are years of polishing, my is relatively new, so it's buggy

[-]

Key_River7180@reddit

yeah, but yours boots, mine has a 1% chance of booting

[-]

TRKlausss@reddit

Well computers are deterministic, so it either boots or doesn’t… So it truly has a 0% chance of booting :D

[-]

DoomBot5@reddit

They very much are not. Lots of factors contribute to "random" bugs. That's why race conditions exist.

[-]

TRKlausss@reddit

Those factors that you are talking about are well understood and avoided where possible. Race conditions exist due to schedulers, an those have a deterministic way of scheduling tasks (which could be event-driven, like with interrupts etc).

But determinism is defined as “given the same inputs, it produces the same outputs”. That “randomness” that you are talking about is because you didn’t consider an input to your system (e.g. an Event, a timer/interrupt, etc) that is causing a different output.

Otherwise, it would be almost impossible to de if these systems at all. Imagine if 2+2 was different every time…

[-]

claytonkb@reddit

*FDIV bug has entered the chat*

On a more serious note, Computers are not deterministic, they are deterministic-ish. As soon as you have more than one clock in the system running asynchronously, you are dealing with physical non-determinism. A typical PC has probably thousands of asynchronous clocks running all over the place. Not deterministic.

[-]

TRKlausss@reddit

Fair to say that, it does depend on clock propagation, and you can’t ensure that two systems have the same electrical characteristics for the signal to arrive at the same time… But they are designed within operating margins, so…

With respect to FDIV: even that bug was deterministic: specific pairs found in the table produced specific outputs, but always the same output. So, even though it was deep, it behaved always the same…

[-]

Key_River7180@reddit

=D

i mean that it is buggy as fuck

[-]

TRKlausss@reddit

Just pulling your leg a bit :D

But I’d recommend something: try it in Rust. Not because RuSt SuPeRiOr, but it might help you with your mental models of why your other implementations may contain said bugs.

[-]

Key_River7180@reddit

i don't like/know any advanced/use rust. It was just a little recreational programming experiment, nothing serious anyways.

[-]

mr_sesquipedalian@reddit

No idea why you have downvotes, bc it's a good joke.

[-]

MathSciElec@reddit

A single core is deterministic (to the extent allowed by physics) but when multiple cores enter the equation you can have nondeterministic behaviour such as race conditions

[-]

Se1d228@reddit (OP)

you just gave me an interesting idea... knowing me, I will implement "1percboot" config

[-]

Jeremy_Thursday@reddit

😂 ahh yes, something for people to go hmmm I wonder what this flag is? Maybe also add `--random-delay` that just injects a random amount of sleep to init.

[-]

avinthakur080@reddit

"init in awk"

I can't even imagine what and how would it work. Hadn't there been this sibling comment, I would've assumed this is joke but I'm intrigued now.

How ?

[-]

Key_River7180@reddit

awk has a system function to execute commands

[-]

Se1d228@reddit (OP)

Unemployed programmers are discovered at 0,000001%

[-]

No-Mind7146@reddit

Can i see the source? Looks cool

[-]

Se1d228@reddit (OP)

Here: https://gitlab.com/Se1d228/laked , but they are not up to date, will commit tomorrow, fighting /dev/pts right now

[-]

AnsibleAnswers@reddit

It can't monitor services, manage login, be a bootloader, perform age checks.

The systemd-init binary can’t do those things either.

[-]

Se1d228@reddit (OP)

systemd is bunch of binaries, laked is bunch of binaries too, systemd can, laked can't

[-]

AnsibleAnswers@reddit

Systemd-userdb cannot actually “perform age checks.” Don’t fib.

I absolutely love the fact that gummiboot became controversial based on a simple name change. You don’t like boatloader freedom?

[-]

lorenzo1142@reddit

don't cloud the conversation with symantics. it facilitates age verification.

[-]

chocopudding17@reddit

It facilitates age verification just like GECOS has facilitated identity verification.

Also, this talks about how systemd-userdb isn't even the first unix-y user database to do this! (It's worth it to note that that comment is from one of the systemd developers. Doesn't change the fact that it's true of course. Also, this other comment from Lennart Poettering is also a good read.)

[-]

lorenzo1142@reddit

oh, if someone else is already doing it, must be fine.... sure....

problem is, cannot question this choice. if you even mention it on the systemd github, they will delete it and block you.

[-]

chocopudding17@reddit

oh, if someone else is already doing it, must be fine.... sure....

This is lazy. Please do better. The point is that this is simply an optional database field. An optional database field with historical precedent nonetheless. If you don't want to use it, then don't use it. In fact, this is free software! If you want to patch it out, then patch it out.

problem is, cannot question this choice. if you even mention it on the systemd github, they will delete it and block you.

Of course you can question it. It's fine and good to question things. But that doesn't mean that you get to make content-free complaints wherever you feel like it without anybody blocking you, locking threads, etc.

The systemd issue tracker on GitHub is not a general forum; it's for reporting bugs and submitting RFEs. This was a contentious issue, and the vast, vast majority of "commentary" on it was vile and lacked any substantial understanding of what was going on. Even if you had something new to contribute to the dialogue (which, so far, it doesn't seem like you do), it'd be understandable that it'd be hard to make your voice heard because the other morons are complaining so loudly and need to be blocked.

[-]

lorenzo1142@reddit

show me one open ticket on the systemd github where people are allowed to talk about this. every one of them is locked and they will delete any new tickets you attempt to open, and they will ban you.

[-]

chocopudding17@reddit

Quoting myself:

The systemd issue tracker on GitHub is not a general forum; it's for reporting bugs and submitting RFEs.

The systemd-devel mailing list is where broader discussions take place. If one can stay constructive and in-tune with the facts of the matter, I would assume it'd be received just fine. Given what you've demonstrated so far though, that's unlikely to apply to what you have to say. So the mailing list probably isn't the place for you either.

[-]

lorenzo1142@reddit

the point is, the systemd maintainers refuse to allow anyone to even mention it. they want to support age verification and no one may question it. bow to them, kiss their feet.

[-]

chocopudding17@reddit

Stuff like this shouldn't be allowed there because it doesn't actually engage with the reality of what the feature is. As said, this is an entirely optional database field that is entirely under control of whoever controls the user database, i.e. the administrator.

Systemd is supporting functionality that other projects (in this case the xdg portal people) wanted and contributed. To wit, a snippet from Lennart's comment:

Hence, the birthdate field is a common thing, not a thing systemd pioneers here. I do believe systemd should take a design backseat here: it just maintains a user database here, is more of a provider than a consumer, and hence it should just provide the fields in a well-defined format if people want it, if it makes any sense at all, if it's a common enough thing and so on.

Hence, to me the situation has been clear, and still is: it's a relatively well defined concept, it's otherwise already well established in similar database schemes (both in the Open Source world, and beyond), and we already maintain similarly sensitive (or non-sensitive) data in userdb, hence it's absolutely fine to be added. And so we did. This is entirely independent of its potential use in any age verification system, because I can come up with at least as many good, valid usecases for this field than bad ones. For example, parental controls are generally a good thing (I speak as a parent), and yes, I also think showing in calendars birthdays of people so close to you that you share a machine with them makes a ton of sense...

[-]

AnsibleAnswers@reddit

An optional field in an optional user database can’t hurt you.

The user database already includes fields for personally identifying information. You should have more faith in the community. The community will provide non-compliant software to those who want or need it.

[-]

lorenzo1142@reddit

so if they add an optional field for your photo, bank account number, social security number, the school schedule of your children.... that's all fine because it's optional.

problem is, cannot question this choice. if you even mention it on the systemd github, they will delete it and block you.

[-]

Top-Rub-4670@reddit

so if they add an optional field for your photo, bank account number, social security number, the school schedule of your children.... that's all fine because it's optional.

....yes? All of those could be useful in some specific context.

What's the harm in having a defined OPTIONAL way of storing that information so that it can be shared between many applications effortlessly?

[-]

lorenzo1142@reddit

my computer doesn't even need to know my real name. we are on a slipery slope, and we are not allowed to question it.

[-]

AnsibleAnswers@reddit

If your only argument is a well-understood logical fallacy, then you can expect people to just tell you to shut up and let the adults handle this.

[-]

AnsibleAnswers@reddit

Your avatar (an image representing the user, usually your photo in a corporate setting) actually goes in a User Record Blob Directory. So the field for your photo is already there. Not shocking given that you can pick an image for your user account in modern DEs.

if you even mention it on the systemd github, they will delete it and block you.

That's what happens when you brigade an issue tracker with complaints about the existence of an optional field in a database that you don't need to use. I don't think you understand that project decisions like that are generally not up to a vote. Someone did the work to include an optional field that is in scope. It gets tested. If it works, it gets merged. If you don't want to use it, you have plenty of options. You could simply not use the optional field. Or, if you don't want to catch cooties or something, you could use a distro that doesn't include systemd-userdb or compiles systemd-userdb without the field. Systemd-userdb isn't really needed outside of an enterprise environment with directory services, anyway...

[-]

CardOk755@reddit

Of course it can

[-]

SithLordRising@reddit

Like the cat

[-]

cmrd_msr@reddit

*Waiting with interest*

[-]

goldmurder@reddit

i wonder how much time would it take for systemd haters to realise, that systemd is not just an "init system", and it's great

[-]

ruby_R53@reddit

systemd is not just an "init system"

ain't that one of the very reasons why it's hated?

[-]

goldmurder@reddit

the very reason why it's hated is because people are dumb. everything lennart poettering wrote in "rethinking pid 1" is true, i guess since many of those who hate systemd didn't even open it actually do hate systemd because of that

[-]

baynell@reddit

Nice. My expertise level will never be on that level. Admirable.

[-]

TRKlausss@reddit

It’s all starting somewhere. One thing that you have to grant to the whole LLM/AI craze is that information is much more accessible. Sure, AI makes mistakes and what not, but they can point to official documentation as well…

[-]

herbertplatun@reddit

I hate AI, but I must agree with you. There are certainly advantages in that regard.

[-]

baynell@reddit

My friend guided me towards self hosted LLM. It's not as good as ChatGPT or other publicly available LLMs, but maybe that could relieve some of your hate towards it.

https://github.com/ggml-org/llama.cpp

https://huggingface.co/models?apps=llama.cpp&sort=trending

I am running it decently well with 5600G and 32gb ram. Calculation happens in cpu.

[-]

TheInevitableLuigi@reddit

What model are you using?

[-]

baynell@reddit

I am using mostly Qwen 3.5 9B Q4 or Meta Llama 3.1 8B Q6.

I am not sure which I like the most, they all feel kind of on par with each other.

I also have GPT OSS 20B Q4, but I usually start the server with Qwen, for no particular reason.

[-]

herbertplatun@reddit

Have you tried Gemma 4?

[-]

baynell@reddit

I have not, this one? I didn't want to make an account to download it.

Or this one?

Would you recommend it instead of those others?

[-]

SquareWheel@reddit

If you're interested in self-hosted LLMs, it's worth having a HuggingFace account. Some of the better models require it for their license sign off, and they do have a neat feature where it'll approximate which models you can run if you enter your hardware specs.

Qwen 3.5 is a great model, but Gemma 4 is the new hotness. Both are worth playing with for the vram-capable.

[-]

TRKlausss@reddit

It’s just a tool in the end. The huge problem comes from it surpassing the uncanny valley and people thinking that they are talking to “something living”, trusting it 100%. That leads to people not using their brains, which was something I was already questioning before LLMs…

[-]

UristBronzebelly@reddit

AI made Linux adoption so much easier. Having essentially live tech support that can tell me what terminal commands to enter, why I am entering them, what each argument in each command means, has been so helpful.

[-]

Craftkorb@reddit

Absolutely. I've recently started working on a new personal project that's in a niche I haven't worked on before. I told the LLM that I don't want it to write code for me, and that the primary goal is for me to learn the stuff. And it's been an incredible tool.

[-]

TRKlausss@reddit

That’s the way of thinking tbf. Use it as a teacher, not as an employee.

[-]

baynell@reddit

Yeah, maybe I could, but it would require a huge investment of time and sanity.

If there was innate motivation, I would do it regardless of those mentioned above, but the initial learning phase seems like a huge wall, it is really difficult to start. It's nice to learn things like Python, it's easy to start with and the progress is fast.

[-]

TRKlausss@reddit

That’s where things have changed quite a lot with LLMs. I feel like that learning curve has eased up a lot. Use with caution though :)

[-]

Uhstrology@reddit

The information has always been just as accessible through Google, and its verifiable.

[-]

TRKlausss@reddit

Not really, Google doesn’t index everything. Sure, it can send you to a datasheet/docs somewhere, but understanding it is a learning curve.

Now, ask an AI, and it will water it down so that you understand it. Bad for someone that doesn’t want to think, great for someone that is just starting on this.

[-]

Se1d228@reddit (OP)

If you want it to be, it will, everything depends on your wish

[-]

T02369@reddit

320kg 💪 our 🐘

[-]

revilo-1988@reddit

My hero

[-]

richardxday@reddit

"Code and error messages hould..." - should be 'should'?

[-]

Unique_Technician984@reddit

What about openrc? Systemd bye bye

[-]

goldmurder@reddit

openrc is significantly slower, doesn't have socket, service files are written on shell, not the best option

[-]

Se1d228@reddit (OP)

I use openrc when my init panics to fix it, it's good and it has /dev/pts

[-]

int23_t@reddit

/dev/pts is not something init does, it's what postinit script does.

Try adding these two shell lines(in whatever way you add them) to your init

mkdir -p /dev/pts
mount -t devpts devpts /dev/pts -o noexec,nosuid,gid=5,mode=620

(I had the exact same issue when trying to switch to sinit from openrc on a VM, and I coppied mount options from openRC's script that handles this

[-]

Se1d228@reddit (OP)

I tried, it doesn't want to mount from service files, pre init (maybe) or root tty, that's all

[-]

int23_t@reddit

Did you try mounting it before remounting root as rw?

you should add the -n flag to the mount too to do so IIRC.

Also your /dev should be devtmpfs

mount -n -t devtmpfs dev /dev -o nosuid,noexec,mode=0755,size=10M

mkdir -p /dev/pts -m 0755

mount -n -t devpts devpts /dev/pts -o noexec,nosuid,gid=5,mode=620

would be the whole thing, along with mounting /proc and /sys similarly to /dev, all of which are done before remount / as rw.

[-]

Se1d228@reddit (OP)

should try

[-]

ArsenicPolaris@reddit

Pretty salty people in the comment section here. Good job on that, by the way, OP!

[-]

blackcain@reddit

I think it would have been better to just have hacked initd directly. I mean it works and people depended on it? If you're just re-implementing runlevels and boot making it work just like initd, just use initd? I guess I don't understand why you'd start a new project. I mean I just assume the author didn't think initd was broken. What's the difference between their implementation and initd?

[-]

Se1d228@reddit (OP)

Difference is custom runlevels, directory name is lake.d because I think of people that have multiple inits on pc

[-]

blackcain@reddit

You can do custom runlevels in initd. I know, I implemented one back when. It's not hard. I don't see why you couldn't just create helper scripts around initd.

Sorry, I don't mean to harsh your mellow. The world has changed, and continues to change. Even the notion of how distro engineering works is changing rapidly.

[-]

Sbatushe@reddit

seems so transparent and clean, good job! will read it

[-]

acecile@reddit

Very nice GIT history.

Thanks for this pièce of useless AI slope.

[-]

arades@reddit

written in 100% rust with no C dependencies Every other file has completely undocumented unsafe blocks with direct calls to libc

I mean yeah there's no way around libc dependency, but a little comment to reassure the reader that you did think through if those fds were valid before passing them would go a long way.

Either that or use some existing safe wrappers, since you already have some big dependencies like serde in there

[-]

dnu-pdjdjdidndjs@reddit

rustix can bypass libc

[-]

Se1d228@reddit (OP)

You're right, I should put comments to unsafes. Since laked is PID 1, direct calls to libc are inevitable for things like mounting and ioctls. Serde is used to parse service files

[-]

ShakaUVM@reddit

I've never written an init before nor had any desire to. What are the steps that goes into making one? I kinda want to learn now

[-]

Se1d228@reddit (OP)

I'm not going to say that's it's hard and it's years of work, I will say as it is. First you must mount filesystems and root in code without /bin/mount, then you have to make your init execute programs from folder, like /etc/init.d, you can execute them as shell scripts, then you have to make shutdown, fight devpts, do some polish and you have working init! Remember: INIT MUST BE ALWAYS ACTIVE, otherwise kernel panic

[-]

dnu-pdjdjdidndjs@reddit

You basically got the easiest part done. See if you can keep the actual pid0 process as minimal as possible, and you can use build-std to make the binary a reasonable size, also use CU=1 and immediate-abort.

The problem I think practicality wise is if you want a full replacement for the things systemd does, suddenly the scope becomes much crazier. The service manager should enforce sandboxing from day one, processes should be as isolated as possible. You'll need an efficient ipc mechanism that's secure and easy to use and reasonably fast for this, dbus is insecure ipc by default, you can make it better but it becomes complicated and its slow and the zbus bindings are huge for safely handling dbus, and you need xdg dbus proxy or equiv for every service. In the case you ditch dbus you would also need replacements for upower, bluez, networkmanager, not to mention if you want things to be useful for corporate use cases you now need systemd-networkd replaced, a proper logging daemon for efficient logs, a userspace management tool to replace systemctl, and a bunch of other things.

For a toy use case the fact that logind has seatd as a replacement is pretty helpful, but new DEs rely on systemd user services since its more efficient and keeps things like pipewire up if it crashes and stuff like that.

[-]

SeriousPlankton2000@reddit

We do have a perfectly working sysv init, it's other people's effort that has the goal to only make systemd work.

[-]

Se1d228@reddit (OP)

I made it because why not? It's just my hobby

[-]

play_minecraft_wot@reddit

This is the correct answer. That is the philosophy of GNU/Linux.

[-]

fek47@reddit

Precisely 👍

[-]

Successful-Peak-6524@reddit

And now you understand how cool systemd really is.

[-]

eattherichnow@reddit

Is skeptical.

Sees GPL.

OK, better, but still skeptical.

Sees the cat.

OK fine, I"m gonna pay attention now.

[-]

Se1d228@reddit (OP)

This cat is not only in readme

[-]

lorenzo1142@reddit

I plan on attempting my own init system, when I have time for it.

[-]

Se1d228@reddit (OP)

I wish good luck to you

[-]

gosand@reddit

Ah, but systemd isn't just an init system. Per wikipedia it "is a software suite for system and service management on Linux". And it will keep growing, and growing.

I don't want all that, so I don't use systemd.

Cool that you can write your own init. Just curious, did you look at the code of the other init systems out there for any inspiration, or to see how they handled some of the details?

[-]