Slashdot Mirror
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.
http://lkml.iu.edu/hypermail/l...
They held off for a release.
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.
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.
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.