Googling around, there's at least one succesful surgical correction of astigmatism from 1895 (Dr. Faber).
The Japanese doctor is Sato.
And LASIK was FDA approved in 1999. And PRK had pre-market approval in the early 90s but never got full approval.
Dr. Joachim Barraquer of Colombia originally developed the lamellar technique in the 60s and 70s, and it was greatly refined in the 1980s by (Colombian) Dr. Luis Ruiz. The technique essentially became the modern LASIK technique.
I had the by-hand RK about 10 years ago...certainly that would've been doable decades ago if somebody had thought of it
[Ugh, by-hand RK was obsolete 15 years ago (by the late 1980s/early 1990s PRK had replaced it).]
My dad's an opthalmologist.
It was done widely decades ago. Hell, even Consumer Reports was running articles comparing RK and PRK more than 10 years ago.
And even longer ago, someone had thought of it. Herman Snellen proposed it in the 1860s. (he's the same guy who invented the modern eye chart). It was tried off and on for a while, but with no measurable success until the 1930s.
A Japanese doctor (Sano or Sato?) performed RK on dozens if not hundreds of patients in the 1930s and 1940s to successfully correct myopia, but there were long-term problems with corneal degeneration--the incisions went through both the anterior and posterior cornea, and corneal clouding eventually resulted in many cases.
But by the 1960s, lamellar surgery (more similar in method to modern LASIK) had come into vogue as the preferred method of surgical vision correction. The technique was developed in Colombia, but spread elsewhere.
Then in the 1970s Russian scientists (Fyodorov and his compatriots) determined that RK could be effective even if limited to the anterior cornea, making it safer than the earlier methods and greatly reducing the corneal clouding issues. They also limited the number of incisions and increased the control, making it subtantially more likely to succeed than the earlier methods.
The focus for real-world surgery switched from lamellar to RK.
It still wasn't super-high percentage, so photoreactive RK (PRK) using a laser followed in the 1980s, followed by a return to lamellar surgery using a laser (LASIK) in the early 1990s.
I think LASIK is the only one to have ever had FDA approval, and that was pretty recent (c. 2000).
If you're coding for hard realtime embedded apps, you shouldn't malloc. Predefine buffers or design the algorithm so it doesn't use heap.
Not disagreeing, just clarifying:
It's perfectly reasonable to use malloc at application startup (e.g. to create those buffers). You need to make sure you actually allocate that memory (many malloc implementations are lazy and only allocate the VM space at malloc time, but you need to touch it to actually get the pages allocated), and you should lock it in memory (along with every page you use--see, e.g., mlockall).
And, of course, you need a hard-realtime scheduler (rtlinux, QNX, etc--there are ongoing efforts to bring hard rt responses to regular Linux, but it's not nearly there yet, nor are any other major consumer OSes).
OS X should be faster than OS 9, then, even with the "Microkernel overhead", because of the improved multitasking and disk I/O
Uhh, no. The "improved multitasking" refers only to security and APIs. Mach's multitasking _performance_ still blows. Mach isn't just a microkernel, it's a particularly bloated and slow one (compared to, say, QNX or l4).
I mean, you can look at comparisons of server apps this that don't use the screen to see that it's not just the graphics that are slowing things down.
Except that they used Apache 1.3 and MySQL, two of the worst possible choices. If they'd gone for Apache 2.x (which actually uses threading, instead of processes) and PostgreSQL, things would've looked much nicer
Please no. Multithreaded Apache is only appropriate for specialized applications that know they want to throw away protected memory. Otherwise, it's basically a hack to allow running on Windows (where multiprocess performance is abysmal).
OS designers spent years getting us protected memory. Hell, as a Mac user you should be even more familiar with the woes of non-protected systems. Sane OSes let you make the threads vs. process decision CORRECTLY, based on whether you want to share all your memory or not. They don't force you to give up safety to get halfway reasonable performance.
Besides, many applications cannot easily be ported to the multithreaded model. So providing the multiprocess benchmarks is key.
(And yes, for the record, I run Apache 2.x in multiprocess mode)
I realize most people that use Linux probably download updates and new pieces of software from the internet (an extension of a "network" right?) - is that what you do?
Have you installed any software since 1990? What do you use to do a fresh install of your OS? What do you do when you build a new computer?
True, if I were to do a from-scratch OS install, I'd probably use CDs for that.
I haven't touched removable media for a software install since 1993--there's this newfangled thing called a "network" that you might want to look into.
The point of DVDROM is that they are basically as fast as CDROM (the difference between 48x and 52x is nothing). The price difference is $11
So I can either: 1. Get a DVDROM drive; or 2. Get a CDROM drive and a couple of pints.
I'll take 2.
It's only a couple of hours wage, but you wouldn't go flush $11 down the toilet, would you?
And really, for me, the _only_ thing I could see using DVD reading for is playing videos, similar to how music CDs are the only reason for me to have a CDROM drive in the first place. I have absolutely no call for playing videos on my computer (not with 3 other DVD playback devices in the house), and if I need to transfer data I use TCP.
For other people, their needs vary and the $11 is worth it.
With the view that your backups don't need to last in mind, you can now select a backup strategy. Simplest solution is a second HDD for first level, either RAID or periodic sync with a USB/FW drive, and DVD-Rs second level
Amen. I just keep a second drive in each of my machines and rsync them every night or whenever the machine is more than 90% idle with the screensaver on for more than 10 minutes.
I think they have already. My last two monitors at home were LCD, as well as my work PC
Great. Now look at the overall market. There've been 3 quarters so far where LCDs outsold CRTs, most recently Q4 of 2004. But, e.g., in Q1 of 2005 CRTs outsold LCDs.
I'd say we're in a crossover point, and LCDs will probably take a clear lead in the next 2-3 years.
(I've never had an LCD monitor. Looking around my office, I see 6 CRTs and 2 LCDs--and the latter are both on the same desk.)
I just get tired of hearing these same criticisms of LCD's that we've heard for the last 10 years - "their colors suck", "they're not fast enough", "their black level is bad", "they're expensive". I mean, do you go around criticizing DVD-ROM drives because they cost more than CD-ROM drives and only read at 1X?
Is there any sane answer to that question other than "yes"? I've never had a DVD-ROM drive, and cost is exactly the reason. I have no need to read DVDs. It'd be moronical to pay extra for a feature I don't ever intend to use, _especially_ when it makes the one I do use worse (slower).
(on the LCD front, I haven't bought a monitor in years. When I do I'll take a look at the price and performance; the form factor is quite compelling, and I would certainly pay a bit extra for it if the performance is even in the ballpark of CRTs--which I suspect it is).
What is freedom other than the ability to act in a non-deterministic manner?
Well, if you can agree on definitions then the whole argument collapses on one obvious solution. Which one depends on the definitions that you agree on.
Suppose that I'm presented with a choice between vanilla and chocolate ice cream. Imagine the following 3 possibilities: 1. The universe is completely deterministic. Everything leading up to that point will cause me to pick vanilla. 2. The universe has is not deterministic. The total of the quantum randomnesses in the universe will lead me to pick vanilla 50% of the time and chocolate 50% of the time (or whatever percentages) 3. There's consciousness inside me but outside of physics that has preference, moral judgement, etc and will steer (either completely or probablistically) my judgement toward one choice or the other.
Choices in (3) are non-deterministic within the universe, but not simply random. Of course, whether or not (3) makes any sense depends on the details of the exact theory. But there is at least a good argument that "free will" doesn't traditionally mean making random choices, but actually means there is some consciousness that can act against the way the world is shoehorning it. Whether or not such a thing actually exists is another thread.
The Internet is a medium of communication for individuals and groups, organizations, and companies, people and assemblies of all kinds. As a medium of communication, putting ownership and control of access to it in the hands of government is a very very bad idea that relies on a false idea that the government can be trusted because it is the government which gives us rights and therefore will protect them on any service it provides.
That's true, but this doesn't put control of that communications medium in the government's hands.
Moreover, granting uniform access to communications is one of the most fundamental jobs of the US government. I mean, hell, there are only 18 things the US Congress is explicitly granted power over in the Constitution, and one of them is the establishment and maintenance of a postal system.
It's almost like ascribing a will to quantum components.
In fact, some modern philosophers (e.g. Roger Penrose, The Emperor's New Mind) have quantum randomness as a defense of free will. Although it may (as, e.g., Dennet) by more of a proof of random will.
That said, I would suppose that a "truly random" generator would involve, for instance, isotope degeneration--not that there is no reason that an isotope decays or not, but it is beyond our (current) understanding of quantum physics to predict it. But surely it must still be the effect of some cause, even if the cause is as yet imperceptible
Surely not. You're positing that the universe is deterministic, which seems like Einstein vainly trying to argue that "God does not play dice" with the universe.
The current belief is that it's not simply that we don't understand the laws of the universe well: the universe is not, in fact, deterministic and at a quantum level things do behave probablistically.
No./dev/urandom does something like that (modulo carefully tracking entropy, whitening with a strong cryptographic has, etc)./dev/random will block if it runs out of entropy, rather than return pseudorandom number generated with a random key.
You don't need to declare or predefine your variables. Rexx automatically allocates them when you first refer to them.
Gah! No-strong-typing is *NOT* a feature!
That excerpt has nothing to do with type strength (without additional information, you can't say whether Rexx is strongly typed or not). In fact, you're mixing up 3 concepts.
A strongly typed language is one that enforces type constraints rigourosly on all variable accesses. This can happen at runtime or compile time. A language that is not strongly typed is weakly typed, but it's really a continuum (C++ is more strongly typed than C, but isn't a very strongly typed language; Java and Python are more strongly typed, and ML stronger still. C is quite weakly typed, but traditional VB is arguably weaker, and ASM weaker still).
A statically typed language detects type violations at compile time. A dynamically typed language detects type violations at runtime. Again, this is a continuum. (e.g. C++ is mostly statically typed but has rtti; Python is completely dynamically typed, and ML is about as statically typed as it gets)
An explicitly typed language requires variable type declarations prior to use. Alternatives include implicit typing and inferred typing.
There are examples of languages that have incredibly strong, static typing yet do not require explicit type declarations. (ML is one example, and has a sophisticated type inference mechanism).
There are languages that are strongly, dynamically typed (e.g Python, Smalltalk).
And there are languages that are weakly typed, yet are statically typed and require explicit type declarations (e.g. C)
And, of course, there are languages that are strongly, statically typed with explicit typing (the so-called Bondage & Discipline languages, like Ada and Java) and languages that are weakly, dynamically typed with implicit typing (the confusing, bad scripting languages, like traditional VB).
But thinking that all strongly typed languages are statically typed and require explicit type declarations (like, say, Java) is fallacious.
Of the 3, strongly typing is the only one that is clearly "good" for a high-level language. Dynamic vs. static typing and explicit vs. implicit typing are at the very least "right tool for the job". There's a pretty solid argument that if you are going to be strongly, statically typed then allowing type inference (a la ML) is a much better idea that requiring explicit type declarations everywhere if you're interested in robost code and programmer productivity. It's much harder to write a good compiler for such a language, however...
He was never a friend of opensource and only in it for the $$$$.
No. Larry was involved with linux kernel development long before he ever started writing Bitkeeper.
If you go back through the linux-kernel archives, you'll find that almost every thread that he's involved in which doesn't mention Bitkeeper is a technical argument about a new feature or interface. Often something innovative--his splice(), for instance, which wasn't adopted whole cloth but drove the development of the no-copy linux-kernel interfaces.
Really, I wish we could have that Larry McVoy back. Because although he wasn't always right, he was usually interesting and often at least came up with a good vocabulary for the problem being discussed and cataloged the main issues well. And sometimes he came up with interesting solutions, too.
what, you've mapped all your "CTRL+", "CTRL+ALT+", "CTRL+ALT+SHIFT+", "CTRL+ALT+SHIFT+FN+" combinations already and need even more special keys?
I mean, I thought I had a lot of hotkeys, but I'm still trying to work my way through mapping all the ctrl+alt+shift+fn keys...
Lightweight.
Wake me up when you've exhausted the super, hyper, and meta keys as well. Then we can take a look at what combination of command, windows, altgr, open-apple, closed-apple, top, front, and application keys you have available.
Double bucky, you're the one, you make emacs lots of fun...
I think they're mistaken about the REASON you cant but pain... at least, here in California -- its becuase gangs use them for grafitti (sp?)...the only person it really stops from getting paint is kids who wanna spray paint their models and toys.
No, no, no, it _is_ because of the huffing! Huffing is a drug. And remember, drug money supports terror--if we don't stop children from buying spray paint, then the terrorists have already won!
Besides, you've got to think of the children! Won't someone please think of the children?
That's nice. It won't handle a multi-terabyte database, though. That's the domain of Terabase, Oracle, and (blech) DB2. It's also what the article is about.
Add postgres to that list, too.
Tough to find examples now. They used to ask people who had DBs over 1TB to post to the list, but they stopped several years ago because they had plenty of them.
I remember Datainfosys's spam rules DB is over 1TB, and the American Chemical Society's historical archives, and there was some genome mapping project. Really they had a couple examples a month, so it's not like there are only 5-10 dbs out there in postgres in these sizes.
Client-Side scripting has always been in JavaScript or languages that look exactly like JavaScript
Or Java.
And a few niche browsers had alternatives (e.g. http://grail.sourceforge.net/ allowed client-side Python scripts), but none of them ever got anything approaching critical mass.
Slashdot Mirror
Googling around, there's at least one succesful surgical correction of astigmatism from 1895 (Dr. Faber).
The Japanese doctor is Sato.
And LASIK was FDA approved in 1999. And PRK had pre-market approval in the early 90s but never got full approval.
Dr. Joachim Barraquer of Colombia originally developed the lamellar technique in the 60s and 70s, and it was greatly refined in the 1980s by (Colombian) Dr. Luis Ruiz. The technique essentially became the modern LASIK technique.
I had the by-hand RK about 10 years ago...certainly that would've been doable decades ago if somebody had thought of it
[Ugh, by-hand RK was obsolete 15 years ago (by the late 1980s/early 1990s PRK had replaced it).]
My dad's an opthalmologist.
It was done widely decades ago. Hell, even Consumer Reports was running articles comparing RK and PRK more than 10 years ago.
And even longer ago, someone had thought of it. Herman Snellen proposed it in the 1860s. (he's the same guy who invented the modern eye chart). It was tried off and on for a while, but with no measurable success until the 1930s.
A Japanese doctor (Sano or Sato?) performed RK on dozens if not hundreds of patients in the 1930s and 1940s to successfully correct myopia, but there were long-term problems with corneal degeneration--the incisions went through both the anterior and posterior cornea, and corneal clouding eventually resulted in many cases.
But by the 1960s, lamellar surgery (more similar in method to modern LASIK) had come into vogue as the preferred method of surgical vision correction. The technique was developed in Colombia, but spread elsewhere.
Then in the 1970s Russian scientists (Fyodorov and his compatriots) determined that RK could be effective even if limited to the anterior cornea, making it safer than the earlier methods and greatly reducing the corneal clouding issues. They also limited the number of incisions and increased the control, making it subtantially more likely to succeed than the earlier methods.
The focus for real-world surgery switched from lamellar to RK.
It still wasn't super-high percentage, so photoreactive RK (PRK) using a laser followed in the 1980s, followed by a return to lamellar surgery using a laser (LASIK) in the early 1990s.
I think LASIK is the only one to have ever had FDA approval, and that was pretty recent (c. 2000).
Not disagreeing, just clarifying:
It's perfectly reasonable to use malloc at application startup (e.g. to create those buffers). You need to make sure you actually allocate that memory (many malloc implementations are lazy and only allocate the VM space at malloc time, but you need to touch it to actually get the pages allocated), and you should lock it in memory (along with every page you use--see, e.g., mlockall).
And, of course, you need a hard-realtime scheduler (rtlinux, QNX, etc--there are ongoing efforts to bring hard rt responses to regular Linux, but it's not nearly there yet, nor are any other major consumer OSes).
OS X should be faster than OS 9, then, even with the "Microkernel overhead", because of the improved multitasking and disk I/O
Uhh, no. The "improved multitasking" refers only to security and APIs. Mach's multitasking _performance_ still blows. Mach isn't just a microkernel, it's a particularly bloated and slow one (compared to, say, QNX or l4).
I mean, you can look at comparisons of server apps this that don't use the screen to see that it's not just the graphics that are slowing things down.
Except that they used Apache 1.3 and MySQL, two of the worst possible choices. If they'd gone for Apache 2.x (which actually uses threading, instead of processes) and PostgreSQL, things would've looked much nicer
Please no. Multithreaded Apache is only appropriate for specialized applications that know they want to throw away protected memory. Otherwise, it's basically a hack to allow running on Windows (where multiprocess performance is abysmal).
OS designers spent years getting us protected memory. Hell, as a Mac user you should be even more familiar with the woes of non-protected systems. Sane OSes let you make the threads vs. process decision CORRECTLY, based on whether you want to share all your memory or not. They don't force you to give up safety to get halfway reasonable performance.
Besides, many applications cannot easily be ported to the multithreaded model. So providing the multiprocess benchmarks is key.
(And yes, for the record, I run Apache 2.x in multiprocess mode)
I realize most people that use Linux probably download updates and new pieces of software from the internet (an extension of a "network" right?) - is that what you do?
Yes.
Have you installed any software since 1990? What do you use to do a fresh install of your OS? What do you do when you build a new computer?
True, if I were to do a from-scratch OS install, I'd probably use CDs for that.
I haven't touched removable media for a software install since 1993--there's this newfangled thing called a "network" that you might want to look into.
The point of DVDROM is that they are basically as fast as CDROM (the difference between 48x and 52x is nothing). The price difference is $11
So I can either:
1. Get a DVDROM drive; or
2. Get a CDROM drive and a couple of pints.
I'll take 2.
It's only a couple of hours wage, but you wouldn't go flush $11 down the toilet, would you?
And really, for me, the _only_ thing I could see using DVD reading for is playing videos, similar to how music CDs are the only reason for me to have a CDROM drive in the first place. I have absolutely no call for playing videos on my computer (not with 3 other DVD playback devices in the house), and if I need to transfer data I use TCP.
For other people, their needs vary and the $11 is worth it.
With the view that your backups don't need to last in mind, you can now select a backup strategy. Simplest solution is a second HDD for first level, either RAID or periodic sync with a USB/FW drive, and DVD-Rs second level
Amen. I just keep a second drive in each of my machines and rsync them every night or whenever the machine is more than 90% idle with the screensaver on for more than 10 minutes.
I think they have already. My last two monitors at home were LCD, as well as my work PC
Great. Now look at the overall market. There've been 3 quarters so far where LCDs outsold CRTs, most recently Q4 of 2004. But, e.g., in Q1 of 2005 CRTs outsold LCDs.
I'd say we're in a crossover point, and LCDs will probably take a clear lead in the next 2-3 years.
(I've never had an LCD monitor. Looking around my office, I see 6 CRTs and 2 LCDs--and the latter are both on the same desk.)
Of course, even my old 15" CRT (14.1" viewable) runs fine at 1600x1200, which that cheap 19 inch LCD won't (the more expensive ones will).
And yeah, it's worth running at that on a small screen for a lot of pure graphics applications.
I just get tired of hearing these same criticisms of LCD's that we've heard for the last 10 years - "their colors suck", "they're not fast enough", "their black level is bad", "they're expensive". I mean, do you go around criticizing DVD-ROM drives because they cost more than CD-ROM drives and only read at 1X?
Is there any sane answer to that question other than "yes"? I've never had a DVD-ROM drive, and cost is exactly the reason. I have no need to read DVDs. It'd be moronical to pay extra for a feature I don't ever intend to use, _especially_ when it makes the one I do use worse (slower).
(on the LCD front, I haven't bought a monitor in years. When I do I'll take a look at the price and performance; the form factor is quite compelling, and I would certainly pay a bit extra for it if the performance is even in the ballpark of CRTs--which I suspect it is).
What is freedom other than the ability to act in a non-deterministic manner?
Well, if you can agree on definitions then the whole argument collapses on one obvious solution. Which one depends on the definitions that you agree on.
Suppose that I'm presented with a choice between vanilla and chocolate ice cream. Imagine the following 3 possibilities:
1. The universe is completely deterministic. Everything leading up to that point will cause me to pick vanilla.
2. The universe has is not deterministic. The total of the quantum randomnesses in the universe will lead me to pick vanilla 50% of the time and chocolate 50% of the time (or whatever percentages)
3. There's consciousness inside me but outside of physics that has preference, moral judgement, etc and will steer (either completely or probablistically) my judgement toward one choice or the other.
Choices in (3) are non-deterministic within the universe, but not simply random. Of course, whether or not (3) makes any sense depends on the details of the exact theory. But there is at least a good argument that "free will" doesn't traditionally mean making random choices, but actually means there is some consciousness that can act against the way the world is shoehorning it. Whether or not such a thing actually exists is another thread.
The Internet is a medium of communication for individuals and groups, organizations, and companies, people and assemblies of all kinds. As a medium of communication, putting ownership and control of access to it in the hands of government is a very very bad idea that relies on a false idea that the government can be trusted because it is the government which gives us rights and therefore will protect them on any service it provides.
That's true, but this doesn't put control of that communications medium in the government's hands.
Moreover, granting uniform access to communications is one of the most fundamental jobs of the US government. I mean, hell, there are only 18 things the US Congress is explicitly granted power over in the Constitution, and one of them is the establishment and maintenance of a postal system.
It's almost like ascribing a will to quantum components.
In fact, some modern philosophers (e.g. Roger Penrose, The Emperor's New Mind) have quantum randomness as a defense of free will. Although it may (as, e.g., Dennet) by more of a proof of random will.
That said, I would suppose that a "truly random" generator would involve, for instance, isotope degeneration--not that there is no reason that an isotope decays or not, but it is beyond our (current) understanding of quantum physics to predict it. But surely it must still be the effect of some cause, even if the cause is as yet imperceptible
Surely not. You're positing that the universe is deterministic, which seems like Einstein vainly trying to argue that "God does not play dice" with the universe.
The current belief is that it's not simply that we don't understand the laws of the universe well: the universe is not, in fact, deterministic and at a quantum level things do behave probablistically.
No. /dev/urandom does something like that (modulo carefully tracking entropy, whitening with a strong cryptographic has, etc). /dev/random will block if it runs out of entropy, rather than return pseudorandom number generated with a random key.
That excerpt has nothing to do with type strength (without additional information, you can't say whether Rexx is strongly typed or not). In fact, you're mixing up 3 concepts.
A strongly typed language is one that enforces type constraints rigourosly on all variable accesses. This can happen at runtime or compile time. A language that is not strongly typed is weakly typed, but it's really a continuum (C++ is more strongly typed than C, but isn't a very strongly typed language; Java and Python are more strongly typed, and ML stronger still. C is quite weakly typed, but traditional VB is arguably weaker, and ASM weaker still).
A statically typed language detects type violations at compile time. A dynamically typed language detects type violations at runtime. Again, this is a continuum. (e.g. C++ is mostly statically typed but has rtti; Python is completely dynamically typed, and ML is about as statically typed as it gets)
An explicitly typed language requires variable type declarations prior to use. Alternatives include implicit typing and inferred typing.
There are examples of languages that have incredibly strong, static typing yet do not require explicit type declarations. (ML is one example, and has a sophisticated type inference mechanism).
There are languages that are strongly, dynamically typed (e.g Python, Smalltalk).
And there are languages that are weakly typed, yet are statically typed and require explicit type declarations (e.g. C)
And, of course, there are languages that are strongly, statically typed with explicit typing (the so-called Bondage & Discipline languages, like Ada and Java) and languages that are weakly, dynamically typed with implicit typing (the confusing, bad scripting languages, like traditional VB).
But thinking that all strongly typed languages are statically typed and require explicit type declarations (like, say, Java) is fallacious.
Of the 3, strongly typing is the only one that is clearly "good" for a high-level language. Dynamic vs. static typing and explicit vs. implicit typing are at the very least "right tool for the job". There's a pretty solid argument that if you are going to be strongly, statically typed then allowing type inference (a la ML) is a much better idea that requiring explicit type declarations everywhere if you're interested in robost code and programmer productivity. It's much harder to write a good compiler for such a language, however...
He was never a friend of opensource and only in it for the $$$$.
No. Larry was involved with linux kernel development long before he ever started writing Bitkeeper.
If you go back through the linux-kernel archives, you'll find that almost every thread that he's involved in which doesn't mention Bitkeeper is a technical argument about a new feature or interface. Often something innovative--his splice(), for instance, which wasn't adopted whole cloth but drove the development of the no-copy linux-kernel interfaces.
Really, I wish we could have that Larry McVoy back. Because although he wasn't always right, he was usually interesting and often at least came up with a good vocabulary for the problem being discussed and cataloged the main issues well. And sometimes he came up with interesting solutions, too.
By default winkey-Backspace brings up the calculator
;-) ;-
Hmm. Winkey-backspace for me just results in a semicolon followed by a hyphen.
Lightweight.
Wake me up when you've exhausted the super, hyper, and meta keys as well. Then we can take a look at what combination of command, windows, altgr, open-apple, closed-apple, top, front, and application keys you have available.
Double bucky, you're the one, you make emacs lots of fun...
No, no, no, it _is_ because of the huffing! Huffing is a drug. And remember, drug money supports terror--if we don't stop children from buying spray paint, then the terrorists have already won!
Besides, you've got to think of the children! Won't someone please think of the children?
Yes/yes and yes (all 3 have liveconnect support).
That's nice. It won't handle a multi-terabyte database, though. That's the domain of Terabase, Oracle, and (blech) DB2. It's also what the article is about.
Add postgres to that list, too.
Tough to find examples now. They used to ask people who had DBs over 1TB to post to the list, but they stopped several years ago because they had plenty of them.
I remember Datainfosys's spam rules DB is over 1TB, and the American Chemical Society's historical archives, and there was some genome mapping project. Really they had a couple examples a month, so it's not like there are only 5-10 dbs out there in postgres in these sizes.
Client-Side scripting has always been in JavaScript or languages that look exactly like JavaScript
Or Java.
And a few niche browsers had alternatives (e.g. http://grail.sourceforge.net/ allowed client-side Python scripts), but none of them ever got anything approaching critical mass.