Almost everybody has a computer with an USB port. Heck, almost everybody had a computer with a floppy drive and a cdrom.
That's true, and it isn't a bad idea if followed through. A floppy drive may not be such a great idea -- read/write access to tokens probably wouldn't be a good thing -- but if they could be mass-produced than I don't see any reason why you couldn't put some kind of ID tokens on a CD-ROM (maybe one of those business card ones, so you could carry it around) or have some kind of USB dongles for the same purpose
The point though was that, while as you say the interfaces for such access devices are currently available, there's still almost no one putting these into practice on anything like a wide scale deployment. Cards with magnetic stripes are ubiquitous, but almost no one has a reader for them at home. Access token CD-ROMS or USB dongles could work, but I've never heard of anyone doing these things. I've seen recent Sun workstations that shipped with actual molded into the slick little case smart card readers -- cool! -- but what kind of nut uses a Sun machine on his home desktop? Almost no one, that's who.
It's a boostrap problem. Consumers won't start demanding such access methods until merchants require them, and merchants can't make them a requirement until there's a viable population of customers that have them installed. Until both sides of that start to move, we're stuck with purely "what you know" authentication systems for all e-commerce. That's not to say that e-commerce as implemented is insecure by design -- it isn't, there's a lot of clever algorithms / processes at work in e-commerce -- but there's still room for improvement and adding a "what you have" or "what you are" component to the mix should only make things stronger.
(This is actually the one bright side of Microsoft's "Trusted Computing" initiative. The evil DRM stuff notwithstanding, if they work some kind of viable "what you have" mechanism into future computer architectures, that could potentially be a very useful thing. But then, it could also be a tremendous violation of your privacy, depending on how it's implemented. Knowing Microsoft, they'll probably take the one grain of good idea and bury it under a mountain of bad implementation and things you didn't want to begin with...)
It was spelled out pretty clear in the beginning by all pro-gun groups (and the President) that they wanted a clean bill.
That's not how things work in a republic.
Clearly, you've been sleeping through George Buh's America, where as far as he and his pals are concerned, that's exactly how they want things to work. You're talking about the ideals of democratic America, and they were nice, but the Rubicon has been crossed and now we've got our dear little tinpot leader changing things as fast as possible. Are we a republic any more? These days, I'm not sure that the term applies.
Be that as it may, Twirlip is absolutely correct: compromise is the absolute core of a functioning democracy, and it absolutely cannot be sacrificed for something as petty as legislative expediency. So it takes years for Congress to get things done -- so what? Do you really want to live in a nation so unstable that the law making bodies are able to change the rules at a whim? That's not democracy, that's dictatorship, and shifting too much power in El Presidente's direction is too big of a step in the wrong direction. When congress moves fast, bad things happen: the Patriot Act is a shining example of the kind of disaster that can happen when compromise & consideration are sacrificed for political expediency, and we're not going to have to live with that mistake for years to come.
Elsewhere in this thread, Twirlip urged you (pi_rules) to look back at history, to see how compromise has molded this country. Did you bother taking his advice? Again, he was right: every nuance of our federal system was the result of compromise. Some wanted a strong, centralized federal system, while others wanted all power devolved to the states -- hence the delicate balance the Constitution strikes between federal & state control. Some wanted to consolidate power in northern cities, while others wanted more of a voice for the rural south -- hence the compromise of building Washington DC in the (at the time) rural south, but close to what was then the middle of the country. Some wanted slavery, some were against it -- hence the 3/5 compromise, which arguably delayed the civil war by decades. Et cetera.
A political system with no compromise is a disaster. North Korea, Iraq, <troll> Buh's America </troll>. No sane person would ever want to live in one of these places. But the line item veto is practically an invitation to give up on legislative compromise, and would undermine the structure of our carefully tuned political system in ways that would be vast, subtle, and ultimately disastrous.
No political issue is so important that achieving it is worth undermining the entire systeem that has served us so well for decades, is it? I sure don't think so...
The important thing to keep in mind for any authentication system -- not just computers, but any system that requires people to identify themselves -- is that there are basically three ways to go about it:
Something you know. (A password or passphrase; your mother's maiden name; your favorite song.)
Something you have. (Some kind of physical token like an ATM card, the key for your car or house, the hardware decorder in a DVD player, or one of the hardware dongles that was briefly popular for enforcing software licenses a few years ago.)
Something you are. (Biometrics: your thumbprint or retina scan; your photo & physical description on a license or passport [which itself is something you have -- see above]; DNA samples; voice or handwriting recognition; etc.)
Good security systems use at least two of these authentication classes: the ATM doesn't work unless you insert your card (something you have) and enter your PIN (something you know); when travelling abroad, customs agents will examine your passport (something you have), will cross-check your appearance against the passport's photo & description (something you are), and may ask probing questions about your travel plans (something you know).
Bad security systems rely exclusively on one of these elements. Basically all Internet security comes down to things you know, a/k/a passwords. From your point of view, an online purchase may seem to involve something you know (a password) and something you have (the numbers on your credit cards), but from the merchant's point of view they're just taking your word for it because they have no way to validate that the security token you're using is actually in your possession -- hence, credit card fraud. Likewise, I've voted in every election since I turned 18, and not once has an election worker asked for anything more than my name & address (something I claim I know) -- they never ask for an ID (something I have) or a fingerprint (something I am) etc. With this kind of scrutiny, it wouldn't be very hard for someone to spend all day voting in every precinct around. (I'm hopeful that electronic voting may actually fix this problem, but if as seems likely it introduces even more avenues for fraud then forget it.)
So, a password is essentially something you know, while an access card is something you have. There's a subtle but essential difference. If it was a string of numbers stamped on the card in an easily human readable way, then it could be considered as a form of password, but the fact that you need a machine to read it really enforces the point that it's something different. And that's why it's a good thing! A computer security system that relied on both traditional passwords as well as this kind of physical token would stand a much better chance of being robust than any system that used only passwords or tokens.
The problem is, almost nobody has a computer capable of reading such tokens. Aside from point of sale systems, almost no one has any use for card reading wedges, so building an authentication system around a requirement for card readers would be difficult to deploy broadly. Setting it as a general company policy might not be hard to do for most companies, if only because there you have a hope of installing the reader hardware for all users. Requiring a dual "know/have" or "know/are" system only for certain systems (access to sensitive areas, etc) would be prudent for any business to implement, but going from there to building a business of providing such systems to the general public would be much harder as long as the infrastructure doesn't exist -- that is, as long as Dell isn't shipping access card readers with every machine they sell.
So: something you know, something you have, something you area. Keep these in mind and the analysis of secure authentication mechanisms gets much clearer.
That's deliberate. According to a Fresh Air interview that Matt Groening did with Terry Gross last year, the resemblance was a deliberate joke in the early days of the show: here was thls little brat, Bart (the name is another joke), that hated his (bumbling, but loving) father and treated him miserably, and yet he absolutely idolzed this television character that was in every way a copy of Homer, but with all the negative attributes of Homer magnifiied.
It's, like, irony. Dig?
********
This message is giving me deja vu -- didn't I post this info to a message of yours once before, or was someone else posing that question in his/her signature?
Shows have survived in syndication with less. There were, if I remember right, 79 episodes of Star Trek
Or let's look at really classic television. Pretty much everybody has seen all the old reruns of The Honeymooners, but the show was only on the air for 39 episodes in the 1955-1956 season. It may seem like way more than that, but that's really it. And yet that show -- and I Love Lucy -- will live on in re-runs forever and ever.
Of course, the real difference between shows like The Honeymooners & I Love Lucy on one hand, and Andreomeda & Mutant X on the other, is that the former are classic & timeless, while the latter are boring crap. By and large. The number of episodes is only part of the equation: a good show can be syndicated forever (and, as a side effect, a good show will have a long initial run), but a bad show won't make it in reruns and will rarely survive long enough to build up a catalog anyway.
The interesting recent twist is that now, with the affirmation of strong DVD sales, dead shows are able to get a second chance at a new life. This has never really happened before. There have been spinoffs (all the Trek variants) and remakes (all the Twilight Zone revivals), but I can't think of many cases before now where a show that had been cancelled & disbanded was brought back on the air, as is supposedly happening now with shows like Family Guy and Futurama. The closest I can think of is when cult shows like The Critic or TV Nation were dropped from their first network but picked up by a smaller one, but at least in these two cases the shows didn't do any better the second time around. It'll be interesting to see where that trend goes in the future, as more shows are put on to DVD and audiences get a second chance to see things they ignored the first time around.
I'm getting bus error crashes when trying to download the patch on two different Macs, one a G5, the other a G3 iBook. The session goes something like this:
% sudo softwareupdate -d AirPortSW-3.4.1
Password:
Software Update Tool
Copyright 2002-2003 Apple Computer, Inc.
This is very repeatable for me -- it happened three times on one machine & twice on the other. I don't remember the softwareupdate command having a problem like this before.
On the other hand, I was able to use Safari to download the.dmg directly from Apple, and Safari hasn't crashed on me. And the fact that people are reporting success with this suggests that the GUI tool is working, &/or the problem is local to the download option for the command line tool.
Still, it's annoying -- I was hoping to skip downloading it over & over, and this was much more of a kludge than I had in mind...
PowerPage [powerpage.org] is reporting that this morning's update is cutting airport range on Extreme clients by up to 60% (!! !!).
So regular 802.11b Airport is unaffected? My old iBook can't use an Airport Extreme card anyway. Do I take it then that older gear is immune to this bug?
I dunno, I think a very good case could be made that building any application around its interface is exactly the wrong way to do it. Rather, the developer[s] should develop code that implements the core functionality, and *then* hang some kind of interface on the front of it. (Whether or not these activities happen in parallel is a separate matter: without getting into a diversion about what development methodologies work best, please concede that it's generally considered a good idea to keep interfaces at arm's length from core functionality.
So, with that in mind, you could make a strong case that a well implemented application may be something unassuming like a library or a command line tool. Around this, you can build different kinds of interfaces (a standard GUI, some GUI for different operating systems, different GUIs for different locales, a web interface, etc.
This is getting to be a common way to implement software on OSX. Take Fink Commander, for example: it's a nice, high level graphical tool for driving/sw/bin/fink and related commands. It demonstrates how a command line toolkit (basically, an extended version of Debian's APT tools) can be presented to the user in a simple, easy to understand graphical way, while still allowing users "direct" access to the command line version as well. Likewise, The core of OSX's Network Utility application is a little command line program in/Applications/Utilities/Network Utility.app/Contents/Resources/stroke. Running it in the GUI is nice, but from the command line it's also useful:
Open Port: 22 ssh
Open Port: 80 http
Open Port: 111 sunrpc
Open Port: 139 netbios-ssn
Open Port: 427 svrloc
Open Port: 631 ipp
Open Port: 877
Open Port: 936
Open Port: 937
Open Port: 938
$
Nice! And other applications can be driven in similar ways -- StuffIt, some of Adobe's stuff, et cetera. Clearly this is an excellent way to appease both the GUI and TUI user bases.
Another nice example is Request Tracker. RT is a trouble ticketing & tracking system, similar in many ways to Bugzilla (but *ahem* much nicer, IMO). One of the really cool things about RT is that you can interact with it through a Perl/Mason driven web interface, you you can use email or a command line tool. The email interface is nice, because you can basically have a natural mail conversation with your colleagues and RT will keep track of everything for you. The command line version is nice because, well, lots of people like working in command lines. The fact that RT allows you so many ways to work with the system is excellent system design (even if you don't care for the interfaces provided, that's a separate matter; the fact that they are all available (and more can be added if you know some Perl) is clearly a good thing).
Finally, look at databases. Every good database -- that is, more or less everything other than desktop toys like Access or FileMaker -- provides at a minimum a command line interface, one or more graphical interfaces, and a programming API for multiple languages. Often, you can find additional third party interfaces so that you can interact with the database other ways, such as through a web browser. All of these things are generally considered to be minimum requirements for any database that wants to be taken seriously.
So, what of your PHB then? The PHBs and marketing & sales drones may want GUIs, and that's fine -- they should be allowed to have them. But if any boss fails to recognize that providing alternative interfaces for software is obviously a good & necessary thing, then maybe someone else deserves that person's job more than they do.
The 5% of Americans who just lost their jobs will now be making those other products, most likely.
Yeah, but that's the thing: what other products? We've outsourced almost every blue collar manufacturing industry overseas by now, and the white collar jobs are starting to follow them.
What industry is going to be the white knight to come in and save all the thousands of UAW workers, shop mechanics, financial services staff, etc?
The only industry that seems to be consistently going up is retail, but that's hardly a promising career move for most people.
++++
It seems to me that this whole business of "we can just switch industries" is nothing so much as a version of the libertarian's beloved broken window fallacy: the idea that switching to something else will magically solve any of our problems seems optimistic & questionable at best. Something about that concept has never seemed convincing to me, but I can't honestly put my finger on what I think the problem might be.
In any case, your argument is seductive: maybe freeing up the thousands of dollars people spend on cars will allow other industries to flourish: I certainly hope that would be true. But at the same time, it could be an awfully traumatic shock to the economy, especially at a time when all those millions of greying baby boomers are about to retire, and I'm having a hard time seeing something positive that we could transform our economy into next. Maybe in hindsight it will seem obvious, but at this point I'm pretty pessimistic...
Home Depot sells window air conditioners for $80. They are made in China. When it breaks you throw it out. Twenty years ago a window air conditioner cost $1000 in today's money. When it broke you called the repairman.
You can buy a 27" TV for less than $200. It is made in China. If someone asks you what brand of TV you have, unless you're a geek with no life, you won't have a clue. You don't see ads for Daewoo or Apex TVs. When it breaks you throw it out. Forty years ago the TV industry employed at least one million Americans. TVs were made here. They cost so much that they needed to be financed, thus creating jobs in banks. If they broke every neighborhood had a TV repairman to come out and service the machine. Some of the most expensive advertising campaigns of the day were for cars. Consequently, consumers were intensely brand-loyal and proud to own an RCA, a Philco or whatever.
Once something can be assembled in China out of 100% Chinese-made components it can sell for approximately 1/10th the previous price.
Let's look at cars. According to http://www.autoalliance.org/ecofacts.htmthe auto industry employs at least 5 percent of Americans. People have jobs making cars. Because cars are so expensive people have jobs financing them, repairing them, and insuring them against collision and theft. Because cars are so expensive, people have jobs marketing and advertising them (more than $1000 of the price of a normalcar has gone into advertising, probably closer to $5000 for a Mercedes or BMW).
Within 10 to 20 years the Chinese will be able to sell a car that is very similar to today's rental car:4 doors, 4 seats, air conditioner, radio, new but not fancy. It will cost between $2000 and $3000 in today's dollars. With cars that cheap it will be unthinkable to manufacture in the U.S. Consumers won't bother to finance a $2000 purchase separately (maybe they'll add it to their credit card debt). Drivers will still carry liability insurance but won't bother with collision or theft coverage. With cars that cheap it won't make sense to advertise. If Ford or Toyota tried to sell the average person a $25,000 car they would simply laugh, much as a Walmart shopper would think you're crazy if you tried to persuade him to spend $2,000 on a TV.
If his analysis is correct -- and it certainly seems plausible -- then the predictions he goes on to make from there are wide-ranging and dramatic. What happens if the 5% of the American workforce that makes, sells, and finances cars is suddenly out of a job? What other manufacturing field could pick up that much slack? Can the economy change course in time to maintain America's wealth, or could this drastically accelerate the loss of blue (and now white) collar jobs that we've been seeing since the 1970s?
Maybe we should all just go apply at Wal-Mart now. At least then in 10 years we'll have a shot at being a minimum wage shlobs with seniority.
And their other product, with the silly cartoons, is even more implausible. But let's not get distracted by the obvious fake -- the gun is more interesting anyway.
As a hypothetical exercise, could this kind of coverty GPS planting work? Let's say that the GPS beacon / transmitter is small enough to be mistaken for an insect's sting, so no bigger than a grain of sand. What then?
Do GPS receivers that small currently exist? Are they reliable? What power supply do they need, and how long could an implanted one continue to operate?
Would it be possible to remotely track these devices from, say, NSA headquarters in Fort Mead, Maryland? The graphics suggest that they can monitor a tag's movement on a 1000 mile journey from Maine to North Carolina -- was this data gathered from close to the target (in which case why bother with the beacon since you can presumably track them with more conventional means), or was the data gathered remotely (in which case how powerful can that little transmitter be?
I don't believe for a minute that this is real, but I had no problem believing that various Three Letter Agencies would love to treat this as a prototype for devices they would like to build. How close are we to being able to approximate this with current technology?
My two year old Sony Clie has a built-in camera that can record video with sound for as long as you have space on the Memory Stick to store it. It seems like you could get an hour or more of video recorded on an empty 128mb card. The image quality isn't anything spectacular, but it's definitely fun & useful to use, if in a "lo-fi / arty" way.
For example, when I was on my honeymoon last year, I was able to use the Clie to make short, narrated video clips of the "disco ball" effect that the Eiffel Tower makes at the top of each hour every night. This was much more fun than lugging around a camcorder everywhere, and because the effect was animated, still photos weren't doing it any justice. Having a pocket camcorder was an excellent compromise in this case.
Admittedly, the Clie isn't quite as small as what Philips is announcing, but then the fact that the Clie is a PDA means that it can be used kind of discretely: when using it to take photos or video, it looks like I'm just using any old Palm Pilot. Plus, I get a nice 2"x3" display of what I'm recording.
The future is now. Well, aside from the flying cars, I'm still bitter about that one...
Is WinAmp the free multimedia player of choice for Windows users?
Generally, yes. WinAmp has a good reputation and deservedly so. Everything else, aside from Windows Media Player, is basically a niche product, and if WMP wasn't embedded in the operating system I'm not sure how many people would use it either.
That said, I'm surprised that more people in this thread haven't brought up iTunes. Nevermind the iTunes Music Store -- the software itself is fantastic. It's very easy to use, it handles things like ripping & burning CDs nicely, and everything just works.
Plus -- and this is a feature that I'm not aware of with any other media software -- the ability to share your library with other users on your local network is wonderful. I've seen software for getting a Linux server to serve the DAAP protocol that iTunes uses, but I don't know of any software that can act as a client other than iTunes. It would be great if WinAmp or XMMS could pick up this ability so that everyone in a mixed Windows / Mac / *nix office or home could share their libraries amongst each other. But until & unless other audio software picks up this ability, iTunes has a clear advantage going for it.
Google is interviewing candidates for engineering positions at our lunar hosting and research center, opening late in the spring of 2007. This unique opportunity is available only to highly-qualified individuals who are willing to relocate for an extended period of time, are in top physical condition and are capable of surviving with limited access to such modern conveniences as soy low-fat lattes, The Sopranos and a steady supply of oxygen.
The Google Copernicus Hosting Environment and Experiment in Search Engineering (G.C.H.E.E.S.E.) is a fully integrated research, development and technology facility at which Google will be conducting experiments in entropized information filtering, high-density high-delivery hosting (HiDeHiDeHo) and de-oxygenated cubicle dwelling. This center will provide a unique platform from which Google will leapfrog current terrestrial-based technologies and bring information access to new heights of utility.
Yeah but an even cooler joke would be throwing something up that everyone thinks is an April Fool's joke, and then doing it for real. A meta-April Fool's joke, if you will.
The name "Parrot" relates to Simon Cozens's April Fool's Joke where Larry Wall and Guido van Rossum announced the merger of the Perl and Python languages.
Except now it's real, it's the already-implemented runtime engine for Perl 6, and the ability to run a variety of dynamic languages like Perl, Python, Ruby, PHP, etc is explicitly part of the design.
The catch is that some pages are transient (generated pages, news articles, etc), so the data you're grabbing isn't necessarily enough to get back to that page in the future. It would probably be better to also record the client's GET or POST request, along with the post data, if any, as well as things like username/password [security issue, but maybe useful enough to warrant it]). Additionaly, it's probably worth setting aside space to cache the retrieved document as well, at least for text/* mime types, but maybe graphics & other media as well.
A proxy does sound like the right way to do this though, if only because a proxy neatly solves the problem of allowing people to switch between different computers (home, work, laptop) and still have access to a central traffic database.
I've worked with a Zope debugger that did basically this kind of thing: it acted as a proxy server, so you point your web browser at it, and it records timestamped.in and.out files for every request your web client makes, capturing all the data being sent both out to the remote web server and back in to your client browser. If you wanted to replay something, there were tools to fire off the.out files & parse the results that came back to make sure that the.in responses matched what you expected.
This kind of web proxy framework is very slick for web site debugging, but it could also be a suitable mechanism for the kind of "where was I?" tool that is being asked for. You could even do something silly like cache the.in and.out results in a big MySQL table with full text indexing on the payload field, so you could search it reasonably quickly.
A very clever system built over this would manage data aset growth by having a way to replace duplicated documents (images, text, etc) with something like symlinks to each other, so that you don't end up grabbing, say, hundreds of copies of the Slashdot logo. Better still, the software could detect page furniture (logos, icons, structural graphics, ads, etc) and throw that out while keeping the good stuff (news photos, etc). But that starts sounding like a deep AI problem, and is probably more trouble than it's worth. If you can just consolidate identical data, that's already a big win.
It would be interesting to see someone put these & related ideas together into something people could actually use. The closest things I know of -- and these are both worth reading about -- are Gordon Bell's MyLifeBits project at Microsoft Research, and Vannevar Bush's As We May Think essay for the July 1945 issue of Atlantic Monthly. Both of these concepts get into the same thing that we're talking about for the web here, but in a much broader way -- Bell wants to digitally record everything in his life, but we're only dealing with web activity.
Wanting to stick with the English language is ignorant?
Granted, not everyone uses English as a primary or even secondary language, but come on, as languages go, English is extremely flexible and willing to adopt foreign terminology. Words like "sushi" and "glasnost" and "bjork" don't sound all that weird to the ears of many English speakers.
But Xiph? Theora? Ogg? These sound like nasty things the Giant would have said to threaten our hero in Jack & The Beanstalk. These words are like something that a cave man would say to threaten, or maybe proposition, some cave-wench.
These names -- and I'm being very charitable here -- are extremely effing stupid.
A lot of the time, new English terminology is borrowed from existing terms in another language: often Greek & Latin, but sometimes more current languages like French, German, Yiddish, Arabic, Japanese, etc. As a general rule, science fiction is not usually seen as a rich source of new names, and the Ogg fiasco is a perfect demonstration of why that would be the case.
I can't say "ogg" without feeling dirty. I already have a hard time typing it and will probably be giving my keyboard a nice bath to purge if of my sins. If you'll excuse me...
Maybe so, I can't say. But from the way I understand the design of the system, getting Perl6 to run on Parrot is "only" going to be a matter of writing an interface wrapper to bootstrap it. They have a reasonable idea of what the basic functionality needs to be, so Parrot has been written to meet those needs -- and the needs of other languages (esp. Python) as well. [1]
From what I understand, the Parrot group wanted to wait for a reasonably complete Perl6 before they started, but when it became obvious that this was going to take a while, they decided to just get started. Surprisingly, work ended up happening very fast, and we've ended up in the strange but possibly useful situation of having a roughly complete Parrot engine available today, two or three years after development started, even though the Perl6 design is still evolving.
This isn't necessarily a bad thing though. No one wants to throw out the expertise that thousands of people have built up in learning Perl5, so even when Perl6 is available, Perl5 is still going to be around -- if only to run the huge number of Perl5 scripts that will never be rewritten for the new version of the language.
With that in mind, one of the design criteria for the Perl6 project is robust Perl5 support, and with Parrot at the level it's at now, it should be possible to write a Perl5 interface to the VM without waiting for Perl6 to be finished. Because the design of Parrot is so much cleaner -- and faster -- than Perl5's current internals, this might actually speed up existing code, and could even make the painful process of developing with XS a thing of the past. It could be a benefit to Perl5 in the near future separate & apart from Perl6's progress, if & when this interface comes to fruition (which, according to the last plans I took a look at, it definitely will).
So yeah, this is probably the reverse of how things "should" have been developed, but there are some positive things about the current situation... *shrug*
******
[1] Python needs support for certain things -- I think co-routines was the example Dan Sugalski used in his talk -- that Perl doesn't currently care about, so they've gone in to Parrot. If anyone wanted to expose this functionality to Perl, it would be easy enough to do so, and sooner or later someone probably will.
The Parrot VM is a neat idea, that goes even further than.NET since it's multi-platform, and definitely will be very nice when it's finished. But I feel like it's going to delay Perl 6.
Nah, Parrot isn't the bottleneck. Parrot development has actually moved pretty fast: they quickly came up with a raw-functionality virtual machine, and at this point the Parrot engine seems to meet the basic runtime needs of Perl5, Perl6 [as specced out to date], Python, and PHP.
Parrot isn't done yet to be sure, but it's already complete enough that, for example, the employer of one of Parrot's main developers is already using Parrot as the runtime engine for their corporate software. [I'd get in to details, but I forget the details -- Dan Sugalski talked about it for the Boston Perl Mongers a month or two ago.] Likewise, there's already a mod_parrot Apache module under development that will allow Parrot targeted code to run, and run very quickly, while embedded in the web server. Longer term, one of the target languages for Parrot is Z-code, so that Parrot will be able to run old text games like Zork and Hitchhiker's Guide To The Galaxy -- with luck, this could lead to Parrot being the embedded virtual machine for portable game machines.
Parrot is, in other words, being actively developed, and there are big plans for it.
Parrot is hardly holding Perl6 back.
The bottleneck with Perl6 seems like the actual design work. Once Larry Wall puts out one of his Apocalypses, it never seems to be long before Damian Conway comes out with an explanation, including working code that can often be experimented with today under Perl5, with his Exegeses. There seems to be a ready pool of people eager to implement this stuff as it becomes available, it's just that the project is so *big* that it's taking a while for people to get anywhere with it in their spare time.
I have read of police who were shot with broadhead hunting arrows and the vests were only useful to them as big band-aids.
Yeah, but think about that for a minute. This is a physics article -- don't you remember the old F = MA formula? If we assume that a bullet flies at roughly the same speed that an arrow does, then the main determinant of force is the mass of the projectile.
Bullets are tiny -- even a big one from an assault rifle probably weighs no more than an ounce or so. Arrows, on the other hand, are comparitively heavy -- maybe half a pound or a pound for a big compound bow's hunter's arrow or a crossbow bolt.
Therefore, if the projectiles are going at the same speed when they hit their target, an arrow is going to hit that target with perhaps ten times more force than the bullet would.
Plus -- and I have no idea how to quantify this, but I'm sure it only amplifies things -- bullets tend to have blunt tips (only moderately sharp for assault rifles), but arrowheads can be razor sharp. I'm sure that only widens the gap between bullets and arrows.
Arrows are a much bigger threat to typical body armor than bullets. Weird, eh?
The US federal government has three branches, which I suppose fits with what I said, but I meant leadership by three individuals.
Three groups isn't so bad necessarily -- tripods can be nice & stable, and from a certain point of view, the US government is just shaped like a big tripod. (OTOH, having all three legs run by one party isn't such a hot idea, but that's a different matter...)
Slashdot Mirror
That's true, and it isn't a bad idea if followed through. A floppy drive may not be such a great idea -- read/write access to tokens probably wouldn't be a good thing -- but if they could be mass-produced than I don't see any reason why you couldn't put some kind of ID tokens on a CD-ROM (maybe one of those business card ones, so you could carry it around) or have some kind of USB dongles for the same purpose
The point though was that, while as you say the interfaces for such access devices are currently available, there's still almost no one putting these into practice on anything like a wide scale deployment. Cards with magnetic stripes are ubiquitous, but almost no one has a reader for them at home. Access token CD-ROMS or USB dongles could work, but I've never heard of anyone doing these things. I've seen recent Sun workstations that shipped with actual molded into the slick little case smart card readers -- cool! -- but what kind of nut uses a Sun machine on his home desktop? Almost no one, that's who.
It's a boostrap problem. Consumers won't start demanding such access methods until merchants require them, and merchants can't make them a requirement until there's a viable population of customers that have them installed. Until both sides of that start to move, we're stuck with purely "what you know" authentication systems for all e-commerce. That's not to say that e-commerce as implemented is insecure by design -- it isn't, there's a lot of clever algorithms / processes at work in e-commerce -- but there's still room for improvement and adding a "what you have" or "what you are" component to the mix should only make things stronger.
(This is actually the one bright side of Microsoft's "Trusted Computing" initiative. The evil DRM stuff notwithstanding, if they work some kind of viable "what you have" mechanism into future computer architectures, that could potentially be a very useful thing. But then, it could also be a tremendous violation of your privacy, depending on how it's implemented. Knowing Microsoft, they'll probably take the one grain of good idea and bury it under a mountain of bad implementation and things you didn't want to begin with...)
Clearly, you've been sleeping through George Buh's America, where as far as he and his pals are concerned, that's exactly how they want things to work. You're talking about the ideals of democratic America, and they were nice, but the Rubicon has been crossed and now we've got our dear little tinpot leader changing things as fast as possible. Are we a republic any more? These days, I'm not sure that the term applies.
Be that as it may, Twirlip is absolutely correct: compromise is the absolute core of a functioning democracy, and it absolutely cannot be sacrificed for something as petty as legislative expediency. So it takes years for Congress to get things done -- so what? Do you really want to live in a nation so unstable that the law making bodies are able to change the rules at a whim? That's not democracy, that's dictatorship, and shifting too much power in El Presidente's direction is too big of a step in the wrong direction. When congress moves fast, bad things happen: the Patriot Act is a shining example of the kind of disaster that can happen when compromise & consideration are sacrificed for political expediency, and we're not going to have to live with that mistake for years to come.
Elsewhere in this thread, Twirlip urged you (pi_rules) to look back at history, to see how compromise has molded this country. Did you bother taking his advice? Again, he was right: every nuance of our federal system was the result of compromise. Some wanted a strong, centralized federal system, while others wanted all power devolved to the states -- hence the delicate balance the Constitution strikes between federal & state control. Some wanted to consolidate power in northern cities, while others wanted more of a voice for the rural south -- hence the compromise of building Washington DC in the (at the time) rural south, but close to what was then the middle of the country. Some wanted slavery, some were against it -- hence the 3/5 compromise, which arguably delayed the civil war by decades. Et cetera.
A political system with no compromise is a disaster. North Korea, Iraq, <troll> Buh's America </troll>. No sane person would ever want to live in one of these places. But the line item veto is practically an invitation to give up on legislative compromise, and would undermine the structure of our carefully tuned political system in ways that would be vast, subtle, and ultimately disastrous.
No political issue is so important that achieving it is worth undermining the entire systeem that has served us so well for decades, is it? I sure don't think so...
Kinda... not really.
The important thing to keep in mind for any authentication system -- not just computers, but any system that requires people to identify themselves -- is that there are basically three ways to go about it:
Good security systems use at least two of these authentication classes: the ATM doesn't work unless you insert your card (something you have) and enter your PIN (something you know); when travelling abroad, customs agents will examine your passport (something you have), will cross-check your appearance against the passport's photo & description (something you are), and may ask probing questions about your travel plans (something you know).
Bad security systems rely exclusively on one of these elements. Basically all Internet security comes down to things you know, a/k/a passwords. From your point of view, an online purchase may seem to involve something you know (a password) and something you have (the numbers on your credit cards), but from the merchant's point of view they're just taking your word for it because they have no way to validate that the security token you're using is actually in your possession -- hence, credit card fraud. Likewise, I've voted in every election since I turned 18, and not once has an election worker asked for anything more than my name & address (something I claim I know) -- they never ask for an ID (something I have) or a fingerprint (something I am) etc. With this kind of scrutiny, it wouldn't be very hard for someone to spend all day voting in every precinct around. (I'm hopeful that electronic voting may actually fix this problem, but if as seems likely it introduces even more avenues for fraud then forget it.)
So, a password is essentially something you know, while an access card is something you have. There's a subtle but essential difference. If it was a string of numbers stamped on the card in an easily human readable way, then it could be considered as a form of password, but the fact that you need a machine to read it really enforces the point that it's something different. And that's why it's a good thing! A computer security system that relied on both traditional passwords as well as this kind of physical token would stand a much better chance of being robust than any system that used only passwords or tokens.
The problem is, almost nobody has a computer capable of reading such tokens. Aside from point of sale systems, almost no one has any use for card reading wedges, so building an authentication system around a requirement for card readers would be difficult to deploy broadly. Setting it as a general company policy might not be hard to do for most companies, if only because there you have a hope of installing the reader hardware for all users. Requiring a dual "know/have" or "know/are" system only for certain systems (access to sensitive areas, etc) would be prudent for any business to implement, but going from there to building a business of providing such systems to the general public would be much harder as long as the infrastructure doesn't exist -- that is, as long as Dell isn't shipping access card readers with every machine they sell.
So: something you know, something you have, something you area. Keep these in mind and the analysis of secure authentication mechanisms gets much clearer.
Woohoo! My trusty old 1234567890 didn't make the list!
That's deliberate. According to a Fresh Air interview that Matt Groening did with Terry Gross last year, the resemblance was a deliberate joke in the early days of the show: here was thls little brat, Bart (the name is another joke), that hated his (bumbling, but loving) father and treated him miserably, and yet he absolutely idolzed this television character that was in every way a copy of Homer, but with all the negative attributes of Homer magnifiied.
It's, like, irony. Dig?
********
This message is giving me deja vu -- didn't I post this info to a message of yours once before, or was someone else posing that question in his/her signature?
Or let's look at really classic television. Pretty much everybody has seen all the old reruns of The Honeymooners , but the show was only on the air for 39 episodes in the 1955-1956 season. It may seem like way more than that, but that's really it. And yet that show -- and I Love Lucy -- will live on in re-runs forever and ever.
Of course, the real difference between shows like The Honeymooners & I Love Lucy on one hand, and Andreomeda & Mutant X on the other, is that the former are classic & timeless, while the latter are boring crap. By and large. The number of episodes is only part of the equation: a good show can be syndicated forever (and, as a side effect, a good show will have a long initial run), but a bad show won't make it in reruns and will rarely survive long enough to build up a catalog anyway.
The interesting recent twist is that now, with the affirmation of strong DVD sales, dead shows are able to get a second chance at a new life. This has never really happened before. There have been spinoffs (all the Trek variants) and remakes (all the Twilight Zone revivals), but I can't think of many cases before now where a show that had been cancelled & disbanded was brought back on the air, as is supposedly happening now with shows like Family Guy and Futurama. The closest I can think of is when cult shows like The Critic or TV Nation were dropped from their first network but picked up by a smaller one, but at least in these two cases the shows didn't do any better the second time around. It'll be interesting to see where that trend goes in the future, as more shows are put on to DVD and audiences get a second chance to see things they ignored the first time around.
I'm getting bus error crashes when trying to download the patch on two different Macs, one a G5, the other a G3 iBook. The session goes something like this:
This is very repeatable for me -- it happened three times on one machine & twice on the other. I don't remember the softwareupdate command having a problem like this before.
On the other hand, I was able to use Safari to download the .dmg directly from Apple, and Safari hasn't crashed on me. And the fact that people are reporting success with this suggests that the GUI tool is working, &/or the problem is local to the download option for the command line tool.
Still, it's annoying -- I was hoping to skip downloading it over & over, and this was much more of a kludge than I had in mind...
So regular 802.11b Airport is unaffected? My old iBook can't use an Airport Extreme card anyway. Do I take it then that older gear is immune to this bug?
I dunno, I think a very good case could be made that building any application around its interface is exactly the wrong way to do it. Rather, the developer[s] should develop code that implements the core functionality, and *then* hang some kind of interface on the front of it. (Whether or not these activities happen in parallel is a separate matter: without getting into a diversion about what development methodologies work best, please concede that it's generally considered a good idea to keep interfaces at arm's length from core functionality.
So, with that in mind, you could make a strong case that a well implemented application may be something unassuming like a library or a command line tool. Around this, you can build different kinds of interfaces (a standard GUI, some GUI for different operating systems, different GUIs for different locales, a web interface, etc.
This is getting to be a common way to implement software on OSX. Take Fink Commander, for example: it's a nice, high level graphical tool for driving /sw/bin/fink and related commands. It demonstrates how a command line toolkit (basically, an extended version of Debian's APT tools) can be presented to the user in a simple, easy to understand graphical way, while still allowing users "direct" access to the command line version as well. Likewise, The core of OSX's Network Utility application is a little command line program in /Applications/Utilities/Network Utility.app/Contents/Resources/stroke. Running it in the GUI is nice, but from the command line it's also useful:
Nice! And other applications can be driven in similar ways -- StuffIt, some of Adobe's stuff, et cetera. Clearly this is an excellent way to appease both the GUI and TUI user bases.
Another nice example is Request Tracker. RT is a trouble ticketing & tracking system, similar in many ways to Bugzilla (but *ahem* much nicer, IMO). One of the really cool things about RT is that you can interact with it through a Perl/Mason driven web interface, you you can use email or a command line tool. The email interface is nice, because you can basically have a natural mail conversation with your colleagues and RT will keep track of everything for you. The command line version is nice because, well, lots of people like working in command lines. The fact that RT allows you so many ways to work with the system is excellent system design (even if you don't care for the interfaces provided, that's a separate matter; the fact that they are all available (and more can be added if you know some Perl) is clearly a good thing).
Finally, look at databases. Every good database -- that is, more or less everything other than desktop toys like Access or FileMaker -- provides at a minimum a command line interface, one or more graphical interfaces, and a programming API for multiple languages. Often, you can find additional third party interfaces so that you can interact with the database other ways, such as through a web browser. All of these things are generally considered to be minimum requirements for any database that wants to be taken seriously.
So, what of your PHB then? The PHBs and marketing & sales drones may want GUIs, and that's fine -- they should be allowed to have them. But if any boss fails to recognize that providing alternative interfaces for software is obviously a good & necessary thing, then maybe someone else deserves that person's job more than they do.
Yeah, but that's the thing: what other products? We've outsourced almost every blue collar manufacturing industry overseas by now, and the white collar jobs are starting to follow them.
What industry is going to be the white knight to come in and save all the thousands of UAW workers, shop mechanics, financial services staff, etc?
The only industry that seems to be consistently going up is retail, but that's hardly a promising career move for most people.
++++
It seems to me that this whole business of "we can just switch industries" is nothing so much as a version of the libertarian's beloved broken window fallacy: the idea that switching to something else will magically solve any of our problems seems optimistic & questionable at best. Something about that concept has never seemed convincing to me, but I can't honestly put my finger on what I think the problem might be.
In any case, your argument is seductive: maybe freeing up the thousands of dollars people spend on cars will allow other industries to flourish: I certainly hope that would be true. But at the same time, it could be an awfully traumatic shock to the economy, especially at a time when all those millions of greying baby boomers are about to retire, and I'm having a hard time seeing something positive that we could transform our economy into next. Maybe in hindsight it will seem obvious, but at this point I'm pretty pessimistic...
Philip Greenspun wrote a fascinating analysis of this a few months ago. To quote part of it:
If his analysis is correct -- and it certainly seems plausible -- then the predictions he goes on to make from there are wide-ranging and dramatic. What happens if the 5% of the American workforce that makes, sells, and finances cars is suddenly out of a job? What other manufacturing field could pick up that much slack? Can the economy change course in time to maintain America's wealth, or could this drastically accelerate the loss of blue (and now white) collar jobs that we've been seeing since the 1970s?
Maybe we should all just go apply at Wal-Mart now. At least then in 10 years we'll have a shot at being a minimum wage shlobs with seniority.
This can't be real.
The image of the rifle in question looks like CGI from a video game -- if it was real, why not just use a photo rather than a photo-realistic synthetic graphic?
And their other product, with the silly cartoons, is even more implausible. But let's not get distracted by the obvious fake -- the gun is more interesting anyway.
As a hypothetical exercise, could this kind of coverty GPS planting work? Let's say that the GPS beacon / transmitter is small enough to be mistaken for an insect's sting, so no bigger than a grain of sand. What then?
I don't believe for a minute that this is real, but I had no problem believing that various Three Letter Agencies would love to treat this as a prototype for devices they would like to build. How close are we to being able to approximate this with current technology?
My two year old Sony Clie has a built-in camera that can record video with sound for as long as you have space on the Memory Stick to store it. It seems like you could get an hour or more of video recorded on an empty 128mb card. The image quality isn't anything spectacular, but it's definitely fun & useful to use, if in a "lo-fi / arty" way.
For example, when I was on my honeymoon last year, I was able to use the Clie to make short, narrated video clips of the "disco ball" effect that the Eiffel Tower makes at the top of each hour every night. This was much more fun than lugging around a camcorder everywhere, and because the effect was animated, still photos weren't doing it any justice. Having a pocket camcorder was an excellent compromise in this case.
Admittedly, the Clie isn't quite as small as what Philips is announcing, but then the fact that the Clie is a PDA means that it can be used kind of discretely: when using it to take photos or video, it looks like I'm just using any old Palm Pilot. Plus, I get a nice 2"x3" display of what I'm recording.
The future is now. Well, aside from the flying cars, I'm still bitter about that one...
<nigel-tufnel> As long as we can all agree that Linux now goes to eleven, because that's, you know, one more. </nigel-tufnel>
Generally, yes. WinAmp has a good reputation and deservedly so. Everything else, aside from Windows Media Player, is basically a niche product, and if WMP wasn't embedded in the operating system I'm not sure how many people would use it either.
That said, I'm surprised that more people in this thread haven't brought up iTunes. Nevermind the iTunes Music Store -- the software itself is fantastic. It's very easy to use, it handles things like ripping & burning CDs nicely, and everything just works.
Plus -- and this is a feature that I'm not aware of with any other media software -- the ability to share your library with other users on your local network is wonderful. I've seen software for getting a Linux server to serve the DAAP protocol that iTunes uses, but I don't know of any software that can act as a client other than iTunes. It would be great if WinAmp or XMMS could pick up this ability so that everyone in a mixed Windows / Mac / *nix office or home could share their libraries amongst each other. But until & unless other audio software picks up this ability, iTunes has a clear advantage going for it.
<crocodile-dundee>
That's not Google's April Fool's joke.
This is Google's April Fool's joke!
</crocodile-dundee>
Et cetera.
I think that should dismiss speculation about whether the mail story is real :-)
You mean like Parrot?
Quoting from the Parrot FAQ:
Except now it's real, it's the already-implemented runtime engine for Perl 6, and the ability to run a variety of dynamic languages like Perl, Python, Ruby, PHP, etc is explicitly part of the design.
Heh... :-)
The catch is that some pages are transient (generated pages, news articles, etc), so the data you're grabbing isn't necessarily enough to get back to that page in the future. It would probably be better to also record the client's GET or POST request, along with the post data, if any, as well as things like username/password [security issue, but maybe useful enough to warrant it]). Additionaly, it's probably worth setting aside space to cache the retrieved document as well, at least for text/* mime types, but maybe graphics & other media as well.
A proxy does sound like the right way to do this though, if only because a proxy neatly solves the problem of allowing people to switch between different computers (home, work, laptop) and still have access to a central traffic database.
I've worked with a Zope debugger that did basically this kind of thing: it acted as a proxy server, so you point your web browser at it, and it records timestamped .in and .out files for every request your web client makes, capturing all the data being sent both out to the remote web server and back in to your client browser. If you wanted to replay something, there were tools to fire off the .out files & parse the results that came back to make sure that the .in responses matched what you expected.
This kind of web proxy framework is very slick for web site debugging, but it could also be a suitable mechanism for the kind of "where was I?" tool that is being asked for. You could even do something silly like cache the .in and .out results in a big MySQL table with full text indexing on the payload field, so you could search it reasonably quickly.
A very clever system built over this would manage data aset growth by having a way to replace duplicated documents (images, text, etc) with something like symlinks to each other, so that you don't end up grabbing, say, hundreds of copies of the Slashdot logo. Better still, the software could detect page furniture (logos, icons, structural graphics, ads, etc) and throw that out while keeping the good stuff (news photos, etc). But that starts sounding like a deep AI problem, and is probably more trouble than it's worth. If you can just consolidate identical data, that's already a big win.
It would be interesting to see someone put these & related ideas together into something people could actually use. The closest things I know of -- and these are both worth reading about -- are Gordon Bell's MyLifeBits project at Microsoft Research, and Vannevar Bush's As We May Think essay for the July 1945 issue of Atlantic Monthly. Both of these concepts get into the same thing that we're talking about for the web here, but in a much broader way -- Bell wants to digitally record everything in his life, but we're only dealing with web activity.
Baby steps... :-)
Wanting to stick with the English language is ignorant?
Granted, not everyone uses English as a primary or even secondary language, but come on, as languages go, English is extremely flexible and willing to adopt foreign terminology. Words like "sushi" and "glasnost" and "bjork" don't sound all that weird to the ears of many English speakers.
But Xiph? Theora? Ogg? These sound like nasty things the Giant would have said to threaten our hero in Jack & The Beanstalk. These words are like something that a cave man would say to threaten, or maybe proposition, some cave-wench.
These names -- and I'm being very charitable here -- are extremely effing stupid.
A lot of the time, new English terminology is borrowed from existing terms in another language: often Greek & Latin, but sometimes more current languages like French, German, Yiddish, Arabic, Japanese, etc. As a general rule, science fiction is not usually seen as a rich source of new names, and the Ogg fiasco is a perfect demonstration of why that would be the case.
I can't say "ogg" without feeling dirty. I already have a hard time typing it and will probably be giving my keyboard a nice bath to purge if of my sins. If you'll excuse me...
Maybe so, I can't say. But from the way I understand the design of the system, getting Perl6 to run on Parrot is "only" going to be a matter of writing an interface wrapper to bootstrap it. They have a reasonable idea of what the basic functionality needs to be, so Parrot has been written to meet those needs -- and the needs of other languages (esp. Python) as well. [1]
From what I understand, the Parrot group wanted to wait for a reasonably complete Perl6 before they started, but when it became obvious that this was going to take a while, they decided to just get started. Surprisingly, work ended up happening very fast, and we've ended up in the strange but possibly useful situation of having a roughly complete Parrot engine available today, two or three years after development started, even though the Perl6 design is still evolving.
This isn't necessarily a bad thing though. No one wants to throw out the expertise that thousands of people have built up in learning Perl5, so even when Perl6 is available, Perl5 is still going to be around -- if only to run the huge number of Perl5 scripts that will never be rewritten for the new version of the language.
With that in mind, one of the design criteria for the Perl6 project is robust Perl5 support, and with Parrot at the level it's at now, it should be possible to write a Perl5 interface to the VM without waiting for Perl6 to be finished. Because the design of Parrot is so much cleaner -- and faster -- than Perl5's current internals, this might actually speed up existing code, and could even make the painful process of developing with XS a thing of the past. It could be a benefit to Perl5 in the near future separate & apart from Perl6's progress, if & when this interface comes to fruition (which, according to the last plans I took a look at, it definitely will).
So yeah, this is probably the reverse of how things "should" have been developed, but there are some positive things about the current situation... *shrug*
******
[1] Python needs support for certain things -- I think co-routines was the example Dan Sugalski used in his talk -- that Perl doesn't currently care about, so they've gone in to Parrot. If anyone wanted to expose this functionality to Perl, it would be easy enough to do so, and sooner or later someone probably will.
Nah, Parrot isn't the bottleneck. Parrot development has actually moved pretty fast: they quickly came up with a raw-functionality virtual machine, and at this point the Parrot engine seems to meet the basic runtime needs of Perl5, Perl6 [as specced out to date], Python, and PHP.
Parrot isn't done yet to be sure, but it's already complete enough that, for example, the employer of one of Parrot's main developers is already using Parrot as the runtime engine for their corporate software. [I'd get in to details, but I forget the details -- Dan Sugalski talked about it for the Boston Perl Mongers a month or two ago.] Likewise, there's already a mod_parrot Apache module under development that will allow Parrot targeted code to run, and run very quickly, while embedded in the web server. Longer term, one of the target languages for Parrot is Z-code, so that Parrot will be able to run old text games like Zork and Hitchhiker's Guide To The Galaxy -- with luck, this could lead to Parrot being the embedded virtual machine for portable game machines.
Parrot is, in other words, being actively developed, and there are big plans for it.
Parrot is hardly holding Perl6 back.
The bottleneck with Perl6 seems like the actual design work. Once Larry Wall puts out one of his Apocalypses, it never seems to be long before Damian Conway comes out with an explanation, including working code that can often be experimented with today under Perl5, with his Exegeses. There seems to be a ready pool of people eager to implement this stuff as it becomes available, it's just that the project is so *big* that it's taking a while for people to get anywhere with it in their spare time.
Please have Cheney be the pilot...
Please have Cheney be the pilot...
Please have Cheney be the pilot...
Yeah, but think about that for a minute. This is a physics article -- don't you remember the old F = MA formula? If we assume that a bullet flies at roughly the same speed that an arrow does, then the main determinant of force is the mass of the projectile.
Bullets are tiny -- even a big one from an assault rifle probably weighs no more than an ounce or so. Arrows, on the other hand, are comparitively heavy -- maybe half a pound or a pound for a big compound bow's hunter's arrow or a crossbow bolt.
Therefore, if the projectiles are going at the same speed when they hit their target, an arrow is going to hit that target with perhaps ten times more force than the bullet would.
Plus -- and I have no idea how to quantify this, but I'm sure it only amplifies things -- bullets tend to have blunt tips (only moderately sharp for assault rifles), but arrowheads can be razor sharp. I'm sure that only widens the gap between bullets and arrows.
Arrows are a much bigger threat to typical body armor than bullets. Weird, eh?
Q: How is Budweiser like sex in a canoe?
A: They're both fucking close to water.
The US federal government has three branches, which I suppose fits with what I said, but I meant leadership by three individuals.
Three groups isn't so bad necessarily -- tripods can be nice & stable, and from a certain point of view, the US government is just shaped like a big tripod. (OTOH, having all three legs run by one party isn't such a hot idea, but that's a different matter...)