Slightly off topic -- java-related wiki pages are notoriously bad and possibly biased for some reason. They are laughably outdated and have a bunch of non-objective sentences that paint a much worse picture of the language than deserved.

I have even tried removing/rewriting some of the questionable sentences but my edits weren't accepted.

Then what is it that you are saying? That I should use JMH to determine the best layout for my helper class that will be initialized 3 times? Like most of the software (by line of code) is boring plumbing from one service to another with some dumb business logic sprinkled in. Something like a single config option for your database driver matters orderS of magnitude more in many types of applications.

It's much more niche to work on stuff where such changes actually matter, like much much more people write boring CRUD backends than those who write physics simulators and audio processing pipelines combined.

Consider the cost of every field, of every action.

Understand the language, the memory model, etc. Don't do "it works on my machine". Understand the architecture, layout, implications etc.

E.g. if you need an int and not a long you should clearly use an int. Wait until you do this every time and things blow up and it's too "hard" to change.

It's called be aware of your actions. Take responsibility of what you do.

> It's much more niche to work on stuff where such changes actually matter,

Not true and that's why there's so much wastage.

A lot of things matter. I've seen more times than the other way that simple awareness and changes can pay for my salary, e.g. not updating to newer EC2 instances when they get released in AWS. Even in a mid size company that was hundreds to thousands in savings.

I've seen CI/CD pipelines where the developers never considered caching and it takes hours to run. It's not free. When every PR and update (hundreds a day) triggers a run it's a cost and a cost not just on machines but developer time waiting.

I can list a lot more examples and everyone in the chain can contribute.

> Consider the cost of every field, of every action.

This runs counter to most modern software performance principles. Thanks to modern hardware optimisations (cache hierarchy, ILP, branch prediction), modern compiler optimisations (aggressive inlining that leads to a much wider view), and increased concurrency, the notion of some action having a cost lost most meaning about 20 years ago, and increasingly since. Because how fast some action is now depends on a much broader context of what else is going on in the program (and the machine), action X can be faster than Y in one program and the same or slower than Y in another.

Because it's nearly impossible to generalise (and so what was true in your previous program may not be true in your current one unless they're nearly identical), the advice is to first profile your program so that you know how fast or slow different parts are in the context of your particular program and then to focus the optimisation efforts on the hot paths in your program. Otherwise, you may end up spending effort where it makes no difference, and this comes at the cost of optimising what matters, overall harming performance.

Taking responsibility means being smart about directing your resources to where they can have the most impact.

And java uses very little CPU compared to most other languages. It's right after manual memory managed languages like C/C++, and is the first managed language according to a paper about how "green" each language is.

But there is a semi-fundamental tradeoff here, you either use more CPU to use less memory or the reverse. Java can be dynamically configured for either end (though defaults to less CPU by not running the GC unnecessarily).

It doesn't even run "JavaTM", but some bastard child that is in like ~5 years delay compared to OpenJDK.

> I have faith in Debian for filtering out rogue applications

Sorry but all I can say to that is: lol

As for security, it's easy/possible to cut holes into a solid wall. But if your whole system is swiss cheese, you can't plug all of them in. Wayland is a solid wall where protocols are the means to cut new holes. Sure, protocol development is slow (at least their acceptance), but this is the proper way to do it.

And even if you have faith in your applications, do you also have faith in your data? Because it's a mostly C/c++ application set, one vulnerability is enough to make them malicious. And with the beautifully engineered default "GNU/Linux" userspace security model, the only thing a random script can't do on your machine is install a new video card driver. But everything else is under the same user and readily accessible with full network access.

Debian applications are not sandboxed so gimping the window system gains you exactly nothing. And yes, we can expect Debian to filter rogue applications.

Well, it's like new car doesn't start but you have forgotten to put fuel into it, and now blame the car.

This is Linux desktop, like if you have never had a black screen before then I'm not sure what you expect. One culprit could actually be the home .config/.cache folders that have all kind of sh*t accumulated (like why do we still do it this way? It's horrible), so I usually rename them and try again to see if this is the problem behind the scenes.

Well, if I never had to put fuel into my old car then this would be a step back, no? I'm not a stranger to troubleshooting, and do a lot of it already, which occupies my energy and time for troubleshooting. I use Debian stable for a reason. It's mostly that if I didn't go looking for a new thing, it doesn't provide anything new that I want, it removes old things that I want, and it doesn't work without troubleshooting, why do I want this thing?

This specifically isn't the biggest issue for me right now because I use this machine mainly over ssh, but if I eventually can't do x-forwarding, RDP, or log in manually without finding some fix, that's a lot of extra work and lost functionality.

I'm not questioning what you are saying, but Wayland's only requirement is DRM, which is a Linux kernel capability that is supported for basically everything that you can push some sort of display cable into. It's for buffer management, and X was also ported to use this API.

Unless you have proprietary X server blobs, you have mostly the same low level route in either case to display stuff, so it's on the exact compositor you have tried, not on the wayland protocol.

I agree, it should work. It just doesn't. I haven't had the time yet to figure out why it doesn't because everything is fine on X11.

Linux kernel, X server, web browsers all seriously violate the Unix philosophy.

And to be perfectly honest, it's nothing more than a philosophy - it's not some universal truth, e.g. a browser by definition is not doing "one small thing" and complex workloads are better organized by monolithic software to a certain degree.

I've noticed a trend that the same people who complain systemd does too much also have a strong affinity for the X server... with it's built in print server!

Well, for ALSA and pulseaudio, the latter more or less just surfaced the tons of bugs in the underlying, at the time very shitty audio drivers. Remember, only pulseaudio is a sound server, so ALSA wasn't even exercising many of the more "advanced" features, and drivers were only supporting the most basic stuff.

That's at odds with the fact that pulseaudio is incapable of exposing the audio reference clocks from sound hardware, which is a fundamental aspect of digital audio engineering. Its design doesn't even acknowledge the existence of an audio clock.

That's fine for basic audio but completely excludes any higher demand application, including high quality A/V sync. Best you can do is work around and best effort guess.

My point wasn't that pulseaudio is flawless, it's just that it has a much worse name than it deserves.

Considering pipewire was a drop-in replacement for pulseaudio with (almost*) full compatibility and none of the stability issues (you can even use the pulseaudio commands to control it), the problem was definitely in the pulseaudio code.

* I do remember reading there was one feature they intentionally dropped because it was extremely rarely useful and could be handled in a different way, but don't remember what it was.

So one audio server managed to provide a shim for another audio server, great.

But it absolutely doesn't follow from that that pulseaudio was somehow bad. There was more than a decade where audio drivers were slowly getting bug fixes to get to a state where they are working okay for the most part. Pipewire would have experienced many of the same issues as pulseaudio, and we would similarly attribute those errors incorrectly to the audio server.

My laptop would regularly freeze and need a hard reboot, and I never could figure out why. One day for a completely unrelated reason I decided to try switching from pulseaudio to pipewire, with no other changes (including no other upgrades; I'm lazy and like stability), and months later I realized it hadn't frozen at all. Still hasn't, years later. The problem was definitely pulseaudio making the whole system unstable, not just causing audio issues.