Er, isn't the whole point of context menus that they're kinda, you know, contextual in their function?
There are two responses to this.
The browser is the context. Sure, when you intentionally right click on an image, you want to do something with the image. But much more often, you want to do something with the page or the browser, and unless you're very careful, there's a good chance you'll right click on an image or a link or a selection or a frame without even realizing it.
Even if showing the back button does break the context menu model, it is worth it. Back is the second most common browser function, after clicking on a link. There ought to be some fast way to do it with the mouse. The context menu is much faster than going to the back button--but only if the back entry is presented consistently.
break my heart? Frankly, it bolstered my belief that the world will
punish crooks and fools. Sure, you say, hindsight, etc. Well, let's look
closer, and you can decide whether my criticism is revisionist.
The legal profession had not worked out for him.
Ok, a failed lawyer, starting a Linux game company. Sounds suspiciously
like an opportunist with no relevant experience and dollar signs in his
eyes. Did he at least have some technical background? Experience in the
(brutal) gaming industry? Familiarity with Linux? You'd think the article
would have mentioned it (working at Apple does not imply a technical
background).
a possible -- no, sure -- winner.
If anyone ever gives you this vibe, get out, quick. The best of plans, in
the best of circumstances, executed by the best of people is a long way from
a sure thing in the free market. Optimism and confidence are good, but
counting on success--even just in your heart--before it's in the bank is
always a mistake. This lesson, it seems, will be learned over and over
until the end of time.
Scott Draker continued to collect unemployment.
You're only supposed to get unemployment benefits if you're looking for
work. So Draker was dishonest from the start.
During 1999,... venture capital was beginning to dry up.
My company was financed in 1999, so I recall distinctly that the boom was in
full swing the whole year. (Hint: when did VA Linux IPO?) If they couldn't
find funding in 1999, something was very wrong.
I'm going to stop, because the later signs are too obvious, and because if
the signs were all there at the height of the bubble--well that's just
pathetic.
Reading this, I couldn't help being reminded of the movie startup.com.
Somehow, you were supposed to feel sorry for these losers, even though they
aspired to nothing more noble than easy riches, and pursued them with
laughably poor judgement. I can't fairly blame them for dipping into the
overflowing VC pool, but I certainly didn't cry for their failure.
Maybe my standards for entrepreneurs are too high. Maybe it's because I've
been with a tech start-up that I was and am proud of (founded in 1998, and
still going, thank you).
The pine source is in... a source package! That's right, the source is in the (non-free) archive, just no binary packages. Unfortunately, this means you can't install it in the standard way (yet), but you shouldn't have much trouble with
apt-get build-dep pine
apt-get source --compile pine
dpkg --install *.deb
There's also a pine-tracker package, which apparently reminds you to upgrade when appropriate. I hope the standard tools make this unnecessary some day.
Redirection isn't a problem either; to redirect the stream you'd have to observe it, and by observing it you will change it, and make it impossible to view the messages.
I mean interception, not man-in-the-middle. I cut your fiber and read your photons, without trying to pass them on to the intended recipient. Then, when you try to contact the recipient over some "conventional" channel for phase two (comparing the polarities on the two ends), I intercept that, and we discuss the polarities I intercepted. You require that my messages be signed by the intended recipient, of course, but I've broken RSA, so no problem. Then, you send the message xor'ed with the random bits, and I intercept that. I've stolen the message, and you're none the wiser.
I've heard it said that, if QC proves practical, the code-makers will have a final victory over the code-breakers. This seems true at first: there is absolutely no way, in theory, for anyone but the recipient to receive the message.
But how do you know who the recipient is? QC offers no authentication. If you have to use public key for authentication, what advantage is gained by using superior methods for confidentiality?
The only one I can think of is that, with conventional cryptography, you can capture the data stream and crack it "off-line". I suppose that this is significant: with QC you only have to worry about whether they've cracked your private key (that you will use for authentication) already, not whether they can in 100 years (because you've used it for encryption).
Another argument might be that it is easier to eavesdrop on a channel than to redirect it. But that seems like a dubious assumption, if the enemy is determined.
But [in contrast to music] software-- and more importantly innovation in software-- is a really important thing.
Woah--you're on really thin ice there, comparing the value of artistic and software innovation. Technology is nice, but I'm damn glad that when I turn on the radio, I don't hear grunts and stone pounding on every station.
The other critical thing to be aware of is that, compared to, say, your text
editor, these CMS's are not mature products. They're bulky, slow,
confusing, buggy, hard to install and administer. They're full of rushed,
ill-conceived features. They usually have twisted histories that zigged and
zagged based on major customer needs, stategy changes, marketing and
technology fads, and bolt-on integration of acquired or licensed
products--and it shows in a big way. (Welcome to the world of enterprise
software!)
When they say "easy to install", they mean it takes one consultant one
day--and that's probably for a minimal install that won't do anything
useful! When they say "easy to use", they mean that after you have done the
install and some initial integration work, and if you have a capable
administrator keeping an eye on things, then the business user will be able
to get his work done.
Be assured: There will be days when these systems drive you insane. On the
bright side: After you've made them work, you can become a highly-paid CMS
consultant!
You absolutely have to understand that "content management" is a buzzword.
That doesn't mean that these packages aren't useful; it just means that you
have to look very closely at what they do in order to make a rational
selection.
The best definition I can come up with is that a CMS is anything that
offers, in some form, with a reasonable level of integration, several of:
content (especially file and data record) control (revision control, access
control, triggers, backup), content entry, searching, workflow, templating,
deployment, delivery (including personalization), and commerce support.
Each of these is a category (perhaps a buzzword) in itself, and you'll have
to research what they are and how useful they are to you. While all the
vendors will say their products do it all (or--the next version will do it
all!), each is stronger in some of these areas, weaker in others. They also
vary greatly in the amount of out-of-box functionality, versus how much you
need to build, and they differ in ease of extension.
Frankly, it's really hard to make a good decision about these products
without putting a lot of time into evaluating them against your needs.
If you don't have a good idea of what you want from a system, you'll
probably end up buying a lot that never gets used (happens all the time!), and missing out on a lot
that could have been useful. So I'd work at defining your needs (talk to
everyone who will use the system to see what they think a CMS does), then
ask specific questions of the vendors, and try to demo the systems before
making a decision.
Also, learn the lingo. You actually can get information out of the
marketing material, once you learn the code.
Don't any of you bozos pay attention to prior articles? Security is about risk management.
What do you see in the post that is inconsistent with this view? It claims that the cost of breaking 1024 bit keys is lower than previously believed. This means that risks must be reassessed.
If you have something to protect that is worth $1bn for someone to steal and the only protection you have on it is 1024-bit crypto, you deserve to have it stolen.
Guarding a $1B asset with a 1024 bit key would be foolish, with or without this finding. (For starters, the enemy doesn't necessarily have to build a cracker, they just have to rent time on one.) But who says we were talking about a $1B asset? Trivially, there exists some scenario in which 1024 bits was a good risk prior to this finding, but is no longer. So this finding is entirely relevant to a risk management approach.
I wish Google would somehow formalize the search for domain names
It's an interesting idea, but it can't work. At least, that's my conclusion.
Obviously, you can (and many do) already use google in preference to URL's by your own choice. But you are probably thinking of a system by which companies, etc can advertise a google URL, eg google://myco (and thus stop suing "little guys" over domain names). This URL would direct the browser to google "myco" and jump to the first hit.
Now, imagine a company considering using google URLs's.:
myco: So if people type
google://myco, they'll get to my web site, even if we don't own myco.com?
google: Sure, as long as myco is the top rated hit for that keyword.
myco: And the ratings are determined how?
google: By scanning random web pages and running them through our proprietary algorithms.
*click*
The alternative, of course, is that google can promise myco the top slot (for a price). But then google is effectively jut an alternate registrar, with even less accountability.
It doesn't. Read again. But, yeah, you could trigger this off of whatever you use to switch interfaces (ie, PCMCIA scripts).
broadcast ping the subnet you're on now, and the one you just left. That's enough for more hardware out there to get it's head out of its ass and recognize your host
My experience is that hardware can be pretty stubborn, but I'll try it. Thanks for the idea.
I do part of this (hopping between wired and wireless) now with ordinary
hardware and software, although a few bits are missing. The key piece is
proxy ARP, a nifty trick I had never heard of until I tried to solve this
problem.
The basic idea is to set up a gateway on both the wired and wireless
networks, and proxies ARPs on both networks, so that hosts on the different
network see each other as if they were on the same LAN. This is a little
like bridging--except that only a tiny bit of traffic (the ARP's) needs to
"bridge" the two networks. The rest is taken care of by normal routing.
The trick is switching a host from wired to wireless without changing its IP
addresses (so it doesn't drop any connections). Note this implies that the
gateway's routing table has a host route (specifying the interface) to every
address that is allowed to switch networks: you can't tell from the address
which side its on, so the usual subnet mask routing won't work.
Pulling off the switch requires that the gateway be able to detect the
switch, and then do two things: One, change its routing table, so that
traffic for the address goes out on the right interface. Two, send
"gratuitous ARPs" to other hosts, forcing them to update their ARP tables
(since, if the host moved to the other network, traffic to it now needs to
be routed through the gateway).
I think the most straightforward way to detect the switch is to have the
gateway run a DHCP server, and have the mobile hosts renegotiate a lease
when they switch networks. Then, add a hook to the DHCP server to do the
magic whenever it notices a host renegotiate on a different network. For
the mobile hosts to be identifyable across networks, they need to send the
same client-identifier on both networks. Since the default
client-identifier is usually the MAC address, this requires configuration on
the clients (I edit/etc/dhclient.conf and pick one MAC address to use as
the client-identifier). Of course, the DHCP server needs to be configured
to give out the same address range on both interfaces.
Unfortunately, on the network I care about, my gateway is not the DHCP
server. Instead, I run a DHCP relay. This mostly works--except the ISC
DHCP relay doesn't have any hooks, and I haven't hacked it to add them. But
it should be easy.
Another way to solve this might be for the gateway simply to monitor ARPs
and do something when it notices a host switch networks. I haven't found a
clean way to do this, and I think it might be less than perfect, because the
host wouldn't get switched until it initiated an ARP transaction.
The last problem is that different systems seem to respond differently to
gratuitous ARPs. For example, Linux systems don't seem to require them at
all, because they (apparently) issue a new ARP pretty quickly after the old
MAC address stops answering. But I can't get Solaris systems to listen to
gratuitious ARPs at all, and they don't time out for minutes.
Also, gratuitiously ARPing the whole network is ugly. Ideally, we would
would only send an ARP when we notice another host using a MAC that we know
has moved to the other network. I have no idea how to do this.
Despite all the glitches, it's quite fun to switch to the wireless for
mobility and back to the ethernet for speed, without losing my ssh
connections. Improvements on this setup would be welcome!
First, I want to support the per-page pricing, in principle. It's just more
fair, and it might even convince some of us to do some work instead of
reloading slashdot! Read an economics text about externalities and
overconsumption if you're dense.
However, slashdot should be forthright about how the page views will be
accounted. Is it a simple HTML page load, or something more complicated?
What about requests for RDF? HEAD requests? Requests without images? Are
there any other special cases? Also, slashdot should give non-subscribers a
way to count their page views, so they can tell how expensive a subscription
would be, based on their viewing habits.
Finally--every slashdot reader who subscribes should learn their browser's
caching behavior--and maybe swith browsers! Does your back button reload
slashdot (watching the "generated by a team of purple midgets" text is a
quick way to check)? If so, you'll probably be throwing away your (half-)
pennies on worthless reloads (unless you use such kluges as tabs and new windows).
Non-ancient mozillas prior to 0.9.8 would reload (as a result of bug 112564).
I think (secondhand information) that IE does and Opera doesn't.
DJB is supposing that as the problem gets larger he is increasing the number of FPUs at the same rate as the amount of memory.
Ok, I read as much as I could of the paper now (was slashdotted). I understand the simple examples: The idea is that, if your memory grows as N, then you can grow your number of processors as N "for free". But a factor of N, or any polynomial, doesn't help you with problems of exponential complexity, right? (I assume the memory required grows polynomially in these algorithms. Am I wrong?) So there much be some other trick I didn't grasp.
The "decreased cost" is misleading here, since it is calculated on the assumption that sieving would have been done by a single processor with access to a huge memory... this quite simply was never the case.
There is nothing here to suggest that factoring can be performed using any fewer FLOPS; all that is demonstrated is that by using several processors, each with a smaller memory, you can do better than with a single processor and a giant memory. Which we already knew.
Hold on. A parallel implementation would normally just give an N times speedup. But the Berstein method (reportedly) does much better than that: it reduces the base of the exponential complexity by about a third (in the asymptotic case). This is far more significant than "merely" parallelizing the algorithm.
Products' SQL support is pathetic
on
SQL Validator
·
· Score: 3, Insightful
The common SQL DMBS implementations have truly abysmal standards support.
They're really not even close. Oracle doesn't support the standard outer
join syntax (and doesn't support full outer joins at all). It gets confused
between the empty string and NULL. MS SQL Server doesn't support the
standard concatenation operator (using '+' instead of '||'). PostgreSQL
honors non-standard escape characters in string literals. And those are
basic language elements--forget about anything interesting like domains and
system tables. Basically, if you pick a random feature from the standard,
you're likely to find missing or broken support in many or most
implementations. (In my experience, Oracle is the worst, and PostgreSQL is
the best.)
I'm not going to get into why support is so bad (my glib answer: databases
suck). But I don't know of any other major standard that is so routinely
disregarded. It's been a fond hope of mine that PostgreSQL would commit to
standards support and (slowly) pull the rest of the industry along. But I
see no indication of that.
I program SQL with two books at my side: "SQL Instant Reference" (Gruber)
and "A Guide to the SQL Standard" (Date and Darwen). To me, they are lone voices of sanity! (It's
hard to find a book that covers SQL the standard, not some
implementation.) When I can't write a portable SQL statement because of
product infidelities, I add a workaround with a big comment full bile and
invectives. It's good for the soul.:-)
I hope this project helps build some momentum for SQL standards support. I'm
not doing an SQL projects right now, but when I do, I'll definitely support
this effort.
Oh but you can argue that the data in it's storage banks would be the same as the storage of your brain, and as such an integral part of the brain. After all you remember the movie too, just not so perfectly.
But the ability to recall (and copy) the movie perfectly (or near perfectly) is a big part of the issue. That's why the "entertainment" industry is making a bigger stink over MP3s and DVDs than over audio and video casettes.
If people could access perfect memories of songs in their brains and perform brain-to-brain transfers, then I would be worried about Valenti lobbying for lobotomies.
Slashdot Mirror
There are two responses to this.
Uh, has Nat actually used shampoo? If so, it's probably still in his hair....
Ok, a failed lawyer, starting a Linux game company. Sounds suspiciously like an opportunist with no relevant experience and dollar signs in his eyes. Did he at least have some technical background? Experience in the (brutal) gaming industry? Familiarity with Linux? You'd think the article would have mentioned it (working at Apple does not imply a technical background).
If anyone ever gives you this vibe, get out, quick. The best of plans, in the best of circumstances, executed by the best of people is a long way from a sure thing in the free market. Optimism and confidence are good, but counting on success--even just in your heart--before it's in the bank is always a mistake. This lesson, it seems, will be learned over and over until the end of time.
You're only supposed to get unemployment benefits if you're looking for work. So Draker was dishonest from the start.
My company was financed in 1999, so I recall distinctly that the boom was in full swing the whole year. (Hint: when did VA Linux IPO?) If they couldn't find funding in 1999, something was very wrong.
I'm going to stop, because the later signs are too obvious, and because if the signs were all there at the height of the bubble--well that's just pathetic.
Reading this, I couldn't help being reminded of the movie startup.com. Somehow, you were supposed to feel sorry for these losers, even though they aspired to nothing more noble than easy riches, and pursued them with laughably poor judgement. I can't fairly blame them for dipping into the overflowing VC pool, but I certainly didn't cry for their failure.
Maybe my standards for entrepreneurs are too high. Maybe it's because I've been with a tech start-up that I was and am proud of (founded in 1998, and still going, thank you).
It's in testing. Where is it missing?
apt-get build-dep pine
apt-get source --compile pine
dpkg --install *.deb
There's also a pine-tracker package, which apparently reminds you to upgrade when appropriate. I hope the standard tools make this unnecessary some day.
That can't be good for the drive.
Not to mention: It relies intimately on several other specifications starting with X. For example, XML Schema--which is considerably longer!
I mean interception, not man-in-the-middle. I cut your fiber and read your photons, without trying to pass them on to the intended recipient. Then, when you try to contact the recipient over some "conventional" channel for phase two (comparing the polarities on the two ends), I intercept that, and we discuss the polarities I intercepted. You require that my messages be signed by the intended recipient, of course, but I've broken RSA, so no problem. Then, you send the message xor'ed with the random bits, and I intercept that. I've stolen the message, and you're none the wiser.
Ugh... A story about a real cryptography breakthrough, followed up by PR for this snake oil. Timothy, you should have stopped while you were ahead. ;-)
But how do you know who the recipient is? QC offers no authentication. If you have to use public key for authentication, what advantage is gained by using superior methods for confidentiality?
The only one I can think of is that, with conventional cryptography, you can capture the data stream and crack it "off-line". I suppose that this is significant: with QC you only have to worry about whether they've cracked your private key (that you will use for authentication) already, not whether they can in 100 years (because you've used it for encryption).
Another argument might be that it is easier to eavesdrop on a channel than to redirect it. But that seems like a dubious assumption, if the enemy is determined.
Thoughts?
Woah--you're on really thin ice there, comparing the value of artistic and software innovation. Technology is nice, but I'm damn glad that when I turn on the radio, I don't hear grunts and stone pounding on every station.
The other critical thing to be aware of is that, compared to, say, your text editor, these CMS's are not mature products. They're bulky, slow, confusing, buggy, hard to install and administer. They're full of rushed, ill-conceived features. They usually have twisted histories that zigged and zagged based on major customer needs, stategy changes, marketing and technology fads, and bolt-on integration of acquired or licensed products--and it shows in a big way. (Welcome to the world of enterprise software!)
When they say "easy to install", they mean it takes one consultant one day--and that's probably for a minimal install that won't do anything useful! When they say "easy to use", they mean that after you have done the install and some initial integration work, and if you have a capable administrator keeping an eye on things, then the business user will be able to get his work done.
Be assured: There will be days when these systems drive you insane. On the bright side: After you've made them work, you can become a highly-paid CMS consultant!
The best definition I can come up with is that a CMS is anything that offers, in some form, with a reasonable level of integration, several of: content (especially file and data record) control (revision control, access control, triggers, backup), content entry, searching, workflow, templating, deployment, delivery (including personalization), and commerce support. Each of these is a category (perhaps a buzzword) in itself, and you'll have to research what they are and how useful they are to you. While all the vendors will say their products do it all (or--the next version will do it all!), each is stronger in some of these areas, weaker in others. They also vary greatly in the amount of out-of-box functionality, versus how much you need to build, and they differ in ease of extension.
Frankly, it's really hard to make a good decision about these products without putting a lot of time into evaluating them against your needs. If you don't have a good idea of what you want from a system, you'll probably end up buying a lot that never gets used (happens all the time!), and missing out on a lot that could have been useful. So I'd work at defining your needs (talk to everyone who will use the system to see what they think a CMS does), then ask specific questions of the vendors, and try to demo the systems before making a decision.
Also, learn the lingo. You actually can get information out of the marketing material, once you learn the code.
Good luck.
What do you see in the post that is inconsistent with this view? It claims that the cost of breaking 1024 bit keys is lower than previously believed. This means that risks must be reassessed.
If you have something to protect that is worth $1bn for someone to steal and the only protection you have on it is 1024-bit crypto, you deserve to have it stolen.
Guarding a $1B asset with a 1024 bit key would be foolish, with or without this finding. (For starters, the enemy doesn't necessarily have to build a cracker, they just have to rent time on one.) But who says we were talking about a $1B asset? Trivially, there exists some scenario in which 1024 bits was a good risk prior to this finding, but is no longer. So this finding is entirely relevant to a risk management approach.
It's an interesting idea, but it can't work. At least, that's my conclusion.
Obviously, you can (and many do) already use google in preference to URL's by your own choice. But you are probably thinking of a system by which companies, etc can advertise a google URL, eg google://myco (and thus stop suing "little guys" over domain names). This URL would direct the browser to google "myco" and jump to the first hit.
Now, imagine a company considering using google URLs's.:
The alternative, of course, is that google can promise myco the top slot (for a price). But then google is effectively jut an alternate registrar, with even less accountability.
Yet another story without enough background info. What the heck is Dutch*BSD?
It doesn't. Read again. But, yeah, you could trigger this off of whatever you use to switch interfaces (ie, PCMCIA scripts).
broadcast ping the subnet you're on now, and the one you just left. That's enough for more hardware out there to get it's head out of its ass and recognize your host
My experience is that hardware can be pretty stubborn, but I'll try it. Thanks for the idea.
The basic idea is to set up a gateway on both the wired and wireless networks, and proxies ARPs on both networks, so that hosts on the different network see each other as if they were on the same LAN. This is a little like bridging--except that only a tiny bit of traffic (the ARP's) needs to "bridge" the two networks. The rest is taken care of by normal routing.
The trick is switching a host from wired to wireless without changing its IP addresses (so it doesn't drop any connections). Note this implies that the gateway's routing table has a host route (specifying the interface) to every address that is allowed to switch networks: you can't tell from the address which side its on, so the usual subnet mask routing won't work.
Pulling off the switch requires that the gateway be able to detect the switch, and then do two things: One, change its routing table, so that traffic for the address goes out on the right interface. Two, send "gratuitous ARPs" to other hosts, forcing them to update their ARP tables (since, if the host moved to the other network, traffic to it now needs to be routed through the gateway).
I think the most straightforward way to detect the switch is to have the gateway run a DHCP server, and have the mobile hosts renegotiate a lease when they switch networks. Then, add a hook to the DHCP server to do the magic whenever it notices a host renegotiate on a different network. For the mobile hosts to be identifyable across networks, they need to send the same client-identifier on both networks. Since the default client-identifier is usually the MAC address, this requires configuration on the clients (I edit /etc/dhclient.conf and pick one MAC address to use as
the client-identifier). Of course, the DHCP server needs to be configured
to give out the same address range on both interfaces.
Unfortunately, on the network I care about, my gateway is not the DHCP server. Instead, I run a DHCP relay. This mostly works--except the ISC DHCP relay doesn't have any hooks, and I haven't hacked it to add them. But it should be easy.
Another way to solve this might be for the gateway simply to monitor ARPs and do something when it notices a host switch networks. I haven't found a clean way to do this, and I think it might be less than perfect, because the host wouldn't get switched until it initiated an ARP transaction.
The last problem is that different systems seem to respond differently to gratuitous ARPs. For example, Linux systems don't seem to require them at all, because they (apparently) issue a new ARP pretty quickly after the old MAC address stops answering. But I can't get Solaris systems to listen to gratuitious ARPs at all, and they don't time out for minutes.
Also, gratuitiously ARPing the whole network is ugly. Ideally, we would would only send an ARP when we notice another host using a MAC that we know has moved to the other network. I have no idea how to do this.
Despite all the glitches, it's quite fun to switch to the wireless for mobility and back to the ethernet for speed, without losing my ssh connections. Improvements on this setup would be welcome!
However, slashdot should be forthright about how the page views will be accounted. Is it a simple HTML page load, or something more complicated? What about requests for RDF? HEAD requests? Requests without images? Are there any other special cases? Also, slashdot should give non-subscribers a way to count their page views, so they can tell how expensive a subscription would be, based on their viewing habits.
Finally--every slashdot reader who subscribes should learn their browser's caching behavior--and maybe swith browsers! Does your back button reload slashdot (watching the "generated by a team of purple midgets" text is a quick way to check)? If so, you'll probably be throwing away your (half-) pennies on worthless reloads (unless you use such kluges as tabs and new windows).
Non-ancient mozillas prior to 0.9.8 would reload (as a result of bug 112564). I think (secondhand information) that IE does and Opera doesn't.
Thanks. Now that I get the basic idea, you're right that it's not so exceptional (though neat).
Ok, I read as much as I could of the paper now (was slashdotted). I understand the simple examples: The idea is that, if your memory grows as N, then you can grow your number of processors as N "for free". But a factor of N, or any polynomial, doesn't help you with problems of exponential complexity, right? (I assume the memory required grows polynomially in these algorithms. Am I wrong?) So there much be some other trick I didn't grasp.
There is nothing here to suggest that factoring can be performed using any fewer FLOPS; all that is demonstrated is that by using several processors, each with a smaller memory, you can do better than with a single processor and a giant memory. Which we already knew.
Hold on. A parallel implementation would normally just give an N times speedup. But the Berstein method (reportedly) does much better than that: it reduces the base of the exponential complexity by about a third (in the asymptotic case). This is far more significant than "merely" parallelizing the algorithm.
I'm not going to get into why support is so bad (my glib answer: databases suck). But I don't know of any other major standard that is so routinely disregarded. It's been a fond hope of mine that PostgreSQL would commit to standards support and (slowly) pull the rest of the industry along. But I see no indication of that.
I program SQL with two books at my side: "SQL Instant Reference" (Gruber) and "A Guide to the SQL Standard" (Date and Darwen). To me, they are lone voices of sanity! (It's hard to find a book that covers SQL the standard, not some implementation.) When I can't write a portable SQL statement because of product infidelities, I add a workaround with a big comment full bile and invectives. It's good for the soul. :-)
I hope this project helps build some momentum for SQL standards support. I'm not doing an SQL projects right now, but when I do, I'll definitely support this effort.
But the ability to recall (and copy) the movie perfectly (or near perfectly) is a big part of the issue. That's why the "entertainment" industry is making a bigger stink over MP3s and DVDs than over audio and video casettes.
If people could access perfect memories of songs in their brains and perform brain-to-brain transfers, then I would be worried about Valenti lobbying for lobotomies.