Which areas of Linux would benefit most from further standardization?
-
Configuration gui standard.
Usually there is a config file that I am suppose to edit as root and usually done in the terminal.There should be a general gui tool that read those files and obey another file with the rules. Lets say it is if you enable this feature then you can't have this on at the same time. Or the number has to be between 1 and 5. Not more or less on the number.
Basic validation. And run the program with --validation to let itself decide if it looks good or not. -
Not really. There are barely any chips out there.
Oct 2021: 200 billion ARM chips
Nov 2023: 1 billion RISC-V chips, hoping to hit 16 billion by 2030
Nov 2024: 300 billion ARM chips
-
Generally speaking, Linux needs better binary compatibility.
Currently, if you compile something, it's usually dynamically linked against dozens of libraries that are present on your system, but if you give the executable to someone else with a different distro, they may not have those libraries or their version may be too old or incompatible.
Statically linking programs is often impossible and generally discouraged, making software distribution a nightmare. Flatpak and similar systems made things easier, but it's such a crap solution and basically involves having an entire separate OS installed in parallel, with its own problems like having a version of Mesa that's too old for a new GPU and stuff like that. Application must be able to be packaged with everything they need with them, there is no reason for dynamic linking to be so important in Linux these days.
I'm not in favor of proprietary software, but better binary compatibility is a necessity for Linux to succeed, and I'm saying this as someone who's been using Linux for over a decade and who refuses to install any proprietary software. Sometimes I find myself using apps and games in Wine even when a native version is available just to avoid the hassle of having to find and probably compile libobsoletecrap-5.so
-
Disagree - making it harder to ship proprietary blob crap "for Linux" is a feature, not a bug.
That's a fair disagreement to have, and a sign that you're fighting bigger battles than just getting software to work.
Static linking really is only an issue for proprietary software. Free software will always give users the option to fix programs that break due to updated dependencies.
-
Yes, I find that dude to be very disagreeable. He's like everything that haters claim Linus Torvalds is - but manifested IRL.
-
If the people criticizing him could roll up their sleeves and make better software, then I'd take their criticisms seriously.
Otherwise they're "just a critic."
OpenRC works just fine on my PC
-
It’s always the best way to get across what needs to be done and have the person execute it.
Sigh. If you want to use the command line, great. Nobody is stopping you.
For those of us who don't want to use the command line (most regular users) there should be an option not to, even in Linux.
Its sad people see it as a negative when it is really useful.
It's even sadder seeing people lose sight of their humanity when praising the command line while ignoring all of its negatives.
lose sight of their humanity
Ok this is now a stupid conversation. Really? Humanity?
Look, you can either follow a flowchart of a dozen different things to click on to get information about your thunderbolt device or type
boltctrl -listDo you want me to create screen shots of every step of the way to use a gui or just say type 12 characters? That is why it is useful. It is easy to explain, easy to ask someone to do it. Then they can copy and paste a response, instead of yet another screenshot.
Next thing you know you will be telling me it is against humanity to "right click". Or maybe we all should just get a Mac Book Wheel
Look, I am only advocating that it is a very useful tool. There is nothing "bad" about it, or even hard. What is the negative?
But I also said, I have been using a Fedora laptop for over a year and guess what? I never needed the command line. Not once.
-
lose sight of their humanity
Ok this is now a stupid conversation. Really? Humanity?
Look, you can either follow a flowchart of a dozen different things to click on to get information about your thunderbolt device or type
boltctrl -listDo you want me to create screen shots of every step of the way to use a gui or just say type 12 characters? That is why it is useful. It is easy to explain, easy to ask someone to do it. Then they can copy and paste a response, instead of yet another screenshot.
Next thing you know you will be telling me it is against humanity to "right click". Or maybe we all should just get a Mac Book Wheel
Look, I am only advocating that it is a very useful tool. There is nothing "bad" about it, or even hard. What is the negative?
But I also said, I have been using a Fedora laptop for over a year and guess what? I never needed the command line. Not once.
Ok this is now a stupid conversation. Really? Humanity?
Yeah, humanity. The fact you think it's 'stupid' really just proves my point that you're too far gone.
or type boltctl -list
Really? You just have every command memorized? You never need to look any of them up? No copy-pasting!
Come on, at least try to make a decent argument to avoid looking like a troll.
I'm glad rational people have won out and your rhetoric is falling further and further by the wayside. The command line is great for development and developers. It's awful for regular users which is why regular users never touch it.
You lost sight of your humanity, which is why you don't even think about how asinine it is to say "just type this command!" as though people are supposed to know it intuitively.
Gonna block ya now. Arguing with people like you is tiresome and a waste of time.
Have fun writing commands. Make sure you don't use a GUI to look them up, or else you'd be proving me right.
-
Ok this is now a stupid conversation. Really? Humanity?
Yeah, humanity. The fact you think it's 'stupid' really just proves my point that you're too far gone.
or type boltctl -list
Really? You just have every command memorized? You never need to look any of them up? No copy-pasting!
Come on, at least try to make a decent argument to avoid looking like a troll.
I'm glad rational people have won out and your rhetoric is falling further and further by the wayside. The command line is great for development and developers. It's awful for regular users which is why regular users never touch it.
You lost sight of your humanity, which is why you don't even think about how asinine it is to say "just type this command!" as though people are supposed to know it intuitively.
Gonna block ya now. Arguing with people like you is tiresome and a waste of time.
Have fun writing commands. Make sure you don't use a GUI to look them up, or else you'd be proving me right.
You blocked me over a difference of opinion?
Wow.
-
Domain authentication and group policy analogs.
-
Rewrite the entire kernel exclusively in rust!
-hehehe-
There is a separate kernel which is being written entirely in rust from scratch that might interest you. I'm not sure if this is the main one https://github.com/asterinas/asterinas but it is the first one that came up when I searched.
By the tone of your post you might just want to watch the world burn in which case I'd raise an issue in that repo saying "Rewrite in C++ for compatibility with wider variety of CPU archs"
-
There is a separate kernel which is being written entirely in rust from scratch that might interest you. I'm not sure if this is the main one https://github.com/asterinas/asterinas but it is the first one that came up when I searched.
By the tone of your post you might just want to watch the world burn in which case I'd raise an issue in that repo saying "Rewrite in C++ for compatibility with wider variety of CPU archs"
I'm of the opinion that a full rewrite in rust will eventually happen, but they need to be cautious and not risk alienating developers ala windows mobile so right now it's still done in pieces. I'm also aware that many of the devs who sharpened their teeth on the kernel C code like it as it is, resist all change, and this causes lots of arguments.
-
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.
So this is why multi monitor support has been a never ending hot mess?!
-
I try to avoid using the command line as much as possible, but it still crops up from time to time.
Back when I used windows, I would legitimately never touch the command line. I wouldn't even know how to interact with it.
We're not quite there with Linux, but we're getting closer!
I try to avoid using the command line as much as possible
Why would you do that?
-
I think there are some that are getting pretty close to this. Like SteamOS (although not a traditional DE) and Mint.
Ubuntu as well.
I wish I could say OpenSuse... -
You're not wrong; I was just being hyperbolic.
I know, I was just having a bad day and I kinda took it out on you. My bad.
-
So this is why multi monitor support has been a never ending hot mess?!
Yes and no. It would solve some problems, but because it has no (non-hacky) graphics acceleration, most DEs wouldn't use it anyway. The biggest benefit would be from not having to use a DE in some circumstances where it's currently required.
-
I have good news and bad news:
A specification already exists. https://specifications.freedesktop.org/basedir-spec/latest/
good luck winning any of these refusers over https://wiki.archlinux.org/title/XDG_Base_Directory#Hardcoded
-
good luck winning any of these refusers over https://wiki.archlinux.org/title/XDG_Base_Directory#Hardcoded
Eh, things have gotten better, and there are tools that make these tools respect them.
-
Generally speaking, Linux needs better binary compatibility.
Currently, if you compile something, it's usually dynamically linked against dozens of libraries that are present on your system, but if you give the executable to someone else with a different distro, they may not have those libraries or their version may be too old or incompatible.
Statically linking programs is often impossible and generally discouraged, making software distribution a nightmare. Flatpak and similar systems made things easier, but it's such a crap solution and basically involves having an entire separate OS installed in parallel, with its own problems like having a version of Mesa that's too old for a new GPU and stuff like that. Application must be able to be packaged with everything they need with them, there is no reason for dynamic linking to be so important in Linux these days.
I'm not in favor of proprietary software, but better binary compatibility is a necessity for Linux to succeed, and I'm saying this as someone who's been using Linux for over a decade and who refuses to install any proprietary software. Sometimes I find myself using apps and games in Wine even when a native version is available just to avoid the hassle of having to find and probably compile libobsoletecrap-5.so
This.
From the perspective of software preservation, we need this. Sometimes we won't have the source, and just need it to work while also getting security updates.
From the perspective of software delivery: read up on JangaFX's recent article about this topic and the problems they run into delivering software in the present
