Well, he builds a lot of stuff that works better than the existing stuff but forces everyone to rewrite everything to work with it. So a company like RedHat picks him up because that’s good for their business. Examples being PulseAudio, dbus (basically POSIX MQ with a layer of terrible), and his magnum opus, systemd
You have per app volume control with OSS but Linux people hate it for some unknown reason. Seriously just go back go OSS. That’s what I do on Linux boxes.
I was just as surprised as Poettering. I was more surprised to discover the “ignore . and ..” behaviour was mandated by POSIX, and followed by FreeBSD and OpenBSD—it seemed like the kind of user-friendlness that gets GNU tools dismissed as over-complicated.
Turns out Plan9’s rm has no such limitation, though, so my faith in minimalism was restored.
That’s a good question. Assuming I’m reading the source code correctly, it just recursively tries to remove() every name that dirreadall() digs up. dirreadall(2) does not mention hiding .. entries, but it also doesn’t mention that they’re included either. intro(2) mentions the kernel normalising relative paths, and paths containing . and .., so maybe dirreadall() doesn’t return such things?
It’s pretty simple: The directory doesn’t contain . or .., so they don’t need to be filtered. This also means that ls .* doesn’t include them, and thatrm .* doesn’t need to do anything special to be safe.
The real answer, bar ‘no,’ is ‘depends on the shell.’ Zsh will do exactly what you mean when issuing this command. Bash otoh has bitten me with this one, though.
The way the shell chooses to expand wildcards has nothing to do with how rm behaves w.r.t. . and ... rm specifically filters out any dots that the shell happens to pass along on its end. Here it is in FreeBSD, and here it is in GNU Coreutils.
The point was that zsh won’t pass rm the paths . and .. to begin with using that glob. The way bash expands that glob could cause problems with other commands as well that don’t explicitly ignore . and .. like rm. The zsh expansion just seems more in line with what the user would want, in my opinion.
NIHing everything but nevertheless making mistakes that had been understood and fixed decades ago – this is why many people have negative attitudes towards systemd. I’ve been using it for many years but still the insistence on reimplementing things in shitty and incomplete ways (journald is a shoddy half-baked reimplementation of sqlite, say) frustrates me to no end.
I only see the systemd things that make it to lobste.rs, so pretty heavy bias, but I don’t think I’ve read a single one of these bug reports where systemd does something unexpected and horrible where poettering has responded with “yep, this is a bug and sorry we’ll fix it”. It’s just weirdly anti-user. I don’t know if Linux users just don’t care or they’ve just given up after all of the init daemon’s various Linux distros have gone through.
I wonder what things will be like in 10 years once systemd is everywhere. Maybe people don’t dare touch the default config and just work around issues in odd ways or people are just miserable but need to wait for the next generation to come along to be energetic enough to propose a whole new init system and deploy it.
I’m pretty sure we’ve given up. Also pretty sure it’ll be a miserable mess of workarounds and hacks.
Hopefully, then, someone starts advocating for Runit or the suckless people resurrect Uselessd, because there is sanity left in the world. Practically no one uses sanity, though.
OpenBSD offers nice bsd.rd images which can be loaded into RAM and started with your favourite bootloader.
That means you can get yourself any KVM (or similar ‘real’ virtualisation) vps (these can be really cheap, starting at €1/mo or even less), choose a Linux template and manually install OpenBSD pretty quickly.
Here’s a nice guide documenting the process. Bear in mind you might need to change the set root=(hd0) in the grub config. For example one some boxes I have I had to use set root=(hd0,msdos1).
Is there anything that keeps you from using one of those handful of providers? As far as I’m aware, they aren’t significantly more expensive than their competition.
I recently tried to get OpenBSD working on Vultr, which is one of them.
If I remember correctly, no matter what I did, sudo refused to recognize that a user I added was in the “wheel” group, even though the command to list a user’s groups showed that was the case.
It was really strange, and after a few reinstalls etc, I gave up.
I have a few OpenBSD VMs on Vultr and they work fine (aka, Works on My Machine™)
Without any more details the problem here could have been anything. Did you log the user out and back in again after changing the group? Maybe you didn’t put a colon in front of the group name in doas.conf? If you were using sudo, did you uncomment the required line in sudoers?
I use Void for work where I need to use Linux, 10/10 would recommend.
For anyone who does use it, the only thing that tripped me up is you need to install git-perl and possibly git-extras in order to get whatever else you normally get when you install git. After learning that, I got used to the extreme package granularity so I don’t remember if it’s that way for anything else, as that’s now always the first thing I check when a command was suspiciously missing.
Hopefully, then, someone starts advocating for Runit.
I’m surprised none of the BSDs have adopted a daemontools derivative into base yet. Seems like a match made in heaven: a small and carefully written codebase, a focus on simplicity and reliability, directly executable service scripts, no action-at-a-distance pidfile nonsense, sane log rotation. I suppose you can chalk up the inertia to the conservation laws which govern the BSD world. Which, viewed from the systemd angle, look more like a virtue than a shortcoming.
Well, for me, the daemontools everything in a maze of symlinks configuration is really alien. One can argue its merits, but it’s definitely different, and not clear how one evolves from some simple rc scripts to that.
Fair. Maybe there’s a good rc-to-daemontools migration guide, but I usually just write the ./run file from scratch and chuck all the supervision and logging boilerplate in the rc script. You won’t need the vast majority of it.
The daemontools everything in a maze of symlinks configuration is really alien.
It definitely is at first. The only symlinks you really need are of the form /var/service/foo -> /etc/service/foo. Those are necessary for clean uninstallation of services (see “How do I remove a service”), and that has to do with how svscan and supervise coordinate directory-based operations.
Convention recommends some other symlinks though. Some people don’t care, but I like to have foo/supervise, foo/log/supervise, and foo/log/main point back into /var for hier(7) reasons. For services that serve from filesystem state, a foo/root symlink is a good idea, as it lets you do atomic deploys via atomic symlink replacement.
There is definitely a selection bias here. Here is the first random, closed ticket I opened on their issue tracker: https://github.com/systemd/systemd/issues/5483 I’m not saying they are all good, but they aren’t all bad.
I find the vitriol on all these issues to be astounding. The project leader asked a question about a wrong assumption he had. A good opportunity to make things better! Look aside from it being systemd. Look at him as a person.
The project leader asked a question about a wrong assumption he had. A good opportunity to make things better! Look aside from it being systemd. Look at him as a person.
Ok.
I’m seeing someone who jumps to conclusions (he assumed that a core utility worked a certain way with no attempt to take 30 seconds to verify) with poor attention to detail (ifrm worked the way he imagined it did, then even a moment’s thought would suggest that calling rm -rf on any directory would result in wiping the root filesystem as it recursed through ..).
Furthermore I’m seeing someone whose technical instincts are, in my opinion, questionable (rather than “I don’t think deleting the root filesystem is a big deal based on my wild-ass guess about rm behaviour”, a more thoughtful reaction might be “why are we reinventing rm in first place?”).
On a less technical level I’m seeing someone who, when taking into account his apparent role as leader of this project, shows a poor understanding of leadership vis-a-vis group dynamics, as when someone in a leadership position asks a question the power dynamics of the situation lead people in less influential positions to perceive it as a passive order (“I don’t think this is a bid deal. rm works the same way, no?” can be perceived as a passive phrasing of “This is not a big deal, we should not fix it”).
I’m also seeing someone who is probably frustrating to work with – at no point did the fact that the bug had been reported, had a fix submitted, had the fixed reviewed and merged by others, and the issue already been closed cause him to pause long-enough to consider that maybe the fact that several others felt the bug was worth fixing
might suggest that his understanding of the situation was flawed and might warrant some experimentation to validate his knowledge of rm semantics. Instead he jumped straight to “I’m pretty sure I know better than everyone who touched this issue”, which implies a real lack of respect for his peers’ technical competency on the project.
I think that about covers what I see by looking at him as a person based on his response in this issue.
Well, that seems like a telling response doesn’t it? Systemd continues to be the least worst Linux init system that has to be debugged into sanity by the community because the leadership insist on re-inventing the wheel from scratch every single time.
Comedy gold.
Those who do not know unix are doomed to reimplement it quite poorly indeed.
The fact that this story was submitted by a user with the name mostly-harmless, added an additional bit of meta humor.
More thriller than comedy.
Does anyone know what Poettering’s actual creds are? Because to me it seems he’s a grinder who got lucky.
I learned to love
~/.local/as a convention, which has his name on the papers, but years of shitty Pulseaudio and this crap…It makes me think of Michael Bay and his career as a filmmaker.
PS. Why don’t we have per-app volume control in ALSA?
Well, he builds a lot of stuff that works better than the existing stuff but forces everyone to rewrite everything to work with it. So a company like RedHat picks him up because that’s good for their business. Examples being PulseAudio, dbus (basically POSIX MQ with a layer of terrible), and his magnum opus, systemd
Maybe the definition of works is fluid, but parallel dependency-checking inits have existed for years. And systemd doesn’t always work FSVO work.
So to me it seems he either didn’t do his homework ir didn’t want to fork or contribute to existing work…
also avahi, which actually works and I use quite a bit
I had better luck with mDNSResponder :/
You have per app volume control with OSS but Linux people hate it for some unknown reason. Seriously just go back go OSS. That’s what I do on Linux boxes.
OSS doesn’t play well with JACK at all, whereas ALSA does. That’s my only real reason for not using OSS.
I didn’t know that.
Then again, I’m not some kind of dear leader for a new sweeping change to the linux landscape.
I was just as surprised as Poettering. I was more surprised to discover the “ignore . and ..” behaviour was mandated by POSIX, and followed by FreeBSD and OpenBSD—it seemed like the kind of user-friendlness that gets GNU tools dismissed as over-complicated.
Turns out Plan9’s rm has no such limitation, though, so my faith in minimalism was restored.
rm -rfbecomes pretty useless unless you ignore... How does Plan9’srm -rfwork if it does not ignore..?That’s a good question. Assuming I’m reading the source code correctly, it just recursively tries to
remove()every name thatdirreadall()digs up. dirreadall(2) does not mention hiding..entries, but it also doesn’t mention that they’re included either. intro(2) mentions the kernel normalising relative paths, and paths containing.and.., so maybedirreadall()doesn’t return such things?I should boot up my 9front VM and poke at it.
It’s pretty simple: The directory doesn’t contain
.or.., so they don’t need to be filtered. This also means thatls .*doesn’t include them, and thatrm .*doesn’t need to do anything special to be safe.Holy hell.
The real answer, bar ‘no,’ is ‘depends on the shell.’ Zsh will do exactly what you mean when issuing this command. Bash otoh has bitten me with this one, though.
Huh? rm is not part of the shell, and its rm that doesn’t remove .. even when asked.
bash:
zsh:
The way the shell chooses to expand wildcards has nothing to do with how
rmbehaves w.r.t..and...rmspecifically filters out any dots that the shell happens to pass along on its end. Here it is in FreeBSD, and here it is in GNU Coreutils.The behaviour of
rmdoes not depend on the shell.The point was that
zshwon’t passrmthe paths.and..to begin with using that glob. The waybashexpands that glob could cause problems with other commands as well that don’t explicitly ignore.and..likerm. Thezshexpansion just seems more in line with what the user would want, in my opinion.Exactly what I meant. I was talking about how it is expanded. But guessing from the downvote, this point wasn’t clear to everyone.
NIHing everything but nevertheless making mistakes that had been understood and fixed decades ago – this is why many people have negative attitudes towards systemd. I’ve been using it for many years but still the insistence on reimplementing things in shitty and incomplete ways (journald is a shoddy half-baked reimplementation of sqlite, say) frustrates me to no end.
I only see the systemd things that make it to lobste.rs, so pretty heavy bias, but I don’t think I’ve read a single one of these bug reports where systemd does something unexpected and horrible where poettering has responded with “yep, this is a bug and sorry we’ll fix it”. It’s just weirdly anti-user. I don’t know if Linux users just don’t care or they’ve just given up after all of the init daemon’s various Linux distros have gone through.
I wonder what things will be like in 10 years once systemd is everywhere. Maybe people don’t dare touch the default config and just work around issues in odd ways or people are just miserable but need to wait for the next generation to come along to be energetic enough to propose a whole new init system and deploy it.
I’m pretty sure we’ve given up. Also pretty sure it’ll be a miserable mess of workarounds and hacks.
Hopefully, then, someone starts advocating for Runit or the suckless people resurrect Uselessd, because there is sanity left in the world. Practically no one uses sanity, though.
Come to BSD, we don’t suck (yet)!
I’d love to use OpenBSD but only a handful of VPS/Server providers support it.
OpenBSD offers nice
bsd.rdimages which can be loaded into RAM and started with your favourite bootloader.That means you can get yourself any KVM (or similar ‘real’ virtualisation) vps (these can be really cheap, starting at €1/mo or even less), choose a Linux template and manually install OpenBSD pretty quickly.
Here’s a nice guide documenting the process. Bear in mind you might need to change the
set root=(hd0)in the grub config. For example one some boxes I have I had to useset root=(hd0,msdos1).Thanks, maybe I’ll try that.
My problem is that I want to have something “just work” without fiddling with stuff.
I believe OpenBSD itself would certainly qualify, but hosting it is another matter.
Is there anything that keeps you from using one of those handful of providers? As far as I’m aware, they aren’t significantly more expensive than their competition.
I recently tried to get OpenBSD working on Vultr, which is one of them.
If I remember correctly, no matter what I did, sudo refused to recognize that a user I added was in the “wheel” group, even though the command to list a user’s groups showed that was the case.
It was really strange, and after a few reinstalls etc, I gave up.
I have a few OpenBSD VMs on Vultr and they work fine (aka, Works on My Machine™)
Without any more details the problem here could have been anything. Did you log the user out and back in again after changing the group? Maybe you didn’t put a colon in front of the group name in doas.conf? If you were using sudo, did you uncomment the required line in sudoers?
I don’t remember what I did anymore, but I guess I should try again.
It would be nice to run OpenBSD for all of my server needs but I can’t tell if it’s a good idea for a business (which I’m building).
forget sudo, use
doas!I may have been trying to - I don’t remember now.
Ah, well, I’m not exactly an openbsd expert but if you want to try again highlight me in #lobsters and I can show you my configuration.
Thanks :)
[Comment removed by author]
I use Void for work where I need to use Linux, 10/10 would recommend.
For anyone who does use it, the only thing that tripped me up is you need to install
git-perland possiblygit-extrasin order to get whatever else you normally get when you installgit. After learning that, I got used to the extreme package granularity so I don’t remember if it’s that way for anything else, as that’s now always the first thing I check when a command was suspiciously missing.Other than that, long live BSD.
I’m surprised none of the BSDs have adopted a daemontools derivative into base yet. Seems like a match made in heaven: a small and carefully written codebase, a focus on simplicity and reliability, directly executable service scripts, no action-at-a-distance pidfile nonsense, sane log rotation. I suppose you can chalk up the inertia to the conservation laws which govern the BSD world. Which, viewed from the systemd angle, look more like a virtue than a shortcoming.
Well, for me, the daemontools everything in a maze of symlinks configuration is really alien. One can argue its merits, but it’s definitely different, and not clear how one evolves from some simple rc scripts to that.
Fair. Maybe there’s a good rc-to-daemontools migration guide, but I usually just write the
./runfile from scratch and chuck all the supervision and logging boilerplate in the rc script. You won’t need the vast majority of it.It definitely is at first. The only symlinks you really need are of the form
/var/service/foo -> /etc/service/foo. Those are necessary for clean uninstallation of services (see “How do I remove a service”), and that has to do with howsvscanandsupervisecoordinate directory-based operations.Convention recommends some other symlinks though. Some people don’t care, but I like to have
foo/supervise,foo/log/supervise, andfoo/log/mainpoint back into/varforhier(7)reasons. For services that serve from filesystem state, afoo/rootsymlink is a good idea, as it lets you do atomic deploys via atomic symlink replacement.Daemontools is a bit alien, but the logging system is superior to what is there for services to use in openbsd imo.
There is definitely a selection bias here. Here is the first random, closed ticket I opened on their issue tracker: https://github.com/systemd/systemd/issues/5483 I’m not saying they are all good, but they aren’t all bad.
….why is systemd badly reinventing
rmnow?I find the vitriol on all these issues to be astounding. The project leader asked a question about a wrong assumption he had. A good opportunity to make things better! Look aside from it being systemd. Look at him as a person.
Ok.
I’m seeing someone who jumps to conclusions (he assumed that a core utility worked a certain way with no attempt to take 30 seconds to verify) with poor attention to detail (if
rmworked the way he imagined it did, then even a moment’s thought would suggest that callingrm -rfon any directory would result in wiping the root filesystem as it recursed through..).Furthermore I’m seeing someone whose technical instincts are, in my opinion, questionable (rather than “I don’t think deleting the root filesystem is a big deal based on my wild-ass guess about
rmbehaviour”, a more thoughtful reaction might be “why are we reinventingrmin first place?”).On a less technical level I’m seeing someone who, when taking into account his apparent role as leader of this project, shows a poor understanding of leadership vis-a-vis group dynamics, as when someone in a leadership position asks a question the power dynamics of the situation lead people in less influential positions to perceive it as a passive order (“I don’t think this is a bid deal.
rmworks the same way, no?” can be perceived as a passive phrasing of “This is not a big deal, we should not fix it”).I’m also seeing someone who is probably frustrating to work with – at no point did the fact that the bug had been reported, had a fix submitted, had the fixed reviewed and merged by others, and the issue already been closed cause him to pause long-enough to consider that maybe the fact that several others felt the bug was worth fixing might suggest that his understanding of the situation was flawed and might warrant some experimentation to validate his knowledge of
rmsemantics. Instead he jumped straight to “I’m pretty sure I know better than everyone who touched this issue”, which implies a real lack of respect for his peers’ technical competency on the project.I think that about covers what I see by looking at him as a person based on his response in this issue.
Well, that seems like a telling response doesn’t it? Systemd continues to be the least worst Linux init system that has to be debugged into sanity by the community because the leadership insist on re-inventing the wheel from scratch every single time.