Parent mentioned that the supposed bug was already fixed, that’s not the point.

And they target GNU compliance, not POSIX compliance. Which is hard mode, since if it was the latter, they could have just checked out the freebsd utils or whatever at will whenever they felt unsure about something.

Also your implementation has a bug because dirname blah.png returns “.” 😉

It wasn’t meant as a 1-1 implementation, but fair enough.

I would argue that this helps my point. Because that’s an ambiguity dirname doesn’t help with. What if “bla.png” is, or expected to be, a dir?

And if you’re going to test, are you going to use shell bult-ins or the test command from coreutils? And if you’re calling test, are you calling it with the full path so you don’t get a shell builtin anyway or not?

If I was just going to use the built-ins I’d use Python or Ruby or something.

Using a better language is absolutely the right thing to do for anything that is not trivial.

Python is a shit choice for another reason though. They don’t know what backward compatibility means. So you may find your script broken in 2-3 years anyway. I don’t know about Ruby.

If you’re going to rely on shell scripts, you should stick to the built-in functionality of your shell as much as possible, as external commands can differ, or even be completely overridden, in random environments for a myriad of reasons.

For example, use ${var%/*} instead of $(dirname $var). Forking out a whole OS process for such minuscule tasks is stupid anyway.

This goes against la-la unix philosophy dreamy thoughts and beliefs, or portability fantasies. But it’s the right thing to do in the real world. And gives you at least some level of control over expected behavior.

While the feel-good kid stories we all heard and believed were nice, Linux would have never gone big if it wasn’t for a billion dollars dedicated by IBM to development in the 90’s, and continued funded development from other companies like RH (which IBM ironically eventually bought).

Most software installed in your system right now is not gnu-licensed btw. Fully functioning non-gnu distributions (sans the kernel) already exist too, with no tangible effect on the user experience for most.

This is a great comment. Not because it’s more stupid than the others, or because of the hilarious scenario envisioned. But because it transparently introduces the cognitive dissonance around liberal licenses, while still presenting as agreeable among the clueless.

The best way to “sell” open source code is to license it non-liberally while retaining copyright fully, or retaining the right to re-license for 3rd parties. And guess what, the latter is what Canonical does with its GPL-licensed projects + their contributor agreement.

In fact, you can go too copyleft to the point of becoming non-free (e.g. the SSPL).

The reason why liberal licenses are framed as corpo-friendly is because corpos can just take, they don’t need to “buy” anything.

Still the hilarious theories around “selling” coreutils, and the continued general ignorance about practically everything from the gantry here, gave me a good chuckle. Although its all starting to get derivative and repetitive.

I’m a “developer edition” user (beta channel) running multiple profiles from multiple system users, and the only change I noticed weeks ago was the file picker not opening at all 😬

Fixed by running firefox with dbus-launch. So that was +1 for dbus over systemd in the race to make less shit work expectedly, while killing unix/posix in the process.

Wow! What an observant smart thought.

Well, except for the fact that code conversion doesn’t give you the permission to change licenses or remove copyright. And the small matter of fact that both projects mentioned are Canonical projects, where whatever code that is not directly copyrighted by Canonical, is contributed by someone who signed an agreement with this stipulation:

(b) To the maximum extent permitted by the relevant law, You grant to Us a perpetual, worldwide, non-exclusive, transferable, royalty-free, irrevocable licence under the Copyright covering the Contribution, with the right to sublicense such rights through multiple tiers of sublicensees, to reproduce, modify, display, perform and distribute the Contribution as part of the Material; provided that this license is conditioned upon compliance with Section 2.3.

“Us” being Canonical of course. So they could actually “re-license” the projects right now, without changing a single line of code.

It’s always astonishing how condiment in their ignorance people are when it comes to these matters.

You geniuses are getting too predictable with your ignorance.

I literally wrote what’s quoted above yesterday replying to someone else.

Wow! What an observant smart thought.

Well, except for the fact that code conversion doesn’t give you the permission to change licenses or remove copyright. And the small matter of fact that both projects mentioned are Canonical projects, where whatever code that is not directly copyrighted by Canonical, is contributed by someone who signed an agreement with this stipulation:

(b) To the maximum extent permitted by the relevant law, You grant to Us a perpetual, worldwide, non-exclusive, transferable, royalty-free, irrevocable licence under the Copyright covering the Contribution, with the right to sublicense such rights through multiple tiers of sublicensees, to reproduce, modify, display, perform and distribute the Contribution as part of the Material; provided that this license is conditioned upon compliance with Section 2.3.

“Us” being Canonical of course. So they could actually “re-license” the projects right now, without changing a single line of code.

It’s always astonishing how condiment in their ignorance people are when it comes to these matters.

They are the best most polished because there exists two other worse implementations in my anecdotal experience.

Wow. Very factual and thorough.

Gnome and KDE currently have the most polished and integrated Wayland compositors, and are the least likely to have any noticeable issues compared to X11

made up “fact”

Yeah. The ArchLinux corporation must be losing money left and right because of this.

Are they stupid?!

That’s a scenario where looking up the slides is the right course of actions, or at worst, seeking informed coverage (e.g. from some LWN reporters, but not all).

It is not uncommon for info provided by tech journalists from sites like OP, or even worse, “e-celeb” baiters, to actually have negative worth.

(Disclaimer: I didn’t specifically read OP, for the reason stated above.)

Anyone who’s actually relevant is already aware of the technical details. Anyone with a non-gossipy interest in the topic has already watched the talk (which is available), or will watch it before opening their mouth.

What remains is the internet gantry, which is irrelevant.

LRU inversion: the problem with not caring about it is that it’s not a visible problem until it very suddenly is. Your system will not gradually degrade but very suddenly and unpredictably hit a wall that it cannot get itself over.

All this talk just confirms my feelings that there is a general lack of understanding of actual modern workloads.

RAM (normal w/wo zram) doesn’t get full, then stay full forever in real workloads. Not only is that not realistic at the “opened apps”/“running processes” level, it’s not real at the heap allocation level within tasks within processes. And this is much more pronounced with code written in modern languages like Rust and some styles of C++. Modern heap allocators batch and cache (primarily to help with performance). But still, A LOT of memory is getting allocated and deallocated all the time, even from the kernel’s PoV.

LRU itself is an imperfect approximation, not a goal. In the setup described in my other comment (fast SSD swap storages only used sparingly most of the time), so called LRU inversion gets auto-cancelled relatively quickly, as free space in RAM(+zram) gets available all the time, and some “LRU-hot” pages in SSD swap turn out to be actually cold, and those ones are the only ones that actually stay there.

This is why, I would imagine a lot of fake scenarios, and “benchmarks” based on them, may fail to replicate the practical reality of many (overall system) use-cases.

More tangentially, the oversized concern for file caching pages also points to specific aligned use-cases in mind, as if everyone is running DB-centric workloads or something.

This is not a good thing btw. Any unused anonymous page takes up space that could instead be used for file-backed pages that make your system faster.

Can you expand here. I think my attempt at brevity in this part wasn’t helpful.

Swap is not tiered storage!

I meant tiered with priorities only, yes.

Cool tech but it’s dead and was quite niche even when it was alive.

We are not talking about the original purpose of Optane as supported on Windows. It’s just a (perhaps somewhat outdated) example of a storage device “smaller but faster than your average SSD storage”, which is very much not did tech.

Not a thing you actually want to use for swap

Depends on the use-case. But yes, this can also be used as the fastest disk tier/priority of normal swap devices, which is why I mentioned both.

This makes no sense at all unless you are extremely space-constrained on the NVMe and absolutely must not OOM – even if progress stalls to an absolute crawl.

Why would you want to see killed processes when you go back to your workstation, in the 1/10000th scenario where something runs amok pushing memory usage to unexpected high levels? When you can simply investigate the reason behind the rare occurrence, then move all the pages off the slowest devices immediately with swapoff?

It was just an example of a “smaller+faster than your average SSD”.

^{and I was mentioning something similar to my setup instead of an imaginary use-case.}

Alright, I will only reply to you, since you raised a fair question.

First of all, I must admit that I thought what was linked was an earlier similar writing, but the general theme is still the same.

The problem with the writing is that it focuses on use-cases like Android and some servers, but doesn’t take into account other use-cases. It also seems to come with the assumption that setup is done by the distributor only, or if it’s done by the user, it’s a configure-and-forget situation.

What he represents is:

• Limited RAM space
• Swap will always/often happen (outside of (z)ram)
• Single tier of non-RAM swap
• Non-ram swap is significantly slower
• OOM can be preferable over (outside of ram) swapping
• Swapped out pages stay where they are until they are required by their process (important).

Now let’s look at a possible modern workstation setup:

• Large RAM size
• Swap is rarely hit, especially if set up with zram.
• Multiple swap tiers beyond zram/zswap
  • Intel Optane disk used as a super-fast zram write-back device, or a high-priority swap
  • Fast NVME disk used as a second tier swap disk
  • Large HDD swap partition used as a third tier swap disk
• The biggest consideration is avoiding worst case latency, i.e. hitting HDD swap.
• Killing processes MUST be avoided, unless exceptional circumstances are hit where the kernel’s OOM would kick in anyway. This holds true even when HDD swap starts getting used.
• When unusual loads are observed, swapped pages can be moved around by the user (or a tool), by turning swap devices off and on. This is how you can empty the HDD swap partition for example.

This last point in particular should make it clear why his “imagination” was rather limited in his LRU inversion section.

It’s shit info. zram is actually better, more so with high ram size+high usage situations.

Oh, you wrote “easy” not “early” in OP. In any case, this looks stupid. But to each their own, I guess.

Why do you think 32GiB is special compared to 16GiB?
And wtf is EasyOOM?

You maximize the usefulness of zram by actually increasing sappiness, and giving zram devices high priority. e.g.

sysctl vm.swappiness=100

for i in {1..8}; do
  swapon /dev/zram${i} -p 32767
done

Then you enable other swap devices with lower priority.

This is the way regardless of how much RAM you have. I mean, it may be pointless if you never ever exceed, let’s say 10/32GiB (including caching). But it still wouldn’t be harmful in any way.