Quoting: Eike

Quoting: LoudTechieLuckily X is not online so it will probably keep running on some offline computers.

But, X is supposed to be "network transparent" and should have loads of network code?!?

Quoting: Eike

Quoting: LoudTechieLuckily X is not online so it will probably keep running on some offline computers.

But, X is supposed to be "network transparent" and should have loads of network code?!?

X uses a "network transparant" protocol(X11), which means the protocol it uses could be used for network communications.
X doesn't actually use this feature.
The reason they still use the protocol is, because it allowed the people who were most likely to rely on it(front-end devlopers) to use a protocol they already knew.

View this comment - View article - View full comments

Quoting: tuubi

Quoting: LoudTechie

Quoting: tuubithat would only be a problem if that software still had some practical value to someone.

That quote works on the web, but on local hardware this is a lot less true.
COBOL has been deprecated longer than the Linux kernel exists, endures a full instruction set switch, a developers shortage and the millennium bug. There're currently around 800million of actively maintained lines of COBOL code.
I've encountered phones in the wild with no Android upgrade path beyond Android 7 and users who want to use modern applications.
I've had to save an ancient laptop from the bloat that is Windows 10 without breaking any compatibility.

You misunderstood. What I meant is that it's more or less fine for software to stop working on modern systems if it's no longer useful.

Clearly businesses still have need for their COBOL software or they wouldn't pay for its maintenance. And people want to keep using their hardware longer than manufacturers are willing to support them. That's all beside my point.

Ah, thanks for the clarification.

View this comment - View article - View full comments

Quoting: tuubithat would only be a problem if that software still had some practical value to someone.

That quote works on the web, but on local hardware this is a lot less true.
COBOL has been deprecated longer than the Linux kernel exists, endures a full instruction set switch, a developers shortage and the millennium bug. There're currently around 800million of actively maintained lines of COBOL code.
I've encountered phones in the wild with no Android upgrade path beyond Android 7 and users who want to use modern applications.
I've had to save an ancient laptop from the bloat that is Windows 10 without breaking any compatibility.

View this comment - View article - View full comments

Quoting: Eike

Quoting: tuubi

Quoting: EikeWhat will run the little DEs in a decade, when X.org is full of problems nobody is fixing anymore?

Just for the sake of clarity, are you talking of any particular DEs here or just some hypothetical ones that will never move on from X.org?

It's hypothetical, I only ever used KDE. I kept hearing about other ones, some E...3?, TWN, I got no idea. Like with many Linux topics, there seem to be many little alternatives to the big fishes. But I have the impression that getting ones DE to work on Wayland is quite some work that little projects might not be able to do. Is this impressions wrong?

The smaller your array of existing code the easier it is(it requires you to check large percentages of your code base for X commands).
The flipside is also true. The bigger you're the more people can work on the review process.

View this comment - View article - View full comments

Quoting: Eike

Quoting: LoudTechie

Quoting: Eike

Quoting: LoudTechie

Quoting: EikeWhen the world moves on to Wayland (in the next decade ;) ), will this be the death of all those little DEs that won't implement a Wayland compositor?

A. Killing a category of small FOSS projects is like weeding Reynoutria Japonica. Only achievable for large organisations with full control over the infrastructure and able to aggressively retribute to anyone who actively opposes the removal process. a.k.a there will always pop up more.
B. FOSS is big on compatibility I remember reading about problems with a removed function 19 years after getting deprecated.
C. FOSS projects don't rely on users to persist(*COUGH GNU/HURD *COUGH) just developers to maintain them.

I don't have the feeling you answered my question. Loads of FOSS projects are dying a silent death every day, GitHub is full of their corpses (and full of all those thriving projects, of course).

Quoting: LoudTechieI promise you that a single decade isn't enough to weed out the small non-implenting DE's or render them incompatible with your distro.

What will run the little DEs in a decade, when X.org is full of problems nobody is fixing anymore?

X will never(on a scale of decades) become any worse than it currently is.
Software doesn't get worse without active interference just more of its problems get known.

Well, there's even a name for it, bit rot [External Link]. And the difference between getting worse and having more known problems is little. Truth is, software, especially software with network components, needs people fixing it up to keep it's level of security. Yes, theoretically, it already has all holes that will become known the next years, but in practice, a hole nobody knows is not a threat. And new ways of finding security holes are invented. (I'd be surprised if AI is not able to find security holes, e.g.). So, yes, in my humble opinion, software (with network code) not being maintained rot over time.

Okay. Security wise I've to agree with you.
The answer to that part is somewhat less comfortable.
In its current state I expect X to sustain a "secure" state for the coming 2 decades wherein it will be getting security fixes at comparable speed people will keep publicly discovering them(both very slow, because interest will dwindle at both sides).
Halfway I expect a (non-security)buggy Wayland compatibility layer to show up saving around half of the code currently running X.
Luckily X is not online so it will probably keep running on some offline computers.

View this comment - View article - View full comments

Quoting: Pengling

Quoting: 14It's terrible. In fact, software usage on a desktop environment in general is a really bad experience on BSD period.

I've never yet used any variant of BSD (it's one of those things that's been on my to-do list for more years than I'd like to admit! :tongue:), so I've got no frame of reference for that either, unfortunately...

