The public source is all there/lib/modules/fglrx/build_mod
All there?
The proprietary code is contained in one static library-- libfglrx_ip.a -- which is linked into the final module.
If this is the whole story, it's a significant departure from ATI's previous R200 driver. Which is why I suspect it's not the whole story.
With the R200 driver, there were four components:
the kernel r200 module - distributed as a big binary blob with a small bit of source-available glue so you could compile it for any kernel (within a specific range)
a modified version of the kernel AGP GART module - distributed as source under the GPL, since as I said it's just existing Linux kernel source, so it has to be GPL. Not sure what ATI's modifications did, except to drop support for most non-Intel AGP chipsets and add support for one or two Intel chipsets. Presumably they added at least one needed feature there. It was quite out of date, as well - derived from the AGP code in kernel 2.4.2 or so, and I was running 2.4.19.
XFree86 driver: binary-only. This is the bit that XFree86 loads on startup. Possibly derived from some existing XFree86 code, but we'll probably never know to what extent, since XFree86 is not GPL.
XFree86 client library: binary-only. A rather large OpenGL client library almost certainly derived from the Mesa project. Since Mesa does not use the GPL, we can have no idea how or how much ATI modified the Mesa code.
So 2 of 4 components were binary-only, a third was binary-mostly with a small stub for multi-kernel compatibility, and the last was a set of trivial modifications to existing GPL code and was therefore open source.
If this driver is like their previous one, which I suspect it is, there's no way it could be considered "open source".
If that is indeed its purpose (and I don't dispute that), then it is already a miserable failure. Suse and Redhat RPMs that
are LSB compliant still break from time to time when used on the other platform, so clearly LSB compliance alone isn't enough to guarantee compatability anyway.
Have you tried LSB-compliant RPM packages and found them incompatible with one or more LSB-compliant distribution, or is this pure FUD based on your previous experiences / hearsay about non-LSB-compliant RPM packages and/or non-LSB-compliant distributions?
I realise that last sentence was a bit long and unwieldy, so I'll rephrase: for the failure(s) you are reporting, are you sure the RPMs and the OSes were actually labeled as LSB-compliant? It's not like all RPMs or all releases of Red Hat are LSB-compliant, obviously.
Forgive my scepticism, but it sounds like you are confusing LSB-compliant RPM with Red Hat RPM and SuSE RPM. Either that or you are confusing LSB-compliant Linux distribution with any RPM-using Linux distribution. Or you could simply be blaming the LSB for what is actually an issue of poor, non-LSB-compliant packaging work mistakenly labeled as LSB-compliant.
Now, I'm not much of a fan of RPM myself, being a Debian user and all. But please, try to keep the FUD down a little.
Were it not for politics and certain entities wielding undue influence on the standards body in question, it never would have been included, and the LSB standard would have been better for it (and much more widely adopted).
Where in your conspiracy theory do you explain why the LSB standardised on RPM v3 rather than v4? The party line is that RPMv4 format is too new and would be unfair to all the non-Red-Hat players, who would have to play catch-up. This would seem to put a serious dent in your 800-pound-Red-Hat-gorilla postulate.
Where in your conspiracy theory do you refute the claim that RPM was chosen because a vast majority of existing Linux installations already use it as a standard package format, and a majority of the remainder have decent alien support for converting RPM packages to their respective native package formats? Remember, the job of the LSB is largely to codify existing common practice wherever practical, so as to cause minimal disruption to the Linux user base while providing useful guarantees to software vendors / packagers. RPM would appear to fit this bill quite well.
Where in your conspiracy theory do you provide the alternative package format which would satisfy the above goals? "tar.gz" is not much of an answer: there is no standard way to handle processing before or after installation, configuration or removal, or quite a few other useful tidbits. Anything you might add to provide such a mechanism would negate the value of using this "well-known" tarball format - your new format would become "tarball with certain magic pixie dust added". --Basically a home-grown RPM with fewer features and no existing buy-in. (But hey, at least it uses tar instead of that eeeeevil cpio!) Would that be sufficient to satisfy your NIH instincts?
A common misconception. The two parties do not share the exact same ideas. Where are the pro-life Democrats and the anti-gun Republicans?
In general you have a point. But Kansas is a bit interesting in that regard. I was told recently by someone who works in the Capitol that there are really three parties here: the right-wing Republicans, the Democrats, and the left-wing Republicans, who on social issues are the most liberal of the three. In the 1994 governor race, pro-life Democrat incumbent Joan Finney was defeated by pro-choice Republican Bill Graves. As for guns, I dunno, this is the midwest, nobody is anti-gun around here. (:
Personal rule: I do have a party preference (one party has a lower impedance mismatch with my ideas than the other) but I never vote party line. If I don't have any specific knowledge of one or more of the candidates in a particular race, I leave that part of the ballot blank.
And is there any chance of getting both maintained and in the kernel (As options)
Neither NGPT nor NPTL are in the kernel. They are both userspace libraries using the same kernel interface. You probably associate them with the kernel because NPTL was developed in parallel (no pun intended) with Ingo Molnar's improvements to the kernel threading interface.
Specifically, they implement libpthread, which is packaged with libc (so libc can use it to be thread-safe). Ulrich Drepper seems quite committed to packaging NPTL with the GNU libc, but it should be possible to rework NGPT to make it possible to swap it in at compile time, if you want to recompile your libc, or possibly even at runtime. (I say "possibly", because I don't know if the two have exactly the same ABI, with regards to things like mutexes.)
If you have hundreds of thousands of connections you should be using aio, which is the new scalable replacement for lots of polls...
Or epoll, which is the other new scalable replacement for lots of polls. epoll was merged into a kernel 2.5.4x recently. Its interface is somewhat similar to select() - should be relatively straightforward to convert select()-using code. Not that anyone should have been using select() for hundreds of thousands of connections in the first place!
The NPTL is proabably still faster for small numbers of threads, but I would guess that "big-iron" performace is better with NGPT.
Well, is your guess based on any fact, or just a guess? The NPTL people benched them and claimed to be quite surprised at how much better NPTL did than NGPT - they figured the two would be approximately equal. And this benchmarking wasn't on the order of 50 threads - it was more like 100_000 threads. Perhaps that's still small iron to you, but it's massive overkill for any workload I can think of.
Oh, and before you get all pissed at me - yes, I agree that you were moderated unfairly. Yes, a certain amount of crack was most likely involved. I don't care - it's still tacky and tiresome to complain about it yourself.
OT: I can't believe I got modded down for this comment. Sheesh.
Next time I get mod points, I think I'm gonna just start modding down posts that complain about moderations done to their authors. Nothing personal, Jack, it's just something I've noticed a lot of recently on slashdot, and it's really frickin' lame. I mean, it's OK to complain that someone else got hammered by the mods, but to whinge about one's own fate - dude, it's only karma, get over it already.
(This is of course in addition to the policy I'm borrowing from someone's sig: "I moderate down any post that says 'I'll probably get moderated down for this'." Same principle.)
Of course, my new-found policy will probably be a big hit with the metamods, some of whom have taken on personal quests to rate all downmods as unfair. So logically I should hide behind "overrated". But I won't. That would be lame. (:
That being said, there are always cynics, some just insist on being more anal than others. Why not send
ALL on an all-expense-paid one-way trip to the moon...?
Uh, are you volunteering to pay those expenses? I, as a US taxpayer, am certainly not....
This wouldn't have been a problem if the Apollo program had put an big advertising sign on the Moon, visible through a telescope. (Heinlein fans will, of course, get this.)
I think they should have put up such a sign that said "We apologise for the inconvenience." (Adams fans will, of course, get this.)
Pictures can be faked, so can computer records, documents, etc...
Yes, and we've pretty much passed the point of no return. For pictures, in particular, anything that can appear in real life can be mocked up by a CG effects house, with very little effort, and be pretty much undetectable. I expect this fact will have interesting ramifications in legal courts in the coming years.
The argument to exit() has unsigned 8 bits, not 7. And they are returned in the first byte of the status integer, not in the
second.
Technically true. But note that I said "not portable". If your program defines an interface where the 8th bit of the return value is of interest, how does a shell script know whether it crashed on a signal or not? Remember, this conversation was originally about shells..
If any of you so called "hard" C junkies ever did any assembly, you would know that 0=true is used because it's the fastest
numerical test. Loading a value of 0 into an accumulator type register causes the zero flag to be set, which you can then use a
conditional branch/jump on
And loading a non-zero value into an accumulator causes the zero flag to be cleared. Which you can then use in your conditional. What was your point again?
Of course, all this depends on the specific instruction set, but for the ones I've seen, testing for nonzero is exactly as easy as testing for zero.
Don't evaluate code that's not marked as code! Since Slashdot doesn't allow the use of <code>, I thought >tt> would be adequate.
It would have been, but my browser of choice (elinks) doesn't show the distinction (hey, it's hard on a text console). They could have picked a distinct color, as they do for bold, italic, hyperlinks, etc, but they didn't.
Real Programmers don't need proportional fonts. (:
Design issue, friend, design issue! These people specifically wanted it to be invoked as "M-x viper-mode".
Bah. Never give the customer what he asks for. We know better than he does what he really needs. Elementary principle in the exude-absolute-arrogance school of software engineering.
Besides, real programmers don't use (while (read-char) (ding)). They just undefine all key bindings.
Oggs require more hardware to decode, There is an integer engine out, but I'm not sure how well it works, or how much CPU it needs
compared to other codecs.
I remember when `ogg123', the reference ogg player, used something like 35% of my P166 CPU, while `mpg123', a popular mp3 player, used less than half that. (Well, "I remember" is a bit strong, I don't actually remember the numbers....) That annoyed me at the time, and I really hoped it would improve.
Now, I don't know about the Tremor implementation, but the original floating point codec has come a long way. I just now benchmarked them on my P4, because I was curious. Result: the mp3 player needed 10 seconds of CPU for a 3-minute song; the ogg player needed only 5 seconds of CPU for a 4 1/2-minute song.
Of course, this isn't scientific. This wasn't the same song or even the same genre, and I think the mp3 was fixed-bitrate as opposed to vbr, and possibly there are more efficient mp3 decoders out there. But the days of saying "ogg takes too much CPU" are long past, at least for the desktop codec. (And, I've heard, for Tremor, but that's second-hand information.)
And some geeks. It's such a naff sounding name - I detest it...
Sure it sounds horrible, you're cutting it off. You have to say the whole thing. "Xiphophorus Ogg Vorbis". Five times fast. If that doesn't impress your friends, well, I guess try hanging out with people who are easily impressed. What can I say, works for me.
(Of course it seems they're now just calling themselves Xiph.org - how lame, no pun intended.)
Am I missing something here? Even if a drive doesn't have an external digital output, surely an application can still access the
raw digits on a CD and encode those?
If the hardware is crap, it will make mistakes. Mistakes are not acceptible for a CD-ROM, where someone's actual data is at stake, so the standard CD-ROM format allows for gobs and gobs of error correction - I think that's why an audio CD sector is 2352 bytes while a data CD sector is only 2048 bytes. Audio is seen as less important. After all, who cares if your playback is 100% the right bits or only 99.9%?
Try ripping a whole CD twice. For extra fun, turn off all those error-detection/correction algorithms in cdparanoia so it will go faster. Then do a bit-by-bit comparison of each track. If your hardware is less than perfect, or your CD has any significant scratches, some of the compares will fail. Heck, I've got a ~1.5-year-old Dell-OEM CD-ROM and it picks up the occasional string of bit errors even on CDs straight out of the shrinkwrap. Not sure if this is the fault of the CD manufacturer or my drive, but my point being.
I agree with you that the "external digital out" is not the important factor here - except that if your hardware is 'leet enough for digital out, it just may be of passable quality in terms of ripping per se.
Slashdot Mirror
OK, so it will work on my Linux 2.2 machine? No?
At least it should work for Linux 2.5.47, right? No?
Oh, ok, we'll stick with Linux 2.4, on my Mac. No?
Careful with that word, universal. "I do not think it means what you think it means."
All there?
If this is the whole story, it's a significant departure from ATI's previous R200 driver. Which is why I suspect it's not the whole story.
With the R200 driver, there were four components:
So 2 of 4 components were binary-only, a third was binary-mostly with a small stub for multi-kernel compatibility, and the last was a set of trivial modifications to existing GPL code and was therefore open source.
If this driver is like their previous one, which I suspect it is, there's no way it could be considered "open source".
Have you tried LSB-compliant RPM packages and found them incompatible with one or more LSB-compliant distribution, or is this pure FUD based on your previous experiences / hearsay about non-LSB-compliant RPM packages and/or non-LSB-compliant distributions?
I realise that last sentence was a bit long and unwieldy, so I'll rephrase: for the failure(s) you are reporting, are you sure the RPMs and the OSes were actually labeled as LSB-compliant? It's not like all RPMs or all releases of Red Hat are LSB-compliant, obviously.
Forgive my scepticism, but it sounds like you are confusing LSB-compliant RPM with Red Hat RPM and SuSE RPM. Either that or you are confusing LSB-compliant Linux distribution with any RPM-using Linux distribution. Or you could simply be blaming the LSB for what is actually an issue of poor, non-LSB-compliant packaging work mistakenly labeled as LSB-compliant.
Now, I'm not much of a fan of RPM myself, being a Debian user and all. But please, try to keep the FUD down a little.
Where in your conspiracy theory do you explain why the LSB standardised on RPM v3 rather than v4? The party line is that RPMv4 format is too new and would be unfair to all the non-Red-Hat players, who would have to play catch-up. This would seem to put a serious dent in your 800-pound-Red-Hat-gorilla postulate.
Where in your conspiracy theory do you refute the claim that RPM was chosen because a vast majority of existing Linux installations already use it as a standard package format, and a majority of the remainder have decent alien support for converting RPM packages to their respective native package formats? Remember, the job of the LSB is largely to codify existing common practice wherever practical, so as to cause minimal disruption to the Linux user base while providing useful guarantees to software vendors / packagers. RPM would appear to fit this bill quite well.
Where in your conspiracy theory do you provide the alternative package format which would satisfy the above goals? "tar.gz" is not much of an answer: there is no standard way to handle processing before or after installation, configuration or removal, or quite a few other useful tidbits. Anything you might add to provide such a mechanism would negate the value of using this "well-known" tarball format - your new format would become "tarball with certain magic pixie dust added". --Basically a home-grown RPM with fewer features and no existing buy-in. (But hey, at least it uses tar instead of that eeeeevil cpio!) Would that be sufficient to satisfy your NIH instincts?
Heh - thanks for the personal fortune file entry. Maybe a future sig too.
In general you have a point. But Kansas is a bit interesting in that regard. I was told recently by someone who works in the Capitol that there are really three parties here: the right-wing Republicans, the Democrats, and the left-wing Republicans, who on social issues are the most liberal of the three. In the 1994 governor race, pro-life Democrat incumbent Joan Finney was defeated by pro-choice Republican Bill Graves. As for guns, I dunno, this is the midwest, nobody is anti-gun around here. (:
Personal rule: I do have a party preference (one party has a lower impedance mismatch with my ideas than the other) but I never vote party line. If I don't have any specific knowledge of one or more of the candidates in a particular race, I leave that part of the ballot blank.
Another comp.unix.shell oldtimer? You just gained a fan. (:
What? 1984 is obscure on slashdot? I very much doubt it..
Neither NGPT nor NPTL are in the kernel. They are both userspace libraries using the same kernel interface. You probably associate them with the kernel because NPTL was developed in parallel (no pun intended) with Ingo Molnar's improvements to the kernel threading interface.
Specifically, they implement libpthread, which is packaged with libc (so libc can use it to be thread-safe). Ulrich Drepper seems quite committed to packaging NPTL with the GNU libc, but it should be possible to rework NGPT to make it possible to swap it in at compile time, if you want to recompile your libc, or possibly even at runtime. (I say "possibly", because I don't know if the two have exactly the same ABI, with regards to things like mutexes.)
Or epoll, which is the other new scalable replacement for lots of polls. epoll was merged into a kernel 2.5.4x recently. Its interface is somewhat similar to select() - should be relatively straightforward to convert select()-using code. Not that anyone should have been using select() for hundreds of thousands of connections in the first place!
Well, is your guess based on any fact, or just a guess? The NPTL people benched them and claimed to be quite surprised at how much better NPTL did than NGPT - they figured the two would be approximately equal. And this benchmarking wasn't on the order of 50 threads - it was more like 100_000 threads. Perhaps that's still small iron to you, but it's massive overkill for any workload I can think of.
Oh, and before you get all pissed at me - yes, I agree that you were moderated unfairly. Yes, a certain amount of crack was most likely involved. I don't care - it's still tacky and tiresome to complain about it yourself.
Next time I get mod points, I think I'm gonna just start modding down posts that complain about moderations done to their authors. Nothing personal, Jack, it's just something I've noticed a lot of recently on slashdot, and it's really frickin' lame. I mean, it's OK to complain that someone else got hammered by the mods, but to whinge about one's own fate - dude, it's only karma, get over it already.
(This is of course in addition to the policy I'm borrowing from someone's sig: "I moderate down any post that says 'I'll probably get moderated down for this'." Same principle.)
Of course, my new-found policy will probably be a big hit with the metamods, some of whom have taken on personal quests to rate all downmods as unfair. So logically I should hide behind "overrated". But I won't. That would be lame. (:
Boy, I wish I hadn't used up those mod points earlier tonight. That's the funniest post I've read in, ummm, at least two days.
What??? Copyright can expire? I thought Congress did away with that sort of thing.
Uh, are you volunteering to pay those expenses? I, as a US taxpayer, am certainly not....
I think they should have put up such a sign that said "We apologise for the inconvenience." (Adams fans will, of course, get this.)
Yes, and we've pretty much passed the point of no return. For pictures, in particular, anything that can appear in real life can be mocked up by a CG effects house, with very little effort, and be pretty much undetectable. I expect this fact will have interesting ramifications in legal courts in the coming years.
Yes, but belief in Occam's Razor is what separates "normal" people from conspiracy theorists.
Technically true. But note that I said "not portable". If your program defines an interface where the 8th bit of the return value is of interest, how does a shell script know whether it crashed on a signal or not? Remember, this conversation was originally about shells..
And loading a non-zero value into an accumulator causes the zero flag to be cleared. Which you can then use in your conditional. What was your point again?
Of course, all this depends on the specific instruction set, but for the ones I've seen, testing for nonzero is exactly as easy as testing for zero.
It would have been, but my browser of choice (elinks) doesn't show the distinction (hey, it's hard on a text console). They could have picked a distinct color, as they do for bold, italic, hyperlinks, etc, but they didn't.
Real Programmers don't need proportional fonts. (:
Bah. Never give the customer what he asks for. We know better than he does what he really needs. Elementary principle in the exude-absolute-arrogance school of software engineering.
<g>
Great, next we'll see slashcode automoderating based on bayesian probability of a troll. Use leetspeak, go to -1, Offtopic.
Please someone tell me I didn't just give them the idea..
I remember when `ogg123', the reference ogg player, used something like 35% of my P166 CPU, while `mpg123', a popular mp3 player, used less than half that. (Well, "I remember" is a bit strong, I don't actually remember the numbers....) That annoyed me at the time, and I really hoped it would improve.
Now, I don't know about the Tremor implementation, but the original floating point codec has come a long way. I just now benchmarked them on my P4, because I was curious. Result: the mp3 player needed 10 seconds of CPU for a 3-minute song; the ogg player needed only 5 seconds of CPU for a 4 1/2-minute song.
Of course, this isn't scientific. This wasn't the same song or even the same genre, and I think the mp3 was fixed-bitrate as opposed to vbr, and possibly there are more efficient mp3 decoders out there. But the days of saying "ogg takes too much CPU" are long past, at least for the desktop codec. (And, I've heard, for Tremor, but that's second-hand information.)
Sure it sounds horrible, you're cutting it off. You have to say the whole thing. "Xiphophorus Ogg Vorbis". Five times fast. If that doesn't impress your friends, well, I guess try hanging out with people who are easily impressed. What can I say, works for me.
(Of course it seems they're now just calling themselves Xiph.org - how lame, no pun intended.)
If the hardware is crap, it will make mistakes. Mistakes are not acceptible for a CD-ROM, where someone's actual data is at stake, so the standard CD-ROM format allows for gobs and gobs of error correction - I think that's why an audio CD sector is 2352 bytes while a data CD sector is only 2048 bytes. Audio is seen as less important. After all, who cares if your playback is 100% the right bits or only 99.9%?
Try ripping a whole CD twice. For extra fun, turn off all those error-detection/correction algorithms in cdparanoia so it will go faster. Then do a bit-by-bit comparison of each track. If your hardware is less than perfect, or your CD has any significant scratches, some of the compares will fail. Heck, I've got a ~1.5-year-old Dell-OEM CD-ROM and it picks up the occasional string of bit errors even on CDs straight out of the shrinkwrap. Not sure if this is the fault of the CD manufacturer or my drive, but my point being.
I agree with you that the "external digital out" is not the important factor here - except that if your hardware is 'leet enough for digital out, it just may be of passable quality in terms of ripping per se.