Actually, it is. The only difference is that community rules lead to pressure, and the collective author ends up writing highly structured, linked documents -- most of the time.
And where's the evidence that "actually being paid" makes these articles better?
Anecdotal evidence on my part. A simple example: I've found The Rails Way to actually be a better reference -- not tutorial, but reference -- than the API docs and Google combined.
Of course, as a user, I'd rather have a publicly available, free resource, and heavily structured if it's to be a reference. Despite this, the sheer quality of that book, and the occasional sparseness of online documentation (especially concerning best practices), made it worthwhile to pay for.
Only difference with Knol is, I'd get it for free.
I find two dissenting articles much less useful than one homogenized compromise.
Sometimes. Sometimes, the homogenized compromise is simply wrong. Often, Wikipedia doesn't manage that -- you still have the two dissenting articles, but it's a lot harder to tell them apart (you have to dig through the edit history).
When I want to do an analysis, I just go to the primary literature.
Knol could be that primary literature.
But I don't think it is.
It's been out for exactly one day. What did Wikipedia have after 24 hours?
I am predicting that Knol will have some better articles than Wikipedia. But honestly, neither of us knows yet.
Because people have an interest in communicating their view of the world.
That sounds more Knol than Wikipedia -- Knol is all about a personal point of view. Wikipedia only helps you "communicate your view of the world" if that view is from a neutral perspective.
Furthermore, Wikipedia is not for original research, which is why you see all those [Citation needed] stickers.
I think Knol just misses the point of Wikipedia and why it has become so successful.
Because you've bought into the Slashdot meme that Knol is meant to be a replacement for Wikipedia. I'm not sure it is.
But I'll argue it could easily become a replacement for O'Reilly.
Democracy is the worst form of government imaginable, except for all the others which have been tried.
Unix is the worst OS ever, except for all the others...
Building a rich user interface in a web browser is a stupid idea. But it has features found nowhere else.
Tell me where else I can try out an app with zero risk to my system (barring a security whole in the sandbox)? The only alternative I can think of is a virtual machine (complex and resource-intensive to setup), or a chroot jail (complex and limited).
Tell me how else I can build an app which is always up to date? The best I could do is "scan for updates", and it would still involve some latency while I patch the client-side code. With a web app, all that has to happen is for the cache to be invalidated -- automatically.
Tell me how else I can build an app which has such a low barrier of entry? It is hard to beat "nothing to install".
Tell me how else I can give so much hackability to the end-user for their own UI, while maintaining the integrity of their data? Greasemonkey, simple tabbed browsing (and bookmarks, back/forward, etc) -- these and others give the user a fair amount of control without me having to think of every possible workflow. Even tweaking browser settings gives the user the ability to change font size, color, background color, etc -- again, without me having to lift a finger.
It's a stupid idea, but it works amazingly well, despite that no one's gotten it "right" yet.
Glancing at your other comment, do you actually have anything valuable to say, or are you just being pedantic? Why, exactly, shouldn't we use the web browser as a rich platform?
As I understand it, at least a few codecs we know of as "protected by patents" are actually mostly open -- just some crucial mathematical function has been patented, and it's impossible to build a working encoder/decoder without it.
NOT having an account lockout means someone can brute-force a password.
Unless said account number or password is sufficiently long/unguessable. Or unless your bank actually uses real two-factor authentication, or at least public-key authentication.
You could probably minimize the problem by doing the lockout by IP address or something
Or something. Some measure other than the target account. By, say, IP address and user-agent wouldn't be a bad idea -- with a somewhat higher threshold to block the entire IP.
Then again -- none of the servers I ssh into on a daily basis have passwords set, on any of their accounts. None of them have account lockout policies. All of them simply use SSH RSA keys.
That blog seems to want software patents to continue -- not surprising, really, given that it's a "patent law blog", and lawyers are the ones with the most to win from the cottage industry of software patents.
While I doubt this ruling will stand, I hope it does. Google has an enormous amount of manpower to throw at this kind of problem, most of it highly intelligent. The only way this hurts Google is if a competitor is able to implement PageRank (and other features) so much better than Google that people start to switch -- and I doubt Google will be standing still as this happens.
The fact is, software patents have had an overwhelmingly detrimental effect.
Does anyone really believe that, for instance, h.264 would never have been invented, were it not for patents? It would either have been open, or some interested party would have paid for the development.
As it is, while it's relatively cheap to obtain the computing power needed to, say, transcode a large library of video to h.264, the licensing cost can end up being something like $2500 per machine used in this capacity. And because of the longevity of patents, it seems unlikely that it will expire before a better encoding option surfaces.
Yeah -- ever wonder why YouTube took so long to convert everything to hi-def, when they have the computing resources of Google available? I think we know now.
I can imagine software patents being a good thing, but not in their current form. Getting rid of the 15-year-monopoly on an ephemeral idea or a mathematical function can only be a good thing for society as a whole.
The concept of two-factor authentication is stupidly simple: Something you have, and something you know.
Somehow, banks (and credit card companies) seem to be confusing this with "two things you know" -- which actually isn't one bit more secure than "one thing you know".
The reality is, all the technology to do this right exists. It is trivial to do. But banks don't want to pay for it. (Which, in itself, is a WTF -- I'll gladly pay some extra for an RSA key auth scheme for my bank, so if the concern is that most users wouldn't notice or care, that gives you an excuse to get more money out of the ones who do. But instead, you just leave everyone somewhat less secure and more irritated than with PayPal.)
Knol articles are just that: plain articles with very little structure or linking.
They are, however, searchable -- and more easily searchable when you can get the whole thing as one page.
And "very little structure or linking" is entirely up to the author -- but at this early stage, there is at least less to link to within Knol.
And I don't think that one expert can compete with dozens of people collaborating on an article.
It's not so much "one expert" as "one person, who is actually being paid" -- not to mention that having two well-developed, dissenting articles could be more useful than either the homogenized compromise in the Wiki page itself, or the archived flamewars on the Discussion tab.
It's the Mythical Man-Month all over again.
A lot of the stuff on Knol is CC. Perhaps it could legally be incorporated into Wikipedia. But, frankly, I don't see why anybody would bother.
Perhaps if the content is good?
Why does anyone bother adding things to Wikipedia? If you can answer that question, see if it's applicable to migrating Knol articles to Wikipedia.
With things like the Wikipedia search box in Firefox people can go directly to the Wikipedia page on a subject rather than type it in to Google.
However, I usually search through Google first, even if the first result might be Wikipedia -- because Google is a broader search.
Wikipedia may well have a detailed, informative article, which links to decent external sources -- then again, it might have no article, or a biased, poorly maintained article.
If I search directly on Wikipedia, the lack of a Wikipedia article means I'll have to repeat that search on Google, or elsewhere -- plus, the Wikipedia search is slower. If I search on Google first, if there's a Wikipedia article, great, it's one click away -- and if there isn't, I've still got a page full of useful results.
Hence Knol. Google's competitor to Wikipedia. But it's too late. Good.
Why is that good? If Knol can actually do a better job than Wikipedia, what's the problem?
I'm not entirely sure why I should trust Wikimedia with my personal information any more than Google. The only real advantage here is the possibility of releasing something anonymously -- which I can still do, through Wikipedia, or Wikileaks, or somewhere else.
Creative Commons means that if someone really has something to add, and I won't let them (or co-author with them), they can always re-publish as their own version -- in this sense, Knol is to Wikipedia as Git is to SVN.
And it means my work is still out there to read, for free, but I'll be getting paid, which means I'll have an incentive to spend more time on it. Say what you will -- Wikipedia is great for the kind of reference material which is truly a list of indisputable facts -- but commercial books (technical manuals, etc) often have better quality for things like teaching fundamentals, or, occasionally, simply being more comprehensive even than the official online documentation.
That would be the main reason Knol could work -- capitalism.
I was all set to rant about what license they wanted to publish on, and would Google own everything, etc.
But it looks like they're going with Creative Commons or keep it to yourself. And I don't see any requirement to sign over the copyright, so I could always publish something both on Knol and elsewhere, under entirely different terms. Cool!
I could, however, rant about how it's not a wiki at all.
I think most DNS servers disregard TTL values of under 60 minutes, no?
Actually, I don't know. If you're right, then sure, Elastic IP is a much better solution.
We are using dynamic DNS for internal things (where's the DB server now?), and neither Amazon's internal nameservers, nor my ISP's, nor anything in between, seems to be slowing it down. I've got a TTL of 100 on that.
The point is why introduce yet another incompatible format into the mix?
Ask Microsoft.
ODF was intended to be one standard, to replace all the existing ones. It had support from some government agencies, which were planning to mandate its use internally. That's the one thing that finally got Microsoft pretending to do open standards -- OOXML may have come first (I'm not sure), but it wasn't viable until ODF became a threat.
With how many suites of apps to create them?
And that's the point. With a standard, it's possible to actually have competing or niche apps which share the same document format.
Really? I bet she doesn't, you know....I wouldn't call that "knowing" Word.
It is, however, much more "knowing Word" than it is "knowing LaTeX." And yes, she can and does format things properly.
Funny how you presume to know what she's like, having never met her.
Or is it that you interpreted "knows Word" as "has used and memorized every single feature Word has"? If that's the case, I don't know word, and I doubt anyone does.
probably even Emacs (the weird keyboard shortcuts wouldn't be an issue, because she doesn't use keyboard shortcuts).
Which means, if she's doing things visually, that she still would be better off with Emacs than with LaTeX.
One possibility is to implement it in Javascript entirely, and run it on the server in SpiderMonkey. Just saying...
You spend hours to get a border right, pixel by pixel.
Or you leave it alone -- let it be slightly off. Or let a designer write your CSS.
Consider, also, the use of straight HTML in your AJAX responses, rather than something like JSON or XML. It's actually reasonably terse, and you can always re-style it, or parse it manually as a microformat.
But also, you might strongly consider:
b) only provide additional functionality with Javascript/AJAX
I'd much rather have a framework make it easy to expose functionality both ways. But you can always think of them as two separate platforms. Is it really so much harder to enable things both with Javascript and without, versus, say, porting a desktop app between Windows/Linux/OSX?
(Or, people don't have the right framework yet;-) )
Using the DB example, a desktop app, you would have communication from App -> DB that could be handled in a single method. In a GWT app, you have Web Client -> Web Server -> DB, handled with at the minimum a method on the client to invoke the call, a method on the server to handle the call, a message class, and a callback class to handle the results are the minimums in a GWT app for the same task.
That would suggest limitations in GWT, not in the model itself. If you're really going to open the database up directly, without access restrictions, you can always implement a simple HTTP->SQL proxy, and send SQL commands back directly from JavaScript.
If this sounds like a horrendous security issue for you, good! It's got you thinking. A similar desktop app has exactly the same security hazards -- it would need a proper server (and not just a proxy) to be secured.
Given that I haven't heard of it, I somehow doubt it's "difficult to replace" on the level of normal GUI frameworks.
Given that the entire page you linked to appears white for me on Konqueror, with some script errors, I somehow doubt they're doing unobtrusive Javascript, or gracefully degrading Javascript -- which disqualifies them from "doing it right".
Because you've put it in quotes, I suspect it's sarcasm, right?
Because I wasn't exaggerating. There actually is a filesystem, for Linux, deliberately written for flash: JFFS2. It actually will not work on a hard drive without an additional layer of emulation, and it wouldn't perform as well or be as reliable as on a real flash drive.
It's called a takedown notice. That should shield you from any liability -- if the creators care, they send you a notice, and you make the video go away. Problem solved.
Of course, the real reason is:
Gaming videos are by nature significantly larger and longer than any other genre on Vimeo...
Really? Have they not seen Wormtooth Nation?
But there you go -- they're not really afraid of litigation. They're afraid of file size...
Of course Vista isn't optimized for SSDs, why should it have been? Is Windows XP optimized for SSDs?
Linux is.
Bigger question is, why isn't it possible to optimize Vista for SSDs? You speak as if Microsoft would have to redesign everything top to bottom in order to support them -- on my Linux, I'd have to use a different root filesystem, and that's about it.
On Linux, stuff which has just been loaded from disk by programs actually needing it right now is left around in RAM, until that RAM is needed for something else.
On Vista, if I am reading right, stuff which Vista thinks might be used someday is actually fetched into RAM, thus wearing out your disk and slowing down your computer while it does this, when most of the time, it's going to be wrong.
Trotting out a machine that is litteraly obsolete* as a case study
While technically true, this is also about right for low-end machines these days.
512 megs of RAM is most likely the biggest bottleneck for Vista. Machines are still sold with 512 megs of RAM.
And it is possible to get underpowered, integrated Intel cards. While not as slow as a GeForce2, the same thing applies -- Vista would struggle, but Ubuntu will show you far more eye candy and actually seem happy.
And while it might not be a Pentium4, you can almost certainly get a single-core Celeron at about that speed.
All of these will be sold to you as a "Vista Capable" machine -- or maybe it's "Vista Ready" -- whichever means "It's possible to boot the OS, but not do anything else." (What kind of sick fucking joke is that? Yes, they're literally selling computers which are not designed to be useful for anything other than booting an OS -- and no one uses a computer just to boot an OS, except perhaps Vista engineers.)
Yet these are probably better than the specs on, say, an EEE PC. There are new markets opening up for less powerful computers, and Vista won't be in any of them.
It proves something else, too -- you're basically admitting that Vista requires much more hardware than any OS has a right to, while providing no additional value. That is, it will require a much better video card, to show you much worse eye candy than Ubuntu. OEMs like that in the short term, for forcing everyone to buy insanely more hardware than they need, but the more innovative ones won't let that stand.
Why wait to fix Vista for your flash drive, when you could just target Linux, which actually has at least one filesystem designed and optimized exclusively for flash?
Except that similar RAD tools exist for desktop environments, too -- Visual Basic being the most famous, but there are others. The only advantage of a web app here is that it's cross-platform -- but you would also get that with, say, Shoes.
No, the cool, unique properties of a web app are pretty much entirely the user experience -- the fact that there's nothing to download, and no updates to manage.
That said, I'd develop just about anything as either a web app or a commandline tool, mostly because these are what I personally have experience with. I develop real web apps for a living, for the reasons I list above -- so when I want to develop a personal app to, say, track my weight, which am I most likely to use?
Slashdot Mirror
Yes, and in Wikipedia, it is not.
Actually, it is. The only difference is that community rules lead to pressure, and the collective author ends up writing highly structured, linked documents -- most of the time.
And where's the evidence that "actually being paid" makes these articles better?
Anecdotal evidence on my part. A simple example: I've found The Rails Way to actually be a better reference -- not tutorial, but reference -- than the API docs and Google combined.
Of course, as a user, I'd rather have a publicly available, free resource, and heavily structured if it's to be a reference. Despite this, the sheer quality of that book, and the occasional sparseness of online documentation (especially concerning best practices), made it worthwhile to pay for.
Only difference with Knol is, I'd get it for free.
I find two dissenting articles much less useful than one homogenized compromise.
Sometimes. Sometimes, the homogenized compromise is simply wrong. Often, Wikipedia doesn't manage that -- you still have the two dissenting articles, but it's a lot harder to tell them apart (you have to dig through the edit history).
When I want to do an analysis, I just go to the primary literature.
Knol could be that primary literature.
But I don't think it is.
It's been out for exactly one day. What did Wikipedia have after 24 hours?
I am predicting that Knol will have some better articles than Wikipedia. But honestly, neither of us knows yet.
Because people have an interest in communicating their view of the world.
That sounds more Knol than Wikipedia -- Knol is all about a personal point of view. Wikipedia only helps you "communicate your view of the world" if that view is from a neutral perspective.
Furthermore, Wikipedia is not for original research, which is why you see all those [Citation needed] stickers.
I think Knol just misses the point of Wikipedia and why it has become so successful.
Because you've bought into the Slashdot meme that Knol is meant to be a replacement for Wikipedia. I'm not sure it is.
But I'll argue it could easily become a replacement for O'Reilly.
Democracy is the worst form of government imaginable, except for all the others which have been tried.
Unix is the worst OS ever, except for all the others...
Building a rich user interface in a web browser is a stupid idea. But it has features found nowhere else.
Tell me where else I can try out an app with zero risk to my system (barring a security whole in the sandbox)? The only alternative I can think of is a virtual machine (complex and resource-intensive to setup), or a chroot jail (complex and limited).
Tell me how else I can build an app which is always up to date? The best I could do is "scan for updates", and it would still involve some latency while I patch the client-side code. With a web app, all that has to happen is for the cache to be invalidated -- automatically.
Tell me how else I can build an app which has such a low barrier of entry? It is hard to beat "nothing to install".
Tell me how else I can give so much hackability to the end-user for their own UI, while maintaining the integrity of their data? Greasemonkey, simple tabbed browsing (and bookmarks, back/forward, etc) -- these and others give the user a fair amount of control without me having to think of every possible workflow. Even tweaking browser settings gives the user the ability to change font size, color, background color, etc -- again, without me having to lift a finger.
It's a stupid idea, but it works amazingly well, despite that no one's gotten it "right" yet.
Glancing at your other comment, do you actually have anything valuable to say, or are you just being pedantic? Why, exactly, shouldn't we use the web browser as a rich platform?
It's not whether I like it -- more that I especially don't see what a comment about me being a "jackhole" has to do with Nintendo and controllers.
As I understand it, at least a few codecs we know of as "protected by patents" are actually mostly open -- just some crucial mathematical function has been patented, and it's impossible to build a working encoder/decoder without it.
Assuming you meant "login attempts per time period"...
Well, the point is that this would also make it possible for anyone to DOS every single person's account for a given time period.
NOT having an account lockout means someone can brute-force a password.
Unless said account number or password is sufficiently long/unguessable. Or unless your bank actually uses real two-factor authentication, or at least public-key authentication.
You could probably minimize the problem by doing the lockout by IP address or something
Or something. Some measure other than the target account. By, say, IP address and user-agent wouldn't be a bad idea -- with a somewhat higher threshold to block the entire IP.
Then again -- none of the servers I ssh into on a daily basis have passwords set, on any of their accounts. None of them have account lockout policies. All of them simply use SSH RSA keys.
That blog seems to want software patents to continue -- not surprising, really, given that it's a "patent law blog", and lawyers are the ones with the most to win from the cottage industry of software patents.
While I doubt this ruling will stand, I hope it does. Google has an enormous amount of manpower to throw at this kind of problem, most of it highly intelligent. The only way this hurts Google is if a competitor is able to implement PageRank (and other features) so much better than Google that people start to switch -- and I doubt Google will be standing still as this happens.
The fact is, software patents have had an overwhelmingly detrimental effect.
Does anyone really believe that, for instance, h.264 would never have been invented, were it not for patents? It would either have been open, or some interested party would have paid for the development.
As it is, while it's relatively cheap to obtain the computing power needed to, say, transcode a large library of video to h.264, the licensing cost can end up being something like $2500 per machine used in this capacity. And because of the longevity of patents, it seems unlikely that it will expire before a better encoding option surfaces.
Yeah -- ever wonder why YouTube took so long to convert everything to hi-def, when they have the computing resources of Google available? I think we know now.
I can imagine software patents being a good thing, but not in their current form. Getting rid of the 15-year-monopoly on an ephemeral idea or a mathematical function can only be a good thing for society as a whole.
Given how many banks employ Wish It Was Two-Factor authentication, I'm not surprised at all.
The concept of two-factor authentication is stupidly simple: Something you have, and something you know.
Somehow, banks (and credit card companies) seem to be confusing this with "two things you know" -- which actually isn't one bit more secure than "one thing you know".
The reality is, all the technology to do this right exists. It is trivial to do. But banks don't want to pay for it. (Which, in itself, is a WTF -- I'll gladly pay some extra for an RSA key auth scheme for my bank, so if the concern is that most users wouldn't notice or care, that gives you an excuse to get more money out of the ones who do. But instead, you just leave everyone somewhat less secure and more irritated than with PayPal.)
Knol articles are just that: plain articles with very little structure or linking.
They are, however, searchable -- and more easily searchable when you can get the whole thing as one page.
And "very little structure or linking" is entirely up to the author -- but at this early stage, there is at least less to link to within Knol.
And I don't think that one expert can compete with dozens of people collaborating on an article.
It's not so much "one expert" as "one person, who is actually being paid" -- not to mention that having two well-developed, dissenting articles could be more useful than either the homogenized compromise in the Wiki page itself, or the archived flamewars on the Discussion tab.
It's the Mythical Man-Month all over again.
A lot of the stuff on Knol is CC. Perhaps it could legally be incorporated into Wikipedia. But, frankly, I don't see why anybody would bother.
Perhaps if the content is good?
Why does anyone bother adding things to Wikipedia? If you can answer that question, see if it's applicable to migrating Knol articles to Wikipedia.
With things like the Wikipedia search box in Firefox people can go directly to the Wikipedia page on a subject rather than type it in to Google.
However, I usually search through Google first, even if the first result might be Wikipedia -- because Google is a broader search.
Wikipedia may well have a detailed, informative article, which links to decent external sources -- then again, it might have no article, or a biased, poorly maintained article.
If I search directly on Wikipedia, the lack of a Wikipedia article means I'll have to repeat that search on Google, or elsewhere -- plus, the Wikipedia search is slower. If I search on Google first, if there's a Wikipedia article, great, it's one click away -- and if there isn't, I've still got a page full of useful results.
Hence Knol. Google's competitor to Wikipedia. But it's too late. Good.
Why is that good? If Knol can actually do a better job than Wikipedia, what's the problem?
I'm not entirely sure why I should trust Wikimedia with my personal information any more than Google. The only real advantage here is the possibility of releasing something anonymously -- which I can still do, through Wikipedia, or Wikileaks, or somewhere else.
Creative Commons means that if someone really has something to add, and I won't let them (or co-author with them), they can always re-publish as their own version -- in this sense, Knol is to Wikipedia as Git is to SVN.
And it means my work is still out there to read, for free, but I'll be getting paid, which means I'll have an incentive to spend more time on it. Say what you will -- Wikipedia is great for the kind of reference material which is truly a list of indisputable facts -- but commercial books (technical manuals, etc) often have better quality for things like teaching fundamentals, or, occasionally, simply being more comprehensive even than the official online documentation.
That would be the main reason Knol could work -- capitalism.
I was all set to rant about what license they wanted to publish on, and would Google own everything, etc.
But it looks like they're going with Creative Commons or keep it to yourself. And I don't see any requirement to sign over the copyright, so I could always publish something both on Knol and elsewhere, under entirely different terms. Cool!
I could, however, rant about how it's not a wiki at all.
I think most DNS servers disregard TTL values of under 60 minutes, no?
Actually, I don't know. If you're right, then sure, Elastic IP is a much better solution.
We are using dynamic DNS for internal things (where's the DB server now?), and neither Amazon's internal nameservers, nor my ISP's, nor anything in between, seems to be slowing it down. I've got a TTL of 100 on that.
The point is why introduce yet another incompatible format into the mix?
Ask Microsoft.
ODF was intended to be one standard, to replace all the existing ones. It had support from some government agencies, which were planning to mandate its use internally. That's the one thing that finally got Microsoft pretending to do open standards -- OOXML may have come first (I'm not sure), but it wasn't viable until ODF became a threat.
With how many suites of apps to create them?
And that's the point. With a standard, it's possible to actually have competing or niche apps which share the same document format.
Really? I bet she doesn't, you know....I wouldn't call that "knowing" Word.
It is, however, much more "knowing Word" than it is "knowing LaTeX." And yes, she can and does format things properly.
Funny how you presume to know what she's like, having never met her.
Or is it that you interpreted "knows Word" as "has used and memorized every single feature Word has"? If that's the case, I don't know word, and I doubt anyone does.
probably even Emacs (the weird keyboard shortcuts wouldn't be an issue, because she doesn't use keyboard shortcuts).
Which means, if she's doing things visually, that she still would be better off with Emacs than with LaTeX.
a) reimplement functionality in Javascript
One possibility is to implement it in Javascript entirely, and run it on the server in SpiderMonkey. Just saying...
You spend hours to get a border right, pixel by pixel.
Or you leave it alone -- let it be slightly off. Or let a designer write your CSS.
Consider, also, the use of straight HTML in your AJAX responses, rather than something like JSON or XML. It's actually reasonably terse, and you can always re-style it, or parse it manually as a microformat.
But also, you might strongly consider:
b) only provide additional functionality with Javascript/AJAX
I'd much rather have a framework make it easy to expose functionality both ways. But you can always think of them as two separate platforms. Is it really so much harder to enable things both with Javascript and without, versus, say, porting a desktop app between Windows/Linux/OSX?
(Or, people don't have the right framework yet ;-) )
This is the most likely reason.
Sounds like I missed some implications, but it seems like you agree with this part:
...the cool, unique properties of a web app are pretty much entirely the user experience...
A Greasemonkey script probably is not essential, and is not part of your development process. But it makes things easier for the user, and adds value.
Although I see your point with back/forward -- if Web-style navigation is going to be required, then most desktop UI systems won't be as helpful.
Using the DB example, a desktop app, you would have communication from App -> DB that could be handled in a single method. In a GWT app, you have Web Client -> Web Server -> DB, handled with at the minimum a method on the client to invoke the call, a method on the server to handle the call, a message class, and a callback class to handle the results are the minimums in a GWT app for the same task.
That would suggest limitations in GWT, not in the model itself. If you're really going to open the database up directly, without access restrictions, you can always implement a simple HTTP->SQL proxy, and send SQL commands back directly from JavaScript.
If this sounds like a horrendous security issue for you, good! It's got you thinking. A similar desktop app has exactly the same security hazards -- it would need a proper server (and not just a proxy) to be secured.
Given that I haven't heard of it, I somehow doubt it's "difficult to replace" on the level of normal GUI frameworks.
Given that the entire page you linked to appears white for me on Konqueror, with some script errors, I somehow doubt they're doing unobtrusive Javascript, or gracefully degrading Javascript -- which disqualifies them from "doing it right".
Because you've put it in quotes, I suspect it's sarcasm, right?
Because I wasn't exaggerating. There actually is a filesystem, for Linux, deliberately written for flash: JFFS2. It actually will not work on a hard drive without an additional layer of emulation, and it wouldn't perform as well or be as reliable as on a real flash drive.
It's called a takedown notice. That should shield you from any liability -- if the creators care, they send you a notice, and you make the video go away. Problem solved.
Of course, the real reason is:
Gaming videos are by nature significantly larger and longer than any other genre on Vimeo ...
Really? Have they not seen Wormtooth Nation?
But there you go -- they're not really afraid of litigation. They're afraid of file size...
Of course Vista isn't optimized for SSDs, why should it have been? Is Windows XP optimized for SSDs?
Linux is.
Bigger question is, why isn't it possible to optimize Vista for SSDs? You speak as if Microsoft would have to redesign everything top to bottom in order to support them -- on my Linux, I'd have to use a different root filesystem, and that's about it.
On Linux, stuff which has just been loaded from disk by programs actually needing it right now is left around in RAM, until that RAM is needed for something else.
On Vista, if I am reading right, stuff which Vista thinks might be used someday is actually fetched into RAM, thus wearing out your disk and slowing down your computer while it does this, when most of the time, it's going to be wrong.
In fact, Linux has at least one filesystem designed for flash.
So why doesn't Microsoft? Obviously, it was more important for them to meet once a week to debate the structure of "shut down" in the start menu.
I'm not making either of these things up, but I can't verify them right now. No time.
Trotting out a machine that is litteraly obsolete* as a case study
While technically true, this is also about right for low-end machines these days.
512 megs of RAM is most likely the biggest bottleneck for Vista. Machines are still sold with 512 megs of RAM.
And it is possible to get underpowered, integrated Intel cards. While not as slow as a GeForce2, the same thing applies -- Vista would struggle, but Ubuntu will show you far more eye candy and actually seem happy.
And while it might not be a Pentium4, you can almost certainly get a single-core Celeron at about that speed.
All of these will be sold to you as a "Vista Capable" machine -- or maybe it's "Vista Ready" -- whichever means "It's possible to boot the OS, but not do anything else." (What kind of sick fucking joke is that? Yes, they're literally selling computers which are not designed to be useful for anything other than booting an OS -- and no one uses a computer just to boot an OS, except perhaps Vista engineers.)
Yet these are probably better than the specs on, say, an EEE PC. There are new markets opening up for less powerful computers, and Vista won't be in any of them.
It proves something else, too -- you're basically admitting that Vista requires much more hardware than any OS has a right to, while providing no additional value. That is, it will require a much better video card, to show you much worse eye candy than Ubuntu. OEMs like that in the short term, for forcing everyone to buy insanely more hardware than they need, but the more innovative ones won't let that stand.
Why wait to fix Vista for your flash drive, when you could just target Linux, which actually has at least one filesystem designed and optimized exclusively for flash?
Except that similar RAD tools exist for desktop environments, too -- Visual Basic being the most famous, but there are others. The only advantage of a web app here is that it's cross-platform -- but you would also get that with, say, Shoes.
No, the cool, unique properties of a web app are pretty much entirely the user experience -- the fact that there's nothing to download, and no updates to manage.
That said, I'd develop just about anything as either a web app or a commandline tool, mostly because these are what I personally have experience with. I develop real web apps for a living, for the reasons I list above -- so when I want to develop a personal app to, say, track my weight, which am I most likely to use?