Humor value noted, but for those wondering, he's talking about Extended Attributes, the big database of stuff about files, stored on HPFS. Kind of like a Resource Fork on a Mac file. EA corruption was one of the more annoying things you'd have to deal with on an OS/2 system. Examples of EA data would include the file's icon, data type (which would refer back to which program to open it), etc. Without it, a lot of the system would get really unhappy. There was even a hack IBM came up with to let you have EAs on FAT volumes, but that was a little less nice.
It's actually a very nice SACD player, using the Cell to decode the DSD streams into high-rate PCM. I have a 'real' SACD player and end up using the PS3 most of the time...
RCA was also bizarrely good at dropping the ball on technologies they had. RCA's Lancaster, PA plant made picture and TV camera tubes. My dad told me they had engineers come to the local ham radio club in the 70's and show off this tiny (for the time) CCD-based video camera they'd come up with, showing how it could take pictures by candlelight. If they'd commercialized that quickly, they could have extended their dominance of the TV station camera market into the 80's. The same plant was also home to the research group that commercialized the heat pipe concept, which was discarded by them, then bought out by the engineers involved and turned into a company that's still going today.
They even had a very workable VCR prototype in the early-mid 70's that they dropped as 'too expensive' rather than try to develop into something affordable. That decision alone, if they'd controlled the US videotape format, could've let us have RCA around as a real company today.
In '97ish I was maintaining a system that ran an inventory database on a Pick emulator running on top of AIX. Boy that was interesting. Took a lot of the neat 'database OS' idea out of it though.
The people with the money probably don't care about Loran. To the manufacturers, forced upgrades to GPS gear would be a giant plus.
And very much agreed - there's enough evidence out there to pretty much prove this system is awful. There's not much development work that can be done to change the rules of physics that make it a bad idea.
A friend of mine who works IT at a hospital was telling me about the VPN they were setting up to Australia just recently. Apparently they're going to set up quite a bit of off-hours consulting to down under. Supposedly this isn't entirely a cost move - the specialists just don't want to get paged off-hours. How this gets past regulations, I have no idea, but you can bet if this can legally fly, then someone *will* sell it for low-cost reasons. (India has many UK-trained docs, right? They'd be perfectly positioned for this...) Scares me a little - Healthcare is the one thing I thought they couldn't sell off.
Not intending to detract, and it certainly doesn't reach the number of ports of BSD or Linux... But NT at various times ran on x86, MIPS, Alpha and PowerPC. The Alpha port and the DEC-written binary translators were reportedly quite good, too. Slowly the ports were dropped, PowerPC dying when the CHRP alliance fell apart, and finally Alpha when Compaq told MS they weren't going to write most of the port anymore.
It really depends. Some will as long as the wireless mode is off. Unfortunately more are getting really bad about it, not caring if it's on or off, just making you put it away.
And NCR's servers (or all the ones I was aware of) used had Micro Channel buses, developed by... IBM.
Which means exactly nothing in terms of this battle, but it's amusing all the connections you can make.
Re:Cringley, Linus, and Christoph Hellwig
on
Today's SCO News
·
· Score: 1
AIX/ESA for 390's did indeed exist, no idea of its current status.
Of course, what started it all was IX on the 370, but that was a quite a while ago...
Token passing in TR was pretty basic. The token travelled the electrical ring and each node passed it through. If the node had a packet waiting for transmit, it listened for the bit (actually a pair of Manchester encoding violations, IIRC) that indicated the current packet was a token and converted the violations into valid bits, essentially stripping the token and turning it into a data frame.
Now there were other complexities like having a master station and error recovery, but the basics were pretty simple.
Actually, IIRC the GUS was the first full-duplex capable card, it's just that noone really used it back then. You also had to set it up "split", so that the input and output sides took seperate DMA channels, a pain if you were resource-constrained.
You're probably right... 802.11g is able to tout "backwards compatibility", and it will probably have some component commonality with b, so it will be cheaper. Thus it'll take over the home market and such. I see some troubles with that.
All the technology reviews I've seen indicate (please correct me if I am mistaken) that 802.11g takes up the whole available 2.4GHz spectrum. This poses a few problems. In my situation, I may be getting into a house down the road. My plan would be to drop one or two AP's inside, as needed for coverage. Then another cell out the back, with an omni antenna to roam the backyard and porch. With g, interference might become a severe factor in such a multi-cell configuration. I could install a/b AP's, but then my girlfriend's Powerbook might lose out, considering all the rumors that Apple is about to get all g'd up. Protocol wars are such fun...
The other concern I have with g is if it retains the good wall-penetrating capability of b, and does take up the whole spectrum, apartment dwellers might be in for a bad time. I've seen apartments where 802.11b users are pretty dense, requiring shifting channel assignments around. g might not have that flexibility.
And the 802.11 Planet articles mentioned elsewhere here brought up a potential mess with RTS/CTS packets in a mixed b/g network. So far I'm liking 802.11a a lot better technically.
Slashdot Mirror
Humor value noted, but for those wondering, he's talking about Extended Attributes, the big database of stuff about files, stored on HPFS. Kind of like a Resource Fork on a Mac file. EA corruption was one of the more annoying things you'd have to deal with on an OS/2 system. Examples of EA data would include the file's icon, data type (which would refer back to which program to open it), etc. Without it, a lot of the system would get really unhappy. There was even a hack IBM came up with to let you have EAs on FAT volumes, but that was a little less nice.
It's actually a very nice SACD player, using the Cell to decode the DSD streams into high-rate PCM. I have a 'real' SACD player and end up using the PS3 most of the time...
RCA was also bizarrely good at dropping the ball on technologies they had. RCA's Lancaster, PA plant made picture and TV camera tubes. My dad told me they had engineers come to the local ham radio club in the 70's and show off this tiny (for the time) CCD-based video camera they'd come up with, showing how it could take pictures by candlelight. If they'd commercialized that quickly, they could have extended their dominance of the TV station camera market into the 80's. The same plant was also home to the research group that commercialized the heat pipe concept, which was discarded by them, then bought out by the engineers involved and turned into a company that's still going today. They even had a very workable VCR prototype in the early-mid 70's that they dropped as 'too expensive' rather than try to develop into something affordable. That decision alone, if they'd controlled the US videotape format, could've let us have RCA around as a real company today.
In '97ish I was maintaining a system that ran an inventory database on a Pick emulator running on top of AIX. Boy that was interesting. Took a lot of the neat 'database OS' idea out of it though.
The people with the money probably don't care about Loran. To the manufacturers, forced upgrades to GPS gear would be a giant plus. And very much agreed - there's enough evidence out there to pretty much prove this system is awful. There's not much development work that can be done to change the rules of physics that make it a bad idea.
A friend of mine who works IT at a hospital was telling me about the VPN they were setting up to Australia just recently. Apparently they're going to set up quite a bit of off-hours consulting to down under. Supposedly this isn't entirely a cost move - the specialists just don't want to get paged off-hours. How this gets past regulations, I have no idea, but you can bet if this can legally fly, then someone *will* sell it for low-cost reasons. (India has many UK-trained docs, right? They'd be perfectly positioned for this...) Scares me a little - Healthcare is the one thing I thought they couldn't sell off.
Not intending to detract, and it certainly doesn't reach the number of ports of BSD or Linux... But NT at various times ran on x86, MIPS, Alpha and PowerPC. The Alpha port and the DEC-written binary translators were reportedly quite good, too. Slowly the ports were dropped, PowerPC dying when the CHRP alliance fell apart, and finally Alpha when Compaq told MS they weren't going to write most of the port anymore.
It really depends. Some will as long as the wireless mode is off. Unfortunately more are getting really bad about it, not caring if it's on or off, just making you put it away.
And NCR's servers (or all the ones I was aware of) used had Micro Channel buses, developed by... IBM. Which means exactly nothing in terms of this battle, but it's amusing all the connections you can make.
AIX/ESA for 390's did indeed exist, no idea of its current status. Of course, what started it all was IX on the 370, but that was a quite a while ago...
Token passing in TR was pretty basic. The token travelled the electrical ring and each node passed it through. If the node had a packet waiting for transmit, it listened for the bit (actually a pair of Manchester encoding violations, IIRC) that indicated the current packet was a token and converted the violations into valid bits, essentially stripping the token and turning it into a data frame. Now there were other complexities like having a master station and error recovery, but the basics were pretty simple.
Actually, IIRC the GUS was the first full-duplex capable card, it's just that noone really used it back then. You also had to set it up "split", so that the input and output sides took seperate DMA channels, a pain if you were resource-constrained.
But just think of the poor Cabbage Patch Kids! Doesn't anyone think of the children? ;)
I do have to wonder if cluefully-run 2000 boxes will be exempt. If not, that would be rather harsh. If so, you'd need some way to verify it...
You're probably right... 802.11g is able to tout "backwards compatibility", and it will probably have some component commonality with b, so it will be cheaper. Thus it'll take over the home market and such. I see some troubles with that.
All the technology reviews I've seen indicate (please correct me if I am mistaken) that 802.11g takes up the whole available 2.4GHz spectrum. This poses a few problems. In my situation, I may be getting into a house down the road. My plan would be to drop one or two AP's inside, as needed for coverage. Then another cell out the back, with an omni antenna to roam the backyard and porch. With g, interference might become a severe factor in such a multi-cell configuration. I could install a/b AP's, but then my girlfriend's Powerbook might lose out, considering all the rumors that Apple is about to get all g'd up. Protocol wars are such fun...
The other concern I have with g is if it retains the good wall-penetrating capability of b, and does take up the whole spectrum, apartment dwellers might be in for a bad time. I've seen apartments where 802.11b users are pretty dense, requiring shifting channel assignments around. g might not have that flexibility.
And the 802.11 Planet articles mentioned elsewhere here brought up a potential mess with RTS/CTS packets in a mixed b/g network. So far I'm liking 802.11a a lot better technically.