According to the linked pages, he previously put no indication of any license on the images. This means they could not be reused for anything, per US copyright law. Everything you create is copyrighted by default.
Even if they completly screwed up all that Microsoft would have to do is stop making this plugin and pull TurboLinux's right to distribute it. Despite all the attempts by Bill Gates to brainwash people into believing otherwise, using GPL code does not cause you to have to give away everything you ever wrote. That is a damn lie, one of the biggest to come out of him.
More to the point, it is pretty obvious that xine allows binary plugins to be used. They sure haven't complained about their code being used to run existing Windows DLL's, have they?
This sort of sounds reasonable, but everybody knows that the kernel and rebooting spews pages and pages of gibberish to the average user. Everybody ignores it, or hides it behind a graphic splash screen.
Also maybe they should consider writing their stuff so it looks like one module, not many?
Unfortunately I think it will have to report tainted modules even if they are unloaded. So just having some way to list currently tainted modules won't get rid of the need for the messages.
By definition, anything "less restrictive than the GPL" cannot prevent you from doing something that the GPL allows you to do. Therefore there is no reason not to dual-license the code as both GPL and BSD.
If you say "but my code can't be GPL'd" then you have made a rule that is obviously more restrictive than the GPL (which obvioiusly allows GPL'd code).
Everybody trying this argument is really saying they want something *more* restrictive than the GPL. They word their arguments very creativly, but they all are equivalent to saying that they require that nobody make a derivative work other than the original author. Now that is a perfectly logical view on how to control your own creative work, but unfortunatly the kernel developers are uninterested in fixing your code under those restrictions. Maybe you can change their mind, but stop trying to lie and say you are "less restrictive than the GPL".
The GPL does not mean you are forced to accept their patches either. So they would have to fork it anyway if you made it GPL/BSD dual-licensed.
Actually it is quite impossible to find any reason to not dual-license your BSD code, since there is nothing the GPL allows somebody to do that the BSD license does not.
You could use normal copyright, but I don't think the kernel developers are interested in debugging your source code in that case, either, since they have to submit the fixes back to you for them to be incorporated, and everybody would have to get the fixed version from you.
First of all, if Office 2003 worked even if that function returned false, it would be like the current situation. Modules will load and run without claiming they are GPL.
SInce it is necessary to make Office 2003 work, Wine certainly has the right to return true. However when you run Office 2003 atop Wine, you don't have the right to call Microsoft and use their time and money to debug your installation and to lie to them and keep telling them you are running a real copy of Windows.
This is like circumventing the DRM in an XBox (perfectly fine) but then trying to get your money back or the machine fixed under warranty by Microsoft. It's like printing the Microsoft copyright on the new rom chip in an attempt to make them think you have not broken the machine yourself.
You do realize that it is physically possible to have *BOTH* the source code and a binary version at the same time, do you? Perhaps you were taught that this was impossible in your MCSE class?
This is not the same, because the string is not needed for the module to work. It can say anything it wants.
This is more like the manufacturer actually printing "official Lexmark ink cartridge" on the cartridge.
Imagine if the printer failed and the user sent it to Lexmark for it to be fixed. Would Lexmark really be out of line if they claimed that the user broke it by putting in that unapproved cartridge?
For de-interlacing you need to get the second field before you can figure out what to display. So there is 1/30 second there (assumming you wait until the end of the second field before displaying the result of the first one, if you really can sync it up carefully you could get the delay down to 1/60 second).
It does seem compensation is the only solution. But there is a problem: lots of high-end equipment produces the sound and sends it to the speaker without any intervention from the tv (ie the speakers are plugged into the stereo amp, which is plugged into the dvd player, not the tv). So it's more like the compensation has to be there.
I would think you need to compensate for the speed of sound as well if you are far enough away from the tv screen. Right now though these problems may cancel out some...
If you took Metallica's songs and somehow managed to convince people you wrote and performed them, and then sold them for as much or more than Metallica's publisher gets, then maybe you might be as low as a typical GPL violator.
How about if you keep your precious model secret like they used to do in the good ol' days? If you only let people see renderings they can't steal very much, can they?
Actually you are legally bound by copyright. The GPL is actually a license to break copyright, if you follow certain rules. In fact the GPL does not force you to do anything.
This is why it is impossible to "test the GPL in court". That's like me offering you a candy bar, but you can refuse it. There is no reason for you to make a court case that somehow says it is illegal for me to offer you a candy bar, because even if you win the result for you is exactly like you refused to get it, a result you can already get.
This is also why it is impossible for the GPL to say "not for military use". If in fact the US government had a law that said "by default everything you make is not for military use unless you explicitly state otherwise" then it would be possible to make a "GPL" that restricted military use (or partially restricted it, like you could say only the Navy can use it, but not the Army).
.a stands for archive. When the Unix compilers were designed they reused a file format that was supposed to "archive" several files into one. I would guess that some of those archive programs had problems and insisted on the extension being ".a", which is why they chose the completely unfriendly and un-Unix-like "lib" prefix rather than just naming the files ".lib" (or maybe ".l" since they really liked short names then).
I am unaware of.a being used for *any* other purpose than code libraries, even back in 1970. Also the format has been hacked plenty and is probably useless for anything other than code libraries today (see the ranlib program, and the fact that Linux does not require it anymore, for details). So IMHO this is one of the many mistakes in Unix design that should be fixed. Perhaps just make the linker look for foo.lib first, and fall back on libfoo.a second. Only problem now is that there may be sites that rely on there not being a name conflict between Unix and Windows libraries...
".so" stands for "shared object" which is much more descriptive than "dll". However I would like to see a scheme by which the same library can be shared or static, with the linker able to choose at link time (perhaps with a default in the library), and both are named ".lib" or ".l".
You are right about that. In fact in our code the STL objects are only being modified by one file and thus only one compiler, only the portability of declaring a pointer to one is tested. However it is true that a pointer to an STL container declared in one compiler links and has the same name as the same pointer declared in another compiler. This means the name mangling is compatable.
Syntax highlighting seems ok
on
A Taste of Qt 4
·
· Score: 1
In my main software project I have used a very specific "foreach" macro (it only works with a single type that we use a lot). Whether this is a good idea or a bad one, I have not had any problems with syntax highlighting or automatic indentation, in Emacs and in several IDE's.
Re:Qt is almost a like a language
on
A Taste of Qt 4
·
· Score: 1
This is an extremely common design.
If the caller is responsible for deleting objects, the caller must also maintain a pointer to all those objects so it can delete them. This is a huge waste of time and space if in fact the toolkit itself has to keep track of such pointers anyways. And if the code for deleting a window can assumme that all widgets inside that window are deleted as well it can vastly simplify the code.
The fact that there is no way to create an arbitrary subclass other than "new" in C++ might be a defect, I suppose some interface that does not let you get at the pointer at all (so you are not tempted to delete it) may be a good idea for a new language.
Unlike the other posters here, I think this may be possible. You should be able to extract the compiled code from an output.obj file. Since the GCC tools work on Windows and can read.obj's produced by VC++ and link them into a.exe, apparently the.obj file is either described by Microsoft or has been successfully reverse-engineered.
Personally I have not seen much speed difference in speed between our Linux versions and IntelCC-compiled Windows versions. GCC has improved considerably in the last few years.
I have quite successfully linked C++ libraries compiled with GCC, VC++, and the IntelCC compiler with no problems. It appears to be ok. Perhaps code that relies on internals of STL would fail, but at least pointers to STL objects actually port back and forth.
I agree that VC++ produces faster code than GCC. Don't really know how much, because we don't use GCC on Windows anymore because of this, except to make dependencies for the makefiles. Can't be too much today, as our GCC-compiled Linux versions seem to run at the same speed as the IntelCC compiled Windows version.
The IntelCC compiler produces code almost twice as fast as VC++6. I believe VC++7 is much better, however, but have not tested it.
This is another weird troll, there have been a lot of them lately. They attack Linux, but rather than with logical things, they say somewhat nonsensical things that have little to do with the problems with Linux and often are complete opposites. Then they tack on faint praise for Linux at the end so that it looks like it came from a Linux supporter.
When you "go to WalMart and buy a new printer" the reason it "works in Windows" is that there was a DISK IN THE BOX WITH THE PRINTER WITH THE DRIVER ON IT!!! This has nothing to do with the "ease of downloading drivers". To the average user, a driver for either Windows or Linux on the net might as well be on Pluto, both are equally and utterly impossible for them to get or use. This appears to be an attempt to deflect critisism that the real advantage of Windows is it's monopooly position so that drivers are only written for it.
Every single toolkit for Linux has a Windows port, and are used quite a bit, to write all that "freeware" you are talking about. I recieve huge numbers of questions about the Windows version of my FLTK toolkit, more than about the Linux version, so no foolish claiming they are not used. And I'd like you to explain why there is so much interest in a free software toolkit on Windows (and it's not from Linux fans trying to be portable, some of the users are so stupid they don't know WIndows accepts forward slashes in the filenames and tried to submit a patch to reverse them all!). By definition Windows has at least the same number of toolkits as Linux. Then you can add on the dozens of Windows-only toolkits, including FOUR from Microsoft itself. This I find particularily insulting, as you are basically saying that "innovation" is a bad idea, except when a single powerful entity does it. Face it, you cannot "innovate" and not be "different", and that means there will be multiple solutions to the same problem!
In my experience old software is about the same on Linux and Windows. *really* old software appears to work on both of them. With the appearance of C++ and really large shared libraries, old software started to break on new systems. I certainly have encountered plenty of large Windows applications that will not run on Windows XP. At work we are still running W2K and NT because Houdini will not run on the newer system. (The Linux distributors are idiots for not testing old software, however. In many cases just copying the libraries off my older machine will make the software work, with no conflicts at all. They really should include those things!)
You also realize that.NET is a "new and different toolkit" that most Windows programmers are totally unfamiliar with, do you?
I think the point is that hackers certainly do try and target Linux machines. Yes it has only 3% of the desktops, but it runs 30% or more of the Internet and it would be extremely interesting to a hacker to compromise Linux. The fact is they are having a much harder time, despite having complete and detailed documentation and source code available to them. This is a fact that the PHB does not want to hear.
It was really annoying. I believe the files were called.DS_Store, they stored where the user dragged the icons to. Not only that, they setuid the file browser program so it could write these anywhere (an obvious bad idea today, but perhaps they were not aware of it). It probably would screw up remote mounts though I never used that. Personally I would not mind if when you visited a directory it just reset to your preferred view style, so imho these files are worse than useless.
The modern freedesktop.org design seems to be to store all this junk in a single directory under the home directory of the user. This makes it much faster to access, and it is clear that it is not vital information, and it is easy to dispose of it all.
According to the linked pages, he previously put no indication of any license on the images. This means they could not be reused for anything, per US copyright law. Everything you create is copyrighted by default.
Even if they completly screwed up all that Microsoft would have to do is stop making this plugin and pull TurboLinux's right to distribute it. Despite all the attempts by Bill Gates to brainwash people into believing otherwise, using GPL code does not cause you to have to give away everything you ever wrote. That is a damn lie, one of the biggest to come out of him.
More to the point, it is pretty obvious that xine allows binary plugins to be used. They sure haven't complained about their code being used to run existing Windows DLL's, have they?
This sort of sounds reasonable, but everybody knows that the kernel and rebooting spews pages and pages of gibberish to the average user. Everybody ignores it, or hides it behind a graphic splash screen.
Also maybe they should consider writing their stuff so it looks like one module, not many?
Unfortunately I think it will have to report tainted modules even if they are unloaded. So just having some way to list currently tainted modules won't get rid of the need for the messages.
Calling strcmp() cannot overflow a buffer, since it does not write anything.
And the \0 is the method C uses to record the string's size. So "checking for the size" means finding the first \0!
No, this is like taking Metallica's music and claiming you wrote and performed it.
By definition, anything "less restrictive than the GPL" cannot prevent you from doing something that the GPL allows you to do. Therefore there is no reason not to dual-license the code as both GPL and BSD.
If you say "but my code can't be GPL'd" then you have made a rule that is obviously more restrictive than the GPL (which obvioiusly allows GPL'd code).
Everybody trying this argument is really saying they want something *more* restrictive than the GPL. They word their arguments very creativly, but they all are equivalent to saying that they require that nobody make a derivative work other than the original author. Now that is a perfectly logical view on how to control your own creative work, but unfortunatly the kernel developers are uninterested in fixing your code under those restrictions. Maybe you can change their mind, but stop trying to lie and say you are "less restrictive than the GPL".
The GPL does not mean you are forced to accept their patches either. So they would have to fork it anyway if you made it GPL/BSD dual-licensed.
Actually it is quite impossible to find any reason to not dual-license your BSD code, since there is nothing the GPL allows somebody to do that the BSD license does not.
You could use normal copyright, but I don't think the kernel developers are interested in debugging your source code in that case, either, since they have to submit the fixes back to you for them to be incorporated, and everybody would have to get the fixed version from you.
First of all, if Office 2003 worked even if that function returned false, it would be like the current situation. Modules will load and run without claiming they are GPL.
SInce it is necessary to make Office 2003 work, Wine certainly has the right to return true. However when you run Office 2003 atop Wine, you don't have the right to call Microsoft and use their time and money to debug your installation and to lie to them and keep telling them you are running a real copy of Windows.
Nonsense.
This is like circumventing the DRM in an XBox (perfectly fine) but then trying to get your money back or the machine fixed under warranty by Microsoft. It's like printing the Microsoft copyright on the new rom chip in an attempt to make them think you have not broken the machine yourself.
You do realize that it is physically possible to have *BOTH* the source code and a binary version at the same time, do you? Perhaps you were taught that this was impossible in your MCSE class?
This is not the same, because the string is not needed for the module to work. It can say anything it wants.
This is more like the manufacturer actually printing "official Lexmark ink cartridge" on the cartridge.
Imagine if the printer failed and the user sent it to Lexmark for it to be fixed. Would Lexmark really be out of line if they claimed that the user broke it by putting in that unapproved cartridge?
For de-interlacing you need to get the second field before you can figure out what to display. So there is 1/30 second there (assumming you wait until the end of the second field before displaying the result of the first one, if you really can sync it up carefully you could get the delay down to 1/60 second).
It does seem compensation is the only solution. But there is a problem: lots of high-end equipment produces the sound and sends it to the speaker without any intervention from the tv (ie the speakers are plugged into the stereo amp, which is plugged into the dvd player, not the tv). So it's more like the compensation has to be there.
I would think you need to compensate for the speed of sound as well if you are far enough away from the tv screen. Right now though these problems may cancel out some...
If you took Metallica's songs and somehow managed to convince people you wrote and performed them, and then sold them for as much or more than Metallica's publisher gets, then maybe you might be as low as a typical GPL violator.
How about if you keep your precious model secret like they used to do in the good ol' days? If you only let people see renderings they can't steal very much, can they?
Actually you are legally bound by copyright. The GPL is actually a license to break copyright, if you follow certain rules. In fact the GPL does not force you to do anything.
This is why it is impossible to "test the GPL in court". That's like me offering you a candy bar, but you can refuse it. There is no reason for you to make a court case that somehow says it is illegal for me to offer you a candy bar, because even if you win the result for you is exactly like you refused to get it, a result you can already get.
This is also why it is impossible for the GPL to say "not for military use". If in fact the US government had a law that said "by default everything you make is not for military use unless you explicitly state otherwise" then it would be possible to make a "GPL" that restricted military use (or partially restricted it, like you could say only the Navy can use it, but not the Army).
.a stands for archive. When the Unix compilers were designed they reused a file format that was supposed to "archive" several files into one. I would guess that some of those archive programs had problems and insisted on the extension being ".a", which is why they chose the completely unfriendly and un-Unix-like "lib" prefix rather than just naming the files ".lib" (or maybe ".l" since they really liked short names then).
.a being used for *any* other purpose than code libraries, even back in 1970. Also the format has been hacked plenty and is probably useless for anything other than code libraries today (see the ranlib program, and the fact that Linux does not require it anymore, for details). So IMHO this is one of the many mistakes in Unix design that should be fixed. Perhaps just make the linker look for foo.lib first, and fall back on libfoo.a second. Only problem now is that there may be sites that rely on there not being a name conflict between Unix and Windows libraries...
I am unaware of
".so" stands for "shared object" which is much more descriptive than "dll". However I would like to see a scheme by which the same library can be shared or static, with the linker able to choose at link time (perhaps with a default in the library), and both are named ".lib" or ".l".
You are right about that. In fact in our code the STL objects are only being modified by one file and thus only one compiler, only the portability of declaring a pointer to one is tested. However it is true that a pointer to an STL container declared in one compiler links and has the same name as the same pointer declared in another compiler. This means the name mangling is compatable.
In my main software project I have used a very specific "foreach" macro (it only works with a single type that we use a lot). Whether this is a good idea or a bad one, I have not had any problems with syntax highlighting or automatic indentation, in Emacs and in several IDE's.
This is an extremely common design.
If the caller is responsible for deleting objects, the caller must also maintain a pointer to all those objects so it can delete them. This is a huge waste of time and space if in fact the toolkit itself has to keep track of such pointers anyways. And if the code for deleting a window can assumme that all widgets inside that window are deleted as well it can vastly simplify the code.
The fact that there is no way to create an arbitrary subclass other than "new" in C++ might be a defect, I suppose some interface that does not let you get at the pointer at all (so you are not tempted to delete it) may be a good idea for a new language.
Unlike the other posters here, I think this may be possible. You should be able to extract the compiled code from an output .obj file. Since the GCC tools work on Windows and can read .obj's produced by VC++ and link them into a .exe, apparently the .obj file is either described by Microsoft or has been successfully reverse-engineered.
Personally I have not seen much speed difference in speed between our Linux versions and IntelCC-compiled Windows versions. GCC has improved considerably in the last few years.
He's talking about ".lib" files.
.a == .lib .so == .dll .o == .obj
How to translate Unix-gibberish into Microsoft-gibberish:
I have quite successfully linked C++ libraries compiled with GCC, VC++, and the IntelCC compiler with no problems. It appears to be ok. Perhaps code that relies on internals of STL would fail, but at least pointers to STL objects actually port back and forth.
I agree that VC++ produces faster code than GCC. Don't really know how much, because we don't use GCC on Windows anymore because of this, except to make dependencies for the makefiles. Can't be too much today, as our GCC-compiled Linux versions seem to run at the same speed as the IntelCC compiled Windows version.
The IntelCC compiler produces code almost twice as fast as VC++6. I believe VC++7 is much better, however, but have not tested it.
This is another weird troll, there have been a lot of them lately. They attack Linux, but rather than with logical things, they say somewhat nonsensical things that have little to do with the problems with Linux and often are complete opposites. Then they tack on faint praise for Linux at the end so that it looks like it came from a Linux supporter.
.NET is a "new and different toolkit" that most Windows programmers are totally unfamiliar with, do you?
When you "go to WalMart and buy a new printer" the reason it "works in Windows" is that there was a DISK IN THE BOX WITH THE PRINTER WITH THE DRIVER ON IT!!! This has nothing to do with the "ease of downloading drivers". To the average user, a driver for either Windows or Linux on the net might as well be on Pluto, both are equally and utterly impossible for them to get or use. This appears to be an attempt to deflect critisism that the real advantage of Windows is it's monopooly position so that drivers are only written for it.
Every single toolkit for Linux has a Windows port, and are used quite a bit, to write all that "freeware" you are talking about. I recieve huge numbers of questions about the Windows version of my FLTK toolkit, more than about the Linux version, so no foolish claiming they are not used. And I'd like you to explain why there is so much interest in a free software toolkit on Windows (and it's not from Linux fans trying to be portable, some of the users are so stupid they don't know WIndows accepts forward slashes in the filenames and tried to submit a patch to reverse them all!). By definition Windows has at least the same number of toolkits as Linux. Then you can add on the dozens of Windows-only toolkits, including FOUR from Microsoft itself. This I find particularily insulting, as you are basically saying that "innovation" is a bad idea, except when a single powerful entity does it. Face it, you cannot "innovate" and not be "different", and that means there will be multiple solutions to the same problem!
In my experience old software is about the same on Linux and Windows. *really* old software appears to work on both of them. With the appearance of C++ and really large shared libraries, old software started to break on new systems. I certainly have encountered plenty of large Windows applications that will not run on Windows XP. At work we are still running W2K and NT because Houdini will not run on the newer system. (The Linux distributors are idiots for not testing old software, however. In many cases just copying the libraries off my older machine will make the software work, with no conflicts at all. They really should include those things!)
You also realize that
I think the point is that hackers certainly do try and target Linux machines. Yes it has only 3% of the desktops, but it runs 30% or more of the Internet and it would be extremely interesting to a hacker to compromise Linux. The fact is they are having a much harder time, despite having complete and detailed documentation and source code available to them. This is a fact that the PHB does not want to hear.
It was really annoying. I believe the files were called .DS_Store, they stored where the user dragged the icons to. Not only that, they setuid the file browser program so it could write these anywhere (an obvious bad idea today, but perhaps they were not aware of it). It probably would screw up remote mounts though I never used that. Personally I would not mind if when you visited a directory it just reset to your preferred view style, so imho these files are worse than useless.
The modern freedesktop.org design seems to be to store all this junk in a single directory under the home directory of the user. This makes it much faster to access, and it is clear that it is not vital information, and it is easy to dispose of it all.