try here on the first page the majority are about the risks of patents not actual patent litigation.
Perhaps I'm dense, but I don't see any patent cases there that are protecting the Lone Inventor. The question remains: Are there any examples of patents actually helping the smart people protect their ideas from IP clone factories?
We don't need everyone in the world to adopt SPF, we only need enough to convince these few people to switch from forging legitimate domain names to using their own. Once that happens, the vast majority of bogus bounces will be eliminated.
Except for the fact that "forwarded" email will have to be placed in a new envelope in the SPF world, so bounces will only go back to the last SMTP server that it touched. If you "forward" your mail, you'll never get a legimitate bounce back, with out a major overhaul of mail servers (eg, the MTA will have to open up each mail message). SPF is broken, and doesn't really solve the SPAM problem at all. It only allows big organization (like Microsoft) to blacklist the little guys because they might send spam... Meanwhile, the spammers will just buy $8 throw-away "legitimiate" domains.
And Gentoo is the solution. OSX is shipped with a very stripped-down UNIX program suite. Fink addresses the problem nicely, and Gentoo looks like it's aiming at the same problem. I don't think the author meant that Gentoo on OSX *is* the problem.
Except for the fact that Titan's atmosphere will be destroyed by the sun when it becomes a red giant. Titan doesn't have enough mass to sustain an Earth-like atmosphere at Earth-like temperatures; the only reason it has one now is becuase of the extremely low temperatures keep the kinetic engery under control.
Try managing 20 ipsec connections with KAME/racoon sometime. You almost always have to kill all the tunnels when a change is made to one tunnel. With Openswan, you can simply do 'ipsec auto --down/--up connectionname' after the connection has been defined. Racoon log messages themselves are cryptic; when no policy can be found, it simply logs (when logging works) a message to that effect: "no policy found"; Openswan will give you all the details of the attempted policy, without having to restart it in "debug mode"; or "running Racoon in foreground -F mode".
Racoon seems to have problems logging normal information to syslog -- sometimes its messages just dissapear mysteriously (I've seen this on RHEL3 and FC2).
KAME also has problems with netfilter; specifically it doesn't work with all NAT rules, which are VERY common on ipsec gateways. It also doesn't work at the interface level, so many of the advanced routing tools don't work like you'd expect (try using tc with it, on an inteface level...).
I don't know why 2.6 and the Linux ipsec-tools project standardized on KAME. It may be from BSD, but we already have better userland tools, and they already (mostly) work with the new 2.6 ipsec intefaces. Hopefully these tools will get better with time, but right now pluto/openswan are simply more mature, stable and just plain better.
Poor JMF; it's all but abandonded by Sun -- and the reference implementation pretty much only works on Windows for anything other than simple audio. IBM seems to be doing more development on JMF than Sun does anymore. The JMF forums are full of questions with very few answers. This would be an excellent library to open source.
The Journal of Discourses wasn't some personal diary of Brigham Young. Several mormon prophets wrote doctrine in it, among the gems:
Non-whites were "less valiant" in the pre-existence, and so their curse is to live in ignorance and slavery in this life (also taught in the Book of Mormon and D&C)
It's better that a man kill his adultrous wife to save her by "blood atonement" than to let her die with her sins
Adam was god the father
Homosexuality and adultry are sins only surpassed by murder
The Catholic church is the whore of all the world and the church of Satan (also taught in Book of Momon somewhat)
Man cannot get into the highest degree of heaven (the "celestial" kingdom) without having multiple wives
Women can't get into the same place without the permission (and proper handshakes "through the veil") without her husband
To call OS X a Mach system is a bit disengenious. All I/O operations are handled by the "BSD Subsystem" for performance reasons. This means that all file and network I/O (along with the file security descriptions) are in a "monolithic subsystem" of the uK. Needles to say, this is the most performance-intense section of a UNIX (any?) system. A lot of the message-passing is therefore avoided; and the performance costs that those message passes would incur. Take a look at this url: OS X System Overview See that dotted-line that stretches from the kernel to userland? Tannenbaum would not approve.
Of course, Slashdot had to put a space in the URL; here's an actual link: Hand of God Shot. This was old-hat by 1998 as well; people had been running translucent windows for years prior to then.
We just had bids in from a few Fortune500 computer makers; HP's support of Linux is what pushed is in their direction. We couldn't use the ICH5 sensors with our deployed system and an HP engineer actually wrote C code to fix it for us. We could have done it ourselves eventually, but knowing that our vendors know Linux that well made us happy. It made them happy too because now we're going to deploy 15,000+ HP boxes running it.
But GTK, QT, wxWindows and VCL (openoffice) are all abstractions too. While Win32 isn't going to be an exact fit for the X environment, most of the time it's not going to make a significant difference to performance.
You're forgetting all the services that accompany Win32. Wine has to have several servers running in the background to pretend that Windows is running underneath. Wordperfect 2000 for Linux had to have its own font server (fontastik, remember that pile...) for similar reasons. It may be easy to port the win32 GDK to Linux (comparable to wxWindows or GTK+), but that hardly gets Windows applications running complete with COM registration, OLE, DDE, the Registry, DirectX/Sound services, etc. etc. etc.
It used the old XFree86 license, which has historically been lumped in the BSD-ish license category. You could re-distribute the code as long as you kept source attribution and the license in place.
From what I can tell, this is still vulnerable to a replay attack. The examples shown would also be relatively easy to brute-force.
Yes, without a challenge-response or one-time secret, this will always be the case (barring wierd quantum physics or somesuch). I don't think it would be that easy to brute-force; there are 65k ports, and you have to have a correct permutation of seven ports. The odds of randomly doing that on the first attempt are 1 in 5.191e+33; assuming you could perform 1000 tests per second.... it would take 1.646e+23 years to exhaust all possible combinations; about half that long to have a good shot at guessing it.
Good luck.
My question is how much better is it than simply moving your services to non-standard ports?
I'd say that it's significantly better, as long as you have nobody in the middle. If you have a black hat in the middle, then it's no good at all. Fortunately, in today's switched world, it's generally Hard to get in the middle, or at least Very Inconvenient.
Gentoo has many problems. I run it on my desktop, but I would never consider it for our production systems for various reasons:
There is no way to re-install a secure Gentoo system in a specific configuration; you either move right on up to Bleeding Edge, or keep unsecure software
Recovery takes forever, unless all your logic and data are replicated, you could be down for hours while you re-compile a secure version of glibc
Portage breaks. Not often, but often enough (remember the gcc problem that destroyed systems last summer?) to write it off as enterprise worthy.
It's difficult to re-build entire trees of software if you want to change USE flags; what's already on your system is already there, and unless you force a lengthy rebuild, then you're stuck with the USE flags that were present when a particular package was emerged.
If you install 10 Gentoo systems, the odds are good that the tenth system is not exaclty the same as the first one; if your production database has problems with something like this, then you can spend hours chasing it down (and trying to revert to a package that isn't in portage anymore)
The configuration file updates are horrible. The hell of letting/etc build up with "new" versions, and having to sift through them or trust diffs. Of course, you can always ignore them and Hope For The Best...
There are other problems that are more minor, but every distribution has its minor problems. Gentoo is fine for bleeding-edge hobbiests, or for production systems which have a lot of replication (clusters, for example).
We were debating the Progeny support system ourselves. We're going to stick with Freshrpm for a while to see if that fills the need (we can even contribute RPMs back in. We looked at SuSE, but it seemed to have the same problems that Redhat has.
Well, we have spent a lot of effort in debunking the supposed SCO claim's of ownership of those header files; but what if that's just a red herring? What if they are not claiming ownership of them, as Linus presumed in his rebuttal, but rather, know that there is some kernel code behind those interfaces that was copied from SCO code? The relevent portions of the SCO claims are as follows:
You are not running Linux binary code that was compiled from any version of Linux that contains our copyrighted application binary interface code ("ABI Code") specifically identified in the attached notification letter.
See? They're not explicitly claiming ownership of the data in those header files, but rather they are claiming that applications which use them are violating their copyright restrictions. Could this be a duck that is not in line? Could there be code behind some API call in those header files that SCO can prove clear ownership of?
First of all, would you do a search on some meta-information to discover new releases? A third party couldn't flood the network with useless such meta-information?
Secondly, Gnutella doesn't scale very well, and relies heavily on people cooperating with one another. A spoiler can poison the directory quite easily.
Well, since I just came up with a solution in 30 seconds, it's not all that hard.
I don't think it would work all that well, actually. Would you have some process that is constantly running Gnutella, and constantly querying for new releases, constantly downloading them and constantly checking signatures to throw out the old stuff. Oh, and you have to constantly search for the revokation message, and contatnly check that signature as well. Due to the anonynimity of Gnuetella, it'd be trivial for some black-hat to post garbage to the network (although I would assume that once a node downloads the Real Thing, it would re-share it, making it more popular than the garbage), which everyone would try to download because they're just searching on meta-information that everyone already knows.
Kind of like how the RIAA has spammed with filenames in the past? You can't check the signature until you've downloaded the entire file (unless some initial meta-information is signed, with a hash of the data; which is a good idea). I like the P2P signatures, but the initial user must be able to get them securely, and on a P2P network it would be easy to get the Evil key the first time you use it. I think DNS may be a good way to solve that problem; it's hard to DDoS and if you kill your own DNS servers, well...
I think using DNS would be a good trade-off. Publish the public key and the seed site (in the case of bittorrent) in DNS. Make the end users accept and sign the public key, so that they know when it changes (and can investigate). The seed site should be as random a location as possible; the same ISP should never host the seed site more than once a year.
There are still flaws in this system; and I'm not saying "it cant[sic] be done!" -- I'm just saying that it isn't easy.
Slashdot Mirror
try here on the first page the majority are about the risks of patents not actual patent litigation.
Perhaps I'm dense, but I don't see any patent cases there that are protecting the Lone Inventor. The question remains: Are there any examples of patents actually helping the smart people protect their ideas from IP clone factories?Except for the fact that "forwarded" email will have to be placed in a new envelope in the SPF world, so bounces will only go back to the last SMTP server that it touched. If you "forward" your mail, you'll never get a legimitate bounce back, with out a major overhaul of mail servers (eg, the MTA will have to open up each mail message). SPF is broken, and doesn't really solve the SPAM problem at all. It only allows big organization (like Microsoft) to blacklist the little guys because they might send spam... Meanwhile, the spammers will just buy $8 throw-away "legitimiate" domains.
And Gentoo is the solution. OSX is shipped with a very stripped-down UNIX program suite. Fink addresses the problem nicely, and Gentoo looks like it's aiming at the same problem. I don't think the author meant that Gentoo on OSX *is* the problem.
Except for the fact that Titan's atmosphere will be destroyed by the sun when it becomes a red giant. Titan doesn't have enough mass to sustain an Earth-like atmosphere at Earth-like temperatures; the only reason it has one now is becuase of the extremely low temperatures keep the kinetic engery under control.
KAME also has problems with netfilter; specifically it doesn't work with all NAT rules, which are VERY common on ipsec gateways. It also doesn't work at the interface level, so many of the advanced routing tools don't work like you'd expect (try using tc with it, on an inteface level...).
I don't know why 2.6 and the Linux ipsec-tools project standardized on KAME. It may be from BSD, but we already have better userland tools, and they already (mostly) work with the new 2.6 ipsec intefaces. Hopefully these tools will get better with time, but right now pluto/openswan are simply more mature, stable and just plain better.
The technology is great an all, but you really need to have the music to understand Formula One; but only if you have at least 5.1 DTS on your tele.
Poor JMF; it's all but abandonded by Sun -- and the reference implementation pretty much only works on Windows for anything other than simple audio. IBM seems to be doing more development on JMF than Sun does anymore. The JMF forums are full of questions with very few answers. This would be an excellent library to open source.
- Non-whites were "less valiant" in the pre-existence, and so their curse is to live in ignorance and slavery in this life (also taught in the Book of Mormon and D&C)
- It's better that a man kill his adultrous wife to save her by "blood atonement" than to let her die with her sins
- Adam was god the father
- Homosexuality and adultry are sins only surpassed by murder
- The Catholic church is the whore of all the world and the church of Satan (also taught in Book of Momon somewhat)
- Man cannot get into the highest degree of heaven (the "celestial" kingdom) without having multiple wives
- Women can't get into the same place without the permission (and proper handshakes "through the veil") without her husband
Go look for yourself if you don't believe me.Apple should probably ask if you want to install the "BSD Userland" tools or something.
To call OS X a Mach system is a bit disengenious. All I/O operations are handled by the "BSD Subsystem" for performance reasons. This means that all file and network I/O (along with the file security descriptions) are in a "monolithic subsystem" of the uK. Needles to say, this is the most performance-intense section of a UNIX (any?) system. A lot of the message-passing is therefore avoided; and the performance costs that those message passes would incur. Take a look at this url: OS X System Overview See that dotted-line that stretches from the kernel to userland? Tannenbaum would not approve.
Of course, Slashdot had to put a space in the URL; here's an actual link: Hand of God Shot. This was old-hat by 1998 as well; people had been running translucent windows for years prior to then.
Here's a screen shot I have from 1998: http://inconnu.isu.edu/~ink/new/linux/handogod_med .jpg
We just had bids in from a few Fortune500 computer makers; HP's support of Linux is what pushed is in their direction. We couldn't use the ICH5 sensors with our deployed system and an HP engineer actually wrote C code to fix it for us. We could have done it ourselves eventually, but knowing that our vendors know Linux that well made us happy. It made them happy too because now we're going to deploy 15,000+ HP boxes running it.
You're forgetting all the services that accompany Win32. Wine has to have several servers running in the background to pretend that Windows is running underneath. Wordperfect 2000 for Linux had to have its own font server (fontastik, remember that pile...) for similar reasons. It may be easy to port the win32 GDK to Linux (comparable to wxWindows or GTK+), but that hardly gets Windows applications running complete with COM registration, OLE, DDE, the Registry, DirectX/Sound services, etc. etc. etc.
Too bad we have to pick between a moron and a charlatan.
It used the old XFree86 license, which has historically been lumped in the BSD-ish license category. You could re-distribute the code as long as you kept source attribution and the license in place.
Yes, without a challenge-response or one-time secret, this will always be the case (barring wierd quantum physics or somesuch). I don't think it would be that easy to brute-force; there are 65k ports, and you have to have a correct permutation of seven ports. The odds of randomly doing that on the first attempt are 1 in 5.191e+33; assuming you could perform 1000 tests per second.... it would take 1.646e+23 years to exhaust all possible combinations; about half that long to have a good shot at guessing it.
Good luck.
My question is how much better is it than simply moving your services to non-standard ports?
I'd say that it's significantly better, as long as you have nobody in the middle. If you have a black hat in the middle, then it's no good at all. Fortunately, in today's switched world, it's generally Hard to get in the middle, or at least Very Inconvenient.
- There is no way to re-install a secure Gentoo system in a specific configuration; you either move right on up to Bleeding Edge, or keep unsecure software
- Recovery takes forever, unless all your logic and data are replicated, you could be down for hours while you re-compile a secure version of glibc
- Portage breaks. Not often, but often enough (remember the gcc problem that destroyed systems last summer?) to write it off as enterprise worthy.
- It's difficult to re-build entire trees of software if you want to change USE flags; what's already on your system is already there, and unless you force a lengthy rebuild, then you're stuck with the USE flags that were present when a particular package was emerged.
- If you install 10 Gentoo systems, the odds are good that the tenth system is not exaclty the same as the first one; if your production database has problems with something like this, then you can spend hours chasing it down (and trying to revert to a package that isn't in portage anymore)
- The configuration file updates are horrible. The hell of letting
/etc build up with "new" versions, and having to sift through them or trust diffs. Of course, you can always ignore them and Hope For The Best...
There are other problems that are more minor, but every distribution has its minor problems. Gentoo is fine for bleeding-edge hobbiests, or for production systems which have a lot of replication (clusters, for example).We were debating the Progeny support system ourselves. We're going to stick with Freshrpm for a while to see if that fills the need (we can even contribute RPMs back in. We looked at SuSE, but it seemed to have the same problems that Redhat has.
I agree; but their claim is so insipid that I keep seeing shadows.
First of all, would you do a search on some meta-information to discover new releases? A third party couldn't flood the network with useless such meta-information?
Secondly, Gnutella doesn't scale very well, and relies heavily on people cooperating with one another. A spoiler can poison the directory quite easily.
Well, since I just came up with a solution in 30 seconds, it's not all that hard.
I don't think it would work all that well, actually. Would you have some process that is constantly running Gnutella, and constantly querying for new releases, constantly downloading them and constantly checking signatures to throw out the old stuff. Oh, and you have to constantly search for the revokation message, and contatnly check that signature as well. Due to the anonynimity of Gnuetella, it'd be trivial for some black-hat to post garbage to the network (although I would assume that once a node downloads the Real Thing, it would re-share it, making it more popular than the garbage), which everyone would try to download because they're just searching on meta-information that everyone already knows.
Kind of like how the RIAA has spammed with filenames in the past? You can't check the signature until you've downloaded the entire file (unless some initial meta-information is signed, with a hash of the data; which is a good idea). I like the P2P signatures, but the initial user must be able to get them securely, and on a P2P network it would be easy to get the Evil key the first time you use it. I think DNS may be a good way to solve that problem; it's hard to DDoS and if you kill your own DNS servers, well...
I think using DNS would be a good trade-off. Publish the public key and the seed site (in the case of bittorrent) in DNS. Make the end users accept and sign the public key, so that they know when it changes (and can investigate). The seed site should be as random a location as possible; the same ISP should never host the seed site more than once a year.
There are still flaws in this system; and I'm not saying "it cant[sic] be done!" -- I'm just saying that it isn't easy.
How do people find out when a new release is made? Can that source be DDoS'd?
Where do people download the new source from? Is there some sort of directory system that is vulnerable?