throwawaysysd

I'm not attacking you or asking you to defend a position, I'm asking for clarification because I legitimately do not understand what the issue is. I totally agree with you, it is not helping anyone to become defensive over this. I don't understand what the attitude was, it seems to have been fixed 8 years ago? Did I miss something?

On Windows, if there has been value in putting those tasks in a GUI in the control panel, they will do it. It's the same deal.

Yes you can technically build a system without dbus or systemd or polkit or gettext or the C library or whatever it is you feel is superfluous. As you've found it is not actually difficult to do that, just tedious and impractical. You aren't gaining anything here by removing things. If you want equivalent functionality you're now tasked with building the equivalents, e.g. Android which is also a single user userspace for Linux without dbus or systemd, but has its own fairly complex set of high level services and IPC system.

>I asked my computer to do something as basic as play sound, something that worked for decades without GUI sudo

Sure, security also was not great for decades. I know what you mean you don't have time to vet packages, very few people have time to do that, that's usually why you'd trust a vendor to do it for you and not keep second guessing their decisions because they published and fixed a CVE.

>I am looking for alternative distros because the ones I've been using include too many things I didn't ask for.

That's great, I wish you luck. Just keep in mind, eventually if you find you want to put a security prompt on something for whatever reason (maybe you find yourself shipping something to a less technically inclined user), I expect you will circle back around to the same solutions. They're there for you to use them. At that point it becomes whether the frustration with XML and Javascript is worth rewriting it with a different configuration format and scripting language. Maybe you also want to take these tools written in C and rewrite it in Go or Rust or something, I don't know. I would not say it's worth it unless you have some really extreme requirements. This doesn't to have the most expressive DSL you can think of it, it just needs to encode some simple logic in a well-understood way.

>Please don't speak for everyone. It's exactly this patronizing we-know-better-than-you attitude that makes users hate their corporate software vendors.

I'm not speaking of corporations here, this is basically every current desktop environment that is shipping on Linux right now. They are all either using polkit or they use something very similar to it because the idea of it (user asks to perform an action, show a prompt) is very straightforward and pretty much universal for GUIs by now. Some of them may be business-oriented but some aren't. If this doesn't fit the definition of "everyone" using desktop Linux then who else are you considering? And just to clarify, I would say using sudo with a fine-grained config is roughly equivalent to polkit, although less convenient for GUI users because it doesn't have pluggable authentication agents.

>I knew someone would immediately reply with this straw man as soon as they saw mention of old Windows. I said user policies are pointless for a single-user desktop.

This itself is a strawman though. Polkit and sudo and such are not strictly about user policies although you can use them for that.

After a lot of recent events, I don't feel comfortable judging any open source project on the speed at which they fix bugs or the way they communicate about it. In open source there is no obligation for anyone to fix anything or communicate anything. To me it's a miracle when anything gets fixed at all. It feels like the community is still largely held together with duct tape and string.

I can't figure out what the problem here is, are you trying to run systemd with a kernel with cgroups compiled out? I don't see how that's a show stopping bug, from the discussion there it was never supported.

>If I need elevated privileges it's always a one-off job, which means I need a commandline anyway.

This is why polkit actions are the way they are, so you actually have a chance of being able to encode those one-off tasks into permissions for a GUI. It's not implemented for everything that requires root, and it probably won't ever be implemented for all of it but it's a lot better than it used to be. Part of it is improving because desktops like KDE made it easier to plug in new panels to the system settings, another part is that applications started using the higher level D-Bus APIs (like udisks2, timedated, networkmanager, etc) instead of trying to access the raw devices themselves.

>There's a bunch of influential people that are bent on making "Linux desktop" be something that competes effectively with Windows and MacOS. Setting aside that I don't think those are particularly desirable objectives in the first place, I simply don't see it happening. Despite their deficiencies, Windows and MacOS work better than Linux desktops.

I don't disagree with the last part here but, companies like Canonical exist and they get paid to ship this stuff. There are customers out there who want this, and they may very well be the ones paying some money or contributing maintenance towards keeping your browser and media player working on Linux. I don't know any overarching reason why these customers would deploy Linux instead of Windows, you would have to ask them.

>I realise that my usage pattern isn't universal; I was just correcting the claim that "all desktops use it". You only need one counterexample to refute such a claim.

Sorry but I don't think any usage of the terminal is a counterexample. That's just sidestepping the desktop, you could also do that from a VT with no GUI present.

I don't understand what you mean by a few people get to define it. This stuff is used by basically every desktop environment on Linux. You have to either use it or write something very similar to it if you want to have permission prompts that actually work. They all give the option to turn it off but they still have to support it for the average user you described. Unsurprisingly, the requirements for shipping a desktop are really not that different on Linux compared to other operating systems. The users all want the same things.

From what I have seen, the amount of users that want to go back to the Windows 95 style of security are an even fewer people. You can find distros that still ship a desktop from that era but they don't seem to be for much beyond novelty.

