No arguments from me about why it makes things more stable. All I was saying is that it's the software that's tied to the hardware and not the other way around.
The only problem I have with Apple is the tight relationship between hardware and software. Yes I know this allows the computer to be much more stable.
That, of course, is bull. There is only a one way relationship. Apple software is tightly related to the hardware, but the hardware is as general purpose as any PC, and can run whatever software you care to run on it.
I'd love to believe everything you've said, but I think you give people too much credit. Somebody called it "Frankenfood" and everybody ran away. They didn't know about or understand half that stuff you're talking about.
I prefer the mouse, but I turn up the acceleration to obscene levels. It has the same effect as a trackball of having only finger movements, but without annoying me. I you hate trackballs, but don't want to hurt your wrists, you should try it.
Firm cardboard doesn't sell as tomatoes, no matter how bright red.
Yet it works for strawberries... I think that the lack of flavor is just an add on to an already sad story. They didn't succed because of the GM, and to make matters worse they didn't taste good. Hell, bigger and better looking sells every other thing in the produce department, why would tomatos be any different? Most people don't know what a fresh grown tomato tastes like anymore anyway.
This is all well and good untill somebody starts calling it "gene-laundering" or some other such unflattering name that implies that it's just sneaky GM, and nobody will eat this stuff either. Especially if it's essentially the same result. The real problem is that people oppose things they don't understand by default.
I made one once back in grade school as a science fair type of project. We used a glass jar as the frame, and some cloths hanger to suspend it so it was all visible. It sounded.... interesting. The jar directed the sound quite well, but it sounded like the whole thing was in a deep hole in the ground. Great for demonstration purposes though. using the jar ring (it was a ball style jam jar) and hanger made it so you don't need all that stuff about the metal plates.
I was amazed that O'Reilly did not even have a book on it.
That's because the definitive text, by LaTeX author Leslie Lamport, was published in 1986 by Addison-Wesley two years before O'Reilly got into the publishing business. Nobody's seen a need to improve on it I guess. Interestingly enough, Leslie Lamport works at Microsoft now, so I would assume if he published any new books on LaTeX they'd be Microsoft Press.
Once you get into more advanced usages, The LaTeX Companion is a good second book to pick up.
Like I said, I don't know why I'm arguing with you. It's clear you have a decent grasp of some of the basic building blocks, but are having a hard time seeing the big picture. If you have multiple processing phases that require knowledge of data from the next frame, you can process them in series, adding at least a frame of latency for each effect, or you can get a more powerful processor that has the capability of applying all the effects you need at the same time. You may not be able to combine a decode operation with a transform operation, but two transform operations can typically be reduced to a single operation that could have a latency less than that of performing the two operations seperatly.
Any additional frame of latency will require an additional frame buffer. Believe me, in current technology there is no sweet spot which asks for increase the number of framebuffers over the bare minimum.... I believe you have no idea of the algorithms.
What part of "I was only using an entire frame as an example" don't you understand?
Wait, why am I arguing with you again? Here's the deal. The processor they're using has a latency that's so high the audio is out of sync by up to four frames depending on which effects you enable. There's no point in arguing anything else, especially since it's clear that you have no idea what actually goes in to choosing parts to design a complex device. If you can't see that's caused by processing latency you need to go back to school and take some signal processing classes again. As for the mystical algorithms you think I don't understand, if the latency is due to a series of effects processors, it doesn't matter one bit what algorithms they use. They're in series. Their latency is additive. If a set manufacturer chooses to purchase a bunch of single purpose chips because they're less expensive than an all in one chip there's no algorithm to get around that.
Oh, one last thing:
...blah blah blah... and the die size... blah blah blah... increases the die size by a two digit percentile and does thus drive yield down and cost up
The largest portion of the cost of these chips is the manufacturer's margin. They're made with old technology left over from two years ago's cutting edge computer silicon. These aren't last weeks athlon where the competition keeps the margin down. What makes the price different between two devices is how much of a premium the manufacturer can get away with charging for their value add, and not how many framebuffers (or whatever, there may not be even one framebuffer in the sence you're thinking) are on the chip. On top of that, the chip is only a fraction of the board cost, and so on.
I think the other poster in this thread was right, and everything you "know" about this stuff you learned from reading poor marketing descriptions of high end video cards. I'll give you a hint. You don't really know how those work either unless you make 'em, because they don't tell you half of how they do what they do. It's called keeping trade secrets.
I used a frame in the example for ease of understanding. What the processor actually uses is something they don't make public knowledge. The issue at hand (the difference between throughput and latency) is the same, so using a frame made for an easily understandable example.
framebuffers are expensive, you do not want to increase the number over the bare minimum.
Actually there's a cost analysis equation that the manufacturer would use that is likely a bit complex. As you slow down each stage, you can use slower (read: cheaper) memory for your buffer. Also, slowing down the chip as a whole may reduce costs more than the increase caused by adding buffer. To complicate things further, you can make design decisions that allow you to reduce your overall component cost by, for example, sharing an oscillator with a communications component. These are specialized devices with tightly integrated designs. You can't make assumptions about which parts are driving the cost. It may not even be obvious to the designer without running the numbers.
The delay is not caused by cheap processors, that is a myth. Just think about it, even delaying the video by 1 second will not reduce the required processing power...
We're talking latency here, not throughput. They're two seperate things.
Let's say you have a pipeline of frames you're processing. There may be multiple frames in flight at different stages of processing. The longer it takes for for a frame to enter in one state and leave in it's final state doesn't nescicarily have any impact on the number of frames you can process per unit time if you increase the number of frames in flight. A processor with fewer steps of the same length along the processing path, or a processor that can complete each step more quickly will reduce the latency. Such pipelining is a common technique for increasing the latency of an operation in exchange for throughput.
Nuclear energy plants are costly and time consuming to construct. Furthermore,there is the cost of the distributing the hydrogen.
Ever seen a natural gas pipeline? Do you know what it takes to get fossil fuels to their destination? Hydrogen can be easier than all that. Don't underestimate the ability and willingness of people to make energy available for usage.
Realistically, the days of large and heavy vehicles powered by engines of >200 hp (such as typical SUVs) are numbered.
As far as percentage of portable energy consumed, SUVs likely use a fraction of a fraction of one percent. Realisticaly, if we can't generate and transport hydrogen in such a way that makes it affordable for SUV drivers, there's no way it'll be affordable for everything else.
Maybe it makes you furious because, if not for the reasons he states, he has a point.
Why do people tout lifestyle changes that people will *not* accept instead of looking for solutions that people will accept or pushing for ones we've known about for ages.
NPR, the other day, had a 5 minute segment about Bush administration plans to switch cars over to Hydrogen fuel cells over the next 20 years. Their expert (a reporter from the New York Times) said, and the basis of the story was, that the proposal would result in *more* polution, not less, since we use coal to generate the majority of our electricity and you need either electricity or natural gas to generate hydrogen. There was not a single mention of nuclear power, which is a technology we know well that can fix almost all of our climate change problems without altering lifestyles. The problem is that it's politically unpopular. But scientists are supposed to be immune to political pressure and focus on objective results, huh?
So maybe your infuriating parent poster there is right, but instead of the money influencing what they say, it influences what they leave out.
The software overhead for RAID1 should be, for all intents and purposes, insignificant. It just doesn't *do* anything that requires much CPU work.
What it does is blocking. A good hardware raid mirror will have a battery backed up cache so it can acknowledge the write as successful either immediatly or after the data is on one disk, which a software raid setup can't do reliably. What you end up with is the additive rotational latency for two disks, which can signifigantly hurt performance for small random access writes.
Of course, in many cases this is perfectly acceptable.
So, having a redhat.com e-mail address makes you more of an authority on the kernel than not having one? I'd think it'd be the other way around. Working at redhat would give you a little bit of bias in this argument I'd think. Just because I chose to write linux code under contract for signifigantly more money than I would be making writing code for redhat doesn't mean I don't know what I'm talking about. So, he wrote some device drivers that a lot of people use. So have I.
Of course being anonymous, I have no way to verify, but I assume you have no idea what my employment background is, or how much of my code is in which kernel trees.
Wrong. The drivers and subsystems I maintain in the Linux kernel are all for the most commonly used hardware.
Read it again. I was being sarcastic.
First, this was documented in both release notes and the rpm changelog.
Really? Where? In the initial release of RHAS, it was not listed. Period. Many of the entries in the kernel source RPM had a date and the nameof the person who applied the patch, but no text. Hardly well documented. Were it well documented I'd have no complaints.
An upstream 2.4 block, scsi, or net driver drops into RHEL kernels with zero modifications. I do this all the time, with all three of these classes of drivers (block/scsi/net). It is a hardware vendor's choice to create 2.4-backport-specific modifications to their driver, with the additional maintenance that entails.
It sucks when you try to use a third-party md personality that assumes your 2.4 kernel has a global request list lock, and it compiles, loads, and crashes randomly on your RedHat kernel, or worse, silently corrupts your data. It's not as backwards compatible as you'd like.
Apparently you have no clue who writes Linux device drivers.
Apparently on this point you are correct. I don't keep up to date with a comprehensive list.
Wrong. Backporting drivers has been fantastically useful to me.
Right. And let me guess. You use all sorts of specialty hardware.
You're missing the entire point. This isn't about community written drivers, it's about third party drivers. Believe it or not, but there are some devices that the community can't/won't write drivers for, and there's a variety of reasons ranging from patented algorithms, to lack of popular interest, or just plain lack of skill in the case of some specialty devices where there are only a few people who really understand how it works. We're not talking about your little file server with IDE disks and last years processor and chipset or whatever it is you have.
I suppose your definition of "notorious" includes upstream 2.6 driver interfaces
Yes, yes it does. When you do something like port just the per block device locking from the 2.6 SCSI mid-layer back to 2.4 for your vendor specific release and don't put as much as a release note or a long file name on the patch in your source tree, all the while making something that's incompatable with both versions, you make it very difficult for outside companies to write interoperable drivers. If you wrote drivers for linux, you'd know this, and that's what "notorious" means.
Wrong. It exposes new features to more users.
From the perspective of somebody who only uses relatively common devices, it may seem like that. But once you need a device that's only supported in Solaris or Windows, and the vendor tells you it's too labor intensive to support linux, you'll understand.
Backporting 2.6 features helps everyone because it subjects those features to more testing, meaning that 2.6 will be better as a result.
Unlikely. Testing of features that have been hacked back into an older kernel won't provide representative results. You'll only find the most glaring of bugs through that kind of testing, and the hope typically is you find those before you put them into production anyway.
The real effect of backporting features is that it scares off third party developers. Companies that want linux drivers for their devices have to pick a version to work with. RedHat's backports are notorious for changing things in the driver interfaces. That means a vendor, who may not be informed as to the dynamics of the kernel development process, may choose to support only RedHat's version of the kernel, to speciffically not support RedHat's version, or worst and most likely, to not support linux at all.
I've done consulting and contracting for all three types of companies, as well as one who tried to support both RedHat's tree and Linus' tree from the same code base, and believe me when I say that it's a mess. Let's just hope that somewhere along the way RedHat decides to pick a versioning scheme that makes it easy to tell their features are in there at compile time, and starts providing change logs so you can figure out what they've done. As of right now their stuff is a nightmare.
LinuxPPC is merged back in periodically too. Hence the reason that forks of Linux don't have the effect forks of Unix did. They're not all hiding their work from each other, and they're all allowed and willing to take the good from another fork and incorporate it into their own trees. Even if they don't, users are free to if they wish. Forking can be healthy in a free software environment.
RedHat has been backporting patches forever. That doesn't make it a fork any more than the actual kernel forks. Look at the LinuxPPC tree for an example of a real fork. Look at rtLinux, uClinux, and all the other actual kernel forks before crying wolf.
Assuming your little Big Company conspiracy theory is correct, auto-makers have too much lobbying pull to allow EV retrofitting kits for older cars to be legal.
But how can GM make money when owners can rebuild the drivetrain so easily?
So your theory is that car companies make their cars difficult to fix in order to make money on service. Explain to me, then, the push towards the leasing model, where most drivers of new vehicles get a new car before the warranty term ends? Most off-lease vehicles end up on the auction block, and the manufacturer and dealership have already made their money off of them. Depending on which company you're talking about, car companies make their money either on margin, or financing. Cars are becoming disposable, and that doesn't support service revenue.
Slashdot Mirror
No arguments from me about why it makes things more stable. All I was saying is that it's the software that's tied to the hardware and not the other way around.
The only problem I have with Apple is the tight relationship between hardware and software. Yes I know this allows the computer to be much more stable.
That, of course, is bull. There is only a one way relationship. Apple software is tightly related to the hardware, but the hardware is as general purpose as any PC, and can run whatever software you care to run on it.
Equally dumb if you ask me.
If a game is available for the PC, how is it an Xbox exclusive again?
I'd love to believe everything you've said, but I think you give people too much credit. Somebody called it "Frankenfood" and everybody ran away. They didn't know about or understand half that stuff you're talking about.
and a trackball
I prefer the mouse, but I turn up the acceleration to obscene levels. It has the same effect as a trackball of having only finger movements, but without annoying me. I you hate trackballs, but don't want to hurt your wrists, you should try it.
Firm cardboard doesn't sell as tomatoes, no matter how bright red.
Yet it works for strawberries... I think that the lack of flavor is just an add on to an already sad story. They didn't succed because of the GM, and to make matters worse they didn't taste good. Hell, bigger and better looking sells every other thing in the produce department, why would tomatos be any different? Most people don't know what a fresh grown tomato tastes like anymore anyway.
This is all well and good untill somebody starts calling it "gene-laundering" or some other such unflattering name that implies that it's just sneaky GM, and nobody will eat this stuff either. Especially if it's essentially the same result. The real problem is that people oppose things they don't understand by default.
Even if new indie labels start to catch on, that still won't account for the massive back catelog.
Two words: Compulsory License
The sooner it happens the better.
I made one once back in grade school as a science fair type of project. We used a glass jar as the frame, and some cloths hanger to suspend it so it was all visible. It sounded.... interesting. The jar directed the sound quite well, but it sounded like the whole thing was in a deep hole in the ground. Great for demonstration purposes though. using the jar ring (it was a ball style jam jar) and hanger made it so you don't need all that stuff about the metal plates.
I was amazed that O'Reilly did not even have a book on it.
That's because the definitive text, by LaTeX author Leslie Lamport, was published in 1986 by Addison-Wesley two years before O'Reilly got into the publishing business. Nobody's seen a need to improve on it I guess. Interestingly enough, Leslie Lamport works at Microsoft now, so I would assume if he published any new books on LaTeX they'd be Microsoft Press.
Once you get into more advanced usages, The LaTeX Companion is a good second book to pick up.
Like I said, I don't know why I'm arguing with you. It's clear you have a decent grasp of some of the basic building blocks, but are having a hard time seeing the big picture. If you have multiple processing phases that require knowledge of data from the next frame, you can process them in series, adding at least a frame of latency for each effect, or you can get a more powerful processor that has the capability of applying all the effects you need at the same time. You may not be able to combine a decode operation with a transform operation, but two transform operations can typically be reduced to a single operation that could have a latency less than that of performing the two operations seperatly.
Any additional frame of latency will require an additional frame buffer. Believe me, in current technology there is no sweet spot which asks for increase the number of framebuffers over the bare minimum. ... I believe you have no idea of the algorithms.
...blah blah blah... and the die size ... blah blah blah... increases the die size by a two digit percentile and does thus drive yield down and cost up
What part of "I was only using an entire frame as an example" don't you understand?
Wait, why am I arguing with you again? Here's the deal. The processor they're using has a latency that's so high the audio is out of sync by up to four frames depending on which effects you enable. There's no point in arguing anything else, especially since it's clear that you have no idea what actually goes in to choosing parts to design a complex device. If you can't see that's caused by processing latency you need to go back to school and take some signal processing classes again. As for the mystical algorithms you think I don't understand, if the latency is due to a series of effects processors, it doesn't matter one bit what algorithms they use. They're in series. Their latency is additive. If a set manufacturer chooses to purchase a bunch of single purpose chips because they're less expensive than an all in one chip there's no algorithm to get around that.
Oh, one last thing:
The largest portion of the cost of these chips is the manufacturer's margin. They're made with old technology left over from two years ago's cutting edge computer silicon. These aren't last weeks athlon where the competition keeps the margin down. What makes the price different between two devices is how much of a premium the manufacturer can get away with charging for their value add, and not how many framebuffers (or whatever, there may not be even one framebuffer in the sence you're thinking) are on the chip. On top of that, the chip is only a fraction of the board cost, and so on.
I think the other poster in this thread was right, and everything you "know" about this stuff you learned from reading poor marketing descriptions of high end video cards. I'll give you a hint. You don't really know how those work either unless you make 'em, because they don't tell you half of how they do what they do. It's called keeping trade secrets.
I used a frame in the example for ease of understanding. What the processor actually uses is something they don't make public knowledge. The issue at hand (the difference between throughput and latency) is the same, so using a frame made for an easily understandable example.
framebuffers are expensive, you do not want to increase the number over the bare minimum.
Actually there's a cost analysis equation that the manufacturer would use that is likely a bit complex. As you slow down each stage, you can use slower (read: cheaper) memory for your buffer. Also, slowing down the chip as a whole may reduce costs more than the increase caused by adding buffer. To complicate things further, you can make design decisions that allow you to reduce your overall component cost by, for example, sharing an oscillator with a communications component. These are specialized devices with tightly integrated designs. You can't make assumptions about which parts are driving the cost. It may not even be obvious to the designer without running the numbers.
The delay is not caused by cheap processors, that is a myth. Just think about it, even delaying the video by 1 second will not reduce the required processing power...
We're talking latency here, not throughput. They're two seperate things.
Let's say you have a pipeline of frames you're processing. There may be multiple frames in flight at different stages of processing. The longer it takes for for a frame to enter in one state and leave in it's final state doesn't nescicarily have any impact on the number of frames you can process per unit time if you increase the number of frames in flight. A processor with fewer steps of the same length along the processing path, or a processor that can complete each step more quickly will reduce the latency. Such pipelining is a common technique for increasing the latency of an operation in exchange for throughput.
Nuclear energy plants are costly and time consuming to construct. Furthermore,there is the cost of the distributing the hydrogen.
Ever seen a natural gas pipeline? Do you know what it takes to get fossil fuels to their destination? Hydrogen can be easier than all that. Don't underestimate the ability and willingness of people to make energy available for usage.
Realistically, the days of large and heavy vehicles powered by engines of >200 hp (such as typical SUVs) are numbered.
As far as percentage of portable energy consumed, SUVs likely use a fraction of a fraction of one percent. Realisticaly, if we can't generate and transport hydrogen in such a way that makes it affordable for SUV drivers, there's no way it'll be affordable for everything else.
Maybe it makes you furious because, if not for the reasons he states, he has a point.
Why do people tout lifestyle changes that people will *not* accept instead of looking for solutions that people will accept or pushing for ones we've known about for ages.
NPR, the other day, had a 5 minute segment about Bush administration plans to switch cars over to Hydrogen fuel cells over the next 20 years. Their expert (a reporter from the New York Times) said, and the basis of the story was, that the proposal would result in *more* polution, not less, since we use coal to generate the majority of our electricity and you need either electricity or natural gas to generate hydrogen. There was not a single mention of nuclear power, which is a technology we know well that can fix almost all of our climate change problems without altering lifestyles. The problem is that it's politically unpopular. But scientists are supposed to be immune to political pressure and focus on objective results, huh?
So maybe your infuriating parent poster there is right, but instead of the money influencing what they say, it influences what they leave out.
The software overhead for RAID1 should be, for all intents and purposes, insignificant. It just doesn't *do* anything that requires much CPU work.
What it does is blocking. A good hardware raid mirror will have a battery backed up cache so it can acknowledge the write as successful either immediatly or after the data is on one disk, which a software raid setup can't do reliably. What you end up with is the additive rotational latency for two disks, which can signifigantly hurt performance for small random access writes.
Of course, in many cases this is perfectly acceptable.
So, having a redhat.com e-mail address makes you more of an authority on the kernel than not having one? I'd think it'd be the other way around. Working at redhat would give you a little bit of bias in this argument I'd think. Just because I chose to write linux code under contract for signifigantly more money than I would be making writing code for redhat doesn't mean I don't know what I'm talking about. So, he wrote some device drivers that a lot of people use. So have I.
Of course being anonymous, I have no way to verify, but I assume you have no idea what my employment background is, or how much of my code is in which kernel trees.
Go away.
Wrong. The drivers and subsystems I maintain in the Linux kernel are all for the most commonly used hardware.
Read it again. I was being sarcastic.
First, this was documented in both release notes and the rpm changelog.
Really? Where? In the initial release of RHAS, it was not listed. Period. Many of the entries in the kernel source RPM had a date and the nameof the person who applied the patch, but no text. Hardly well documented. Were it well documented I'd have no complaints.
An upstream 2.4 block, scsi, or net driver drops into RHEL kernels with zero modifications. I do this all the time, with all three of these classes of drivers (block/scsi/net). It is a hardware vendor's choice to create 2.4-backport-specific modifications to their driver, with the additional maintenance that entails.
It sucks when you try to use a third-party md personality that assumes your 2.4 kernel has a global request list lock, and it compiles, loads, and crashes randomly on your RedHat kernel, or worse, silently corrupts your data. It's not as backwards compatible as you'd like.
Apparently you have no clue who writes Linux device drivers.
Apparently on this point you are correct. I don't keep up to date with a comprehensive list.
Wrong. Backporting drivers has been fantastically useful to me.
Right. And let me guess. You use all sorts of specialty hardware.
You're missing the entire point. This isn't about community written drivers, it's about third party drivers. Believe it or not, but there are some devices that the community can't/won't write drivers for, and there's a variety of reasons ranging from patented algorithms, to lack of popular interest, or just plain lack of skill in the case of some specialty devices where there are only a few people who really understand how it works. We're not talking about your little file server with IDE disks and last years processor and chipset or whatever it is you have.
I suppose your definition of "notorious" includes upstream 2.6 driver interfaces
Yes, yes it does. When you do something like port just the per block device locking from the 2.6 SCSI mid-layer back to 2.4 for your vendor specific release and don't put as much as a release note or a long file name on the patch in your source tree, all the while making something that's incompatable with both versions, you make it very difficult for outside companies to write interoperable drivers. If you wrote drivers for linux, you'd know this, and that's what "notorious" means.
Wrong. It exposes new features to more users.
From the perspective of somebody who only uses relatively common devices, it may seem like that. But once you need a device that's only supported in Solaris or Windows, and the vendor tells you it's too labor intensive to support linux, you'll understand.
Backporting 2.6 features helps everyone because it subjects those features to more testing, meaning that 2.6 will be better as a result.
Unlikely. Testing of features that have been hacked back into an older kernel won't provide representative results. You'll only find the most glaring of bugs through that kind of testing, and the hope typically is you find those before you put them into production anyway.
The real effect of backporting features is that it scares off third party developers. Companies that want linux drivers for their devices have to pick a version to work with. RedHat's backports are notorious for changing things in the driver interfaces. That means a vendor, who may not be informed as to the dynamics of the kernel development process, may choose to support only RedHat's version of the kernel, to speciffically not support RedHat's version, or worst and most likely, to not support linux at all.
I've done consulting and contracting for all three types of companies, as well as one who tried to support both RedHat's tree and Linus' tree from the same code base, and believe me when I say that it's a mess. Let's just hope that somewhere along the way RedHat decides to pick a versioning scheme that makes it easy to tell their features are in there at compile time, and starts providing change logs so you can figure out what they've done. As of right now their stuff is a nightmare.
LinuxPPC is merged back in periodically too. Hence the reason that forks of Linux don't have the effect forks of Unix did. They're not all hiding their work from each other, and they're all allowed and willing to take the good from another fork and incorporate it into their own trees. Even if they don't, users are free to if they wish. Forking can be healthy in a free software environment.
RedHat has been backporting patches forever. That doesn't make it a fork any more than the actual kernel forks. Look at the LinuxPPC tree for an example of a real fork. Look at rtLinux, uClinux, and all the other actual kernel forks before crying wolf.
Kernel forks don't kill the kernel.
You're joking, right?
Assuming your little Big Company conspiracy theory is correct, auto-makers have too much lobbying pull to allow EV retrofitting kits for older cars to be legal.
But how can GM make money when owners can rebuild the drivetrain so easily?
So your theory is that car companies make their cars difficult to fix in order to make money on service. Explain to me, then, the push towards the leasing model, where most drivers of new vehicles get a new car before the warranty term ends? Most off-lease vehicles end up on the auction block, and the manufacturer and dealership have already made their money off of them. Depending on which company you're talking about, car companies make their money either on margin, or financing. Cars are becoming disposable, and that doesn't support service revenue.