Quoting: LoudTechieQuite comparable to gaming on and amd64 Mac(or gaming on linux 10 years ago)
Wine is available.
Vulkan is available.
There is a quite good linux compatibility layer, so linux natives work most of the time.
Proton-GE isn't available.
Said differently everything Apple's Rosetta can run + most linux native.

That's actually better than I expected! Thanks very much. :smile:

You're welcome.
What has to be pointed out here though is that most BSD users and developers don't actually care that much about gaming.
Its pretty sturdy state is mostly, due to what I call compatibility leak.
The FOSS world finds compatibility important, because incompatibility is how the proprietary platforms keep them caged and it encourage collaboration, which is their greatest strength.
One of the effects is that all "core" projects like Wine are developed to be as compatible with as much as possible.
Bsd gaming benefits from this.
Wine supports around 300 "platforms"
The Linux kernel is technically also a Bsd kernel, because it's mostly to fully compliant with the Bsd standard.
The GNU project has stopped counting.
Beside a Linux/bsd compatibility layer and wine there are also Darling(wine for apple), tons of emulators, C compilers for virtually every processor available, the entire Mesa project, a foss and still maintained alternative to PalmOS, XWayland and so further.

View this comment - View article - View full comments

Quoting: Eike

Quoting: LoudTechie

Quoting: EikeWhen the world moves on to Wayland (in the next decade ;) ), will this be the death of all those little DEs that won't implement a Wayland compositor?

A. Killing a category of small FOSS projects is like weeding Reynoutria Japonica. Only achievable for large organisations with full control over the infrastructure and able to aggressively retribute to anyone who actively opposes the removal process. a.k.a there will always pop up more.
B. FOSS is big on compatibility I remember reading about problems with a removed function 19 years after getting deprecated.
C. FOSS projects don't rely on users to persist(*COUGH GNU/HURD *COUGH) just developers to maintain them.

I don't have the feeling you answered my question. Loads of FOSS projects are dying a silent death every day, GitHub is full of their corpses (and full of all those thriving projects, of course).

Quoting: LoudTechieI promise you that a single decade isn't enough to weed out the small non-implenting DE's or render them incompatible with your distro.

What will run the little DEs in a decade, when X.org is full of problems nobody is fixing anymore?

X will never(on a scale of decades) become any worse than it currently is.
Software doesn't get worse without active interference just more of its problems get known.

The problem you've now more clearly described(sorry, I misunderstood you) will only arise when the things X relies on make breaking changes(and probably when 64 bit time runs out, but that is 292 billion years removed from today).
This is really unpopular within all layers of computer development and X relies on very little things, but unpopular doesn't mean unheard off.
So what would it take to take down everything that relies on X?
A few examples
Combined: processor manufacturers remove OpenGL support, nobody writes an X compatible OpenGL Vulkan compatibility layer, nobody ports x to Vulkan, people switch to the newer processors.
Combined: Everybody switches to a currently unknown processor type and all compilers for it only support programming languages X is not compatible with(a.k.a everybody switches away from C).

View this comment - View article - View full comments

Quoting: EikeWhen the world moves on to Wayland (in the next decade ;) ), will this be the death of all those little DEs that won't implement a Wayland compositor?

A. Killing a category of small FOSS projects is like weeding Reynoutria Japonica. Only achievable for large organisations with full control over the infrastructure and able to aggressively retribute to anyone who actively opposes the removal process. a.k.a there will always pop up more.
B. FOSS is big on compatibility I remember reading about problems with a removed function 19 years after getting deprecated.
C. FOSS projects don't rely on users to persist(*COUGH GNU/HURD *COUGH) just developers to maintain them.

I promise you that a single decade isn't enough to weed out the small non-implenting DE's or render them incompatible with your distro.

View this comment - View article - View full comments

Quoting: Pyretic

Quoting: satorideponDon't forget SteamOS long-standing issue with increasing storage consumption due to Proton prefixes, shader caches

Wasn't this fixed already? Caches are much smaller now and you can even delete the ones you're not using.

Quoting: LoudTechieI don't what does it stand for.
Gaming
On
Ayeneo
Teacher
?

Greatest Of All Time

A. Performance isn't something something you "fix" it's something you improve. Proton will always take on more space than no Proton and always be slower than no Proton. It's why it's such a shock when it manages to outperform native Windows in some contexts. Many people use Windows as the zero line, where everything faster than Windows is "good" and everything slower is "bad".
B. Thnx

View this comment - View article - View full comments

Quoting: BlackBloodRumI can't share my wallpaper for uh, reasons. But anyway, I thought everyone changed their wallpaper anyway?

Does anyone actually use the OS's default wallpaper, without changing it? :neutral:

Jup, I do.
Too much effort and am not artsy enough to fully appreciate it.

View this comment - View article - View full comments