Which areas of Linux would benefit most from further standardization?
-
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.
-
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.
This right here is why i moved to a single display setup.
-
Systemd is fine. This sounds like an old sysadmin who refuses to learn because "new thing bad" and zero logic to back it up.
As a former sysadmin, there is plenty of logic in saying that. I have debugged countless systems that were using systemd, yet somehow the openrc ones just chug along. In the server space systemd is a travesty.
In the desktop space however, i much prefer systemd. Dev environments as well. So yes thst is where "it's fine". More than fine, needed!
I just hate this black and white view of the world, I cant stand it. Everything has its place, on servers you want as small a software footprint as possible, on desktop you want compatibility.
-
As a former sysadmin, there is plenty of logic in saying that. I have debugged countless systems that were using systemd, yet somehow the openrc ones just chug along. In the server space systemd is a travesty.
In the desktop space however, i much prefer systemd. Dev environments as well. So yes thst is where "it's fine". More than fine, needed!
I just hate this black and white view of the world, I cant stand it. Everything has its place, on servers you want as small a software footprint as possible, on desktop you want compatibility.
You're not wrong; I was just being hyperbolic.
-
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 really don't understand this. I put a fairly popular Linux distro on my son's computer and never needed to touch the command line. I update it by command line only because I think it's easier.
Sure, you may run into driver scenarios or things like that from time to time, but using supported hardware would never present that issue. And Windows has just as many random "gotchas".
-
I think webassembly will come out on top as preferred runtime because of this, and the sandboxing.
People thought the same about JVM
-
I'm primarily talking about Win32 API when I talk about Windows, and for Mac primarily Foundation/AppKit (Cocoa) and other system frameworks. What third-party libraries do or don't do is their own thing.
There's also nothing wrong with bundling specialized dependencies in principle if you provide precompiled binaries. If it's shipped via the system package manager, that can manage the library versions and in fact it should do that as far as possible. Where this does become a problem is when you start shipping stuff like entire GUI toolkits (hello bundled Qt which breaks Plasma's style plugins every time because those are not ABI-compatible either).
The amount of time that I had to get out of .dll-hell on Windows on the other hand. The Linux way is better and way more stable.
Try running an old precompiled Linux game (say Unreal Tournament 2004 for example). They can be a pain to get working. This is not just some "ooooh gotcha" case, this is an important thing that's missing for software preservation and cross-compatibility, because not everything can be compiled from source by distro packagers, and not every unmaintained open-source software can be compiled on modern systems (and porting it might not be easy because of the same problem).
I suppose what Linux is severely lacking is a comprehensive upwards-compatible system API (such as Win32 or Cocoa) which reduces the churn between distros and between version releases. Something that is more than just libc.
We could maybe have had this with GNUstep, for example (and it would have solved a bunch of other stuff too). But it looks like nobody cares about GNUstep and instead it seems like people are more interested in sidestepping the problem with questionably designed systems like Flatpak.
There was the Linux Standard Base project, but there were multiple issues with it and finally it got abandoned. Some distributions still have a /etc/lsb-release file for compatibility.
-
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?
Rewrite the entire kernel exclusively in rust!
-hehehe-
-
Where app data is stored.
~/.local
~/.config
~/.var
~/.appname
Pick one and stop cluttering my home directory
Yea I like how a lot have moved to using .config but mozilla just moved out of there and now has a .mozilla folder outside of it.. wtf... It is insanely sad.
I have actually moved my entire "user home folder".. folders out of there just because it is so ugly and unorganized. I now use /home/user/userfolders/.. all my stuff like documents / videos etc in here
-
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 -
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?
While all areas could benefit in terms of stability and ease of development from standadization, the whole system and each area would suffer in terms of creativity. There needs to be a balance.
However, if I had to choose one thing, I'd say the package management. At the moment we have deb, rpm, pacman, flatpak, snap (the latter probably should not be considered as the server side is proprietary) and more from some niche distros. This makes is very difficult for small developers to offer their work to all/most users.
Otherwise, I think it is a blessing having so many DEs, APIs, etc. -
Rewrite the entire kernel exclusively in rust!
-hehehe-
-
that .steam is a bunch of symlinks to the .local one.. which makes it even worse. they have also .steampid and .steampath.
and even worse a bunch of games are starting to add them there too.
Factorio puts game saves in ~/.factorio for some reason...
-
Factorio puts game saves in ~/.factorio for some reason...
