Linux 4.2-rc1 Is One of the Largest Kernel Releases of Recent Times
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.
The same way it has always been done - unpack it, move into the directory, and use "make menuconfig" for a nice easy menu system to pick the parts that you want. If you really want to trim things down only compile in the options you need and remove loadable modules (useful in some setups).
I'm starting to think GNU is the problem with "GNU/Linux" these days.
"oldconfig" also works, if you've already done the menuconfig tango a couple of times.
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.
Just use an old kernel like everybody else.
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.
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!"
Everything in the Universe sucks: It's the law!
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.
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.
"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.
Just to pick a nit, unless you have a copy of make in the same directory as the kernel source, it's make meuconfig that you'd be running.
Good, inexpensive web hosting
... over FDDI.
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.
I'd use firefox as OS and chromium as browser
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion. -- Spazmania (174582)
The equivalent in the kernel is kdbus. Heard that the developers of kdbus are not listening to people as usual.
Does it still fit on a DVD?
“He’s not deformed, he’s just drunk!”
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.
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!
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.
Ce n'est pas une signature automatique.
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.
Sorry to hear that.
I hope our civilization will overcome this sad situation before going extinct.
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.
Shutting down free speech with violence isn't fighting fascism. It IS fascism!
Just to pick a nit, it's make menuconfig that you'd be running.
?
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 to critique every single options.
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.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
Sun was pissing away an enormous pile of cash. Oracle bought out Sun before the money ran out, so Sun did not go bankrupt.
Contribute to civilization: ari.aynrand.org/donate
It's lusers like you that make many developers bitter.
Contribute to civilization: ari.aynrand.org/donate
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 to have Systemd's features or be able to use them. Ironically its people like you who make the accusation that you are being put upon, when in fact Systemd has taken nothing away from you, it does not prevent you from starting your jobs just as you do now as it fully supports the older mechanisms and is backward compatible. The bottom line is if you dont like the new mechanisms, systemd lets you use the old ones.
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.
What didn't they listen to? AFAIK Linus will not merge kdbus if that where the case.
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.
...omphaloskepsis often...
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 exist. Systemd makes major policy decisions that are probably not going to get in the way of "most"1 people, but it definitely gets in the way. Oh, and who said anything about "SysV scripts"? You do know that "init" is only a tiny portion of systemd, right? Moist of the problem with systemd have absolutely nothing whatsoever to do with "starting jobs".
Of course, with all that crap about systemd being a modular design (it's not - modular doesn't refer to how many binaries it compiles into) - which is only part of the unix philosophy - and blatant falsehoods ("doesn't take away any feature"), you're clearly either as a troll, shill, or useful idiot. I normally wouldn't bother feeding such nonsense, but....
The main reason I'm replying is to point out that the serious reading comprehension issue: you seem to have:
No, that isn't what I said at all, and it say a lot about you systemd apparatchik that you have to lie and misrepresent anyone who criticizes systemd into being a "hater" trying to suppress anything ("not allowed"). That has never been the case.. If you had actually read my post, you might have noticed I specifically said that if systemd works better for you or is just nicier in some way, then use it. I'm glad you found software that works better for you. Maybe you culd you show your fellow Linux users some courtesy and refrain from making up lies and accusations about anybody that doesn't run systemd?
My main thesis wasn't even about system directly, and instead address the misconception that features (such as cgroups) were somehow unavailable without systemd (either today or in the past).
Ce n'est pas une signature automatique.
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?
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.
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.
I find it's faster to use GIT than download and unpack a whole new kernel.
By the same token kernel developers are free to keep rejecting kdbus if it doesn't meet their needs or expectations.
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.
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.
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?
It won't. The driver support won't be there
Because it sucks when you realize that you don't have enough USB ports to plug in the full variety of external hardware that you might want to use in the system, and that'd be a goofy requirement anyhow. Either you have to plug in all the hardware you want to support, or you're back to enabling hardware one piece at a time manually in the kernel configuration.
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 reasonable to assume that you *will* know what hardware is in your machine, that you'll do the research to figure it out, or at least that you'll discover it by trial and error.
It is pitch black. You are likely to be eaten by a grue.
386 is supported up to the 3.7 kernel, and the 3.8 kernel was widely announced (and designed) to break 386 support. I've got an ARM system with 128MB of RAM, and it runs GCC 4.2 just fine. I can't imagine that an X86 version would be *that* much heavier that it wouldn't run. Of course, if I try to compile large, modern projects (with output binaries in the hundreds of MB, sometimes), it goes to swap *really* darned fast, but what did you expect? If I'm compiling the size of project that will actually run in the amount of RAM available on the system, without swapping, it works just fine.
It is pitch black. You are likely to be eaten by a grue.
"Free" Linux is starting to sound pretty expensive.
Because a project thrives when it has users interested in it and (more importantly) using it. Projects that don't give users what they want, or which start doing things that users *don't* want will lose their mindshare to another project. Now, if it's just a case of developers scratching an itch and having users doesn't matter, then that's different, of course.
It is pitch black. You are likely to be eaten by a grue.
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 recompiling the kernel for each machine on which it will be used, every time it is installed or updated?
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.
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.
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?
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
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 follow if you refused to take the hint.
So disagreeing with you is "fuck you" to you? Seriously?
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.
And these policy decision are? And are they due to a clear clack of viable alternative mechanism? From what I understand systemD only has a small number of hard dependencies (even if you consider each module separately. , Smaller even that to old bare-bones init to multiuser