I'm seeing increasing numbers of OSS software projects with installation programs (e.g. Windows ones) insisting that the end user accept the GPL before allowing them to install. I've asked a few about this, and the general response is, 'we need you to accept that, because that's where the "no warranty" agreement is, and we don't provide you with a warranty.'
The problem is that you can't distill the EULA's of most commercial software down to that level. It works with privacy policies because most companies are willing to work with a very loosely defined one; they just take the next available 'size' up from what they need to do with your information and use that.
You can't do that with an EULA. They contain wildly varying terms, with specific phrasing that the company's lawyers have recommended over and above any other. They're not about to choose the phrasing recommended by some standards body just to make sure it works with a piece of software they don't see the need for anyway.
If they can phrase a summary like that that contains all the information required for you to understand what you're agreeing to, there's no need for the legalese section. You don't think contracts _have_ to be written like that, do you? The only reason that they _are_ written like that is that that is the only way to include all the information that's necessary without approximating the size of war & peace.
It's a lot like Bridge -- The rules say that you can't show your partner your hand and you can't tell them what you have, but you are allowed to use prearranged bidding conventions to pass information across the table.
Actually, the rules I understand for bridge specifically disallow prearranged bidding conventions that aren't well known standard conventions. But the rules of IPD don't, so I would guess it's OK there.
But it doesn't work, of course, because all you need to do to beat this strategy is mimic it until it recognises you and then not behave as it expects.
I suspect you could come up with a solution that beats this system by mimicing it, then changing its behaviour suddenly.
That's why this isn't a good answer to the problem -- not because it's somehow "cheating", but because its a strategy that only works in limited circumstances and fails spectacularly in others. Kind of like chasing down losses when gambling.
This isn't a big problem, to be honest. The following comment coming from the Linux kernel explains that while Linux doesn't use TSSs, it isn't for performance reasons:
/* [...]
* NOTE! We used to use the x86 hardware context switching. The
* reason for not using it any more becomes apparent when you
* try to recover gracefully from saved state that is no longer
* valid (stale segment register values in particular). With the
* hardware task-switch, there is no way to fix up bad state in
* a reasonable manner.
*
* The fact that Intel documents the hardware task-switching to
* be slow is a fairly red herring - this code is not noticeably
* faster. However, there _is_ some room for improvement here,
* so the performance issues may eventually be a valid point.
* More important, however, is the fact that this allows us much
* more flexibility.
*/
This is because it's not a reference to the application, but to the type of document that will be created. You should also have items like 'From Template', 'HTML Document', and 'Text Document' that also follow this convention. It's a little confusing, I know. I think the word 'New' should be added before each item.
Maybe the.NET CLR did exist and was publically documented at the time they started work on this; I'm sure you know more about that than me. However, their FAQ clearly states that they weren't aware of it at the time.
Also, I suspect they are right that a VM targeted at dynamic languages will be more efficient for running those languages than one that was primarily designed for static languages, if only because the dynamic method dispatch code that a dynamic language on a static VM would have to emit for each method call could be subsumed into a single VM instruction (I know nothing of the internals of.NET; I assume it doesn't support such an instruction). This would allow for smaller bytecode files, and therefore more efficient compilation when it reaches the JIT compiler, or more efficient interpretation when not using JIT compilation.
In addition to the other responses, there is a fairly serious architectural flaw with the python VM, that is apparently difficult, if not impossible, to fix without either seriously degrading performance or completely rewriting it from scratch (as this project is doing). It is not threadsafe.
I, for one, consider this a serious flaw that needs to be fixed before the language can be used for serious projects, as it presents a fundamental limit on scalability (adding additional processors will not make your application run faster).
While this may be solved by other reimplementations (like Jython and IronPython, which targets the.NET CLR), there remains a chance that Parrot will be officially adopted by the Python team, at which point my last remaining problem with the language will disappear.
True. The cost wouldn't be quadratic at all. It would in fact be hyperbolic, tending to infinity at the point where all of the proceeds of sale will be distributed to the licensors.
I said I didn't care about proprietary software, but I'll bite anyway.
Tell me, do you own an MP3 player? A DVD or VCD player? A digital video camera? An MPEG-accelerated video capture or display card?
All of these products' manufacturers will be licensees of MPEG related patents. Unless they're illegal grey imports, of course.
You've added an extra quantum of "their IP" to your first product, increasing your manufacturing cost by zero, and you want to charge an extra $100 for that and that alone... and you're complaining about having to pay an extra $20 in royalties in order to get an extra $80 in net profit.
First of all, their IP isn't all I'm adding to that product. I'll have my own software development costs (buying a patent license doesn't buy you an implementation), the machine will likely require a more powerful processor, because its a higher priced model it will probably sell fewer units, therefore I will have higher per-unit distribution and marketing costs on it, and so on.
I might actually end up making _less_ profit on it, because of that extra (and let's be quite clear) unfair $10 fee that you're talking about levying because you believe it would in some way be more fair.
Whichever way you look at the profits on such a piece of equipment, there is one thing that is clear: if you increase the manufacturers costs by $10, they will increase the price by that $10 to pass those costs to the consumer. That's the way business works, and because _everyone_ in the market will be licensing the same patents, you will suddenly find that the price of all DVD players that can also play DIVX (or WMV, or whatever other patented format you may be interested in) have gone up.
In fact, the cost will rise _quadratically_ with the number of patented features you want to include. If a player had MPEG2, MPEG4, WMV, WMA, MP3, WTF and FOOBAR support, each licensed at 5%, I'd have to put the price up by another $75 just to cover the cost of the licenses at $300... then there would be another $18.75 to cover the increased cost because I just put my unit price up... before you know it I'm spending over $130 on patent licenses without increasing my profits, my unit price is up to $400... and those individual licenses were priced at 5% because their owners expected systems to retail at about $200 and they wanted $10; now they're getting twice as much money for that. And they have no control over it, because they're _forced_ to work on a fixed percentage.
But you always have options. For example, you could sell just the hardware, and make the software available for free. If your product uses hardware MPEG decoders, you could sell them as add-ons to a basic unit, so that royalties are paid on the selling prices of the add-ons.
Oh, yeah, 'cause everyone wants to buy consumer electronics devices that they have to put together themselves and install software on to make them work.
Given that option 2 is not legally available for sale in most of the world, and option 1 hasn't yet been produced, I would suspect plain old standard XP. Probably with SP2.
The biggest feature I would like to see would be tools more similar to Excel VBA. It would be nice to move macros and non-trivial VBA code, not to mention leverage existing skills in VBA.
Interestingly, do the latest versions of VBA use.NET? (The latest office I've used is '97, so I'm not sure if they went that route or not)
If so, it ought to be reasonably easy to integrate mono, then all you'll have to do is build up an object model to expose to the macros and you have instant compatibility.
Strange, other than startup speeds I've had no complaint about OO's performance on my PII-300 desktop, which shouldn't be substantially different to your laptop.
As a Linux user in a corporate world full of Windows site licenses, is it possible to make it easy for OO.o users to take advantage of the Windows fonts for which they already paid?
With most modern Linux distributions, do 'locate *.ttf' to find where it's installing the truetype fonts, then copy the fonts from your windows machine to the same directory. You may need to restart X for it to notice them.
I opened it with "Spreadsheet" (offtopic aside - part of me wishes the OO.o guys had more clever names for their components, and part of me is glad they don't waste their mental energy on such trivialities:-)
Actually, OO's spreadsheet component is called 'calc'.
Is anybody actually working on the grammar checker component? My understanding was that it was an area nobody had decided they were willing to put the time in to complete.
Except what I'm not talking about is fabricating claims that are highly unlikely to be true and somehow conning people who ought to know better into believing them.
Based on another poster's description, it is a fully functional 1GHz processor intel-compatible PC. In that case you can run Linux on it if you want, but it comes with XP as standard.
Slashdot Mirror
The GPL is a license not a EULA.
What do you think the 'L' in EULA stands for?
I'm seeing increasing numbers of OSS software projects with installation programs (e.g. Windows ones) insisting that the end user accept the GPL before allowing them to install. I've asked a few about this, and the general response is, 'we need you to accept that, because that's where the "no warranty" agreement is, and we don't provide you with a warranty.'
The problem is that you can't distill the EULA's of most commercial software down to that level. It works with privacy policies because most companies are willing to work with a very loosely defined one; they just take the next available 'size' up from what they need to do with your information and use that.
You can't do that with an EULA. They contain wildly varying terms, with specific phrasing that the company's lawyers have recommended over and above any other. They're not about to choose the phrasing recommended by some standards body just to make sure it works with a piece of software they don't see the need for anyway.
If they can phrase a summary like that that contains all the information required for you to understand what you're agreeing to, there's no need for the legalese section. You don't think contracts _have_ to be written like that, do you? The only reason that they _are_ written like that is that that is the only way to include all the information that's necessary without approximating the size of war & peace.
No, they decided to put it back to the next version.
It's a lot like Bridge -- The rules say that you can't show your partner your hand and you can't tell them what you have, but you are allowed to use prearranged bidding conventions to pass information across the table.
Actually, the rules I understand for bridge specifically disallow prearranged bidding conventions that aren't well known standard conventions. But the rules of IPD don't, so I would guess it's OK there.
But it doesn't work, of course, because all you need to do to beat this strategy is mimic it until it recognises you and then not behave as it expects.
I suspect you could come up with a solution that beats this system by mimicing it, then changing its behaviour suddenly.
That's why this isn't a good answer to the problem -- not because it's somehow "cheating", but because its a strategy that only works in limited circumstances and fails spectacularly in others. Kind of like chasing down losses when gambling.
Err... what's the difference between this and iterated prisoner's dilemma?
This is because it's not a reference to the application, but to the type of document that will be created. You should also have items like 'From Template', 'HTML Document', and 'Text Document' that also follow this convention. It's a little confusing, I know. I think the word 'New' should be added before each item.
Maybe the .NET CLR did exist and was publically documented at the time they started work on this; I'm sure you know more about that than me. However, their FAQ clearly states that they weren't aware of it at the time.
.NET; I assume it doesn't support such an instruction). This would allow for smaller bytecode files, and therefore more efficient compilation when it reaches the JIT compiler, or more efficient interpretation when not using JIT compilation.
Also, I suspect they are right that a VM targeted at dynamic languages will be more efficient for running those languages than one that was primarily designed for static languages, if only because the dynamic method dispatch code that a dynamic language on a static VM would have to emit for each method call could be subsumed into a single VM instruction (I know nothing of the internals of
Well, given that many of the languages it targets support dynamic compilation, not just dynamic loading, it would have to support something similar.
In addition to the other responses, there is a fairly serious architectural flaw with the python VM, that is apparently difficult, if not impossible, to fix without either seriously degrading performance or completely rewriting it from scratch (as this project is doing). It is not threadsafe.
.NET CLR), there remains a chance that Parrot will be officially adopted by the Python team, at which point my last remaining problem with the language will disappear.
I, for one, consider this a serious flaw that needs to be fixed before the language can be used for serious projects, as it presents a fundamental limit on scalability (adding additional processors will not make your application run faster).
While this may be solved by other reimplementations (like Jython and IronPython, which targets the
True. The cost wouldn't be quadratic at all. It would in fact be hyperbolic, tending to infinity at the point where all of the proceeds of sale will be distributed to the licensors.
I said I didn't care about proprietary software, but I'll bite anyway.
... and you're complaining about having to pay an extra $20 in royalties in order to get an extra $80 in net profit.
Tell me, do you own an MP3 player? A DVD or VCD player? A digital video camera? An MPEG-accelerated video capture or display card?
All of these products' manufacturers will be licensees of MPEG related patents. Unless they're illegal grey imports, of course.
You've added an extra quantum of "their IP" to your first product, increasing your manufacturing cost by zero, and you want to charge an extra $100 for that and that alone
First of all, their IP isn't all I'm adding to that product. I'll have my own software development costs (buying a patent license doesn't buy you an implementation), the machine will likely require a more powerful processor, because its a higher priced model it will probably sell fewer units, therefore I will have higher per-unit distribution and marketing costs on it, and so on.
I might actually end up making _less_ profit on it, because of that extra (and let's be quite clear) unfair $10 fee that you're talking about levying because you believe it would in some way be more fair.
Whichever way you look at the profits on such a piece of equipment, there is one thing that is clear: if you increase the manufacturers costs by $10, they will increase the price by that $10 to pass those costs to the consumer. That's the way business works, and because _everyone_ in the market will be licensing the same patents, you will suddenly find that the price of all DVD players that can also play DIVX (or WMV, or whatever other patented format you may be interested in) have gone up.
In fact, the cost will rise _quadratically_ with the number of patented features you want to include. If a player had MPEG2, MPEG4, WMV, WMA, MP3, WTF and FOOBAR support, each licensed at 5%, I'd have to put the price up by another $75 just to cover the cost of the licenses at $300... then there would be another $18.75 to cover the increased cost because I just put my unit price up... before you know it I'm spending over $130 on patent licenses without increasing my profits, my unit price is up to $400... and those individual licenses were priced at 5% because their owners expected systems to retail at about $200 and they wanted $10; now they're getting twice as much money for that. And they have no control over it, because they're _forced_ to work on a fixed percentage.
But you always have options. For example, you could sell just the hardware, and make the software available for free. If your product uses hardware MPEG decoders, you could sell them as add-ons to a basic unit, so that royalties are paid on the selling prices of the add-ons.
Oh, yeah, 'cause everyone wants to buy consumer electronics devices that they have to put together themselves and install software on to make them work.
True, I have 256Mb of RAM in that machine, which probably helps a fair amount, and was a little unusual for machines of that age.
Given that option 2 is not legally available for sale in most of the world, and option 1 hasn't yet been produced, I would suspect plain old standard XP. Probably with SP2.
The biggest feature I would like to see would be tools more similar to Excel VBA. It would be nice to move macros and non-trivial VBA code, not to mention leverage existing skills in VBA.
.NET? (The latest office I've used is '97, so I'm not sure if they went that route or not)
Interestingly, do the latest versions of VBA use
If so, it ought to be reasonably easy to integrate mono, then all you'll have to do is build up an object model to expose to the macros and you have instant compatibility.
Writer is way too slow on my P266 laptop.
Strange, other than startup speeds I've had no complaint about OO's performance on my PII-300 desktop, which shouldn't be substantially different to your laptop.
As a Linux user in a corporate world full of Windows site licenses, is it possible to make it easy for OO.o users to take advantage of the Windows fonts for which they already paid?
With most modern Linux distributions, do 'locate *.ttf' to find where it's installing the truetype fonts, then copy the fonts from your windows machine to the same directory. You may need to restart X for it to notice them.
I opened it with "Spreadsheet" (offtopic aside - part of me wishes the OO.o guys had more clever names for their components, and part of me is glad they don't waste their mental energy on such trivialities :-)
Actually, OO's spreadsheet component is called 'calc'.
Is anybody actually working on the grammar checker component? My understanding was that it was an area nobody had decided they were willing to put the time in to complete.
SCO business model, sure, nothing broken here.
Except what I'm not talking about is fabricating claims that are highly unlikely to be true and somehow conning people who ought to know better into believing them.
G_Hz_.
Thinking about one thing while writing another. Ahem.
I dunno, I reckon a palmtop computer with a 1Gb processor and 256Mb of RAM would last longer than that site did.
Based on another poster's description, it is a fully functional 1GHz processor intel-compatible PC. In that case you can run Linux on it if you want, but it comes with XP as standard.