I never said that. Also, I have no idea how this is a reply to what you quoted.
It would be hypocritical if you did, but I apologize. I don't mean to strawman, but this does seem to be the direction Mozilla is heading -- if they were to use the native video APIs, it'd be entirely up to the user which codecs are supported. If the native APIs aren't rich enough, how hard would it be to expose a rich enough API for others to hook into?
So? It's a platform with enough market share that a person could say the solution works for nearly everyone and is therefore acceptable. I just threw your own argument back at you, and you respond with special pleading [wikipedia.org].
Actually, no, it was an argument of degree -- it's a very different "nearly everyone" which only includes two OSes from a "nearly everyone" which only excludes (mabye) things like Haiku, and not necessarily.
I'm also not sure the "right OS" argument is ultimately valid, considering I don't think anyone has ever objected to people writing their own third-party drivers -- so if you've already got a decoder in hardware, why should it matter what OS you have? If you don't have a driver, that's a bit like decrying Ethernet because your OS doesn't support your network card.
No it isn't. The reasons I gave for not supporting native codecs simply do not apply to WebGL.
The security reasons absolutely do. Let me quote them:
Giving untrusted websites free reign to load dozens of unknown external libraries and feed unchecked data to them is a very bad idea.
I suppose it's different, but what is the important difference? Dozens of libraries, but I'll be the nVidia driver has more code than all of them put together. Unknown, certainly -- you have no idea what OpenGL renderer will be used, could be one backed by DirectX, could be ATI/AMD, nVidia, Intel, any software renderer, any intermediate layer, etc, etc.
Unchecked data, absolutely.
And this is the only way to implement it -- you cannot reasonably embed an OpenGL implementation; for many websites which will be implementing this, a hardware accelerator of some sort will be required. So this:
Hardware accelerated decoding is a good thing. But it should actually be hardware accelerated decoding, not hardware enabled decoding.
...effectively becomes a distinction without a difference in the case of WebGL.
I suppose I will have to concede that it would be a good thing if pages were viewable -- though as a slideshow rather than video -- on any device, anywhere, which chooses to implement it.
"on some platforms Firefox supports, there is a native video API, and that native video API occasionally supports h.264"
I don't see it. In particular, how would the "nearly every" become "some"? Do you see many platforms abandoning their video APIs in the near future? Or do you see a viable new video platform which would not expose such an API?
I don't see the second part changing soon, either. nVidia has a large investment in Linux, for one. I can find articles from 2008 talking about ATI's H.264 support on Linux, and ATI is also committed to solid open-source drivers -- meaning they should be portable to other GPL'd OSes -- though I don't know for a fact whether the open source drivers support it. ATI has also used open specs, suggesting it should be possible to write a clean-room implementation.
Yeah, probably. That's actually pretty likely.
Other than a shift towards ATI, which supports the same thing, what makes you say that?
In any case, a wise decision maker does not assume that they can reliably predict the future.
Yet it is exactly concerns about the future which bring this up in the first place. I'm curious what possible outcomes would vindicate Firefox here. It doesn't seem
it seems to me that once the transaction being tested is committed and the test detects a failure, it should be able to record details before rolling back the test-level transaction.
It could, but would I be able to explore a snapshot of the data at that point in time? In particular, could I watch changes to the data as I step through with a debugger?
These are things which are easy if I have an isolated copy (as you described in SQLite), but don't work as well just using a transaction of a development or production database.
If you've got tests that don't need a copy of the store, I'd say partition those from tests that do need it;
It can be done, sure, but I think it's far easier just to have object factory classes -- though I'm not sure, now that I think of it, that these are easier without SQL, it seems to be fairly independent of datastore.
along with dump files to repopulate either DB schema.
Not just the schema, though. You'd want a clone of the production schema and (likely) the production data. But I see your point.
(they don't actually *need* Oracle for this app, but they've standardized on it for all their internal apps).
I hate when that happens, but then, I'm not sure I see any real applications of Oracle. It seems to me that when you get to the scale where you would need Oracle, you're very nearly at a scale which would make Oracle useless and force you to think in distributed terms.
I think you're right about PostgreSQL, but I'm too lazy to check.
I think there may, at one point, have been some proprietary options for true multimaster replication, but I don't think they went anywhere. And multimaster replication doesn't really buy you much in terms of scalability, if you have to keep all nodes in sync.
Anyway, you should get a firm grasp during planning of how large (or distributed) the data needs to be within a foreseeable time frame. If you anticipate truly huge data on multiple servers or a need for distributed data, then that should strongly influence what data platform you choose.
Point is, if I design and plan for truly huge data on multiple servers, it's still going to work at a smaller scale -- and as an added bonus, I find many of the NoSQL databases much more pleasant to use than SQL.
However, if I design and plan for a small scale, well, it's probably not going to be pleasant upgrading from SQLite to MySQL or from MySQL to Oracle, so you can imagine how not fun it would be to go from any of these to a truly sharded design, or to one of these NoSQL designs.
One thing I love about Google App Engine, for instance, is that it makes me think about the shape of my data. If I can think about how this works at a high level, I can design my application around it such that it can scale to pretty much any load anyone throws at it.
maybe not if the data model just won't work well with a key-value DB.
Well, but what data is that? Consider CouchDB -- you get "views", which are essentially mapping functions, and you can also create arbitrary "reduce" functions. This means you essentially get a cached view of the result of arbitrary code execution, and these can each be pretty much arbitrarily parallized.
Most of the major databases can handle medium-sized data sets, say 10s of GBs to 100s of GBs, on a single server.
That doesn't tell anywhere near the whole story -- I handle terabytes of data on a single server with a flat filesystem, because they happen to be terabytes of video.
So what kinds of data, and what kinds of access patterns are we talking about? And how big a server -- how many cheap PCs could I buy for the same price? How are you going to handle availability -- that is, what happens if that one server goes down?
However, without rooting it, Android still lets you install any app you want, from anywhere. You have to jailbreak an iPhone to be able to install any app from anywhere other than the App Store.
In other words, like so many other things, Android gives you a choice -- you can buy exclusively from an app store, and enjoy the dubious security and quality benefits of doing so, or you can buy (or download) from anywhere. Apple removes choice from you -- you can only buy from the app store.
I would also argue that it's nice to have the source for the OS once you root it, and it's nice that there have been Android phones sold which were entirely unlocked and allowed root. With the iPhone, you were always breaking the warranty, and until very recently, you were breaking the law -- there never was an iPhone you legitimately had root on.
In other words, Android isn't a huge brand. So what?
The non-technical people I know who have an Android phone may not necessarily realize it's a "competitor OS", but they certainly know it's a competitor phone. They might credit HTC or Motorola, they might call it "Droid" instead of "Android", but they know they got a smartphone.
If they didn't, they wasted a lot of money compared to a "non-smartphone", which are absurdly smart these days.
the marketplace _really_ is big enough for Android, iOS and RIM to coexist...
I'd hope so. But if it really is, I'd also hope developers would start to realize that Android and RIM won't rape them, or will at least use some fucking lube. I'd imagine that if we see enough cross-platform apps that aren't on the iPhone, we'll start to see some converts.
After all, it worked for the PC -- pick whatever hardware you want, Windows (and all your apps) will run on it, even if it doesn't work as smoothly as a Mac.
So you think Mac's being "closed" hurt them more then being over 2x as expensive and slower than the equivalent PC?
Except they haven't been, for a long time. I've generally found that if I price out a PC with all the same features that, say, a Macbook has, it's going to cost about as much as that Macbook, unless I start adding RAM.
The main reason people believe this is that you can price out a PC with almost-equivalent specs, which certainly have all the specs you care about (and beat the Mac on a few), for about half the price.
If the general public prefers "openness" then how do you explain the lack of iPod Killers?
An iPod is a legitimate candidate for being an appliance. However, it's still not the only mobile music player, and if the general public doesn't prefer "openness", how do you explain the push against DRM, to the point where even Apple has un-DRM'd their music store?
according to the keynote yesterday, Apple still activates more iOS devices (iPhones +Touches + iPads) then all Android devices combined.
You might consider that the person who has this flash requirement, such as yourself, should be savvy enough to find a way to get flash operating on the iPhone.
Why should I bother?
Why should I give my hard-earned dollars to buy a computing device which is going to make me jump through hoops before I can use it as a computing device?
So effectively the option is there.
Only now that Jailbreaking mobile devices, specifically -- a ridiculously restricted definition of jailbreaking -- has been legalized. And Apple has made it clear that they would much rather it was still illegal, so yes, I will avoid giving money to Apple for that reason.
If your aim is to move design away from a format that you consider unstable/unsuitable for your environment, then the majority of people who don't have an opinion should not be given access.
Why not? They're perfectly capable of seeing the difference for themselves, particularly if the default was click-to-enable. If you want to be especially obnoxious, provide huge warnings like "This WILL kill your battery life. Are you sure you need to see this page that badly?"
This will apply pressure to designers to seek open standards compliant formats.
No it won't. It'll apply pressure to designers to support whatever formats the iStuff allows.
As a trivial example: Last I checked, any sort of modification to the web browser wasn't allowed in the app store. One such modification would be supporting alternate video formats -- in part, because the iPhone has a hardware h.264 decoder. So in this instance, Apple is specifically pressuring designers to seek closed standards that work on iPhone (h.264) rather than open ones which work most other places (theora and WebM).
More troubling, designers seem so eager to make sure their stuff works perfectly on iStuff, they're going straight for the app store. Comic books are "apps." WTF? Is it 1995 again, with everyone wetting themselves over CD-ROM encyclopedias? More than once, I've seen something which would work just as well as a web app (and thus, work on iPhone, Android, PC, etc) be released instead as an iPhone-specific app.
Still more troubling, Apple has placed some requirements which effectively mean that cross-platform UIs cannot be developed if one of the target platforms is an iPhone app, and they are aggressively anti-cross-platform.
Sure, I'm glad it helps HTML5, but on balance, I'd rather the iPhone never existed.
Mostly the principle of the thing, and how it's reflected in every aspect of the device. I do tinker. I've written my own adblocker -- took me an afternoon, from having no experience with the Chrome API, to having a satisfactory adblocker, and that's not the only extension I've written.
With iStuff, even if I'm willing to do stuff myself, I can't, and that's not OK, either in principle or in practice -- I do rely on things I've written myself.
And yes, I would really like the ability to turn Flash on for certain sites, even if I'd probably leave it disabled most of the time on a mobile device.
I'd rather live in a country where it's legal to eat shit, even if I never intend to do so myself. Because when they outlaw shit, that means they're telling me what I can and can't eat, and next thing you know, they'll be outlawing burgers because they're unhealthy, or certain brands of chocolate for being too orgasmic, or...
That's what it feels when browsing a web site with flash on it on my N900.
...so turn it off? Your N900 is, if I recall, a perfectly capable Debian system, which means you could easily swap out the browser for any other browser, uninstall the plugin, etc.
By contrast, an iPhone has made the choice for you.
And you don't always know that there's flash somewhere.
It's called "Flashblock."
On the other hand, I'm glad I know I can trust my iPad to last for 10h of full use on a single full charge, even if that means that I can't see annoying ads or poorly designed websites.
Even if some of those "poorly-designed websites" are things like the Daily Show. I agree, it should be using HTML5 -- maybe it is on iPads -- but I'd rather have the ability to run proprietary crap and see those pages, and yes, burn some battery life, than have the decision made for me.
The only reason I posted at all is because I get really tired of the "atheism is a religion/no it's not" argument. It's sophomoric, pedantic, and silly.
What? No, it's actually fundamental to the debate, and it undermines almost everything you said.
The epistemological observation is made that people "believe" a lot more than they "know," and it turns out that in the realm of belief-prompted-actions, atheists and Christians and Buddhists and everyone behave in strikingly similar ways.
Certainly -- except that "no god" is not a belief of any atheist I know. It's merely the default position. Neither knowing or believing has anything to do with it -- it's simply not knowing.
We want other people to believe what we believe.
Again not something I find terribly many atheists have as a goal -- at least, if you are talking about the lack of belief as a belief.
Nor do I necessarily care that other people share most of the things I do believe. I believe I'm a decent programmer, but I really don't care what you think.
The primary goals are much simpler: We want others to stop preaching at us and others, we want public and political debate to be informed by reason and evidence instead of emotional and biblical appeals, and we want people to stop making assumptions about atheists -- in particular, that we're evil, though the assumptions you made about beliefs are annoying also.
I know a few people who are quietly atheist. Perhaps agnostic would be a better word, as they do not believe in God,
Nope, that's atheist, and the more people who use the term properly, the less often I'll have to answer "Prove to me God doesn't exist!" or worse, "Prove that atheism is true and correct!"
And then I have met many atheists who are zealots, or at least hobbyists, about it. Their disbelief is not a passive thing, but an active assertion, a passion, an argument they must make at every possible opportunity.
And yet, we should make a distinction here -- the disbelief itself is very much passive, and even in the most "militant" atheists will admit that, given sufficient evidence, they would believe. It is the consequences of that disbelief in light of such ubiquitous belief that leads to the "passion" you're talking about.
I have a passion for truth.
Robert Pirsig once observed that very few people run around screaming that the sun is going to rise tomorrow. Things we are deeply certain about generate very little in the way of zealotry.
This is largely because not only are we very sure of it, there isn't much argument about it. If there was a large community of people in the desert who were absolutely convinced the sun wouldn't rise tomorrow, and thus not concerned about finding shelter from the coming heat, then hell yes, I would be running around screaming that the sun would rise tomorrow to anyone who would listen.
Firefox does not embed IE by default. The user has to install a third-party addon to embed IE, and hardly anyone does that.
Yet you seem to be against even allowing a common API for third parties to add on codecs.
There isn't a native and licensed H.264 renderer you can call out to on every platform, either.
IE's renderer exists on exactly one platform. H.264 exists on nearly every platform, and by "exists", I mean "already installed, or available at zero cost." Refusing to support native codecs is like refusing to support WebGL because the best GL implementations happen to be composed of both proprietary hardware and software.
to support viewing of content that isn't in an open format or coded to open standards.
Or to make it up to the user whether or not to support that. Or to use existing hardware renderers on a given platform. Or, yes, to support viewing of content that isn't in an open format or coded to open standards, but is significantly more open and useful than the same content in a less open format (Flash).
That's just a statement about today. Look at the qualifiers I italicized. They will change in the future.
How so?
If Linux adoption grows, the "rely on the OS" approach will cover fewer people.
So nVidia cards would become less popular among Linux users? Or is it that you don't think Linux will grow by vendor support, like Dell's Ubuntu, which includes codecs?
By encouraging the widespread use of H.264 now, we'd just be handing over free leverage to the patent cartel that is MPEG LA, and they will use it...
...for how long? Patents expire.
And just what is this nightmare scenario you're envisioning? It looks to me like they already have control. It looks to me like they have more control than they ever dreamed -- they can dictate which player you use (Flash, Silverlight, etc), because there isn't a common browser-based standard for people to use.
Actually, it is, because security is Firefox's business. Giving untrusted websites free reign to load dozens of unknown external libraries and feed unchecked data to them is a very bad idea.
Out of curiosity, do you roll your own IP stack, too?
Giving untrusted websites free reign to feed data to libraries provided by the OS seems like an inevitability, and a far safer prospect than providing a model in which any local program can install plugins or extensions which load into the browser process and arbitrarily muck with any arbitrary page.
Firefox shouldn't get in the way and it wouldn't get in the way. Hardware accelerated decoding is a good thing. But it should actually be hardware accelerated decoding, not hardware enabled decoding.
In other words, Firefox shouldn't support WebGL unless it ships MesaGL? Really?
I don't want a dongle to be required for a fully functioning browser.
Even one you already have? How many devices do you have which don't already have a decoder of some sort?
Nobody is stopping you. You even have access to the source code to make it happen.
The source code isn't all I'd require -- Mozilla owns the Firefox trademark, so whatever I created, the result wouldn't be Firefox. I may as well stick to Chromium.
It is MPEG LA that's trying to take away your right to use H.264 so they can sell it back to you.
Except they haven't. Right now, they have given me the right to use it -- at no cost, and with significant improvements over all other codecs, including but not limited to native hardware support.
And I do -- in Flash and in Chrome. But because of Mozilla's choices, I can't in Firefox.
In other words, you are taking away my ability to do something because the MPEG LA might take
Most major databases support nested transactions. If the ones you've had to test against don't, that would be a real PITA.
I'm probably thinking of something like SQLite. Good point, though.
Of course, there is the added problem of being able to access the result of running a given failed test before rolling it back. Should we dump the entire production database to do that?
You would need to do essentially the same things with any persistent store, right? Unless you mean to test against production data...
Eventually, the idea is to test against a clone of production data, which is I think what you're suggesting. However, there are a lot of tests you can do without even touching the database, and a lot more you can do with generated data. This means you need a quick way to get a completely clean datastore, and a quick way to get a datastore which is a clone of a given snapshot of production. (Has to be a given snapshot, otherwise you might have a test that fails on one run and succeeds on the next.)
OTOH, why do you care if your web app that doesn't need ACID happens to run on an ACID database? ACID is usually transparent to the application programmer, and I would assert that most web apps will never grow large enough to notice any performance hit, assuming a reasonably sane schema is in place.
As soon as you grow beyond a single database server, that's a serious performance hit, or quite possibly an administration nightmare, assuming your chosen database can scale to multiple servers -- last I checked, Postgres only does replication.
Also, SQL is ugly. If I don't need ACID, why should I put up with it? More generally, if my web app doesn't need ACID, why would I want to use an ACID-compliant database at all?
Hardly any of our web apps are ever going to become the next Google, Amazon, Twitter, or whatever.
Even without that, I'd like to be able to handle spikes in traffic gracefully. While I doubt it was the database that was the bottleneck, recently, a number of students in my physics class have been unable to work on or submit online homework, because the online homework system seems to buckle under the load of all the procrastinators. Being able to trivially scale the database with the application is still a Good Thing, even for a tiny app.
If only you could start something like a "transaction", which you could then "roll back" after finishing the test, leaving the database in its original state.
...which means you now can't test transactions.
And if you could somehow "back up" the database and "restore" it on a test server, or under a different name.
That'd be obnoxious, but sure.
If you've got multiple users and connections, you want ACID.
Spoken like someone who's never written a web app.
Let's take Slashdot as a trivial example. Do I need transactions to be atomic? That'd be nice -- I don't want to see half a post succeed and the other half fail -- but it isn't really needed outside profile settings. Consistency? Posts really only depend on their parents, which are immutable -- pretty much by definition, if a user can see a parent post to reply to, by the time Slashdot will let them reply, that parent post will be committed. How about isolation? Nope -- if two users post two comments simultaneously, the application can trivially figure out which one should go on top -- no need for a transaction. Durability? Again, I don't see this being needed anywhere but in the user's profile.
So, we could take atomicity and durability as useful and easily drop isolation and consistency -- they simply are not needed and add zero value, unless I'm grossly misunderstanding what they are.
If you want to see what it's like without those protections, go use Mac OS 9 for a week or so,
Really, I don't understand this argument. "Why don't the browsers just use the system's video support?" How about this: why don't *websites* just use the system's video support?
If by that you mean the object tag, well, consider what you can do with a video that you can't necessarily do with an object. Compositing, pause/play or otherwise control, point it at a Base64 data URL, etc, etc. You acknowledged this:
the HTML5 video tag has a lot of properties and JavaScript behavior that needs to be guaranteed to work, or we won't have gotten anything better than just using an object tag.
Which would be exactly the point of using the native video framework, yet inside a video tag.
YouTube could already play its h.264 source videos just fine on my system without using Flash, but this has never been an option without using a greasemonkey hack
Because YouTube wants to be able to do things like stick an ad in front of the video, then start the video once the ad finishes, or float an ad, or annotations, etc on top of the video, or deep-link to a specific timecode.
So what, exactly, is the problem with the platform APIs?
I don't think most platform video libraries expose the sort of low-level stuff that the spec demands.
Citation needed, especially as Safari already uses QuickTime, or whatever they've got on the iPad, to do just this.
And why not also embed the IE engine for compatibility with IE-only sites?
Aside from the fact that this has happened and it wasn't the end of the world, there simply isn't an analogy here. There isn't a native HTML renderer API you can call out to on every platform, or a reason to do so.
However, on pretty much every platform Firefox supports, there is a native video API, and that native video API most likely supports h.264, not that it's any of Firefox's fucking business what codecs it supports. For all Firefox knows, I could have a Linux-only hardware-accelerated theora card -- why should Firefox get in the way by insisting it's all software-based, so Firefox can keep a stranglehold of control on it?
I've got h.264 in hardware and in two OSes on the same machine. I've also got Firefox on the same machine. And it's only fucking zealots like you that keep me from connecting the two together.
If Firefox can't support GPU rendering on all operating systems, then it shouldn't support it on any.
Fixed that for you. Does it still make sense?
If so, why does Firefox currently support GPU rendering? It doesn't work on all OSes -- not all OSes have drivers for modern enough GPUs to make this work.
If not, what is your argument?
We don't need to regress back to the days where websites only work if you have the "correct" OS.
Yeah, just keep repeating that as if it's an argument. I mostly agree with you, but I find your methods disgusting. You would restrict my freedom to ensure I have freedom. Do you realize how pathological that is?
If Firefox implements H.264, then what's next? ActiveX?
You've gotta be joking. ActiveX isn't cross-platform.
Guess what is?
That's right, the netscape plugin API, which Firefox still supports, which enables them to run Flash, which is far worse than any codec which could conceivably be used for HTML5 video.
We don't need to regress back to the days where websites only work if you have the "correct" OS.
The "correct" OS being Windows or OS X, or if you've got an nVidia card, Linux, Solaris, or FreeBSD, or Apple's iOS, or Android, or...
You're kind of losing the high ground if your complaint is really that you can't legally play HTML5 video on AmigaOS or BeOS.
or, another translation, "I can't wrap my brain around Rails/Ruby, and wish I could do things the way I would do them in [fill in the blank]".
While that's often the case, I've got a patch in rails-core, I've got over a year of Rails experience, and I've written a few Sinatra toys which run on Google App Engine.
So yeah, I think it's reasonable to say that I know Rails and Ruby.
Flash is a plug in as are Windows Media and Quicktime. You don't have to install the plug ins if you don't want to. Which coincidentally is how Mozilla is handling the problem of H.264 as well, if you get the plug in you can play it.
BZZZT!
Nope, in fact, that's the point, that's what I've been saying for months now -- things would be much simpler if Firefox allowed this kind of thing to be based on plugins, even better if they simply delegated to the system's native media framework. They don't, they refuse to -- I know of no way to play H.264 in an HTML5 video tag in Firefox.
Slashdot Mirror
I never said that. Also, I have no idea how this is a reply to what you quoted.
It would be hypocritical if you did, but I apologize. I don't mean to strawman, but this does seem to be the direction Mozilla is heading -- if they were to use the native video APIs, it'd be entirely up to the user which codecs are supported. If the native APIs aren't rich enough, how hard would it be to expose a rich enough API for others to hook into?
So? It's a platform with enough market share that a person could say the solution works for nearly everyone and is therefore acceptable. I just threw your own argument back at you, and you respond with special pleading [wikipedia.org].
Actually, no, it was an argument of degree -- it's a very different "nearly everyone" which only includes two OSes from a "nearly everyone" which only excludes (mabye) things like Haiku, and not necessarily.
I'm also not sure the "right OS" argument is ultimately valid, considering I don't think anyone has ever objected to people writing their own third-party drivers -- so if you've already got a decoder in hardware, why should it matter what OS you have? If you don't have a driver, that's a bit like decrying Ethernet because your OS doesn't support your network card.
No it isn't. The reasons I gave for not supporting native codecs simply do not apply to WebGL.
The security reasons absolutely do. Let me quote them:
Giving untrusted websites free reign to load dozens of unknown external libraries and feed unchecked data to them is a very bad idea.
I suppose it's different, but what is the important difference? Dozens of libraries, but I'll be the nVidia driver has more code than all of them put together. Unknown, certainly -- you have no idea what OpenGL renderer will be used, could be one backed by DirectX, could be ATI/AMD, nVidia, Intel, any software renderer, any intermediate layer, etc, etc.
Unchecked data, absolutely.
And this is the only way to implement it -- you cannot reasonably embed an OpenGL implementation; for many websites which will be implementing this, a hardware accelerator of some sort will be required. So this:
Hardware accelerated decoding is a good thing. But it should actually be hardware accelerated decoding, not hardware enabled decoding.
...effectively becomes a distinction without a difference in the case of WebGL.
I suppose I will have to concede that it would be a good thing if pages were viewable -- though as a slideshow rather than video -- on any device, anywhere, which chooses to implement it.
"on some platforms Firefox supports, there is a native video API, and that native video API occasionally supports h.264"
I don't see it. In particular, how would the "nearly every" become "some"? Do you see many platforms abandoning their video APIs in the near future? Or do you see a viable new video platform which would not expose such an API?
I don't see the second part changing soon, either. nVidia has a large investment in Linux, for one. I can find articles from 2008 talking about ATI's H.264 support on Linux, and ATI is also committed to solid open-source drivers -- meaning they should be portable to other GPL'd OSes -- though I don't know for a fact whether the open source drivers support it. ATI has also used open specs, suggesting it should be possible to write a clean-room implementation.
Yeah, probably. That's actually pretty likely.
Other than a shift towards ATI, which supports the same thing, what makes you say that?
In any case, a wise decision maker does not assume that they can reliably predict the future.
Yet it is exactly concerns about the future which bring this up in the first place. I'm curious what possible outcomes would vindicate Firefox here. It doesn't seem
it seems to me that once the transaction being tested is committed and the test detects a failure, it should be able to record details before rolling back the test-level transaction.
It could, but would I be able to explore a snapshot of the data at that point in time? In particular, could I watch changes to the data as I step through with a debugger?
These are things which are easy if I have an isolated copy (as you described in SQLite), but don't work as well just using a transaction of a development or production database.
If you've got tests that don't need a copy of the store, I'd say partition those from tests that do need it;
It can be done, sure, but I think it's far easier just to have object factory classes -- though I'm not sure, now that I think of it, that these are easier without SQL, it seems to be fairly independent of datastore.
along with dump files to repopulate either DB schema.
Not just the schema, though. You'd want a clone of the production schema and (likely) the production data. But I see your point.
(they don't actually *need* Oracle for this app, but they've standardized on it for all their internal apps).
I hate when that happens, but then, I'm not sure I see any real applications of Oracle. It seems to me that when you get to the scale where you would need Oracle, you're very nearly at a scale which would make Oracle useless and force you to think in distributed terms.
I think you're right about PostgreSQL, but I'm too lazy to check.
I think there may, at one point, have been some proprietary options for true multimaster replication, but I don't think they went anywhere. And multimaster replication doesn't really buy you much in terms of scalability, if you have to keep all nodes in sync.
Anyway, you should get a firm grasp during planning of how large (or distributed) the data needs to be within a foreseeable time frame. If you anticipate truly huge data on multiple servers or a need for distributed data, then that should strongly influence what data platform you choose.
Point is, if I design and plan for truly huge data on multiple servers, it's still going to work at a smaller scale -- and as an added bonus, I find many of the NoSQL databases much more pleasant to use than SQL.
However, if I design and plan for a small scale, well, it's probably not going to be pleasant upgrading from SQLite to MySQL or from MySQL to Oracle, so you can imagine how not fun it would be to go from any of these to a truly sharded design, or to one of these NoSQL designs.
One thing I love about Google App Engine, for instance, is that it makes me think about the shape of my data. If I can think about how this works at a high level, I can design my application around it such that it can scale to pretty much any load anyone throws at it.
maybe not if the data model just won't work well with a key-value DB.
Well, but what data is that? Consider CouchDB -- you get "views", which are essentially mapping functions, and you can also create arbitrary "reduce" functions. This means you essentially get a cached view of the result of arbitrary code execution, and these can each be pretty much arbitrarily parallized.
Most of the major databases can handle medium-sized data sets, say 10s of GBs to 100s of GBs, on a single server.
That doesn't tell anywhere near the whole story -- I handle terabytes of data on a single server with a flat filesystem, because they happen to be terabytes of video.
So what kinds of data, and what kinds of access patterns are we talking about? And how big a server -- how many cheap PCs could I buy for the same price? How are you going to handle availability -- that is, what happens if that one server goes down?
OK, you don't like SQL.
That is most likely a bad argument, yes.
However, without rooting it, Android still lets you install any app you want, from anywhere. You have to jailbreak an iPhone to be able to install any app from anywhere other than the App Store.
In other words, like so many other things, Android gives you a choice -- you can buy exclusively from an app store, and enjoy the dubious security and quality benefits of doing so, or you can buy (or download) from anywhere. Apple removes choice from you -- you can only buy from the app store.
I would also argue that it's nice to have the source for the OS once you root it, and it's nice that there have been Android phones sold which were entirely unlocked and allowed root. With the iPhone, you were always breaking the warranty, and until very recently, you were breaking the law -- there never was an iPhone you legitimately had root on.
In other words, Android isn't a huge brand. So what?
The non-technical people I know who have an Android phone may not necessarily realize it's a "competitor OS", but they certainly know it's a competitor phone. They might credit HTC or Motorola, they might call it "Droid" instead of "Android", but they know they got a smartphone.
If they didn't, they wasted a lot of money compared to a "non-smartphone", which are absurdly smart these days.
the marketplace _really_ is big enough for Android, iOS and RIM to coexist ...
I'd hope so. But if it really is, I'd also hope developers would start to realize that Android and RIM won't rape them, or will at least use some fucking lube. I'd imagine that if we see enough cross-platform apps that aren't on the iPhone, we'll start to see some converts.
After all, it worked for the PC -- pick whatever hardware you want, Windows (and all your apps) will run on it, even if it doesn't work as smoothly as a Mac.
So you think Mac's being "closed" hurt them more then being over 2x as expensive and slower than the equivalent PC?
Except they haven't been, for a long time. I've generally found that if I price out a PC with all the same features that, say, a Macbook has, it's going to cost about as much as that Macbook, unless I start adding RAM.
The main reason people believe this is that you can price out a PC with almost-equivalent specs, which certainly have all the specs you care about (and beat the Mac on a few), for about half the price.
If the general public prefers "openness" then how do you explain the lack of iPod Killers?
An iPod is a legitimate candidate for being an appliance. However, it's still not the only mobile music player, and if the general public doesn't prefer "openness", how do you explain the push against DRM, to the point where even Apple has un-DRM'd their music store?
according to the keynote yesterday, Apple still activates more iOS devices (iPhones +Touches + iPads) then all Android devices combined.
Which keynote?
You might consider that the person who has this flash requirement, such as yourself, should be savvy enough to find a way to get flash operating on the iPhone.
Why should I bother?
Why should I give my hard-earned dollars to buy a computing device which is going to make me jump through hoops before I can use it as a computing device?
So effectively the option is there.
Only now that Jailbreaking mobile devices, specifically -- a ridiculously restricted definition of jailbreaking -- has been legalized. And Apple has made it clear that they would much rather it was still illegal, so yes, I will avoid giving money to Apple for that reason.
If your aim is to move design away from a format that you consider unstable/unsuitable for your environment, then the majority of people who don't have an opinion should not be given access.
Why not? They're perfectly capable of seeing the difference for themselves, particularly if the default was click-to-enable. If you want to be especially obnoxious, provide huge warnings like "This WILL kill your battery life. Are you sure you need to see this page that badly?"
This will apply pressure to designers to seek open standards compliant formats.
No it won't. It'll apply pressure to designers to support whatever formats the iStuff allows.
As a trivial example: Last I checked, any sort of modification to the web browser wasn't allowed in the app store. One such modification would be supporting alternate video formats -- in part, because the iPhone has a hardware h.264 decoder. So in this instance, Apple is specifically pressuring designers to seek closed standards that work on iPhone (h.264) rather than open ones which work most other places (theora and WebM).
More troubling, designers seem so eager to make sure their stuff works perfectly on iStuff, they're going straight for the app store. Comic books are "apps." WTF? Is it 1995 again, with everyone wetting themselves over CD-ROM encyclopedias? More than once, I've seen something which would work just as well as a web app (and thus, work on iPhone, Android, PC, etc) be released instead as an iPhone-specific app.
Still more troubling, Apple has placed some requirements which effectively mean that cross-platform UIs cannot be developed if one of the target platforms is an iPhone app, and they are aggressively anti-cross-platform.
Sure, I'm glad it helps HTML5, but on balance, I'd rather the iPhone never existed.
Both.
Mostly the principle of the thing, and how it's reflected in every aspect of the device. I do tinker. I've written my own adblocker -- took me an afternoon, from having no experience with the Chrome API, to having a satisfactory adblocker, and that's not the only extension I've written.
With iStuff, even if I'm willing to do stuff myself, I can't, and that's not OK, either in principle or in practice -- I do rely on things I've written myself.
And yes, I would really like the ability to turn Flash on for certain sites, even if I'd probably leave it disabled most of the time on a mobile device.
I'd rather live in a country where it's legal to eat shit, even if I never intend to do so myself. Because when they outlaw shit, that means they're telling me what I can and can't eat, and next thing you know, they'll be outlawing burgers because they're unhealthy, or certain brands of chocolate for being too orgasmic, or...
That's what it feels when browsing a web site with flash on it on my N900.
...so turn it off? Your N900 is, if I recall, a perfectly capable Debian system, which means you could easily swap out the browser for any other browser, uninstall the plugin, etc.
By contrast, an iPhone has made the choice for you.
And you don't always know that there's flash somewhere.
It's called "Flashblock."
On the other hand, I'm glad I know I can trust my iPad to last for 10h of full use on a single full charge, even if that means that I can't see annoying ads or poorly designed websites.
Even if some of those "poorly-designed websites" are things like the Daily Show. I agree, it should be using HTML5 -- maybe it is on iPads -- but I'd rather have the ability to run proprietary crap and see those pages, and yes, burn some battery life, than have the decision made for me.
It is not unreasonable to restrict choices to things that only work at least as well 99% perfectly.
So by that logic, you should disable wifi -- any time some asshat turns on a microwave, the wireless signal drops.
Flash does not cross that threshold on my laptop, I do not expect it to even approach that threshold on my iPhone.
So you could disable it. That doesn't explain not offering it as an option.
I allow it to run infrequently, and only when there is no other option on my laptop
Sounds like, if it was available, you'd do exactly the same with your iPhone. Since it's not, you rationalize it away.
frankly, I wish I had the same h.264 hardware decoder on my laptop that I do on my phone
You probably do, if you've got an nVidia card in your laptop. Of course, Firefox will refuse to use it.
"cross platform" API.
Ah, but it is fairly cross-platform, except for your iPhone.
Of course, instead of that, you've got HTML5, which is also cross-platform. Why the quote marks?
Furthermore, if you accidentally click on a link with Flash content, your browser may slow to a crawl.
Or you could have the option to enable or disable Flash at will. In what way would not having that option make your life better?
The only reason I posted at all is because I get really tired of the "atheism is a religion/no it's not" argument. It's sophomoric, pedantic, and silly.
What? No, it's actually fundamental to the debate, and it undermines almost everything you said.
The epistemological observation is made that people "believe" a lot more than they "know," and it turns out that in the realm of belief-prompted-actions, atheists and Christians and Buddhists and everyone behave in strikingly similar ways.
Certainly -- except that "no god" is not a belief of any atheist I know. It's merely the default position. Neither knowing or believing has anything to do with it -- it's simply not knowing.
We want other people to believe what we believe.
Again not something I find terribly many atheists have as a goal -- at least, if you are talking about the lack of belief as a belief.
Nor do I necessarily care that other people share most of the things I do believe. I believe I'm a decent programmer, but I really don't care what you think.
The primary goals are much simpler: We want others to stop preaching at us and others, we want public and political debate to be informed by reason and evidence instead of emotional and biblical appeals, and we want people to stop making assumptions about atheists -- in particular, that we're evil, though the assumptions you made about beliefs are annoying also.
I know a few people who are quietly atheist. Perhaps agnostic would be a better word, as they do not believe in God,
Nope, that's atheist, and the more people who use the term properly, the less often I'll have to answer "Prove to me God doesn't exist!" or worse, "Prove that atheism is true and correct!"
And then I have met many atheists who are zealots, or at least hobbyists, about it. Their disbelief is not a passive thing, but an active assertion, a passion, an argument they must make at every possible opportunity.
And yet, we should make a distinction here -- the disbelief itself is very much passive, and even in the most "militant" atheists will admit that, given sufficient evidence, they would believe. It is the consequences of that disbelief in light of such ubiquitous belief that leads to the "passion" you're talking about.
I have a passion for truth.
Robert Pirsig once observed that very few people run around screaming that the sun is going to rise tomorrow. Things we are deeply certain about generate very little in the way of zealotry.
This is largely because not only are we very sure of it, there isn't much argument about it. If there was a large community of people in the desert who were absolutely convinced the sun wouldn't rise tomorrow, and thus not concerned about finding shelter from the coming heat, then hell yes, I would be running around screaming that the sun would rise tomorrow to anyone who would listen.
...really? I'd rather have the option than not, but I guess that's why I don't buy iStuff anymore.
Firefox does not embed IE by default. The user has to install a third-party addon to embed IE, and hardly anyone does that.
Yet you seem to be against even allowing a common API for third parties to add on codecs.
There isn't a native and licensed H.264 renderer you can call out to on every platform, either.
IE's renderer exists on exactly one platform. H.264 exists on nearly every platform, and by "exists", I mean "already installed, or available at zero cost." Refusing to support native codecs is like refusing to support WebGL because the best GL implementations happen to be composed of both proprietary hardware and software.
to support viewing of content that isn't in an open format or coded to open standards.
Or to make it up to the user whether or not to support that. Or to use existing hardware renderers on a given platform. Or, yes, to support viewing of content that isn't in an open format or coded to open standards, but is significantly more open and useful than the same content in a less open format (Flash).
That's just a statement about today. Look at the qualifiers I italicized. They will change in the future.
How so?
If Linux adoption grows, the "rely on the OS" approach will cover fewer people.
So nVidia cards would become less popular among Linux users? Or is it that you don't think Linux will grow by vendor support, like Dell's Ubuntu, which includes codecs?
By encouraging the widespread use of H.264 now, we'd just be handing over free leverage to the patent cartel that is MPEG LA, and they will use it...
...for how long? Patents expire.
And just what is this nightmare scenario you're envisioning? It looks to me like they already have control. It looks to me like they have more control than they ever dreamed -- they can dictate which player you use (Flash, Silverlight, etc), because there isn't a common browser-based standard for people to use.
Actually, it is, because security is Firefox's business. Giving untrusted websites free reign to load dozens of unknown external libraries and feed unchecked data to them is a very bad idea.
Out of curiosity, do you roll your own IP stack, too?
Giving untrusted websites free reign to feed data to libraries provided by the OS seems like an inevitability, and a far safer prospect than providing a model in which any local program can install plugins or extensions which load into the browser process and arbitrarily muck with any arbitrary page.
Firefox shouldn't get in the way and it wouldn't get in the way. Hardware accelerated decoding is a good thing. But it should actually be hardware accelerated decoding, not hardware enabled decoding.
In other words, Firefox shouldn't support WebGL unless it ships MesaGL? Really?
I don't want a dongle to be required for a fully functioning browser.
Even one you already have? How many devices do you have which don't already have a decoder of some sort?
Nobody is stopping you. You even have access to the source code to make it happen.
The source code isn't all I'd require -- Mozilla owns the Firefox trademark, so whatever I created, the result wouldn't be Firefox. I may as well stick to Chromium.
It is MPEG LA that's trying to take away your right to use H.264 so they can sell it back to you.
Except they haven't. Right now, they have given me the right to use it -- at no cost, and with significant improvements over all other codecs, including but not limited to native hardware support.
And I do -- in Flash and in Chrome. But because of Mozilla's choices, I can't in Firefox.
In other words, you are taking away my ability to do something because the MPEG LA might take
Most major databases support nested transactions. If the ones you've had to test against don't, that would be a real PITA.
I'm probably thinking of something like SQLite. Good point, though.
Of course, there is the added problem of being able to access the result of running a given failed test before rolling it back. Should we dump the entire production database to do that?
You would need to do essentially the same things with any persistent store, right? Unless you mean to test against production data...
Eventually, the idea is to test against a clone of production data, which is I think what you're suggesting. However, there are a lot of tests you can do without even touching the database, and a lot more you can do with generated data. This means you need a quick way to get a completely clean datastore, and a quick way to get a datastore which is a clone of a given snapshot of production. (Has to be a given snapshot, otherwise you might have a test that fails on one run and succeeds on the next.)
OTOH, why do you care if your web app that doesn't need ACID happens to run on an ACID database? ACID is usually transparent to the application programmer, and I would assert that most web apps will never grow large enough to notice any performance hit, assuming a reasonably sane schema is in place.
As soon as you grow beyond a single database server, that's a serious performance hit, or quite possibly an administration nightmare, assuming your chosen database can scale to multiple servers -- last I checked, Postgres only does replication.
Also, SQL is ugly. If I don't need ACID, why should I put up with it? More generally, if my web app doesn't need ACID, why would I want to use an ACID-compliant database at all?
Hardly any of our web apps are ever going to become the next Google, Amazon, Twitter, or whatever.
Even without that, I'd like to be able to handle spikes in traffic gracefully. While I doubt it was the database that was the bottleneck, recently, a number of students in my physics class have been unable to work on or submit online homework, because the online homework system seems to buckle under the load of all the procrastinators. Being able to trivially scale the database with the application is still a Good Thing, even for a tiny app.
I'm guessing it's a comparison between Drudge and Jon Stewart -- that both put other "real" reporters' feet to the fire.
Why do we use quicksort when there are other approaches to sorting?
That's actually a good question, and many languages have switched to things like mergesort as a default sort.
If only you could start something like a "transaction", which you could then "roll back" after finishing the test, leaving the database in its original state.
...which means you now can't test transactions.
And if you could somehow "back up" the database and "restore" it on a test server, or under a different name.
That'd be obnoxious, but sure.
If you've got multiple users and connections, you want ACID.
Spoken like someone who's never written a web app.
Let's take Slashdot as a trivial example. Do I need transactions to be atomic? That'd be nice -- I don't want to see half a post succeed and the other half fail -- but it isn't really needed outside profile settings. Consistency? Posts really only depend on their parents, which are immutable -- pretty much by definition, if a user can see a parent post to reply to, by the time Slashdot will let them reply, that parent post will be committed. How about isolation? Nope -- if two users post two comments simultaneously, the application can trivially figure out which one should go on top -- no need for a transaction. Durability? Again, I don't see this being needed anywhere but in the user's profile.
So, we could take atomicity and durability as useful and easily drop isolation and consistency -- they simply are not needed and add zero value, unless I'm grossly misunderstanding what they are.
If you want to see what it's like without those protections, go use Mac OS 9 for a week or so,
Or an embedded system. Or an OS kernel.
Yes -- that is another common point of FUD.
Really, I don't understand this argument. "Why don't the browsers just use the system's video support?" How about this: why don't *websites* just use the system's video support?
If by that you mean the object tag, well, consider what you can do with a video that you can't necessarily do with an object. Compositing, pause/play or otherwise control, point it at a Base64 data URL, etc, etc. You acknowledged this:
the HTML5 video tag has a lot of properties and JavaScript behavior that needs to be guaranteed to work, or we won't have gotten anything better than just using an object tag.
Which would be exactly the point of using the native video framework, yet inside a video tag.
YouTube could already play its h.264 source videos just fine on my system without using Flash, but this has never been an option without using a greasemonkey hack
Because YouTube wants to be able to do things like stick an ad in front of the video, then start the video once the ad finishes, or float an ad, or annotations, etc on top of the video, or deep-link to a specific timecode.
So what, exactly, is the problem with the platform APIs?
I don't think most platform video libraries expose the sort of low-level stuff that the spec demands.
Citation needed, especially as Safari already uses QuickTime, or whatever they've got on the iPad, to do just this.
And why not also embed the IE engine for compatibility with IE-only sites?
Aside from the fact that this has happened and it wasn't the end of the world, there simply isn't an analogy here. There isn't a native HTML renderer API you can call out to on every platform, or a reason to do so.
However, on pretty much every platform Firefox supports, there is a native video API, and that native video API most likely supports h.264, not that it's any of Firefox's fucking business what codecs it supports. For all Firefox knows, I could have a Linux-only hardware-accelerated theora card -- why should Firefox get in the way by insisting it's all software-based, so Firefox can keep a stranglehold of control on it?
I've got h.264 in hardware and in two OSes on the same machine. I've also got Firefox on the same machine. And it's only fucking zealots like you that keep me from connecting the two together.
If Firefox can't support GPU rendering on all operating systems, then it shouldn't support it on any.
Fixed that for you. Does it still make sense?
If so, why does Firefox currently support GPU rendering? It doesn't work on all OSes -- not all OSes have drivers for modern enough GPUs to make this work.
If not, what is your argument?
We don't need to regress back to the days where websites only work if you have the "correct" OS.
Yeah, just keep repeating that as if it's an argument. I mostly agree with you, but I find your methods disgusting. You would restrict my freedom to ensure I have freedom. Do you realize how pathological that is?
If Firefox implements H.264, then what's next? ActiveX?
You've gotta be joking. ActiveX isn't cross-platform.
Guess what is?
That's right, the netscape plugin API, which Firefox still supports, which enables them to run Flash, which is far worse than any codec which could conceivably be used for HTML5 video.
We don't need to regress back to the days where websites only work if you have the "correct" OS.
The "correct" OS being Windows or OS X, or if you've got an nVidia card, Linux, Solaris, or FreeBSD, or Apple's iOS, or Android, or...
You're kind of losing the high ground if your complaint is really that you can't legally play HTML5 video on AmigaOS or BeOS.
or, another translation, "I can't wrap my brain around Rails/Ruby, and wish I could do things the way I would do them in [fill in the blank]".
While that's often the case, I've got a patch in rails-core, I've got over a year of Rails experience, and I've written a few Sinatra toys which run on Google App Engine.
So yeah, I think it's reasonable to say that I know Rails and Ruby.
Flash is a plug in as are Windows Media and Quicktime. You don't have to install the plug ins if you don't want to. Which coincidentally is how Mozilla is handling the problem of H.264 as well, if you get the plug in you can play it.
BZZZT!
Nope, in fact, that's the point, that's what I've been saying for months now -- things would be much simpler if Firefox allowed this kind of thing to be based on plugins, even better if they simply delegated to the system's native media framework. They don't, they refuse to -- I know of no way to play H.264 in an HTML5 video tag in Firefox.