Maybe it's just me, but I always spelled that "exp".
Then again, I'm also the type to usually spell things out, rather than simply lol stfu nub.
Ah. Now I know why -- the MMO I play has EXP clearly marked, right next to VITA, MANA, and GOLD.
Re:The more I learn about JavaScript...
on
GWT in Action
·
· Score: 1
The Mozilla Rhino Javascript Engine actually compiles the JS down to Java byte code. That wouldn't be all that special, except that the JVM then JITs that to native code. Which means that Javascript doesn't have to be slow.
How fast is it, really? Compiling down to Java bytecode doesn't necessarily make it faster.
Consider a Bash script -- for most of what people use Bash for, you're not going to get any significant speed improvement out of "compiling" it, if you could.
I think JavaScript could be very fast, but I haven't seriously looked at Rhino, so I don't know if it's actually a real improvement, or if it's just "compiling" similar to how Bash "compiles". Or if it's an improvement, but still slower than other languages.
Not likely - the bar would be considerably higher than merely whether the patent was invalid. You would have to show, for example, that the patent was filed fraudulently or in bad faith; or that the suit was brought even though the plaintiffs knew that they had no reasonable hope of prevailing on the merits.
Still doesn't sound hard. You demonstrate that the plaintiffs had no other business model than patent trolling. You bring in experts in the industry, you show them the patent, and let the court watch them laugh until they cry... And then you show the prior art, not in some obscure thing that a patent clerk might have missed, but in common use, a simple Google search away for anyone who'd bothered to look -- or common knowledge for anyone who understands how email works.
There are around 60 separate claims in the patent, and all that's necessary is for one or two of them to be found to be novel in order for the patent to hold up at least partially.
I forget who said it first, but...
Why is it that you can define a patent very, very narrowly to avoid stepping on prior art, and then turn around and sue people for infringing on the vaguest, broadest possible interpretation of said patent?
I certainly share the frustration but once the software patent genie is out of the bottle, you're stuck with trying to knock down each patent and each claim within each patent much like the whack-a-mole games at the fair.
I would hope that there's a legal firm, somewhere, bold enough to take this on. One or two risky cases to set a precedent, then make it standard operating procedure to fight and countersue patent trolls.
Which means you can find out who calls your method pretty easily in eclipse. Try that with your javascript editor.
I must be missing what, exactly, you're trying to do here -- it's really easy to just search for a method name, for one thing.
If it's more complicated than that, I suppose you could examine the call stack from a debugger...
Coding in Javascript becomes a pain, you don't want to split up your files since that creates browser lag so you usually have one large file with all the Javascript classes.
Ok, first off, it seems like it would be really easy to load a bunch of scripts from a bunch of separate files. Just load a bit of Javascript up front that can take care of loading the rest of it on-demand. Hell, even load it with XMLHttpRequest and you can do it asynchronously -- at that point, the only way you have browser lag is if the user limited their number of connections.
Second, you apparently haven't discovered the wonderful Javascript compiler known as 'cat'. Or, if you want to be really adventurous, use a real "JavaScript Compiler" to combine the files and strip out the whitespace.
Third, it seems like your main argument against one file is that you like package names. Fine, throw em all in one file and build packages. The only reason one file gets to be a problem is if you're doing a lot of collaboration, and you need people working on different aspects of the project at once.
With GWT, just code all your java classes in separate files, with their own package names, GWT will take care of streaming the javascript intelligently.
Not very intelligent if it just pipes it all back in the same response. Really, lots of small files makes sense, for a lot of reasons -- you want everything to be cacheable, but you don't want any one client to have to download any more code than is needed.
But if that doesn't make sense, it's usually not a big deal to just throw everything in one file, even if you do it with 'cat', then gzip it -- it ends up being really tiny. Just irrelevantly tiny.
Re:The more I learn about JavaScript...
on
GWT in Action
·
· Score: 1
The simple fact is that it lacks some very basic modern OO language constructs such as interfaces
Not needed in a dynamically-typed language.
abstract classes
See above.
and threads
That's a property of the interpreter, not the language.
And by the time you add those in, you'll just have reinvented Java.
Really? So Java has anonymous subroutines, anonymous classes, classes/objects/functions/methods all as first-class variables, closures, dynamic typing, the eval() keyword, and the ability to add stuff to existing classes without subclassing?
...Need I go on?
Go read Douglas Crockford. Until then, you don't really know Javascript.
Re:The more I learn about JavaScript...
on
GWT in Action
·
· Score: 1
Um, you understand that GWT is not a language, it is a framework, right? Java is the language. And JavaScript is most CERTAINLY not more powerful than Java.
Really? What features are missing from Javascript that are in Java?
Because I could come up with a very long list of things that are nowhere to be found in Java, but are actually cleverly hid in Javascript.
Don't give in to the temptation because it would make you look quite foolish.
Only because it's been done already.
However, you just claimed Java is more powerful than Javascript, and I think that makes you look quite foolish. Javascript is lisp in C's clothing, much like Ruby -- and I think most of us can agree that Lisp is MUCH more powerful than Java will ever be.
Like many things, this can be hacked to be better in Javascript. Crockford's idea of a "superconstructor" is actually really useful, I think.
Re:The more I learn about JavaScript...
on
GWT in Action
·
· Score: 1
In JavaScript you find all errors at runtime, in Java you can catch many at compile time.
So what?
Most of the errors I catch at compile time in languages like Java are things that would not be errors in languages like Javascript. And in any case, what is so magically better about compile time?
Differences in browsers object models makes it counter-intuitive to write cross-browser JavaScript code, GWT can take care of these differences for you.
So can Dojo, the Yahoo UI library, and so on. I understand the need to have a toolkit, I just don't understand why you'd want a toolkit that forces you to use Java code instead of Javascript.
Re:The more I learn about JavaScript...
on
GWT in Action
·
· Score: 1
This may be more of a DOM issue than a javascript issue but I find a lot of situations where you don't get an error at all. It just doesn't do what you instructed. Sometimes execution just halts in that method and sometimes it doesn't.
You want a good debugger. Or, hell, just look at Firefox's error log -- it'll show you errors in HTML and CSS, also.
Also, don't get me started on javascript's this variable which is a complete joke.
It's completely easy to work around, also. Would you care to explain what about it is a problem?
Re:The more I learn about JavaScript...
on
GWT in Action
·
· Score: 1
It is full of unexpected quirks, and compared to other dynamic languages such as Python or Ruby it is hell to work with.
I'll bet you just don't know how to work with it. Go read Douglas Crockford.
There are a few quirks, here and there, that I really don't like, but they are things I can live with. As the sibling asked, could you be specific?
The power of GWT and similar frameworks is that they provide ready to use components which render similarly across all browsers, making it feasible to prepare a fully functional and nicely lookung web UI in a matter of minutes.
In other words, just like Dojo, Mochikit, Yahoo Web Toolkit, and other JavaScript libraries, only instead of using a nice, clean, powerful language (Javascript), you're forced to use a verbose, restrictive, backwards language (Java), which just compiles to Javascript anyway, resulting in bigger and slower Javascript code.
In theory, any language could have a sufficiently good compiler to make it as fast as any other language.
In practice, the more powerful the language is, and the simpler a naive interpreter is, the harder it can be to make a good compiler.
Consider JavaScript -- you have to carry around enough baggage to be able to support random 'eval' statements. Or Perl -- common wisdom dictates creating classes as a hash table, because there's no such thing as actual object members in Perl. Technically, you could make a Perl object that's as fast as, say, Ruby or Python objects, but it requires some brutal hacks -- and since OO in Perl is already a brutal hack (though a bit beautiful, too), you know this is going to hurt.
Ruby must store and lookup all function and variable names at runtime as strings, in order to support things like the default method -- which is a method that gets called when it can't find a given method, with the name of that method as a string argument.
It's theoretically possible to make these languages faster, but in practice, I've found that things like Jython usually end up supporting a subset of the language and not providing much of a speed boost. Of course, that's mostly just a "feeling level", so I could be way off here...
I think that Javascript, Ruby, and friends could all be made faster than C. It's just going to take a kind of JIT compiler that I don't think anyone's seen before.
First of all, Windows doesn't claim to boot as a LiveCD. Ubuntu does.
So you refuse to use Ubuntu because it claims to have a feature, and then doesn't. Yet you continue to use an OS that doesn't have that feature, and never claimed to.
In other words, you're more concerned about truth in advertising than you are about actually getting a solid product. Never mind how little work you've actually put into trying to make it work.
Second, I expect any quality OS to work out of the box.
Better ditch Windows, then.
On just about every bit of hardware I've ever had, I have to download drivers for Windows, at the very least, to make it usable. The only exception is when it comes preloaded -- in which case, you don't have the right to bitch about Linux until you buy a Dell with Ubuntu preloaded.
I mean, there are plenty of things to hate about PHP, and even object-oriented PHP, but you can no longer complain that it doesn't have namespaces.
And Javascript is just far too flexible not to let you hack together namespaces on your own. Watch this (sorry about the lack of indentations; stupid Slashdot):
var mynamespace = function() {
var privateNSvariable = 'foo';
function privateNSfunction() {... }
var that = {
publicNSfunction: function() {
I can access privateNSvariable or privateNSfunction(), and I can also do that.publicNSfunction().
},
publicNSvariable: 'foo'
};
return that;
}();// call the anonymous function. mynamespace is a singleton object, not a class.
// Now we can call it like so:
mynamespace.publicNSfunction(); // Or do things like this:
someHandler.onSomeEvent = mynamespace.publicNSfunction; // If we're writing a library, and people don't like our naming convention:
var yournamespace = mynamespace;
yournamespace.publicNSfunction();
I highly recommend reading Douglas Crockford if you don't already know about tricks like this. From what I can tell, he's pretty much written the book on best practices in Javascript.
Javascript is at least as powerful as Ruby, if not more so, and the syntax feels a lot cleaner. But it has been awhile since I had to do any Ruby, too.
It's actually not braindead. It makes a lot of sense, when you understand in more detail how javascript works...
But look up Douglas Crockford. He had one way of solving this: var that = this. Since Javascript supports closures, you can then refer to that, even in nested functions in which "this" gets overwritten.
I had to deal with the fact that browsers do not implement things consistently. In particular, IE seems to do things differently than every other browser. The idea of GWT is to do all the hard browser bug workarounds and compatibility work for you, so that you write some code in Java and poof!
In other words, it does something like Dojo, Yahoo Web Toolkit, and so on, only in Java instead of Javascript. And Java is, without question, a more restrictive and less powerful language than Javascript.
Re:The more I learn about JavaScript...
on
GWT in Action
·
· Score: 1
Care to elaborate on what sucked about it?
I know, for one thing, that JavaScript started out as a horrible little language, and within a year or so, it became a beautiful little language. I imagine that we could do better, were the same thing attempted today.
First of all, Windows doesn't boot as a LiveCD. Or maybe Vista does, but last I checked, XP does, in fact, start you off with a textual install. Ubuntu's textual install is basically the same as its graphical one, it's just not as pretty -- there's no "slogging" at all.
Second, there are most likely ways to make it work, even in graphical mode. You, apparently, didn't even try. Were it any other product, would you have given up on it that easily? I wouldn't.
In Ubuntu, as a matter of course, I go enable the Universe and Multiverse repositories, which is now a point-and-click operation. That done, codecs are just stupidly easy: apt-get install vlc.
And done. All your media codecs are now enabled.
It's not automatic, so it could be better. But I find it very odd that people even bring up codec support anymore -- after I install mplayer and vlc, I have codecs for 99% of the content out there, all open. People still talk about win32codecs, and the hassle of making them work on amd64, but I know of about one thing that isn't supported without those codecs, and I doubt it will take very long.
When I say we're installing "Ubuntu Feisty", sure, it sounds... different. But it doesn't actually sound stupid, like it would if I said "Feisty Fawn".
Same with Gusty. In fact, Hardy works even better.
I also tend to like names that don't actually offend programmers. Windows XP seems to me a deliberate attempt to steal the XP acronym -- and they have. XP used to stand for "Xtreme Programming", which is actually a very useful concept, and one which might have avoided some of the dumber problems Windows has had.
And they do this all the time..NET, Word, Office, Internet Explorer, etc. They choose names that are so generic that you get most people confusing them with something else almost instantly. It's difficult to talk about a "Word processor", because most people hear that and think MS Word. It took Firefox long enough, and we still have to deal with people who think the Internet is Internet Explorer.
So now we have names like "Ubuntu" and "Hardy", and I think they work well -- they're distinctive, and they don't actually sound like anything else in the same field.
The more I learn about JavaScript...
on
GWT in Action
·
· Score: 4, Insightful
The more I learn about JavaScript, the more I like it as a language.
I'm not really sure I see the point of GWT, given that JavaScript is actually a more powerful language at this point. I'm almost tempted to suggest that someone build a webserver platform around a JavaScript interpreter.
Well, almost. The problem with JavaScript is that it's horribly slow to execute. But then, you still have that problem, even if it's JavaScript generated from Java code.
This would be difficult to prove if the USPTO had indeed granted a patent and you had in fact infringed on the patent, leaving open only the question of the validity of said patent.
Wouldn't that question be closed by the time you won the first case -- their suit against you?
Why is it so hard to prove these obvious patent trolls? Slashdot just provided reams of prior art, isn't that enough?
Can you afford to pay your attorneys plus legal fees for the year or more that the lawsuit drags out?
I'd borrow what I need, or find a lawyer willing to work pro bono.
What if the troll gets an injunction against you selling your product that they say violates their patent?
Ah, that would be a problem. Yet I still see far too many companies pussying out at this point.
Consider Blackberry -- they practically owned a monopoly on the mobile email market. An obvious patent troll sued them, and tried to get an injunction. Blackberry settled.
Can you imagine what would happen if they had decided to fight it? Just leave a friendly little note in everyone's inbox, before the injunction takes effect, telling everyone what's about to happen, and posting contact information for the troll's lawyers and the judge.
They'd have an instant army of Crackberry addicts writing to tell the troll exactly what they thought. They might even get quite a lot of people donating money to the cause.
Going to trial is always a crapshoot even if you're 100% sure that you have a solid case. Nasty surprises happen (jury goofs up, judge makes a bad decision -- can your cashflow survive the appeal process? -- etc).
It should be just as bad, if not worse, if you don't have any case at all. It should be more dangerous for the trolls here.
But plenty of people see discretion as the better part of valor. (As witness the amount of crap people submit to before boarding a plane these days.)
Generally, even for international flights, it's only an inconvenience. They're not actually taking money out of my pockets.
Once the startup matures into a certain size, they'll find that Linux just ain't cutting it no more (support, stability, scalability) and they need to move up the computer food chain.
I suppose it's possible, but it seems unlikely. Linux certainly scales well enough to be used in Hollywood renderfarms, and I don't see anything close to that being used by any startup, anywhere.
I would not be surprised if both Solaris and AIX provide a virtually seamless migration from Linux, perhaps even binary compatibility.
I believe Solaris does offer Linux binary support -- as does BSD.
But that's in no way proof of some sinister plan -- it's just proof of neither platform particularly wanting to commit suicide just yet.
Shit, Sun is even now making an open source, entry level version of Solaris; perhaps as a reaction to GPLv3? Basically, they are hoping that startups on a shoe string budget will take free (Linux) over quick & easy (Microsoft) and grow up into paying customers.
You know, Linux is quick and easy for the types of applications that make it popular.
And OpenSolaris? What the fuck makes you think it's "entry level"? It's got everything the proprietary Solaris did. The only difference at this point is, if you actually buy Solaris, you get support.
Microsoft wants us cheapsake startups who pick free (Linux) to use their tools (quick & easy) and when we grow up, we move onto their platform (Windows Server) instead of IBM or Sun.
That would be because Microsoft doesn't provide a cheap platform that scales well. Linux does.
Once again, I'm not convinced that every startup who started with Linux eventually has to move to Sun or IBM's OSes. And if they move to Sun, so what? It's open, they don't have to pay a dime to Sun if they don't want to. I've heard of people using Solaris only for ZFS -- literally, as in, they build a ZFS cluster, then share it over NFS to some Linux servers which do the actual work.
GPLv3 makes it very hard for these companies to play this game.
Even if you're right about that plan, explain how GPLv3 makes it any harder. I'll bet you just don't understand how it works.
It also makes it hard for companies doing embedded systems too.
Here, you're right, but only to a point -- not all embedded systems need to have proprietary components. I'd have thought OpenMoko would've proven that by now.
But it still leaves a few very obvious choices:
Use only GPLv2 stuff (not hard; the kernel would find it very difficult to go GPLv3, even if Linus loved it)
Use BSD stuff.
Buy or license another system entirely -- QNX, for example.
Plus, the "leader" of the GPL world is clearly becoming a destabilizing concern.
Good thing you put him in quotes.
He's not my leader. He can't, in fact, do anything to me other than make GPLv4 do something I don't want it to do, and I'm free to license my software GPLv3-only, and only make the decision to GPLv4 if I like that license. Same with people who have GPLv2 software today -- even if they included the "or later" clause, the project as a whole can stay GPLv2 for as long as they like, and simply refuse any GPLv3 contributions.
My ECON101-sense predicts that Linux is on it's way out as it looses all it's corporate developers.
My faith in common sense predicts that, if SCO didn't scare them off already, RMS won't be very intimidating either.
The corporate sponsors didn't show up for a long time -- I believe it took several years. And they certainly didn't notice until Linux was in a usable form.
That's the essential difference -- 1991 was when Linus released a working kernel, all by himself. HURD had absolutely nothing usable at that point. Neither had any corporate backing, and in fact, Linus expected HURD to replace Linux whenever it was done, but as it turns out, microkernels are much harder to write than monolithic kernels, and developers do tend to flock to the more popular open projects.
I think that is telling of the roles of free software vs. corporate/whatever-you-want-to-call-it software.
Only if you have an agenda.
If you were trying to make a case of Linux vs BSD, it would be telling. Linux has more developers simply because it was the first on the scene. BSD was still closed at that point. So, it does say something about a massive open community versus a few proprietary developers, and also about why if you're going to go open source, you should release early and often.
Slashdot Mirror
Maybe it's just me, but I always spelled that "exp".
Then again, I'm also the type to usually spell things out, rather than simply lol stfu nub.
Ah. Now I know why -- the MMO I play has EXP clearly marked, right next to VITA, MANA, and GOLD.
How fast is it, really? Compiling down to Java bytecode doesn't necessarily make it faster.
Consider a Bash script -- for most of what people use Bash for, you're not going to get any significant speed improvement out of "compiling" it, if you could.
I think JavaScript could be very fast, but I haven't seriously looked at Rhino, so I don't know if it's actually a real improvement, or if it's just "compiling" similar to how Bash "compiles". Or if it's an improvement, but still slower than other languages.
Still doesn't sound hard. You demonstrate that the plaintiffs had no other business model than patent trolling. You bring in experts in the industry, you show them the patent, and let the court watch them laugh until they cry... And then you show the prior art, not in some obscure thing that a patent clerk might have missed, but in common use, a simple Google search away for anyone who'd bothered to look -- or common knowledge for anyone who understands how email works.
I forget who said it first, but...
Why is it that you can define a patent very, very narrowly to avoid stepping on prior art, and then turn around and sue people for infringing on the vaguest, broadest possible interpretation of said patent?
I would hope that there's a legal firm, somewhere, bold enough to take this on. One or two risky cases to set a precedent, then make it standard operating procedure to fight and countersue patent trolls.
I must be missing what, exactly, you're trying to do here -- it's really easy to just search for a method name, for one thing.
If it's more complicated than that, I suppose you could examine the call stack from a debugger...
Ok, first off, it seems like it would be really easy to load a bunch of scripts from a bunch of separate files. Just load a bit of Javascript up front that can take care of loading the rest of it on-demand. Hell, even load it with XMLHttpRequest and you can do it asynchronously -- at that point, the only way you have browser lag is if the user limited their number of connections.
Second, you apparently haven't discovered the wonderful Javascript compiler known as 'cat'. Or, if you want to be really adventurous, use a real "JavaScript Compiler" to combine the files and strip out the whitespace.
Third, it seems like your main argument against one file is that you like package names. Fine, throw em all in one file and build packages. The only reason one file gets to be a problem is if you're doing a lot of collaboration, and you need people working on different aspects of the project at once.
Not very intelligent if it just pipes it all back in the same response. Really, lots of small files makes sense, for a lot of reasons -- you want everything to be cacheable, but you don't want any one client to have to download any more code than is needed.
But if that doesn't make sense, it's usually not a big deal to just throw everything in one file, even if you do it with 'cat', then gzip it -- it ends up being really tiny. Just irrelevantly tiny.
Oh, because i is so much better than K, J, or G.
Not needed in a dynamically-typed language.
See above.
That's a property of the interpreter, not the language.
Really? So Java has anonymous subroutines, anonymous classes, classes/objects/functions/methods all as first-class variables, closures, dynamic typing, the eval() keyword, and the ability to add stuff to existing classes without subclassing?
...Need I go on?
Go read Douglas Crockford. Until then, you don't really know Javascript.
Really? What features are missing from Javascript that are in Java?
Because I could come up with a very long list of things that are nowhere to be found in Java, but are actually cleverly hid in Javascript.
Only because it's been done already.
However, you just claimed Java is more powerful than Javascript, and I think that makes you look quite foolish. Javascript is lisp in C's clothing, much like Ruby -- and I think most of us can agree that Lisp is MUCH more powerful than Java will ever be.
Like many things, this can be hacked to be better in Javascript. Crockford's idea of a "superconstructor" is actually really useful, I think.
So what?
Most of the errors I catch at compile time in languages like Java are things that would not be errors in languages like Javascript. And in any case, what is so magically better about compile time?
So can Dojo, the Yahoo UI library, and so on. I understand the need to have a toolkit, I just don't understand why you'd want a toolkit that forces you to use Java code instead of Javascript.
You want a good debugger. Or, hell, just look at Firefox's error log -- it'll show you errors in HTML and CSS, also.
It's completely easy to work around, also. Would you care to explain what about it is a problem?
I'll bet you just don't know how to work with it. Go read Douglas Crockford.
There are a few quirks, here and there, that I really don't like, but they are things I can live with. As the sibling asked, could you be specific?
In other words, just like Dojo, Mochikit, Yahoo Web Toolkit, and other JavaScript libraries, only instead of using a nice, clean, powerful language (Javascript), you're forced to use a verbose, restrictive, backwards language (Java), which just compiles to Javascript anyway, resulting in bigger and slower Javascript code.
In theory, any language could have a sufficiently good compiler to make it as fast as any other language.
In practice, the more powerful the language is, and the simpler a naive interpreter is, the harder it can be to make a good compiler.
Consider JavaScript -- you have to carry around enough baggage to be able to support random 'eval' statements. Or Perl -- common wisdom dictates creating classes as a hash table, because there's no such thing as actual object members in Perl. Technically, you could make a Perl object that's as fast as, say, Ruby or Python objects, but it requires some brutal hacks -- and since OO in Perl is already a brutal hack (though a bit beautiful, too), you know this is going to hurt.
Ruby must store and lookup all function and variable names at runtime as strings, in order to support things like the default method -- which is a method that gets called when it can't find a given method, with the name of that method as a string argument.
It's theoretically possible to make these languages faster, but in practice, I've found that things like Jython usually end up supporting a subset of the language and not providing much of a speed boost. Of course, that's mostly just a "feeling level", so I could be way off here...
I think that Javascript, Ruby, and friends could all be made faster than C. It's just going to take a kind of JIT compiler that I don't think anyone's seen before.
So you refuse to use Ubuntu because it claims to have a feature, and then doesn't. Yet you continue to use an OS that doesn't have that feature, and never claimed to.
In other words, you're more concerned about truth in advertising than you are about actually getting a solid product. Never mind how little work you've actually put into trying to make it work.
Better ditch Windows, then.
On just about every bit of hardware I've ever had, I have to download drivers for Windows, at the very least, to make it usable. The only exception is when it comes preloaded -- in which case, you don't have the right to bitch about Linux until you buy a Dell with Ubuntu preloaded.
I mean, there are plenty of things to hate about PHP, and even object-oriented PHP, but you can no longer complain that it doesn't have namespaces.
And Javascript is just far too flexible not to let you hack together namespaces on your own. Watch this (sorry about the lack of indentations; stupid Slashdot):
I highly recommend reading Douglas Crockford if you don't already know about tricks like this. From what I can tell, he's pretty much written the book on best practices in Javascript.
Javascript is at least as powerful as Ruby, if not more so, and the syntax feels a lot cleaner. But it has been awhile since I had to do any Ruby, too.
It's actually not braindead. It makes a lot of sense, when you understand in more detail how javascript works...
But look up Douglas Crockford. He had one way of solving this: var that = this. Since Javascript supports closures, you can then refer to that, even in nested functions in which "this" gets overwritten.
In other words, it does something like Dojo, Yahoo Web Toolkit, and so on, only in Java instead of Javascript. And Java is, without question, a more restrictive and less powerful language than Javascript.
Care to elaborate on what sucked about it?
I know, for one thing, that JavaScript started out as a horrible little language, and within a year or so, it became a beautiful little language. I imagine that we could do better, were the same thing attempted today.
First of all, Windows doesn't boot as a LiveCD. Or maybe Vista does, but last I checked, XP does, in fact, start you off with a textual install. Ubuntu's textual install is basically the same as its graphical one, it's just not as pretty -- there's no "slogging" at all.
Second, there are most likely ways to make it work, even in graphical mode. You, apparently, didn't even try. Were it any other product, would you have given up on it that easily? I wouldn't.
In Ubuntu, as a matter of course, I go enable the Universe and Multiverse repositories, which is now a point-and-click operation. That done, codecs are just stupidly easy: apt-get install vlc.
And done. All your media codecs are now enabled.
It's not automatic, so it could be better. But I find it very odd that people even bring up codec support anymore -- after I install mplayer and vlc, I have codecs for 99% of the content out there, all open. People still talk about win32codecs, and the hassle of making them work on amd64, but I know of about one thing that isn't supported without those codecs, and I doubt it will take very long.
When I say we're installing "Ubuntu Feisty", sure, it sounds... different. But it doesn't actually sound stupid, like it would if I said "Feisty Fawn".
.NET, Word, Office, Internet Explorer, etc. They choose names that are so generic that you get most people confusing them with something else almost instantly. It's difficult to talk about a "Word processor", because most people hear that and think MS Word. It took Firefox long enough, and we still have to deal with people who think the Internet is Internet Explorer.
Same with Gusty. In fact, Hardy works even better.
I also tend to like names that don't actually offend programmers. Windows XP seems to me a deliberate attempt to steal the XP acronym -- and they have. XP used to stand for "Xtreme Programming", which is actually a very useful concept, and one which might have avoided some of the dumber problems Windows has had.
And they do this all the time.
So now we have names like "Ubuntu" and "Hardy", and I think they work well -- they're distinctive, and they don't actually sound like anything else in the same field.
The more I learn about JavaScript, the more I like it as a language.
I'm not really sure I see the point of GWT, given that JavaScript is actually a more powerful language at this point. I'm almost tempted to suggest that someone build a webserver platform around a JavaScript interpreter.
Well, almost. The problem with JavaScript is that it's horribly slow to execute. But then, you still have that problem, even if it's JavaScript generated from Java code.
Wouldn't that question be closed by the time you won the first case -- their suit against you?
Why is it so hard to prove these obvious patent trolls? Slashdot just provided reams of prior art, isn't that enough?
I'd borrow what I need, or find a lawyer willing to work pro bono.
Ah, that would be a problem. Yet I still see far too many companies pussying out at this point.
Consider Blackberry -- they practically owned a monopoly on the mobile email market. An obvious patent troll sued them, and tried to get an injunction. Blackberry settled.
Can you imagine what would happen if they had decided to fight it? Just leave a friendly little note in everyone's inbox, before the injunction takes effect, telling everyone what's about to happen, and posting contact information for the troll's lawyers and the judge.
They'd have an instant army of Crackberry addicts writing to tell the troll exactly what they thought. They might even get quite a lot of people donating money to the cause.
It should be just as bad, if not worse, if you don't have any case at all. It should be more dangerous for the trolls here.
Generally, even for international flights, it's only an inconvenience. They're not actually taking money out of my pockets.
I suppose it's possible, but it seems unlikely. Linux certainly scales well enough to be used in Hollywood renderfarms, and I don't see anything close to that being used by any startup, anywhere.
I believe Solaris does offer Linux binary support -- as does BSD.
But that's in no way proof of some sinister plan -- it's just proof of neither platform particularly wanting to commit suicide just yet.
You know, Linux is quick and easy for the types of applications that make it popular.
And OpenSolaris? What the fuck makes you think it's "entry level"? It's got everything the proprietary Solaris did. The only difference at this point is, if you actually buy Solaris, you get support.
That would be because Microsoft doesn't provide a cheap platform that scales well. Linux does.
Once again, I'm not convinced that every startup who started with Linux eventually has to move to Sun or IBM's OSes. And if they move to Sun, so what? It's open, they don't have to pay a dime to Sun if they don't want to. I've heard of people using Solaris only for ZFS -- literally, as in, they build a ZFS cluster, then share it over NFS to some Linux servers which do the actual work.
Even if you're right about that plan, explain how GPLv3 makes it any harder. I'll bet you just don't understand how it works.
Here, you're right, but only to a point -- not all embedded systems need to have proprietary components. I'd have thought OpenMoko would've proven that by now.
But it still leaves a few very obvious choices:
Good thing you put him in quotes.
He's not my leader. He can't, in fact, do anything to me other than make GPLv4 do something I don't want it to do, and I'm free to license my software GPLv3-only, and only make the decision to GPLv4 if I like that license. Same with people who have GPLv2 software today -- even if they included the "or later" clause, the project as a whole can stay GPLv2 for as long as they like, and simply refuse any GPLv3 contributions.
My faith in common sense predicts that, if SCO didn't scare them off already, RMS won't be very intimidating either.
The corporate sponsors didn't show up for a long time -- I believe it took several years. And they certainly didn't notice until Linux was in a usable form.
That's the essential difference -- 1991 was when Linus released a working kernel, all by himself. HURD had absolutely nothing usable at that point. Neither had any corporate backing, and in fact, Linus expected HURD to replace Linux whenever it was done, but as it turns out, microkernels are much harder to write than monolithic kernels, and developers do tend to flock to the more popular open projects.
Only if you have an agenda.
If you were trying to make a case of Linux vs BSD, it would be telling. Linux has more developers simply because it was the first on the scene. BSD was still closed at that point. So, it does say something about a massive open community versus a few proprietary developers, and also about why if you're going to go open source, you should release early and often.