It would be nice if the "tool tip" or direct help bar resolved the URI into pieces, instead of displaying the whole URI or whatever...
http://www.ebay.com/cgi.bin/blah?blah@bad_site would look a lot less enticing to users if the hover over help read: site: bad_site.com resource:/ user: www.ebay.com/cgi.bin/blah?blah password: (not specified)
Application level security is, indeed, the answer or at least a strong first step.
The current assumption is that because the user logged in to the computer clicked a link, they know what that link does. Because the user logged in clicked an icon, they knew what it contained, because they opened a document, they knew what it is.
Spyware can -- and will -- start infecting Linux, as less technical users get there. It's not a matter of infecting the whole system - if they can get just one user, they'll go after just that one user.
Yes, e-Bay (PayPal) is well known for cutting off access, often without investigation, if contacted about transactions that are illegal. What's better still is, in many cases, they can bounce the money back out of the offender's account.
The end user shouldn't be responsible for a programmer's error, for correcting the programer's error, or for identifying and catching the programmer's error.
The issue is that even if you have the source code, you are unlikely to review it for the vast majority of the programs you have installed. The issue is that it is trivial to make an error that would go undetected in your code, and that error can then be used to attack your system.
The application will still terminate with NX bit, if there's a buffer overrun. The trick with the NX bit is that it prevents code insertion attacks using the buffer overflow. The app will crash (SIGSEGV), but the bad guy won't get in.
There are dozens of projects that have reported fixing buffer overrun errors in the last two to three months./. focusses on Microsoft's errors, but Samba, GNome, KDE, Mozilla have also had buffer overruns lately. The Samba vulnerability even allowed access to root privledges, which would be a pretty bad vulnerability indeed.
NX bit would prevent most of these buffer overruns from compromising the system. The first goal has to be keeping the system secure, and since you cannot control the code going in in a meaningful way (by this, I mean there is nobody who has the time to agressively review every single line of source code in every single package that they install), you must focus on limiting the damage that can be inflicted.
This arguement would carry more weight if Samba, libJpeg, libPng, Mozilla FireFox, Knoquerer, KDE, Gnome and xPDF hadn't had recent buffer overflows.
The big issue is that C and C++ don't perform buffer checks at a language level, and if they did, performance would be compromised for some applications. Some programs can deal with a performance hit, others cannot.
NX is a really nice feature in that most overflow attacks involve putting some code in memory, then crafting some attack to jump to it. It is really much more difficult to do this with NX.
Meanwhile any sane VM should be allocating memory with system alloc calls, and then be manually flagging it as executable when it is ready to run.
There is no question about multiple cores value. Today thousands of business applications already run on multiple cores, you can find multiple core applications everywhere.
A JIT should be using an OS level allocate call (not a standard library call), and should be requesting a writeable block. It then should be using an OS level call to mark the block read only and executable.
The JIT should never require write access to a block that is currently executing, and a JIT that does is probably poorly designed and suspect.
So you're arguement would be Dr. Steve Squires assertion that the technology won't be there for an adequate rover during any of our lifetimes, as publicly stated on the record not just once but several times, and that his assertion that a human scientist can do all of the work that Spirit and Opportunity take days to accomplish in a matter of minutes is based on Star Trek?
At a Nasa safety conference, the good doctor spent some time discussing safety and robotic missions, and told a story. During testing and design of the Mars Exploration Vehicles, they were out in the desert, collecting rock samples with some geologists. The prototype vehicle was having some issues, and wasn't operable, so he took them on a little rock hunt, and sat there with a stenographer's pad recording ballpark or rough time it took them to see things, make decisions, and act on the decisions, and to perform various science.
On the average, a task that would require the rover two to three days was accomplished in under twenty seconds by a human being.
He said, and this is an almsot driect quote, that it really irked him when people said that robotic missions were adequate and could provide the science, because the amount of science they can perform is so small compared to a human being there, on the planet.
He said, again an almost direct quote, that there would not be a robotic mission in his lifetime that could adequately answer the questions that scientists have, and that there might never be the capability to answer the questions by robotic means.
Now I'm not going to argue that sending someone there isn't a technological feat, and that it won't require a great deal of effort and technological progress.
At any rate, the line you quote is an almost direct, word for word, quote from the head of the MERV program, who, I would say, most definitely has the scientific knowledge to make the determination.
Quote: At least with GPL, I will always have an opportunity to improve on improvements made by others on my work.
There is no requirement to distribute source code with a GPL program. The requirement is that for 3 years, you must make the source code available to any party whom you provided with a copy of the code in any form. You may use physical media to provide the source code, and you may require the person to whom you are providing the source code to pay for the media and shipping.
There is absolutely nothing saying that any of this must be provided to the original author, nor that the original author must be notified or otherwise made aware of the change.
The GPL does not require me to provide anyone, even the original author, with a copy of the code unless and until they obtain a copy of the modified code through some mechanism.
And so everything you say about the BSD license applies equally to the GPL and LGPL licenses.
Meanwhile, you're inflicting a burden on each and every user of your software by using the GPL. They must be able to provide source code, for a period of not less than 3 years, to anyone to whom they copy the software. By definition, they must obtain the source code in order to be able to comply with this clause, because there is no requirement for the original author to provide source code for the rest of the period.
The issue is you can't retroactively remove the stipulation "or any later version" from the GPL as presented at the top of ever application, nor can you contain what "or any later version" applies.
Unless you have consent of all the original authors, you cannot relicense a GPL project under any other license, so the "or any later version" clause really could potentially cause a lot of damage, if something like this were to occur.
Competition even between commercial and open source is good. When you can't see the code, when you have to guess at how something might work, you are more likely to come up with a different approach than when you have code that you can just copy from.
Blocking port 25 is a really bad idea, there are a lot of legitimate uses, although people forget that in this day and age.
I would much rather see StartTLS as a requirement on all mail servers. Simply require TLS, and require both sides to have certificates signed by a trusted CA (the list the web browsers use, plus any I have manually added to my particular systems list).
First of all, I'd rather use TLS than CRAM to identify to Earthlink to begin with, because I have to go over the public internet and would rather have a secure connection than what I get right now (Earthlink cable travels over time warner's wires).
Secondly, greylisting delays e-mail by up to a half hour. There are times when I'm handling a support call where I have 30 minutes, and need to get information from a customer whose PC has been locked down by another company's IT deparment to only run Word and Outlook. In these cases, I am contractually obligated to resolve the issue in a fixed period of time, or we pay a huge penalty.
I strongly advocate a small delay (15-60s) between accepting the initial HELO/EHLO command and sending a response, and dropping any connection that sends a new command in that window.
The root CA's require contact information that at least works, and billing information that at least works, before they issue a certificate. Therefore, you have information to go after them that had to be valid at least when the certificate was granted.
The spammers use zombie bots and change ISPs on an ongoing basis, generally in remote, out of the way areas. I'm more likely to get a spam report because some outlook zombie picked my name out of someone's address book who had a message from me five years ago than because of anything my system actually sends.
Spammer 2394596 sends out a free screen saver, user installs it, it sends a spam every few seconds when it's active with names from the address book in reply...
And before you say "don't send mail to people who use outlook," unfortunately, in my old job, I had to handle calls from customers who paid $2m for a system at 2 and 3 am, and had no way to control what software they might be running when I sent them e-mails.
One of the issues that independent software developers (shareware authors, in particular) have is that the FBI and government will not become involved in cases where you can't demonstrate a substantial (around $5000) loss, because they can't successfully prosecute many of the cases -- even of proven infringement -- because of the requirement of a trial by jury.
The person committing the infringement is brought up on charges, cries to the jury about how they can't afford the fine or whatever, and the jury (being a bunch of mindless saps) goes oh, we feel sorry for you, you get off for free.
These people that the RIAA is suing, they aren't downloading one or two games, or one or two movies, or one or two movies. The RIAA and MPAA are going after people who are blatantly pirating.
And they have a right to do that. There is no difference between walking out of best buy with a DVD tucked under your shirt and downloading a torrent of that same movie.
Yes, lets compare illegally ripping off artists, motion pictures or video games to a legitimate business, and then put on our tin-foil hats and blame the government.
So far as steve jackson games (one of the other children) goes, I'm sure their closing down has more to do with the FBI raid, after which they released a few hundred products, and less to do with the total collapse of the pen and paper RPG industry.
Game Designers Workshop - dead. TSR - dead. Fasa - dead. SJG - dead. Westwood - dead. White Wolf - dead. Yeah some of these bounced back from their bankrupcies or got bought out, but I don't think you can blame the FBI in SJG's case.
On the 3D side of things, GameSpace Light (I use both GameSpace Pro and GameSpace Light) is also a pretty effective program, free of advertising and spyware. I have found it to be much more effective than Wings, Blender, Anim8or, and OpenFX.
I use the professional version on a single machine (which is definitively non-free software) and the free version on three machines with a lot of success at its primary purpose (making modles for games)
--- QUOTE from someone who doesn't get the problem Simple, get your kernel driver into the main kernel tree (remember we are talking about GPL released drivers here, if your code doesn't fall under this category, good luck, you are on your own here, you leech.) If your driver is in the tree, and a kernel interface changes, it will be fixed up by the person who did the kernel change in the first place. This ensures that your driver is always buildable, and works over time, with very little effort on your part. ---END quote from someone who doesn't get the problem
Wrong.
The kernel developer goes into the GPL source code, and marks the driver as "incomplete" or at absolute best makes it compile. Not actually having the device, in all likelyhood, the code is then comitted, untested, to the kernel.
At some later point in time, a week or a month down the line, some unsuspecting user installs the updated kernel, and their device starts having random, untrackable problems. They come to the list, and are told by a dozen people that the kernel developers aren't responsible for drivers, and that they should talk to whoever actually maintains the driver.
After finding the appropriate mailing list for the particular driver that the kernel developer broke, the user posts a question about is there a patch, and receives e-mails from not less than 10 trolls telling them "it's open source, fix it yourself." Their message is in a sea of messages in all caps with too many question marks and exclamation points, where a developer is going around in circles with a user who can't afford a keyboard with a shift key, and can't afford to buy a vowel (they are expensive, you know).
Finally after all of this, the device driver developer sends them back a reply "sorry, I've not had a chance to test with the new kernel yet, run the old version while you wait." Then the developer gets around to posting a patch.
If you're lucky, it's a device a lot of people use, people get angry about it, and it gets some attention fast. If you're unlucky, you've got a device that needs the older kernel and a device that needs the newer kernel, and you have to make a choice between the two and wait for the other driver to get upgraded.
The odds of another user capable of it getting off their ass and actually researching, fixing, and posting the fix are virtually nil.
Here is the scenario for Windows: Insert your device Boot the computer Windows says "there's a new device, put the disk in" Windows copies the device driver Windows possibly reboots (this is rare for most device classes, but some still need reboots) Device works
Now you can argue about bluescreens or whatever, but it is a better model in that Microsoft's kernel team takes no time maintaining device drivers. There's a clear ABI division between their kernel and their drivers, and that division changes only at major versions of the kernel.
This is the thing. When I get the kernel, I'm getting thousands of drivers I don't want or need. Most of these aren't being actively maintained, and are being updated so that they compile but aren't undergoing any level of testing at all.
The kernel developers do not perform unit testing on the drivers (there is no facility for them to do so), and do not typically have the hardware or the large number of hardware, software combinations that need to be tested.
So no, putting it in the kernel tree does absolutely nothing to solve the problem.
Currently, configure.sh usually has to probe for a lot of libraries, to determine what's available on your system. If you require LSB, you don't need to probe for any library or function that is part of LSB.
This is similar to requiring ISO or ANSI C/C++. If you require ANSI C++ v3, then you don't have to probe for a lot of information.
For example, a common probe in configure.sh is to determine byte width. If you can be sure you're running on only ANSI/ISO compilers, you can just pull in stdtypes, and use int32, uint32, etc. and friends, and you have template functions that can return sizes, limits, etc.
You can be sure IO Streams is there and that the base STL is there, and have a firm foundation to build from.
The issue is most projects won't be brave enough to tell their users "we're only supporting systems with the LSB baseline."
That's why we still have checks for work around for bugs in SunOS 3 going in to new code, becuse nobody is brave enough to tell the Sun OS users, "You know what, just install GNU C and the GNU libraries so that we don't have to keep dealing with 20 year old bugs."
Not to mention, pop up "configure.sh" and look at how many of the problems a typical project has to work around because some *nix variant pukes if you Malloc 0x2020 bytes or some other nonsense...
Posting it out here as a root because it's applicable to 3/4 of the "why isn't listed?"
1. Solutions like PopFile or Thunderbird: These require per-machine or per-user configuration beyond "point the program at the mail server and go." If you had 10,000 users, these solutions wouldn't work. I love PopFile, I love Thunderbird, but for any solution to be enterprise level, it needs to occur on the server.
2. Solutions like SpamAssassin: The packages reviewed had graphical interfaces, installs and actual support teams.
Spam Assassin was invited, but the support was lacking. When they went to the community, the community let them down. This is far more often the case than a lot of us would admit. Usually there are about 10 to 15 useful people on any given projects mailing list or on any projects community site, and a legion of trolls, flamers and other morons who will just repeatedly post messages like "fix it yourself" rather than letting the people who are in the list to actually contribute usefully can respond.
Even in that case, if you're managing 12 servers, or 100 servers, or all of hotmail (these are enterprise scenarios), you want a nice UI, you want to be able to sync all those servers, you want to be able to check their status without going out to each of them, desktop notifications, etc.
The article went to great lengths to point out that many of the products use Spam Assassin internally, calling out several by names, and saying that is wasn't excluded because of this.
3. Graduate college and spend a couple weeks in commercial IT, and then see how much patience you have for RPM, APT, etc. and editing config files. Try talking a user who can't get their e-mail through configuring their client for pop file. I'm not talking people who read/., I'm talking actual users.
When some VP who barely understands how to work a power switch can't get their e-mail, you don't want to be trying to talk them through typing a bunch of "garbage" into a configuration field.
4. Security also comes into play here.
PopFile is not an enterprise solution. Anyone with a web browser and access to your machine can pull up PopFile and view every e-mail it has ever processed. I know of very few executives or even common employees who would consider that to be a "good thing."
Maybe because this was for enterprise solutions.
I use PopFile, but it has no place in this article in its current state.
An enterprise means a few hundred or thousand users. Maintaining a few hundred or thousand copies of popfile is a mess. You cannot use a central server, because it shows all e-mail its ever processed in the log, to anyone who can happen to establish an IP connection to it. It doesn't require any authentication, etc.
It requires per-machine configuration, and per-user training, and is has buckets on only a per-install basis, so you better have an install per user.
These solutions that were reviewed were reviewed for large companies (read: someone like IBM) with dozens of mail servers, etc. that have to be kept in sync for thousands of users.
Any solution that isn't server side isn't applicable. That includes Thunderbird. The reason that they aren't applicable is simple.
Anything that isn't done on the server, isn't enterprise.
The main reason that this was obliged was for people who can't get a direct flight.
It used to be that our corprate policies had me taking two connecting flights. While 2 hours might not be a long time, 6 hours could be, and often there was only 5 or 10 minutes to get between the planes, so grabbing something to eat wasn't really an option.
This is based on Wired's much more clear and coherent description.
Desktop search installs an object that the browser instantiates on Google web pages to render local results along side of google results. No data is sent in this process.
The attack involves the fact that this data is present on the web page itself, and is added to the DOM. An attacker using JavaScript can traverse the DOM and read the exerpts of files shown on the search page.
It cannot follow this to the document itself in the cache, and it can see nothing other than the quoted excerpt.
It's beta software, bound to be problems. This particular problem is because the object isn't "locked to the page."
The vulnerability doesn't effect any other desktop search tool that is currently available, because none of them use an object in the browser to integrate search results with their web page. All the other tools are either search your desktop or search the web, not search both at once.
Using FireFox, without the object, you won't get the integrated search results, so you won't have the problem.
Slashdot Mirror
It would be nice if the "tool tip" or direct help bar resolved the URI into pieces, instead of displaying the whole URI or whatever...
/
http://www.ebay.com/cgi.bin/blah?blah@bad_site
would look a lot less enticing to users if the hover over help read:
site: bad_site.com
resource:
user: www.ebay.com/cgi.bin/blah?blah
password: (not specified)
Application level security is, indeed, the answer or at least a strong first step.
The current assumption is that because the user logged in to the computer clicked a link, they know what that link does. Because the user logged in clicked an icon, they knew what it contained, because they opened a document, they knew what it is.
Spyware can -- and will -- start infecting Linux, as less technical users get there. It's not a matter of infecting the whole system - if they can get just one user, they'll go after just that one user.
Yes, e-Bay (PayPal) is well known for cutting off access, often without investigation, if contacted about transactions that are illegal. What's better still is, in many cases, they can bounce the money back out of the offender's account.
Double opt-in would also be kinda rare for a true spam program.
The end user shouldn't be responsible for a programmer's error, for correcting the programer's error, or for identifying and catching the programmer's error.
/. focusses on Microsoft's errors, but Samba, GNome, KDE, Mozilla have also had buffer overruns lately. The Samba vulnerability even allowed access to root privledges, which would be a pretty bad vulnerability indeed.
The issue is that even if you have the source code, you are unlikely to review it for the vast majority of the programs you have installed. The issue is that it is trivial to make an error that would go undetected in your code, and that error can then be used to attack your system.
The application will still terminate with NX bit, if there's a buffer overrun. The trick with the NX bit is that it prevents code insertion attacks using the buffer overflow. The app will crash (SIGSEGV), but the bad guy won't get in.
There are dozens of projects that have reported fixing buffer overrun errors in the last two to three months.
NX bit would prevent most of these buffer overruns from compromising the system. The first goal has to be keeping the system secure, and since you cannot control the code going in in a meaningful way (by this, I mean there is nobody who has the time to agressively review every single line of source code in every single package that they install), you must focus on limiting the damage that can be inflicted.
This arguement would carry more weight if Samba, libJpeg, libPng, Mozilla FireFox, Knoquerer, KDE, Gnome and xPDF hadn't had recent buffer overflows.
The big issue is that C and C++ don't perform buffer checks at a language level, and if they did, performance would be compromised for some applications. Some programs can deal with a performance hit, others cannot.
NX is a really nice feature in that most overflow attacks involve putting some code in memory, then crafting some attack to jump to it. It is really much more difficult to do this with NX.
Meanwhile any sane VM should be allocating memory with system alloc calls, and then be manually flagging it as executable when it is ready to run.
There is no question about multiple cores value. Today thousands of business applications already run on multiple cores, you can find multiple core applications everywhere.
A JIT should be using an OS level allocate call (not a standard library call), and should be requesting a writeable block. It then should be using an OS level call to mark the block read only and executable.
The JIT should never require write access to a block that is currently executing, and a JIT that does is probably poorly designed and suspect.
Interesting...
So you're arguement would be Dr. Steve Squires assertion that the technology won't be there for an adequate rover during any of our lifetimes, as publicly stated on the record not just once but several times, and that his assertion that a human scientist can do all of the work that Spirit and Opportunity take days to accomplish in a matter of minutes is based on Star Trek?
At a Nasa safety conference, the good doctor spent some time discussing safety and robotic missions, and told a story. During testing and design of the Mars Exploration Vehicles, they were out in the desert, collecting rock samples with some geologists. The prototype vehicle was having some issues, and wasn't operable, so he took them on a little rock hunt, and sat there with a stenographer's pad recording ballpark or rough time it took them to see things, make decisions, and act on the decisions, and to perform various science.
On the average, a task that would require the rover two to three days was accomplished in under twenty seconds by a human being.
He said, and this is an almsot driect quote, that it really irked him when people said that robotic missions were adequate and could provide the science, because the amount of science they can perform is so small compared to a human being there, on the planet.
He said, again an almost direct quote, that there would not be a robotic mission in his lifetime that could adequately answer the questions that scientists have, and that there might never be the capability to answer the questions by robotic means.
Now I'm not going to argue that sending someone there isn't a technological feat, and that it won't require a great deal of effort and technological progress.
At any rate, the line you quote is an almost direct, word for word, quote from the head of the MERV program, who, I would say, most definitely has the scientific knowledge to make the determination.
Quote:
At least with GPL, I will always have an opportunity to improve on improvements made by others on my work.
There is no requirement to distribute source code with a GPL program. The requirement is that for 3 years, you must make the source code available to any party whom you provided with a copy of the code in any form. You may use physical media to provide the source code, and you may require the person to whom you are providing the source code to pay for the media and shipping.
There is absolutely nothing saying that any of this must be provided to the original author, nor that the original author must be notified or otherwise made aware of the change.
The GPL does not require me to provide anyone, even the original author, with a copy of the code unless and until they obtain a copy of the modified code through some mechanism.
And so everything you say about the BSD license applies equally to the GPL and LGPL licenses.
Meanwhile, you're inflicting a burden on each and every user of your software by using the GPL. They must be able to provide source code, for a period of not less than 3 years, to anyone to whom they copy the software. By definition, they must obtain the source code in order to be able to comply with this clause, because there is no requirement for the original author to provide source code for the rest of the period.
OSI doesn't control the license, FSF does.
The issue is you can't retroactively remove the stipulation "or any later version" from the GPL as presented at the top of ever application, nor can you contain what "or any later version" applies.
Unless you have consent of all the original authors, you cannot relicense a GPL project under any other license, so the "or any later version" clause really could potentially cause a lot of damage, if something like this were to occur.
Competition even between commercial and open source is good. When you can't see the code, when you have to guess at how something might work, you are more likely to come up with a different approach than when you have code that you can just copy from.
Generally speaking, the GPL gives neither freedom for the developer nor freedom for the user.
Users don't build from source, developers already have the source, regardless of the license.
Blocking port 25 is a really bad idea, there are a lot of legitimate uses, although people forget that in this day and age.
I would much rather see StartTLS as a requirement on all mail servers. Simply require TLS, and require both sides to have certificates signed by a trusted CA (the list the web browsers use, plus any I have manually added to my particular systems list).
First of all, I'd rather use TLS than CRAM to identify to Earthlink to begin with, because I have to go over the public internet and would rather have a secure connection than what I get right now (Earthlink cable travels over time warner's wires).
Secondly, greylisting delays e-mail by up to a half hour. There are times when I'm handling a support call where I have 30 minutes, and need to get information from a customer whose PC has been locked down by another company's IT deparment to only run Word and Outlook. In these cases, I am contractually obligated to resolve the issue in a fixed period of time, or we pay a huge penalty.
I strongly advocate a small delay (15-60s) between accepting the initial HELO/EHLO command and sending a response, and dropping any connection that sends a new command in that window.
The root CA's require contact information that at least works, and billing information that at least works, before they issue a certificate. Therefore, you have information to go after them that had to be valid at least when the certificate was granted.
The spammers use zombie bots and change ISPs on an ongoing basis, generally in remote, out of the way areas. I'm more likely to get a spam report because some outlook zombie picked my name out of someone's address book who had a message from me five years ago than because of anything my system actually sends.
Spammer 2394596 sends out a free screen saver, user installs it, it sends a spam every few seconds when it's active with names from the address book in reply...
And before you say "don't send mail to people who use outlook," unfortunately, in my old job, I had to handle calls from customers who paid $2m for a system at 2 and 3 am, and had no way to control what software they might be running when I sent them e-mails.
Code is just another form of equation, with a different way of recording numbers.
Actually, no you wouldn't have.
One of the issues that independent software developers (shareware authors, in particular) have is that the FBI and government will not become involved in cases where you can't demonstrate a substantial (around $5000) loss, because they can't successfully prosecute many of the cases -- even of proven infringement -- because of the requirement of a trial by jury.
The person committing the infringement is brought up on charges, cries to the jury about how they can't afford the fine or whatever, and the jury (being a bunch of mindless saps) goes oh, we feel sorry for you, you get off for free.
These people that the RIAA is suing, they aren't downloading one or two games, or one or two movies, or one or two movies. The RIAA and MPAA are going after people who are blatantly pirating.
And they have a right to do that. There is no difference between walking out of best buy with a DVD tucked under your shirt and downloading a torrent of that same movie.
Yes, lets compare illegally ripping off artists, motion pictures or video games to a legitimate business, and then put on our tin-foil hats and blame the government.
So far as steve jackson games (one of the other children) goes, I'm sure their closing down has more to do with the FBI raid, after which they released a few hundred products, and less to do with the total collapse of the pen and paper RPG industry.
Game Designers Workshop - dead. TSR - dead. Fasa - dead. SJG - dead. Westwood - dead. White Wolf - dead. Yeah some of these bounced back from their bankrupcies or got bought out, but I don't think you can blame the FBI in SJG's case.
On the 3D side of things, GameSpace Light (I use both GameSpace Pro and GameSpace Light) is also a pretty effective program, free of advertising and spyware. I have found it to be much more effective than Wings, Blender, Anim8or, and OpenFX.
I use the professional version on a single machine (which is definitively non-free software) and the free version on three machines with a lot of success at its primary purpose (making modles for games)
2.6.8 to 2.6.9 broke ABI.
.) If your driver is in the tree, and a kernel interface changes, it will be fixed up by the person who did the kernel change in the first place. This ensures that your driver is always buildable, and works over time, with very little effort on your part.
--- QUOTE from someone who doesn't get the problem
Simple, get your kernel driver into the main kernel tree (remember we are talking about GPL released drivers here, if your code doesn't fall under this category, good luck, you are on your own here, you leech
---END quote from someone who doesn't get the problem
Wrong.
The kernel developer goes into the GPL source code, and marks the driver as "incomplete" or at absolute best makes it compile. Not actually having the device, in all likelyhood, the code is then comitted, untested, to the kernel.
At some later point in time, a week or a month down the line, some unsuspecting user installs the updated kernel, and their device starts having random, untrackable problems. They come to the list, and are told by a dozen people that the kernel developers aren't responsible for drivers, and that they should talk to whoever actually maintains the driver.
After finding the appropriate mailing list for the particular driver that the kernel developer broke, the user posts a question about is there a patch, and receives e-mails from not less than 10 trolls telling them "it's open source, fix it yourself." Their message is in a sea of messages in all caps with too many question marks and exclamation points, where a developer is going around in circles with a user who can't afford a keyboard with a shift key, and can't afford to buy a vowel (they are expensive, you know).
Finally after all of this, the device driver developer sends them back a reply "sorry, I've not had a chance to test with the new kernel yet, run the old version while you wait." Then the developer gets around to posting a patch.
If you're lucky, it's a device a lot of people use, people get angry about it, and it gets some attention fast. If you're unlucky, you've got a device that needs the older kernel and a device that needs the newer kernel, and you have to make a choice between the two and wait for the other driver to get upgraded.
The odds of another user capable of it getting off their ass and actually researching, fixing, and posting the fix are virtually nil.
Here is the scenario for Windows:
Insert your device
Boot the computer
Windows says "there's a new device, put the disk in"
Windows copies the device driver
Windows possibly reboots (this is rare for most device classes, but some still need reboots)
Device works
Now you can argue about bluescreens or whatever, but it is a better model in that Microsoft's kernel team takes no time maintaining device drivers. There's a clear ABI division between their kernel and their drivers, and that division changes only at major versions of the kernel.
This is the thing. When I get the kernel, I'm getting thousands of drivers I don't want or need. Most of these aren't being actively maintained, and are being updated so that they compile but aren't undergoing any level of testing at all.
The kernel developers do not perform unit testing on the drivers (there is no facility for them to do so), and do not typically have the hardware or the large number of hardware, software combinations that need to be tested.
So no, putting it in the kernel tree does absolutely nothing to solve the problem.
Yes, it does (contrary to the other two posts).
Currently, configure.sh usually has to probe for a lot of libraries, to determine what's available on your system. If you require LSB, you don't need to probe for any library or function that is part of LSB.
This is similar to requiring ISO or ANSI C/C++. If you require ANSI C++ v3, then you don't have to probe for a lot of information.
For example, a common probe in configure.sh is to determine byte width. If you can be sure you're running on only ANSI/ISO compilers, you can just pull in stdtypes, and use int32, uint32, etc. and friends, and you have template functions that can return sizes, limits, etc.
You can be sure IO Streams is there and that the base STL is there, and have a firm foundation to build from.
The issue is most projects won't be brave enough to tell their users "we're only supporting systems with the LSB baseline."
That's why we still have checks for work around for bugs in SunOS 3 going in to new code, becuse nobody is brave enough to tell the Sun OS users, "You know what, just install GNU C and the GNU libraries so that we don't have to keep dealing with 20 year old bugs."
Not to mention, pop up "configure.sh" and look at how many of the problems a typical project has to work around because some *nix variant pukes if you Malloc 0x2020 bytes or some other nonsense...
Posting it out here as a root because it's applicable to 3/4 of the "why isn't listed?"
/., I'm talking actual users.
1. Solutions like PopFile or Thunderbird:
These require per-machine or per-user configuration beyond "point the program at the mail server and go." If you had 10,000 users, these solutions wouldn't work. I love PopFile, I love Thunderbird, but for any solution to be enterprise level, it needs to occur on the server.
2. Solutions like SpamAssassin:
The packages reviewed had graphical interfaces, installs and actual support teams.
Spam Assassin was invited, but the support was lacking. When they went to the community, the community let them down. This is far more often the case than a lot of us would admit. Usually there are about 10 to 15 useful people on any given projects mailing list or on any projects community site, and a legion of trolls, flamers and other morons who will just repeatedly post messages like "fix it yourself" rather than letting the people who are in the list to actually contribute usefully can respond.
Even in that case, if you're managing 12 servers, or 100 servers, or all of hotmail (these are enterprise scenarios), you want a nice UI, you want to be able to sync all those servers, you want to be able to check their status without going out to each of them, desktop notifications, etc.
The article went to great lengths to point out that many of the products use Spam Assassin internally, calling out several by names, and saying that is wasn't excluded because of this.
3. Graduate college and spend a couple weeks in commercial IT, and then see how much patience you have for RPM, APT, etc. and editing config files. Try talking a user who can't get their e-mail through configuring their client for pop file. I'm not talking people who read
When some VP who barely understands how to work a power switch can't get their e-mail, you don't want to be trying to talk them through typing a bunch of "garbage" into a configuration field.
4. Security also comes into play here.
PopFile is not an enterprise solution. Anyone with a web browser and access to your machine can pull up PopFile and view every e-mail it has ever processed. I know of very few executives or even common employees who would consider that to be a "good thing."
Maybe because this was for enterprise solutions. I use PopFile, but it has no place in this article in its current state. An enterprise means a few hundred or thousand users. Maintaining a few hundred or thousand copies of popfile is a mess. You cannot use a central server, because it shows all e-mail its ever processed in the log, to anyone who can happen to establish an IP connection to it. It doesn't require any authentication, etc. It requires per-machine configuration, and per-user training, and is has buckets on only a per-install basis, so you better have an install per user. These solutions that were reviewed were reviewed for large companies (read: someone like IBM) with dozens of mail servers, etc. that have to be kept in sync for thousands of users. Any solution that isn't server side isn't applicable. That includes Thunderbird. The reason that they aren't applicable is simple. Anything that isn't done on the server, isn't enterprise.
The main reason that this was obliged was for people who can't get a direct flight.
It used to be that our corprate policies had me taking two connecting flights. While 2 hours might not be a long time, 6 hours could be, and often there was only 5 or 10 minutes to get between the planes, so grabbing something to eat wasn't really an option.
Here is how the attack works.
This is based on Wired's much more clear and coherent description.
Desktop search installs an object that the browser instantiates on Google web pages to render local results along side of google results. No data is sent in this process.
The attack involves the fact that this data is present on the web page itself, and is added to the DOM. An attacker using JavaScript can traverse the DOM and read the exerpts of files shown on the search page.
It cannot follow this to the document itself in the cache, and it can see nothing other than the quoted excerpt.
It's beta software, bound to be problems. This particular problem is because the object isn't "locked to the page."
The vulnerability doesn't effect any other desktop search tool that is currently available, because none of them use an object in the browser to integrate search results with their web page. All the other tools are either search your desktop or search the web, not search both at once.
Using FireFox, without the object, you won't get the integrated search results, so you won't have the problem.