You realize that both of these are implementations of X11R6, a standard which hasn't changed in a non-backwards-compatible manner in something like a decade, right? This means jack shit to the average person compiling apps "against the new X", since both provide an implementation of Xlib. (Not only an implementation, but the same implementation!)
This is roughly equivalent to worrying if plain vanilla POSIX programs will compile against newlib instead of glibc. There's absolutely nothing to see here. The only possible problem is drivers maintained out-of-tree for whatever reason, but that probably won't become an issue for some time since X11R6.7 is almost exactly XFree86 4.4.0.
It's funny that you mention that, since one of the tests that Andrew Morton ran to see what AS was improving, and how much, was to time how long it took to get a login on a machine that was doing large streaming writes. Generally, 2.4 sucked a lot, and AS went somewhat faster than 2.5 deadline.
AS favors read throughput over write throughput, which will generally be perceived as an increase in responsiveness... for some tasks during certain workloads, like this one, of course.
Actually, one of the big thing about as is that reads are favored above writes. Streaming writes in the presence of reads are generally somewhat slower (up to 30% slowdown has been noted in some cases), but small reads in the presence of streaming writes can be insanely faster.
Doing some googling, I've read that RAID setups and disks with deep TCQ won't benefit much at all from AS.
For your concrete examples, do a google for:anticipatory deadline scheduler: and you'll come up with the Kerneltrap article on Andrew Morton running various benchmarks. The 1000% speedup came in a workload that isn't much like a desktop workload at all (effect of streaming write on many small reads), so it's no surprise that you're not experiencing an 11x speedup on day-to-day apps.
As for the article, it also manages to get Stephen Tweedie's name wrong. For future reference, Yahoo! News articles about Linux (the kernel) probably won't be that great -_^
Nothing to do with "new make parameters"
on
Linux 2.6.5 is Released
·
· Score: 3, Informative
Hrm, looks like you meant to post that with "Plain Old Text" formatting...:/
Anyway, make install can depend on the contents of/sbin/installkernel, which is distribution-specific. Everything's compiling, but installkernel is trying to make an initrd that contains the ata_piix module, which you didn't build as a module (either you built it into the kernel or aren't using it at all). So, either fix your installkernel settings (check docs on how to do that), or build ata_piix as a module. (Basically, this is a configuration error -_^ )
This has nothing to do with "new make parameters".
It looks like the laptop mode patch is in Andrew Morton's -mm patch series. Since -mm has the leading edge of six different maintainer trees for merging with Linus, and contains lots of other general fixes, running -mm may not be a bad idea, since fixes often appear in -mm before they do in mainline. (Of course, sometimes things break in -mm that aren't broken yet in mainline too... )
Actually, the "Uhh... " is because it took me a minute to think about it and respond, and I type almost exactly the way I'd speak in real life ^_^; (Well, minus silly emoticons, obviously.) Also, I'm not a kernel hacker. Come to think of it, I have no idea where I picked up that version.h was generated...
(Yes, it makes more sense in IMs or IRC, but it's a years-old habit that's not going to go away because someone on Slashdot thinks I'm an ass... )
Perhaps; not all projects follow the "Release xx is the same as xx-rclast" release schedule, though.
Linus gets a lot of his patches from other maintainers, like Andrew Morton and Benjamin Herrenschmidt, who have their own kernel trees which get lots of testing.
Uhh, version.h is a generated file. It'll get rebuilt if you (e.g.) make menuconfig. (Actually, 'make prepare0' will work, as will... well, 'make include/linux/version.h' ^_^ )
If you're having problems, please read capture any oops output the kernel gives and submit a bug report. Kernel developers won't know about problems you have on your hardware if you don't tell them:3 Reporting bugs is as important as actually writing the drivers.
(I, for one, use snd-pcm-oss with gstreamer all the time without issues, so the ALSA people would definitely be interested in a bug report from you. No clue about the ieee1394 issues; obviously it works for someone, though, or it wouldn't have been released without being marked EXPERIMENTAL.)
I see you, sir-or-madam, haven't read any of the previous 2.6 stories:3
davej has a nice list of big changes in the 2.6 series that's commonly referred to as the post Halloween document that you may be interested in looking at.
The big change for users is to install module-init-tools, which is packaged in debian. (I don't recall if it's made its way to stable, though.) In any case, have a read through that document.
It's only a problem because people post the damn thing to Slashdot, really. I mean, all these people already get spam because they post to LKML, so having the slight added exposure in the Changelog probably really isn't a big deal compared to that.
(Actually, the last time I posted to LKML, I didn't get spam, so the stated problem may be even less than you might think.)
Yes, but pretty much everyone builds everything builds with -O2 and perhaps a few other sundry flags. Compared to that, -mtune optimizations will have basically negligible effect 99% of the time. So, I don't really find this argument compelling. At all. (Well, not "at all"... for some workloads, this is really important. But not for most people, not for most apps.)
Any sane distributor these days builds binary package with reasonable optimizations that won't break across architecture submodels, and occasionally releases binaries targetting submodels (e.g. PentiumPro-specific packages). On many machines, for many workloads, however, the model-specific optimizations just aren't that helpful. Obvious exceptions are floating point math on most platforms (especially x86, where x87 math code is a dog and should be replaced with SSE code if possible) and - I'm told - really slow hardware. (I'll be able to test that once I get these Indys running GNU/Linux.) In my experience, Debian hasn't really felt any slower than my LFS systems for personal use.
So, I'll say this: if you have enough time to build everything you're using, do some careful speed comparisons between your self-built packages and the vendor's binaries. If there's really a significant speed increase, and you need that increase, source is the only way to go for the packages that need the speed increase. Otherwise, it's probably not worth your time.
Unless whatever you're doing is extremely security critical, you can probably deal with the fact that server app foo has features bar and baz installed that you won't use. If you can't, you're probably auditing the source of everything you use anyway, and that doesn't sound like the case, so "control" probably isn't a real issue here either. Control can be found in config files as well as in the configure script.
People say, "but package dependencies suck!" Well, yes, rpm (the program) isn't built to deal with dependencies that gracefully. If it annoys you that much, go install apt-rpm or something, or even Debian (gods forbid). Package management isn't rocket science.
If you're responsible for the machines you run how can you abdicate that responsibility by using whatever some package maintainer decides to give you?
While in principle I can agree with what you're saying, this is a pretty insulting view to take of all the people who work on GNU/Linux distributions. (Or put another way, how am I better than every Debian developer combined? (Substituting Debian for your distribution of choice, of course.))
Eh. The one I found appeared to be a valid bug that's been about half-fixed; some sort of mailing list search feature that doesn't work consistently. It's been followed up to several times, but the commit that seemed to fix most of it seems to be late 2003 vintage for a bug that was submitted in late 2001.
Granted, it's not a malicious-code-exploit bug, and it's not all that serious... but like I said, I spent two minutes looking ^^; (Not that I'd expect to find tons of stuff on the order of the reports linked to in my parent, but I think debunking something like this is best achieved by focusing on other bits of the report first.)
On the other hand, if parent had said something like "sitting on bugs for months without saying anything", I'd have probably agreed fully.
No, you just showed me to watch what I say more closely:P Yes, I know it's basically impossible to write non-trivial bug free software, and generally impossible to verify that software is bug-free. I should have said... well, something else, like "relatively bug free" or "software that doesn't eat your pets and terrorize your in-laws". This is just a case of ENOCOFFEE -> stupid things getting said, my bad.
While I agree that the power of choice (and the power of change) that free software gives us is a great thing - hell, I've used it a bunch myself, from reporting bugs to making changes - it's just not useful for everyone. Not everyone is a programmer, and with the software market downsizing (or so they say) and less undergrads enrolling in CS programs, not all corporations are going to be able to hire someone to smash bugs for them. That's just the shakes.
It's like the power to maintain your car. If - and I realize this isn't a realistic situation, but analogies suck - you don't know how to take apart an engine, and no-one you know knows how to do so, and there are no mechanics in town, and your engine breaks, you're just as screwed as if the hood was welded shut and the car magically stopped working. While I believe very strongly in the freedoms guaranteed by (e.g.) GPLv2, I also don't think it's a panacea.
However, I stand by my original point - there's not much point in bashing Microsoft for having long-standing bugs. We on the free side of the fence are generally much better about it than they are, but neither are we spotless.
Man, you know, the funny thing is that the one thing you pick on them for is true. Yes, even GPL'd software can have unresolved bugs sitting for months. Hell, go to the OO.o bug tracker and you can find entries from 2002 if you look for two minutes.
This isn't to pick on OO.o - writing bug-free software is manageable, but not necessarily easy, especially for something that big. But no, Microsoft isn't the only one who leaves bugs unresolved for months. If you're going to debunk this, I'd start somewhere else.
Oooh. This was made into a 4-episode OVA in 1993 (which got shown as a movie on the Sci-Fi channel, back when they had Saturday Anime... which I remember seeing, and it kicked all sorts of ass when I was 13 ^_^; ), and was originally a 35-episode TV series which started in 1973.
The general plot is the usual mysterious-fighter-saves-world-from-robot-army, with twists.
it will be interesting to see this done, if only just to see how well they pull it off.
Um, normal desktop users will probably never upgrade their kernel, much less across major versions, short of the equivalent of an operating system upgrade. Honestly, how many patches to ntkernel.dll do you see in service packs? (Serious question, I don't use Windows.)
People who are having trouble upgrading to the 2.6 series from 2.4 are generally people who are doing it all on their own because the distros haven't all started doing it yet. Many of them have run into common problems that are explained in FAQs ("Why is my screen blank and the keyboard does nothing?", "Why don't my modules work?", etc.). Some of them are valid regressions. Some are because the technologies underlying tools have changed (I believe dm is an example of this). Most of these problems are things best solved by the distributions, which provide the functional equivalent of service packs.
So, no, I don't think this is really a big problem for Linux, since most Windows users wouldn't go download binary patches to system files and apply them by hand. They'd use Windows Update. Similarly, non-tech-savvy Linux users can wait until distributions ship 2.6.
(As far as cohesiveness of Linux, yeah, I agree. That's why I'm really waiting to see what comes out of the D-BUS and HAL projects.)
Ah, I didn't know about mingw. Well, that's too bad.
As a point of curiosity, what if that installer shipped the arch binary and cygwin.dll, but just didn't tell you? That's really all arch needs. Since all you'd have to do is ship the binary, install it in (say) C:\tla, and put the Cygwin DLL also in C:\tla, if an installer did that for you, would that be enough?
(tla works fine for non-distributed Open Source projects too, speaking from experience... ^^; )
The biggest downside to arch is user interface and documentation. I hate to say it, but it's true. Obscure error messages is one of arch's biggest problems, and command names and syntax are sometimes not consistent. Focus thus far has been on functionality; user interface cleanups will probably start in earnest after GNU Arch 1.2 is released, which shouldn't be too far off.
There is, however, a fairly decent Arch tutorial called "arch meets Hello World", and if you like wikis, there is a more or less official GNU Arch wiki. (Even if you don't like wikis, there's good information here.) Each tla command will give you short usage if you specify --help as an option, and more info if you give -H.
Slashdot Mirror
You realize that both of these are implementations of X11R6, a standard which hasn't changed in a non-backwards-compatible manner in something like a decade, right? This means jack shit to the average person compiling apps "against the new X", since both provide an implementation of Xlib. (Not only an implementation, but the same implementation!)
This is roughly equivalent to worrying if plain vanilla POSIX programs will compile against newlib instead of glibc. There's absolutely nothing to see here. The only possible problem is drivers maintained out-of-tree for whatever reason, but that probably won't become an issue for some time since X11R6.7 is almost exactly XFree86 4.4.0.
It's funny that you mention that, since one of the tests that Andrew Morton ran to see what AS was improving, and how much, was to time how long it took to get a login on a machine that was doing large streaming writes. Generally, 2.4 sucked a lot, and AS went somewhat faster than 2.5 deadline.
... for some tasks during certain workloads, like this one, of course.
AS favors read throughput over write throughput, which will generally be perceived as an increase in responsiveness
Actually, one of the big thing about as is that reads are favored above writes. Streaming writes in the presence of reads are generally somewhat slower (up to 30% slowdown has been noted in some cases), but small reads in the presence of streaming writes can be insanely faster.
Doing some googling, I've read that RAID setups and disks with deep TCQ won't benefit much at all from AS.
For your concrete examples, do a google for :anticipatory deadline scheduler: and you'll come up with the Kerneltrap article on Andrew Morton running various benchmarks. The 1000% speedup came in a workload that isn't much like a desktop workload at all (effect of streaming write on many small reads), so it's no surprise that you're not experiencing an 11x speedup on day-to-day apps.
As for the article, it also manages to get Stephen Tweedie's name wrong. For future reference, Yahoo! News articles about Linux (the kernel) probably won't be that great -_^
Hrm, looks like you meant to post that with "Plain Old Text" formatting ... :/
/sbin/installkernel, which is distribution-specific. Everything's compiling, but installkernel is trying to make an initrd that contains the ata_piix module, which you didn't build as a module (either you built it into the kernel or aren't using it at all). So, either fix your installkernel settings (check docs on how to do that), or build ata_piix as a module. (Basically, this is a configuration error -_^ )
Anyway, make install can depend on the contents of
This has nothing to do with "new make parameters".
It looks like the laptop mode patch is in Andrew Morton's -mm patch series. Since -mm has the leading edge of six different maintainer trees for merging with Linus, and contains lots of other general fixes, running -mm may not be a bad idea, since fixes often appear in -mm before they do in mainline. (Of course, sometimes things break in -mm that aren't broken yet in mainline too ... )
Actually, the "Uhh ... " is because it took me a minute to think about it and respond, and I type almost exactly the way I'd speak in real life ^_^; (Well, minus silly emoticons, obviously.) Also, I'm not a kernel hacker. Come to think of it, I have no idea where I picked up that version.h was generated ...
... )
(Yes, it makes more sense in IMs or IRC, but it's a years-old habit that's not going to go away because someone on Slashdot thinks I'm an ass
Perhaps; not all projects follow the "Release xx is the same as xx-rclast" release schedule, though.
Linus gets a lot of his patches from other maintainers, like Andrew Morton and Benjamin Herrenschmidt, who have their own kernel trees which get lots of testing.
Uhh, version.h is a generated file. It'll get rebuilt if you (e.g.) make menuconfig. (Actually, 'make prepare0' will work, as will ... well, 'make include/linux/version.h' ^_^ )
If you're having problems, please read capture any oops output the kernel gives and submit a bug report. Kernel developers won't know about problems you have on your hardware if you don't tell them :3 Reporting bugs is as important as actually writing the drivers.
(I, for one, use snd-pcm-oss with gstreamer all the time without issues, so the ALSA people would definitely be interested in a bug report from you. No clue about the ieee1394 issues; obviously it works for someone, though, or it wouldn't have been released without being marked EXPERIMENTAL.)
I see you, sir-or-madam, haven't read any of the previous 2.6 stories :3
davej has a nice list of big changes in the 2.6 series that's commonly referred to as the post Halloween document that you may be interested in looking at.
The big change for users is to install module-init-tools, which is packaged in debian. (I don't recall if it's made its way to stable, though.) In any case, have a read through that document.
Linus' announcement on LKML has a "Summary of changes from v2.6.5-rc3 to v2.6.5", so no, this is not the same as -rc3.
It's only a problem because people post the damn thing to Slashdot, really. I mean, all these people already get spam because they post to LKML, so having the slight added exposure in the Changelog probably really isn't a big deal compared to that.
(Actually, the last time I posted to LKML, I didn't get spam, so the stated problem may be even less than you might think.)
Yes, but pretty much everyone builds everything builds with -O2 and perhaps a few other sundry flags. Compared to that, -mtune optimizations will have basically negligible effect 99% of the time. So, I don't really find this argument compelling. At all. (Well, not "at all" ... for some workloads, this is really important. But not for most people, not for most apps.)
Optimization? Control?
Man, what is this, Gentoo?
Any sane distributor these days builds binary package with reasonable optimizations that won't break across architecture submodels, and occasionally releases binaries targetting submodels (e.g. PentiumPro-specific packages). On many machines, for many workloads, however, the model-specific optimizations just aren't that helpful. Obvious exceptions are floating point math on most platforms (especially x86, where x87 math code is a dog and should be replaced with SSE code if possible) and - I'm told - really slow hardware. (I'll be able to test that once I get these Indys running GNU/Linux.) In my experience, Debian hasn't really felt any slower than my LFS systems for personal use.
So, I'll say this: if you have enough time to build everything you're using, do some careful speed comparisons between your self-built packages and the vendor's binaries. If there's really a significant speed increase, and you need that increase, source is the only way to go for the packages that need the speed increase. Otherwise, it's probably not worth your time.
Unless whatever you're doing is extremely security critical, you can probably deal with the fact that server app foo has features bar and baz installed that you won't use. If you can't, you're probably auditing the source of everything you use anyway, and that doesn't sound like the case, so "control" probably isn't a real issue here either. Control can be found in config files as well as in the configure script.
People say, "but package dependencies suck!" Well, yes, rpm (the program) isn't built to deal with dependencies that gracefully. If it annoys you that much, go install apt-rpm or something, or even Debian (gods forbid). Package management isn't rocket science.
If you're responsible for the machines you run how can you abdicate that responsibility by using whatever some package maintainer decides to give you?
While in principle I can agree with what you're saying, this is a pretty insulting view to take of all the people who work on GNU/Linux distributions. (Or put another way, how am I better than every Debian developer combined? (Substituting Debian for your distribution of choice, of course.))
Eh. The one I found appeared to be a valid bug that's been about half-fixed; some sort of mailing list search feature that doesn't work consistently. It's been followed up to several times, but the commit that seemed to fix most of it seems to be late 2003 vintage for a bug that was submitted in late 2001.
... but like I said, I spent two minutes looking ^^; (Not that I'd expect to find tons of stuff on the order of the reports linked to in my parent, but I think debunking something like this is best achieved by focusing on other bits of the report first.)
Granted, it's not a malicious-code-exploit bug, and it's not all that serious
On the other hand, if parent had said something like "sitting on bugs for months without saying anything", I'd have probably agreed fully.
Oh, you just admitted you aren't a programmer.
:P Yes, I know it's basically impossible to write non-trivial bug free software, and generally impossible to verify that software is bug-free. I should have said ... well, something else, like "relatively bug free" or "software that doesn't eat your pets and terrorize your in-laws". This is just a case of ENOCOFFEE -> stupid things getting said, my bad.
No, you just showed me to watch what I say more closely
While I agree that the power of choice (and the power of change) that free software gives us is a great thing - hell, I've used it a bunch myself, from reporting bugs to making changes - it's just not useful for everyone. Not everyone is a programmer, and with the software market downsizing (or so they say) and less undergrads enrolling in CS programs, not all corporations are going to be able to hire someone to smash bugs for them. That's just the shakes.
It's like the power to maintain your car. If - and I realize this isn't a realistic situation, but analogies suck - you don't know how to take apart an engine, and no-one you know knows how to do so, and there are no mechanics in town, and your engine breaks, you're just as screwed as if the hood was welded shut and the car magically stopped working. While I believe very strongly in the freedoms guaranteed by (e.g.) GPLv2, I also don't think it's a panacea.
However, I stand by my original point - there's not much point in bashing Microsoft for having long-standing bugs. We on the free side of the fence are generally much better about it than they are, but neither are we spotless.
Man, you know, the funny thing is that the one thing you pick on them for is true. Yes, even GPL'd software can have unresolved bugs sitting for months. Hell, go to the OO.o bug tracker and you can find entries from 2002 if you look for two minutes.
This isn't to pick on OO.o - writing bug-free software is manageable, but not necessarily easy, especially for something that big. But no, Microsoft isn't the only one who leaves bugs unresolved for months. If you're going to debunk this, I'd start somewhere else.
P.S. Oh btw, the reason my friend declined their offers is that he lost the source code in a harddrive failure and he's too embarrass to admit it :)
;)" - Linus
"Only wimps use tape backup; *real* men just upload their important stuff on FTP, and let the rest of the world mirror it
Oooh. This was made into a 4-episode OVA in 1993 (which got shown as a movie on the Sci-Fi channel, back when they had Saturday Anime ... which I remember seeing, and it kicked all sorts of ass when I was 13 ^_^; ), and was originally a 35-episode TV series which started in 1973.
The general plot is the usual mysterious-fighter-saves-world-from-robot-army, with twists.
it will be interesting to see this done, if only just to see how well they pull it off.
No.
There are separate change logs for each kernel release in the kernel download directory, though.
Um, normal desktop users will probably never upgrade their kernel, much less across major versions, short of the equivalent of an operating system upgrade. Honestly, how many patches to ntkernel.dll do you see in service packs? (Serious question, I don't use Windows.)
People who are having trouble upgrading to the 2.6 series from 2.4 are generally people who are doing it all on their own because the distros haven't all started doing it yet. Many of them have run into common problems that are explained in FAQs ("Why is my screen blank and the keyboard does nothing?", "Why don't my modules work?", etc.). Some of them are valid regressions. Some are because the technologies underlying tools have changed (I believe dm is an example of this). Most of these problems are things best solved by the distributions, which provide the functional equivalent of service packs.
So, no, I don't think this is really a big problem for Linux, since most Windows users wouldn't go download binary patches to system files and apply them by hand. They'd use Windows Update. Similarly, non-tech-savvy Linux users can wait until distributions ship 2.6.
(As far as cohesiveness of Linux, yeah, I agree. That's why I'm really waiting to see what comes out of the D-BUS and HAL projects.)
Ah, I didn't know about mingw. Well, that's too bad.
... ^^; )
As a point of curiosity, what if that installer shipped the arch binary and cygwin.dll, but just didn't tell you? That's really all arch needs. Since all you'd have to do is ship the binary, install it in (say) C:\tla, and put the Cygwin DLL also in C:\tla, if an installer did that for you, would that be enough?
(tla works fine for non-distributed Open Source projects too, speaking from experience
The biggest downside to arch is user interface and documentation. I hate to say it, but it's true. Obscure error messages is one of arch's biggest problems, and command names and syntax are sometimes not consistent. Focus thus far has been on functionality; user interface cleanups will probably start in earnest after GNU Arch 1.2 is released, which shouldn't be too far off.
There is, however, a fairly decent Arch tutorial called "arch meets Hello World", and if you like wikis, there is a more or less official GNU Arch wiki. (Even if you don't like wikis, there's good information here.) Each tla command will give you short usage if you specify --help as an option, and more info if you give -H.