Have you ever noticed when you buy software that there's usually a paragraph of legalese about terms for US Govt use of the software? There are reasons for this:-) It's specifically because the Feds have more lawyers than you do and a huge body of law and contract procedures concerning stuff built for hire, especially the military, which has a long history of buying very specialized stuff that's created just for them (or for other hired killers much like them), and a long history of the customer and contractors trying extremely hard to rip each other off because of the huge amount of future money that can be leveraged by any decisions.
GPL and other open-source licenses actually accomplish much of what the government tries to accomplish with its contracting terms, which is that if you design something for them, they can go get more of them in the future made by somebody else, instead of having contractors saying to them "Heh-heh, those special $500 hammers are now $5000 hammers, since you didn't buy enough the first time, and if you want the plans so somebody else can make them for you for $50, the plans will cost you $10 million because we're the only one who knows OUR trade secret!" Because most Open Source license let anybody use the technology, this is pretty much prevented, but the government is used to an environment where the only way to accomplish that is by owning the software themselves.
Even though they filed their patent ~6 months before you developed your code, you probably weren't exposed to their material, but instead were developing it independently. Obviousness isn't as solid a patent-buster as prior art, because it's much harder to demonstrate, but the technique of Ugly_Looking_URLs has been around a long time as a method for doing lots of different things (and primarily as an alternative to cookies.)
First of all, it's nice for vendors to have a free OS so they reduce licensing costs, since consumer products care excessively about a few bucks in price, and so the development tools can be available cheaply/free to more developers, so more good applications get ported - and it's good applications that sell the product (though the calendar, address book, and notepad functions are the most critical ones for most users, and the vendor will need to build or buy them regardless of OS.) And handhelds are much more useful with some networking support - Unix gives you a range of choices, from TCP/IP down to kermit.
But the real benefit of using a Real Operating System instead of Yet Another Broken Program Loader With No Memory Protection is that providing decent memory protection lets applications trust that they'll be safe from other applications, instead of getting their memory scribbled. This means that you don't have to worry about your calendar getting scribbled when you install Clone Wars, and if Foobie App crashes and dies horribly, you don't need to worry about your machine rebooting - you just garbage-collect the dead app and everything else is fine.
It's not like a Real Operating System requires huge amounts of resources - Unix ran just fine on a PDP-11, and a Palm Pilot looks suspiciously like a Sun-1 with a smaller screen and no disk, or like an early Macintosh. The real issue is whether you want something like a file system, in which case Unix is a fine choice, or whether you want an OS that's built out of persistent objects like some of the Psion or Newton OSs.
Underspecification invites Security Risks
on
ESR On XML-RPC
·
· Score: 4
I'm just starting to buckle down and learn XML, so I may have the occasional detail wrong and major clue missing, but I've got several decades of experience with bad security and inadequate design:-)
The biggest technical security risk in most environments is that Bad Guys can hand programs input that doesn't have the properties that the programs' authors expected, and in networked environments (such as an RPC) there are Bad Guys all over the Solar System who have the means of handing input to your programs (both client and server), and RPC mechanisms have been a popular target for crackers, not that networking in general isn't a target-rich environment. Anybody who provides a new general RPC mechanism and doesn't make the default behavior to be "secure" at least to the extent of safety-checking input is a danger to the community. I don't see any evidence that XML-RPC addresses this problem.
The great thing about XML, besides flexibility and popularity, is that it provides a mechanism for defining valid input, through the use of Document Type Definitions, so parsers can determine whether input is both well-formed and valid. That doesn't mean that everybody writing a program that uses your XML DTD will write it safely, or even if they use a parser that they'll refrain from mismanaging memory, but at least they'll all have a consistent spec for what they need to support, and if they've got an xml parser that they're using, it'll have something to work from.
The XML-RPC Spec doesn't provide a DTD, and provides examples that don't use it. They don't say what resources a conforming call might use, and is pretty sketchy about responses to invalid calls, as well as about what to do with non-existent or invalid responses. Of course, it does help to use an XML parser that itself responds safely to maliciously designed inputs, but that's a job for open-source commonly used code, just as any XML-RPC toolkit built using it is. But with no DTD, it's harder to decide if requests are malformed or invalid, so the author's program needs to do that work itself, which means that 25% of the popular packages won't even bother, because the deadline for the next release is coming, or the overhead of the XML parser makes the dancing pigs GUI skin too slow. And it only takes one widespread dangerous application to carry the next internet worm - you don't want QuakeSter OpenMusic&WeaponsAuction to start DDOSing metallica.com because a buffer overflow in the PayLars feature lets bad guys in (and the distributed database that replaces Napster makes it easy to find people running that client.)
Please, there are so many loose ends on this stuff - give it a full-scale spec, and build enough documentation and API tools that encourage safe use and strongly resist unsafe use. (Of course, that's harder than it sounds - the obvious way to protect against buffer overflows in an environment where all the input is character strings is for the API to (safely, with checking) malloc (or language-appropriately-create-objects) any input objects, so the malicious client can probably find some good resource starvation attack, but that's at least a Denial Of Service rather than an attack that lets the bad guy hand the server some code to run.
I agree that XML does have some similarities to Unix tab-delimited text files, but I think a better analog is SQL databases - the database is a bunch of tuples, and the database schema is also a bunch of tuples.
A long long time ago, in a galaxy far, far away, I think University of Maryland in ~1985, there was a project for a many-processor machine made with Z-80s, ZMOB, "the Computer of the Future, using the Processor of the Past". You can find several interesting stories on your favorite web search engine.
Also, the Transputer was an early machine designed for clustering massively parallel systems. Each Transputer chip had four interfaces, which you could use to connect to neighboring machines in a big mesh, or build more hypercubish things with.
Centralized ASN.1 vs. Decentralized XML Standards
on
Inside XML
·
· Score: 2
Ignoring the minor problem that ASN.1's binary representations are the ugliest thing since Intercal or maybe PGP and that people who try too hard to steal bits should be locked up in padded rooms, and that in spite of its ugliness it's still offers incompleteness and ambiguity, the important difference between the two standards is that ASN.1 is a top-down centrally-controlled standard where anybody who wants to define an object type has to either negotiate with a committee to get namespace or buy a hunk of private vendor namespace, while XML is decentralized and anybody can define any object type they like that doesn't start with [Xx][Mm][Ll] and propagate the definitions. The good part about centralization is that it's unambiguous, doesn't lead to conflicts, and reduces portability problems, but it's slow, cumbersome, and often not worth the bother (though the slowness and cumbersomeness does encourage you to get the design right before going through the pain of registration.) Decentralized groups who want to do reusable interoperable XML DTDs still have to negotiate namespace with each other, but you can resolve much of that with naming conventions like FooProjectWidget1 instead of just calling your object Widget1, so you only need to discuss with other FooProject makers what kinds of widgets you need.
While there are problems and impracticalities with this plan, one of the nice features is that it's not using Mutant Pond Scum that grow at room temperature which could Escape And Take Over The Planet. It's using bacteria that thrive at high temperatures - as long as they're in a nice warm smokestack scrubber, they might try to take over, but outside where it's 100 degrees cooler they'd be much less active, either dying or at least growing much more slowly because they're not operating in the range they're bred for.
Also, remember how we reduce water pollution by treating sewage and other point sources - it goes into variants on ponds or vats full of bacteria that eat up the nutrients and outgrow the bad bacteria. This isn't much different. Then there's all the stuff that gets eaten by bugs, big bugs, little bugs, smaller bugs that eat them, fungi, molds, and the rest of the organic gucky stuff that makes up the food chain and carbon cycles.
Surely somebody's thought of that already...... There is a certain similarity to the proposals to use Hydrogen as a miracle energy source (It comes from Water! And only produces Water as its waste product!), mistaking it for an energy storage and transport mechanism like electricity or steam.
Open Source provides a method for consultants who develop software to leverage the experience they gain from working for one client into the projects they do for the next clients, just as most other consultants do.
There was a recent Free Telephony Summit held by ostel.com, who do Open Source Telephony work, with participants including openh323.org, the Bayonne.cx project, Pre-Viking, GNUComm, and others. Several of the participants were individuals or small companies that developed open source telephony products funded by major corporations (who were either hiring work out, or had bought the small companies.) This turns out to be a useful variant on the traditional consultant business model - instead of the code you develop for customers becoming their intellectual property as work-for-hire, you still own it and can reuse it for your future customers, because it's Open Source (whether religously correct GPL, BSD-like, Artistic License, Free Beer, or whatever). It's practical for the telephony business, because most of the work involves building complex but relatively standardizable interfaces and then heavily customizing applications on top of them, so the client needs to either pay the consultant to build the Ugly Telephony Standard Toolkit or buy an overpriced commercial version which will still need extensive customization, and open-source developers are good at building toolkits and applications that are easy to customize and at least as well documented as commercial code, plus they can use other open source tools to build them , which may be difficult for Software-Hoarders to do. Additionally, some of the clients are manufacturers of telecom hardware products, such as interface boards, so funding development of open-source tools that support _their_ hardware is a good way to leverage hardware sales - the gamble is that they'll get more money providing free software and selling more hardware than if they sell overpriced development software (especially because any commercial product developer will buy a bunch of boards for their development work, plus you can sell to smaller developers.) It's a good deal for everybody.
A decade and a half ago, when I was interacting with my employer's PBX developers, I would periodically go into a rant about the need for open, standardized, well-documented interfaces to the hardware and software components of their systems. It's not so much that our _customers_ need to develop applications to hack their PBXs (though that's valuable even if a pointy-haired product manager can't see a well-defined revenue stream), but so our own _developers_ could develop products quickly and easily instead of spending three years of formal development cycles to be allowed to get all the pieces they need into the schedule so they can do their six months of work for a feature that might only be a medium-sized win instead of a big win. That's one of the real advantages the IP PBX world has, is that it can chuck out 2/3 of the baggage, though some of it's still around:-)
The issue isn't whether some parts of the software are performing server functions and some are performing client functions - it's that everybody's a server, and there aren't any centralized resources - it's all decentralized. One big difference between a Gnutella-like P2P and your hypothetical Mozpache is that everything your client-side downloads in Gnutella or Napster is advertised for uploading by your server-side, and the object naming convention is something that supports this. By contrast, Mozpache could symlink the Mozilla cache directory and the apache exportable-files directories together, with a bit of work, but Apache doesn't have a useful way to extract information from fat.db, and the cache directory file naming convention isn't very exportable (random-looking names, but better than taking all the files and naming them "index.html".)
If the Census Bureau didn't want correlation to happen, they'd ask far fewer questions, like "how many people live here" instead of "Are you Guatemalan or Honduran or Salvadoran? N years of school? How many bedrooms and bathrooms in the house? How many kids, and what ages?" - The information about kids alone can easily be correlated with school records, and the housing information with real estate tax and building inspection records. And it's even easier for government officials to do that than for businesses. Census tracts are small enough that the number of couples where the husband is Guatemalan and the wife Salvadoran and the kids are boy 12 and girl 10 are likely to be just 1.
Correlating information used to be hard, back when computers were big and expensive - businesses could still do it, but it had to be financially worthwhile to dedicate time from that 10-MIPS multi-megabuck mainframe which had two megs of memory, 250MB DASD, and a tape drive. That machine now fits in your pocket, and your desktop machine can do amazing queries with free data from the internet and cheap mapping programs - any data that's been collected can pretty much be correlated with anything else, and the only way to prevent that is not to collect it in the first place.
Remember that the laws protecting privacy of census data aren't graven in stone - they apply only until Congress feels like changing them because they've got some political goal or other. And the US military got access to census data in the 40s to use it for arresting Japanese-Americans because of their race - in spite of the 2000 Census bragging about how nobody's violated their privacy in 50 years, which is since 1950, after the war was over....
The cable companies have a technology problem - their transmission methods provide lots more bandwidth downstream than upstream, so they need to do something to prevent the upstream from getting swamped by people running big servers, Napster, or other heavy transmitters from home. Newer equipment lets them limit to 128 kbps upstream; the older stuff was something like 768kbps, so they managed upstream by annoyingly heavy-handed "Don't do anything Server-Like" usage policies and providing customers with small home page capabilities off their servers. What they desparately need to get more business is for people to develop the killer apps for home always-on users, and a content/protocol-based policy is much more likely to prevent that than a bandwidth-based policy.
By contrast, modems are symmetric, and the upstream network infrastructure beyond the dial POPs uses symmetric capabilities, so modem ISPs don't have that problem.
Disclaimer: If this were corporate policy, I'd be wearing a suit and tie instead of a t-shirt.
They're transmitting bits. You're interpreting them. Get used to it. If you don't like the bits they're sending, because they're too confusing for your bootleg-hacked not-smart-enough-card,
buy the real thing (ok, smuggle it from your US Mailboxes Etc. box:-) or find some better reverse engineers.
Nanotech with Artificial Intelligence is one thing, but Nanotech without it (or with Artificial Stupidity) has its own problems. The "Gray Goo" problem says that "If we create a successful assembler, which is designed to take Raw Stuff and make it into more assemblers, which are designed to take More Raw Stuff and make it into even more assemblers, how do we stop it from eating everything". Then there's the "Computer Virus" problem, which applies to nanocomputers as well as to DNA computing - bad enough to have viruses in Microsoft Word and Mail, much worse in Nanosoft StuffMaker.
Buggy Software - Nanothings are small computers that do what they're programmed to do. Surely by 20-50 years from now when we've got the hardware technology well-developed, we'll have figured out how to write bug-free software - after all, it's just a Simple Matter of Programming, and the mere fact that the machine is so small that you don't program it directly, you just use other software to transmit object messages to negotiate with it shouldn't create any problems. (Bwah-hah-hah!) Yeah, right.
Then there's the privacy issues - what are the implications of Smart Dust computers that are networked together? Vernor Vinge's book A Deepness In The Sky discusses the issues of locators in a fictional environment.
One of the main problems with browsers is that the big players want to offer product differentiation, so people will design web pages that are "Best Viewed With BloatBrowser" and so they can leverage their free browser to get people to pay money to buy their non-free BloatAuthor HTML-plus-bloat-objects authoring tool and BloatServer web server and KitchenSinkWare email/calendar/dogwalking product.
A related problem is that the Sun+Netscape Java Browser Conspiracy threatened to create a Runs-Almost-Anywhere programming environment that would make the underlying operating system mostly irrelevant, so software buyers and software users wouldn't have to care if they were using MacOS, Linux, FooBSD, Solaris, or those products from Redmond, which forced Microsoft to invade the browser market to keep from getting killed.
It's one of the best features of ksh vs. /bin/sh
on
David Korn Tells All
·
· Score: 2
I used Korn Shell extensively for programming back in the 80s and early 90s, and that was one of the nicest features - it made it possible to implement things clearly and cleanly that were otherwise very annoying. Parsing various argument lists is a common task, and this is good for it. Most of that was ksh88, but some was earlier ksh versions.
It's been fun the last few years watching the Republicans be the party advocating civil liberties, and the Democrats advocating National Security and giving the FBI whatever it wants. Now that there's a Republican administration, they've dumped figurehead Janet Reno but kept Louis Freeh, the Wiretapper Behind the Curtain, and the parties are moving back to their more traditional alignments.
Girls have this game called "house", that's more or less an RPG. Then there's jump rope, which is mostly cooperative, though sometimes competitive. Then there are building toys like Tinkertoys or Erector Sets (Mechano for UK folks), or for that matter blocks, which lead to cooperative play.
Kids are also very good at inventing zero-sum games, like "You're on MY side of the room".
Sounds cool - for the vast majority of us who do very little high-speed floating point, and would much rather have DSP features like a fast MAC (:-), this would be a really good machine. What kind of hardware did you use - the Intel 80310 evaluation board? How much hardware did you have to add around it? Looks like there are a few PCI slots, ether and RAM, so it shouldn't be too hard to add a video an d a disk controller of some sort.
Agreed - you don't need multiple machines if you've got a multi-level secure operating system. (And you don't need multiple machines very often if you've got removable disk drives, as someone else said.) But maintaining MLSs hasn't been mainstream commercial business for a while, certification is way too expensive, networking is too important, and everybody wants to use Windows anyway (which means getting a POSIX compliance waiver, if they still enforce that.)
I spent way too much time in the late 80s making things fit on System V/MLS, the AT&T System V Unix version that was certified as a B1 Orange Book System. The Red Book, which covers secure networking, was still pretty edgy research at the time, because authentication for machines you don
't directly control is a hard problem - doing it right requires crypto, and the NSA didn't want to let it out of the box at the time or let the military use civilian crypto, though there were a few IPSEC-predecessor networks that were certifiable.
Flynn's article suggests that educational technology ought to provide censorship over content because, gasp!, Bad People From Montana might also use them to teach politically incorrect materials. Some of those marginalized groups are certainly better than what passes for education these days, with the schools teaching kids that the War On Drugs is good, and the Wars On Commies were in America's National Interest [there can be only one!], just like the support for military dictators around the world is good. We certainly need to have central control of Our Nation's Thought Patterns, to prevent Un-American Activities, just like we need to stop those Commie Plots against our Precious Bodily Fluids, such as the movements to fluoridate water, decaffienate coffee and make non-smokable hemp. And we definitely need technology to stamp out sex on the internet (except when it involves President Clinton, who's one of those Evil Democrats.)
I'm not a moderator this week, but it'd be nice if somebody moderates Flynn's article appropriately.
In theory, it's relatively easy - the DNS registration authority who sells you "foo.com" either generates the public and private keys for foo.com and gives them to the person who paid the money to register the name, or lets the person who registered the name send in the public keys along with the payment. Unlike the more general certificate authority problem, where a CA wants some evidence that the person claiming to be "Bill Clinton" so they can certify that "Bill Clinton" owns the key "0x1234566735", and needs to charge some amount of money for verification and for any liabilities that accompany that certification,
the DNS registrar inherently knows that the person that they sold foo.com to is the person they sold foo.com to. That doesn't mean they're certifying that it's really "The Foo Corporation, 1600 Pennsylvania Ave, Washington DC, USA" (an issue that leads to trademark resolution court cases when "Joe Foo Widgets" says that foo.com is their trademark) - it just certifies that "the person who possesses this key can change the IP addresses that.com uses for the foo.com domain and that foo.com uses for subdomains under it."
In practice, that could work fine for new domain names, as long as the registrars want to start supporting SecureDNS for their domains, but there's more trouble in setting the keys for existing domain names. Some domain names use PGP keys to control changes to their DNS data, and those PGP keys could be used to certify any submitted keys. Some domain names use the previous traditional method for controlling DNS information "accept any syntactically correct request to change the IP address and user data, even if that allows anybody in the world to hijack the domain." You could either retain the same mechanism (:-), or use that mechanism to bootstrap setting an initial SecureDNS key, and using that key to certify future change requests, or pick some hybrid mechanism like "generate the keys and email them to the registered contact address, if it exists".
We'll probably see Secure DNS from smaller, more flexible TLDs like.to and the Scandinavian country-code domains before ICANN gets around to getting.com on board.
Slashdot Mirror
GPL and other open-source licenses actually accomplish much of what the government tries to accomplish with its contracting terms, which is that if you design something for them, they can go get more of them in the future made by somebody else, instead of having contractors saying to them "Heh-heh, those special $500 hammers are now $5000 hammers, since you didn't buy enough the first time, and if you want the plans so somebody else can make them for you for $50, the plans will cost you $10 million because we're the only one who knows OUR trade secret!" Because most Open Source license let anybody use the technology, this is pretty much prevented, but the government is used to an environment where the only way to accomplish that is by owning the software themselves.
Even though they filed their patent ~6 months before you developed your code, you probably weren't exposed to their material, but instead were developing it independently. Obviousness isn't as solid a patent-buster as prior art, because it's much harder to demonstrate, but the technique of Ugly_Looking_URLs has been around a long time as a method for doing lots of different things (and primarily as an alternative to cookies.)
But the real benefit of using a Real Operating System instead of Yet Another Broken Program Loader With No Memory Protection is that providing decent memory protection lets applications trust that they'll be safe from other applications, instead of getting their memory scribbled. This means that you don't have to worry about your calendar getting scribbled when you install Clone Wars, and if Foobie App crashes and dies horribly, you don't need to worry about your machine rebooting - you just garbage-collect the dead app and everything else is fine.
It's not like a Real Operating System requires huge amounts of resources - Unix ran just fine on a PDP-11, and a Palm Pilot looks suspiciously like a Sun-1 with a smaller screen and no disk, or like an early Macintosh. The real issue is whether you want something like a file system, in which case Unix is a fine choice, or whether you want an OS that's built out of persistent objects like some of the Psion or Newton OSs.
The biggest technical security risk in most environments is that Bad Guys can hand programs input that doesn't have the properties that the programs' authors expected, and in networked environments (such as an RPC) there are Bad Guys all over the Solar System who have the means of handing input to your programs (both client and server), and RPC mechanisms have been a popular target for crackers, not that networking in general isn't a target-rich environment. Anybody who provides a new general RPC mechanism and doesn't make the default behavior to be "secure" at least to the extent of safety-checking input is a danger to the community. I don't see any evidence that XML-RPC addresses this problem.
The great thing about XML, besides flexibility and popularity, is that it provides a mechanism for defining valid input, through the use of Document Type Definitions, so parsers can determine whether input is both well-formed and valid. That doesn't mean that everybody writing a program that uses your XML DTD will write it safely, or even if they use a parser that they'll refrain from mismanaging memory, but at least they'll all have a consistent spec for what they need to support, and if they've got an xml parser that they're using, it'll have something to work from.
The XML-RPC Spec doesn't provide a DTD, and provides examples that don't use it. They don't say what resources a conforming call might use, and is pretty sketchy about responses to invalid calls, as well as about what to do with non-existent or invalid responses. Of course, it does help to use an XML parser that itself responds safely to maliciously designed inputs, but that's a job for open-source commonly used code, just as any XML-RPC toolkit built using it is. But with no DTD, it's harder to decide if requests are malformed or invalid, so the author's program needs to do that work itself, which means that 25% of the popular packages won't even bother, because the deadline for the next release is coming, or the overhead of the XML parser makes the dancing pigs GUI skin too slow. And it only takes one widespread dangerous application to carry the next internet worm - you don't want QuakeSter OpenMusic&WeaponsAuction to start DDOSing metallica.com because a buffer overflow in the PayLars feature lets bad guys in (and the distributed database that replaces Napster makes it easy to find people running that client.)
Please, there are so many loose ends on this stuff - give it a full-scale spec, and build enough documentation and API tools that encourage safe use and strongly resist unsafe use. (Of course, that's harder than it sounds - the obvious way to protect against buffer overflows in an environment where all the input is character strings is for the API to (safely, with checking) malloc (or language-appropriately-create-objects) any input objects, so the malicious client can probably find some good resource starvation attack, but that's at least a Denial Of Service rather than an attack that lets the bad guy hand the server some code to run.
I agree that XML does have some similarities to Unix tab-delimited text files, but I think a better analog is SQL databases - the database is a bunch of tuples, and the database schema is also a bunch of tuples.
Also, the Transputer was an early machine designed for clustering massively parallel systems. Each Transputer chip had four interfaces, which you could use to connect to neighboring machines in a big mesh, or build more hypercubish things with.
Ignoring the minor problem that ASN.1's binary representations are the ugliest thing since Intercal or maybe PGP and that people who try too hard to steal bits should be locked up in padded rooms, and that in spite of its ugliness it's still offers incompleteness and ambiguity, the important difference between the two standards is that ASN.1 is a top-down centrally-controlled standard where anybody who wants to define an object type has to either negotiate with a committee to get namespace or buy a hunk of private vendor namespace, while XML is decentralized and anybody can define any object type they like that doesn't start with [Xx][Mm][Ll] and propagate the definitions. The good part about centralization is that it's unambiguous, doesn't lead to conflicts, and reduces portability problems, but it's slow, cumbersome, and often not worth the bother (though the slowness and cumbersomeness does encourage you to get the design right before going through the pain of registration.) Decentralized groups who want to do reusable interoperable XML DTDs still have to negotiate namespace with each other, but you can resolve much of that with naming conventions like FooProjectWidget1 instead of just calling your object Widget1, so you only need to discuss with other FooProject makers what kinds of widgets you need.
Also, remember how we reduce water pollution by treating sewage and other point sources - it goes into variants on ponds or vats full of bacteria that eat up the nutrients and outgrow the bad bacteria. This isn't much different. Then there's all the stuff that gets eaten by bugs, big bugs, little bugs, smaller bugs that eat them, fungi, molds, and the rest of the organic gucky stuff that makes up the food chain and carbon cycles.
Surely somebody's thought of that already...... There is a certain similarity to the proposals to use Hydrogen as a miracle energy source (It comes from Water! And only produces Water as its waste product!), mistaking it for an energy storage and transport mechanism like electricity or steam.
There was a recent Free Telephony Summit held by ostel.com, who do Open Source Telephony work, with participants including openh323.org, the Bayonne.cx project, Pre-Viking, GNUComm, and others. Several of the participants were individuals or small companies that developed open source telephony products funded by major corporations (who were either hiring work out, or had bought the small companies.) This turns out to be a useful variant on the traditional consultant business model - instead of the code you develop for customers becoming their intellectual property as work-for-hire, you still own it and can reuse it for your future customers, because it's Open Source (whether religously correct GPL, BSD-like, Artistic License, Free Beer, or whatever). It's practical for the telephony business, because most of the work involves building complex but relatively standardizable interfaces and then heavily customizing applications on top of them, so the client needs to either pay the consultant to build the Ugly Telephony Standard Toolkit or buy an overpriced commercial version which will still need extensive customization, and open-source developers are good at building toolkits and applications that are easy to customize and at least as well documented as commercial code, plus they can use other open source tools to build them , which may be difficult for Software-Hoarders to do. Additionally, some of the clients are manufacturers of telecom hardware products, such as interface boards, so funding development of open-source tools that support _their_ hardware is a good way to leverage hardware sales - the gamble is that they'll get more money providing free software and selling more hardware than if they sell overpriced development software (especially because any commercial product developer will buy a bunch of boards for their development work, plus you can sell to smaller developers.) It's a good deal for everybody.
A decade and a half ago, when I was interacting with my employer's PBX developers, I would periodically go into a rant about the need for open, standardized, well-documented interfaces to the hardware and software components of their systems. It's not so much that our _customers_ need to develop applications to hack their PBXs (though that's valuable even if a pointy-haired product manager can't see a well-defined revenue stream), but so our own _developers_ could develop products quickly and easily instead of spending three years of formal development cycles to be allowed to get all the pieces they need into the schedule so they can do their six months of work for a feature that might only be a medium-sized win instead of a big win. That's one of the real advantages the IP PBX world has, is that it can chuck out 2/3 of the baggage, though some of it's still around :-)
The issue isn't whether some parts of the software are performing server functions and some are performing client functions - it's that everybody's a server, and there aren't any centralized resources - it's all decentralized. One big difference between a Gnutella-like P2P and your hypothetical Mozpache is that everything your client-side downloads in Gnutella or Napster is advertised for uploading by your server-side, and the object naming convention is something that supports this. By contrast, Mozpache could symlink the Mozilla cache directory and the apache exportable-files directories together, with a bit of work, but Apache doesn't have a useful way to extract information from fat.db, and the cache directory file naming convention isn't very exportable (random-looking names, but better than taking all the files and naming them "index.html".)
Correlating information used to be hard, back when computers were big and expensive - businesses could still do it, but it had to be financially worthwhile to dedicate time from that 10-MIPS multi-megabuck mainframe which had two megs of memory, 250MB DASD, and a tape drive. That machine now fits in your pocket, and your desktop machine can do amazing queries with free data from the internet and cheap mapping programs - any data that's been collected can pretty much be correlated with anything else, and the only way to prevent that is not to collect it in the first place.
Remember that the laws protecting privacy of census data aren't graven in stone - they apply only until Congress feels like changing them because they've got some political goal or other. And the US military got access to census data in the 40s to use it for arresting Japanese-Americans because of their race - in spite of the 2000 Census bragging about how nobody's violated their privacy in 50 years, which is since 1950, after the war was over....
From the Dead song, referring to Kesey's Magic Bus trip, which Neal Cassidy was driving, generally wired on meth or equivalents.
By contrast, modems are symmetric, and the upstream network infrastructure beyond the dial POPs uses symmetric capabilities, so modem ISPs don't have that problem.
Disclaimer: If this were corporate policy, I'd be wearing a suit and tie instead of a t-shirt.
They're transmitting bits. You're interpreting them. Get used to it. If you don't like the bits they're sending, because they're too confusing for your bootleg-hacked not-smart-enough-card, :-) or find some better reverse engineers.
buy the real thing (ok, smuggle it from your US Mailboxes Etc. box
Buggy Software - Nanothings are small computers that do what they're programmed to do. Surely by 20-50 years from now when we've got the hardware technology well-developed, we'll have figured out how to write bug-free software - after all, it's just a Simple Matter of Programming, and the mere fact that the machine is so small that you don't program it directly, you just use other software to transmit object messages to negotiate with it shouldn't create any problems. (Bwah-hah-hah!) Yeah, right.
Then there's the privacy issues - what are the implications of Smart Dust computers that are networked together? Vernor Vinge's book A Deepness In The Sky discusses the issues of locators in a fictional environment.
A related problem is that the Sun+Netscape Java Browser Conspiracy threatened to create a Runs-Almost-Anywhere programming environment that would make the underlying operating system mostly irrelevant, so software buyers and software users wouldn't have to care if they were using MacOS, Linux, FooBSD, Solaris, or those products from Redmond, which forced Microsoft to invade the browser market to keep from getting killed.
Support The AnyBrowser Campaign at www.anybrowser.org
I used Korn Shell extensively for programming back in the 80s and early 90s, and that was one of the nicest features - it made it possible to implement things clearly and cleanly that were otherwise very annoying. Parsing various argument lists is a common task, and this is good for it. Most of that was ksh88, but some was earlier ksh versions.
It's been fun the last few years watching the Republicans be the party advocating civil liberties, and the Democrats advocating National Security and giving the FBI whatever it wants. Now that there's a Republican administration, they've dumped figurehead Janet Reno but kept Louis Freeh, the Wiretapper Behind the Curtain, and the parties are moving back to their more traditional alignments.
Kids are also very good at inventing zero-sum games, like "You're on MY side of the room".
Sounds cool - for the vast majority of us who do very little high-speed floating point, and would much rather have DSP features like a fast MAC (:-), this would be a really good machine. What kind of hardware did you use - the Intel 80310 evaluation board? How much hardware did you have to add around it? Looks like there are a few PCI slots, ether and RAM, so it shouldn't be too hard to add a video an d a disk controller of some sort.
http://www.ti.com/calc/docs/faq/83faq067.htm
without the extra %0D at the end...
I spent way too much time in the late 80s making things fit on System V/MLS, the AT&T System V Unix version that was certified as a B1 Orange Book System. The Red Book, which covers secure networking, was still pretty edgy research at the time, because authentication for machines you don
't directly control is a hard problem - doing it right requires crypto, and the NSA didn't want to let it out of the box at the time or let the military use civilian crypto, though there were a few IPSEC-predecessor networks that were certifiable.
I'm not a moderator this week, but it'd be nice if somebody moderates Flynn's article appropriately.
the DNS registrar inherently knows that the person that they sold foo.com to is the person they sold foo.com to. That doesn't mean they're certifying that it's really "The Foo Corporation, 1600 Pennsylvania Ave, Washington DC, USA" (an issue that leads to trademark resolution court cases when "Joe Foo Widgets" says that foo.com is their trademark) - it just certifies that "the person who possesses this key can change the IP addresses that
In practice, that could work fine for new domain names, as long as the registrars want to start supporting SecureDNS for their domains, but there's more trouble in setting the keys for existing domain names. Some domain names use PGP keys to control changes to their DNS data, and those PGP keys could be used to certify any submitted keys. Some domain names use the previous traditional method for controlling DNS information "accept any syntactically correct request to change the IP address and user data, even if that allows anybody in the world to hijack the domain." You could either retain the same mechanism (:-), or use that mechanism to bootstrap setting an initial SecureDNS key, and using that key to certify future change requests, or pick some hybrid mechanism like "generate the keys and email them to the registered contact address, if it exists".
We'll probably see Secure DNS from smaller, more flexible TLDs like