Live data from Hacker News

Run0, a systemd based alternative to sudo, announced

mastodon.social

371–380 of 902 posts

Re: Run0, a systemd based alternative to sudo, announced

#371

Earlier quoted context omitted.

systemd isn't a single piece of software. It's a collection of software with an unified theme, like KDE or Gnome. Attack surface-wise, I don't think there's much difference between "sudo" being a part of the systemd package and not. Either way there's "sudo" code to be targeted, which package it's part of is just a technicality.

I like to compare Systemd to GNU. Pretty similar scale, similar "take over the world" levels of adoption in Linux (GNU's libc is in nearly everything , all the other GNU tools are ridiculously common), adds lots of attack surface to what used to be single-purpose simple tools, etc. Just about every criticism of Systemd applies just as well to GNU.

https://news.ycombinator.com/item?id=40215413

Re: Run0, a systemd based alternative to sudo, announced

#372

I have seldom come across unix multiuser environments getting used anymore for servers. Its generally just one user on one physical machine now a days. I understand run0's promise is still useful but i would really like to see the whole unix permission system simplified for just one user who has sudo access.

in some other systems the concept has become overloaded. instead of multiple real people as users, different software with different permissions are different users. its not a bad abstraction.

Maybe containers are a better way of isolating processes as mentioned in other comments.

Re: Run0, a systemd based alternative to sudo, announced

#373
post #230

Earlier quoted context omitted.

> remember when you had to write bash scripts to start, stop, restart services This was a really big pain, yes, but I also remember how I could `tail -f *.logs`. I remember how I didn't need to remember about `--no-pager` and `--follow`. I knew where the files were, what they were called. I remember how I didn't have to google how to find logs between 10 days ago and 4 days ago, because the logs would be in a .tar cr…

> I could `tail -f *.logs`. I remember how I didn't need to remember about `--no-pager` and `--follow`. journalctl supports -f, which by your own account you were already using for tail, so I'm not clear what's worse there. > I remember how I didn't have to google how to find logs between 10 days ago and 4 days ago, because the logs would be in a .tar created by logrotate with a date in the filename. My memory of thi…

Oh the joy it is to have a corrupted log file which the program that wrote it refuses to even read.

Once you deal with that you’ll realize journald is just in the way and needs to be modified to output a human readable log by default.

Re: Run0, a systemd based alternative to sudo, announced

#374

I have seldom come across unix multiuser environments getting used anymore for servers. Its generally just one user on one physical machine now a days. I understand run0's promise is still useful but i would really like to see the whole unix permission system simplified for just one user who has sudo access.

I always still split up "sysadmin" from "deploy".

Ephemeral setups (amongst which k8s) remove that need but introduce a big load of other stuff.

Having a VPS that is managed by sysadmins (users with sudo rights, authed with keys) and on which partly overlapping "deploy" users can write to small parts and maybe do a passwordless "sudo sysctl restart fooapp" but only that, is a nice and simple setup.

I manage at least seven of these. And nothing in me even considers porting this to my k8s infra.

Edit: The reason for this setup is simple and twofold: deploy is safe and clear: deployers can be confident that whatever crap they pull, the server will churn on, data will be safe, recovery is possible. And all devs/ops having their own keys and accts gives a trail, logs and makes it very easy to remove that contractor after she did her work.

Re: Run0, a systemd based alternative to sudo, announced

#375
post #356

2 weeks ago I didn't understood the systemd hate. But I tried to run udev-requiring program on non-systemd based distro. And now I don't like systemd anymore.

So, you don't like a component because you ran software which requires that component, and you intentionally ran it in an environment without that component.

That does not make sense to me?

Re: Run0, a systemd based alternative to sudo, announced

#376

Earlier quoted context omitted.

These absolutely SUCK as answers to that question. They entirely miss the point. They provide a specific answer to a general problem. The problem with systemnd is it assumes that it's possible for all needs to be predicted and accounted for ahead of time. While "look around at directories and files, and grep within them" works after the fact without any special knowledge or tools. The person who wrote the log file di…

> These absolutely SUCK as answers to that question. They entirely miss the point. They provide a specific answer to a general problem. No they don't. They are good answers. If you want answers to a more general problem, then ask. This is not an emotive topic.

They may be correct answers, in that they accomplish a task.

They suck in that the proposed method for accomplishing the task is a suck-ass downgrade from the previous ways the new way proposes to displace.

I beg to differ about emotive, because absolutely the other side of this fence behaves every bit as butt-hurt when challenged as I just did. You yourself just said these crappy commands were good, as a purely unfounded assertion. They are great because you just say they are great. That is even less objective than my rant. I at least explained what exactly I find so bad. Tell me more about not emotive.

Re: Run0, a systemd based alternative to sudo, announced

#377
post #356

2 weeks ago I didn't understood the systemd hate. But I tried to run udev-requiring program on non-systemd based distro. And now I don't like systemd anymore.

So, you don't like a component because you ran software which requires that component, and you intentionally ran it in an environment without that component. That does not make sense to me?

Well, I tried to run a Mac binary on Windows and it didn't work, so now I don't like Mac.

Re: Run0, a systemd based alternative to sudo, announced

#378

I have seldom come across unix multiuser environments getting used anymore for servers. Its generally just one user on one physical machine now a days. I understand run0's promise is still useful but i would really like to see the whole unix permission system simplified for just one user who has sudo access.

[deleted]

Re: Run0, a systemd based alternative to sudo, announced

#379
post #356

2 weeks ago I didn't understood the systemd hate. But I tried to run udev-requiring program on non-systemd based distro. And now I don't like systemd anymore.

So, you don't like a component because you ran software which requires that component, and you intentionally ran it in an environment without that component. That does not make sense to me?

The popularity of systemd encourages people to require it, which is the major problem

that said iirc udev was formerly separate and active forks still exist

Re: Run0, a systemd based alternative to sudo, announced

#380
post #230

Earlier quoted context omitted.

> remember when you had to write bash scripts to start, stop, restart services This was a really big pain, yes, but I also remember how I could `tail -f *.logs`. I remember how I didn't need to remember about `--no-pager` and `--follow`. I knew where the files were, what they were called. I remember how I didn't have to google how to find logs between 10 days ago and 4 days ago, because the logs would be in a .tar cr…

> I could `tail -f *.logs`. I remember how I didn't need to remember about `--no-pager` and `--follow`. journalctl supports -f, which by your own account you were already using for tail, so I'm not clear what's worse there. > I remember how I didn't have to google how to find logs between 10 days ago and 4 days ago, because the logs would be in a .tar created by logrotate with a date in the filename. My memory of thi…

'journalctl -u service -f' takes many seconds to start showing logs (even with 4GB journal size limit which not that much). 'tail -f /var/log/service' works without a noticeable delay (be it 1kb or 100Gb log file). For me it's a huge regression.
Post reply on HN