Next kernel will be 6.0

[peebee]

https://www.kernel.org/

Probably? LTS?

[Grey]

https://www.kernel.org/

Probably? LTS?

Oh. And I'm "stuck" on 5.18.2 and still can't move on. Whether it's because of the heat, or I'm not in the mood, I don't know

[mikewalsh]

Didn't I read somewhere that with the release of 6.0, the kernel team have made a huge number of changes, more and more of which are seriously favouring systemd? And that "non-standard" init systems are being increasingly left out in the cold...?

Looks like Poettering's getting his way again.

Mike.

[ozsouth]

@mikewalsh - Linus T seems to be favouring that way now. At least systemd isn't the dogs brekky it was.

[wiak]

Didn't I read somewhere that with the release of 6.0, the kernel team have made a huge number of changes, more and more of which are seriously favouring systemd?

I wouldn't worry about it too much. Kernel 6.0 is not going to take away ability to use SysVinit, runit, or whatever. As for systemd... well, think about the situation:

systemd has/was adopted as the preferred init by most upstream distros around ten years ago... Linux as an OS is a bit of a jungle when you (otherwise) think of it - alternative init systems, alternative desktops environments (so many...), and even different start menus (or none at all), tint2 bars, or Lmpanel, or Rox pinboards, or what have you...

How can an operating system be sensibly developed when there are so MANY combinations of different core systems (with common kernel - well actually not - constantly changing kernels and different ones used, different modules, firmware, here there and everywhere)?!!! Yes, we love choice, but that has that huge issue/disadvantage that development focus is widely spread - nothing in such a world ever gets created as best it could be if the focus was better. I myself think it is great to have alternative desktop environments, because that nowadays is the major component in allowing us to build distros that run faster on lesser hardware (we can do nothing about web/browser bloat - all distros have to face that side of the issues that confront us all). But... the init of a distro is REALLY a pretty low-level and core important system component. It is almost crazy to not fix that as a common component for all Linux distros - that's my opinion anyway. Yes, you can still (and probably always) build a simple little init system for a mini linux using sysvinit mechanism, and runit does a pretty good job of providing similar functionality to systemd (but it is NOT as polished and easy to use IMO and I've used them all).

Truth is, personally, I am always glad when a system I am weedogging is using systemd (and most of course nowadays do...) because I become familiar with systemctl start, stop, restart and systemd arrangement and operation - I cannot be bothered with sysvinit systems because it everyone writes their own scripts to use with that and result can be so different it means re-learning how the damned thing works every such distro I play with! Systemd pretty much always works for me (and yes, I have similar feelings about the likes of pulseaudio and likely replacement, in the same vein, pipewire). People should IMO embrace new core systems and become good with them and advance them instead of hanging on to a mess of different alternatives that end up just making development more complicated - sticking with old sysVinit does not make the resulting distro better - it simply increases the chance parts of it won't work well. Linux is great for its flexibility of desktop environments as I said, but for goodness sakes it really needs to move away from TOO MUCH core system alternatives - that is just a waste of human hours since each init system is used to effectively provide exactly the same functionality (though usually not so good as systemd....) unlike different desktop environments, which are a trade-off between functionality and resource usage.

