Linus Torvalds Officially Announces the Release of Linux Kernel 4.8 (softpedia.com)

Slashdot reader prisoninmate brings news from Softpedia: Today, Linus Torvalds proudly announced the release and availability for download of the Linux 4.8 kernel branch, which is now the latest stable and most advanced one. Linux kernel 4.8 has been in development for the past two months, during which it received no less than eight Release Candidate testing versions that early adopters were able to compile and install on their GNU/Linux operating system to test various hardware components or simply report bugs...

A lot of things have been fixed since last week's RC8 milestone, among which we can mention lots of updated drivers, in particular for GPU, networking, and Non-Volatile Dual In-line Memory Module (NVDIMM), a bunch of improvements to the ARM, MIPS, SPARC, and x86 hardware architectures, updates to the networking stack, as well as to a few filesystem, and some minor changes to cgroup and vm.
The kernel now supports the Raspberry Pi 3 SoC as well as the Microsoft Surface 3 touchscreen.

Comments

Well that's nice

[Anonymous Coward]

I'm still using 2.6.32-642.4.2 and it works eminently well for me. Plus, no systemd.

Re:Well that's nice

[arth1]

I'm still using 2.6.32-642.4.2 and it works eminently well for me. Plus, no systemd.

No need to stay at old kernels to get the benefit of no systemd.

# uname -a
Linux hastur 4.4.21-gentoo #1 SMP Thu Sep 29 15:31:21 EDT 2016 x86_64 Intel Xeon E312xx (Sandy Bridge) GenuineIntel GNU/Linux
# ps -fp 1
UID PID PPID C STIME TTY TIME CMD
root 1 0 0 Sep29 ? 00:00:02 init [3]

Re:Well that's nice

[epyT-R]

4.8 doesn't require systemd either..

Re:Well that's nice

[epyT-R]

sorry, also meant to add that old kernels don't require systemd either.

Re:Well that's nice

[epyT-R]

arth's point was that the kernel, new or old, doesn't require systemd.

Re: Well that's nice

[Anonymous Coward]

Not yet, but I'm sure Lennard will correct that in due course.

Re: Well that's nice

[arth1]

Not yet, but I'm sure Lennard will correct that in due course.

One of the systemd developers tried to make changes to the kernel for systemd only, breaking other software in the process, and was politely told where to stuff it.

Re:Well that's nice

[Anonymous Coward]

I preferred the Linux kernel when its versioning was not driven by a marketingseque scheme. Between SystemD, dropping support of older hardware - why when almost everything can be a module? - and this version grinding it is disheartening. I was a relatively early adopter of GNU/Linux in 1992 when it was primarily a command-line-driven user interface.

Linus if you feel compelled to make changes maybe try redesigning the kernel to a micro-kernel. These days any perceived advantages of a monolithic kernel are addressed by CPUs whose speed we could not even fathom when you began this epic adventure with "nothing commercial, just a hobby" operating system used by millions of people or organisations around the world. A grateful GNU/Linux user on a personal and professional level.

Re:Well that's nice

[arth1]

You can tell the system with sysvinit apart by the runlevel being shown, in this case [3].

(And that telinit is actually working, so you can change runlevels at will or have init reload, without having to reboot, like with upstart or systemd.)

Re:Well that's nice

[Rutulian]

Of course you can change targets ("runlevels") with systemd without rebooting. If you use Fedora, they have even preserved the telinit command and made equivalent "runlevel" targets, to make it easy for people coming from a sysvinit background.

https://fedoraproject.org/wiki...

Re:Well that's nice

[arth1]

If you use Fedora, they have even preserved the telinit command and made equivalent "runlevel" targets, to make it easy for people coming from a sysvinit background.

So if I update any of the libraries that init uses, all I have to do is a "telinit q"? Last I checked, that was broken in upstart, and missing in systemd.

And systemd now lets me drop to single user mode? That's an improvement. Last I heard was that the systemd perps claimed that you didn't need single user mode nor read-only, evidence to the contrary (like growing raids or single-stepping through commands with nothing running except what was manually started) being archaic and not needed on modern systems...

Re:Well that's nice

[Rutulian]

So if I update any of the libraries that init uses, all I have to do is a "telinit q"?

systemctl daemon-reexec

That one isn't mapped to a telinit equivalent (I don't think).

Last I checked, that was broken in upstart

