then i start to find out it is full of rando backdoors intended for VMs, which will run just the same on your bare metal. For example, just to list the very last one, you can inject smbios data that will be parsed to create files in your system. very convenient to drop passwords and keyfiles around a vm... unless it is the firmware on your actual bios doing the same. And we know how common persistence via bios is. sigh.
but as you mention correctly, it have crushed and dominated linux. so i guess i just waste a week or some working around those things later, as usual.
All it takes is to look around at what Microsoft is doing to gestures vaguely to see the writing on the wall for how Microsoft sees Linux.
Advertisements on the home screen? Advertisements on the every screen? Login darkpatterns? Configuration resets on updates? Forceful browser choices? Forced updates? UEFI shenanigans? Boot manager shenanigans?
As proven by OEM distributions on by gone netbooks, and Android flavours, OEMs will always do what they do best.
In what concerns Windows, unfortunately it appears only Azure, Office and XBox matter now.
LOL
Its amazing how easy it is. I guess if you spend your entire history being a shitty company and then spend a couple of years pretending to be marginally less shitty then you can dupe a bunch of people.
I do think they had commercial aspirations work systemd, but more about "being the company that invented..." Than a direct cash cow.
This is in contrast to the play canonical makes with snaps that has 30% app store tax written all over it.
Do you have some links to share?
Now working on a replacement to systemd-tmpfiled for OpenRC.
Run these sysvinit, OpenRC and maintain systemd as well at this shop.
Also who are these people who have complicated sysv scripts? I've heard this for years and never really understood it. One script per service with a stop and start command (and maybe a status if you want to get fancy) and runlevel definitions that start and stop them. It's not rocket surgery, and it's a hell or a lot easier to debug than a declarative system definition.
Into correct imperative sequence. That’s the whole point of declarative things.
You can’t feasibly write it correctly otherwise. You are writing programming languages over assembly for largely this same reason.
FreeBSD has Mewburn rc not van Smoorenberg rc and was thus inherently better in this regard until the middle of 2014 (https://unix.stackexchange.com/a/480897/5132). But even FreeBSD has some large rc scripts, particularly in the networking and the HID parts such as Bluetooth and configuring all attached keyboards; albeit that the FreeBSD style guidelines mean that they are more legible than the nightmare Debian (et al.) ones.
Startup is ultimately a complex problem. There is no magic, just race conditions which maybe became more apparent. LVM may or may not be used, and takes time to start up. Do you wait for it? Ditto wireless networks. And how do you handle devices being hotplugged? Setups vary widely, and can be dynamic.
??
Mount filesystem, start networking, start networking daemons, update crappy gtk stuff, run rc.local.
What is so complex ?
It was run in the middle of rc, not at the end; as pointed out in the OpenBSD manual.
So OpenRC was "normal" for me, and when the systemd debate came around I didn't think about the fact that OpenRC wasn't the norm and folks hat been using SysV init all that time.
I'm still a Gentoo user these days (although not as heavily, the laptops are running Fedora nowadays), but running systemd. The unitfile format is really great.
I remember being stuck in a holiday let in the arse end of Somerset, whilst waiting for a house purchase to grind through to a conclusion. Around 2009. I got pppd to use both of our mobiles via bluetooth to get some sort of rather sad internet connection together so we could browse rather slowly and email etc.
All of that was done in /etc/conf.d/net - one file! You can also put a firewall together with it and generate routing tables and all sorts of things. I have no idea why netplan needed inventing, when net already did it all without the bloody YAML! OK - slap YAML on net. Job done.
I don't miss Miguel van S's sysvinit scripts and all the peculiarities in the various ways of doing them by distro.
I did try to write OpenRC initscripts but they are still too complicated for a simple sysadmin like me. I have used git to get an elderly Gentoo box from 2007 to 2022 - so can attest to the sheer robustness of the distro. It did take some doing.
I think that the greatest gift that Gentoo gives to its adherents is this: No matter how broken a Linux box is, provided the storage is operational, the CPU can crunch stuff and RAM is mostly functional and there are not too many holes in your files, you will repair it.
Oh and it has always had the best looking terminal in all modes, bar none, for decades.
Cheers: Uberlord.
[EDIT] Took me a while: https://web.archive.org/web/20211120235128/https://roy.marpl...
Thought that was petty exciting. On this note, I think I will finally overcome my anxieties and make July the month I finally install Gentoo!
Go for it - it really is rather satisfying. Your lap will get rather warm if its a laptop! Stick to the manual and don't get too hung up on minutiae until you have to. I do recommend ~amd64 (the ~ is very significant). Although ~ means something like "beta" you tend to get much more modern software. Make sure you have another route to the internet to find out how to fix breakage because it is inevitable with Gentoo.
I leave the compiler output to fairly verbose and found it hypnotic and very satisfying to watch. I could tell what was being compiled just by the shape of the output.
The wiki and forums are superb.
You might consider running it in a VM at first to get the hang of it and make use of snapshots/checkpoints to back out failed experiments. You could turn that into a stage 4 and recover to bare metal (if you dare!)
Cheers from Yeovil.
Personally I just wish it had any notion of logging stdout/stderr, or a way to manage daemons as a user.
[1]: https://github.com/OpenRC/openrc/blob/master/service-script-...
You have piqued my interest and I will spin up a VM at work and have another look at the state of the art on Gentoo.
I absolutely loved it back in the day. Every few months or so a major change would arrive and make life better. Sets - @world etc - smashing. User patching - drop a patch in a suitable directory and effectively you could fix snags yourself without having to write your own ebuild. Do your own ebuilds - again drop your override into the right directory and your personal ebuild is seamlessly part of the distro.
No doubt much more has happened in the roughly five years when I have used it in anger. Ironically enough I have two systems at work that do run Gentoo but are woefully "legacy". Today I emerged a couple of packages to fix something on one of them and it is still hanging on in there. It is quite a delicate dance on a rather crucial system. I will get rid of it eventually but one step at a time 8)
Through being voted on/carefully chosen based on merit.
That said, OpenRC also looks to be a nice system that does its job well without function creep, which is more than I can say for systemd.
I'm pretty happy with Systemd these days, and in some ways I don't mind the way it has as 'standardized' (read: dominated) Linux stacks. But I'm glad that people are still doing the work to keep OpenRC viable and integrating it into a full-featured, long-lived, relatively popular distro.