Bcachefs Looks Like It Won't Make It For Linux 6.6

[MorrisS.]

I've noted a strange behavior in the memory management. When the RAM has been fulled, the HDD is involved. When the fulled RAM is freed the system continues to involve the HDD making slow al the activities. What is the cause? (kernel 6.2)

[avis]

I've noted a strange behavior in the memory management. When the RAM has been fulled, the HDD is involved. When the fulled RAM is freed the system continues to involve the HDD making slow al the activities. What is the cause? (kernel 6.2)

1) Paging out (into swap)
2) Paging in (from swap)

[Quackdoc]

I'm among those people as well. I hope this Kent-guy manages to cool his head and just proceeds to do as asked to. All this hubbub would die off practically instantly if he'd just sign with PHP, fix the compilation error and submitted the patches to kernel-next and everyone would benefit. But oh well, it is his decision.

not so simple, Torvalds already said that he didn't want to merge over the objections of other maintainers, said maintainers who objected, without giving reason, and when asked for elaboration, ghosted. This has been an ongoing issue for a long time on the LKML, long before bcachefs, where someone would get a NAK, and then correspondence would just end without further elaboration (this is an issue with mailing lists in general which is why I really don't like them, not sure what a suitable solution is, gitlab is the closest to being acceptable, but it's still not good).

[timofonic]

Too many egos, too little technical mindset and work using something a lot more reliable and responsible, e.g. github/gitlab where people can post merge requests officially and discuss them in a manner which facilitates a frictionless information exchange without the need to grep through thousands of emails trying to find a needle in a haystack.

Issues like this will rear its ugly head again and again in the future. A mailing list as a method of developing such a big project with so many participants is simply wrong and breaks way too often.

Too bad, LKML is preferred for the exact same reasons: no fucking responsibility for anything. There are literally tens of dozens of unreplied posts with serious issues in LKML every month. And don't tell me kernel developers are volunteers working in their spare time. Over 95% of commits to the kernel are made by paid developers developing the Linux kernel and nothing else.

Sometimes I don't like your attitude. But these days you're very right!

I fully agree with you in this topic

[npwx]

What a strange word... I had to look that up on StartPage:

I could imagine its use is more common in Europe, but anyone from Europe should probably know what it means.

[Vistaus]

I hope it wont end up similar to "that filesystem that shall not be named".

ReiserFS. There, I said it.

[Vistaus]

What a strange word... I had to look that up on StartPage:

Maybe in English, but in Dutch, it's quite well-known.

[Errinwright]

The Joker?

...that's probably unwarranted. That said, if a rewrite is on the cards, be aware that Rust is not a magic wand to make your code bug-free. It certainly doesn't substitute for poor, or lacking, systems analysis; or misapprehensions about workflows; or other meta-level complications of logic encoded in the application. Understanding what your code is meant to do is far more important than writing exemplary code that does the wrong thing.

It is, albeit barely. The distant future will see it release in Rust (7-9years).

[andyprough]

It is, albeit barely. The distant future will see it release in Rust (7-9years).

As we can see from Wayland, 7-9 years is no longer a "distant future" in GNU/Linux development terms, or even 15 years. LLVM took about 18 years to be able to build the kernel. A major project like a new kernel or a rewritten kernel is going to take multiple decades to have broad useability, probably 20-30 years, maybe more.

[cl333r]

What a strange word... I had to look that up on StartPage:

https://www.youtube.com/watch?v=gEyFH-a-XoQ