Although I don't like Microsoft's software and it's a real pain having to get all the latest patches, they do at least tell us when they've got a patch. This is an inadequacy with Free Software that in general needs to be addressed, and it will make a nice revenue stream.... Even though the software is Free we are still willing to pay someone to tell us what we need to patch.
Doesn't every distro have a security list? I'd think RedHat is creating more problems than they're solving. They give away the distro then make you jump through hoops or pay to patch it. Can you imagine what would happen if WindowsUpdate cost $5/month? It's a frightening thought.
Get used to it. US workers cannot get jobs in Canada, Europe, Australia, etc. without first applying, and getting necessary work visas. To get a work visa, you must have an employer who has applied to get you in, and has demonstrated that there isn't local talent who could do the job you're being hired for.
It seems that these standards are near impossible to apply, and it goes both ways. When I was stationed in Germany my wife (a US citizen) got a job working for a German photographer. It was basicly light office work...hardly anything that native workers couldn't do. She had to get a SOFA stamp on her passport (Status of Forces Agreement), and her employer had to file some paperwork claiming that no German citizen would/could do the job. For the money he was paying, it's not suprising that no German would take the job.
I think you could solve the problem both here and in Germany by simply requiring employers that hire foreign citizens to pay them MORE than citizens working in the same job recieve. If their skills are so important, pay shouldn't be an issue right?
Thats what the article talks about, jobs being lost over seas. So yes they do come from all over to work here, just that the don't have to be here to have the same effect on taking our jobs.
Can you honestly say with a straight face that US companies have never destroyed any foreign labor markets? I mean, if Nike could make all their shoes cheaper with just 10 american workers and a room full of machines, would anyone here give two shits about putting 10,000 day-laborers in Malaysia out of work? This aspect of the problem (foreign countries doing things cheaper) is unsolvable. If we start building trade barriers everyone else will do the same. Problems with out own immigration laws are a different subject. They should be fixed to make US citizens more competitive in the US labor market.
Interesting.. The definition of racketeering includes things like "section 2318 (relating to trafficking in counterfeit labels for phonorecords, computer programs or computer program documentation or packaging and copies of motion pictures or other audiovisual works), section 2319 (relating to criminal infringement of a copyright)"
If I'm reading it correctly RICO makes it illegal to invest the proceeds of "racketeering" in any business which conducts interstate commerce. One could certainly argue that the directors of SCO are involved in a conspiracy to criminally infringe copyrights. They can't claim the GPL is invalid and continue distributing GPL'd software without infringing someone's copyright. They're also obviously investing some of the money back into SCO which does indeed conduct interstate commerce.
So...unless Sharp broke something, this should really say "Sharp supports only their Windows sync software," but several solutions are available for Linux, none of which should scare the./ crowd at all.
Sharp did break something. They changed the way Syncing works and the way data for the PIM apps is stored. The SL-5500/5000 with any of the 2.x ROMs syncs fine with QtopiaDesktop. Everything beyond that is broken when it comes to syncing with Linux.
>> it's basically impossible to sync them with Linux
>Using Sharp-supported software, yes. Using other free solutions, no.
This isn't entirely true. With the SL-5500 you can sync it using QtopiaDesktop as long as you're running one of the old ROMs. If you've upgraded your SL-5500 to version 3.1 you're screwed. If you bought a SL-5600 you're screwed. I assume that you're also screwed with these newer models. You'd do much better syncing Linux with a run of the mill Palm. This thread is informative on the subject.
It doesn't help to pretend the Zaurus works properly with Linux when it's only true under a very limited set of circumstances. It just ends up pissing people off when they discover they've been misled on a high dollar purchase like this. I find it almost insulting that Sharp leaves us in the position where the protocols have to be reverse engineered.
SCO's biggest mistake here is the outrageous fee they're trying to charge. They would have done much better by charging some trivial amount like five or ten dollars per CPU. At $699 it would cost me over $20,000 to buy licenses for my servers. For that much money an attorney sounds affordable.
It may not have been free at some point in the past, according to your version of events, but it certainly is now, which is all that really matters, isn't it?
Not if you look at SCO's argument against the idea that they accidentally GPL'd the code by distributing it. SCO may have signed off on this code, but it's clear that they did so after it had already been released by SGI. I pointed out in a previous post where you can locate a patch containing ate_utils.c that dates back prior to Jan 2002.
Even so, the license Caldera used is equivalent to the four clause BSD license. It is not compatible with the GPL because it adds additional restrictions (mention of Caldera in any advertising.) The Caldera release may indeed show that the code was considered worthless just a short time back, but it doesn't at all provide a valid license to use he code in the Linux kernel. Considering the fact that Caldera now hates you, me, and everyone else that uses Linux, I doubt we'll have any luck convincing them to switch to the GPL compatible three clause BSD license.
The code was around before it was put into the main tree. Look at the date on the 2.4.16-ia64 patch, then open the file and you'll see ate_utils.c. I haven't followed it all the way up the patch list, but it's certain that ate_utils.c was around PRIOR to the Caldera relicensing.
>>Slander/Libel law broadened to include "negative and harmful" speech towards economic activity.
>Why not? We already have laws that cover hurt feelings. (AKA "hate speech.")
That's perfect. Negative reviews will be a "hate crime". They can even throw out some 90 year old segregationist to be against the changes. Guaranteed to pass with flying colors.
It DOES overlap.. Compare malloc() is BSD3 and System-3. They're identical. You can follow malloc() and free() all the way back up the chain to the earliest Unix releases. At the point the file carried a comment stating that it was copyright 1973 by Bell labs.
The BSD 2.x & 3.x version are not free. They're taken from Unix. The BSD 4.4 version is a different story.
No.. He's pointing out (as was done on the LKML that any use of code under the Caldera license requires that you include a (c) Caldera in the source. This file doens't do that. More importantly it was release PRIOR to Caldera relicensing the Ancient Unix code.
A lot of people want to think since it's in BSD it must be free. This just shows how dangerous a little knowledge can be. Not all BSD's are free. Originally you needed a Unix license to use the BSD code, and all of the BSD examples people keep quoting are from versions that required a Unix license. The only BSD code you can use and feel confident about comes from version 4.4 BSD-lite and beyond. Anything prior to that in not free. Whether or not Caldera's release of the Ancient Unix code makes these older versions of BSD "free" is questionable (and given Caldera/SCO's sue happy management...it's just stupid to use it anyway.) It's unfortunate that the old BSD's are so readily available. Too many people are geting confused. It all just drills home the fact that if you're accepting patches from someone else you need them to let you know exactly where they took material from if they're reusing code. They might believe the code they're using is free when in fact it isn't.
Not that I think this is a case of someone getting confused. If I had to guess I'd say that someone at SGI was just being lazy and grabbed the first version of malloc() and free() that they could find. There are better versions available (in the Linux kernel even) and they don't flow from the questionably licensed Unix sources.
This entire thing is old news though. The Kernel team were told about this code quite a while back and it was prompty removed. If I remember correctly ate_utils is in Kernel versions 2.4.19 to 2.4.21. It will not be in 2.4.22. It's also available in a seperate ia64 port package for kernel versions prior to 2.4.19 on kernel.org.
Actually I looked at this before and malloc() and free() are in BSD-Lite. They've been rewritten though. This version is tainted. It goes back all the way to Bell Labs with a copyright of 1973. There is a version in BSD-Lite that is guaranteed free software, but it looks different.
Come on now. I took the idea of comparing sources using MD5 hashes that Michael Chaney and Rick Bradley came up with, tweaked it a bit, compared Sys3 with 2.4.21 and posted this match on/. a while back.
When it was posted on the Linux Kernel Mailing List they gave me a little shout-out. If when SCO says "a team of code comparison experts" they actually mean some guy on slashdot...well...they could at least give me a mention. Not like I really care about getting a proper "* Thanks LSPD" in the SCO Legal Case Changelog, but give me a break.
BSD 2.11 is not free. You need a Unix license to use it....for the very reason that you've pointed out. Much of BSD prior to 4.4 was taken directly from Unix. For 4.4 they rewrote all this garbage.
This doesn't particularly matter since ate_utils.c was removed from the kernel some time back.
Beyond that though, Caldera put the ancient unix under a BSD license AFTER ate_utils.c was available on kernel.org. It wasn't in the main tree at the time, but it was available as in the ia64 port.
It's rather funny that SCO would show this piece of code. It does illustrate that someone at SGI pulled these functions from a bad source (it has appeared in print also, so it's possible the programmer got it from a book rather than a Unix tree), but the actual functions are trivially simple to replace. If you really think it through you're left wondering why in the world someone would use the Unix version of malloc and free rather than the slew of better written and untainted versions that are available.
Previous slashdot discussion is here. LKML thread is here.
...but the installer's lack of ReiserFS or 2.4 support is irritating
Both ReiserFS and the 2.4 kernel are supported by the Debian installer. They have been since Woody was released. Try downloading either CD #1 or the bf2.4 floppies.
This means I have to rebuild every Debian box in the company once a year.
Huh?? Potato was supported from August 2000 to June 2003. Functionality isn't supposed to change at all between major releases unless a piece of software is useless without a fix. I didn't even notice the change from 3.0r0 to 3.0r1 on my servers.
Check the release history. Also take a look at the changes from 3.0r0 to 3.0r1. The majority were simply security updates moving into main. That's a far cry from what RedHat, Mandrake, and SuSE mean by a new release. I expect RHAS will follow a similar system. Why would you want a CD set that needs several hundred MB of security updates?
Call me crazy, but I never really liked Glade. QT/KDE-Designer is ok, but the documentation on integrating it's use into Kdevelop was rather poor the last time I looked.
As ass-backwards as it sounds, I find it easier to put the UI together by hand in QT, GTK and WX. I think if you look through the source code for most of the projects out there you'll see that the designers took the same path and limited use of Glade and QT-Designer to popup dialogs and wizards.
Still, I'd be perfectly happy to see both QT and GTK integrate their RAD tools proprely into the 2 main IDEs (anjuta and kdevelop.) As things stand though, I don't see either one competing well with Visual C++ in this regard.
Still, your point is valid though. WX is lagging in this area. Given the state of the QT and GTK offerings though, I wouldn't say it's critical.
Slashdot Mirror
Although I don't like Microsoft's software and it's a real pain having to get all the latest patches, they do at least tell us when they've got a patch. This is an inadequacy with Free Software that in general needs to be addressed, and it will make a nice revenue stream. ... Even though the software is Free we are still willing to pay someone to tell us what we need to patch.
Doesn't every distro have a security list? I'd think RedHat is creating more problems than they're solving. They give away the distro then make you jump through hoops or pay to patch it. Can you imagine what would happen if WindowsUpdate cost $5/month? It's a frightening thought.
Get used to it. US workers cannot get jobs in Canada, Europe, Australia, etc. without first applying, and getting necessary work visas. To get a work visa, you must have an employer who has applied to get you in, and has demonstrated that there isn't local talent who could do the job you're being hired for.
It seems that these standards are near impossible to apply, and it goes both ways. When I was stationed in Germany my wife (a US citizen) got a job working for a German photographer. It was basicly light office work...hardly anything that native workers couldn't do. She had to get a SOFA stamp on her passport (Status of Forces Agreement), and her employer had to file some paperwork claiming that no German citizen would/could do the job. For the money he was paying, it's not suprising that no German would take the job.
I think you could solve the problem both here and in Germany by simply requiring employers that hire foreign citizens to pay them MORE than citizens working in the same job recieve. If their skills are so important, pay shouldn't be an issue right?
Thats what the article talks about, jobs being lost over seas. So yes they do come from all over to work here, just that the don't have to be here to have the same effect on taking our jobs.
Can you honestly say with a straight face that US companies have never destroyed any foreign labor markets? I mean, if Nike could make all their shoes cheaper with just 10 american workers and a room full of machines, would anyone here give two shits about putting 10,000 day-laborers in Malaysia out of work? This aspect of the problem (foreign countries doing things cheaper) is unsolvable. If we start building trade barriers everyone else will do the same. Problems with out own immigration laws are a different subject. They should be fixed to make US citizens more competitive in the US labor market.
Downside: Uh... it just came out... and it's making some big, big claims involving fuzzy logic. I think it's gonna need some testing first, eh?
This is the same technique that was used to find the similarity between malloc.c in ancient Unix and ate_utils.c in Linux 2.4.21.
Interesting.. The definition of racketeering includes things like "section 2318 (relating to trafficking in counterfeit labels for phonorecords, computer programs or computer program documentation or packaging and copies of motion pictures or other audiovisual works), section 2319 (relating to criminal infringement of a copyright)"
If I'm reading it correctly RICO makes it illegal to invest the proceeds of "racketeering" in any business which conducts interstate commerce. One could certainly argue that the directors of SCO are involved in a conspiracy to criminally infringe copyrights. They can't claim the GPL is invalid and continue distributing GPL'd software without infringing someone's copyright. They're also obviously investing some of the money back into SCO which does indeed conduct interstate commerce.
So...unless Sharp broke something, this should really say "Sharp supports only their Windows sync software," but several solutions are available for Linux, none of which should scare the ./ crowd at all.
Sharp did break something. They changed the way Syncing works and the way data for the PIM apps is stored. The SL-5500/5000 with any of the 2.x ROMs syncs fine with QtopiaDesktop. Everything beyond that is broken when it comes to syncing with Linux.
>> it's basically impossible to sync them with Linux
>Using Sharp-supported software, yes. Using other free solutions, no.
This isn't entirely true. With the SL-5500 you can sync it using QtopiaDesktop as long as you're running one of the old ROMs. If you've upgraded your SL-5500 to version 3.1 you're screwed. If you bought a SL-5600 you're screwed. I assume that you're also screwed with these newer models. You'd do much better syncing Linux with a run of the mill Palm. This thread is informative on the subject.
It doesn't help to pretend the Zaurus works properly with Linux when it's only true under a very limited set of circumstances. It just ends up pissing people off when they discover they've been misled on a high dollar purchase like this. I find it almost insulting that Sharp leaves us in the position where the protocols have to be reverse engineered.
SCO's biggest mistake here is the outrageous fee they're trying to charge.
They would have done much better by charging some trivial amount like
five or ten dollars per CPU. At $699 it would cost me over $20,000 to buy
licenses for my servers. For that much money an attorney sounds affordable.
The trick is for the relay site to use a meta refresh instead of a HTTP redirect. It always blocks out the referrer.
Doesn't work for images, but who cares?
You think Dell goes to its partners and asks them to supply trialware so they can bundle it?
Of course they do. You think Dell ships it's computers with tialware and doesn't get a cut of the profits?
You forgot step #3
...continued...
Budget Linux CDs claims they will have a CD set available as soon as any files are released.
It may not have been free at some point in the past, according to your version of events, but it certainly is now, which is all that really matters, isn't it?
Not if you look at SCO's argument against the idea that they accidentally GPL'd the code by distributing it. SCO may have signed off on this code, but it's clear that they did so after it had already been released by SGI. I pointed out in a previous post where you can locate a patch containing ate_utils.c that dates back prior to Jan 2002.
Even so, the license Caldera used is equivalent to the four clause BSD license. It is not compatible with the GPL because it adds additional restrictions (mention of Caldera in any advertising.) The Caldera release may indeed show that the code was considered worthless just a short time back, but it doesn't at all provide a valid license to use he code in the Linux kernel. Considering the fact that Caldera now hates you, me, and everyone else that uses Linux, I doubt we'll have any luck convincing them to switch to the GPL compatible three clause BSD license.
Look before you post..
The code was around before it was put into the main tree. Look at the date on the 2.4.16-ia64 patch, then open the file and you'll see ate_utils.c. I haven't followed it all the way up the patch list, but it's certain that ate_utils.c was around PRIOR to the Caldera relicensing.
>>Slander/Libel law broadened to include "negative and harmful" speech towards economic activity.
>Why not? We already have laws that cover hurt feelings. (AKA "hate speech.")
That's perfect. Negative reviews will be a "hate crime". They can even throw out some 90 year old segregationist to be against the changes. Guaranteed to pass with flying colors.
So anything that appeared in BSD before 1992 is open source under a BSD license even if it came directly from UNIX.
You mean AFTER 1992 right?
It DOES overlap.. Compare malloc() is BSD3 and System-3. They're identical. You can follow malloc() and free() all the way back up the chain to the earliest Unix releases. At the point the file carried a comment stating that it was copyright 1973 by Bell labs.
The BSD 2.x & 3.x version are not free. They're taken from Unix. The BSD 4.4 version is a different story.
No.. He's pointing out (as was done on the LKML that any use of code under the Caldera license requires that you include a (c) Caldera in the source. This file doens't do that. More importantly it was release PRIOR to Caldera relicensing the Ancient Unix code.
A lot of people want to think since it's in BSD it must be free. This just shows how dangerous a little knowledge can be. Not all BSD's are free. Originally you needed a Unix license to use the BSD code, and all of the BSD examples people keep quoting are from versions that required a Unix license. The only BSD code you can use and feel confident about comes from version 4.4 BSD-lite and beyond. Anything prior to that in not free. Whether or not Caldera's release of the Ancient Unix code makes these older versions of BSD "free" is questionable (and given Caldera/SCO's sue happy management...it's just stupid to use it anyway.) It's unfortunate that the old BSD's are so readily available. Too many people are geting confused. It all just drills home the fact that if you're accepting patches from someone else you need them to let you know exactly where they took material from if they're reusing code. They might believe the code they're using is free when in fact it isn't.
Not that I think this is a case of someone getting confused. If I had to guess I'd say that someone at SGI was just being lazy and grabbed the first version of malloc() and free() that they could find. There are better versions available (in the Linux kernel even) and they don't flow from the questionably licensed Unix sources.
This entire thing is old news though. The Kernel team were told about this code quite a while back and it was prompty removed. If I remember correctly ate_utils is in Kernel versions 2.4.19 to 2.4.21. It will not be in 2.4.22. It's also available in a seperate ia64 port package for kernel versions prior to 2.4.19 on kernel.org.
Actually I looked at this before and malloc() and free() are in BSD-Lite. They've been rewritten though. This version is tainted. It goes back all the way to Bell Labs with a copyright of 1973. There is a version in BSD-Lite that is guaranteed free software, but it looks different.
Come on now. I took the idea of comparing sources using MD5 hashes that Michael Chaney and Rick Bradley came up with, tweaked it a bit, compared Sys3 with 2.4.21 and posted this match on /. a while back.
When it was posted on the Linux Kernel Mailing List they gave me a little shout-out. If when SCO says "a team of code comparison experts" they actually mean some guy on slashdot...well...they could at least give me a mention. Not like I really care about getting a proper "* Thanks LSPD" in the SCO Legal Case Changelog, but give me a break.
Bastards...
BSD 2.11 is not free. You need a Unix license to use it....for the very reason that you've pointed out. Much of BSD prior to 4.4 was taken directly from Unix. For 4.4 they rewrote all this garbage.
Any version of BSD prior to BSD-Lite (4.4?) requires a Unix license.
This doesn't particularly matter since ate_utils.c was removed from the kernel some time back.
Beyond that though, Caldera put the ancient unix under a BSD license AFTER ate_utils.c was available on kernel.org. It wasn't in the main tree at the time, but it was available as in the ia64 port.
It's rather funny that SCO would show this piece of code. It does illustrate that someone at SGI pulled these functions from a bad source (it has appeared in print also, so it's possible the programmer got it from a book rather than a Unix tree), but the actual functions are trivially simple to replace. If you really think it through you're left wondering why in the world someone would use the Unix version of malloc and free rather than the slew of better written and untainted versions that are available.
Previous slashdot discussion is here. LKML thread is here.
...but the installer's lack of ReiserFS or 2.4 support is irritating
Both ReiserFS and the 2.4 kernel are supported by the Debian installer. They have been since Woody was released. Try downloading either CD #1 or the bf2.4 floppies.
This means I have to rebuild every Debian box in the company once a year.
Huh?? Potato was supported from August 2000 to June 2003. Functionality isn't supposed to change at all between major releases unless a piece of software is useless without a fix. I didn't even notice the change from 3.0r0 to 3.0r1 on my servers.
Check the release history. Also take a look at the changes from 3.0r0 to 3.0r1. The majority were simply security updates moving into main. That's a far cry from what RedHat, Mandrake, and SuSE mean by a new release. I expect RHAS will follow a similar system. Why would you want a CD set that needs several hundred MB of security updates?
Call me crazy, but I never really liked Glade. QT/KDE-Designer is ok, but the documentation on integrating it's use into Kdevelop was rather poor the last time I looked.
As ass-backwards as it sounds, I find it easier to put the UI together by hand in QT, GTK and WX. I think if you look through the source code for most of the projects out there you'll see that the designers took the same path and limited use of Glade and QT-Designer to popup dialogs and wizards.
Still, I'd be perfectly happy to see both QT and GTK integrate their RAD tools proprely into the 2 main IDEs (anjuta and kdevelop.) As things stand though, I don't see either one competing well with Visual C++ in this regard.
Still, your point is valid though. WX is lagging in this area. Given the state of the QT and GTK offerings though, I wouldn't say it's critical.