Slashdot Mirror
What Will Be in Linux 2.7?
Realistic_Dragon writes "The first discussion has been sighted on the Linux kernel mailing list to put together a feature list of things that should go into Linux 2.7 - including hotplug CPU & Ram support, network transparent sound and improvements to Netfilter to bring it up to the the level of OpenBSD's Packet Filter. And all this before most of us have started to run 2.6.0-preX, or even a 2.6 series stable release happening. Perhaps if you have a (sensible) idea now would be a good time to voice it, otherwise you will have to wait for 2.9 to get it included."
Ummmm... Wouldn't you fry the motherboard by swapping a CPU when the computer's on?
FreeBSD jails rock. Root access to your own logical partition which looks and smells just like a dedicated machine, with no overhead.
Virtual host providers can do it for free with FreeBSD, or with ~10% CPU load using User-Mode Linux.
Laugh at my Lisp and I keeell you.
I've been wanting this for a while - it's time for most of the drivers in the kernel to be split out. There's no reason why the kernel sources need to be as large as they are, and there's absolutely no reason why eg sound drivers and network cards can't be maintained independently with their own build process. Tying them to kernel releases means waiting until the next release for driver improvements, can bottleneck development, and leads to the 41M(!) tarball that is 2.6test7.
This would require setting up a decent build process for modules outside the kernel, but that's a good thing anyway. Have you tried to compile the nVidia drivers lately? It can be a pain if your kernel headers aren't quite right. If there were a decent external API and good support for building third party modules, this would also make it easier for manufacturers to supply independent drivers.
Furthermore, it is a boot process (userspace apps terminate), it just uses the linux kernel as the bootloader rather than something like grub.
More work on drivers for hardware with emphasis on making it easier to detect/install/manage your hardware.
It would be really nice if the kernel was more plug-and-playish (microsoft reference not intended).
It bothers me that the mixer doesn't have separate slides for each app volume. (I know the slides aren't kernel, but the tech behind them is). Since sound comes from many sources, it would be nice to be able to set the volume levels of each source. For example, I've got festival and xmms, (which for those who don't know, it's a speech synth, and music). festival is quiet, and xmms is loud. There is currently no way to make festival loud and xmms quiet.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
I believe the word you're looking for is mature, and immature on the Linux side. Take Linux's VM implementation, which has been scrapped and rewritten from scratch multiple times within 2.4 alone. Meanwhile the Solaris VM has been fine tuned over the past decade. Solaris's time share scheduler has been O(1) for well over half a decade, whereas Linux is just now getting an O(1) time share scheduler.
"Take a look at Sun's IP stack versus Linux's, for instance."
Care to tell me how Linux is superior? You seem to be only assuming it is, and leaving the burden of proof upon me. Sorry, I put it back on you.
But just for review of some networking features: Solaris has offered stateful I/O multiplexing through the /dev/poll mechanism as well as asynchronous I/O for years. These features are only now being implemented in Linux with things like epoll(), which you'll need a 2.6 kernel and userland support in glibc to use. It will be at least a year before we can begin to expect the average Linux system to support stateful I/O multiplexing through epoll().
Or how about lvm+softraid? When will Solaris stop relying on Veritas? (and don't answer diskuite, please).
Don't answer Solstice Disk Suite? Perhaps you forget that the LVM was modeled after the Sun Volume Manager (which later became SDS) Perhaps you'd have an argument if you were championing FreeBSD's vinum, which was modeled after the Veritas Volume Manager, however you're trying to champion a technology which mimics the Solaris implementation yet saying to discount that very implementation. Pathetic...
"Or how about good integrated netfilter-like code?"
Sorry, people aren't going to be using their $20,000 systems as routers for their cable modems.
"While we're on it, let's talk hardware. The price /performance ratios on UltraSparcs make Xeons look like a super bargain, not to mention Athlons.
Please show me a system with better price/performance than the V440: http://store.sun.com/catalog/doc/BrowsePage.jhtml? cid=104994&parentId=48589
Keep in mind that no one in their right mind is going to shell out $26,000 for a system without a warranty. The V440 comes with 3 years of parts and on-site labor.
I'd certainly like to see you configure an equivalent system (the 1.28GHz UltraSPARC IIIi is equivalent to a 1.8GHz Opteron) from a vendor that offers at least a year of parts and on-site labor.
"It's way past late for them to have closed up the Sparc shop and moved everything over to this cheaper commodity platform that can pump more mips or flops per dollar than Sun can. And how freaking long did it take them to adopt PCI?"
The earliest Sparc systems I know of supporting PCI were Ultra 5s, released in 1995, about the same time most PC systems were starting to feature PCI.
"Of course, now most of my Suns have 64/66 PCI busses, while my latest Intels are doing PCI-X..."
Unless you're talking about the Opteron, the scalability and throughput of x86 systems is severely limited by the interconnect used between CPUs. P4 Xeons essentially share the FSB between processors, greatly limiting the amount of bus bandwidth that can be simultaneously utilized by multiple processors. With the P4, keep in mind also that the P4 does not cache operations, only micro-ops in its trace cache, so whenever the trace cache becomes tainted (by, say, mispredicing a branch) the P4 must fall back on retrieving the original opcodes out of main memory, saturating the front side bus (this is why Intel has been aggressively stepping up the bus speed of the P4)
For use as a high performance server, Linux does not rival Solaris in