451–460 of 902 posts
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.
You only have one admin? How do you know who logged in, ssh certificates?
Earlier quoted context omitted.
Agreed. I've taken to treating my linux installs like I used to treat Windows: no internet access expect application specific. For example, I run a Visionfive 2 OpenBSD install with squid, everything else has to go through that.
Curious why squid and not pf?
Earlier quoted context omitted.
# journalctl -f _PID=${your_pid} # option 1 # systemctl status ${your_pid} # option 2 [1]: https://www.freedesktop.org/software/systemd/man/latest/jour... [2]: https://www.freedesktop.org/software/systemd/man/latest/syst...
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…
Offtop: long mastodon/X threads are so inconvenient that I would not even consider it a use case of such platforms. Write a blog post and link it there, ffs
https://mastoreader.io/?url=https%3A%2F%2Fmastodon.social%2F...
Earlier quoted context omitted.
It violates the principle of Least Surprise; if I'm invoking run0 I'm expecting it to run my program with a different UID and return the same stdout I'd have gotten if I had just run the program in my shell. Not inject a whole bunch of color control bytes in there. Which hopefully my terminal will handle. Unless it doesn't. I'll give them the benefit of the doubt and assume they only do this if $TERM supports color.…
Any sane command line program will only output color codes if isatty(STDOUT_FILENO) succeeds.
systemd has been a net positive for the linux ecosystem. remember when you had to write bash scripts to start, stop, restart services and handle any other signals you want to send it? nowadays it's a unit file (basically just an ini file) away with relatively straightforward API. and you can actually declare startup dependencies and other useful relationships past just "prepend a number signifying when it should run…
Systemd was meant to replace Ubuntu's upstart, not sysv init. And it indeed systemd was better designed than upstart.
Sysv init is a horrendous hack. People should NOT use that. Upstart had limitations but is okay, and certainly much better than sysv init. Systemd is okay too (but has much more features).
Also as an historical note, both upstart and system was inspired by Apple's launchd.
NixOS was an early adopter of upstart but it later migrated to systemd (alongside Ubuntu itself)
This made me smile:
> sudo has serious problems though. It's a relatively large SUID binary, i.e. privileged code that unprivileged users can invoke from their own context. It has a complicating configuration language, loadable plugins (ldap!), hostname matches and so on and so on.
That is a bit rich coming from the author of systemd, which must be in the running for one of the largest bodies of code that must run as root. It's also a very complex piece of code. That complexity is the reason I was completely flummoxed by interactions between systemd and dll's being exploited by the XZ utils hack to attack an unrelated and uncompromised binary: openssh. Run0 is just an extension of that ball of mud. It's a stretch to believe it will be more secure than sudo in the long term, which is amusing because it appears Lennarts primary argument is it will be more secure.
I'm not the only one who has noticed this: https://lwn.net/Articles/971812/
Earlier quoted context omitted.
> If you're only used to cloud VMs that are setup for a single user or service, I guess your views would be different. This is overwhelmingly the view for business and personal users. Settings like what you described are very rare nowadays. No corporate IT department is timesharing users on a mainframe. It's just baremetal laptops or VMs on Windows with networked mountpoints.
Multi-user clusters are still quite common in HPC. And I think you're not going to see a switch away from multi-user systems anytime soon. Single user systems like laptops might be a good use-case, but even the laptop I'm using now has different accounts for me and my wife (and it's a Mac). When you have one OS that is used on devices from phones, to laptops, to servers, to HPC clusters, you're going to have this fri…
Earlier quoted context omitted.
I can think of a number of things this tinting would break.
Can you name any?
> One could say, "run0" is closer to behaviour of "ssh" than to "sudo", in many ways. This is an interesting offhand comment. You could implement a very similar tool by SSHing to localhost.