There are plenty of incentives to keep producing. Living in abject poverty isn't particularly compelling for most people, even if it means "sticking it to the man".
Because a majority of the people have decided that society should have that right. That the right to not starve is more fundamental than the right to keep all that you produce.
So, if someone chooses to be a farmer, do I have the right to compel them to feed me?
You, as an individual, do not. Society as a whole? Of course it does.
Also, what do you intend to do about the large number of physicians who've said that they intend to leave the profession if socialized medicine passes?
Generally people work for money. If there aren't enough physicians, subsidizing education and raising wages will probably work. If anything, physicians seem to be MORE motivated by money than the average person.
1) I can see no reason why they wouldn't be respected, but in all cases I've seen involving GPLv2 code the authors have graciously reinstated the license without additional payment. Most GPL infringement cases have involved the FSF or Harald Welte, and they have so far been very generous.
2) How would rebranding help? It's still the same code, and they still don't have a license to distribute it.
It's too late for them to publish the full source under the GPLv2. The GPLv2 termination clauses have already triggered, so they can't ever distribute (parts of) ImageMaster under the GPLv2.
Assuming that ImageMaster is under the GPLv2. I can't RTFA, because it is Slashdotted. The GPLv3 is more lenient.
I remember those days you are talking about, with networked workstations. It isn't something I want to go back to, ever. Sure, the PC world was even worse, but beating DOS isn't really much of a challenge.
Workstations are dead anyway, new computers are portable. It isn't worth optimizing anything for those stuck in the early 90's.
Closed source software would still have the library hell to contend with. No help there from FatELF. Usability-wise the users would use more bandwidth for updates and install-media would bloat up too.
If you want to help closed source software run Linux, fix the library hell. That would make a large difference.
With most systems, failure is potentially dangerous but success it harmless. The LHC is the other way around: the only way there could theoretically be a danger from the LHC is if it succeeded.
Managing binaries on local workstation drives is trivial with package handling. You're stuck in the world of 20 years ago. Should the workstation somehow fail, PXE + automatic installation will have it back up in a few minutes.
You install the 32-bit compatibility libraries and off you go? I am surprised it was much of a wrestle. Unless your distribution didn't have the versions of system libraries that the proprietary application expected, in which case you'd have exactly the same problem with the FatELF "solution".
Yes, that works on most Linux distributions. Solaris apparently does it one better and automatically boots the 64-bit kernel if available. Linux distributions should do the same.
I'm arguing that it isn't worth doing, not that it's hard (inventing FatELF isn't particular hard, although Apple managed to get a patent on the equivalent.)
Right, so you put x86 + SPARC + whatever binaries in both 32-bit and 64-bit flavours into one executable... As I said, VERY fat elves. Even if you could generate those binaries in the first place, which you can't, because you'd need cross compilers for every architecture.
In other news, you can probably afford to upgrade your 20MB disks in the workstations to say 500MB so that your binaries will fit locally. No longer will your users have to wait 30 seconds for ed to load across the 10Mbps ethernet.
In this context, Solaris is pretty much the same as a typical Linux distribution. The main difference is that it's optimized for SPARC, where you really want to run everything you can in 32-bit mode, because otherwise the slow CPU gets even slower. Solaris has an advantage in that they discovered that it's smart to run 64-bit kernel with 32-bit userland, so they include a 64-bit kernel with their otherwise 32-bit distribution. Linux really ought to do the same, running a 32-bit kernel on 64-bit capable hardware has only downsides. Solaris did it out of necessity though, because a security vulnerability in the first UltraSPARC makes it possible for any 64-bit program to crash the system (no, they did not offer refunds or exchanges for that one). Hence 64-bit kernel but pure 32-bit userland.
OS X has the advantage of just one install medium for 32-bit and 64-bit. That's where FatELF would help, but DVD's are already cramped for install media. FatELF would push lots of software to the second DVD, and then the win is gone.
Moving installed systems from 64-bit to 32-bit? I think that's very rarely done, and personally I wouldn't waste any disk space on making it possible.
The 32-bit vs. 64-bit split is handled pretty well on Linux (well, Debian drug its heels a bit on multiarch handling in packages, but even they seem to be getting with the programme).
Real multi-arch could be useful, but the number of arches on Linux is just too overwhelming. To get somewhat decent coverage for Linux binaries, they'd have to run on x86, ARM, and PPC. Plus possibly MIPS, SPARC, and Itanium. Most of those in 32-bit and 64-bit flavours. Those elves are going to be very fat indeed.
Indeed. GPG and SSH have workable trust models. Not perfect, but workable. The model in TLS is just wrong. Anything which requires me to trust the (hopefully merely incompetent) people working for Verisign is a loss.
not the opposite that happened with others blacklists in the past.
In the one instance that comes to my mind, they answered NOT blacklisted for more than a year after disabling the service. Still the queries came flooding in. In the end the choice was between abandoning the domain (and pushing all that load to the.com or whichever name servers) or answering blacklisted to make people wake up.
Slashdot Mirror
There are plenty of incentives to keep producing. Living in abject poverty isn't particularly compelling for most people, even if it means "sticking it to the man".
Because a majority of the people have decided that society should have that right. That the right to not starve is more fundamental than the right to keep all that you produce.
So, if someone chooses to be a farmer, do I have the right to compel them to feed me?
You, as an individual, do not. Society as a whole? Of course it does.
Also, what do you intend to do about the large number of physicians who've said that they intend to leave the profession if socialized medicine passes?
Generally people work for money. If there aren't enough physicians, subsidizing education and raising wages will probably work. If anything, physicians seem to be MORE motivated by money than the average person.
1) I can see no reason why they wouldn't be respected, but in all cases I've seen involving GPLv2 code the authors have graciously reinstated the license without additional payment. Most GPL infringement cases have involved the FSF or Harald Welte, and they have so far been very generous.
2) How would rebranding help? It's still the same code, and they still don't have a license to distribute it.
Cisco doesn't allow legitimate owners of their hardware to apply security patches without an exorbitantly expensive software subscription.
This is actually not true. Security patches are available without a subscription. Read the security advisories published by Cisco.
Taking advantage of the offer is sufficiently inconvenient so I don't think very many do.
No, you are defrauding whoever you sold the property to.
It's too late for them to publish the full source under the GPLv2. The GPLv2 termination clauses have already triggered, so they can't ever distribute (parts of) ImageMaster under the GPLv2.
Assuming that ImageMaster is under the GPLv2. I can't RTFA, because it is Slashdotted. The GPLv3 is more lenient.
That only applies if they provide a written offer to do so.
Not least about the author...
I remember those days you are talking about, with networked workstations. It isn't something I want to go back to, ever. Sure, the PC world was even worse, but beating DOS isn't really much of a challenge.
Workstations are dead anyway, new computers are portable. It isn't worth optimizing anything for those stuck in the early 90's.
You haven't solved all the steps backwards that FatELF represents. Especially the file size issue.
Closed source software would still have the library hell to contend with. No help there from FatELF. Usability-wise the users would use more bandwidth for updates and install-media would bloat up too.
If you want to help closed source software run Linux, fix the library hell. That would make a large difference.
With most systems, failure is potentially dangerous but success it harmless. The LHC is the other way around: the only way there could theoretically be a danger from the LHC is if it succeeded.
Managing binaries on local workstation drives is trivial with package handling. You're stuck in the world of 20 years ago. Should the workstation somehow fail, PXE + automatic installation will have it back up in a few minutes.
You install the 32-bit compatibility libraries and off you go? I am surprised it was much of a wrestle. Unless your distribution didn't have the versions of system libraries that the proprietary application expected, in which case you'd have exactly the same problem with the FatELF "solution".
Yes, that works on most Linux distributions. Solaris apparently does it one better and automatically boots the 64-bit kernel if available. Linux distributions should do the same.
How did you manage to fit the desktop disk into the laptop?
Sisyphos did something hard.
I'm arguing that it isn't worth doing, not that it's hard (inventing FatELF isn't particular hard, although Apple managed to get a patent on the equivalent.)
What do you use for return wire?
Right, so you put x86 + SPARC + whatever binaries in both 32-bit and 64-bit flavours into one executable... As I said, VERY fat elves. Even if you could generate those binaries in the first place, which you can't, because you'd need cross compilers for every architecture.
In other news, you can probably afford to upgrade your 20MB disks in the workstations to say 500MB so that your binaries will fit locally. No longer will your users have to wait 30 seconds for ed to load across the 10Mbps ethernet.
In this context, Solaris is pretty much the same as a typical Linux distribution. The main difference is that it's optimized for SPARC, where you really want to run everything you can in 32-bit mode, because otherwise the slow CPU gets even slower. Solaris has an advantage in that they discovered that it's smart to run 64-bit kernel with 32-bit userland, so they include a 64-bit kernel with their otherwise 32-bit distribution. Linux really ought to do the same, running a 32-bit kernel on 64-bit capable hardware has only downsides. Solaris did it out of necessity though, because a security vulnerability in the first UltraSPARC makes it possible for any 64-bit program to crash the system (no, they did not offer refunds or exchanges for that one). Hence 64-bit kernel but pure 32-bit userland.
OS X has the advantage of just one install medium for 32-bit and 64-bit. That's where FatELF would help, but DVD's are already cramped for install media. FatELF would push lots of software to the second DVD, and then the win is gone.
Moving installed systems from 64-bit to 32-bit? I think that's very rarely done, and personally I wouldn't waste any disk space on making it possible.
The 32-bit vs. 64-bit split is handled pretty well on Linux (well, Debian drug its heels a bit on multiarch handling in packages, but even they seem to be getting with the programme).
Real multi-arch could be useful, but the number of arches on Linux is just too overwhelming. To get somewhat decent coverage for Linux binaries, they'd have to run on x86, ARM, and PPC. Plus possibly MIPS, SPARC, and Itanium. Most of those in 32-bit and 64-bit flavours. Those elves are going to be very fat indeed.
Indeed. GPG and SSH have workable trust models. Not perfect, but workable. The model in TLS is just wrong. Anything which requires me to trust the (hopefully merely incompetent) people working for Verisign is a loss.
They don't save lives. Sockets in other countries don't kill anyone, and therefore there are noone to save.
UK plugs are just damn inconvenient and ugly. Carrying around chargers in the UK is a pain.
not the opposite that happened with others blacklists in the past.
In the one instance that comes to my mind, they answered NOT blacklisted for more than a year after disabling the service. Still the queries came flooding in. In the end the choice was between abandoning the domain (and pushing all that load to the .com or whichever name servers) or answering blacklisted to make people wake up.