Well, I'm familiar with the concept of RAID, but I've never sat down and thought through the exact striping scheme, so thanks for the intro. (I usually end up going straight to RAID-10.)
I'm still confused on the original point, though. I understand that ZFS doesn't use deltas, exactly, but it still uses their moral equivalent; it saves space by storing a pointer to the original block. So I feel like you run into the same problem.
Let's look at a degenerate example:/source is a hard drive that can store exactly five blocks of one character each. I store "ABCDE". I back it up to a ginormous ZFS volume,/backup-log, which has one physical volume,/backup1-phy, that holds ten one-character blocks. Initially,/backup1-phy contains "ABCDE-----" (where "-" represents an empty block)./backup-log also shows "ABCDE-----" in its "current view" (whatever ZFS calls that non-snapshotted real-time view).
Now I take a ZFS snapshot on/backup-log, delete/source/E, and create/source/F./source now contains "ABCDF". Next time I back up,/backup-log looks like "ABCDF-----"; because the snapshot still uses "E",/backup1-phy contains "ABCDEF----".
I keep going down this road, until/source contains "FGHIJ"./backup1-phy now contains "ABCDEFGHIJ" among various snapshots;/backup-log just shows "FGHIJ".
Oh noez!!/backup1-phy is full. No problem; I'll just add/backup2-phy to the/backup-log volume. Now, when I take a snapshot on/backup-log, delete/source1/J and add/source1/K, I should be fine.
Except, and this is the part I don't get: Either (a) there is going to be a snapshot on/backup-log that depends on BOTH/backup1-phy and/backup2-phy, or (b) everything on/backup1-phy needs to be copied to/backup2-phy.
Maybe the answer is (a), and maybe that's fine, because underneath the snapshot layer, we've still got a parity layer that can deal with one of/backup1-phy or/backup2-phy failing. I can't really articulate *why* that doesn't feel right; there's just something about it that screams "wrong" to me, or at least it screams "less reliable than partitioning your data so any given file depends on only one volume".
the argument can also be made that it wasn't the most secure extension in the world, what with having your personal data kept on Google's servers and shot around the internet.
I, for one, feel safer knowing that my browser bookmarks are no longer kept on remote servers and shot around the internet.
Now if you'll excuse me, I need to go do some online bill payments and check my G-Mail.
(If this question isn't relevant to ZFS, please just yell at me.)
I've been using CrashPlan lately for backups, which, AFAICT, is effectively the same as a copy-on-write system; they store some type of "rolling delta" so that only changed data is rewritten to disk.
And that seems really cool. But one thing keeps nagging at me: Don't copy-on-write/delta based systems prevent you from safely growing a logical volume beyond the limits of a physical volume, short of massive duplication?
Let's say I had a 500GB physical drive rooted at/source, and I'm backing it up to a 1TB physical drive/media/backupa, keeping backups forever. The first copy is 500GB; great. Over some period of time, every byte of/source changes, so that I have another 500GB of deltas. Oops,/media/backupa is now full.
No problem; I can add another 1TB physical drive at/media/backupb, and combine them into logical volume/media/logical-backup. Except that either (a)/media/backupb has to ALSO hold the first 1TB of data, which means it's full, or (b) any backup that depends on deltas stored on/media/backupb also must depend on/media/backupa, which contains the ancestor of those deltas.
So maybe I just make/media/backupb a mirror of/media/backupa; now I have two copies. I then add a third 1TB drive,/media/backupc, and make it part of/media/logical-backup. Now I'm cool - assuming I don't lose both/media/backupa and/media/backupb at once. Except that, as we keep expanding/media-logical-backup, the number of failure combinations we can withstand keeps going down, as the number of cross-dependencies increases.
I don't have any experience with the other status-symbol-ergo-chairs like the Humanscale Freedom, so I don't know if the Aeron is especially good, or just that ~$1000 buys a whole lot of chair.
Nope, it's really that good. I had back problems that made $1000 for a chair seem like a bargain, so I've owned a few kinds, and sat in many more. The big advantage of the Aeron is the Pellicle weave; it's strong enough to support you, but it lets air flow. A few years ago, it was the only mesh chair available; now, others have copied it, but I've never seen any with the same level of support.
Definitely avoid any chair made of "memory foam". I love the stuff, and I have a Tempur-Pedic pillow, but it loses its stiffness in about a year and needs replacing. You can't replace a chair the way you replace a pillow. (I gave the mattress away.)
Likewise, there was a fad for a few years of having a "scooped" or contoured seat pan, with a raised center; avoid that. It's fine if you're wearing slacks at the office. But if you're a guy, and you're at home, and you're wearing pajamas or boxers... it's... uncomfortable.
Last time I checked, compilers were cheaper than computers.
Depends on the app, doesn't it? My argument's more suited for server-side apps than desktop; on the server, the money comes out of the same pocket whether it goes to programmers or computers. And if I can spend one man-month getting a 10% increase in performance, then I have to ask if one man-month of salary will buy me 10% more hardware. If it will, that's a sweet deal - because that man-month can be spent doing something that more hardware CAN'T do, like adding features.
Sure, faster compilers and interpreters are great; in fact, I agree that they're the best bang for the buck, because the savings get multiplied by every application that runs on them. On the other hand, most of the things I do aren't CPU-bound anymore; I just don't NEED a faster compiler. I don't even need a compiler; an interpreted language like Ruby suits me just fine to string together the database queries that really drive my performance.
How much energy is taken per year, do you think, executing JavaScript in web pages? How much would be saved if the implementations were twice as efficient?
Don't assume that faster compilers and interpreters mean that you'll execute the same amount of code in less time; they don't. They mean you'll execute MORE code in the SAME amount of time, because people will start doing more. The UI will get more natural; the abstractions will get cleaner. We shifted from arrays to associative arrays, from two-letter commands to mouse gestures, from page-oriented web sites to AJAX, from monochrome or 4-color CGA to alpha blends.
My neighbor is a UI designer, and she recently asked me: "Aren't all the good computer technologies invented already?" And I said "No... what about speech recognition?" She said, "Well, my work doesn't involve any speech recognition." So I said "Right. And 30 years ago, your work didn't involve graphics, either."
The other thing to remember is that "costs" aren't just monetary; recruiting is hard. If two good programmers can do the work of five computers, and you have one good programmer, is it more "expensive" to find and hire another good programmer - or to buy five computers that'll show up tomorrow with three clicks of the mouse? What's the cost of launching two months later because it took two months to find a good programmer? Etc.
I remember the bad old days of Compu$erve Information $ervices when the clock was ticking at, if I recall correctly, $6.00 an hour... and much more than that if you entered some of their "premium" services.
You remember right... $6/hour it was (off-peak; I think peak was $12). More for stock quotes, news feeds, other business-y things. Remember, these services were designed for businesses; the night-time home usage was just a way to make money off the idling computing and telecom power.
Three stories of my childhood:
* When I was 13, CompuServe had a trivia game called "You Guessed It!", which awarded free online time to winners. I was convinced that if I played and won enough, I could get CIS for free.
* When I was 16, I ran up several hundred dollars in Q-Link charges, and ended up selling my Casio CZ-1 keyboard to one of the Q-Link employees, which money went to pay my bill.
* When I was 18, I went to work for Q-Link - which meant a free account. Usually, they had you register a new account in your training class, but they did have procedures for converting existing accounts. They did not, however, have procedures for uncancelling an account that was overdue, and collecting the overdue bill from your first paycheck... till I got there.
3. We already know that things didn't go the way they were supposed to. Something failed. Some safety plan didn't work. We have to assume that we're dealing with chaos until proved otherwise.
A-freaking-men to ALL your posts. I think point #3 is the part your (now-modded-below-my-reading-level) antagonist isn't getting.
Yes, we know how electrical circuits work. We know the theory. We know which way current flows. We know logic.
We also know that when things are working the way we know them to work, nothing blows up. Therefore, we know that, somewhere in the blown-up, on-fire building, reality has diverged from that theory. And, usually, it's not one thing: it's a confluence of events. There's no reason to place lives at risk; turn the power off, and find out exactly what happened and why.
Um, no. I miss the days of hand-optimizing branches as much as the next guy, but the latest trend toward bigger, bulkier software isn't stemming from Microsoft this time. It's because computers are cheaper than developers.
I recently had the opportunity to work with some code I hadn't touched in over a decade, and port it to a modern hardware platform (same OS). It was amazing, because I could now do the "overnight full build" in 15 minutes. Daemons that used to take 5-10 minutes to compile now took 1 to 2 seconds.
Faster computers change everything. (Just like the availability of cheap screens, and then cheap graphics hardware, moved us from teletypes to CRTs to GUIs.) Continuous integration? Sure, we have cycles to spare. Automated testing? Ditto. Over-modularized components for quicker builds? Don't need 'em. Complex, custom circular buffers? Just log it and parse it later. Need more cache? Have some RAM.
Could I still write code that fits in 2048 bytes and runs at 1MHz? Sure. Can I do a lot more when I don't have to worry about it? Yep. Do we gain more from standing on the shoulders of frameworks and libraries than we lose to hardware costs? Hell yeah.
They claim they called Comcast's technical contact and told him they'd taken control of the domain, BEFORE they changed anything. I don't know if it'll help them in court, but it sounds like if he hadn't blown them off, it really would have been a harmless prank.
It probably won't help them, but it certainly help anyone who might have been harmed - as a subscriber or a shareholder - and wants to sue Comcast for negligence...
Open source is a guarantee that things can be fixed legally and practically.
That depends on your company size, though. If you're big enough, your SLA with the vendor says that they will fix the problems legally, practically, and quickly (and you've probably got the source in escrow, just in case). With open source, you have to hope that the code base is transparent enough that you can find someone to understand and fix it.
I remember times when we had problems with the operating system of a large, high-end vendor; they flew out the "father of the OS" to troubleshoot on-site and fix them for us. Try doing that with Cyrus IMAPD. Sure, there are some open-source projects where you can do that; there are also many you can't, because the authors have day jobs, college careers, existing contracts, etc.
There's a reason Apple bought CUPS; it's because their OS depends on it, and they want to make sure they have someone who understands the internals on staff. But if you have to buy out every open-source project you use, you've lost the advantages of open-source.
About seven years ago, I needed to write a DSL. I used ANTLR to do it, and it was a pleasure - even though I didn't know Java! I wrote out the grammar, ANTLR wrote all the code for me, everyone was happy. And that was long before there was anything as amazing as ANTLRWorks.
But lately I've been wondering: Do we really need parser generators anymore? In Ruby, if you're writing a DSL, you usually implement it in terms of the Ruby language itself. I imagine that's true for other dynamic languages too. Look at Rails, or Adhearsion, or RSpec: They're DSLs, but they're valid Ruby.
And if you're not writing your own DSL, but parsing a "well-known" format, parsers have a downside there too: They're picky. If I need to scrape a bit of data out of an XHTML page, I'm better off *not* using an XML parser; it'll choke. It's usually easier to use a regex, waste some theoretical CPU, and throw away the bits I don't need.
So, parser lovers: Why do we still need cool tools like ANTLR? What do they provide that crude regular expressions don't?
I encountered an error installing 10.5.3; downloading the Combo Update and running it again fixed the problem. I had moved some of Apple's software from/Applications to/Applications/Apple; the installer tries to guess where you've moved it, but apparently the 10.5.2 installer guesses wrong. My/var/log/install.log read:
May 28 15:14:57 macpro payloadExtractor[5981]: Diverting "./Applications/iSync. app/Contents/Resources" to "/System/Library/Frameworks/Ruby.framework/Versions/1 .8/usr/lib/ruby/gems/1.8/doc/actionpack-1.13.6/rdoc/files/lib/action_controller/ vendor/html-scanner/html/version_rb.html/Contents/Resources" May 28 15:14:57 macpro payloadExtractor[5981]: BomFileError 20: Not a directory -/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8/d oc/actionpack-1.13.6/rdoc/files/lib/action_controller/vendor/html-scanner/html/v ersion_rb.html/Contents/Resources May 28 15:14:57 macpro payloadExtractor[5981]: 20418 of 20418 files written in 21.95 seconds. May 28 15:14:57 macpro payloadExtractor[5981]: 1261696 kilobytes installed at 5 6.1 MB/s. May 28 15:14:57 macpro payloadExtractor[5981]: Error extracting archive. May 28 15:14:57 macpro payloadExtractor[5981]: pkgExtractor exited with error 1 while processing package '/Library/Updates/Mac OS X Update/Packages/MacOSXUpd10. 5.3.pkg' May 28 15:14:57 macpro/System/Library/CoreServices/Software Update.app/Contents /MacOS/Software Update[5947]: Install failed: The Installer could not install so me files in "/". Contact the software manufacturer for assistance.
It looks like it realized I'd moved iSync, but it somehow thought I'd moved it deep into the Rails gem in Ruby. Oops.
You can download the 10.5.3 combo installer here. Running again worked fine, so I'm guessing they fixed the bug in 10.5.3; you just need 10.5.3 to run the fixed pkgExtractor!
Most hot tubs and swimming pools have a chlorine/bromine-based water chemistry, to kill bacteria. But there's an alternative treatment, based on biguanide polymers, that IIRC weakens the cell walls of the bacteria. (It's sold as BaquaSpa and BaquaCil, among others.)
The most common bacteria in hot tubs? Pseudomonas.
It's one of the few times I've heard someone make the point that because you don't know what it is, then by definition it's an unidentified flying object
Exactly; it's a semantic cop-out. "UFO" holds two, related meanings, which they love to conflate...
1. Unidentified Flying Object: Something that's flying that wasn't identified. 2. Unidentified Flying Object: An alien spacecraft kept secret through government conspiracies.
The UFO believers really, really want to talk about #2. But if you point out just how unlikely that is, they'll fall back on definition #1: Hey, it was flying, right? And it wasn't identified, right?
I believe I have come up with a solution to that. I am going to follow up on every single UFO report. I will ask to see the pictures, or to hear a description. And then, the conversation goes like this:
Roswellian: It was disc-shaped, hundreds of feet long, with one purple light. And nobody could identify it. Me: Oh, that. That's "Bob". Roswellian: Bob? Me: Yes. I know just the craft you speak of, and it's called "Bob". Roswellian: Me: So it's not really unidentified anymore. It's just a flying object named Bob. Roswellian: But.. but okay, what about this report from last week? Gray humanoids, with egg-shaped heads, descended from a tube-shaped-- Me: Now that one, we call "Bob". Roswellian: I thought the saucer was called Bob? Me: Yes, that too. Roswellian: They're both... They're both "Bob"? Me: It's a very common name. Roswellian: Me: Anything else? Roswellian: Well.. there was this time that I was driving, and-- Me: Irving. Roswellian: IRVING?? Me: Well, actually, we've nicknamed it "Bob". Irving's kind of a dorky name. Roswellian: "Bob." Me: Naturally.
Slashdot Mirror
The Storm worm now attacks this pot as well; it secretly replaces the coffee with Folger's Crystals.
Well, I'm familiar with the concept of RAID, but I've never sat down and thought through the exact striping scheme, so thanks for the intro. (I usually end up going straight to RAID-10.)
/source is a hard drive that can store exactly five blocks of one character each. I store "ABCDE". I back it up to a ginormous ZFS volume, /backup-log, which has one physical volume, /backup1-phy, that holds ten one-character blocks. Initially, /backup1-phy contains "ABCDE-----" (where "-" represents an empty block). /backup-log also shows "ABCDE-----" in its "current view" (whatever ZFS calls that non-snapshotted real-time view).
/backup-log, delete /source/E, and create /source/F. /source now contains "ABCDF". Next time I back up, /backup-log looks like "ABCDF-----"; because the snapshot still uses "E", /backup1-phy contains "ABCDEF----".
/source contains "FGHIJ". /backup1-phy now contains "ABCDEFGHIJ" among various snapshots; /backup-log just shows "FGHIJ".
/backup1-phy is full. No problem; I'll just add /backup2-phy to the /backup-log volume. Now, when I take a snapshot on /backup-log, delete /source1/J and add /source1/K, I should be fine.
/backup-log that depends on BOTH /backup1-phy and /backup2-phy, or (b) everything on /backup1-phy needs to be copied to /backup2-phy.
/backup1-phy or /backup2-phy failing. I can't really articulate *why* that doesn't feel right; there's just something about it that screams "wrong" to me, or at least it screams "less reliable than partitioning your data so any given file depends on only one volume".
I'm still confused on the original point, though. I understand that ZFS doesn't use deltas, exactly, but it still uses their moral equivalent; it saves space by storing a pointer to the original block. So I feel like you run into the same problem.
Let's look at a degenerate example:
Now I take a ZFS snapshot on
I keep going down this road, until
Oh noez!!
Except, and this is the part I don't get: Either (a) there is going to be a snapshot on
Maybe the answer is (a), and maybe that's fine, because underneath the snapshot layer, we've still got a parity layer that can deal with one of
Uh, not quite. By 1955, lunar settlement was already considered not only feasible but threatening, even to your average blue-collar city-dweller.
I, for one, feel safer knowing that my browser bookmarks are no longer kept on remote servers and shot around the internet.
Now if you'll excuse me, I need to go do some online bill payments and check my G-Mail.
(If this question isn't relevant to ZFS, please just yell at me.)
/source, and I'm backing it up to a 1TB physical drive /media/backupa, keeping backups forever. The first copy is 500GB; great. Over some period of time, every byte of /source changes, so that I have another 500GB of deltas. Oops, /media/backupa is now full.
/media/backupb, and combine them into logical volume /media/logical-backup. Except that either (a) /media/backupb has to ALSO hold the first 1TB of data, which means it's full, or (b) any backup that depends on deltas stored on /media/backupb also must depend on /media/backupa, which contains the ancestor of those deltas.
/media/backupb a mirror of /media/backupa; now I have two copies. I then add a third 1TB drive, /media/backupc, and make it part of /media/logical-backup. Now I'm cool - assuming I don't lose both /media/backupa and /media/backupb at once. Except that, as we keep expanding /media-logical-backup, the number of failure combinations we can withstand keeps going down, as the number of cross-dependencies increases.
I've been using CrashPlan lately for backups, which, AFAICT, is effectively the same as a copy-on-write system; they store some type of "rolling delta" so that only changed data is rewritten to disk.
And that seems really cool. But one thing keeps nagging at me: Don't copy-on-write/delta based systems prevent you from safely growing a logical volume beyond the limits of a physical volume, short of massive duplication?
Let's say I had a 500GB physical drive rooted at
No problem; I can add another 1TB physical drive at
So maybe I just make
Am I missing something?
Nope, it's really that good. I had back problems that made $1000 for a chair seem like a bargain, so I've owned a few kinds, and sat in many more. The big advantage of the Aeron is the Pellicle weave; it's strong enough to support you, but it lets air flow. A few years ago, it was the only mesh chair available; now, others have copied it, but I've never seen any with the same level of support.
Definitely avoid any chair made of "memory foam". I love the stuff, and I have a Tempur-Pedic pillow, but it loses its stiffness in about a year and needs replacing. You can't replace a chair the way you replace a pillow. (I gave the mattress away.)
Likewise, there was a fad for a few years of having a "scooped" or contoured seat pan, with a raised center; avoid that. It's fine if you're wearing slacks at the office. But if you're a guy, and you're at home, and you're wearing pajamas or boxers... it's... uncomfortable.
I second the leather arms. I have the original fabric arms (not sure if they're even still offered), and they wear a hole in my wrist.
Also, go for the PostureFit back; it's a terrific improvement.
They've been making breakfast-cereal "waxed" liner bags out of this for years.
Heisenberg also worked for the Nazi's and attempted to build a Nuclear bomb.
Well, we can't be certain about both...
Drop cube in can of paint.
Paint is so 1987. Sears now sells powder coaters for $150.
There is nothing that can't be improved with a little powder coating. Pencils, silverware, desks...
Last time I checked, compilers were cheaper than computers.
Depends on the app, doesn't it? My argument's more suited for server-side apps than desktop; on the server, the money comes out of the same pocket whether it goes to programmers or computers. And if I can spend one man-month getting a 10% increase in performance, then I have to ask if one man-month of salary will buy me 10% more hardware. If it will, that's a sweet deal - because that man-month can be spent doing something that more hardware CAN'T do, like adding features.
Sure, faster compilers and interpreters are great; in fact, I agree that they're the best bang for the buck, because the savings get multiplied by every application that runs on them. On the other hand, most of the things I do aren't CPU-bound anymore; I just don't NEED a faster compiler. I don't even need a compiler; an interpreted language like Ruby suits me just fine to string together the database queries that really drive my performance.
How much energy is taken per year, do you think, executing JavaScript in web pages? How much would be saved if the implementations were twice as efficient?
Don't assume that faster compilers and interpreters mean that you'll execute the same amount of code in less time; they don't. They mean you'll execute MORE code in the SAME amount of time, because people will start doing more. The UI will get more natural; the abstractions will get cleaner. We shifted from arrays to associative arrays, from two-letter commands to mouse gestures, from page-oriented web sites to AJAX, from monochrome or 4-color CGA to alpha blends.
My neighbor is a UI designer, and she recently asked me: "Aren't all the good computer technologies invented already?" And I said "No... what about speech recognition?" She said, "Well, my work doesn't involve any speech recognition." So I said "Right. And 30 years ago, your work didn't involve graphics, either."
Good point about recurring vs. non-recurring.
The other thing to remember is that "costs" aren't just monetary; recruiting is hard. If two good programmers can do the work of five computers, and you have one good programmer, is it more "expensive" to find and hire another good programmer - or to buy five computers that'll show up tomorrow with three clicks of the mouse? What's the cost of launching two months later because it took two months to find a good programmer? Etc.
Assuming, of course, they even still exist (which was the case in the GGP's post, if I'm not mistaken).
That's why you put their source in escrow. If they cease to exist, you get access to the source. SOP for large contracts.
Proof that Time Warner has laid off anyone who remembers the early days of AOL, or the lessons learned...
2009: Time Warner announces unlimited Internet; busy signals ensue
I remember the bad old days of Compu$erve Information $ervices when the clock was ticking at, if I recall correctly, $6.00 an hour... and much more than that if you entered some of their "premium" services.
You remember right... $6/hour it was (off-peak; I think peak was $12). More for stock quotes, news feeds, other business-y things. Remember, these services were designed for businesses; the night-time home usage was just a way to make money off the idling computing and telecom power.
Three stories of my childhood:
* When I was 13, CompuServe had a trivia game called "You Guessed It!", which awarded free online time to winners. I was convinced that if I played and won enough, I could get CIS for free.
* When I was 16, I ran up several hundred dollars in Q-Link charges, and ended up selling my Casio CZ-1 keyboard to one of the Q-Link employees, which money went to pay my bill.
* When I was 18, I went to work for Q-Link - which meant a free account. Usually, they had you register a new account in your training class, but they did have procedures for converting existing accounts. They did not, however, have procedures for uncancelling an account that was overdue, and collecting the overdue bill from your first paycheck... till I got there.
This reminds me of a story from my youth...so we... scanned...
You have no idea how depressing this is.
3. We already know that things didn't go the way they were supposed to. Something failed. Some safety plan didn't work. We have to assume that we're dealing with chaos until proved otherwise.
A-freaking-men to ALL your posts. I think point #3 is the part your (now-modded-below-my-reading-level) antagonist isn't getting.
Yes, we know how electrical circuits work. We know the theory. We know which way current flows. We know logic.
We also know that when things are working the way we know them to work, nothing blows up. Therefore, we know that, somewhere in the blown-up, on-fire building, reality has diverged from that theory. And, usually, it's not one thing: it's a confluence of events. There's no reason to place lives at risk; turn the power off, and find out exactly what happened and why.
Um, no. I miss the days of hand-optimizing branches as much as the next guy, but the latest trend toward bigger, bulkier software isn't stemming from Microsoft this time. It's because computers are cheaper than developers.
I recently had the opportunity to work with some code I hadn't touched in over a decade, and port it to a modern hardware platform (same OS). It was amazing, because I could now do the "overnight full build" in 15 minutes. Daemons that used to take 5-10 minutes to compile now took 1 to 2 seconds.
Faster computers change everything. (Just like the availability of cheap screens, and then cheap graphics hardware, moved us from teletypes to CRTs to GUIs.) Continuous integration? Sure, we have cycles to spare. Automated testing? Ditto. Over-modularized components for quicker builds? Don't need 'em. Complex, custom circular buffers? Just log it and parse it later. Need more cache? Have some RAM.
Could I still write code that fits in 2048 bytes and runs at 1MHz? Sure. Can I do a lot more when I don't have to worry about it? Yep. Do we gain more from standing on the shoulders of frameworks and libraries than we lose to hardware costs? Hell yeah.
It probably won't help them, but it certainly help anyone who might have been harmed - as a subscriber or a shareholder - and wants to sue Comcast for negligence...
OK, I did, but it's not done running yet...
Open source is a guarantee that things can be fixed legally and practically.
That depends on your company size, though. If you're big enough, your SLA with the vendor says that they will fix the problems legally, practically, and quickly (and you've probably got the source in escrow, just in case). With open source, you have to hope that the code base is transparent enough that you can find someone to understand and fix it.
I remember times when we had problems with the operating system of a large, high-end vendor; they flew out the "father of the OS" to troubleshoot on-site and fix them for us. Try doing that with Cyrus IMAPD. Sure, there are some open-source projects where you can do that; there are also many you can't, because the authors have day jobs, college careers, existing contracts, etc.
There's a reason Apple bought CUPS; it's because their OS depends on it, and they want to make sure they have someone who understands the internals on staff. But if you have to buy out every open-source project you use, you've lost the advantages of open-source.
About seven years ago, I needed to write a DSL. I used ANTLR to do it, and it was a pleasure - even though I didn't know Java! I wrote out the grammar, ANTLR wrote all the code for me, everyone was happy. And that was long before there was anything as amazing as ANTLRWorks.
But lately I've been wondering: Do we really need parser generators anymore? In Ruby, if you're writing a DSL, you usually implement it in terms of the Ruby language itself. I imagine that's true for other dynamic languages too. Look at Rails, or Adhearsion, or RSpec: They're DSLs, but they're valid Ruby.
And if you're not writing your own DSL, but parsing a "well-known" format, parsers have a downside there too: They're picky. If I need to scrape a bit of data out of an XHTML page, I'm better off *not* using an XML parser; it'll choke. It's usually easier to use a regex, waste some theoretical CPU, and throw away the bits I don't need.
So, parser lovers: Why do we still need cool tools like ANTLR? What do they provide that crude regular expressions don't?
You can download the 10.5.3 combo installer here. Running again worked fine, so I'm guessing they fixed the bug in 10.5.3; you just need 10.5.3 to run the fixed pkgExtractor!
Most hot tubs and swimming pools have a chlorine/bromine-based water chemistry, to kill bacteria. But there's an alternative treatment, based on biguanide polymers, that IIRC weakens the cell walls of the bacteria. (It's sold as BaquaSpa and BaquaCil, among others.)
The most common bacteria in hot tubs? Pseudomonas.
So... who wins that battle?
It's one of the few times I've heard someone make the point that because you don't know what it is, then by definition it's an unidentified flying object
Exactly; it's a semantic cop-out. "UFO" holds two, related meanings, which they love to conflate...
1. Unidentified Flying Object: Something that's flying that wasn't identified.
2. Unidentified Flying Object: An alien spacecraft kept secret through government conspiracies.
The UFO believers really, really want to talk about #2. But if you point out just how unlikely that is, they'll fall back on definition #1: Hey, it was flying, right? And it wasn't identified, right?
I believe I have come up with a solution to that. I am going to follow up on every single UFO report. I will ask to see the pictures, or to hear a description. And then, the conversation goes like this:
Roswellian: It was disc-shaped, hundreds of feet long, with one purple light. And nobody could identify it.
Me: Oh, that. That's "Bob".
Roswellian: Bob?
Me: Yes. I know just the craft you speak of, and it's called "Bob".
Roswellian:
Me: So it's not really unidentified anymore. It's just a flying object named Bob.
Roswellian: But.. but okay, what about this report from last week? Gray humanoids, with egg-shaped heads, descended from a tube-shaped--
Me: Now that one, we call "Bob".
Roswellian: I thought the saucer was called Bob?
Me: Yes, that too.
Roswellian: They're both... They're both "Bob"?
Me: It's a very common name.
Roswellian:
Me: Anything else?
Roswellian: Well.. there was this time that I was driving, and--
Me: Irving.
Roswellian: IRVING??
Me: Well, actually, we've nicknamed it "Bob". Irving's kind of a dorky name.
Roswellian: "Bob."
Me: Naturally.