First, let me say that SELinux is an enormously complex system that has the potential to provide huge security benefits for administrators, and that it is the bar by which other OS security infrastructure should be measured against.
With that out of the way, you're comparing apples to orange-seeds here. UAC is merely a component of the overall security model, and should most directly be compared to gksudo, sudo and su and other methods of user-initiated rights elevation. Additionally, the Windows security model does support some really fine-grained stuff now with mandatory access controls, support for signing trusted executables and all sorts of other complexity that the IT administrator can get into if they want. It's not as easy as SELinux yet, I don't think, but it's not far away either. It's not vetted by the NSA either, so I suppose that'd be a minus.
So do what every other computer platform in the damn universe does - let everyone publish applications and have the market sort out the good from the bad.
You seem to be missing something: I don't want to have to sort through piles of crappy apps in order to find a decent app. I'm perfectly happy to have an official "store" or "repository" that's rejected the malware, filtered the crap out, and told the developers to fix the bugs.
Chances are you posted this from a PC (in the larger sense, including Mac, *nix, etc) did you use an "app store" to figure out what software to put on it? No? How did you ever survive?
Amusing. As a matter of fact, I did somewhat use an "app store" of sorts. And chances are, so do you but you're just too arrogant/ignorant to admit it. You see, I downloaded the apps I'm using from a stable apt repository, which is vetted and maintained by volunteers of a sort. And they tell people "No, your app/project can't get into this repository until you fix @bug_reports or for whatever other stupid reason I care to name". But we don't see you railing against the Ubuntu maintainers.
After all, there's must be a billion useless or even actively harmful applications out there. The answer, of course, is that you're a grown-up who can decide for him/herself what to put on your machine. Why can't I do the same with my iPhone?
There's a couple
We've proven time and again that even grown ups don't have the common sense not to install malware (even that which actively announces itself as such) - even if they should (technically) be allowed to install "crap". The interesting bit is that "crappy software" colors people's perception of what they own. What would you think if someone said "oh look at my new phone" and you touched the screen and it crashed? Well you damn sure wouldn't buy it, and chances are they'd be really unhappy with it too. Thus, what Apple's doing by controlling all the apps that people put on their iphones is controlling the expectation that the phone *works* and works *well*.
Even so, the complaints about the app store really boil down to (roughly) three complaints.
1: I think Apple is draconian and evil and I want alternative/competing app stores! Well, let me ask you a couple of questions about where this leads. Are iphones going to keep working if people install random malware and broken apps on them? No. Is Apple going to make money off of the apps bought at a competing app store? No. Are there going to be entire "app stores" that distribute nothing but malware? Yes. Is this going to look bad for Apple? Yes. Should Apple do it? No. Is Apple losing money by not allowing this? No. Do they have any compelling reason to do it? No. Case closed.
2: I WANT OPEN SOURCE SOFTWARE AND LINUX AND GREP RA RA RA. Again, this comes down to Apple controlling the user experience and guaranteeing a positive one. I'm sorry, but this is not the year of the Linux desktop and really it's not the year of the Linux phone either. User experiences tend to be pretty poor: see the Open Moko for a prime example. While cool to geeks like us, it wouldn't be cool to a geek like my wife who just wants the damn thing to be usable and work.
3: I want to run an iPhone Botnet! Yeah, DIAF. The internet has enough of these.
But logic for why it's bad for the Apple, bad for the iphone, and bad for the consumer market in general won't convince you. You're too busy riding your high horse to realize that what you're demanding simply does not make sense. You're too busy to look where your examples really point: to things like Windows (malware-bug-land) and Linux (Virutally unusable hacker-only-land). I mean really, if you're going to demand these things then you already know that the iphone is not for you. Why must you spew your drivel and pester those of us that just want a usable working device with a good solid high quality app store?
How many of them are good? Well, quite honestly alot more are good than if there was no review process at all. If there wasn't a review process, we'd see apps that ignored or borked your settings, leaked memory like a sieve, chewed through your battery life out of ignorance, or hell - maybe we'd simply be looking at a deluge of carbon copy flashlight and porn apps, making the app store effectively useless. Hell, in my opinion (and I do have an iphone) the app store already has *too many* apps, and the quality on the ones there aren't quite high enough for my liking.
I suppose you could think of it this way: you're looking for a needle (good app that does what you want) and you can either search in the pin cushion full of mostly needles and a bit of straw or you can search through the whole fricking hay stack yourself. I'll take the pin cushion, thank-you-very-much.
Also, I'm not sure that you're really qualified to say anything about the relative quality of the app store. You don't, afterall, actually have an iphone.
I really have no idea how many rows/day the likes of Walmart throws into a database. 100 million a day wouldn't surprise me. I just have a hard time believing that Google/Amazon/ is the biggest DB users in the world.
There are two kinds of data stores: those that simply store data and those that retrieve it as well. I very seriously doubt that Walmart needs fast random access into the database. Consider:
- Walmart (as of last reckoning, Aug 2007) had a 4PB database and handles 276M+ events/day
- Yahoo handled (as of May 2008) 24 billion events per day over a 2 PB database. For reference, Visa handled 50 million events per day, and the NYSE 225M/day.
- Google seems to be secretive about their db size, but indexes at least 3x as much as Yahoo (implying at least a 6PB database just for web searches... notally neglecting gmail, youtube, etc), and accounts for roughly half of all internet searches. And they store every bit of it.
So, I guess what I'm saying is that it doesn't matter whether you have a difficult time believing that companies like that are the biggest DB users in the world.. they are. Saying otherwise simply because you have a "hard time believing it" is roughly equivalent to sticking your head in the sand.
(btw. throwing around the word "vast" like it has some specialized meaning outside of some small group of people is just incredibly wrong)
I would say it's actually quite correct. Judging from your estimation of 100M rows/day as being huge, and from the email in my inbox, I'd say that most people consider a few hundred gig to be a really large database and a terabyte to be a virtually inconceivable amount of data.
So yeah, I'd say that the people that deal with petabytes of data have a rather different definition of "vast". Arguably, one that you and I really don't comprehend... but I comprehend enough of it not to doubt then when they say that the relational model breaks down with a hundred TB almost no matter how much hardware you throw at it!
This statement, taken as a whole is pure nonsense. "Databases" scale quite well for "vast" amounts of data. There's retailers that store millions of transactions a day on relational databases that would be out of business if they didn't.
A couple of comments:
- Databases do not in fact scale well to "vast" amounts of data. In fact, the stating that they scale to vast amounts of data makes me think that either you've essentially got an unlimited hardware budget to throw at your problems (and even that only takes you so far) or you've never actually dealt with something that *is* a vast amount of data.
- Millions of rows per day is barely a noticeable amount of data... let alone "vast"
If I had to guess, I'd say that relational databases might not be a great solution for a quickly evolving web company with possibly constantly changing data structures and new requirements being added. Doing all that glue code sucks, and patchwork solutions like Hibernate aren't much better (and IMO worse).
Actually, I'd argue the opposite. A relational database is exactly the way someone in that situation should go unless they know from the start that they will be seeing "vast" amounts of data (hundred million rows/day, etc). You can think of SQL as a really high level programming language for data access, complete with very mature libraries for delivering that data to whatever language you should choose to write your app in. Think of it like Rapid App Development.
However, there will (sometimes) come a time when you've pretty well exceeded what a database is going to do for you (I'll spare you the details of how painful this process will be when you discover where that limit is). Then you either need to distribute your database (Greenplum, RAC, etc) or you need to reevaluate why you're keeping it in a relational database in the first place. Where I work, where we work with marginally "vast" amounts of data (~10TB of online data for the last 6 months I think) we chose to get our tushes largely out of the database for data processing.
It shouldn't be surprising that a tool developed for one purpose isn't well suited to all purposes. Creating some kind of "movement" out of it is about as stupid as being against hammers in favor of screwdrivers. Down with hammers! Yeah screwdrivers!!
Actually, I find it funny that you assume they're trying to use the wrong tool for the job. Like you said: it shouldn't be surprising that a tool developed for one purpose (relational databases) isn't well suited to all problems (actually vast amounts of data) in it's problem domain. Think of it like this: you wouldn't use a wrench to change your car tire (though you probably *could*). You'd use a 4-way, or maybe even an air gun. SQL can be just as underwhelming as said wrench when dealing with actually vast amounts of data, specifically for the same reason I'd pick it when dealing with lesser amounts of data: it's simple and fast to write.
I would think that having a "regular job" is somewhat front-loaded money. They pay you, you do the work. Going off on your own, being an author, writing a book, magazine, painting, whatever is not so front-loaded. Nobody's paying you up front for your work, and there's really no reason that they *should*.
Also, not everyone rushes out and buys the books *ALL AT THE SAME TIME*. I go buy 10-20 year old books all the time... and you know what? I WANT THE AUTHOR TO GET THEIR CASH FOR IT. Otherwise, I'd have bought them *used*.
PL/I -- "the fatal disease" -- belongs more to the problem set than to the solution set. -- Edsger W. Dijkstra, SIGPLAN Notices, Volume 17, Number 5