Stallman's goal is that the market for software will eventually get to a point a lot like where the automotive market is today. Software without source code is like a car with the engine compartment welded shut. No one would buy a car like that because it is a basic expectation that anyone should be able to open up their car and work on their engine -- even if 99% of car owners never do and just let a mechanic take care of things, the expectation is still there.
No, it isn't. If that were his goal, it would be ok for him if software would be sold under a 'proprietary with source code' model (like all software in scripted languages is anyway), with explicit permission to modify the code. This would match your car example fairly well, I think (copyright law also forbids to copy the design of a car engine).
However, Stallman's wants much more - he wants that you are free to manufacture a copy of your Toyota and give it away, if you are so inclined (just to stick with the car example, though it gets unrealistic here). But since buying a car doesn't give you a license for manufacturing copies, you are not allowed to do that in the current automotive market either.
Read the manpage of 'xauth'. It even contains (wonder of all wonders - at least with manpages) an example, which should give you an idea how to write a simple script that will do what you want.
No, the Unix model doesn't get you there, either, although it could get you a lot closer if you could sudo your browser to another user in either X-11 or Aqua. (And, of course, then we'd have Microsoft forcing us to take them to court to show why their attempt to patent sudo is egregious.)
You can do that - no "if" and "could" required. If you have trouble authenticating to the X server when starting the browser under another UID, read the manpage for 'xauth'.
First, it's actually easier to detect smaller particles. Surface scales as radius squared, mass as radius to the third power, thus with smaller particles you get much more (absorbing or reflecting) surface per mass.
Second, the author's results depend on whether their particular model geometry for the binary system + disk is correct.
And third, in their Nature paper they argue that they most likely are biased towards the smallest grains that make up the circumbinary disk, and that the bulk of the disk may be in even larger grains ('pebbles'). For the same amount of occultation, that would require much more mass (see first point). I wonder whether that wouldn't result in an insane mass for the disk... they don't discuss this;-)
Aren't most free software developers going to want to work on free software?
While I am an OSS developer, I would rather work on an interesting non-free project than on a boring free project. And I suppose that most OSS developers are employed (like me), but still might consider an offer that looks interesting.
Except that its use has serious privacy implications (if you use reCaptcha, their server learns the IP adresses of your visitors, and could even track their surfing habits, if enough sites use reCaptcha). From that point of view, the implementation is seriously flawed, and using reCaptcha might even be illegal in some countries due to privacy laws.
Every other day bugs get detected in web applications, allowing an intruder to run arbitrary code under the webserver UID. This exploit means each of these bugs gives way to root privileges.
As a member of the Apple camp, I'll probably check out a copy just to laugh at all the problems the other side is having, but I do think this is a useful book for those stuck on the other side.
Remove Xcode 2.1. Try to install Xcode 3.0 (on Leopard). Oh, installer does not work because GraphKit.framework is missing now (ok, I cheated: as a mere mortal Apple user, the error message will read like egyptian hieroglyphes to you). No problemo, it's an Apple; just search the net for half an hour to find some solution involving Pacifist (shareware) and the Install DVD (shit, is at home, buried someplace).
Fortunately, it wasn't me who was affected by this, since I'm in the Linux camp;)
The way reCAPTCHA is implemented, they (the reCAPTCHA project) learn the IP addresses (hence identity) of your website visitors. Actually, if enough websites would use reCAPTCHA, they would be able to track people's browsing history. This is a major design flaw, and renders reCAPTCHA useless if you respect the privacy of your users. If it weren't for this, I certainly would use it.
If your server is hosted in a safe area but you (the owner/responcible operator) reside in the US. Can the FBI contact or require you to provide that info?
Don't have that info. Have a root server (virtual or otherwise). Check that the hosting company only logs the amount of traffic, not the IPs. Use mod_removeip for apache, and the syslog-ng anonymizer patch for everything else.
Application authors should sanitize not only user input, but also the data they get from the database. This would go a long way towards making the web server resistant against web application vulnerabilities: if you exploit a vulnerability, you get the UID of the webserver. This UID actually does not need to own anything, or have write permissions on anything, except log files and application databases. I.e. with proper file permissions, you could do not much more than writing to the database, circumventing the input sanitation performed by the application. But if the app sanitizes the data it gets from the database, you still loose.
Only in the UK. In most other countries, roundabouts eliminate left turns, rather than making them mandatory. Actually, roundabouts are becoming increasingly popular in Germany.
PDFs are neither slow nor crappy. Acrobat Reader is slow, but there are free and faster alternatives (e.g. xpdf). Also, PDFs make for excellent portable presentations (PPTs by default only work on the same machine were they were created, since different MS Powerpoint versions are sometimes less than compatible - PDF works always and everywhere). And with the 'prosper' LaTeX package it's very easy to create PDF presentations on Linux.
Most of the times printing problems are related to Acrobat Reader. Using xpdf solves this issue (for Windows, there are probably alternative PDF readers as well).
Did you ever notice that (a) about 100 per cent of playgrounds are rated for children aged 3+ only, and that (b) about 100 per cent of toys are rated for children aged 3+ only? It's all about CYA, and since your children need to play someplace and with something, of course you have to ignore this bullshit and buy your children what you think is appropriate.
The stupid thing is, since practically nothing is 'officially' rated suitable for children below kindergarten age, you have no guidance at all for buying toys (and you get into the habit of ignoring age ratings). Those few things that are rated for toddlers are usually incredibly boring, and will keep a toddler busy for about 5min maximum.
Your argument looks appealing. However, the problem is that most people don't have the time to evaluate the validity of each and every random statement they encounter. Thus, for economic reasons people tend to filter information based on the repudiation of the source. You may bemoan this on philosophical grounds, but it's actually a fairly sound way to deal with the problem at hand.
At least Ubuntu 7.04 (perhaps also 6.10, but not 6.06 LTS) is compiled with fstack-protector; Debian is not. However, both Debian and Ubuntu make it very hard, if not impossible, to find any information about proactive security features, contrary to e.g. Fedora, where you can fetch all the information from a single web page (http://fedoraproject.org/wiki/Security/Features). I'm only sure about fstack-protector in 7.04 because I've tested some exploits...
I can see a serious privacy problem with this, since it divulges the IP address of visitors to a third party (Carnegie Mellon). The API is fundamentally broken, since both the website visitor and the website need to contact the central server (rather than the website alone), which allows said third party to generate personalized profiles of web surfers.
Basically. Either you do it manually and manage conflicts at sync time, or you do it automatically and define one of the sides as a master in the case of conflict. There's really no way round this, software just isn't sophisticated enough to decide what you're thinking.
Sure there is another way: newest file wins. There are situations where this would be the most logical choice, but nevertheless I couldn't find software that would support this, thus had to write it by myself...
In theory, once rooted you cannot trust anything on the system. In practice, in about 99.9 per cent (or more) of all intrusions, the intruder will use some more or less imperfect off-the-shelf rootkit that only performs standard activities (hide itself, open a backdoor, do keylogging or similar). If it's old, signature-based detectors like Rootkit Hunter or chkrootkit will work. If it's new, signature-based detection will fail, but generic detection techniques (like the ones employed by samhain) have a good chance of catching it. You have a pretty slim chance of ever seeing the (theoretically possible) flawlessly programmed rootkit that hides itself perfectly by closing all possible ways of detecting it. As an example, there are plenty system calls that take a PID (or a path, i.e./proc/PID) as argument and can be used to infer the presence of a process. All kernel rootkits I've ever seen only care to "fix" about half a dozen of the most frequently used of these system calls.
He says that the only detectors he is aware of are chrootkit and Rootkit Hunter. As he correctly points out, these are signature based - they look e.g. for specific files in userspace (chrootkit also does a generic check for hidden processes). However, the samhain integrity checker also has two different modules to check for kernel-mode rootkits. First, it can check the kernel syscall table to detect syscall redirection within the kernel (on FreeBSD and Linux), and second, it can detect hidden processes (basically in the same way as chrootkit). Also, if checking file integrity, samhain compares the number of hardlinks of a directory with the number of subdirectories to detect hidden subdirectories.
No, it isn't. If that were his goal, it would be ok for him if software would be sold under a 'proprietary with source code' model (like all software in scripted languages is anyway), with explicit permission to modify the code. This would match your car example fairly well, I think (copyright law also forbids to copy the design of a car engine).
However, Stallman's wants much more - he wants that you are free to manufacture a copy of your Toyota and give it away, if you are so inclined (just to stick with the car example, though it gets unrealistic here). But since buying a car doesn't give you a license for manufacturing copies, you are not allowed to do that in the current automotive market either.
Read the manpage of 'xauth'. It even contains (wonder of all wonders - at least with manpages) an example, which should give you an idea how to write a simple script that will do what you want.
You can do that - no "if" and "could" required. If you have trouble authenticating to the X server when starting the browser under another UID, read the manpage for 'xauth'.
Second, the author's results depend on whether their particular model geometry for the binary system + disk is correct.
And third, in their Nature paper they argue that they most likely are biased towards the smallest grains that make up the circumbinary disk, and that the bulk of the disk may be in even larger grains ('pebbles'). For the same amount of occultation, that would require much more mass (see first point). I wonder whether that wouldn't result in an insane mass for the disk ... they don't discuss this ;-)
While I am an OSS developer, I would rather work on an interesting non-free project than on a boring free project. And I suppose that most OSS developers are employed (like me), but still might consider an offer that looks interesting.
Except that its use has serious privacy implications (if you use reCaptcha, their server learns the IP adresses of your visitors, and could even track their surfing habits, if enough sites use reCaptcha). From that point of view, the implementation is seriously flawed, and using reCaptcha might even be illegal in some countries due to privacy laws.
Every other day bugs get detected in web applications, allowing an intruder to run arbitrary code under the webserver UID. This exploit means each of these bugs gives way to root privileges.
Remove Xcode 2.1. Try to install Xcode 3.0 (on Leopard). Oh, installer does not work because GraphKit.framework is missing now (ok, I cheated: as a mere mortal Apple user, the error message will read like egyptian hieroglyphes to you). No problemo, it's an Apple; just search the net for half an hour to find some solution involving Pacifist (shareware) and the Install DVD (shit, is at home, buried someplace).
Fortunately, it wasn't me who was affected by this, since I'm in the Linux camp ;)
It's a US university. In other words, for all practical purposes it is a corporation (one whose main business is selling tuition).
The way reCAPTCHA is implemented, they (the reCAPTCHA project) learn the IP addresses (hence identity) of your website visitors. Actually, if enough websites would use reCAPTCHA, they would be able to track people's browsing history. This is a major design flaw, and renders reCAPTCHA useless if you respect the privacy of your users. If it weren't for this, I certainly would use it.
Don't have that info. Have a root server (virtual or otherwise). Check that the hosting company only logs the amount of traffic, not the IPs. Use mod_removeip for apache, and the syslog-ng anonymizer patch for everything else.
Application authors should sanitize not only user input, but also the data they get from the database. This would go a long way towards making the web server resistant against web application vulnerabilities: if you exploit a vulnerability, you get the UID of the webserver. This UID actually does not need to own anything, or have write permissions on anything, except log files and application databases. I.e. with proper file permissions, you could do not much more than writing to the database, circumventing the input sanitation performed by the application. But if the app sanitizes the data it gets from the database, you still loose.
Only in the UK. In most other countries, roundabouts eliminate left turns, rather than making them mandatory. Actually, roundabouts are becoming increasingly popular in Germany.
Do it in Second Life. Nobody will know you're a guy.
PDFs are neither slow nor crappy. Acrobat Reader is slow, but there are free and faster alternatives (e.g. xpdf). Also, PDFs make for excellent portable presentations (PPTs by default only work on the same machine were they were created, since different MS Powerpoint versions are sometimes less than compatible - PDF works always and everywhere). And with the 'prosper' LaTeX package it's very easy to create PDF presentations on Linux.
Most of the times printing problems are related to Acrobat Reader. Using xpdf solves this issue (for Windows, there are probably alternative PDF readers as well).
The stupid thing is, since practically nothing is 'officially' rated suitable for children below kindergarten age, you have no guidance at all for buying toys (and you get into the habit of ignoring age ratings). Those few things that are rated for toddlers are usually incredibly boring, and will keep a toddler busy for about 5min maximum.
Your argument looks appealing. However, the problem is that most people don't have the time to evaluate the validity of each and every random statement they encounter. Thus, for economic reasons people tend to filter information based on the repudiation of the source. You may bemoan this on philosophical grounds, but it's actually a fairly sound way to deal with the problem at hand.
At least Ubuntu 7.04 (perhaps also 6.10, but not 6.06 LTS) is compiled with fstack-protector; Debian is not. However, both Debian and Ubuntu make it very hard, if not impossible, to find any information about proactive security features, contrary to e.g. Fedora, where you can fetch all the information from a single web page (http://fedoraproject.org/wiki/Security/Features). I'm only sure about fstack-protector in 7.04 because I've tested some exploits...
I can see a serious privacy problem with this, since it divulges the IP address of visitors to a third party (Carnegie Mellon). The API is fundamentally broken, since both the website visitor and the website need to contact the central server (rather than the website alone), which allows said third party to generate personalized profiles of web surfers.
While I guess your comment was intended to be fun, I think this is actually a problem where Second Life could be the best possible solution.
Sure there is another way: newest file wins. There are situations where this would be the most logical choice, but nevertheless I couldn't find software that would support this, thus had to write it by myself...
In theory, once rooted you cannot trust anything on the system. In practice, in about 99.9 per cent (or more) of all intrusions, the intruder will use some more or less imperfect off-the-shelf rootkit that only performs standard activities (hide itself, open a backdoor, do keylogging or similar). If it's old, signature-based detectors like Rootkit Hunter or chkrootkit will work. If it's new, signature-based detection will fail, but generic detection techniques (like the ones employed by samhain) have a good chance of catching it. You have a pretty slim chance of ever seeing the (theoretically possible) flawlessly programmed rootkit that hides itself perfectly by closing all possible ways of detecting it. As an example, there are plenty system calls that take a PID (or a path, i.e. /proc/PID) as argument and can be used to infer the presence of a process. All kernel rootkits I've ever seen only care to "fix" about half a dozen of the most frequently used of these system calls.
He says that the only detectors he is aware of are chrootkit and Rootkit Hunter. As he correctly points out, these are signature based - they look e.g. for specific files in userspace (chrootkit also does a generic check for hidden processes). However, the samhain integrity checker also has two different modules to check for kernel-mode rootkits. First, it can check the kernel syscall table to detect syscall redirection within the kernel (on FreeBSD and Linux), and second, it can detect hidden processes (basically in the same way as chrootkit). Also, if checking file integrity, samhain compares the number of hardlinks of a directory with the number of subdirectories to detect hidden subdirectories.
Frank Boldewins site is http://www.reconstructer.org/, not http://www.reconstruction.org/.