As a matter of fact, all telemarketing and opt-out systems should be reviewed as a whole from the legal standpoint, as they are very broken. Not only do companies have the right to pass on your phone numbers to others, there is no way to undo that except after each call, by asking to specifically have your number removed. There are ways out there to register your phone on a "do-not-call" list but they just plainly don't work.
A few years ago I bought this nice $100 answering machine that right now is collecting dust somewhere, because I disconnected it after I found I was getting 6-7 messages A DAY, wasting tape and my time to listen to each one of them.
This goes for my home line too - I pay for it only because I need a "home phone" but the phone is always off and I use the cell exclusively for my incoming calls.
I had a couple of these systems, they would develop filesystem errors out of nowhere. It always turned out to be faulty old hardware (memory, cables, motherboard etc). The PC components get old really fast, my plan has been to get new hardware at least every three years and get real server hardware (ServerWorks mobo etc).
For the last series, I have not noticed any unexpected filesystem errors after 200-300 days of uptime (they need to be rebooted from time to time for kernel upgrades).
To conclude, always suspect your hardware first, especially if it's at least a couple years old.
We have today a global information society and thus broadcasts from various parts of the world will (or, at least, should) be available in other parts as well. This is illustrated by the fact that finally a lot of TVs sold today work with all three major standards, but for a long time they didn't. This makes the issue of standardization more important than it was in the past where the broadcasts were mostly local. I'd rather have them to it right this time.
You know, not all broadcasts are terrestrial, they invented satellites in the meantime.
Multiple standards are a ploy by manufacturers and broadcasters to control market share (the same way DVD region-coding works) and for their local patent owners to get their royalties.
It is generally accepted (read "taught in schools") that there are four states of matter, no ifs and buts. Therefore, the statement "as we all know there are three" is not quite correct.
I believe the author is wrong on a couple issues, which kind of discredits his rather artificial logic for the rest of them (that I could care less about anyway).
1) Today applications DON'T take seconds to start. In fact, the bloat in software has kept the pace with advances in hardware, thus making the software today take the same resources (percentage-wise) as the one yesterday. Netscape, Photoshop, Real player, any application not deeply embedded in Windows take forever to start requiring all those nifty "accelerators" ran at login time that use up real memory trying to cope with this problem. Even if it didn't, so long as computers have limited resources (and hardware manufacturers will make sure the prices are never so low for us to afford plenty of ).
2) Same goes for documents. Saving documents in Word, images in Photoshop is never blazingly fast.
Let alone that file versioning a la VMS fills the disk space quite quickly and would require an interface to "clean up" the unnecessary revisions lying around.
By the way, Word does by default do incremental saves which a lot of us here seemed to like so much; I hope we still remember the events concerning inadvertent release of information through documents published on the web that were saved using this mechanism. Besides, all the points made about me choosing when to save are valid - I really want to have the choice of when to write my changes.
3) Inodes - just by mentioning that the author proves he has no idea what he is talking about. Unix has had this for a long time - there are hard links which use inodes and there are symbolic links which just point to the path. So Unix offers both, care to check which type is most commonly used ?
For one, hard links are not portable across filesystems (partitions). Also, deleting a hard linked file does not actually release the disk space until all links have been removed. This can cause some serious confusion to the head of the Windows user. Hard links are difficult to back up and restore properly.
Want more ? When an application saves a file it usually creates a new file, writes the data then moves it over the original file (to avoid data loss due to write errors). Guess what happens to the inode number.
I seriously doubt this. I never heard SCSI was sensitive to cable lengths (within spec of course). The data goes in a buffer anyway, it's not like it's written to the media on the fly.
You are missing all the bugs that might be in the code still running as uid 0. Your daemons, the kernel, all of them are vulnerable. I haven't seen many exploits that actually get root by doing "su" to it, so "disabling" that account will not achieve more than, for example, a good password.
A "secure" OS in this context means an OS with well-known "clean", stable code that has been reviewed for flaws etc etc. There isn't much you can do from an administration point of view if the services/daemons you have to use are flawed.
I think sprinkling setuids around is not a great idea at all. Especially custom-written ones. Beautiful things can happen accidentally linking against the wrong library in a chrooted dir:)
Chroot is *not* 100% secure. It is not a sandbox. You can still access ports, memory and processes and kernel functions, you can talk to daemons, starve the system of resources or convince the parent process to do things it will regret.
Plus if you chroot users you'd still have to give them most of the OS somewhere unless they login to not do any work, and that will soon get boring when you'll have to upgrade all of it.
A truly secure machine requires hardware support. A better CPU design. If the 8086 did not mix stack with code and data we would not have had so many problems today.
Or VMS which from what I heard is still being used by banks and such despite the fact that it was such a perverse OS and that TCP/IP was an optional package. Did that thing have any bugs at all !?
I would just like to point out that the filesystem is a particular case of specialized database so this whole debate fs versus db does not make much sense. Some of its implementations may suck, but it's still a database that has a well-known, familiar interface (access mechanism). One can build a file store using a filesystem and replace it with a database-backed "file system" later if need be.
And we should also keep in mind that while some databases do give killer performance, you have to pay a lot for it, while the ol' filesystem comes with the OS already.
Now, for any other use than filesystem-related stuff, it does not make sense to try to invent your own small-scale storage mechanism when there are so many good, cheap/free database servers out there well-suited for the job.
The PC's architecture does not lend itself too well to multiple CPUs. In particular, the CPUs do not have their own separate memory partitions so they will keep fighting over the same bandwidth and I/O space, thrashing the main cache in the process. While I believe the performance in a dual system is pretty close to a single CPU at twice the speed (because the single CPU has the context-switching overhead too), it gets only worse from there. I would not be surprised if for some application you'll only get a 300% performance increase from a for 4-way machine.
At any rate, database servers are very disk-intensive anyway. They are all about organizing data on disks to retrieve it in the least amounts of block reads, but they can't control where the data actually goes on the physical disk. Most of the time it's the disks and I/O bandwidth that are the bottleneck. I would get a good RAID device with gobs of memory (independent of the main system's) connected to fast SCSI disks in a striped configuration. I would also get as much system memory as I can to allow disk caching.
Another possibility is to use distributed access instead of a parallel system. Set up a replicated database where you can send the requests to any of the machines. I think this will get you the best performance improvement over any n-way system if you are doing lots of short queries and few writes (the times where this won't work so well is when your program consists of heavy, resource intensive single queries that take long to answer).
You are the sad reason that laws are so complicated. If people actually had common sense and consideration for others things would be very different. Just because something isn't explicitly outlawed does not mean it is ethical to do it.
Apparently Australian and New Zealand legislation already makes it illegal for companies to restrict the parallel importation of their products, and the Australian Competition and Consumer Commission is poised to take action against DVD regionalisation. So if other places, including Europe, follow the lead, Steve Ballmer could find himself threatening to stop selling Xbox virtually everywhere...
Slashdot Mirror
Try FreeDOS (www.freedos.org) or DR-DOS (www.drdos.net). They are drop-in (more or less) replacements for MS-DOS.
A few years ago I bought this nice $100 answering machine that right now is collecting dust somewhere, because I disconnected it after I found I was getting 6-7 messages A DAY, wasting tape and my time to listen to each one of them.
This goes for my home line too - I pay for it only because I need a "home phone" but the phone is always off and I use the cell exclusively for my incoming calls.
This situation is ridiculous.
That system will also block the failed-delivery messages from MTAs so you will never know when that happens.
Most people on /. would buy SCSI if IDE would cost as much as SCSI.
For the last series, I have not noticed any unexpected filesystem errors after 200-300 days of uptime (they need to be rebooted from time to time for kernel upgrades).
To conclude, always suspect your hardware first, especially if it's at least a couple years old.
We have today a global information society and thus broadcasts from various parts of the world will (or, at least, should) be available in other parts as well. This is illustrated by the fact that finally a lot of TVs sold today work with all three major standards, but for a long time they didn't. This makes the issue of standardization more important than it was in the past where the broadcasts were mostly local. I'd rather have them to it right this time.
Multiple standards are a ploy by manufacturers and broadcasters to control market share (the same way DVD region-coding works) and for their local patent owners to get their royalties.
It is generally accepted (read "taught in schools") that there are four states of matter, no ifs and buts. Therefore, the statement "as we all know there are three" is not quite correct.
1) Today applications DON'T take seconds to start. In fact, the bloat in software has kept the pace with advances in hardware, thus making the software today take the same resources (percentage-wise) as the one yesterday. Netscape, Photoshop, Real player, any application not deeply embedded in Windows take forever to start requiring all those nifty "accelerators" ran at login time that use up real memory trying to cope with this problem. Even if it didn't, so long as computers have limited resources (and hardware manufacturers will make sure the prices are never so low for us to afford plenty of ).
2) Same goes for documents. Saving documents in Word, images in Photoshop is never blazingly fast. Let alone that file versioning a la VMS fills the disk space quite quickly and would require an interface to "clean up" the unnecessary revisions lying around.
By the way, Word does by default do incremental saves which a lot of us here seemed to like so much; I hope we still remember the events concerning inadvertent release of information through documents published on the web that were saved using this mechanism. Besides, all the points made about me choosing when to save are valid - I really want to have the choice of when to write my changes.
3) Inodes - just by mentioning that the author proves he has no idea what he is talking about. Unix has had this for a long time - there are hard links which use inodes and there are symbolic links which just point to the path. So Unix offers both, care to check which type is most commonly used ?
For one, hard links are not portable across filesystems (partitions). Also, deleting a hard linked file does not actually release the disk space until all links have been removed. This can cause some serious confusion to the head of the Windows user. Hard links are difficult to back up and restore properly.
Want more ? When an application saves a file it usually creates a new file, writes the data then moves it over the original file (to avoid data loss due to write errors). Guess what happens to the inode number.
As we all know, there are actually four states of matter: solid, liquid, gaseous and plasma.
I am curious whether the said patents apply to previous SOAP versions as well.
or VOIPIP (voice over IP over IP tunnel)
really ? explain DMCA :)
I seriously doubt this. I never heard SCSI was sensitive to cable lengths (within spec of course). The data goes in a buffer anyway, it's not like it's written to the media on the fly.
You are missing all the bugs that might be in the code still running as uid 0. Your daemons, the kernel, all of them are vulnerable. I haven't seen many exploits that actually get root by doing "su" to it, so "disabling" that account will not achieve more than, for example, a good password.
A "secure" OS in this context means an OS with well-known "clean", stable code that has been reviewed for flaws etc etc. There isn't much you can do from an administration point of view if the services/daemons you have to use are flawed.
I think sprinkling setuids around is not a great idea at all. Especially custom-written ones. Beautiful things can happen accidentally linking against the wrong library in a chrooted dir :)
Chroot is *not* 100% secure. It is not a sandbox. You can still access ports, memory and processes and kernel functions, you can talk to daemons, starve the system of resources or convince the parent process to do things it will regret.
Plus if you chroot users you'd still have to give them most of the OS somewhere unless they login to not do any work, and that will soon get boring when you'll have to upgrade all of it.
A truly secure machine requires hardware support. A better CPU design. If the 8086 did not mix stack with code and data we would not have had so many problems today.
Or VMS which from what I heard is still being used by banks and such despite the fact that it was such a perverse OS and that TCP/IP was an optional package. Did that thing have any bugs at all !?
I would just like to point out that the filesystem is a particular case of specialized database so this whole debate fs versus db does not make much sense. Some of its implementations may suck, but it's still a database that has a well-known, familiar interface (access mechanism). One can build a file store using a filesystem and replace it with a database-backed "file system" later if need be.
And we should also keep in mind that while some databases do give killer performance, you have to pay a lot for it, while the ol' filesystem comes with the OS already.
Now, for any other use than filesystem-related stuff, it does not make sense to try to invent your own small-scale storage mechanism when there are so many good, cheap/free database servers out there well-suited for the job.
The PC's architecture does not lend itself too well to multiple CPUs. In particular, the CPUs do not have their own separate memory partitions so they will keep fighting over the same bandwidth and I/O space, thrashing the main cache in the process. While I believe the performance in a dual system is pretty close to a single CPU at twice the speed (because the single CPU has the context-switching overhead too), it gets only worse from there. I would not be surprised if for some application you'll only get a 300% performance increase from a for 4-way machine.
At any rate, database servers are very disk-intensive anyway. They are all about organizing data on disks to retrieve it in the least amounts of block reads, but they can't control where the data actually goes on the physical disk. Most of the time it's the disks and I/O bandwidth that are the bottleneck. I would get a good RAID device with gobs of memory (independent of the main system's) connected to fast SCSI disks in a striped configuration. I would also get as much system memory as I can to allow disk caching.
Another possibility is to use distributed access instead of a parallel system. Set up a replicated database where you can send the requests to any of the machines. I think this will get you the best performance improvement over any n-way system if you are doing lots of short queries and few writes (the times where this won't work so well is when your program consists of heavy, resource intensive single queries that take long to answer).
You are the sad reason that laws are so complicated. If people actually had common sense and consideration for others things would be very different. Just because something isn't explicitly outlawed does not mean it is ethical to do it.
Actually, no. You do not have "public performance" rights when you buy the DVD, you need a special license for that.