I'm reminded of the "Acme Inescapable Rope" used to tie up Roger and Jessica Rabbit.
Think of spider-silk adhesive as the inclusion. Cut it and you end up with the scissors stuck in the rope and the layers of rope bonded to each other, etc.
Another simple composite, concrete, is wellknown long lifespan.
It also self-heals. When it has set, a significant fraction of the material is still unreacted. Microcracks admit water and restart the setting process, reenforcing them somewhat. You can even grind it up and cast it a second time (though the second-cast will be a LOT weaker).
The phenomenon has been known for a while. I wonder if it was the inspiration for this work?
... [census bureau administration told their workers that] this is the LAST census.
Wishful thinking by the Clinton regime.
They were trying to set a precedent that the census could be done by statistical sampling. If they had succeeded, they could then set up a "sampling" organization and make up any numbers they wanted.
If you think jerrymandering distorts the electoral process, imagine what would happen if the party in power could assign any population numbers they wanted (within reason) to each state, thus changing the state's number of representatives and electoral votes.
"There are people of voting age residing here. There are people who will be of voting age by the next census."
Oops. Make that:
"There are [M] people of voting age residing here. There are [N] people who will be of voting age by the next census."
I keep forgetting that angle brackets delimit HTML tags and I hit the "submit" rather than the "preview" button. (I'd do the hack to get the angle brackets in there but I'm not at the computer where I made the note on how to do it.)
You're assuming that $1 in the future is worth $1 today. In reality, the farther into the future you look, the less a dollar then is worth today.
No, I'm not. I explicitly took that into account with the "bank account" analogy for the time-difference in value of the money.
The cost in current dollars is the amount you have to put into the interest bearing account, in order to have the money to cover the shortfalls at the time they occur. Future withdrawals are a greater number of dollars then the initial deposit.
So how much of that loss is due to the virus and how much of it is actually due to the boneheaded over-reacting "fix" to the problem?
What's boneheaded about it? Can you think of a way requiring LESS down time to make SURE that the virus and anything it corrupted is removed from ANY computer at the company?
Starting a virus is like starting a fire - in this case one that burns through all the computers that are susceptable. After the fire is out the firemen are going to water the ashes and dig them up to make SURE it's out, and build firebreaks to keep it from relighting from the surrounding area (which may still be burning).
- A virus comes in and trashes some files/configs, etc. Some people's work is lost forever and has to be redone. Those people lose days.
- The sysadmins take down the mail server and clean things out. The whole company's email is out of service for hours.
and so on.
Let's suppose it's a high-tek company on the rise. And lets suppose this delays its product introduction by one day.
Now consider the amount of money the company would make FOR THE REST OF TIME, if it hadn't been hit by the virus. Draw the graph of the amount it makes each day and color it in below the graph. That area is the amount of money it takes in.
Now draw the same graph for the company WITH the virus hit. Start by shifting the graph to the right by one day, then lower it to account for the competition beating it to market, irate customers, delayed customers not doing as well and not buying as much product, and so on. Put that graph over the first and erase everything it covers. What's left is a financial flow that the company DIDN'T get because of the virus.
Finally, compute how much money you'd have to put in an account at prevailing interest rates to be able to take out all that money at the time the graph shows it. THAT's the cost of the virus hit - on THAT COMPANY.
(If there are any places where the graph WITH the virus hit is higher than the one without, it represents a deposit rather than a withdrawal. The account should go to zero when the company without the hit folds.)
Of course predicting the actual cost means accurately predicting two futures and taking the difference. So coming up with a number is crystal-ball reading.
Computing the PROVABLE direct loss is another story entirely.
The whole Internet Protocol is equally hokey.
on
DSL Woes
·
· Score: 2
Excuse me? This is high tech? I'm supposed to rely my web business on "try it to see if it works" networking technology?
Sure.
After all, you "rely" your web business on the internet protocol, which uses "best effort" routing rather than reserved bandwidth.
You throw your packets into the network cloud and hope they don't get dropped before the etherwind blows them to their desitnation. B-)
What's hokey about not knowing if the wire quality is up to snuff until you hook up the equipment and TEST it? Different wires have different amounts of rot and different defects, whether they're cat-3 twisted pair, coax, fiber, or whatever. Modem users have been dealing with line quality issues since there were modems, and phone users ditto since there were phones.
Heck - telegraph users before phones, too, and radio-link users have to deal with trees in the microwave beam and ionosphere disturbance. Ad infinitum.
Communication links are part of the big, noisy, analog, real-world.
So what's a KLUDGE about taking a wire design that was intended to take 4 KHz for miles and about 1.5 MHz for a fraction of that (due to frequency-selective attenuation) and take advantage of DSP technology to design a coding scheme that compensates for the attenuation well enough to get 3 miles out of it at about 1.5 MHz?
Luckily some smart folk have reverse engineered and documented the ASF 1 format and are using it to make the avifile project (which currently plays DivXs and ASF using thin layer of Wine to implement the Win32 avifile API) actually implement its codecs natively.
Of course Microsoft could claim DRM is a copy-protection scheme to "effectively" enforce the copyright on the works, and this effort would become a felony under the DCMA. (Running somebody ELSE's software under WINE might skate by, but doing your own would run right into the Feds.)
This strikes me as Microsoft trying to sweet talk the move studios into putting all their content out on their proprietary format. (It shouldn't be too hard, given the association in the studio execs' minds between Linux software and DeCSS.)
If they succeed, they've set up a situation similar to the way VHS pushed out Betamax: The Beta format was better, but VHS had all the movies.
Linux as Betamax, Windows as VMS, and the DCMA to make it a federal felony to fight back.
Replace the sensor with a sensor that have a non-linear response curve. That way lower speeds will be reported more true to the actual speed, much higher speeds will appear much less (say, 80 MPH appears to system as 60MPH).
Won't work if they embed it in the engine control computer and drive it off the same sesore that times the spark.
Yes there is a point in sleeping hardware whether or not it makes a difference on the rolling blackouts! We should be conserving energy, not wasting it, and we shouldn't wait until things are critical before taking action.
First point: The truely limited resource is administration time. If you want to use it to save energy, you have a choice:
- You can throw it at the servers and save a little power, which is consumed at a time where it DOESN'T risk blacking out California.
- You can throw it at the clients and save a LOT of power, much of which is consumed at a time where it DOES risk blacking out California.
Take your pick.
Secondly:
We are less than a hundred million miles from a STAR for crying out loud. There is NO energy shortage. There is only an energy CONVERSION shortage.
The only reason we're still burning fossil fuels to generate power is that it's still CHEAPER than putting up solar panels or powersats.
And the only reason California is browning out is that government and left-wing pressure groups interfered with the market, first by throwing roadblocks in the way of building power plants until the capacity was too small, and second by imposing controls on the power market and breaking the feedback loop.
your 'mission' is most likely a small piece of [deleted]. like keeping a small department up. if it fails, not much of the world is going to be affected.
But if it fails his employment is likely to be affected. I've always taken "mission critical" as meaning "paycheck critical". B-)
Who cares about "the big scheme of things" when he's hunting for his family's next meal?
And it seems to me that the only "big scheme of things" issue I've ever considered important is whether "the people" can, individually, handle their individual issues. Like their quality of life. Which often comes down to continued employment.
If a server is in a position where it can go into a power saving mode, then someone has not done a good job on the server farm.
As others have pointed out, the load on the server farm varies and parts of it could go down when it's light.
Unfortunately, the time when the load is light may not match the time when the load on the grid is heavy. There's no point in shutting down or "sleeping" the servers if it doesn't happen when it might make the difference on the rolling blackouts.
Further, the servers are a drop in the bucket compared to the clients. Workstations in many businesses are NOT needed during the worst of the daily peak, and many of them are only in use part of the day anyhow. There's little to be saved by the effort to hack the server load balancing to accomodate sleeping servers, and a LOT to be gained by activating the automatic sleep-mode features on clients.
So put the effort where there's something to be gained.
Its partially the language C that causes these problems because C has no bound checking on its arrays which can lead to bad situations with buffer overruns and such.
That's because C is an "enough rope" language. Others do some checking, but it costs execution speed, and they still can't block all the holes. C does JUST what you tell it, without waisting cycles on trying to save you from yourself (and giving you a false sense of security). It's up to you to tell it to do whatever checking you want done.
The problem isn't really the language. It's the standard library, which contains some input routines with buffer overflows built in. The biggest culprit is gets(). It was a mistake to put it there, and the manual page now warns you not to use it and what to use to replace it (fgets()). But now it's there, and a bunch of stuff will break if it goes away.
(Of course anything that will break is already broken. So you might want to cut it out of your own library and see what won't link. B-) )
... distros like RedHat (which I use) run everything under the sun when you first install.
Which is truly annoying.
A quick way to give yourself some protection is to configure ipchains first thing to block all inbound everything except responses to things (like TCP sessions) originating inside. Then selectively expose anything you want to be reachable from outside. This limits the (initial) vulnerabilities to the servers you expose and the TCP/IP stack itself.
Even if a server like BIND is running they can't exploit it unless they can get a message to it.
(Of course once they get through a hole in one of the things you DO expose they can open up any others they want. Then all bets are off.)
When installing on a new machine you might want to go out onto the net and get any security tools and patches I might need, roll them onto a floppy, then pull your network connections and reinstall from scratch (reformatting the disk), just in case some kiddie got to the box while the initial wide-open install was running.
Of course you don't want it running open on a home network, either, since it could be used to sniff and attack other machines while it's open. But if you have any other machines you can write that floppy on one of 'em and run both the install and door-locking while the machine is connected to nothing but the power grid and sneakernet. B-)
John is an interesting character. Talks continuously. He stayed at my apartment for a couple days once (int the apple ][ days) and I finally figured out how to shut him up, for two whole minutes:
I showed him something about a phone he didn't already know. B-)
Usually they'll mail them only if they don't know they're bricks. I hear there's a specific regulation about it.
It's not to keep you from mailing bricks attached to business-reply cards...
Seems a LONG time back (like before the US highway system was complete - and I mean US, not Interstate) there was a town in the upper half of lower Michigan, which wanted to build a town hall. Out of bricks.
There were no paved roads nearby, and no brick makers either.
So they bought some bricks down in Detroit and looked into what it would cost to ship them commercially. Then they checked how much it would cost to mail them first-class. First class rates are standard, with the easy-to-deliver metro mail subsidizing the hard-to-deliver cross-country and back-country stuff.
Turned out it was MUCH cheaper to wrap each brick and send it first class than to ship them.
So they did.
And the post office delivered every last one of 'em. At considerable impact to their budget.
And then the regulations were changed - before somebody decided to build a hotel or something. B-)
It is foolish to write a site that depends on java. That mistake is right up there with using Microsoft tools that only display properly on Microsoft browsers. (Unless you're Microsoft, of course. For them it's good marketing.)
One big reason is that a significant fraction of the potential audience browses with java and javascript disabled due to concern over security flaws. (Given that there's a netscape hole that lets a hostile site set up a server on YOUR machine to publish every file you can read, AND notify the hostile site that this is up and running, it's a reasonable concern. B-) )
So if you want a web site to reach the max audience, either forget java or provide a non-java alternate functionality.
CGI runs on the server, so you only depend on the client browser's ability to display.
Even if we get Gnutella to a point where even those folks on dial up modems can participate in the grand link-up, I'm a bit worried about what the broadband ISP monopolies (@home anyone?) will do to dissuade their customers from using such a product.
Good point. Especially given the tie-ins between the content providers and the ISPs. (AOL/Time Warner for example.)
Another thing that I expect to see is deliberate sabotage from the likes of RIAA, in the form of both DOS attacks and attempts to corrupt the database or take advantage of any weakness they find in the protocol to attack the "evil pirates".
I can imagine them discovering a hole that lets them damage a server and exploiting it to trash a lot of people's personal machines, ala the DSS "Black Sunday" incident.
After which I can imagine a BIG lawsuit. B-) Unlike the DSS pirate takedown, THIS would be king-hell illegal.
Wouldn't it be pleasant if the RIAA was finally taken down, permanently, by legal action under the new anti-cracking laws? B-)
Those little "lawn jockies" are a memorial to a hero of the US revolution. To understand this, you need to know about mounted infantry.
Mounted infantry consisted of infantrymen who ride their horses to the battle, then dismount and fight on foot. This means they get the mobility of cavalry, but don't require the training, the special equipment, and the well-trained horse that won't shy on the battlefield. Mounted infantry were a major component of the revolutionary war, because a lot of the militiamen knew how to ride.
When mounted infantry arrive at a battle, they typically dismount in groups of four. Three go to battle, the fourth holds the horses. Typically it's the least-trained fighter in the group.
Holding the horses is very dangerous. They might panic at the sounds and smells of the battle and trample the soldier. Or the battle might spill over to where they are being held and the soldier (with his hands full of paniced horses) is not able to defend himself.
Even when the bulk of the army is straight infantry the field officers and staff were mounted, and the same principles often applied there: Some of them just held the horses some distance from the battle, just as if the officers were a small detachment of mounted infantry.
Among General Washington's staff was his groom, a black man. (Note that not all American blacks at the time were slaves - far from it.) I don't recall his name just now, but it is well documented. This man had VOLUNTEERED to go to war with Washington. In one of the battles he was killed while holding the horses. The tradition of the "lawn jockies" began as a memorial to his heroism, bravery, and sacrifice in the war for independence.
And the idea of a cpu being on a slot really isn't a bad idea (I think pci would be too slow personally). But why oh why would you need a completely different computer in a drive bay (thats assuming you have any available).
This is a variant on a design concept dating from the "Big Board".
For those not familiar with it: The Big Board was a CPM-era machine. In those days when your basic PC was a desktop box the size of a mini-tower, with a front panel full of blinky lights and switches, a pair of EXternal 8" floppy drives. 8080 or Z80 processor, up to 64K of RAM. Alphanumeric dumb terminal or teletype for a console. Brand names like "Altair" or "Imsai" and maybe you assembled it yourself.
As complex-function chips improved a company had a great idea for a cheap process controller: They built a computer-on-a-board. It had a Z80, 64K (the max) of RAM, RAM-window alphanumeric video generator, two parallel ports (one for the keyboard, one for machine control), a serial port, a boot/monitor ROM, a floppy controller, and all supporting circuitry. But that's not all:
The board was exactly the same form factor as the electronics card on the floppy disk, right down to the hole placement and power connector. You just bolted it on top of the drive's board (with longer screws and standoff bushings), powered it with a two-drive power supply, stuffed in a floppy, and you had a machine controller. Plug in a monitor, a keyboard, and/or a network connection if appropriate for your application. Program it with the inexpensive CPM development tools.
Of course what ACTUALLY happened is that the hobbiests got hold of it and used it as a small, cheap, powerful CPM machine for home-computer use. (A little later Xerox licensed the design and built it into a monitor cabinet, to make a CPM machine the form factor of a monitor as their entry into the PC business.)
But the basic idea remained valid. As drives shrank (physically) and processors advanced to X80s you continued to see strap-onto-the-drive single-board computers ("SBC"s) for industrial process automation.
This looks like a variant on the idea: Put it in the slot next to the actual drive on a multi-drive bay (or put two drive mounts into your industrial machine), add power and some interface cables, and you're in business. No one-of engineering to automate your industrial machine, so your engineers only have to design the machine itself. The programming environment is the same as the desktops, so you can use off-the-shelf development tools.
You don't have to reinvent the whole wheel. Just tweak the trim for the new model year. B-)
This thing was invented at least ten years ago. It didn't end up in volume production at least partially because the guy who patented it wanted it built in the USA only.
Slashdot Mirror
I'm reminded of the "Acme Inescapable Rope" used to tie up Roger and Jessica Rabbit.
Think of spider-silk adhesive as the inclusion. Cut it and you end up with the scissors stuck in the rope and the layers of rope bonded to each other, etc.
Another simple composite, concrete, is wellknown long lifespan.
It also self-heals. When it has set, a significant fraction of the material is still unreacted. Microcracks admit water and restart the setting process, reenforcing them somewhat. You can even grind it up and cast it a second time (though the second-cast will be a LOT weaker).
The phenomenon has been known for a while. I wonder if it was the inspiration for this work?
... [census bureau administration told their workers that] this is the LAST census.
Wishful thinking by the Clinton regime.
They were trying to set a precedent that the census could be done by statistical sampling. If they had succeeded, they could then set up a "sampling" organization and make up any numbers they wanted.
If you think jerrymandering distorts the electoral process, imagine what would happen if the party in power could assign any population numbers they wanted (within reason) to each state, thus changing the state's number of representatives and electoral votes.
Fortunately the courts slapped 'em down.
The processes they described DO corrupt the data for statisitcal analysis.
When they switch some of the entries among people on the same block you can't get proper results when looking for correlations.
When they add noise your statistical significance tresholds rise and you can't detect small effects.
"There are people of voting age residing here. There are people who will be of voting age by the next census."
Oops. Make that:
"There are [M] people of voting age residing here. There are [N] people who will be of voting age by the next census."
I keep forgetting that angle brackets delimit HTML tags and I hit the "submit" rather than the "preview" button. (I'd do the hack to get the angle brackets in there but I'm not at the computer where I made the note on how to do it.)
When the census polls me, I tell them:
"There are people of voting age residing here. There are people who will be of voting age by the next census."
That's all they're constitutionally entitled to know. (Actually, it's even more than they're entitled to know. The first half is sufficient.)
They try to make it SOUND like you have to answer all the rest of the questions or face a fine. You don't.
You're assuming that $1 in the future is worth $1 today. In reality, the farther into the future you look, the less a dollar then is worth today.
No, I'm not. I explicitly took that into account with the "bank account" analogy for the time-difference in value of the money.
The cost in current dollars is the amount you have to put into the interest bearing account, in order to have the money to cover the shortfalls at the time they occur. Future withdrawals are a greater number of dollars then the initial deposit.
So how much of that loss is due to the virus and how much of it is actually due to the boneheaded over-reacting "fix" to the problem?
What's boneheaded about it? Can you think of a way requiring LESS down time to make SURE that the virus and anything it corrupted is removed from ANY computer at the company?
Starting a virus is like starting a fire - in this case one that burns through all the computers that are susceptable. After the fire is out the firemen are going to water the ashes and dig them up to make SURE it's out, and build firebreaks to keep it from relighting from the surrounding area (which may still be burning).
Viruses are probably even MORE costly. Consider:
- A virus comes in and trashes some files/configs, etc. Some people's work is lost forever and has to be redone. Those people lose days.
- The sysadmins take down the mail server and clean things out. The whole company's email is out of service for hours.
and so on.
Let's suppose it's a high-tek company on the rise. And lets suppose this delays its product introduction by one day.
Now consider the amount of money the company would make FOR THE REST OF TIME, if it hadn't been hit by the virus. Draw the graph of the amount it makes each day and color it in below the graph. That area is the amount of money it takes in.
Now draw the same graph for the company WITH the virus hit. Start by shifting the graph to the right by one day, then lower it to account for the competition beating it to market, irate customers, delayed customers not doing as well and not buying as much product, and so on. Put that graph over the first and erase everything it covers. What's left is a financial flow that the company DIDN'T get because of the virus.
Finally, compute how much money you'd have to put in an account at prevailing interest rates to be able to take out all that money at the time the graph shows it. THAT's the cost of the virus hit - on THAT COMPANY.
(If there are any places where the graph WITH the virus hit is higher than the one without, it represents a deposit rather than a withdrawal. The account should go to zero when the company without the hit folds.)
Of course predicting the actual cost means accurately predicting two futures and taking the difference. So coming up with a number is crystal-ball reading.
Computing the PROVABLE direct loss is another story entirely.
Excuse me? This is high tech? I'm supposed to rely my web business on "try it to see if it works" networking technology?
Sure.
After all, you "rely" your web business on the internet protocol, which uses "best effort" routing rather than reserved bandwidth.
You throw your packets into the network cloud and hope they don't get dropped before the etherwind blows them to their desitnation. B-)
What's hokey about not knowing if the wire quality is up to snuff until you hook up the equipment and TEST it? Different wires have different amounts of rot and different defects, whether they're cat-3 twisted pair, coax, fiber, or whatever. Modem users have been dealing with line quality issues since there were modems, and phone users ditto since there were phones.
Heck - telegraph users before phones, too, and radio-link users have to deal with trees in the microwave beam and ionosphere disturbance. Ad infinitum.
Communication links are part of the big, noisy, analog, real-world.
So what's a KLUDGE about taking a wire design that was intended to take 4 KHz for miles and about 1.5 MHz for a fraction of that (due to frequency-selective attenuation) and take advantage of DSP technology to design a coding scheme that compensates for the attenuation well enough to get 3 miles out of it at about 1.5 MHz?
Luckily some smart folk have reverse engineered and documented the ASF 1 format and are using it to make the avifile project (which currently plays DivXs and ASF using thin layer of Wine to implement the Win32 avifile API) actually implement its codecs natively.
Of course Microsoft could claim DRM is a copy-protection scheme to "effectively" enforce the copyright on the works, and this effort would become a felony under the DCMA. (Running somebody ELSE's software under WINE might skate by, but doing your own would run right into the Feds.)
This strikes me as Microsoft trying to sweet talk the move studios into putting all their content out on their proprietary format. (It shouldn't be too hard, given the association in the studio execs' minds between Linux software and DeCSS.)
If they succeed, they've set up a situation similar to the way VHS pushed out Betamax: The Beta format was better, but VHS had all the movies.
Linux as Betamax, Windows as VMS, and the DCMA to make it a federal felony to fight back.
Replace the sensor with a sensor that have a non-linear response curve. That way lower speeds will be reported more true to the actual speed, much higher speeds will appear much less (say, 80 MPH appears to system as 60MPH).
Won't work if they embed it in the engine control computer and drive it off the same sesore that times the spark.
The system uses GPS to figure out if the vehicle is in a speed limited zone.
So make a low-power GPS transmitter and fool it into thinking you're on the Autobahn.
"Every new law is a new opportunity for graft."
- From Heinlein's "Red Planet"
Yes there is a point in sleeping hardware whether or not it makes a difference on the rolling blackouts! We should be conserving energy, not wasting it, and we shouldn't wait until things are critical before taking action.
First point: The truely limited resource is administration time. If you want to use it to save energy, you have a choice:
- You can throw it at the servers and save a little power, which is consumed at a time where it DOESN'T risk blacking out California.
- You can throw it at the clients and save a LOT of power, much of which is consumed at a time where it DOES risk blacking out California.
Take your pick.
Secondly:
We are less than a hundred million miles from a STAR for crying out loud. There is NO energy shortage. There is only an energy CONVERSION shortage.
The only reason we're still burning fossil fuels to generate power is that it's still CHEAPER than putting up solar panels or powersats.
And the only reason California is browning out is that government and left-wing pressure groups interfered with the market, first by throwing roadblocks in the way of building power plants until the capacity was too small, and second by imposing controls on the power market and breaking the feedback loop.
your 'mission' is most likely a small piece of [deleted]. like keeping a small department up. if it fails, not much of the world is going to be affected.
But if it fails his employment is likely to be affected. I've always taken "mission critical" as meaning "paycheck critical". B-)
Who cares about "the big scheme of things" when he's hunting for his family's next meal?
And it seems to me that the only "big scheme of things" issue I've ever considered important is whether "the people" can, individually, handle their individual issues. Like their quality of life. Which often comes down to continued employment.
If a server is in a position where it can go into a power saving mode, then someone has not done a good job on the server farm.
As others have pointed out, the load on the server farm varies and parts of it could go down when it's light.
Unfortunately, the time when the load is light may not match the time when the load on the grid is heavy. There's no point in shutting down or "sleeping" the servers if it doesn't happen when it might make the difference on the rolling blackouts.
Further, the servers are a drop in the bucket compared to the clients. Workstations in many businesses are NOT needed during the worst of the daily peak, and many of them are only in use part of the day anyhow. There's little to be saved by the effort to hack the server load balancing to accomodate sleeping servers, and a LOT to be gained by activating the automatic sleep-mode features on clients.
So put the effort where there's something to be gained.
Its partially the language C that causes these problems because C has no bound checking on its arrays which can lead to bad situations with buffer overruns and such.
That's because C is an "enough rope" language. Others do some checking, but it costs execution speed, and they still can't block all the holes. C does JUST what you tell it, without waisting cycles on trying to save you from yourself (and giving you a false sense of security). It's up to you to tell it to do whatever checking you want done.
The problem isn't really the language. It's the standard library, which contains some input routines with buffer overflows built in. The biggest culprit is gets(). It was a mistake to put it there, and the manual page now warns you not to use it and what to use to replace it (fgets()). But now it's there, and a bunch of stuff will break if it goes away.
(Of course anything that will break is already broken. So you might want to cut it out of your own library and see what won't link. B-) )
... distros like RedHat (which I use) run everything under the sun when you first install.
Which is truly annoying.
A quick way to give yourself some protection is to configure ipchains first thing to block all inbound everything except responses to things (like TCP sessions) originating inside. Then selectively expose anything you want to be reachable from outside. This limits the (initial) vulnerabilities to the servers you expose and the TCP/IP stack itself.
Even if a server like BIND is running they can't exploit it unless they can get a message to it.
(Of course once they get through a hole in one of the things you DO expose they can open up any others they want. Then all bets are off.)
When installing on a new machine you might want to go out onto the net and get any security tools and patches I might need, roll them onto a floppy, then pull your network connections and reinstall from scratch (reformatting the disk), just in case some kiddie got to the box while the initial wide-open install was running.
Of course you don't want it running open on a home network, either, since it could be used to sniff and attack other machines while it's open. But if you have any other machines you can write that floppy on one of 'em and run both the install and door-locking while the machine is connected to nothing but the power grid and sneakernet. B-)
John is an interesting character. Talks continuously. He stayed at my apartment for a couple days once (int the apple ][ days) and I finally figured out how to shut him up, for two whole minutes:
I showed him something about a phone he didn't already know. B-)
Yeah, they'll mail bricks, but...
Usually they'll mail them only if they don't know they're bricks. I hear there's a specific regulation about it.
It's not to keep you from mailing bricks attached to business-reply cards...
Seems a LONG time back (like before the US highway system was complete - and I mean US, not Interstate) there was a town in the upper half of lower Michigan, which wanted to build a town hall. Out of bricks.
There were no paved roads nearby, and no brick makers either.
So they bought some bricks down in Detroit and looked into what it would cost to ship them commercially. Then they checked how much it would cost to mail them first-class. First class rates are standard, with the easy-to-deliver metro mail subsidizing the hard-to-deliver cross-country and back-country stuff.
Turned out it was MUCH cheaper to wrap each brick and send it first class than to ship them.
So they did.
And the post office delivered every last one of 'em. At considerable impact to their budget.
And then the regulations were changed - before somebody decided to build a hotel or something. B-)
Most web sites are Java-based
It is foolish to write a site that depends on java. That mistake is right up there with using Microsoft tools that only display properly on Microsoft browsers. (Unless you're Microsoft, of course. For them it's good marketing.)
One big reason is that a significant fraction of the potential audience browses with java and javascript disabled due to concern over security flaws. (Given that there's a netscape hole that lets a hostile site set up a server on YOUR machine to publish every file you can read, AND notify the hostile site that this is up and running, it's a reasonable concern. B-) )
So if you want a web site to reach the max audience, either forget java or provide a non-java alternate functionality.
CGI runs on the server, so you only depend on the client browser's ability to display.
Even if we get Gnutella to a point where even those folks on dial up modems can participate in the grand link-up, I'm a bit worried about what the broadband ISP monopolies (@home anyone?) will do to dissuade their customers from using such a product.
Good point. Especially given the tie-ins between the content providers and the ISPs. (AOL/Time Warner for example.)
Another thing that I expect to see is deliberate sabotage from the likes of RIAA, in the form of both DOS attacks and attempts to corrupt the database or take advantage of any weakness they find in the protocol to attack the "evil pirates".
I can imagine them discovering a hole that lets them damage a server and exploiting it to trash a lot of people's personal machines, ala the DSS "Black Sunday" incident.
After which I can imagine a BIG lawsuit. B-) Unlike the DSS pirate takedown, THIS would be king-hell illegal.
Wouldn't it be pleasant if the RIAA was finally taken down, permanently, by legal action under the new anti-cracking laws? B-)
Those little "lawn jockies" are a memorial to a hero of the US revolution. To understand this, you need to know about mounted infantry.
Mounted infantry consisted of infantrymen who ride their horses to the battle, then dismount and fight on foot. This means they get the mobility of cavalry, but don't require the training, the special equipment, and the well-trained horse that won't shy on the battlefield. Mounted infantry were a major component of the revolutionary war, because a lot of the militiamen knew how to ride.
When mounted infantry arrive at a battle, they typically dismount in groups of four. Three go to battle, the fourth holds the horses. Typically it's the least-trained fighter in the group.
Holding the horses is very dangerous. They might panic at the sounds and smells of the battle and trample the soldier. Or the battle might spill over to where they are being held and the soldier (with his hands full of paniced horses) is not able to defend himself.
Even when the bulk of the army is straight infantry the field officers and staff were mounted, and the same principles often applied there: Some of them just held the horses some distance from the battle, just as if the officers were a small detachment of mounted infantry.
Among General Washington's staff was his groom, a black man. (Note that not all American blacks at the time were slaves - far from it.) I don't recall his name just now, but it is well documented. This man had VOLUNTEERED to go to war with Washington. In one of the battles he was killed while holding the horses. The tradition of the "lawn jockies" began as a memorial to his heroism, bravery, and sacrifice in the war for independence.
And the idea of a cpu being on a slot really isn't a bad idea (I think pci would be too slow personally). But why oh why would you need a completely different computer in a drive bay (thats assuming you have any available).
This is a variant on a design concept dating from the "Big Board".
For those not familiar with it: The Big Board was a CPM-era machine. In those days when your basic PC was a desktop box the size of a mini-tower, with a front panel full of blinky lights and switches, a pair of EXternal 8" floppy drives. 8080 or Z80 processor, up to 64K of RAM. Alphanumeric dumb terminal or teletype for a console. Brand names like "Altair" or "Imsai" and maybe you assembled it yourself.
As complex-function chips improved a company had a great idea for a cheap process controller: They built a computer-on-a-board. It had a Z80, 64K (the max) of RAM, RAM-window alphanumeric video generator, two parallel ports (one for the keyboard, one for machine control), a serial port, a boot/monitor ROM, a floppy controller, and all supporting circuitry. But that's not all:
The board was exactly the same form factor as the electronics card on the floppy disk, right down to the hole placement and power connector. You just bolted it on top of the drive's board (with longer screws and standoff bushings), powered it with a two-drive power supply, stuffed in a floppy, and you had a machine controller. Plug in a monitor, a keyboard, and/or a network connection if appropriate for your application. Program it with the inexpensive CPM development tools.
Of course what ACTUALLY happened is that the hobbiests got hold of it and used it as a small, cheap, powerful CPM machine for home-computer use. (A little later Xerox licensed the design and built it into a monitor cabinet, to make a CPM machine the form factor of a monitor as their entry into the PC business.)
But the basic idea remained valid. As drives shrank (physically) and processors advanced to X80s you continued to see strap-onto-the-drive single-board computers ("SBC"s) for industrial process automation.
This looks like a variant on the idea: Put it in the slot next to the actual drive on a multi-drive bay (or put two drive mounts into your industrial machine), add power and some interface cables, and you're in business. No one-of engineering to automate your industrial machine, so your engineers only have to design the machine itself. The programming environment is the same as the desktops, so you can use off-the-shelf development tools.
You don't have to reinvent the whole wheel. Just tweak the trim for the new model year. B-)
This thing was invented at least ten years ago. It didn't end up in volume production at least partially because the guy who patented it wanted it built in the USA only.