Slashdot Mirror
Linux 2.6.16 released
diegocgteleline.es writes "Linux 2.6.16 has been released after two months and two weeks of development. You can check the comprehensible changelog (text mirror of the site). The new features include OCFS2, a clustering filesystem contributed by Oracle, new unshare(), pselect()/ppoll() and *at() system calls, support the moving of the physical location of pages between nodes in NUMA systems, support for the Cell processor, cpufreq support for G5s plus thermal control for dualcore G5s, improved power management support for many devices and subsystems (libata, alsa...), a new mutex locking primitive, high-resolution timers, per-mountpoint noatime/nodiratime, 64-to-32-bit ioctl compatibility for the v4l2 subsystem, IPv6 support for DCCP, the TIPC protocol (Transparent Inter Process Communication, ACL support for CIFS filesystem, HFSX filesystem support, new configfs filesystem (which complements sysfs, not replaces it), support for running executables from v9fs (plan9 9P distributed filesystem), support for many new devices, improved support for others and lots of other changes. Check it out from kernel.org"
Yes, there are bugs in previous versions. These bugs were found with coverity and resolved in 2.6.16.
Actually, the usage is correct in this case. The full changelog has nothing but single fix entries which hardly give a good picture of what was actually changed in the kernel. A comprehensible changelog gives an overview of the changes rather than a patch-by-patch listing. Therefore, it is more comprehensible for someone outside of kernel development.
Keep in mind that Sony is a Linux supporter. In the past, they've released Playstation dev kits that are based on the Linux Operating System. (requisite Wikipedia link) I don't see any reason why they'd stop the program, especially if the professional devs were also finding the technology useful.
Javascript + Nintendo DSi = DSiCade
All this provided, the new one doesn't fuck up your system, which I highly doubt will be the case.
for the last time people, I am "frodo from middle eaRTH", not "middle eaST".
Any point in me upgrading the kernel from 2.6.14?
1. Read the changelog. Do you see anything in there that applies to you (new features, bugs that you have encountered that are now fixed, or serious security updates)?
2. Do you have any stability issues with 2.6.14?
3. Are you really that concerned with upgrading your kernel again? It's not a status symbol afterall.
4. I'm still running 2.4.x because I have no need to run 2.6.x (I use it strictly as a console machine) Linux supplication 2.4.32 #4 Tue Jan 3 18:35:16 CST 2006 i686 GNU/Linux
When Slackware 11.0 comes out, it'll use the 2.6 kernel as default. It looks like Pat is still keeping 2.4 support built in, so it's similar to what 10.2 is - built for 2.4, but contains full support for 2.6. Now it's built for 2.6 but still supports 2.4, in case your hardware really requires it.
Death by snoo-snoo!
I would like to know other peoples experiences with upgrades on 2.6.x. BTW, I run the debian testing kernels and the hotplug to udev switch has given me problems as well.
I guess the PS3 HDD with Linux was true...r y/pa-expert4/
Not necessarily. AFAIK, IBM and friends have had Linux running on a cell for some time. And they plan on selling cell-based machines outside of the PS3. A quick google leads to this page : http://www-128.ibm.com/developerworks/power/libra
I'll do it for cheesy poofs.
Broken I guess in terms of "doing the right thing",
..
m l
but I have burned with cdrecord on 2.6.13 like this:
$ cdrecord dev=ATA -scanbus
$ cdrecord dev=ATA:1,0,0
see this discussion:
http://community.livejournal.com/debian/186598.ht
Give Gentoo a try. You can keep a stable kernel and experiment with a number of new ones. Slackware is hopelessly outdated.
an ill wind that blows no good
But just what in the hell is a 'High Resolution Timer'?
A "timer" is a software or hardware device that keeps track of how many time increments have passed. The "resolution" of the timer is how small the increments are. Thus a timer that tracks the number of milliseconds (1000 increments per second) wouldn't be of a particularly high resolution, a timer that tracks nanosecond increments (1,000,000 increments per second) would be.
The purpose of high resolution timers is to provide better performance through more accurate digital timing. Take a serial port as an example. At 9600 baud, the timer it uses will "tick" about 9,600 times per second. The computers on each side align with these ticks to know that there's new data on the line. Assuming that the electronics can handle it in a stable fashion, the speed of that connection can be increased by changing the timer used for the port. On many serial ports, this speed can be over 100,000 baud, or 100,000 ticks per second.
Modern USB ports can easily require timing in the nanosecond range to produce a high speed signal. Thus the need for high resolution timers capable of producing the necessary signal. Many other uses (such as video signal synchronization) exist.
Javascript + Nintendo DSi = DSiCade
No goddamit, NO! I find it really surprising that people STILL get this wrong! 2.6.15 is considered just as stable as 2.6.16 is. Hell, if you even bothered to read the summary of this discussion, you would see that they added several new features to this version!
The closest thing to a "developement-version" is the -mm-tree, where new stuff is tried out before being added to the Linus-tree. Then we have the STABLE-trees (like 2.6.15.2).
It used to be that odd-numbered kernels (2.x.y, where X is odd or even) were developement-kernel (like 2.3.0), while even-numbered kernels were stable ones (like 2.4.0). But that system is NOT used with the 2.6-series in any shape or form!
Lesbian Nazi Hookers Abducted by UFOs and Forced Into Weight Loss Programs - -all next week on Town Talk.
Bah, hit submit too soon on my previous reply:
A high resolution timer is very useful when asking a question such as:
How far apart (in time) were these two 10 Gbps ethernet packets?
With the old, low resolution, timers, you got one of two answers typically: 0 ms or 1 ms. And when it said 1ms, it was actually probably closer to 0 ms, the clock just happened to roll over. The 'real' answer was probably 0.000000030 seconds, and that happened to be enough to make the clock trip into the next millisecond.
With a higher resolution timer, the above scenario might tell you that those 2 packets were 30 nanosecs apart.
This can be rather useful for assorted predictive algorithms, and pretty much any code that needs to measure the passage of time while operating in the greater than 1000 operations per second range.
"Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
Whoops. I can't count today. (Hey, it's a monday. :-P)
:)
Nanosecond == 1E-9 == 1,000,000,000/sec
Microsecond == 1E-6 == 1,000,000/sec
Thanks for pointing that out.
Javascript + Nintendo DSi = DSiCade
In order to install them you must use a patch here, or they won't work.
~ Jim
It depends really.
Lately, the kernel has put lots of improvements for desktop frameworks.
For example, 2.6.15 put forth uevent for managing devices. Wich the latest udev needs.
Udev keeps being more and more powerful, and latest hal takes advantage of it, and DE like Gnome and KDE also take advantage of this.
For the desktop, power management (and suspend) is the reason to go 2.6.16.
Most distros still don't use these features, but I already do, and some tools already use even the 2.6.16 features (no kidding).
That means you don't have to go 2.6.16 now, but eventually, distro will have to install it if they want to upgrade their desktop features on Linux.
The kernel and all the Utopia framework that goes with it.
Udev is still moving fast, some distro are stuck at udev 036. We are already at udev 087 (unusable on anything below linux 2.6.15) !!
I would go on about how reiser4's plugin system makes it much easier for people to contribute their own small parts to the filesystem and means we could have the best of everything if only the bloody kernel devs would accept it, but that's a rant for another day.
I am trolling
I believe you have confused "timer" with "timestamp". All you need for your example is a high resolution time *stamp*. The kernel has had usec accurate timestamps for ages now, and each architecture generally has a way to get better than that (although it's not generically available across the whole kernel).
High resolutions timers are a different thing all together. They're what you would use if you had some code that you wanted to run 100usec from now, but you wanted to give up the cpu in the meantime.
You are using an unstable release of the kernel. Linus had made sevral lenghty posts addressing this and has made it abundantly clear that 2.6 is not stable and it will be under development.
Quick and dirty: the kernel.org kernels aren't "stable" like you're wanting. Get a kernel from your distro if you want a stable kernel. If you want bleeding edge stuff (they call it bleeding edge for a reason), then be prepared for those kinds of problems.
My blog. Good stuff (when I remember to update it). Read it.
As noted above, the cdrecord code has been forked. This forked version of the code is now called dvdrecord. They dropped Joerg's artificial bullshit errors about linux, enabled the dvd code, and fixed up the build to use standard tools.
In the USA, we like stuff watered down, like beer, television, and freedom.
Yes, it does. K3b is an excellent frontend to cdrecord. Of course, you still have to have cdrecord properly installed and working in order to use it.
Dewey, what part of this looks like authorities should be involved?
My K3B uses cdrdao or growisofs as required. No cdrecord here...
Oh my. The CPU is not anywhere near fast enough to handle that. USB chips are fed with linked lists of packets. The chip follows the list and sends out the data, using a timer built-in to the USB chip.
Reception is typically similar. Both transmit and receive are in fact similar to Ethernet or SCSI.
We do bit-bang I2C busses (in video cards, RAM chips, temperature sensors, fan RPM sensors...) and various automotive and factory automation busses. These busses are way slower than USB.