Not significantly. Certainly not more so than any other language with multiple implementations.
You might be confusing Javascript with the DOM and various other APIs. I'll admit, that has sucked in the past, but modern browsers tend to at least support standard ways of accessing the DOM, and libraries like jQuery hide that away.
In fact, this "WebGL" is precisely the kind of standardization that's meant to ease that pain.
it's loose type system playing havoc with math meaning you have to explicitly declare types anyway if you want things to work without suffering obscure bugs
I honestly cannot remember the last time I had a bug related to this.
the fact many important features like namespaces are pretty much just a hack
A pretty elegant "hack" -- I'm going to chalk that up to you not understanding the language.
the fact there's no decent tools for building and debugging Javascript apps?
Firebug.
At least those languages are well known, solid, and can be implemented well.
Javascript isn't well known? And if you're claiming it can't be implemented well, citation needed.
Or are you referring to the bytecode interpreters commonly used with those languages?
Javascript has several good VMs now, so no, that's pretty irrelevant.
There's no reason we can't have things run in the browser directly but with a better language and set of libraries to go with that.
Except that brings us to forcing people to download a new browser, or browser plugin, to support those languages and libraries -- thus removing a major draw of browser-based apps.
There's some irony in your argument in that you suggest we don't want to take steps back, whilst defending an outdated language.
If I was defending C, or even COBOL, you might have a point.
Like say, Java then?
Java is easily twice as verbose as Javascript, probably a bit more. Java is not only strictly typed, but explicitly typed, down to what kinds of exceptions a method might raise.
I prefer to write my app, not ream after ream of declaration.
Now, if you're arguing that the Java VM should be used, I'd say there are probably better choices, but that's at least a possibility -- I don't know what the state of Jython is, but JRuby is pretty solid. But the language itself is an abomination. It's like someone took C++ and asked themselves, "How can we remove features to make this even more annoying?"
Oh, and just for fun, some things Javascript can do that Java can't:
That was a lot of fail packed into such a small package...
All of you stupid slashdot karma whores
I'm speaking my mind. I have plenty of karma to burn, if it was about that. I do get the occasional troll/flamebait mod.
need to look around and realize that the rest of the world doesn't give a shit.
The rest of the world by default doesn't give a shit about technical issues, at all. What part of that makes us wrong?
Did you read the summary? "while native audio/video support has been dropped"
Yeah, that's actually not true. Native audio/video support is still there. All that's been dropped from the spec is specific codecs -- in other words, browser vendors can support whatever codecs they want. So what?
which can also be read as: "your 'open standards' have been hijacked".
So, someone wants to use h.264 instead of Theora. Sucks, but I can live with that -- these are all well understood codecs that have open implementations, even if those implementations are of questionable legality until the patents expire.
But are you really telling me that you would rather have Flash suck down 99% CPU, opening up all kinds of security and privacy questions, and still sometimes lag playing fullscreen video on Linux? (And HD video in Flash is a joke on any OS.) Compare this to, say, Firefox "just working" at 1-10% CPU (saving a ton of battery life on my laptop), as just part of the page, with the ability to right-click and "save video as"?
"Open standards" are always going to be behind the times,
You're posting this on a website serving HTML over HTTP. Chances are, you use SMTP to communicate at least with your business contacts (assuming you have a job?), and all three of those will be using at least ASCII, if not Unicode, probably UTF-8.
You could probably find a few open standards which are behind the times. I could certainly find some proprietary ones which are. But the world runs on open standards. Take them away, and you wouldn't be able to read this comment.
I'm going to use the best tool for the job.
Flash is the worst possible tool for this job. It's just been the only tool for awhile.
If you're really going to use the "best tool for the job", then once IE implements HTML5, I suspect you will as well.
THATS WHAT THE OS IS FOR, which no one seems to understand or willing to fix.
I understand. What you may not understand is that "OS" is incredibly loosely defined, and in fact, we do have a case of the browser becoming an OS -- Chrome OS.
If the OS can't be made secure, the VM can't either
It's much easier to make a VM secure than an OS, for the simple reason that, as you say,
and adding more code is always less secure and has more bugs. ALWAYS.
I wouldn't agree with "always", because nothing is ever "always". But consider: The VM itself is less code than an OS. An individual layer, especially one as isolated as a VM, can be secured independently of other layers -- the complexity of code running inside the VM, or code the VM might run inside, doesn't change how difficult (or not) it is to secure the VM. And if the VM is secure, the code running inside the VM won't be able to break out of it.
We put browsers on top of OSes as if its a security fence. If the OS can't be made secure, the VM can't either
Not true.
As a trivial example, consider DOS. From DOS, we could run loadlin, and load an entire Linux OS. Would you then argue that this Linux can't be secure, since DOS wasn't secure?
Granted, if the OS provides additional security holes in code that the browser uses, that makes the browser less secure. Also, the OS could have holes that have nothing to do with the browser -- for example, a ping of death.
But if the browser is doing its job, barring deliberate malice on the part of the OS, the code running inside the browser won't be able to affect anything outside the browser, or any other tabs in the browser -- in general, anything it's not supposed to.
If you still disagree, can you come up with a reasonable example of how an insecure OS could make a secure browser running inside it allow a web app to escape?
Your browser can't do any the OS doesn't allow it to do.
All modern OSes allow browsers to be Turing-complete. So again, barring something deliberate on the part of the OS -- like, say, scribbling all over the browser's address space -- a browser can do anything it wants, within itself. The only thing the OS could prevent it from doing is fetch data from the outside properly, or render properly, and I don't know of any OS that currently screws this up.
Web apps are portable because we've started to demand that our browsers function with a common set of code and APIs, you can do the same for the OS you know?
No, I can't. I can't do anything; I'm one person.
The browser has pretty much evolved organically into an application platform. For something native to replace it, you'd have to get enough people to care about it as currently care about web standards -- and the web is used as more than just an application platform.
You may have heard of it, Posix.
Posix is not sufficient for modern applications. It can be used, certainly, but does it specify any sort of GUI, say?
I would rather not take the web direction and skip that entire bullshit layer and do it at the OS.
Browsers add a fair amount more than what we've been discussing, also. For example: The back/forward buttons, bookmarking, and other bits of navigation -- you get all this for free in a well designed web app. These are things you'd have to reinvent in a native app. Not that it's all bad -- native apps have (I'm told) much better GUI widget toolkits -- but it looks as though you're throwing the entire layer out as "bullshit" without making an effort to understand it.
In particular, focus on REST and semantic HTML.
The only advantage of what you're proposing is that you wouldn't have to use Javascript as an implementation language -- that you could use native code. For the vast majority of applicati
in all seriousness, the uses for 3D support in a browser is pretty limited I think.
Just for fun...
How about a free-to-play MMO? No download required, just go to this URL and you're in.
I think it will end up being misapplied everywhere.
I'd rather this be misapplied than Flash.
I find myself in agreement with the GP though that there is a general trend of moving traditional desktop applications to web apps in cases where it makes little sense.
Examples, please?
Developers are working hard to come up with ways to preserve functionality and use these applications even while disconnected from a network.
Seems to me, they've succeeded. Google Apps can be used offline.
I think the whole thing is an exercise in futility because there will always be people like me who demand snappy, native applications that are locally stored.
You're not the target market.
In particular, what you're demanding is stupid:
snappy, native applications that are locally stored.
If you didn't have that requirement, I'd agree with you. But since when do end-users care about whether an application is "native" or not? If I was doing desktop development, I'd probably still want to use Ruby, or something similar.
As an end-user, if you're sane, what matters to you is what the application does, and how well it does it, not implementation details like whether the UI is written in HTML, MFC, XUL, Qt, whatever. As long as it works, right?
One example: Do you use Firefox? The Firefox GUI is written in XML (XUL), rendered by Gecko, the same engine that renders HTML.
For security, privacy, responsiveness
These are good reasons.
So, in other words, you'd have no problems with a web app, so long as it was secure, private, and responsive -- which would probably mean it would have to run locally, and/or connect to a server you control.
Well, true, worse than that would be a browser vulnerability. But once we start talking about vulnerabilities, that's no worse than any other system, and in fact, a good deal better.
Put another way, suppose I download a program and let it run locally. How should I protect the rest of my system from it? I could run it as an unprivileged user, but it could always find a local root exploit, or it could potentially read files it isn't supposed to read (modern Linux tends to create files with mode 644, thus world-readabale), or it could fill up my hard drive, or...
So, I'd have to put it in its own private virtual machine in order to be completely safe. At that point, I wonder if the browser might be faster after all -- and certainly, there could be a vulnerability in the VM just as easily as in the browser.
The point I'm making is, the browser is the best we've got.
HOWEVER, if I put mail. or smtp. in front of that address, the resolution immediately fails
That's a pretty huge assumption. There are commonly other things you might use, like mx.example.com, or something completely different:
> host slaphack.com slaphack.com has address 69.18.26.255 slaphack.com mail is handled by 10 grunt.slaphack.com. slaphack.com mail is handled by 20 kernel.forkbox.net.
For what it's worth, both of those boxes are also webservers. And while my setup is unusual, it's not hard to imagine even a large company having something similar.
To assume a particular function or protocol based on nothing but a particular box's hostname is dangerous, even if it's a human making that assumption. For a machine to try is just stupid.
So yes, this is still pretty much a "breaks the Internet" kind of stupid.
Web devs may find it worth it to leave IE out of their support efforts to get out of having to use proprietary technologies with more cumbersome licensing circumstances.
Unfortunately, this isn't likely to happen.
A small website is likely to want all the traffic they can get, so they'll have to support IE in some form. The best they could do is progressive degradation -- a <video> tag that gets replaced with a Flash object if the browser doesn't support html5. But a small website isn't likely to have resources to burn creating and supporting an entirely separate player. I know, I was part of one -- html5 was always something I wanted to do, but we ended up going with Flash because social networking sites (Facebook, Myspace, etc) would just accept a Flash object -- we even had the entire player (all the controls, etc) done in HTML/AJAX with just a flash player component, and then it was swapped out for a pure Flash widget.
A large website might be able to take this risk -- after all, some fairly large websites have embraced Silverlight, which requires at least a download for most users. I don't see forcing a browser upgrade as any more intrusive than forcing users to install a plugin. Unfortunately, the kind of corporations behind such websites are typically much more risk-averse. They can afford the Flash licensing fees, and it'll Just Work, already has a thousand times before, so why would they try something new?
My only real hope for something like this would be somebody both huge and innovative -- say, Google -- doing this with something that people won't be willing to miss -- say, YouTube. It's possible that if YouTube required an HTML5-compliant browser, that browser marketshare would shift massively in favor of Firefox, Chrome, etc. It's also possible that this would drive people to Google's competitors (Vimeo, Viddler, etc), or drive people away from online video entirely -- I don't think that outcome is likely, but Google is getting too big to take that risk. And keep in mind, Google tends to play nice with others, to the point of re-encoding all their videos to h.264 just so they'd be easier to play on the iPhone, so I doubt they'd be as ready to flip the bird to Microsoft as I'd like them to be.
widely regarded as a poor idea to use in the age of style sheets. The philosophy widely espoused with regard to modern web development is to separate content from presentation (much like much GUI application design philosophies).
Well, you forgot to escape your tags, so I can't actually see which ones you're talking about. But as an example, I still use things like <ul>, <blockquote>, and <dl>... I could go on. And while <b> might be bad form, <em> still makes sense.
Yes, we want to separate content from presentation, but the content itself should still be meaningful, and so should the tags surrounding it.
If I want an unordered list of stuff, I use <ul>. I may use CSS to replace the bullets with images, even remove the bullets altogether and re-style the list items as paragraphs, but if it's truly an unsorted list, the <ul> tag makes sense. Using these makes life easier for lynx users, screenreaders, scrapers/robots, and basically anyone who isn't viewing your content together with your stylesheet -- indeed, taken to an extreme, HTML could actually be used as a decent API (rather than JSON or XML).
It is worth noticing that MS seems to be the last to support a given standard, even once it's recognized as a standard -- they'd rather come out with their own competing "standard".
Case in point: OOXML. ODF works well, and could conceivably be extended to match the capabilities of MS Office. Instead, Microsoft launched a competing, far worse standard -- one nearly impossible for a competitor to implement completely -- and rammed it through Ecma and ISO so that it would be called a "standard", even if it currently has zero compliant implementations (MS Office manages to screw up its own "standard").
Now, I'm not "happy as a pig in shit" when others do similar things. I'm no fan of Apple, for example -- in particular, the iPhone's restrictions disgust me. On the other hand, I do hold Microsoft to a higher standard, as they still have over 80% of the browser marketshare -- meaning if Mozilla implements a standard, and Microsoft doessn't, that standard is pretty much useless to me unless I'm willing to tell 80% of my users to go home.
What I don't get is why a small competitor couldn't use your device to eat their lunch? Yes, it'd be less profit, but it'd be more profit for you than zero, and more money saved for the end-user. Eventually, if users liked the concept, the existing companies would be forced to adapt.
I mean, no existing company wants to build a better, cheaper mousetrap. The point is, the free market is supposed to reward a company that does, and punish (through competition) those who don't adapt.
It actually seems pretty obvious -- a community which was altruistic would, in the long run, have a higher chance of survival than a community which wasn't.
Another example: Superstition. I love this bit:
Religion offers another possible evolutionary benefit of superstition.
So... how is religion not superstition? Now you've got two mysteries, instead of one. And the same explanation still holds:
Our ancestors would not have lasted long if they had assumed that a rustle in the grass was caused by wind when there was even a small chance it was a lion. And it is worth making false-positive mistakes to get these relationships right.
Basically, religion and other superstitions are maladaptions of our ability to recognize patterns -- and an acceptable alternative to missing some pattern. Better to be paranoid than to be gullible -- better to be afraid of the tiger that isn't there than to be eaten by the tiger who is.
I suppose these aren't proven, but I do find this pretty weak, even for a "top 10" list. It's not "mysteries" so much as "cases which are not yet airtight".
Why is this a bad thing? Or what would you suggest as a better language?
Most people who hate Javascript don't really understand it. I qualify that as "most" because a few people do know enough about it to actually have good reasons for hating it.
won't have a standard GUI framework to use
HTML is more standard than about any other GUI framework, even if less featured.
In fact, something to notice -- most people seem determined to style away the standard GUI elements. Below this message, you'll almost certainly see a "Reply to This" button and a "Parent" button, and unless you've disabled your CSS, they probably look nothing like your standard native buttons.
The issue is that most web designers hate these things, and think they're "ugly". Whether actual users care is up for debate -- they don't seem to have a problem with Google's homepage, for example.
we'll have to code our own from scratch every time as if it's MS-DOS all over again
You mean the MS-DOS, where the network was nearly nonexistent, and applications would largely be written in C or assembly?
I understand your sentiment that the browser feels like a step back, but hyperbole doesn't help your argument.
This way, people will have a pointless, non-native middle-man between their operating systems and their apps!
Better this than Java or C#.
What's more, it's hardly pointless. Or would you rather go back to the days when if you wanted something cool, like the ability to check the weather, receive email, or watch TV, you'd have to download an untrusted (possibly virus/spyware infested) binary.exe, run it on Windows, and hope it doesn't have some weird incompatibility with everything else on your system?
I much prefer the ability to try out pretty much anything I want, in my browser, without having to download/install anything, or uninstall it later. Worst case, I reload the page, or close the tab. Absolute worst case, I have to kill the browser, but no permanent harm.
Oh, and they're portable. I can play with the same apps on Windows, Linux, OS X, an iPhone...
You could argue that the browser isn't the best possible way we could've accomplished that, but those are real advantages it has over the vast majority of desktop apps, especially "fast" ones.
I've wanted nothing more than to program 3D in friggin' JavaScript.
Better than programming 3D in friggin' Flash.
If people are going to insist on taking the Web in this direction, wouldn't you rather it be based on cross-platform open standards?
The page you get from Comcast (or whoever) is the same as getting the busy signal/number not found.
A busy signal doesn't try to sell you ads, so it makes sense. Also, we already have something that is the same as a busy signal -- it's called NXDOMAIN.
They're also irrelevant for mail delivery, as last time I checked, mail wasn't sent via HTTP.
Which is one of the main points here -- if it's HTTP, especially if it's HTML over HTTP to a web browser, then getting Comcast's page probably wouldn't bother you any more than getting Firefox's "not found" page. It might use slightly more bandwidth, but it wouldn't really be an issue.
The problem comes when you start doing things like mail delivery, or any number of other applications, which expect nonexistent domains to be, well, nonexistent. Many of them will never fire an HTTP request, and so could not even theoretically figure out WTF is going on -- they get a "connection refused", at best, and maybe they have to wait for a timeout, instead of an immediate domain-not-found error.
It's especially harmful for various applications which depend on actual domain-not-found results, such as various VPN setups. This is more or less exactly like the analogy given -- the payphone giving you your dime back depends on getting an actual, real busy signal and/or "not in service" result. Anything else, and it assumes you were successful, and does the wrong thing -- in this case, it eats your dime.
A cryptographic system, properly done, would be able to deal with lost radios.
I realize this wouldn't be directly applicable, but I've run OpenVPN networks before. Each remote machine (laptop, etc), and each server, has its own keypair. Servers, at the very least, can run CRLs -- so if a laptop is stolen, I can revoke its key and deny access right there, without affecting other users.
Radio would suggest a different mechanism, but ultimately, disabling a single missing radio doesn't sound like a particularly difficult task.
When it started to get disgusting is when people started using it to describe just about any sort of cheat in an online game, other than exploiting a bug -- for instance, "wallhacking".
Like Web 2.0, it has at least one or two specific meanings. The problem is getting specific -- a little knowledge is a dangerous thing, and managers can be very fuzzy (clouded?) about "cloud computing" if they don't understand the difference between calling Gmail a "cloud app" and calling Amazon Web Services a "compute cloud".
Generating SSH keys involves interaction via at least keyboard and possibly mouse at a terminal.
If you use PuTTY, yes. OpenSSH, at least, doesn't require anything in particular, just a sufficient amount of entropy. On a properly configured system, moving a mouse or banging randomly on the keyboard might feed entropy -- but then, so would plugging a microphone into the sound card, or any number of other things.
And as Kaseijin mentions, this is about host keys. Especially in a virtualized environment, you can't assume any sort of human interaction when these keys are generated.
Those are other claims. If you want to talk about them, we can, but it's getting a bit offtopic.
It seamlessly syncs with my calendar, address book, etc.
Is that not true on Android?
Browsing the web works quickly and pages render pretty well.
Are you really going to tell me that's unique? Both Android and iPhone use Webkit-based browsers.
Even in the event that my iPhone gets hacked by a vulnerability apple fails to fix, I won't regret my decision.
That sounds very much like a fanboi or astroturf position. You won't regret it? Not even for a moment?
Tell me... just how much would Apple have to screw up for you to regret it?
There's no worthwhile information on it to steal, and it gets backed up every time I plug it in (every day).
That tells me you're either naive or a naive asshole.
Suppose someone cracks your phone and uses it to send thousands of spams via your 3G connection, or thousands of spammy text messages. The former will run up a huge bill and piss off network admins, and the latter will run up a huge bill and alienate all your friends.
Or suppose they only use it as a carrier -- any wifi network you connect to, you'll infect all nearby PCs. Chances are, you'd never be caught, but it still doesn't really make you a good citizen.
Or suppose it gets infected with something that then exploits something on your PC (or Mac, to be fair), and then, later, nukes _all_ your data? Do you have the backup backed up? Even if you do, is that really something you want to risk?
The absolute dumbest statement anyone can make about security is "I'm not a target," or "I have nothing to lose."
Now, I'm not suggesting you should immediately throw out your iPhone, or that it was necessarily a bad choice. But your arguments here sound more like rationalizations -- it sounds more like you are starting to regret it, and you're trying to justify it to yourself, to reassure yourself that you made the right decision.
I really wish that some posters here would resist the urge to be rude and grandstand in order to bully their point.
I was having a bad day... I really do need to learn to not post on bad days.
an open platform introduces risk
This is where we disagree.
Given that a closed platform will simply be jailbroken, an open platform introduces nothing more than legitimate apps delivered through other channels.
So, the real question here is whether other legitimate channels necessarily introduce risk.
I argue that they don't, or at least, that it is an acceptable risk, as a consumer can always choose to stay with the safer channels.
Windows is an open platform, and look at the disaster we have there.
It is actually quite easy to run a secure Windows system. The problem is, it requires a moderately educated, motivated, and disciplined user. I don't think it's too much to ask -- people have more discipline with cars than with computers.
I looked at the G1 (Android) before getting an iPhone. I was very reluctant to give all of my personal data to Google. Given the disastrous breach at Network Solutions recently, I don't think it is unwise to be reluctant to want to keep one's data on one's own system.
Maybe there's something I'm missing, but how is the Android going to give more of your data to Google than the iPhone gives to Apple?
supports the secure installation of insecure apps.
That's a good point, and one I wish a modern OS would address, beyond the web browser.
However, even here, I would want an OS to allow the insecure installation of apps it cannot verify. It can complain loudly -- think Firefox 3 when it sees a bad/untrusted SSL cert -- but it should be possible to override (again, think Firefox 3).
And again, even if Apple has a point, it only applies if the review process is better than completely random. Right now, it's not.
Slashdot Mirror
We've seen a lot more exploitable bugs in browser sandboxes than OS ones, because they are much more complicated to implement.
I suspect also because they see a lot more use than OS ones.
And that's ignoring the issue of making it cross-platform and easily used.
implemented differently across browsers
Not significantly. Certainly not more so than any other language with multiple implementations.
You might be confusing Javascript with the DOM and various other APIs. I'll admit, that has sucked in the past, but modern browsers tend to at least support standard ways of accessing the DOM, and libraries like jQuery hide that away.
In fact, this "WebGL" is precisely the kind of standardization that's meant to ease that pain.
it's loose type system playing havoc with math meaning you have to explicitly declare types anyway if you want things to work without suffering obscure bugs
I honestly cannot remember the last time I had a bug related to this.
the fact many important features like namespaces are pretty much just a hack
A pretty elegant "hack" -- I'm going to chalk that up to you not understanding the language.
the fact there's no decent tools for building and debugging Javascript apps?
Firebug.
At least those languages are well known, solid, and can be implemented well.
Javascript isn't well known? And if you're claiming it can't be implemented well, citation needed.
Or are you referring to the bytecode interpreters commonly used with those languages?
Javascript has several good VMs now, so no, that's pretty irrelevant.
There's no reason we can't have things run in the browser directly but with a better language and set of libraries to go with that.
Except that brings us to forcing people to download a new browser, or browser plugin, to support those languages and libraries -- thus removing a major draw of browser-based apps.
There's some irony in your argument in that you suggest we don't want to take steps back, whilst defending an outdated language.
If I was defending C, or even COBOL, you might have a point.
Like say, Java then?
Java is easily twice as verbose as Javascript, probably a bit more. Java is not only strictly typed, but explicitly typed, down to what kinds of exceptions a method might raise.
I prefer to write my app, not ream after ream of declaration.
Now, if you're arguing that the Java VM should be used, I'd say there are probably better choices, but that's at least a possibility -- I don't know what the state of Jython is, but JRuby is pretty solid. But the language itself is an abomination. It's like someone took C++ and asked themselves, "How can we remove features to make this even more annoying?"
Oh, and just for fun, some things Javascript can do that Java can't:
you're giving Javascript far more credit than it's due, it really is a crap language,
Here, go read.
I'll agree it could be improved. But I don't agree that it's a "crap" language, especially when compared to Java.
That was a lot of fail packed into such a small package...
All of you stupid slashdot karma whores
I'm speaking my mind. I have plenty of karma to burn, if it was about that. I do get the occasional troll/flamebait mod.
need to look around and realize that the rest of the world doesn't give a shit.
The rest of the world by default doesn't give a shit about technical issues, at all. What part of that makes us wrong?
Did you read the summary? "while native audio/video support has been dropped"
Yeah, that's actually not true. Native audio/video support is still there. All that's been dropped from the spec is specific codecs -- in other words, browser vendors can support whatever codecs they want. So what?
which can also be read as: "your 'open standards' have been hijacked".
So, someone wants to use h.264 instead of Theora. Sucks, but I can live with that -- these are all well understood codecs that have open implementations, even if those implementations are of questionable legality until the patents expire.
But are you really telling me that you would rather have Flash suck down 99% CPU, opening up all kinds of security and privacy questions, and still sometimes lag playing fullscreen video on Linux? (And HD video in Flash is a joke on any OS.) Compare this to, say, Firefox "just working" at 1-10% CPU (saving a ton of battery life on my laptop), as just part of the page, with the ability to right-click and "save video as"?
"Open standards" are always going to be behind the times,
You're posting this on a website serving HTML over HTTP. Chances are, you use SMTP to communicate at least with your business contacts (assuming you have a job?), and all three of those will be using at least ASCII, if not Unicode, probably UTF-8.
You could probably find a few open standards which are behind the times. I could certainly find some proprietary ones which are. But the world runs on open standards. Take them away, and you wouldn't be able to read this comment.
I'm going to use the best tool for the job.
Flash is the worst possible tool for this job. It's just been the only tool for awhile.
If you're really going to use the "best tool for the job", then once IE implements HTML5, I suspect you will as well.
THATS WHAT THE OS IS FOR, which no one seems to understand or willing to fix.
I understand. What you may not understand is that "OS" is incredibly loosely defined, and in fact, we do have a case of the browser becoming an OS -- Chrome OS.
If the OS can't be made secure, the VM can't either
It's much easier to make a VM secure than an OS, for the simple reason that, as you say,
and adding more code is always less secure and has more bugs. ALWAYS.
I wouldn't agree with "always", because nothing is ever "always". But consider: The VM itself is less code than an OS. An individual layer, especially one as isolated as a VM, can be secured independently of other layers -- the complexity of code running inside the VM, or code the VM might run inside, doesn't change how difficult (or not) it is to secure the VM. And if the VM is secure, the code running inside the VM won't be able to break out of it.
We put browsers on top of OSes as if its a security fence. If the OS can't be made secure, the VM can't either
Not true.
As a trivial example, consider DOS. From DOS, we could run loadlin, and load an entire Linux OS. Would you then argue that this Linux can't be secure, since DOS wasn't secure?
Granted, if the OS provides additional security holes in code that the browser uses, that makes the browser less secure. Also, the OS could have holes that have nothing to do with the browser -- for example, a ping of death.
But if the browser is doing its job, barring deliberate malice on the part of the OS, the code running inside the browser won't be able to affect anything outside the browser, or any other tabs in the browser -- in general, anything it's not supposed to.
If you still disagree, can you come up with a reasonable example of how an insecure OS could make a secure browser running inside it allow a web app to escape?
Your browser can't do any the OS doesn't allow it to do.
All modern OSes allow browsers to be Turing-complete. So again, barring something deliberate on the part of the OS -- like, say, scribbling all over the browser's address space -- a browser can do anything it wants, within itself. The only thing the OS could prevent it from doing is fetch data from the outside properly, or render properly, and I don't know of any OS that currently screws this up.
Web apps are portable because we've started to demand that our browsers function with a common set of code and APIs, you can do the same for the OS you know?
No, I can't. I can't do anything; I'm one person.
The browser has pretty much evolved organically into an application platform. For something native to replace it, you'd have to get enough people to care about it as currently care about web standards -- and the web is used as more than just an application platform.
You may have heard of it, Posix.
Posix is not sufficient for modern applications. It can be used, certainly, but does it specify any sort of GUI, say?
I would rather not take the web direction and skip that entire bullshit layer and do it at the OS.
Browsers add a fair amount more than what we've been discussing, also. For example: The back/forward buttons, bookmarking, and other bits of navigation -- you get all this for free in a well designed web app. These are things you'd have to reinvent in a native app. Not that it's all bad -- native apps have (I'm told) much better GUI widget toolkits -- but it looks as though you're throwing the entire layer out as "bullshit" without making an effort to understand it.
In particular, focus on REST and semantic HTML.
The only advantage of what you're proposing is that you wouldn't have to use Javascript as an implementation language -- that you could use native code. For the vast majority of applicati
in all seriousness, the uses for 3D support in a browser is pretty limited I think.
Just for fun...
How about a free-to-play MMO? No download required, just go to this URL and you're in.
I think it will end up being misapplied everywhere.
I'd rather this be misapplied than Flash.
I find myself in agreement with the GP though that there is a general trend of moving traditional desktop applications to web apps in cases where it makes little sense.
Examples, please?
Developers are working hard to come up with ways to preserve functionality and use these applications even while disconnected from a network.
Seems to me, they've succeeded. Google Apps can be used offline.
I think the whole thing is an exercise in futility because there will always be people like me who demand snappy, native applications that are locally stored.
You're not the target market.
In particular, what you're demanding is stupid:
snappy, native applications that are locally stored.
If you didn't have that requirement, I'd agree with you. But since when do end-users care about whether an application is "native" or not? If I was doing desktop development, I'd probably still want to use Ruby, or something similar.
As an end-user, if you're sane, what matters to you is what the application does, and how well it does it, not implementation details like whether the UI is written in HTML, MFC, XUL, Qt, whatever. As long as it works, right?
One example: Do you use Firefox? The Firefox GUI is written in XML (XUL), rendered by Gecko, the same engine that renders HTML.
For security, privacy, responsiveness
These are good reasons.
So, in other words, you'd have no problems with a web app, so long as it was secure, private, and responsive -- which would probably mean it would have to run locally, and/or connect to a server you control.
I hope that was sarcasm...
If not, care to tell me the ways in which Visual Basic is better than Javascript?
Well, true, worse than that would be a browser vulnerability. But once we start talking about vulnerabilities, that's no worse than any other system, and in fact, a good deal better.
Put another way, suppose I download a program and let it run locally. How should I protect the rest of my system from it? I could run it as an unprivileged user, but it could always find a local root exploit, or it could potentially read files it isn't supposed to read (modern Linux tends to create files with mode 644, thus world-readabale), or it could fill up my hard drive, or...
So, I'd have to put it in its own private virtual machine in order to be completely safe. At that point, I wonder if the browser might be faster after all -- and certainly, there could be a vulnerability in the VM just as easily as in the browser.
The point I'm making is, the browser is the best we've got.
HOWEVER, if I put mail. or smtp. in front of that address, the resolution immediately fails
That's a pretty huge assumption. There are commonly other things you might use, like mx.example.com, or something completely different:
For what it's worth, both of those boxes are also webservers. And while my setup is unusual, it's not hard to imagine even a large company having something similar.
To assume a particular function or protocol based on nothing but a particular box's hostname is dangerous, even if it's a human making that assumption. For a machine to try is just stupid.
So yes, this is still pretty much a "breaks the Internet" kind of stupid.
Web devs may find it worth it to leave IE out of their support efforts to get out of having to use proprietary technologies with more cumbersome licensing circumstances.
Unfortunately, this isn't likely to happen.
A small website is likely to want all the traffic they can get, so they'll have to support IE in some form. The best they could do is progressive degradation -- a <video> tag that gets replaced with a Flash object if the browser doesn't support html5. But a small website isn't likely to have resources to burn creating and supporting an entirely separate player. I know, I was part of one -- html5 was always something I wanted to do, but we ended up going with Flash because social networking sites (Facebook, Myspace, etc) would just accept a Flash object -- we even had the entire player (all the controls, etc) done in HTML/AJAX with just a flash player component, and then it was swapped out for a pure Flash widget.
A large website might be able to take this risk -- after all, some fairly large websites have embraced Silverlight, which requires at least a download for most users. I don't see forcing a browser upgrade as any more intrusive than forcing users to install a plugin. Unfortunately, the kind of corporations behind such websites are typically much more risk-averse. They can afford the Flash licensing fees, and it'll Just Work, already has a thousand times before, so why would they try something new?
My only real hope for something like this would be somebody both huge and innovative -- say, Google -- doing this with something that people won't be willing to miss -- say, YouTube. It's possible that if YouTube required an HTML5-compliant browser, that browser marketshare would shift massively in favor of Firefox, Chrome, etc. It's also possible that this would drive people to Google's competitors (Vimeo, Viddler, etc), or drive people away from online video entirely -- I don't think that outcome is likely, but Google is getting too big to take that risk. And keep in mind, Google tends to play nice with others, to the point of re-encoding all their videos to h.264 just so they'd be easier to play on the iPhone, so I doubt they'd be as ready to flip the bird to Microsoft as I'd like them to be.
widely regarded as a poor idea to use in the age of style sheets. The philosophy widely espoused with regard to modern web development is to separate content from presentation (much like much GUI application design philosophies).
Well, you forgot to escape your tags, so I can't actually see which ones you're talking about. But as an example, I still use things like <ul>, <blockquote>, and <dl>... I could go on. And while <b> might be bad form, <em> still makes sense.
Yes, we want to separate content from presentation, but the content itself should still be meaningful, and so should the tags surrounding it.
If I want an unordered list of stuff, I use <ul>. I may use CSS to replace the bullets with images, even remove the bullets altogether and re-style the list items as paragraphs, but if it's truly an unsorted list, the <ul> tag makes sense. Using these makes life easier for lynx users, screenreaders, scrapers/robots, and basically anyone who isn't viewing your content together with your stylesheet -- indeed, taken to an extreme, HTML could actually be used as a decent API (rather than JSON or XML).
It is worth noticing that MS seems to be the last to support a given standard, even once it's recognized as a standard -- they'd rather come out with their own competing "standard".
Case in point: OOXML. ODF works well, and could conceivably be extended to match the capabilities of MS Office. Instead, Microsoft launched a competing, far worse standard -- one nearly impossible for a competitor to implement completely -- and rammed it through Ecma and ISO so that it would be called a "standard", even if it currently has zero compliant implementations (MS Office manages to screw up its own "standard").
Now, I'm not "happy as a pig in shit" when others do similar things. I'm no fan of Apple, for example -- in particular, the iPhone's restrictions disgust me. On the other hand, I do hold Microsoft to a higher standard, as they still have over 80% of the browser marketshare -- meaning if Mozilla implements a standard, and Microsoft doessn't, that standard is pretty much useless to me unless I'm willing to tell 80% of my users to go home.
What I don't get is why a small competitor couldn't use your device to eat their lunch? Yes, it'd be less profit, but it'd be more profit for you than zero, and more money saved for the end-user. Eventually, if users liked the concept, the existing companies would be forced to adapt.
I mean, no existing company wants to build a better, cheaper mousetrap. The point is, the free market is supposed to reward a company that does, and punish (through competition) those who don't adapt.
Example: Altruism.
It actually seems pretty obvious -- a community which was altruistic would, in the long run, have a higher chance of survival than a community which wasn't.
Another example: Superstition. I love this bit:
Religion offers another possible evolutionary benefit of superstition.
So... how is religion not superstition? Now you've got two mysteries, instead of one. And the same explanation still holds:
Our ancestors would not have lasted long if they had assumed that a rustle in the grass was caused by wind when there was even a small chance it was a lion. And it is worth making false-positive mistakes to get these relationships right.
Basically, religion and other superstitions are maladaptions of our ability to recognize patterns -- and an acceptable alternative to missing some pattern. Better to be paranoid than to be gullible -- better to be afraid of the tiger that isn't there than to be eaten by the tiger who is.
I suppose these aren't proven, but I do find this pretty weak, even for a "top 10" list. It's not "mysteries" so much as "cases which are not yet airtight".
will require programming in JavaScript
Why is this a bad thing? Or what would you suggest as a better language?
Most people who hate Javascript don't really understand it. I qualify that as "most" because a few people do know enough about it to actually have good reasons for hating it.
won't have a standard GUI framework to use
HTML is more standard than about any other GUI framework, even if less featured.
In fact, something to notice -- most people seem determined to style away the standard GUI elements. Below this message, you'll almost certainly see a "Reply to This" button and a "Parent" button, and unless you've disabled your CSS, they probably look nothing like your standard native buttons.
The issue is that most web designers hate these things, and think they're "ugly". Whether actual users care is up for debate -- they don't seem to have a problem with Google's homepage, for example.
we'll have to code our own from scratch every time as if it's MS-DOS all over again
You mean the MS-DOS, where the network was nearly nonexistent, and applications would largely be written in C or assembly?
I understand your sentiment that the browser feels like a step back, but hyperbole doesn't help your argument.
This way, people will have a pointless, non-native middle-man between their operating systems and their apps!
Better this than Java or C#.
What's more, it's hardly pointless. Or would you rather go back to the days when if you wanted something cool, like the ability to check the weather, receive email, or watch TV, you'd have to download an untrusted (possibly virus/spyware infested) binary .exe, run it on Windows, and hope it doesn't have some weird incompatibility with everything else on your system?
I much prefer the ability to try out pretty much anything I want, in my browser, without having to download/install anything, or uninstall it later. Worst case, I reload the page, or close the tab. Absolute worst case, I have to kill the browser, but no permanent harm.
Oh, and they're portable. I can play with the same apps on Windows, Linux, OS X, an iPhone...
You could argue that the browser isn't the best possible way we could've accomplished that, but those are real advantages it has over the vast majority of desktop apps, especially "fast" ones.
I've wanted nothing more than to program 3D in friggin' JavaScript.
Better than programming 3D in friggin' Flash.
If people are going to insist on taking the Web in this direction, wouldn't you rather it be based on cross-platform open standards?
The page you get from Comcast (or whoever) is the same as getting the busy signal/number not found.
A busy signal doesn't try to sell you ads, so it makes sense. Also, we already have something that is the same as a busy signal -- it's called NXDOMAIN.
They're also irrelevant for mail delivery, as last time I checked, mail wasn't sent via HTTP.
Which is one of the main points here -- if it's HTTP, especially if it's HTML over HTTP to a web browser, then getting Comcast's page probably wouldn't bother you any more than getting Firefox's "not found" page. It might use slightly more bandwidth, but it wouldn't really be an issue.
The problem comes when you start doing things like mail delivery, or any number of other applications, which expect nonexistent domains to be, well, nonexistent. Many of them will never fire an HTTP request, and so could not even theoretically figure out WTF is going on -- they get a "connection refused", at best, and maybe they have to wait for a timeout, instead of an immediate domain-not-found error.
It's especially harmful for various applications which depend on actual domain-not-found results, such as various VPN setups. This is more or less exactly like the analogy given -- the payphone giving you your dime back depends on getting an actual, real busy signal and/or "not in service" result. Anything else, and it assumes you were successful, and does the wrong thing -- in this case, it eats your dime.
Hmm... mind telling me the name of your ISP, so I can make a point to avoid them?
Perhaps more importantly, why are you still their customer?
A cryptographic system, properly done, would be able to deal with lost radios.
I realize this wouldn't be directly applicable, but I've run OpenVPN networks before. Each remote machine (laptop, etc), and each server, has its own keypair. Servers, at the very least, can run CRLs -- so if a laptop is stolen, I can revoke its key and deny access right there, without affecting other users.
Radio would suggest a different mechanism, but ultimately, disabling a single missing radio doesn't sound like a particularly difficult task.
When it started to get disgusting is when people started using it to describe just about any sort of cheat in an online game, other than exploiting a bug -- for instance, "wallhacking".
Like Web 2.0, it has at least one or two specific meanings. The problem is getting specific -- a little knowledge is a dangerous thing, and managers can be very fuzzy (clouded?) about "cloud computing" if they don't understand the difference between calling Gmail a "cloud app" and calling Amazon Web Services a "compute cloud".
Generating SSH keys involves interaction via at least keyboard and possibly mouse at a terminal.
If you use PuTTY, yes. OpenSSH, at least, doesn't require anything in particular, just a sufficient amount of entropy. On a properly configured system, moving a mouse or banging randomly on the keyboard might feed entropy -- but then, so would plugging a microphone into the sound card, or any number of other things.
And as Kaseijin mentions, this is about host keys. Especially in a virtualized environment, you can't assume any sort of human interaction when these keys are generated.
Tabbed browsing wasn't a reason?
Isn't that the country that just recently created anti-blasphemy laws?
And this is precisely why GPLv3 stuff probably won't make it on the iPhone, unless Apple backs down.
Those are other claims. If you want to talk about them, we can, but it's getting a bit offtopic.
It seamlessly syncs with my calendar, address book, etc.
Is that not true on Android?
Browsing the web works quickly and pages render pretty well.
Are you really going to tell me that's unique? Both Android and iPhone use Webkit-based browsers.
Even in the event that my iPhone gets hacked by a vulnerability apple fails to fix, I won't regret my decision.
That sounds very much like a fanboi or astroturf position. You won't regret it? Not even for a moment?
Tell me... just how much would Apple have to screw up for you to regret it?
There's no worthwhile information on it to steal, and it gets backed up every time I plug it in (every day).
That tells me you're either naive or a naive asshole.
Suppose someone cracks your phone and uses it to send thousands of spams via your 3G connection, or thousands of spammy text messages. The former will run up a huge bill and piss off network admins, and the latter will run up a huge bill and alienate all your friends.
Or suppose they only use it as a carrier -- any wifi network you connect to, you'll infect all nearby PCs. Chances are, you'd never be caught, but it still doesn't really make you a good citizen.
Or suppose it gets infected with something that then exploits something on your PC (or Mac, to be fair), and then, later, nukes _all_ your data? Do you have the backup backed up? Even if you do, is that really something you want to risk?
The absolute dumbest statement anyone can make about security is "I'm not a target," or "I have nothing to lose."
Now, I'm not suggesting you should immediately throw out your iPhone, or that it was necessarily a bad choice. But your arguments here sound more like rationalizations -- it sounds more like you are starting to regret it, and you're trying to justify it to yourself, to reassure yourself that you made the right decision.
In other words, Android, the open platform, patched before iPhone, the closed platform.
Yet I still occasionally run into people trying to claim that the iPhone being closed is somehow good, as it's more secure.
I really wish that some posters here would resist the urge to be rude and grandstand in order to bully their point.
I was having a bad day... I really do need to learn to not post on bad days.
an open platform introduces risk
This is where we disagree.
Given that a closed platform will simply be jailbroken, an open platform introduces nothing more than legitimate apps delivered through other channels.
So, the real question here is whether other legitimate channels necessarily introduce risk.
I argue that they don't, or at least, that it is an acceptable risk, as a consumer can always choose to stay with the safer channels.
Windows is an open platform, and look at the disaster we have there.
It is actually quite easy to run a secure Windows system. The problem is, it requires a moderately educated, motivated, and disciplined user. I don't think it's too much to ask -- people have more discipline with cars than with computers.
I looked at the G1 (Android) before getting an iPhone. I was very reluctant to give all of my personal data to Google. Given the disastrous breach at Network Solutions recently, I don't think it is unwise to be reluctant to want to keep one's data on one's own system.
Maybe there's something I'm missing, but how is the Android going to give more of your data to Google than the iPhone gives to Apple?
supports the secure installation of insecure apps.
That's a good point, and one I wish a modern OS would address, beyond the web browser.
However, even here, I would want an OS to allow the insecure installation of apps it cannot verify. It can complain loudly -- think Firefox 3 when it sees a bad/untrusted SSL cert -- but it should be possible to override (again, think Firefox 3).
And again, even if Apple has a point, it only applies if the review process is better than completely random. Right now, it's not.