Gosh. I guess Oracle was a toy for the first dozen years of existence before it had transactions.
But I don't care. I like MySQL and Postgresql OK, neither of them works particularly well with the apps I have, so I still use R:Base which has had COMMIT/ROLLBACK since about 1991*, subselects and referential integrity since before that, it's fast and easy to work with, and doesn't have data or index corruption problems.
And I really don't care what people think they know about R:Base.
My only regret is being unable to talk the current owner/developer into doing a Linux port a couple years ago.
*In 1991 Oracle was still in the multi-year process of putting out press releases about how they were going to have transactions Real Soon Now.
We could call it the Slashdot Twitch. That's when your knee starts jerking because you won't bother to look into the facts and context of a story before you leap to conclusions.
If those of you afflicted with the Slashdot Twitch at the moment actually read what John Gilmore has said about this episode all along, perhaps you will be able to alleviate your symptoms before they make you look foolish. Especially those of you who shot your mouths off, called him names and blackholed toad.com without a second thought.
The point John was making all along, for those too lazy to actually read what he wrote, is that braindead ISP policies that are designed to address issues in a technically deficient but corporately convenient way, that get in the way of people who know what they are doing, are irrational and to be resisted.
I've known John for a long time and I have my (friendly) disagreements with him -- "please would you support getting FreeS/WAN going on FreeBSD" was my last one he didn't go for:) -- but really, John has done a terrific amount for the net and for our inherent right as human folks to communicate. And THAT is what the whole tussle with the Verio middle managers is all about.
Next time you spout off, maybe you might think about actually researching the subject first. This whole story is based on a paper that was presented at the October NANOG conference.
You do a disservice to the memory of Abha Ahuja with your uninformed yelping. This had nothing to do with a cheap gimmick to get publicity.
For years now we have been reading comments about What Randal Should Have Done.
It's easy to be critical from a distance. But before you're too smug in your assessment, walk a mile in his shoes, or in today's terms, sit for an hour at Randal's shell prompt. Many of us do every single day.
Randal was doing pretty much what many sysadmins do as an ordinary matter of course: secure and protect the systems they are responsible for. It's the job they're hired for, you know?
I've always felt that this amounted to a personality clash that spun out of control, bruised the ego of an Intel senior PHB, and then completely escaped from reality when it was referred as a criminal matter to the local gendarmerie.
Unless you live in or next to Washington County, Oregon, as I do, it may be hard to understand the pressure that develops when the local cops get a call from the largest employer in your area and the most powerful company in the state.
I remind everyone here that Randal was an Intel contractor with a one-line contract that basically ended up being interpreted in a completely arbitrary way.
Randal would be the first to say he did some things that weren't wise, but there was never any intent of illegality or damage to his client, the mighty Intel Corporation.
Intel has rightly gotten a big old black eye over this entire episode, at least among those who bother to learn the details, and at least as far as I know has not repeated this stupidity.
Randal has managed to keep going, dealing with an onerous legal case, the threat of jail, an extraordinarily out of whack fine, and daunting legal costs.
The Oregon law that all this hooked on is widely regarded as badly written and prone to misuse (I've written some Oregon law in my time, not in this particular area, and it's easy to see how this happens in the legislative process).
The gross sense of disproportion is the lesson I have learned from this sorry episode. It is sobering for any of us who take on sysadmin duties under any circumstances. As security becomes an ever more complex and consequential issue, that is a lesson everyone should take seriously. Just because you are doing the best you can, all of us have our flaws. What protection do you have if someone decides to settle a grudge with you and have the full weight of an ill-defined law and an immensely powerful legal apparatus thrown on you?
Good luck to Randal. He handled this with a lot more diplomacy and good cheer than many of us would probably have mustered.
By the definition given, DHCP is a P2P app, since it is contingent (temporary IP addresses) and edge-oriented. And DHCP is mundane, not revolutionary. And this points to exactly the problem: defining a logical relationship like P2P in terms of physical mapping leads to contradictions.
As for P2P as some kind of permiter around a non-surveilled zone of the net: notice that Ethernet is dependent on MACs. All the transient IP addressing in the world doesn't get around that. And to my knowledge other transports have a similar invariant logical-to-physical mapping. Consider the security issues with that. Consider the security issues if you don't have that . . . : Is it trust then verify, or verify then trust?
-------
I *am* a "mere user" but even though I'm currently running FreeBSD I have great admiration for Debian and affection for the Debian developer community.
I met up with a bunch of the core folks at Usenix last summer and we went off -- with Ian Murdock leading the way -- for a couple rounds of beer at a local bar in San Diego after they closed down the hotel meeting rooms. GPG keys were swapped, tall tales of PHBs were told, and Ian clued us in to a little of Progeny's future plans, for which the distro is just one building block.
I like the Debian attitude because it is refreshingly mature, while not been stuffy. That in turn reflects the experience and willingness to try new stuff and see what works, and in turn that goes back to the influence that Ian himself, Bruce and, yes, RMS, have had on Debian. But of course it wouldn't happen without the contributions of hundreds of developers and testers and documentation writers.
I couldn't be more pleased that Debian has emerged as the flagship of the good old Unix hacker ethic. It made a rather stuffy Usenix meeting come alive for me.
Steven Levy is not only an excellent journalist but he's a very fine book writer. This is a rare combination. I learned a great deal from Crypto, and of course still have the original edition of Hackers, but I still think my favorite is Artificial Life because it made an obscure topic I had little interest in much more relevant.
I strongly recommend reading Whit Diffie and Susan Landau's excellent Privacy on the Line in conjunction with Steven's book. And Simon Singh's book is another good companion, since it has much more of the pre-World War II history of crypto and secret writing.
We are very fortunate that someone like Whit Diffie did the right thing technically for the right reasons ethically. It is making a huge difference.
I'm not at all convinced the.NET stuff has anything going for it other than whatever marketing millions Microsoft can throw at it.
For one thing, nobody can describe what.NET really is. It's a framework! No, it's a protocol! No, it's a platform! No, it's a floor cleaner! No, it's a dessert topping!
Frankly, if something like this can't be described so ordinary mortals can understand what it is, maybe it isn't anything to begin with.
I think Microsoft has finally reached the point where IBM was in the mid-1980s wth SAA. Anyone here remember the late unlamented SAA, the framework/protocol/platform/etc. that was Finally Going To Tie All the Pieces Together? "Just say LU 6.2 and run like hell, baybee."
Sure, there are parts of ".NET" that might actually be useful. But the notion of some kind of universal intermediate level language is JUST PLAIN HOOEY.
If someone else like, you know, IBM or Sun, were trying to do this, I could say, "OK, nothing to see here, time to move along."
But this is Microsoft we're talking about, the same company that didn't put real arrays into Visual Basic until release 6. And Microsoft has a crappy, crappy track record for these framework exercises. Let me illustrate with a little example series:
ODBC
DAO
ODBCDirect
RDO
OLE DB
ADO
RDS
Do I make myself clear? This way lies madness.
CORBA and COM are both bad enough. I reach diametrically opposed conclusions to those of Miguel de Icaza concerning CORBA, component frameworks in general, and the overall thrust of.NET These are universalized "solutions" to problems which cannot be addressed on a universal scale. The component frameworks (CORBA, COM and, it seems,.NET) try to resolve an essentially unresolvable issue, which is that the network world is complex. The inability of any of these frameworks to conclusively address latency, replicability, security and other problems in the realm of distributed network resources is indicated in their rapid and unstable evolution, and eventual diversion to one of two fates: either oblivion (SAA) or some localizable usage that does not correspond to the original dramatic claims made for universality.
Really, the whole approach is just wrong. These are top-down "solutions" being imposed on already complex and messy landscapes, not even on blank tablets. Even a cursory understanding of self-evolving systems shows that this simply won't work.
No doubt,.NET will make a lot of money for Microsoft and a whole generation of programmers, consultants and hypesters. But what value does it offer that less tightly coupled, less rigidly doctrinaire approaches don't?
Hmm. How many incorrect statements can be made in a single/. comment? This one is in the running for the record this week anyway.
1. Randal did not "hack his former employer." Randal was not an Intel employee; he was a sysadmin on contract. Those of you who have been contract sysadmins understand the issues.
2. He can and does speak for himself on this issue, but my understanding is that he was performing fairly ordinary security reviews for his then-current client. Due to what might be described as a personality conflict with another Intel person, his activities were "escalated" (insert wry telecom reference) to the point where PHB CYA mode kicked in. The company over-reacted and the matter was referred to the supine Washington County, Oregon district attorney. A Keystone Kops scenario of Randal's home being invaded by Law Enforcement Personnel, weapons drawn, ensued. Randal tried to persuade them with his notion of the truth, but it didn't matter; the CYA mode is one-way and the company felt impelled to 'accede' to the county pressing charges.
3. A show trial ensued with a judge misinterpreting both the law and the facts. Randal was convicted and received a suspended sentence and a major fine. His case is STILL ON APPEAL.
4. The lesson is here is, never forget the famous cliche "no good deed goes unpunished." Especially for those of you involved in security-related system administration. Especially when you type su
5. Hmm, come to think of it, that means all of us who manage even a single box for just one other person.
6. Randal did not "hack" ora.com. Child, where did you get these notions? Actually, I will say this, when Randal ran crack on Teleport around that time, James Deibele told him to knock it off. Then Intel and Washington County decided to throw the book at him and try to make a big bad example out of him. The way things are going it could have meant a jail sentence. As for the fine and court costs, my recollection is: $300,000. Look at those zeroes. There are a lot of them.
8. Much of the humor in the first Camel is a blend of both Larry Wall and Randal Schwartz. It remains a unique contribution to the literature of computer science.
9. "Probably politics between him and ORA." No. Read my friend Steve Silberman's piece in Wired, and you will get a much clearer view of what is going on in the Perl world. I feel very badly for Randal that after all he's done this is the kind of treatment he gets, including completely lazy, ill-informed hearsay from the likes of this 'ackthpt'.
10. "his first ORA book". No. Go read the cover, or better yet read the book. There are TWO names on the cover.
11. "I wouldn't be surprised if he reads Slashdot." You know, the Search box is your friend.
It would be so nice if everyone would engage brain before steering fingers. But this is asking for the world, I know . . .
Re:Poor article & microkernels arch. are dead
on
JKH on OS X
·
· Score: 2
It's not about how well you write in English, it's whether you are paying attention.
I suppose it will be news to Jordan Hubbard that he doesn't have any interest in the details of the Mach kernel, or that he "failed to explain" things that were not the focus of an article geared toward a general audience. After all, I guess the introductory note that he is one of the "lead developers on the FreeBSD project" really is a trivial detail of no importance.
It's hard to imagine someone reading an article and so completely Not Getting It. Congratulations.
I mean, you can disagree with JKH's views and conclusions, but this is ridiculous.
There are two issues here. One is the public nature of voter registration records. This is essential to democracy; how could you effectively have fair elections and representative government if only the government knew who the registered voters were?
There is an exception. Under Oregon state law, voters who feel that publishing their addresses would constitute a hazard (for example, those who have been subjected to stalking by acquaintances) can request that their addresses be suppressed in the public file.
The second issue is voter registration data security. Changing one's registration should be simple and easy, but it shouldn't make it easy for fraud to occur. We have well-established routines for fraud checking with paper documents. Weak online security defeats that purpose.
There are still some concerns. I saw a file layout for the voter file data that the state of Florida provides for a fee. It included Social Security number! Now anyone who has tried to get credit recently (for example, starting up a cell phone account) knows that there is no way around the increasing use of the SSN for credit verification. But having a public agency spread these around is a really bad idea and is unnecessary, to boot. Most voter registrars provide their own affidavit ("voter ID") number that us database types recognize as a Primary Key (or at least a "production key in a Slowly Changing Monster Dimension":).
So there is no reason to disseminate the SSN even if the state collects it as part of your registration. (See Simson Garfinkel's comments about the dangers of SSN overuse and exposure in his excellent book Database Nation.)
Oregon now has all-vote-by-mail elections. In fact, about 40% of Oregonians have already sent in their ballots for the current election. But we are not moving fast at all toward online voting, for all the good reasons that Bruce Schneier and others have pointed out.
Oregon also has the first and to my knowledge only online interactive voter file system, which my business partner and I designed and implemented (it's a subscription service we provide to progressive organizations). We track ballot returns day by day (not perfectly, given the shortcomings of the "legacy systems" our counties use to manage the voter rolls) to remove voters from the active list so that our cooperating campaigns stop bothering people who have already voted. This reduces the cost of campaigning and provides an incentive for electoral participation.
I'm really sick and tired of the flaming directed at MySQL for no other reason than that it is successful.
The proponents of Postgresql have completely lost any credibility with me. Their unending whining about MySQL's limitations are topped only by how they duck the touchy issue of Postgres performance.
Today's article is supposed to address that. So Great Bridge plants a deliberately biased "benchmark" (oops, mortal sin, I used the B word) which, unsurprisingly, puts the competitors at a disadvantage by artificially forcing down their performance via ODBC drivers so they will match Postgres' slug-slow performance.
And what we have is a PRESS RELEASE about a BENCHMARK. Can it get any lower than that? Shame on Postgres and shame on Great Bridge. When MySQL does comparisons, they publish entire tables showing the features for each database in the test, they show the run results, and they make the source code available.
They don't whine about their competition not being "SQL compatible" (a debatable term in any event). They don't lie about how the competition "isn't relational." They don't sneer about how the competition is "just a front end to the file system." By the way -- many are now arguing that it is better to run Oracle, DB2 and other systems that have a native disk mode through the file system anyway -- see the very informative Slashdot discussion on this a few weeks ago.
No, Monty and the MySQL folks just keep doing their thing, improving an already good product and sticking to a clearly charted development course. They have responded to the market and GPLed their code and are adding other features. When they get to subselects I'll probably be using it.
That's right, I'm not even a MySQL user these days. I still use R:Base, everyone's favorite database to piss on in the early 1990s, just like you losers are pissing on MySQL now. Only problem with R:Base (aside from it not being open source, I'm still trying to get their attention on that) is that it has virtually no marketing. But it is rock-solid, as ANSI92 SQL compatible as anyone, supports all the features of Postgres and then some, and runs like a bat out of hell.
If the Postgres crowd will stop flaming, whining and lying, I will start taking Postgres seriously again.
I gather from the reports that Miguel de Icaza's speech was somewhat reduced in scope from his Usenix presentation.
At Usenix, his talk started from the premise that "the kernel sucks" but only as a springboard to cover extensively the approach, the philosophy really, of moving away from kernel-centric development to a component focus.
Now as a relative old schooler in all this I applaud the notion that every generation needs to overthrow the excesses and cruft of the previous one, so to that extent Miguel's to-the-barricades rhetoric is welcome. Unix, and Linux, have become a sprawling pasted-together mess, which is evident if you compare, say, Aeleen Frisch's first system admin book in 1991 with what there is now.
And some of the principles Microsoft has embraced in software architecture may also be applauded. Although I hasten to add that their implementation of those foundations has broken every conceivable rule of software architecture/engineering, not to mention common sense. Nevertheless, I think Miguel's willingness to learn from good principles wherever they may be found is also welcome.
But where I part ways is with his proposed grand solution space, which basically amounts to: CORBA.
CORBA is yet another sprawling, somewhat incoherent and definitely incomplete attempt to Make the World Behave Like We Say It Should Or We'll Stamp Our Little Feet. I have long felt that the dependence on CORBA, not merely the availability, is a millstone around the neck of both GNOME and KDE.
I've read quite a bit of CORBA and component model advocacy, and it reminds me all too much of IBM-think circa the mid-1980s. "You will use SNA because it's good for you. Here, just implement this spec that comes on four bookshelves of binders."
The brilliance of the UNIX philosophy is scalability built on self-evolving systems, not based on universal frameworks that try to provide order through mapping. As has often been noted, the map is not the territory. And it should not be.
But mapping (metaphorically, if not in its strict technical sense) is what component architectures are all about.
DLL Hell was just the first phase of this. You can argue that DLLs are not "components" by the standard definition, but they are component-like and function in many ways as if they were in such a framework. COM rationalizes and makes DLL World somewhat more orthogonal to the component model, and that is the positive sense that Miguel seems to respond to. I can see some merit to the reuse and iterability inherent in this approach.
But that is entirely a developer-centric approach, and this is where I think Miguel's vision will be sorely tested, and emerge as at best mixed bag: one part fixing some rather sticky issues for GUI development and near-field reusability, one part creating a whole new layer of complexity and frustration for the user, the system planner and the sysadmin.
Components are not static; they evolve, and they evolve both in form and function. In other words, wish as much as you might for a static API for a given component (as Miguel sort of did during his Usenix speech), but it's not gonna happen. Both what the component does and what hooks and appearances it presents to the world are destined -- in fact must -- change over time. That's the lesson we learned as soon as Microsoft put out the first revision to the first DLL.
It is simply impossible to imagine some Component World Authority that has the job of telling every component architect and developer: this is your feature set, this is your quest: go forth (or go C++ or go Java ) and Make It So, and Thus Shall It Always Be! Nuh uh, not gonna happen.
The advantage of reusable libraries as in C compilers is that while some variation in them may be permitted (whether this is a good thing or not is circumstance-dependent), you are basically faced with a binary result: either the code compiles or it doesn't. Once it does, you have a static binary that will continue to work as long as most of the underlying OS stuff remains the same.
In Component World, you are now at the mercy of component dependence every single time you run code. And since the component framework is both (1) more dynamic and (2) more distributed than we are used to with our desktop computers these days, this is going to pose major problems. Some of these have already been noted by the GNOME skeptics who have posted here (including at least one well known GNOME developer).
The problems are inherent in component architecture: compatibility, resilience, security. This is less of an issue when all the components reside in devices connected to one backplane, usually inside one metal box. But with distributed apps and, probably more importantly, mobile apps, this is increasingly going to pose problems.
Remember when you installed some random program in Win 9x and it changed a DLL so that your email didn't work any more? At least you have the ability to reinstall DLLs/programs/the system itself (depending on the severity) to deal with the compatibility problem.
W2K supposedly deals with this by creating its own little mini-World Component Authority backed by an internal database subject to all the usual database reliability and performance issues (plus of course it's closed source). All this does is allow a bigger mess to be made at some point.
But what about this? You're running a nice little cell phone/PIM gadget that is built on GNOME and CORBA, and suddenly you can't get your email any more because some schmucko at a service center upgraded to the latest/spiffiest version of a component your handheld relies on via its mobile link to do its work.
Welcome to Component Hell.
As a non-developer and mere observer of the passing landscape, I would be happy to have someone come along and explain exactly why I am all wet. But for the moment, I am persuaded by Miguel's disdain for the suckiness of the kernel, and completely unpersuaded why components, as instantiated by CORBA and GNOME, are a universal solution rather than a local fix.
You're gonna love Joe Nacchio, who is a fast-talking dealmaker who is even more greedy than Trujillo.
I work right across the street from the US West -- er Qwest -- Small Business Center here in downtown Portland, which services the entire territory (it used to be Pacific Northwest Bell headquarters back in the days of old).
I am a customer and DSL user, and the acquisition by Qwest is of grave concern because US West did an excellent job blocking implementation of the parts of the 1996 Telecom Act that it didn't like. My favorite indication of that was the photo of the empty colo cage in Seattle that Data Communications published at some point in 1998.
The consolidation in telecom is being driven by absolutely ruthless operators like Nacchio who make Bill Gates look like a kid at a lemonade stand as far as how they do business. Nacchio rolled Trujillo, a noted shark in the executive suites who was loathed by the line-level reps, service people and engineers. What direction can Qwest service possibly take but downward as it extends its empire and increasingly escapes the clutches of state and federal regulation?
Sorry, I'm very bitter about this. We will live to regret the day that the Telecom Act passed, and it won't be long.
Same mistake here as always. MySQL is a relational database. "Transactions" does not define what "relational" is -- go read E. F. Codd's papers if you don't know why.
Even though I'm posting toward the end of this, I gotta say it.
George Gilder, as usual, is full of bullshit. There is absolutely nothing wrong with making better use of the existing copper plant, which is what DSL does. Pulling fiber to the home user (and even to many businesses) also does not make sense in any kind of real-world economics I know about, in cases where there is DSL-capable copper (and there are certainly situations where that is not the case).
DSL simply uses the 98% of the available wire capacity that Plain Old Voice never touched. It's clever in how it does so, but the basic principle is very simple.
As the telecom network continues to be built out, I expect to see the gap between the CO and the CPE increasingly filled with fiber, but for the foreseeable future the vast majority especially in home situations will have copper for at least the "last mile."
But George Gilder never lets basic economics get in the way of a thumping good oversimplification.
Slashdot Mirror
It was very good a few years ago and slowly declined. I stopped subscribing when it became in effect SolarisAdmin.
SAIC! This is some kind of cruel joke.
SAIC made the DNS the shambles it is today.
You could look it up.
SAIC, NSI. What a strange history.
Gosh. I guess Oracle was a toy for the first dozen years of existence before it had transactions.
But I don't care. I like MySQL and Postgresql OK, neither of them works particularly well with the apps I have, so I still use R:Base which has had COMMIT/ROLLBACK since about 1991*, subselects and referential integrity since before that, it's fast and easy to work with, and doesn't have data or index corruption problems.
And I really don't care what people think they know about R:Base.
My only regret is being unable to talk the current owner/developer into doing a Linux port a couple years ago.
*In 1991 Oracle was still in the multi-year process of putting out press releases about how they were going to have transactions Real Soon Now.
--------
We could call it the Slashdot Twitch. That's when your knee starts jerking because you won't bother to look into the facts and context of a story before you leap to conclusions.
:) -- but really, John has done a terrific amount for the net and for our inherent right as human folks to communicate. And THAT is what the whole tussle with the Verio middle managers is all about.
If those of you afflicted with the Slashdot Twitch at the moment actually read what John Gilmore has said about this episode all along, perhaps you will be able to alleviate your symptoms before they make you look foolish.
Especially those of you who shot your mouths off, called him names and blackholed toad.com without a second thought.
The point John was making all along, for those too lazy to actually read what he wrote, is that braindead ISP policies that are designed to address issues in a technically deficient but corporately convenient way, that get in the way of people who know what they are doing, are irrational and to be resisted.
I've known John for a long time and I have my (friendly) disagreements with him -- "please would you support getting FreeS/WAN going on FreeBSD" was my last one he didn't go for
--------------
Scientists should be precise and fair in their assessments of real world and experimental data.
Lonborg is sloppy and biased. It's evident throughout his book. It's not even a close call.
The difference between science and this whatever-it-is should be obvious.
--------
Next time you spout off, maybe you might think about actually researching the subject first. This whole story is based on a paper that was presented at the October NANOG conference.
You do a disservice to the memory of Abha Ahuja with your uninformed yelping. This had nothing to do with a cheap gimmick to get publicity.
--------
For years now we have been reading comments about What Randal Should Have Done.
It's easy to be critical from a distance. But before you're too smug in your assessment, walk a mile in his shoes, or in today's terms, sit for an hour at Randal's shell prompt. Many of us do every single day.
Randal was doing pretty much what many sysadmins do as an ordinary matter of course: secure and protect the systems they are responsible for. It's the job they're hired for, you know?
I've always felt that this amounted to a personality clash that spun out of control, bruised the ego of an Intel senior PHB, and then completely escaped from reality when it was referred as a criminal matter to the local gendarmerie.
Unless you live in or next to Washington County, Oregon, as I do, it may be hard to understand the pressure that develops when the local cops get a call from the largest employer in your area and the most powerful company in the state.
I remind everyone here that Randal was an Intel contractor with a one-line contract that basically ended up being interpreted in a completely arbitrary way.
Randal would be the first to say he did some things that weren't wise, but there was never any intent of illegality or damage to his client, the mighty Intel Corporation.
Intel has rightly gotten a big old black eye over this entire episode, at least among those who bother to learn the details, and at least as far as I know has not repeated this stupidity.
Randal has managed to keep going, dealing with an onerous legal case, the threat of jail, an extraordinarily out of whack fine, and daunting legal costs.
The Oregon law that all this hooked on is widely regarded as badly written and prone to misuse (I've written some Oregon law in my time, not in this particular area, and it's easy to see how this happens in the legislative process).
The gross sense of disproportion is the lesson I have learned from this sorry episode. It is sobering for any of us who take on sysadmin duties under any circumstances. As security becomes an ever more complex and consequential issue, that is a lesson everyone should take seriously. Just because you are doing the best you can, all of us have our flaws. What protection do you have if someone decides to settle a grudge with you and have the full weight of an ill-defined law and an immensely powerful legal apparatus thrown on you?
Good luck to Randal. He handled this with a lot more diplomacy and good cheer than many of us would probably have mustered.
--------
Before answering the question, it's important to understand the question.
.NET is ?
So my question about the question is:
Does anyone actually know what
--------
By the definition given, DHCP is a P2P app, since it is contingent (temporary IP addresses) and edge-oriented. And DHCP is mundane, not revolutionary. And this points to exactly the problem: defining a logical relationship like P2P in terms of physical mapping leads to contradictions.
As for P2P as some kind of permiter around a non-surveilled zone of the net: notice that Ethernet is dependent on MACs. All the transient IP addressing in the world doesn't get around that. And to my knowledge other transports have a similar invariant logical-to-physical mapping. Consider the security issues with that. Consider the security issues if you don't have that . . . : Is it trust then verify, or verify then trust?
-------
-------
I *am* a "mere user" but even though I'm currently running FreeBSD I have great admiration for Debian and affection for the Debian developer community.
I met up with a bunch of the core folks at Usenix last summer and we went off -- with Ian Murdock leading the way -- for a couple rounds of beer at a local bar in San Diego after they closed down the hotel meeting rooms. GPG keys were swapped, tall tales of PHBs were told, and Ian clued us in to a little of Progeny's future plans, for which the distro is just one building block.
I like the Debian attitude because it is refreshingly mature, while not been stuffy. That in turn reflects the experience and willingness to try new stuff and see what works, and in turn that goes back to the influence that Ian himself, Bruce and, yes, RMS, have had on Debian. But of course it wouldn't happen without the contributions of hundreds of developers and testers and documentation writers.
I couldn't be more pleased that Debian has emerged as the flagship of the good old Unix hacker ethic. It made a rather stuffy Usenix meeting come alive for me.
-------
Steven Levy is not only an excellent journalist but he's a very fine book writer. This is a rare combination. I learned a great deal from Crypto, and of course still have the original edition of Hackers, but I still think my favorite is Artificial Life because it made an obscure topic I had little interest in much more relevant.
I strongly recommend reading Whit Diffie and Susan Landau's excellent Privacy on the Line in conjunction with Steven's book. And Simon Singh's book is another good companion, since it has much more of the pre-World War II history of crypto and secret writing.
We are very fortunate that someone like Whit Diffie did the right thing technically for the right reasons ethically. It is making a huge difference.
-------
Why are you sure it was Mitnick?
--------
I'm not at all convinced the .NET stuff has anything going for it other than whatever marketing millions Microsoft can throw at it.
.NET really is. It's a framework! No, it's a protocol! No, it's a platform! No, it's a floor cleaner! No, it's a dessert topping!
.NET These are universalized "solutions" to problems which cannot be addressed on a universal scale. The component frameworks (CORBA, COM and, it seems, .NET) try to resolve an essentially unresolvable issue, which is that the network world is complex. The inability of any of these frameworks to conclusively address latency, replicability, security and other problems in the realm of distributed network resources is indicated in their rapid and unstable evolution, and eventual diversion to one of two fates: either oblivion (SAA) or some localizable usage that does not correspond to the original dramatic claims made for universality.
.NET will make a lot of money for Microsoft and a whole generation of programmers, consultants and hypesters. But what value does it offer that less tightly coupled, less rigidly doctrinaire approaches don't?
For one thing, nobody can describe what
Frankly, if something like this can't be described so ordinary mortals can understand what it is, maybe it isn't anything to begin with.
I think Microsoft has finally reached the point where IBM was in the mid-1980s wth SAA. Anyone here remember the late unlamented SAA, the framework/protocol/platform/etc. that was Finally Going To Tie All the Pieces Together? "Just say LU 6.2 and run like hell, baybee."
Sure, there are parts of ".NET" that might actually be useful. But the notion of some kind of universal intermediate level language is JUST PLAIN HOOEY.
If someone else like, you know, IBM or Sun, were trying to do this, I could say, "OK, nothing to see here, time to move along."
But this is Microsoft we're talking about, the same company that didn't put real arrays into Visual Basic until release 6. And Microsoft has a crappy, crappy track record for these framework exercises. Let me illustrate with a little example series:
ODBC
DAO
ODBCDirect
RDO
OLE DB
ADO
RDS
Do I make myself clear? This way lies madness.
CORBA and COM are both bad enough. I reach diametrically opposed conclusions to those of Miguel de Icaza concerning CORBA, component frameworks in general, and the overall thrust of
Really, the whole approach is just wrong. These are top-down "solutions" being imposed on already complex and messy landscapes, not even on blank tablets. Even a cursory understanding of self-evolving systems shows that this simply won't work.
No doubt,
--------
Hmm. How many incorrect statements can be made in a single /. comment? This one is in the running for the record this week anyway.
1. Randal did not "hack his former employer." Randal was not an Intel employee; he was a sysadmin on contract. Those of you who have been contract sysadmins understand the issues.
2. He can and does speak for himself on this issue, but my understanding is that he was performing fairly ordinary security reviews for his then-current client. Due to what might be described as a personality conflict with another Intel person, his activities were "escalated" (insert wry telecom reference) to the point where PHB CYA mode kicked in. The company over-reacted and the matter was referred to the supine Washington County, Oregon district attorney. A Keystone Kops scenario of Randal's home being invaded by Law Enforcement Personnel, weapons drawn, ensued. Randal tried to persuade them with his notion of the truth, but it didn't matter; the CYA mode is one-way and the company felt impelled to 'accede' to the county pressing charges.
3. A show trial ensued with a judge misinterpreting both the law and the facts. Randal was convicted and received a suspended sentence and a major fine. His case is STILL ON APPEAL.
4. The lesson is here is, never forget the famous cliche "no good deed goes unpunished." Especially for those of you involved in security-related system administration. Especially when you type su
5. Hmm, come to think of it, that means all of us who manage even a single box for just one other person.
6. Randal did not "hack" ora.com. Child, where did you get these notions? Actually, I will say this, when Randal ran crack on Teleport around that time, James Deibele told him to knock it off. Then Intel and Washington County decided to throw the book at him and try to make a big bad example out of him. The way things are going it could have meant a jail sentence. As for the fine and court costs, my recollection is: $300,000. Look at those zeroes. There are a lot of them.
8. Much of the humor in the first Camel is a blend of both Larry Wall and Randal Schwartz. It remains a unique contribution to the literature of computer science.
9. "Probably politics between him and ORA." No. Read my friend Steve Silberman's piece in Wired, and you will get a much clearer view of what is going on in the Perl world. I feel very badly for Randal that after all he's done this is the kind of treatment he gets, including completely lazy, ill-informed hearsay from the likes of this 'ackthpt'.
10. "his first ORA book". No. Go read the cover, or better yet read the book. There are TWO names on the cover.
11. "I wouldn't be surprised if he reads Slashdot." You know, the Search box is your friend.
It would be so nice if everyone would engage brain before steering fingers. But this is asking for the world, I know . . .
-------
"Most people."
Nice try, generalizing your personal experience. Guess what, doesn't work.
I'm moving to Ruby AND staying with Perl.
--------
Forget all this vi vs. emacs foolishness. Why not use a REAL editor?
teco for Windows.
Yes, it's still around.
--------
It's not about how well you write in English, it's whether you are paying attention.
I suppose it will be news to Jordan Hubbard that he doesn't have any interest in the details of the Mach kernel, or that he "failed to explain" things that were not the focus of an article geared toward a general audience. After all, I guess the introductory note that he is one of the "lead developers on the FreeBSD project" really is a trivial detail of no importance.
It's hard to imagine someone reading an article and so completely Not Getting It. Congratulations.
I mean, you can disagree with JKH's views and conclusions, but this is ridiculous.
-------
There are two issues here. One is the public nature of voter registration records. This is essential to democracy; how could you effectively have fair elections and representative government if only the government knew who the registered voters were?
:).
There is an exception. Under Oregon state law, voters who feel that publishing their addresses would constitute a hazard (for example, those who have been subjected to stalking by acquaintances) can request that their addresses be suppressed in the public file.
The second issue is voter registration data security. Changing one's registration should be simple and easy, but it shouldn't make it easy for fraud to occur. We have well-established routines for fraud checking with paper documents. Weak online security defeats that purpose.
There are still some concerns. I saw a file layout for the voter file data that the state of Florida provides for a fee. It included Social Security number! Now anyone who has tried to get credit recently (for example, starting up a cell phone account) knows that there is no way around the increasing use of the SSN for credit verification. But having a public agency spread these around is a really bad idea and is unnecessary, to boot. Most voter registrars provide their own affidavit ("voter ID") number that us database types recognize as a Primary Key (or at least a "production key in a Slowly Changing Monster Dimension"
So there is no reason to disseminate the SSN even if the state collects it as part of your registration. (See Simson Garfinkel's comments about the dangers of SSN overuse and exposure in his excellent book Database Nation.)
Oregon now has all-vote-by-mail elections. In fact, about 40% of Oregonians have already sent in their ballots for the current election. But we are not moving fast at all toward online voting, for all the good reasons that Bruce Schneier and others have pointed out.
Oregon also has the first and to my knowledge only online interactive voter file system, which my business partner and I designed and implemented (it's a subscription service we provide to progressive organizations). We track ballot returns day by day (not perfectly, given the shortcomings of the "legacy systems" our counties use to manage the voter rolls) to remove voters from the active list so that our cooperating campaigns stop bothering people who have already voted. This reduces the cost of campaigning and provides an incentive for electoral participation.
--------
I'm really sick and tired of the flaming directed at MySQL for no other reason than that it is successful.
The proponents of Postgresql have completely lost any credibility with me. Their unending whining about MySQL's limitations are topped only by how they duck the touchy issue of Postgres performance.
Today's article is supposed to address that. So Great Bridge plants a deliberately biased "benchmark" (oops, mortal sin, I used the B word) which, unsurprisingly, puts the competitors at a disadvantage by artificially forcing down their performance via ODBC drivers so they will match Postgres' slug-slow performance.
And what we have is a PRESS RELEASE about a BENCHMARK. Can it get any lower than that? Shame on Postgres and shame on Great Bridge. When MySQL does comparisons, they publish entire tables showing the features for each database in the test, they show the run results, and they make the source code available.
They don't whine about their competition not being "SQL compatible" (a debatable term in any event). They don't lie about how the competition "isn't relational." They don't sneer about how the competition is "just a front end to the file system." By the way -- many are now arguing that it is better to run Oracle, DB2 and other systems that have a native disk mode through the file system anyway -- see the very informative Slashdot discussion on this a few weeks ago.
No, Monty and the MySQL folks just keep doing their thing, improving an already good product and sticking to a clearly charted development course. They have responded to the market and GPLed their code and are adding other features. When they get to subselects I'll probably be using it.
That's right, I'm not even a MySQL user these days. I still use R:Base, everyone's favorite database to piss on in the early 1990s, just like you losers are pissing on MySQL now. Only problem with R:Base (aside from it not being open source, I'm still trying to get their attention on that) is that it has virtually no marketing. But it is rock-solid, as ANSI92 SQL compatible as anyone, supports all the features of Postgres and then some, and runs like a bat out of hell.
If the Postgres crowd will stop flaming, whining and lying, I will start taking Postgres seriously again.
-------
IE-only sites are Truly Lame. Of course, I can tell Opera to lie, but why bother.
Next.
--------
I gather from the reports that Miguel de Icaza's speech was somewhat reduced in scope from his Usenix presentation.
At Usenix, his talk started from the premise that "the kernel sucks" but only as a springboard to cover extensively the approach, the philosophy really, of moving away from kernel-centric development to a component focus.
Now as a relative old schooler in all this I applaud the notion that every generation needs to overthrow the excesses and cruft of the previous one, so to that extent Miguel's to-the-barricades rhetoric is welcome. Unix, and Linux, have become a sprawling pasted-together mess, which is evident if you compare, say, Aeleen Frisch's first system admin book in 1991 with what there is now.
And some of the principles Microsoft has embraced in software architecture may also be applauded. Although I hasten to add that their implementation of those foundations has broken every conceivable rule of software architecture/engineering, not to mention common sense. Nevertheless, I think Miguel's willingness to learn from good principles wherever they may be found is also welcome.
But where I part ways is with his proposed grand solution space, which basically amounts to: CORBA.
CORBA is yet another sprawling, somewhat incoherent and definitely incomplete attempt to Make the World Behave Like We Say It Should Or We'll Stamp Our Little Feet. I have long felt that the dependence on CORBA, not merely the availability, is a millstone around the neck of both GNOME and KDE.
I've read quite a bit of CORBA and component model advocacy, and it reminds me all too much of IBM-think circa the mid-1980s. "You will use SNA because it's good for you. Here, just implement this spec that comes on four bookshelves of binders."
The brilliance of the UNIX philosophy is scalability built on self-evolving systems, not based on universal frameworks that try to provide order through mapping. As has often been noted, the map is not the territory. And it should not be.
But mapping (metaphorically, if not in its strict technical sense) is what component architectures are all about.
DLL Hell was just the first phase of this. You can argue that DLLs are not "components" by the standard definition, but they are component-like and function in many ways as if they were in such a framework. COM rationalizes and makes DLL World somewhat more orthogonal to the component model, and that is the positive sense that Miguel seems to respond to. I can see some merit to the reuse and iterability inherent in this approach.
But that is entirely a developer-centric approach, and this is where I think Miguel's vision will be sorely tested, and emerge as at best mixed bag: one part fixing some rather sticky issues for GUI development and near-field reusability, one part creating a whole new layer of complexity and frustration for the user, the system planner and the sysadmin.
Components are not static; they evolve, and they evolve both in form and function. In other words, wish as much as you might for a static API for a given component (as Miguel sort of did during his Usenix speech), but it's not gonna happen. Both what the component does and what hooks and appearances it presents to the world are destined -- in fact must -- change over time. That's the lesson we learned as soon as Microsoft put out the first revision to the first DLL.
It is simply impossible to imagine some Component World Authority that has the job of telling every component architect and developer: this is your feature set, this is your quest: go forth (or go C++ or go Java ) and Make It So, and Thus Shall It Always Be! Nuh uh, not gonna happen.
The advantage of reusable libraries as in C compilers is that while some variation in them may be permitted (whether this is a good thing or not is circumstance-dependent), you are basically faced with a binary result: either the code compiles or it doesn't. Once it does, you have a static binary that will continue to work as long as most of the underlying OS stuff remains the same.
In Component World, you are now at the mercy of component dependence every single time you run code. And since the component framework is both (1) more dynamic and (2) more distributed than we are used to with our desktop computers these days, this is going to pose major problems. Some of these have already been noted by the GNOME skeptics who have posted here (including at least one well known GNOME developer).
The problems are inherent in component architecture: compatibility, resilience, security. This is less of an issue when all the components reside in devices connected to one backplane, usually inside one metal box. But with distributed apps and, probably more importantly, mobile apps, this is increasingly going to pose problems.
Remember when you installed some random program in Win 9x and it changed a DLL so that your email didn't work any more? At least you have the ability to reinstall DLLs/programs/the system itself (depending on the severity) to deal with the compatibility problem.
W2K supposedly deals with this by creating its own little mini-World Component Authority backed by an internal database subject to all the usual database reliability and performance issues (plus of course it's closed source). All this does is allow a bigger mess to be made at some point.
But what about this? You're running a nice little cell phone/PIM gadget that is built on GNOME and CORBA, and suddenly you can't get your email any more because some schmucko at a service center upgraded to the latest/spiffiest version of a component your handheld relies on via its mobile link to do its work.
Welcome to Component Hell.
As a non-developer and mere observer of the passing landscape, I would be happy to have someone come along and explain exactly why I am all wet. But for the moment, I am persuaded by Miguel's disdain for the suckiness of the kernel, and completely unpersuaded why components, as instantiated by CORBA and GNOME, are a universal solution rather than a local fix.
-------
You're gonna love Joe Nacchio, who is a fast-talking dealmaker who is even more greedy than Trujillo.
I work right across the street from the US West -- er Qwest -- Small Business Center here in downtown Portland, which services the entire territory (it used to be Pacific Northwest Bell headquarters back in the days of old).
I am a customer and DSL user, and the acquisition by Qwest is of grave concern because US West did an excellent job blocking implementation of the parts of the 1996 Telecom Act that it didn't like. My favorite indication of that was the photo of the empty colo cage in Seattle that Data Communications published at some point in 1998.
The consolidation in telecom is being driven by absolutely ruthless operators like Nacchio who make Bill Gates look like a kid at a lemonade stand as far as how they do business. Nacchio rolled Trujillo, a noted shark in the executive suites who was loathed by the line-level reps, service people and engineers. What direction can Qwest service possibly take but downward as it extends its empire and increasingly escapes the clutches of state and federal regulation?
Sorry, I'm very bitter about this. We will live to regret the day that the Telecom Act passed, and it won't be long.
-------
Define "advanced."
Go ahead, I dare you.
-------
Same mistake here as always. MySQL is a relational database. "Transactions" does not define what "relational" is -- go read E. F. Codd's papers if you don't know why.
------
Even though I'm posting toward the end of this, I gotta say it.
George Gilder, as usual, is full of bullshit. There is absolutely nothing wrong with making better use of the existing copper plant, which is what DSL does. Pulling fiber to the home user (and even to many businesses) also does not make sense in any kind of real-world economics I know about, in cases where there is DSL-capable copper (and there are certainly situations where that is not the case).
DSL simply uses the 98% of the available wire capacity that Plain Old Voice never touched. It's clever in how it does so, but the basic principle is very simple.
As the telecom network continues to be built out, I expect to see the gap between the CO and the CPE increasingly filled with fiber, but for the foreseeable future the vast majority especially in home situations will have copper for at least the "last mile."
But George Gilder never lets basic economics get in the way of a thumping good oversimplification.
-------