Lots of things were broken in upstart. Systemd is a tremendous improvement over upstart, much to the chagrin of Mark Shuttleworth.

And systemd now lets me drop to single user mode? That's an improvement.

That's been there, for a while. I'm not sure who these "perps" are that you speak of, but systemd will do anything you tell it to. If you want a single user mode, define a target that creates a single user mode, just like you would define runlevel 1 to not start multiple ttys. I didn't follow every development of systemd as it was happening, and only really jumped in when it came (officially) to Red Hat 7.2 and then Ubuntu 16.04. While there are some lingering integration issues still (mostly with specific daemons), I would say it works pretty well, and the distro maintainers have done a lot good work with backwards-compatibility scripts to help people transition from sysvinit. So yes, there is a rescue.target, which is also called runlevel1.target on both Fedora and Debian.

Re: Well that's nice

[lsatenstein]

Not yet, but I'm sure Lennard will correct that in due course.

One of the systemd developers tried to make changes to the kernel for systemd only, breaking other software in the process, and was politely told where to stuff it.

Yes, systemd in 2014 was flakey, just as pulseaudio was back in it's time. But it is doing well today, healthy, and meeting expectations.

Good.

[Anonymous Coward]

Now we can give Linus back his blanket.

Linux Torvalds sends his regards

[Anonymous Coward]

https://regmedia.co.uk/2015/07...

Nine, Maybe Ten, How About Eleven

[Anonymous Coward]

No less than eight release candidates. But how many release candidates were there?

Does it?

[dohzer]

Does it have a new Easter Egg game to play when you click the Linux logo many times in a row?

Announcement

[hcs_$reboot]

The announcement was made from a balcony somewhere in Finland. We expect the video anytime now.

Re:Announcement

[Anonymous Coward]

The announcement was made from a balcony somewhere in Finland. We expect the video anytime now.

So fucking META

Re:Announcement

[MayeulC]

I'm So Meta, Even This Acronym

Re:Announcement

[swillden]

The announcement was made from a balcony somewhere in Oregon. We expect the video anytime now.

FTFY.

Woops

[MayeulC]

I was planning for at least one more RC, looks like I will have to hurry to catch the merge window.

Misleading summary as usual.

[Anonymous Coward]

A lot of things have been fixed since last week's RC8 milestone

vs the actual announcement:

So the last week was really quiet, which maybe means that I could
probably just have skipped rc8 after all. Oh well, no real harm done.
[snip]
Anyway, there's a few stragging fixes since rc8... [snip]

All of it pretty small, and there really aren't that many of them.

it's gotta be a forgery..

[Anonymous Coward]

not a cuss word or insult to be found anywhere in that announcement.

Wow

[Psychotria]

Years ago when I first started reading slashdot, a story about Linux kernel release (even though they often weren't all that interesting) generated interesting discussions. I see just 2 comments here so far that are not stupid. The rest are bad attempts at trolling, or for some reason using the story to talk about systemd, or very bad attempts at humour (humour is better than the rest of the shit though... I like humour if it's actually funny). It seems that the real nerds have abandoned slashdot entirely :(

Re:Wow

[Anonymous Coward]

and where does your little moan fit into the categories that you've defined for us? It certainly isn't in the 'interesting' one.

Eight RCs?

[allo]

That's not good sign. Either Linus doesn't understand what a RC is, or each of them still had bugs nobody noticed before, which is a bad sign for the code.

A RC is something, which can be renamed to a final version, unless somebody finds a critical last minute bug.

Re:Eight RCs?

[gmack]

On something as complicated as an OS, there will be bugs that are workload or hardware dependent and won't show up until the wider pool of people start testing it and that, as it turns out, is when RC1 gets released. .

Re:Eight RCs?

[Anonymous Coward]

Or alternatively, there is a lack of understanding of the Linux kernel development process.

Re:Eight RCs?

[allo]

If you're ending up having eight RC, you did not have long enough beta phase before. An RC should not require any further snapshot. It can happen (that's why you have a RC), but more than let's say RC3 is a bad sign.
It may happen for one release, because you don't go back from rc2 to beta8, but if it happens on a matured project, that's strange.

Re:Eight RCs?

[allo]

alpha-beta-RC-final is independend from the process. The process of the kernel would require many beta-releases, but not many RCs. If they label it correctly and it's not totally broken (i would guess it's not).

Isn't every release

[sabbede]

the latest and most advanced?

