Another interesting thing about the Intel driver is that due to being pretty much the most capable open-source driver around, it gets a lot of attention from XOrg way, including being compatible with the latest nifty standards. If I want TV-out on ATI, I have to use a driver that's been in continuous beta for the past four years and reboot the machine with the TV plugged in so the card notices it. If I want TV-out on NVidia I have to put weird crap in my X config file and then run nvidia's custom settings app to configure displays. Okay, better. If I want TV-out on Intel I use xrandr -- from the commandline or from any of the GUI utilities already out there... and it works. Bang. Just like that.
The important word there is intermediate. You don't get a result of infinite precision, you get a 32-bit result (since the parent mentioned single-precision floating point). But it carries the right number of bits internally, and uses the right algorithms, so that the result is as if the processor did the multiply and add at infinite precision, and then rounded the result to the nearest 32-bit float. Which is better than the result you would get by multiplying two 32-bit floats into a 32-bit float, then adding that to another 32-bit float into a 32-bit float. You're limited to 32 bits at all times and therefore you have intermediate precision loss.
because they're not evil demon ninjas, they're Apple ninjas, which is subtly different. Besides 1) they have some honor -- they were hired to implement the Secret Hardware Changes, not steal phones. 2) Locking your phone and returning it undetected requires skill, and everyone knows that if a ninja has one weakness it's his desire to prove how skilled he is. 3) If the job is done properly, you'll have no clue what happened to your phone besides weird internet rumors... thus assuring the safety of the Apple ninja.
... so they're going to send ninjas with screwdrivers into the streets to steal people's iPhones, make hardware modifications, and then quietly return them?
Except, of course, that the "one guy" is a sovereign nation enforcing its laws (specifically, as regards compulsory licensing). And in truth the situation isn't all that different from what pertains in the US. ROMS is essentially equivalent to an organization called SoundExchange, which collects those compulsory-license royalties you've heard about on webcasts, and is a division... you guessed it... of the RIAA. Russians just happen to enjoy a slightly broader license grant under their system than do Americans under theirs. So this is a case of "your laws are different from ours... OMG IP terrists!"
Except that you're not pushing around single samples. MP3 decoding produces a few thousand at a time, and the soundcard buffers a few thousand samples. Which means that you're looking at tens of interrupts per second from the soundcard, compared with a potentially gigantic number from a GigE controller. In that situation, sure, you can give a little priority to servicing the soundcard interrupt if you want, because audio pops are annoying and because doing it will take practically no time and won't degrade anyone else's performance much. MS have to be really screwing up by the numbers here to cause this kind of impact. The last time I saw MP3 decoding really tax a system, I was on a 486.:)
Yeah well. Doesn't worry me a lot. When I want a desktop machine I pop in a Kubuntu disc; when I'm setting up a server it's Debian netinst. I just think it's funny that the whole "oh noes boot-floppies sucks the big one" thing is so incredibly sticky. I guess people just got used to it;)
that these days you can install Debian by popping in the disc, booting, and hitting Enter about ten times. Hell, they even brought back tasksel and created a useful set of tasks, so you can select "desktop machine" or "email server":)
No, wine "emulates" (really reimplements) most of the core system libraries. Keep in mind that it does work and run windows apps without a native windows install. The libraries that it runs directly are the ones that ship with apps. And as others have pointed out, it's taken Wine years and a huge amount of work to reach its current state, which is still just passable. It runs a lot of things well, but somehow they're never the things that I want. To replicate the same feat for OSX, providing standins for Cocoa, Carbon, Aqua, Rosetta, and xnu would be a pretty monstrous task. And keeping up with the latest would be a bigger problem than with Wine as well; Apple keeps the releases rolling out pretty steadily, and they not-so-subtly encourage the big software developers to require the latest version.
You're a smart guy, and I used your code for years, but you're dead wrong here. Just because some of the kernel guys are jerks and you don't have the patience to deal with them doesn't mean that Linux has "failed on the desktop". Nor is the kernel burdened with useless crap. And far from having gigantic performance problems, Linux actually kicks some serious ass in plenty of metrics that affect desktop usability. Note that that's the kernel only, of course; X is its own little problem. Linux has great soft-realtime abilities, a scheduler with great fairness characteristics and accurate accounting, tickless timers, the fast process creation and fast IPC that come from its Unix heritage, lots of great shit under the hood. And it's starting to get used. I'm not one of those guys who really wants to see "Linux on every desktop" but you've got to admit that from a usability standpoint things have also improved dramatically in the past few years.
As for you, it's not that you don't get taken seriously -- obviously you've made a huge impact on things -- it's just that you're really good at coming at things from the wrong angle. It doesn't matter how loudly you make an argument if it's not the argument that someone wants to hear. It doesn't matter how well the code works if it's not the code that someone wants to maintain. It doesn't matter how well you can explain something if someone would rather read an academic paper, appreciate the algorithm, and write their own implementation -- and there are a bunch of people who do have that attitude. So, it was a rare occasion that your stuff won directly. But that doesn't mean you were ignored. Just that your little world of ideas had to filter through the right people before it saw the light of day. And when it did get merged (look at how much has, in time) it was generally much improved. How can you complain about that?
Incidentally, plugsched is not a good argument to continue to make. There's no reason for a proliferation of schedulers -- that's simply a sign that you couldn't do the job right once. And that is not the kind of place where you want the complexity of a plugin system:)
Uh no. No they don't. I used to do my web browsing and email on a 486DX4 with 12MB of RAM. That would be with Netscape 4.7 and Balsa. Did word processing on a similar machine with 16MB of RAM and WP5.2. Everything was reasonably snappy. Now I understand software bloat and all, but if you're going to tell me that the bare minimum requirement to get these things done has increased over 80-fold, you're just an asshole:)
Nah, that would be dead simple to correct for. Just create a lowpass filter that matches the response of a really good physical turntable. If the sampled data is accurate, then that would be all you would have to run it through to get beautiful reproduction. But if the sampling process has errors, you're slightly more screwed:)
Whee. Thanks, I've been tempted to write this about a hell of a lot of things lately. For those of you watching from home, the relevant research topic is "Negative and positive rights". Wikipedia's coverage is, if rather brief, enough to plant a little bit of a clue.
Depends on the system, but either each will get ~49% of CPU, or one will get ~99% while the other starves (well, competes with no significant advantage). It depends on a few factors. If the prios are shaken up enough and both cheaters get a chance to run, then each cheat will get to monopolize the CPU for a whole timeslice (on average) every other scheduling interval. But it's at least as likely that the process that gets the scheduler first wins every time, and runs so much that the other one doesn't even get time to play its games. All this of course assumes that they're both trying to run on the same CPU. As others have pointed out, on a system with two or more processors they'll simply consume 198% of CPU time:)
I never said otherwise. Of course the problem is the X server (and even beyond that, the problem is X), and the problem needs to be fixed at that end. That was my point, actually -- that attempts to fix it from the scheduler end are ultimately futile and in the end just add complexity, and make as many things worse as they make better:)
Absolutely. In fact I think it should go half a step further. In the interest of civility, using this feature should hide the message from casual viewing. But a single click will still bring up the original so that you can't use slashdot to be a complete ass and then censor yourself after the damage is done:)
Yep. I've seen this in CFS testing actually. Pretty much all of the work that the X server does can be assumed to be "on behalf of" somebody, but in the end those cycles still belong to the X server. So an app can be thoroughly abusive, spam the X server with requests, fill up queues, and prevent anyone else from using the server to do anything useful -- and yet it still gets priority because as far as the scheduler can tell it's a perfectly nice I/O-bound task that spends most of its time waiting for the X server to get back to it. As I recall, Linus provided a "fix" for that particular problem sometime early in 2.6 or late in 2.5 -- but later retracted it because it did more harm than good -- any simple solution you might think of has already been tried and thrown away.
Oh, and the abusive app that likes to make X servers choke? Firefox. Ugh. Hate that thing.:)
And with the 2.3 devel releases, they've reorganized the menus in a way that takes a little getting used to, but corrects a lot of the original sources of confusion in the UI (like putting things that actually affect the whole image in the "Layer" menu). They've also made a number of the tools easier to use (compare for instance the old and new behaviors of the crop box). Unfortunately at the same time, they've replaced the wonderful old tool icons with the stupid indistinct pastel blobs that all of the GNOME retards seem to love these days.
My terminals are usually somewhere between 140 and 160 characters wide, but when coding, I wrap at 120. Beyond that, the eye starts to have a really hard time following. Plus it gives me plenty of room for fold marks, line numbers, or even blame annotation. And, of course, if I'm working on someone else's code that's written to an 80col standard, I will follow it:)
Slashdot Mirror
Another interesting thing about the Intel driver is that due to being pretty much the most capable open-source driver around, it gets a lot of attention from XOrg way, including being compatible with the latest nifty standards. If I want TV-out on ATI, I have to use a driver that's been in continuous beta for the past four years and reboot the machine with the TV plugged in so the card notices it. If I want TV-out on NVidia I have to put weird crap in my X config file and then run nvidia's custom settings app to configure displays. Okay, better. If I want TV-out on Intel I use xrandr -- from the commandline or from any of the GUI utilities already out there... and it works. Bang. Just like that.
The important word there is intermediate. You don't get a result of infinite precision, you get a 32-bit result (since the parent mentioned single-precision floating point). But it carries the right number of bits internally, and uses the right algorithms, so that the result is as if the processor did the multiply and add at infinite precision, and then rounded the result to the nearest 32-bit float. Which is better than the result you would get by multiplying two 32-bit floats into a 32-bit float, then adding that to another 32-bit float into a 32-bit float. You're limited to 32 bits at all times and therefore you have intermediate precision loss.
Making sense now?
Or, put a different way: Childish Things :)
because they're not evil demon ninjas, they're Apple ninjas, which is subtly different. Besides
1) they have some honor -- they were hired to implement the Secret Hardware Changes, not steal phones.
2) Locking your phone and returning it undetected requires skill, and everyone knows that if a ninja has one weakness it's his desire to prove how skilled he is.
3) If the job is done properly, you'll have no clue what happened to your phone besides weird internet rumors... thus assuring the safety of the Apple ninja.
... so they're going to send ninjas with screwdrivers into the streets to steal people's iPhones, make hardware modifications, and then quietly return them?
It's possible, it just takes exactly as much work as it does anywhere else and you pay them for the experience instead of the other way around.
Idiot. Learn to read plzthx.
Except, of course, that the "one guy" is a sovereign nation enforcing its laws (specifically, as regards compulsory licensing). And in truth the situation isn't all that different from what pertains in the US. ROMS is essentially equivalent to an organization called SoundExchange, which collects those compulsory-license royalties you've heard about on webcasts, and is a division... you guessed it... of the RIAA. Russians just happen to enjoy a slightly broader license grant under their system than do Americans under theirs. So this is a case of "your laws are different from ours... OMG IP terrists!"
Except that you're not pushing around single samples. MP3 decoding produces a few thousand at a time, and the soundcard buffers a few thousand samples. Which means that you're looking at tens of interrupts per second from the soundcard, compared with a potentially gigantic number from a GigE controller. In that situation, sure, you can give a little priority to servicing the soundcard interrupt if you want, because audio pops are annoying and because doing it will take practically no time and won't degrade anyone else's performance much. MS have to be really screwing up by the numbers here to cause this kind of impact. The last time I saw MP3 decoding really tax a system, I was on a 486. :)
Yeah well. Doesn't worry me a lot. When I want a desktop machine I pop in a Kubuntu disc; when I'm setting up a server it's Debian netinst. I just think it's funny that the whole "oh noes boot-floppies sucks the big one" thing is so incredibly sticky. I guess people just got used to it ;)
that these days you can install Debian by popping in the disc, booting, and hitting Enter about ten times. Hell, they even brought back tasksel and created a useful set of tasks, so you can select "desktop machine" or "email server" :)
No, KDE allows for options. GNOME allows for removing options :)
No, wine "emulates" (really reimplements) most of the core system libraries. Keep in mind that it does work and run windows apps without a native windows install. The libraries that it runs directly are the ones that ship with apps. And as others have pointed out, it's taken Wine years and a huge amount of work to reach its current state, which is still just passable. It runs a lot of things well, but somehow they're never the things that I want. To replicate the same feat for OSX, providing standins for Cocoa, Carbon, Aqua, Rosetta, and xnu would be a pretty monstrous task. And keeping up with the latest would be a bigger problem than with Wine as well; Apple keeps the releases rolling out pretty steadily, and they not-so-subtly encourage the big software developers to require the latest version.
You're a smart guy, and I used your code for years, but you're dead wrong here. Just because some of the kernel guys are jerks and you don't have the patience to deal with them doesn't mean that Linux has "failed on the desktop". Nor is the kernel burdened with useless crap. And far from having gigantic performance problems, Linux actually kicks some serious ass in plenty of metrics that affect desktop usability. Note that that's the kernel only, of course; X is its own little problem. Linux has great soft-realtime abilities, a scheduler with great fairness characteristics and accurate accounting, tickless timers, the fast process creation and fast IPC that come from its Unix heritage, lots of great shit under the hood. And it's starting to get used. I'm not one of those guys who really wants to see "Linux on every desktop" but you've got to admit that from a usability standpoint things have also improved dramatically in the past few years.
:)
As for you, it's not that you don't get taken seriously -- obviously you've made a huge impact on things -- it's just that you're really good at coming at things from the wrong angle. It doesn't matter how loudly you make an argument if it's not the argument that someone wants to hear. It doesn't matter how well the code works if it's not the code that someone wants to maintain. It doesn't matter how well you can explain something if someone would rather read an academic paper, appreciate the algorithm, and write their own implementation -- and there are a bunch of people who do have that attitude. So, it was a rare occasion that your stuff won directly. But that doesn't mean you were ignored. Just that your little world of ideas had to filter through the right people before it saw the light of day. And when it did get merged (look at how much has, in time) it was generally much improved. How can you complain about that?
Incidentally, plugsched is not a good argument to continue to make. There's no reason for a proliferation of schedulers -- that's simply a sign that you couldn't do the job right once. And that is not the kind of place where you want the complexity of a plugin system
Than. than. than. not then. than.
Uh no. No they don't. I used to do my web browsing and email on a 486DX4 with 12MB of RAM. That would be with Netscape 4.7 and Balsa. Did word processing on a similar machine with 16MB of RAM and WP5.2. Everything was reasonably snappy. Now I understand software bloat and all, but if you're going to tell me that the bare minimum requirement to get these things done has increased over 80-fold, you're just an asshole :)
Nah, that would be dead simple to correct for. Just create a lowpass filter that matches the response of a really good physical turntable. If the sampled data is accurate, then that would be all you would have to run it through to get beautiful reproduction. But if the sampling process has errors, you're slightly more screwed :)
Whee. Thanks, I've been tempted to write this about a hell of a lot of things lately. For those of you watching from home, the relevant research topic is "Negative and positive rights". Wikipedia's coverage is, if rather brief, enough to plant a little bit of a clue.
Depends on the system, but either each will get ~49% of CPU, or one will get ~99% while the other starves (well, competes with no significant advantage). It depends on a few factors. If the prios are shaken up enough and both cheaters get a chance to run, then each cheat will get to monopolize the CPU for a whole timeslice (on average) every other scheduling interval. But it's at least as likely that the process that gets the scheduler first wins every time, and runs so much that the other one doesn't even get time to play its games. All this of course assumes that they're both trying to run on the same CPU. As others have pointed out, on a system with two or more processors they'll simply consume 198% of CPU time :)
I never said otherwise. Of course the problem is the X server (and even beyond that, the problem is X), and the problem needs to be fixed at that end. That was my point, actually -- that attempts to fix it from the scheduler end are ultimately futile and in the end just add complexity, and make as many things worse as they make better :)
Absolutely. In fact I think it should go half a step further. In the interest of civility, using this feature should hide the message from casual viewing. But a single click will still bring up the original so that you can't use slashdot to be a complete ass and then censor yourself after the damage is done :)
"The server" I'm talking about is the X server, not a server machine -- so we can assume it's pretty likely that it's going to be running X :)
Yep. I've seen this in CFS testing actually. Pretty much all of the work that the X server does can be assumed to be "on behalf of" somebody, but in the end those cycles still belong to the X server. So an app can be thoroughly abusive, spam the X server with requests, fill up queues, and prevent anyone else from using the server to do anything useful -- and yet it still gets priority because as far as the scheduler can tell it's a perfectly nice I/O-bound task that spends most of its time waiting for the X server to get back to it. As I recall, Linus provided a "fix" for that particular problem sometime early in 2.6 or late in 2.5 -- but later retracted it because it did more harm than good -- any simple solution you might think of has already been tried and thrown away.
:)
Oh, and the abusive app that likes to make X servers choke? Firefox. Ugh. Hate that thing.
And with the 2.3 devel releases, they've reorganized the menus in a way that takes a little getting used to, but corrects a lot of the original sources of confusion in the UI (like putting things that actually affect the whole image in the "Layer" menu). They've also made a number of the tools easier to use (compare for instance the old and new behaviors of the crop box). Unfortunately at the same time, they've replaced the wonderful old tool icons with the stupid indistinct pastel blobs that all of the GNOME retards seem to love these days.
My terminals are usually somewhere between 140 and 160 characters wide, but when coding, I wrap at 120. Beyond that, the eye starts to have a really hard time following. Plus it gives me plenty of room for fold marks, line numbers, or even blame annotation. And, of course, if I'm working on someone else's code that's written to an 80col standard, I will follow it :)