No, it makes complete sense. Copyrights control distribution, not use. If the use of a piece of code is to output some content, push something on screen, or whatever else, then anything can drive it -- open source, closed source, or whatever. It's only when you distribute code that insinuates itself at the source level that you need to share the code you added.
No, it does not make complete sense. It does if you are a freenode-using, FSF-supporting GPL Zealot, but under any other condition it does not make since (i.e. the real world.).
The Linux exception comes from the fact that you directly link chunks of Linux into your own modules when you create kernel modules. You are correct that it's ludicrous to consider the generic kernel syscall interface living under the same exemption.
You don't link syscalls. Syscalls are re-enterant entrypoints into kernel namespace, and their shims (AND _syscall()) are provided by glibc, NOT the kernel.
In the kernel, you call routines directly, not through syscall, unless they are inter-modular, in which case you use syscalls (but not the libc _syscall()), but only under those conditions.
1) All the MSFT vulnerabilities were reported, if not fixed, by 3rd party researchers. Not sure how much of this is true in the case of the OpenBSD errata you linked to, but I would hazard a guess the the OpenBSD team found most of the vulnerabilities themselves (rigorous code auditing and all).
Incorrect, most OpenBSD vulnerabilities are found in other operating systems and reported to OpenBSD by CERT.
2) The source code for the patch is linked right next to the vulnerability description! What more could you want? I don't think there could be a more specific "description" of the vulnerability. You've got the freely available original source code and the patch. Pretty exact, if you ask me.
The latest patch against tcp(4) is vague and non-specific.
While I am fully capable of reading a patch, most people are not, and thus a detailed explanation of what the patch provides must be provided. It is imperative. Also, look at the latest patch against TCP... there is no explanation as into why that was necessary, and the patch provides no explanation even in the source, it just changes some timestamping logic around and does not say why.
As an OpenBSD user, I'd much prefer that they disclose more information about their patches before they release them.
Erm. No. You obviously have no idea how the root server system works. Not all of the servers are maintained by ICANN (only one, which is rarely used, most resolvers just use the verisign cluster), therefore ICANN has no actual say, just influence.
A majority of the root servers are maintained by VeriSign and the government. The others are maintained by various ISP's and Universities, with only one maintained by ICANN, which could easily be removed without any problem -- the network is overly redundant.
You are right though, it would only take a few phone calls to launch a new TLD, but calling ISP's would be the stupid way of doing it, especially when the root servers themselves would take less effort and provide more overall value.
No, ICANN doesn't matter. These people do, however.
There is no purpose to these TLDs. It's all bureaucratic crap. The fact of the matter is that it is the root server admin group (primarily VeriSign, that's why they got away with sitefinder for weeks while ICANN continued to complain) that actually has the power to create and maintain TLDs. Which is why nobody really cares about anything ICANN has to say, especially when everything they say tends to be ridiculously stupid.
The problem is that nobody seems to care about what ICANN has to say. Which is a shame. But I mean really, ICANN isn't going to be able to fight a corporation so they should probably quit with these little nitpicking events they have, as they always wind up to be a waste of bandwidth and nothing more.
That's irrelevant. The fact that the individuals violated Oklahoma's anti spam law, means that they are liable for that, and that case would still be litigated in Oklahoma.
This lawsuit is more intended to make the owners of cruise.com appear to be victimized, that's all there is to it. It's a fairly common move in litigation of this nature, and it rarely works out in the spammer's favour. Usually these things get dismissed from court.
In an effort, by Jean-Francois Brousseau (jfb@openbsd.org), to rid the OpenBSD CVS tree of GPL'ed licensed code, OpenCVS is now officially part of the OpenBSD project. For more details, see the OpenCVS homepage; http://www.openbsd.org/opencvs/
Umm. No. That's not what it's about at all. Lets correct the mistakes now, shall we?
1) There was no OpenCVS until the OpenBSD project noticed some major security vulnerabilities posted tobugtraq in GNU CVS.
2) The reason why OpenCVS was written was to provide a more secure client/server package than what the [now stagnant] GNU CVS project is currently providing. It has nothing to do with GPL vs BSD, infact the OpenBSD project is all about what RMS calls "free software".
So basically the Slashdot editors posted a troll to the front page. Beautiful.:)
Re:look at the blackboard in the background
on
SCO.com Defaced
·
· Score: 2, Informative
08:37 -!- Channel Users Name 08:37 -!- #sco 1 08:37 -!- End of/LIST
FreeBSD's port is also amd64.
Same with NetBSD and OpenBSD. This is nothing new. There are other reasons why Debian is using amd64 as well. Two of their target platforms (NetBSD and FreeBSD, see here) use amd64 internally, as listed above.
Umm, the BSD licensing clause ONLY applies to documentation. The actual requirement to display a copyright notice upon execution, was removed in the later version of the license.
Hardware Hacking whitepapers
Best deals: Hardware Hacking
More Hardware Hacking stories
Emulation (Games) whitepapers
Best deals: Emulation (Games)
More Emulation (Games) stories
OS X whitepapers
Best deals: OS X
More OS X stories
XBox (Games) whitepapers
Best deals: XBox (Games)
More XBox (Games) stories
Being based on Opteron, any x86 software will run on it. Maybe without all the bells and whistles though. But Openmosix can solve most of those problems.
Destroy the evil microsoft-controlled email! Let's get the campaign rolling now!
Anyway.. it appears to me that Microsoft could not technically require people to get licensing for their servers as this behaviour would destroy a major subsystem of the internet.
Example 1 is a fucking COMMENT. Who the hell cares? And what's with Example 2? Where's the SYSV code that got ripped? SIDE BY SIDE YOU IDIOT SCO PEOPLE!!!
Slashdot Mirror
Actually, it isn't theora. It's XViD with ogg bitstream encapsulation. Cleanroom reverse engineering practices can be quite useful.
:)
Also, you can choose either vorbis or MP3 for the audio track. (Same thing, encapsulation.)
So, in reality, it's a bloated piece of crap.
No, it makes complete sense. Copyrights control distribution, not use. If the use of a piece of code is to output some content, push something on screen, or whatever else, then anything can drive it -- open source, closed source, or whatever. It's only when you distribute code that insinuates itself at the source level that you need to share the code you added.
No, it does not make complete sense. It does if you are a freenode-using, FSF-supporting GPL Zealot, but under any other condition it does not make since (i.e. the real world.).
The Linux exception comes from the fact that you directly link chunks of Linux into your own modules when you create kernel modules. You are correct that it's ludicrous to consider the generic kernel syscall interface living under the same exemption.
You don't link syscalls. Syscalls are re-enterant entrypoints into kernel namespace, and their shims (AND _syscall()) are provided by glibc, NOT the kernel.
In the kernel, you call routines directly, not through syscall, unless they are inter-modular, in which case you use syscalls (but not the libc _syscall()), but only under those conditions.
1) All the MSFT vulnerabilities were reported, if not fixed, by 3rd party researchers. Not sure how much of this is true in the case of the OpenBSD errata you linked to, but I would hazard a guess the the OpenBSD team found most of the vulnerabilities themselves (rigorous code auditing and all).
Incorrect, most OpenBSD vulnerabilities are found in other operating systems and reported to OpenBSD by CERT.
2) The source code for the patch is linked right next to the vulnerability description! What more could you want? I don't think there could be a more specific "description" of the vulnerability. You've got the freely available original source code and the patch. Pretty exact, if you ask me.
The latest patch against tcp(4) is vague and non-specific.
While I am fully capable of reading a patch, most people are not, and thus a detailed explanation of what the patch provides must be provided. It is imperative. Also, look at the latest patch against TCP... there is no explanation as into why that was necessary, and the patch provides no explanation even in the source, it just changes some timestamping logic around and does not say why.
As an OpenBSD user, I'd much prefer that they disclose more information about their patches before they release them.
Erm. No. You obviously have no idea how the root server system works. Not all of the servers are maintained by ICANN (only one, which is rarely used, most resolvers just use the verisign cluster), therefore ICANN has no actual say, just influence.
A majority of the root servers are maintained by VeriSign and the government. The others are maintained by various ISP's and Universities, with only one maintained by ICANN, which could easily be removed without any problem -- the network is overly redundant.
You are right though, it would only take a few phone calls to launch a new TLD, but calling ISP's would be the stupid way of doing it, especially when the root servers themselves would take less effort and provide more overall value.
No, ICANN doesn't matter. These people do, however.
And yet they are less vague than the ones which have recently come out of OpenBSD. That's scary.
The .XXX TLD is probably the most useful one out of those listed.
There is no purpose to these TLDs. It's all bureaucratic crap. The fact of the matter is that it is the root server admin group (primarily VeriSign, that's why they got away with sitefinder for weeks while ICANN continued to complain) that actually has the power to create and maintain TLDs. Which is why nobody really cares about anything ICANN has to say, especially when everything they say tends to be ridiculously stupid.
The problem is that nobody seems to care about what ICANN has to say. Which is a shame. But I mean really, ICANN isn't going to be able to fight a corporation so they should probably quit with these little nitpicking events they have, as they always wind up to be a waste of bandwidth and nothing more.
Come on now, it's a repackaged version with pretty graphics!
That's irrelevant. The fact that the individuals violated Oklahoma's anti spam law, means that they are liable for that, and that case would still be litigated in Oklahoma.
This lawsuit is more intended to make the owners of cruise.com appear to be victimized, that's all there is to it. It's a fairly common move in litigation of this nature, and it rarely works out in the spammer's favour. Usually these things get dismissed from court.
Probably from the mysterious future.
Umm. No. That's not what it's about at all. Lets correct the mistakes now, shall we?
1) There was no OpenCVS until the OpenBSD project noticed some major security vulnerabilities posted to bugtraq in GNU CVS.
2) The reason why OpenCVS was written was to provide a more secure client/server package than what the [now stagnant] GNU CVS project is currently providing. It has nothing to do with GPL vs BSD, infact the OpenBSD project is all about what RMS calls "free software".
So basically the Slashdot editors posted a troll to the front page. Beautiful.
08:37 -!- Channel Users Name /LIST
08:37 -!- #sco 1
08:37 -!- End of
He's the only one in there, and it's +k.
FreeBSD's port is also amd64. Same with NetBSD and OpenBSD. This is nothing new. There are other reasons why Debian is using amd64 as well. Two of their target platforms (NetBSD and FreeBSD, see here) use amd64 internally, as listed above.
Umm, the BSD licensing clause ONLY applies to documentation. The actual requirement to display a copyright notice upon execution, was removed in the later version of the license.
It's already been done, all they need is the Aqua part done: www.opendarwin.org
Hardware Hacking whitepapers
Best deals: Hardware Hacking
More Hardware Hacking stories
Emulation (Games) whitepapers
Best deals: Emulation (Games)
More Emulation (Games) stories
OS X whitepapers
Best deals: OS X
More OS X stories
XBox (Games) whitepapers
Best deals: XBox (Games)
More XBox (Games) stories
That doesn't look right.
Being based on Opteron, any x86 software will run on it. Maybe without all the bells and whistles though. But Openmosix can solve most of those problems.
By modifying the shellcode.
Destroy the evil microsoft-controlled email! Let's get the campaign rolling now!
Anyway.. it appears to me that Microsoft could not technically require people to get licensing for their servers as this behaviour would destroy a major subsystem of the internet.
That's just my $0.02.
Bill is now posting his life story on the internet for all to read?! So when is it going to come out that he knocked up some chick at SCO? :)
Example 1 is a fucking COMMENT. Who the hell cares? And what's with Example 2? Where's the SYSV code that got ripped? SIDE BY SIDE YOU IDIOT SCO PEOPLE!!!
Oh you mean... this?
Bonzi buddy will now be ashcroft's buddy.