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?
like this
Mihies
in reply to Einar • • •Overspark
in reply to Mihies • • •Fecundpossum
in reply to Overspark • • •LouSlash
in reply to Fecundpossum • • •And in some cases, even better experience than on Windows (f.e. older games compatibility or higher FPS alongside smoother gameplay)
Tbh, about a year ago i checked the price difference between various laptops with Windows preinstalled and without any OS. The difference wasn't actually a flat amount of money, it was like +10% (price of the laptop 500$ --- ~ +50$ for Windows | price of the other laptop 1000$ --- ~ 100$ for Windows).
So because of the actual state of gaming on Linux (and overall experience) i wouldn't pay that 10% to play games with rootkits built-in, but rather spend it on other things
dan
in reply to Overspark • • •These are eventually going to be blocked on Windows. Microsoft are making changes to what's allowed to run in the kernel after the Crowdstrike issue last year.
Xanza
in reply to Mihies • • •verdigris
in reply to Mihies • • •jagged_circle
in reply to verdigris • • •teawrecks
in reply to Mihies • • •smiletolerantly
in reply to Einar • • •At this point, package management is the main differentiating factor between distro (families). Personally, I'm vehemently opposed to erasing those differences.
The "just use flatpak!" crowd is kind of correct when we're talking solely about Linux newcomers, but if you are at all comfortable with light troubleshooting if/when something breaks, each package manager has something unique und useful to offer. Pacman and the AUR a a good example, but personally, you can wring nixpkgs Fron my cold dead hands.
And so you will never get people to agree on one "standard" way of packaging, because doing your own thing is kind of the spirit of open source software.
But even more importantly, this should not matter to developers. It's not really their job to package the software, for reasons including that it's just not reasonable to expect them to cater to all package managers. Let distro maintainers take care of that.
like this
timlyo likes this.
SwingingTheLamp
in reply to Einar • • •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
... Show more...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.
like this
timlyo likes this.
Lovable Sidekick
in reply to SwingingTheLamp • • •steeznson
in reply to SwingingTheLamp • • •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 throw 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.
dosse91
in reply to Einar • • •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. Applications 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 in
... Show more...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. Applications 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
MyNameIsRichard
in reply to dosse91 • • •dblsaiko
in reply to MyNameIsRichard • • •And yet, ancient Windows binaries will still (mostly) run and macOS allows you to compile for older system version compatibility level to some extent (something glibc alone desperately needs!). This is definitely a solvable problem.
Linus keeps saying “you never break userspace” wrt the kernel, but userspace breaks userspace all the time and all people say is that there’s no other way.
MyNameIsRichard
in reply to dblsaiko • • •dblsaiko
in reply to MyNameIsRichard • • •Distributions are not the problem. Most just package upstream libraries as-is (plus/minus some security patches). Hence why programs built for another distro will a lot of the time just run as is on a contemporary distro given the necessary dependencies are installed, perhaps with some patching of the library paths (plenty of packages in nixpkgs which just use precompiled deb packages as a source, as an extreme example because nixpkgs has a very different file layout).
Try a binary built for an old enough Ubuntu version on a new Ubuntu version however...
Giooschi
in reply to dblsaiko • • •dblsaiko
in reply to Giooschi • • •Magiilaro
in reply to dblsaiko • • •It works under Windows because the windows binaries come with all their dependency .dll (and/or they need some ancient visual runtime installed).
This is more or less the Flatpack way, with bundling all dependencies into the package
Just use Linux the Linux way and install your program via the package manager (including Flatpack) and let that handle the dependencies.
I run Linux for over 25 years now and had maybe a handful cases where the Userland did break and that was because I didn't followed what I was told during package upgrade.
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.
dblsaiko
in reply to Magiilaro • • •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).
... Show more...Try running an old precompiled Linux game (say Unreal Tournament 2004 for example). They can be a pain to get working. This is
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).
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.
The modern packager’s security nightmare
Michał GórnyMagiilaro
in reply to dblsaiko • • •Unreal Tournament 2004 depends on SDL 1.3 when I recall correctly, and SDL is neither on Linux nor on any other OS a core system library.
Binary only programs are foreign to Linux, so yes you will get issues with integrating them. Linux works best when everyone plays by the same rules and for Linux that means sources available.
Linux in its core is highly modifiable, besides the Kernel (and nowadays maybe systemd), there is no core system that could be used to define a API against.
Linux on a Home theater PC has a different system then Linux on a Server then Linux on a gaming PC then Linux on a smartphone.
You can boot the Kernel and a tiny shell as init and have a valid, but very limited, Linux system.
Linux has its own set of rules and his own way to do things and trying to force it to be something else can not and will not work.
navordar
in reply to dblsaiko • • •iii
in reply to dosse91 • • •navordar
in reply to iii • • •CarrotsHaveEars
in reply to dosse91 • • •What you described as the weakness, is actually what is strong of an open source system. If you compile a binary for a certain system, say Debian 10, and distribute the binary to someone who is also running a Debian 10 system, it is going to work flawlessly, and without overhead because the target system could get the dependency on their own.
The lack of ability to run a binary which is for a different system, say Alpine, is as bad as those situations when you say you can't run a Windows 10 binary on Windows 98. Alpine to Debian, is on the same level of that 10 to 98, they are practically different systems, only marked behind the same flag.
Ephera
in reply to CarrotsHaveEars • • •pr06lefs
in reply to dosse91 • • •PopeRigby
in reply to pr06lefs • • •Building 15-year-old software with Nix
blinry.orgAtariDump
in reply to pr06lefs • • •pr06lefs
in reply to AtariDump • • •catloaf
in reply to dosse91 • • •I don't think static linking is that difficult. But for sure it's discouraged, because I can't easily replace a statically-linked library, in case of vulnerabilities, for example.
You can always bundle the dynamic libs in your package and put the whole thing under /opt, if you don't play well with others.
apt_install_coffee
in reply to dosse91 • • •Captain Beyond
in reply to dosse91 • • •lumony
in reply to Captain Beyond • • •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.
lumony
in reply to dosse91 • • •asudox
in reply to Einar • • •IHave69XiBucks
in reply to asudox • • •Flatpak is very useful for a lot of things, but i really dont think it should be the default. It still has some weird issues. For example if you run a seperate home and root partition flatpak by default will install things into your root partition which quickly fills up. You have to go in and do a bunch of work to get it to use the home partition.
Or for example issues with themeing and cursors. Its a pretty common issue for flatpaks to not properly detect your cursor theme and just use the default until you mess around with perms and settings to fix it.
They also generally get updates slower. I guess maybe if its adopted more that would change but flatpak is already pretty widely used and thats still an issue. Especially for smaller programs not used by as many people.
Keeping it as just something that is good to use for the ones who like a GUI experience and want something simple and easy is great. But if we were to start doing like what ubuntu does with snaps where theyll just replace things you install with the snap version then im not in favor of that at all.
fxdave
in reply to IHave69XiBucks • • •Im_old
in reply to Einar • • •enumerator4829
in reply to Einar • • •Stability and standardisation within the kernel for kernel modules. There are plenty of commercial products that use proprietary kernel modules that basically only work on a very specific kernel version, preventing upgrades.
Or they could just open source and inline their garbage kernel modules…
ethancedwards8
in reply to enumerator4829 • • •I’m struggling with this now. There’s an out of tree module I want upstreamed, but the author (understandably) doesn’t want to put in the work to upstream, so I did. The upstream folks are reluctant to take it because I didn’t actually write it.
I really don’t know what to do.
fxdave
in reply to enumerator4829 • • •enumerator4829
in reply to fxdave • • •It mostly affects people working with ”fun” enterprise hardware or special purpose things.
But to take one example, proprietary drivers for high performance network cards, most likely from Nvidia.
kibiz0r
in reply to Einar • • •ARM support. Every SoC is a new horror.
Armbian does great work, but if you want another distro you’re gonna have to go on a lil adventure.
eneff
in reply to kibiz0r • • •kibiz0r
in reply to eneff • • •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
More Than 16 Billion RISC-V Chips Forecasted by 2030
Anton Shilov (Tom's Hardware)lumony
in reply to kibiz0r • • •Mio
in reply to Einar • • •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.
lime!
in reply to Mio • • •Einar
in reply to lime! • • •I agree. OpenSuse should set the standards in this.
Tbf, they really need a designer to upgrade this visually a bit. It exudes its strong "Sys Admin only" vibes a bit much. In my opinion. 🙂
lumony
in reply to Mio • • •Fuckin hate having to go through config files to change settings...
It's always great when settings are easily accessible in a GUI, though! Mad props to the great developers that include them!
irotsoma
in reply to Einar • • •Not offering a solution here exactly, but as a software engineer and architect, this is not a Linux only problem. This problem exists across all software. There are very few applications that are fully self contained these days because it's too complex to build everything from scratch every time. And a lot of software depends on the way that some poorly documented feature worked at the time that was actually a bug and was eventually fixed and then breaks the applications that depended on it, etc. Also, any time improvements are made in a library application it has potential to break your application, and most developers don't get time to test the every newer version.
The real solution would be better CI/CD build systems that automatically test the applications with newer versions of libraries and report dependencies better. But so many applications are short on automated unit and integration tests because it's tedious and so many companies and younger developers consider it a waste of time/money. So it would only work in well maintained and managed open source types of appli
... Show more...Not offering a solution here exactly, but as a software engineer and architect, this is not a Linux only problem. This problem exists across all software. There are very few applications that are fully self contained these days because it's too complex to build everything from scratch every time. And a lot of software depends on the way that some poorly documented feature worked at the time that was actually a bug and was eventually fixed and then breaks the applications that depended on it, etc. Also, any time improvements are made in a library application it has potential to break your application, and most developers don't get time to test the every newer version.
The real solution would be better CI/CD build systems that automatically test the applications with newer versions of libraries and report dependencies better. But so many applications are short on automated unit and integration tests because it's tedious and so many companies and younger developers consider it a waste of time/money. So it would only work in well maintained and managed open source types of applications really. But who has time for all that?
Anyway, it's something I've been thinking about a lot at my current job as an architect for a major corporation. I've had to do a lot of side work to get things even part of the way there. And I don't have to deal with multiple OSes and architectures. But I think it's an underserved area of software development and distribution that is just not "fun" enough to get much attention. I'd love to see it at all levels of software.
ikidd
in reply to Einar • • •Domain authentication and group policy analogs. Honestly, I think it's the major reason it isn't used as a workstation OS when it's inherently more suited for it than Windows in most office/gov environments. But if IT can't centrally managed it like you can with Windows, it's not going to gain traction.
Linux in server farms is a different beast to IT. They don't have to deal with users on that side, just admins.
loonsun
in reply to ikidd • • •fxdave
in reply to ikidd • • •without limit...
ikidd
in reply to fxdave • • •Lka1988
in reply to fxdave • • •TL;DR - Because people are stupid.
One of my coworkers (older guy) tends to click on things without thinking. He's been through multiple cyber security training courses, and has even been written up for opening multiple obvious phishing emails.
People like that are why company-owned laptops are locked down with group policy and other security measures.
steeznson
in reply to fxdave • • •Lka1988
in reply to ikidd • • •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.
silly goose meekah
in reply to Lka1988 • • •Pup Biru
in reply to ikidd • • •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
Lv_InSaNe_vL
in reply to ikidd • • •Ubuntu Server supports Windows Active Directory. I haven't used it for anything but authentication (and authentication works flawlessly) and some basic directory/share permissions but theoretically it should support group policy too.
It'd be cool if there was a mainstream FOSS alternative though (there might be, I've done literally 0 research), but this works okay-ish in the meantime.
But for management of the actual production servers at work I use a combination of ManageEngine (super great and reasonably priced) and Microsoft's Entra (doesn't work well, don't do it)
Lovable Sidekick
in reply to Einar • • •Mactan
in reply to Einar • • •Ferk
in reply to Mactan • • •interoperability == API standardization == API homogeneity
standardization != monopolization
arsCynic
in reply to Einar • • •Cysio
in reply to Einar • • •NicolaHaskell
in reply to Cysio • • •corsicanguppy
in reply to Einar • • •eneff
in reply to corsicanguppy • • •markstos
in reply to eneff • • •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.
Lka1988
in reply to corsicanguppy • • •chaoticnumber
in reply to Lka1988 • • •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.
Lka1988
in reply to chaoticnumber • • •chaoticnumber
in reply to Lka1988 • • •steeznson
in reply to corsicanguppy • • •lumony
in reply to steeznson • • •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."
steeznson
in reply to lumony • • •HiddenLayer555
in reply to Einar • • •Where app data is stored.
~/.local
~/.config
~/.var
~/.appname
Sometimes more than one place for the same program
Pick one and stop cluttering my home directory
itslilith
in reply to HiddenLayer555 • • •~/.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
FooBarrington
in reply to HiddenLayer555 • • •I have good news and bad news:
A specification already exists. specifications.freedesktop.org…
XDG Base Directory Specification
specifications.freedesktop.orgMactan
in reply to FooBarrington • • •XDG Base Directory - ArchWiki
wiki.archlinux.orgFooBarrington
in reply to Mactan • • •arsCynic
in reply to HiddenLayer555 • • •Tlaloc_Temporal
in reply to HiddenLayer555 • • •gandalf_der_12te
in reply to Einar • • •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.
And also we need a good app store where users can download and install software in a reasonably safe and easy way.
AugustWest
in reply to gandalf_der_12te • • •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.
Its sad people see it as a negative when it is really useful. But as of today you can get by without it.
reshared this
Elischeva91 reshared this.
lumony
in reply to AugustWest • • •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.
It's even sadder seeing people lose sight of their humanity when praising the command line while ignoring all of its negatives.
AugustWest
in reply to lumony • • •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
boltctl -listDo you want me to create screen shots of every step of the way to use a gui or just 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.
lumony
in reply to AugustWest • • •Yeah, humanity. The fact you think it's 'stupid' really just proves my point that you're too far gone.
Really? You 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.
AugustWest
in reply to lumony • • •You blocked me over a difference of opinion?
Wow.
All I am trying to say it that it is a tool in the toolbox. Telling people Linux needs it is not true, telling people it's bad is not true.
Quit trying to make it a negative. I would encourage anyone to explore how to use this tool. And when trying to communicate ideas on the internet it is a very useful one.
I have never blocked anyone, I find that so strange. It's like saying because of our difference on this issue, we could never have common ground on any other.
And you ask me to remember my humanity?
Elischeva91
in reply to gandalf_der_12te • •@gandalf_der_12te @Einar
Linux Mint and some Kind of Ubuntu-Flavour are the Goto. Preferably the LTS Vefsions. For Ubuntu its 24.04, for Mint it is 22. So you ever need the commandline only for one short line and only in 2029.
So for the next few years you don't need to touch the commandline.
RawrGuthlaf
in reply to gandalf_der_12te • • •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".
lumony
in reply to RawrGuthlaf • • •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!
eneff
in reply to lumony • • •Why would you do that?
Jack Waterhouse
in reply to gandalf_der_12te • • •ChapulinColorado
in reply to Jack Waterhouse • • •Einar
in reply to Jack Waterhouse • • •I wish I could say OpenSuse...
JuxtaposedJaguar
in reply to Einar • • •Each monitor should have its own framebuffer device rather than only one app controlling all monitors at any time 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.
chaoticnumber
in reply to JuxtaposedJaguar • • •Codilingus
in reply to JuxtaposedJaguar • • •JuxtaposedJaguar
in reply to Codilingus • • •muusemuuse
in reply to Einar • • •Rewrite the entire kernel exclusively in rust!
-hehehe-
TrivialBetaState
in reply to muusemuuse • • •steeznson
in reply to muusemuuse • • •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 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" ;)
GitHub - asterinas/asterinas: Asterinas is a secure, fast, and general-purpose OS kernel, written in Rust and providing Linux-compatible ABI.
GitHubmuusemuuse
in reply to steeznson • • •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.
Looking at that link, I'm not liking the MPL.
TrivialBetaState
in reply to Einar • • •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.