Re:systemd

[number6x]

systemd is a pile of horse shit that was thrown into a fan so it sprayed everywhere, touched everything and contaminated what it touched.

sysvinit is a pile of cow shit, in a field somewhere, touching only the ground it rests on. Don't go to that field and step in that pile and it won't bother you.

If there are bugs in sysvinit, they affect sysvinit. If there are bugs in systemd, its everyone else's fault and everyone else should re-write their software to handle the bugs in systemd because the systemd developers are way too important to waste their incredible talent fixing their own bugs.

What OpenRC ?

[DrYak]

What? OpenRC? Why run a mean a lean init system written C ? The heresy !

When you could show the world how geeky you are by running a horrible pile of hacked-together shell-scripts as the gods themselves (= Old versions of UNIX) intended ?
With said shell script running inside bash, a shell interpreter whose BUG manpage section not only opens with... :

It's too big and too slow.

...but also a shell interpreter that features full blown networking support out of the box ?

Turn your geek card, you non-Sysvinit / non-Bash script heretic !

Re:What OpenRC ?

[arth1]

What? OpenRC? Why run a mean a lean init system written C ? The heresy !

You're confusing sysv init with sysv rc. Gentoo uses sysv init - no need to replace the init system with something complex. OpenRC is a replacement for what init calls - the rc handler, which doesn't need pid 1.

Personally, I like many of openrc's ideas, but not the implementation. I like good old-fashioned runlevels, and not named abstractions that may differ from system to system. Predictability is good. So are posix scripts, which continue working even on systems where /bin/sh is lightweight ash or some other bourne family shell that isn't bash.

Re:What OpenRC ?

[Rutulian]

I like good old-fashioned runlevels, and not named abstractions that may differ from system to system

Um, why do you think "old-fashioned" runlevels are any less abstract than named process groups. A runlevel is just a group of processes to start that happens to be named as a number (ex: runlevel 3 could just as easily be "network-enabled" and function identically). The fact that most linux distributions used runlevels may have been a convention, but it was hardly a standard. In fact, Red Hat famously used runlevel 5 to distinguish between an X and console environment, whereas Debian used runlevel 3 to distinguish between single-user vs multi-user environment regardless of whether there was a desktop session manager running. So I would definitely call runlevels "named abstractions that may differ from system to system". Since derivative distributions (ex: Ubuntu from Debian and Mandrake from Red Hat) tended to adopt the original's runlevel classification, it may have given the appearance that there was a de facto standard, but there really wasn't.

Predictability is good.

Correct. Which includes knowing that your processes actually started and not just that you told them to start, but maybe they failed, when you change runlevels.

So are posix scripts, which continue working even on systems where /bin/sh is lightweight ash or some other bourne family shell that isn't bash.

Some do, some don't. It depends on who wrote the script. When Ubuntu switched to dash, which was one of the first attempts to speed up boot times years ago, quite a few of the boot scripts broke and had to be rewritten. If you upgraded Ubuntu and suddenly one of your services didn't start, switching back to bash was usually the easiest fix. They eventually ironed out all of the bugs, but it was shaky for a while.

Re:What OpenRC ?

[arth1]

Correct. Which includes knowing that your processes actually started and not just that you told them to start, but maybe they failed, when you change runlevels.

Um, no. That's not predictability, that's assumptions.
One of the absolute worst features of systemd (and inittab when abused) is automatic restart. Predictability is to know that when a daemon crashes, it will stay down so you can investigate why it crashed, and not have log files and other evidence overwritten by a watchdog you didn't even set up to do so attempting to restart it.
Being able to single-step through the startup sequence one script at a time. Because the start order is 100% predictable.

As for what starts and stops at each runlevel, that's as easy as an "ls". Beats grepping a myriad of MSDOS ini files (and grep doesn't work all that well with ini files in the first place, given that you can have the same keyword in different sections), or using specialized tools that aren't even available because your system didn't boot far enough.

I have tried systemd. And I find it to combine the worst aspects of Windows 95 .ini files and the admin-unfriendliness of IBMs smit. No, thanks. After the first crash where I couldn't fail over to another machine, I said enough is enough.

Re:What OpenRC ?

[Rutulian]

One of the absolute worst features of systemd (and inittab when abused) is automatic restart.

