Linus Torvalds Officially Announces the Release of Linux Kernel 4.8 (softpedia.com) 95
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.
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.
Well that's nice (Score:2, Informative)
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 (Score:5, Interesting)
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: (Score:2)
4.8 doesn't require systemd either..
Re: (Score:2)
sorry, also meant to add that old kernels don't require systemd either.
Re:Well that's nice (Score:4, Informative)
arth's point was that the kernel, new or old, doesn't require systemd.
Re: Well that's nice (Score:1)
Not yet, but I'm sure Lennard will correct that in due course.
Re: (Score:3)
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 [phoronix.com].
Re: (Score:2)
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 [phoronix.com].
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.
What OpenRC ? (Score:2)
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 [tldp.org] ?
Turn your geek card, you non-Sysvinit / non-Bash script heretic !
Re: (Score:3)
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
Re: (Score:2)
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 dist
Re: (Score:2)
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
Re: (Score:2)
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 anythin
Re: (Score:2)
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.
Re: (Score:2)
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: (Score:3)
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... [fedoraproject.org]
Re: (Score:2)
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 syst
Re: (Score:3)
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 eve
Re: (Score:1)
I'm running stampede 2.0.32 and it still works on my 0xF00F, almost as smooth back when it was the year of the Linux Desktop.
No more first posts since ages though and swap partition envelopes nearly the disk nowadays when starting Firefox.
Re: (Score:1)
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 a
Re: (Score:2)
Non-Volatile Dual In-line Memory Module (NVDIMM)
Is that another way of saying 'PCIe SSD'?
Good. (Score:1)
Now we can give Linus back his blanket.
Just wait for 6.4! (Score:1)
Upon the release of Linux 6.4, Time magazine will officially declare it to be "Year of the Linux Desktop"... in memoriam of Linus. :(
RIP Linus 20XX: that badger was too fast for anyone to dodge.
Linux Torvalds sends his regards (Score:5, Funny)
https://regmedia.co.uk/2015/07... [regmedia.co.uk]
Re: (Score:1)
Linux is a punk.
Re:systemd (Score:4, Informative)
systemd is a pile of horse shit [phoronix.com] 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.
Re:systemd (Score:5, Insightful)
Re: (Score:2)
Nine, Maybe Ten, How About Eleven (Score:1)
No less than eight release candidates. But how many release candidates were there?
Does it? (Score:2)
Does it have a new Easter Egg game to play when you click the Linux logo many times in a row?
Announcement (Score:5, Funny)
Re: (Score:1)
The announcement was made from a balcony somewhere in Finland. We expect the video anytime now.
So fucking META
Re: (Score:2)
Re: (Score:2)
The announcement was made from a balcony somewhere in Oregon. We expect the video anytime now.
FTFY.
Woops (Score:1)
Misleading summary as usual. (Score:1)
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.. (Score:1)
not a cuss word or insult to be found anywhere in that announcement [iu.edu].
Wow (Score:2, Insightful)
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: (Score:2, Funny)
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? (Score:3)
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? (Score:4, Insightful)
Re: (Score:2)
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: (Score:2, Insightful)
Or alternatively, there is a lack of understanding of the Linux kernel development process.
Re: (Score:2)
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 (Score:2)
Moving faster? (Score:2)
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: (Score:2)
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.
That was quick (Score:1)
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: (Score:1)
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: (Score:1)
Wow, time flies. I didn't realize it had already been a year and a half.
Still Wish it were Micro-Kernal. (Score:2)
Sorry. I love the community, but I wish the kernel was more modular and adaptable without recompiling.
Re:Still Wish it were Micro-Kernel. (Score:2)