It's what causes Linux to be more mainstream
on
Red Hat Backlash?
·
· Score: 1
So what about that software and the distribution would lock you in to a particular distribution? What precisely is it that would be incompatible between distributions? Maybe this would help clarify what the problem is that needs solved.
The unwillingness to join the LSG has me more than a bit concerned. It appears that RH is taking the "...we don't need to adhere to any standards..." mantra that is so deeply rooted in the MS mentality.
I'm not sure about that. The critical standards are things like Posix, X11, the various RFCs, the FSSTND, things like that that are already there and RedHat seems to follow those either deliberately or by default. The LSB seems to be going in the direction of "This is the standard window manager and desktop, this is the standard X11 widget set, and so on.", and RedHat seems to be saying that that's not useful. I agree with Redhat: there should not be a standard window manager as such. There should be one like twm that you can expect to have on all distros, but you select the window managers, widget sets and such depending on what software you want and what it needs and then select a distro based on which one provides what you need with the least fuss. And if you like the rest of Redhat but want KDE, you just buy RedHat and install KDE, confident that RedHat follows all the standards KDE needs it to follow.
Standrdizatin, Componentization, Inovaction or els
on
Linux 2.2.3 Released
·
· Score: 1
Multiple incompatible versions of shared libraries is why shared libraries have version numbers. I've got 2 variations of libc4, 5 variations of libc5 and 2 variations of libc6 on my system right now, all in/usr/lib with no problems.
As for keeping packages seperate and building a big symlink farm, I merely let the package manager keep track of which files belong to which packages. That's what it's for, after all. One version of a package is the primary installed version, and if I need other versions I install them elsewhere. Most often that's under my home directory for a new version of a package. Occasionally I get into a situation where I need to have multiple versions system-wide, but that only amounts to about 7 packages out of the 200+ I have installed and I can manage 7 package-specific directories easier than I can the/opt tree and related symlink farm for 200+ packages.
Standrdizatin, Componentization, Inovaction or els
on
Linux 2.2.3 Released
·
· Score: 1
#1, that's not a kernel issue. #2, yeah, right, replace a few big directories with a few hundred small ones and require 8k PATHs, smooth move Clyde. For what you want done with/usr, see/bin,/lib etc.. I've dealt with/opt and IMHO is a major headache without providing any advantage over a good package manager (flames about RedHat vs. Debian to/dev/null).
Why shouldn't you read the threads? It's not like this isn't a public forum, after all. And it's somewhat reassuring to see that at least some of the reporters do read forums like Slashdot and see what the response to their articles is.
Personally, I don't much like broad limits on liability. If a company blew it, they should be responsible for the results. I'd prefer:
If the company discloses the problems up front, they cannot be held liable for more than the cost of users of their software switching to software that isn't affected.
If a company makes a statement in good faith and it turns out to be wrong, they cannot be held liable unless they are first given the chance to correct the problem.
No company can be held liable for the problems in someone else's software. If the application handles 4-digit dates correctly and the OS hands it the wrong current date, the app vendor cannot be sued.
If a company makes a statement that it knows is wrong, or refuses to make any statements about the state of their software, there are no limits on their liability.
The exception only covers modules that don't require kernel modifications. So it doesn't matter that they're claiming that the two are seperate products--the modules dependancy on the patches means it has to be GPL'ed.
I don't see this. You might have a point, if the kernel mods depended on the module ( ie. you can't run the modified kernel without the non-GPL module ). Their mods, from what I can tell, leave the kernel usable without their module and could in fact be used by modules other than theirs if someone wanted. When they released the GPL'd patches they essentially created a new published kernel interface subject to the GPL, and they can release a non-GPL module that uses that interface.
Frankly I'd rather not require all kernel modules to be GPL'd. It's just not in our interest. I'd like everything to be GPL'd, but given the choice between having the functionality non-GPL'd and not having the functionality, I'd rather have it.
From what I can see, they provide two things: the binary-only module, and the GPL'd modifications to the kernel sources needed to use the module. As long as they keep any mods to the kernel sources themselves GPL'd and in source form, the module itself should fall under the module exception. What would violate the license would be distributing a modified, binary-only kernel, and they aren't doing that.
This doesn't sound like a decision on long-distance from a user's point of view. It sounds like the old argument about under what circumstances, when a caller on Telco A's network places a call to someone served by Telco B, B owes A for routing the call to them. Also, according to the ruling, the existing agreements on reciprocal compensation still apply and the state PUC still has the final say in the matter. Sounds like a lot of uproar over very little.
Depends. You needed to recompile to use the ELF format, but a.out binaries would still run ( and still run today ) just fine if you included a.out support. This also applies to things like libc upgrades: when I upgraded to libc6 all my libc5-linked apps continued to run just fine, albeit using the libc5 libraries.
The userland tools that need recompiled are the ones that talk intimately to the kernel. Things like procps or sound drivers need rebuilt. Things like StarOffice should continue to work just fine, blissfully unaware of the kernel upgrade.
Linux, I think, has a much better record for letting older apps continue to run without breaking than Windows. Heck, just installing an NT service pack or a new version of their compiler can break things in the Windows world. They really need versioned DLLs.
If he has evidence, he has to tell you about it. If he doesn't, he probably will shortly. That's one of the chances you take in discovery, and it does work both ways.
This account of Beos/Compaq/MSFT issue is not true
on
Microsoft-Compaq-BeOS
·
· Score: 1
The characterization is misleading, yes. But, Be hasn't been involved heavily in this case ( as compared to, say, Netscape ). Boies is relying on their statements about what Compaq said to them, and I don't think Be would stick their nose in like this if they couldn't back that up, not considering the risk of annoying the judge by making claims in court you can't produce evidence to back up. So far, Boies has a pretty good track record of producing the evidence ( and MS is not happy about that at all ).
As for trusting or not trusting the validity, both MS and the DoJ have overt reasons to spin anything they present in their favor. MS, moreover, has already shown that they're willing to, under oath before a judge, misrepresent and edit evidence. If they've done that under those circumstances, I simply can't trust them not to do it again.
This account of Beos/Compaq/MSFT issue is not true
on
Microsoft-Compaq-BeOS
·
· Score: 1
I think the point was to provide evidence that MS has enough power and influence that a company like Compaq would feel that, if violating a non-disclosure agreement with another company would annoy MS and endanger their relationship with them, then keeping MS happy is worth the legal consequences of violating an NDA. That goes to the question of whether MS has enough power to be considered a monopoly ( albeit a bit obliquely ).
OTOH, it would be more impressive if DoJ could come up with more than a single such instance. A single instance is easily just an accident or oversight, multiple instances make a much better case.
As far as primary source material, I don't consider anything from either MS or DoJ a primary source, no matter what they claim. A copy of the transcript from some source not affiliated with any of the parties involved, that would be a good primary source.
It might be argued that Mr. Boies should have turned over a copy of his evidence before Mr. Rose took the stand, but playing games with the discovery process is nothing new.
Depends. During discovery you're obliged to turn over things your opponent asks for or about, but you're not obliged to volunteer information he hasn't asked for. If MS didn't ask if Boies had evidence Compaq had leaked confidential information to them, AFAIK Boies is entirely within his rights not to volunteer the information. Yes, Boies ambushed Compaq and MS with this. Part of his job is to pull suprises like this if they let him set them up.
The embarrassing part is that MS's attorneys keep letting these things happen. MS has done more for the government's case than any of the government's witnesses. That's sad.
As long as they don't interfere with fair-use copying, having the copyright information watermarked in and using it to prevent illegal copying sounds good. If they try to use it to prevent legal fair-use copying, that's another story.
I wonder what the result would be if, if they try to restrict legal copying, people just started denying the right to use their material to any entity that tried to restrict fair use of it's material.
I think that your point #3 is pretty accurate. Personally I use Linux at home, but I'd hate to see FreeBSD go away.
Point #2 makes a big assumption: that no programmer is interested in user interfaces. I think that's a bad assumption. I've no data to back it up, but it seems to me that the existence of things like KDE and GNOME indicate that there are programmers who like making things look as good as they work. And I think you underestimate the consequences of OSS programmers just plain getting ticked off and saying "I can do a better-looking job that that!".
Point #4 makes the assumption that the number of programmers capable of understanding the code is constant. I think that's wrong, and that as more and more complex code is available and people get more used to looking at code we'll see more and more people who understand it. I do know that, over the years, I've gone from being able to handle a few thousand lines of code at a time to a few hundred thousand lines. I can't be unique in that progression.
IMHO making them reveal their source code, while it would be suitably humiliating for them, isn't the best punishment. More appropriate would be to force their application divisions to use nothing in the OS that wasn't equally available to any other company, and to go through the same support lines as everyone else to get questions answered and bugs fixed. They could integrate their browser, for instance, but only if they had an interface that would let Netscape integrate Navigator in the same way and to the same degree. This'd level the playing field without giving MS an excuse to complain that lawyers are dictating OS design, and you can check compliance by checking the source code against the published interfaces without having to resort to opinion.
Brin's statements remind me of a book by David Drake, Lacey and his Friends. Cameras recorded literally every second of your life, everywhere. Not even the police were exempt. The only protection was that there was so much being recorded that random or casual searches had become impossible. Even with those limitations, Lacey was an unsettling example of what an unscrupulous person could do in that system. Adding modern computers and their ability to search vast quantities of data quickly to that gives me a very bad feeling.
No, I'm afraid I don't agree with Mr. Brin on this subject.
According to the report from the Seattle Times, the Win98 system was using a 56k modem while the Win3.1 system had a 33.6k one. The Win98 system could be 25% slower than the Win3.1 system and still appear faster.
Have the PTO put up a Web site. The examiners abstract the application and post the summary and complete application. The public gets 6 months to submit ( via Web form or e-mail ) examples of prior art, objections and such. The examiners then review the comments and see if anyone has valid prior art or other reasons not to grant the patent. If they don't have time to research each application, let interested parties do the research for them.
They'll still have to weed out flames and garbage, but that's got to be faster to do than researching the subject.
That happens even with wills drawn up by attorneys. All it takes is for the contesting party to have a better ( more expensive ) lawyer than you did. If you have any sense you have your will pre-probated and deal with any problems found before you kick off. That deals with all problems, regardless of who wrote the will.
Slashdot Mirror
So what about that software and the distribution would lock you in to a particular distribution? What precisely is it that would be incompatible between distributions? Maybe this would help clarify what the problem is that needs solved.
The unwillingness to join the LSG has me more than a bit concerned. It appears that RH is taking the "...we don't need to adhere to any standards..." mantra that is so deeply rooted in the MS mentality.
I'm not sure about that. The critical standards are things like Posix, X11, the various RFCs, the FSSTND, things like that that are already there and RedHat seems to follow those either deliberately or by default. The LSB seems to be going in the direction of "This is the standard window manager and desktop, this is the standard X11 widget set, and so on.", and RedHat seems to be saying that that's not useful. I agree with Redhat: there should not be a standard window manager as such. There should be one like twm that you can expect to have on all distros, but you select the window managers, widget sets and such depending on what software you want and what it needs and then select a distro based on which one provides what you need with the least fuss. And if you like the rest of Redhat but want KDE, you just buy RedHat and install KDE, confident that RedHat follows all the standards KDE needs it to follow.
Multiple incompatible versions of shared libraries is why shared libraries have version numbers. I've got 2 variations of libc4, 5 variations of libc5 and 2 variations of libc6 on my system right now, all in /usr/lib with no problems.
As for keeping packages seperate and building a big symlink farm, I merely let the package manager keep track of which files belong to which packages. That's what it's for, after all. One version of a package is the primary installed version, and if I need other versions I install them elsewhere. Most often that's under my home directory for a new version of a package. Occasionally I get into a situation where I need to have multiple versions system-wide, but that only amounts to about 7 packages out of the 200+ I have installed and I can manage 7 package-specific directories easier than I can the /opt tree and related symlink farm for 200+ packages.
#1, that's not a kernel issue. #2, yeah, right, replace a few big directories with a few hundred small ones and require 8k PATHs, smooth move Clyde. For what you want done with /usr, see /bin, /lib etc.. I've dealt with /opt and IMHO is a major headache without providing any advantage over a good package manager (flames about RedHat vs. Debian to /dev/null).
Why shouldn't you read the threads? It's not like this isn't a public forum, after all. And it's somewhat reassuring to see that at least some of the reporters do read forums like Slashdot and see what the response to their articles is.
Personally, I don't much like broad limits on liability. If a company blew it, they should be responsible for the results. I'd prefer:
The exception only covers modules that don't require kernel modifications. So it doesn't matter that they're claiming that the two are seperate products--the modules dependancy on the patches means it has to be GPL'ed.
I don't see this. You might have a point, if the kernel mods depended on the module ( ie. you can't run the modified kernel without the non-GPL module ). Their mods, from what I can tell, leave the kernel usable without their module and could in fact be used by modules other than theirs if someone wanted. When they released the GPL'd patches they essentially created a new published kernel interface subject to the GPL, and they can release a non-GPL module that uses that interface.
Frankly I'd rather not require all kernel modules to be GPL'd. It's just not in our interest. I'd like everything to be GPL'd, but given the choice between having the functionality non-GPL'd and not having the functionality, I'd rather have it.
From what I can see, they provide two things: the binary-only module, and the GPL'd modifications to the kernel sources needed to use the module. As long as they keep any mods to the kernel sources themselves GPL'd and in source form, the module itself should fall under the module exception. What would violate the license would be distributing a modified, binary-only kernel, and they aren't doing that.
This doesn't sound like a decision on long-distance from a user's point of view. It sounds like the old argument about under what circumstances, when a caller on Telco A's network places a call to someone served by Telco B, B owes A for routing the call to them. Also, according to the ruling, the existing agreements on reciprocal compensation still apply and the state PUC still has the final say in the matter. Sounds like a lot of uproar over very little.
Forget the current trial and the other antitrust lawsuits, this will sink MS for good.
Depends. You needed to recompile to use the ELF format, but a.out binaries would still run ( and still run today ) just fine if you included a.out support. This also applies to things like libc upgrades: when I upgraded to libc6 all my libc5-linked apps continued to run just fine, albeit using the libc5 libraries.
The userland tools that need recompiled are the ones that talk intimately to the kernel. Things like procps or sound drivers need rebuilt. Things like StarOffice should continue to work just fine, blissfully unaware of the kernel upgrade.
Linux, I think, has a much better record for letting older apps continue to run without breaking than Windows. Heck, just installing an NT service pack or a new version of their compiler can break things in the Windows world. They really need versioned DLLs.
If he has evidence, he has to tell you about it. If he doesn't, he probably will shortly. That's one of the chances you take in discovery, and it does work both ways.
The characterization is misleading, yes. But, Be hasn't been involved heavily in this case ( as compared to, say, Netscape ). Boies is relying on their statements about what Compaq said to them, and I don't think Be would stick their nose in like this if they couldn't back that up, not considering the risk of annoying the judge by making claims in court you can't produce evidence to back up. So far, Boies has a pretty good track record of producing the evidence ( and MS is not happy about that at all ).
As for trusting or not trusting the validity, both MS and the DoJ have overt reasons to spin anything they present in their favor. MS, moreover, has already shown that they're willing to, under oath before a judge, misrepresent and edit evidence. If they've done that under those circumstances, I simply can't trust them not to do it again.
I think the point was to provide evidence that MS has enough power and influence that a company like Compaq would feel that, if violating a non-disclosure agreement with another company would annoy MS and endanger their relationship with them, then keeping MS happy is worth the legal consequences of violating an NDA. That goes to the question of whether MS has enough power to be considered a monopoly ( albeit a bit obliquely ).
OTOH, it would be more impressive if DoJ could come up with more than a single such instance. A single instance is easily just an accident or oversight, multiple instances make a much better case.
As far as primary source material, I don't consider anything from either MS or DoJ a primary source, no matter what they claim. A copy of the transcript from some source not affiliated with any of the parties involved, that would be a good primary source.
It might be argued that Mr. Boies should have turned over a copy of his evidence before Mr. Rose took the stand, but playing games with the discovery process is nothing new.
Depends. During discovery you're obliged to turn over things your opponent asks for or about, but you're not obliged to volunteer information he hasn't asked for. If MS didn't ask if Boies had evidence Compaq had leaked confidential information to them, AFAIK Boies is entirely within his rights not to volunteer the information. Yes, Boies ambushed Compaq and MS with this. Part of his job is to pull suprises like this if they let him set them up.
The embarrassing part is that MS's attorneys keep letting these things happen. MS has done more for the government's case than any of the government's witnesses. That's sad.
As long as they don't interfere with fair-use copying, having the copyright information watermarked in and using it to prevent illegal copying sounds good. If they try to use it to prevent legal fair-use copying, that's another story.
I wonder what the result would be if, if they try to restrict legal copying, people just started denying the right to use their material to any entity that tried to restrict fair use of it's material.
I think that your point #3 is pretty accurate. Personally I use Linux at home, but I'd hate to see FreeBSD go away.
Point #2 makes a big assumption: that no programmer is interested in user interfaces. I think that's a bad assumption. I've no data to back it up, but it seems to me that the existence of things like KDE and GNOME indicate that there are programmers who like making things look as good as they work. And I think you underestimate the consequences of OSS programmers just plain getting ticked off and saying "I can do a better-looking job that that!".
Point #4 makes the assumption that the number of programmers capable of understanding the code is constant. I think that's wrong, and that as more and more complex code is available and people get more used to looking at code we'll see more and more people who understand it. I do know that, over the years, I've gone from being able to handle a few thousand lines of code at a time to a few hundred thousand lines. I can't be unique in that progression.
IMHO making them reveal their source code, while it would be suitably humiliating for them, isn't the best punishment. More appropriate would be to force their application divisions to use nothing in the OS that wasn't equally available to any other company, and to go through the same support lines as everyone else to get questions answered and bugs fixed. They could integrate their browser, for instance, but only if they had an interface that would let Netscape integrate Navigator in the same way and to the same degree. This'd level the playing field without giving MS an excuse to complain that lawyers are dictating OS design, and you can check compliance by checking the source code against the published interfaces without having to resort to opinion.
Brin's statements remind me of a book by David Drake, Lacey and his Friends. Cameras recorded literally every second of your life, everywhere. Not even the police were exempt. The only protection was that there was so much being recorded that random or casual searches had become impossible. Even with those limitations, Lacey was an unsettling example of what an unscrupulous person could do in that system. Adding modern computers and their ability to search vast quantities of data quickly to that gives me a very bad feeling.
No, I'm afraid I don't agree with Mr. Brin on this subject.
According to the report from the Seattle Times, the Win98 system was using a 56k modem while the Win3.1 system had a 33.6k one. The Win98 system could be 25% slower than the Win3.1 system and still appear faster.
http://www.seat tletimes.com/news/technology/html98/micr_021099.hHave the PTO put up a Web site. The examiners abstract the application and post the summary and complete application. The public gets 6 months to submit ( via Web form or e-mail ) examples of prior art, objections and such. The examiners then review the comments and see if anyone has valid prior art or other reasons not to grant the patent. If they don't have time to research each application, let interested parties do the research for them.
They'll still have to weed out flames and garbage, but that's got to be faster to do than researching the subject.
That happens even with wills drawn up by attorneys. All it takes is for the contesting party to have a better ( more expensive ) lawyer than you did. If you have any sense you have your will pre-probated and deal with any problems found before you kick off. That deals with all problems, regardless of who wrote the will.