Intent and desire are separate concepts. For example an employee may act with intent, but no desire, as their goal is to acquire money to satisfy their real desires.
In some places it's shameful to show one's hair, or to eat while you walk in public. In some, people don't think about those things at all. In others, the ability to do those things can be an expression of personal freedom.
Well, not quite. Not showing your hair or not eating in public may have meaning in somebody's culture/religion, but it doesn't hurt anyone else either way. Playing video/music without earphones does. And surely people must have experienced it from the other side when people nearby were playing music they didn't care for. I think it is reasonable for people to ask themselves "Would I like it if someone near me did <X>?", and if the answer is 'No' to not do it themselves. Maybe this is "shame" or maybe simple empathy.
Eating in public places not mean for eating subjects others to the smell of your food in the same way that listening to something on speaker subjects them to unwanted sound. Hijabs are more indirect but I would disagree that it doesn't affect others.
Have you traveled Latin America? Loud audio in public is so normal there that immigrants to Europe often can't see what all this fuss is about when people complain about loud phones on public transport. This is very much a mutable cultural thing.
Negative externalities is culturally dependent. The Japanese consider the sight of a person eating while walking to be a negative externality. Are we going to start complaining here on HN about people doing it? No, we recognize that those taboos vary across time and space.
The difference is some taboos are just based on tradition, and others are based on actual damage. Nobody is hurt by seeing someone walking and eating -- they can just not look at them and the problem is solved. You can't not just hear the noise people inconsiderate not to use headphones make.
In cultures where the sight of certain things is taboo, telling a local person that they have to direct their gaze elsewhere feels as much of a rude imposition as someone's phone audio reaching your ears. Please try to step beyond your own cultural upbringing and realize how arbitrary and mutable all these things are.
But then people get angry if you don't want those "cultural differences" in your daily life. And when people question why you prefer private transportation.
My own observations are that I used to target turn lengths of 10-15 minutes and these new models (since 5.6) extended that a bit to ~25 minutes, as they tend to do more tests and reviews. Targeting hours-long turns makes as much sense, as putting on cruise control and going to sleep.
It would make sense to make it possible, but increasingly expensive to extend the copyright. It's fine for Disney to keep their successful creations, it just makes no sense to drag all other copyrighted works in existence along for the ride.
It’s not specific to this program, but I lately get this feeling that distributing widely a piece of software that exists for 5 days and saw a dozen releases in that period is stretching the open source trust model.
For a single user, opinionated, modern, developer focussed OS, this is completely and utterly on par. Using docker as a developer without this is just plain annoying.
Docker can be run rootless. It is so easy. No excuse for desktop distros to not do this by default. And that is why all major Linux distros are just as bad as Omarchy (Not recommending MacOS or Windows either as those are wildly worse)
>when it’s a very common setup to add regular user to the docker group.
As an official configuration? Or in random copy paste guides? The former is very different than the latter. It's not uncommon to disable sudo passwords, but it would be considered a serious security lapse if that were the default on some OS.
You mean the optional post install instructions, which is a separate page from the main install instructions, and contains a giant warning about the security implications?
Per my other comments, it does not really matter if you disable the sudo password or not. If you have a sudo binary at all you effectively are giving every user process root since malware can mask the sudo command and intercept the password so trivially.
The methods are described on the official docker website, not just random blogs or SO pages. There are caveats about security, of course, but it's not truly discouraged.
I think there are notes that warn you about the consequences. And they have been written with sys admin in mind which knows about user groups and security.
Docker itself is such a massive security problem. Like it’ll punch through your firewall. Found out the hard way after a misconfigured redis was exposed to the web.
Exactly! I was also surprised by this — that's a sensible default for many people.
However, I agree that it should be opt-in. Docs should be more explicit about that too, they should warn users about risks of going with that option. That excerpt mentioned in the article was rather misleading.
This also seems like one of the more common things LLMs use to priv escalate themselves when not given root access, seems like a rather common misconfiguration.
> Ubuntu has the exact same vulnerability out of the box, just with lxd instead.
No, it does not[1]. LXD:
- explicitly warns against this mode of vulnerability. Of course, there's no protection against people who blindly run commands copied from the internets, but the official documentation, at least, for as far back as I can recall, has had clear warning boxes against this, with explanations.
- does not have the track record of bad design that docker has had (IMO).
Yes, it does. None of this information changes the fact that, on a fresh install of Ubuntu Server 24+, the default user can privilege escalate to root using a few LXD commands.
Ah, Ubuntu _Server_. I'm tempted to dismiss this by simply saying "Server Linux != Desktop Linux", but yeah, I don't like that this is on by default either.
I mean, this is a setup that ships with a default password that's the same as the username, and the first thing I do on all my server installs is disable all default user accounts and enable passwordless sudo.
From reading other docs of Ubuntu Server, it appears they relax the root/non-root distinction in other ways too. But I'd probably never have suspected this particular vector of vulnerability.
reply