Slashdot Mirror
Linux 4.0 Kernel Released
An anonymous reader writes "The Linux 4.0 kernel has been released. Linux 4.0 brings many features including live patching, Radeon DisplayPort Audio, RadeonSI fan control improvements, new OverlayFS functionality, Intel Quark SoC support, and a heck of a lot more. Linus's release announcement reads in part: "So I decided to release 4.0 as per the normal schedule, because there really weren't any known issues, and while I'll be traveling during the end of the upcoming week due to a college visit, I'm hoping that won't affect the merge window very much. We'll see. Linux 4.0 was a pretty small release both in linux-next and in final size, although obviously 'small' is all relative. It's still over 10k non-merge commits. But we've definitely had bigger releases (and judging by linux-next v4.1 is going to be one of the bigger ones)."
Four major versions in 25 years, who does Linus think he is? He's drunk with power!
Over 20 billion Linux kernels in use on a daily basis. How many exploits have your heard about, troll?
You do understand that Shellshock was not a Linux vulnerability, right?
Our sales department decided in our contracts a (totally arbitrary) policy to "support" only the last 3 major versions of our products. This means we periodically update the major version just so we can stop supporting the older versions even if there are not any major new features.
It's kind of funny that Microsoft has also decided to move their Kernel from version 6.1.62.6.2.7.21.1.6.2.2.000.02.432.523.253.532 to 10.0 in Windows 10.
I wonder if some useless managers got wind of Linux changing theirs, and made their developers change the number.
"Dear busy senior developers: I just found out Linux made a bigger number. Why can't we? Why are you wasting our time fixing bugs? Add this feature I just heard about today! It's very important.
Sincerely,
--Scott Miller"
I suppose I should start looking to upgrade my old Centos 6.6 box. I'm running a 2.6.32 kernel on that. I've thought about upgrading to the new Centos 7,0 but I'm not sure I want to fuck with it. The current system I have works perfectly and does exactly what I need it to do.
Well Centos 7 will cure that. It's based on systemd.
*IF* you don't change it.... or dare to dream by suspending it and expecting it to come alive again exactly the way it was before. Double headed may or may not work. Yeah, other then that it is stable.
Oh and you need linux support for all the hardware in your machine. And have the fortune that all new (within the last 10 years) features of your device are supported in the available linux driver. Not to mention whether it will support dual graphics cards.
And before you go on saying 'x' distro does it, or 'y' distro does it.. we don't always have the choice of all distros due to dependencies or legal reasons.
Linux is good, maybe even great, but it is not without its headaches. Personally I find Windows to be the most headache free OS. OS/X loses out in my mind because they have sacrificed a lot to make the UI basic and simple, and that is a matter of personal preference.
Laws are rules for the court, but merely a bottom bar to hit for life. Think beyond laws in your actions always.
I know that sounds like cynical marketroidism, but sometimes you do need to do that to wean people off some hideously ancient version they're still running on an old 386 under Netware 3.1 bricked into a wall next to the second floor men's toilet. "Last 3 major versions" sounds like a pretty generous strategy, we do "last n minor versions", where n is usually spread over 2-3 years. In other words unless you have a long-term support contract, if you come to us with a problem in a product written in the heyday of Windows XP, you're told to upgrade.
Here's the list, though a few are mis-filed (the arbitrary code execution from this year is actually in Flash, no idea why it appears here), but most of the privilege elevation ones from this year and most of the arbitrary code execution vulnerabilities are real (though several seem to be in Logitech HID drivers).
I am TheRaven on Soylent News
I'd like to interject for a moment. Sadly, the desktop is still extremely glitchy. Let me show some examples.
1) Notebookcheck a new Intel NUC. Intel HD Graphics 6000 was missing Linux support at the moment of writing. That's not the end of the world, but how does Linux Mint report about it? Nope, you don't get an informative "device not supported" message, nor does X.org fall back to a VESA mode. Instead you get corrupted graphics! Nice failure mode there. Just look at the screenshot in the article. Does that look professional to you?
2) When you install Linux, various manual hacks are needed to correct all sorts of little glitches here and there. Read the installation report of this guy. Does that seem familiar?
3) Laptop brightness adjustment still goes in multiple steps! I can't believe this bug is still around. The same issue is in Ubuntu in Mint and affects most laptops. Bug #527157. Just try pressing the brightness keys of your laptop under Linux and you see what I mean. An everyday feature like this should Just Work without me having to even think about it.
Conclusion: I need an desktop operating system that is more deterministic in behavior. I want robust and predictable user experience. This is not rock solid at all.
"Unfortunately the only technique I ever found (and I've forgotten what it was at this point) generated a text file listing *every* package installed on the machine"
Unfortunately I fail to see where's the problem.
"a list nigh guaranteed to bork a machine if I tried to import it all on a different OS version"
Not my experience.
Now, my experience:
1) Debian-based: I don't reinstall that often (now that I remember, my current setup goes in time about 10 years or maybe more).
2) Debian-based when cloning a machine: when it's been the same release, no problem at all. When the receptor is a different version (newer) I installed a minimal system and then applied the package list. It might fail on some package disappearing or changing names (usually only a few) and then it's a matter to see what failed and act accordingly. Worst case scenario, I had to extract a list of the (partial) setup on the new machine and diff old/new.
3) Red-Hat based: yes, they are not so great at upgrading in place so I had to resort to the trick in point two. It was a bit longer and required more than one iteration but far from a drama.
"And good luck sorting out the 10% of user software from the umpteen dozen pages of semi-cryptically named packages."
From time to time (I mean months or even years, here) I spend no more than an hour looking at the installed package list. I know what most of the packages do, for the minority I don't know, I read its description as provided by the package manager. If still no clue, I try to unistall it and see what reverse-dependencies are going to be unistalled, which always made clear what was happening. Not a big problem either.
Oh! by the way, a few seconds of google search showed me how to list manually installed packages both for debian-based and redhat-based systems so it seems your concern was not so much a problem even for you as to expend even a minute looking for a solution.
To run Windows desktop applications on the Linux kernel, you'll need to install the X Window System and the Wine application environment on top of it. (Most desktop-oriented distributions of GNU/Linux include both of these in their repositories.) Try running Windows desktop applications in Wine, and if they don't work, you can report the failure to both the application's publisher and the Wine team.
"In-place upgrades are one thing, and they're great until one goes belly-u"
As I already told, the machine I'm writing this from was originally installed about ten years ago and upgraded in place since then, despite of the fact that, by now, it shares not a single piece of the original hardware.
In fact, in the last almost 20 years (wow, time really goes by!) I don't remember having an in-place upgrade going so bad that I couldn't recover it, and I'm talking hundreds, probably thousands of machines even working remotely on a different continent in all these years.
I'm sure that all those systems being of the Debian Stable flavour has something to do with my sucess rate.
Yeah, what can be done about this? The current GNU/Linux alternatives still have a catch up time of at least a decade in this field. Pixel editing is okay, vector editing is one of the success stories as well as digital photo development. But video is way off...If only one of these major companies can get a port to work on GNU/Linux...unless we can crowdfund openshot or some similar ilk to close the gap...
"SO we bide our time, waiting for a purer kick to bloom and the future is still bleak, uncertain and beautiful" -GSYBE
So www.lwn.net has a better section dealing with the 4.0 kernel including what persistent memory and lazytime changes are. I would suggest going there.
http://www.lwn.net/
I like to find more information than the smattering that was a "detailed look". as they say.. NOT.
I can program myself out of a Hello World Contest!!
In practice Bash is part of most Linux installations.
Even in the realm of "GNU/Linux" not everybody uses bash (some use zsh, for exemple).
And that's only the portion of users running an actual "GNU" userland.
Then you have the embed world using Busybox (with uClib, etc.) and co for the userland (which has its own simplified shell).
And then you have Android (which runs a completely different user land by Google, like Bionic for a C library, a different message passing bus, and most of the things usually handled by deamon running in userland, handled by java-like code on a java-like VM).
And the other way arround: you have other Unice (OS X, various *BSD) which obviously do not run Linux kernel, but do run bash.
OS X, for example, was affected by bash.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
If the Wine team discovers that a particular application is relying on unspecified or undefined behaviors of a particular Windows function, behaviors that may break in a future version of Windows, then who is responsible?