|
|
|
|
|
|
by loloquwowndueo
1912 days ago
|
|
|
You apparently didn’t read the parent: “ I'm sure the same model can be applied to Linux.” I was replying to that, so perhaps your reply belongs one level up. I read the parent as “all next-gen packaging formats should adopt this pattern” and envisioned a hell where said packages are the only way to get new software, if any of them gains enough traction. I already know of a few packages I depend on which are only officially packaged as snaps - I’ve had to find alternatives or look into compiling from source (not always feasible - I don’t have a ton of time to tinker anymore). |
|
|
Parent here. Whoa, you're reading too deep into that. How do you think that I envision such a future? Even I didn't know I've envisioned such a future.
If I had time to implement such an elaborate subsystem, I'd do it as a user-configurable kernel level interface. Like a more user-configurable, more flexible version of SELinux or AppArmor.
The first thing I'd implement would be a global on/off switch, too. I've seen and worked in enough projects where keeping it on was the only sensible choice, and I know enough that some people (incl. me in some scenarios) would like to keep it turned off.
For clarity, I neither support snaps, commercialization of Linux distributions to create commercial lock-ins, centralizing packages like Snap and dumbing down Linux. I already don't touch Chrome, Electron, VSCode and other pseudo opensource and pseudo free software and use some paid, cross-platform closed source software since they solve some real problems of mine, but I wouldn't dream of a Linux like you're creating by reading my simple comment.
Wow.