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"
support for the Cell processor
I guess the PS3 HDD with Linux was true...
Ryan - http://www.thecosmotron.com/
everyone get together and create 1 really good filesystem instead of 20 halfassed bugridden ones?
But just what in the hell is a 'High Resolution Timer'?
I thought the 2.6.x series of kernels was stable ? Shouldn't all of these new features being showing up in 2.7.... ?
They have changed things in favor of a faster development model. I believe now it is 2.6.X where when X is odd it is development (includes adding new features) and X is even it is release.
#!/
The problem is that Schilling wants linux to behave exactly like Solaris' incomprehensable s,b,l format even though Linux has to support more devices and refuses to even read patches that make things easier for Linux users. It's at the point that if cdrecord accidentally supports something that doesn't look like the solaris way Schilling will add code to disable it.
Combine that with the fact that the DVD tools from Schilling are no longer open source and requires a License key The project has been forked.
If your having trouble with cdrecord I'd suggest using the alternate version instead.
He wants something consistent, is all. Remember how towards the end of the 2.4 lifespan linux people were saying "ide-scsi is obsolete, move to the new ATAPI: method"? And then in a few months that was old and deprecated and it was all "move to the ATA: method"? And then it was changed around again around 2.6.9 for no discernible reason at all?
It's at the point that if cdrecord accidentally supports something that doesn't look like the solaris way Schilling will add code to disable it.
I haven't seen that. I have seen Linus adding code that looks to be there solely to break cdrecord.
Combine that with the fact that the DVD tools from Schilling are no longer open source and requires a License key The project has been forked.
It was forked before (dvdrtools), and will doubtless be forked again. The forks will die out once the maintainers realise that it's not Schilling being awkward, it's the kernel people. Last I knew, the fork you mention was depending on ide-scsi, which had a witch hunt against it towards the end of 2.4, was declared obsolete a few times as the latest poorly-thought-out replacement arose, and when this didn't get people to abandon it, was intentionally crippled around 2.6.9 or 2.6.10 time. Whoops. CD writing on linux is bloody hard - the only other project which has lasted any amount of time is cdrdao, and that uses Schilling's libscg for drive access. The sooner people stop their hero-worship of Linus, stop the persecution of Schilling, and start looking at the facts, the sooner something can be done.
I am trolling
I have a laptop with an ATI mobility (X600) chipset. I've consistently had issues compiling the ATI-provided drivers in various 2.6.x kernels, but I've heard from many that it should compile cleanly under 2.6.16. I'll try to update this post when I know more, as the kernel is currently compiling as I write, and the driver will soon (hopefully) follow.
And on that subject, what's so inherently difficult about writing CD recording software? FreeBSD comes with an IDE burning tool, burncd, that has worked perfectly every time I've used it. Is it harder to do the same under Linux, or does cdrecord include some advanced, hard-to-implement functionality that burncd skipped?
Dewey, what part of this looks like authorities should be involved?