> At the limit, sure, maybe there are tradeoffs between freedom and security. But there's lots of technical solutions that we could build right now that give a lot more safety without losing any freedom at all.
Everything you have suggested in this post takes away freedom. There is no solution that doesn't take away freedom / your control. There is always a trade off.
> Like sandboxing applications by default. Applications should by default run on my computer with the same permissions as a browser tab. Occasionally applications need more access than that. But that should require explicit privilege escalation rather than being granted to all programs by default. (Why do I need to trust that spotify and davinci resolve won't install keyloggers on my computer? Our computers are so insecure!)
This already exists on Linux.
I run Discord/Slack in Flatpak. Out of the box the folders and clipboard permissions are restricted. Only the ~/Downloads folder on my PC is accessible to Discord/Slack. You can't drag and drop things into these apps. Which makes sharing content a PITA.
If you don't want to worry about things like keyloggers, you should run an open source OS and use open source programs where you can verify that there are no key loggers. You should also make sure you find out what firmware your keyboard is using (many keyboards themselves have complex micro controllers on them that can be programmed).
> Everything you have suggested in this post takes away freedom. There is no solution that doesn't take away freedom / your control. There is always a trade off.
Huh? In what way does application sandboxing take away my freedom? What can I do today that I can't do with a sandbox-everything-by-default model?
In my mind, it gives me (the user) more freedom because I can run any program I want without fear.
> I run Discord/Slack in Flatpak. Out of the box the folders and clipboard permissions are restricted. Only the ~/Downloads folder on my PC is accessible to Discord/Slack. You can't drag and drop things into these apps. Which makes sharing content a PITA.
Cool! Yeah this is the sort of thing I want to see more of. The drag & drop problem is technically solvable - it just sounds like they haven't solved it yet. (Capabilities would be a great solution for this.. just sayin!)
> Huh? In what way does application sandboxing take away my freedom? What can I do today that I can't do with a sandbox-everything-by-default model?
I've just explained that sand-boxing causes issues with file access, clipboard sharing etc.
Every hoop you add in makes it more difficult for the user to gain back control, even if that is modifying permissions yourself. Most people will just remove permissions out of annoyance.
If you remove control, you remove people's freedom.
> In my mind, it gives me (the user) more freedom because I can run any program I want without fear.
Any security mechanism has a weakness or it will be bypassed by other means. So all this will give you a false sense of security.
The moment you think you are safe. Is when you are most unsafe.
> Cool! Yeah this is the sort of thing I want to see more of. The drag & drop problem is technically solvable - it just sounds like they haven't solved it yet. (Capabilities would be a great solution for this.. just sayin!)
I don't. It is a PITA. Eventually people just turn it off. I did.
The reality is that if you want ultimate security you have to make a trade offs. Pretending you can make some theoretical system where those trade off don't exists just isn't realistic.
> I've just explained that sand-boxing causes issues with file access, clipboard sharing etc.
You've explained that flatpak has issues with file access and clipboard sharing. My iphone does sandboxing too, but the clipboard works just fine on my phone.
I don't think "failing clipboards" is a problem specific to sandboxing. I think its a problem specific to flatpak. (And maybe X11 and so on.)
> If you remove control, you remove people's freedom.
Sandboxing gives users more control. Not less. Even if they use that control to turn off sandboxing, they still have more freedom because they get to decide if sandboxing is enabled or disabled.
Maybe you're trying to say that security often comes with the tradeoff of accessibility? I think thats true! Security often makes things less convenient - for example, password prompts, confirmation dialogue boxes, and so on. But I think the sweet spot for inconvenience is somewhere around the iphone. On the desktop, I want to get asked the first time a program tries to mess with the data of another program. Most programs shouldn't be allowed to do that by default.
> Pretending you can make some theoretical system where those trade off don't exists just isn't realistic.
I think you might be arguing with a strawman. I totally agree with you. I don't think a perfect system exists either. Of course there are tradeoffs - especially at the limit.
But there's still often ways to make things better than they are today. For example, before rust existed, lots of people said you had to make a tradeoff between memory safety and performance. Well, rust showed that by making a really complex language & compiler, you could have memory safety and great performance at the same time. SeL4 shows you can have a high performance microkernel based OS. V8 shows you can have decent performance in a dynamically typed language like JS.
Those are the improvements I'm interested in. Give me capabilities and sandboxing. A lot more security in exchange for maybe a little inconvenience? I'd take that deal.
> You've explained that flatpak has issues with file access and clipboard sharing. My iphone does sandboxing too, but the clipboard works just fine on my phone.
> I don't think "failing clipboards" is a problem specific to sandboxing. I think its a problem specific to flatpak. (And maybe X11 and so on.)
There are other examples.
e.g. There are other things that become a PITA on the phone. Want to share pictures between apps without them having full access to the everything. You need to manually share each picture between apps.
The point being made is that it causes usability issues. What those usability issues are will vary depending on platform. However they will exist.
> Sandboxing gives users more control. Not less. Even if they use that control to turn off sandboxing, they still have more freedom because they get to decide if sandboxing is enabled or disabled.
Anything that gets in my way is something that taken control away from me. Unfortunately giving me full control comes with dangers. That is a trade off.
> Maybe you're trying to say that security often comes with the tradeoff of accessibility? I think thats true! Security often makes things less convenient - for example, password prompts, confirmation dialogue boxes, and so on. But I think the sweet spot for inconvenience is somewhere around the iphone.
No usability and control.
BTW, Your sweet spot is a platform which is the most locked down.
> On the desktop, I want to get asked the first time a program tries to mess with the data of another program. Most programs shouldn't be allowed to do that by default.
Well I don't want to be asked. I find it annoying. I assume that this is the case when I install the program. So I don't install software in the first place that I think might be risky. If I need to install something that I might think is iffy then I find a way to mitigate it.
> But there's still often ways to make things better than they are today. For example, before rust existed, lots of people said you had to make a tradeoff between memory safety and performance. Well, rust showed that by making a really complex language & compiler, you could have memory safety and great performance at the same time.
You aren't selling it to me. I got so annoyed by Rust that I didn't complete the tutorial book. Other than the strange decisions. One thing I hate doing is fighting with the compiler. That has a cost associated with it.
I spend a lot of time fighting with the TypeScript compiler (JS ecosystem is a mess) as a result to have some things work with TypeScript you need to faff with tsconfig and transpilers. Then once you are past that you have to keep the compiler happy. Frequently you are forced to write stupid code to keep the compiler happy. That again has a *cost*.
> V8 shows you can have decent performance in a dynamically typed language like JS.
I work with JavaScript a lot. While performance is better, it isn't actually that good.
There was also two secondary effects.
- Websites ballooned up in size. Also application development moved to the browser. This meant you can lock people in your SaaS offering. Which reduces control/freedom.
- There is a lot of software that is now written in JavaScript that really shouldn't be. Discord / Slack are two of the slowest and memory hogging programs on my computer. Both using Electron.
> Those are the improvements I'm interested in. Give me capabilities and sandboxing. A lot more security in exchange for maybe a little inconvenience? I'd take that deal.
Again. It is a trade-off that you are willing to take. I am willing to make the opposite trade-off.
You seem to be arguing that adding complexity reduces freedom, but I don't think that's true in a reasonable interpretation of the word.
Your argument would suggest that virtual memory takes away user freedom, because it's now much harder to access hardware or share data between programs, but that sounds ridiculous from a modern perspective. I think it's better to keep freedom and complexity separate, and speak about loss of freedom only when something becomes practically impossible, not just a bit more complex.
> Anything that gets in my way is something that taken control away from me. Unfortunately giving me full control comes with dangers. That is a trade off.
No I am not. The example given was ridiculous and absurd and you are doing exactly the same thing.
There is a big difference between basic memory protections and what was being discussed.
This is the issue with a lot of people that work in software. They take the most ridiculous interpretation because "that is technically" correct while not bothering to try to understand what was said.
The problem is that if what "really counts" is too vaguely defined, then it's hard to pin down and argue the point.
Virtual memory probably isn't what you meant, but take something like user privilege separation. It's usually considered a good idea to not run software as root. To interpret the statement generously, privilege separation does restrict immediate freedom: you have to escalate whenever you want to do system-level changes. But I think josephg's statement:
> Sandboxing gives users more control. Not less. Even if they use that control to turn off sandboxing, they still have more freedom because they get to decide if sandboxing is enabled or disabled.
can be directly transposed to user privilege separation. While it's true that escalating to root is more of a hassle than just running everything as root, in another sense it does provide more control because the user can run arbitrary code without being afraid that it will nuke their OS; and more freedom because you could always just run everything as root anyway.
Maybe josephg's sense of freedom and control is what you're saying there is a trade-off between. But the case of privilege separation shows that some trade-offs are such that they provide a lot of security for only a little bit of inconvenience, and that's a trade-off most people are willing to make.
Sometimes the trade-off may seem unacceptable because OS or software support isn't there yet. Like Vista's constant UAC annoyances in the case of privilege separation/escalation. But that doesn't mean that the fundamental idea of privilege levels is bad or that it must necessarily trade off too much convenience for control.
I think that's also what josephg is suggesting about sandboxing. He says that the clipboard problem could probably be fixed; then you say, "but there are other examples". What remains to be shown is whether the examples are inherent to sandboxing and must degrade a capabilities/sandbox approach to a level where the trade-off is unacceptable to most.
> The problem is that if what "really counts" is too vaguely defined, then it's hard to pin down and argue the point.
It really wasn't. It isn't hard to understand what was meant.
> Virtual memory probably isn't what you meant,
No it wasn't and there is no need to put "probably". It was obvious it wasn't.
> can be directly transposed to user privilege separation. While it's true that escalating to root is more of a hassle than just running everything as root, in another sense it does provide more control because the user can run arbitrary code without being afraid that it will nuke their OS; and more freedom because you could always just run everything as root anyway.
The difference is that there are very few things I need to run as user directly daily as root on my Desktop Linux box. I can't think of anything.
However having to cut and paste a meme into ~/Downloads so I can share it on Discord or Slack is a constant PITA. If you sandbox apps you have to restrict what they can access. There is no way around this. The iPhone works the same way BTW. I know I used to own one. You either have to say "Discord can have access to this file", or you have to give it all the access.
> Maybe josephg's sense of freedom and control is what you're saying there is a trade-off between. But the case of privilege separation shows that some trade-offs are such that they provide a lot of security for only a little bit of inconvenience, and that's a trade-off most people are willing to make.
No they are a false sense of security with a lot of inconvenience. The inconvenience is inherent and always will be because you will need to restrict resources using a bunch of rules.
> Sometimes the trade-off may seem unacceptable because OS or software support isn't there yet. Like Vista's constant UAC annoyances in the case of privilege separation/escalation. But that doesn't mean that the fundamental idea of privilege levels is bad or that it must necessarily trade off too much convenience for control.
There are many things that seem like they are fundamentally sound ideas on the face of it. However there are always secondary effects that happen. e.g. Often people just ignore the prompts, this is called "prompt fatigue". I've literally seen people do it on streams.
Operating systems are now quite a lot more secure than they were. So instead of going for the OS, most bad actors will use a combination of social engineering to gain initial entry to the system. The OS security often isn't the problem. Most operating systems have either app stores, some active threat management.
If you are running things from npm/PyPI/github without doing some due diligence, that is on you. This is well past what non-savvy user is likely to do.
> I think that's also what josephg is suggesting about sandboxing. He says that the clipboard problem could probably be fixed; then you say, "but there are other examples". What remains to be shown is whether the examples are inherent to sandboxing and must degrade a capabilities/sandbox approach to a level where the trade-off is unacceptable to most.
It is inherent. It obvious it is. If you want to share stuff between applications like data, which is something you want to do almost all the time. You will need to give it access at least to your file-system. The more of this you do, you will either have to give more access or having to faff moving stuff around. So either you work with a frustrating system (like I have to do at work), or you disable it.
So what happens is you only have "all or nothing".
> If you want to share stuff between applications like data, […]. You will need to give it access at least to your file-system. The more of this you do, you will either have to give more access or having to faff moving stuff around.
Why are those the only answers?
If we had free rein to redesign our computers from the ground up, there’s lots of other ways that problem could be solved.
One obvious example is to make copy+paste be an OS level shortcut so apps can’t access the clipboard without the user invoking that chord. Then just copy paste stuff between applications.
Another idea: right now when I invoke a shell script, I say “foo blah.txt”. The argument is passed as a string and I have to trust that the program will open the file I asked - and not look instead at my ssh private keys. Instead of that, my shell program could have access to the filesystem and open the file on behalf of the script. Then the script can be invoked and passed the file descriptor as input. That way, the script doesn’t need access to the rest of my filesystem.
If we’re a little bit creative, there’s probably all sorts of ways to solve these problems. The biggest problem in my mind is that Unix has ossified. It seems that nobody can be bothered making desktop Linux more secure. A pity.
> However having to cut and paste a meme into ~/Downloads so I can share it on Discord or Slack is a constant PITA.
Why round trip it through the file system or Files.app? That seems like extra (annoying) work On my iPhone, I copy the meme onto the clipboard and then I open discord/slack/signal/Whatsapp and find the right channel/chat, and paste right in there.
At least two independent people understood you in the same way. So just dismissing it isn't productive.
> PITA. If you sandbox apps you have to restrict what they can access. There is no way around this.
This has nothing to do with freedom though.
> You will need to give it access at least to your file-system.
On Qubes, you copy-paste with ctrl+shift+v/c and nothing is shared unless you actively do it yourself. It becomes a habit very quickly (my daily driver). Sharing files is a bit harder (you send them from VM to VM), but it's not as hard as you want it to look.
> At least two independent people understood you in the same way. So just dismissing it isn't productive.
Two people that we are aware of.
BTW, I often encounter this when talking to other techies. People go to the most ridiculous extremes to be contrarian. Often they don't even know they are doing. I know because I used to engage in this behaviour.
So I feel like I am well withing my rights to dismiss it.
> Any security mechanism has a weakness or it will be bypassed by other means. So all this will give you a false sense of security.
> The moment you think you are safe. Is when you are most unsafe.
This is demonstrably false. Qubes OS has the lowest number of CVEs, even less than that of Xen. Last VM escape in it was found in 2006 by the Qubes founder (it's called "Blue Pill").
You are only thinking of attacking computer directly itself. Often people socially engineer access to a computer system. Many UK super markets were hacked, using some of the software that is very secure, because people managed to socially engineer access.
There is nothing and I mean nothing that is completely secure.
Everything in life is about trade-offs. Certain trade-offs people aren't going to make.
- If you want to run an alternative operating system, you got to learn how it works. That is a trade off not even many tech savvy people want to make.
- There is a trade-off with a desktop OS. I actually like the fact that it isn't super sand-boxed and locked down. I am willing to trade security & safety for control.
> Personally I think we need to start making computers that provide the best of both worlds. I want much more control over what code can do on my computer. I also want programs to be able to run in a safe, sandboxed way. But I should be the one in charge of that sandbox. Not Google. Definitely not Apple. But there's currently no desktop environment that provides that ability.
The market and demand for that is low.
BTW. This does exist with Qubes OS already. However there are a bunch of trade-offs that most people are unlikely to want to make.
No, not everything is a trade-off. Some things are just good and some are just bad.
A working permission system would be objectively good. By that I mean one where a program called "image-editor" can only access "~/.config/image-editor", and files that you "File > Open". And if you want to bypass that and give it full permissions, it can be as simple as `$ yolo image-editor` or `# echo /usr/bin/image-editor >> /etc/yololist`.
A permission system that protects /usr/bin and /root, while /home/alex, where all my stuff is is a free-for-all, is bad. I know about chroot and Linux namespaces, and SELinux, and QEMU. None of these are an acceptable way to to day-to-day computing, if you actually want to get work done.
That claim is too generic to add anything to this discussion. Ok, everything has a trade off. Thanks for that fortune cookie wisdom. But we’re not discussing CS theory 101. In this case in particular, what is the cost exactly? Is it a cost worth paying?
The cost is that developing that simple script to execute something and accessing files will have to be constructed differently. It will be much more complex.
That or the OS settings for said script will need to be handled. That is time and money.
I've said this elsewhere in this thread - but I think it might be interesting to consider how capabilities could be used to write simple scripts without sacrificing simplicity.
For example, right now when you invoke a script - say "cat foo.js" - the arguments are passed as strings, parsed by the script and then the named files are opened via the filesystem. But this implicitly allows cat to open any file on your computer.
Instead, you could achieve something similar with capabilities. So, I assume the shell has full access to the filesystem. When you call "cat foo.js", the shell could open the file and pass the file handle itself to the "cat" program. This way, cat doesn't need to be given access to the filesystem. In fact, literally the only things it can do are read the contents of the file it was passed, and presumably output to stdout.
> It will be much more complex.
Is this more complex? In a sense, its exactly the same as what we're doing now. Just with a new kind of argument for resources. I'm sure some tasks would get more complex. But also, some tasks might get easier too. I think capability based computing is an interesting idea and I hope it gets explored more.
> how capabilities could be used to write simple scripts without sacrificing simplicity.
I proposed a solution for that in my original comment - you should be able to trivially bypass the capability system if you trust what you're running ($ yolo my_script.sh).
The existance of such a "yolo" command implies you're running in a shell with the "full capabilities" of your user, and that by default that shell launches child processes only a subset of those. "yolo" would then have to be a shell builtin, that overrides this behavior and launches the child process with the same caps as the shell itself.
> That claim is too generic to add anything to this discussion. Ok, everything has a trade off. Thanks for that fortune cookie wisdom.
It isn't fortune cookie wisdom and no it isn't "too generic". It is something that fundamentally wasn't understood by the person I was replying to from their comment. I also don't believe you really understand the concept either.
> But we’re not discussing CS theory 101.
No we are not. We are discussing concepts about security and time / money management.
> In this case in particular, what is the cost exactly? Is it a cost worth paying?
You just accused me of "fortune cookie wisdom" and "being too generic". While asking a question where the answer differs dependant on the person / organisation.
All security is predicated on what you are protected against. So it is unique to your needs. What realistically are your threats. This is known as threat modelling.
e.g. I have a old vehicle. The security on it is a joke. Without additional third party security products, you can literally steal it with a flat blade about two inches long and drive away. You don't even need to hot-wire it. Additionally it is highly desirable by thieves. I can only realistically as a individual without a garage to store it in overnight, protect it from an opportunist. So I have a pedal box, a steering wheel lock, and a secret key switch that turns off the ignition and only I know where it is in the cab. That is like stop an opportunist. However more determined individuals. It will be stolen. Therefore I keep it out of public view when parked overnight. BTW because of the security measures, it takes about a good few minutes to be able to drive anywhere.
Realistically. Operating system security is much better than than it was. It is at the point that many recent large scale hacks in the last few years were initiated via social engineering to bypass the OS security entirely. So I would say it is in the area of diminishing returns already. So the level of threats I face and most people face, it is already sufficient. The rest I can mitigate myself.
Just like my vehicle. If a determined individual wants to get into you computer they are going to do so.
Thanks for educating me there champ. I'm sure you're very smart. But I've been writing software for a few decades now. Longer than a lot of people on HN have been alive. There's a good chance the computer you're using right contains code I've written. Suffice it to say, I'm pretty familiar with the idea of engineering tradeoffs. I suspect many other people in this thread are familiar with it too.
You missed the point the person you were replying to upthread was making. You're technically right - there is always some tradeoff when it comes to engineering choices. But there's a pernicious idea that comes along for the ride when you think too much about "engineering tradeoffs". The idea is that all software exists on some paraeto frontier, where there's no such thing as "better choices", there's only "different choices with different tradeoffs".
This idea is wrong.
The point made upthread was that often the cost of some choice is so negligible that its hardly worth considering. For example, if you refactor a long function by splitting it into two separate functions, this will usually result in more work for the compiler to do. This is an engineering tradeoff - we get more readability in exchange for slower compile times. But the compilation speed difference is usually so miniscule that we don't even talk about it.
"Everything comes with tradeoffs" is technically true if you look hard enough. But "No, not everything is a trade-off. Some things are just good and some are just bad" is also a good point. Some things are better or worse for almost everyone. Writing a huge piece of software using raw assembly? Probably a bad idea. Adding a thorough test suite to a mission-critical piece of software? Probably a good idea. Operating systems? Version control? Yeah those are kinda great. All these things come with tradeoffs. But the juice can still be worth the squeeze.
My larger point in this thread is that perhaps there are ways we can improve security that don't make computing measurably worse in other ways. You might not be clever enough to think of any of them, but that isn't proof that improvements aren't possible. I wasn't smart enough to invent typescript or rust 20 years ago. But I write better software today thanks to their existence.
I would be very sad if, in another 30 years, we're still programming using the same mishmash of tools we're using today. Will there be tradeoffs involved? Yes, for sure. But no matter, the status quo can still be improved.
> Realistically. Operating system security is much better than than it was. [...] So I would say it is in the area of diminishing returns already. So the level of threats I face and most people face, it is already sufficient.
What threat models are you considering? Computers might be secure enough for you, but they are nowhere near secure enough for me. I also don't consider them secure enough for my parents. I won't go into detail of some of the scams people have tried to pull on my parents - but better computer systems could easily have done a better job protecting them from some of this stuff.
If you use programming languages with a lot of dependencies, how do you protect yourself and your work against supply chain attacks? Do you personally audit all the code you pull into a project? Do you continue doing that when those dependencies are updated? Or do you trust someone to do that for you? (Who?). This is the threat model that keeps me up at night. All the tools I have to defend against this threat feel inadequate.
> If you want to run an alternative operating system, you got to learn how it works.
The typical user doesn't know how Windows works, and they can run that. These days, users can run a friendly GNU/Linux distribution not knowing how it works. So, disagree with you here.
> The typical user doesn't know how Windows works, and they can run that.
That is because Windows for the most part manages itself and there are enough IT professionals, repairs shops and other third support options (including someone that is good with computers that lives down the road) where people can problems sorted.
This is not the case with Linux.
> These days, users can run a friendly GNU/Linux distribution not knowing how it works. So, disagree with you here.
Sooner or later there will be an issue that will need to be solved with opening up a terminal and entering a set of esoteric commands. I've been using Linux on and off since 2002. I have done a Linux from Scratch build. I have tried most of the distros over the years, everything from Ubuntu to Gentoo.
When people claim that you will never have to know how it works. That is simply incorrect and gives a false impression to new users.
I would rather that other Linux users tell potential users the truth. There is trade off. You get a lot more control over your own computer, but you will need to peek under the hood sooner or later and you maybe be on your own solving problems yourself a lot of the time.
> That is because Windows for the most part manages itself
Windows is the least "manage itself" OS out of all OS available today. It needs pretty constant maintenance and esoteric enchantments to keep trucking.
That’s not my experience with it. I have 2 windows installations at home and they both seem fine.
I must admit - I spent about an hour figuring out how to turn off telemetry and other junk after installation. But since then, windows has been trucking along just fine.
I wonder why! Has your workplace installed weird junk on the machine which is gumming it up? Are you using some set of configuration options that microsoft doesn't regularly check?
My experience of windows is that it works pretty well these days. But I don't develop on windows - I just use it for entertainment (steam, vlc, etc). So there's probably a lot of edge cases that I'm not hitting.
It wasn't ever different when I ran windows on my personal computers, although granted that was back in 8.1. 8.1 was just bad for a variety of reasons, but it definitely still had the rot problem.
The latest in my saga of Windows being annoying is applications just randomly killing themselves when I'm not looking. I don't reboot my work computer because I have far too much precious stuff open.
But, every other day or so, an application or two will mysteriously disappear from my taskbar. Silently. I never catch it, then I get the "hey did you see this email??"
Why no, no I did not. Outlook committed suicide at some point and I'm not pocket watching the windows taskbar. My mistake.
For a while I thought I just hallucinated me closing the application, but I don't close applications, like, ever.
To put into perspective, my work has a policy which forcefully reboots windows once every 14 days. It helps, but not much, because by day 2-3 it's already breaking down. My Debian machine has an uptime of a few hundred days. I legitimately still have applications open from last year.
Maybe I use my computer like a psychopath, or maybe my expectations are too high, but I don't consider windows to take care of itself. Its the most babying-an-OS I ever have to do. iOS and Android are much better as well.
No it doesn't. I barely do anything to manage my Windows Installation. I install loads of garbage (I mostly still run the same programs as I did 15 years ago).
I don't understand why people propagate these falsehoods.
Windows rots. Even a few days without a reboot and things will just stop working or be really slow. No idea why.
But if you don't clean install once every few years you'll just have a ton of shit everywhere. Programs don't clean themselves up.
Also every program has its own update mechanism. Great... now I don't just have to manage windows update, but also a few dozen other esoteric update mechanisms.
iOS and Android are self managing. Windows? Can we be for real? Why get on the internet and lie to people?
Anybody who is good with computers should be able to install linux, it's easier than to install windows, because you don't need to jump through capitalist dark patterns.
>Sooner or later there will be an issue that will need to be solved with opening up a terminal and entering a set of esoteric commands.
That's what I did to export drivers from previous windows installation in suspicion of regression.
>Installation is not the same as support and isn't the same as trouble shooting.
The meme is still alive that windows accumulates garbage and becomes slower with time, so you need to reinstall it periodically. Reinstallation is also how you fix regressions, because ms is busy with cloud services.
>It isn't unusual situation in Linux.
As I remember, on linux I have an ample choice of kernel versions, but I didn't encounter regressions. For windows intel provides only the latest drivers.
> The meme is still alive that windows accumulates garbage and becomes slower with time, so you need to reinstall it periodically.
I've not needed to worry about this since Windows XP. Which was what? 25 years ago almost.
> Reinstallation is also how you fix regressions, because ms is busy with cloud services.
I've never had hardware regressions with Windows. I've had plenty of weird and annoying bugs return with Linux.
e.g. My Dell 6410 has an issue where the wifi card would die after suspend with kernel 6.1. However it would get fixed by a patch, and then get unfixed the next patch.
> As I remember, on linux I have an ample choice of kernel versions, but I didn't encounter regressions. For windows intel provides only the latest drivers.
"Swings and Roundabout".
Again. It is a pretty niche problem. I've had plenty of weird hardware regressions with the Kernel. Recently there was a AMD HDMI audio bug, IIRC it was kernel related.
I’ve had the same experience. Never had a regression with windows. Had plenty with Linux.
One Linux kernel version broke hdmi audio and another fixed it. Recently a change to power management has made my Intel Ethernet controller stop working about an hour after the computer boots up. And so on. Each time I’ve needed to pouring through forums trying to find the right fix. That or pin an older version which worked correctly.
>I've never had hardware regressions with Windows.
Until recently I didn't either. Windows resizing to 640x480 when display turns off and sound resetting to 100% after a toast notification.
>It is a pretty niche problem.
I think hdmi audio is a niche problem. What do you even use it for? With linux you can at least try a different version, with windows you have to just eat it.
I think a lot of it is "nobody has bothered building it yet" vs security.
Eg Qubes runs everything in Xen isolates - which is a wildly complex, performance limiting way to do sandboxing on modern computers. There are much better ways to implement sandboxing that don't limit performance or communication between applications. For example SeL4's OS level capability model. SeL4 still allows arbitrary IPC / shared memory between processes. Or Solaris / Illumos's Zones. But that route would unfortunately require rewriting / changing most modern software.
> I think a lot of it is "nobody has bothered building it yet" vs security.
All of this takes considerable time, money to build and after that you need to get people to buy into it anyway. Large billion dollar software companies have difficulty doing this. If you think it is so easy, go away and build a proof of concept.
BTW They have implementing sand-boxing in most desktop operating system. It is often a PITA. Phone like permissions model already exist in Windows, Linux and I suspect MacOS in various guises.
For development there are various solutions that already exist.
So these things already exist and often people don't use them. The reason for that is that there is usually reduces usability by introducing annoyances.
> Eg Qubes runs everything in Xen isolates - which is a wildly complex, performance limiting way to do sandboxing on modern computers.
It exists though today. If I care about security enough, I am willing to sacrifice performance. That is a trade off that some people are willing to make.
> There are much better ways to implement sandboxing that don't limit performance or communication between applications. For example SeL4's OS level capability model. SeL4 still allows arbitrary IPC / shared memory between processes. Or Solaris / Illumos's Zones. But that route would unfortunately require rewriting / changing most modern software.
If you solution starts with "rewriting most modern software". Then it isn't really a solution.
BTW what you are suggesting is a trade off. You have to trade resources (time and money typically) to build the thing and then you will need to spend more resources to get people to buy into using your tech.
What happens when the OS that is running the browser fails to update because /boot has run out of room for a new Linux kernel (this happened to me the other week)?
What happens when the browser update fails because the package database got corrupted?
What happens when a lock file stop the whole system updating because of a previous iffy update?
You are going to need to drop to a terminal and fix that issue or reinstall the whole OS.
Either way you are going to need to know something about how the machine works.
I use Debian Stable on my laptop and workstation. Most packages you don't need newer versions. I don't need the latest version of Gnome or Gedit or whatever.
I don't understand why people like the rigmarole of constantly updating their systems. The only things that come down the wire are security updates.
Installer newer software can be managed. I use the following strategy:
- For Discord / Slack / <something that needs to be the newest>. I can normally use Flatpak.
- Use a third party repo. For Brave, Node and some other things. I use their repository.
- Open source stuff. For smaller stuff that is easy to compile from source e.g. vim / neo-vim I just compile from source so I have the newest versions.
- Python Apps / NPM tooling. I install them in my local user directory.
I have some quad core celeron board integrated thing. It draws 15watts. I added a PCI-E sata which gave me 6 extra ports. I am sure you can buy better ones.
I used a Fractal Node Case that has 6 drive bays. Installed TrueNAS Scale on an SSD. Swapping drives is a pain as I have to take the computer apart. But that is infrequent. So it is fine.
If you still use HDD's they pull around 10w each, 15w for the board is not too bad. (My current quite old machine is something like 40-50w, disks being the big draw), still at 15W you'll get a fair bit more perf than with any Arm board.
The difference here is pretty much negligible to the vast majority of folks.
10w is... Nothing. There are only very specific cases where it's worth picking hardware on this constraint, and unless you're on a solar powered sail boat or something similarly niche, you probably shouldn't be prioritizing this.
In my region, 10w comes out to about 0.90 USD/month. Or roughly 3 pennies a day.
Over the entire lifetime of the device (5 years assumed) it's less than 50 USD in power costs.
I'll take basically any other quality of life improvement instead...
10W constant over 10 years would cost me 275 euro. My hard drives (7 ST2000DL003 and one ST2000DL001) are 10-15 years old now. They're all different batches, none failed yet, so I expect it to last at least 5 more years, possibly a lot more.
The current NAS setup I have (router + DAS + 2 USB) is around 50W. Over 20years it will cost me ~2800 euro in today's prices. So you see, the electricity is a very significant portion of TCO. In fact, it's more than half, because I bought everything second-hand.
Your setup is a tiny niche of a niche. Nobody using a NAS is using tiny 2TB HDDs in 2025 when 20+TB drives are so available.
I feel like you are making your setup more complicated than is even worth and searching for a weird solution when all you need is a RasPi with a big 16+TB USB HDD connected to it.
> 10W constant over 10 years would cost me 275 euro.
€2.30 per month. Which is almost nothing.
> Over 20years it will cost me ~2800 euro in today's prices.
That is €11 a month over 20 years. So the extra 10 watts is still next to nothing even taking into account your exaggerated time frames, which I am dubious as to whether this is real.
I am certainly not going to worry about €11 a month.
> I suspect, as with programming languages, some people think in a way that makes it easy for them and others think in a way that makes it hard.
No that often isn't the case. What is usually the case is that people don't bother the learning the basics. CSS is very easy. You can literally mess about with it on the fly in the browser and instantly see the result.
It is easier now than it has ever been. Since all the browsers for the most part implement the standards properly. Safari is the only standout and all the issues with that are well known.
> In large part because the syntax is ugly, but also because it just doesn't "mesh" with me. If I'm reading it or writing it, I always feel like I'm having to decode it. But I can easily and happily work with some programming languages that most devs would cross the street to avoid.
It is probably because you haven't learned the basics.
Whenever anyone has issues understanding CSS, they haven't bothered learning the basics and think they can flub their way through doing it.
I don't understand what is ugly about the syntax.
<some element selector> {
property_1: <some value>
property_2: <some other value>
}
It is about as straight forward as it could be. The difficulty with CSS is organisation as the web app becomes larger. There are well documented strategies on how to do this.
> As a user, nothing would thrill me more than if web pages just stopped using JS, though, so I am very happy that there is a feasible alternative to doing that that web devs could enjoy!
Non-trivial functionality requires JS. Basic Websites rarely require JS. So I am not sure what you are trying to say here.
Honestly the best thing I tell people to get some decent css basics is try to build a few stylus themes.
You can instantly see the results in devtools. I can't think of any other language that does that besides html, and even then you have to save and refresh.
Css is pretty easy to pick up in the chrome devtools at least because it has built in autocomplete. Showing you exactly what you can set the values too etc
I don't understand how that is the case when you say you can figure out much more complicated programming languages. It strains credulity.
I am a former front-end developer that managed to figure out AWS, Go, C++, C#, JavaScript, Python, OpenGL and have done a LFS build. I am not some sort of mega genius. I just had to go through and read the correct material and learn the basics.
CSS is easy, but it's not simple - it's enormously complex. Imagine the worst sins you could commit in a Ruby or Python codebase, multiply that by 100x and that's a normal CSS codebase.
It probably seems easy to you because you are already familiar with the pitfalls. For me, CSS felt like an endless minefield of unexpected interactions. When you say that "CSS is easy", do you perhaps mean only the syntax and the basic language structure? I would agree, but that doesn't get you very far; actually trying to use CSS frustrated me so much that I simply don't touch anything related to the web at all anymore.
I learned the basics in maybe a day almost 20 years ago now. I could make a page template with PHP and style that in maybe a day. This was back when IE6 was dominate, I don't think Firebug was even a thing.
At that time I was a novice, didn't know what a debugger was (I printed everything out the the console / page) and didn't know what an IDE was (I think I was using Notepad++). I managed this feat by following the tutorial.
The biggest problem I had was that I couldn't understand why centre, and colour didn't work. Once I realised that I had to spell everything in American English, that problem quickly went away.
I too learned the basics of CSS back in the IE6 era, and I had no trouble following the steps of the tutorials, using similarly primitive tools. If I'd had an experience like yours, I suppose my career might have gone in a different direction. Instead, though, as soon as I tried to take what I thought I had learned from those tutorials and make something of my own, I smashed into a wall of chaos; nothing seemed to be predictable. I knew the browser could do what I was imagining, because I had been making it do that for years already via tables and repeating GIFs and all that, but trying to do it with CSS got me nowhere.
> Intuitive function names like __new__() and __init__()? Or id() and pickle.dumps()?
I use python for some basic scripting and I don't write anything huge. Most of these do roughly what I would expect.
> __new__ is a static method that’s responsible for creating and returning a new instance (object) of the class. It takes the class as its first argument followed by additional arguments.
> In Python, __init__ is an instance method that initializes a newly created instance (object). It takes the object as its first argument followed by additional arguments
> Python id() function returns the “identity” of the object. The identity of an object is an integer, which is guaranteed to be unique and constant for this object during its lifetime.
The pickel.dumps() is the only one that is a bit odd until to find out what the pickle module does.
> The accessibility of Python is overrated.
The accessibility isn't overrated. Python has something that is missing from a lot of languages that isn't often talked about. It is really good a RAD (Rapid Application Development). You can quickly put something together that works reasonably well, it also is enough of the proper language that you can build bigger things in it.
> It's a language with warts and issues just like the others.
>The difference between new and init is not knowable from reading their names. The same is true of pickle. By definition, that makes them unintuitive.
By that standard nothing is. At some point if you are using a programming language you are going to have to RTFM. None of things you cherry-picked would be used by a novice either.
Even the pickle.dumps() example is obvious when you read the description for the module and works exactly the same to json.dumps(), which works similarly to dumps() methods and terminology in other programming languages.
I feel like I am repeating myself.
> A lot of languages work for RAD including Clojure, C#, and JavaScript. This is nothing special about Python.
Nonsense. None of those I would say are RAD. JavaScript literally has no standard lib and requires node/npm these days and that can be a complete rigmarole in itself. C# these relies heavily on DI. I have no idea about Clojure so won't comment.
All the RAD stuff in C# and JS is heavily reliant on third party scripts and templates, that have all sorts of annoying quirks and bloat your codebase. That isn't the case with Python at all
R.E. scaffolding in C#, with upcoming .NET 10, it's really simple:
- Write code to myfile.cs
- `dotnet run myfile.cs`
That doesn't need scaffolding either. And the standard library is huge too; you could even add dependencies in that file.
And since we're talking about RAD, Python can't even compare to Clojure. Having a separate REPL "server" that you interact with from your text editor with access to the JVM's ecosystem and standard library inside of a "living" environment and structural navigation from being a LISP is pure RAD. Heck, I often start a REPL "server" inside chrome's devtools with scittle[1] if I need to rapidly and programmatically interact with a website and/or to script something; I haven't been able to do that anywhere else. Even pure JS.
> R.E. scaffolding in C#, with upcoming .NET 10, it's really simple: - Write code to myfile.cs - `dotnet run myfile.cs`
> That doesn't need scaffolding either. And the standard library is huge too; you could even add dependencies in that file.
I've just had a quick look at some of this and they've basically just moved stuff in to the cs file from the proj file. I remember them saying this was on the roadmap when I was doing a .NET 8 refresher.
// app.cs
#:package Humanizer@2.*
using Humanizer;
It also seems anything non-trivial will still require proj files. Which means that they are likely to still have project templates etc.
> And since we're talking about RAD, Python can't even compare to Clojure.
I am unlikely to ever use Clojure, I certainly won't be able to use it at work.
> Having a separate REPL "server" that you interact with from your text editor with access to the JVM's ecosystem and standard library inside of a "living" environment and structural navigation from being a LISP is pure RAD. Heck, I often start a REPL "server" inside chrome's devtools with scittle[1] if I need to rapidly and programmatically interact with a website and/or to script something; I haven't been able to do that anywhere else. Even pure JS.
All sounds very complicated and is the sort of thing I am trying to get away from. I find all of this stuff more of a hinderance than anything else.
Okay, and? I didn't make the claim that some other language was all that. I was dispelling the claim that Python is.
> Even the pickle.dumps() example is obvious
Well, we've so far been restricted to function names which is what the claim was. There are plenty of cryptic other names in Python like ABCMeta, deriving from `object`, MRO, slots, dir, spec, etc.
The idea you can't do RAD with libraries is insane. Games are developed rapidly, and a lot of game engines use C#. The fact that you're using Unity, a very large dependency, means nothing regarding whether you can do RAD, which is more about having the right architecture, tooling, and development cycle.
> Okay, and? I didn't make the claim that some other language was all that. I was dispelling the claim that Python is.
I believe that people should RTFM. Any arguments that is predicated on not reading the documentation for the language, and then pretending that it is somehow opaque, I am going to dismiss to be quite honest.
> Well, we've so far been restricted to function names which is what the claim was. There are plenty of cryptic other names in Python like ABCMeta, deriving from `object`, MRO, slots, dir, spec, etc.
You are still cherry-picking things to attempt to prove a point. I don't find this convincing.
> The idea you can't do RAD with libraries is insane. Games are developed rapidly, and a lot of game engines use C#. The fact that you're using Unity, a very large dependency, means nothing regarding whether you can do RAD, which is more about having the right architecture, tooling, and development cycle.
I didn't say that you can't do RAD with libraries. You didn't understand what I was saying at all.
I can get up and running with Python in mere minutes. It doesn't require a application templates/scaffolding apps to get started (like C# and JS/TS). You just need a text editor and a terminal. Doing that is still quicker and easier to get something working than all the gumpf you have to do with the other languages. I BTW was a JS/TS and .NET for about 15 years
I just wish there were more Python and Go jobs in the UK.
C# does not require scaffolding any more than Python does. It comes with a large standard library (aka .NET). Even the NodeJS standard library is quite large now too. How much setup you need really depends on what you are trying to do; if you are using Django, there will be an insignificant amount of that, and some of the most complicated setups I've seen have been with Pylons/Pyramid. If you're just making a CLI app, well I don't see how it's any less setup with Python than with Node. And anyway, RAD isn't about setup time, it's about iteration time.
I feel you on the lack of Go jobs. It seems like they aren't very well globally distributed...
> C# does not require scaffolding any more than Python does.
They've changed so much in the last few years I honestly don't know anymore. Which is part of the entire problem.
The last time I bothered writing anything with C# / .NET was .NET 8. They definitely had scaffolding tools for popular project types. Setting stuff up from a blank project wasn't straight forward.
> It comes with a large standard library (aka .NET). Even the NodeJS standard library is quite large now too.
I find dealing with C++ and CMake/Make (I hobby program Vulkan/OpenGL) easier than dealing with Node JS and NPM. People think I am being hyperbolic when I say this, I am not. Which show you how insane the JS ecosystem is.
I am honestly fed up of both C# and JS. There are far more headaches with both (especially if you are using TypeScript).
If you use TypeScript and don't want to use babel, until recently you have to basically use tsx or tsnode .
You then have to wrangle a magic set of options in the tsconfig.json to have some popular libraries work.
.NET after 5 has absolute DI madness in ASP.NET and none of it seems documented properly anywhere (or I can't find it) and it seems to change subtly every time they update .NET or ASP.NET.
I ended up resorting to pulling down the entire source code to see what the Startup was doing. C# now has total language and syntactic sugar overload.
I have almost none of these headaches with Python and Go.
> And anyway, RAD isn't about setup time, it's about iteration time.
It is both. I find Python quicker, easier and less headaches that either JS or .NET. I am well versed in C# and JS.
I know less Python than .NET and JS/TS, yet I find it easier.
> I feel you on the lack of Go jobs. It seems like they aren't very well globally distributed...
That is true. I am sure most Go jobs advertised in the UK are in London.
No they shouldn't have done. The Browser API Implementation doesn't exist in TypeScript. It exists in the browser. TypeScript shouldn't be fixing how the browser behaves.
Think about what is happening. When you build to the browser as a target, TSC basically transpiles the TypeScript code to JavaScript. The Browser APIs that Typescript provides are a bunch of type definitions. When it transpiles the code the only thing it can really do is check the types match up.
Generally most Linux distributions are literally the same thing underneath. I have recently done an LFS build (using version 12.3 of the book). The same files were in the same directories in Debian, Arch and LFS for the most part.
I even had a look at source code for makepkgs in Arch and they are literally the same commands in the script that the book has you manually type in.
The packaging critique comes up over the years but it is a bit of an overblown.
Building packages for different distributions isn't super difficult. I've build Arch Packages using the ABS, DEBS and RPMS and they are all conceptually the same. Having a quick skim of the Flatpak instructions it doesn't look that different either.
If you don't want to bother with all of that. You can just have a script that drops the installation either in /opt or ~./.local/. I am pretty sure Jetbrains Toolbox does that, but I would need to check my other machine to confirm and I don't have access currently.
Everything you have suggested in this post takes away freedom. There is no solution that doesn't take away freedom / your control. There is always a trade off.
> Like sandboxing applications by default. Applications should by default run on my computer with the same permissions as a browser tab. Occasionally applications need more access than that. But that should require explicit privilege escalation rather than being granted to all programs by default. (Why do I need to trust that spotify and davinci resolve won't install keyloggers on my computer? Our computers are so insecure!)
This already exists on Linux.
I run Discord/Slack in Flatpak. Out of the box the folders and clipboard permissions are restricted. Only the ~/Downloads folder on my PC is accessible to Discord/Slack. You can't drag and drop things into these apps. Which makes sharing content a PITA.
If you don't want to worry about things like keyloggers, you should run an open source OS and use open source programs where you can verify that there are no key loggers. You should also make sure you find out what firmware your keyboard is using (many keyboards themselves have complex micro controllers on them that can be programmed).