A few months ago we got a Dell server with Red Hat preinstalled. To our surprise, the "Linux" compatible system was "Linux ready". But it had a binary-only RAID controller driver, which caused much grief amongst us when the recent kernel security hole (found by the sendmail project people) was found. We had no good way to upgrade the Linux kernel to close the bug without losing access to our drives.
Note however, that this may have been Adaptec's fault; they supposively designed the RAID system, and may have been trying to keep its features private. One could also have blamed us for not researching the "Linux compatibility" further. But we were scared for a while since we heard rumors that they were having problems getting the driver to compile with the new kernel.
Since then, they have released an update (over a month after the hole was first reported), and it includes an open-source version of the binary driver, but we have to wonder what was going on in their heads when they tried such a move. The driver (aacraid) is in Red Hat's Linux's current source code as well, but I don't see it in the mainstream (or for Linux 2.4.0-test#) yet. Drivers in Linux tend to be tied to the kernel; if you don't have the source to upgrade them, you lose the compatibility. Dell only learned that their common usage of custom hardware and drivers wasn't going to work with Linux when a whole bunch of us starting screaming on their message boards.
I used to watch a semi-major Internet site. We got tons and tons of scans against our web server. Soon I learned that at least one of the patterns seen *did* point to systems that were compromised. I likely would have never associated a scanning pattern as being related to a particular tool used on broken-into systems until I spotted an IP address from our hosting ISP scanning us. They quickly confirmed that that system I had seen was indeed compromised. I subsequently sent off a bunch of emails, some to of which went to other quite signficiant players on the Internet that you would have never guessed would have poor security.
Telling someone that their system is portscanning often is not a threat. In my case, I wanted to warn other admins that I thought their systems had problems. If I had chased every portscanner we got, I never would have had time for anything else.
Allright, he says he is getting 76% of people who download his book to say they will pay. Assuming they all do, this is still not likely 76% of the people who downloaded his work in the real world. I'm not even going to get into people who downloaded it and then deciding it wasn't worth the money - let's assume those people are insignificant.
Without into details, I once worked on a reasonably popular website. I had a variety of ways to track what you seemed to go to, and how long you were there. But whenever my superiors pressed, I refused to give them an exact number of people who visited the site, nor any particular page, URL, or file. Why? Web servers do not count users. They simply count hits to a file.
Whenever you access a URL, your web browser may make one or two requests (depending on the version or edition) to access a file and determine its type. In addition, someone may start a download, stop it, resume it later, download it again (either from the same or another computer), etc. In addition, you may have one user behind a proxy or a hundred. The proxy may or may not make itself known.
Now you could create a complex system which noted if a particular IP address supported cookies, if a request seemed to go through a proxy, etc., to try and gain a more accurate count. Still, you are never going to come up with an exact figure. The different between counts of cookies, IP addresses, and hits in terms of bytes downloaded divided by bytes for the page(s) in question can vary by orders of magnitude.
So can Steven King say that exactly 76% of people have paid for his book? He can not. The actual number may be higher or lower (depending on how many illegal "mirrors" sprung up, and their access rates). If he really wanted to get his work online inexpensively, he should have just donated it to Project Gutenburg.
...when they make money no matter what off of the CD-Rs, Cassette tapes, and other related items that independant labels need? They get a fee for every recordable audio medium sold in many countries to compensate artists for copied works.
So in a sense, the RIAA can not be boycotted fully, since you always have to pay them money somewhere along the chain whenever you get recordable or pre-recorded media.
There was talk a long time ago about challenging this in the United States as an illegal form of tax. I do not know happened to that, however.
Yes, it has a photo ID, but can it see faces? The system itself uses a magnetic strip. If the librarian doesn't see you swipe the card, they don't know whose card it is.
Also note: "Huisman said that in Hudsonville, the top two levels of access are restricted for all minors. About 100 cards are currently issued to patrons, who have been charged $3." So, there still is censorship.
Keep in mind any IRC server could be eavesdropping
on
ChatScan Search Engine
·
· Score: 2
While I admit that it sounds like their implementation is poor, *any* IRC server could be watching *every* converstation going through it, *including* private messages (except for DCC chat contents) simply by being compiled with debug code, and enabling it.
IRC is not private. The Internet is not private - any router along the way could be listing in on what you're doing. And given that there are probably at least 20 hops between you and your friends across the country, there is a lot of potential for someone to listen in.
I hate to say it, but something like Microsoft's Terraserver would be real nice here. Given my current coordinates on Earth, the day I want to go star searching, the area of the sky I will look at, etc., and let me see what I will look at through my telescope. There is an interface that provides the ability to search in a fashion somewhat like this, but I still seem to know more that I do to use it.
Actually, you can get reasonably inexpensive dual-format hardware in the United States - you just have to know where to look. One place to look would be the New York area photography/video stores. Do not look in just any shop - you have to go to the ones the professionals use. Most of these businesses are heavily reliant on mail-order sales, so you can have one shipped likely anywhere in the country.
Expect to pay around $200-$300 US dollars (plus shipping) for a basic player unit. These stores stock a lot of equipment to support a variety of formats. Now I really do not want to plug any stores over any others, but doing a quick look, here is one company that stocks multi-format players. Do not treat this as a recommendation - I have never purchased anything from them. Look in their consumer video section. The one downside is that you really have to do some research into what you are buying - unless you are actually visiting these stores, you will not know what you have physically purchased until you get it.
Of particular intrest to me is one item. I would link to it, but they're site is dynamically generated. Do a search for the part number "Dv414" - it should be made by Pioneer. A $400 Multi-Region DVD player?
Everyone seems to be skirting around the main point of this: MAPS is a voluntary system. No one says you must use it. ISPs that use MAPS normally tell their customers that they use it (or likely should). If you do not like that your ISP is using the MAPS system, you can ask for your account to be excluded (if they can), or find another ISP to use. Choosing an ISP with MAPS is choosing features, like choosing what areas with an ISP you have local dialups in.
Now IANAL, but you can say all you want. Talk and talk and talk if it makes you feel happy. If I put earmuffs on my own head (or let my ISP do so on my behalf), you have no right to take them off. I chose to have them put them on.
This is like Yesmail saying I can not hang up on a telemarketer because I must listen to what they say, no how matter how little (i.e. the subject line) I pay attention. This is not a good precendent.
Time for the electrical engineers to comment. Unfortunately, MD5 is not going to work. Anyone who thinks it will likely does not understand the issue.
MD5 is a protocol designed to detect even single bit changes in a file. Note that this works on the file level. MD5 does not care what the file contains. In this case, we are proposing to prove that two files contain the same song. So how can we modify one of these files?
Change the amount of silence before and/or after the file. It wouldn't have to be much: a millisecond or a few probably would be enough, and no person would be the wiser
Change the volume of the recorded music, say, by 0.1%. For best results, one could change the volume the original, uncompressed file. Again, you are not too likely to notice the difference.
Convert the digital audio to analog, and then back again. Have the original audio source be a CD so there is no degredation. There is no way to account for what all the combinations of CD players/sound cards would do to this. Turn on/off "bass boost" and related functions for more file changes. Tweak the treble and bass controls, or use an equilizer. A slight loss of quality in this case, but negligable. The music might even sound better:)
Vary the encoding program used.
Vary the sampling rate used for the raw digital data.
Change the ID3 tag inside the file.
Pad the MPEG file with frames containing no data or data that serves no useful purpose to most programs.
Add white and/or pink noise to the file at very low amplitudes. Simply randomly modify the original digital audio data in the last one or two decimal places, and no one is likely to notice.
There are probably other ways to do this, but I think I've made my point.
MD5 *could* be used to prove that filea.zip and fileb.zip are likely identical (provided they are also the same size). It likely can say file1.mp3 and file2.mp3 were made from track #2 of Some CD when the same encoder and ripper are used, and Some CD's #1 and/or #2 are from the same production run.
MD5 could be used to prove that Bob has the same MP3 file as Alice, although their sources could not be easily proven through this method. But can I say that given this copy of "charttopper#1" that I have an MD5 signature usable to find all copies of "charttopper#1" online? No, you can not.
Now IANAL, nor a PE(yet), and I have not used Napster at all, but I do not think MD5 is the answer here. One could come up with an algorithm that tries to use characteristics of the music itself to look at this issue, but the likelyhood of it working for every possible song in any possible case is nearly zero. It might work for many cases, however. I do not support nor like piracy at all, but this concept of restrict piracy by restricting user rights is also crazy.
I just worry about the person automatically kicked off their ISP due to the fact that some file they downloaded matched the MD5 signature of someone's protected file, even if that file was a completely different one. There are only so many files one can distinguish using any hash algorithm before two come up with the same signature.
I'll agree with you there to an extent. My point is that if I have some boring little website that does not get that much traffic, and the data I have is not that critical, then why do I need to set up a full-fledged database system? For your concerns with two write handles, you could use flock(), a second lockfile, or a combination of both to try and minimize that risk.
The applications I dealt with did not require any instantantaneous access to the data by anyone, so the extra step of copying a week's worth of data (mainly surveys) and importing it into a local database was acceptable to the client. They did not see the point in receiving every last response immediately; it would likely bog them down if they dealt with this data on a daily basis. So in this case, I feel justified in using a system like this; there was no SQL access set up on their systems, so I did not have to create it solely for this task. MySQL or Postgres would have been another thing for their administrators to watch which was not needed.
Linux is a huge beast. Look at it: You have support for IPv4, IPv6, IPX, parallel ports, serial ports, interprocess communication, filesystems, ethernet, etc. You can modularly add or remove these features, but only to an extent. You can run Linux on a 386, but you still need at least 8 MB of RAM to do basic functions. Many microcontrollers at most address 1 MB or 2 MB of memory! That includes your RAM, ROM, etc. Normally, not even half this address space is used. Operating systems designed from the start to fit within the limitations of a these systems (some with as little as 32 KB of RAM or below still - the 68HC11's I used only had 2 KB of EEPROM space onboard) are likely to do a better job than those that are modified and stripped down to do so.
While a high-end consumer device that needs ethernet access might be a good canidate for one of these new Linux-running chips, there will always be room for the smaller and older microcontollers and microprocessors. Remember the Z80? This microprocessor ran Timex's computers back when 16 KB would cost you US $100. It is still available today; Texas Instruments uses it in their calculators that cost about US $80 for the entire thing. Likewise, old microcontrollers are used because they are ready available in bulk -- cheap. A microcontroller for Linux may be a great idea, but likely costs a fortune.
For example, a modern Z180 (with two serial ports built in, a board with their C routines, RTOS, etc.) in quantities of 1,000+ would likely cost me US $50 -- each. That's half the cost of your modern microwave. Compare it to the lowly PIC's we use -- in the same quantities, these chips only cost about US $8 each in the one-time programmable variety. It isn't as fancy, but would be fine for controlling your average clock radio or answering machine. Which would you want in the next item you buy?
While doing web scripts, I often find myself writing simple databases. These forms do trivial things like take a users form and add it (comma or tab seperated) to the end of a text file. While I could have used a complete SQL backend, I chose the simple append to file approach. This is because my forms were purely meant to be imported into a database on another system - there was no need for them to be entered in a manner where they would be quickly searchable locally.
So instead of connecting to an SQL server, logging in, sending the command "INSERT INTO mytable VALUES data_1, data2,..., data_n;", waiting to hear if it worked, and closing the connection, I simply appended a line to a file. When I wanted to read the file, I downloaded it, viewed it locally, and zeroed the online copy so it could be filled again. What is wrong with that?
Compare this to my work with microcontrollers. I do work on Z180's, the PIC series, Basic STAMPs, and the 68HC11's (you can get a good student deal on these from Motorola - ask them). I have done work in both C and pure assembler (or in the case of the stamp, their BASIC). Guess whose programs comes out largest? Those in C. While the assembler routine itself for the task at hand is similar, a bunch of additional preloading code added by the C compiler is added. Imagine how much bloat a crude real-time operating system (RTOS) such as Linux would add if I did not need it.
If I'm purely watching inputs and outputs, and need to scan a few interrupts, I do not see the need to have Linux in my design. Granted, I'm a huge Linux user myself, but putting a stripped-down version in a microcontroller seems to be like shoving an elephant into a tin can. Real-time OS's for microcontrollers have been around for a while; some are designed to take up less than 2 KB. Why do we need to adapt Linux to a task that has already been solved?
First of all, I'll admit that I am one of those lowly "No-Code Techs" that people often used to mutter about. However, I am not one of those who is fond of the FCC lowering its standards. When I first saw the new requirements, I was tempted to let my license expire.
Even though Morse Code may be on its way out, it still is a useful tool for getting through when it really counts. A solid carrier can be understood much easier through heavy interference than a voice. I know I have yet to learn it (I have tried on occasion), but that isn't my point. Morse Code has had another semi-useful side effect: it kept those less civil out who would otherwise just blindly wander into the hobby. Granted, it also kept those who could not learn it easily from coming in to Amateur Radio and advancing, but it is hard to say which it has done more of just by looking at the numbers.
How many people saw the lines that formed when the Morse Code tests were being done just prior to and after April 15 (the date the new pools)? I assisted with running a hamfest (a technical flea market for a day) around that time which offered a testing session. We almost had more people coming just for the old (shorter) test sections than we did for the actual hamfest! Our Volunteer Exam Coordiator (VEC) had to go get more people to assist giving the exam, and space that was not intended for use with the exam sessions suddenly became dedicated to it. About the only reason I was not among them is because I have trouble taking standarized exams; I actually failed the first time I applied for my license.
Rumor has it (and correct me if I'm wrong) that the California area has a major problem with unlicensed users getting Amateur Radio equipment. Even here in New Jersey, local repeaters have often become more CB like than anything. I know CB is often politely referred to as "11-meters," but that is being too kind. The more people that use Amateur Radio, the more we risk it becoming another CB as people see getting a simple license as an unnecessary obstacle.
But this time, the FCC simply can not stop licensing it. CB was a local thing; Amateur Radio is mainly on Internationally set frequencies. (AR's 40-meter band is a shortwave one, but who knows what the FCC was thinking then.) Yes, the ARRL has the Offical Observer (OO) system in place, but how much can we do without the direct authority the FCC has to suspend, revoke, and fine? Although this is partially due to the Internet, the number of FCC actions against Hams I've seen is on the rise.
Part of the problem is our own lack of supervision of the rules. How many hams do you know who have modified their equipment for MARS/CAP/European transmitting operation on the wider bands those provide? How many do not identify themselves online every 10 minutes? You would be surprised. The OO's in our area love the local repeaters. Since they made their presence known, people have been getting back into shape. But Amateur Radio must not get too open and too easy to get into lest we go the way of the CB.
Anyway, this is just my rant. Call it flamebait or whatever you want. I recognize I am being a bit harsh, but take it however you think it should be.
A team at Bell Labs came up with a preloader for ld.so called Libsafe. It tries to keep buffer overflows from happening by keeping various string functions from overwriting the system stack by redefining them so they can not. Since buffer overflows are what cause a significant number of exploits these types of people can use, blocking them from happening is a good idea. Libsafe also can be set up to email a system administrator when a buffer overflow occurs.
While there are a few programs that break due to it, the vast majority I've seen are compatible, and my personal experience has shown that this program keeps people from playing games when they should not. I am *not* saying that having this program is an excuse not to keep up with the latest security patches for your system; rather, this is a useful tool to have in your arsenal. A poorly written program still could have exploits that this utility does not catch.
Just wait for Vertical Integration
on
Frankenstein Time
·
· Score: 1
What if the company that made you required you to take a certain serum in order to stay alive once a week? And what if that same company had a subsidiary that made that serum? You better hope that they do not go out of business.
Seriously, this is not that hard to do once you can manipulate DNA. We already play games with people's hormones to fix percieved illnesses such as depression, and know which genes often cause depression. I'm just waiting for this to happen - chances are, it will happen at least once somewhere.
My organization recently purchased a Dell Server with Linux preloaded. It came with a Perc 3/Si RAID controller built in. Low and behold, the sendmail people found a flaw in the Linux kernel, and it was the concensus of our network administrators to upgrade the kernel to the latest (presently 2.2.16) from Dell's default (2.2.14-12).
However, Dell only seems to provide their drivers in binary form. This may be our mistake, but others seem to be unable to find source versions as well. Hence, we are unable to upgrade the kernel without risking losing access to our RAID array. This is a frestruation I find other people are griping about on USENET and the like. It seems that some groups have figured out what the hardware is; they just do not know how Dell has it interfaced to everything else.
Slashdot Mirror
A few months ago we got a Dell server with Red Hat preinstalled. To our surprise, the "Linux" compatible system was "Linux ready". But it had a binary-only RAID controller driver, which caused much grief amongst us when the recent kernel security hole (found by the sendmail project people) was found. We had no good way to upgrade the Linux kernel to close the bug without losing access to our drives.
Note however, that this may have been Adaptec's fault; they supposively designed the RAID system, and may have been trying to keep its features private. One could also have blamed us for not researching the "Linux compatibility" further. But we were scared for a while since we heard rumors that they were having problems getting the driver to compile with the new kernel.
Since then, they have released an update (over a month after the hole was first reported), and it includes an open-source version of the binary driver, but we have to wonder what was going on in their heads when they tried such a move. The driver (aacraid) is in Red Hat's Linux's current source code as well, but I don't see it in the mainstream (or for Linux 2.4.0-test#) yet. Drivers in Linux tend to be tied to the kernel; if you don't have the source to upgrade them, you lose the compatibility. Dell only learned that their common usage of custom hardware and drivers wasn't going to work with Linux when a whole bunch of us starting screaming on their message boards.
It is obvious to me this quite a "cool computer" to have. Or as a teenager might say, "way cool."
I used to watch a semi-major Internet site. We got tons and tons of scans against our web server. Soon I learned that at least one of the patterns seen *did* point to systems that were compromised. I likely would have never associated a scanning pattern as being related to a particular tool used on broken-into systems until I spotted an IP address from our hosting ISP scanning us. They quickly confirmed that that system I had seen was indeed compromised. I subsequently sent off a bunch of emails, some to of which went to other quite signficiant players on the Internet that you would have never guessed would have poor security.
Telling someone that their system is portscanning often is not a threat. In my case, I wanted to warn other admins that I thought their systems had problems. If I had chased every portscanner we got, I never would have had time for anything else.
Allright, he says he is getting 76% of people who download his book to say they will pay. Assuming they all do, this is still not likely 76% of the people who downloaded his work in the real world. I'm not even going to get into people who downloaded it and then deciding it wasn't worth the money - let's assume those people are insignificant.
Without into details, I once worked on a reasonably popular website. I had a variety of ways to track what you seemed to go to, and how long you were there. But whenever my superiors pressed, I refused to give them an exact number of people who visited the site, nor any particular page, URL, or file. Why? Web servers do not count users. They simply count hits to a file.
Whenever you access a URL, your web browser may make one or two requests (depending on the version or edition) to access a file and determine its type. In addition, someone may start a download, stop it, resume it later, download it again (either from the same or another computer), etc. In addition, you may have one user behind a proxy or a hundred. The proxy may or may not make itself known.
Now you could create a complex system which noted if a particular IP address supported cookies, if a request seemed to go through a proxy, etc., to try and gain a more accurate count. Still, you are never going to come up with an exact figure. The different between counts of cookies, IP addresses, and hits in terms of bytes downloaded divided by bytes for the page(s) in question can vary by orders of magnitude.
So can Steven King say that exactly 76% of people have paid for his book? He can not. The actual number may be higher or lower (depending on how many illegal "mirrors" sprung up, and their access rates). If he really wanted to get his work online inexpensively, he should have just donated it to Project Gutenburg.
...when they make money no matter what off of the CD-Rs, Cassette tapes, and other related items that independant labels need? They get a fee for every recordable audio medium sold in many countries to compensate artists for copied works.
So in a sense, the RIAA can not be boycotted fully, since you always have to pay them money somewhere along the chain whenever you get recordable or pre-recorded media.
There was talk a long time ago about challenging this in the United States as an illegal form of tax. I do not know happened to that, however.
Yes, it has a photo ID, but can it see faces? The system itself uses a magnetic strip. If the librarian doesn't see you swipe the card, they don't know whose card it is.
Also note: "Huisman said that in Hudsonville, the top two levels of access are restricted for all minors. About 100 cards are currently issued to patrons, who have been charged $3." So, there still is censorship.
While I admit that it sounds like their implementation is poor, *any* IRC server could be watching *every* converstation going through it, *including* private messages (except for DCC chat contents) simply by being compiled with debug code, and enabling it.
IRC is not private. The Internet is not private - any router along the way could be listing in on what you're doing. And given that there are probably at least 20 hops between you and your friends across the country, there is a lot of potential for someone to listen in.
I hate to say it, but something like Microsoft's Terraserver would be real nice here. Given my current coordinates on Earth, the day I want to go star searching, the area of the sky I will look at, etc., and let me see what I will look at through my telescope. There is an interface that provides the ability to search in a fashion somewhat like this, but I still seem to know more that I do to use it.
Actually, you can get reasonably inexpensive dual-format hardware in the United States - you just have to know where to look. One place to look would be the New York area photography/video stores. Do not look in just any shop - you have to go to the ones the professionals use. Most of these businesses are heavily reliant on mail-order sales, so you can have one shipped likely anywhere in the country.
Expect to pay around $200-$300 US dollars (plus shipping) for a basic player unit. These stores stock a lot of equipment to support a variety of formats. Now I really do not want to plug any stores over any others, but doing a quick look, here is one company that stocks multi-format players. Do not treat this as a recommendation - I have never purchased anything from them. Look in their consumer video section. The one downside is that you really have to do some research into what you are buying - unless you are actually visiting these stores, you will not know what you have physically purchased until you get it.
Of particular intrest to me is one item. I would link to it, but they're site is dynamically generated. Do a search for the part number "Dv414" - it should be made by Pioneer. A $400 Multi-Region DVD player?
Everyone seems to be skirting around the main point of this: MAPS is a voluntary system. No one says you must use it. ISPs that use MAPS normally tell their customers that they use it (or likely should). If you do not like that your ISP is using the MAPS system, you can ask for your account to be excluded (if they can), or find another ISP to use. Choosing an ISP with MAPS is choosing features, like choosing what areas with an ISP you have local dialups in.
Now IANAL, but you can say all you want. Talk and talk and talk if it makes you feel happy. If I put earmuffs on my own head (or let my ISP do so on my behalf), you have no right to take them off. I chose to have them put them on.
This is like Yesmail saying I can not hang up on a telemarketer because I must listen to what they say, no how matter how little (i.e. the subject line) I pay attention. This is not a good precendent.
Time for the electrical engineers to comment. Unfortunately, MD5 is not going to work. Anyone who thinks it will likely does not understand the issue.
MD5 is a protocol designed to detect even single bit changes in a file. Note that this works on the file level. MD5 does not care what the file contains. In this case, we are proposing to prove that two files contain the same song. So how can we modify one of these files?
There are probably other ways to do this, but I think I've made my point.
MD5 *could* be used to prove that filea.zip and fileb.zip are likely identical (provided they are also the same size). It likely can say file1.mp3 and file2.mp3 were made from track #2 of Some CD when the same encoder and ripper are used, and Some CD's #1 and/or #2 are from the same production run.
MD5 could be used to prove that Bob has the same MP3 file as Alice, although their sources could not be easily proven through this method. But can I say that given this copy of "charttopper#1" that I have an MD5 signature usable to find all copies of "charttopper#1" online? No, you can not.
Now IANAL, nor a PE(yet), and I have not used Napster at all, but I do not think MD5 is the answer here. One could come up with an algorithm that tries to use characteristics of the music itself to look at this issue, but the likelyhood of it working for every possible song in any possible case is nearly zero. It might work for many cases, however. I do not support nor like piracy at all, but this concept of restrict piracy by restricting user rights is also crazy.
I just worry about the person automatically kicked off their ISP due to the fact that some file they downloaded matched the MD5 signature of someone's protected file, even if that file was a completely different one. There are only so many files one can distinguish using any hash algorithm before two come up with the same signature.
I'll agree with you there to an extent. My point is that if I have some boring little website that does not get that much traffic, and the data I have is not that critical, then why do I need to set up a full-fledged database system? For your concerns with two write handles, you could use flock(), a second lockfile, or a combination of both to try and minimize that risk.
The applications I dealt with did not require any instantantaneous access to the data by anyone, so the extra step of copying a week's worth of data (mainly surveys) and importing it into a local database was acceptable to the client. They did not see the point in receiving every last response immediately; it would likely bog them down if they dealt with this data on a daily basis. So in this case, I feel justified in using a system like this; there was no SQL access set up on their systems, so I did not have to create it solely for this task. MySQL or Postgres would have been another thing for their administrators to watch which was not needed.
Linux is a huge beast. Look at it: You have support for IPv4, IPv6, IPX, parallel ports, serial ports, interprocess communication, filesystems, ethernet, etc. You can modularly add or remove these features, but only to an extent. You can run Linux on a 386, but you still need at least 8 MB of RAM to do basic functions. Many microcontrollers at most address 1 MB or 2 MB of memory! That includes your RAM, ROM, etc. Normally, not even half this address space is used. Operating systems designed from the start to fit within the limitations of a these systems (some with as little as 32 KB of RAM or below still - the 68HC11's I used only had 2 KB of EEPROM space onboard) are likely to do a better job than those that are modified and stripped down to do so.
While a high-end consumer device that needs ethernet access might be a good canidate for one of these new Linux-running chips, there will always be room for the smaller and older microcontollers and microprocessors. Remember the Z80? This microprocessor ran Timex's computers back when 16 KB would cost you US $100. It is still available today; Texas Instruments uses it in their calculators that cost about US $80 for the entire thing. Likewise, old microcontrollers are used because they are ready available in bulk -- cheap. A microcontroller for Linux may be a great idea, but likely costs a fortune.
For example, a modern Z180 (with two serial ports built in, a board with their C routines, RTOS, etc.) in quantities of 1,000+ would likely cost me US $50 -- each. That's half the cost of your modern microwave. Compare it to the lowly PIC's we use -- in the same quantities, these chips only cost about US $8 each in the one-time programmable variety. It isn't as fancy, but would be fine for controlling your average clock radio or answering machine. Which would you want in the next item you buy?
While doing web scripts, I often find myself writing simple databases. These forms do trivial things like take a users form and add it (comma or tab seperated) to the end of a text file. While I could have used a complete SQL backend, I chose the simple append to file approach. This is because my forms were purely meant to be imported into a database on another system - there was no need for them to be entered in a manner where they would be quickly searchable locally.
So instead of connecting to an SQL server, logging in, sending the command "INSERT INTO mytable VALUES data_1, data2,..., data_n;", waiting to hear if it worked, and closing the connection, I simply appended a line to a file. When I wanted to read the file, I downloaded it, viewed it locally, and zeroed the online copy so it could be filled again. What is wrong with that?
Compare this to my work with microcontrollers. I do work on Z180's, the PIC series, Basic STAMPs, and the 68HC11's (you can get a good student deal on these from Motorola - ask them). I have done work in both C and pure assembler (or in the case of the stamp, their BASIC). Guess whose programs comes out largest? Those in C. While the assembler routine itself for the task at hand is similar, a bunch of additional preloading code added by the C compiler is added. Imagine how much bloat a crude real-time operating system (RTOS) such as Linux would add if I did not need it.
If I'm purely watching inputs and outputs, and need to scan a few interrupts, I do not see the need to have Linux in my design. Granted, I'm a huge Linux user myself, but putting a stripped-down version in a microcontroller seems to be like shoving an elephant into a tin can. Real-time OS's for microcontrollers have been around for a while; some are designed to take up less than 2 KB. Why do we need to adapt Linux to a task that has already been solved?
First of all, I'll admit that I am one of those lowly "No-Code Techs" that people often used to mutter about. However, I am not one of those who is fond of the FCC lowering its standards. When I first saw the new requirements, I was tempted to let my license expire.
Even though Morse Code may be on its way out, it still is a useful tool for getting through when it really counts. A solid carrier can be understood much easier through heavy interference than a voice. I know I have yet to learn it (I have tried on occasion), but that isn't my point. Morse Code has had another semi-useful side effect: it kept those less civil out who would otherwise just blindly wander into the hobby. Granted, it also kept those who could not learn it easily from coming in to Amateur Radio and advancing, but it is hard to say which it has done more of just by looking at the numbers.
How many people saw the lines that formed when the Morse Code tests were being done just prior to and after April 15 (the date the new pools)? I assisted with running a hamfest (a technical flea market for a day) around that time which offered a testing session. We almost had more people coming just for the old (shorter) test sections than we did for the actual hamfest! Our Volunteer Exam Coordiator (VEC) had to go get more people to assist giving the exam, and space that was not intended for use with the exam sessions suddenly became dedicated to it. About the only reason I was not among them is because I have trouble taking standarized exams; I actually failed the first time I applied for my license.
Rumor has it (and correct me if I'm wrong) that the California area has a major problem with unlicensed users getting Amateur Radio equipment. Even here in New Jersey, local repeaters have often become more CB like than anything. I know CB is often politely referred to as "11-meters," but that is being too kind. The more people that use Amateur Radio, the more we risk it becoming another CB as people see getting a simple license as an unnecessary obstacle.
But this time, the FCC simply can not stop licensing it. CB was a local thing; Amateur Radio is mainly on Internationally set frequencies. (AR's 40-meter band is a shortwave one, but who knows what the FCC was thinking then.) Yes, the ARRL has the Offical Observer (OO) system in place, but how much can we do without the direct authority the FCC has to suspend, revoke, and fine? Although this is partially due to the Internet, the number of FCC actions against Hams I've seen is on the rise.
Part of the problem is our own lack of supervision of the rules. How many hams do you know who have modified their equipment for MARS/CAP/European transmitting operation on the wider bands those provide? How many do not identify themselves online every 10 minutes? You would be surprised. The OO's in our area love the local repeaters. Since they made their presence known, people have been getting back into shape. But Amateur Radio must not get too open and too easy to get into lest we go the way of the CB.
Anyway, this is just my rant. Call it flamebait or whatever you want. I recognize I am being a bit harsh, but take it however you think it should be.
A team at Bell Labs came up with a preloader for ld.so called Libsafe. It tries to keep buffer overflows from happening by keeping various string functions from overwriting the system stack by redefining them so they can not. Since buffer overflows are what cause a significant number of exploits these types of people can use, blocking them from happening is a good idea. Libsafe also can be set up to email a system administrator when a buffer overflow occurs.
While there are a few programs that break due to it, the vast majority I've seen are compatible, and my personal experience has shown that this program keeps people from playing games when they should not. I am *not* saying that having this program is an excuse not to keep up with the latest security patches for your system; rather, this is a useful tool to have in your arsenal. A poorly written program still could have exploits that this utility does not catch.
What if the company that made you required you to take a certain serum in order to stay alive once a week? And what if that same company had a subsidiary that made that serum? You better hope that they do not go out of business.
Seriously, this is not that hard to do once you can manipulate DNA. We already play games with people's hormones to fix percieved illnesses such as depression, and know which genes often cause depression. I'm just waiting for this to happen - chances are, it will happen at least once somewhere.
My organization recently purchased a Dell Server with Linux preloaded. It came with a Perc 3/Si RAID controller built in. Low and behold, the sendmail people found a flaw in the Linux kernel, and it was the concensus of our network administrators to upgrade the kernel to the latest (presently 2.2.16) from Dell's default (2.2.14-12).
However, Dell only seems to provide their drivers in binary form. This may be our mistake, but others seem to be unable to find source versions as well. Hence, we are unable to upgrade the kernel without risking losing access to our RAID array. This is a frestruation I find other people are griping about on USENET and the like. It seems that some groups have figured out what the hardware is; they just do not know how Dell has it interfaced to everything else.