I observed that, I just wanted to stop and question your assumptions around why to pull in another database at all. Thank you for answering that clearly.
If your backend is something as developer oriented as PostgreSQL, are all sorts of interesting but not very well known things you can do there. You can push the difficult cache invalidation issues that always pop up in the top layer directly into triggers. If a piece of work turns out to have larger implications than you want to deal with right there, you can use the LISTEN/NOTIFY interface to kick off asynchronous work. And that work doesn't even necessarily have to happen on the server. Add in the Foreign Data Wrapper feature, and you can farm things out very easily to arbitrary worker nodes, including ones built with other database technologies. Make the worker another PostgreSQL database (presumably optimized for different purposes) with postgres_fdw, and you can even get the information it knows to percolate upward into top level query planning--while low level execution happens elsewhere.
PostgreSQL has a lot of these interesting features that let you build more complicated architectures. The minute you add another database layer in front of that, you've done something akin to dumbing down the API available. If I build a 3-tier system, it's usually a memcache style layer at top, PostgreSQL as the full featured middle, and something else below there--but under Postgres's control. This is nice from the perspective that until you really need it (when a light system will do) you don't necessarily even need to add the second database into the mix. When it does show up, you can hide it either with FDW or within Postgres's ability to have functions in most popular programming languages, and maybe not even have to tough the top layer to do so.
Take this philosophy far enough and you can end up with something like Skype's PostgreSQL installation, where exactly how/where the data underneath is stored is done via pl/proxy. Whenever I see people start on the "but PostgreSQL alone will never be fast enough for my web scale app" I ask them if they're more popular than Skype. If not, you can probably ignore using MySQL or NoSQL altogether if you're clever about it.
MariaDB is requiring that contributions have their copyright assigned to the latest MontyScamAB or whatever it's called. Monty likes to mess with the licensing on the client side as a way to get leverage on people, and there's already a new client with a messy license history to advance that.
Eventually they will have enough new code that they can build dual-licensed client or administration add-ons that interface with the GPL center, and then put critical features for non-trivial use cases into those. The last time they ran the add-on scam, they left the backup capabilities in the free version crippled such that you had to buy the Enterprise version to get backup tools that actually worked well. And yet people are falling for every part of this con again, having paid no attention to what happened the last time.
Here's an edited version, which I wanted to make before sharing it further (thanks!):
1. Create a popular but flawed FLOSS product (MySQL). 2. Build a business atop flawed FLOSS product (MySQL AB). 3. Ca$h out by selling your baby to formerly glorious tech company on the ropes (FGTCOTR, aka Sun). 4. Profit! 5. Leave FGTCOTR after a tasteful waiting period to start your own company DOING THE SAME THING YOU JUST SOLD because you can fork the OSS codebase you just sold. 6. Petition government (the European Commission) to try and prevent EVIL Corp (who very predictably want to acquire FGTCOTR) from acquiring your already sold baby as part of the deal, to make it more expensive for them to acquire. 7. Take public potshots at EVIL Corp for mismanaging the baby you sold (because EVIL), while flogging your fork of the product you sold as a viable alternative (FLOSS, to cloak yourself in the veneer of legitimacy because you can live off of steps 3 and 4). 8. Reunite to form company that does the same thing the company you sold for big $$$ did, to compete with the product you willingly relinquished control over. 9. GOTO #1?
Let us say that was true. (It isn't, but let's pretend.) MySQL is faster than PostgreSQL or Ingres, correct? Then use PostgreSQL or Ingres for your primary storage DB, and use MySQL to store cached responses. (Key issues, etc, are then a non-issue - you don't need a vast key to identify a cached pre-generated page.)
Why use MySQL just to cache responses? People who use PostgreSQL for the backing store just put some memcache-style layer in front for that. That's even faster than MySQL, and you don't have the complexity of a second database to worry about. You can use something very database aware like pgmemcache. Most people pick their cache mechanism based on integration with their application development environment though. On Java use a cache that integrates well with Tomcat+Hibernate+JDBC, etc.
PostgreSQL has a secure by default stance that can be frustrating the first time you use it. When you start a server, it won't be open to the world and ready to serve queries. You'll have to configure exactly how much access you allow instead. If your only criteria is "which system can I get up and running with the least work?", and a lot of developers fall into that category, you will probably find the strictness of PostgreSQL forces you to do more work. There is a similar strictness with what data can and can't be inserted into the database. If you're using PostgreSQL, you better be ready to distinguish between an empty string and a null value for example. That detail will be important and one you have to manage the implications of. And MySQL will make assumptions to quietly convert data to another type so that your code runs, in many situations where PostgreSQL will force you to eliminate the ambiguity with direct type casting.
MySQL apps get built faster, but on a non-trivial database you're likely to spend the application's entire lifetime occasionally shaking out weird bugs due to invalid data. PostgreSQL has few easy "let me ignore this right now" shortcuts. You do things by what's considered the right way to the PostgreSQL contributors, which relies on things like the SQL standards for guidance, and that is your only option. If you only care about getting things done now by the quickest and easiest choice, with no regard to the future, you'll use MySQL. To return to the car analogy, are you the sort of person who likes to buy an expensive car now that will likely be reliable for a few years? Or do you want something that costs less up front, but you'll have to pay for service regularly? Some people want to get out the door and driving today with no money down, and that's a MySQL car.
In addition to integrity issue being likely to introduce bugs, the other downside to always taking the easy way out is that if your application's standards for data integrity go up later, you have nowhere to go. There's a long list of nasty MySQL limitations that are unlikely to ever be resolved. The learning curve for PostgreSQL is something you pay for once, and then benefit from forever.
MySQL got taken over by Oracle so the real development was forked with the new name of MariaDB.
No it didn't. MySQL was sold in a way that allowed Oracle to then purchase it. There's no reason to believe MariaDB will be any different. The fact that contributors to MariaDB have to assign their copyright to Monty's company says he's at least thinking about doing the same trick again.
I don't understand why people trust MariaDB either. The result the last time everyone jumped onto Monty's open-source ship? He cashed out and put all of his customers on a road that led to being screwed by Oracle. There's a bit of madness expecting different results adopting MariaDB I wouldn't buy into either.
Hint: when a contributor agreement like the MariaDB one says copyright must be assigned to "Monty Program AB", your contributors are usually being setup so that the owner of that copyright can then profit from the community's free work on the project, a decision that will be motivated by what's best for them. There are a few software projects that require copyright assignment that aren't doing that, like the gnu projects. Monty Program AB is not a non-profit with a decades long history of anti-commercialism like gnu though. It's a regular company run by someone who has screwed both his paying customers and his open-source user community exactly this way once. Why are people signing up such that he could do it again?
This project's innovation is noting that that GPUs have enough RAM now that you can push medium sized data sets into them if you have enough available. With lots of cores and high memory bandwidth, in-memory data sets in a GPU can do multi-core operations faster than in-memory data sets in a standard CPU/memory combination.
That's great for simple data operations that are easy to run in parallel and when the data set is small enough to fit in your available hardware. Break any of those assumptions, and you've got a whole different set of problems to solve than what this is good for. I suspect none of those three requirements hold in the usual case for what people want out of "big data".
seems easy enough to buy low and sell high, it's just a matter of watching the prices and being patient
Said every trading company in history that eventually blew up. One day you'll buy what you think is low, only to watch the market keep going lower. Perhaps it's genuine activity; it might be a larger player who is "running the stops", executing trades at low prices specifically to shake out casual players. You might have your program execute its version of a stop order only to discover there isn't a buyer. Finally your "I want to get out!" trade executes at some incredibly low price...and now you've lost all your profits and then some. If you're lucky you'll still have enough capital to risk trading more...but if you do return to the market with less capital, you'll be even more vulnerable to market churn.
Most trading systems that look profitable over time underestimate the odds of an unprecedented event--something never seen in the history of the exchange--and risk too much chasing returns. If you adjust your profit estimate for real-world volatility, which includes things like not being able to execute trades without a greater loss than expected, suddenly you're unprofitable. This is hard because if you're new to a market, you have zero chance of predicting in advance what its volatility will really look like--so any profit model you come up with will be wrong. The equities stock market watches someone hit a major blow-up like this about every ten years: Black Monday (1987), Long-Term Capital Management explosion (1998), and then the market crash of 2008. Even in that mature market, there's an unexpectedly large blow-up every ten years. With Bitcoins, the period between those looks like months.
Hint: when you turn a technical correction into a personal attack, you're being an asshole. Normally I just ignore assholes on Slashdot, but since you seem to be a reasonable poster most of the time I'll address the minor point you raise.
The issue was never whether I could get a system up and running once. It's about companies who feel they can arbitrarily alter their products after purchase, such that you have to just eat whatever shit they throw at you.
Yes, there have been a variety of ways to get a running copy of Windows that require less activation hassle. I know a few versions of the activation rules that have applied over time, how to get around some of them, and how to avoid the WGA notifier client. And, yes, the activation rules for XP Pro have been reasonable at some points in time. But I assumed from XP release day that Microsoft would eventually tighten them and break some systems that were functional, under the banner of anti-piracy. And that's exactly what happened in 2006 when KB905474 was pushed as a critical update.
The exact terms and enforcement for what makes a copy of Windows "Genuine" haven't been stable, and that was the first such major change to them. Microsoft still regularly rolls out updates to the WGA validation that change the rules. The latest text on that Wikipedia page even alludes to a recent "WGA update for Windows XP Professional" that alters how that OS is treated. You just quoted some activation rule of thumb at me. But did you check an XP Pro system today? Yesterday might have been a Patch Tuesday that grabbed new WGA code you know.
If you're fine with a Microsoft system pulling down updates that can alter if your OS is functional, ones that have the very real risk of deactivating it, good for you. I didn't care whether I could activate a system or not at a given point in time. The fact that a later update might deactivate one, via rules I could not predict, that was the thing that was unacceptable. When a software company issues a security update, it's a fix to a product that was sold with a defect. It's not an invitation to install extra crap or to disable features arbitrarily on my computer. It was bullshit when Microsoft does it, it was bullshit when Sony pulled Linux support on the PS3, and it's still bullshit now.
All of these firms must submit to financial audits by outside firms like one of the big 4 as well as frequent SEC random audits, so even making money they would be caught.
(Snort) Right. Search for information about the SEC with keywords "revolving door" and "document shredding" added and you'll see how this really works. The big firms get busted by the SEC about as often as they are nailed for off-shore tax schemes--neither ever happen with enough impact to matter. The worst the SEC does is issue them a few million in fines, like the recent HSBC case, which are just lumped in as cost of doing business relative to the profits earned. This guy's problem is just that he was working for too small of a company to be playing the game he picked.
He almost recreated the business model of every large bank. The missing step is that when you have a loss, you then ask for a bailout because it will hurt the economy if you fail.
Resistance to XP included the new product activation "feature". I stayed on Windows 2000 until its EOL in 2010 because Microsoft could decide your copy of Windows wasn't "Genuine" at any time and disable it, and those were unacceptable terms for me to run a business on. I'll only use Windows XP and 7 inside of a VM, where I can both easily take a snapshot of the system in a working state and move it onto new hardware without asking Microsoft for approval.
And they're not going to go for a small company's product or a free (e.g. Linux) replacement for Windows because there's nobody to sue if they fuck up your systems and stop critical business processes.
Like how Microsoft has fucked up Windows 8 and stopped critical business processes from working on it? Good luck with that lawsuit. This idea of companies making software decisions because they need someone to sue has always been ridiculous. I talk to a fair number of people going from Oracle to PostgreSQL who bring up this argument as a major issue in their way. I ask them if they can name a single instance where someone sued Oracle for releasing buggy software and won. The "need someone to sue" myth is even getting weaker lately, as many companies update their EULA so that individual users must accept arbitration. That's all about keeping them from jumping onto a class action lawsuit instead.
Liability insurance for developers does not cost very much. My consulting company has an insurance policy for the work we do, and the premium is based on how much money the company makes. I'm making enough to fund two full time people and my liability policy is around $1000 per year.
The biggest thing that keeps developers safe is the minimum legal costs of taking someone to court for long enough to sort out blame on a software project. If I botch $10K worth of development, it's impossible hire a legal team and beat it out of me with any real profit. I'd have to make a $100K mistake before I'd be worried someone might actually sue me for being incompetent.
Greater than 20% variation is the expected situation with capacitors. That's not a funny data point--that's the day to day reality of the job involved to go from lab prototype to large scale manufacturing of electronics.
Most of the broadband modem/router devices I see now have a little sticker with unique information like the SSID, MAC address, and WPA key printed on them. You could usefully improve things just by making the default router password be the WPA key. People you've given the WPA key to would then also be able to reconfigure the router in the default config, but that's basically how it works now. When I visit someone non-technical and they invite me to read the WPA key from the router, invariably once I'm on the network I find I can then administer the router using its default, shared by every model password.
It would be nice to have a separate admin password printed on the sticker though. The main problem with using one derived from information the client computers know is that trojans on those clients can still be smart enough to hack into the router they're behind, and then open up the whole network from there.
Because there are potentially large performance gains to be had in VMs running postgres by running a 3.x kernel, which CentOS doesn't use yet. Fedora or Ubuntu server are what i'm going to look at to see if it's of use to me.
This is an excellent example of why that sort of thing is avoided by risk-adverse deployments. Early adopters of PostgreSQL on various 3.X kernels are still seeing a variety of nasty kernel issues, and many of them are rolling back to the stable RHEL or Debian kernels based on 2.6.32 to avoid them. A good example is High CPU usage / load average after upgrading to Ubuntu 12.04. I'm tracking about 5 such PostgreSQL issues that only show up in 3.X kernels we're trying to get sorted out still. (I'm a PostgreSQL contributor) Yes, the 3.X kernels are faster in general, but they're still not very stable compared to the boring old ones in CentOS.
That Oracle supports running on btrfs isn't really a strong statement about its quality level for general use. btrfs aims to runs Oracle stably as its top development priority. Oracle doesn't require very many filesystem features. Some people run it happily on raw disk volumes. There's a good sized list of companies over the years that have built filesystems optimized for exactly type of workload Oracle creates. As an example, around 2006 I had a consulting job getting PostgreSQL to work well on a Linux system with the Veritas vxfs filesystem. Much of that tuning involved making the database's I/O look more like how Oracle writes things--things like using direct I/O instead of cached writes.
The problems get bad when you try to use btrfs for anything else. Repeat the same sort of experiment today, try and use PostgreSQL on btrfs for example, and you can expect btrfs will panic and corrupt itself under heavy load. The specific subset of filesystem read/write and caching behaviors Oracle expects may work, but the other read/write paths through the btrfs filesystem aren't nearly as well tested. Oracle's priorities for btrfs QA remind me of the old joke about Microsoft's monopoly abuse: "DOS Ain't Done til Lotus Won't Run".
Lack of useful backports to their LTS releases is the major reason I avoid Ubuntu Server. Canonical does some occasional updates to older LTS releases. But most of the time, the only suggested fix for bugs I see is "upgrade to the latest version of Ubuntu". They do not show nearly the same dedication to backporting bug fixes and nailing down a stable, well tested version of packages that I see from RedHat and Debian.
There are a lot of Lensmen similarities in "Star Wars". But since the Lensmen still haven't made into a proper movie, it doesn't make a good example of a film precursor. Someone watching "Star Wars" for the first time in 1977 was comparing it to SF movies like 2001, "Logan's Run", or "Close Encounters of the Third Kind"; lots of science, but no magic.
Comparing development cycles to mortgage back securities is a bit dramatic, don't you think...All the bubble did was weed out the wannabes from those that were established.
That is how the mortgage bubble worked too. There were a large number of banks that were viable only because they could make so much money just passing mortgages through to other people. And once the bubble popped, they started going out of business in droves, just like the.com companies did. Take a look at the failed bank list. It's a very similar pattern to the list of dead tech companies left in the wake of the 2000 tech bubble. The big established companies managed to hang on (Bank of America, Wells Fargo, Citibank, etc.) while little players were sunk in large quantities.
Slashdot Mirror
I observed that, I just wanted to stop and question your assumptions around why to pull in another database at all. Thank you for answering that clearly.
If your backend is something as developer oriented as PostgreSQL, are all sorts of interesting but not very well known things you can do there. You can push the difficult cache invalidation issues that always pop up in the top layer directly into triggers. If a piece of work turns out to have larger implications than you want to deal with right there, you can use the LISTEN/NOTIFY interface to kick off asynchronous work. And that work doesn't even necessarily have to happen on the server. Add in the Foreign Data Wrapper feature, and you can farm things out very easily to arbitrary worker nodes, including ones built with other database technologies. Make the worker another PostgreSQL database (presumably optimized for different purposes) with postgres_fdw, and you can even get the information it knows to percolate upward into top level query planning--while low level execution happens elsewhere.
PostgreSQL has a lot of these interesting features that let you build more complicated architectures. The minute you add another database layer in front of that, you've done something akin to dumbing down the API available. If I build a 3-tier system, it's usually a memcache style layer at top, PostgreSQL as the full featured middle, and something else below there--but under Postgres's control. This is nice from the perspective that until you really need it (when a light system will do) you don't necessarily even need to add the second database into the mix. When it does show up, you can hide it either with FDW or within Postgres's ability to have functions in most popular programming languages, and maybe not even have to tough the top layer to do so.
Take this philosophy far enough and you can end up with something like Skype's PostgreSQL installation, where exactly how/where the data underneath is stored is done via pl/proxy. Whenever I see people start on the "but PostgreSQL alone will never be fast enough for my web scale app" I ask them if they're more popular than Skype. If not, you can probably ignore using MySQL or NoSQL altogether if you're clever about it.
MariaDB is requiring that contributions have their copyright assigned to the latest MontyScamAB or whatever it's called. Monty likes to mess with the licensing on the client side as a way to get leverage on people, and there's already a new client with a messy license history to advance that.
Eventually they will have enough new code that they can build dual-licensed client or administration add-ons that interface with the GPL center, and then put critical features for non-trivial use cases into those. The last time they ran the add-on scam, they left the backup capabilities in the free version crippled such that you had to buy the Enterprise version to get backup tools that actually worked well. And yet people are falling for every part of this con again, having paid no attention to what happened the last time.
Here's an edited version, which I wanted to make before sharing it further (thanks!):
1. Create a popular but flawed FLOSS product (MySQL).
2. Build a business atop flawed FLOSS product (MySQL AB).
3. Ca$h out by selling your baby to formerly glorious tech company on the ropes (FGTCOTR, aka Sun).
4. Profit!
5. Leave FGTCOTR after a tasteful waiting period to start your own company DOING THE SAME THING YOU JUST SOLD because you can fork the OSS codebase you just sold.
6. Petition government (the European Commission) to try and prevent EVIL Corp (who very predictably want to acquire FGTCOTR) from acquiring your already sold baby as part of the deal, to make it more expensive for them to acquire.
7. Take public potshots at EVIL Corp for mismanaging the baby you sold (because EVIL), while flogging your fork of the product you sold as a viable alternative (FLOSS, to cloak yourself in the veneer of legitimacy because you can live off of steps 3 and 4).
8. Reunite to form company that does the same thing the company you sold for big $$$ did, to compete with the product you willingly relinquished control over.
9. GOTO #1?
Let us say that was true. (It isn't, but let's pretend.) MySQL is faster than PostgreSQL or Ingres, correct? Then use PostgreSQL or Ingres for your primary storage DB, and use MySQL to store cached responses. (Key issues, etc, are then a non-issue - you don't need a vast key to identify a cached pre-generated page.)
Why use MySQL just to cache responses? People who use PostgreSQL for the backing store just put some memcache-style layer in front for that. That's even faster than MySQL, and you don't have the complexity of a second database to worry about. You can use something very database aware like pgmemcache. Most people pick their cache mechanism based on integration with their application development environment though. On Java use a cache that integrates well with Tomcat+Hibernate+JDBC, etc.
PostgreSQL has a secure by default stance that can be frustrating the first time you use it. When you start a server, it won't be open to the world and ready to serve queries. You'll have to configure exactly how much access you allow instead. If your only criteria is "which system can I get up and running with the least work?", and a lot of developers fall into that category, you will probably find the strictness of PostgreSQL forces you to do more work. There is a similar strictness with what data can and can't be inserted into the database. If you're using PostgreSQL, you better be ready to distinguish between an empty string and a null value for example. That detail will be important and one you have to manage the implications of. And MySQL will make assumptions to quietly convert data to another type so that your code runs, in many situations where PostgreSQL will force you to eliminate the ambiguity with direct type casting.
MySQL apps get built faster, but on a non-trivial database you're likely to spend the application's entire lifetime occasionally shaking out weird bugs due to invalid data. PostgreSQL has few easy "let me ignore this right now" shortcuts. You do things by what's considered the right way to the PostgreSQL contributors, which relies on things like the SQL standards for guidance, and that is your only option. If you only care about getting things done now by the quickest and easiest choice, with no regard to the future, you'll use MySQL. To return to the car analogy, are you the sort of person who likes to buy an expensive car now that will likely be reliable for a few years? Or do you want something that costs less up front, but you'll have to pay for service regularly? Some people want to get out the door and driving today with no money down, and that's a MySQL car.
In addition to integrity issue being likely to introduce bugs, the other downside to always taking the easy way out is that if your application's standards for data integrity go up later, you have nowhere to go. There's a long list of nasty MySQL limitations that are unlikely to ever be resolved. The learning curve for PostgreSQL is something you pay for once, and then benefit from forever.
MySQL got taken over by Oracle so the real development was forked with the new name of MariaDB.
No it didn't. MySQL was sold in a way that allowed Oracle to then purchase it. There's no reason to believe MariaDB will be any different. The fact that contributors to MariaDB have to assign their copyright to Monty's company says he's at least thinking about doing the same trick again.
I don't understand why people trust MariaDB either. The result the last time everyone jumped onto Monty's open-source ship? He cashed out and put all of his customers on a road that led to being screwed by Oracle. There's a bit of madness expecting different results adopting MariaDB I wouldn't buy into either.
Hint: when a contributor agreement like the MariaDB one says copyright must be assigned to "Monty Program AB", your contributors are usually being setup so that the owner of that copyright can then profit from the community's free work on the project, a decision that will be motivated by what's best for them. There are a few software projects that require copyright assignment that aren't doing that, like the gnu projects. Monty Program AB is not a non-profit with a decades long history of anti-commercialism like gnu though. It's a regular company run by someone who has screwed both his paying customers and his open-source user community exactly this way once. Why are people signing up such that he could do it again?
This project's innovation is noting that that GPUs have enough RAM now that you can push medium sized data sets into them if you have enough available. With lots of cores and high memory bandwidth, in-memory data sets in a GPU can do multi-core operations faster than in-memory data sets in a standard CPU/memory combination.
That's great for simple data operations that are easy to run in parallel and when the data set is small enough to fit in your available hardware. Break any of those assumptions, and you've got a whole different set of problems to solve than what this is good for. I suspect none of those three requirements hold in the usual case for what people want out of "big data".
All you need to make Boston police go crazy are some LEDs and batteries.
This was a one-time deal; it does not have to be the standard response for every event.
01-31-2007: Never forget
seems easy enough to buy low and sell high, it's just a matter of watching the prices and being patient
Said every trading company in history that eventually blew up. One day you'll buy what you think is low, only to watch the market keep going lower. Perhaps it's genuine activity; it might be a larger player who is "running the stops", executing trades at low prices specifically to shake out casual players. You might have your program execute its version of a stop order only to discover there isn't a buyer. Finally your "I want to get out!" trade executes at some incredibly low price...and now you've lost all your profits and then some. If you're lucky you'll still have enough capital to risk trading more...but if you do return to the market with less capital, you'll be even more vulnerable to market churn.
Most trading systems that look profitable over time underestimate the odds of an unprecedented event--something never seen in the history of the exchange--and risk too much chasing returns. If you adjust your profit estimate for real-world volatility, which includes things like not being able to execute trades without a greater loss than expected, suddenly you're unprofitable. This is hard because if you're new to a market, you have zero chance of predicting in advance what its volatility will really look like--so any profit model you come up with will be wrong. The equities stock market watches someone hit a major blow-up like this about every ten years: Black Monday (1987), Long-Term Capital Management explosion (1998), and then the market crash of 2008. Even in that mature market, there's an unexpectedly large blow-up every ten years. With Bitcoins, the period between those looks like months.
I hate it when I miss the 5 o'clock free crack giveaway.
Hint: when you turn a technical correction into a personal attack, you're being an asshole. Normally I just ignore assholes on Slashdot, but since you seem to be a reasonable poster most of the time I'll address the minor point you raise.
The issue was never whether I could get a system up and running once. It's about companies who feel they can arbitrarily alter their products after purchase, such that you have to just eat whatever shit they throw at you.
Yes, there have been a variety of ways to get a running copy of Windows that require less activation hassle. I know a few versions of the activation rules that have applied over time, how to get around some of them, and how to avoid the WGA notifier client. And, yes, the activation rules for XP Pro have been reasonable at some points in time. But I assumed from XP release day that Microsoft would eventually tighten them and break some systems that were functional, under the banner of anti-piracy. And that's exactly what happened in 2006 when KB905474 was pushed as a critical update.
The exact terms and enforcement for what makes a copy of Windows "Genuine" haven't been stable, and that was the first such major change to them. Microsoft still regularly rolls out updates to the WGA validation that change the rules. The latest text on that Wikipedia page even alludes to a recent "WGA update for Windows XP Professional" that alters how that OS is treated. You just quoted some activation rule of thumb at me. But did you check an XP Pro system today? Yesterday might have been a Patch Tuesday that grabbed new WGA code you know.
If you're fine with a Microsoft system pulling down updates that can alter if your OS is functional, ones that have the very real risk of deactivating it, good for you. I didn't care whether I could activate a system or not at a given point in time. The fact that a later update might deactivate one, via rules I could not predict, that was the thing that was unacceptable. When a software company issues a security update, it's a fix to a product that was sold with a defect. It's not an invitation to install extra crap or to disable features arbitrarily on my computer. It was bullshit when Microsoft does it, it was bullshit when Sony pulled Linux support on the PS3, and it's still bullshit now.
All of these firms must submit to financial audits by outside firms like one of the big 4 as well as frequent SEC random audits, so even making money they would be caught.
(Snort) Right. Search for information about the SEC with keywords "revolving door" and "document shredding" added and you'll see how this really works. The big firms get busted by the SEC about as often as they are nailed for off-shore tax schemes--neither ever happen with enough impact to matter. The worst the SEC does is issue them a few million in fines, like the recent HSBC case, which are just lumped in as cost of doing business relative to the profits earned. This guy's problem is just that he was working for too small of a company to be playing the game he picked.
He almost recreated the business model of every large bank. The missing step is that when you have a loss, you then ask for a bailout because it will hurt the economy if you fail.
Resistance to XP included the new product activation "feature". I stayed on Windows 2000 until its EOL in 2010 because Microsoft could decide your copy of Windows wasn't "Genuine" at any time and disable it, and those were unacceptable terms for me to run a business on. I'll only use Windows XP and 7 inside of a VM, where I can both easily take a snapshot of the system in a working state and move it onto new hardware without asking Microsoft for approval.
And they're not going to go for a small company's product or a free (e.g. Linux) replacement for Windows because there's nobody to sue if they fuck up your systems and stop critical business processes.
Like how Microsoft has fucked up Windows 8 and stopped critical business processes from working on it? Good luck with that lawsuit. This idea of companies making software decisions because they need someone to sue has always been ridiculous. I talk to a fair number of people going from Oracle to PostgreSQL who bring up this argument as a major issue in their way. I ask them if they can name a single instance where someone sued Oracle for releasing buggy software and won. The "need someone to sue" myth is even getting weaker lately, as many companies update their EULA so that individual users must accept arbitration. That's all about keeping them from jumping onto a class action lawsuit instead.
Liability insurance for developers does not cost very much. My consulting company has an insurance policy for the work we do, and the premium is based on how much money the company makes. I'm making enough to fund two full time people and my liability policy is around $1000 per year.
The biggest thing that keeps developers safe is the minimum legal costs of taking someone to court for long enough to sort out blame on a software project. If I botch $10K worth of development, it's impossible hire a legal team and beat it out of me with any real profit. I'd have to make a $100K mistake before I'd be worried someone might actually sue me for being incompetent.
Greater than 20% variation is the expected situation with capacitors. That's not a funny data point--that's the day to day reality of the job involved to go from lab prototype to large scale manufacturing of electronics.
Most of the broadband modem/router devices I see now have a little sticker with unique information like the SSID, MAC address, and WPA key printed on them. You could usefully improve things just by making the default router password be the WPA key. People you've given the WPA key to would then also be able to reconfigure the router in the default config, but that's basically how it works now. When I visit someone non-technical and they invite me to read the WPA key from the router, invariably once I'm on the network I find I can then administer the router using its default, shared by every model password.
It would be nice to have a separate admin password printed on the sticker though. The main problem with using one derived from information the client computers know is that trojans on those clients can still be smart enough to hack into the router they're behind, and then open up the whole network from there.
Because there are potentially large performance gains to be had in VMs running postgres by running a 3.x kernel, which CentOS doesn't use yet. Fedora or Ubuntu server are what i'm going to look at to see if it's of use to me.
This is an excellent example of why that sort of thing is avoided by risk-adverse deployments. Early adopters of PostgreSQL on various 3.X kernels are still seeing a variety of nasty kernel issues, and many of them are rolling back to the stable RHEL or Debian kernels based on 2.6.32 to avoid them. A good example is High CPU usage / load average after upgrading to Ubuntu 12.04. I'm tracking about 5 such PostgreSQL issues that only show up in 3.X kernels we're trying to get sorted out still. (I'm a PostgreSQL contributor) Yes, the 3.X kernels are faster in general, but they're still not very stable compared to the boring old ones in CentOS.
That Oracle supports running on btrfs isn't really a strong statement about its quality level for general use. btrfs aims to runs Oracle stably as its top development priority. Oracle doesn't require very many filesystem features. Some people run it happily on raw disk volumes. There's a good sized list of companies over the years that have built filesystems optimized for exactly type of workload Oracle creates. As an example, around 2006 I had a consulting job getting PostgreSQL to work well on a Linux system with the Veritas vxfs filesystem. Much of that tuning involved making the database's I/O look more like how Oracle writes things--things like using direct I/O instead of cached writes.
The problems get bad when you try to use btrfs for anything else. Repeat the same sort of experiment today, try and use PostgreSQL on btrfs for example, and you can expect btrfs will panic and corrupt itself under heavy load. The specific subset of filesystem read/write and caching behaviors Oracle expects may work, but the other read/write paths through the btrfs filesystem aren't nearly as well tested. Oracle's priorities for btrfs QA remind me of the old joke about Microsoft's monopoly abuse: "DOS Ain't Done til Lotus Won't Run".
Lack of useful backports to their LTS releases is the major reason I avoid Ubuntu Server. Canonical does some occasional updates to older LTS releases. But most of the time, the only suggested fix for bugs I see is "upgrade to the latest version of Ubuntu". They do not show nearly the same dedication to backporting bug fixes and nailing down a stable, well tested version of packages that I see from RedHat and Debian.
There are a lot of Lensmen similarities in "Star Wars". But since the Lensmen still haven't made into a proper movie, it doesn't make a good example of a film precursor. Someone watching "Star Wars" for the first time in 1977 was comparing it to SF movies like 2001, "Logan's Run", or "Close Encounters of the Third Kind"; lots of science, but no magic.
Comparing development cycles to mortgage back securities is a bit dramatic, don't you think...All the bubble did was weed out the wannabes from those that were established.
That is how the mortgage bubble worked too. There were a large number of banks that were viable only because they could make so much money just passing mortgages through to other people. And once the bubble popped, they started going out of business in droves, just like the .com companies did. Take a look at the failed bank list. It's a very similar pattern to the list of dead tech companies left in the wake of the 2000 tech bubble. The big established companies managed to hang on (Bank of America, Wells Fargo, Citibank, etc.) while little players were sunk in large quantities.