This is where the risk/reward idea alluded to in the article comes into play. There are play strategies that will maximize your score on average, but are slightly more dangerous. Let's say these work 10% of the time, increasing your score by 20%, and the other 90% of the time they crash and burn. Almost all of the time, this a losing approach. The more conservative player will avoid these, because it means almost all of your games are useless. But eventually, someone playing with that aggressive style will stumble on the magic game where enough risky gambits go their way, if they just keep playing over and over again without any concern for typical performance. Now, the real numbers aren't like that; it might be a 1% reward for a 10% risk instead. But there's just now getting to be enough games played at this level to start even estimating statistics like that.
I suspect this is why Billy Mitchell remains such a overconfident guy here. He has such a head start on the others working this problem I expect he already has the more aggressive play worked out. He just ramps up use of those techniques as needed when the competitors catch up with him again. He's just the sort of dick to have worked all that out twenty years ago, and is just reeling out the knowledge as needed. I actually like the guy for the way he's a devious no holds-barred competitor. Messing with your opponents psyche by things like quitting your game the minute you've beat their old score is a classic all out technique.
Re:no, it's still there and it still works
on
PS3 Root Key Found
·
· Score: 1
In addition to whether the feature itself works or not, one of the selling points of the PS3 was how Sony presented the idea that it was going to be upgraded regularly to work around the issues it did have. The theory was their overpowered hardware had enough headroom to allow just software upgrades to unlock more potential, and some buyers invested in the unit on the promise the early bugs and limitations would eventually be righted.
In the most extreme example, if Sony had stopped releasing new firmware releases for Blu-ray disks, all owners would be screwed because newer titles wouldn't work right? That's the understanding implicit in the product. You're buying something that may have limitations, but you're going to get regular updates to continue to move forward. All part of the PS3 promise. And dropping development on some aspect, even if the early version of the feature continued to work in the form it shipped in, does represent a disappointing break in those expectations. They've done a better job than I expected at keeping the PS3 a good Blu-Ray player, but all of its other non-gaming use withered relative to its potential.
There's a hierarchy of badness here:
1) OtherOS: Removed from all units retroactively and with no workaround. Complete bait and switch.
2) SACD: Some features (admittedly minimal ones) available but then removed. Feature dropped from future models, meaning no compatible replacement units for those who liked having this capability. Firmware development halted with a reasonable feature set, but with some capabilities people dreamed of seeing forever abandoned.
3) PS2 Backwards Compatibility. No features ever removed for those who had the capable units. Removed from all newer models, making those who liked this feature hard pressed to get a replacement for a failed unit. And again, development halted earlier than was expected once that happened. It's not hard to find someone ticked that some particular title they wanted to play was never fully made to work before Sony killed development of the feature.
I try to be fair, but doing this three times certainly is a pattern in how Sony treats non-core features in this product. If I were going for full-on angry troll, as a fan of the SACD format I actually have even more gripes with the whole thing that are less fair to assign blame for. I watched one of my favorite albums of all time fail to get a SACD release, because Sony decided to just abandon the format and killed the project. It's very sad given they were finally on the edge of getting a critical mass of capable players in the world, via all these people who purchased PS3s, and that might have finally made SACD a viable format had they just kept it up.
I guess instead now I get to look forward to Sony trying to sell me favorite albums, again, this time on one of the high resolution Blu-Ray audio formats instead.
Re:no, it's still there and it still works
on
PS3 Root Key Found
·
· Score: 5, Informative
To quote someone who said one correct thing today, "you really should consider making posts based upon facts". Read What difference does the firmware version make for CD and SA-CD? for an intro to the firmware issues I was speaking of. I know people who purchased the PS3 when firmware V2.00 added optical output for the format, only to find that capability taken away in the next revision. Since firmware upgrades are not optional if you want to stay on PSN, that's a clear bait and switch move. And if you read through the whole FAQ you can see some of the other limitations that come from Sony giving up on development here before the feature ever really worked perfectly.
I purchased about 20 new SACDs in 2010, from companies like Mobile Fidelity and via the SHM-SACD remasters. That gives me about 80 of them total. Since some of these are the highest quality recordings available, they get an inordinate amount of playtime here relative to the rest of my music collection.
See activity on SA-CD.net to see that many people are still actively using the format, and how many titles are available. Yes, there are probably only a few hundred people in the world impacted by Sony's SACD on PS3 decisions. That doesn't mean those people were not misled about Sony's commitment to supporting the format well in the PS3. I never claimed there were a "mountain" of such people, merely that the mechanics of how they were treated is similar to the situation with both backward compatibility and the Other OS features. This is a regularly recurring behavior from Sony.
One problem is that because the capability has been removed from all current models, if your early model breaks you could easily find yourself in a situation where it's not feasible to replace. Another is that since they dropped the feature, work on adding support for more games stopped too.
Another thing on the bait and switch pile is Sony's support for SACD. That was also available in the early models, then cut from the later ones. While it theoretically still works for people who have older units, the firmware isn't very good, and because they dropped the feature they also stopped development on improvements to that. So people who bought their PS3 expecting that to work right as a long-term capability have also been screwed.
Someone did get out their checkbook, which is why MERGE has been under development for months already, with working prototypes being tested since late August. The hope is that this makes it into PostgreSQL 9.1, due to be released next summer. Right now trivial cases work, the main bugs found in the last round of review involve concurrency issues that are still being ironed out.
Tuscan Dairy Farms. Only sold in the area around New York City, from north New Jersey out to Long Island, but fairly popular there; drank many gallons of it during the years I lived there. The idea of buying milk online from Amazon and having it delivered was always is a bit odd, even before the spoof reviews started.
There are all sorts of common database paths where slow cores are troublesome. Acquiring locks, access to shared memory, writes to redo logs; these are all examples of things that can end up serializing more than is optimal if individual cores are slow. Because of this, half as many cores that run at twice the speed is not the same net speed; it's probably faster, because each process is introducing less contention. Reducing the time things hold onto shared resources is really important for database workloads, and the easiest way to do that is to make the cores so fast they get in and out of holding access to those resources as quickly as possible.
This is not at all limited to Oracle either. I used to have a Sun Fire T2000 server using the 32-thread UltraSPARC T1 chip at my office. Running PostgreSQL, that system was trounced every time we compared it to x64 systems from Intel and AMD with much lower core counts but higher clocks. Sun released some specific compiler tuning magic for MySQL to make it perform better on that processor that helped. It sounds like after looking at the same trade-offs here, Oracle has decided to just go for the traditional solution--faster cores--rather than to try and optimize their software design for the processors. Can't say I blame them.
How can you write a historical description of Geocities and not mention the BLINK tag? The constant threat of epileptic seizure is part of what made that site great.
It makes every process spawned by the user that passes through the bash shell add their process ID to a per-user task control group. See the documentation on control groups for more information about exactly what that means, and what what some of the commands involved aim to do. I'm not sure if this is exactly the same impact as the kernel-level patch, which aimed at per-TTY control groups. That might includes some processes that don't pass through something that executes the.bashrc file along the way.
From the standard RHEL channel, there is a postgresql84 package available for RHEL5 that swaps the stock PostgreSQL 8.1 for 8.4, introduced during the version 5.5 update of RHEL. That's the precedent I was citing.
Re:Could have included more updated packages...
on
Red Hat Releases RHEL 6
·
· Score: 2, Informative
RedHat eventually added PostgreSQL 8.4 as an option for RHEL5, so it wouldn't be surprising to find that eventually they decide to make 9.0 (or 9.1) available for RHEL6. This really isn't as big of an issue as people think though. One of the PostgreSQL core team members is employed by RedHat, and the updated PostgreSQL packages available from their yum repo are extremely close to the RHEL builds. The same group of people is involved in the packaging and version updates, and the PostgreSQL yum repo is kept as current with security fixes as the RHEL releases of that same version are.
Interesting bit of code, and well done to hash that out so fast. But tail doesn't work like that. It seeks to the end of the file, and works backwards from there in blocks. Like most re-implementations of the seemingly simple UNIX utilities, the one you've done here will be thrashed in a head-to-head performance test on real-world sized files, because you're reading forward from the beginning by character. That's actually demonstrating exactly why "Taco Bell Programming" can be deceptively powerful. The actual implementation details under the hood and feature sets of some of the basic UNIX and GNU tools are much more sophisticated than they appear. Had I been throwing you down a "beat this in C" example, it would have been one of the common ways I use egrep to find things in log files, and there you'd be hard harder pressed to match either the feature set or the performance of the shell result even given days of coding. That thing is way more sophisticated in how it works than any simple implementation could reinvent without a whole lot of work.
There may be some trivial cases where doing a Dropbox sync would be easier, sure. As I don't trust maintenance, or even possession, of my important information to a third party, doing so just for a small improvement in ease of use isn't a good trade in my opinion.
As for more effective, the minute you have a merge conflict where you happened to modify the same file on more than one computer, any small advantage Dropbox has in the simple case is gone.
If someone doesn't have a programming background, and therefore the whole concepts behind version control and text merging are foreign, then perhaps a simple file sync solution would be better. But that didn't seem the context this question was being asked in.
Right basic idea, but not CVS or SVN. Use a distributed version control system like git. Create subdirectories for everything. Put every file that's important to you in there. Make the directory tree the organizational structure. Move stuff around as you see fit if the structure isn't working for you.
That's how I've gotten every important bit of information I've ever collected in my life all in one place. And every copy I check out, on every computer I own, is yet another backup. I'd never trust a single centralized repo for this job. Also, a distributed VCS means that you can work and commit changes on any system, with some hope of merging change conflicts. One system should be the nominal "master" you synchronize every other around, but if it's lost no big deal; just promote another copy to that role, and let switch other systems to checking out from it instead.
The other trick I've adopted to is to write all text file notes in ReST markup. It makes for a structure that tends to be more readable anyway, and I need to turn one of them into something more formal, or print a nice looking copy, the work to do so is trivial.
Many cheap hosting companies don't offer PostgreSQL because there's not enough demand for it; there's not enough demand because people don't know where to host the result, and therefore don't develop against it. You have to break that dependency one person at a time to start reversing the network effect here. There's a list of PostgreSQL Hosting companies that includes multiple entries in the sub $10/month range. So while it's still true that most cheap hosting companies don't support it yet, if you demand true software freedom from your database there are inexpensive hosting options available. And more people are waking up to realize this is an important enough reason to start migrating to PostgreSQL every day.
The 3M Ergonomic Mouse is another alternative that might work well for mouse/wrist issues. It keeps those stable, instead using your elbow and shoulder for movement. Only available for right-handed use. I've been much happier with 3M's product than the conceptually similar Evoluent VerticalMouse, mainly because the 3M stick uses a completely different set of muscles. The VerticalMouse might work OK for wrist issues, but it's easy to just move your injury to somewhere else that's weak from years of mouse abuse, because it's not really that different.
Someone might suggest a trackball next. When I last had wrist issues, those didn't help at all. Way too many muscles close to the injured ones involved in using one of those.
Performance level instrumentation for PostgreSQL is normally collected with kernel-level tools including oprofile and DTrace. The overhead for collecting it with those two is really not that bad, only a few percent on most workloads. About the only place you can really see bad instrumentation in PostgreSQL is when you're running EXPLAIN ANALYZE to get really detailed timestamp level information about every row processed by a query. That can execute dramatically slower than the uninstrumented query.
Re:I think Sun was giving them access to some...
on
PostgreSQL 9.0 Released
·
· Score: 3, Informative
The servers Sun supplied that Oracle recently yanked were for the regular PostgreSQL build farm, used to run basic regression tests. They've since been replaced, the project is unmoved. As I mention in more detail in my upthread post, work on the PostgreSQL performance farm continues unaffected by that. It is expected that some build farm machines will also run the performance farm client periodically too, that's the only overlap there ever was between the two pieces of work. If Oracle still had hardware in the build farm it could have been used for performance tests too eventually. But they don't, and we in the PostgreSQL community don't care; we don't need their contributions.
You've got the performance part backwards for PostgreSQL; it goes up with every release, sometimes a little, sometimes in a big way. See PostgreSQL history for a comparison covering versions 8.0 to 8.4. The mild regression in 8.4 shown there is actually reversible; it's mainly because a query related parameter for how many statistics to collect and use for query planning was increased by default. That results in better plans for most real-world queries, but it detuned this trivial benchmark a little bit. You can get performance back to 8.3 levels just by turning the parameter back to the "optimized for trivial queries" default of the older versions if you care about that. Most people prefer the new default. In the real world, 8.4 is actually faster due to improved handling of background VACUUM tasks too, which don't show up in simple benchmarks either.
I'm the current lead architect on building a PostgreSQL Performance Farm to prevent regressions from popping into future versions of the code too. There is a recently completed beta client for that purpose. We're in the process of working out how to integrate into future development, starting with 9.1, so that potential regressions are spotted on a commit by commit basis. I haven't seen any performance regressions between 8.4 and 9.0, only moderate improvements overall and large ones in specific areas that were accelerated.
Now, if you use some of the new replication features aggressively, that can add some overhead to slow down the master. But that's true of most solution; the data coming off the master has to take up some time to generate. The way PostgreSQL 9.0 does it is is pretty low overhead, it just ships the changed blocks around. Theoretically some statement based solutions might have lower overhead, but they usually come with concerns about non-determinism on the slaves when replayed (random numbers, timestamps, and sequence numbers are common examples).
Given the non-disclosure terms of most of the closed source databases, nobody can publish benchmarks that include them without going through something like the TPC or SPEC process. The last time that was done in 2007, PostgreSQL 8.2 was about 15% slower than Oracle running the same database-heavy workload. And note that it was PostgreSQL 8.3 that had one of the larger performance increases, so that was from just before a large leap forward in PostgreSQL performance.
At this point, Oracle and most other commercial databases still have a large lead on some of the queries run in the heavier TPC-H benchmarks. Links to more details as to why are on the PostgreSQL wiki. It just hasn't been a priority for development to accelerate all of the types of queries required to do well in that benchmark, and nobody so far has been willing to fund that or the subsequent certification via the TPC yet. Sun was the only one throwing money in that direction, and obviously the parts of that left within Oracle will no longer do so.
Have you looked at Archiveopteryx? That is one potential solution to the storage side of the problem. It stores the messages into a PostgreSQL database with minimal tinkering, so you can always get the original plain text stuff back out again. Consider it a database of mbox files that exposes an IMAP interface. You can't get any less proprietary than Postgres, and you can scale up many of its operations using standard database approaches in that area.
What I would do here is store messages there as my permanent store for them, dump periodically to full plain-text backups just for disaster recovery, then experiment with search software that runs on top of it using IMAP as the transport. There I don't have any specific advice. Ultimately it should be possible to extend Archiveopteryx to handle that too--PostgreSQL has decent full-text search built in--but I don't know of anybody working on that.
Probably easier to break this into two pieces, get a robust solution for the storage side, and then see what clients have search capabilities you like that won't choke on importing your data.
I'm qualified to work at RethinkDB; while I work with database internals (PostgreSQL) all day and used to do some Linux kernel hacking, I do think SQL is a terribly designed language. And I'm already optimizing hybrid systems with SSD elements for crucial database portions. Regardless, the idea that you should reject SQL-like thinking, and also limit yourself to optimizing exclusively for SSDs--which the largest databases customers can never do given they just don't hold enough--basically means they cannot convert anyone with real money to use their product easily, even if it does work well in its very specific niche. I'd consider going to work there career suicide. There are no serious sales prospects for what they're doing, and you'd be too out of touch with the mainstream after the company flops to transition back to a traditional job easily.
I once applied for a job where the main work was in Java, but they had some silly ColdFusion crap mixed in too you had to deal with. I told them flat out I didn't know anything about it, but the technology was so trivial I'd just pick it up as needed. Instead they hired somebody with mediocre Java skills but who had actual ColdFusion experience too. I told them to fuck off when they called back a few months later, after letting that guy go because he really couldn't get any complicated coding done.
Also, since when isn't iPhone jailbreaking associated with piracy?
I know more people who have done jailbreaking for things like tethering than piracy. Regardless, when you've got the Library of Congress ruling that it's a legitimate behavior, that's further distanced the two.
The "jailbreak" terminology came from chroot jail, which is a UNIX feature that constricts a user to run with limited ability to see files on the system. Since this was essentially the way the iPhone was being protected from hacking, it was an appropriate term to use for breaking out of their form of jail. It's not technically correct at all as a way to describe the Sony hacks, but that won't stop people from adopting it anyway because it sounds cool. (See the mainstream use of "hackers" rather than "crackers" as a precedent for bad terminology winning when it sounds more bad-ass)
Slashdot Mirror
This is where the risk/reward idea alluded to in the article comes into play. There are play strategies that will maximize your score on average, but are slightly more dangerous. Let's say these work 10% of the time, increasing your score by 20%, and the other 90% of the time they crash and burn. Almost all of the time, this a losing approach. The more conservative player will avoid these, because it means almost all of your games are useless. But eventually, someone playing with that aggressive style will stumble on the magic game where enough risky gambits go their way, if they just keep playing over and over again without any concern for typical performance. Now, the real numbers aren't like that; it might be a 1% reward for a 10% risk instead. But there's just now getting to be enough games played at this level to start even estimating statistics like that.
I suspect this is why Billy Mitchell remains such a overconfident guy here. He has such a head start on the others working this problem I expect he already has the more aggressive play worked out. He just ramps up use of those techniques as needed when the competitors catch up with him again. He's just the sort of dick to have worked all that out twenty years ago, and is just reeling out the knowledge as needed. I actually like the guy for the way he's a devious no holds-barred competitor. Messing with your opponents psyche by things like quitting your game the minute you've beat their old score is a classic all out technique.
In addition to whether the feature itself works or not, one of the selling points of the PS3 was how Sony presented the idea that it was going to be upgraded regularly to work around the issues it did have. The theory was their overpowered hardware had enough headroom to allow just software upgrades to unlock more potential, and some buyers invested in the unit on the promise the early bugs and limitations would eventually be righted.
In the most extreme example, if Sony had stopped releasing new firmware releases for Blu-ray disks, all owners would be screwed because newer titles wouldn't work right? That's the understanding implicit in the product. You're buying something that may have limitations, but you're going to get regular updates to continue to move forward. All part of the PS3 promise. And dropping development on some aspect, even if the early version of the feature continued to work in the form it shipped in, does represent a disappointing break in those expectations. They've done a better job than I expected at keeping the PS3 a good Blu-Ray player, but all of its other non-gaming use withered relative to its potential.
There's a hierarchy of badness here:
1) OtherOS: Removed from all units retroactively and with no workaround. Complete bait and switch.
2) SACD: Some features (admittedly minimal ones) available but then removed. Feature dropped from future models, meaning no compatible replacement units for those who liked having this capability. Firmware development halted with a reasonable feature set, but with some capabilities people dreamed of seeing forever abandoned.
3) PS2 Backwards Compatibility. No features ever removed for those who had the capable units. Removed from all newer models, making those who liked this feature hard pressed to get a replacement for a failed unit. And again, development halted earlier than was expected once that happened. It's not hard to find someone ticked that some particular title they wanted to play was never fully made to work before Sony killed development of the feature.
I try to be fair, but doing this three times certainly is a pattern in how Sony treats non-core features in this product. If I were going for full-on angry troll, as a fan of the SACD format I actually have even more gripes with the whole thing that are less fair to assign blame for. I watched one of my favorite albums of all time fail to get a SACD release, because Sony decided to just abandon the format and killed the project. It's very sad given they were finally on the edge of getting a critical mass of capable players in the world, via all these people who purchased PS3s, and that might have finally made SACD a viable format had they just kept it up.
I guess instead now I get to look forward to Sony trying to sell me favorite albums, again, this time on one of the high resolution Blu-Ray audio formats instead.
To quote someone who said one correct thing today, "you really should consider making posts based upon facts". Read What difference does the firmware version make for CD and SA-CD? for an intro to the firmware issues I was speaking of. I know people who purchased the PS3 when firmware V2.00 added optical output for the format, only to find that capability taken away in the next revision. Since firmware upgrades are not optional if you want to stay on PSN, that's a clear bait and switch move. And if you read through the whole FAQ you can see some of the other limitations that come from Sony giving up on development here before the feature ever really worked perfectly.
I purchased about 20 new SACDs in 2010, from companies like Mobile Fidelity and via the SHM-SACD remasters. That gives me about 80 of them total. Since some of these are the highest quality recordings available, they get an inordinate amount of playtime here relative to the rest of my music collection.
See activity on SA-CD.net to see that many people are still actively using the format, and how many titles are available. Yes, there are probably only a few hundred people in the world impacted by Sony's SACD on PS3 decisions. That doesn't mean those people were not misled about Sony's commitment to supporting the format well in the PS3. I never claimed there were a "mountain" of such people, merely that the mechanics of how they were treated is similar to the situation with both backward compatibility and the Other OS features. This is a regularly recurring behavior from Sony.
One problem is that because the capability has been removed from all current models, if your early model breaks you could easily find yourself in a situation where it's not feasible to replace. Another is that since they dropped the feature, work on adding support for more games stopped too.
Another thing on the bait and switch pile is Sony's support for SACD. That was also available in the early models, then cut from the later ones. While it theoretically still works for people who have older units, the firmware isn't very good, and because they dropped the feature they also stopped development on improvements to that. So people who bought their PS3 expecting that to work right as a long-term capability have also been screwed.
Someone did get out their checkbook, which is why MERGE has been under development for months already, with working prototypes being tested since late August. The hope is that this makes it into PostgreSQL 9.1, due to be released next summer. Right now trivial cases work, the main bugs found in the last round of review involve concurrency issues that are still being ironed out.
Tuscan Dairy Farms. Only sold in the area around New York City, from north New Jersey out to Long Island, but fairly popular there; drank many gallons of it during the years I lived there. The idea of buying milk online from Amazon and having it delivered was always is a bit odd, even before the spoof reviews started.
There are all sorts of common database paths where slow cores are troublesome. Acquiring locks, access to shared memory, writes to redo logs; these are all examples of things that can end up serializing more than is optimal if individual cores are slow. Because of this, half as many cores that run at twice the speed is not the same net speed; it's probably faster, because each process is introducing less contention. Reducing the time things hold onto shared resources is really important for database workloads, and the easiest way to do that is to make the cores so fast they get in and out of holding access to those resources as quickly as possible.
This is not at all limited to Oracle either. I used to have a Sun Fire T2000 server using the 32-thread UltraSPARC T1 chip at my office. Running PostgreSQL, that system was trounced every time we compared it to x64 systems from Intel and AMD with much lower core counts but higher clocks. Sun released some specific compiler tuning magic for MySQL to make it perform better on that processor that helped. It sounds like after looking at the same trade-offs here, Oracle has decided to just go for the traditional solution--faster cores--rather than to try and optimize their software design for the processors. Can't say I blame them.
How can you write a historical description of Geocities and not mention the BLINK tag? The constant threat of epileptic seizure is part of what made that site great.
It makes every process spawned by the user that passes through the bash shell add their process ID to a per-user task control group. See the documentation on control groups for more information about exactly what that means, and what what some of the commands involved aim to do. I'm not sure if this is exactly the same impact as the kernel-level patch, which aimed at per-TTY control groups. That might includes some processes that don't pass through something that executes the .bashrc file along the way.
From the standard RHEL channel, there is a postgresql84 package available for RHEL5 that swaps the stock PostgreSQL 8.1 for 8.4, introduced during the version 5.5 update of RHEL. That's the precedent I was citing.
RedHat eventually added PostgreSQL 8.4 as an option for RHEL5, so it wouldn't be surprising to find that eventually they decide to make 9.0 (or 9.1) available for RHEL6. This really isn't as big of an issue as people think though. One of the PostgreSQL core team members is employed by RedHat, and the updated PostgreSQL packages available from their yum repo are extremely close to the RHEL builds. The same group of people is involved in the packaging and version updates, and the PostgreSQL yum repo is kept as current with security fixes as the RHEL releases of that same version are.
Interesting bit of code, and well done to hash that out so fast. But tail doesn't work like that. It seeks to the end of the file, and works backwards from there in blocks. Like most re-implementations of the seemingly simple UNIX utilities, the one you've done here will be thrashed in a head-to-head performance test on real-world sized files, because you're reading forward from the beginning by character. That's actually demonstrating exactly why "Taco Bell Programming" can be deceptively powerful. The actual implementation details under the hood and feature sets of some of the basic UNIX and GNU tools are much more sophisticated than they appear. Had I been throwing you down a "beat this in C" example, it would have been one of the common ways I use egrep to find things in log files, and there you'd be hard harder pressed to match either the feature set or the performance of the shell result even given days of coding. That thing is way more sophisticated in how it works than any simple implementation could reinvent without a whole lot of work.
There may be some trivial cases where doing a Dropbox sync would be easier, sure. As I don't trust maintenance, or even possession, of my important information to a third party, doing so just for a small improvement in ease of use isn't a good trade in my opinion.
As for more effective, the minute you have a merge conflict where you happened to modify the same file on more than one computer, any small advantage Dropbox has in the simple case is gone.
If someone doesn't have a programming background, and therefore the whole concepts behind version control and text merging are foreign, then perhaps a simple file sync solution would be better. But that didn't seem the context this question was being asked in.
Right basic idea, but not CVS or SVN. Use a distributed version control system like git. Create subdirectories for everything. Put every file that's important to you in there. Make the directory tree the organizational structure. Move stuff around as you see fit if the structure isn't working for you.
That's how I've gotten every important bit of information I've ever collected in my life all in one place. And every copy I check out, on every computer I own, is yet another backup. I'd never trust a single centralized repo for this job. Also, a distributed VCS means that you can work and commit changes on any system, with some hope of merging change conflicts. One system should be the nominal "master" you synchronize every other around, but if it's lost no big deal; just promote another copy to that role, and let switch other systems to checking out from it instead.
The other trick I've adopted to is to write all text file notes in ReST markup. It makes for a structure that tends to be more readable anyway, and I need to turn one of them into something more formal, or print a nice looking copy, the work to do so is trivial.
Many cheap hosting companies don't offer PostgreSQL because there's not enough demand for it; there's not enough demand because people don't know where to host the result, and therefore don't develop against it. You have to break that dependency one person at a time to start reversing the network effect here. There's a list of PostgreSQL Hosting companies that includes multiple entries in the sub $10/month range. So while it's still true that most cheap hosting companies don't support it yet, if you demand true software freedom from your database there are inexpensive hosting options available. And more people are waking up to realize this is an important enough reason to start migrating to PostgreSQL every day.
The 3M Ergonomic Mouse is another alternative that might work well for mouse/wrist issues. It keeps those stable, instead using your elbow and shoulder for movement. Only available for right-handed use. I've been much happier with 3M's product than the conceptually similar Evoluent VerticalMouse, mainly because the 3M stick uses a completely different set of muscles. The VerticalMouse might work OK for wrist issues, but it's easy to just move your injury to somewhere else that's weak from years of mouse abuse, because it's not really that different.
Someone might suggest a trackball next. When I last had wrist issues, those didn't help at all. Way too many muscles close to the injured ones involved in using one of those.
Performance level instrumentation for PostgreSQL is normally collected with kernel-level tools including oprofile and DTrace. The overhead for collecting it with those two is really not that bad, only a few percent on most workloads. About the only place you can really see bad instrumentation in PostgreSQL is when you're running EXPLAIN ANALYZE to get really detailed timestamp level information about every row processed by a query. That can execute dramatically slower than the uninstrumented query.
The servers Sun supplied that Oracle recently yanked were for the regular PostgreSQL build farm, used to run basic regression tests. They've since been replaced, the project is unmoved. As I mention in more detail in my upthread post, work on the PostgreSQL performance farm continues unaffected by that. It is expected that some build farm machines will also run the performance farm client periodically too, that's the only overlap there ever was between the two pieces of work. If Oracle still had hardware in the build farm it could have been used for performance tests too eventually. But they don't, and we in the PostgreSQL community don't care; we don't need their contributions.
You've got the performance part backwards for PostgreSQL; it goes up with every release, sometimes a little, sometimes in a big way. See PostgreSQL history for a comparison covering versions 8.0 to 8.4. The mild regression in 8.4 shown there is actually reversible; it's mainly because a query related parameter for how many statistics to collect and use for query planning was increased by default. That results in better plans for most real-world queries, but it detuned this trivial benchmark a little bit. You can get performance back to 8.3 levels just by turning the parameter back to the "optimized for trivial queries" default of the older versions if you care about that. Most people prefer the new default. In the real world, 8.4 is actually faster due to improved handling of background VACUUM tasks too, which don't show up in simple benchmarks either.
I'm the current lead architect on building a PostgreSQL Performance Farm to prevent regressions from popping into future versions of the code too. There is a recently completed beta client for that purpose. We're in the process of working out how to integrate into future development, starting with 9.1, so that potential regressions are spotted on a commit by commit basis. I haven't seen any performance regressions between 8.4 and 9.0, only moderate improvements overall and large ones in specific areas that were accelerated.
Now, if you use some of the new replication features aggressively, that can add some overhead to slow down the master. But that's true of most solution; the data coming off the master has to take up some time to generate. The way PostgreSQL 9.0 does it is is pretty low overhead, it just ships the changed blocks around. Theoretically some statement based solutions might have lower overhead, but they usually come with concerns about non-determinism on the slaves when replayed (random numbers, timestamps, and sequence numbers are common examples).
Given the non-disclosure terms of most of the closed source databases, nobody can publish benchmarks that include them without going through something like the TPC or SPEC process. The last time that was done in 2007, PostgreSQL 8.2 was about 15% slower than Oracle running the same database-heavy workload. And note that it was PostgreSQL 8.3 that had one of the larger performance increases, so that was from just before a large leap forward in PostgreSQL performance.
At this point, Oracle and most other commercial databases still have a large lead on some of the queries run in the heavier TPC-H benchmarks. Links to more details as to why are on the PostgreSQL wiki. It just hasn't been a priority for development to accelerate all of the types of queries required to do well in that benchmark, and nobody so far has been willing to fund that or the subsequent certification via the TPC yet. Sun was the only one throwing money in that direction, and obviously the parts of that left within Oracle will no longer do so.
Have you looked at Archiveopteryx? That is one potential solution to the storage side of the problem. It stores the messages into a PostgreSQL database with minimal tinkering, so you can always get the original plain text stuff back out again. Consider it a database of mbox files that exposes an IMAP interface. You can't get any less proprietary than Postgres, and you can scale up many of its operations using standard database approaches in that area.
What I would do here is store messages there as my permanent store for them, dump periodically to full plain-text backups just for disaster recovery, then experiment with search software that runs on top of it using IMAP as the transport. There I don't have any specific advice. Ultimately it should be possible to extend Archiveopteryx to handle that too--PostgreSQL has decent full-text search built in--but I don't know of anybody working on that.
Probably easier to break this into two pieces, get a robust solution for the storage side, and then see what clients have search capabilities you like that won't choke on importing your data.
To provide some better references to what you've said here: the article PostgreSQL 8.4: Common Table Expressions (CTE)... covers this feature in PostgreSQL, and includes links to the documentation of other database products that support this feature to compare against. Same author also did Using recursive CTEs to represent tree structures on this topic.
I'm qualified to work at RethinkDB; while I work with database internals (PostgreSQL) all day and used to do some Linux kernel hacking, I do think SQL is a terribly designed language. And I'm already optimizing hybrid systems with SSD elements for crucial database portions. Regardless, the idea that you should reject SQL-like thinking, and also limit yourself to optimizing exclusively for SSDs--which the largest databases customers can never do given they just don't hold enough--basically means they cannot convert anyone with real money to use their product easily, even if it does work well in its very specific niche. I'd consider going to work there career suicide. There are no serious sales prospects for what they're doing, and you'd be too out of touch with the mainstream after the company flops to transition back to a traditional job easily.
I once applied for a job where the main work was in Java, but they had some silly ColdFusion crap mixed in too you had to deal with. I told them flat out I didn't know anything about it, but the technology was so trivial I'd just pick it up as needed. Instead they hired somebody with mediocre Java skills but who had actual ColdFusion experience too. I told them to fuck off when they called back a few months later, after letting that guy go because he really couldn't get any complicated coding done.
Also, since when isn't iPhone jailbreaking associated with piracy?
I know more people who have done jailbreaking for things like tethering than piracy. Regardless, when you've got the Library of Congress ruling that it's a legitimate behavior, that's further distanced the two.
The "jailbreak" terminology came from chroot jail, which is a UNIX feature that constricts a user to run with limited ability to see files on the system. Since this was essentially the way the iPhone was being protected from hacking, it was an appropriate term to use for breaking out of their form of jail. It's not technically correct at all as a way to describe the Sony hacks, but that won't stop people from adopting it anyway because it sounds cool. (See the mainstream use of "hackers" rather than "crackers" as a precedent for bad terminology winning when it sounds more bad-ass)