Actually, I thought "top" was the verb, like "Star Trek spoof tops [beats] Finnish movie." This is why newspaper-style headlines are retarded and worthless. Is it really so much more difficult to write "Star Trek spoof is the top Finnish movie?" Or hell, this is Slashdot, we can probably assume most people know the name of the spoof: "In the Pirkinning is the top Finnish movie."
Although these micro-headlines do give us such gems as these, lifted from James Taranto:
"Black Faces Day in Chicago Court"--headline, Globe and Mail (Toronto), Nov. 22
"Door Thwarts Quick Exit for Bush"--headline, BBC Web site, Nov. 20
"Bird Flu Drug 'Safe' Despite Death Link"--headline, Daily Telegraph (Australia), Nov. 19 - "Gee, that's 'comforting'"
"Man Arrested for Stealing Car, Alluding Police"--headline, Jackson (Mich.) Citizen Patriot, Nov. 16 - "'Look Out for That Guy in the Uniform, if You Catch My Drift'"
"Superman Returns Trailer"--headline, IGN.com, Nov. 17 - "It's About Time That Mooch Gave It Back"
I RTFA hoping to get more details, specifically what parts Activa is claiming are libelous. The article just lists examples of complaints Lanteigne has, not which ones are at issue (unless I misread). I kind of think there must be something to this, because David-vs-Goliath cases always result in significant bad press for Goliath. I just can't see this working out well for them unless they can really prove Lanteigne is full of shit.
People will bring up the RIAA suing grandmothers, and rightly so. The difference, as I see it, is that the RIAA believes - rightly or wrongly - that they're losing millions and millions of dollars to piracy. Look at it that way and it makes sense that they're willing to trade some bad press for a lessened erosion of their bottom line. Nothing in the article led me to believe that Activa was being so seriously affected by this one little site.
I guess what I'm saying is there's just enough information to make me think something else is going on here, but not enough to know what.
It's feasible. Think of it like this. Clearly the computing labs aren't trusted, or you wouldn't have to authenticate and the schools wouldn't have to regulate or monitor your traffic. Students are trying to get to computers which are trusted, namely the proxy and other internal servers. So what do you usually use to go from an untrusted network to a trusted one? A VPN. It'll handle authentication and do encryption to boot. As an added bonus, it can be set up to allow connections from the wider Internet as well, so students can access class materials and such from home and not just the public labs.
It will require students to install VPN clients on their "mobile OSes," but I don't think that's an unreasonable demand to make.
It looks like the main problem with font quality at this point is the availability of good free (as in speech) fonts. GNOME, which comes with the Bitstream Vera fonts on FreeBSD, looked great out of the box with zero configuration. KDE, which does not, looked like ass. Until I told KDE to use Vera for everything, at which point it looked pretty good. (The antialiasing routines being used by GNOME seem better.) GNOME actually looked much better than Windows.
I suspect that if GNOME and KDE had, like Windows, five or six families of solid fonts that shipped with the DE, this would be a nonissue.
I'll go ahead and add my list of tools I find myself using all the time. Note that because I admin more than just Linux boxes, I only use tools which are likely to be present on every Unix variant.
find. It can be a handy ps replacement for boxes you think might be rooted (find/proc -name exe) in addition to all its other uses.
xargs. Everyone uses it with find, but it's also good with...
awk and/or cut. Need to reset quotas for 900 users? awk -F: '{if($3 >= 1000) print $1)} | xargs edquota -p protouser.
sh. If you need to run more than one command via xargs, you can use a while loop in sh. I actually prefer tcsh as my interactive shell because of its nifty history-completion feature, but it's weaker at scripting.
sort and uniq. They get one item because I almost never use them individually. Your webserver's getting DoSed and you want to know what IPs to firewall? netstat -an | awk '$4 ~/:80$/ {print $5}' | cut -d: -f1 | sort | uniq -c | sort -n.
grep -v. Yes, the -v is part of it: I almost never use regular grep for some reason. -v does the opposite of usual grep and excludes matching lines, which for me turns out to be much more useful.
telnet. Same reason as in TFA. I mainly use it as a quick way to see if relaying is actually disabled or not, or if a service is hung. (Running according to ps, listening according to netstat, accepting connections, but not doing anything.)
less. Mainly because some versions of more are worthless and won't allow you to scroll up, for example.
vi. You need an editor, and once you climb the sheer face of vi's learning cliff, this is good at it. I still can't stand to use vi for coding, but for writing and adjusting config files it's great. Also it's pretty much the only editor guaranteed to be in all of Solaris, HP-UX, IRIX, FreeBSD, and RedHat Linux, so it's not like I have much of a choice.
ssh. The all-purpose Swiss Army Chainsaw of networking. If you need to move data across a network, ssh can do it. It may be complicated, painful, and slow, but by God it can be done. ssh outer ssh border ssh inner tar czf - / | ssh storage 'cat >inner.tar.gz'.
There are other useful tools, but I pretty much use those on every single box I touch for any reason.
They won't all die, just the bad ones. Which is, frankly, fine by me. After ten years of reading nothing but The Wall Street Journal, The Boston Globe (sports section), and The New York Times, I can't stand anything else. The writing is just so abysmally poor that I throw the paper down in disgust ten seconds after picking it up.
Quality stuff will always survive in some form. I'm least worried about the WSJ, which is probably the smallest of the three papers I read. As you'd expect from a business-oriented newspaper, they got their business model straight from the get-go, and they've done very well with it - as of 2002, they were the most popular subscription service on the Internet.
- Obviously a happy subscriber to WSJ.com, but nothing more.
What does this mean exactly? When I want to edit a Word document I have to be online?
I think what it means is that, if you don't want to buy Office outright (for example), you can pay a small monthly or yearly fee and use it online. For home users, not a big deal, but for a business it could be really handy. No need for local installs, just a web browser. Built-in easy document sharing. The license costs would be split into monthly payments, so it's more affordable for smaller companies who live from month to month. And MS could probably reduce the license costs because they'd be able to ensure your compliance. Right now, if you buy 50 licenses of Office, you can install Office on 5000 computers. But with a web-based system, MS could limit you to a set number of concurrent users.
This would also let employees work from home or on the road without needing laptops, or with laptops but without keeping the document on there. ("We need those FY 2005 financial reports, but Bob has the latest version on his laptop and he's in Cancun for a week!")
I can see definite potential for this.
Couldn't an undergrad CS student develop an app that could do this for said small IT company.
There are already apps to do this. But none of them are really easy to set up or maintain. If something breaks, or you want to change the configuration, you have to hire someone to fix it (and wait for them to get around to it, during which time you may be losing business). But if you get your calendar app hosted and supported by the same company as the one doing your web and mail, which you'd have anyway...
I'm not saying it's a brilliant idea on the part of MS. Hosted Exchange would get you money hand over fist, because no one wants to pay the astronomical fees for an in-house Exchange admin. But the hardware requirements for Exchange are so high I'm not sure you'd actually be able to turn those huge revenues into profit.
You should be able to describe any useful innovation in a way that's interesting to a layman, even if he doesn't understand the details. Consider an oft-touted feature of the Linux kernel, O(1) scheduling. Only programmers and mathemeticians know what that actually means. But we can explain it in a way that makes sense to non-programmers so they can see the advantages, even though they probably still don't know what O(1) scheduling really is. Similarly, you can explain some insanely technical new MRI technology by saying "This makes detection of cancerous cells easier and more accurate," or an assembly-line innovation with "This allows us to cut our costs by 25% without sacrificing quality."
If you can't do that, then probably your innovation isn't really an innovation at all. It's an incremental improvement or a different, but not better or worse, way of doing the same thing we do now.
First, start with a full-featured interpreted language like Python, Perl, Ruby, or Scheme. Interpreted languages give you instant gratification that you won't get with Java or C. And because the languages I named all have big libraries, you can start writing some nontrivial programs with them too. As for which of these to choose, I would say Python, because I like it, but it's up to you. The Scheme syntax is cake to learn, but "the Scheme way" (actually the Lisp way) is unlike most popular languages so transitioning to something else would be harder. It's too easy to develop bad habits in Perl, especially if you don't know enough to have any idea what habits are good and what aren't. I've never used Ruby, so I have no idea how good it is. All four of these languages are full-featured, well-supported, and popular. None of them are toys: they are all used for serious work. So don't worry that you might be "wasting time" by learning one or more of them.
Next, once you get past the simple tutorials, try to think of a simple program you'd like to write. My personal favorite target for learning exercises is reimplementing well-known Unix programs, or parts of them at least. So I might design a version of "cut" that does some things I want it to, like treat contiguous whitespace as a single delimiter. But maybe you already have something in mind, like a simple web app. If so, you should tailor your choice of language to what you want to do. Like if you want to make a simple web app first, you probably want to use PHP. (Which I didn't recommend earlier because it's a little harder to debug.)
At this point you can hopefully write nontrivial programs - programs 100 lines or so long that mostly do what you want on the first few tries. Now you should learn Java. The main reason for this is that you will need to learn C, or at least a C-like language, at some point, but you don't want to get into the complex parts of C yet. Java will handle most of them for you. It's also a compiled language, so it adds an extra step to the process (code-compile-test instead of just code-test). This is probably where you ought to learn most of the intermediate programming concepts, like basic data structures and algorithms. What you may find helpful is going back and forth between Java and the language you started with. Sort of sketch out the app's framework and decide how you want to do something in e.g. Python, then rewrite it in Java. This will not only let you use the language you're most familiar with, it will give you a valuable understanding of how programming languages work.
Finally, move to C. C++ would be an easier transition since it's much more like Java than C is. But what you want to learn is memory management and all the other hard shit, and there's no way to escape it in C (there are lots of ways to escape it in C++). Plus, once you have a solid grasp of C and Java, you will almost by default know C++. Then you can learn the advanced features of C++ without having to worry about anything else.
Once you're at this point, you will be able to pick up the basics of any new language in a week or two. If you still want to learn and didn't start with Scheme, you should learn it now. It's a very different way of programming than you'll be used to, and it'll teach you even more about how languages work and how to be a good programmer.
I'm assuming you want to do as much of this as possible on your own. The first two steps - learning your first language and writing some simple programs in it - can be done with books and online tutorials. Past that, however, I would advise taking classes. You will know enough by then to have questions which might not be answered in a book, but which an instructor could answer easily - maybe before you even know to ask. Instructors will also be giving you assignments which are neither too easy nor too hard (hopefully), which is really hard to do on your own. You'll quickly find that you can read a book and understand every word in it, but not be able to write a program that says "Hello, world!" on your own. You need to be practicing this stuff constantly as you learn it or all the books in the world will be useless.
Don't get so worked up, I'm sure there's a way to change it. And it's perfectly consistent with the way many script interpreters work:
Python 2.4.1 (#2, Jul 17 2005, 18:17:13) [GCC 3.4.2 [FreeBSD] 20040728] on freebsd5 Type "help", "copyright", "credits" or "license" for more information. >>> "blah" 'blah' >>> 5 5
It's only when you don't assign the expression to a variable in interactive mode that Python will do this. I'm sure Monad works similarly.
Remember that Monad isn't supposed to be a functional replacement for bash. It's supposed to be more like Perl+CPAN. cmd.exe, weak as it is, is a "good enough" replacement for bash already.
Re:Can common/civil law override these licenses?
on
End User License Gems
·
· Score: 1
There must be a nuance of "statutory rights" that I'm not getting, unless you are just being offensively cynical in asking whether we have them. Maybe it's a good-faith question since our big rights are in our Constitution rather than legislation. Yes, we have statutory rights as well, and no, you can't waive those rights in a contract. Some of them you actually can, I think, but only because the law is written to allow it sometimes. For example, it's illegal to require employees to take polygraph tests. But there are exceptions, such as working on a government project for a private company (i.e. a defense contractor). I'm not a lawyer, but the sign outlining the circumstances is posted prominently - as required by law - in my workplace. Some other well-known statutory right bills are the Americans with Disabilities Act and the Equal Pay Act (on that same poster at work). This applies not only at the federal level, but also at the state level.
I do sort of wonder about the legal rationale for this. In the context of onerous EULAs, it certainly makes sense and is a good thing; but it seems to me that if I make a conscious choice, of my own free will (not under duress), to waive a particular right, I should be allowed to do so. Consider assisted suicide as an example. Normally if a physician were to give me a lethal drug knowing that it would end my life, he'd be guilty of murder. But it's my life, so can't I sign away my right to it and absolve him of any crime? It clearly makes pragmatic sense not to allow this since it can be so difficult to tell if I gave away my right under duress or not. Better to make mistakes we can later remedy than ones we can't... once I'm dead, that's it. But if it's my decision, and I'm using the doctor as a tool - rather than him using me - then why should the law even consider his role?
Perhaps it stems from the "life, liberty, and pursuit of happiness" bit. Congress isn't actually granting rights, it's acting almost like the SCOTUS and instead defining the legal parameters for the rights already given to us. God gives us our right to life, and only God can take it away. Because it doesn't come from us, nothing we can do can abrogate it. Congress is doing nothing more than clarifying the matter for more complex situations. (I used the word "God" here because it was pretty obviously the way the Founders believed. The origin of the rights is irrelevant so long as we agree that we have some sort of innate rights. If we don't agree, you're a utilitarian and probably stopped reading two paragraphs ago.)
No you don't. Use a filesystem which supports snapshots, like UFS2, and take a snapshot of the filesystem. Back up the snapshot. You will have a "broken" database backup, but since PostgreSQL does logging and all sorts of other ACID-ish things, it can recover from that just fine. You'll just lose whatever transactions were pending at the time the snapshot was taken. Par for the course: you'd lose them doing pg_dump too.
It amazes me every time I go to the states how no signature or pin is required to buy goods on a credit card. Self-service gas stations are good example. This is single-factor authentication. RFID or magnetic strip, doesn't make a difference.
Most places have a guideline about what the total cost of the purchase can be before they want additional authentication (i.e. a signature). At a nearby convenience store, it's $20. I'm sure that most gas stations don't require a signature because, until fairly recently, most people could get a tank of gas for less than $25. Nowadays, of course, it's twice that, but...
All gas stations in my area now ask for your zip code too. It's a dumb form of authentication, but it can be done at the pump so it doesn't annoy people into going elsewhere.
(Actually, coupled with decent fraud-detection software, and if you're in or near a major city, it could be really effective. We have probably twenty zip codes within a twenty mile radius here, so your chances of guessing right the first time are pretty poor. You could spot a stolen card real quick just by noting two consecutive failed attempts on the card. It would actually be far more effective than signature verification. Hmm. I was thinking their primary motivation for this approach was the fact that pumps can't take signatures, but now that I think about it this could be a really excellent idea. After all, signatures are only useful when it's already too late and you're in court. One-digit PINs, anyone?)
There could be a lot of reasons. Because of soft updates, FreeBSD is much more aggressive about metadata caching, which might explain why you're noticing the improvements for creating large number of smallish files (most of the I/O there is metadata updates). There is also just one filesystem for FreeBSD, making optimizations much easier. On Linux, optimizing for e[23]fs may really hurt the performance of XFS and vice versa, for example. Also, journalling filesystems are always slightly slower on writes than non-journalling ones because of the overhead of writing the log. This would, again, become most evident when creating lots of small files.
The WSJ's obit on Rehnquist had some interesting points on this. Early in his (pre-Chief) SCOTUS career, he had a tendency to write scathing dissents that nobody else would sign. Once he became Chief Justice, though, this mostly stopped. The obvious explanation is that he realized he had to work with his fellow justices and so decided to temper his dissents a little, in the spirit of compromise.
But one interesting thing about the CJ position is that he gets to decide who writes the opinions. The WSJ cited several examples of where Rehnquist unexpectedly did an about face and voted for stuff everyone was expecting him to vote against. The tinfoil-hat theory is that he did this because he knew he was going to lose (like 7-2 votes) but he wanted to "limit the damage." So he would side with the winners, then elect himself to write the majority opinion. He would make a legitimate assent, the theory goes, but he would carefully limit it. One of the examples was the Miranda case. Everyone expected him to vote against it, but he didn't. Instead, he wrote the opinion and basically just said "Miranda stands as is," when many of the majority justices actually wanted to expand it.
So if the WSJ's depiction is accurate, the CJ is pretty important. He can't make policy, but he can guide it. I'm sure there are also lots of procedural advantages that are mostly invisible to outsiders, like maybe he gets to decide who talks first in deliberations or something.
The best approach, probably, is to write mini-filesystem drivers and store them in a well-known section of each filesystem (like the boot sector). The loader will load the drivers into memory and can use them to find the kernel, modules to preload, and so on. The drivers can be "installed" as part of mkfs/newfs/format, so you don't have to touch the boot loader even if you're showing it a filesystem that didn't exist when it was written. This is the way OS/2 worked (and might be the way Windows works now, I don't know).
Let me tell you that a boot loader which understands filesystems is very handy. If you're familiar with Linux, you've probably come across initial RAM disks (initrds), which are used to load critical drivers - like for filesystems, hard disk controllers, and so on - without forcing them to be compiled into the kernel. This is a really powerful approach, but it's so complex and prone to failure. FreeBSD, to name one example, lets you load modules within the boot loader from the actual filesystem. Very convenient, elegant, and in my opinion a ton easier to use. (I believe GRUB is capable of this as well, it's only Linux that isn't. Or maybe both GRUB and Linux are capable of it and they just don't do it for whatever reason.)
I am a little surprised that the article didn't mention FreeBSD's boot loader. It's very Unix-like (Forth!) and open source as well, so it would be a good comparison to "traditional" offerings.
I can understand prices varying with costs. Buy why does the "insurance coverage" matter? Shouldn't the device cost whatever it costs, regardless of what insurance someone has?
Should, but doesn't. If you have good insurance, doctors will always charge the maximum allowed. If you don't, often they will charge substantially less. The actual cost of the device (to the doctor) falls somewhere in between; the idea is that insured patients help subsidize the uninsured.
Probably not all doctors do this, and certainly not all to the same degree, but it is fairly common. Note that it does not apply to hospitals.
There is a point to Perl, definitely. For fairly small and simple things, most people will use shell scripts. If you are filtering a lot of data, though, they tend to get painfully slow (because of their reliance on stuff like awk and sed). That's an excellent place to drop in Perl, which is really great at filtering lots of data. It's also a clearer language, believe it or not, for "super-scripts:" things which maybe started as shell scripts but evolved into small applications.
I would say that Perl is far less useful for major applications than Python (my favorite) or other, "cleaner," languages. Perl's a full-fledged general-purpose language, so of course it can be used for major apps, but it's not as good for them. I think that's part of the reason CPAN is so huge and powerful: it comes from a recognition by Perl programmers that the language is at its best when your scripts are under a thousand lines. By using many small CPAN modules you can do some pretty complex stuff with a pretty small amount of code (code written by you, anyway).
So a fuller answer to your question: I think Perl is becoming less important as other languages develop CPAN-like capabilities, but I don't ever see it going away. It will, at worst - or best, depending on your perspective - devolve to what it began life as: a powerful tool for writing nontrivial scripts.
I've been reading too much Best of the Web, I think, because I initially read the headline and thought "Do you download the entire Internet, or just part of it?"
Slashdot Mirror
Jane is a girl's name.
Although these micro-headlines do give us such gems as these, lifted from James Taranto:
People will bring up the RIAA suing grandmothers, and rightly so. The difference, as I see it, is that the RIAA believes - rightly or wrongly - that they're losing millions and millions of dollars to piracy. Look at it that way and it makes sense that they're willing to trade some bad press for a lessened erosion of their bottom line. Nothing in the article led me to believe that Activa was being so seriously affected by this one little site.
I guess what I'm saying is there's just enough information to make me think something else is going on here, but not enough to know what.
It will require students to install VPN clients on their "mobile OSes," but I don't think that's an unreasonable demand to make.
I suspect that if GNOME and KDE had, like Windows, five or six families of solid fonts that shipped with the DE, this would be a nonissue.
There are other useful tools, but I pretty much use those on every single box I touch for any reason.
Quality stuff will always survive in some form. I'm least worried about the WSJ, which is probably the smallest of the three papers I read. As you'd expect from a business-oriented newspaper, they got their business model straight from the get-go, and they've done very well with it - as of 2002, they were the most popular subscription service on the Internet.
- Obviously a happy subscriber to WSJ.com, but nothing more.
This would also let employees work from home or on the road without needing laptops, or with laptops but without keeping the document on there. ("We need those FY 2005 financial reports, but Bob has the latest version on his laptop and he's in Cancun for a week!")
I can see definite potential for this.
There are already apps to do this. But none of them are really easy to set up or maintain. If something breaks, or you want to change the configuration, you have to hire someone to fix it (and wait for them to get around to it, during which time you may be losing business). But if you get your calendar app hosted and supported by the same company as the one doing your web and mail, which you'd have anyway...I'm not saying it's a brilliant idea on the part of MS. Hosted Exchange would get you money hand over fist, because no one wants to pay the astronomical fees for an in-house Exchange admin. But the hardware requirements for Exchange are so high I'm not sure you'd actually be able to turn those huge revenues into profit.
If you can't do that, then probably your innovation isn't really an innovation at all. It's an incremental improvement or a different, but not better or worse, way of doing the same thing we do now.
Next, once you get past the simple tutorials, try to think of a simple program you'd like to write. My personal favorite target for learning exercises is reimplementing well-known Unix programs, or parts of them at least. So I might design a version of "cut" that does some things I want it to, like treat contiguous whitespace as a single delimiter. But maybe you already have something in mind, like a simple web app. If so, you should tailor your choice of language to what you want to do. Like if you want to make a simple web app first, you probably want to use PHP. (Which I didn't recommend earlier because it's a little harder to debug.)
At this point you can hopefully write nontrivial programs - programs 100 lines or so long that mostly do what you want on the first few tries. Now you should learn Java. The main reason for this is that you will need to learn C, or at least a C-like language, at some point, but you don't want to get into the complex parts of C yet. Java will handle most of them for you. It's also a compiled language, so it adds an extra step to the process (code-compile-test instead of just code-test). This is probably where you ought to learn most of the intermediate programming concepts, like basic data structures and algorithms. What you may find helpful is going back and forth between Java and the language you started with. Sort of sketch out the app's framework and decide how you want to do something in e.g. Python, then rewrite it in Java. This will not only let you use the language you're most familiar with, it will give you a valuable understanding of how programming languages work.
Finally, move to C. C++ would be an easier transition since it's much more like Java than C is. But what you want to learn is memory management and all the other hard shit, and there's no way to escape it in C (there are lots of ways to escape it in C++). Plus, once you have a solid grasp of C and Java, you will almost by default know C++. Then you can learn the advanced features of C++ without having to worry about anything else.
Once you're at this point, you will be able to pick up the basics of any new language in a week or two. If you still want to learn and didn't start with Scheme, you should learn it now. It's a very different way of programming than you'll be used to, and it'll teach you even more about how languages work and how to be a good programmer.
I'm assuming you want to do as much of this as possible on your own. The first two steps - learning your first language and writing some simple programs in it - can be done with books and online tutorials. Past that, however, I would advise taking classes. You will know enough by then to have questions which might not be answered in a book, but which an instructor could answer easily - maybe before you even know to ask. Instructors will also be giving you assignments which are neither too easy nor too hard (hopefully), which is really hard to do on your own. You'll quickly find that you can read a book and understand every word in it, but not be able to write a program that says "Hello, world!" on your own. You need to be practicing this stuff constantly as you learn it or all the books in the world will be useless.
Remember that Monad isn't supposed to be a functional replacement for bash. It's supposed to be more like Perl+CPAN. cmd.exe, weak as it is, is a "good enough" replacement for bash already.
I do sort of wonder about the legal rationale for this. In the context of onerous EULAs, it certainly makes sense and is a good thing; but it seems to me that if I make a conscious choice, of my own free will (not under duress), to waive a particular right, I should be allowed to do so. Consider assisted suicide as an example. Normally if a physician were to give me a lethal drug knowing that it would end my life, he'd be guilty of murder. But it's my life, so can't I sign away my right to it and absolve him of any crime? It clearly makes pragmatic sense not to allow this since it can be so difficult to tell if I gave away my right under duress or not. Better to make mistakes we can later remedy than ones we can't... once I'm dead, that's it. But if it's my decision, and I'm using the doctor as a tool - rather than him using me - then why should the law even consider his role?
Perhaps it stems from the "life, liberty, and pursuit of happiness" bit. Congress isn't actually granting rights, it's acting almost like the SCOTUS and instead defining the legal parameters for the rights already given to us. God gives us our right to life, and only God can take it away. Because it doesn't come from us, nothing we can do can abrogate it. Congress is doing nothing more than clarifying the matter for more complex situations. (I used the word "God" here because it was pretty obviously the way the Founders believed. The origin of the rights is irrelevant so long as we agree that we have some sort of innate rights. If we don't agree, you're a utilitarian and probably stopped reading two paragraphs ago.)
No you don't. Use a filesystem which supports snapshots, like UFS2, and take a snapshot of the filesystem. Back up the snapshot. You will have a "broken" database backup, but since PostgreSQL does logging and all sorts of other ACID-ish things, it can recover from that just fine. You'll just lose whatever transactions were pending at the time the snapshot was taken. Par for the course: you'd lose them doing pg_dump too.
That'll be $100 million, please.
All gas stations in my area now ask for your zip code too. It's a dumb form of authentication, but it can be done at the pump so it doesn't annoy people into going elsewhere.
(Actually, coupled with decent fraud-detection software, and if you're in or near a major city, it could be really effective. We have probably twenty zip codes within a twenty mile radius here, so your chances of guessing right the first time are pretty poor. You could spot a stolen card real quick just by noting two consecutive failed attempts on the card. It would actually be far more effective than signature verification. Hmm. I was thinking their primary motivation for this approach was the fact that pumps can't take signatures, but now that I think about it this could be a really excellent idea. After all, signatures are only useful when it's already too late and you're in court. One-digit PINs, anyone?)
There could be a lot of reasons. Because of soft updates, FreeBSD is much more aggressive about metadata caching, which might explain why you're noticing the improvements for creating large number of smallish files (most of the I/O there is metadata updates). There is also just one filesystem for FreeBSD, making optimizations much easier. On Linux, optimizing for e[23]fs may really hurt the performance of XFS and vice versa, for example. Also, journalling filesystems are always slightly slower on writes than non-journalling ones because of the overhead of writing the log. This would, again, become most evident when creating lots of small files.
But one interesting thing about the CJ position is that he gets to decide who writes the opinions. The WSJ cited several examples of where Rehnquist unexpectedly did an about face and voted for stuff everyone was expecting him to vote against. The tinfoil-hat theory is that he did this because he knew he was going to lose (like 7-2 votes) but he wanted to "limit the damage." So he would side with the winners, then elect himself to write the majority opinion. He would make a legitimate assent, the theory goes, but he would carefully limit it. One of the examples was the Miranda case. Everyone expected him to vote against it, but he didn't. Instead, he wrote the opinion and basically just said "Miranda stands as is," when many of the majority justices actually wanted to expand it.
So if the WSJ's depiction is accurate, the CJ is pretty important. He can't make policy, but he can guide it. I'm sure there are also lots of procedural advantages that are mostly invisible to outsiders, like maybe he gets to decide who talks first in deliberations or something.
Let me tell you that a boot loader which understands filesystems is very handy. If you're familiar with Linux, you've probably come across initial RAM disks (initrds), which are used to load critical drivers - like for filesystems, hard disk controllers, and so on - without forcing them to be compiled into the kernel. This is a really powerful approach, but it's so complex and prone to failure. FreeBSD, to name one example, lets you load modules within the boot loader from the actual filesystem. Very convenient, elegant, and in my opinion a ton easier to use. (I believe GRUB is capable of this as well, it's only Linux that isn't. Or maybe both GRUB and Linux are capable of it and they just don't do it for whatever reason.)
I am a little surprised that the article didn't mention FreeBSD's boot loader. It's very Unix-like (Forth!) and open source as well, so it would be a good comparison to "traditional" offerings.
...does her house have stairs?
And if you like BitTorrent: FileRush.
Probably not all doctors do this, and certainly not all to the same degree, but it is fairly common. Note that it does not apply to hospitals.
I would say that Perl is far less useful for major applications than Python (my favorite) or other, "cleaner," languages. Perl's a full-fledged general-purpose language, so of course it can be used for major apps, but it's not as good for them. I think that's part of the reason CPAN is so huge and powerful: it comes from a recognition by Perl programmers that the language is at its best when your scripts are under a thousand lines. By using many small CPAN modules you can do some pretty complex stuff with a pretty small amount of code (code written by you, anyway).
So a fuller answer to your question: I think Perl is becoming less important as other languages develop CPAN-like capabilities, but I don't ever see it going away. It will, at worst - or best, depending on your perspective - devolve to what it began life as: a powerful tool for writing nontrivial scripts.
I've been reading too much Best of the Web, I think, because I initially read the headline and thought "Do you download the entire Internet, or just part of it?"