I never said anything about automatic restart. Systemd allows you to be alerted to and to respond to process failures. To me, that's predictability. If I start a bunch of network services and one of them fails, systemd will decide whether to continue (ie: the dependency tree allows it) or to fail. Regardless, the outcome is entirely predictable. Services that depend on other services (which includes the target state itself) will have all of their dependencies satisfied, or they won't be started, and anything that fails will be logged in a consistent manner that is easily parseable by a system monitoring utility. When you "telinit 3", sysvinit runs all of the scripts in /etc/rc3.d and if they start they start, if they fail they fail. It's up to you to scrape the logs and keep tabs on all of the daemons. The state "runlevel 3" is not guaranteed.

Because the start order is 100% predictable.

Ah, ok, that's a different kind of predictable. I agree, start order is not predictable with systemd. I would argue, though, that it doesn't need to be because you have explicit dependencies that allow depending on the actual started and functioning state of a prior process (as opposed to just a numbering scheme), and logged events that allow you to determine precisely when and where (and often why) a dependency tree failed. You don't need to step through the boot process one script at a time because the log tells you exactly what failed, and you can start your debugging there right at that point.

As for what starts and stops at each runlevel, that's as easy as an "ls". Beats grepping a myriad of MSDOS ini files

Agreed that it isn't quite as nice and easy as an "ls", but it definitely is not as complicated as grepping the unit files and trying to figure out when things start. The nice thing about explicitly declaring your dependencies is that you can have systemd show them to you. Let it do the work so you don't have to.

And I find it to combine the worst aspects of Windows 95 .ini files

That's kind of funny because .ini files were one of the better parts of Win95. They were simple text, easy to read and edit (by a human) configuration files, that happened to use [bracketed] headers, but whatever. Samba actually uses that convention for smb.conf, by the way. Anyway, Win became much worse when they took away the .ini files and replaced them with the registry. If I need to change a configuration, I would rather do it in a plain non-executable text file, rather than something structured but cumbersome like XML, or something with variables and conditionals built-in but takes time to parse and study like a shell script.

Re:What OpenRC ?

[Rutulian]

As for what starts and stops at each runlevel, that's as easy as an "ls". Beats grepping a myriad of MSDOS ini files

Agreed that it isn't quite as nice and easy as an "ls",

Scratch that. It is as easy as an "ls". I was poking around in the /etc/systemd directory and realized /etc/systemd/system is functionally equivalent to /etc/rcX.d/. It is maintained by the systemd daemon, but it consists of a bunch of symlinks to service unit files that allow you to very quickly and easily see which services are dependencies of a particular target.

Moving faster?

[furry_wookie]

Is it just me or are the version numbers accelerating?

Redhat Enterprise is still running 3.10 in its latest release. At this pace it seems like Linus will be well into 5.x, or 6.x before Redhat 8 ever comes out(probably beta next year).

Re:Moving faster?

[kwalker]

The way Linus runs the kernel version numbers, yes, they are moving faster than they used to. It used to be that he would work on 2.x.y, then y+1 and so on. Now he works on 4.x and eventually they proclaim one to be "LTS" (in this case 3.10) and another trusted lieutenant maintains that tree for a while, and Linus works on 4.x+1.

And especially with the way Red Hat prefers stable kernels, they always track LTS, regardless of what Linus is working on.

Re:systemd

[Barsteward]

yaaawwnnnnn......

That was quick

[TylerJWhit]

4.0 just came out a couple of months ago and now we're on 4.8. That's fast. Did Linus choose a different numbering scheme for the Linux kernel?

Re:That was quick

[emmamai]

4.0 was released a year and a half ago, and new releases come out approximately every 2 months.

Ever since 3.0 came out, the numbering scheme has simply been "Increment the minor number every release. Increment the major one whenever we feel like it."

Re:That was quick

[TylerJWhit]

Wow, time flies. I didn't realize it had already been a year and a half.

Still Wish it were Micro-Kernal.

[BrendaEM]

Sorry. I love the community, but I wish the kernel was more modular and adaptable without recompiling.

Re:Point?

[unixisc]

Non-Volatile Dual In-line Memory Module (NVDIMM)

Is that another way of saying 'PCIe SSD'?

Re:Still Wish it were Micro-Kernel.

[unixisc]

If that's what you want, just go w/ Minix 3.x. Or do you have anything against NetBSD userland?

Re: systemd

[Barsteward]

he/she certainly knows nothing hence the yawn and its from hearing tired old crap from adolescent ignorant trolls