Most are, but they can also get to the Chrome extension API, I think. That, and it means Google can sell them the way they can sell other "apps", which means that whether it's "just a website" or not, I can actually sell it to you as if it was a thing.
And the big thing about Java was that you would be able to write code that was platform-independent, and just rely on a Java interpreter that would be released on any necessary platforms. Which is why everything is written in Java now...
I don't think that's the biggest reason. I think the biggest reason is that it was reasonably similar to other 800-lb gorillas, like C++, but included things like garbage collection.
I'm just saying, using a browser as a conveyance for some sort of universal HTML-based software market just seems like a new version of an old idea that didn't pan out in the first place.
Maybe so, but here are some things that help:
First, there are multiple implementations with significant marketshare. If your app didn't run on things like kaffe or gcj, no big loss -- if one of Oracle's flagship JDeveloper-based frameworks doesn't work on OpenJDK today, they don't care -- hell, one of the bigger reasons Java failed is Microsoft delivered a broken JVM, and if you only care about supporting Windows, you code to Microsoft's broken JVM and you don't need to run anywhere else. Even ignoring that, I've taken recent code written for Java6 and had it fail to run on Linux because the code was littered with hardcoded backslashes, and had never had to run on an OS which used a different path separator. But if you want your HTML to work, you need to at least support the latest Firefox, Safari, Chrome, and maybe IE and Opera.
If you've done that, there's a good chance you've coded more or less to the standards, with a minimum of per-browser hacks, because to do otherwise would be insane -- which means there's a good chance that if I'm using a browser you didn't test, but my browser implements the specs reasonably, your code probably works. If Java developers had been forced to test their code on Windows, Linux, and OS X, there's a good chance it wouldn't break on, say, Solaris -- in the example above, they'd at least be forced to hardcode a forward slash instead (which works on all of the above platforms) or use the system path separator.
Second, because of this actual competition, all browsers, proprietary or not, aren't just competing to add crazy new non-standard features, they're also competing to implement the standard the best. The ACID tests helped a lot here -- no one (not even Microsoft, anymore) wants to be known as the browser that universally scores dead last here, and is therefore causing developers the most headaches when porting their code. By contrast, the only reason Java can maintain anything approaching a standard is because there is exactly one implementation, which is also a terrible thing for an open standard. Look how much uncertainty there was when Oracle started suing people (like Google) over making something similar to Java, but not quite. If Java was more like HTML, then Dalvik would've been pressured to become more and more standard, and where it got the standard and OpenJDK didn't, OpenJDK would be fixed -- but instead, Oracle sued.
Third, there's the part where you don't need to install anything. Everyone already has a browser, and most people have a fairly decent browser, other than, maybe, office drones stuck with IE6 -- but then, they'd also be stuck without Java or with the wrong version of Java.
Fourth, people already have to target the Web anyway. It's no longer acceptable to force people to load a Java applet, and even Flash is getting unfashionable. You need a Web presence, at the very least, and the more stuff that works from the Web, the better off you are -- after all, if you're forcing people to download something, and your competitors "just work", you lose. And once you've got something on the Web anyway, especially if it's something at all interactive, the transition to using it as an application platform isn't that big.
It also helps that JavaScript doesn't suck nearly as much as Java, as a language.
But whatever the reason, it also looks like this s
Not enough people, anyway, for it to be really successful. I think part of the problem is that it took them ages to actually create a separate "XULrunner" package, so that you could install XUL once and then install Firefox, Thunderbird, Sunbird, Songbird, etc. When it was just the Mozilla Suite (Seamonkey, now), it might have made sense to bundle XUL with that, but if I ship a XUL app, it shouldn't be tied to Firefox itself.
But people did write apps using XUL -- Songbird wasn't even affiliated with Mozilla, if I recall. And people wrote tons of Firefox extensions that are almost standalone apps in their own right -- Zotero, for instance. (I think Zotero would make more sense as a standalone XUL app and a "send to Zotero" Firefox extension, but whatever.)
There's another reason XUL never caught on, though: It seemed pointlessly different than HTML. That is, they created their own separate markup language, rather than extend HTML. At the same time, you couldn't really write websites in XUL -- if I recall, it would at least ask for some sort of permissions -- that, and it wouldn't run on any other browser. So, despite the fact that so much of the Firefox UI (or, I'd guess, most of Firefox that isn't Gecko) is written in XML+JavaScript, it was still very different than the Web itself.
Compare this to their new invention, Jetpack, which is really taking the main idea behind the Chrome extension API and applying it to Firefox -- Chrome extensions almost entirely use HTML+JavaScript. They add some custom JavaScript APIs, but other than that, if there's a way to do what you want to do in HTML+JavaScript, they won't duplicate it for Chrome -- for example, if you absolutely need to run native code with full OS access, you use NPAPI and write a plugin, and restrict it to your extension.
I think this might be why HTML5 is taking off as an actual generic application platform -- people need web apps anyway, so it's already a cool idea to take your web app offline and integrate it into the desktop. Or, if you're writing a new app, you already have a bunch of web developers that you needed for your web app, so you don't need to hire or train experts in Win32 or.NET -- you just write another web app.
Basically what you are saying here is that when you move to a "Browser is the OS set up" what you are actually moving to is a "Google is your administrator and your system and all applications are controlled by them set up".
I can't imagine Microsoft deliberately walking into that.
No, it seems much more like, Google and others may provide a software-as-a-service version (pure Web), but it can also run locally. At this point, it's essentially a replacement for the other platforms you mentioned -- Java being the closest, I think.
I do wish there was more emphasis on local servers, but as a developer and a user, I actually like this trend. As a developer, it means that while my frontend is forced into HTML/CSS/JavaScript, my backend can be anything I want, and I don't need to make my backend code run on everyone and their dog's Windows machine, let alone every OS. I can push a lot of stuff to the backend, and what's left is much easier to make work on all recent browsers than it is to, say, make a portable C++ app that works on all OSes -- and if it was Java, I'd have to either include a JVM or force users to download one.
And as a user, it means everyone making an actual Web app is actually making a Linux app without realizing it -- and a whatever-OS-I-want app. As a user with some dev skills, I actually get more control over many of these apps, not less -- while I may be surrendering my data (if I had any to begin with; I tend not to put important stuff "in the cloud"), I gain the ability to use userscripts (Greasemonkey), custom CSS, or even my own web scraper to interact with this app in any way I want. (Every webcomic I read now has keyboard shortcuts, whether they wanted to or not (thanks, XKCD!).) Even if I didn't have development tools, I could still download userscripts and extensions which extend the functionality of the app.
It also means I get features I actually like from the Web. Not installing, or streamlining installation, is nice (thank you, Linux package managers), tabs, bookmarks, back/forward, or sending a link to a friend. These are all things which can be implemented (reinventing the wheel) in native apps, but for a well-designed web app, they just work. It's true that sometimes the developers have to deliberately re-enable these things (hash URLs), but it's common for this to happen, since users expect it.
My main complaint was being forced into JavaScript/HTML. But now we've got canvas (and even WebGL) and Google's Native Client for things which don't fit well with JavaScript/HTML, though again, most things do -- I used to hate HTML, but more recently, I've come to appreciate its extensibility (microformats and such) and semantic markup. I also used to hate HTTP, but take semantic markup + REST + proper use of hypertext, and you've got an API almost by accident, as an artifact of writing an app correctly.
Every new protocol seriously adopted in the last years seems to have to have an http tunnelled equivalent. This is insane...
For every protocol, maybe. But for the vast majority of protocols, HTTP done right (REST or websockets) is actually a good fit.
Still, I do wish there was some API by which a web app could ask for cross-site, or a generic socket API. That's about the only thing that's missing.
it's just another binary format equivalent to ELF or COFF.
Except, unlike those, it's actually standardized to the point where if you get an x86_64 binary and you're running and x86_64 browser, you can execute it, no matter what OS you're running -- whereas ELF (other than within NativeClient, if they're still using ELF) doesn't run on Windows, for example. There's also a "portable native client" which compiles to LLVM bytecode, which can then be compiled on the client's system, so you're not even necessarily locking people to an architecture.
It must be said, though, that MS Office always offered a plain text format (RTF) so the migration path was always there. Newer formats are zipped XML [guardian.co.uk], so the point is largely moot.
Oh wow.
I'm sorry, I don't have time to give this the treatment it deserves, so I'll have to direct you to here for a start:
Microsoft Open Office XML has 6000 pages of documentation, still professionals need better documentation. Open Office XML is the largest standard that was ever put under ISO fast-track procedures.
The large amount of comments filed by national standard bodies indicates that ECMA did no proper review of the standard proposal. No one printed them yet. However the dispositions for the comments provided by ECMA for the BRM comprise another 2300 pages of bugfixes and deprecated functionality
Yeah. So XML is great, once I read the six thousand page spec. Why is this better than a binary format again? Having an open spec is helpful, but forget about open implementations -- IIRC, even Office itself isn't compliant, which causes even more problems given that if someone else, by some miracle, implements the spec properly, they still can't interoperate.
By contrast, while OpenOffice is kind of big and bloated, ODF does have multiple independent implementations, and they do seem to work reasonably well. Even if this wasn't the case, at least you don't have the problem where a bit of functionality is deliberately left unspecified -- large chunks of the OOXML format will mention something (a tag, say) and then declare its actual behavior to be "beyond the scope of this document" or "implementation-defined".
The same is true of RTF, by the way -- while normal.doc documents have enough issues between versions of Word (often OpenOffice does a better job of opening old ones), RTF does much worse. And if Office can't keep it straight, how is anyone else supposed to get it approximately right?
I don't know that I'd suggest a business keep their data in ODF, either, but it's a hell of a lot better than OOXML as far as having actual migration paths and being reasonable for third-party software to read and manipulate. The last time I actually tried working with this stuff (just extracting stuff from MS Office and converting it to more-reasonable HTML), I tried parsing the OOXML, only to realize that it was suicide without a library, no matter how small the data I needed was. Switched to ODF and it was still a project, but I could actually read the document and figure out what was going on, without having to read the spec.
But yeah, "It's zipped XML, therefore it has a migration path!" May as well say, "It's stored in bytes, therefore it has a migration path!"
...because frankly, this isn't an excuse if there in fact still are such bugs in OpenOffice. But really:
Students may use OpenOffice, but only until they encounter some serious bug that threatens their paper (which will occur on the last night before submission date.)
If this is really a problem for you, you've already fucked up. You've waited until the last night before the submission date without having something viable. You allow one software bug to threaten "your paper", suggesting you only have one copy in one place...
It's not like this only happens with OpenOffice, and it seems to rarely happen, period. Supposing it does, any decent university is going to have multiple computer labs which are going to have some form of office installed -- my university does, in fact, have some Linux machines with OpenOffice, as well as plenty of Windows/Mac machines with MS Office. I've also never had a problem getting an instructor to accept PDF.
So, while none of this excuses OpenOffice if this kind of crap is still happening -- and if it is, in fact, an OpenOffice bug and not, say, an OS bug or hardware issue -- if something goes screwy with a paper I'm working on (or with my whole machine), I walk over to a computer lab, log in, and find a recent copy of my paper on the network storage. I lose maybe half an hour, and I still get the thing in on time.
Oh, and I get it done well before the night before it's due.
What's cool about this is that at least for audio, it's actually efficient enough that we can stop caring about whether browsers support a given codec. Maybe use <audio> when supported, fall back to pure JS when it isn't.
All that without relying on any plugins, which means the entire process can sit inside the same sandbox browsers have been building for years.
What we had before this required users to download and install software, and give it full rights to the machine, in order to play back media. It's similar superficially, I suppose, but it has massive practical differences.
More frustrating than that, to me, is that while I would love to find a solution that works for those less-than-1% group, I don't think I own any machines that don't come with hardware decoders for all of these things.
Still, it is nice to have another option. This works surprisingly well -- Firefox uses ~40% of an 800 mhz CPU. Chrome used ~20%, but didn't actually play, so it's not quite the same. What we need now is better detection/negotiation, so I can use native HTML5 audio on sane browsers and fall back to hacks like this when they aren't supported.
But Raffi Krikorian, infrastructure engineer at Twitter, also called out the limitations of HTML5, saying it's "really nice to look at," but can't do things such as send notifications to users.
I don't know if it's part of HTML itself, but GMail manages to send me desktop notifications via Chrome. I'm not seeing a problem here.
Also, is anyone surprised that the Microsoft guy is the loudest skeptic? I mean, I've heard a lot of good arguments from a lot of skeptics, but this really seems like a case of "follow the money". Twitter is skeptical because they can actually build a better experience, in some circumstances, with a custom client -- but they're still doing HTML. Microsoft has to be looking at this as yet another assault on their Win32 monopoly.
Well, again, do we know that this is what actually happened?
Or is it that there just weren't enough Linux gamers of any sort to begin with for a company like Loki to be profitable?
In either case, I was pleasantly surprised to find that most of my peers who are tech savvy enough to have heard of Linux have also bought the Humble Indie Bundle, play Minecraft on Linux, etc. Yes, open source would be better, but they're not going to refuse to play a game because it's proprietary, especially if it's ported to their OS of choice.
Traffic is still probably moving faster in those cases than with the escalator. It's also giving them that much more exercise. I think that's a fair trade.
Developer: I'm going to make a great game for Linux, it's closed source. Linux Community: closed source? BAH! No thank you, Linux is about Freedom man...
Seriously? Can you cite any actual examples of this actually happening?
I mean, I might grumble that a game is closed, and that I might be able to solve some issue it has if it's open, but I'll buy it. How many Linux users with nVidia cards refuse to run the nVidia proprietary drivers? Those are a much bigger issue than some game running in userspace.
It's not the access to high performance video drivers, as they don't exist.
Bullshit. The nVidia drivers benchmark comparably on Linux and Windows. ATI might still be worse.
And this is where I think the Linux community missed an opportunity. Back when Quake 3 was the hot new shit, and was how benchmarks were done, someone benchmarked Windows vs Wine vs native Linux. They found the performance went roughly in that order -- Quake 3 was faster under Wine on Linux than it was on Windows, and the native Linux port was faster still.
So you're right that gamers need something better -- but we had that. We had a significant performance advantage for awhile, and that was out of the box. This was also back when desktop GUI environments were still fairly resource-intensive things, so you could get even more performance out of killing off your entire GUI and running just that game in its own X server (with no other X apps) -- and PC gamers were always looking for little tweaks like that to give them an edge.
None of these things are true anymore. Linux is no longer a performance edge by itself, and whatever performance there is to be gained isn't really going to make your framerate go up. That's where it's even comparable, because since then, Direct3D got better and much more popular. There was a point where OpenGL was just faster and better, when games would ship with multiple renderers (OpenGL, D3D, and software) in case one happened to be faster or better supported on your machine, but as I remember, after a certain point, Half-Life always ran faster under OpenGL. But again, things just aren't comparable anymore -- too many games are D3D only.
That, and there are so many new features (all of them high-performance) that you're not likely to get the best experience out of open source drivers, so if you're stuck with ATI, Linux is going to be significantly worse than Windows, even for an identical OpenGL game.
I feel like if we'd kept that edge just a bit longer, we might've seen a lot more start to change. I played an MMO with a friend, and aside from his Norton Anti-Virus always interrupting his game, I could run it windowed (via Wine hacks) while he couldn't -- and eventually, when the game's auto-patching system not only worked on Wine but not his Windows, but we "patched" his copy by pulling files out of my Wine copy, he was convinced -- a few months later, I set him up with Linux. That kind of thing happens much less often these days.
Anyway...
It's not the access to ubiquitous and non-finicky audio systems, as they don't exist.
I don't know, ALSA pretty much met that goal, and I haven't had issues with Pulse since I switched to it, though I did wait awhile before making that switch. For a gamer, though, I don't see needing anything more than ALSA. For that matter, I also don't see a game developer needing to use anything more than OpenAL.
You are, however, almost right about this:
The gamers need something better than what they have if they are going to move away from their current situation and negate their library of games... The majority of game companies won't make games on Linux until there is a market, which doesn't exist.
Linux support is still a very good idea for a new indie game. And if anything, I'd expect it to be easier to build a portable game than other kinds of applications -- the game's entire interface with the OS can be reduced to OpenAL, OpenGL, the filesystem, and the network. OpenAL and OpenGL are already ported, and the filesystem is almost automatically portable if you don't assume stupid things (don't add a bunch of backslashes; forward slashes work on Windows, too).
But then, indie developers can't really afford to exclusively support Linux, which means the game itself isn't an inc
Unless of course you botnet all the machines in, say, China to do this for you...
This would be a fun calculation to run, but I'm not convinced it would actually work out in the end. For one, how many computers in China have a decent video card capable of being used for this? If you do CPU mining, you need about 150 good CPUs to match a single video card, and there are people who build massive mining operations, putting at least two or three video cards per machine and as many machines as they can support with the amount of electricity they have.
Bitcoin is currently estimated to be the world's most powerful supercomputer. If you could do it that way, it seems like it would really have to be all the machines in China.
And again, you're still not likely to get all of it. You'll get enough to cause a lot of damage, and if you control more than 50% of the computing resources in the network, you're a much bigger threat than just mining extra coins. But your claim of "enough" processing power... I think if a p2p system is only vulnerable to being gamed when all of the computers in the most populous country in the world are brought to bear against it is a pretty damned resilient system.
It also seems like with that amount of power, there would have to be other things you could attack which would be much more interesting and lucrative.
How is the difficulty increased arbitrarily for a distributed system?
It's increased according to preset "rules", in the same way most things are enforced in a distributed system. That is, each node will, after two weeks, look at the past two weeks and calculate what the new difficulty should be. They'll calculate it according to the same algorithm -- probably something stupidly simple, like what the rate of block generation is and what it should be -- and they'll come up with the same number.
After that, each node will reject new blocks which aren't sufficiently "difficult", which means that anyone who wants to continue to use the old difficulty level effectively needs to fork the network -- or, maybe, control a majority of the machines.
I'm not entirely sure this is how it works, but it seems like an obvious implementation.
Well, right now, we've only seen a DirectX implementation, so that'd be one reason.
Another is that it might actually make your application slower, because you now have the synchronization of your multi-core CPU to think about, and synchronizing data to and from the GPU, etc. Alright, yes, this thing abstracts all that away from you, which is cool, but you have to have at least some part of your application which actually gains something from being parallelized.
And while I don't know the details here, I would guess you still have to do some thinking about where to apply this, and how, and what will work, and what will fail horribly. If nothing else, it's got its own separate syntax.
Now consider the amount of work it's going to take to figure out if and when you'll get any performance boost, and you're guessing you might get 1%. Compare that to the amount of time you're going to spend on it. Your time might be better served with more traditional forms of optimization -- maybe instead of identifying parts which can run in parallel on the GPU, you want to identify tight loops you can rewrite in assembly.
I can imagine there would be cases where it would be useless, but I really can't see it being worthwhile to try this on anything you don't already know has something embarrassingly parallel in it. It might be only 1% of your code that's embarrassingly parallel, but you still need to find that. Otherwise, it seems as likely to slow your program down (and waste your time testing it) rather than give you any performance increase.
That's just it, though -- you now have to break through a large number of peers to find a miner, and to be sure you've found one. This is something a botnet might be able to do, but then, if a botnet controls a significant portion of the Bitcoin network, there are bigger problems.
I take a dim view of uppity managers claiming methods like Agile, XP, Scrum and blah blah blah make two shits of a difference when you are not granted autonomy.
And what about when you are granted a reasonable amount of autonomy?
It also seems like these things are becoming buzzwords, while forgetting their roots. I find I still agree with the Agile Manifesto, though I'm as skeptical of trendy managers as you are.
But not necessarily as cheap as just assigning the pointer.
Worse than that, it's at least one extra instruction, and one which is repeated often. Probably inlined, because actually making any sort of call is going to take at least as much space as incrementing/decrementing.
Which means your code is now bigger everywhere. Which means more cache misses. You probably get smoother, more consistent performance, but probably not overall better, and there aren't that many places this particular bit of consistency matters.
However, I don't agree that reference counting has so many drawbacks as to not be useful. I don't know of many other mechanisms for GC other than manually using malloc/free/new/delete as appropriate which can deliver quite the consistency of reference counting -- the instant nothing has a reference to the object anymore, it goes away and its destructor is called. This is one thing I miss from C++ in languages which do have builtin GC -- it's actually nicer semantics.
For example, in Ruby, I can do this:
open 'foo', 'w' do |file|
file.puts 'Hello, world!' end
This guarantees the file is closed, which is helpful when file descriptors are limited, or when I just want to be sure that everything's properly flushed to disk. But I have to do it in that block format, which is occasionally inconvenient, and my only other option is to either manually close the file or let the file maybe be closed by garbage collection at some point -- but finalizers aren't guaranteed to ever run before the program itself eventually closes, and it's hard to imagine a good way to catch errors from that, so no, bad idea.
By contrast, in C++, we can do this (grabbed from a quick Google search; it's been awhile since I've done C++):
And as soon as the object falls out of scope, the file will automatically be closed. The thing I like about reference counting, though I can imagine there might be more efficient ways to do it, is that I can do something like this:
Only this time, I can pass that shared_ptr around -- the file will now automatically close when the last reference to it falls out of scope.
Sure, there are limitations. Sure, 99% of the time, I'd much rather have the advantages and limitations of real GC. But I think that's an example of where reference counting is still useful.
Nope. The difficulty also goes up every two weeks or so in order to keep the rate constant. You'd have to have a ridiculous amount more power than the entire other network for a given two weeks, and you still wouldn't necessarily get all of it, you'd just increase your probability of getting all of it.
That's not "arbitrary" in the same sense as a fiat currency. That's "arbitrary" in the sense that, if it were gold, I could "arbitrarily" decide to dig up the entire landscape looking for ore.
What's more, the more computing power that's added to the system, the better, because it's that much harder for any one entity to seize over 50% of the computing resources and start to game the network.
If one cannot control their personal finances such that they have a decent credit rating, that may already be negatively impacting themselves as a candidate. If one cannot obey the law and has a criminal record, that may already be negatively impacting themselves as a candidate.
Both of these have something to do with the ability to conduct ones self responsibly. Paying your debts and following the law are things that it makes sense for a company to care about.
How drunk you get in a country where it is legal to get drunk, and whether you are willing to share that, is pretty much irrelevant. I'm really not sure how "discretion" factors in here, either -- it isn't as though this is something I need to be keeping secret.
You may not like it, but the individual is often the image of the company they represent.
I not only don't like it, I see evidence to the contrary all over the place -- tons of people with private blogs where they are careful to mention that this doesn't reflect their employers' opinion.
For what it's worth, I don't even drink. I still don't like this -- there are tons of opinions I'm going to have and share online, most of which have nothing to do with whether I can do my job effectively. What's next, rejecting me because of something like a recent change to "Relationship Status: Single" because I couldn't keep a girl, or because I'll be too depressed to do my job effectively?
Slashdot Mirror
Most are, but they can also get to the Chrome extension API, I think. That, and it means Google can sell them the way they can sell other "apps", which means that whether it's "just a website" or not, I can actually sell it to you as if it was a thing.
And the big thing about Java was that you would be able to write code that was platform-independent, and just rely on a Java interpreter that would be released on any necessary platforms. Which is why everything is written in Java now...
I don't think that's the biggest reason. I think the biggest reason is that it was reasonably similar to other 800-lb gorillas, like C++, but included things like garbage collection.
I'm just saying, using a browser as a conveyance for some sort of universal HTML-based software market just seems like a new version of an old idea that didn't pan out in the first place.
Maybe so, but here are some things that help:
First, there are multiple implementations with significant marketshare. If your app didn't run on things like kaffe or gcj, no big loss -- if one of Oracle's flagship JDeveloper-based frameworks doesn't work on OpenJDK today, they don't care -- hell, one of the bigger reasons Java failed is Microsoft delivered a broken JVM, and if you only care about supporting Windows, you code to Microsoft's broken JVM and you don't need to run anywhere else. Even ignoring that, I've taken recent code written for Java6 and had it fail to run on Linux because the code was littered with hardcoded backslashes, and had never had to run on an OS which used a different path separator. But if you want your HTML to work, you need to at least support the latest Firefox, Safari, Chrome, and maybe IE and Opera.
If you've done that, there's a good chance you've coded more or less to the standards, with a minimum of per-browser hacks, because to do otherwise would be insane -- which means there's a good chance that if I'm using a browser you didn't test, but my browser implements the specs reasonably, your code probably works. If Java developers had been forced to test their code on Windows, Linux, and OS X, there's a good chance it wouldn't break on, say, Solaris -- in the example above, they'd at least be forced to hardcode a forward slash instead (which works on all of the above platforms) or use the system path separator.
Second, because of this actual competition, all browsers, proprietary or not, aren't just competing to add crazy new non-standard features, they're also competing to implement the standard the best. The ACID tests helped a lot here -- no one (not even Microsoft, anymore) wants to be known as the browser that universally scores dead last here, and is therefore causing developers the most headaches when porting their code. By contrast, the only reason Java can maintain anything approaching a standard is because there is exactly one implementation, which is also a terrible thing for an open standard. Look how much uncertainty there was when Oracle started suing people (like Google) over making something similar to Java, but not quite. If Java was more like HTML, then Dalvik would've been pressured to become more and more standard, and where it got the standard and OpenJDK didn't, OpenJDK would be fixed -- but instead, Oracle sued.
Third, there's the part where you don't need to install anything. Everyone already has a browser, and most people have a fairly decent browser, other than, maybe, office drones stuck with IE6 -- but then, they'd also be stuck without Java or with the wrong version of Java.
Fourth, people already have to target the Web anyway. It's no longer acceptable to force people to load a Java applet, and even Flash is getting unfashionable. You need a Web presence, at the very least, and the more stuff that works from the Web, the better off you are -- after all, if you're forcing people to download something, and your competitors "just work", you lose. And once you've got something on the Web anyway, especially if it's something at all interactive, the transition to using it as an application platform isn't that big.
It also helps that JavaScript doesn't suck nearly as much as Java, as a language.
But whatever the reason, it also looks like this s
Not enough people, anyway, for it to be really successful. I think part of the problem is that it took them ages to actually create a separate "XULrunner" package, so that you could install XUL once and then install Firefox, Thunderbird, Sunbird, Songbird, etc. When it was just the Mozilla Suite (Seamonkey, now), it might have made sense to bundle XUL with that, but if I ship a XUL app, it shouldn't be tied to Firefox itself.
But people did write apps using XUL -- Songbird wasn't even affiliated with Mozilla, if I recall. And people wrote tons of Firefox extensions that are almost standalone apps in their own right -- Zotero, for instance. (I think Zotero would make more sense as a standalone XUL app and a "send to Zotero" Firefox extension, but whatever.)
There's another reason XUL never caught on, though: It seemed pointlessly different than HTML. That is, they created their own separate markup language, rather than extend HTML. At the same time, you couldn't really write websites in XUL -- if I recall, it would at least ask for some sort of permissions -- that, and it wouldn't run on any other browser. So, despite the fact that so much of the Firefox UI (or, I'd guess, most of Firefox that isn't Gecko) is written in XML+JavaScript, it was still very different than the Web itself.
Compare this to their new invention, Jetpack, which is really taking the main idea behind the Chrome extension API and applying it to Firefox -- Chrome extensions almost entirely use HTML+JavaScript. They add some custom JavaScript APIs, but other than that, if there's a way to do what you want to do in HTML+JavaScript, they won't duplicate it for Chrome -- for example, if you absolutely need to run native code with full OS access, you use NPAPI and write a plugin, and restrict it to your extension.
I think this might be why HTML5 is taking off as an actual generic application platform -- people need web apps anyway, so it's already a cool idea to take your web app offline and integrate it into the desktop. Or, if you're writing a new app, you already have a bunch of web developers that you needed for your web app, so you don't need to hire or train experts in Win32 or .NET -- you just write another web app.
Basically what you are saying here is that when you move to a "Browser is the OS set up" what you are actually moving to is a "Google is your administrator and your system and all applications are controlled by them set up".
I can't imagine Microsoft deliberately walking into that.
No, it seems much more like, Google and others may provide a software-as-a-service version (pure Web), but it can also run locally. At this point, it's essentially a replacement for the other platforms you mentioned -- Java being the closest, I think.
I do wish there was more emphasis on local servers, but as a developer and a user, I actually like this trend. As a developer, it means that while my frontend is forced into HTML/CSS/JavaScript, my backend can be anything I want, and I don't need to make my backend code run on everyone and their dog's Windows machine, let alone every OS. I can push a lot of stuff to the backend, and what's left is much easier to make work on all recent browsers than it is to, say, make a portable C++ app that works on all OSes -- and if it was Java, I'd have to either include a JVM or force users to download one.
And as a user, it means everyone making an actual Web app is actually making a Linux app without realizing it -- and a whatever-OS-I-want app. As a user with some dev skills, I actually get more control over many of these apps, not less -- while I may be surrendering my data (if I had any to begin with; I tend not to put important stuff "in the cloud"), I gain the ability to use userscripts (Greasemonkey), custom CSS, or even my own web scraper to interact with this app in any way I want. (Every webcomic I read now has keyboard shortcuts, whether they wanted to or not (thanks, XKCD!).) Even if I didn't have development tools, I could still download userscripts and extensions which extend the functionality of the app.
It also means I get features I actually like from the Web. Not installing, or streamlining installation, is nice (thank you, Linux package managers), tabs, bookmarks, back/forward, or sending a link to a friend. These are all things which can be implemented (reinventing the wheel) in native apps, but for a well-designed web app, they just work. It's true that sometimes the developers have to deliberately re-enable these things (hash URLs), but it's common for this to happen, since users expect it.
My main complaint was being forced into JavaScript/HTML. But now we've got canvas (and even WebGL) and Google's Native Client for things which don't fit well with JavaScript/HTML, though again, most things do -- I used to hate HTML, but more recently, I've come to appreciate its extensibility (microformats and such) and semantic markup. I also used to hate HTTP, but take semantic markup + REST + proper use of hypertext, and you've got an API almost by accident, as an artifact of writing an app correctly.
Every new protocol seriously adopted in the last years seems to have to have an http tunnelled equivalent. This is insane...
For every protocol, maybe. But for the vast majority of protocols, HTTP done right (REST or websockets) is actually a good fit.
Still, I do wish there was some API by which a web app could ask for cross-site, or a generic socket API. That's about the only thing that's missing.
it's just another binary format equivalent to ELF or COFF.
Except, unlike those, it's actually standardized to the point where if you get an x86_64 binary and you're running and x86_64 browser, you can execute it, no matter what OS you're running -- whereas ELF (other than within NativeClient, if they're still using ELF) doesn't run on Windows, for example. There's also a "portable native client" which compiles to LLVM bytecode, which can then be compiled on the client's system, so you're not even necessarily locking people to an architecture.
Citation, please?
Because it uses Portage, which is the Gentoo package manager, and which is not at all used by Ubuntu.
Second obligatory XKCD.
It must be said, though, that MS Office always offered a plain text format (RTF) so the migration path was always there. Newer formats are zipped XML [guardian.co.uk], so the point is largely moot.
Oh wow.
I'm sorry, I don't have time to give this the treatment it deserves, so I'll have to direct you to here for a start:
Microsoft Open Office XML has 6000 pages of documentation, still professionals need better documentation. Open Office XML is the largest standard that was ever put under ISO fast-track procedures.
The large amount of comments filed by national standard bodies indicates that ECMA did no proper review of the standard proposal. No one printed them yet. However the dispositions for the comments provided by ECMA for the BRM comprise another 2300 pages of bugfixes and deprecated functionality
Yeah. So XML is great, once I read the six thousand page spec. Why is this better than a binary format again? Having an open spec is helpful, but forget about open implementations -- IIRC, even Office itself isn't compliant, which causes even more problems given that if someone else, by some miracle, implements the spec properly, they still can't interoperate.
By contrast, while OpenOffice is kind of big and bloated, ODF does have multiple independent implementations, and they do seem to work reasonably well. Even if this wasn't the case, at least you don't have the problem where a bit of functionality is deliberately left unspecified -- large chunks of the OOXML format will mention something (a tag, say) and then declare its actual behavior to be "beyond the scope of this document" or "implementation-defined".
The same is true of RTF, by the way -- while normal .doc documents have enough issues between versions of Word (often OpenOffice does a better job of opening old ones), RTF does much worse. And if Office can't keep it straight, how is anyone else supposed to get it approximately right?
I don't know that I'd suggest a business keep their data in ODF, either, but it's a hell of a lot better than OOXML as far as having actual migration paths and being reasonable for third-party software to read and manipulate. The last time I actually tried working with this stuff (just extracting stuff from MS Office and converting it to more-reasonable HTML), I tried parsing the OOXML, only to realize that it was suicide without a library, no matter how small the data I needed was. Switched to ODF and it was still a project, but I could actually read the document and figure out what was going on, without having to read the spec.
But yeah, "It's zipped XML, therefore it has a migration path!" May as well say, "It's stored in bytes, therefore it has a migration path!"
...because frankly, this isn't an excuse if there in fact still are such bugs in OpenOffice. But really:
Students may use OpenOffice, but only until they encounter some serious bug that threatens their paper (which will occur on the last night before submission date.)
If this is really a problem for you, you've already fucked up. You've waited until the last night before the submission date without having something viable. You allow one software bug to threaten "your paper", suggesting you only have one copy in one place...
It's not like this only happens with OpenOffice, and it seems to rarely happen, period. Supposing it does, any decent university is going to have multiple computer labs which are going to have some form of office installed -- my university does, in fact, have some Linux machines with OpenOffice, as well as plenty of Windows/Mac machines with MS Office. I've also never had a problem getting an instructor to accept PDF.
So, while none of this excuses OpenOffice if this kind of crap is still happening -- and if it is, in fact, an OpenOffice bug and not, say, an OS bug or hardware issue -- if something goes screwy with a paper I'm working on (or with my whole machine), I walk over to a computer lab, log in, and find a recent copy of my paper on the network storage. I lose maybe half an hour, and I still get the thing in on time.
Oh, and I get it done well before the night before it's due.
That's what <ecode> is for.
Try <audio>, if they don't have MP3 support, fall back to this.
Before this, the fallback would've been Flash, which sucks.
What's cool about this is that at least for audio, it's actually efficient enough that we can stop caring about whether browsers support a given codec. Maybe use <audio> when supported, fall back to pure JS when it isn't.
All that without relying on any plugins, which means the entire process can sit inside the same sandbox browsers have been building for years.
What we had before this required users to download and install software, and give it full rights to the machine, in order to play back media. It's similar superficially, I suppose, but it has massive practical differences.
More frustrating than that, to me, is that while I would love to find a solution that works for those less-than-1% group, I don't think I own any machines that don't come with hardware decoders for all of these things.
Still, it is nice to have another option. This works surprisingly well -- Firefox uses ~40% of an 800 mhz CPU. Chrome used ~20%, but didn't actually play, so it's not quite the same. What we need now is better detection/negotiation, so I can use native HTML5 audio on sane browsers and fall back to hacks like this when they aren't supported.
But Raffi Krikorian, infrastructure engineer at Twitter, also called out the limitations of HTML5, saying it's "really nice to look at," but can't do things such as send notifications to users.
I don't know if it's part of HTML itself, but GMail manages to send me desktop notifications via Chrome. I'm not seeing a problem here.
Also, is anyone surprised that the Microsoft guy is the loudest skeptic? I mean, I've heard a lot of good arguments from a lot of skeptics, but this really seems like a case of "follow the money". Twitter is skeptical because they can actually build a better experience, in some circumstances, with a custom client -- but they're still doing HTML. Microsoft has to be looking at this as yet another assault on their Win32 monopoly.
Well, again, do we know that this is what actually happened?
Or is it that there just weren't enough Linux gamers of any sort to begin with for a company like Loki to be profitable?
In either case, I was pleasantly surprised to find that most of my peers who are tech savvy enough to have heard of Linux have also bought the Humble Indie Bundle, play Minecraft on Linux, etc. Yes, open source would be better, but they're not going to refuse to play a game because it's proprietary, especially if it's ported to their OS of choice.
Traffic is still probably moving faster in those cases than with the escalator. It's also giving them that much more exercise. I think that's a fair trade.
Developer: I'm going to make a great game for Linux, it's closed source.
Linux Community: closed source? BAH! No thank you, Linux is about Freedom man...
Seriously? Can you cite any actual examples of this actually happening?
I mean, I might grumble that a game is closed, and that I might be able to solve some issue it has if it's open, but I'll buy it. How many Linux users with nVidia cards refuse to run the nVidia proprietary drivers? Those are a much bigger issue than some game running in userspace.
You are flat wrong on a few points:
It's not the access to high performance video drivers, as they don't exist.
Bullshit. The nVidia drivers benchmark comparably on Linux and Windows. ATI might still be worse.
And this is where I think the Linux community missed an opportunity. Back when Quake 3 was the hot new shit, and was how benchmarks were done, someone benchmarked Windows vs Wine vs native Linux. They found the performance went roughly in that order -- Quake 3 was faster under Wine on Linux than it was on Windows, and the native Linux port was faster still.
So you're right that gamers need something better -- but we had that. We had a significant performance advantage for awhile, and that was out of the box. This was also back when desktop GUI environments were still fairly resource-intensive things, so you could get even more performance out of killing off your entire GUI and running just that game in its own X server (with no other X apps) -- and PC gamers were always looking for little tweaks like that to give them an edge.
None of these things are true anymore. Linux is no longer a performance edge by itself, and whatever performance there is to be gained isn't really going to make your framerate go up. That's where it's even comparable, because since then, Direct3D got better and much more popular. There was a point where OpenGL was just faster and better, when games would ship with multiple renderers (OpenGL, D3D, and software) in case one happened to be faster or better supported on your machine, but as I remember, after a certain point, Half-Life always ran faster under OpenGL. But again, things just aren't comparable anymore -- too many games are D3D only.
That, and there are so many new features (all of them high-performance) that you're not likely to get the best experience out of open source drivers, so if you're stuck with ATI, Linux is going to be significantly worse than Windows, even for an identical OpenGL game.
I feel like if we'd kept that edge just a bit longer, we might've seen a lot more start to change. I played an MMO with a friend, and aside from his Norton Anti-Virus always interrupting his game, I could run it windowed (via Wine hacks) while he couldn't -- and eventually, when the game's auto-patching system not only worked on Wine but not his Windows, but we "patched" his copy by pulling files out of my Wine copy, he was convinced -- a few months later, I set him up with Linux. That kind of thing happens much less often these days.
Anyway...
It's not the access to ubiquitous and non-finicky audio systems, as they don't exist.
I don't know, ALSA pretty much met that goal, and I haven't had issues with Pulse since I switched to it, though I did wait awhile before making that switch. For a gamer, though, I don't see needing anything more than ALSA. For that matter, I also don't see a game developer needing to use anything more than OpenAL.
You are, however, almost right about this:
The gamers need something better than what they have if they are going to move away from their current situation and negate their library of games... The majority of game companies won't make games on Linux until there is a market, which doesn't exist.
Linux support is still a very good idea for a new indie game. And if anything, I'd expect it to be easier to build a portable game than other kinds of applications -- the game's entire interface with the OS can be reduced to OpenAL, OpenGL, the filesystem, and the network. OpenAL and OpenGL are already ported, and the filesystem is almost automatically portable if you don't assume stupid things (don't add a bunch of backslashes; forward slashes work on Windows, too).
But then, indie developers can't really afford to exclusively support Linux, which means the game itself isn't an inc
Unless of course you botnet all the machines in, say, China to do this for you...
This would be a fun calculation to run, but I'm not convinced it would actually work out in the end. For one, how many computers in China have a decent video card capable of being used for this? If you do CPU mining, you need about 150 good CPUs to match a single video card, and there are people who build massive mining operations, putting at least two or three video cards per machine and as many machines as they can support with the amount of electricity they have.
Bitcoin is currently estimated to be the world's most powerful supercomputer. If you could do it that way, it seems like it would really have to be all the machines in China.
And again, you're still not likely to get all of it. You'll get enough to cause a lot of damage, and if you control more than 50% of the computing resources in the network, you're a much bigger threat than just mining extra coins. But your claim of "enough" processing power... I think if a p2p system is only vulnerable to being gamed when all of the computers in the most populous country in the world are brought to bear against it is a pretty damned resilient system.
It also seems like with that amount of power, there would have to be other things you could attack which would be much more interesting and lucrative.
How is the difficulty increased arbitrarily for a distributed system?
It's increased according to preset "rules", in the same way most things are enforced in a distributed system. That is, each node will, after two weeks, look at the past two weeks and calculate what the new difficulty should be. They'll calculate it according to the same algorithm -- probably something stupidly simple, like what the rate of block generation is and what it should be -- and they'll come up with the same number.
After that, each node will reject new blocks which aren't sufficiently "difficult", which means that anyone who wants to continue to use the old difficulty level effectively needs to fork the network -- or, maybe, control a majority of the machines.
I'm not entirely sure this is how it works, but it seems like an obvious implementation.
Well, right now, we've only seen a DirectX implementation, so that'd be one reason.
Another is that it might actually make your application slower, because you now have the synchronization of your multi-core CPU to think about, and synchronizing data to and from the GPU, etc. Alright, yes, this thing abstracts all that away from you, which is cool, but you have to have at least some part of your application which actually gains something from being parallelized.
And while I don't know the details here, I would guess you still have to do some thinking about where to apply this, and how, and what will work, and what will fail horribly. If nothing else, it's got its own separate syntax.
Now consider the amount of work it's going to take to figure out if and when you'll get any performance boost, and you're guessing you might get 1%. Compare that to the amount of time you're going to spend on it. Your time might be better served with more traditional forms of optimization -- maybe instead of identifying parts which can run in parallel on the GPU, you want to identify tight loops you can rewrite in assembly.
I can imagine there would be cases where it would be useless, but I really can't see it being worthwhile to try this on anything you don't already know has something embarrassingly parallel in it. It might be only 1% of your code that's embarrassingly parallel, but you still need to find that. Otherwise, it seems as likely to slow your program down (and waste your time testing it) rather than give you any performance increase.
That's just it, though -- you now have to break through a large number of peers to find a miner, and to be sure you've found one. This is something a botnet might be able to do, but then, if a botnet controls a significant portion of the Bitcoin network, there are bigger problems.
I take a dim view of uppity managers claiming methods like Agile, XP, Scrum and blah blah blah make two shits of a difference when you are not granted autonomy.
And what about when you are granted a reasonable amount of autonomy?
It also seems like these things are becoming buzzwords, while forgetting their roots. I find I still agree with the Agile Manifesto, though I'm as skeptical of trendy managers as you are.
But not necessarily as cheap as just assigning the pointer.
Worse than that, it's at least one extra instruction, and one which is repeated often. Probably inlined, because actually making any sort of call is going to take at least as much space as incrementing/decrementing.
Which means your code is now bigger everywhere. Which means more cache misses. You probably get smoother, more consistent performance, but probably not overall better, and there aren't that many places this particular bit of consistency matters.
However, I don't agree that reference counting has so many drawbacks as to not be useful. I don't know of many other mechanisms for GC other than manually using malloc/free/new/delete as appropriate which can deliver quite the consistency of reference counting -- the instant nothing has a reference to the object anymore, it goes away and its destructor is called. This is one thing I miss from C++ in languages which do have builtin GC -- it's actually nicer semantics.
For example, in Ruby, I can do this:
This guarantees the file is closed, which is helpful when file descriptors are limited, or when I just want to be sure that everything's properly flushed to disk. But I have to do it in that block format, which is occasionally inconvenient, and my only other option is to either manually close the file or let the file maybe be closed by garbage collection at some point -- but finalizers aren't guaranteed to ever run before the program itself eventually closes, and it's hard to imagine a good way to catch errors from that, so no, bad idea.
By contrast, in C++, we can do this (grabbed from a quick Google search; it's been awhile since I've done C++):
And as soon as the object falls out of scope, the file will automatically be closed. The thing I like about reference counting, though I can imagine there might be more efficient ways to do it, is that I can do something like this:
Only this time, I can pass that shared_ptr around -- the file will now automatically close when the last reference to it falls out of scope.
Sure, there are limitations. Sure, 99% of the time, I'd much rather have the advantages and limitations of real GC. But I think that's an example of where reference counting is still useful.
Nope. The difficulty also goes up every two weeks or so in order to keep the rate constant. You'd have to have a ridiculous amount more power than the entire other network for a given two weeks, and you still wouldn't necessarily get all of it, you'd just increase your probability of getting all of it.
That's not "arbitrary" in the same sense as a fiat currency. That's "arbitrary" in the sense that, if it were gold, I could "arbitrarily" decide to dig up the entire landscape looking for ore.
What's more, the more computing power that's added to the system, the better, because it's that much harder for any one entity to seize over 50% of the computing resources and start to game the network.
If one cannot control their personal finances such that they have a decent credit rating, that may already be negatively impacting themselves as a candidate. If one cannot obey the law and has a criminal record, that may already be negatively impacting themselves as a candidate.
Both of these have something to do with the ability to conduct ones self responsibly. Paying your debts and following the law are things that it makes sense for a company to care about.
How drunk you get in a country where it is legal to get drunk, and whether you are willing to share that, is pretty much irrelevant. I'm really not sure how "discretion" factors in here, either -- it isn't as though this is something I need to be keeping secret.
You may not like it, but the individual is often the image of the company they represent.
I not only don't like it, I see evidence to the contrary all over the place -- tons of people with private blogs where they are careful to mention that this doesn't reflect their employers' opinion.
For what it's worth, I don't even drink. I still don't like this -- there are tons of opinions I'm going to have and share online, most of which have nothing to do with whether I can do my job effectively. What's next, rejecting me because of something like a recent change to "Relationship Status: Single" because I couldn't keep a girl, or because I'll be too depressed to do my job effectively?