Which areas of Linux would benefit most from further standardization?
-
- find something Lennart built. Eg. systemd
- remove that
- go to 1
Yes, I find that dude to be very disagreeable. He's like everything that haters claim Linus Torvalds is - but manifested IRL.
-
I've never understood putting arbitrary limits on a worker's laptop. I had always been seeking for ways to hijack them. Once I ended up using a VM,
without limit...Rule #1 never trust your users
-
Would you mind providing some reasoning so this doesn't come off as unsubstantiated badmouthing?
My experience with systemd has been the opposite. Thanks to systemd, many core tools have consistent names and CLI behaviors.
Before systemd I used sysVinit, upstart and various other tools.
I’m glad systemd alternatives exist as part of a diverse Linux ecosystem but I haven’t had a compelling reason to not use systemd.
-
One that Linux should've had 30 years ago is a standard, fully-featured dynamic library system. Its shared libraries are more akin to static libraries, just linked at runtime by ld.so instead of ld. That means that executables are tied to particular versions of shared libraries, and all of them must be present for the executable to load, leading to the dependecy hell that package managers were developed, in part, to address. The dynamically-loaded libraries that exist are generally non-standard plug-in systems.
A proper dynamic library system (like in Darwin) would allow libraries to declare what API level they're backwards-compatible with, so new versions don't necessarily break old executables. (It would ensure ABI compatibility, of course.) It would also allow processes to start running even if libraries declared by the program as optional weren't present, allowing programs to drop certain features gracefully, so we wouldn't need different executable versions of the same programs with different library support compiled in. If it were standard, compilers could more easily provide integrated language support for the system, too.
Dependency hell was one of the main obstacles to packaging Linux applications for years, until Flatpak, Snap, etc. came along to brute-force away the issue by just piling everything the application needs into a giant blob.
I find the Darwin approach to dynamic linking too restrictive. Sometimes there needs to be a new release which is not backwards compatible or you end up with Windows weirdness. It is also too restrictive on volunteer developers giving their time to open source.
At the same time, containerization where we through every library - and the kitchen sink - at an executable to get it to run does not seem like progress to me. It's like the meme where the dude is standing on a huge horizontal pile of ladders to look over a small wall.
At the moment you can choose to use a distro which follows a particular approach to this problem; one which enthuses its developers, giving some guarantee of long term support. This free market of distros that we have at the moment is ideal in my opinion.
-
Domain authentication and group policy analogs.
An immutable distro would be ideal for this kind of thing. ChromeOS (an immutable distro example) can be centrally managed, but the caveat with ChromeOS in particular is that it's management can only go through Google via their enterprise Google Workspace suite.
But as a concept, this shows that it's doable.
-
The diversity of Linux distributions is one of its strengths, but it can also be challenging for app and game development. Where do we need more standards? For example, package management, graphics APIs, or other aspects of the ecosystem? Would such increased standards encourage broader adoption of the Linux ecosystem by developers?
Where app data is stored.
~/.local
~/.config
~/.var
~/.appname
Pick one and stop cluttering my home directory
-
The diversity of Linux distributions is one of its strengths, but it can also be challenging for app and game development. Where do we need more standards? For example, package management, graphics APIs, or other aspects of the ecosystem? Would such increased standards encourage broader adoption of the Linux ecosystem by developers?
Standardizing package management? Imagine everyone being stuck with .rpm
-
Domain authentication and group policy analogs.
i’ve never understood why there’s not a good option for using one of the plethora of server management tools with prebuilt helpers for workstations to mimic group policy
like the tools we have on linux to handle this are far, far more powerful
-
Where app data is stored.
~/.local
~/.config
~/.var
~/.appname
Pick one and stop cluttering my home directory
it's pretty bad. steam for example has both
~/.steam and
~/.local/share/Steam
for some reason. I'm just happy I moved to an impermanent setup for my PC, so I don't need to worry something I temporarily install is going to clutter my home directory with garbage -
Where app data is stored.
~/.local
~/.config
~/.var
~/.appname
Pick one and stop cluttering my home directory
I have good news and bad news:
A specification already exists. https://specifications.freedesktop.org/basedir-spec/latest/
-
An immutable distro would be ideal for this kind of thing. ChromeOS (an immutable distro example) can be centrally managed, but the caveat with ChromeOS in particular is that it's management can only go through Google via their enterprise Google Workspace suite.
But as a concept, this shows that it's doable.
I don't think anyone was saying it's impossible, just that it needs standardization. I imagine windows is more appealing to companies when it is easier to find admins than if they were to use some specific linux system where only a few people are skilled to manage it.
-
- find something Lennart built. Eg. systemd
- remove that
- go to 1
I regret that I have but a single upvote for you
-
Where app data is stored.
~/.local
~/.config
~/.var
~/.appname
Pick one and stop cluttering my home directory
This would be convenient indeed, but I've learned to be indifferent about it as long as the manual or readme provides helpful and succinct information.
-
The diversity of Linux distributions is one of its strengths, but it can also be challenging for app and game development. Where do we need more standards? For example, package management, graphics APIs, or other aspects of the ecosystem? Would such increased standards encourage broader adoption of the Linux ecosystem by developers?
I'm not sure whether this should be a "standard", but we need a Linux Distribution where the user never has to touch the command line. Such a distro would be beneficial and useful to new users, who don't want to learn about command line commands.
-
I'm not sure whether this should be a "standard", but we need a Linux Distribution where the user never has to touch the command line. Such a distro would be beneficial and useful to new users, who don't want to learn about command line commands.
-
nix can deal with this kind of problem. Does take disk space if you're going to have radically different deps for different apps. But you can 100% install firefox from 4 years ago and new firefox on the same system and they each have the deps they need.
What OS? Unix?
-
Where app data is stored.
~/.local
~/.config
~/.var
~/.appname
Pick one and stop cluttering my home directory
This would also be nice for atomic distros, application space and system space could be separated in more cases.
-
What OS? Unix?
I use nixos. But the package manager its based on, nix, can be used on other OSes.
-
The diversity of Linux distributions is one of its strengths, but it can also be challenging for app and game development. Where do we need more standards? For example, package management, graphics APIs, or other aspects of the ecosystem? Would such increased standards encourage broader adoption of the Linux ecosystem by developers?
Each monitor should have its own framebuffer device rather than only one app controlling all monitors at any tine and needing each app to implement its own multi-monitor support. I know fbdev is an inefficient, un-accelerated wrapper of the DRI, but it's so easy to use!
Want to draw something on a particular monitor? Write to its framebuffer file. Want to run multiple apps on multiple screens without needing your DE to launch everything? Give each app write access to a single fbdev. Want multi-seat support without needing multiple GPUs? Same thing.
Right now, each GPU only gets 1 fbdev and it has the resolution of the smallest monitor plugged into that GPU. Its contents are then mirrored to every monitor, even though they all have their own framebuffers on a hardware level.
-
I'm not sure whether this should be a "standard", but we need a Linux Distribution where the user never has to touch the command line. Such a distro would be beneficial and useful to new users, who don't want to learn about command line commands.
Why do people keep saying this? If you don't want to use the command line then don't.
But there is no good reason to say people shouldn't. It's always the best way to get across what needs to be done and have the person execute it.
The fedora laptop I have been using for the past year has never needed the command line.
On my desktop I use arch. I use the command line because I know it and it makes sense.
