It's stalling because it CO$T$, guys!
on
CNN On IPv6
·
· Score: 3
To help push IPv6 forward, the Internet Assigned Numbers Authority on July 19 gave regional registries around the world the go-ahead to begin assigning numbers based on the new standard. So far, the majority of the organizations that requested IPv6 numbers are research departments and universities. The only commercial ISPs to ask for such address blocks are two Japanese firms, Internet Initiative Japan and Nippon Telegraph & Telephone.
The regional registries are charging big bucks for blocks of numbers and managing them as if they were as scarce as IPv4 address space - or as if the world was beating down their door and needed to be throttled. Results: Only the big router builders' research departments (garage shops need not apply) and the universities (grant money and need to keep at the cutting edge) are interested.
ISPs aren't going to buy numbers until they roll out the infrastructure. Why tie up even a few grand now, when you're not going to use the numbers until later? There's enough numbers to give one to every hair on every human's head, so they won't run out if you don't jump early. (And they want to encode routing in the numbers, so it might be better to wait.)
What burns me is that price tag. The home experimenters can't get in on this unless they ante up (or do all their work with bogus numbers - which is problematic when you want to start interconnecting with the other guys). So we get to depend on the Cisco/3Com/Ascends of the world.
Microsoft would be proud.
Hmmm... Maybe we ought to pick a block UNofficially and divy it up for playing with. B-)
Corel has a plausible argument that they are NOT actually RELEASING this code yet (note that they're only giving it to a limited selection of volunteers, not making it generally FTPable), that they have some of their proprietary packages mixed in there which they do NOT intend to open-source, and that they were simply trying to accellerate the beta test by not holding things up to sort them out, instead relying on the contract with the beta testers (trading pre-release access for their work and waiver of rights under the open-source licenses).
Now they may not have a leg to stand on. But then again they may. And they HAVE announced an intention to release the source according to the appropriate open-source license terms with the general release, and to sell a separate distribution with their closed-source intellectual property added.
So the courts might agree with them. And other prospective open-source providers might be turned off if someone "bites the hand that feeds them" by publishing Corel's IP along with the beta.
Some time back I wrote a patch for a public-domain Z80 assembler to let you also use the intel opcodes (with a pseudo-op to switch between them), to simplify some porting of an 8080 ROM monitor/debugger. The Z80 was "trailing edge" technology at the time, so I didn't publish them. Maybe I ought to now. (If I can find 'em. B-) )
My home IS "node"(.com) on the internet - and was (and still is) "node" on the UUCP flat address space before the domain addressing coup. That it is a "good" four-letter sitename should give you some idea how long it's been around.
"Node" was my second choice - I'd wanted "home", so I could have the email address "@home". B-) I missed getting "home" by a few days - during the several weeks it took the sysadmin of my first UUCP connection to get me the registration form.
Seriously, I am wondering why they want to restrict this to alzheimers patients.
Because it's a big risk. Inserting cells producing a nerve growth factor into the skull could cause all sorts of problems with overgrowth of nerve and related tissues - resulting in nasty brain damage or fatality. A particular risk is brain tumors, especially mama/baby tumors where two types of cells, at least one immortalized, manufacture each other's growth factors in a positive feedback loop.
So they'll start with people who are ALREADY having their brains slowly but unstoppably destroyed by another disease process. At worst it will just speed up something that's already happing. At best it might slow, halt, or reverse the disease - perhaps by promoting replacement of the brain tissue as it is destroyed, perhaps by invigorating the existing cells to resist the problem or switching them to a mode where they aren't "yet" susceptable.
One of the reasons UNIX achieved such a large penetration on diverse hardware platforms, back when it was Bell Labs' baby, was the defacto free trial period for designers, creating a revolution in operating systems.
Up to that point, if you built a computer you had to write your own custom OS - in assembler. That's not a garage operation. But now along came UNIX:
You were supposed to have a source license. But the source code circulated freely (due to a bunch that had been handed to universities) and Mama Bell didn't bother with you until you were ready to sell it, and then didn't hold any grudges for your "illegal" use of the source when it came time to price your license. The kernel was tiny and easy to port - and mostly in a compiler language yet! So a whole new model of OS construction became prevalant:
Suppose you've got your new box (or a design for it and a prototype coming together), with it's new processor and new peripherals.
First: If it's a new CPU, add a code generator for it to the Portable C Compiler (PCC). Compile once to get a cross-compiler (to use on your development platform), then use that to compile again to get a native compiler (to run on your target, once it's up).
Second: Port (and configure) the kernel. You probably have to modify the memory management code, the task-switcher, and the raw disk and console driver. Write drivers for any new-fangled peripherals (though you can probably modify them from stock stuff, too) - but that can wait 'til you're running native.
Third: Port the ROM bootloader. (It uses the drivers you already ported, above.) Burn it into a PROM. Plug it into the lab box.
Fourth: Compile all the utilities with your cross-compiler and build an initial root disk - using your current UNIX platform to write it.
Fifth: Plug the disk into your new box. Boot up. You're live. Debug and expand on your shiny new lab box.
Sixth: Call up AT&T and negotiate price of a license to distribute this puppy, after you got it to work so there's no longer any risk.
Seventh: Show the vulture capitalists your working shiny new box. Get your working capital with a high valuation on your company (so you still own most of it).
Eighth: Build it and ship it.
This you can do in a garage shop (or as a grad school project). And it happened just as a couple decent microprocessors hit the market, too. So there was a decade or more where dozens of UNIX boxes, on diverse platforms, sprang up like weeds.
Looks to me like Sun wants to use the same model with the SPARC CPU core, to penetrate the ASIC market (which MIPS and ARM currently dominate). They're making the SPARC processor core free to the shoestring fabless-chip-house startups, during that difficult design period when they're still hanging by their shoestring.
The federal government gives immunity to such suits to officials doing their jobs. The law dates from the "Reconstruction Era" after the Civil War, when states and their citizens tried to stop federal officials by suing them under state or federal law.
There are a VERY few exceptions - such as for malicious violation of civil rights - but not for mere incompetence.
But it has to be obvious to a master of the trade who hasn't been shown the solution. The "Oh, of COURE!" style of obvious doesn't cut it. The classic case of this is patent on the "sealed in steel" dry-cell battery.
Back in the old days, the outer case of a dry cell was a cardboard tube wrapped around a zinc cup, and that zinc cup was the battery's sacrificial negative electrode. If you didn't throw out the battery before discharging it put the first hole in the zinc (i.e. while the flashlight still lit up just fine), the corrosive electrolyte paste would leak out and eat your flashlight.
Well Ray-O-Vac had a long-running R&D project to improve on that, and it had no luck. One day a member of the team came home in a blue funk and his wife (while cooking dinner) asked him what was wrong. He described the problem, and she says "Why don't you seal it in a steel can?"
Well, DUH!
So they tried it. And it worked. And Union Carbide (Everready), who had run similar but UNsuccessful long-term project, sued because it was "obvious".
So the judge asked the defense how long it had taken them to figure this out (I don't recall how many years). Then he asked the plaintif, and got a similar response. And he threw out the suit.
BUT...
The REAL issue is not whether it's obvious to a worker in the field, but whether the judge THINKS it is. So the game is to try to get it in front of the right judge. (For a long time patent challenges were always filed in the federal court district that tries its cases in Chicago, because there was this one judge who thought that EVERYTHING was obvious... B-) )
It would be interesting if someone could come up with a way to bill the holder of a bogus patent for more than the cost of proving it bogus in court. That would promote both better searches and a cottage industry of shooting holes in bogus patents.
Might not be a good thing, though. It would also give the big guys more ways to make it tough on the little guys.
One thing US jurisprudence really needs is a "loser pays" allocation of court costs, reasonable attorney fees, and perhaps reimbursement for other damages resulting from a lost suit. That would provide a financial disincentive for bogus lawsuits, and might be extended to damages resulting from the attempted enforcement of bogus patents, providing a financial disincentive there, too.
Yeah, some companies believe that years of evolved systems designed for their business can be inexpensively replaced with "general purpose, off-the-shelf" packages. Generally, I think those folks are nuts. I think that it is usually much more expensive to replace old-but-well-optimized applications with a general purpose package, in both the short term and the long term.
On the other hand, rooting out Y2K bugs from all those evolved systems - all one-ofs, most with the programmers gone away - can be a major disaster.
But if you convert your business process to a specialized configuration of a general-purpose package, you can sidestep the issue. If it's a popular enough GP package, the core will be fixed by the vendor (if it hasn't been already). The Y2K costs for the core will have been distributed over a large number of customers.
As long as you're going to thrash the company's DP for Y2K anyhow, why not re-analyze your processes and go to a supported platform? That way you also end up with fresh code, that your current DP employees understand, which fits your current business model, takes advantage of advances in tools, and does it all with a single thrash?
Doesen't it seem odd to you that the only significant "competition" being cited is a system being given away for free? How is it a competitive environment when one company can sell its product for real bucks and everybody else has to give theirs away and make money on packaging and service, or get squeezed out?
Isn't it "harm" that Netscape had to stop selling its browser and start giving it away to keep Microsoft from taking over the browser market? Isn't $0/copy the limiting case of a cross-subsidy?
Looks to me like there are two ways this might impact crypto:
On one hand, the Fed might decide to open up crypto so they could get better stuff. (And pigs might start to fly.)
On the other hand, the Fed might start having its own Linux distribution, or NSA/military/etc. crypto add-ons for NSA/military/etc.-certified configurations of commercial products. This is how I expect them to go.
This second approach has two variants: They might loosen up crypto for the general public, or they might try to keep it locked up.
In either case, when crypto-enhanced stuff is distributed widely among the civilian portion of the government, it's only a matter of time until the object code leaks out, is reverse-engineered, and appears as bare source, as plug-ins, and what-have you. Then it gets analyzed in the open crypto community, and anything useful gets integrated into the general code base.
The remaining variable is how much the government fights this. If they try to stay tight, expect loud screaming about espionage and nasty crackers and the like. They'll slow it down a bit. But the main result of their fighting will be to continue to retard crypto among the US civilian population relative to the rest of the world, making us fall progressively behind on computer secutiry, and leaving US private and private-enterprise systems more open to snooping and attack than they otherwise might be.
Of course that might be what they want: The main problem for an oppressive government is keeping its own population under control.
Should a general really be concerned about TCP stack bugs? Should a general even know that his computer has a TCP stack?
If he's the general in charge of evaluating, obtaining, modifying, and deploying some computer system for the military, or making the selection of an OS for the military, he and/or his subordiantes should be concerned about it. If he's a general using them, he should only have to worry about the likelyhood of his security being compromized, and delegate these matters to the people below him.
A general has too much else to think about to be involved with the details of everything under his command.
And the same holds true for everybody else in large organizations, government or private. The system security is the job of particular people, who should know at least as much as they need to know to do the job right - and some extra to be sure they didn't miss something. But the rest of the people - from the President to the Receptionist - only needs to know enough to be sure they don't compromize security by improper operation, plus enough more to motivate them not to skimp to save some effort - or to interfere in the selection process.
Colt sold the M16 as a point and shoot automatic rifle, no cleaning required. When it was used as advertised a combination of the South East Asian climate and powder residue/gunk caused the failures
That's not the whole story.
When used with the specified ammuntion, the original M16 worked as advertised. But there was an admiral who had a warehouse full of ball powder that was going out of date. It was the sort that was in bags, and you throw several of the bags into the breech of a big naval gun on a battleship. So he decided to save the Navy a few bucks by having the poweder made up into ammo for this new gun the Marines had just started using in the current war, instead of buying this expensive fancy-schmancy clearn-burn ammo that looked like another $200-hammer boondoggle.
Now when you're firing a bullet the size of a large automobile, from a gun reloaded by a conveyor-belt or something similar, you're not too concerned about powder residue fouling the barrel and loading mechanism. But when you're firing something the size of a.22 bullet, with a reloading mechanism powered by a similarly-sized piston in a cylinder filled with the combustion gasses, a little smoke residue quickly clogs the works.
And while a warehouse full of powder for navy guns might only make for few dozen volleys of those guns, it can make up a LOT of ammo for overpowered.22s like the M16.
So the Marines (and others) got a lot of bad ammo. And even with the spray-and-pray style of fighting (where they even used M16s to cut grass) it took a long time to shoot it up. Meanwhile, those M16s were clogging up, and people were dying, and the new-fangled gun got blamed. So they retrofitted it with that knob to get it restarted when it stuck, and passed out some cleaning kits. And people got by. And eventually the bad ammo got used up or discarded and things went back to working.
So if you want G2 certification for your proprietary system, you have to give the source to NSA.
Any bets on whether they pass it on to their intrusion department?
It's not a problem for Open Source of course. We've got much of the world's programmer stock on our side of the security game. But with Closed Source the NSA could easily put far more crackers onto a project to break the code's security than the vendor can afford to put on cerating and fixing it.
One of my colleagues didn't study with the source, although they did study the architecture. He maintains that the Kernel itself is designed quite well, and that the user level stuff is so bad...
I hear that the NT kernel is reasonably good because they hired the architect of the VMS operating system to run the project, and he did it largely as a VMS clone/next generation. Person who told me this also says that most of the major data structures retain the VMS naming.
How did the bacteria have a chance to evolve from 100 genes to 350 if it could not survive with 100?
RNA strands alone can make a complimentary copy of themselves, given the right raw materials and environment. But it's SLOOOOOOOOOW, and it's error-prone. RNA can also have enzymatic activity.
So a plausable scenario for starting life is the random assembly of an RNA strand that occasionally folds up into an RNA enzyme that facilitates RNA-directed RNA synthesis - even slightly. The first time one of these folds up near a complimentary copy of itself that had been assembled by the random method and copies it, you've got your start. There's now a place in the soup where a particular RNA pattern is efficiently copying RNA patterns, in a concentration of RNA strands with its own pattern.
Once this occurs, it's a matter of incremental improvement through error-and-trial. You'll have RNA "parasites" - any other RNA strands with the right characteristics will also be grabbed and copied. Some of these will evolve into symbionts - additional RNA enzymes that complex with the basic copier to form a more efficient copying complex - thus giving themselves an evolutioinary advantage over the random parasites. One might facilitate binding. Another might hang a repeating code on the ends of strands - which are hard to copy correctly. Another might crack an energetic molecule and use the released energy to speed up a slow part of the reaction. Another might help stick the complex together, while yet another might break it appart occasionally so its pieces can be copied by a neighbor. Another might form a barrier, to let in raw materials while blocking parasites and toxic junk. And because these RNA gene/enzymes are all error prone they all evolve, with complexes contatining the improved models outdoing those without them.
Very quickly (in geological time) you have billions of these little machines doing parallel computation on the life/invention algorithm. You get major inventions, each with an incremental improvement: Gene-damage repair systems. Backup copies in the related, but more stable, DNA. Chemo- and Photo-synthesis of the energetic molecules that power the system. Protien enzyme synthesis - both of peripheral devices and of replacement or additional parts of the replication complex (though even now it's largely RNA-based.) Gene expression regulation. Cooperative groups of cells, each of which has an invention to contribute, forming a super-cell, with the original cells becoming organelles and perhaps consolidating their genetic material. An inner barrier to isolate the genetic machine from the surrounding factory. Synchronized replication of genetic material and the containing package(s).
But very early on you get hunters.
As soon as you have a self-replicating system it starts consuming the local raw materials. As soon as you have a divergent copy you have competition for raw materials. As soon as you have a self-replicating system you have concentrations of the raw materials in the form of the finished products. So it isn't too far along this path when one of the little replicants figures out how to take another apart and get something useful from the pieces.
Once that happens, you start a whole new set of evolutionary games: Arms vs Armor. Identification of relatives and selective predation on things not like onself. Mimicry and disguise. The list is long.
And in this battle zone the original, lazy, brownian-motion-powered, one-RNA-gene replicant is just food for these new war machines, with their armored surfaces covered with protien enzymes to grab the pieces and haul them in, and their guts filled with little vats of chemicals to tear them into their useful components and build more war machines, all powered by high-energy reactions running at blazing speed. The original model doesn't stand a chance- it looks like a slightly concentrated bit of nearly-inert food. And even at human time scales it is so slow we might not recognize it as alive. (It might have reproduced more slowly than a century palm.)
Getting one of the late-model war machines to work with only 350 genes is quite a feat.
Even if the signal didn't leak out - making the powerline-borne signal just another copy of what's in the aether - it would still have been one big party line - with the whole world on it.
By comparison, a T3 propagates on a coax cable, not leaky open lines, and it's good for less than half a 100 Mbps LAN, less than a 20th of a gigabit ethernet. Neglecting compression, it's only good for 116 phone calls or 56KB to 64KB data links, or 28 T1 connections.
This thing would have been a drop in the bucket.
Raise your frequency and you get more data but less range (and more leakage) - requiring the addition of repeaters all over the place, and thus eliminating most of the advantage of using the installed base. (And you also need a mod at every transformer to get the higher frequency stuff passed from one side to another of a device designed for low audio frequencies.) If you're going to send a lineman out to add equipment for each cluster of a half-dozen homes, why not just string some fiber while you're at it?
A year or so ago my ISP at the time, which is located in the OTHER major metropolitan area of California, decided to drop its service to silicon valley - leaving me in the lurch just as I was moving across the bay anyhow.
So I installed a copy of SLiRP on my netcom shell account, and used that for network connectivity until a couple months ago - when I finally got an ADSL link. I still use it as a backup for when Pack Bell dies on me.
My mail exchanger has always been separate from my ISP, reached via UUCP polling. (This lets me change ISPs without losing mail connectivity.) The mail server has two entries for it in the Systems file, the first one trying (twice!) to make a UUCP-over-IP connection if the net is up. The second dials up the exchanger via modem if the first fails and the modem is free. In the days when my network connection was also via phone - either to the fly-by-night ISP or the SLiRP hack, it used the same modem - after I tweaked my PPP install to use the same locking scheme. If the net was up, it used it in the background. If it had dropped, it made the call. All automagic. (I have an alias that forces a poll if I want to be sure something goes out right away or check for mail without waiting for the next poll.)
Now when on the road I can call into the same modem from any phone, picking up and dropping off mail (again via UUCP-over-IP-over-PPP) in parallel with tweaking the home network or doing a quick surf. (Who needs POP and fetchmail?)
If I ever decide to save a few bucks and downgrade from "enhanced" to "basic" DSL, SLiRP is one way to let my whole net of machines masquerade as a single host on the one IP number.
So these "obsolete" protocols aren't really so obsolete.
This is back where they started. Sun pioneered the dick^H^H^H^Hdiskless workstation, after all. (I hear even the company name is an acronym for Stanford University Network, a project from which they spun out.)
The diskless workstation was the result of an observation: Ethernet (10Mbps) is fast enough that mounting a (VERY expensive at the time) disk on a central server and accessing it over a network was about as fast as having a local disk at a machine - and with several machines it was a LOT cheaper, letting you have many more workstations of comparable capacity for the same budget.
Their first machines had a processor, some local RAM, a screen buffer, and a network interface, but the disk controller and disk were optional. Any machine with a disk could serve it to any machine that didn't have one. All machines shared most of the file systems - so you could access your files (and your neighbors, and your shared resources) from any workstation, and there could be one copy of software for all the clients. Diskless machines put their root partition and swap space on a server, too, doing the computation and graphics rendering locally but consolidating all the mass storage centrally. You got the power of a decent machine on your desk, at a fraction of the cost. And you got better disk utilization, on larger (and thus cheaper-per-megabyte) drives.
Thin client is the same idea, carried a step farther: The local network is now fast enough to shove bitmaps around rather than rendering them locally. So you can push the crunch back into the server room, too. Do the computation and the rendering in a suitable processor farm, and put just enough machine on each desk to handshake the network and unpack the graphics.
But crunch is cheap enough now that, for many applications, there may not be enough saving by consolidating it for that to be a sufficient sole driving factor in the thin-client decision. So other factors (such as security, control, labor cost, and employee moralle) will probably determine whether thin-clent takes hold or withers.
1) Write a program to lex and partially parse the language the compiler is written in, identifying the symbols and substituting a new set of its own creation, and writing the result.
2) Run this over all the source files of the compiler (including the preprocessor and any subroutine libraries - statically linked or loadable - that either uses), producing a new set of sources where "the names are changed to protect the innocent".
3) Build from these sources using the possibly contaminated compiler. Any Thompson Trojans in the compiler will be unable to recognize the modified signatures of the insertion points, and will thus fail to propagate.
4) Use the modified ("dragnet") compiler to build from the UNmodified sources, producing another clean version with the original names. Either this clean compiler, or the "dragnet" substitute, can be installed permanently.
5) If you want to determine whether any trojans were eliminated, you can compare the new clean object module to the original compiler. They should be identical unless compile times or pathnames get included in the object, in which case these should be the only difference. (You probably can't compare the Dragnet object to the original: Even if debugging symbols aren't included, the changed names may make symbol table hashing come out differently, resulting in subtle differences in the ordering of parts of the object module.)
If you're truly paranoid, don't confine yourself to the source path. Do a second program to modify the filenames in the makefiles (using care to properly deal with filenames that also must appear in string constants) and redo all the programs on the build path while making your "dragnet" build system (including make and any shells). Then use your "dragnet" version to rebuild the kernel and ALL the executables. This catches any hypothetical stuff that might be hidden in the linker, the filesystem, etc.
I notice there's no surface for manuals, scribbled notes, or other reference material.
This thing may be nice for web surfing or completely paperless environments. But most people trying to do serious work will need another piece of furnature (or another computer).
Yes, I know it's theoretically possible to work without anything beyond the screen and what's in your head - if your tools (or your head's RAM) are good enough. But IMHO theory and practice have yet to meet.
Slashdot Mirror
The regional registries are charging big bucks for blocks of numbers and managing them as if they were as scarce as IPv4 address space - or as if the world was beating down their door and needed to be throttled. Results: Only the big router builders' research departments (garage shops need not apply) and the universities (grant money and need to keep at the cutting edge) are interested.
ISPs aren't going to buy numbers until they roll out the infrastructure. Why tie up even a few grand now, when you're not going to use the numbers until later? There's enough numbers to give one to every hair on every human's head, so they won't run out if you don't jump early. (And they want to encode routing in the numbers, so it might be better to wait.)
What burns me is that price tag. The home experimenters can't get in on this unless they ante up (or do all their work with bogus numbers - which is problematic when you want to start interconnecting with the other guys). So we get to depend on the Cisco/3Com/Ascends of the world.
Microsoft would be proud.
Hmmm... Maybe we ought to pick a block UNofficially and divy it up for playing with. B-)
Now they may not have a leg to stand on. But then again they may. And they HAVE announced an intention to release the source according to the appropriate open-source license terms with the general release, and to sell a separate distribution with their closed-source intellectual property added.
So the courts might agree with them. And other prospective open-source providers might be turned off if someone "bites the hand that feeds them" by publishing Corel's IP along with the beta.
Some time back I wrote a patch for a public-domain Z80 assembler to let you also use the intel opcodes (with a pseudo-op to switch between them), to simplify some porting of an 8080 ROM monitor/debugger. The Z80 was "trailing edge" technology at the time, so I didn't publish them. Maybe I ought to now. (If I can find 'em. B-) )
"Node" was my second choice - I'd wanted "home", so I could have the email address "@home". B-) I missed getting "home" by a few days - during the several weeks it took the sysadmin of my first UUCP connection to get me the registration form.
I've seen barcodes as I.D. tattoos used by a repressive regime in at least one made-for-TV movie years ago, too.
Not when it's a link from slashdot! B-)
Think about all the sites /. has taken down with a single round from its HREF gun.
Because it's a big risk. Inserting cells producing a nerve growth factor into the skull could cause all sorts of problems with overgrowth of nerve and related tissues - resulting in nasty brain damage or fatality. A particular risk is brain tumors, especially mama/baby tumors where two types of cells, at least one immortalized, manufacture each other's growth factors in a positive feedback loop.
So they'll start with people who are ALREADY having their brains slowly but unstoppably destroyed by another disease process. At worst it will just speed up something that's already happing. At best it might slow, halt, or reverse the disease - perhaps by promoting replacement of the brain tissue as it is destroyed, perhaps by invigorating the existing cells to resist the problem or switching them to a mode where they aren't "yet" susceptable.
Up to that point, if you built a computer you had to write your own custom OS - in assembler. That's not a garage operation. But now along came UNIX:
You were supposed to have a source license. But the source code circulated freely (due to a bunch that had been handed to universities) and Mama Bell didn't bother with you until you were ready to sell it, and then didn't hold any grudges for your "illegal" use of the source when it came time to price your license. The kernel was tiny and easy to port - and mostly in a compiler language yet! So a whole new model of OS construction became prevalant:
Suppose you've got your new box (or a design for it and a prototype coming together), with it's new processor and new peripherals.
First: If it's a new CPU, add a code generator for it to the Portable C Compiler (PCC). Compile once to get a cross-compiler (to use on your development platform), then use that to compile again to get a native compiler (to run on your target, once it's up).
Second: Port (and configure) the kernel. You probably have to modify the memory management code, the task-switcher, and the raw disk and console driver. Write drivers for any new-fangled peripherals (though you can probably modify them from stock stuff, too) - but that can wait 'til you're running native.
Third: Port the ROM bootloader. (It uses the drivers you already ported, above.) Burn it into a PROM. Plug it into the lab box.
Fourth: Compile all the utilities with your cross-compiler and build an initial root disk - using your current UNIX platform to write it.
Fifth: Plug the disk into your new box. Boot up. You're live. Debug and expand on your shiny new lab box.
Sixth: Call up AT&T and negotiate price of a license to distribute this puppy, after you got it to work so there's no longer any risk.
Seventh: Show the vulture capitalists your working shiny new box. Get your working capital with a high valuation on your company (so you still own most of it).
Eighth: Build it and ship it.
This you can do in a garage shop (or as a grad school project). And it happened just as a couple decent microprocessors hit the market, too. So there was a decade or more where dozens of UNIX boxes, on diverse platforms, sprang up like weeds.
Looks to me like Sun wants to use the same model with the SPARC CPU core, to penetrate the ASIC market (which MIPS and ARM currently dominate). They're making the SPARC processor core free to the shoestring fabless-chip-house startups, during that difficult design period when they're still hanging by their shoestring.
First bag is free, dude!
There are a VERY few exceptions - such as for malicious violation of civil rights - but not for mere incompetence.
Back in the old days, the outer case of a dry cell was a cardboard tube wrapped around a zinc cup, and that zinc cup was the battery's sacrificial negative electrode. If you didn't throw out the battery before discharging it put the first hole in the zinc (i.e. while the flashlight still lit up just fine), the corrosive electrolyte paste would leak out and eat your flashlight.
Well Ray-O-Vac had a long-running R&D project to improve on that, and it had no luck. One day a member of the team came home in a blue funk and his wife (while cooking dinner) asked him what was wrong. He described the problem, and she says "Why don't you seal it in a steel can?"
Well, DUH!
So they tried it. And it worked. And Union Carbide (Everready), who had run similar but UNsuccessful long-term project, sued because it was "obvious".
So the judge asked the defense how long it had taken them to figure this out (I don't recall how many years). Then he asked the plaintif, and got a similar response. And he threw out the suit.
BUT...
The REAL issue is not whether it's obvious to a worker in the field, but whether the judge THINKS it is. So the game is to try to get it in front of the right judge. (For a long time patent challenges were always filed in the federal court district that tries its cases in Chicago, because there was this one judge who thought that EVERYTHING was obvious... B-) )
Might not be a good thing, though. It would also give the big guys more ways to make it tough on the little guys.
One thing US jurisprudence really needs is a "loser pays" allocation of court costs, reasonable attorney fees, and perhaps reimbursement for other damages resulting from a lost suit. That would provide a financial disincentive for bogus lawsuits, and might be extended to damages resulting from the attempted enforcement of bogus patents, providing a financial disincentive there, too.
On the other hand, rooting out Y2K bugs from all those evolved systems - all one-ofs, most with the programmers gone away - can be a major disaster.
But if you convert your business process to a specialized configuration of a general-purpose package, you can sidestep the issue. If it's a popular enough GP package, the core will be fixed by the vendor (if it hasn't been already). The Y2K costs for the core will have been distributed over a large number of customers.
As long as you're going to thrash the company's DP for Y2K anyhow, why not re-analyze your processes and go to a supported platform? That way you also end up with fresh code, that your current DP employees understand, which fits your current business model, takes advantage of advances in tools, and does it all with a single thrash?
Isn't it "harm" that Netscape had to stop selling its browser and start giving it away to keep Microsoft from taking over the browser market? Isn't $0/copy the limiting case of a cross-subsidy?
On one hand, the Fed might decide to open up crypto so they could get better stuff. (And pigs might start to fly.)
On the other hand, the Fed might start having its own Linux distribution, or NSA/military/etc. crypto add-ons for NSA/military/etc.-certified configurations of commercial products. This is how I expect them to go.
This second approach has two variants: They might loosen up crypto for the general public, or they might try to keep it locked up.
In either case, when crypto-enhanced stuff is distributed widely among the civilian portion of the government, it's only a matter of time until the object code leaks out, is reverse-engineered, and appears as bare source, as plug-ins, and what-have you. Then it gets analyzed in the open crypto community, and anything useful gets integrated into the general code base.
The remaining variable is how much the government fights this. If they try to stay tight, expect loud screaming about espionage and nasty crackers and the like. They'll slow it down a bit. But the main result of their fighting will be to continue to retard crypto among the US civilian population relative to the rest of the world, making us fall progressively behind on computer secutiry, and leaving US private and private-enterprise systems more open to snooping and attack than they otherwise might be.
Of course that might be what they want: The main problem for an oppressive government is keeping its own population under control.
computer has a TCP stack?
If he's the general in charge of evaluating, obtaining, modifying, and deploying some computer system for the military, or making the selection of an OS for the military, he and/or his subordiantes should be concerned about it. If he's a general using them, he should only have to worry about the likelyhood of his security being compromized, and delegate these matters to the people below him.
A general has too much else to think about to be involved with the details of everything under his command.
And the same holds true for everybody else in large organizations, government or private. The system security is the job of particular people, who should know at least as much as they need to know to do the job right - and some extra to be sure they didn't miss something. But the rest of the people - from the President to the Receptionist - only needs to know enough to be sure they don't compromize security by improper operation, plus enough more to motivate them not to skimp to save some effort - or to interfere in the selection process.
it was used as advertised a combination of the South East Asian climate and powder residue/gunk
caused the failures
That's not the whole story.
When used with the specified ammuntion, the original M16 worked as advertised. But there was an admiral who had a warehouse full of ball powder that was going out of date. It was the sort that was in bags, and you throw several of the bags into the breech of a big naval gun on a battleship. So he decided to save the Navy a few bucks by having the poweder made up into ammo for this new gun the Marines had just started using in the current war, instead of buying this expensive fancy-schmancy clearn-burn ammo that looked like another $200-hammer boondoggle.
Now when you're firing a bullet the size of a large automobile, from a gun reloaded by a conveyor-belt or something similar, you're not too concerned about powder residue fouling the barrel and loading mechanism. But when you're firing something the size of a .22 bullet, with a reloading mechanism powered by a similarly-sized piston in a cylinder filled with the combustion gasses, a little smoke residue quickly clogs the works.
And while a warehouse full of powder for navy guns might only make for few dozen volleys of those guns, it can make up a LOT of ammo for overpowered .22s like the M16.
So the Marines (and others) got a lot of bad ammo. And even with the spray-and-pray style of fighting (where they even used M16s to cut grass) it took a long time to shoot it up. Meanwhile, those M16s were clogging up, and people were dying, and the new-fangled gun got blamed. So they retrofitted it with that knob to get it restarted when it stuck, and passed out some cleaning kits. And people got by. And eventually the bad ammo got used up or discarded and things went back to working.
Any bets on whether they pass it on to their intrusion department?
It's not a problem for Open Source of course. We've got much of the world's programmer stock on our side of the security game. But with Closed Source the NSA could easily put far more crackers onto a project to break the code's security than the vendor can afford to put on cerating and fixing it.
maintains that the Kernel itself is designed quite well, and that the user level stuff is so bad...
I hear that the NT kernel is reasonably good because they hired the architect of the VMS operating system to run the project, and he did it largely as a VMS clone/next generation. Person who told me this also says that most of the major data structures retain the VMS naming.
RNA strands alone can make a complimentary copy of themselves, given the right raw materials and environment. But it's SLOOOOOOOOOW, and it's error-prone. RNA can also have enzymatic activity.
So a plausable scenario for starting life is the random assembly of an RNA strand that occasionally folds up into an RNA enzyme that facilitates RNA-directed RNA synthesis - even slightly. The first time one of these folds up near a complimentary copy of itself that had been assembled by the random method and copies it, you've got your start. There's now a place in the soup where a particular RNA pattern is efficiently copying RNA patterns, in a concentration of RNA strands with its own pattern.
Once this occurs, it's a matter of incremental improvement through error-and-trial. You'll have RNA "parasites" - any other RNA strands with the right characteristics will also be grabbed and copied. Some of these will evolve into symbionts - additional RNA enzymes that complex with the basic copier to form a more efficient copying complex - thus giving themselves an evolutioinary advantage over the random parasites. One might facilitate binding. Another might hang a repeating code on the ends of strands - which are hard to copy correctly. Another might crack an energetic molecule and use the released energy to speed up a slow part of the reaction. Another might help stick the complex together, while yet another might break it appart occasionally so its pieces can be copied by a neighbor. Another might form a barrier, to let in raw materials while blocking parasites and toxic junk. And because these RNA gene/enzymes are all error prone they all evolve, with complexes contatining the improved models outdoing those without them.
Very quickly (in geological time) you have billions of these little machines doing parallel computation on the life/invention algorithm. You get major inventions, each with an incremental improvement: Gene-damage repair systems. Backup copies in the related, but more stable, DNA. Chemo- and Photo-synthesis of the energetic molecules that power the system. Protien enzyme synthesis - both of peripheral devices and of replacement or additional parts of the replication complex (though even now it's largely RNA-based.) Gene expression regulation. Cooperative groups of cells, each of which has an invention to contribute, forming a super-cell, with the original cells becoming organelles and perhaps consolidating their genetic material. An inner barrier to isolate the genetic machine from the surrounding factory. Synchronized replication of genetic material and the containing package(s).
But very early on you get hunters.
As soon as you have a self-replicating system it starts consuming the local raw materials. As soon as you have a divergent copy you have competition for raw materials. As soon as you have a self-replicating system you have concentrations of the raw materials in the form of the finished products. So it isn't too far along this path when one of the little replicants figures out how to take another apart and get something useful from the pieces.
Once that happens, you start a whole new set of evolutionary games: Arms vs Armor. Identification of relatives and selective predation on things not like onself. Mimicry and disguise. The list is long.
And in this battle zone the original, lazy, brownian-motion-powered, one-RNA-gene replicant is just food for these new war machines, with their armored surfaces covered with protien enzymes to grab the pieces and haul them in, and their guts filled with little vats of chemicals to tear them into their useful components and build more war machines, all powered by high-energy reactions running at blazing speed. The original model doesn't stand a chance- it looks like a slightly concentrated bit of nearly-inert food. And even at human time scales it is so slow we might not recognize it as alive. (It might have reproduced more slowly than a century palm.)
Getting one of the late-model war machines to work with only 350 genes is quite a feat.
By comparison, a T3 propagates on a coax cable, not leaky open lines, and it's good for less than half a 100 Mbps LAN, less than a 20th of a gigabit ethernet. Neglecting compression, it's only good for 116 phone calls or 56KB to 64KB data links, or 28 T1 connections.
This thing would have been a drop in the bucket.
Raise your frequency and you get more data but less range (and more leakage) - requiring the addition of repeaters all over the place, and thus eliminating most of the advantage of using the installed base. (And you also need a mod at every transformer to get the higher frequency stuff passed from one side to another of a device designed for low audio frequencies.) If you're going to send a lineman out to add equipment for each cluster of a half-dozen homes, why not just string some fiber while you're at it?
So I installed a copy of SLiRP on my netcom shell account, and used that for network connectivity until a couple months ago - when I finally got an ADSL link. I still use it as a backup for when Pack Bell dies on me.
My mail exchanger has always been separate from my ISP, reached via UUCP polling. (This lets me change ISPs without losing mail connectivity.) The mail server has two entries for it in the Systems file, the first one trying (twice!) to make a UUCP-over-IP connection if the net is up. The second dials up the exchanger via modem if the first fails and the modem is free. In the days when my network connection was also via phone - either to the fly-by-night ISP or the SLiRP hack, it used the same modem - after I tweaked my PPP install to use the same locking scheme. If the net was up, it used it in the background. If it had dropped, it made the call. All automagic. (I have an alias that forces a poll if I want to be sure something goes out right away or check for mail without waiting for the next poll.)
Now when on the road I can call into the same modem from any phone, picking up and dropping off mail (again via UUCP-over-IP-over-PPP) in parallel with tweaking the home network or doing a quick surf. (Who needs POP and fetchmail?)
If I ever decide to save a few bucks and downgrade from "enhanced" to "basic" DSL, SLiRP is one way to let my whole net of machines masquerade as a single host on the one IP number.
So these "obsolete" protocols aren't really so obsolete.
(Subject line says it all.)
The diskless workstation was the result of an observation: Ethernet (10Mbps) is fast enough that mounting a (VERY expensive at the time) disk on a central server and accessing it over a network was about as fast as having a local disk at a machine - and with several machines it was a LOT cheaper, letting you have many more workstations of comparable capacity for the same budget.
Their first machines had a processor, some local RAM, a screen buffer, and a network interface, but the disk controller and disk were optional. Any machine with a disk could serve it to any machine that didn't have one. All machines shared most of the file systems - so you could access your files (and your neighbors, and your shared resources) from any workstation, and there could be one copy of software for all the clients. Diskless machines put their root partition and swap space on a server, too, doing the computation and graphics rendering locally but consolidating all the mass storage centrally. You got the power of a decent machine on your desk, at a fraction of the cost. And you got better disk utilization, on larger (and thus cheaper-per-megabyte) drives.
Thin client is the same idea, carried a step farther: The local network is now fast enough to shove bitmaps around rather than rendering them locally. So you can push the crunch back into the server room, too. Do the computation and the rendering in a suitable processor farm, and put just enough machine on each desk to handshake the network and unpack the graphics.
But crunch is cheap enough now that, for many applications, there may not be enough saving by consolidating it for that to be a sufficient sole driving factor in the thin-client decision. So other factors (such as security, control, labor cost, and employee moralle) will probably determine whether thin-clent takes hold or withers.
1) Write a program to lex and partially parse the language the compiler is written in, identifying the symbols and substituting a new set of its own creation, and writing the result.
2) Run this over all the source files of the compiler (including the preprocessor and any subroutine libraries - statically linked or loadable - that either uses), producing a new set of sources where "the names are changed to protect the innocent".
3) Build from these sources using the possibly contaminated compiler. Any Thompson Trojans in the compiler will be unable to recognize the modified signatures of the insertion points, and will thus fail to propagate.
4) Use the modified ("dragnet") compiler to build from the UNmodified sources, producing another clean version with the original names. Either this clean compiler, or the "dragnet" substitute, can be installed permanently.
5) If you want to determine whether any trojans were eliminated, you can compare the new clean object module to the original compiler. They should be identical unless compile times or pathnames get included in the object, in which case these should be the only difference. (You probably can't compare the Dragnet object to the original: Even if debugging symbols aren't included, the changed names may make symbol table hashing come out differently, resulting in subtle differences in the ordering of parts of the object module.)
If you're truly paranoid, don't confine yourself to the source path. Do a second program to modify the filenames in the makefiles (using care to properly deal with filenames that also must appear in string constants) and redo all the programs on the build path while making your "dragnet" build system (including make and any shells). Then use your "dragnet" version to rebuild the kernel and ALL the executables. This catches any hypothetical stuff that might be hidden in the linker, the filesystem, etc.
This thing may be nice for web surfing or completely paperless environments. But most people trying to do serious work will need another piece of furnature (or another computer).
Yes, I know it's theoretically possible to work without anything beyond the screen and what's in your head - if your tools (or your head's RAM) are good enough. But IMHO theory and practice have yet to meet.