Windows gets hit with 99% of virii because 99% of them are written for Windows. Why? Because Windows is so damn popular.
That's FUD. And it's wrong.
Yes it's a bigger target. But it's also an EASIER target, because it has SO many gaping holes that, even when they do get fixed, get replaced by even more holes.
If it were JUST that more-is-easer, there'd be more Apache web server attacks than Microsoft IIS web server attacks.
And just because there are fewer systems of other types doesn't mean there won't be soft-diseases among them if they're susceptable. What matters for a disease - whether it's software on computers or pathological biological agents in living organisms - is not the FRACTION of the population that is susceptable, but the existence and size of the susceptable subpopulation. A disease lives in a world populated by only the susceptable individuals. As far as it's concerned the non-susceptable population just doesn't exist. If there are enough susceptable individuals, in sufficient contact, it will spread.
So don't be surprised if, in some hypothetical future where Linux has a 60% desktop share and Windows is down to 10%, there are still be more Windows than Linux viruses.
What's this "primarily affect" business? It only affects Microsoft systems, [...]
Only SPREADS via Microsoft systems - and maybe Microsoft software running under Wine or on Macs or the like.
But it AFFECTS other systems somewhat - by clogging the net, filling inboxes with infection attempts, etc.
[...] just like every other friggin' virus on the face of the planet.
Actually, Mac viruses predate those for Windows. (It's the downside of the old MacOS versions looking at the disks for driver patches on startup/insert.) But for some reason the Windows viruses, historically, have tended to be both more prevalant and more vicious, while Mac viruses have tended to be of the prank variety.
It's a lot harder to infect Unix variants (including OS X) than single-user paradigm OSes, because they were originally designed to protect the users in a multiuser environment from each other, and the system from the users. So there are bariers built-in from scratch that a virus must find a way around.
By the way: Protecting the system from the user (except when he says he REALLY INTENDS to change it) is a good paradigm even in a single-user environment and even in the absense of malicious intents. The only difference, security-wise, between taking the system down accidentally and taking it down maliciously is that the intentional attack will usually find the security hole a little earlier than random activity.
Now if only someone can teach the MS admins and users to apply the goddamn patches that Microsoft releases!
Sysadmins in businesses don't apply Microsoft patches, or don't apply them in a timely manner, for a very good reason: Sometimes the patches do more damage to their operations than the virus/worm/whatever they're supposet to block. And applying a broken patch is GUARANTEED to do the damage IMMEDIATELY, while you MIGHT not get bit by the attack - or not get bit by it soon - or be protected by an antivirus update before it gets to you.
If you're running mission-critical stuff for your business, you have to do a bunch of checking of any patches/upgrades/other changes before installing them on your live machines. And this takes money (so you aviod it if you can) and time (so even if you do it it won't happen right away). For some business processes it takes a LOT of money and/or time.
Of course the same is true of any operating system, not just Microsoft. But that makes it all the more important to use a system that has a low frequency of security incidents that require patches. B-)
And that last means that it's tempting for a vendor (such as Microsoft) to resist patching problems before a wild exploit is discovered, in order to reduce the perceived cost of using their systems. Unfortunately, while such a strategy reduces the cost of applying upgrades, it also means the system gets hit by more exploits - increasing the total cost. (But the vendor can blame THOSE costs on the authors of the exploits, so the corporate customer decision-makers may not be aware of these costs of their software supplier's policies.)
Now hear this: the US military DOES NOT USE MS WINDOWS BOXEN TO CONTROL NUCLEAR WEAPONS. Or, any sort of weapon for that matter. The military, like most large institutions, has a need for office automation apps, e-mail, and the like. And for this, they use Windows and Office.
So they use Windows to order, ship, track, inventory, order deployment of, etc. nuclear weapons. Also MREs, toilet paper, and all the other supplies necessary for a deployment - and whose quantities and destinations are secret, because, if you're sending X amount of toilet paper to Borneo, it means you're sending Y amount of troops to Borneo.
So what happens when it's time to send troops against one of our likely future enemies, or one of their clients. And suddenly a wave of shiny new blended-threat self-propagating worms from their info-warefare department floods through the Army's half-million desktops, emailing/ftping/whateveing the info to the other side and then wiping essentially every office computer in the U.S. Army?
Rember:
- Microsoftware holds the record for security vulnerabilities.
- Microsoft showed the source code to the info-warfare department of every major non-US power recently (to "satisfy them of its security").
Meanwhile it does NOT show source to the U.S. academic-community software security specialists - who wouldn't look anyhow due to non-disclosure requirements. Requirements which, of course, are a total joke to a foreign infowar department.
You guys have to remember that there is a HUGE digital divide out there and getting soldiers with out much education comfortable with computers tends to be quicker and easier with Windows.
Therefore you want to simplify the training by standardizing on a system which not only holds the record for security vulnerabilities, but whose source has been delivered to the electronic warfare departments of most of our potential enemies but NOT to our own academic-community security specialists?
What do you do the next time there's a conflict and some new crop of blended-threat self-propagating worms (locusts?) suddenly takes out the US Army's entire office infrastructure?
==============
While you're at it, why are you advocating depending on the NON-standardized training the recruits got as civilians rather than teaching them "The Army Way"? (But if you MUST, why not use a Windows-like interface and workalike basic apps, ala Lindows or KDE + OpenOffice, for the basic stuff? They have to learn the army-specific apps anyhow. Meanwhile there's a good chance the next crop of high-school students will be learning on open source platforms rather than Windows, due to developments already discussed on Slashdot.)
And brace yourself for a major bloom of astroturf
on
NYT On Online Reputations
·
· Score: 4, Interesting
Of course, a really gutsy, ethical company wants you to know the truth about their products, and enjoys the enhanced word of mouth the Internet provides, because perhaps they can save some money on advertising.
Of course and UNethical company - which may be a requriement for a PR firm - will simply put one or two people to work posting through pseudonyms to create the illusion of a vast population of enthusiastic supporters. (Like the paid endorsements and fake man-on-the-street interviews in commercials and political ads, written large on the internet.)
The term of art is "Astroturf" - for phoney grass-roots.
And after the NYT article you can expect a sudden wash of it, polluting the net as a reputationg system for some time to come.
Unfortunately, the current implementations don't scale to the size of even the current internet - because they requre every node to know about every other (in case it needs to forward a packet).
(Routing table explosions were what drove the switch from RIP to BGP in the first place.)
They'll get there eventually. Meanwhile, imagine them as drops of mercury. When two touch they join. And when two equal-sized drops join, each "atom" (machine) in the big drop needs twice as much table space as it needed in the separate little drop.
Now imagine them joining, and joining, and joining, until the whole world is covered by one big drop. Somewhere along the way the tables get too big for your handheld, VoIP phone, toaster, or what-have-you.
The Nortel (and related) boxes wireless link you to VoIP on an internet portal.
Use the 802.11x handset anywhere you've got an access point that lets you hit the net.
Plug the IP desk set in ditto with your wired LAN. Move offices by unplugging it and carrying it, rather than having the $400/hr consultant come reconfigure the PBX. Heck: Move to the branch office on the other coast, or take an "office phone" home and plug it into the hub on your DSL modem.
Think "free long-distance" and "cellphone" and "no air-time", vs. "wireless extension phone" with an invisible cord to your phone jack.
* Transmeta hired Linus primarily to do work on the kernel for them (i.e. have a Linux kernel ready to go when their chip came out, both so linux would run and in case Microsoftware didn't.)
* While working for them he, as part of his work, distributed (thus copying) the allegedly-SCO's IP that was allegedly ported into Linux by IBM or others, or that he ported some in himself.
So therefore Transmeta was involved in the IP "theft", yadda yadda...
Or any of a number of variations on the theme.
But I doubt that has anything to do with Linus leaving Transmeta. (If nothing else, SCO could still sue them after he's gone.)
I imagine that, now that Transmeta's first chips are out, most of the Transmeta-specific kernel work is done. So if Linus stays he's likely to get sucked into other software that's less kernel-specific, losing his kernel focus to the detriment of Linux. On the other hand, he can focus on the kernel full-time at his new site, to the benefit of Liunx, Transmeta, Linus' peace of mind, and a whole lot more.
Linus sounds like he feels uncomfortable being paid by Transmeta for kernel work - even it really IS a big help to Transmeta for the kernel to continue to prosper. Going to somewhere where this is no longer an issue in HIS mind (regardless of whether it's an issue for his management) is good all around.
I'd REALLY REALLY REALLY like to see Boeing, Airbus et al. installing avionics and comms systems that can't be disrupted by ubiquitous and nearly free techno-gadgets.
If radio interference from the passenger cabin is such a hazard they should just SHIELD THE PASSENGER CABIN!
Turn it into a faraday cage when the crew cabin door is closed.
This would NOT take a lot of weight: Heavily aluminized or copper-flashed mylar added to the insulating panels, doors, and bulkheads (along with metallic fingers or sponges to connect the joints) would do the job nicely. The windows could be lightly metalized (if they aren't already) which would also reduce glare and heat from the sun - or just left alone, since the high frequency stuff won't bend around to bother the avionics. Metal gaskets and ferrite donuts where conduits pass through bulkheads to/from passenger cabin, light metal coating where they pass through it on their way back out, and ferrite beads again on power and low-frequency signaling to cabin equipment. (And the TV system already lives in the cabin, where the stews can twiddle it.)
Shielding the cabin will also cut the cell phones off from the cells, to keep people from talking on them. (Or the plane could have a cell of its own just inside the cabin, without trashing the avionics. Low power, and provoking the phones to run at low power, too.) Alternatively, a "smoke detector" like device to alarm if anybody's phone is still on. (They "check in" every few minutes, so they're easy to detect.)
Similarly, 802.11 would be contained within the cabin, and could be detected and requested to be shut down if it's still a problem - or used for an in-flight internet service. And the ubiquitous switching power supplies would be no issue either, with THEIR radiation also contained.
The Mobile Mesh Routing Protocol (MMRP) is a robust, scalable, andefficient mobile adhoc routing protocol based upon the "link state" approach. A node periodically broadcasts its own Link State Packet (LSP) on each interface participating in the protocol. LSP's are relayed by nodes, thus allowing each node to have full topology nformation for the entire adhoc network. From its topology database, a node is able to compute least cost unicast routes to all other nodes in the mobile adhoc network.
The first and third sentences contradict each other: Each node in the ad-hock network must REMEMBER the connectivity of ALL THE OTHER nodes of the network. If the ad-hoc network becomes widespread (i.e. you do an open network, and your neighbor does, and his neighbor does, all across the planet) you run out of RAM.
(The protocol DOES cut down TRAFFIC to a level that may scale by reducing the frequency of transmission of packets containing routing information as they get more hops away from the nodes in question.)
This won't be an issue if your nodes are configured to only participate in your local network. It becomes an issue when they are not so limited. This includes the case where a particular "local network" is the default configuration for commercial equipment.
But most of the spectrum alloted for TV is still unused. Since most people do have cable or satellite, there isn't much incentive for corporations to invest the $$ to build a bunch of new broadcast towers for more over-the-air TV channels. If anything, the number of over-the-air channels will probably decrease, not increase.
Hardly.
Looked at your over-the-air UHF specturm lately? There are a LOT of stations there now. (And UHF is a lot more expensive per eyeball beacause it doesn't go around hills as well as VHF.)
Shopping channels. "Educational" channels. Church channels. Etc.
VHF is half-empty because adjacent channels interfere - especially when their signal strengths are significantly different because the two transmitters are located at different distances from, or in different directions as viewed from, the receiver. UHF ditto, only moreso.
(Cable boxes get away with using adjacent channels because adjacent channel signal strengths on the cable are kept about equal and the converter box has a much sharper IF filter than TV sets - especially older sets.)
Expect more, not less, over-the-air TV stations, as the price of program-origination technology continues to plummet. If some broadcast outlet were to actually give up its multi-megabuck license, somebody else will snap up the space.
Nobody cares about these people, because they can't afford to donate to political campaigns.
But they CAN contribute their TIME - serving as warm bodies for demonstrations, being bussed to polling places on election day (some claim multiply), doing volunteer campaign work, showing up at legislature comment sessions, etc.
Of course STILL nobody cares what they actually THINK, because the bulk of them do what their "leaders" - or their social workers - tell them to do. But they DO influence politicians - or at least those who haven't figured out that there are a lot of shills in the crowd.
It might be great if some oes to Hams and other bits to commercial radio and unlicensed (low-power) data transmission (upper UHF freqs). [...] Granted, in the upper UHF region, [antenna size] gets better [smaller], [...]
Forget about the "upper UHF" TV band. It was ALREADY converted to telephone service.
A program doesn't necessarily know where it lives, but it is possible to tell if it's talking to a black box that's been signed by Intel's private key
Not if you emulate the black box, signature and all.
It's one thing to sign something, another to have a local device that can sign with a hidden key that can't be extracted. You need the latter - an unemulatable-because-you-can't-see-its-guts box - to be robust against spoofing the software via an emulation platform.
The main way to detect emulation is response time checking. But that won't work to detect if YOU'RE running on an emulation platform, because the emulation platform can also spoof your idea of time.
Worldcom spent large amounts in start-up costs building physical networks and did not report these expenditures as current period expenses. Instead they deferred these to future peiods where they hoped they'd make money on the new grids.
One of the telecoms got into trouble for doing exactly the opposite: They accounted several billion in operating expenses as capital expenditure.
So money that was just gone for things like wages, electric bills, and gasoline looked like it had bought a few billion in equipment. When the auditors looked around they discovered the company had a few billion less in plant equipment than the books showed, making the book value of the investors stock a lot less.
GPL is based on copyright. This law would mean that GPL code would begin to go into public domain in 50 years, unless somebody like FSF ponies up the bux. And given the plethora of incremental deltas (which, taken alone, will probably be considered "fair use" to apply), renewing copyrights separately on all the versions could get very expen$ive.
(You'll recall that the reason GPL code is not just PD is to keep people from locking up the fixes and improvements.)
Now it could be argued that in something as fast moving as software, something 50 years old is dead. But how old is Unix already, eh? (Not to mention "Hello, world!".) This industry is maturing. Like classical music, things written already, or being written now, are likely to have lasting value and be around a long time.
As far as I'm concerned RedHat is not ready for prime time - and WON'T be until:
1) Their prepaid included-with-the-expensive-box support continues until your first install is up on the net or LAN (and preferably with a built-from-source kernel), rather than stopping when you first get a login screen.
2) Their quickstart manual includes a clear description (accessable to neophytes - and keystroke-by-keystroke again) of both
* how to install the system (Of particular interest as of 6.x: Tell 'em how to make sane choices for the size of the partitions.) and
* how to obtain and install security upgrades.
3) Their install documentation includes a step-by-step, keystroke-by-kestroke recipe for going:
* from a blank computer and their CDROMs,
* through an intermediate system installed from the CDROM image
* To the SAME system but with the kernel built from the supplied sources.
4) Their in-depth manual includes a section giving a COMPLETE list of the configuration files twiddled by each of the functions of each of the graphic-interface admin tools. (And don't tell me to read the source or look it up on the net. You're a packager. Package it already.)
5) Their quickstart manual tells me how to adjust the screen parameters. (And DON'T tell me to go figure out X. Give a recipe.)
C'mon, guys! Get a tech writer and assign him/her the task with 2), 3), 4), and 5) as the goals.
(And while we're at it, the Gnome and/or KDE crews really ought to do a desktop tool, on the model of Apples', for tuning the screen, and RedHat should have it in the default menus.)
the management team will never work again in corporate America
If only that were true. Unfortunately, private enterprise does a poor job of recognizing a loser manager when it sees one. Even if you take your company into the toilet, you've got experience and a bunch of connections to get that next job.
There is a saying among engineers - especially electrical engineers - to the effect that:
"Expertese is directly proportional to value of equipment destroyed."
The implication being that learning is an ongoing thing, and one of the most effective ways to learn what not to do because it smokes the expensive box is to smoke one.
Perhaps there is a similar saying relating to CEOs who crash companies?
(Interestingly, the saying appears to be largely false. Good engineers learn early to think ahead, and tend to stop smoking expensive boxes, or at least lower the occurrence rate of smoke generation events to near-nill - often before leaving junior high school. Meanwhile, flakes keep frying 'em as long as management lets them twiddle knobs and swap cables. Perhaps this ALSO applies to CEOs. B-) )
So I suppose you still can not slashdot the phone network..
Actually you CAN slashdot the PSTN (Public Switched Telephone Netowork). And you always could. The equipment is sized to handle the expected peak loads with some slop. But there is nowhere near enough equipment in place to handle every phone being connected to another phone.
You can slashdot it at several levels. The commonest is the "all-trunks busy" level - where all the routes from the calling phone to the called number (that the switching equipment knows how to use) are busy. In the older exchanges that produced the tones that sounded like a busy signal but twice as fast. Modern stuff gives you a recording.
You can also tie up all the equipment that gives you a dial tone and collects the digits you dial, by getting enough people on the exchange to try to make calls at once. Usually this just means you wait a second or so for a dial tone - and maybe not even notice it. If it's REALLY severe you might wait seconds, or minutes, and then it is really noticible. But it's also really rare.
The last time I recall that actually happening where I lived was the Loma Prieta earthquake, and the time before was the assassination of JFK. Before that was at an old relay-based exchange (using line-finders rather than registers) where the line finders didn't time out, and a tornado had shorted out enough lines - which made them look "off-hook" - to busy out all the line-finders that could give my phone a dial tone.
Again, modern equipment is more informative: When things get hairy the people operating the network can switch it to a mode where, when you take your phone off the hook, it first connects you to a recording asking you to hold off unless it's an emergency, then giving you a delay followed by a fair chance at a dialtone. (I THINK it actually deliberately delays you a bit even if it COULD have given you a dial tone right away, both to throttle you and to give you a chance to hang up if it wasn't urgent.)
I wonder what would be the world without Ethernet? Would Internet begin and survive just on UUCP/SLIP/PPP?
Would you rather be stuck with Token Ring?
I mean, IBM is a great innovator to be sure. But token ring, IMHO, was one of their great misses.
There's token rings and there's token rings. Saying "Token Ring" when you mean "IBM's Token Ring" is like saying "DOS" when you mean "Microsoft's Disk Operating System".
My guess is that, in the absense of the invention of Ethernet's listen/transmit/back off on collision model, we'd have bootstrapped up from Datapoint's ARCnet.
Like IBM's protocol, ARCnet is also a token ring. But unlike IBM, ARCnet's transport layer is broadcast. So it combines the self-healing characteristics of Ethernet with the delivery-time and latency guarantees of token rings.
ARCnet did have a downside - limited number of addresses on a segment. But there are ways around that. (My favorite is my own variant which I call "bumblenet", involving an aborted binary search for the next station to get the token.)
But for radio, Ethernet-like low-level protocols have a distinct advantage over token rings: They suffer less from the "hidden transmitter" issue - where some devices can hear each other and others can't.
Ethernet-like protocols get their packet through if the transmitter and receiver can hear each other and nobody else within their earshot is talking. So a pair of stations on THIS side of the hill can swap a packet at the same time a pair of stations on the OTHER side are swapping one, without explicitly negotiating about it over relays through other stations - or even knowning about stations on the other side of the hill.
Token rings can work around a hill - even if you have a sparse chain of stations where each can only hear two neighbors. But there's a lot more effort involved. They only get simple when either everybody hears everybody else or everybody talks to exactly two neighbors in a closed ring.
Slashdot Mirror
Windows gets hit with 99% of virii because 99% of them are written for Windows. Why? Because Windows is so damn popular.
That's FUD. And it's wrong.
Yes it's a bigger target. But it's also an EASIER target, because it has SO many gaping holes that, even when they do get fixed, get replaced by even more holes.
If it were JUST that more-is-easer, there'd be more Apache web server attacks than Microsoft IIS web server attacks.
And just because there are fewer systems of other types doesn't mean there won't be soft-diseases among them if they're susceptable. What matters for a disease - whether it's software on computers or pathological biological agents in living organisms - is not the FRACTION of the population that is susceptable, but the existence and size of the susceptable subpopulation. A disease lives in a world populated by only the susceptable individuals. As far as it's concerned the non-susceptable population just doesn't exist. If there are enough susceptable individuals, in sufficient contact, it will spread.
So don't be surprised if, in some hypothetical future where Linux has a 60% desktop share and Windows is down to 10%, there are still be more Windows than Linux viruses.
What's this "primarily affect" business? It only affects Microsoft systems, [...]
Only SPREADS via Microsoft systems - and maybe Microsoft software running under Wine or on Macs or the like.
But it AFFECTS other systems somewhat - by clogging the net, filling inboxes with infection attempts, etc.
[...] just like every other friggin' virus on the face of the planet.
Actually, Mac viruses predate those for Windows. (It's the downside of the old MacOS versions looking at the disks for driver patches on startup/insert.) But for some reason the Windows viruses, historically, have tended to be both more prevalant and more vicious, while Mac viruses have tended to be of the prank variety.
It's a lot harder to infect Unix variants (including OS X) than single-user paradigm OSes, because they were originally designed to protect the users in a multiuser environment from each other, and the system from the users. So there are bariers built-in from scratch that a virus must find a way around.
By the way: Protecting the system from the user (except when he says he REALLY INTENDS to change it) is a good paradigm even in a single-user environment and even in the absense of malicious intents. The only difference, security-wise, between taking the system down accidentally and taking it down maliciously is that the intentional attack will usually find the security hole a little earlier than random activity.
Now if only someone can teach the MS admins and users to apply the goddamn patches that Microsoft releases!
Sysadmins in businesses don't apply Microsoft patches, or don't apply them in a timely manner, for a very good reason: Sometimes the patches do more damage to their operations than the virus/worm/whatever they're supposet to block. And applying a broken patch is GUARANTEED to do the damage IMMEDIATELY, while you MIGHT not get bit by the attack - or not get bit by it soon - or be protected by an antivirus update before it gets to you.
If you're running mission-critical stuff for your business, you have to do a bunch of checking of any patches/upgrades/other changes before installing them on your live machines. And this takes money (so you aviod it if you can) and time (so even if you do it it won't happen right away). For some business processes it takes a LOT of money and/or time.
Of course the same is true of any operating system, not just Microsoft. But that makes it all the more important to use a system that has a low frequency of security incidents that require patches. B-)
And that last means that it's tempting for a vendor (such as Microsoft) to resist patching problems before a wild exploit is discovered, in order to reduce the perceived cost of using their systems. Unfortunately, while such a strategy reduces the cost of applying upgrades, it also means the system gets hit by more exploits - increasing the total cost. (But the vendor can blame THOSE costs on the authors of the exploits, so the corporate customer decision-makers may not be aware of these costs of their software supplier's policies.)
Now hear this: the US military DOES NOT USE MS WINDOWS BOXEN TO CONTROL NUCLEAR WEAPONS. Or, any sort of weapon for that matter. The military, like most large institutions, has a need for office automation apps, e-mail, and the like. And for this, they use Windows and Office.
So they use Windows to order, ship, track, inventory, order deployment of, etc. nuclear weapons. Also MREs, toilet paper, and all the other supplies necessary for a deployment - and whose quantities and destinations are secret, because, if you're sending X amount of toilet paper to Borneo, it means you're sending Y amount of troops to Borneo.
So what happens when it's time to send troops against one of our likely future enemies, or one of their clients. And suddenly a wave of shiny new blended-threat self-propagating worms from their info-warefare department floods through the Army's half-million desktops, emailing/ftping/whateveing the info to the other side and then wiping essentially every office computer in the U.S. Army?
Rember:
- Microsoftware holds the record for security vulnerabilities.
- Microsoft showed the source code to the info-warfare department of every major non-US power recently (to "satisfy them of its security").
Meanwhile it does NOT show source to the U.S. academic-community software security specialists - who wouldn't look anyhow due to non-disclosure requirements. Requirements which, of course, are a total joke to a foreign infowar department.
You guys have to remember that there is a HUGE digital divide out there and getting soldiers with out much education comfortable with computers tends to be quicker and easier with Windows.
Therefore you want to simplify the training by standardizing on a system which not only holds the record for security vulnerabilities, but whose source has been delivered to the electronic warfare departments of most of our potential enemies but NOT to our own academic-community security specialists?
What do you do the next time there's a conflict and some new crop of blended-threat self-propagating worms (locusts?) suddenly takes out the US Army's entire office infrastructure?
==============
While you're at it, why are you advocating depending on the NON-standardized training the recruits got as civilians rather than teaching them "The Army Way"? (But if you MUST, why not use a Windows-like interface and workalike basic apps, ala Lindows or KDE + OpenOffice, for the basic stuff? They have to learn the army-specific apps anyhow. Meanwhile there's a good chance the next crop of high-school students will be learning on open source platforms rather than Windows, due to developments already discussed on Slashdot.)
Of course, a really gutsy, ethical company wants you to know the truth about their products, and enjoys the enhanced word of mouth the Internet provides, because perhaps they can save some money on advertising.
Of course and UNethical company - which may be a requriement for a PR firm - will simply put one or two people to work posting through pseudonyms to create the illusion of a vast population of enthusiastic supporters. (Like the paid endorsements and fake man-on-the-street interviews in commercials and political ads, written large on the internet.)
The term of art is "Astroturf" - for phoney grass-roots.
And after the NYT article you can expect a sudden wash of it, polluting the net as a reputationg system for some time to come.
Unfortunately, the current implementations don't scale to the size of even the current internet - because they requre every node to know about every other (in case it needs to forward a packet).
(Routing table explosions were what drove the switch from RIP to BGP in the first place.)
They'll get there eventually. Meanwhile, imagine them as drops of mercury. When two touch they join. And when two equal-sized drops join, each "atom" (machine) in the big drop needs twice as much table space as it needed in the separate little drop.
Now imagine them joining, and joining, and joining, until the whole world is covered by one big drop. Somewhere along the way the tables get too big for your handheld, VoIP phone, toaster, or what-have-you.
$25 will do the same thing.
Nope.
That device wireless links you to a POTS line.
The Nortel (and related) boxes wireless link you to VoIP on an internet portal.
Use the 802.11x handset anywhere you've got an access point that lets you hit the net.
Plug the IP desk set in ditto with your wired LAN. Move offices by unplugging it and carrying it, rather than having the $400/hr consultant come reconfigure the PBX. Heck: Move to the branch office on the other coast, or take an "office phone" home and plug it into the hub on your DSL modem.
Think "free long-distance" and "cellphone" and "no air-time", vs. "wireless extension phone" with an invisible cord to your phone jack.
SCO could alledge that:
* Transmeta hired Linus primarily to do work on the kernel for them (i.e. have a Linux kernel ready to go when their chip came out, both so linux would run and in case Microsoftware didn't.)
* While working for them he, as part of his work, distributed (thus copying) the allegedly-SCO's IP that was allegedly ported into Linux by IBM or others, or that he ported some in himself.
So therefore Transmeta was involved in the IP "theft", yadda yadda...
Or any of a number of variations on the theme.
But I doubt that has anything to do with Linus leaving Transmeta. (If nothing else, SCO could still sue them after he's gone.)
I imagine that, now that Transmeta's first chips are out, most of the Transmeta-specific kernel work is done. So if Linus stays he's likely to get sucked into other software that's less kernel-specific, losing his kernel focus to the detriment of Linux. On the other hand, he can focus on the kernel full-time at his new site, to the benefit of Liunx, Transmeta, Linus' peace of mind, and a whole lot more.
Linus sounds like he feels uncomfortable being paid by Transmeta for kernel work - even it really IS a big help to Transmeta for the kernel to continue to prosper. Going to somewhere where this is no longer an issue in HIS mind (regardless of whether it's an issue for his management) is good all around.
At the risk of sounding off-topic... doesn't this seem very familiar? [Comparison to RIAA deleted]
I'd be happier with your post if the RIAA didn't keep WINNING in court.
I mean, come on, SCO! [IBM is] going to sue you into bankruptcy, and then buy the rights to your code from your liquidators at a dirt cheap price.
If SCO folds before the case is settled and your scenario takes place, that could be very bad.
Imagine IBM and Microsoft in a sealed-bid auction for SCO's claimed rights to Unix and its derivatives.
I'd REALLY REALLY REALLY like to see Boeing, Airbus et al. installing avionics and comms systems that can't be disrupted by ubiquitous and nearly free techno-gadgets.
If radio interference from the passenger cabin is such a hazard they should just SHIELD THE PASSENGER CABIN!
Turn it into a faraday cage when the crew cabin door is closed.
This would NOT take a lot of weight: Heavily aluminized or copper-flashed mylar added to the insulating panels, doors, and bulkheads (along with metallic fingers or sponges to connect the joints) would do the job nicely. The windows could be lightly metalized (if they aren't already) which would also reduce glare and heat from the sun - or just left alone, since the high frequency stuff won't bend around to bother the avionics. Metal gaskets and ferrite donuts where conduits pass through bulkheads to/from passenger cabin, light metal coating where they pass through it on their way back out, and ferrite beads again on power and low-frequency signaling to cabin equipment. (And the TV system already lives in the cabin, where the stews can twiddle it.)
Shielding the cabin will also cut the cell phones off from the cells, to keep people from talking on them. (Or the plane could have a cell of its own just inside the cabin, without trashing the avionics. Low power, and provoking the phones to run at low power, too.) Alternatively, a "smoke detector" like device to alarm if anybody's phone is still on. (They "check in" every few minutes, so they're easy to detect.)
Similarly, 802.11 would be contained within the cabin, and could be detected and requested to be shut down if it's still a problem - or used for an in-flight internet service. And the ubiquitous switching power supplies would be no issue either, with THEIR radiation also contained.
The first and third sentences contradict each other: Each node in the ad-hock network must REMEMBER the connectivity of ALL THE OTHER nodes of the network. If the ad-hoc network becomes widespread (i.e. you do an open network, and your neighbor does, and his neighbor does, all across the planet) you run out of RAM.
(The protocol DOES cut down TRAFFIC to a level that may scale by reducing the frequency of transmission of packets containing routing information as they get more hops away from the nodes in question.)
This won't be an issue if your nodes are configured to only participate in your local network. It becomes an issue when they are not so limited. This includes the case where a particular "local network" is the default configuration for commercial equipment.
This sounds like Philo T. Farnsworth's Ion Transport Vacuum Pump, patent #3,240,421
But most of the spectrum alloted for TV is still unused. Since most people do have cable or satellite, there isn't much incentive for corporations to invest the $$ to build a bunch of new broadcast towers for more over-the-air TV channels. If anything, the number of over-the-air channels will probably decrease, not increase.
Hardly.
Looked at your over-the-air UHF specturm lately? There are a LOT of stations there now. (And UHF is a lot more expensive per eyeball beacause it doesn't go around hills as well as VHF.)
Shopping channels. "Educational" channels. Church channels. Etc.
VHF is half-empty because adjacent channels interfere - especially when their signal strengths are significantly different because the two transmitters are located at different distances from, or in different directions as viewed from, the receiver. UHF ditto, only moreso.
(Cable boxes get away with using adjacent channels because adjacent channel signal strengths on the cable are kept about equal and the converter box has a much sharper IF filter than TV sets - especially older sets.)
Expect more, not less, over-the-air TV stations, as the price of program-origination technology continues to plummet. If some broadcast outlet were to actually give up its multi-megabuck license, somebody else will snap up the space.
Nobody cares about these people, because they can't afford to donate to political campaigns.
But they CAN contribute their TIME - serving as warm bodies for demonstrations, being bussed to polling places on election day (some claim multiply), doing volunteer campaign work, showing up at legislature comment sessions, etc.
Of course STILL nobody cares what they actually THINK, because the bulk of them do what their "leaders" - or their social workers - tell them to do. But they DO influence politicians - or at least those who haven't figured out that there are a lot of shills in the crowd.
It might be great if some oes to Hams and other bits to commercial radio and unlicensed (low-power) data transmission (upper UHF freqs). [...] Granted, in the upper UHF region, [antenna size] gets better [smaller], [...]
Forget about the "upper UHF" TV band. It was ALREADY converted to telephone service.
A program doesn't necessarily know where it lives, but it is possible to tell if it's talking to a black box that's been signed by Intel's private key
Not if you emulate the black box, signature and all.
It's one thing to sign something, another to have a local device that can sign with a hidden key that can't be extracted. You need the latter - an unemulatable-because-you-can't-see-its-guts box - to be robust against spoofing the software via an emulation platform.
The main way to detect emulation is response time checking. But that won't work to detect if YOU'RE running on an emulation platform, because the emulation platform can also spoof your idea of time.
Worldcom spent large amounts in start-up costs building physical networks and did not report these expenditures as current period expenses. Instead they deferred these to future peiods where they hoped they'd make money on the new grids.
One of the telecoms got into trouble for doing exactly the opposite: They accounted several billion in operating expenses as capital expenditure.
So money that was just gone for things like wages, electric bills, and gasoline looked like it had bought a few billion in equipment. When the auditors looked around they discovered the company had a few billion less in plant equipment than the books showed, making the book value of the investors stock a lot less.
Oops!
I guess the idea is to not use lpd for printing but instead use it for queueing up MP3 files.
That goes well with the misreading-flast I got when scrolling past the article:
Common Unix Pirating System.
B-)
GPL is based on copyright. This law would mean that GPL code would begin to go into public domain in 50 years, unless somebody like FSF ponies up the bux. And given the plethora of incremental deltas (which, taken alone, will probably be considered "fair use" to apply), renewing copyrights separately on all the versions could get very expen$ive.
(You'll recall that the reason GPL code is not just PD is to keep people from locking up the fixes and improvements.)
Now it could be argued that in something as fast moving as software, something 50 years old is dead. But how old is Unix already, eh? (Not to mention "Hello, world!".) This industry is maturing. Like classical music, things written already, or being written now, are likely to have lasting value and be around a long time.
Alas, RedHat is largely US based.
Alas, Redhat indeed.
As far as I'm concerned RedHat is not ready for prime time - and WON'T be until:
1) Their prepaid included-with-the-expensive-box support continues until your first install is up on the net or LAN (and preferably with a built-from-source kernel), rather than stopping when you first get a login screen.
2) Their quickstart manual includes a clear description (accessable to neophytes - and keystroke-by-keystroke again) of both
* how to install the system (Of particular interest as of 6.x: Tell 'em how to make sane choices for the size of the partitions.) and
* how to obtain and install security upgrades.
3) Their install documentation includes a step-by-step, keystroke-by-kestroke recipe for going:
* from a blank computer and their CDROMs,
* through an intermediate system installed from the CDROM image
* To the SAME system but with the kernel built from the supplied sources.
4) Their in-depth manual includes a section giving a COMPLETE list of the configuration files twiddled by each of the functions of each of the graphic-interface admin tools. (And don't tell me to read the source or look it up on the net. You're a packager. Package it already.)
5) Their quickstart manual tells me how to adjust the screen parameters. (And DON'T tell me to go figure out X. Give a recipe.)
C'mon, guys! Get a tech writer and assign him/her the task with 2), 3), 4), and 5) as the goals.
(And while we're at it, the Gnome and/or KDE crews really ought to do a desktop tool, on the model of Apples', for tuning the screen, and RedHat should have it in the default menus.)
the management team will never work again in corporate America
If only that were true. Unfortunately, private enterprise does a poor job of recognizing a loser manager when it sees one. Even if you take your company into the toilet, you've got experience and a bunch of connections to get that next job.
There is a saying among engineers - especially electrical engineers - to the effect that:
"Expertese is directly proportional to value of equipment destroyed."
The implication being that learning is an ongoing thing, and one of the most effective ways to learn what not to do because it smokes the expensive box is to smoke one.
Perhaps there is a similar saying relating to CEOs who crash companies?
(Interestingly, the saying appears to be largely false. Good engineers learn early to think ahead, and tend to stop smoking expensive boxes, or at least lower the occurrence rate of smoke generation events to near-nill - often before leaving junior high school. Meanwhile, flakes keep frying 'em as long as management lets them twiddle knobs and swap cables. Perhaps this ALSO applies to CEOs. B-) )
So I suppose you still can not slashdot the phone network..
Actually you CAN slashdot the PSTN (Public Switched Telephone Netowork). And you always could. The equipment is sized to handle the expected peak loads with some slop. But there is nowhere near enough equipment in place to handle every phone being connected to another phone.
You can slashdot it at several levels. The commonest is the "all-trunks busy" level - where all the routes from the calling phone to the called number (that the switching equipment knows how to use) are busy. In the older exchanges that produced the tones that sounded like a busy signal but twice as fast. Modern stuff gives you a recording.
You can also tie up all the equipment that gives you a dial tone and collects the digits you dial, by getting enough people on the exchange to try to make calls at once. Usually this just means you wait a second or so for a dial tone - and maybe not even notice it. If it's REALLY severe you might wait seconds, or minutes, and then it is really noticible. But it's also really rare.
The last time I recall that actually happening where I lived was the Loma Prieta earthquake, and the time before was the assassination of JFK. Before that was at an old relay-based exchange (using line-finders rather than registers) where the line finders didn't time out, and a tornado had shorted out enough lines - which made them look "off-hook" - to busy out all the line-finders that could give my phone a dial tone.
Again, modern equipment is more informative: When things get hairy the people operating the network can switch it to a mode where, when you take your phone off the hook, it first connects you to a recording asking you to hold off unless it's an emergency, then giving you a delay followed by a fair chance at a dialtone. (I THINK it actually deliberately delays you a bit even if it COULD have given you a dial tone right away, both to throttle you and to give you a chance to hang up if it wasn't urgent.)
I wonder what would be the world without Ethernet? Would Internet begin and survive just on UUCP/SLIP/PPP?
Would you rather be stuck with Token Ring?
I mean, IBM is a great innovator to be sure. But token ring, IMHO, was one of their great misses.
There's token rings and there's token rings. Saying "Token Ring" when you mean "IBM's Token Ring" is like saying "DOS" when you mean "Microsoft's Disk Operating System".
My guess is that, in the absense of the invention of Ethernet's listen/transmit/back off on collision model, we'd have bootstrapped up from Datapoint's ARCnet.
Like IBM's protocol, ARCnet is also a token ring. But unlike IBM, ARCnet's transport layer is broadcast. So it combines the self-healing characteristics of Ethernet with the delivery-time and latency guarantees of token rings.
ARCnet did have a downside - limited number of addresses on a segment. But there are ways around that. (My favorite is my own variant which I call "bumblenet", involving an aborted binary search for the next station to get the token.)
But for radio, Ethernet-like low-level protocols have a distinct advantage over token rings: They suffer less from the "hidden transmitter" issue - where some devices can hear each other and others can't.
Ethernet-like protocols get their packet through if the transmitter and receiver can hear each other and nobody else within their earshot is talking. So a pair of stations on THIS side of the hill can swap a packet at the same time a pair of stations on the OTHER side are swapping one, without explicitly negotiating about it over relays through other stations - or even knowning about stations on the other side of the hill.
Token rings can work around a hill - even if you have a sparse chain of stations where each can only hear two neighbors. But there's a lot more effort involved. They only get simple when either everybody hears everybody else or everybody talks to exactly two neighbors in a closed ring.