I don't know about others but I have a dual boot system (gentoo on one side and WinXP on the other) and I notice NO difference whatsoever in UI performance. Linux is not faster but certainly not slower either. On the other hand things like file access (useful for compilation and such) is significantly faster on windows (at least on my system here).
I have an Acer Aspire 5024 Laptop with AMD64 btw. 1Gig ram.
That's funny, because I have exactly the opposite experience (Acer Aspire, Core 2 Duo, 1 GB RAM). File access under Linux seems significantly faster than Windows, and it seems a lot smarter about choosing which files to keep in cache, as well as swap behaviour. (Based on totally subjective observations, seeing as I don't boot Windows very often).
Sadly such christians are the majority - for example roman catholics are required to believe literally in the resurrection and ascension of jesus or they are not catholics in good standing. That's a billion christians right there.
Um... I think you've got your wires rather crossed. All Christians believe that. Not believing that makes you... not a Christian, seeing as one of the fundamental points of the Christian belief is in Christ's divinity and corporeal ascension into heaven.
Roman Catholics believe in the literal and actual transubstantiation of the gifts of the Eucharist into the Body and Blood of Christ (and if you don't believe that you're not a Catholic). This is the bit which gives other Christian a bit of a headache.
On Slashdot, it's not cross-platform if there's a single platform that it doesn't run on. See the various complaints about Flash not being "cross-platform" since it doesn't natively run on 64-bit Linux.
I tend to agree: it's not cross-platform. Tell me, how well does it run on Sparc NetBSD? Or x86-64 Solaris, for that matter?
There's absolutely no excuse for code which will run on i386 but not on x86-64 (given the same operating system, same libraries and otherwise same hardware). Such code is indicative of very poor programming practises. In fact, I would go so far as to say that any code outside the kernel or low-level libraries which won't happily compile and run on i386, x86-64, PPC and Sparc with no changes required suggests that the programmers don't know what they're doing. The "inline assembly" excuse doesn't cut it either; assembly without a plain C fallback smacks of premature optimisation.
Differences in libraries APIs and available system calls I can understand as reasons for lack of portability. Differences in CPU architecture? No way.
It seems that first the linux people need to embrace the concept of cross platform development. Most linux developers I know don't want to build their stuff to run on all platforms, so it should be no surprise that vendors don't want to bother with developing cross platform either, and will simply target the platform that reaches the most uses.
If the cross platform toolkits were the easiest way to build apps, and those apps were every bit as good as ones developed targeting a single platform, things would change.
Pardon me, but what the hell are you smoking? All of the applications I use on my Linux desktop are developed with highly portable (yep, cross-platform) toolkits such as GTK+ and Qt. Most run very well on many architectures and many kernels (Linux 2.4 and 2.6, *BSD including Darwin, Solaris, etc).
One data point. gEDA (the GPL Electronic Design Automation suite) has active users on Solaris, NetBSD, OSX and Linux. But when I'm working on it, I don't even have to thing about portability to those operating systems: keeping to some very simple rules makes porting as simple as "git clone ;./configure; make install". Of course, sometimes there's a very obscure difference which breaks something, but it's always easily fixable without much thought required.
There have been several attempts to make a maintainable port to Windows, but such attempts always run up against the realization that Windows is so fundamentally different to all these other operating systems that it's almost as if it was designed to be hard to port too -- or, more importantly, from. [1]
Funny, that.
[1] There's something that sort of works now... but the bugs aren't due to lack of willingness to port or effort spent on it.
Do you live in the UK? If so, you have no right to rip music from CDs (there's no fair use) and your collection is illegal.
Fair enough, my collection is illegal. That particular law is unconscionable, and I will happily violate it in full knowledge of its existence. So sue me.
Re:Has already existed and thrived for a long time
on
Rewritable Song Lyrics
·
· Score: 1
When artistic concerns are overshadowed by the need to please one's patron, art suffers.
Tell that to Mozart. And Handel. And Beethoven. And Wagner. And...
Much of the fantastic music that makes up our collective cultural heritage came from patronage. In fact, this continues today. Music which is not written on order for a customer is by far the minority of all music.
You can use the Windows XP recovery console from the CD. That thing has like, five whole commands!
Wow, that's amazing! My Linux box only has 3761 commands available from the "recovery console" mode! (Okay, to be fair some of them require an X server).
For Linux to gain appreciable market share it will have to be a better product: it will have to do something much better than Windows. It will also have to have the things people expect from products; warranties, 1-800 numbers and tech support.
I have never come across any software with a warranty. Every piece of software I have ever installed on a Windows box (including Windows itself) makes you click through an agreement which disclaims all possible and conceivable merchantability guarantees or warranties.
As far as tech support is concerned, for most Linux software I can do something I can very rarely do for Windows software: talk directly to the people who actually write the code. My record is 30 minutes from submitting a bug report to completing a patched compile. Beat that.
To be honest though, I couldn't really give a shit about Linux market share, except to the extent that the more users there are the more people there will be writing new and improving existing Free software.
Er, I don't know what version of Windows you've been using, but in the few times I've had Explorer crash on me, it's restarted itself within 10 seconds. (XP/Vista)
First off, I'm talking about the GUI failing; that is, you can't even get a GUI up due to, I don't know, a driver problem. What do you do then[1]?
Secondly, the contract I'm on at the moment requires me to use a Windows XP box. Explorer crashes and freezes for up to 30 seconds at a time on a regular basis, making the desktop pretty much unusable while it sorts itself out. In the last three years of using a KDE desktop almost constantly, I have never seen kicker, kwin or the other core KDE services do anything of the sort. Even when a process goes nuts and tries to eat all my CPU time, the desktop remains pleasantly responsive compared to the equivalent thing happening on a Windows desktop.
[1]This actually happened to me. It had five MSCE's scratching their heads for about a day trying to work out what to do about it. I'm not sure what the eventual fix was.
Something that Windows still is better at is the configuration tools for the OS. You are of course still able to hand-hack the config files under Linux but not all users are able to do that. The ability to easily configure triple-head displays are actually better under Windows than under Linux. But you will be able to do it under Linux too if you hand-hack xorg.conf.
Have you tried nvidia-settings recently? You can reconfigure the X server to just about any possible monitor configuration without root access, without writing to xorg.conf at all, all with a intuitive GUI interface. I'm damn impressed with it.
The only time I have to hack system config files these days is if either there's a bug which I need to work around, or I'm setting up some complicated low-level software like a MTA or HTTP daemon. I can't remember the last time I hacked a config file for a desktop feature for a reason other than a major bug in the software (or if it's a piece of software I'm developing). These things have got a heck of a lot better in the last couple of years.
Something to remember and take into account is the principle of itch-scratching. If the config file is straightforward enough to hack, I'm not going to be bothered to make a GUI for it. From my point of view, the cost-benefit ratio is poor. If you're being paid to work on said dialog, the cost-benefit balance shifts.
Linux is not a desktop OS. Its a long way from it. While things like gnome and kde are doing more than most to help get it there, too many apps still don't fit together. Start mixing X applications from KDE, gnome, and other toolkits together and you get a horrible mess of applications that follow no common theme, work in different ways than the typical desktop user will expect, and have UIs that were designed be developers with about 8 times as many options as they actually need.
Actually, I challenge you to find a set of Windows of applications as comprehensive as KDE with such a cohesive feel to them. The last time I used a Windows desktop, it felt exactly like I had a horrible mess of applications that follow no common theme, work in different ways than the typical desktop user will expect, and have UIs that were designed by developers with about 8 times fewer options as they actually need.
For linux to be a desktop OS it needs to be a lot more consistent across the board, not just the applications, but the distros. Want to scare people away, give them 5 distros to choose from and no real defining reason as to why they should pick any of them. So they pick one, and not only do they have to get used to learning how the new apps and OS work, they also have to get used to the fact that several apps use UIs that don't act much like anything they used before or any of the new ones on thier shiny new GNU/Linux PC.
Part of the problem is user education. People think of an operating system as the entire user system, from kernel to WiFi configuration dialog, when it's really not. I can find two current distros as different as Vista and BSD are. Just because a "user desktop system" is built on a particular operating system says absolutely nothing about how it will behave from the users point of view.
FOSS developers need to learn something very important when making apps for normal users:
Do because you should, not because you can. You must start with a UI design in mind, and make it the way you intended when you started. Don't add the 15 features that 15 different people ask for while you are developing it. Add the 5 features that 300 people ask for while you are developing it. If you must add a feature, do it in such a way that it doesn't scare a normal user to see all the options they have to select from. Make things obvious, don't add a tiny little button for some feature that most people won't use, and then hope that they can figure out what happens when they accidently click it and something unexpected happens.
Who are these "normal users" of which you speak? I've never met one.
In any case, I don't write applications for "normal users". I write applications for me[1]. If I wasn't writing them for me, I wouldn't be writing them. If they're useful to someone else that's great. If someone else who uses them doesn't like a change I've made, or has a suggestion for a new feature or an improvement to user interface, I'll most certainly take that into account, but in the end I write code for entirely selfish reasons: to make it work better for me.
[1] Referring to Open Source software I work on in my own time, of course.
Linux is awesome and I use it daily, but it's years behind Win&Mac for user experience.
But it's clearly not. You said it yourself: "Linux is awesome and I use it daily." You wouldn't use it daily if your Linux user experience wasn't much better that Windows/OSX.
People seem to believe in the myth of the One True Operating System which is everything to everyone. My user experience with Linux is far, far better than any other operating system I've used (and I used Windows for a long, long time). I am orders of magnitude more productive with Linux than with anything else. It has powerful tools which can be simply & easily combined in an infinite number of ways to achieve just about any task. It is trivially easy to try out new versions of software or develop software without interfering with the version you have currently installed for general user use, and keeping your system up-to-date with upgrades and fixes not only to the core operating system but also to almost all user-level applications is but the work of click of a mouse button.
The day Linux becomes the majority OS is the day the geeks flee to Solaris and the BSDs. Because Linux won't be the "leet" OS anymore. (We've seen it happen already, sometimes causing developer/maintainer disputes and leading to forks, like cdrtools -> cdrkit.)
This is a poor example. The cdrkit fork only occurred because Joerg Schilling doesn't understanding that the CDDL isn't compatible with the GPL; none of the distros could actually legally distribute his cdrtools, so they had to fork.
That, and the fact he's an arrogant asshole who cannot understand the notion that he might not be right 100% of the time. Absolutely nothing to do with whether Linux is a "leet" (sic) operating system or not.
(My experiences dictate that if GNOME or KDE fails, an inexperienced user is left helpless at the command line - Windows does no such thing. This needs to change and support needs to become even *more* accessible before acceptance is widespread.)
You're quite right. Windows does no such thing. My experiences indicate that if the Windows GUI fails, an inexperienced user is left helpless without a (usable) command line.
These companies would say no because of the ridiculous difficulty of supplying binary executables for "Linux"....and they're not about to GPL their secret sauce recipes.
It's not ridiculously difficult. It's dead easy. If a tiny indie games company like Introversion can make their programs completely portable between Windows and Linux, and an enormous well-established company like Id can make their programs completely portable between Windows and Linux, there's no reason why anyone in between can't either.
All they have to do is not use the lockin-tastic DirectX API and use OpenGL, OpenAL and SDL instead. All three have been optimised to death, and are portable not only to Linux and Windows but OSX and many BSDs as well.
The biggest barrier to Linux games is the large number of programmers who know nothing but DirectX. Nothing more.
HP has always had either rotten on non-existent drivers. I remember returning my last HP device to the store where I bought it (a large flatbed scanner, I think) because HP didn't ever release Windows 2000 drivers for my gizmo with the explanation that Windows 2000 was a "business OS". HP is a truly crappy company. I wouldn't buy a pencil from them.
It's strange. My Linux-using friends who have HP kit say the HP Linux drivers are second to none. How odd that this is not also true of their drivers for other operating systems...
The Ubuntu folks seem to be much more forgiving that you didn't pop out of your mothers nether regions without a C programming manual in hand. In my experience, they don't shout RTFM!!! ad-nauseum.
I confess to be someone who uses "RTFM" frequently in conversations with new Linux users. However, I am very careful to specify which FM, how to find TFM, and which parts of TFM they need to R. Usually the biggest problem is that the new user didn't realise there was a FM available for the thing they were having difficulty with.
Not sure who developed it first, but I do remember being somewhat enamored with Seiko's Kinetic watches. They had a off-center flywheel attached to a generator and gearbox that powered a small capacitor. Apparently the watch would run for 2 weeks on a full charge and all you had to do was walk around with it for a few hours. But that was a few years ago.
I've got one. It's got a battery and a flywheel; the battery stops it from losing time for up to a month of leaving it stationary. One of the most elegant pieces of engineering I own.
To meta-paraphrase your paraphrase, that is essentially to say: "If you use my software, and put it on a device which you sell, that device must not be of kind X". A similar requirement would be: "You may not use my software in weapons", or "You may not use it in polluting industries" and so on.
I see what you did there! You drastically abstracted what the FSF have written, then used the fact that other restrictions may be abstracted similarly to say that what they have written is the exactly the same as something totally different! Clever!
That isn't particularly meaningful in any way whatsoever. The restriction in no way stops a vendor from giving a user capabilities (like the ability to kill things, or the ability to watch movies, or the ability to hide several boxes behind a single IP address), it merely stops them from removing capabilities which would otherwise be implicit.
While I find the cause to prevent vendors from locking down consumer hardware with cryptographic keys sound, I'm not yet convinced that the fight really belongs in a software license.
Given that they're using my software in a device which they are locking down with cryptographic keys, and given that I don't want them to put my software in such a locked-down device, logically the correct thing to do is to license my software to them in a way that stops them from using it in such a device. This is a means appropriate to the end, is it not?
Anyway, where if anywhere do you think it does belong?
Re:FSF Chief and iPhone FUD
on
GPLv3 Released
·
· Score: 1
Apple has been using BSD since 1988, Apache since 1998, OS X since 1999, WebKit since 2003... how did porting them to the iPhone suddenly get some GPL on there?
Webkit is derived from KHTML, which is GPL software. Webkit is, therefore, also GPL (note that it may be the default HTML rendering engine for KDE 4).
I have a problem with this for multiple reasons. First, the license makes a clear distinction between products for a home and a business. If freedom is the essence of the GPL, this clause is the antithesis of that. By making the distinction, since the specification of a user product provides a way to classify a non-user product, the license admits that practice is a valid one.
No, it doesn't.
I believe that the practise of locking down software from user modification is a really bad thing, in general, and in the vast majority of cases where this is done it's for bad reasons. Tivo, XBox, PS3: all these are sold to me, and theoretically they are my property to do what I wish with, under consumer protection law. The locking down is a deliberate attempt to stop me.
In business, however, there are a few cases where this is desirable. For instance, e-mail is beginning to be much more important in court cases involving unfair dismissal, anti-trust, tortuous business interference, etc. If a company has an e-mail logging server which they have read-only access to, and is completely locked down by the vendor against interference from the company or its agents, it makes the e-mail records much more reliable as evidence in a court of law. Note that in this case, the restriction adds utility to user, rather than removing utility from the user. This is an important distinction.
There is absolutely no reason to stop GPL software from being used to implement such a business model, and according to the drafters of the GPL v3, the vast majority of instances which they consider safe fall outside the realm of "User Products". However, note that the definition of "User Product" used in the GPL v3 is deliberately painted with a very broad brush.
I hope that clears things up for you. As I said, I'd personally rather a blanket prohibition, but I can see why the drafters put the language in.
Finally, for your own products you can quite freely add an "Additional Permission" under the meaning of section 7 paragraph 1 which removes or weakens the requirements of distributing "Installation Instructions".
2. People who defend the GPL normally argue that copying someone else's work, earning money either with it or a derivative work of it and not giving something back is unethical. That's a different type of fish.
I know lots of people who copy my GPL work, earn money with it and don't give anything back. They're called users.
As long as you're not going to distribute my work, you can do what you like with it, including making copies.
I think I know what you mean, but I thought it would be a good idea to clarify!
Re:tivoisation
on
GPLv3 Released
·
· Score: 2, Interesting
But closed hardware and code does not prevent cheating. The PS3 and Motorstorm are pretty closed, yet online game play is rife with people cheating with infinite boosts.
Which to my mind makes whether or not you're allowed to restrict the user to running vendor-signed game binaries a rather moot point...
Slashdot's told me to "Slow down, cowboy!" so while waiting for the timer to run out I'll write this rather pointless line at the end of my post.
Slashdot Mirror
I have an Acer Aspire 5024 Laptop with AMD64 btw. 1Gig ram.
That's funny, because I have exactly the opposite experience (Acer Aspire, Core 2 Duo, 1 GB RAM). File access under Linux seems significantly faster than Windows, and it seems a lot smarter about choosing which files to keep in cache, as well as swap behaviour. (Based on totally subjective observations, seeing as I don't boot Windows very often).
Um... I think you've got your wires rather crossed. All Christians believe that. Not believing that makes you... not a Christian, seeing as one of the fundamental points of the Christian belief is in Christ's divinity and corporeal ascension into heaven.
Roman Catholics believe in the literal and actual transubstantiation of the gifts of the Eucharist into the Body and Blood of Christ (and if you don't believe that you're not a Catholic). This is the bit which gives other Christian a bit of a headache.
I tend to agree: it's not cross-platform. Tell me, how well does it run on Sparc NetBSD? Or x86-64 Solaris, for that matter?
There's absolutely no excuse for code which will run on i386 but not on x86-64 (given the same operating system, same libraries and otherwise same hardware). Such code is indicative of very poor programming practises. In fact, I would go so far as to say that any code outside the kernel or low-level libraries which won't happily compile and run on i386, x86-64, PPC and Sparc with no changes required suggests that the programmers don't know what they're doing. The "inline assembly" excuse doesn't cut it either; assembly without a plain C fallback smacks of premature optimisation.
Differences in libraries APIs and available system calls I can understand as reasons for lack of portability. Differences in CPU architecture? No way.
If the cross platform toolkits were the easiest way to build apps, and those apps were every bit as good as ones developed targeting a single platform, things would change.
Pardon me, but what the hell are you smoking? All of the applications I use on my Linux desktop are developed with highly portable (yep, cross-platform) toolkits such as GTK+ and Qt. Most run very well on many architectures and many kernels (Linux 2.4 and 2.6, *BSD including Darwin, Solaris, etc).
One data point. gEDA (the GPL Electronic Design Automation suite) has active users on Solaris, NetBSD, OSX and Linux. But when I'm working on it, I don't even have to thing about portability to those operating systems: keeping to some very simple rules makes porting as simple as "git clone ; ./configure; make install". Of course, sometimes there's a very obscure difference which breaks something, but it's always easily fixable without much thought required.
There have been several attempts to make a maintainable port to Windows, but such attempts always run up against the realization that Windows is so fundamentally different to all these other operating systems that it's almost as if it was designed to be hard to port too -- or, more importantly, from. [1]
Funny, that.
[1] There's something that sort of works now... but the bugs aren't due to lack of willingness to port or effort spent on it.
Then, I noticed that the thing in front of the numbers wasn't a dollar sign...it was a pound sign.
(Just for reference, the current exchange rate is: 1.00 GBP = 2.05749 USD.)
Yes, but that's not the effective exchange rate, which we all know is 1.00 GBP = 1.00 USD.
Welcome to rip-off Britain. </bitter>
Fair enough, my collection is illegal. That particular law is unconscionable, and I will happily violate it in full knowledge of its existence. So sue me.
Tell that to Mozart. And Handel. And Beethoven. And Wagner. And...
Much of the fantastic music that makes up our collective cultural heritage came from patronage. In fact, this continues today. Music which is not written on order for a customer is by far the minority of all music.
Nope. It's the Afferro GPL.
Wow, that's amazing! My Linux box only has 3761 commands available from the "recovery console" mode! (Okay, to be fair some of them require an X server).
I have never come across any software with a warranty. Every piece of software I have ever installed on a Windows box (including Windows itself) makes you click through an agreement which disclaims all possible and conceivable merchantability guarantees or warranties.
As far as tech support is concerned, for most Linux software I can do something I can very rarely do for Windows software: talk directly to the people who actually write the code. My record is 30 minutes from submitting a bug report to completing a patched compile. Beat that.
To be honest though, I couldn't really give a shit about Linux market share, except to the extent that the more users there are the more people there will be writing new and improving existing Free software.
First off, I'm talking about the GUI failing; that is, you can't even get a GUI up due to, I don't know, a driver problem. What do you do then[1]?
Secondly, the contract I'm on at the moment requires me to use a Windows XP box. Explorer crashes and freezes for up to 30 seconds at a time on a regular basis, making the desktop pretty much unusable while it sorts itself out. In the last three years of using a KDE desktop almost constantly, I have never seen kicker, kwin or the other core KDE services do anything of the sort. Even when a process goes nuts and tries to eat all my CPU time, the desktop remains pleasantly responsive compared to the equivalent thing happening on a Windows desktop.
[1]This actually happened to me. It had five MSCE's scratching their heads for about a day trying to work out what to do about it. I'm not sure what the eventual fix was.
Have you tried nvidia-settings recently? You can reconfigure the X server to just about any possible monitor configuration without root access, without writing to xorg.conf at all, all with a intuitive GUI interface. I'm damn impressed with it.
The only time I have to hack system config files these days is if either there's a bug which I need to work around, or I'm setting up some complicated low-level software like a MTA or HTTP daemon. I can't remember the last time I hacked a config file for a desktop feature for a reason other than a major bug in the software (or if it's a piece of software I'm developing). These things have got a heck of a lot better in the last couple of years.
Something to remember and take into account is the principle of itch-scratching. If the config file is straightforward enough to hack, I'm not going to be bothered to make a GUI for it. From my point of view, the cost-benefit ratio is poor. If you're being paid to work on said dialog, the cost-benefit balance shifts.
Actually, I challenge you to find a set of Windows of applications as comprehensive as KDE with such a cohesive feel to them. The last time I used a Windows desktop, it felt exactly like I had a horrible mess of applications that follow no common theme, work in different ways than the typical desktop user will expect, and have UIs that were designed by developers with about 8 times fewer options as they actually need.
For linux to be a desktop OS it needs to be a lot more consistent across the board, not just the applications, but the distros. Want to scare people away, give them 5 distros to choose from and no real defining reason as to why they should pick any of them. So they pick one, and not only do they have to get used to learning how the new apps and OS work, they also have to get used to the fact that several apps use UIs that don't act much like anything they used before or any of the new ones on thier shiny new GNU/Linux PC.Part of the problem is user education. People think of an operating system as the entire user system, from kernel to WiFi configuration dialog, when it's really not. I can find two current distros as different as Vista and BSD are. Just because a "user desktop system" is built on a particular operating system says absolutely nothing about how it will behave from the users point of view.
FOSS developers need to learn something very important when making apps for normal users:Do because you should, not because you can. You must start with a UI design in mind, and make it the way you intended when you started. Don't add the 15 features that 15 different people ask for while you are developing it. Add the 5 features that 300 people ask for while you are developing it. If you must add a feature, do it in such a way that it doesn't scare a normal user to see all the options they have to select from. Make things obvious, don't add a tiny little button for some feature that most people won't use, and then hope that they can figure out what happens when they accidently click it and something unexpected happens.
Who are these "normal users" of which you speak? I've never met one.
In any case, I don't write applications for "normal users". I write applications for me[1]. If I wasn't writing them for me, I wouldn't be writing them. If they're useful to someone else that's great. If someone else who uses them doesn't like a change I've made, or has a suggestion for a new feature or an improvement to user interface, I'll most certainly take that into account, but in the end I write code for entirely selfish reasons: to make it work better for me.
[1] Referring to Open Source software I work on in my own time, of course.
But it's clearly not. You said it yourself: "Linux is awesome and I use it daily." You wouldn't use it daily if your Linux user experience wasn't much better that Windows/OSX.
People seem to believe in the myth of the One True Operating System which is everything to everyone. My user experience with Linux is far, far better than any other operating system I've used (and I used Windows for a long, long time). I am orders of magnitude more productive with Linux than with anything else. It has powerful tools which can be simply & easily combined in an infinite number of ways to achieve just about any task. It is trivially easy to try out new versions of software or develop software without interfering with the version you have currently installed for general user use, and keeping your system up-to-date with upgrades and fixes not only to the core operating system but also to almost all user-level applications is but the work of click of a mouse button.
This is a poor example. The cdrkit fork only occurred because Joerg Schilling doesn't understanding that the CDDL isn't compatible with the GPL; none of the distros could actually legally distribute his cdrtools, so they had to fork.
That, and the fact he's an arrogant asshole who cannot understand the notion that he might not be right 100% of the time. Absolutely nothing to do with whether Linux is a "leet" (sic) operating system or not.
You're quite right. Windows does no such thing. My experiences indicate that if the Windows GUI fails, an inexperienced user is left helpless without a (usable) command line.
It's not ridiculously difficult. It's dead easy. If a tiny indie games company like Introversion can make their programs completely portable between Windows and Linux, and an enormous well-established company like Id can make their programs completely portable between Windows and Linux, there's no reason why anyone in between can't either.
All they have to do is not use the lockin-tastic DirectX API and use OpenGL, OpenAL and SDL instead. All three have been optimised to death, and are portable not only to Linux and Windows but OSX and many BSDs as well.
The biggest barrier to Linux games is the large number of programmers who know nothing but DirectX. Nothing more.
It's strange. My Linux-using friends who have HP kit say the HP Linux drivers are second to none. How odd that this is not also true of their drivers for other operating systems...
I confess to be someone who uses "RTFM" frequently in conversations with new Linux users. However, I am very careful to specify which FM, how to find TFM, and which parts of TFM they need to R. Usually the biggest problem is that the new user didn't realise there was a FM available for the thing they were having difficulty with.
I've got one. It's got a battery and a flywheel; the battery stops it from losing time for up to a month of leaving it stationary. One of the most elegant pieces of engineering I own.
I see what you did there! You drastically abstracted what the FSF have written, then used the fact that other restrictions may be abstracted similarly to say that what they have written is the exactly the same as something totally different! Clever!
That isn't particularly meaningful in any way whatsoever. The restriction in no way stops a vendor from giving a user capabilities (like the ability to kill things, or the ability to watch movies, or the ability to hide several boxes behind a single IP address), it merely stops them from removing capabilities which would otherwise be implicit.
While I find the cause to prevent vendors from locking down consumer hardware with cryptographic keys sound, I'm not yet convinced that the fight really belongs in a software license.Given that they're using my software in a device which they are locking down with cryptographic keys, and given that I don't want them to put my software in such a locked-down device, logically the correct thing to do is to license my software to them in a way that stops them from using it in such a device. This is a means appropriate to the end, is it not?
Anyway, where if anywhere do you think it does belong?
Webkit is derived from KHTML, which is GPL software. Webkit is, therefore, also GPL (note that it may be the default HTML rendering engine for KDE 4).
Next!
No, it doesn't.
I believe that the practise of locking down software from user modification is a really bad thing, in general, and in the vast majority of cases where this is done it's for bad reasons. Tivo, XBox, PS3: all these are sold to me, and theoretically they are my property to do what I wish with, under consumer protection law. The locking down is a deliberate attempt to stop me.
In business, however, there are a few cases where this is desirable. For instance, e-mail is beginning to be much more important in court cases involving unfair dismissal, anti-trust, tortuous business interference, etc. If a company has an e-mail logging server which they have read-only access to, and is completely locked down by the vendor against interference from the company or its agents, it makes the e-mail records much more reliable as evidence in a court of law. Note that in this case, the restriction adds utility to user, rather than removing utility from the user. This is an important distinction.
There is absolutely no reason to stop GPL software from being used to implement such a business model, and according to the drafters of the GPL v3, the vast majority of instances which they consider safe fall outside the realm of "User Products". However, note that the definition of "User Product" used in the GPL v3 is deliberately painted with a very broad brush.
I hope that clears things up for you. As I said, I'd personally rather a blanket prohibition, but I can see why the drafters put the language in.
Finally, for your own products you can quite freely add an "Additional Permission" under the meaning of section 7 paragraph 1 which removes or weakens the requirements of distributing "Installation Instructions".
(I am not a lawyer and this is not legal advice)
I know lots of people who copy my GPL work, earn money with it and don't give anything back. They're called users.
As long as you're not going to distribute my work, you can do what you like with it, including making copies.
I think I know what you mean, but I thought it would be a good idea to clarify!
Which to my mind makes whether or not you're allowed to restrict the user to running vendor-signed game binaries a rather moot point...
Slashdot's told me to "Slow down, cowboy!" so while waiting for the timer to run out I'll write this rather pointless line at the end of my post.