I agree it's not particularly useful for home users, I expect most would go with the defaults provided by their distro and leave it there. This is meant for corporate deployments where sysadmins might need to write more advanced policies.

Yes, polkit does have some overlap with sudo. What it has over sudo is a real API, programs can use it to authenticate an IPC request for an action to a privileged daemon while that daemon is running.

If those checks always fail, you've now lost that functionality to do anything requiring elevated permissions and made your system less useful. You could get it back by installing a suid root tool like sudo/doas but that opens the same hole again that elevates these problems from a crash into a CVE.

Is that really any dumber than doing any similarly dangerous industrial jobs that require a lot of training? Or something else dangerous in entertainment like being a Hollywood stuntman, or being Siegfried & Roy? I'm sure you could get a lot of money for having that skill if you did it in the right place.

I'm sorry, now I really don't understand. If these libraries shipped with your distro, you asked for them. If they were dependencies of a package you installed, you asked for them. It's bizarre to me that there are hundreds of Linux distros with every combination of packages you could possibly ask for and I still see this complaints. It's very likely you didn't see a prompt because your distro configured it to not require a password. If you want to configure it to require a password, the system lets you do that. This is just another choice you have.

Sorry but if you keep falling back to the terminal to do things I would say you're not really using a desktop. What's the purpose of pointing this out? Yes, you can do whatever you want in Linux by opening the terminal and typing sudo. I understand the propensity of developers to like this because we spend all day in our xterm windows anyway but this is not the way anyone else expects a desktop to work.

Just to follow this discussion a bit further: If you have a task that /really/ needs elevated privileges you could turn it into a kernel module. That's great for you if you want to do that, but will you tell everyone else to develop kernel modules for every little thing? I don't think I would. I'm happy to give the muggles a better interface.

I detailed this in another comment, the reason desktops use it is to get those macOS-style permission dialogs that pop up when you try to take some privileged action. I don't think any desktop distribution wants to ask users to open a terminal and type "sudo usermod" and then log out and log back in in order to do something like setting the clock or formatting a usb drive. I don't remember this working well at all before polkit arrived either, I remember when device hotplug in Linux was really broken for this reason (and a few others). It's not reasonable to ask desktop users to edit udev rules when plugging in a new device. If it worked well at all it was because you were doing things like having a lot of suid/sgid tools or just running GUI programs as root which is a terrible idea.

>Who is trying to prevent the user from using their own hardware?

I don't understand this question. The functionality here is equivalent to sudo, you type your password to authenticate a certain action. As the sysadmin you can configure some actions to always accept or always deny, if you want.

You can still get realtime priority for threads without rtkit but you will have to set the appropriate permissions on your user. See the section on privileges: https://www.man7.org/linux/man-pages/man7/sched.7.html

I wouldn't suggest giving those permissions to your user because it opens up the possibility of a denial of service. With those permissions, any program running as your user can spawn lots of realtime threads that can take over the scheduler and lock the system up. This was detailed in the rtkit announcement, and preventing it is the reason rtkit exists: http://lalists.stanford.edu/lad/2009/06/0191.html

Maybe realtime audio is not important to you, and that's fine. But it's never as simple as "delete these things and now I have a secure system", you may be trading off security elsewhere to get that. Please also note that pkexec is not required to use polkit. You can remove pkexec and still have a functioning polkit installation and still use all those other daemons too. For a really secure system you may want to remove all suid binaries anyway and only use polkit or SELinux or something.

Or it could be because those libraries actually do something and users want them? I really don't get these complaints. Is the C library an "invasive weed" because C programs require an ABI compatible C library to run?

Creating another group every time and asking the sysadmin to add you to the group when you want a new permission is not an appropriate solution for the desktop. It also isn't fine grained (what if you want to only grant permission to one audio device, then you'll need to create lots of audio groups and keep track of them all) and doesn't handle the case where you want to temporarily grant privileges to some device for just one session. There is more to it than just the issue with ssh, and it's not superfluous. There is a very good reason desktops all use it.

>given the "move fast, break things, wontfix" approach the systemd authors currently have with the project.

I don't understand where anyone is getting this impression from, that describes the opposite of my experience with systemd. The authors publish stability guarantees, and they have done so for several years: https://systemd.io/PORTABILITY_AND_STABILITY/

Thanks for the clarification. In practice what that means to me is you need more people backporting fixes to the old branch. My experience: it's boring, thankless work and it doesn't pay unless there is some serious investment behind it, think heavily-audited systems deployed in government offices that have to stay the same for decades.

If I'm wrong then I'm interested to know why. I'm willing to listen to what you have to say, but you have to actually say something. Thanks.

A pid file is never actually reliable though. Since the supervised process has control over it, it can write any number it wants in there and trick the service manager into signaling the wrong process. As long as the process is not root and can't escape its own cgroup, systemd's pid detection is going to be less error-prone in basically every case.

