Suppose you have something like a syscall number getting changed. Suddenly, all binaries compiled for a "vanilla" kernel need to be recompiled for the Redhat kernel. This is a massive undertaking.
This is a bit of an extreme example, but something like this is basically what people are afraid of -- having to basically "Redhat-ize" a system if they wish to run "Redhat-Linux" applications. It's NOT something you have to do now -- it's just a fear for the future.
The fear is that a version of Oracle will come out that depends on 2.6-ish kernel features but doesn't actually work on 2.6 proper (i.e. it has dependencies on 2.4-era semantics). At that point, the only way to run Oracle -- no matter your toolchain -- is to use the Redhat kernel.
Notice how refrigerators are sold with an estimate for how much electricity (in dollars) they'll consume per year? I promise you, Sears doesn't _want_ to put that data on the price tag; it's federally mandated that they do.
Expect the same kind of sticker shock to arrive for car insurance multipliers. In other words -- cars that are really expensive to repair, and thus insure, will be forcibly marked as such.
The exemption will come if the manufacturer offers to replace/repair in lieu of "third party repair shops" (who manufacturers despise anyway). Thus, manufacturers get into the replacement business.
Seriously, this is inevitable. Hell, it might very well have been the plan all along.
It's worth pointing out that profit margins for new vehicles are quite large -- I think the last figure I heard, on a variable cost basis, was $3,000 for a $20,000 car. Fixed costs are, of course, enormous -- R&D, testing, compliance, advertising, sunk costs in the factory, etc -- but whipping up one more Corolla is pretty cheap.
In other words, relief to the insurance industry will probably come via mandated replacements by the manufacturer, at cost (or maybe cost+10%). This could get worked into warranty programs, first as a perk, then as something greater.
Keep in mind, if your car is totalled, who's to say you'll buy the same brand next time around? Properly managed (i.e. worked into the cost of each car sold), this isn't a bad strategy for keeping customers loyal to your brand.
Manufacturer replacement is thus almost guaranteed to occur.
A whole lot of nothing (extending into the infinity before the big bang). Then a bang -- massive flare-out. Then everything slows down, and second per second we know a hell of alot less.
I'm just pointing out that, if you graph our knowledge / sources of information about the universe, it's 2D-toplogically similar to a trumpet. I'm absolutely not saying the cosmologists are wrong, just that it's an interesting coincidence that the output (shape of the universe) looks like the input (shape of the input data about the universe, which is by no means the same).
If your only light source on a dark street is a non-moving flashlight pointed slightly down, you wouldn't think the universe was oblong. Rather, you'd assume everything else was dark.
I'm saying it's a strange coincidence that they're postulating a universal shape that matches the distribution of incoming photons. Dark things still exist, you know.
Hmmm. The big bang posits a long period of time where everything is compressed, followed by an explosion which flares stuff out in all directions.
A long thin period, followed by a huge flare...that is sort of the shape of a trumpet. These are the guys who tell us that distance equals time, too...not to pretend to be a cosmologist, but isn't it possible that we're seeing a trumpet shaped universe because our input data (i.e. energy) followed a trumpet-shaped distribution curve over time?
Wow. Very cool. I was unaware of this particular failure mode for 802.11. I would have assumed that the exponential TCP backoffs would have slowed down the incoming packet rates enough for the system to eventually slow down to some reasonable rate... I bet, to some extent, hidden node played a _big_ factor here too.
Still, I'm amazed you saw not dropped packets, but the MAC hold onto stuff for thousands of ms. Wow.
You know, the newest Linux wireless drivers have moved _everything_ into software -- thus the ability to throw up an AP on demand. I've actually got an amusingly demented protocol hack that would address some of these shortcomings, quite transparently...any interest in collaborating? Send me an email.
Mesh networks aren't perfect, but the extreme low bandwidth of voice (8kbps for G.729) relative to the channel capacity makes up for quite a bit. Voice is way more sensitive to packet loss than delay, because almost nobody's implemented error concealment*. You notice the dropped signal on your cell phone way before you notice the absolutely atrocious latency you chug through.
Multisecond RTT doesn't happen on anything but GPRS, and that's because the actual core bandwidth is so slow (well, it's for many reasons, but ultimately ad-hoc networks of this scale are only a couple hops of megabit-class networking).
Ethernet frames move at the speed of light over the aether, and "Layer 1.5" 802.11 retransmission gives up after very few tries. Voice packets don't IP fragment, ever, because they're always way below the 576 minimum MTU size for IP networks. And, with only one absolutely batsh*t exception**, you'll never actually see voice routed over TCP -- you don't care about retransmissions in the voice domain.
Meshes aren't a utopia; they're an opportunity. Much like the Internet itself.
-Dan www.doxpara.com
* Avaya's VoIP implementation has. Dynamic jitter buffers are ludicrous. Disclosure: I work at Avaya. ** Exception = set tcp window size large enough that you don't actually ever need to retransmit. this lets you run voip through a firewall that's only allowing tcp/80, even if the firewall is looking for ACKs. You have to enable window scaling, though:-)
No, they're not accurate, but until the cost of not correcting data exceeds the cost of correcting data, they're not going to scrub anything. Nobody wants to be the guy who erased the terrorists from the database.
Zero of them actually attempted to destroy their flight. One of them would have been sufficient (the Shoe Bomber, for instance). The people tasked with finding this individual must thus be accurate to a level of one out of six hundred and forty one million.
But people do win the lottery, quite regularly in fact. Lots of people have to lose, of course -- that's what funds the thing -- but it's not a particularly rare occurance.
That's sort of the idea here. Given enough "losing tickets", we'll beat the odds. And even if we don't -- at least we tried (which, ultimately, is what all the controversy is about right now -- not whether we succeeded in stopping the attacks, which we obviously didn't but whether "we tried".)
Hate to quote Scott McNealy, but like the man who sells the servers that store all our personal information says, "You have no privacy, get over it." Everyone gave up the flight info, because everyone was damn near thrown out of business. That's the bottom line.
Yes, the nGage itself is a steaming pile of crap -- and everyone knew it, from the moment we excitedly tried it at GDC last year. And we all know the games for nGage suck -- Nokia, memo from 1987, sprite acceleration makes Puzzle Bobble play at speeds higher than 7fps. But what's not well realized is that, for all of the Gameboy Advance's massive library, the vast majority of the content is Atari-market-crash level crap, and most of the remainder is unplayable by anyone over the age of 14.
Don't believe me? I swear on everything that is true in this world that the following was excitedly exclaimed from a Fry's in Campbell, CA, just a scant few months ago:
"Mommy! Mommy! It's American Idol for the Gameboy Advance!"
The kid was ten. The game was not purchased.
Don't get me wrong. I own a GBA. Hell, it's my second one, since I lost my first one. There's a good dozen games on the system that are actually playable -- the Castlevanias, the Metroids, some of the work coming out of Squaresoft. But even if the hardware is the spiritual successor of the SNES, the software selection is embarassing, bordering on mortifying.
And Nokia knows all this -- they know there's a pent up demand for gaming that scales to people who don't need to beg for a candy bar. Sony knows this -- and could actually destroy Nintendo on a whim, simply by releasing a handheld Playstation 1 (and re-releasing a small chunk of the old library on new media). But everyone seems to be skipping a generation of failed machines (the "Don't Be Sega" effect?) and trying, better or worse, to do portable, multiplayer 3D gaming right.
And if you don't think MS is in this game, you're not paying attention to those "portable video players" with DRM support and space for a gamepad.
There's alot at stake here. I'm frankly surprised to still see Nokia still involved -- if nGage was any worse, the FCC probably would have refused to certify it on principal -- but you can't fault their recognition of the potential size of this market. Nintendo may have owned this space since the 80's -- but they've gone from the company that returned quality to video games ("Nintendo Seal of Quality" meant something) to... well, one that adds another screen.
Threw this on MetaFilter a few hours ago; hope this helps clarify what's going on here. Thanks to the good Jason Spence for explaining most of this to me over fine tequila at Defcon a few years back:-)
=== OK, terrible terrible story. Nobody's going to contest that. My immediate reaction: "Yay, another whiz kid story. Kid probably rediscovered prefetching web pages."
Yeah. Then the CoLinux guy came up.
People, CoLinux is absurdly brilliant stuff, the kind of hardcore engineers get drunk about and laugh that "some psycho pulled off WHAT?!" regarding. I can say this from personal experience:-)
To put it simply, most approaches that involve multiple operating systems sharing a processor require a significant degree of subordination. In the Cygwin model, the "Linux/Unix" way of requesting services from the operating system (open this file, give me that network connection) is translated to the Windows way through a library of functions. The mapping is pretty good, but like any translation, it's not perfect. Some actions, like starting new programs, are very very fast under Linux/Unix and are extraordinarily slow under Windows. Cygwin deals with this as best it can, but there's only so much it can do.
VMWare offers a different approach. Instead of translating Unix to Windows, VMWare creates a "virtual PC", complete with its own processor, motherboard, sound card, network card, and everything else. The child operating system -- Linux, for example -- gets a complete environment to manipulate, and VMWare handles the translation between what the child PC is asking to do and what the parent PC is actually capable of. This interface is much more isolated than what Cygwin offers -- memory, for instance, is not shared between the two environs -- but as such, the child operating system is freed of many of the particular quirks of the parent OS. The child Linux really is Linux, and can do everything Linux can do, because Linux is an environment for controlling a PC.
The only catch is that it's a virtualized PC, and VMWare needs to do alot of work to keep the two contexts separate -- and to emulate all the hardware resources that are normally "just there", but now need to be simulated. There's a 20-30% speed cut out of this. Also, switching contexts between parent PC and child PC is not a trivial thing to do, meaning it can only be done a certain number of times per second. This causes issues for some real time operations. Specifically, audio in VMWare is a problem.
CoLinux is something else entirely. x86 CPU's have the concept of Rings -- these are roughly analogous to privelege levels, in which certain classes of commands may be issued to certain components of the architecture. Lowest level code operates in what's referred to as "Ring 0" -- at this level of permissions, one can directly control the raw components of the PC, for better or worse. This is a gross oversimplification, but there's basically two things that live at Ring 0: A kernel, and device drivers (which are not entirely separate from the kernel). Kernels are basically a core set of commands that user software can execute to get things done -- create processes, read files, open network connections, and so on. Here's a list of Linux syscalls, at least from 2.2. Not on this list -- stuff like, "Send this block of memory to this device on the PCI bus, and tell the sound card to start emitting sound from that memory address on its internal buffer." That's what device drivers are for -- they get some kind of interface that userspace can talk to, and they do things with what they're given. Those things can be pretty much anything the underlying hardware can do -- stuff way deeper than "write this file" and "trace this process", and into the nuts and bolts of what the PC is -- a collection of wires and memory addresses. Normally, that's what a device driver does: It implements the requisite hardware calls to let some piece of equipment work.
Dude. Nested folders. It's 2004, we've had them for a while.
--Dan
Enough With The Forced Database Access
on
Linux for iPod Matures
·
· Score: 1, Interesting
Yeah. It's real great that Apple's willing to let me organize my music by Artist, Album, maybe Genre too.
F*ck 'em. I want folders.
I don't know how more clear to say it: When I get new music, I want it separated from my old music. I don't want to have to manage per-song playlists, and I certainly don't want to have to care about which single found its way into what Artist or Genre. The most insidious aspect of Apple's architecture (and that of the Rio Karma -- I had one of those too) is the degree to which it makes it so accursedly difficult to separate Singles and Albums, New and Old, Unfiltered and Validated, Fast Stuff and Slow. It's Apple's way or the highway.
Heh. Sort by purchase date, THEN tell me you've integrated iTunes well.
For what it's worth, LTC is a fantastically architected crypto library. The utter simplicity of what Tom puts together is disarming, compared to the utter horror that ships with (say) OpenSSL. Both Dropbear (a very small SSH server) and MatrixSSL (a very small SSL server) have been built on LTC.
Plus, you get a crypto lib with Makefile.gba. That's Gameboy Advance. Yup.
DVD-Audio is dead, AC3 w/ normal, copyable DVD's has won the day.
Something about that whole "anyone can master it" thing really excites the hordes of audio engineers that I know. "Hi, ten people will be allowed to work with this" technology tends only to be worked with by ten people.
By far, the most popular algorithm in use for surround sound encoding is Dolby's AC3 (I can say this, because it's on pretty much every DVD, and nothing comes close to its penetration even in the audio space -- not even DVD-Audio). AC3 itself is a pretty fascinating codec; one of the more interesting things about it is that each additional channel requires less and less bandwidth to tack on. This is because there tends to be massive correlation between channels -- either the same sound is coming from multiple directions, or a sound is coming from one direction and all the others are silent, or some combination therein. AC3 encodes this quite efficiently, and thus gets really high quality surround sound in surprisingly few bits.
I suspect they're engineering a similar mode for MP3 -- hopefully something a little nicer than Joint Stereo, which basically works by doing a mono mix and specifying which frequencies are louder in which channel. No, this doesn't work very well. Concievably, we could see something like VBR on a per-channel basis, but I suspect this would cause existing decoders to collapse. I do believe it's possible to place extra data between MP3 granules; I suppose they'll get their backwards compatible surround mode worked into there.
Comfort noise is missing on less advanced VoIP implementations.
Here's a link to the RFC that specifically describes how to send packets with comfort noise. Note that there's actually some work done to make sure the noise matches the spectral shape of what should actually be there. This prevents the noise from seeming "unusual" the the listener (i.e. it's not just random fuzz):
In terms of conversion and recompression, G.711 -- the "high bandwidth" version of VoIP, at around 64kbit per direction -- isn't even converted when it's passed to the PSTN network. It's only the higher levels of compression -- G.729, G.723 -- that need to be transformed at the proxy. And it turns out most of the failures happen one hop up from the DSL/Cable modem, because there's a huge amount of bandwidth coming in and relatively little to each endpoint. Something needs to be done about this, but it's not entirely clear what. Designing from the ground up -- yeah, we did that with the PSTN, and it's great, but there's so many legacy taxes that people are going to IP just to avoid regs written before the new tech was born.
Voice over IP actually creates some particularly hairy security problems that traditional approaches really, really don't manage well. Some disclosure: I work for Avaya, one of the big vendors of large scale VoIP systems, though much more for the enterprise market than for anything to do with the public space (Vonage, Packet8, etc).
Lets start by looking at the wire protocols. We have two separate domains within which VoIP operates: Signaling, which determines where a call should route, and traffic, which is the actual stream of speech that needs to arrive at its destination in under a tenth of a second. These are very different protocols. Signaling was originally implemented using H.323, which can be basically thought of as a port of the existing telephony protocols (SS7) to IP.
H.323 is...well...not entertaining to work with. It's a very messy protocol. To a first level of approximation, H.323 is being reimplemented with SIP, which applies the semantics of HTTP to VoIP signaling. SIP is still complicated, but in a more manageable way.
Whether one is using H.323 or SIP to route calls, the actual traffic is moved over a relatively simple protocol entitled RTP. RTP basically involves chunking compressed audio into small packets, attaching a timestamp and a codec identifier, and throwing the packet at the appropriate host. UDP Port selection is managed dynamically by whatever signaling protocol is being used, meaning a firewall either needs to open the entire range of ports that VoIP might use (not small) or it needs to directly parse the signaling traffic to determine what ports to open.
Remember how both SIP and H.323 are both very complex protocols? Add in that complex protocols can hide many security vulnerabilities, and put that complexity in the firewall: Mistakes are made. (That's not theoretical -- a recent mass audit of H.323 exposed holes not merely in VoIP endpoints, but VoIP-aware firewalls. Microsoft, who actually has a pretty impressive firewall solution, was hit pretty bad.)
It's now that we can start discussing the differences between Enterprise VoIP and the kind of PSTN-Bridge VoIP that Vonage sells. Phones in enterprises receive connections from every other potential phone -- in other words, there's generally no central proxy that copies all the traffic towards where it needs to be. In the enterprise world, there's relatively few firewalls inside the corporate network, those that are deployed can be made VoIP aware, and the "central gatekeepers" really only manage directory services (go to this IP for this extension), conference-call mixing, and in the Avaya case, encryption keys.
You don't have that situation in the public realm. Firewalls -- which are everywhere, as deployed through NAT -- simply won't accept incoming connections from hosts that a backend client wasn't communicating with in the first place. But that's almost OK, because the only host a Vonage box needs to communicate with is Vonage itself. So if you actually examine the Motorola device that Vonage is presently deploying, you'll see that it itself accepts almost no incoming connectivity of any form that doesn't appear to come from Vonage itself (just DHCP and ARP, basically). The public providers basically proxy all traffic, because they have to: Nodes on the public PSTN network (normal phone lines) can't be told to just send IP packets at the Motorola device. So the proxying is basically mandatory.
It's ironic that, at least at the moment, PSTN integration carries with it an architecture that's infinitely more wiretap-friendly than what VoIP could eventually become. Tapping a complex mesh where any node often communicates with every other node is difficult-to-impossible to do, at least with any form of reliability. Create a finite number of junction points that must be passed through in order for connectivity to be established, however, and tapping becomes feasible.
The business of a city is smooth operation. Disruption of that business is what gave India back to the Indians. And since the business of elected officials is to get re-elected, large numbers of people who will refuse to vote for you, and will actively work to illustrate that fact to your other constituents, can be pretty terrifying.
Look. Just because you don't like the anti-globalization cause doesn't mean you can deny the mechanism, or especially state that only unions should be allowed to use them.
And why do you think unions are effective? Strikes, picket lines, work stoppages, etc. are all by definition non-violent protest.
All rights have to be fought for. Non-violent protest exists, and is respected, so they don't have to be died for. But do you not realize that the implicit threat of a hundred thousand person protest is that that's numerically a gigantic army with high morale, that is peaceful today but possibly not tommorow?
Slashdot Mirror
Suppose you have something like a syscall number getting changed. Suddenly, all binaries compiled for a "vanilla" kernel need to be recompiled for the Redhat kernel. This is a massive undertaking.
This is a bit of an extreme example, but something like this is basically what people are afraid of -- having to basically "Redhat-ize" a system if they wish to run "Redhat-Linux" applications. It's NOT something you have to do now -- it's just a fear for the future.
--Dan
The fear is that a version of Oracle will come out that depends on 2.6-ish kernel features but doesn't actually work on 2.6 proper (i.e. it has dependencies on 2.4-era semantics). At that point, the only way to run Oracle -- no matter your toolchain -- is to use the Redhat kernel.
--Dan
As a slight self-addendum:
Notice how refrigerators are sold with an estimate for how much electricity (in dollars) they'll consume per year? I promise you, Sears doesn't _want_ to put that data on the price tag; it's federally mandated that they do.
Expect the same kind of sticker shock to arrive for car insurance multipliers. In other words -- cars that are really expensive to repair, and thus insure, will be forcibly marked as such.
The exemption will come if the manufacturer offers to replace/repair in lieu of "third party repair shops" (who manufacturers despise anyway). Thus, manufacturers get into the replacement business.
Seriously, this is inevitable. Hell, it might very well have been the plan all along.
--Dan
It's worth pointing out that profit margins for new vehicles are quite large -- I think the last figure I heard, on a variable cost basis, was $3,000 for a $20,000 car. Fixed costs are, of course, enormous -- R&D, testing, compliance, advertising, sunk costs in the factory, etc -- but whipping up one more Corolla is pretty cheap.
In other words, relief to the insurance industry will probably come via mandated replacements by the manufacturer, at cost (or maybe cost+10%). This could get worked into warranty programs, first as a perk, then as something greater.
Keep in mind, if your car is totalled, who's to say you'll buy the same brand next time around? Properly managed (i.e. worked into the cost of each car sold), this isn't a bad strategy for keeping customers loyal to your brand.
Manufacturer replacement is thus almost guaranteed to occur.
--Dan
Graph out our knowledge over time:
A whole lot of nothing (extending into the infinity before the big bang).
Then a bang -- massive flare-out.
Then everything slows down, and second per second we know a hell of alot less.
I'm just pointing out that, if you graph our knowledge / sources of information about the universe, it's 2D-toplogically similar to a trumpet. I'm absolutely not saying the cosmologists are wrong, just that it's an interesting coincidence that the output (shape of the universe) looks like the input (shape of the input data about the universe, which is by no means the same).
If your only light source on a dark street is a non-moving flashlight pointed slightly down, you wouldn't think the universe was oblong. Rather, you'd assume everything else was dark.
I'm saying it's a strange coincidence that they're postulating a universal shape that matches the distribution of incoming photons. Dark things still exist, you know.
Hmmm. The big bang posits a long period of time where everything is compressed, followed by an explosion which flares stuff out in all directions.
A long thin period, followed by a huge flare...that is sort of the shape of a trumpet. These are the guys who tell us that distance equals time, too...not to pretend to be a cosmologist, but isn't it possible that we're seeing a trumpet shaped universe because our input data (i.e. energy) followed a trumpet-shaped distribution curve over time?
Wow. Very cool. I was unaware of this particular failure mode for 802.11. I would have assumed that the exponential TCP backoffs would have slowed down the incoming packet rates enough for the system to eventually slow down to some reasonable rate ... I bet, to some extent, hidden node played a _big_ factor here too.
Still, I'm amazed you saw not dropped packets, but the MAC hold onto stuff for thousands of ms. Wow.
You know, the newest Linux wireless drivers have moved _everything_ into software -- thus the ability to throw up an AP on demand. I've actually got an amusingly demented protocol hack that would address some of these shortcomings, quite transparently...any interest in collaborating? Send me an email.
--Dan
Er, no.
:-)
Mesh networks aren't perfect, but the extreme low bandwidth of voice (8kbps for G.729) relative to the channel capacity makes up for quite a bit. Voice is way more sensitive to packet loss than delay, because almost nobody's implemented error concealment*. You notice the dropped signal on your cell phone way before you notice the absolutely atrocious latency you chug through.
Multisecond RTT doesn't happen on anything but GPRS, and that's because the actual core bandwidth is so slow (well, it's for many reasons, but ultimately ad-hoc networks of this scale are only a couple hops of megabit-class networking).
Ethernet frames move at the speed of light over the aether, and "Layer 1.5" 802.11 retransmission gives up after very few tries. Voice packets don't IP fragment, ever, because they're always way below the 576 minimum MTU size for IP networks. And, with only one absolutely batsh*t exception**, you'll never actually see voice routed over TCP -- you don't care about retransmissions in the voice domain.
Meshes aren't a utopia; they're an opportunity. Much like the Internet itself.
-Dan
www.doxpara.com
* Avaya's VoIP implementation has. Dynamic jitter buffers are ludicrous. Disclosure: I work at Avaya.
** Exception = set tcp window size large enough that you don't actually ever need to retransmit. this lets you run voip through a firewall that's only allowing tcp/80, even if the firewall is looking for ACKs. You have to enable window scaling, though
No, they're not accurate, but until the cost of not correcting data exceeds the cost of correcting data, they're not going to scrub anything. Nobody wants to be the guy who erased the terrorists from the database.
You think SPAM filtering is hard?
In 2003, there were 641 Million passengers on U.S. flights.
Zero of them actually attempted to destroy their flight. One of them would have been sufficient (the Shoe Bomber, for instance). The people tasked with finding this individual must thus be accurate to a level of one out of six hundred and forty one million.
By comparison, the odds of winning Powerball are approximately one out of one hundred and twenty million.
But people do win the lottery, quite regularly in fact. Lots of people have to lose, of course -- that's what funds the thing -- but it's not a particularly rare occurance.
That's sort of the idea here. Given enough "losing tickets", we'll beat the odds. And even if we don't -- at least we tried (which, ultimately, is what all the controversy is about right now -- not whether we succeeded in stopping the attacks, which we obviously didn't but whether "we tried".)
Hate to quote Scott McNealy, but like the man who sells the servers that store all our personal information says, "You have no privacy, get over it." Everyone gave up the flight info, because everyone was damn near thrown out of business. That's the bottom line.
Yes, the nGage itself is a steaming pile of crap -- and everyone knew it, from the moment we excitedly tried it at GDC last year. And we all know the games for nGage suck -- Nokia, memo from 1987, sprite acceleration makes Puzzle Bobble play at speeds higher than 7fps. But what's not well realized is that, for all of the Gameboy Advance's massive library, the vast majority of the content is Atari-market-crash level crap, and most of the remainder is unplayable by anyone over the age of 14.
... well, one that adds another screen.
Don't believe me? I swear on everything that is true in this world that the following was excitedly exclaimed from a Fry's in Campbell, CA, just a scant few months ago:
"Mommy! Mommy! It's American Idol for the Gameboy Advance!"
The kid was ten. The game was not purchased.
Don't get me wrong. I own a GBA. Hell, it's my second one, since I lost my first one. There's a good dozen games on the system that are actually playable -- the Castlevanias, the Metroids, some of the work coming out of Squaresoft. But even if the hardware is the spiritual successor of the SNES, the software selection is embarassing, bordering on mortifying.
And Nokia knows all this -- they know there's a pent up demand for gaming that scales to people who don't need to beg for a candy bar. Sony knows this -- and could actually destroy Nintendo on a whim, simply by releasing a handheld Playstation 1 (and re-releasing
a small chunk of the old library on new media). But everyone seems to be skipping a generation of failed machines (the "Don't Be Sega" effect?) and trying, better or worse, to do portable, multiplayer 3D gaming right.
And if you don't think MS is in this game, you're not paying attention to those "portable video players" with DRM support and space for a gamepad.
There's alot at stake here. I'm frankly surprised to still see Nokia still involved -- if nGage was any worse, the FCC probably would have refused to certify it on principal -- but you can't fault their recognition of the potential size of this market. Nintendo may have owned this space since the 80's -- but they've gone from the company that returned quality to video games ("Nintendo Seal of Quality" meant something) to
Yay.
--Dan
Threw this on MetaFilter a few hours ago; hope this helps clarify what's going on here. Thanks to the good Jason Spence for explaining most of this to me over fine tequila at Defcon a few years back :-)
:-)
===
OK, terrible terrible story. Nobody's going to contest that. My immediate reaction: "Yay, another whiz kid story. Kid probably rediscovered prefetching web pages."
Yeah. Then the CoLinux guy came up.
People, CoLinux is absurdly brilliant stuff, the kind of hardcore engineers get drunk about and laugh that "some psycho pulled off WHAT?!" regarding. I can say this from personal experience
To put it simply, most approaches that involve multiple operating systems sharing a processor require a significant degree of subordination. In the Cygwin model, the "Linux/Unix" way of requesting services from the operating system (open this file, give me that network connection) is translated to the Windows way through a library of functions. The mapping is pretty good, but like any translation, it's not perfect. Some actions, like starting new programs, are very very fast under Linux/Unix and are extraordinarily slow under Windows. Cygwin deals with this as best it can, but there's only so much it can do.
VMWare offers a different approach. Instead of translating Unix to Windows, VMWare creates a "virtual PC", complete with its own processor, motherboard, sound card, network card, and everything else. The child operating system -- Linux, for example -- gets a complete environment to manipulate, and VMWare handles the translation between what the child PC is asking to do and what the parent PC is actually capable of. This interface is much more isolated than what Cygwin offers -- memory, for instance, is not shared between the two environs -- but as such, the child operating system is freed of many of the particular quirks of the parent OS. The child Linux really is Linux, and can do everything Linux can do, because Linux is an environment for controlling a PC.
The only catch is that it's a virtualized PC, and VMWare needs to do alot of work to keep the two contexts separate -- and to emulate all the hardware resources that are normally "just there", but now need to be simulated. There's a 20-30% speed cut out of this. Also, switching contexts between parent PC and child PC is not a trivial thing to do, meaning it can only be done a certain number of times per second. This causes issues for some real time operations. Specifically, audio in VMWare is a problem.
CoLinux is something else entirely. x86 CPU's have the concept of Rings -- these are roughly analogous to privelege levels, in which certain classes of commands may be issued to certain components of the architecture. Lowest level code operates in what's referred to as "Ring 0" -- at this level of permissions, one can directly control the raw components of the PC, for better or worse. This is a gross oversimplification, but there's basically two things that live at Ring 0: A kernel, and device drivers (which are not entirely separate from the kernel). Kernels are basically a core set of commands that user software can execute to get things done -- create processes, read files, open network connections, and so on. Here's a list of Linux syscalls, at least from 2.2. Not on this list -- stuff like, "Send this block of memory to this device on the PCI bus, and tell the sound card to start emitting sound from that memory address on its internal buffer." That's what device drivers are for -- they get some kind of interface that userspace can talk to, and they do things with what they're given. Those things can be pretty much anything the underlying hardware can do -- stuff way deeper than "write this file" and "trace this process", and into the nuts and bolts of what the PC is -- a collection of wires and memory addresses. Normally, that's what a device driver does: It implements the requisite hardware calls to let some piece of equipment work.
Dude. Nested folders. It's 2004, we've had them for a while.
--Dan
Yeah. It's real great that Apple's willing to let me organize my music by Artist, Album, maybe Genre too.
F*ck 'em. I want folders.
I don't know how more clear to say it: When I get new music, I want it separated from my old music. I don't want to have to manage per-song playlists, and I certainly don't want to have to care about which single found its way into what Artist or Genre. The most insidious aspect of Apple's architecture (and that of the Rio Karma -- I had one of those too) is the degree to which it makes it so accursedly difficult to separate Singles and Albums, New and Old, Unfiltered and Validated, Fast Stuff and Slow. It's Apple's way or the highway.
Heh. Sort by purchase date, THEN tell me you've integrated iTunes well.
--Dan
For what it's worth, LTC is a fantastically architected crypto library. The utter simplicity of what Tom puts together is disarming, compared to the utter horror that ships with (say) OpenSSL. Both Dropbear (a very small SSH server) and MatrixSSL (a very small SSL server) have been built on LTC.
Plus, you get a crypto lib with Makefile.gba. That's Gameboy Advance. Yup.
--Dan
DVD-Audio is dead, AC3 w/ normal, copyable DVD's has won the day.
Something about that whole "anyone can master it" thing really excites the hordes of audio engineers that I know. "Hi, ten people will be allowed to work with this" technology tends only to be worked with by ten people.
--Dan
Here's the deal.
By far, the most popular algorithm in use for surround sound encoding is Dolby's AC3 (I can say this, because it's on pretty much every DVD, and nothing comes close to its penetration even in the audio space -- not even DVD-Audio). AC3 itself is a pretty fascinating codec; one of the more interesting things about it is that each additional channel requires less and less bandwidth to tack on. This is because there tends to be massive correlation between channels -- either the same sound is coming from multiple directions, or a sound is coming from one direction and all the others are silent, or some combination therein. AC3 encodes this quite efficiently, and thus gets really high quality surround sound in surprisingly few bits.
I suspect they're engineering a similar mode for MP3 -- hopefully something a little nicer than Joint Stereo, which basically works by doing a mono mix and specifying which frequencies are louder in which channel. No, this doesn't work very well. Concievably, we could see something like VBR on a per-channel basis, but I suspect this would cause existing decoders to collapse. I do believe it's possible to place extra data between MP3 granules; I suppose they'll get their backwards compatible surround mode worked into there.
--Dan
headbulb--
Comfort noise is missing on less advanced VoIP implementations.
Here's a link to the RFC that specifically describes how to send packets with comfort noise. Note that there's actually some work done to make sure the noise matches the spectral shape of what should actually be there. This prevents the noise from seeming "unusual" the the listener (i.e. it's not just random fuzz):
RFC3389.
In terms of conversion and recompression, G.711 -- the "high bandwidth" version of VoIP, at around 64kbit per direction -- isn't even converted when it's passed to the PSTN network. It's only the higher levels of compression -- G.729, G.723 -- that need to be transformed at the proxy. And it turns out most of the failures happen one hop up from the DSL/Cable modem, because there's a huge amount of bandwidth coming in and relatively little to each endpoint. Something needs to be done about this, but it's not entirely clear what. Designing from the ground up -- yeah, we did that with the PSTN, and it's great, but there's so many legacy taxes that people are going to IP just to avoid regs written before the new tech was born.
That's the story.
--Dan
Voice over IP actually creates some particularly hairy security problems that traditional approaches really, really don't manage well. Some disclosure: I work for Avaya, one of the big vendors of large scale VoIP systems, though much more for the enterprise market than for anything to do with the public space (Vonage, Packet8, etc).
Lets start by looking at the wire protocols. We have two separate domains within which VoIP operates: Signaling, which determines where a call should route, and traffic, which is the actual stream of speech that needs to arrive at its destination in under a tenth of a second. These are very different protocols. Signaling was originally implemented using H.323, which can be basically thought of as a port of the existing telephony protocols (SS7) to IP.
H.323 is...well...not entertaining to work with. It's a very messy protocol. To a first level of approximation, H.323 is being reimplemented with SIP, which applies the semantics of HTTP to VoIP signaling. SIP is still complicated, but in a more manageable way.
Whether one is using H.323 or SIP to route calls, the actual traffic is moved over a relatively simple protocol entitled RTP. RTP basically involves chunking compressed audio into small packets, attaching a timestamp and a codec identifier, and throwing the packet at the appropriate host. UDP Port selection is managed dynamically by whatever signaling protocol is being used, meaning a firewall either needs to open the entire range of ports that VoIP might use (not small) or it needs to directly parse the signaling traffic to determine what ports to open.
Remember how both SIP and H.323 are both very complex protocols? Add in that complex protocols can hide many security vulnerabilities, and put that complexity in the firewall: Mistakes are made. (That's not theoretical -- a recent mass audit of H.323 exposed holes not merely in VoIP endpoints, but VoIP-aware firewalls. Microsoft, who actually has a pretty impressive firewall solution, was hit pretty bad.)
It's now that we can start discussing the differences between Enterprise VoIP and the kind of PSTN-Bridge VoIP that Vonage sells. Phones in enterprises receive connections from every other potential phone -- in other words, there's generally no central proxy that copies all the traffic towards where it needs to be. In the enterprise world, there's relatively few firewalls inside the corporate network, those that are deployed can be made VoIP aware, and the "central gatekeepers" really only manage directory services (go to this IP for this extension), conference-call mixing, and in the Avaya case, encryption keys.
You don't have that situation in the public realm. Firewalls -- which are everywhere, as deployed through NAT -- simply won't accept incoming connections from hosts that a backend client wasn't communicating with in the first place. But that's almost OK, because the only host a Vonage box needs to communicate with is Vonage itself. So if you actually examine the Motorola device that Vonage is presently deploying, you'll see that it itself accepts almost no incoming connectivity of any form that doesn't appear to come from Vonage itself (just DHCP and ARP, basically). The public providers basically proxy all traffic, because they have to: Nodes on the public PSTN network (normal phone lines) can't be told to just send IP packets at the Motorola device. So the proxying is basically mandatory.
It's ironic that, at least at the moment, PSTN integration carries with it an architecture that's infinitely more wiretap-friendly than what VoIP could eventually become. Tapping a complex mesh where any node often communicates with every other node is difficult-to-impossible to do, at least with any form of reliability. Create a finite number of junction points that must be passed through in order for connectivity to be established, however, and tapping becomes feasible.
AOL Instant Messenger is the most interesting va
MySQL doesn't listen on its network interface by default, that's why.
The business of a city is smooth operation. Disruption of that business is what gave India back to the Indians. And since the business of elected officials is to get re-elected, large numbers of people who will refuse to vote for you, and will actively work to illustrate that fact to your other constituents, can be pretty terrifying.
Look. Just because you don't like the anti-globalization cause doesn't mean you can deny the mechanism, or especially state that only unions should be allowed to use them.
--Dan
And why do you think unions are effective? Strikes, picket lines, work stoppages, etc. are all by definition non-violent protest.
All rights have to be fought for. Non-violent protest exists, and is respected, so they don't have to be died for. But do you not realize that the implicit threat of a hundred thousand person protest is that that's numerically a gigantic army with high morale, that is peaceful today but possibly not tommorow?
--Dan
http://www.cs.uu.nl/people/jeroen/article/jpeg/
A good example of how terse yet powerful functional code can be: JPEG decoding in a few pages of code. Damn.
--Dan
Heh Cecil,
:-)
pChars[0] = 1;
memset(pChars, 0, 8);
What's that memset doing?
--Dan