Sadly, with these sorts of shifts human nature is to moan about the shift to Linux. In the organisations which make the switch, the thousands of non-techies affected will blame every new problem they have on the switch to Linux. In every other department that has not switched, nobody will complain because they are already used to the problems they have with Windows and habitually work around them. And the new Linux-users won't experience the positive side of the switch to Linux as greatly as us techies because they are already used to the Microsoft way.
With any change, there is a pain, and that pain is normally blamed on the technology you're changing to.
Of course since the first line of the rules includes the statement functional programming has taken over the world and so humans live in an almost unimaginable luxury, it's hardly suprising to find that the competition problem and rules do indeed suit a functional programming solution, and lo-and-behold the functional programming languages do rather well...
Except that most people don't actually like Steam. It has usability nasties like forcing patches even for single player (guess I'll not be playing this today after all then), making it very slow to start games (first you have to wait for steam to start... login... check for updates... check the available games list... then you can think about starting your game), foisting advertising for new products on the user (in Steam Update News and the Coming Soon), and of course placing a technical barrier to reselling a game second hand even though the game's EULA permits it.
Valve don't care to fix these deficiencies for their own business reasons around Half-Life 2, but the upshot is I know very few people who wouldn't rather have a good ol' CD/DVD instead.
If EA wanted an online distribution and patch mechanism, they'd do much better to write a proper one rather than rely on Steam.
Watson brings a valuable contribution to the table and with proper utilization his proposed linguistic paradigm shift can be leveraged to provide a significant value-add to the interpersonal communication process...
3) Each copy takes TWO context switches - one to switch into the kernel to copy the memory across ports, another back out to the called program. This means that even the simplest "system calls" are twice as slow as under a monokernel, AT BEST.
Ahem, the point the poster was making was about modern desktop computers going multicore, in which case you cannot discount the possibility that the message will be going from an OS process active on one core to an OS process active on another core. This can potentially involve zero context switches. So "AT BEST" would not be twice as slow...
There is a compelling reason for some VM functionality to become part of the operating system. For a long time, memory management [in terms of making sure one app cannot tread on another app's memory even if it is badly written] has been a function of the OS. Providing garbage collection to ensure that one process cannot expend available memory with leaks (affecting the performance of other processes) is a sensible extension of this.
Code management probably should be a facility in modern desktop and server operating systems. (But perhaps not small embedded systems). At that stage it makes sense for your distributed binary to be compiled to code for the VM/OS rather than compiled to the VM/OS+CPU combination. The VM, either through compilation at install or JIT compilation can then optimise it for the CPU (hello Gentoo-like optimisation on downloaded packages!).
Whether Linux should provide that with Mono or Java is an open question. Personally, I would prefer Java [for the selfish reason that I know Java very well], but "both" is probably the right answer. This gives support for both sets of programmers, and some protection against one of the technology-patenters going rampant...
I thought that Mos Def nailed Ford Prefect in about ten seconds.
Ah, I couldn't disagree more. Mos Def was a very good actor, but misinterpreted the purpose of his role. He played "alienness" when much of the humour for the early part of the story only works if Ford is a character Arthur thought he could relate to. Mos Def's Ford was so alien as to be unintelligible, killing the Arthur-Ford dynamic and making the beginning of the movie not funny.
Much of the later part of the movie picked up and was funny, including the changes they put in, but those first impressions dented the movie as a whole.
A) This all fails the reasonable expectation test. It's not a contract if one of the parties could not reasonably have known what they were agreeing to. Or some technical interpretation of it. (The "reasonable person" using a font is not a computer expert, but an average joe with a wordprocessor)
B) A huge difference between this and modifying GPL code is that it is impossible to argue that a document is a derivative work of the font it was printed in...from A and B we can conclude...
C) If this ever went to court [incredibly unlikely], the result would be "oh, ok I'll substitute a different font" not "suddenly all my documents are GPL". So the GPL isn't met and nothing else gives a license to use the font - that just means the suee'd have to stop using the font, not that the document would magically become GPL'd. Chances of damages in this kind of ridiculous logic-chopping of how fonts are implemented in typesetting documents: not a lot.
And can you honestly see the copyright owner of a font chasing document writers? (After all, the person launching the suit has to have an "interest" in the case - they can't just be a bystander making mischief or the courts won't hear it).
Hmmm, "but what constitutes distribution?" If a contractor does work for a client, does that constitute distribution (it's going from one legal entity to another)? What about between divisions of a company or between government departments? What about third-party backups (disaster recovery) of a corporation's filing system - that's certainly the code leaving the building and going to another firm. And if your own use is something that necessarily involves distribution (say, a peer-to-peer client) that's a bit sticky. No, I'm not at all convinced that the "only if it's for distribution" get-out is much of a help.
And the awkward GPL clause often fails to open up code -- we have the silly situation where if you run a webservice you don't need to reveal your changes to GPL'ed code (the code never leaves the server), but if you write the same thing to do the processing in the client (the code leaving the server), suddenly you do.
And worse, we have the mess where Sun have difficulty putting Java code [their own free-as-in-beer product] into OpenOffice.org [which they fund] because suddenly OpenOffice.org wouldn't be GPL-compatible. Sun can't GPL a JRE because MS would pounce, and nobody else is willing to fund a GPL'ed one properly.
Are you mad - mixing code and linking code are particularly important kinds of use!
Especially when some of your major products are programming languages, application servers, and operating systems and their components, but even in OpenOffice.org there have been complaints about including Java (because it could make it not-GPL-compatible) and that's something mostly funded and developed by Sun themselves!
But of course Sun aren't using anybody else's code. Their problem is that GPL customers aren't being allowed to use Sun's own code as they'd like to because it isn't deemed GPL-compatible.
Much as I personally do quite like the GPL (and ideed I'm developing lots of new GPL code), I do sometimes feel it sounds strangely parallel to a big company (say, Microsoft) saying "you may only use other Microsoft-approved products with this software". And we slap MS heavily for that sort of talk. And yet we actively approve of the GPL community shutting out non-GPL community products far more explicitly.
I think some people here are missing the point a bit.
Sun's planned "how to get straight again" is to open up their software most of the way, but they can't free it completely or their bigger competitors (ie MS) could wrench it off them immediately by forking it and throwing more money at the fork than Sun can throw at the original. The GPL has a "give-back-to-the-community" clause but not a "be-fair-to-the-original-author" clause. A GPL with some kind of limited non-compete clause to prevent direct competition of forks with the original might have been more palatable to them.
Meanwhile, the big completely closed IP players have been relatively unharmed by the GPL. Microsoft still ship XP with almost every new machine, and have a lovely income from Office despite the rise of OpenOffice.org. They are biting their fingernails a bit about the future, but so far profits are fine. Oracle don't seem to be stressing to much either. Apple (who although they have some open source code at the base have some very closed source code making up the rest of it) seem to be bounding along too.
The slightly-open-source firms get hit much harder by the GPL (and flamed with more venom on slashdot too) than the totally-closed-source firms.
And if Sun went splat, everyone on slashdot would be dancing for joy... and wondering why improvements to OpenOffice.org were suddenly taking so very very long to happen (curse those developers, just because nobody's paying their wages them any more, why won't they work?).
Write-once-run-anywhere is actually rather attractive even with it being not quite true across GUIs and operating systems:
If you distribute bytecode specialised to the OS / desktop environment, you have around 2 to 5 different versions to distribute (there are 2 to 5 operating systems most user applications would particularly want to support)
If you distribute native binaries, then you have 2-5 OS / environments times 3 or more processors (possibly plus optional extensions.)
If you distribute sourcecode, you're back at one version per OS, but users really don't like the idea of the thing needing to be compiled (which can be lengthy - eg OpenOffice.org)
Distributing bytecode suddenly looks attractive. And you can theoretically get the gentoo-like advantages of it being optimised for your system.
Brave prediction: Within 5 years, users will generally expect the VM to be "always available" in the OS, rather than needing to specially start up for an application - ie, bytecode will be a "native" (natural) langauge for the OS.
Brave prediction 2: there's going to be a battle between Java and Mono for which one is going to be natural for Linux. (Mono looks like winning, but when it starts to get very popular, watch Sun change its tune and suddenly want to push a GPL'ed Java VM into Linux)
From the community's perspective, the Sun JVM tends to move a bit faster than the others, bringing in new features. Having a big industry name behind it makes it corporately more trusted. And linux may get the chance to integrate the JVM a bit more - so that for instance 'ps' might tell you a bit more about the java process than just that it's 'java'. Which java program is it? Tomcat? Eclipse? If linux can support running Java bytecode more smoothly and naturally than other platforms, that's yet another big insentive for Java-focussed corporations to migrate to it.
From Sun's perspective, there is a competition between Java and Mono to become "the way" of doing managed code on Linux. Java has the advantage of a lot of programmers who know it, but the disadvantage that many people seem to think Java GUIs have to be in Swing, and Java apps not meshing completely with the native environment. (And Mono has a linux company's weight behind it). If Mono were to win that fight, and.Net bytecode became standard on both Windows and Linux, then Java's "write once run anywhere" aim would largely have been trumped.
You don't need to touch the DOM at all if you do the rendering in Java. The controls available to you that way are much richer than the standard HTML controls too.
This is true to an extent, but then you're really just using the browser as a delivery mechanism for a dedicated client app. And if you have any hypertext in your document, that is more easily rendered and integrated into the user's environment in a browser / browser pane than in a Swing HTML component.
There are some advantages to keeping it in the browser - use of third party plugins, CSS on the HTML is particularly helpful for vision impaired users (who have normally already got their browser set up with a personalised CSS with larger fonts, etc), shorter loading times for the page, and generally the fact that the browser is what the visitor is used to (and has come to your site with) makes a big difference.
They each (browser, Java) have their uses, and some better work to tie them together would be useful. A XUL that had easier access to Java would be handy. So I could just say "here's the tag, here's the class to render it". Java tag libraries on the client side. As would merging the virtual machine worlds of the browser and Java so hopping between JavaScript and Java calls wouldn't be so awkward.
I bet someone else will post the exact same thing, but instead they will replace Java with Flash...
I think the point is that you don't need to insert an object or rely on a 3rd party enviroment. You can do it in Javascript.
Also, the reason this is so very cool is that it doesn't tie your applicaiton into a backend of any kind, you can scale your backend as long as it spits out XML. I think this is the reason so many of the big companies are going to it. They require a bit more flexibility on that end.
In my work on the Intelligent Book project (intro text, example screenshot), I've been doing just this sort of thing using a Java applet for the communication and then modifying the page for 18 months or so (including returning XML). Fundamentally the advantage to using JavaScript over Java if you can is that the calls into the browser DOM from Java go through JavaScript anyway (whether explicitly in your code, or internally in the Sun code) and that Java-to-JavaScript bridge has been the source of interesting bits of flakiness, and there is still a delay on the first JavaScript-to-Java call in Firefox and Mozilla.
If you want to support graphical components (eg graphing tools, maths editor), you can nest XML-rendering applets on the page. This is what I do - see a couple of papers on my website (apologies for the dire need to update it). Of course, then you are stuck with having to do the Java-to-JavaScript thing at some point.
The fact that it is becoming a popular thing to do is great news - the more of us there are taking advantage of this capability, the more impetus there is for the browser authors to make sure it can be supported in a clean and quirk-free way.
Will Billingsley PhD student Intelligent Book project.
I'm sorry to say this, but that isn't a good thing.
If a webmaster starts to shift his focus from IE to FireFox/Mozilla, he is just being as bad as all the other webmasters who give preference to IE users.
Actually, computer science researchers, such as those at the University of Southampton who developed this, don't have a particular requirement (moral or actual) to develop "for all platforms". They are interested in research - showing something can be done, and publishing details on it when they have shown it can be done, not waiting til they have also ported it to all proprietary platforms.
Is it illegal? Probably not. It is an EULA, ergo it is not legally binding, but illegal? Overstatement.
Not an overstatement at all. It can very easily be illegal to mislead your customers into believing they do not have rights that they do have under their nation's laws. That's one reason why most shop refund policies say things like "this does not affect your statutary rights", and take great care actually not to affect your statutary rights!
In this case, the legality is even more easily called into question: Steam uses technical measures to enforce the EULA, including some very unexpected clauses. For example, it is impossible to sell Half-Life 2 second hand at all when you're done with it (the second purchaser *has* to pay Valve a fee to get the game "reactivated", and cannot then resell it again it all). These restrictions are generally not acceptable in consumer purchases, where the right to sell second hand is normally protected, but Valve attempts to legally justify them using the Steam EULA. The restrictions not declared on the box.
In other words, it is a technical enforcement of a clause the consumer could not reasonably have expected they were "agreeing to" at the time they bought the product in the shop.
The problem is, if he or she does that, then suddenly there is GPL code that can't be used with other GPL code because they have the wrong versions. That kind of version incompatibility would be a bit of a killer for viable free software.
Which is my most code has the "(at your option) any later version" note.
Remember clause 9 of the current GPL -- most GPL code either specifies "GPL version #.# or any later version", or does not specify a version at all in which case Clause 9 permits the user to choose any GPL version that has ever been published.
For existing code, a subsequent GPL revision can effectively only liberalise the usage rights - the user is free to choose to stick to the prior version. But oddly, perhaps this could could end up including "the right to restrict the use of modifications further" because of licence version creep. (See later in post for an example).
This is something that might be concerning to a whole raft of programmers who have released code under the GPL. Are Richard and Eben about to decide to "grant" rights to those pieces of code that the author never intended to grant? Or restrict rights, through version creep, they never intended to restrict?
Example 1 (version creep)...
Say I write package A, and release it under GPL 2. You are allowed to modify it and use it as a web service without being required to release your changes. But then a hypothetical GPL 3 is published which requires the publication of modified webservice code. No problem, you can still use GPL version 2. But then, someone integrates my package and some GPL version 3 code. The result has to be a GPL 3 package. But that means it is a modified version of my code which can no longer be modified for webservices without requiring the source code be published. It is a version of my GPL 2 code that does not have the full GPL 2 rights I released it under. Result: "That's not free!" I cry, and get very grumpy...
For anything other than extremely small changes to the GPL, version interoperability could get messy.
Example 2 (granting unintended rights - a bit of an extreme example)
A hypothetical GPL 4 is published which somehow allows integrating with non-Free code. A lot of people's business model (GPL is free, non-Free licence costs) gets instantly scuppered. The result is probably that the hapless company will attempt to invalidate all their GPL licences, claiming that they could not reasonably have expected the FSF to make this clause change, and therefore the modified licence is not valid. Result: lawyers at high noon.
For anything other than extremely small changes to the GPL, companies who have built their business around the GPL might start kicking up a stink...
The only things I would be concerned about are ensuring that of the 30000 banned, all of them are actually banned for valid reasons and not due to any error. Valve has said they wont reactivate these accounts, so once it's gone, it's gone.
Hmm, I wonder how much of that is true, and how much is bluster. In the UK I've heard about some small retailers that have claimed that they will not accept returns of anything sold no matter what - but if the customer gets in touch with Trading Standards and then tries again, the shop suddenly gives them a refund no trouble at all.
Steam, while it is a useful innovation, looks like it might have few snags with UK consumer trading law at the best of times. Valve making unilateral and unappealable decisions to refuse to supply product for which consideration has already been received sounds at odds with consumer laws, regardless of what the EULA might say. (Especially since the bulk of the "innocent" people caught are likely to be under 18 with a store-bought copy).
I wonder if Valve will actually quietly refund / reactivate accounts where the owner gets in touch with the proper consumer body.
Except there is no Fair Use clause in Aussie copyright law. So they can't do this legally in Austrialia, hence why the submitter said this.
Yes, there is a Fair Use clause in Australian copyright law, it just isn't identical to the one in the US. (and unfortunately while it does cover photocopying parts of books, it doesn't cover copying music from one medium to another).
However, there is also case law, some of which may be helpful. One example was when an Australian cable network was sued by a free-to-air network because the cable network was rebroadcasting the free-to-air signal (including ads) over cable without permission. Seems like an obvious breach of copyright law - copying the entire network content. But the cable network won, partly on the grounds that they were rebroadcasting the signal to people who were already entitled to receive it, and the free-to-air network couldn't actually prove it had caused any financial loss to them.
As such, a law suit to stop someone copying their CDs to their own media player might prove difficult, despite it not being covered by fair use.
I don't actually see how they are managing to put "unstructured" into this patent at all anyway - surely by dint of the fact that the input is into a computer that input obtains some form of encoding, and hence, structure. Whether the input is a sequence of pen-strokes, recording the user speaking, or listening to an unbounded sequence of button presses, it still has some (albeit loose) structure.
And it also seems like Microsoft shooting their own patent in the foot. It looks as though a litigee could simply stand up and say "No, No, the input in our product has structure. The structure is a time-ordered sequence of user input events". And despite this sounding bizarre, surely they could even point to the object in their code that represents the input, thus showing its structure.
Your worth (at least in $ terms) is defined by the market.
That's a mantra we are often told, and it makes everyone feel humble, but actually it isn't quite true. Your worth is not your cost, it is what you bring to the company set against your cost. A lot of companies have employees (including key software architects, etc) that they would, if push came to shove, be willing to pay rather more than what market forces dictate because if the employee left it would mean much more loss to the company than just the cost of hiring a new guy.
Slashdot Mirror
Sadly, with these sorts of shifts human nature is to moan about the shift to Linux. In the organisations which make the switch, the thousands of non-techies affected will blame every new problem they have on the switch to Linux. In every other department that has not switched, nobody will complain because they are already used to the problems they have with Windows and habitually work around them. And the new Linux-users won't experience the positive side of the switch to Linux as greatly as us techies because they are already used to the Microsoft way.
With any change, there is a pain, and that pain is normally blamed on the technology you're changing to.
Of course since the first line of the rules includes the statement functional programming has taken over the world and so humans live in an almost unimaginable luxury, it's hardly suprising to find that the competition problem and rules do indeed suit a functional programming solution, and lo-and-behold the functional programming languages do rather well...
Except that most people don't actually like Steam. It has usability nasties like forcing patches even for single player (guess I'll not be playing this today after all then), making it very slow to start games (first you have to wait for steam to start... login... check for updates... check the available games list... then you can think about starting your game), foisting advertising for new products on the user (in Steam Update News and the Coming Soon), and of course placing a technical barrier to reselling a game second hand even though the game's EULA permits it.
Valve don't care to fix these deficiencies for their own business reasons around Half-Life 2, but the upshot is I know very few people who wouldn't rather have a good ol' CD/DVD instead.
If EA wanted an online distribution and patch mechanism, they'd do much better to write a proper one rather than rely on Steam.
Watson brings a valuable contribution to the table and with proper utilization his proposed linguistic paradigm shift can be leveraged to provide a significant value-add to the interpersonal communication process...
Ahem, the point the poster was making was about modern desktop computers going multicore, in which case you cannot discount the possibility that the message will be going from an OS process active on one core to an OS process active on another core. This can potentially involve zero context switches. So "AT BEST" would not be twice as slow...
You mean non-slashdotters only change their undies a dozen times in twenty years? Gosh, and there was me thinking slashdotters were unhygienic!
There is a compelling reason for some VM functionality to become part of the operating system. For a long time, memory management [in terms of making sure one app cannot tread on another app's memory even if it is badly written] has been a function of the OS. Providing garbage collection to ensure that one process cannot expend available memory with leaks (affecting the performance of other processes) is a sensible extension of this.
Code management probably should be a facility in modern desktop and server operating systems. (But perhaps not small embedded systems). At that stage it makes sense for your distributed binary to be compiled to code for the VM/OS rather than compiled to the VM/OS+CPU combination. The VM, either through compilation at install or JIT compilation can then optimise it for the CPU (hello Gentoo-like optimisation on downloaded packages!).
Whether Linux should provide that with Mono or Java is an open question. Personally, I would prefer Java [for the selfish reason that I know Java very well], but "both" is probably the right answer. This gives support for both sets of programmers, and some protection against one of the technology-patenters going rampant...
Ah, I couldn't disagree more. Mos Def was a very good actor, but misinterpreted the purpose of his role. He played "alienness" when much of the humour for the early part of the story only works if Ford is a character Arthur thought he could relate to. Mos Def's Ford was so alien as to be unintelligible, killing the Arthur-Ford dynamic and making the beginning of the movie not funny.
Much of the later part of the movie picked up and was funny, including the changes they put in, but those first impressions dented the movie as a whole.
A) This all fails the reasonable expectation test. It's not a contract if one of the parties could not reasonably have known what they were agreeing to. Or some technical interpretation of it. (The "reasonable person" using a font is not a computer expert, but an average joe with a wordprocessor)
..from A and B we can conclude...
B) A huge difference between this and modifying GPL code is that it is impossible to argue that a document is a derivative work of the font it was printed in.
C) If this ever went to court [incredibly unlikely], the result would be "oh, ok I'll substitute a different font" not "suddenly all my documents are GPL". So the GPL isn't met and nothing else gives a license to use the font - that just means the suee'd have to stop using the font, not that the document would magically become GPL'd. Chances of damages in this kind of ridiculous logic-chopping of how fonts are implemented in typesetting documents: not a lot.
And can you honestly see the copyright owner of a font chasing document writers? (After all, the person launching the suit has to have an "interest" in the case - they can't just be a bystander making mischief or the courts won't hear it).
Not that big an issue after all, then.
Hmmm, "but what constitutes distribution?" If a contractor does work for a client, does that constitute distribution (it's going from one legal entity to another)? What about between divisions of a company or between government departments? What about third-party backups (disaster recovery) of a corporation's filing system - that's certainly the code leaving the building and going to another firm. And if your own use is something that necessarily involves distribution (say, a peer-to-peer client) that's a bit sticky. No, I'm not at all convinced that the "only if it's for distribution" get-out is much of a help.
And the awkward GPL clause often fails to open up code -- we have the silly situation where if you run a webservice you don't need to reveal your changes to GPL'ed code (the code never leaves the server), but if you write the same thing to do the processing in the client (the code leaving the server), suddenly you do.
And worse, we have the mess where Sun have difficulty putting Java code [their own free-as-in-beer product] into OpenOffice.org [which they fund] because suddenly OpenOffice.org wouldn't be GPL-compatible. Sun can't GPL a JRE because MS would pounce, and nobody else is willing to fund a GPL'ed one properly.
Are you mad - mixing code and linking code are particularly important kinds of use!
Especially when some of your major products are programming languages, application servers, and operating systems and their components, but even in OpenOffice.org there have been complaints about including Java (because it could make it not-GPL-compatible) and that's something mostly funded and developed by Sun themselves!
But of course Sun aren't using anybody else's code. Their problem is that GPL customers aren't being allowed to use Sun's own code as they'd like to because it isn't deemed GPL-compatible.
Much as I personally do quite like the GPL (and ideed I'm developing lots of new GPL code), I do sometimes feel it sounds strangely parallel to a big company (say, Microsoft) saying "you may only use other Microsoft-approved products with this software". And we slap MS heavily for that sort of talk. And yet we actively approve of the GPL community shutting out non-GPL community products far more explicitly.
I think some people here are missing the point a bit.
Sun's planned "how to get straight again" is to open up their software most of the way, but they can't free it completely or their bigger competitors (ie MS) could wrench it off them immediately by forking it and throwing more money at the fork than Sun can throw at the original. The GPL has a "give-back-to-the-community" clause but not a "be-fair-to-the-original-author" clause. A GPL with some kind of limited non-compete clause to prevent direct competition of forks with the original might have been more palatable to them.
Meanwhile, the big completely closed IP players have been relatively unharmed by the GPL. Microsoft still ship XP with almost every new machine, and have a lovely income from Office despite the rise of OpenOffice.org. They are biting their fingernails a bit about the future, but so far profits are fine. Oracle don't seem to be stressing to much either. Apple (who although they have some open source code at the base have some very closed source code making up the rest of it) seem to be bounding along too.
The slightly-open-source firms get hit much harder by the GPL (and flamed with more venom on slashdot too) than the totally-closed-source firms.
And if Sun went splat, everyone on slashdot would be dancing for joy... and wondering why improvements to OpenOffice.org were suddenly taking so very very long to happen (curse those developers, just because nobody's paying their wages them any more, why won't they work?).
Write-once-run-anywhere is actually rather attractive even with it being not quite true across GUIs and operating systems:
If you distribute bytecode specialised to the OS / desktop environment, you have around 2 to 5 different versions to distribute (there are 2 to 5 operating systems most user applications would particularly want to support)
If you distribute native binaries, then you have 2-5 OS / environments times 3 or more processors (possibly plus optional extensions.)
If you distribute sourcecode, you're back at one version per OS, but users really don't like the idea of the thing needing to be compiled (which can be lengthy - eg OpenOffice.org)
Distributing bytecode suddenly looks attractive. And you can theoretically get the gentoo-like advantages of it being optimised for your system.
Brave prediction: Within 5 years, users will generally expect the VM to be "always available" in the OS, rather than needing to specially start up for an application - ie, bytecode will be a "native" (natural) langauge for the OS.
Brave prediction 2: there's going to be a battle between Java and Mono for which one is going to be natural for Linux. (Mono looks like winning, but when it starts to get very popular, watch Sun change its tune and suddenly want to push a GPL'ed Java VM into Linux)
Seems to me there are big benefits on both sides.
.Net bytecode became standard on both Windows and Linux, then Java's "write once run anywhere" aim would largely have been trumped.
From the community's perspective, the Sun JVM tends to move a bit faster than the others, bringing in new features. Having a big industry name behind it makes it corporately more trusted. And linux may get the chance to integrate the JVM a bit more - so that for instance 'ps' might tell you a bit more about the java process than just that it's 'java'. Which java program is it? Tomcat? Eclipse? If linux can support running Java bytecode more smoothly and naturally than other platforms, that's yet another big insentive for Java-focussed corporations to migrate to it.
From Sun's perspective, there is a competition between Java and Mono to become "the way" of doing managed code on Linux. Java has the advantage of a lot of programmers who know it, but the disadvantage that many people seem to think Java GUIs have to be in Swing, and Java apps not meshing completely with the native environment. (And Mono has a linux company's weight behind it). If Mono were to win that fight, and
This is true to an extent, but then you're really just using the browser as a delivery mechanism for a dedicated client app. And if you have any hypertext in your document, that is more easily rendered and integrated into the user's environment in a browser / browser pane than in a Swing HTML component.
There are some advantages to keeping it in the browser - use of third party plugins, CSS on the HTML is particularly helpful for vision impaired users (who have normally already got their browser set up with a personalised CSS with larger fonts, etc), shorter loading times for the page, and generally the fact that the browser is what the visitor is used to (and has come to your site with) makes a big difference.
They each (browser, Java) have their uses, and some better work to tie them together would be useful. A XUL that had easier access to Java would be handy. So I could just say "here's the tag, here's the class to render it". Java tag libraries on the client side. As would merging the virtual machine worlds of the browser and Java so hopping between JavaScript and Java calls wouldn't be so awkward.
In my work on the Intelligent Book project (intro text, example screenshot), I've been doing just this sort of thing using a Java applet for the communication and then modifying the page for 18 months or so (including returning XML). Fundamentally the advantage to using JavaScript over Java if you can is that the calls into the browser DOM from Java go through JavaScript anyway (whether explicitly in your code, or internally in the Sun code) and that Java-to-JavaScript bridge has been the source of interesting bits of flakiness, and there is still a delay on the first JavaScript-to-Java call in Firefox and Mozilla.
If you want to support graphical components (eg graphing tools, maths editor), you can nest XML-rendering applets on the page. This is what I do - see a couple of papers on my website (apologies for the dire need to update it). Of course, then you are stuck with having to do the Java-to-JavaScript thing at some point.
The fact that it is becoming a popular thing to do is great news - the more of us there are taking advantage of this capability, the more impetus there is for the browser authors to make sure it can be supported in a clean and quirk-free way.
Will Billingsley
PhD student
Intelligent Book project.
Actually, computer science researchers, such as those at the University of Southampton who developed this, don't have a particular requirement (moral or actual) to develop "for all platforms". They are interested in research - showing something can be done, and publishing details on it when they have shown it can be done, not waiting til they have also ported it to all proprietary platforms.
This isn't a product; it's a research demo.
Not an overstatement at all. It can very easily be illegal to mislead your customers into believing they do not have rights that they do have under their nation's laws. That's one reason why most shop refund policies say things like "this does not affect your statutary rights", and take great care actually not to affect your statutary rights!
In this case, the legality is even more easily called into question: Steam uses technical measures to enforce the EULA, including some very unexpected clauses. For example, it is impossible to sell Half-Life 2 second hand at all when you're done with it (the second purchaser *has* to pay Valve a fee to get the game "reactivated", and cannot then resell it again it all). These restrictions are generally not acceptable in consumer purchases, where the right to sell second hand is normally protected, but Valve attempts to legally justify them using the Steam EULA. The restrictions not declared on the box.
In other words, it is a technical enforcement of a clause the consumer could not reasonably have expected they were "agreeing to" at the time they bought the product in the shop.
The problem is, if he or she does that, then suddenly there is GPL code that can't be used with other GPL code because they have the wrong versions. That kind of version incompatibility would be a bit of a killer for viable free software.
Which is my most code has the "(at your option) any later version" note.
Remember clause 9 of the current GPL -- most GPL code either specifies "GPL version #.# or any later version", or does not specify a version at all in which case Clause 9 permits the user to choose any GPL version that has ever been published.
For existing code, a subsequent GPL revision can effectively only liberalise the usage rights - the user is free to choose to stick to the prior version. But oddly, perhaps this could could end up including "the right to restrict the use of modifications further" because of licence version creep. (See later in post for an example).
This is something that might be concerning to a whole raft of programmers who have released code under the GPL. Are Richard and Eben about to decide to "grant" rights to those pieces of code that the author never intended to grant? Or restrict rights, through version creep, they never intended to restrict?
Example 1 (version creep)...
Say I write package A, and release it under GPL 2. You are allowed to modify it and use it as a web service without being required to release your changes. But then a hypothetical GPL 3 is published which requires the publication of modified webservice code. No problem, you can still use GPL version 2. But then, someone integrates my package and some GPL version 3 code. The result has to be a GPL 3 package. But that means it is a modified version of my code which can no longer be modified for webservices without requiring the source code be published. It is a version of my GPL 2 code that does not have the full GPL 2 rights I released it under. Result: "That's not free!" I cry, and get very grumpy...
For anything other than extremely small changes to the GPL, version interoperability could get messy.
Example 2 (granting unintended rights - a bit of an extreme example)
A hypothetical GPL 4 is published which somehow allows integrating with non-Free code. A lot of people's business model (GPL is free, non-Free licence costs) gets instantly scuppered. The result is probably that the hapless company will attempt to invalidate all their GPL licences, claiming that they could not reasonably have expected the FSF to make this clause change, and therefore the modified licence is not valid. Result: lawyers at high noon.
For anything other than extremely small changes to the GPL, companies who have built their business around the GPL might start kicking up a stink...
Hmm, I wonder how much of that is true, and how much is bluster. In the UK I've heard about some small retailers that have claimed that they will not accept returns of anything sold no matter what - but if the customer gets in touch with Trading Standards and then tries again, the shop suddenly gives them a refund no trouble at all.
Steam, while it is a useful innovation, looks like it might have few snags with UK consumer trading law at the best of times. Valve making unilateral and unappealable decisions to refuse to supply product for which consideration has already been received sounds at odds with consumer laws, regardless of what the EULA might say. (Especially since the bulk of the "innocent" people caught are likely to be under 18 with a store-bought copy).
I wonder if Valve will actually quietly refund / reactivate accounts where the owner gets in touch with the proper consumer body.
Yes, there is a Fair Use clause in Australian copyright law, it just isn't identical to the one in the US. (and unfortunately while it does cover photocopying parts of books, it doesn't cover copying music from one medium to another).
However, there is also case law, some of which may be helpful. One example was when an Australian cable network was sued by a free-to-air network because the cable network was rebroadcasting the free-to-air signal (including ads) over cable without permission. Seems like an obvious breach of copyright law - copying the entire network content. But the cable network won, partly on the grounds that they were rebroadcasting the signal to people who were already entitled to receive it, and the free-to-air network couldn't actually prove it had caused any financial loss to them.
As such, a law suit to stop someone copying their CDs to their own media player might prove difficult, despite it not being covered by fair use.
But your milage may vary and I am not a lawyer...
I don't actually see how they are managing to put "unstructured" into this patent at all anyway - surely by dint of the fact that the input is into a computer that input obtains some form of encoding, and hence, structure. Whether the input is a sequence of pen-strokes, recording the user speaking, or listening to an unbounded sequence of button presses, it still has some (albeit loose) structure.
And it also seems like Microsoft shooting their own patent in the foot. It looks as though a litigee could simply stand up and say "No, No, the input in our product has structure. The structure is a time-ordered sequence of user input events". And despite this sounding bizarre, surely they could even point to the object in their code that represents the input, thus showing its structure.