Many in these forums cried foul against this form of vigilante justice, and rightly so because vigilante justice is no justice at all. Even when the shoe is on the other foot, as it appears to be in this case, it still makes the act of dispensing justice, without the backing of our legal system, wrong.
This isn't justice, it's revenge. Sweet, sweet revenge.
Intel is banking heavily on people finally ditching x86 for good. There are good reasons for people to ditch x86, but there is one good reason to keep it: Legacy Support. How important that is will depend on the person and their needs.
Ironically, 64-bit processors are also the best time in the next 5 years to ditch the worst of the cruft with the 8086. I seem to remember, in fact, that the Opteron is doing exactly that --- IIRC, some of the legacy operations are simply not supported while the processor is in 'pure' 64-bit mode.
I would speak with specifics but AMD still hasn't sent me my copy of the hammer specifications and programming guide.
You also? I ordered mine around the middle of August, but the only thing I've heard from them since was an e-mail in October saying it was "finally available" and that they'd be shipping to my correct address.
If you fill a glass to the brim with water, and ice sticks above the rim of the glass, the glass WILL overflow when the ice melts.
-1, Wrong.
The block of ice floats because it displaces as much water as the ice weighs -- if a glass of water is at a given level with a block of ice of mass X grammes in it, then removing the block of ice would require one to put X grammes of water back in the glass to return the liquid to the same level as with the block.
As the block of ice melts, the water from the melting will combine with the water in the glass, tending to increase the water level in the glass -- however, there is now less ice in the glass, so it displaces less, tending to decrease the water level in the glass. As it so happens, for ice the equation is balanced and there ends up being zero net change in the water level -- as in the above example (removing the block), we just happened to remove the block (X grammes) by melting the ice (returning X grammes of water).
This isn't the complete story with regards to the ocean, of course, because the ocean isn't pure fresh water -- but the effects of melting ice in seawater would still be orders of magnitude less than you're predicting with an 'overflowing glass of water'.
It is very likely that the OS is going to be modularized into abstraction modules and service modules,
But the point still stands that one cannot write something that is merely an application and call it an 'OS Replacement'. To prove his point that this computing metaphor is a suitable replacement for the filesystem, he has to go and show that it is both possible and (relatively) efficent to write the base operating system in a method that complies with this model -- that, IMHO, is a much more challenging and worthy task.
It is one thing to talk about changing the representation of data as presetned to the Average User of the system -- it's done all the time, at least in small ways (e.g., a Web Page is an entire unit to be dealt with by the user; there is no longer separation into the HTML file, the image files, the CSS file, etc.). It is entirely something else to argue that this new method of data representation is robust and efficent enough to be useful in the implementation of an operating system.
First there was the pumpkin PC, then the Dune book, and now a story that takes pertains only to NJ. I am officially suing slashdot for breach of contract.
Now will someone who reads the relevant language tell me what, if anything 'kjafd' means? Links to other reports were all in a very similar vein, although the 'kjafd' part changes in a nonobvious pattern.
lie. I've used Windows enough that I can imagine what they are trying to do in my head, so I just fake that I'm doing it while actually doing the equivalent in Linux.
I've been in a similar situation, right up until the point where they asked me exactly what the error message on their special PPPoE software said -- being unable to fake that [although the error was a generalized 'no connect', it obviously wasn't specific enough to fool them], I faked a catastrophic system crash and called back later after digging up a Windows system for the support.
I hate to say it, but lately it's becoming more and more obvious that Intel is no longer really interested in performance. They'll squeeze a bit more out of an ancient architecture and add a few buz words like "SSE2", so they can slap on a hefty price-tag.
Bah. SSE2 may be a marketing-ism (especially with the 'We make the Internet go Faster ' slogans), but the underlying technology is relatively neat.
Back in Ye Older Days, processors had a physical limit of one set of effective operaands per instruction -- SISD, Single Instruction, Singe Data. One could add two numbers together to get a third, but adding n sets of two numbers together would take n instructions.
Then came MMX (on the x86 -- other architecturs have equivalents) -- this extended the x86 architecure by basicially co-opting the (64-bit) FPU registers for SIMD, Single Instruction Multiple Data, instructions, on 8 bytes, 4 shorts, or 2 ints at the same time. A single PADDB instruction can now add 2 sets of 8 bytes at once, for example.
This was a Good Thing, but there is one obvious limitation -- it doesn't work for floats. Thus begat SSE, which adds 128-bit XMM registers to the processor to deal with SIMD floats in much the same way that MMX deals with ints. SSE also adds non-blocking writes to memory and other cache-control bits, but those aren't particularly important in this paragraph.
SSE2 came about when it was decreed that SSE would be extended to handle all datatypes. With SSE2, introduced in the P4, the XMM registers can handle basically all interesting datatypes (with the exception of BCD, which really should die). I'm not so sure about you, but I think that performing operations on 16 bytes at a time _may_ be a performance boost, no?
In short, x86 has its architectural problems, but for the time being it's far more efficent to keep improving what we have rather than start a completely new architecture. In fact, that's what Intel tried with the Itanium, and we all know how successful that venture's been.
Of course RISC processors are so much nicer to work with because of their large, flat register files (at least 16 or 32 registers, all of them equally usable), but that's not possible with existing x86 architecture.
Although I would like to take this opportunity to point out that AMD's X86-64 (Opteron) architecture increases the number of gp and xxm (used for SSE instructions) registers up to 16 each.
I don't like that the function you've called is named "findPerson" - wouldn't it be far better to call it something like "findPersonByFirstName"? Or "findFirstPersonWithFirstName"?
Actually, I think it should be called findTheFirstPersonWithTheFirstNameThatIsSpecificed ByTheFirstArgumentToThisFunctionCallAndThereAreNoM oreArguments_TheFunctionThrowsPersonNotFoundExcept ionIfItCannotFindThePersonWhoseFirstNameYouSpecify
There is something to be said for short function names.
1. - they may put their common carrier status at risk; and,
Firstly, common carrier status comes with the _requirement_ of content-blind transportation.
Secondly, the only reason the RIAA has a case here is that I don't believe it's been established that Internet backbones posess legal common-carrier status yet; it's been talked about and assumed, but I don't think it's been codified into law. If we get a reasonable judge on this one, common-carrier for networks may become the legal precedent.
This makes sense, but I don't understand why they didn't make the default behavior equivalent the break, and provide a "fallthrough" keyword or something similar that does the same as the default requirements.
I'll admit -- what you describe is very technically possible. However, implementing this would make the language more complex than necessary.
Firstly, implementing something like this would put an 'implicit break' at the end of each case-list of statements. Doing this would crack the program sequence of C-code, in that (unless specificially altered by the deliberate use of a control statement by the programmer) the lexically next statement is always the chronologically next statement. Admittedly, this specific case wouldn't have _too_ much of an impact on code writing, but for the language in general the statement 'program instructions are executed in order' becomes 'program instructions are executed in order EXCEPT when it's part of a switch statement.' It's inelegant, and doing something like this to solve this particular problem could lead to similar stopgap solutions for other preceived problems, and before long we may as well reintroduce the unlimited goto.
Secondly, introducing a specific keyword for this function means that all C programmers would have to learn YAK (Yet Another Keyword). No existing keyword serves a similar purpose as fallthough (continue being reserved only for loops, and 'switch' is most definitely not a looping construct), and the addition of any new keyword in a language should come only after much debate -- with too many keywords, programmers learn only a subset of the language, and you get 'dialects' of the language based on coding style.
In my opinion, modern compilers should catch this kind of thing (when possible) and, on suitably detailed warning levels (such as -Wall or -Wstudent [yes this one's made up]) should emit a warning. Although a prime source of small errors in code, constructs like these (and assignment-in-ifs) have their uses. Expressly dealing with them makes the language more complex than it needs to be, IMO, and forbidding them takes power from the programmer -- better to recognize and warn (if told to do so), but otherwise compile just fine.
What do the Feds get from forcing mass change to HDTV?
They get the spectrum back. Currently, TV stations got their spectrum as a freebie from the government, way back In The Day.
Now, they're getting HDTV spectrum for free, with the requirement that they'll be forced to shut down their VHF/UHF transmission someday and return the spectrum. Unfortunately for the FCC (and the boradcasters that have to maintain two sets of transmition equipment) HDTV is not being adoptes as quickly as even the slowest projections said it would be -- currently, we're not on track _at all_ for there to be enough adoption for the FCC to force the shutdown of analog broadcasts.
In the meantime, the FCC has giveen a relatively huge band of valuable spectrum away, with little hope of recovering the huger band held by current analog broadcasts. Therefore, they're trying to take steps to speed adoption in any way they can.
If the market isn't willing to pay for digital television, is there really a compelling national reason to mandate it?
In the FCC's mind, Yes. All the improvements to the TV-signal you listed (color, stereo) have the advantage of being completely backwards-compatible with older broadcasts. Presuming it still physicially functions, there's no reason a TV from 1940 shouldn't be able to watch VHF signals today.
What the FCC's trying to do here is _replace_ the TV standard, not extend it. For the moment, all TV stations have two channels (and frequency bands, by extension) -- their normal VHF or UHF analog band, and a HDTV band. Once the conversion is complete, the FCC will order the VHF/UHF transmitters shut down and the frequency returned for whatever use the FCC deems appropriate. By its very nature, this conversion is _not_ backwards compatible.
It's too far along for the FCC to pull the plug on HDTV, but the transition isn't moving quickly enough that the FCC currently has hope of killing analog TV within our lifetime. Therefore, this move.
Of course, the question now is whether there's enough turnover in TVs that just mandating digital receivers (which are distinct from the display equipment required for the HD signal -- you'll likely be getting analog quality display on the HD signal) will increase the digital market penetration quickly enough to avoid the next boondoggle.
I have always looked at the default fall-through behavior of the case in C as a design error - a complete disaster waiting to happen.
Why is it so?
Because Original C is almost completely a block-structured language. With very rare exceptions (that tend to involve comma-delemited lists of statements), all control structures control a single statement -- the beauty of C, however, is that a block is acceptable in any case a single statement is allowed.
As this relates to the switch/case statement, it becomes a question of what exactly each component can control. The switch statement has to control a list of something, obviously, because it has to contain the cases. What the cases control is a more interesting question.
If the case controlled a statement/block, such as what happens in Pascal, then we end up with code that would look something like this:
switch foo {
case bar { ....
}
case baz { ....
}
}
With structure like that, there is no mechanism for fall through, even explicitly -- using a goto would involve gotos between a block and its sibling (instead of its ancestor), which creates spaghetti-code problems with gotos all over again. The only way that the language could implement fall-through would be through a new explicit statement to do so, and taking that route too many times leads to PL/I or APL.
Kernighan and Ritchie, the designers of C, were expressly designing the language for systems programming -- operating systems and compilers. These people want (and even need) a language that is both high-performance and flexible. To them, a "weak switch," one that allows fall-through, was potentially useful and came at neither a performance nor complexity (of the language) price.
Therefore, the optimal decision was to implement switch controlling a block of statements, with the innovative implementation of cases as labels within those statements. Programmers who used C were supposed to understand what this meant for fall-through, and although I'm sure they made the mistake of leaving out a break occasionally (just as often as Us Normal People leave out semicolons or the like), the error it caused wouldn't be impossible to find or fix.
Sad to tell you, but you will either have to upgrade within the next couple of years or buy a digital converter. There's a regulation that requires all broadcasters to broadcast in digital by a certain date. After which, all current tvs are obsolete.
Except for the caevat that the cutoff date is extended indefinitely, until at least 80% of households can receive the digital signal. In the meantime, starting quite soon all [at least primetime] broadcasts are sppposed to be HDTV, so television stations will have to maintain the second HDTV transmitter out-of-pocket alongside their old analog one. Not to mention any backups, master control equipment, microwave links _to_ the transmitter, etc.
When this roadmap was first being laid out, I don't think anyone expected the adoption of HDTV to be as slow as it has been. Presumably by now, everyone above the median income would have a fully-digital television experience, and be pressuring the stations/networks for full HDTV broadcast. Goes to show you how easily consumer intertia and corporate bungling can completely derail a good thing.
The Ogg software may (I haven't looked) make downcoding more convenient to do, but I doubt the CPU savings will actually matter to anyone. CPU is cheap. Wait - it just got cheaper. Wait - there it goes again.
True, but I'd shudder to think of you trying to serve something like every bitrate from 30 up to 160, in 5kbs increments.:) I'd also imagine that something like what you're doing would be rather difficult on an old P1 laying around as a router; you're still using a relatively beefy system for this.
Secondly, and unfortunately, these tools aren't out there yet. The file format supports them, but unfortunately there isn't even a good production quality streamer yet (with icecast2/ices2 still in CVS alpha only), which I fear is hurting the adoption significantly among the people best suited to push it. Even new versions of winamp ship with an ogg decoder, I hear, so the switch could be done near-seamlessly if the tools were there. (You hearing this, Xiph?:))
Do you actually know that this is so? I know that one of the goals of the MP3 design is streamed play in fact that's pretty much how it works so I would say that this claim is bogus. They are probably about the same, with OGG slightly better if you consider that it probably takes less bandwidth to get the same quality, but even then it's debatable.
This is true when we're talking about entire files -- a 160kpbs mp3 file will take just as much bandwidth as a 160kpbs ogg file, even if the ogg file has higher effective quality.
However, we're not talking about the entire file, with regards to streaming. After all, streaming is a realtime application limited by bandwidth -- this is why we don't see many 160kps mp3 audio streamers lying around all over the place; streaming is only effective at a bandwidth that your listeners have, which is why we see a proliferation of 128kpbs stremers (for broadband), or even sub-56k streamers for modem compatibility.
This bandwidth crunch presents us with a dillema -- the audio files are best stored at a high bitrate, to preserve whatever quality they may have had in the first place (coughSpearscough), but they're best streamed at low bitrates, so people can actuall hear the music. For the mp3 format, the most common way around this is called "re-encoding" -- literally, a piece of software reencodes the 160/whatever kpbs mp3 into the desired streaming format. It works, but it's an ugly solution -- even if there isn't any extra quality loss due to double-encoding (I'm not informed enough on the details of the mp3 format to tell), the reencoding process is quite CPU intensive. Lower-end systems cannot manage it in realtime, and higher-end systems can only do one or two encodings at the same time, preventing a single system from effectively serving a stream at 160 and 128 and 64 and 32kps versions, let alone multiple streams at all those bitrates.
Enter ogg. The ogg format supports peeling of the stream, because of the way data is stored. IIRC, the most important data is stored at the beginning of the audio frame (which is on the order of a fraction of a second in length), so with only minor processing it's possible to truncate the rest of the frame and get a perfectly servicable, albeit quality-reduced, ogg file at the lower bitrate of your choice. With marginal processor overhead, our theoretical streamer could probably support dozens of streams at arbitrary bitrates (capped by the initial quality of the file), without any overhead of the reencoding process that mp3's need.
There's only a couple minor flaws. Firstly, there's no set of tools out there that supports this peeling. Secondly, there's only marginal software out there that even supports ogg streaming -- so far as I know, we're limited to an alpha version of ices2, whose ancestor (ices1) is a mp3-streamer for their (Xiph's) icecast server.
Hopefully with 1.0 now out, we'll see some work on these tools may well be vital for ogg adoption.
Slashdot Mirror
No, it goes to two because it'll be reposted.
This isn't justice, it's revenge. Sweet, sweet revenge.
Ironically, 64-bit processors are also the best time in the next 5 years to ditch the worst of the cruft with the 8086. I seem to remember, in fact, that the Opteron is doing exactly that --- IIRC, some of the legacy operations are simply not supported while the processor is in 'pure' 64-bit mode.
Sure, but precision happens in the floating point units (and SSE(2) vector unit); 64-bit integer registers won't help with float precision.
You also? I ordered mine around the middle of August, but the only thing I've heard from them since was an e-mail in October saying it was "finally available" and that they'd be shipping to my correct address.
No books.
And in a real feat of obscure knowledge, I'll identify this as the joke told in the SimCity 2k credits.
-1, Wrong.
The block of ice floats because it displaces as much water as the ice weighs -- if a glass of water is at a given level with a block of ice of mass X grammes in it, then removing the block of ice would require one to put X grammes of water back in the glass to return the liquid to the same level as with the block.
As the block of ice melts, the water from the melting will combine with the water in the glass, tending to increase the water level in the glass -- however, there is now less ice in the glass, so it displaces less, tending to decrease the water level in the glass. As it so happens, for ice the equation is balanced and there ends up being zero net change in the water level -- as in the above example (removing the block), we just happened to remove the block (X grammes) by melting the ice (returning X grammes of water).
This isn't the complete story with regards to the ocean, of course, because the ocean isn't pure fresh water -- but the effects of melting ice in seawater would still be orders of magnitude less than you're predicting with an 'overflowing glass of water'.
But the point still stands that one cannot write something that is merely an application and call it an 'OS Replacement'. To prove his point that this computing metaphor is a suitable replacement for the filesystem, he has to go and show that it is both possible and (relatively) efficent to write the base operating system in a method that complies with this model -- that, IMHO, is a much more challenging and worthy task.
It is one thing to talk about changing the representation of data as presetned to the Average User of the system -- it's done all the time, at least in small ways (e.g., a Web Page is an entire unit to be dealt with by the user; there is no longer separation into the HTML file, the image files, the CSS file, etc.). It is entirely something else to argue that this new method of data representation is robust and efficent enough to be useful in the implementation of an operating system.
First there was the pumpkin PC, then the Dune book, and now a story that takes pertains only to NJ. I am officially suing slashdot for breach of contract.
You must be new here.
http://www.intentia.com/w2000.nsf/files/kjafd_0210 _us.pdf/$FILE/kjafd_0210_us.pdf
Now will someone who reads the relevant language tell me what, if anything 'kjafd' means? Links to other reports were all in a very similar vein, although the 'kjafd' part changes in a nonobvious pattern.
I've been in a similar situation, right up until the point where they asked me exactly what the error message on their special PPPoE software said -- being unable to fake that [although the error was a generalized 'no connect', it obviously wasn't specific enough to fool them], I faked a catastrophic system crash and called back later after digging up a Windows system for the support.
2*dwn_ld + 2*src_build = 2(dwn_ld + src_build)
No, because it was stipulated that the Deb system is building from binary packages -- no compiling.
My opinion of Gentoo: Very nice distro, and one I'll use personally, but it's not for anyone who wants their computer to Just Work.
Bah. SSE2 may be a marketing-ism (especially with the 'We make the Internet go Faster ' slogans), but the underlying technology is relatively neat.
Back in Ye Older Days, processors had a physical limit of one set of effective operaands per instruction -- SISD, Single Instruction, Singe Data. One could add two numbers together to get a third, but adding n sets of two numbers together would take n instructions.
Then came MMX (on the x86 -- other architecturs have equivalents) -- this extended the x86 architecure by basicially co-opting the (64-bit) FPU registers for SIMD, Single Instruction Multiple Data, instructions, on 8 bytes, 4 shorts, or 2 ints at the same time. A single PADDB instruction can now add 2 sets of 8 bytes at once, for example.
This was a Good Thing, but there is one obvious limitation -- it doesn't work for floats. Thus begat SSE, which adds 128-bit XMM registers to the processor to deal with SIMD floats in much the same way that MMX deals with ints. SSE also adds non-blocking writes to memory and other cache-control bits, but those aren't particularly important in this paragraph.
SSE2 came about when it was decreed that SSE would be extended to handle all datatypes. With SSE2, introduced in the P4, the XMM registers can handle basically all interesting datatypes (with the exception of BCD, which really should die). I'm not so sure about you, but I think that performing operations on 16 bytes at a time _may_ be a performance boost, no?
In short, x86 has its architectural problems, but for the time being it's far more efficent to keep improving what we have rather than start a completely new architecture. In fact, that's what Intel tried with the Itanium, and we all know how successful that venture's been.
Although I would like to take this opportunity to point out that AMD's X86-64 (Opteron) architecture increases the number of gp and xxm (used for SSE instructions) registers up to 16 each.
I'll take 3.
"What is the airspeed of an unladen Greyhound?"
Actually, I think it should be called findTheFirstPersonWithTheFirstNameThatIsSpecificed ByTheFirstArgumentToThisFunctionCallAndThereAreNoM oreArguments_TheFunctionThrowsPersonNotFoundExcept ionIfItCannotFindThePersonWhoseFirstNameYouSpecify
There is something to be said for short function names.
Firstly, common carrier status comes with the _requirement_ of content-blind transportation.
Secondly, the only reason the RIAA has a case here is that I don't believe it's been established that Internet backbones posess legal common-carrier status yet; it's been talked about and assumed, but I don't think it's been codified into law. If we get a reasonable judge on this one, common-carrier for networks may become the legal precedent.
I'll admit -- what you describe is very technically possible. However, implementing this would make the language more complex than necessary.
Firstly, implementing something like this would put an 'implicit break' at the end of each case-list of statements. Doing this would crack the program sequence of C-code, in that (unless specificially altered by the deliberate use of a control statement by the programmer) the lexically next statement is always the chronologically next statement. Admittedly, this specific case wouldn't have _too_ much of an impact on code writing, but for the language in general the statement 'program instructions are executed in order' becomes 'program instructions are executed in order EXCEPT when it's part of a switch statement.' It's inelegant, and doing something like this to solve this particular problem could lead to similar stopgap solutions for other preceived problems, and before long we may as well reintroduce the unlimited goto.
Secondly, introducing a specific keyword for this function means that all C programmers would have to learn YAK (Yet Another Keyword). No existing keyword serves a similar purpose as fallthough (continue being reserved only for loops, and 'switch' is most definitely not a looping construct), and the addition of any new keyword in a language should come only after much debate -- with too many keywords, programmers learn only a subset of the language, and you get 'dialects' of the language based on coding style.
In my opinion, modern compilers should catch this kind of thing (when possible) and, on suitably detailed warning levels (such as -Wall or -Wstudent [yes this one's made up]) should emit a warning. Although a prime source of small errors in code, constructs like these (and assignment-in-ifs) have their uses. Expressly dealing with them makes the language more complex than it needs to be, IMO, and forbidding them takes power from the programmer -- better to recognize and warn (if told to do so), but otherwise compile just fine.
They get the spectrum back. Currently, TV stations got their spectrum as a freebie from the government, way back In The Day.
Now, they're getting HDTV spectrum for free, with the requirement that they'll be forced to shut down their VHF/UHF transmission someday and return the spectrum. Unfortunately for the FCC (and the boradcasters that have to maintain two sets of transmition equipment) HDTV is not being adoptes as quickly as even the slowest projections said it would be -- currently, we're not on track _at all_ for there to be enough adoption for the FCC to force the shutdown of analog broadcasts.
In the meantime, the FCC has giveen a relatively huge band of valuable spectrum away, with little hope of recovering the huger band held by current analog broadcasts. Therefore, they're trying to take steps to speed adoption in any way they can.
Score:
FCC: 0 -- Broadcasters: 0 -- Consumers: -1
In the FCC's mind, Yes. All the improvements to the TV-signal you listed (color, stereo) have the advantage of being completely backwards-compatible with older broadcasts. Presuming it still physicially functions, there's no reason a TV from 1940 shouldn't be able to watch VHF signals today.
What the FCC's trying to do here is _replace_ the TV standard, not extend it. For the moment, all TV stations have two channels (and frequency bands, by extension) -- their normal VHF or UHF analog band, and a HDTV band. Once the conversion is complete, the FCC will order the VHF/UHF transmitters shut down and the frequency returned for whatever use the FCC deems appropriate. By its very nature, this conversion is _not_ backwards compatible.
It's too far along for the FCC to pull the plug on HDTV, but the transition isn't moving quickly enough that the FCC currently has hope of killing analog TV within our lifetime. Therefore, this move.
Of course, the question now is whether there's enough turnover in TVs that just mandating digital receivers (which are distinct from the display equipment required for the HD signal -- you'll likely be getting analog quality display on the HD signal) will increase the digital market penetration quickly enough to avoid the next boondoggle.
Why is it so?
Because Original C is almost completely a block-structured language. With very rare exceptions (that tend to involve comma-delemited lists of statements), all control structures control a single statement -- the beauty of C, however, is that a block is acceptable in any case a single statement is allowed.
As this relates to the switch/case statement, it becomes a question of what exactly each component can control. The switch statement has to control a list of something, obviously, because it has to contain the cases. What the cases control is a more interesting question.
If the case controlled a statement/block, such as what happens in Pascal, then we end up with code that would look something like this:
switch foo {
....
....
case bar {
}
case baz {
}
}
With structure like that, there is no mechanism for fall through, even explicitly -- using a goto would involve gotos between a block and its sibling (instead of its ancestor), which creates spaghetti-code problems with gotos all over again. The only way that the language could implement fall-through would be through a new explicit statement to do so, and taking that route too many times leads to PL/I or APL.
Kernighan and Ritchie, the designers of C, were expressly designing the language for systems programming -- operating systems and compilers. These people want (and even need) a language that is both high-performance and flexible. To them, a "weak switch," one that allows fall-through, was potentially useful and came at neither a performance nor complexity (of the language) price.
Therefore, the optimal decision was to implement switch controlling a block of statements, with the innovative implementation of cases as labels within those statements. Programmers who used C were supposed to understand what this meant for fall-through, and although I'm sure they made the mistake of leaving out a break occasionally (just as often as Us Normal People leave out semicolons or the like), the error it caused wouldn't be impossible to find or fix.
Except for the caevat that the cutoff date is extended indefinitely, until at least 80% of households can receive the digital signal. In the meantime, starting quite soon all [at least primetime] broadcasts are sppposed to be HDTV, so television stations will have to maintain the second HDTV transmitter out-of-pocket alongside their old analog one. Not to mention any backups, master control equipment, microwave links _to_ the transmitter, etc.
When this roadmap was first being laid out, I don't think anyone expected the adoption of HDTV to be as slow as it has been. Presumably by now, everyone above the median income would have a fully-digital television experience, and be pressuring the stations/networks for full HDTV broadcast. Goes to show you how easily consumer intertia and corporate bungling can completely derail a good thing.
True, but I'd shudder to think of you trying to serve something like every bitrate from 30 up to 160, in 5kbs increments. :) I'd also imagine that something like what you're doing would be rather difficult on an old P1 laying around as a router; you're still using a relatively beefy system for this.
Secondly, and unfortunately, these tools aren't out there yet. The file format supports them, but unfortunately there isn't even a good production quality streamer yet (with icecast2/ices2 still in CVS alpha only), which I fear is hurting the adoption significantly among the people best suited to push it. Even new versions of winamp ship with an ogg decoder, I hear, so the switch could be done near-seamlessly if the tools were there. (You hearing this, Xiph? :))
This is true when we're talking about entire files -- a 160kpbs mp3 file will take just as much bandwidth as a 160kpbs ogg file, even if the ogg file has higher effective quality.
However, we're not talking about the entire file, with regards to streaming. After all, streaming is a realtime application limited by bandwidth -- this is why we don't see many 160kps mp3 audio streamers lying around all over the place; streaming is only effective at a bandwidth that your listeners have, which is why we see a proliferation of 128kpbs stremers (for broadband), or even sub-56k streamers for modem compatibility.
This bandwidth crunch presents us with a dillema -- the audio files are best stored at a high bitrate, to preserve whatever quality they may have had in the first place (coughSpearscough), but they're best streamed at low bitrates, so people can actuall hear the music. For the mp3 format, the most common way around this is called "re-encoding" -- literally, a piece of software reencodes the 160/whatever kpbs mp3 into the desired streaming format. It works, but it's an ugly solution -- even if there isn't any extra quality loss due to double-encoding (I'm not informed enough on the details of the mp3 format to tell), the reencoding process is quite CPU intensive. Lower-end systems cannot manage it in realtime, and higher-end systems can only do one or two encodings at the same time, preventing a single system from effectively serving a stream at 160 and 128 and 64 and 32kps versions, let alone multiple streams at all those bitrates.
Enter ogg. The ogg format supports peeling of the stream, because of the way data is stored. IIRC, the most important data is stored at the beginning of the audio frame (which is on the order of a fraction of a second in length), so with only minor processing it's possible to truncate the rest of the frame and get a perfectly servicable, albeit quality-reduced, ogg file at the lower bitrate of your choice. With marginal processor overhead, our theoretical streamer could probably support dozens of streams at arbitrary bitrates (capped by the initial quality of the file), without any overhead of the reencoding process that mp3's need.
There's only a couple minor flaws. Firstly, there's no set of tools out there that supports this peeling. Secondly, there's only marginal software out there that even supports ogg streaming -- so far as I know, we're limited to an alpha version of ices2, whose ancestor (ices1) is a mp3-streamer for their (Xiph's) icecast server.
Hopefully with 1.0 now out, we'll see some work on these tools may well be vital for ogg adoption.