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."
so we can play all our favorite programs and games.
What WON'T be in Linux 2.7?
Uhh, you mean like any SCO code?
Remove SCO from all future distributions. :^)
"It's the height of ridiculousness to say for those 9 lines you get hundreds of millions."
" Ummmm... Wouldn't you fry the motherboard by swapping a CPU when the computer's on?" Think Enterprise environment and Big Iron, not desktop machines.
Maybe we should start working on a way to re-load the kernel without rebooting. I don't know if it's practically possible, but it certainly would be neat!
Moderation: Put your hand inside the puppet head!
I believe they're referring to some mainframes, in which there are bays of CPUs/RAM that can be swapped in and out while the system is running.
CPU hotplug support is not designed for removing the processor from your single-CPU x86 box.
There is hardware that supports this for higher end servers. (With multiprocessor, AFAIK). Just another way to reduce downtime.
How about a userfriendly UI that'd let me configure everything without having to recompile eveything (or do it invisibly) just so that I can play and use without the pain and suffering that is require nowdays.
My main gripe with Linux has been that it's a bitch to configure for things that should't be so hard. Trying to get powermanagment to work on my IBM took me months and never worked right.
In Soviet Russia, the television watches YOU!
What Linux needs is some fatal errors. How about a screen of one solid color that comes on to warn you that all your work for the past hour is gone. You have to remember that Linux is competing with windows. If you can't beat them Join them. p.
Nope, you just have to do it REALLY fast...
And don't forget to lick all the Cheetos orange dust off your fingers before you start.
"Karma can only be portioned out by the cosmos." -Homer Simpson
is a scheduler on the same caliber as Solaris, so that the kernel can utilize multiple schedulers simultaneously. Linux currently ships with only a timeshare scheduler, but Solaris supports a number of different schedulers which can all operate simultaneously. Administrators can also move processes between different schedulers on the fly as well. A Fair Share Scheduler, for example, would be nice so that resources on large systems can be partitioned effectively as to prevent certain processes from monopolizing system resources. The CPU/RAM hotplug support would be nice... glad to see Linux trying to catch up to where Solaris was years ago. Just kidding :)
BSP/IP - "Bitch Slap Protocol/Internet Protocol" support - for remotely Bitch Slapping stupid users. An idea whose time has come(tm).
:)
Oh yeah, and add more SCO(tm) code - adding Evil(tm) to MS Windows(tm) sure didn't hurt the bottomline at MS(tm)!
Disclaimer: (tm), (r), and (c) wherever appropriate...
Note: BSP/IP is defensively patented by FlyByNite Industries, Inc., a wholly-owned subsidiary of Harkonnen Enterprises.
If the name of keeping up with the leader of the industry, I think we should integrate Mozilla. A web browser is an integral part of a modern OS.
-Pete
Soccer Goal Plans
http://www.scyld.com/products/beowulf/software/mon te.html
Already there.
--
# Canmephians for a better Linux Kernel
$Stalag99{"URL"}="http://stalag99.net";
Disipation of excess heat via copper clad water cooling through food preparation areas, and they implement it as a kernel flag for improved overclocking processor utilization, can we start to say "Yes, Linux does include the Kitchen Sink"?
You never know...
Linux Journal's May 2003 issue had an article from Rob Love about what's new in the 2.6 kernel (new VM, ALSA, improved IO subsystem, preemptive kernel) and with a few items: SCSI needs to be rewritten to make it smarter than the drivers, and the TTY code needs a rewrite -- "it's looking like to be hack."
--
# Canmephians for a better Linux Kernel
$Stalag99{"URL"}="http://stalag99.net";
What Will Be in Linux 2.7?
Plenty of SCO's intellectual property, duh!
Trolling is a art,
The beauty of Linux (IMO) is the ability to tweak the kernel. Why not take advantage of the fact that there is source code to be modified and make it simple for the average user to recompile the kernel? It's an ugly, ugly process right now and a lot of people are running distro kernels that aren't as optimized as they could be.
What if Digg added local news and a Slashdot inspired comment karma system? ---
http://houndwire.com
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.
Good 64 bit support was added in what, Linux 1.2 or so. Digital (remember them?) borrowed Linus a few Alpha boxes for the purpose. One can still find the occasional kinks in less used applications, but the kernel has been working fine on 64-bit computers for a good while.
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.
Currently even fairly advanced users can get hung up trying to get hardware to work. Windows has a huge advantage in this area even though you usually need a cd of drivers.
Even better would be a way to build a kernel that detects and includes support for your hardware automatically.
If you're compiling a large program, your motherboard and OS support hot-swap, and you add more RAM, then yes, the next GCC process to execute will see the extra RAM.
Removing RAM, on the other hand, would probably need a hardware switch on the motherboard that swaps everything in that bank to disk.
Will I retire or break 10K?
I can't wait to see the kiddies show off that feature! "The new kernel has CPU hotplug support, here, watch... oh CRAP."
the preceding comment is my own and in no way reflects the opinion of the Joint Chiefs of Staff
NFS used to be userspace and was slow as shit.
PHP is the solution of choice for relaying mysql errors to web users.
PLEASE include native support for SATA!!
"Ask not what your country can do for you." --John F. Kennedy
I would like to be able to share proc, mem, disk, and net resources across multiple machines (as is partially implemented in openMosix) AND run multiple instances of Linux on a single system (as in User-mode Linux). These two features combined would provide the ultimate solution in hardware resource flexibility and scalability in large server deployments. It looks like VMware Server provides similar functionality, but with cross-platform capabilities and at a cost of over $1500 per processor.
Damn straight. I'm a Gentoo man personally, but even portage is not a solution to this dependency hell problem. You should be able to download an RPM, double click it, and install a program without having to deal with solving dependencies manually. I really wish Linux would evolve beyond this trivial crap. It's the one thing that prevents me from recommending Linux to the average Joe (besides Gentoo's abysmal install process of course).
You're right, I wouldn't steal a car. But if it were possible, I sure as hell would download one!
I see a lot of entries about application level stuff (yeh I got a list there too. :-) But laptops still have a lot of variables connected to the kernel:
* APM / ACPI (still very hit & miss, and many vendors don't seem to follow the standard making it harder)
* docking station support (sometimes works, sometimes it freezes hard)
* hot swapping mice & keyboards (maybe 2.6 will make this better?)
* Function (FN) keys don't work (you know, the vendor function keys that get you the keypad; this may be an X thing but I've never seen them work even under the console)
Probably more, but that's a good start.
On the app side, better video drivers would be my #1 wish. Many of the ones we have now for laptops are so incomplete or problematic (generally because the driver writers are at a real disadvantage working without specs; they do a great job with what they have, but the result can be hard to live with...such a catch-22).
I wish there would be default stack protection, right out of the kernel. I'm tired of these repeated buffer overflows, and I know people can code right around them even with stack protection, but at least an attempt to make it harder for stack busting would be nice.
Gonzo Granzeau
"Nothing the god of biomechanics wouldn't let you into heaven for.." -Roy Batty
When useing multiple USB keyboards all keyboards can be accessed through /dev/input/keyboard, and input from all keyboards appears on the console. (unless you don't insmod kbdev.o, and instead use /dev/input/eventx, which disables the console unless you also have a PS/2 keyboard, as well as useing a decidedly non-console like api)
If instead there were /dev/input/keyboards optionally linked to the console, and /dev/input/keyboard0..n (like it is with USB mice), we could use multiple video cards and an appropriately modified X to build multi-seat workstations, POS terminals, etc without needing Xterminals.
PCI VGA ~$50 vs ~$500 /XTerminal
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).
2.6 already supports the Athlon-64, and GCC has architecture optimizations for it as well.
How did this get modded up?
Visit the
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.
...two big challenges: ... ... ...
1.
2.
3.
<insert cheap shot here> or perhaps you expect the Spanish Inquisition?
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
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'd really like to have an interface to the video system that is both fast and safe. At the moment, it's one or the other. Either I use straight X11 or I let the program bang on the hardware directly via DRI, SVGALib or the like.
I'd like to see video drivers in the kernel. Not necessarily full-featured OpenGL drivers, but something that:
Of these, #4 may not be possible to do safely, or may only be possible for some cards. If so, it would still be a win because a lot of applications will do fine with only the basic functionality and over time, as the bleeding-edge stuff becomes mundane, it will slowly trickle into the #3 category.
And here we go with the woefully mis-informed Solaris-advocacy again.
/etc/sysctl.conf. However, in Linux, all these control variables can also be set _without_ even rebooting. And this is the real riot: you can set plenty of control variables in Linux without a reboot which in Solaris REQUIRE a reboot. Just issue "sysctl -p", and the new values in your sysctl.conf will be effective immediately. It's a hell of a lot nicer (my opinion, of course) than having to fire up the kernel debugger (*shudder*) to change dynamic variables, like you have to do in Solaris. To give an example, in Solaris SysV Shared Memory parameters are not dynamic and can only be changed by editing /etc/system and then doing a reboot. In linux, these are tunable on the fly.
/etc/modules.conf will set your read-on-module-load-by-kernel control values. No recompiles needed here either.
/proc, except to say that /proc is a sometimes _useful_ mess sinnce it allows for tuning things on the fly that Solaris will only allow you to change with a reboot... like the abovementioned SysV shared memory settings.
> I can make changes in the running kernel (instead of rebooting).
What "changes" are you talking about here? Modules in linux can be loaded and unloaded without rebooting, and that most definitely is "making changes in a running kernel".
> I can set control variables for the kernel on future reboots (instead of recompiling the entire thing).
Ok, here's the thing that really irks me. Where do you people GET this idiocy from? Does SUN feed you this BS at courses or something? You can set control variables in Linux on future reboots. Just edit
And here follows more displays of fascinating ignorance/misinformation:
> Individual kernel modules can have their own read-on-module-load-by-the-kernel config file; in Linux the only general way of tweaking modules' control values is by editing the source.
No argument about the mess that is
No argument about devfs either. This most definitely IS something that solaris does better, and where Linux is catching up.
My own general impression from working with Linux and Solaris both, however, is that Solaris may be better in a few, small, specific areas mostly relating to really huge boxes, but that Linux stomps big time over Solaris in most areas, including areas where pure ignorance makes Solaris-advocates believe Solaris is superior.