People say similar stuff about Serbians in Chicago (how it's the second biggest Serbian city after Belgrade), but usually all of that is overestimated significantly. Just like people overestimate their local city population (most in Belgrade claim it has 2M people when census on a metropolitan area gets us to 1.57M).
That file name thing was from Win95 keeping DOS (FAT) compatibility by introducing FAT32/VFAT: long file names were truncated to standard 8.3 names from DOS (and by extension, Win3.11 too) with fs extensions used to store long file names alongside DOS names. Win95 would show long names, DOS would show shorter ones.
Also, file formats were binary optimized at the time, compared to current XML behemoths compressed with zip. So 12MB file in 1993 is probably something like 100k+ rows, and try that out today.
A person who is like that is rarely called a "lovely person": how does that lovely interaction look like when you point such an egregious flaw out to them?
And tbh, this has nothing to do with being self-taught: by the time I enrolled in CS program, I was arguably self-taught and could spot issues like this myself. But I pride myself in learning from my mistakes and learning fast.
So it's more likely a character thing: if you are willing to admit when you are wrong, you'll learn much faster!
FWIW, Nokia did develop a pretty good Linux phone back in the day (Maemo/Meego) with Nokia N9 (it even received rave reviews from consumer tech sites like engadget), but it did get killed off as they got absorbed into Microsoft (we all know that didn't age well).
Similarly, Palm Pre, and especially HP Pre 3 was a wonderful WebOS incarnation.
Ubuntu Touch did seem like it had a future, but it was a massive sink for Canonical so it was defunded as well.
The user experience was there on all of these: the apps, not so much.
Ubuntu Touch is not dead though, I use it happily on my primary device for 8 years. It's working like a charm. And waydroid allows you to run APKs, even if some bank apps may not work.
Do you have any source for that claim? That would be a pretty serious security issue even unrelated to any security hardening (eg. on a multi-user system, one user could read out the password from another user — even with desktop usage, second user could be SSHed in).
As a datapoint, everything in /dev/input/* is owned by root:input on my Debian Bookworm install, and my main user is not a member of the "input" group either.
Biggest problem with most security hardening for Linux desktop is that it breaks the natural usage pattern: I store my files by their content, not by their format (eg. I might have a folder for my project containing image files, spreadsheets, FreeCAD files, maybe even some code or TeX/ODF files). If programs are restricted to access the entirety of my $HOME though, there is not much benefit to that protection since that's where my most valuable data is. If they are restricted to per-program folder, I need to start organizing my data differently and unnaturally.
Android mostly does not use the "files" metaphor and basically does exactly that (per-app data): coming up with a security model and file management UX that does both is where the challenge is.
It comes from a history of using mostly trusted application sources like Debian/Ubuntu package archives with manual review being the norm. And few supply chain attacks.
But both Flatpak and Snap offer this new model from the two biggest desktop players in the Linux world: Red Hat and Canonical.
As the sibling comment said though, being an administrator for your own computer (including a phone) does not mean that you will be running untrusted applications as one: on the contrary, if you assume an administrator role and run an untrusted application, naturally, all bets are off. But even as a power user, I'd love to be able to safely run programs I do not necessarily trust, feeding it only data it needs and no more.
Again, Snap/Flatpak provide this model, but we need to see more application authors take them up to ship their software.
It comes from a history of using mostly trusted application sources like Debian/Ubuntu package archives with manual review being the norm. And few supply chain attacks.
What most of these people do not seem to get is that proper sandboxing does not only protect against attacks from the inside (rogue developer, supply chain attack), but also from the outside. Most desktop apps probably have a good number of security vulnerabilities that can be exploited when they parse untrusted data. On the Linux desktop, most apps still use decades-old C libraries for parsing XML, images, JSON, etc.
Sandboxing also protects against external attacks.
Again, Snap/Flatpak provide this model, but we need to see more application authors take them up to ship their software.
Agreed, though for a lot of technical and social reasons, most apps still need privileges that allow trivial sandbox escapes on Flatpak (I don't know or care about Snap). Strengthening app sandboxing should be a top-priority for the Linux desktop, but only a few people seem to care. The same for fully verified boot, etc. Even things like UKIs only go so far, yet almost no distribution has adopted them.
The general security mindset of the Linux desktop community seems to be stuck in the 90ies, levitating between hahah, they cannot get root (as if that matters on desktop Linux) and secure boot and sandboxing is here to take my rights (on open source desktop Linux, seriously?).
I think you are mistaken. Just like neither Windows nor MacOS have really solved the desktop app sandboxing story, so neither has Linux.
Because, as I said in a sibling comment and cosmic_cheese notes further below, this requires rethinking the usage model altogether: files and folders, and even file types, don't work anymore.
If an app needs to access any related files, it basically needs access to my entire $HOME, and once that is granted, well, any sandboxing is out the window.
I think Linux community is well aware of that, and basically what we get from sandboxing of desktop apps is all the nuisance with no benefit.
Android model is also broken from a usage perspective: having files "owned" by an app is just as wrong, and precludes there being multiple apps operating on the same file. Example of VLC with subtitles is a common one, but if you've never used multiple apps on the same file, this is the challenge that is unsolved by any sandboxing approach today, because it is more of a UX problem, than a sandboxing technical problem.
I don't fully agree with cosmic_cheese's comment. If we take music as an example, you could put your music in a Music folder and open that folder using your music player/manager and that folder gets added to your sandbox. This is how macOS sandboxing works and it works fine. Moreover, you can protect certain directories by default, even for unsandboxed apps, as e.g. macOS does, where a random app that is not sandboxed cannot read your Mail, address book, documents folder, etc. unless you allow this.
All these things make security substantially better than the Linux model of every app gets access to your full home directory.
Sure, a capabilities-based OS or whatnot would work better, but would even be harder to implement in the current desktop Linux. Instead of gradually improving security, you are basically throwing away the baby with the bathwater.
You get exactly that with snaps/flatpaks which are not given access to your $HOME.
But even with your example, you might need access to cover art from your graphics editing app, and very quickly you get to the same state. How about lyrics file from your text editor or a dedicated one? And wait, I'd like to mix in some music into Audacity too. File portals are actually a decent solution there, but they only work for files with supported software.
Yes, you can adapt your workflow, but it's going to be adapting and you will lose some things you might love in your workflow.
> What most of these people do not seem to get is that proper sandboxing does not only protect against attacks from the inside (rogue developer, supply chain attack), but also from the outside.
The problem is that strict file system sandboxing in particular also breaks a substantial number of workflows that can't be modelled as 'only ever open the exact file the user explicitly' picked. (Any multi-file file formats are particularly affected, as well as any UI workflows that don't integrate well with strictly having to use the OS file picker.)
So you need some escape hatch for optionally allowing access to larger swathes of the file system, or even really everything as before, but that in turn then risks being abused again by malicious actors. And then…?
Plus things like Android's implementation initially using an API completely incompatible with classical file APIs, as well as causing some noticeable performance overhead even today if you need more than simply accessing the occasional single file here and there.
I think had the problem is that the toolbox we can deploy to solve these problems is so empty.
For example, it’s useful for a music player with metadata editing features to have read/write access to the whole filesystem, but that constitutes a significant risk since all we can do is wholesale allow or prevent access to the whole filesystem. What if the system could allow it to access only music files, though? That’d scope the risk back down to almost nothing while also allowing the music player to do its job.
This is the kind of thing I’ve been getting at in the other replies. Nobody has really sat down and given system level security controls a deep rethink.
I think Apple's implementation in macOS is the only one that offers some slightly more advanced features, but even those don't get you that far
(Some sort of way to store permission references with relatives paths in a file, but which most probably wouldn't work with files being exchanged cross-platform, and other than that mainly being able to get automatic access to 'related' files, i.e. same file name, but a differing extension – that solves some sidecar files, like video subtitles, or certain kinds of georeferenced images, but large capability gaps still remain – even the video subtitle example stops working if the file name is no longer 100 % the same, like if you have multiple subtitle files for differing languages, where VLC for example supports prefix-matching the video file name with the subtitle files.)
And while your idea does have its merits, I fear that pretty soon you still hit a point where you can't sensibly and succinctly display those more complex types of permissions in the UI.
> And while your idea does have its merits, I fear that pretty soon you still hit a point where you can't sensibly and succinctly display those more complex types of permissions in the UI.
I could very well be wrong, but my inclination is that it's possible, but it's going to take the sort of fundamentals R&D that desktop operating systems haven't seen in decades. It can't just be tacked on, everything to be designed with this new system in mind.
Agreed. I want to "own my device" as in "being able to install the system I want on it". Not as in "I want it to behave exactly like Desktop Linux", or whatever it is that people complain about AOSP.
On my Desktop I love Linux. But on my smartphone, I want AOSP.
Largely agreed, though I think on the desktop I’d also want AOSP in desktop mode with a traditional Linux distribution in a VM pretty much like Android 16’s Linux VM.
But then on desktop/laptop-class hardware, since the thermal constraints are different and it’s nice to have extensible storage and RAM. Of course, all this on the phone is also nice for when you only have your phone with you.
Then one could use fully sandboxed apps for banks, instant messaging, etc. and the VM for development.
Yes I can totally imagine that in a few years, most people will only need a smartphone and a dock station. At home, they will plug their phone (iOS, Android, whatever) to their dock station and it will behave as a Desktop. And it will be good enough for everything they do.
Flatpak and Snaps are built to solve this. They do conflict with some expectations from users to be able to play around with things, though, so they do not have the penetration one might want.
They only cover the user-facing app part of the story. The rest of the system needs isolation and safeguards, too, including things like the desktop environment and whatever random daemon.
A solution that's integral to the system and not just loosely taped on is required.
Docker style containerization technically works, but for desktop use I think is a rather heavy kludge and not really a solution.
It would be much more nice if e.g. daemons could have their privileges pared down to only exactly what they need to function and nothing more with a config file somewhere. This can somewhat be achieved with the user system, but that really doesn’t scale well and doesn’t suit the purpose all that well in some ways.
If you are in taller than 95% for men, and reasonably fit, you might need a bigger waistline (think 36 or more), which is still the same length for pants (up to 34) with your socks showing even when standing (depending on your individual proportions), but much wider around hips and legs than you need. I imagine for shorter men, it's the inverse but equally bad.
Some brands will carry slim and extra long trousers, but if I find a model that fits (not all models from the same brand do), I immediatelly buy a few. Otherwise, I try to get tailored stuff, but that's slow and annoying.
For shirts, it's even worse: unless you can find an extra long version, you are going to be wearing a sail and your underpants/ass will pop out when you sit down. But these are easier to get sewed for you as you can just have a single tailor make many of them as needed.
So it's probably easier for median men, but sizes scale exactly the same without regard to actual proportions for simply bigger people.
> I imagine for shorter men, it's the inverse but equally bad.
Not really, as a quite short guy, many shops will offer me to have the clothes fitted, and if not it's pretty trivial to fit them myself. Maybe on the most extreme end of short it's more of an issue, but in general I suspect shortening pants and shirts is signficantly easier than lengthening them.
I'm a 5'5", 110lbs man. I shop at the teens section and get larges. I may not get the trendiest looks, but I get cheaper clothes that fits and looks good on me!
I also tried Stitch Fix, they had a surprising amount of stuff that could fit me (both fashionably and size wise), albeit not as cheap as kids' clothes.
I might grab something like sweatpants from kids section, but for normal clothes I generally prefer a bit more quality. I work remotely so a good pair of pants can last me more than half a decade, so I don't mind buying quality and having it fitted. But yeah, I feel as a short guy there's actually more than plenty of options for us, I never felt that clothes were an issue. Well, there was a shop once that put the smallest sizes on the highest shelf, I don't know if they thought it was funny, but I didn't go back.
That's fair. I work remotely as well and to be honest I just cycle through the same two pants I got from Stitch Fix and a few collared shirts, and some concert merch for more casual outings.
I was speaking more to waistline — I have a 28 inch waist and the smallest I usually find is like 30 or more, so even a belt can't fix that.
Thanks both for the perspective: yeah, even if simply scaled down proportionally, you are left with too long garments that you can fold/shorten, so a much better situation than tall men who can end up looking like cartoon caricatures if dressed with widely available garments.
And don't get me wrong, tall girls (my sister is 6'1") have it even worse.
If we used MacOS throughout the org, and we asked a SW dev team to build inventory tracking software without specifying the OS, I'd squarely put the blame on SW team for building it for Linux or Windows.
(Yes, it should be a blameless culture, but if an obvious assumption like this is broken, someone is intentionally messing with you most likely)
There exists an expected level of context knowledge that is frequently underspecified.
Humans ask each other silly questions all the time: a human confronted with a question like this would either blurb out a bad response like "walk" without thinking before realizing what they are suggesting, or pause and respond with "to get your car washed, you need to get it there so you must drive".
Now, humans, other than not even thinking (which is really similar to how basic LLMs work), can easily fall victim to context too: if your boss, who never pranks you like this, asked you to take his car to a car wash, and asked if you'll walk or drive but to consider the environmental impact, you might get stumped and respond wrong too.
(and if it's flat or downhill, you might even push the car for 50m ;))
People say similar stuff about Serbians in Chicago (how it's the second biggest Serbian city after Belgrade), but usually all of that is overestimated significantly. Just like people overestimate their local city population (most in Belgrade claim it has 2M people when census on a metropolitan area gets us to 1.57M).
reply