I can't stress this enough. Pid files are really bad. The fact that we used to have to use them is a flaw in the OS design. Using them for startup notification is also a hack in and of itself. The kernel has enough information to fully track lifecycle of these processes without writing information into files that are inherently prone to race conditions, and we now have better APIs to expose this information, so we shouldn't need to use these hacks anymore. I don't think there is any Unix-like system left that considers the old forking daemon style to be a good idea, and systemd's handling of pidfiles is really just a legacy compatibility thing.

That doesn't seem very practical. Viewing something as dumb before learning anything about it is holding a prejudice towards it.

>is way too complex for the given functionality, and is completely unneeded in the first place--yes, get rid of the damn thing. Unless of course you enjoy getting "your" system OWNED and dominated by bad actors.

This is a rather nonsense statement. Polkit (or something like it) is needed if you want to have those macOS-style "program A wants to have permission to access privileged resource B" security prompts in the GUI. It's about as complicated as any similar solution needs to be for that use case. Perhaps you find these to be annoying and you disable them so they always succeed, but with that you've effectively given every program permanent suid root access. Definitely simpler, but can you say it's less of a security nightmare? I wouldn't. Yes there are risks of vulnerabilities in any security layer, but without them you've got no security layer at all.

>Ownership attestation is a pretty common service. Law companies do the same thing for home titles during real estate purchases, and there's definitely more than one provider of that service!

Sure, but now we're back to talking about properties of the good old common law legal system, which in some ways is already decentralized. It's not benefiting from anything provided by blockchains and crypto.

>If there were an equally trustworthy provider, or even a provider that offered better title insurance, why would people still use Opensea?

To me, it's the same reason everyone still uses Amazon. Blockchains don't change this dynamic.

>If Epic says "ownership of this digital thing gives you this other thing in game", imagine there are two ways to trade that digital thing: (1) within Epic's internal platform, or (2) on an open Blockchain.

Public blockchains do not provide any additional value here. The only important part is if there is consensus between the two parties to agree that the digital thing should mean something in both places. A public "trustless" blockchain is just noise as far as this goes. The whole thing doesn't work if there is no trust between the two parties to agree that token A should correspond to both item B and item C.

>Doesn't it stand to reason that (2) is a clearer ownership claim, with less control, and therefore more valuable? And if it's more valuable, then isn't Epic incentivized to sell their digital goods on Blockchain (and get better prices for them) than their internal platform?

I don't see how this is the case. If I'm not mistaken, you're talking about transferring an item from an Epic game to another game. That means Epic gets the initial payout for the item and the company making the other game gets nothing but still has to expend time and money supporting items that Epic got paid for. I can't see why they would agree to that.

The ownership claim also isn't clearer, both companies could still just decide to shut down their games simultaneously or retire those items and now you're left with nothing.

I have read countless research papers and press releases and blogs and open source code relating to web3 over the past few years, so if I'm ill informed then it sounds like you're suggesting that pretty much everyone else is also. If there is some secret I'm missing, now is your chance to say it. Please try to make more substantial comments. Thanks.

>Wouldn’t it be great for FreeBSD to be the first OS to have a release that was actually, truly finished?

I don't mean this in a rude or dismissive way but these comments make me want to pull my hair out. Deciding your software has a fixed scope and is finished doesn't stop the wheels of progress from turning. Worst case, the rest of the world will decide the scope you chose was crap, for reasons beyond your control, and then your project is dead. I get that it is an engineer's fantasy to build a theoretically "perfect" system but such a thing can't exist in practice. I think you'd have a better chance of proving P=NP or something.

Sure, you can do all that and set it up manually. I'd love to be corrected here but last I checked this was not done automatically in any BSD. Systemd recognizes this is so common that it does it automatically for every service using the Linux equivalent (cgroups). IMO now that we have these tools, every sysadmin is always going to want to use cgroups/jails for every service all the time and never want to use pidfiles because pidfiles are tremendously broken, error-prone and racy.

No I mentioned two ways it could be done better, it has to use different OS facilities. Of course you are right about the futility of trying to secure anything connected to the X server, a solution based on X11 will probably always have vulnerabilities.

Upon observation, that huge community of developers appears to still be mostly building apps and altcoins on top of ETH and cashing out on BTC exchanges because that's what everyone uses and it's how you make the most money. These coins have not diminished in popularity, the huge community has only increased their popularity. If you take issue with cognitive bias then take it up with them. Like I said, I will concede this point when that changes and all the proof-of-work coins are gone, and the BTC maxis go away and stop having so much influence, but that has not happened and I am very skeptical that it ever will without also taking everything else you'd describe as "web3" with it.

I used to be very interested in defi but I can't anymore when it's evident that the same market forces and consolidation and network effects keeping traditional banking afloat are also keeping BTC afloat because too many people are invested in keeping it the dominant coin. I really hope I'm wrong and BTC is not "too big to fail" but if I am then I expect you'll see these fancy web3 startups pivot back to making "boring" web 2.0 banking systems because there is no big money in defi anymore.