Considering that the total tax for on the road gasoline in California is less than fifty cents a gallon, you might want to check your numbers. That's combined state and federal excise taxes as well as a variety of other fees added by the state.
Earlier this year I took my black MacBook in because of a bulging battery. The Apple employee tried a few times to get it to netboot (so they could run their diagnostics) with no luck. In the end the employee just grabbed a battery off of the shelf and swapped it out for me. No paperwork, no checking of serial numbers, etc. Yes, I bought the extended warranty. No, he didn't even ask (and it had expired a few months prior). And, yes, the *new* battery said "service battery" for a week or so.
That kinda thing is exactly why I'm not interested in a difficult to replace battery. Instead of a ten second swap, you've got to do some serious work to get at the battery. More work equals less goodwill equals a lower chance of getting a free battery replacement. It's a shame really, as Apple had been trending towards more owner repairable hardware (iBook -> MacBook, Mini -> Unibody Mini).
So what? CSS3 Media Queries are at the candidate recommendation stage. At that point the W3C thinks they're stable enough to recommend removing vendor prefixes.
Besdies IE8 doesn't have any SVG support. Not even SVG Tiny. If the Mozilla, Opera, and WebKit guys can all agree... surely it shouldn't be too hard for Microsoft to agree? Ah, well.
You're kidding, right? IE8 lacks: Rounded corners, SVG anything, more robust font support, most HTML5 goodies (enhanced form support for things like validations and placeholders), text on canvas, CSS media queries, javascript optimizations like nested arrays and getElementsByClassName. IE8 is definitely a primitive browser.
IE9 is much closer, but it's still pretty bad. AFAIK it still doesn't support rounded borders + gradients and it has a number of problems with its SVG support. Others have linked to caniuse.com, but I'll point you in the direction of D3's issue tracker>.
If you're doing a dead simple site, sure IE8 not too bad. If you're trying to take advantage of "new" features, you're pretty much SOL (even with IE9).
I dismiss these NoSQL tools as being immature because they are immature. I'm in the process of migrating away from a NoSQL solution named like a piece of fruit. I was able to crash it by doing something WILD AND CRAZY. I created an index on a live system. Known bug. Not documented in the wiki. That was fun.
If these NoSQL solutions delivered on what they promised, or came close, that'd be one thing. But, at least with the DB that sounds like a fruit, the promise of all this distributed computation was for naught. MapReduce is the only way to distribute calculations across multiple nodes. However, MapReduce was not only the slowest way of munging data, but it still has/had major concurrency issues because it relies on process level locking. Not to be deterred I took a look at people who had been trying to use this distributed goodness (a.k.a. sharding). I was frightened away by the numerous complaints about this fruit-like database's inability to keep the partitions balanced, resulting in massive contention for the process lock on one node. That's an immature code base.
Or you could read the TFA. CouchDB is simply not mature enough for any semblance of high availability. Most of the downtime was credited to CouchDB being unstable. But, more importantly, as I've already outlined in another post on this story, distributed computation with NoSQL stuff ain't all it's cracked up to be. The reason it's being pushed so hard by the NoSQL camp is because that's the only way these products can scale in the first place. The reason you don't see stuff like that in more mature products is because fancy concepts like MVCC or finer grained locking mean that you typically don't need to distribute calculations.
Anyhow. At this point the only way we've been able to keep any semblance of performance (and we've got a tiny data set) has been to pull as much logic out of the NoSQL parts as possible. IOW it's a dumb key-value store... and if all you need is a key-value store, BDB's got you covered (and it's already way more mature).
And with InnoDB you still get table locks every time you update an autoincrement field. Performance then drops like a fucking rock. Anyway, that's when you move to Postgres.
So the thing is, traditional joins (on, say, Postgres or MySQL) aren't blocking operations. You can run more than one at a time. MapReduce (as well as writes, any aggregation, and any use of JavaScript) are blocking operations on Mongo. They block the entire mongo process. The MapReduce case gets around this with a bit of cooperative multitasking (yielding every few hundred or thousand rows), but writes, aggregation, and other use of javascript do not. So there's already a much bigger need to distribute MapReduce on Mongo than there is to distribute a JOIN on an SQL database.
Plus, MapReduce on Mongo is painfully slow, so you'll need to break things down into really small partitions to scale at all. Aggregating 800,000 documents (group by + sum) took me about 20 seconds with Mongo using the existing aggregation framework (which is universally credited with being faster than the MapReduce case). Porting the whole thing over to an SQL database allowed me to a.) not block the entire freaking process and b.) run the query in about 800ms.
So, sure, we could have partitioned the data and spread it across multiple nodes. Maybe that would have been faster (but you can only run MapReduce across multiple nodes, using the existing aggregation framework you can only operate on one node). Dunno. But it would have been a lot more expensive since we would have required more hardware to accomplish the same thing that an SQL database is optimized for.
The reason that "they" mock JOINs is because you simply can't do that efficiently with Mongo.
If you're dealing with the latest Big Data paradigms and designs, where you can sacrifice some of the rigidity of a RDBMS to gain some flexibility and cheaper scalability, use a NoSQL database, and hire people who aren't stuck in their old RDBMS ways.
Well, no. If you're dealing with "big data", you still need to evaluate which tool is appropriate for the task. If you're calling it "NoSQL", you're probably referring to a rather immature set of products designed to pander to people looking for teh new hotness. If you're looking for a key-value store, mature solutions like Berkeley DB have been around for ages.
It's not that key-value stores don't have their place, it's that people running around chanting the NoSQL mantra are really just reinventing the wheel. Poorly.
Unfortunately the developers of these "NoSQL"databases seem to have the same idea. I'm working with one that shill remain nameless but sounds oddly like a piece of fruit right now. The generally accepted best practice for scaling is to pull as much of the logic out of the database layer. While there are fancy aggregation pieces, they're all impossibly slow (and hamper concurrency). Argh.
So BlackBerry OS 11 or 12 will have e-mail too? Or will it have to be tethered to a PlayBook? When most people think of BlackBerry, they think of e-mail. I don't care how good it is, if they omit major features in the first release of a product... that's bad. It's like the dev phone not having a real keyboard. I'm sure some later phones will have keyboards, but look at how many commenters here love their BlackBerries for having the best keyboards out there. If RIM is going to throw away their core strengths... why bother? They're targeting a whole market demographic that just doesn't give a flying fuck about RIM or BlackBerry.
Seriously, it took one search to find that you're posting incorrect information. I'll be kind and not make jokes about why one would care about OTA app deployments on BlackBerry when there are no apps. I've nothing invested either way in BlackBerry anything, but you've failed to list anything that BES can do that's its competition cannot.
And what if you were referring to Apple's involvement in the calendaring (CardDAV, CalDAV) working groups? Multicast DNS (Bonjour)? How about HTTP live streaming? Is Apple perfect? No. Is Apple anywhere near as nefarious as Google or Rambus? No. At least with Apple I am their *customer*. With Google and Facebook, I'm the product.
Google is just as walled as Facebook if not more so. The real name policy for Google Plus comes to mind, especially as Google has forced integration with all of its other services. Hell, I was served with a threatening e-mail for not using my real name... and I don't even have a Google Plus account. Given that plenty of places will use your Google credentials for authentication I'm no quite sure how this is so different from Facebook.
- In *any* group there will be jerkwads. I've seen hardware companies run like frat houses and diverse rails shops that were unbelievably professional. And then there's slashdot.
- Younger kids will act less mature and less professional. Get a bunch of kids in their mid-twenties together and they'll do stupid shit. Give them ten years and they'll (typically) grow out of that phase. My guess is that the median age at the Ruby conferences you've attended is much lower than at the Fortran conferences.
Say what? Google Maps has always had the scepter of fees for commercial use. The previous(?) standard was that if your site was not publicly accessible you'd have to buy an annual license. I thought that ToS already indicated high traffic sites would potentially be required to pay... guess not. If you are/were designing a business around a commercial product like Google Maps and believed it is/was free, you are/were doing it wrong.
In a previous life I had to evaluate potential alternatives to Google Maps for desktop (browser) use. ESRI stuff was unbelievably archaic, the browser widget was horrid, and the pricing was astronomical. MapQuest had old data for the metro areas we needed, and Bing was pretty forgettable. The OSM stuff is pretty slick, and if you're going to setup a tile server you've got infinite customization available. Google provided a turnkey product with a fairly stable API.
In the Android arena, however, it's been my experience that the Google Maps was exceedingly frustrating with a limited feature set compared to something like OSM.
The Espionage Act was used only three times before President Barack Obama took office.
Obama, who serves the interests of the surveillance and security state with even more fervor than did George W. Bush, has used the Espionage Act to charge suspected leakers six times since he took office.
Apple (iOS and OSX), Android, and BlackBerry all support CardDAV. SyncML is dead, not to be missed unless you're using fairly old hardware. For fun I started writing a CardDAV server (so now there are FOSS options written in PHP, Python, and Ruby), but more mature open source projects like Davical, owncloud, and Radicale exist. If you're the sort that likes Zimbra, that does CardDAV too. If you use Exchange, there's always Kerio... and someone's even come up with an adapter for webOS of all things. Looks like Microsoft is the lone holdout.
In contrast the Wikipedia article about SyncML states that interoperability is a big problem. Using SyncML or CardDAV is still bound to be more of a pain than swapping SIM cards, but I'm not sure I see much lost in the de-facto death of SyncML.
I can only speak to the LG thunder stuff (P500, Optimus One/V/S/M/C/U/etc, Thrive, Phoenix, Vortex, etc). LG released an official Gingerbread update for the Euro carriers, Sprint (okay, not a discount prepaid carrier, but still) released a Gingerbread update for the Optimus S, and CyanogenMod 7 (Gingerbread) is working on all of the phones. CM9 (ICS) has been ported to the more capable (ex: not Thrive, Phoenix, or Vortex). Otherwise these phones come with some variant of Android 2.2.x.
Lousy follow through on updates is, IMO, more of a carrier thing than an Android thing. Only Apple's really bucked the trend there. On the plus side, some of these lower end phones are easily rootable and have been upgraded to include very good support of newer versions of Android (2.3, 4.0).
It's possible that the problem is on AT&T's end. I know AT&T does not have MMS agreements with Virgin. SMS typically works tho. At some point it just goes beyond incompetence and becomes outright malice. IMO AT&T's far past that point of incompetence.
Slashdot Mirror
Considering that the total tax for on the road gasoline in California is less than fifty cents a gallon, you might want to check your numbers. That's combined state and federal excise taxes as well as a variety of other fees added by the state.
http://taxfoundation.org/article/state-gasoline-tax-rates-january-1-2012
Maybe it helps to be nicer? *shrug*
Earlier this year I took my black MacBook in because of a bulging battery. The Apple employee tried a few times to get it to netboot (so they could run their diagnostics) with no luck. In the end the employee just grabbed a battery off of the shelf and swapped it out for me. No paperwork, no checking of serial numbers, etc. Yes, I bought the extended warranty. No, he didn't even ask (and it had expired a few months prior). And, yes, the *new* battery said "service battery" for a week or so.
That kinda thing is exactly why I'm not interested in a difficult to replace battery. Instead of a ten second swap, you've got to do some serious work to get at the battery. More work equals less goodwill equals a lower chance of getting a free battery replacement. It's a shame really, as Apple had been trending towards more owner repairable hardware (iBook -> MacBook, Mini -> Unibody Mini).
So what? CSS3 Media Queries are at the candidate recommendation stage. At that point the W3C thinks they're stable enough to recommend removing vendor prefixes.
Besdies IE8 doesn't have any SVG support. Not even SVG Tiny. If the Mozilla, Opera, and WebKit guys can all agree... surely it shouldn't be too hard for Microsoft to agree? Ah, well.
You're kidding, right? IE8 lacks: Rounded corners, SVG anything, more robust font support, most HTML5 goodies (enhanced form support for things like validations and placeholders), text on canvas, CSS media queries, javascript optimizations like nested arrays and getElementsByClassName. IE8 is definitely a primitive browser.
IE9 is much closer, but it's still pretty bad. AFAIK it still doesn't support rounded borders + gradients and it has a number of problems with its SVG support. Others have linked to caniuse.com, but I'll point you in the direction of D3's issue tracker>.
If you're doing a dead simple site, sure IE8 not too bad. If you're trying to take advantage of "new" features, you're pretty much SOL (even with IE9).
I dismiss these NoSQL tools as being immature because they are immature. I'm in the process of migrating away from a NoSQL solution named like a piece of fruit. I was able to crash it by doing something WILD AND CRAZY. I created an index on a live system. Known bug. Not documented in the wiki. That was fun.
If these NoSQL solutions delivered on what they promised, or came close, that'd be one thing. But, at least with the DB that sounds like a fruit, the promise of all this distributed computation was for naught. MapReduce is the only way to distribute calculations across multiple nodes. However, MapReduce was not only the slowest way of munging data, but it still has/had major concurrency issues because it relies on process level locking. Not to be deterred I took a look at people who had been trying to use this distributed goodness (a.k.a. sharding). I was frightened away by the numerous complaints about this fruit-like database's inability to keep the partitions balanced, resulting in massive contention for the process lock on one node. That's an immature code base.
Or you could read the TFA. CouchDB is simply not mature enough for any semblance of high availability. Most of the downtime was credited to CouchDB being unstable. But, more importantly, as I've already outlined in another post on this story, distributed computation with NoSQL stuff ain't all it's cracked up to be. The reason it's being pushed so hard by the NoSQL camp is because that's the only way these products can scale in the first place. The reason you don't see stuff like that in more mature products is because fancy concepts like MVCC or finer grained locking mean that you typically don't need to distribute calculations.
Anyhow. At this point the only way we've been able to keep any semblance of performance (and we've got a tiny data set) has been to pull as much logic out of the NoSQL parts as possible. IOW it's a dumb key-value store... and if all you need is a key-value store, BDB's got you covered (and it's already way more mature).
RTFM.
If you need to narrow down your search, look for the phrase "To avoid blocking concurrent transactions that obtain numbers from the same sequence".
Right. Inserts still lock at the table level, however. Your move.
Looks a whole lot like table level locking to me.
And with InnoDB you still get table locks every time you update an autoincrement field. Performance then drops like a fucking rock. Anyway, that's when you move to Postgres.
So the thing is, traditional joins (on, say, Postgres or MySQL) aren't blocking operations. You can run more than one at a time. MapReduce (as well as writes, any aggregation, and any use of JavaScript) are blocking operations on Mongo. They block the entire mongo process. The MapReduce case gets around this with a bit of cooperative multitasking (yielding every few hundred or thousand rows), but writes, aggregation, and other use of javascript do not. So there's already a much bigger need to distribute MapReduce on Mongo than there is to distribute a JOIN on an SQL database.
Plus, MapReduce on Mongo is painfully slow, so you'll need to break things down into really small partitions to scale at all. Aggregating 800,000 documents (group by + sum) took me about 20 seconds with Mongo using the existing aggregation framework (which is universally credited with being faster than the MapReduce case). Porting the whole thing over to an SQL database allowed me to a.) not block the entire freaking process and b.) run the query in about 800ms.
So, sure, we could have partitioned the data and spread it across multiple nodes. Maybe that would have been faster (but you can only run MapReduce across multiple nodes, using the existing aggregation framework you can only operate on one node). Dunno. But it would have been a lot more expensive since we would have required more hardware to accomplish the same thing that an SQL database is optimized for.
The reason that "they" mock JOINs is because you simply can't do that efficiently with Mongo.
If you're dealing with the latest Big Data paradigms and designs, where you can sacrifice some of the rigidity of a RDBMS to gain some flexibility and cheaper scalability, use a NoSQL database, and hire people who aren't stuck in their old RDBMS ways.
Well, no. If you're dealing with "big data", you still need to evaluate which tool is appropriate for the task. If you're calling it "NoSQL", you're probably referring to a rather immature set of products designed to pander to people looking for teh new hotness. If you're looking for a key-value store, mature solutions like Berkeley DB have been around for ages.
It's not that key-value stores don't have their place, it's that people running around chanting the NoSQL mantra are really just reinventing the wheel. Poorly.
Unfortunately the developers of these "NoSQL"databases seem to have the same idea. I'm working with one that shill remain nameless but sounds oddly like a piece of fruit right now. The generally accepted best practice for scaling is to pull as much of the logic out of the database layer. While there are fancy aggregation pieces, they're all impossibly slow (and hamper concurrency). Argh.
So BlackBerry OS 11 or 12 will have e-mail too? Or will it have to be tethered to a PlayBook? When most people think of BlackBerry, they think of e-mail. I don't care how good it is, if they omit major features in the first release of a product... that's bad. It's like the dev phone not having a real keyboard. I'm sure some later phones will have keyboards, but look at how many commenters here love their BlackBerries for having the best keyboards out there. If RIM is going to throw away their core strengths... why bother? They're targeting a whole market demographic that just doesn't give a flying fuck about RIM or BlackBerry.
http://iphonecto.com/2010/07/07/ios4-wireless-app-distribution-finally-iphone/
Seriously, it took one search to find that you're posting incorrect information. I'll be kind and not make jokes about why one would care about OTA app deployments on BlackBerry when there are no apps. I've nothing invested either way in BlackBerry anything, but you've failed to list anything that BES can do that's its competition cannot.
Obvious astroturf is obvious. Sigh.
Unless you want to use it for e-mail.
That's really special.
And what if you were referring to Apple's involvement in the calendaring (CardDAV, CalDAV) working groups? Multicast DNS (Bonjour)? How about HTTP live streaming? Is Apple perfect? No. Is Apple anywhere near as nefarious as Google or Rambus? No. At least with Apple I am their *customer*. With Google and Facebook, I'm the product.
Google is just as walled as Facebook if not more so. The real name policy for Google Plus comes to mind, especially as Google has forced integration with all of its other services. Hell, I was served with a threatening e-mail for not using my real name... and I don't even have a Google Plus account. Given that plenty of places will use your Google credentials for authentication I'm no quite sure how this is so different from Facebook.
Two things stand out to me:
- In *any* group there will be jerkwads. I've seen hardware companies run like frat houses and diverse rails shops that were unbelievably professional. And then there's slashdot.
- Younger kids will act less mature and less professional. Get a bunch of kids in their mid-twenties together and they'll do stupid shit. Give them ten years and they'll (typically) grow out of that phase. My guess is that the median age at the Ruby conferences you've attended is much lower than at the Fortran conferences.
Say what? Google Maps has always had the scepter of fees for commercial use. The previous(?) standard was that if your site was not publicly accessible you'd have to buy an annual license. I thought that ToS already indicated high traffic sites would potentially be required to pay... guess not. If you are/were designing a business around a commercial product like Google Maps and believed it is/was free, you are/were doing it wrong.
In a previous life I had to evaluate potential alternatives to Google Maps for desktop (browser) use. ESRI stuff was unbelievably archaic, the browser widget was horrid, and the pricing was astronomical. MapQuest had old data for the metro areas we needed, and Bing was pretty forgettable. The OSM stuff is pretty slick, and if you're going to setup a tile server you've got infinite customization available. Google provided a turnkey product with a fairly stable API.
In the Android arena, however, it's been my experience that the Google Maps was exceedingly frustrating with a limited feature set compared to something like OSM.
Isn't much better? How about is worse?
Does that sound like an improvement?
Apple (iOS and OSX), Android, and BlackBerry all support CardDAV. SyncML is dead, not to be missed unless you're using fairly old hardware. For fun I started writing a CardDAV server (so now there are FOSS options written in PHP, Python, and Ruby), but more mature open source projects like Davical, owncloud, and Radicale exist. If you're the sort that likes Zimbra, that does CardDAV too. If you use Exchange, there's always Kerio... and someone's even come up with an adapter for webOS of all things. Looks like Microsoft is the lone holdout.
In contrast the Wikipedia article about SyncML states that interoperability is a big problem. Using SyncML or CardDAV is still bound to be more of a pain than swapping SIM cards, but I'm not sure I see much lost in the de-facto death of SyncML.
I can only speak to the LG thunder stuff (P500, Optimus One/V/S/M/C/U/etc, Thrive, Phoenix, Vortex, etc). LG released an official Gingerbread update for the Euro carriers, Sprint (okay, not a discount prepaid carrier, but still) released a Gingerbread update for the Optimus S, and CyanogenMod 7 (Gingerbread) is working on all of the phones. CM9 (ICS) has been ported to the more capable (ex: not Thrive, Phoenix, or Vortex). Otherwise these phones come with some variant of Android 2.2.x.
Lousy follow through on updates is, IMO, more of a carrier thing than an Android thing. Only Apple's really bucked the trend there. On the plus side, some of these lower end phones are easily rootable and have been upgraded to include very good support of newer versions of Android (2.3, 4.0).
The GSM versions of the LG thunder board (Optimus One/P500, even the neutered AT&T Phoenix and Thrive I think) have quite a community around them and support has been merged into the Cyaogenmod tree. The CDMA versions (Optimus C/U/V/M/S) have , but the CM guys have been dragging their feet on integrating it.
Never touched the Slider tho.
It's possible that the problem is on AT&T's end. I know AT&T does not have MMS agreements with Virgin. SMS typically works tho. At some point it just goes beyond incompetence and becomes outright malice. IMO AT&T's far past that point of incompetence.