IMO warez is papering over the real issue: a short-term solution that perpetuates the long-term problem.
Just as you describe, warez feeds addictions to proprietary software. And I do not think propreitary (shrinkwrapped) is healthy for the industry in the long-term.
If the same effort had instead been spent on a Software Libre replacement, we could have had more free (monetary cost) AND legal alternatives.
I think for a long time, the Earth, Moon and Mars are really going to be the limit of what humans can do.
Still, it's quite possible that the distances will not prove impossible to overcome forever. For example, Visser recently published on his findings that traversible wormholes could be created with arbitrarily small energy condition violations, which removes one of the major barriers to creating them.
We might have a steep slope to climb, but it's not at all clear that it's a vertical wall yet; we still seem to be making progress.
Nonsense. You might as well say that witchhunts were necessary precursors to modern law.
I'm not sure I agree; witchhunts were not a direct antecedent of modern law (more of an outgrowth/abuse of it), whereas alchemy was a direct antecedent of chemistry.
These are remarkably poor examples. Both fire and farming brought huge immediate benefits to the populations that pioneered them. They don't need to be justified as "adventures" or "new experiences" -- the benefits are readily apparent.
My first comparison was not with fire, but with expanding outside of tropical climates (where fire and many other things besides became necessary).
In any case, I suspect the benefits are so strongly apparent only in hindsight, and there was always a "window of risk" before even the most obvious benefits were realized.
Agriculture, to take one example, isn't easy, especially when you don't have domesticated species to begin with. The techniques have to be developed over a long period of time before an agricultural society is sustainable.
For the most part, yes, things aren't going to happen without some apparent short-term benefits. But some crazy or stupid sod is still going to have to eat the first tomato (a member of the nightshade family).
I expect human space travel will happen in its own time, and incrementally, as economic benefits become easier to realize. Certainly the noncommercial and very half-assed way NASA's doing human spaceflight isn't useful long-term.
I guess my point is that your question is legitimate, but that at this point it isn't possible to answer. We need to play with space some more first.
And alchemy, for all its occult silliness, was the necessary precursor to modern chemistry.
"I still don't get how anybody can even THINK of abandoning warm climates. Sure, fire is dangerous and hard to control. Sure, it's easier to stay where warmth isn't a problem. But CRIPES, people. It's an adventure. It's a new experience for the human race. That, IN AND OF ITSELF, is more than enough justification for continuing."
"I still don't get how anybody can even THINK of abandoning hunting and gathering. Sure, wild grasses and animals aren't very cooperative and don't want to be domesticated. Sure, it's easier to find things where they grow naturally. But CRIPES, people. It's an adventure. It's a new experience for the human race. That, IN AND OF ITSELF, is more than enough justification for continuing."
The truth is that expanding our horizons and testing our limits always pays off in big ways down the road.
Let's face it. Humans aren't built for the universe. Put down the science-fiction magazine and think about reality for a while, just because we want something to be so doesn't make it so.
Single-use values are used to represent the parts of the outside world that can change -- when, say, inserting a record into the database, you pass a value representing the database to the "insert" function, and it returns a value representing the modified database, and invalidating the previous "database" value.
Arguably the invalidation of the old value is still a side-effect, though, and it's still somewhat awkward to use.
Monads approach things the other way around, permitting you to set up purely functional "pipelines" through which state will be passed at runtime (but the state-passing need never be explicitly exposed, and in the pure sense cannot be).
Monads work very well, and maintain purity (without having to pass extra arguments around everywhere), but they're very, very mind-bending to think about until you get accustomed to them.
There are also other monad-like approaches (e.g. "arrows") which are possibly better, but this is an area that's still being actively researched.
So, it's possible today, but really it's an issue computer scientists have only recently started to experiment with in earnest; I expect we will have even better approaches for managing state in functional programs in the next few decades.
Ironically, it was Tolkien who wrote the edition of the OED "dwarf" entry that in large part promulgated the modern "dwarfs" plural in the first place.
Few authors could legitimately defend their alternate spelling (as Tolkien did) by observing that they had changed their mind since they wrote the dictionary. ^^;
[ random note: in Old English, 'f' takes on a 'v' sound when used in the middle of words; so "dwarves" is _slightly_ more "archaeically correct" than "dwarfs". I think it sounds nicer anyway. ]
3) and 4) are difficult because even if Israel backed down completely, many radical Palistinians have already comitted themselves to the complete and unconditional destruction of the Israeli state.
It's kind of a variation on the old prisoner's dilemma... if both sides remain aggressive, the status quo continues. If one side stops fighting, they get wiped out by the other side. You need to get both to back down at the same time.
Ok, that makes sense. I understand where we disagree now.
As far as I can tell, capital investment in the creation of software is qualitatively different from physical investment (e.g. building a building) in that it's not zero-sum; not sharing is a perference (which might be made for sound strategic reasons), rather than a laws-of-physics-level requirement to prevent loss of the investment.
The exceptions are:
1. if you're the only one "paying into the pool"
2. if you're selling licenses to shrink-wrapped software
In the case of #1, that is where keeping in-house software proprietary makes sense. Once you have several different entities who have started investing capital in developing software to do the same thing, it makes economic sense to pool efforts and share the costs.
A rising tide floats all boats.
As for #2, to be clear, I really don't care if the shrink-wrap software industry dies. It's not as big a portion of the software industry as most people think.
Most jobs lost would ultimately go to in-house development or specialized contractors as you describe. The demand for the software they had been producing would still remain.
The jobs would also be harder to offshore once they'd moved out of the shrink-wrap arena; developing shrink-wrap software doesn't require the same level of customer interaction that in-house or contract development does.
I don't see what that has to do with software being free or not.
The software I write for my day job is proprietary , but there are more extreme examples; consider Cygnus solutions, who, as a "third party company" charged for their work, producing GPLed software.
(maybe they did some propreitary software I've forgotten about, but the bulk of their work was contracting as I recall)
Cygnus did very well at that up to the time they were bought out by Red Hat (who try to manage through "licensing fees" which aren't quite actual licensing fees, and not doing so well).
The imposition of licensing fees are not necessary in order to be paid for services rendered; a simple contract will do.
Heck, even on an informal basis, in Inkscape we have had a couple developers who were paid to develop GPLed code for us.
Being paid for work, rather than artificial entitlements. What a novel concept.
I'm a programmer. I work for a company. They own the code. They use it themselves; they do not sell it to anyone.
I don't get royalties for any of the software I develop. I don't get paid licensing fees. I am paid wages for my time, and that is how I am paid to develop software.
That is how my working time is valued.
I don't have to subsidize my time after-the-fact with uncertain licensing fees, and if I stop working I do not continue to be paid. I am directly paid for the work I put in each day.
I think this is fair.
I represent 90% of the software industry. If all royalties and licensing fees for software were magically abolished, my job would not change at all.
While that is true, I suspect most DoS offenders already overcommit zombies, and there still seem to be large pools of idle zombies at present which could be drawn on.
Don't get me wrong, I think something like this might put the squeeze on those with smaller zombie nets, but in general I think the blackhat community would be able to cope.
I don't really see how that helps much with distributed DOS attacks, which are the most common variety these days. The number of zombie machines involved is quite mind-boggling.
So, what about public domain works? They have no copyright to sign them, and it is impossible to sign and register them all -- can they not be distributed by such a system?
If not, then it will create a situation in which only works approved (directly or indirectly) by a cenralized signing authority can be distributed. Bad if such systems become legally mandated.
On the other hand, if unsigned PD works can be distributed, then there's not much point -- you can (via analog holes if nothing else) strip the signature from a copyrighted work and distribute it that way. So there wouldn't be much point.
That is like THE most basic and obvious compression method, ever. And was most certainly repeatedly discovered many times decades ago. And is used in pretty much everything someplace.
For those of you unfamiliar with it, it consists of alternating counts and data; each count indicates how many times the following bit of data is repeated. For example:
784 784 34 34 34 34 2
RLE compresses to:
2 784 4 34 1 2
A common enhancement is to mark long sequences without repeats (since they don't RLE compress well), and include them literally, preceded by their length.
Slashdot Mirror
IMO warez is papering over the real issue: a short-term solution that perpetuates the long-term problem.
Just as you describe, warez feeds addictions to proprietary software. And I do not think propreitary (shrinkwrapped) is healthy for the industry in the long-term.
If the same effort had instead been spent on a Software Libre replacement, we could have had more free (monetary cost) AND legal alternatives.
No argument there.
I think for a long time, the Earth, Moon and Mars are really going to be the limit of what humans can do.
Still, it's quite possible that the distances will not prove impossible to overcome forever. For example, Visser recently published on his findings that traversible wormholes could be created with arbitrarily small energy condition violations, which removes one of the major barriers to creating them.
We might have a steep slope to climb, but it's not at all clear that it's a vertical wall yet; we still seem to be making progress.
I'm not sure I agree; witchhunts were not a direct antecedent of modern law (more of an outgrowth/abuse of it), whereas alchemy was a direct antecedent of chemistry.
My first comparison was not with fire, but with expanding outside of tropical climates (where fire and many other things besides became necessary).
In any case, I suspect the benefits are so strongly apparent only in hindsight, and there was always a "window of risk" before even the most obvious benefits were realized.
Agriculture, to take one example, isn't easy, especially when you don't have domesticated species to begin with. The techniques have to be developed over a long period of time before an agricultural society is sustainable.
For the most part, yes, things aren't going to happen without some apparent short-term benefits. But some crazy or stupid sod is still going to have to eat the first tomato (a member of the nightshade family).
I expect human space travel will happen in its own time, and incrementally, as economic benefits become easier to realize. Certainly the noncommercial and very half-assed way NASA's doing human spaceflight isn't useful long-term.
I guess my point is that your question is legitimate, but that at this point it isn't possible to answer. We need to play with space some more first.
Yes, I am.
And thank you, I shall give your regards to the other developers. ^_^
And alchemy, for all its occult silliness, was the necessary precursor to modern chemistry.
"I still don't get how anybody can even THINK of abandoning warm climates. Sure, fire is dangerous and hard to control. Sure, it's easier to stay where warmth isn't a problem. But CRIPES, people. It's an adventure. It's a new experience for the human race. That, IN AND OF ITSELF, is more than enough justification for continuing."
"I still don't get how anybody can even THINK of abandoning hunting and gathering. Sure, wild grasses and animals aren't very cooperative and don't want to be domesticated. Sure, it's easier to find things where they grow naturally. But CRIPES, people. It's an adventure. It's a new experience for the human race. That, IN AND OF ITSELF, is more than enough justification for continuing."
The truth is that expanding our horizons and testing our limits always pays off in big ways down the road.
Let's face it. Humans aren't built for the universe. Put down the science-fiction magazine and think about reality for a while, just because we want something to be so doesn't make it so.
We have to go and make it so.
z teechz bd 4 h8n ppl writ liek thiz or z ppl bd 4 writ liek thiz LOLZ
Lameness filter go away, come again another day.
The C standard doesn't guarantee optimization tail-recursion; and while gcc does it (to a limited extent), many compilers do not.
Additionally, it's sometimes important to compile your code without any optimization during debugging.
Relying on tail recursion is really only possible in languages where the standard guarantees support.
At least stylesheets make this sort of repair possible. Imagine what it would be like if you just had a bunch of font tags to contend with.
In holographic disks... Greedo shoots you?
Use e.g. monads or "single-use" values.
Single-use values are used to represent the parts of the outside world that can change -- when, say, inserting a record into the database, you pass a value representing the database to the "insert" function, and it returns a value representing the modified database, and invalidating the previous "database" value.
Arguably the invalidation of the old value is still a side-effect, though, and it's still somewhat awkward to use.
Monads approach things the other way around, permitting you to set up purely functional "pipelines" through which state will be passed at runtime (but the state-passing need never be explicitly exposed, and in the pure sense cannot be).
Monads work very well, and maintain purity (without having to pass extra arguments around everywhere), but they're very, very mind-bending to think about until you get accustomed to them.
There are also other monad-like approaches (e.g. "arrows") which are possibly better, but this is an area that's still being actively researched.
So, it's possible today, but really it's an issue computer scientists have only recently started to experiment with in earnest; I expect we will have even better approaches for managing state in functional programs in the next few decades.
Hmm, thank you. I think that is a much better analysis.
Ironically, it was Tolkien who wrote the edition of the OED "dwarf" entry that in large part promulgated the modern "dwarfs" plural in the first place.
Few authors could legitimately defend their alternate spelling (as Tolkien did) by observing that they had changed their mind since they wrote the dictionary. ^^;
[ random note: in Old English, 'f' takes on a 'v' sound when used in the middle of words; so "dwarves" is _slightly_ more "archaeically correct" than "dwarfs". I think it sounds nicer anyway. ]
3) and 4) are difficult because even if Israel backed down completely, many radical Palistinians have already comitted themselves to the complete and unconditional destruction of the Israeli state.
It's kind of a variation on the old prisoner's dilemma... if both sides remain aggressive, the status quo continues. If one side stops fighting, they get wiped out by the other side. You need to get both to back down at the same time.
Wow, it makes Roujin Z sound prophetic, doesn't it?
Most modern virtual machines have some form of JIT compilation, Parrot included.
So, no, having a VM doesn't necessarily mean emulation at instruction-level granuarity.
Ok, that makes sense. I understand where we disagree now.
As far as I can tell, capital investment in the creation of software is qualitatively different from physical investment (e.g. building a building) in that it's not zero-sum; not sharing is a perference (which might be made for sound strategic reasons), rather than a laws-of-physics-level requirement to prevent loss of the investment.
The exceptions are:
1. if you're the only one "paying into the pool"
2. if you're selling licenses to shrink-wrapped software
In the case of #1, that is where keeping in-house software proprietary makes sense. Once you have several different entities who have started investing capital in developing software to do the same thing, it makes economic sense to pool efforts and share the costs.
A rising tide floats all boats.
As for #2, to be clear, I really don't care if the shrink-wrap software industry dies. It's not as big a portion of the software industry as most people think.
Most jobs lost would ultimately go to in-house development or specialized contractors as you describe. The demand for the software they had been producing would still remain.
The jobs would also be harder to offshore once they'd moved out of the shrink-wrap arena; developing shrink-wrap software doesn't require the same level of customer interaction that in-house or contract development does.
To put it another way, I prefer measuring work in units of "billable hours".
I don't think it's equitable to pretend that "licenses sold" is a measure of work, whatever my opinions on charging for licenses might be.
If I were to live off of licensing fees alone, I wouldn't be being paid for my work, I would be subsidizing it.
I don't understand you.
Of course my work is not free.
I don't see what that has to do with software being free or not.
The software I write for my day job is proprietary , but there are more extreme examples; consider Cygnus solutions, who, as a "third party company" charged for their work, producing GPLed software.
(maybe they did some propreitary software I've forgotten about, but the bulk of their work was contracting as I recall)
Cygnus did very well at that up to the time they were bought out by Red Hat (who try to manage through "licensing fees" which aren't quite actual licensing fees, and not doing so well).
The imposition of licensing fees are not necessary in order to be paid for services rendered; a simple contract will do.
Heck, even on an informal basis, in Inkscape we have had a couple developers who were paid to develop GPLed code for us.
Being paid for work, rather than artificial entitlements. What a novel concept.
You misunderstand the software industry.
I'm a programmer. I work for a company. They own the code. They use it themselves; they do not sell it to anyone.
I don't get royalties for any of the software I develop. I don't get paid licensing fees. I am paid wages for my time, and that is how I am paid to develop software.
That is how my working time is valued.
I don't have to subsidize my time after-the-fact with uncertain licensing fees, and if I stop working I do not continue to be paid. I am directly paid for the work I put in each day.
I think this is fair.
I represent 90% of the software industry. If all royalties and licensing fees for software were magically abolished, my job would not change at all.
Except perhaps I could be more productive.
And less likely to get my job "offshored".
While that is true, I suspect most DoS offenders already overcommit zombies, and there still seem to be large pools of idle zombies at present which could be drawn on.
Don't get me wrong, I think something like this might put the squeeze on those with smaller zombie nets, but in general I think the blackhat community would be able to cope.
I don't really see how that helps much with distributed DOS attacks, which are the most common variety these days. The number of zombie machines involved is quite mind-boggling.
So, what about public domain works? They have no copyright to sign them, and it is impossible to sign and register them all -- can they not be distributed by such a system?
If not, then it will create a situation in which only works approved (directly or indirectly) by a cenralized signing authority can be distributed. Bad if such systems become legally mandated.
On the other hand, if unsigned PD works can be distributed, then there's not much point -- you can (via analog holes if nothing else) strip the signature from a copyrighted work and distribute it that way. So there wouldn't be much point.
RLE? Saints preserve us...
That is like THE most basic and obvious compression method, ever. And was most certainly repeatedly discovered many times decades ago. And is used in pretty much everything someplace.
For those of you unfamiliar with it, it consists of alternating counts and data; each count indicates how many times the following bit of data is repeated. For example:
784 784 34 34 34 34 2
RLE compresses to:
2 784 4 34 1 2
A common enhancement is to mark long sequences without repeats (since they don't RLE compress well), and include them literally, preceded by their length.