541–550 of 902 posts
Just a side note: sudo is largely maintained by just one dude https://github.com/sudo-project/sudo/graphs/contributors
I can't help but think of another XZ crisis that is yet to come.
Earlier quoted context omitted.
I've never understood the need for sudo(1) on single-user, physical machines: I keep a root shell (su(1)) around for admin tasks, and it's always been sufficient.
One password is easier than two and it feels weird to use the same password for both accounts. About half of my sudo invocations are 'sudo su' lmao.
There was (is?) a program developed by some debian developers that did a similar thing way back, but I can't remember it.
Anyone?
[edit - https://www.chiark.greenend.org.uk/~ian/userv/ is probably what I'm thinking of]
Wasn't the recent liblzma attack already exploiting the fact that systemd has its hands in pretty much everything? Wouldn't this expand further the attack surface of systemd and the systems that connect with it?
That's not a great summary of lzma. It was systems adding custom patch to ssh which used a systemd-related library which it didn't really need in the first place. It's a stack of issues that don't have much to do with systemd itself really. But re. expanding the attack surface - unlikely. Systemd's primary purpose is to start processes with the right environment / permissions. systemd-run/run0 basically give you the…
Earlier quoted context omitted.
> I also wasn't a fan of the tinting. From the linked mastodon thread: > For example, by default it will tint your terminal background in a reddish tone while you are operating with elevated privileges. That is supposed to act as a friendly reminder that you haven't given up the privileges yet, and marks the output of all commands that ran with privileges appropriately. (If you don't like this, you can easily turn it…
I for one love to type out 13 extra characters to a 4 character command to disable dumb choices by the developer. On a more serious note, I wonder what random ASCII escape sequences we can send.
This is great! There was (is?) a program developed by some debian developers that did a similar thing way back, but I can't remember it. Anyone? [edit - https://www.chiark.greenend.org.uk/~ian/userv/ is probably what I'm thinking of]
Earlier quoted context omitted.
Use something else then? Linux won on Unix merits. Feels a bit disingenuous to use that against it, especially when including half the system libs has caused one major and highly publicized security issue already
> Use something else then? What a tiresome response, but here, I'm feeling in a loquacious mood, so I'll humor it. First, what else would I use? I don't just want a "well designed" operating system, I also NEED an open source, customizable one that is compatible with the vast majority of developer tools and build systems and toolchains — and that is, without a doubt, Linux. I don't have a better option from a practic…
The CLR is Microsoft’s answer to the JVM. It is not among the ideas Windows NT inherited from OpenVMS. It is not part of the core OS. Most apps don’t use it. With the advent of WinRT, there is arguably less of a push for its use than there once was.
And when you talk about “communicating with structured data”, I believe you are talking about PowerShell - which apps don’t participate in by default, you need to go to the extra effort of writing PowerShell cmdlets for your app, and many developers don’t. You have to write them in PowerShell itself, or else a CLI language such as C#, F#, C++/CLI, etc. So if your app is written in C or (standard) C++ or Go or Rust or Python or Java or JavaScript or Lisp or whatever, integrating with PowerShell requires adding a new language to your project - no wonder many don’t bother
Earlier quoted context omitted.
I find your comment here sadly indicative of the level of discussion around systemd from its haters. Your metric is utterly misleading not only because you're almost certainly counting non-code files, but more crucially, because the systemd repository contains the code for *sixty-nine* entirely separate binaries, separate tools under the overall systemd project umbrella , so counting their collective code size as if…
Two things: - Non code files were counted for both sudo and systemd. That's because I'm lazy, not because I think it influences the result one way or the other (I don't what effect it would have). - Separate binaries are not separate logical entities. Pointing to separate binaries is a misdirection. systemd is a set of binaries cooperating using RPC (dbus) to yield something bigger than any single binary. The biggest…
And portability. Sudo, being a truly independent binary, has been ported in many OSes. Run0?
The issue with systemd ecosystem is not primarily technical, it's the isolationism.
Earlier quoted context omitted.
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?
No. I don't like a framework that promotes using components that are arbitrary dependent on it. To use udev, I need systemd-init, and to use systemd-init I need systemd boot. I really don't believe it MUST be this way, and those requirements aren't at least partially arbitral. Why systemd refuses to run in chroot?