So IMO the best Linux design would not offer many alternative low-level system mechanisms. Rather its low-level design should be rock-solid good, flexible and advanced - that would benefit all distro variant design in the end and save tons of re-invented wheels. Come to think of it, one really flexible initrd (and I'm not talking about WDL initrd) would be wonderful for saving time/effort/skill in getting systems all to boot via well-understood methods for any sort of usage (full or frugal install, with overlayfs or not and so on). Instead it is even hard work determining how to uncompress the myriad of initrd's out there when we wish to see how another distro boots and works - cpio (with or without gz, lzma, jumping some header or other via dracut facilities or whatever), squashfs variants or ext4 image files - it goes on and on and that's before we even look inside them to see what the init script does!). Yes, all the crazy alternative system-level components make for a great hobby - a great vehicle to build a hobby system - but wastes so much human energy and intellectual thought and time in the process. And then there are the tons of different package managers all doing effectively the same job, and because of that complexity (and breaking systems via constantly being updated dependencies), the approach of avoiding such package managers altogether via humungous self-contained apps+their-dependencies type systems such as Appimage, Flatpak, Snap and so on... Really it all becomes pretty dumb in the end (similar to different countries driving on different sides of the road and having to redesign cars with steering wheels on alternative sides!!!). That's humans for you. We certainly know how to make development difficult and expensive.

So my own favourite development hobby work nowadays is simply weedogit.sh script. I don't need to care about what init system is being used and my grub2 config is pretty much identical for all distros I'm playing with and allows me to check out all the distros in frugal install configurations that I'm curious about. Underneath the most important thing for me is simply to maintain and improve that one core item I use, which is WDL initrd... I don't care what root filesystem it is booting and that makes my own life easy. If Linux itself would focus a bit more and not have too much underneath system-level alternatives, that would be great, and we could then better focus on what the user actually wants in terms of best GUI desktops and facilities and so on.

[wiak]

https://en.wikipedia.org/wiki/Systemd#History

In May 2011 Fedora became the first major Linux distribution to enable systemd by default, replacing Upstart. The reasoning at the time was that systemd provided extensive parallelization during startup, better management of processes and overall a saner, dependency-based approach to control of the system.[18]

In October 2012, Arch Linux made systemd the default, also switching from SysVinit.[19] Developers had debated since August 2012[13] and came to the conclusion that it was faster and had more features than SysVinit, and that maintaining the latter was not worth the effort in patches.[20] Some of them thought that the criticism towards the implementation of systemd was not based on actual shortcomings of the software, rather the disliking of Lennart from a part of the Linux community and the general hesitation for change. Specifically, some of the complaints regarding systemd not being programmed in bash, it being bigger and more extensive than SysVinit, the use of D-bus, and the optional on-disk format of the journal were regarded as advantages by programmers.[21]

Between October 2013 and February 2014, a long debate among the Debian Technical Committee occurred on the Debian mailing list,[22] discussing which init system to use as the default in Debian 8 "jessie", and culminating in a decision in favor of systemd.

[Grey]

That's humans for you.

A friend of mine wants to write his own picture viewer all the time (with blackjack and whores, as he says ). I tell him every time that it's better to finally finish writing the ceiling fans control program. No, a picture viewer and that's it. Because you can buy an outlet with a remote control and a timer. And there don't seem to be enough viewers, or what

[wiak]

Most of us need hobbies though.

If it all becomes too focussed it becomes less useful as a time-'occupying' hobby.

That's why what I say about the likes of what Puppy Linux itself provides is a different picture (and others understandably thus disagree with me). I think of most distros discussed on this forum (in particular) as hobby-ventures and flexibility is more fun in that pursuit. If someone wants Puppy Linux to be a professional Linux distro (e.g. to be used in mission-critical business use) then it would/should have a very different design philosophy approach - ONE package manager would then make utter sense.

But that is not Puppy Linux style or I feel reason to be enthusiastic about. There are better professional-oriented distros, but most of these limit hobby Linux enthusiasts one way or the other.

Nevertheless, I wish Linux core design would be at least be a bit more focussed - there is too much choice. I like systemd. Kernel constantly changing is a problem in itself (glibc worse, X being replaced by Wayland yet another long term nightmare can of worms). No wonder the distros we 'create/discuss/glue-together' are always so rough around the edges. Bluetooth not working, remote desktops not even considered or implemented properly, yes, browsers tend to work... and libreoffice... focus is impossible. Half the time (or more) even basic printing isn't working reliably. But that's 'hobby distros' for you - I accept that - for something else I use something else.

I don't want hobby linux distros to become irrelevant. Because then I'd have to take up chess again, or find something else to spend my time on.

[fredx181]

I wouldn't worry about it too much. Kernel 6.0 is not going to take away ability to use SysVinit, runit, or whatever. As for systemd... well, think about the situation:

systemd has/was adopted as the preferred init by most upstream distros around ten years ago...

It would be a bad thing IMO if the kernel development influences user-space in a way that using only systemd is inevitable.
If so, I think Puppy developers will have a really hard time to make it work with systemd just as good as with sysvinit.
Yes, systemd works well on the major distro's such as Fedora, Ubuntu, Debian, Arch Linux .... ....
But Puppy really is VERY different, call it un-orthodox, I'm sure the systemd developers didn't think 'Ok, let's support Puppy Linux too", no way

[wiak]

I wouldn't worry about it too much. Kernel 6.0 is not going to take away ability to use SysVinit, runit, or whatever. As for systemd... well, think about the situation:

systemd has/was adopted as the preferred init by most upstream distros around ten years ago...

It would be a bad thing IMO if the kernel development influences user-space in a way that using only systemd is inevitable.
If so, I think Puppy developers will have a really hard time to make it work with systemd just as good as with sysvinit.

Nah, I discovered Fedora even uses systemd to in their initrd to set up that stage and prepare for the main root filesystem. At least runit should be considered as a reasonable alternative (until everyone gets fed up kicking a dead horse - systemd might even end up with much of its code in the kernel!) and move away from sysVinit IMO

[rockedge]

@wiak I have experimented with runit compiled in Puppy Linux builds. Nothing major yet but got it so far as it compiled and did stuff.
https://github.com/void-linux/runit

[peebee]

o news
When linux-v6.0 (not -rcN) is released, current GIT repos (aufs5-linux
and aufs5-standalone) will be replaced by aufs6-*, and I will stop
maintaining aufs5.10--aufs5.14 branches.

Aufs5.x-rcN branches in this replease is for linux-v6.0-rc1. No new
features but some behaviours changed in the mainline.
- unlink(2) and rmdir(2) in NFS is broken, and they may result
NULL-pointer-access.
- access(2) in tmpfs changed its error code.

J. R. Okajima

NOTE, this is the LAST 5.18.y stable release. This tree will be
end-of-life after this one. Please move to 5.19.y at this point in time
or let us know why that is not possible.

[bigpup]

If a Puppy version starts using it.

The bigger question is, what older hardware is no longer going to be supported

I hope that is still a concern for Puppy Linux versions.

[dimkr]

I don't get this drama around 6.0, and it's been this way at 5.0, 4.0 and 3.0. News sites like the .0 version number and "announce" it on their front page, without looking at the changelog. There's nothing fundamentally different about 6.0: it won't force anyone to use systemd, it won't suddenly lose a big bunch of drivers, and hardware requirements won't change drastically. In a parallel universe where Linus opts for 5.20.0 as the version number, you'd get the same kernel.

Here, 3 quotes from Torvalds:

when the minor number gets to around 20 I prefer to just increment the major number instead and reset to something smaller.

Despite the major number change, there’s nothing fundamentally different about this release

if you want to call this "Linux 5.20", go right ahead. Because the kernel version numbers really are entirely made up and have no intrinsic meaning.

[Clarity]

Kernel 6 is now at RC2. Is this a request from Tovalds?

FYI

Curious: Will the upcoming WoofCE builds have latest NTFS features enabled within its kernel(s)?

[mistfire]

Kernel 6 is now at RC2. Is this a request from Tovalds?

FYI

Curious: Will the upcoming WoofCE builds have latest NTFS features enabled within its kernel(s)?

Luckily, @peebee always implement as a builtin kernel module on his lxpup kernels. NTFS3 was very helpful on dealing NTFS storage. It works fast with less CPU usage than NTFS-3G

[rockedge]

I also build in both overlay and NTFS3 into the kernels I compile as well.