Linux 4.2-rc1 Is One of the Largest Kernel Releases of Recent Times 110
An anonymous reader writes: Linus Torvalds ended the Linux 4.2 kernel merge window today by releasing Linux 4.2-rc1. He quickly wrote, "I thought this release would be one of the biggest ones ever, but it turns out that it will depend on how you count." By most metrics, Linux 4.2 is shaping up to be a very large release. Linux 4.2 is bringing plenty of new features including the new 'AMDGPU' kernel graphics driver, Intel Broxton support, NCQ TRIM improvements, F2FS file-system encryption, new ARM CPU/board support, Renesas R8/300 arch support, and many other additions.
Re: (Score:1)
Re: (Score:3, Funny)
The oldest commercially-built Linux kernel I have only has CDROM support for proprietary things like the Sound Blaster Pro and the old proprietary 1x Mitsumi CDROM drive. I guess I have Slackware floppy diskette images tucked away that are that old, too.
Those 0.99 builds are small kernels. They'd run on a 386sx motherboard with 2M of memory. I should put one in a box and see how it spins for old times sake.
It would be fun to see how it would scale to modern hardware, like, say, a Pentium 233 box.
Re: (Score:3, Funny)
If you think a 233 MHz Pentium is modern hardware just wait until you hear what kind of processing power they can put into mobile phones these days. It'll blow your mind!
Re: (Score:2)
It won't. The driver support won't be there
Re:Please please stop with the MONOLITH (Score:4, Informative)
Ubuntu Support plans? (Score:2)
While we're talking about monoliths, I don't usually build my Linuxes from scratch - I either use Ubuntu, or occasionally a Red Hat version, or sometime soon one of those cloud-vm-thingies. (I also run Raspberry Pi, but I don't expect it to have a full-sized kernel.) So when will Ubuntu start supporting the newer kernels? 15.10, or some updates to 15.04?
Re: (Score:2)
Sorry to hear that.
I hope our civilization will overcome this sad situation before going extinct.
Re: (Score:2)
Well yes, I suppose you are irony impaired. Or maybe the ACs who replied don't know the meaning of the word irony:
"noun: irony
the expression of one's meaning by using language that normally signifies the opposite, typically for humorous or emphatic effect."
Do you take that to mean that I believe 50% should be women? Can you not see the last sentence? Sorry you are so impaired. Maybe you should go back to Reddit.
kdbus, where are you? (Score:2, Interesting)
Still no kdbus, oy vey Jose. So what's it gonna take, three pretty, prancing blondes wearing sandwich boards and high heels marching in lock step in front of the White House? What do the sandwich boards say, you ask?
"The twenty-second century is screaming down the pipe and we've no KDBUS!"
"Hurry the fuck up with the KDBUS already!"
"Yo mamma needs her KDBUS too!"
Re:kdbus, where are you? (Score:4, Informative)
http://lkml.iu.edu/hypermail/l... [iu.edu]
They held off for a release.
Re: (Score:2)
Re: (Score:1, Informative)
Many trusted kernel hackers feel that kdbus -in its current incarnation- feel that kdbus does one or more of the following:
* Needs more work to meet the quality standards for such a major new system
* Doesn't actually solve a problem that needs solving (Analysis of benchmarks presented in the 4.1 kdbus merge request thread showing 2x speedup over userspace DBUS revealed trivially achievable 10x speedups in the code used by the benchmarking code. If it's "clear" that the 2x speedup by moving to kernelspace is
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
It's worse than that - not only is it not clear that it's actually required, I (and other [spinics.net]) want to know why they aren't just writing a simple userland library that uses TIPC [gentoo.org], which is already in the kernel. Even if there was some legitimate reason to need a kdbus-like feature that that wasn't already supported [gentoo.org] by TIPC, wouldn't it make a lot more sense to extend that existing, already debugged code and extend TIPC with the that feature?
Re: (Score:1)
Frankly, NIH syndrome is strong with folks who:
* Work on the Gnome project
* Work at RedHat
After all, it's "easier" to begin writing your own code than it is to understand someone else's crufty-but-complete solution to the same problem. (Not to mention which one looks better on a resume or end-of-year performance review!)
Re: (Score:2)
+1 clueful
mod up please
Hmm (Score:1)
Re: (Score:1)
Whoa! Cool! A kernel that does everything! (Score:1)
Does it still fit on a DVD?
Re:Kernel size and compile reduction (Score:4, Informative)
Re: (Score:1)
"oldconfig" also works, if you've already done the menuconfig tango a couple of times.
Re: (Score:1)
"If you really want to trim things down only compile in the options you need"
That might have been possibly by one person 10 years ago, but these days by the time you've finished setting up all the compile options manually you'll be ready to collect your pension. Assuming you hadn't died of boredom already.
Re: (Score:1)
?
I'm not by any means a Kernel guru, it took me 20 hours to trim down my kernel, removing any devices and features I didn't need and still have a bootable, problem free system. From about 1,5GB of drivers to 140MB.
I read the help for every option that I didn't understand completely, google helped with the rest that didn't have any help info or was too cryptic for me.
Granted, a fast system helps so you don't wait forever to compile, but it's far from a clusterfuck like you make it out to be. You don't need t
Boot drive size (Score:2)
This is what modules do for e.g. PCI devices. You can compile them all, and only the ones that are detected will get actually loaded.
Yet the unused modules in a generic kernel are still occupying space on the boot drive. For a smaller flash-based system, this can become significant. Even on an HDD-based system, more modules loaded before the file system comes up means more time to load the initial RAM disk.
The concept of generic kernels (Score:2)
Anything necessary to mount drives and any non-removable devices should be compiled into the kernel.
Which would make for a pretty big generic kernel if it has to handle every possible bus through which bootable storage can be accessed, and through which the decryption password can be entered, on every PC since the Pentium II.
For a smaller flash-based system
This kind of machine is more likely to be something purpose-built
I was sort of referring to tablets and tablet-laptops, which are likely to come with an internal SSD as small as 16 to 32 GB, or to bootable USB flash drives.
Just compile the drivers into the kernel, rather than producing any modules.
The drivers for which system? Or are you referring to abandoning the concept of a binary "generic kernel" in favor of recompili
Re: (Score:3, Insightful)
It sounds like the project you want [someone] to start, does this: reads a config file, looks at what modules ended up actually getting loaded, and then enables/disables config options, writes a new config file. Then your subsequent compiles can be faster and your /lib/modules can be smaller.
Re: (Score:2)
Basically, it's a neat concept, but it might not be practical, and if you're at the point where you want/need to compile your own kernel, then it's r
Re: (Score:2)
Oh only 20 hours, well thats alright them. I mean who doesn't have 20 hours spare to sit in front of a console typing Y/N/M a couple of thousand times?
Re: (Score:2)
I can do it in less than an hour but reserve that for machines that need special options (SCTP etc) or rare drivers not supported bu the distro kernels.
Re: Kernel size and compile reduction (Score:1)
Re: (Score:2)
I find it's faster to use GIT than download and unpack a whole new kernel.
Re: (Score:1)
Is the kernel configurable? Can one be reducing it through selective compile? How is one doing that?
Yippeeeee!!!!!!! I got first post!!!
How should a post that is both informative and trolling at the same time be modded?
I do not want to waste up my mod points either way on this one.
Re: (Score:1)
Since it's informative only in a really, really trivial way ( even *I* know about ./make menuconfig and I haven't built a linux kernel since about 1998) it can just be squelched.
Re: (Score:3)
Re: (Score:1)
Just to pick a nit, it's make menuconfig that you'd be running.
Re: (Score:1)
To clarify for those who don't know, "big" is referring to the amount of changes since the last release, and has nothing to do with the size of the kernel.
Re: (Score:1)
Still have support for that one asshole running an FDDI card on an EISA bus? Spend $20 already and buy a PCI replacement you cheap motherfucker. Whatever you're using it for is not that critical, seriously.
It's not about using FDDI card on a EISA bus .. it's about sending a message.
Re: (Score:2, Funny)
... over FDDI.
Re: (Score:2)
If that one asshole as you say it is an active kernel developer he has the right to include support for whatever the fuck he wants, that's the whole point of the Linux development model. As long as it is disabled at compile time, it won't affect you.
Re: Systemd (Score:3, Interesting)
"Systemd is causing massive bloat in Linux."
One of the main objectives of systemd is to take advantage of linux-specific features (such as cgroups) that existed before systemd did.
The servers I am building at present have a minimum of 256GB ram, I couldn't care about a few MB of "bloat", what I *do* care about is resource limits at various levels, which cgroups gives me and systemd makes useable but default.
if you were trolling, you're the worst systemd troll I've seen this year.
Re: (Score:2)
Re: Systemd (Score:5, Insightful)
What, exactly, are these linux-specific features that systemd supposedly makes available? You certainly don't need systemd to use cgroups, which were usable before systemd tried to monopolize the project.
"Usability" is personal opinion, and if you find systemd's management of cgroups management to be easier than the other options, than use it; we don't *have* to agree on such details, thanks to the flexibility of Free Software.. After all, the usability of a tool depends on what your particular goals and requirements.
So please,, stop spreading the misinformation and revisionist history that has is popular with many systemd advocates. Very few of the commonly stated benefits of systemd are new, and most were available - and in use - before systemd showed up.- it just became popular to ignore history and existing projects.
Oh, and iff you were trolling, then this is a sadly a typical example of systemd apparatchik: repeating popular misconception, arguments based on the projection of personal requirements and opinions, and quick to throw around moral accusations and insults. The person you were replying to may be a bit misguided and hyperbolic, they are not entirely wrong, either.
Re: (Score:2)
The fact is, systemd doesnt force anything on you. You are free to start your jobs from SysV scripts just as before. Systemd also follows a highly modular architecture and design that fits in with the Unix philosophy. So its not a big monolithic thing. So, I don't see what the problem is. Systemd is fine by me and I see no issue as it only adds additional capability rather than takes them away. Since it does not take away any features, basically what you are arguing for is that people should not be allowed
Re: (Score:2)
Systemd doesn't force anything on me because I don't use it, and have a much more stable system because of it. If I werre to run systemd, it *absolutely does* force an increasing number of policy decisions and questionable quality code on me.
This is what I meant when I said about how apparatchik tend to their personal requirements and opinions on to others. You are making a failure of induction, by assuming that just because you haven't personally seen any problems with systemd,, those problems must not exi
Re: (Score:2)
Re: Systemd (Score:1)
The equivalent in the kernel is kdbus. Heard that the developers of kdbus are not listening to people as usual.
Re: Systemd (Score:4, Insightful)
The equivalent in the kernel is kdbus. Heard that the developers of kdbus are not listening to people as usual.
Well the point of free software is to do things you need and contribute that back so other people can use it, do things out of charity or get paid by people to do those things. If those "people" want to pay the kdbus developers to do what they want then fine but outside of that there's no real need or reason they would listen to what other people want them to do.
Re: (Score:2, Insightful)
Re: (Score:2)
Re: (Score:2)
But it's not work. The developers are free to listen to you, and they're also free to ignore you. You aren't their boss. Refusing to treat you like you were isn't "fuck you". You just took it that way because getting rejected is humiliating and you didn't want to admit you misunderstood the situation.
Re: (Score:2)
Neither is appropriate for when people refuse to care about your orders because you don't have any authority over them. You aren't paying so you aren't in any position to demand features, or anything else.
It's not "you're not my boss, fuck you" but "you're not my boss, so stop giving me orders". Altough I suppose "fuck you" could very quickly
Re: (Score:2)
See, arguments like this are precisely why people like me quit contributing to open source projects a long time ago. It's just the "fuck you" attitude that gets to us. When users demand features, you are supposed to listen. But nope, this stock answer is trotted out every time as a way to avoid doing work.
No that's absolute rubbish! Just because you release code as open source doesn't mean you then have an obligation to do whatever the users of that code demand of you.
Re: (Score:3)
Re: (Score:2)
By the same token kernel developers are free to keep rejecting kdbus if it doesn't meet their needs or expectations.
Yes, of course. And distro maintainers and users are free to keep rejecting systemd if they don't like it.
Re: (Score:2)
Re: (Score:2)
That is not the same thing as "the developers are not listening to people", it's simply the open questions from the code reviewers that needs to be addressed if kdbus will have a chance of being included. I.e business as usual.
And of course the devs are hell-bent to get it included, when was the last time that you wrote kernel code without caring if it would be included or not?
Re: (Score:3)
Can anyone be telling reasons for staying with Linux?
Nope, none what so ever. Please install windows and resign from every online discussion about Linux for every. Don't even bother looking at Linux again. We have nothing here for you.
Re: (Score:2)