Also relevant (hilarious movie btw): https://www.youtube.com/watch?v=DrezGdru6TQ&t=20s
And an analysis of the scene: https://puzzlewocky.com/fallacies/the-50-50-fallacy/
595 karma · joined June 27, 2023
And an analysis of the scene: https://puzzlewocky.com/fallacies/the-50-50-fallacy/
Edit: to be clear, I specifically need ARM CPUs. Headless is OK (although a basic console over HDMI would be nice). To answer myself, an Orange Pi 5 might fit the bill but I'm not sure how stable it runs at 100% continuous load (on a mainline kernel).
Doesn't Go allocate / extend stacks using dynamic allocation rather than having a static limit (e.g. like C)?
What you're proposing is not even possible with standard Unix permissions (without leaving a huge security hole). You're suggesting that each program can create the state for each user inside the program's directory but somehow cannot read or modify the state for other users.
This suggests the program runs with each user's privileges and therefore these directories would require the sticky bit for state creation (like /tmp does) but this would not prevent a user from roguely creating the state for another user (this is why files in /tmp should be created with random names, they should not be predictable).
Or maybe you're suggesting that all apps should run with setuid privileges (so that they can create the state for each user, but users themselves couldn't) but we already know that would be absolutely terrible for security.
So something like AppArmor (which AFAIK has security flaws) or even SELinux would be required to implement this scheme, I believe, if it's possible at all.
SELinux, AppArmor and other jail-like mechanisms can be a huge burden to manage, especially since most apps would require a substantial number of exceptions to a default security policy (think GUI apps, or apps that require access to a user's files, for example)...
Since most apps do require read/write access to a user's files, or permission to show things on a screen, I'm not sure if you're gaining much security with your scheme. There would be almost infinite ways for an app to exfiltrate or modify a user's files or trick the user into doing things on behalf of the app, I think (like running other apps...).
And if you're implementing a restrictive security policy with something like SELinux or even some kind of container/jail, you might as well do the same but without having to change each and every app to use the weird per-app directory containing the state of all users. This would save you a huge amount of work and potential security vulnerabilities, since private home directories are already secure by default (in terms of protecting a user from other users) and restricting an app not to access the state of other apps could be equally done when using home directories.
> The user has an idea on what the same app is. Unfortunately Nix does not properly understand this concept.
So a user can decide what "Firefox" is? Then what prevents a user from installing a rogue Firefox that exfiltrates the other users' state, in your scheme?
> That is one place. Some programs don't use it. It's not a centralized place of state for every program.
It is for programs that run system-wide and they should be using it.
Which system-wide programs are not using /var/lib for their mutable state?
It's not like they have many other places to save their state... I mean, there is /var/cache but that's for state that can be removed without data loss.
Who knows, maybe something can be fleshed out and improvements come out of it...
Really? So a program can access (and modify!) the state of all of its users?
Do you realize how easy it would be to trick my Firefox instance into reading (and even modifying) the state of another user, and even running other code on behalf of another user, given that it would have privileges to do so?
If I understand correctly your proposal, you basically just converted almost every single application bug into a privilege escalation bug.
Not to mention that how do you even define what the same "app" is?
Is Firefox 28 the same app as Firefox 45? And if so, can a user install his own Firefox (like you currently can on NixOS and even other OSes)?
Also, how would you backup all of your own per-user state, given that every app can decide to manage it differently (i.e. storing it in different files and/or directories inside their own per-app directory, or perhaps even in a single per-app database which you wouldn't have access to).
Look, I'm not trying to grill you, I just think you haven't thought this through (but again, I'm happy to be proven wrong).
> This is unrealistic. On the want majority of computers an app will only be run by 1 user. Focusing on handling multiple users is a more special case and is a distraction from the point I'm trying to make.
What does this even mean? We're talking about user-specific state. So there's different state for each user, which means there are multiple users, by definition!
So how is focusing on multiple users a distraction? It's the whole point...
As I mentioned, on NixOS, the system-wide mutable state is already stored on /var/lib/<app>, which is what you are (redundantly) proposing. So we're just arguing about how to handle user-specific state, nothing else.
NixOS already has that. It's called `/var/lib`.
> Each program could have its own global and user specific state it could manage from within its directory.
The user-specific state is (and should be) in each user's home directory, not scattered around in a bunch of system-wide directories, one for each application...
That's not just for convenience, but also for security (and privacy) reasons.
I'd be interested to know who gets to manage the user-specific state in your proposal. Does each app have it's own per-user directory for each user? i.e. if you have 1000 apps and 10 users, do you need exactly 10,000 user-specific directories? And if not, who gets to create these directories and when are they created/removed?
To be honest, it sounds like you're not aware of all the complexities and implications / consequences of what you're proposing, i.e. it sounds like you didn't think this through. But on the off-chance I'm wrong, I'd be happy to be proven so.
> NixOS's handling of state is poor. Even ignoring the problem of it all being spread out it is not uncommon for secrets to make it into /nix/store which is world readable.
The secrets handling is a well-known issue and easy to avoid when you're familiar with Nix. Although yes, it can be a problem when people are not aware of it.
And I disagree with NixOS's handling of state being poor. Apart from this "secrets" problem you mentioned, it's not worse than other Linux-based operating systems and in fact it can be argued that it's significantly better.
Just the fact that /nix/store is mounted read-only is, on its own, already a huge improvement over letting users and applications installing and modifying the system in an ad-hoc fashion (good luck when you upgrade your system!).
Not to mention all the other advantages of /nix/store (such as user-installed applications, no package or library conflicts even if you install multiple versions of them, etc).
And as another example, the `stateVersion` feature is something that also makes upgrades a lot more reliable, and I know of no other operating system that has a similar feature.
Atomic configuration changes, booting into specific configurations, and system-wide configuration roll-backs (configurations which also include changes in package versions or even entire OS upgrades), also makes upgrades and configuration changes easy to try / fix if anything goes wrong. No other widely-used operating system has such a reliable configuration change mechanism, as far as I know.
But, you know, if you have other ideas of how things can be improved (apart from your idea of merging user and system-wide state into the same place, which I think makes no sense), I would definitely appreciate to hear it!
Those are features, not bugs... There are reasons for all of those existing and for why you wouldn't want everything in a centralized place.
Is that significant enough to matter? How much does it lose?
Did you figure out why it did not pass the test? Was there a bug in the implementation, perhaps?
Also, where can I find the benchmark you speak of? My web search did not find anything.
No, I'm asking for the judicial system to prosecute politicians who make promises that they don't keep. Like they prosecute politicians in other instances of illegal behavior.
To be clear, I'm not saying that currently, it is illegal for politicians to make promises they don't keep. I'm saying it should be, in some form.
> If he or she ran on banning guns, introduced legislation to ban guns, but some conservative added a rider to ban abortion, should he or she be prosecuted for voting against their own bill? Because that kind of nonsense happens all the time.
Obviously not. I'm not advocating for putting politicians in prison willy nilly. But we should at least prosecute the obvious, egregious instances of the kind of wrongdoing I'm talking about.
Besides, the whole concept of a "rider" is stupid, corrupt and should be illegal as well (just like it is in other areas of the law). Then you wouldn't have that problem.
You could just prosecute a politician if he didn't deliver what he promised, you know.
Outside politics (and depending on the context) this is called breach of contract, fraud, misrepresentation or, say, false advertising or consumer protection violation.
It's also colloquially called "holding someone accountable".
Thank you for the chuckle, Professor Peter Itin!
Shouldn't the car trips from/to the airport mean that an airplane journey is even more dangerous, as you can't really fly without those additional car trips?
Of course there is, and it's obviously a positive correlation.
I think you just proved you don't understand what a correlation is...
> Then they start talking about things that currently cannot account for even 0.001% of our global energy storage needs
Not currently, but who's to say that it won't be possible to scale out manufacturing capacity for the technologies that we'll need? A couple of decades ago, EV production and EV charging networks basically did not exist, so by the same reasoning you'd be saying that it wouldn't be possible to have them.
But look where we are now.
Furthermore, the space of possibly feasible ideas/technologies is gigantic, you're just lacking in imagination. For starters, we haven't yet explored my idea:
1. Turn gym equipment into energy-generating devices.
2. Mandatory gym time by law for every able-bodied man and woman.
Solve the renewable problem and health/obesity problems at the same time. Boom.
If that's not enough:
3. Mandatory gym time also for pets and farm animals.
4. Install wind turbines on airplanes (deployed only when descending).
5. Install boat engines on floating wind turbines and remotely navigate them into hurricanes (imagine all that wind energy we're currently wasting!).
6. And if that's not enough, let's start constructing a Dyson sphere already. We already know how to build space rockets. So what's taking us so long? Less talk, more action.
And that's just the ideas that I, a layman, have come up with. So imagine what the experts could think of.
Depends on what you mean by "run out".
In reality, it will never actually run out. It will just keep progressively increasing in cost, with progressively less profitable uses for it, which will progressively be replaced by other technologies (including renewables but also others like sustainable aviation fuel).
LSD does cause significant psychoactive effects with one thousandth of that amount, which suggests that for a typical isolated dose, LSD is safer than caffeine and amphetamines. Not to mention that LSD is not as addictive.
But I don't think that invalidates my underlying point regarding caffeine, even if the lethal dose is not a perfect measure.
It's a decent measure for how much a certain amount of a drug is likely to cause immediate important effects in the body.
A typical cup of coffee contains about the same proportion of caffeine compared to a lethal caffeine dose than the proportion of one Aderall dosage compared to a lethal amphetamine dose.
How about that?
Also, the foot tapping behavior can be related to caffeine consumption even if you also do it when not taking caffeine. Some people (like me) metabolize caffeine a lot slower than average, so its effects last a lot longer (twice longer or so, I think). Also, caffeine notably causes sleep disruption. And caffeine withdrawal can also cause irritability.
Caffeine can also increase anxiety or anxiety-related behaviors, and even if anxiety or these behaviors are not exclusively experienced while taking caffeine, it can still increase the likelihood and magnitude of its effects. These behaviors can also persist in the absence of substance intake for a variety of (psychological) reasons.
So you're kind of proving the parent poster's point, no?
Or are you suggesting caffeine is not stimulant or a psychoactive drug?