This would show that the UK government holds their citizen's information in high regard (hahahaha, yeah right) and at the same time indicate a desire for "compliance" with their US masters' wishes, and simultaneously earn the UK a spot of cash.
From the two videos on YouTube (especially the second one which explained what the team was doing), I have to say that this was an extremely interesting experiment, but not in robotics --- in human psychology.
The reaction of people to Quasi was quite amazing, and not limited to kids. I found myself reacting to Quasi as an entity too, despite knowing that this was merely an interface manipulated by humans.
This is probably a good indicator of how humans will react to real AI-based robots once they eventually appear, if they too offer such a highly human-like facade. I think it goes well beyond mere "suspension of disbelief" --- we seem to WANT to accept humanity in objects. Very intriguing.
Chip design is a good example of such uses in "real engineering". The whole semiconductor industry is permeated with "strongly formal" tools implementing different types of formal methods at their core. These vary hugely, from loose fuzzy logic design aids to stronger expert system parameter, timing and topology validation, to the full blown formal methods that a language-based computer scientist would recognize.
And it's been going on for decades. The FPU of the well-known transputer CPUs from the 80's were designed using formal methods.
If integrated circuits were crafted using our current manual programming methods, 99% of computers would be dead 99% of the time.
"The customer is always right" we hear, and indeed when the silly crud and newbie chaff is separated out, there is often good substance and insight coming from the more knowledgeable users, sometimes even terrific suggestions.
Yet, how many companies actually have a strong official link between users and developers, taking user suggestions and pinning them up visibly as official input to the works process, duly accredited? Almost none, in my experience. The trend seems to be to have a Customer Relations officer whose job is to answer obvious questions from users and to keep fanboys happy, and little else. If a requested feature is implemented, it appears by a form of magic as a fait acomplit; the process of design, development and testing is certainly is not made visible, in general.
This area could be improved a lot in the corporate world!
On the FOSS side of things of course, we have merging of designer/developers and users, so the issue is somewhat irrelevant. We can still improve our communications and documentation *a lot* though.
>> Why not some formal law language with clear semantics and syntax?
Several people have written objections to youe suggestion here, but computer-based solutions are easy to find if you use a reductionist approach and don't try to do *everything* mechanically.
The simplest and most powerful approach by far is to apply formal semantics by case, not by generic mathemetics: For each area of legal engagement, a large number of highly specific case rules are defined and given a priority to define the order in which they are applied, with each one capable of matching only one very narrow situation. Separately from this you define a set of legal outcomes (independent of the case rules!!!), and causal links are only then drawn from the case rules to the case outcomes.
This can be made as deterministic a system as you like, merely by narrowing the scope of each case rule. Needless to say, if no case rule matches then the case pops out of the bottom to be handled by a human.
This addresses the ambiguity problem by each case rule being extremely specific, and allows lawyers to enter the loop for unmatched cases given by hard or undefined problems. It addresses comprehensibility by the public by allowing a worm's eye of the problem, one case rule at a time, and by allowing your own computer to "scan the law", which is otherwise impossible unless you practice law yourself.
Of course, anyone who has worked in AI or expert systems will recognize that the above is just a logic system, only expressed in a way that doesn't blow the mind. Well, that's good.:P
There's always a way, if you want to find one. The trouble is, such a mechanism would require endorsement from the legal profession... and that of course would not be in their interests.
I believe that the FSF have stated on various occasions that while they would *like* GPL virality to extend to all methods of linking, "unfortunately" they can't enforce that for dynamic linkages, notwithstanding what it says in the license.
The reason for this "problem" or "benefit" (depending on your philosophy) is very simple. Dynamic linking is done against an interface, and interfaces cannot be copyrighted because they are the key mechanism for interoperability. There are decades of case law enshrining that principle. (Don't forget that we benefit hugely from interoperability too.)
The GPL is a copyright license (not a EULA), and it cannot claim copyright on the interface to which separate applications are coded. As a result, the GPL has no copyright mechanism for "bridging the gap" between a dynamic library file and an entirely separate application which uses its interfaces. (Otherwise SCO too would have a case that all Linux apps are derived works of Unix, just because they use the same interfaces --- fortunately it's not so.)
And it gets worse (or better). The fact that such an application can be made to work against *ANY* other dynamic library that satisfies the same interfaces reinforces the exclusions for interoperability. Add to that the fact that no COPYrighted material ever actually gets copied, and you see why GPL enforcement is limited to two clear cases:
code derived by ancestry -- the new source code physically contains elements of GPL'd source code within it, with or without modification -- so that the laws covering derived works can be applied (in this case the GPL license transfers to the new code by inheritance); or
code inclusion by static linking -- the new source code does not contain any GPL'd source code within it, but the distributed binaries physically contain GPL'd code brought in by the static linkage -- so that the copyright laws which cover copying can be applied (in this case the GPL license transfers by the GPL'd code being physically bound to the new code and distributed along with it).
Both of the above cases are quite clearcut to apply, and hence supposedly safe.
The other major case (dynamic linking, in which no copyrighted source code has been used and no copyrighted binaries are included) is shrouded deep within the darkest clouds of uncertainty, since there is no legal mechanism by which the copyright can transfer to mere client code which is coded to a non-copyrightable interface.
Saying the GPL is not viral does the opposite of clarifying. This is no way to remove uncertainty.
That's very true.
It's very easy to make a clear statement about GPL virality, so I really don't understand why the interviewees didn't take the opportunity to do so. Here's my off-the-cuff attempt at an explanation:
The GPL intentionally creates virality through the mechanism of program derivation (defined below); a derived work must then also be licensed under the GPL if it is to be distributed.
The GPL specifically refrains from any virality through aggregation on media or through simple proximity to other programs within any form of container, virtual or otherwise.
The GPL is a distribution license, and not a usage license. It guarantees downstream developers the availability of source code whenever a GPL-licensed program reaches them. It is not viral through simple usage of a program under any circumstances. (At least in theory, but see below.)
Unfortunately, a nice simple summary like that doesn't carry the whole truth.
The problem is that the derivation of programs carries a double semantic under the GPL, and this is the source of endless debate and discontent because it is partly inappropriate in a distribution license.
One of the two meanings of derivation relates to physical modification of the original GPL source code to create a new ("derived") work through the process of code extension. By any rational assessment, this is a self-evidently fair provision, in that if you take someone else's source code and modify it in some way, then your new program is derived by ancestry. and thus quite reasonably should inherit the license of its progenitor.
In contrast, the other meaning relates quite illogically to *using* GPL'd library code through linking to it, despite having made no modification whatsoever to that GPL'd code. This could make sense in a usage license (which the GPL is not, in theory), but it is quite out of place in a license dedicated to protecting the availability of the original source code and any modified versions thereof. That semantic is clearly in the license "for other reasons".
Remember the discredited attempt by some content providers a few years ago to equate web links and the content to which they point as being one and the same thing? We "obviously" knew that that was ridiculous at the time, yet the GPL tries to claim that linking for usage is the same thing as copying the source for derivation by extension. It's "obvious" that this is incorrect, and that therefore the client application should not become affected virally. There is no derivation by ancestry, so by what mechanism is the license inherited? Well the answer is that it's not inherited --- instead the new, non-derived client code has been tainted by usage.
This second semantic has no business being in the license at all, because consistency would then require us to taint everything else that comes into contact with GPL code through simple USAGE, and that includes web applications. Usage is usage, you can't make arbitrary exceptions to it without totally undermining your platform of logic.
It's quite a mess. Maybe we need a good chat with Eben Moglen; I think he'd understand the problems inherent in tainting by usage very clearly.
So you see, those 3 paragraphs don't really tell the whole story. Still, they certainly define GPL virality a lot better than the article did.
Yes, Anarchy Online's approach of being skills-based but defining classes which have preferential improvement point costs worked very well indeed. And the implants provided yet another level of skills customizeability in AO.
Guild Wars is even better in that regard though, and this was mentioned briefly by the fifth of the people mentioned in the headline article, Damion Schubert.
In GW, every character has both a primary and a secondary profession, but you can raise the attributes of your primary profession higher than a secondary could through runes that your put on your armor. Since armor is switchable on the fly, even while fighting, this gives you a lot of flexibility for optimizing your build for a particular zone or encounter. It's better than AO's equivalent, the implants, since those couldn't really be changed in the field (AO's portable clinics were useless).
And since in GW your secondary profession can be changed to any other one with a 30-second visit to Crystal Desert or Senji's Corner, the range of possible combination builds is truly astronomic, yet everyone still knows that (for example) the Elementarist can provide the most powerful nukes. One of the bloggers wrote that skills-based systems introduce uncertaintly, but that doesn't apply to GW -- the primary will always reign supreme at the top end of their skill's abilities.
Quite a few of the other points made in those blogs seem to have been overcome in GW too. For example, it's no hardship at all to call for a "healer" instead of a "Monk" specifically, and everyone is perfectly happy to be healed by a Ritualist or an Elementarist/Monk or a Mesmer/Monk who are running healer builds despite not being primary monks. In fact, it introduces some very pleasant variety.
In summary then, hybrid systems work really well in practice, so the "classes vs skills" debate is a rather pointless one. Just combine the two, and you get the best of both worlds.
I had a tenured position at a university as well, but I left the system anyway, and it was partly due to issues of the kind described.
Academia hinges almost entirely on your research karma, your success at obtaining grants, and the funds you can bring in to your department. In computing, it has very little to do with how effectively your work extends understanding in your area, even less to do with using honest scientific methods, and absolutely nothing to do with teaching.
And since your research karma is in the hands of the high priests in the field and has relatively little to do with your own technical abilities, I can fully understand the frustrations of other research academics. It's a dead-man's-shoes area, and not a good field to be in unless you're good at cultivating your profile through social engineering.
Fortunately I left early because of the compelling attraction of fat paycheques in freelance contracting, an order of magnitude better than academic payscales. But even without that, I think the social problems within academia might have made me leave in disgust at some point too.
I don't know anything specific to SIGGRAPH, but that kind of malaise is quite widespread in the academic sector.
PS. The current publication/conference-based approach in peer review needs change. The author of TFA actually gave one possible avenue, arXiv, which fits in well with today's greater interest in open systems. I support that.
Your good ideas are your lifeblood. If you have been honing and developing methods and techniques over the years, then you've been building a priceless (or at least highly valuable) personal resource, to be metered out in small, controlled, and non-exclusive amounts to your clients.
For any single client to want the whole lot, nicely gift-wrapped and handed to them on a plate, is the height of impertinence, even if they say that they are going to use the document merely as reference and to give you proper accreditation. This is the real world --- that won't happen. And you probably don't want to spend 6 figures in court to enforce it.
By all means produce such a comprehensive document. I suggest that the MINIMUM price under which you would offer it to a client should be US$50,000, under non-exclusive NDA and with all your rights reserved. And that would be utter peanuts for this kind of thing.
You might like to consider the lengths to which companies go in search of valuable advice or ideas, in the form of hiring consultancies or even industrial espionage. Useful information is not cheap, so don't undersell your own.
>> The only thing in danger is CHEAP water, really.
Seawater is pretty cheap. Why not use it directly instead of using freshwater biomass and then needing a supply of freshwater for it?
Make biofuel from kelp biomass and no freshwater irrigation is needed. Grow it in situ or pump the seawater into a shoreline kelp farm, and harvest the biomass.
Jeez, do I have to think of everything for those environmentalists?:P
Until FOSS administrators and coders wake up and realize that usability is a key cornerstone of effective software, people will continue paying for proprietary software that gives them just that.
That of course is true, but you missed the key point:
"if you want to write something beyond your ability for total reinvention, you won't be able to make it shareware." (because of licensing constraints)
Sure, people will continue paying for proprietary software that gives them what they want, if it exists. But the proprietary developer will have to continually reinvent everything he needs to create such products, and that places him at an immense disadvantage against those who make similar products based on FOSS code.
If you extrapolate this trend, and give FOSS time to shave off the rough edges, it leads inescapably to vendors of closed products being entirely unable to compete with FOSS on product features, quality, and of course cost. This really leaves very few avenues for profit.
Consequently, the days of proprietary code (for the masses, not bespoke) are numbered, except in niche markets not yet covered by FOSS capability.
This is wishfull thinking. your thousands and thousands of developers are answerable to nobody, with little incentive to band together and get organised.
They don't need to be organized. All they need to do is to add to the volume of FOSS resources, and they are doing that admirably and in collosal amounts. The size of the FOSS mountain is just mind-boggling already, and always increasing.
However, there is another way of looking at this which perhaps will suit you better:
They *ARE* being organized, not by management, but simply through the act of making things compile. It is the various APIs that ensure that people's separate efforts all work together. There's your "management". It's light-handed, but it works, superbly.
The point being made in TFA is all very well and good, for a developer who writes his own programs from scratch, or derives from public domain resources which he then closes into shareware. However, the proposal has a very limited future.
Not too far down the line, it will become completely impossible for any fully independent developer to compete against the collosal pyramid of software resources being constructed by the FOSS movement. And that includes the Redmonds and IBMs of this world, not a chance. A thousand fully paid developers beavering away without the benefit of standing on the shoulders of a thousand times that many unpaid giants will get absolutely nowhere, comparatively speaking.
This is just a simple matter of geometric growth of FOSS capability, and the trend is absolutely unstoppable (except possibly by patents, hence the worry there). To stay on the leading edge, your application will have to ride that collosal resource, because to not do so will mean spending an extreme amount of time and money reinventing the wheel and probably failing anyway. And that precludes shareware, because of licensing.
While some people don't like the intentionally viral nature of the GPL, it is instrumental in making sure that this stunningly huge resource continues to grow and to be ever more beneficial to the community that uses it. While that doesn't make its use compulsary, and non-dependent developers like in TFA will probably always exist for small projects, the general trend is clear: if you want to write something beyond your ability for total reinvention, you won't be able to make it shareware.
There is no need to resign to support your strongly held views against patents in software.
All you need to do to fight patents very effectively is to ensure that your key ideas are released to the FOSS world as programming "noddies", ie. small example programs that illustrate the concept. Be very sure not to include any company code, nor any business logic.
That establishes the prior art, so that even if a patent is taken out for that idea, eventually your prior art will ensure its demise if a patent claim ever reaches the courts.
And if a company fires you for publishing your ideas in this way, well, it's not really the company that you wanted to work for in the first place.
Is AMD's Pacifica virtualisation system any better?
Apparently, yes, and by a good margin.
There are several documents and articles out there which point out VT's problems and how Pacifica is quite dramatically better. Here's an excerpt from "AMD Pacifica turns the nested tables", part 3 of an informative series of articles:
The basic architecture of the K8 gives AMD more toys to play with, the memory controller and directly connected devices. AMD can virtualise both of these items directly while Intel has to do so indirectly if it can do so at all.
This should allow an otherwise identical VMM to do more things in hardware and have lower overhead than VT. AMD appears to have used the added capability wisely, giving them a faster and as far as memory goes, more secure virtualisation platform."
So, it looks like AMD are ahead on hardware virtualization at the moment.
If I read it correctly, this is because Intel's VT actually requires a lot of software intervention, so it's not actually a very strong hardware solution at all.
Bah, megabytes... my first multiuser computer was a PDP-11/20 with a 64 kilobyte fixed hard drive, which I think came from our PDP-7.
I upgraded the box to a PDP-11/34 to run Unix though, and chucked out the 64 KB drive since the 11/34 had spanking new RK07 drives with 2 megabyte disk packs. Pity.
In a nut shell, hardware is expensive and software is cheap. Anything you can do in software with little or no impact on your performance requirements is something you should not do in hardware.
Yes indeed Theovon, that's a commercial fact of life, and it's not going to change. Since it's not going to change, kernel designers who want to protect Linux from the problems inherent in closed binary drivers should have structured the driver architecture in a manner that addresses this, but they haven't.
Driver manufacturers who "need" closed code (because it saves their company money) should be forced to run it in their own private and heavily MMU-isolated VM, with absolutely no exceptions allowed to this rule.
nVidia and ATI will complain that this reduces their performance somewhat --- tough, that's the price you pay for insisting on using your own opaque driver code and refusing to provide full hardware interface documentation.
Companies who DO provide full specs so that we can write open drivers to them would benefit from increased performance, which is a nice incentive to be more open.
It all depends on who controls the root certificates that are used by the trusted computing hardware to verify the signatures of the BIOS and of the boot image.
If the FOSS fraternity are left out in the cold by the certificate authority, this will lead to some almighty class-action type litigation. It would be utterly anti-competitive to lock out a huge potential competitor, and Europe in particular would have a field day with Microsoft. Look at the trouble MS got into merely by locking people to their browser.
It's one thing to use TPM to ensure your PC is "trusted". It's totally another to use it to ensure that you PC is running Microsoft or Mac software.
The paragraph after the one you quoted offers us additional hope:
"The TCG design does not have any requirement that software be "certified" in order to use it. The specification talks in some length about ways of using the platform to create certificates for keys that are provably secure and yet not identify the platform they came from."
In principle then, FOSS operating systems should be able to use TPM to enhance the trust that their owners have in them, in contrast to the way in which MS systems will use it to enhance the trust that content providers have in the platform. It all comes down to the way it's used.
It was restrictive licensing that killed am/data
on
Own the Last Mile
·
· Score: 1
It wasn't the Internet that killed amateur radio (the data side of it, not long-distance HF, that's still going strong).
It was government licensing restrictions that killed it, idiotic things like not being allowed to encrypt our data links because the authorities wanted the content of transmissions to be visible to them. They didn't care that this made our data systems open to every script kiddie under the sun, nor that lack of privacy rendered it largely worthless for personal utility comms.
Amateur data could have been great as a secondary "internet" (small 'i') hooked into the public Internet to give radio amateurs extra reach, but that whole concept died utterly once it became clear that the whole range of Internet traffic was barred from being transmitted (and I don't mean just pr0n). When you can't browse your home mail because private info is visible to all and because its content may contravene the rules, the whole thing becomes useless.
So it died as a potentially useful personal/community data service. Big pity, but it's not the first time that regulators have destroyed something.
But not an important one in this case, because most people will have bought their PCs with WinXP preinstalled and so the cost is hidden. In contrast, the pain and distress of their property being willfully disabled (because they've avoided WGA) will be immense, and a very strong motivator. The question is, motivator for what?
Well, some will no doubt relent and let the evil bastards install WGA. Some will see it as the last straw and migrate to Macs. Those of us who already use Linux or BSD will laugh and see it as confirming their views about MS, and no doubt the Unix-oriented FOSS movement will see some new recruits.
However, this is where I see the most exciting effect of MS's moronic action: ReactOS.
If Microsoft's product facism becomes too much of a pain for too many people, a direct replacement will start to become extremely appealing. For the non-technical MS masses, that O/S with a familiar face will become a far better proposition than submitting themselves to the fear of the unknown with Linux and Co.
It's still early days on the ReactOS project, but draconian measures of the kind suggested by TFA could swell the ranks of their developers and users very nicely.:P
Slashdot Mirror
This would show that the UK government holds their citizen's information in high regard (hahahaha, yeah right) and at the same time indicate a desire for "compliance" with their US masters' wishes, and simultaneously earn the UK a spot of cash.
Next problem please.
From the two videos on YouTube (especially the second one which explained what the team was doing), I have to say that this was an extremely interesting experiment, but not in robotics --- in human psychology.
The reaction of people to Quasi was quite amazing, and not limited to kids. I found myself reacting to Quasi as an entity too, despite knowing that this was merely an interface manipulated by humans.
This is probably a good indicator of how humans will react to real AI-based robots once they eventually appear, if they too offer such a highly human-like facade. I think it goes well beyond mere "suspension of disbelief" --- we seem to WANT to accept humanity in objects. Very intriguing.
Chip design is a good example of such uses in "real engineering". The whole semiconductor industry is permeated with "strongly formal" tools implementing different types of formal methods at their core. These vary hugely, from loose fuzzy logic design aids to stronger expert system parameter, timing and topology validation, to the full blown formal methods that a language-based computer scientist would recognize.
And it's been going on for decades. The FPU of the well-known transputer CPUs from the 80's were designed using formal methods.
If integrated circuits were crafted using our current manual programming methods, 99% of computers would be dead 99% of the time.
"The customer is always right" we hear, and indeed when the silly crud and newbie chaff is separated out, there is often good substance and insight coming from the more knowledgeable users, sometimes even terrific suggestions.
Yet, how many companies actually have a strong official link between users and developers, taking user suggestions and pinning them up visibly as official input to the works process, duly accredited? Almost none, in my experience. The trend seems to be to have a Customer Relations officer whose job is to answer obvious questions from users and to keep fanboys happy, and little else. If a requested feature is implemented, it appears by a form of magic as a fait acomplit; the process of design, development and testing is certainly is not made visible, in general.
This area could be improved a lot in the corporate world!
On the FOSS side of things of course, we have merging of designer/developers and users, so the issue is somewhat irrelevant. We can still improve our communications and documentation *a lot* though.
You'll be hearing from our lawyers. :P
:-((((
I'm just laughing as a defence mechanism though. This is very sad news for you guys, and probably for the west as a whole.
>> Why not some formal law language with clear semantics and syntax?
:P
... and that of course would not be in their interests.
Several people have written objections to youe suggestion here, but computer-based solutions are easy to find if you use a reductionist approach and don't try to do *everything* mechanically.
The simplest and most powerful approach by far is to apply formal semantics by case, not by generic mathemetics: For each area of legal engagement, a large number of highly specific case rules are defined and given a priority to define the order in which they are applied, with each one capable of matching only one very narrow situation. Separately from this you define a set of legal outcomes (independent of the case rules!!!), and causal links are only then drawn from the case rules to the case outcomes.
This can be made as deterministic a system as you like, merely by narrowing the scope of each case rule. Needless to say, if no case rule matches then the case pops out of the bottom to be handled by a human.
This addresses the ambiguity problem by each case rule being extremely specific, and allows lawyers to enter the loop for unmatched cases given by hard or undefined problems. It addresses comprehensibility by the public by allowing a worm's eye of the problem, one case rule at a time, and by allowing your own computer to "scan the law", which is otherwise impossible unless you practice law yourself.
Of course, anyone who has worked in AI or expert systems will recognize that the above is just a logic system, only expressed in a way that doesn't blow the mind. Well, that's good.
There's always a way, if you want to find one. The trouble is, such a mechanism would require endorsement from the legal profession
The reason for this "problem" or "benefit" (depending on your philosophy) is very simple. Dynamic linking is done against an interface, and interfaces cannot be copyrighted because they are the key mechanism for interoperability. There are decades of case law enshrining that principle. (Don't forget that we benefit hugely from interoperability too.)
The GPL is a copyright license (not a EULA), and it cannot claim copyright on the interface to which separate applications are coded. As a result, the GPL has no copyright mechanism for "bridging the gap" between a dynamic library file and an entirely separate application which uses its interfaces. (Otherwise SCO too would have a case that all Linux apps are derived works of Unix, just because they use the same interfaces --- fortunately it's not so.)
And it gets worse (or better). The fact that such an application can be made to work against *ANY* other dynamic library that satisfies the same interfaces reinforces the exclusions for interoperability. Add to that the fact that no COPYrighted material ever actually gets copied, and you see why GPL enforcement is limited to two clear cases:
- code inclusion by static linking -- the new source code does not contain any GPL'd source code within it, but the distributed binaries physically contain GPL'd code brought in by the static linkage -- so that the copyright laws which cover copying can be applied (in this case the GPL license transfers by the GPL'd code being physically bound to the new code and distributed along with it).
Both of the above cases are quite clearcut to apply, and hence supposedly safe.The other major case (dynamic linking, in which no copyrighted source code has been used and no copyrighted binaries are included) is shrouded deep within the darkest clouds of uncertainty, since there is no legal mechanism by which the copyright can transfer to mere client code which is coded to a non-copyrightable interface.
It's very easy to make a clear statement about GPL virality, so I really don't understand why the interviewees didn't take the opportunity to do so. Here's my off-the-cuff attempt at an explanation:
Unfortunately, a nice simple summary like that doesn't carry the whole truth.
The problem is that the derivation of programs carries a double semantic under the GPL, and this is the source of endless debate and discontent because it is partly inappropriate in a distribution license.
One of the two meanings of derivation relates to physical modification of the original GPL source code to create a new ("derived") work through the process of code extension. By any rational assessment, this is a self-evidently fair provision, in that if you take someone else's source code and modify it in some way, then your new program is derived by ancestry. and thus quite reasonably should inherit the license of its progenitor.
In contrast, the other meaning relates quite illogically to *using* GPL'd library code through linking to it, despite having made no modification whatsoever to that GPL'd code. This could make sense in a usage license (which the GPL is not, in theory), but it is quite out of place in a license dedicated to protecting the availability of the original source code and any modified versions thereof. That semantic is clearly in the license "for other reasons".
Remember the discredited attempt by some content providers a few years ago to equate web links and the content to which they point as being one and the same thing? We "obviously" knew that that was ridiculous at the time, yet the GPL tries to claim that linking for usage is the same thing as copying the source for derivation by extension. It's "obvious" that this is incorrect, and that therefore the client application should not become affected virally. There is no derivation by ancestry, so by what mechanism is the license inherited? Well the answer is that it's not inherited --- instead the new, non-derived client code has been tainted by usage.
This second semantic has no business being in the license at all, because consistency would then require us to taint everything else that comes into contact with GPL code through simple USAGE, and that includes web applications. Usage is usage, you can't make arbitrary exceptions to it without totally undermining your platform of logic.
It's quite a mess. Maybe we need a good chat with Eben Moglen; I think he'd understand the problems inherent in tainting by usage very clearly.
So you see, those 3 paragraphs don't really tell the whole story. Still, they certainly define GPL virality a lot better than the article did.
Yes, Anarchy Online's approach of being skills-based but defining classes which have preferential improvement point costs worked very well indeed. And the implants provided yet another level of skills customizeability in AO.
Guild Wars is even better in that regard though, and this was mentioned briefly by the fifth of the people mentioned in the headline article, Damion Schubert.
In GW, every character has both a primary and a secondary profession, but you can raise the attributes of your primary profession higher than a secondary could through runes that your put on your armor. Since armor is switchable on the fly, even while fighting, this gives you a lot of flexibility for optimizing your build for a particular zone or encounter. It's better than AO's equivalent, the implants, since those couldn't really be changed in the field (AO's portable clinics were useless).
And since in GW your secondary profession can be changed to any other one with a 30-second visit to Crystal Desert or Senji's Corner, the range of possible combination builds is truly astronomic, yet everyone still knows that (for example) the Elementarist can provide the most powerful nukes. One of the bloggers wrote that skills-based systems introduce uncertaintly, but that doesn't apply to GW -- the primary will always reign supreme at the top end of their skill's abilities.
Quite a few of the other points made in those blogs seem to have been overcome in GW too. For example, it's no hardship at all to call for a "healer" instead of a "Monk" specifically, and everyone is perfectly happy to be healed by a Ritualist or an Elementarist/Monk or a Mesmer/Monk who are running healer builds despite not being primary monks. In fact, it introduces some very pleasant variety.
In summary then, hybrid systems work really well in practice, so the "classes vs skills" debate is a rather pointless one. Just combine the two, and you get the best of both worlds.
I had a tenured position at a university as well, but I left the system anyway, and it was partly due to issues of the kind described.
Academia hinges almost entirely on your research karma, your success at obtaining grants, and the funds you can bring in to your department. In computing, it has very little to do with how effectively your work extends understanding in your area, even less to do with using honest scientific methods, and absolutely nothing to do with teaching.
And since your research karma is in the hands of the high priests in the field and has relatively little to do with your own technical abilities, I can fully understand the frustrations of other research academics. It's a dead-man's-shoes area, and not a good field to be in unless you're good at cultivating your profile through social engineering.
Fortunately I left early because of the compelling attraction of fat paycheques in freelance contracting, an order of magnitude better than academic payscales. But even without that, I think the social problems within academia might have made me leave in disgust at some point too.
I don't know anything specific to SIGGRAPH, but that kind of malaise is quite widespread in the academic sector.
PS. The current publication/conference-based approach in peer review needs change. The author of TFA actually gave one possible avenue, arXiv, which fits in well with today's greater interest in open systems. I support that.
Your good ideas are your lifeblood. If you have been honing and developing methods and techniques over the years, then you've been building a priceless (or at least highly valuable) personal resource, to be metered out in small, controlled, and non-exclusive amounts to your clients.
For any single client to want the whole lot, nicely gift-wrapped and handed to them on a plate, is the height of impertinence, even if they say that they are going to use the document merely as reference and to give you proper accreditation. This is the real world --- that won't happen. And you probably don't want to spend 6 figures in court to enforce it.
By all means produce such a comprehensive document. I suggest that the MINIMUM price under which you would offer it to a client should be US$50,000, under non-exclusive NDA and with all your rights reserved. And that would be utter peanuts for this kind of thing.
You might like to consider the lengths to which companies go in search of valuable advice or ideas, in the form of hiring consultancies or even industrial espionage. Useful information is not cheap, so don't undersell your own.
>> The only thing in danger is CHEAP water, really.
:P
Seawater is pretty cheap. Why not use it directly instead of using freshwater biomass and then needing a supply of freshwater for it?
Make biofuel from kelp biomass and no freshwater irrigation is needed. Grow it in situ or pump the seawater into a shoreline kelp farm, and harvest the biomass.
Jeez, do I have to think of everything for those environmentalists?
That of course is true, but you missed the key point:
Sure, people will continue paying for proprietary software that gives them what they want, if it exists. But the proprietary developer will have to continually reinvent everything he needs to create such products, and that places him at an immense disadvantage against those who make similar products based on FOSS code.
If you extrapolate this trend, and give FOSS time to shave off the rough edges, it leads inescapably to vendors of closed products being entirely unable to compete with FOSS on product features, quality, and of course cost. This really leaves very few avenues for profit.
Consequently, the days of proprietary code (for the masses, not bespoke) are numbered, except in niche markets not yet covered by FOSS capability.
This is wishfull thinking. your thousands and thousands of developers are answerable to nobody, with little incentive to band together and get organised.
They don't need to be organized. All they need to do is to add to the volume of FOSS resources, and they are doing that admirably and in collosal amounts. The size of the FOSS mountain is just mind-boggling already, and always increasing.
However, there is another way of looking at this which perhaps will suit you better:
They *ARE* being organized, not by management, but simply through the act of making things compile. It is the various APIs that ensure that people's separate efforts all work together. There's your "management". It's light-handed, but it works, superbly.
The point being made in TFA is all very well and good, for a developer who writes his own programs from scratch, or derives from public domain resources which he then closes into shareware. However, the proposal has a very limited future.
Not too far down the line, it will become completely impossible for any fully independent developer to compete against the collosal pyramid of software resources being constructed by the FOSS movement. And that includes the Redmonds and IBMs of this world, not a chance. A thousand fully paid developers beavering away without the benefit of standing on the shoulders of a thousand times that many unpaid giants will get absolutely nowhere, comparatively speaking.
This is just a simple matter of geometric growth of FOSS capability, and the trend is absolutely unstoppable (except possibly by patents, hence the worry there). To stay on the leading edge, your application will have to ride that collosal resource, because to not do so will mean spending an extreme amount of time and money reinventing the wheel and probably failing anyway. And that precludes shareware, because of licensing.
While some people don't like the intentionally viral nature of the GPL, it is instrumental in making sure that this stunningly huge resource continues to grow and to be ever more beneficial to the community that uses it. While that doesn't make its use compulsary, and non-dependent developers like in TFA will probably always exist for small projects, the general trend is clear: if you want to write something beyond your ability for total reinvention, you won't be able to make it shareware.
There is no need to resign to support your strongly held views against patents in software.
All you need to do to fight patents very effectively is to ensure that your key ideas are released to the FOSS world as programming "noddies", ie. small example programs that illustrate the concept. Be very sure not to include any company code, nor any business logic.
That establishes the prior art, so that even if a patent is taken out for that idea, eventually your prior art will ensure its demise if a patent claim ever reaches the courts.
And if a company fires you for publishing your ideas in this way, well, it's not really the company that you wanted to work for in the first place.
The article is entirely wrong, because Sony has a highly aggressive strategy!
What could be more aggressive than implying that all your customers are morons?
Apparently, yes, and by a good margin.
There are several documents and articles out there which point out VT's problems and how Pacifica is quite dramatically better. Here's an excerpt from "AMD Pacifica turns the nested tables", part 3 of an informative series of articles:
This should allow an otherwise identical VMM to do more things in hardware and have lower overhead than VT. AMD appears to have used the added capability wisely, giving them a faster and as far as memory goes, more secure virtualisation platform."
So, it looks like AMD are ahead on hardware virtualization at the moment.
If I read it correctly, this is because Intel's VT actually requires a lot of software intervention, so it's not actually a very strong hardware solution at all.
>> Perens disagreed with the direction HP was taking on its Linux platform when it merged with Compaq.
A company that fires you when you disagree with them is most emphatically a company that you no longer want to work for.
Bruce has principles and doesn't toe the company line when it seems wrong. In my book, that's a good thing.
Bah, megabytes ... my first multiuser computer was a PDP-11/20 with a 64 kilobyte fixed hard drive, which I think came from our PDP-7.
:P
I upgraded the box to a PDP-11/34 to run Unix though, and chucked out the 64 KB drive since the 11/34 had spanking new RK07 drives with 2 megabyte disk packs. Pity.
That's retro.
Yes indeed Theovon, that's a commercial fact of life, and it's not going to change. Since it's not going to change, kernel designers who want to protect Linux from the problems inherent in closed binary drivers should have structured the driver architecture in a manner that addresses this, but they haven't.
Driver manufacturers who "need" closed code (because it saves their company money) should be forced to run it in their own private and heavily MMU-isolated VM, with absolutely no exceptions allowed to this rule.
nVidia and ATI will complain that this reduces their performance somewhat --- tough, that's the price you pay for insisting on using your own opaque driver code and refusing to provide full hardware interface documentation.
Companies who DO provide full specs so that we can write open drivers to them would benefit from increased performance, which is a nice incentive to be more open.
If the FOSS fraternity are left out in the cold by the certificate authority, this will lead to some almighty class-action type litigation. It would be utterly anti-competitive to lock out a huge potential competitor, and Europe in particular would have a field day with Microsoft. Look at the trouble MS got into merely by locking people to their browser.
It's one thing to use TPM to ensure your PC is "trusted". It's totally another to use it to ensure that you PC is running Microsoft or Mac software.
In principle then, FOSS operating systems should be able to use TPM to enhance the trust that their owners have in them, in contrast to the way in which MS systems will use it to enhance the trust that content providers have in the platform. It all comes down to the way it's used.
It wasn't the Internet that killed amateur radio (the data side of it, not long-distance HF, that's still going strong).
It was government licensing restrictions that killed it, idiotic things like not being allowed to encrypt our data links because the authorities wanted the content of transmissions to be visible to them. They didn't care that this made our data systems open to every script kiddie under the sun, nor that lack of privacy rendered it largely worthless for personal utility comms.
Amateur data could have been great as a secondary "internet" (small 'i') hooked into the public Internet to give radio amateurs extra reach, but that whole concept died utterly once it became clear that the whole range of Internet traffic was barred from being transmitted (and I don't mean just pr0n). When you can't browse your home mail because private info is visible to all and because its content may contravene the rules, the whole thing becomes useless.
So it died as a potentially useful personal/community data service. Big pity, but it's not the first time that regulators have destroyed something.
>> Money is a suprisingly efficient motivator.
:P
But not an important one in this case, because most people will have bought their PCs with WinXP preinstalled and so the cost is hidden. In contrast, the pain and distress of their property being willfully disabled (because they've avoided WGA) will be immense, and a very strong motivator. The question is, motivator for what?
Well, some will no doubt relent and let the evil bastards install WGA. Some will see it as the last straw and migrate to Macs. Those of us who already use Linux or BSD will laugh and see it as confirming their views about MS, and no doubt the Unix-oriented FOSS movement will see some new recruits.
However, this is where I see the most exciting effect of MS's moronic action: ReactOS.
If Microsoft's product facism becomes too much of a pain for too many people, a direct replacement will start to become extremely appealing. For the non-technical MS masses, that O/S with a familiar face will become a far better proposition than submitting themselves to the fear of the unknown with Linux and Co.
It's still early days on the ReactOS project, but draconian measures of the kind suggested by TFA could swell the ranks of their developers and users very nicely.