Ahh, but so far all the terrorists have been Muslim.
Oh, sure. How about Timothy McVeigh (a vaguely right-wing "survivalist"), Eric Robert Rudolph (an adherent of the "Christian Identity" movement), Yigal Amir (an ultra-orthodox jew), the ELF, the pre-1988 PLO (left-wing pan-arabists), the IRA (catholics), the ULF (protestants), the ETA (Basque socialist separationists), the PKK (Kurdish Marxist-Leninist separationists), the RAF (German communists), the Brigate Rosse (Italian communists),... the list goes on and on. Terrorism didn't begin on 9/11, and islamic extremism is but one of many belief systems people seem to be willing to kill and die for, and not the first such belief system that opposes "western civilisation" or the US in particular.
But so far I really haven't seen any wide Muslim condemnation of the acts of the terrorists. Until that happens, then sorry if I make connections based on HISTORY.
Try this collection of statements for a start. Finding this took me all of 10 seconds on google. Just because you don't hear about this on Fox doesn't mean it's not out there.
Do some research before you make such sweeping generalizations in public. And, before making connections based on history, read up on it.
Yes, but, to reiterate the title of my first comment, does it help? I think the language currently in section 1, paragraph 4 is throwing the baby out with the bathwater, while getting the bathwater all over the floor in the process. You do realize that the FSF's response to hardware manufacturers claiming to need control over installed software is, "Well, put it in ROM, then, that way noone will be able to upgrade, and you're in compliance again", right?
Yes, but everyone is worse off in that situation. I find the logic behind this deeply repulsive. As I wrote elsewhere in this thread (and sent to the FSF as well):
In essence, it states:
any degree of freedom is acceptable if everyone has the same freedom.
users should be concerned with freedom first, maintainability, security, and upgradeability second
hardware developers looking to make sure that they know what they sell - to be able to support it, for example, not to bask in the glory of having more freedom than their users - should use proprietary software or make everyone's life more difficult
the concerns of software developers who worry about tivoization of their work are unimportant if the "tivoizer" locks the code down hard enough.
Of these statements, only the second could maybe have been construed as an FSF position earlier. The rest is just plain idiotic, no matter what side you're on.
> If you think the license has the balance wrong, comment on it at http://gplv3.fsf.org./
My basic objections - in soundbite form, as unfortunately encouraged by the interface - seem to have been submitted already; I'll still mail the text below to the comment system, in the hope that a human being might encounter it somewhere in there.;)
That was a very interesting read indeed, and confirms that Linus was and still is wrong about the process. I still think he's right about the result so far, though. Here's what I'll submit to the e-Mail comment system in a few minutes, both "for the record" of this thread, and as a shameless attempt to exploit the attention of a committee member, if it does get dropped:
I feel deeply uncomfortable with the following section, specifically with the *marked* sentences:
Terms and Conditions, section 1, paragraph 4
The Corresponding Source also includes any encryption or authorization keys necessary to install and/or execute modified versions from source code in the recommended or principal context of use, such that they can implement all the same functionality in the same range of circumstances. (For instance, if the work is a DVD player and can play certain DVDs, it must be possible for modified versions to play those DVDs. *If the work communicates with an online service, it must be possible for modified versions to communicate with the same online service in the same way such that the service cannot distinguish.*) A key need not be included in cases where use of the work normally implies the user already has the key and can read and copy it, as in privacy applications where users generate their own keys. *However, the fact that a key is generated based on the object code of the work or is present in hardware that limits its use does not alter the requirement to include it in the Corresponding Source.*
This specifically allows modified versions to hide the fact that they are modified. Thereby it creates two technical problems:
it makes it impossible to verify and certify distributed systems consisting in whole or in part of (derived works of) Free Software.
it makes it impossible to verify the integrity of a distribution package consisting of Free Software and hardware and/or non-free software, e.g. to determine eligibility for support or warranties.
These seem to me to exclude Free Software from a substantial set of reasonable and legitimate applications in existence today or foreseeable for the future.
Additionally, it seems to be in conflict with the following provision:
Terms and Conditions, section 5, paragraph 2
a) The modified work must carry prominent notices stating that you changed the work and the date of any change.
In particular, the section quoted earlier seems to amend this with, "unless the notice would be machine-readable, in which case the modified work may choose not to carry such a notice". This serves as a strong deterrent to authors of original works to free those works if they customarily provide them e.g. as part of a hardware package on which they in turn provide a warranty.
Lastly, this whole issue seems to open up a veritable can of worms with regards to the definition of "derived work" vs. "aggregate". In the case of Tivo for example, the distribution package consists of a computer with some proprietary hardware on which some free software and some proprietary software is installed, all of which works properly only in connection with an online service. Now for some reasons, the proprietary software part is s
> The DRM provisions in the GPLv3 that Linus is complaining about are there to help ensure that FOSS developers like Linus will not be locked out from developing software on future generations of computers.
How exactly, by which mechanism, does licensing software under the GPLv3 prevent crippled machines taking over the market to the point where it's prohibitively expensive to buy a non-crippled computer? Note that I don't believe that that will happen, but if it were to happen, how would the GPLv3 save us (apart from prohibiting users to run their software on their machines, just like Tivo is doing right now)?
I honestly don't get it. Are we expecting Microsoft to switch to GPLv3 any time soon?
> Didn't their customer purchase the product? Why shouldn't I as a consumer be able to modify a product that I've purchased to implement whatever fixes or features I want the product to run?
Would it advance the overall level of freedom if the customer were unable to purchase the product in question, but instead had to rent it from the manufacturer, signing a contract that would make him subject to a heavy fine for replacing the software? Would that be compliant with the GPLv3?
Or to look at this from a slightly different angle, how about putting the software in an SMD ROM chip with a blob of glue on top? That is compliant with the GPLv3 (see the link I posted in another response on this thread). Whose freedoms does that protect?
> Why are hardware developers so special? Why do they deserve their own privileged class with respect to FLOSS users/developers?
Simple. Economics. It is not cheap to supply hardware to your customers, and for many applications, customers are unwilling to pay the actual cost of the hardware. Think game consoles, cell phones, Tivo and friends.
> It seems to me that Linus (and you) are identifying too much with the hardware developers and forgetting the perspective of software developers! Let alone end users.
End users wishing to buy a general purpose computer that can act as a PVR should buy just that. As for the freedom to fix what you bought, that's not guaranteed by the GPLv3. Even the FSF sort-of admits this, in the context of regulatory compliance:
But if there really are regulations which forbid software on certain devices from being modified once it's installed, it's still possible to use software licensed under the GPL -- simply burn the software into a ROM. Then nobody can upgrade it without replacing the ROM. Of course, device manufacturers will protest that this prevents them from upgrading it themselves. This shows that their true desires are not to comply with FDA rules, but to get special rights that nobody else has.
Does that sound like a logical argument to you? Is this really about users' freedoms?
> Arguments about "more people will develop for/with free software if we simply don't insist that it be free" have always been stupid and always will be.
Fully agreed. However, the world in which RMS (and I) would like to live in is one in which for any reasonable task you want to do, there's a Libre option. We're not getting closer by excluding certain applications by default.
There is one other interesting point that just happened to cross my mind. Imagine google was built on a GPLv3 foundation. If the original authors added the appropriate clause, they'd have to make their source code downloadable. That's fair. However, if I downloaded said code and modified it to suit my tastes, should they then be required to run my version on google.com, so that I can use the code in the same context from which I received it?
BTW, just for the record, I'm not a hardware manufacturer, nor do I work for one. I'm an independent software developer building FOSS-based billing/accounting/CRM/etc. systems (for food) and music production software (for fun).
> I mean, who cares if Joe Hacker can see and make their own versions of the voting software, as long as he can't install it on the voting machines on election day. This is a social problem of having safeguards and procedures, not a question of open or closed sources.
I don't worry about Joe Hacker the outsider, I worry about the people who legitimately have access to the voting machines. If they can install modified software on the machines without the machine ceasing to function, the integrity of the machine can be breached. The GPLv3 explicitly prohibits the manufacturer of the machine to make sure that that doesn't happen, in effect making a voting machine using GPLv3 software uncertifiable.
Not to mention medical devices. Or devices that handle payment transactions, like this one (unfortunately in German only). Do we, as the Free Software community, go on record stating, "well, for this sort of thing, Free Software is just not the solution"?
As far as I can see it, DRM technology poses three distinct major threats to developers' and users' freedoms:
1. locked digital media This is where the GPLv3 works, sort of. You cannot take a GPLv3ed media player, add some DRM component, and distribute the result while keeping the key that unlocks the media secret. That's fair. Unfortunately, there is a large range of non-GPLed media players available. In the end, FOSS users will still have to resort to hacks, but they're not worse off in that respect than they are now, and at least the code they worked on won't be used to prevent them from doing what they want.
2. locked FOSS-using devices (the Tivo scenario) I think the FSF, and software developers advocating GPLv3, are seriously overstepping their bounds here. Basically, they're telling hardware developers that in order to use FOSS, not only do they need to give freely what they freely received (which is just reasonable), but they also have to make THEIR OWN product convertable to any use their customers see fit. This immediately excludes building devices that need to assure overall system integrity (from fair network gaming through to voting machines) and also excludes a number of fairly reasonable business models (hardware has a significantly non-zero duplication cost, unlike software, and the money has to come from somewhere). Alternatively, they can choose to make their machines physically tamper-proof (which defeats the intent of the license, makes the license unverifiable, and the product unrepairable in case of software problems). The net result will simply be that hardware developers will stop considering the use of FOSS, which will lead to them getting what they want anyway, FOSS code getting less exposure and less fixes, and end users receiving an arguably less technologically sound product at a higher price.
3. locked general-purpose computers The GPLv3 can't do squat about thread 3. If such devices do indeed appear, they will simply not be running FOSS. Ever. Because even if a vendor would like to offer an OS based on some hypothetical GPLv3ed kernel, the license wouldn't allow it.
So, looking at the above, I can't help but think that Linus is right here. I have the utmost respect for RMS and the members of the various committees, I'm even a paid-up and (CD-)card-carrying member of the FSF (#2342), but so far they have failed in providing a satisfactory solution to the problems ahead.
#3: As a newbie admin, late at night, I copied some.-files and -dirs from user a to user b as root, and then did the following:
cd/home/b
chown -R b:users.*
When that didn't come back after 5 seconds I realized what I had done and canceled it. Luckily, someone in the first 50 or so users had like a million files in their home, so cleaning up the mess took just three hours.
#2: After a brownout we discovered that one of the production machines crapped all over its/etc (bad UPS), making logins impossible. Luckily, there was a root session left on the console. Some 30 minutes later we had what we believed to be the complete set of files back from lost+found, but I wanted to make sure by comparing them to the/etc of a nearly identical second machine. So I logged into that one, and proceeded to clean up the editor backups to make comparing easier. I typed
cd/etc
rm * ~
and got the reply
rm: cannot remove `~': No such file or directory
I literally smashed the keyboard. I still have a scar on my right palm from that one.
#1: Since we had reason not to trust our mains power, we moved a cluster of server machines from the company's basement to a hired data center. This was fully redundant hardware, down to the doubled independent power supplies. The data center provided four separate mains circuits to the racks, UPS, diesel generator, the works. A week after the move, one of the servers died when one of the mains circuits went down for repairs.
It turned out that someone had managed to plug both power supplies into the same circuit.
This is fundamentally boring stuff, but easy to get wrong, with potentially disastrous consequences. So, instead of shelling out big bucks for 'COTS'-ware, violating your own IT policies, and costing you an additional bag of appendages for the consulting work necessary to get it running, I'd rather buy this as a service.
Incidentally, I work for a company that sells that kind of service (not in the US, though, but it's a rather obvious business model, so there will be someone in your area for sure). To give you an idea: we handle over 200 million calls a month (order management, provisioning, rating, billing, invoicing, payment handling, dunning, customer care, call-center support, the whole chain) using a near-FOSS system that we built and run in-house. The only proprietary components are IBM DB2 and the Sun JDK.
For lowish transaction volumes, we can afford to be cheaper than a bare software license, and as an added benefit we know what we're doing, so your auditors will be happier, too. So, go and find one of our competitors.;)
There's quite a few, actually. RME cards are what Paul Davis recommends; if you can do without quite as many channels, the M-Audio Delta series (especially the PCI-based options) work quite nicely as well.
I personally run MusE/Jack on an M-Audio Delta 1010LT (8 channels analog i/o + S/PDIF stereo i/o) at 24/96 and have yet to run into serious problems.
We all know the classics - Foundation, Dune, Star Wars... here's a couple of maybe less well-known options:
William Barton: Dark Sky Legion
Now, this is not High Art(tm), but its premise is very original, and Barton manages to pull it off: a galaxy-wide civilization of human colonies, established and held together solely by slower-than-light space ships. Currently out of print, but well worth tracking down.
David Brin: The Uplift Trilogies
Space Opera at its finest. If you read Brin's other works and didn't like them, try it anyway. If you read Sundiver and didn't like it, keep going anyway. Featuring truly alien aliens, insights into the thought patterns of space-faring dolphins, psi weaponry, privacy wasps, and more ways to cheat Einstein than Tesla would've dared to imagine - and all that in impeccable prose. Dune looks positively deserted in comparison.
Stanislav Lem: Golem
Lectures on life delivered by a machine vastly more intelligent than any human could hope to become. This should rightly be impossible to do convincingly, given that the writer is human after all, but at least in the German translation he is frighteningly convincing. So, until I find the time to learn Polish to read the original, I have to operate under the assumption that Lem is either an alien or a time traveller. For me, that makes our own universe a lot more interesting than any of the above.
IMHO, the problem with 'gurus' teaching 'users' has nothing to do with their relative intelligence. Rather, it's an issue of the semantics of teaching, or more specifically, teaching the use of computers. To a 'guru', teaching the use of computers means getting their student to the point where they can figure out what's going on when confronted with a new program, task, or problem on their own, by connecting it to what they already know. This is called understanding, but that's not what 'users' are used to in the context of computers. What's worse, it is continually suggested to them that it's not what they want.
To quote from the linked article:
People using their computers don't need to know much beyond "Push button A and action B results." They don't need to get confused with a lot of complex commands while they're just starting to figure out the way to do things in Linux that they already knew how to do in Windows. That basic level of knowledge is enough for a start - and for a good while afterwards.
This is the basic problem. Telling someone "To A, push B" is not teaching, it's more like programming the student. The student will not understand what they are doing. They'll end up with an unconnected heap of little task descriptions in their head; actually, a lot of people end up with a heap of Post-its glued to their screens and keyboards. They are unprepared to cope with B not causing A (at best they'll reboot, typically they'll call tech support), and if they're given new software where B happens to look a lot more like C and is 5 inches off to the left, they'll need retraining.
That sort of thing doesn't happen with, say, cars. But contrary to popular opinion, that's not because cars are easy, it's because Driving School actually teaches you something, while 'Computer User School' does not.
One can only speculate as to the reasons behind that; after all, driving schools surely wouldn't complain if their students had to return at regular intervals to be told that "in this new and improved model, the windshield wiper switch is now located on the second stick right of the wheel". But in the computer user world, this is exactly how it works. The end result is the perpetual myth that computers are complicated and hard to use, plus excellent job opportunities for 'teachers'.
Feh, that came out rather rambling... Thanks for reading it anyway.;)
Right now, you can't *just* deploy a Linux PC to a former Windows user.
As a matter of fact, you can't *just* deploy anything but Windows to a 'Windows user'. For the average corporate officebeing, a Windows/MS Office upgrade comes with a week of mandatory training and two months minimum of fiddling and frantic support calls until all those little post-it notes that detail the clicks needed to print to that other printer down the hall etc. etc. are updated. To them, the oft-touted 'user-friendliness' of Windows is little more than an urban legend.
On the other hand, people who are not irrationally afraid of computers in general will hardly notice the difference. My girlfriend's just as happy with 4DWM on my Indigo2 as she's with her Win98 box, and she's in marketing...;)
Transmeta's TM5600 processor (built into a Sony Vaio) is currently undergoing c't labs' scrutiny. The first benchmark results put it into the range between a Pentium III-400 (e.g. the c't Mandelbrot fractal at about 15 million iterations per second) and a Pentium III-600. Memory performance is impressive for a small notebook, starting with about 60MB/s for MemCopy and increasing to about 170MB/s for cache hits within the processor's translation buffer. Write performance (measured via Memset) peaks at about 280MB/s. In comparison, a Pentium III-500 with Via-Apollo-II chipset won't reach more than 70MB/s and 150MB/s, respectively. A Pentium III-Coppermine-800 on a Solano i815 board comes in close at 190 and 255MB/s.
Another interesting fact is that the Crusoe processor supplies a serial number via CPUID, which cannot be disabled, at least in the Vaio configuration. This serial number seems however to be generated exclusively by the code-morphing software. The "true" CPUID command (compatible with the AMD Athlon) does not yield a serial number. Additionally, Transmeta declared the otherwise flawlessly functional CMPXCHG8 command as not available in the list of official features, since Windows NT can't cope with a Pentium-class processor (family ID 5) supplying this feature.
Further benchmarks and power consumption measures will be published by c't during the next week.
Granted, it's ugly, but at least in my experience, it's not as ugly in practice as it looks in theory. For GUI code, the Qt-supplied containers are all you'll need, and QString is a godsend compared to STL string, especially if you're dealing with internationalization issues.
Down in the layers that do the actual work, I tend to use STL containers for reasons like uniformity with low-level libraries etc. I have yet to encounter a situation where that approach causes actual ugliness in my code - YMMV, of course.
[...] That's why Qt still seems to hold the edge despite the zillion disadvantages that it entertains. [...]
Apart from the GPL incompatibility of QPL 1.0 (which is on its way out), and the preprocessor (which is about as non-intrusive as it gets with three extra lines in your Makefile), what disadvantages did you notice? Note that I'm referring to Qt2.x, so lack of themeability is out...
Same here, initially ("Germany" in this case). It took me five tries to figure out that it expects an ISO country code. "UK" or "GB" should work for you; "DE" did it for me.
After I finally donated my modest $50, I sent mail to the site's admin, explaining the situation, and pledged another $100 if they managed to fix that.
Given these factors, I'd suggest you simply stay closed-source. You'll have a hard-enough time making money from this anyway, even then.
If your customers demand source, sell it to them, but don't give it away. If you feel you need to give back to the community, there might be other, better ways - how about sponsoring development of free software you use, for example?
To wit: the company I work for makes extensive use of MICO, Xalan, Xerces, and Apache. We're closed source, but we contribute fixes, fund MICO-MT development, and will soon sponsor standardization committee activities for XML-Apache. In the end, everyone's happy. Maybe that would work for you, too?
There are two different issues at play here: firstly, GPL compatibility, and secondly, availability for closed source development at no charge.
The QPL is incompatible with the GPL due to the "changes may be only distributed as patches" clause. This is just plain silly, but a fact of life. When writing new code, you can grant a licence exception and be done with it.
Contrary to popular opinion, the QPL does NOT restrict you further in any way that the GPL doesn't. You can sell your apps, as long as you supply source code. You can port all of Qt to Windows, as long as you distribute that port as archive + patchset. You can't use Qt to write closed-source apps without paying Troll Tech, but then again you can't use GDBM that way either (it's GPLed, not LGPLed). So where's the problem?
The current OpenMOTIF license is, too, incompatible with the GPL. You can't take GPLed Motif code, link with Open Motif, and redistribute. The incompatibility isn't silly, either: you cannot allow your users to port away from the freeNIXes.
As far as closed-source development goes, it's just as impossible without paying up as it is with Qt. But - do we really care about that?
That's just brilliant - it basically amounts to a grand new scheme for copyright holders to make more money. Encrypt it, and suddenly not only can you sell licenses for use of your actual property, you can additionally sell licenses for the manufacture and sale of decryption devices.
I can see it now. "This software is not licensed for use on non-Intel processors." Then add region coding... "This software is not licensed for use in the UK." Before you know, it'll be illegal to carry laptops on intercontinental flights, because of copyright issues.
Sometimes I wonder what customers of "high-tech products" can be reliably expected to put up with. I mean, who'd buy books that you could only read wearing the right glasses?
Problems unsolvable by computers roughly fall into three categories:
1. Mathematically proven impossible
The Halting Problem and similar. These are inherently impossible to solve exactly or exhaustively. Note that this impossibility applies regardless of whether the entity tackling the problem is carbon-based or silicon-based.
2. Theoretically possible (exact algorithm is known), but time-/space-consuming.
The Traveling Salesman and his friends in NP. The jury is still out on whether their intractability is a human limitation (i.e. we just haven't managed to come up with a working algorithm in P) or whether they're really that hard, but if the latter is true, then again they're hard to solve exactly for anyone, not just computers.
3. Things involving creativity, feelings, "true understanding", etc.
A suprising number of technically knowledgeable people are willing to grant that one without further questioning, and that's understandable. After all, one can't quite imagine what an algorithm for coming up with a new idea or a subroutine for falling in love would look like, and yet humans are able to DO these things, and they're easy.
So why is it hard to teach a machine to do that? Well, look at it from a different angle: how hard is it to teach a human to do that? Have you ever tried to explain what exactly "being in love" is? The best we've come up with so far in that area is art, music, poetry, which seems to evoke similar feelings in different people, but that's by no means fail-safe. So, from a not too unlikely point of view, humans can't do these things either - we don't know how to do them. They do us instead. Machines might suffer from the same shortcoming, but given the state of our knowledge about this area of human behaviour, we're not even in a position to find out yet.
But then again, maybe the author of the book reviewed here has found a way...
I knew I should've explained these... you see, we have about 45 fish and ramen dishes around, and a lot of the new folk we hired don't even like sushi, so what we switched to were more descriptive terms. To wit:
ryouko (= good writing) is a printer yakuza is a VMWare Win98 setup on a linux box. We needed something evil there... karoshi and seppuku belong to quality control folks. The connection is obvious. ronin (= the lordless samurai) is a shared notebook.
Slashdot Mirror
Oh, sure. How about Timothy McVeigh (a vaguely right-wing "survivalist"), Eric Robert Rudolph (an adherent of the "Christian Identity" movement), Yigal Amir (an ultra-orthodox jew), the ELF, the pre-1988 PLO (left-wing pan-arabists), the IRA (catholics), the ULF (protestants), the ETA (Basque socialist separationists), the PKK (Kurdish Marxist-Leninist separationists), the RAF (German communists), the Brigate Rosse (Italian communists),
Try this collection of statements for a start. Finding this took me all of 10 seconds on google. Just because you don't hear about this on Fox doesn't mean it's not out there.
Do some research before you make such sweeping generalizations in public. And, before making connections based on history, read up on it.
Yes, but, to reiterate the title of my first comment, does it help? I think the language currently in section 1, paragraph 4 is throwing the baby out with the bathwater, while getting the bathwater all over the floor in the process. You do realize that the FSF's response to hardware manufacturers claiming to need control over installed software is, "Well, put it in ROM, then, that way noone will be able to upgrade, and you're in compliance again", right?
Of these statements, only the second could maybe have been construed as an FSF position earlier. The rest is just plain idiotic, no matter what side you're on.
My basic objections - in soundbite form, as unfortunately encouraged by the interface - seem to have been submitted already; I'll still mail the text below to the comment system, in the hope that a human being might encounter it somewhere in there.
> [...] (I'm on Committee D, in case it wasn't clear.) You can see what else I've written on it [...]here: http://svn.donarmstrong.com/don/trunk/projects/gpl v3/issues/drm_allowing_authentication/.
That was a very interesting read indeed, and confirms that Linus was and still is wrong about the process. I still think he's right about the result so far, though. Here's what I'll submit to the e-Mail comment system in a few minutes, both "for the record" of this thread, and as a shameless attempt to exploit the attention of a committee member, if it does get dropped:
I feel deeply uncomfortable with the following section, specifically with the *marked* sentences:
This specifically allows modified versions to hide the fact that they are modified. Thereby it creates two technical problems:
These seem to me to exclude Free Software from a substantial set of reasonable and legitimate applications in existence today or foreseeable for the future.
Additionally, it seems to be in conflict with the following provision:
In particular, the section quoted earlier seems to amend this with, "unless the notice would be machine-readable, in which case the modified work may choose not to carry such a notice". This serves as a strong deterrent to authors of original works to free those works if they customarily provide them e.g. as part of a hardware package on which they in turn provide a warranty.
Lastly, this whole issue seems to open up a veritable can of worms with regards to the definition of "derived work" vs. "aggregate". In the case of Tivo for example, the distribution package consists of a computer with some proprietary hardware on which some free software and some proprietary software is installed, all of which works properly only in connection with an online service. Now for some reasons, the proprietary software part is s
> The DRM provisions in the GPLv3 that Linus is complaining about are there to help ensure that FOSS developers like Linus will not be locked out from developing software on future generations of computers.
How exactly, by which mechanism, does licensing software under the GPLv3 prevent crippled machines taking over the market to the point where it's prohibitively expensive to buy a non-crippled computer? Note that I don't believe that that will happen, but if it were to happen, how would the GPLv3 save us (apart from prohibiting users to run their software on their machines, just like Tivo is doing right now)?
I honestly don't get it. Are we expecting Microsoft to switch to GPLv3 any time soon?
> Didn't their customer purchase the product? Why shouldn't I as a consumer be able to modify a product that I've purchased to implement whatever fixes or features I want the product to run?
Would it advance the overall level of freedom if the customer were unable to purchase the product in question, but instead had to rent it from the manufacturer, signing a contract that would make him subject to a heavy fine for replacing the software? Would that be compliant with the GPLv3?
Or to look at this from a slightly different angle, how about putting the software in an SMD ROM chip with a blob of glue on top? That is compliant with the GPLv3 (see the link I posted in another response on this thread). Whose freedoms does that protect?
Simple. Economics. It is not cheap to supply hardware to your customers, and for many applications, customers are unwilling to pay the actual cost of the hardware. Think game consoles, cell phones, Tivo and friends.
> It seems to me that Linus (and you) are identifying too much with the hardware developers and forgetting the perspective of software developers! Let alone end users.
End users wishing to buy a general purpose computer that can act as a PVR should buy just that. As for the freedom to fix what you bought, that's not guaranteed by the GPLv3. Even the FSF sort-of admits this, in the context of regulatory compliance:
Does that sound like a logical argument to you? Is this really about users' freedoms?
> Arguments about "more people will develop for/with free software if we simply don't insist that it be free" have always been stupid and always will be.
Fully agreed. However, the world in which RMS (and I) would like to live in is one in which for any reasonable task you want to do, there's a Libre option. We're not getting closer by excluding certain applications by default.
There is one other interesting point that just happened to cross my mind. Imagine google was built on a GPLv3 foundation. If the original authors added the appropriate clause, they'd have to make their source code downloadable. That's fair. However, if I downloaded said code and modified it to suit my tastes, should they then be required to run my version on google.com, so that I can use the code in the same context from which I received it?
BTW, just for the record, I'm not a hardware manufacturer, nor do I work for one. I'm an independent software developer building FOSS-based billing/accounting/CRM/etc. systems (for food) and music production software (for fun).
> I mean, who cares if Joe Hacker can see and make their own versions of the voting software, as long as he can't install it on the voting machines on election day. This is a social problem of having safeguards and procedures, not a question of open or closed sources.
I don't worry about Joe Hacker the outsider, I worry about the people who legitimately have access to the voting machines. If they can install modified software on the machines without the machine ceasing to function, the integrity of the machine can be breached. The GPLv3 explicitly prohibits the manufacturer of the machine to make sure that that doesn't happen, in effect making a voting machine using GPLv3 software uncertifiable.
Not to mention medical devices. Or devices that handle payment transactions, like this one (unfortunately in German only). Do we, as the Free Software community, go on record stating, "well, for this sort of thing, Free Software is just not the solution"?
As far as I can see it, DRM technology poses three distinct major threats to developers' and users' freedoms:
1. locked digital media
This is where the GPLv3 works, sort of. You cannot take a GPLv3ed media player, add some DRM component, and distribute the result while keeping the key that unlocks the media secret. That's fair. Unfortunately, there is a large range of non-GPLed media players available. In the end, FOSS users will still have to resort to hacks, but they're not worse off in that respect than they are now, and at least the code they worked on won't be used to prevent them from doing what they want.
2. locked FOSS-using devices (the Tivo scenario)
I think the FSF, and software developers advocating GPLv3, are seriously overstepping their bounds here. Basically, they're telling hardware developers that in order to use FOSS, not only do they need to give freely what they freely received (which is just reasonable), but they also have to make THEIR OWN product convertable to any use their customers see fit. This immediately excludes building devices that need to assure overall system integrity (from fair network gaming through to voting machines) and also excludes a number of fairly reasonable business models (hardware has a significantly non-zero duplication cost, unlike software, and the money has to come from somewhere). Alternatively, they can choose to make their machines physically tamper-proof (which defeats the intent of the license, makes the license unverifiable, and the product unrepairable in case of software problems). The net result will simply be that hardware developers will stop considering the use of FOSS, which will lead to them getting what they want anyway, FOSS code getting less exposure and less fixes, and end users receiving an arguably less technologically sound product at a higher price.
3. locked general-purpose computers
The GPLv3 can't do squat about thread 3. If such devices do indeed appear, they will simply not be running FOSS. Ever. Because even if a vendor would like to offer an OS based on some hypothetical GPLv3ed kernel, the license wouldn't allow it.
So, looking at the above, I can't help but think that Linus is right here. I have the utmost respect for RMS and the members of the various committees, I'm even a paid-up and (CD-)card-carrying member of the FSF (#2342), but so far they have failed in providing a satisfactory solution to the problems ahead.
Please prove me wrong.
#3: .-files and -dirs from user a to user b as root, and then did the following:
/home/b .*
/etc (bad UPS), making logins impossible. Luckily, there was a root session left on the console. /etc of a nearly identical second machine. So I logged into that one, and proceeded to clean up the editor backups to make comparing easier. I typed
/etc
As a newbie admin, late at night, I copied some
cd
chown -R b:users
When that didn't come back after 5 seconds I realized what I had done and canceled it. Luckily, someone in the first 50 or so users had like a million files in their home, so cleaning up the mess took just three hours.
#2:
After a brownout we discovered that one of the production machines crapped all over its
Some 30 minutes later we had what we believed to be the complete set of files back from lost+found, but I wanted to make sure by comparing them to the
cd
rm * ~
and got the reply
rm: cannot remove `~': No such file or directory
I literally smashed the keyboard. I still have a scar on my right palm from that one.
#1:
Since we had reason not to trust our mains power, we moved a cluster of server machines from the company's basement to a hired data center. This was fully redundant hardware, down to the doubled independent power supplies. The data center provided four separate mains circuits to the racks, UPS, diesel generator, the works. A week after the move, one of the servers died when one of the mains circuits went down for repairs.
It turned out that someone had managed to plug both power supplies into the same circuit.
This is fundamentally boring stuff, but easy to get wrong, with potentially disastrous consequences. So, instead of shelling out big bucks for 'COTS'-ware, violating your own IT policies, and costing you an additional bag of appendages for the consulting work necessary to get it running, I'd rather buy this as a service.
;)
Incidentally, I work for a company that sells that kind of service (not in the US, though, but it's a rather obvious business model, so there will be someone in your area for sure). To give you an idea: we handle over 200 million calls a month (order management, provisioning, rating, billing, invoicing, payment handling, dunning, customer care, call-center support, the whole chain) using a near-FOSS system that we built and run in-house. The only proprietary components are IBM DB2 and the Sun JDK.
For lowish transaction volumes, we can afford to be cheaper than a bare software license, and as an added benefit we know what we're doing, so your auditors will be happier, too. So, go and find one of our competitors.
There's quite a few, actually. RME cards are what Paul Davis recommends; if you can do without quite as many channels, the M-Audio Delta series (especially the PCI-based options) work quite nicely as well.
I personally run MusE/Jack on an M-Audio Delta 1010LT (8 channels analog i/o + S/PDIF stereo i/o) at 24/96 and have yet to run into serious problems.
William Barton: Dark Sky Legion
Now, this is not High Art(tm), but its premise is very original, and Barton manages to pull it off: a galaxy-wide civilization of human colonies, established and held together solely by slower-than-light space ships. Currently out of print, but well worth tracking down.
David Brin: The Uplift Trilogies
Space Opera at its finest. If you read Brin's other works and didn't like them, try it anyway. If you read Sundiver and didn't like it, keep going anyway. Featuring truly alien aliens, insights into the thought patterns of space-faring dolphins, psi weaponry, privacy wasps, and more ways to cheat Einstein than Tesla would've dared to imagine - and all that in impeccable prose. Dune looks positively deserted in comparison.
Stanislav Lem: Golem
Lectures on life delivered by a machine vastly more intelligent than any human could hope to become. This should rightly be impossible to do convincingly, given that the writer is human after all, but at least in the German translation he is frighteningly convincing. So, until I find the time to learn Polish to read the original, I have to operate under the assumption that Lem is either an alien or a time traveller. For me, that makes our own universe a lot more interesting than any of the above.
IMHO, the problem with 'gurus' teaching 'users' has nothing to do with their relative intelligence. Rather, it's an issue of the semantics of teaching, or more specifically, teaching the use of computers. To a 'guru', teaching the use of computers means getting their student to the point where they can figure out what's going on when confronted with a new program, task, or problem on their own, by connecting it to what they already know. This is called understanding, but that's not what 'users' are used to in the context of computers. What's worse, it is continually suggested to them that it's not what they want.
To quote from the linked article:
This is the basic problem. Telling someone "To A, push B" is not teaching, it's more like programming the student. The student will not understand what they are doing. They'll end up with an unconnected heap of little task descriptions in their head; actually, a lot of people end up with a heap of Post-its glued to their screens and keyboards. They are unprepared to cope with B not causing A (at best they'll reboot, typically they'll call tech support), and if they're given new software where B happens to look a lot more like C and is 5 inches off to the left, they'll need retraining.
That sort of thing doesn't happen with, say, cars. But contrary to popular opinion, that's not because cars are easy, it's because Driving School actually teaches you something, while 'Computer User School' does not.
One can only speculate as to the reasons behind that; after all, driving schools surely wouldn't complain if their students had to return at regular intervals to be told that "in this new and improved model, the windshield wiper switch is now located on the second stick right of the wheel". But in the computer user world, this is exactly how it works. The end result is the perpetual myth that computers are complicated and hard to use, plus excellent job opportunities for 'teachers'.
Feh, that came out rather rambling... Thanks for reading it anyway. ;)
As a matter of fact, you can't *just* deploy anything but Windows to a 'Windows user'. For the average corporate officebeing, a Windows/MS Office upgrade comes with a week of mandatory training and two months minimum of fiddling and frantic support calls until all those little post-it notes that detail the clicks needed to print to that other printer down the hall etc. etc. are updated. To them, the oft-touted 'user-friendliness' of Windows is little more than an urban legend.
On the other hand, people who are not irrationally afraid of computers in general will hardly notice the difference. My girlfriend's just as happy with 4DWM on my Indigo2 as she's with her Win98 box, and she's in marketing...
Crusoe in the c't labs
Transmeta's TM5600 processor (built into a Sony Vaio) is currently undergoing c't labs' scrutiny. The first benchmark results put it into the range between a Pentium III-400 (e.g. the c't Mandelbrot fractal at about 15 million iterations per second) and a Pentium III-600. Memory performance is impressive for a small notebook, starting with about 60MB/s for MemCopy and increasing to about 170MB/s for cache hits within the processor's translation buffer. Write performance (measured via Memset) peaks at about 280MB/s. In comparison, a Pentium III-500 with Via-Apollo-II chipset won't reach more than 70MB/s and 150MB/s, respectively. A Pentium III-Coppermine-800 on a Solano i815 board comes in close at 190 and 255MB/s.
Another interesting fact is that the Crusoe processor supplies a serial number via CPUID, which cannot be disabled, at least in the Vaio configuration. This serial number seems however to be generated exclusively by the code-morphing software. The "true" CPUID command (compatible with the AMD Athlon) does not yield a serial number. Additionally, Transmeta declared the otherwise flawlessly functional CMPXCHG8 command as not available in the list of official features, since Windows NT can't cope with a Pentium-class processor (family ID 5) supplying this feature.
Further benchmarks and power consumption measures will be published by c't during the next week.
Granted, it's ugly, but at least in my experience, it's not as ugly in practice as it looks in theory. For GUI code, the Qt-supplied containers are all you'll need, and QString is a godsend compared to STL string, especially if you're dealing with internationalization issues.
Down in the layers that do the actual work, I tend to use STL containers for reasons like uniformity with low-level libraries etc. I have yet to encounter a situation where that approach causes actual ugliness in my code - YMMV, of course.
Apart from the GPL incompatibility of QPL 1.0 (which is on its way out), and the preprocessor (which is about as non-intrusive as it gets with three extra lines in your Makefile), what disadvantages did you notice? Note that I'm referring to Qt2.x, so lack of themeability is out...
Same here, initially ("Germany" in this case). It took me five tries to figure out that it expects an ISO country code. "UK" or "GB" should work for you; "DE" did it for me.
After I finally donated my modest $50, I sent mail to the site's admin, explaining the situation, and pledged another $100 if they managed to fix that.
Let me reiterate what you have:
Given these factors, I'd suggest you simply stay closed-source. You'll have a hard-enough time making money from this anyway, even then.
If your customers demand source, sell it to them, but don't give it away. If you feel you need to give back to the community, there might be other, better ways - how about sponsoring development of free software you use, for example?
To wit: the company I work for makes extensive use of MICO, Xalan, Xerces, and Apache. We're closed source, but we contribute fixes, fund MICO-MT development, and will soon sponsor standardization committee activities for XML-Apache. In the end, everyone's happy. Maybe that would work for you, too?
Interesting that they left those two out of the list... Expect the next e-Mail-Virus to carry a .doc file.
These Microsoft guys are really security-conscious, huh? Great job.
There are two different issues at play here: firstly, GPL compatibility, and secondly, availability for closed source development at no charge.
The QPL is incompatible with the GPL due to the "changes may be only distributed as patches" clause. This is just plain silly, but a fact of life. When writing new code, you can grant a licence exception and be done with it.
Contrary to popular opinion, the QPL does NOT restrict you further in any way that the GPL doesn't. You can sell your apps, as long as you supply source code. You can port all of Qt to Windows, as long as you distribute that port as archive + patchset. You can't use Qt to write closed-source apps without paying Troll Tech, but then again you can't use GDBM that way either (it's GPLed, not LGPLed). So where's the problem?
The current OpenMOTIF license is, too, incompatible with the GPL. You can't take GPLed Motif code, link with Open Motif, and redistribute. The incompatibility isn't silly, either: you cannot allow your users to port away from the freeNIXes.
As far as closed-source development goes, it's just as impossible without paying up as it is with Qt. But - do we really care about that?
I can see it now. "This software is not licensed for use on non-Intel processors." Then add region coding... "This software is not licensed for use in the UK." Before you know, it'll be illegal to carry laptops on intercontinental flights, because of copyright issues.
Sometimes I wonder what customers of "high-tech products" can be reliably expected to put up with. I mean, who'd buy books that you could only read wearing the right glasses?
Problems unsolvable by computers roughly fall into three categories:
1. Mathematically proven impossible
The Halting Problem and similar. These are inherently impossible to solve exactly or exhaustively. Note that this impossibility applies regardless of whether the entity tackling the problem is carbon-based or silicon-based.
2. Theoretically possible (exact algorithm is known), but time-/space-consuming.
The Traveling Salesman and his friends in NP. The jury is still out on whether their intractability is a human limitation (i.e. we just haven't managed to come up with a working algorithm in P) or whether they're really that hard, but if the latter is true, then again they're hard to solve exactly for anyone, not just computers.
3. Things involving creativity, feelings, "true understanding", etc.
A suprising number of technically knowledgeable people are willing to grant that one without further questioning, and that's understandable. After all, one can't quite imagine what an algorithm for coming up with a new idea or a subroutine for falling in love would look like, and yet humans are able to DO these things, and they're easy.
So why is it hard to teach a machine to do that? Well, look at it from a different angle: how hard is it to teach a human to do that? Have you ever tried to explain what exactly "being in love" is? The best we've come up with so far in that area is art, music, poetry, which seems to evoke similar feelings in different people, but that's by no means fail-safe. So, from a not too unlikely point of view, humans can't do these things either - we don't know how to do them. They do us instead. Machines might suffer from the same shortcoming, but given the state of our knowledge about this area of human behaviour, we're not even in a position to find out yet.
But then again, maybe the author of the book reviewed here has found a way...
I knew I should've explained these... you see, we have about 45 fish and ramen dishes around, and a lot of the new folk we hired don't even like sushi, so what we switched to were more descriptive terms. To wit:
;)
ryouko (= good writing) is a printer
yakuza is a VMWare Win98 setup on a linux box. We needed something evil there...
karoshi and seppuku belong to quality control folks. The connection is obvious.
ronin (= the lordless samurai) is a shared notebook.
I won't comment on the owner of sake, though.