This isnt an RTFM attitude, this is a 'use the GUI filemanager' attitude. The filemanager is there to be friendly and to help newbies. The filemanager will put things in the trashcan. There is nothing stopping anyone from adding a friendly (and most distributions have it) alias for rm either, for the shell newbies.
But unlink(2) and rm need to do what they're meant to do or there's no end to the things you break. Applications and scripts that create loads of temporary files can fill up a filesystem in minutes or even seconds if unlink and rm suddenly arent 'really really really _delete_ this' anymore.
There are solutions to this. Use them.
Re:So everyone is perfect?
on
Undelete In Linux
·
· Score: 4, Insightful
Because a lot of us _mean_ rm when we type rm. Otherwise we would have used mv. Or used Nautilus or some other filemanager that by default puts stuff in the trashcan.
rm means 'remove'. Not 'move to trash'. Think of it as the 'empty trashcan' command. Would you like a trashcan that moves things to yet another trashcan when you empty it?
If you're uncertain about wether or not to remove something dont use rm. You're entirely free to rm/bin/rm if you dont want to use it. Or even mv/bin/rm/tmp if you're uncertain about wether or not to remove it permanently.
And if you, despite knowing that rm means 'remove', make a mistake, just restore from your backups.
You _have_ to compile with GCC. If you're writing C++ code at least. Or you wont be able to link with any C++ libraries. Doesnt seem like the C++ abi is going to get standardized ever, does it.
I have the money to spend, but what I dont have is the time to dink around trying to get whatever code to compile with whatever compiler to link with whatever library. Either it works with everything compiled in GCC out of the box or it's a useless pain in the rear.
That's why you put a picture of the iris you want to fake in front of your own eye. The machine will scan the temperature on your eye and accept the iris from the picture. Worked like a charm for c't I believe it was who tested it.
Anyone saying biometrics by itself is secure is a liar and trying to defraud you into paying loads of money for a worthless easily tricked system.
At least a live guard ought to be able to tell wether you're holding a picture of someone else in front of your face or not while he's checking your passport.
Anyone who has any trouble installing a Java VM, C++/C/ObjC/Python at home should not be taking CS or EE.
Perhaps you've missed it, but CS and EE curriculums are not generally meant to teach students specific industry related languages. As they aim to teach students programming concepts they often teach languages that are rarely used outside of university, but are conceptually clear.
Wether or not C# will be suitable remains to be seen.
You mean, we request that the majority of weirdos who choose to ever upgrade their web-browser or OS stop doing that at once. Maybe we should forbid any further development of browsers too at the same time?
Badly written websites dont merely fail on non-standard browsers, they also often fail on every new release of IE or Netscape.
But, *if* you code to standard, then it should work with every browser, and it should work with every new release, and if it doesnt, it's the browsers fault, not yours, and you can tell whatever minority of upgraders or weird-browsers to go whine at their vendor instead.
Why would I need to IPC a file descriptor? The FD's get passed to the child on fork. And if you have an application working on common data, you have one process reading the data and creating the shared segment, and you get a clean interface to the shared data.
I'm sure you can figure out some situation where you have to pass FD's around, but I'm not saying that you should never use threads. I'm saying you shouldnt use them unless you absolutely have to, and I wonder why apache absolutely had to.
And, _I_ dont think binary modules are better. Some of our vendors, however, appear to think so, which means _I_ get stuck with having to compile apache with the specific compiler used for the binary c++ module just because c++ _STILL_ doesnt have a stable ABI.
This is true, of course, altho I regard that as a misfeature of Solaris, and even worse HP-UX. In my experience OS's that actually reserve space fail terminally when they get into an OOM situation _anyway_, usually requireing a reboot to recover full functionality. And guaranteeing the availability of allocated memory will make that happen much much faster.
Avoiding overcommitting seems like a good idea until the day you realize that half the programmers of the world havent checked the return value of malloc() since it was invented, and the rest cant figure out a way to degrade gracefully when OOM anyway (usually because there just isnt one).
For any webserver that regularly has 1000 people hit the site, having 1000+ processes is not uncommon or strange in any way.
Threads do not reduce memory usage. Any OS with a not-completely-braindead vm implementation shares any common memory between forked processes. It does not get copied until it's actually written to, which usually doesnt happen to code.
Processes blocking on IO is also a non-issue; you fork more processes to handle new requests. The overhead is minimal. Especially compared to the application logic guaranteeing thread safety on the database connection.
Threaded programs make no difference compared to forked programs in a multiprocessor environment. Threading only improves performance in SMP if you for some reason absolutely cannot fork (for example, a kernel).
Threading has been vastly overrated. It makes sense to use it in java since the language supports it, even as it may be more or less pointless, but in C it should be avoided unless you cannot get around it.
Like you say, threads dont really significantly impact performance (nor do I think it improves scalability beyond a process model), but threads do impact stability and reliability due to the increased difficulty of writing thread safe code.
Apache is mainly used on UN*X. Modules, both free and proprietary are usually available for UN*X. Those proprietary modules that exist on both Windows and UN*X usually exist for IIS on Windows and probably not for apache on Windows. If you're going to switch from IIS to apache it makes little sense not to switch to Linux or Solaris at the same time.
So for most users the gain in performance is insignificant, the potential loss of stability may be immensly irritating and the target groups on NT are either likely to not switch to apache for other reasons than performance and if they want to switch could easily switch completely to the group which gains little from the threading.
No, IPC isnt faster, nor is forking faster in any way. The problem with threading comes from the fact that everything you do (and everything you depend on) has to be threadsafe. You have to add mutexes for anything that could be concurrently accessed from different threads, and the slightest mistake (which is easy to make) can lead to data corruption and/or crashes, and a threaded application is more difficult to debug. Programmers are human, and threading is more difficult to design and implement right.
The advantage of processes (using IPC for communications if you need it) is that the code becomes simpler and you have a very well defined interface for the shared data.
Threading inherently violates Keep It Simple.
A threaded apache may very well be 'better' in some ways, but it will be more difficult to maintain and while it might not crash more often, more time will have to be spent ensuring that it remains of the same quality as a process based apache.
You're not forking a 15MB process for every concurrent connection. You're creating a PID for every concurrent connection; process memory with regards to fork under most UNIX systems is _copy_on_write_, which means it isnt getting copied until such a time as it is actually written to. There's no real gain in memory.
So. Why did they add threading at all? What were the advantages, apart from making the code more complicated and prone to breakage, breaking module interfaces and making modules more difficult to write and making it less portable?
Threading in general is a really really bad idea unless you absolutely need it. Stick with a process model, with IPC if needed, unless you're one of those poor sods who absolutely has to have threading.
In fact, the only engineering idea that could be worse for Apache would be to include C++ code... can you say 'unresolved symbol in xxxxx'? You'd never find two binary-only modules that could be loaded into the same server. I do so love trying to figure out exactly which version of which compiler I have to compile Apache with to link it to the proprietary modules we, unfortunately, have.
The funny thing is that it would be so easy for the RIAA corps to add more value. The only value they have to add is legitimacy, availability and merchandising.
If they could cobble together a site where pretty much any and all material people were interested in was available, on a legitimate basis, with lyrics, CD covers, previews, and a reasonable (50c-$1) price per track, easy payment and encoding available in ogg/mp3 in various bitrates, I'd buy it in a second.
Who cares if you can copy it? If I can get what I want faster and easier off a pay-per (permanent, reasonably priced) download site, I'd love to use it.
Either the RIAA corps will eventually figure that out, or some artists whose contracts expire will get together and do it for themselves, cutting the RIAA out of the loop.
... why do you really care? If you're getting the service you need, why bother? If you're satisfied with the current bandwidth and ping times through your T1, why buy something more expensive even if it is faster/less congested/has blinkity blinky florbs?
All reasonably priced providers will sell you shared capacity. And overselling is (usually) a question of what the other customers are doing and at what point your upwards link is going to get upgraded. You'll never get full bandwidth connectivity to the providers peering point for yourself unless you're willing to pay through the nose.
But do you really need that or are you satisfied? If you're satisfied, spending more is a waste of money, wether or not your current provider is using IP over avian carrier to connect you.
The Congress shall have power... to promote the progress of science and useful arts, by securing for limited times to authors and inventors the exclusive right to their respective writings and discoveries;
The original intent of patents and copyright was about fostering innovation.
Not that the corruption of the idea we have today is about that tho.
MP3 is trivial. It does not deserve a patent. The evidence that MP3 is trivial is all around; since the development (and before) of it, there have been several other formats developed that solve the same problem.
Patents were meant to promote the development of new inventions for the benefit of humankind. Since the development of this or similar technology would have been accomplished and has been accomplished without patents, there is no benefit for humanity in granting a patent for such trivial technology. That the USPTO and other patent offices are incompetent enough that they cant tell a patent worthy invention from what it would take 5 monkeys five hours to make up (or at least what it would take 5 people experienced in the field five hours to make up) is really beside the point.
An automated sourcebased install might end up looking like... a source RPM (or ports, or various other automated source installs). There's nothing stopping you from rebuilding many of the RPM's from source, which wont even break your package management system. rpm --rebuild is your friend:)
A) The DOJ doesnt 'rule'. B) The court ruled they did break the law, and C) The appeals court ruled they did break the law. Read the finding of facts.
The only thing in question was the punishment and that was mostly because the Microsoft representatives behaved so much like juvenile delinquents in court that judge Jackson eventually broke and exploded in the media in a not entirely acceptable way. Judges arent allowed to get irritated in public. After being subjected to several months of MS representatives lying and whining in his courtroom I can underand why tho.
Patents are not laws. And with patents it doesnt matter wether or not you've read them; without being a patent lawyer you are not regarded as being competent to decide wether or not you're infringing, so reading them is rather pointless anyway.
Ignorance of the law is not a defense, but in the case of patents you have no choice. You can either stop developing software, or you can try to ascertain wether or not something you invented violates a patent (which you cant legally ascertain anyway so you just end up with a willful violation instead) which ends up worse than pointless or you can ignore the issue and hope you dont get legal action your way.
It's annoying, but it's a pretty solid and very common practice for anyone involved in software development. Dont Look At The Patents.
Patents have become such a complete minefield that if you spent time researching software patents while programming you might just as well quit the buisness. You cant develop anything beyond 'hello world' without risking running afoul of software patents. They're overly broad, they have decades of prior art, they're trivial and should never have been awarded in the first place, but they're there. And it will cost to get them overturned.
What it comes down to is that basically you have three choices. Either you dont know about them, or you know about them and violate them or you quit developing software.
And out of those choices not knowing about them is the least painful and/or dangerous one.
Because a second box running firewalling cant be turned off by the outlook virus of the day, or by a trojan, or any of the multitude of other ways a local firewall can be bypassed.
Slashdot Mirror
This isnt an RTFM attitude, this is a 'use the GUI filemanager' attitude. The filemanager is there to be friendly and to help newbies. The filemanager will put things in the trashcan. There is nothing stopping anyone from adding a friendly (and most distributions have it) alias for rm either, for the shell newbies.
But unlink(2) and rm need to do what they're meant to do or there's no end to the things you break. Applications and scripts that create loads of temporary files can fill up a filesystem in minutes or even seconds if unlink and rm suddenly arent 'really really really _delete_ this' anymore.
There are solutions to this. Use them.
Because a lot of us _mean_ rm when we type rm. Otherwise we would have used mv. Or used Nautilus or some other filemanager that by default puts stuff in the trashcan.
/bin/rm if you dont want to use it. Or even mv /bin/rm /tmp if you're uncertain about wether or not to remove it permanently.
rm means 'remove'. Not 'move to trash'. Think of it as the 'empty trashcan' command. Would you like a trashcan that moves things to yet another trashcan when you empty it?
If you're uncertain about wether or not to remove something dont use rm. You're entirely free to rm
And if you, despite knowing that rm means 'remove', make a mistake, just restore from your backups.
You _have_ to compile with GCC. If you're writing C++ code at least. Or you wont be able to link with any C++ libraries. Doesnt seem like the C++ abi is going to get standardized ever, does it.
I have the money to spend, but what I dont have is the time to dink around trying to get whatever code to compile with whatever compiler to link with whatever library. Either it works with everything compiled in GCC out of the box or it's a useless pain in the rear.
With PAE you still cant use more than 3GB per process. And, unfortunately, it's not too uncommon that you need more than 3GB.
That's why you put a picture of the iris you want to fake in front of your own eye. The machine will scan the temperature on your eye and accept the iris from the picture. Worked like a charm for c't I believe it was who tested it.
Anyone saying biometrics by itself is secure is a liar and trying to defraud you into paying loads of money for a worthless easily tricked system.
At least a live guard ought to be able to tell wether you're holding a picture of someone else in front of your face or not while he's checking your passport.
Um, most sysadmins I know have spent the last 10-20 years trying to automate away their jobs.
It doesnt appear to reduce the amount of work tho. You get a lot of automated jobs getting done, but the inbasket keeps growing anyway.
Anyone who has any trouble installing a Java VM, C++/C/ObjC/Python at home should not be taking CS or EE.
Perhaps you've missed it, but CS and EE curriculums are not generally meant to teach students specific industry related languages. As they aim to teach students programming concepts they often teach languages that are rarely used outside of university, but are conceptually clear.
Wether or not C# will be suitable remains to be seen.
You mean, we request that the majority of weirdos who choose to ever upgrade their web-browser or OS stop doing that at once. Maybe we should forbid any further development of browsers too at the same time?
Badly written websites dont merely fail on non-standard browsers, they also often fail on every new release of IE or Netscape.
But, *if* you code to standard, then it should work with every browser, and it should work with every new release, and if it doesnt, it's the browsers fault, not yours, and you can tell whatever minority of upgraders or weird-browsers to go whine at their vendor instead.
www.vignette.com
Why would I need to IPC a file descriptor? The FD's get passed to the child on fork. And if you have an application working on common data, you have one process reading the data and creating the shared segment, and you get a clean interface to the shared data.
I'm sure you can figure out some situation where you have to pass FD's around, but I'm not saying that you should never use threads. I'm saying you shouldnt use them unless you absolutely have to, and I wonder why apache absolutely had to.
And, _I_ dont think binary modules are better. Some of our vendors, however, appear to think so, which means _I_ get stuck with having to compile apache with the specific compiler used for the binary c++ module just because c++ _STILL_ doesnt have a stable ABI.
This is true, of course, altho I regard that as a misfeature of Solaris, and even worse HP-UX. In my experience OS's that actually reserve space fail terminally when they get into an OOM situation _anyway_, usually requireing a reboot to recover full functionality. And guaranteeing the availability of allocated memory will make that happen much much faster.
Avoiding overcommitting seems like a good idea until the day you realize that half the programmers of the world havent checked the return value of malloc() since it was invented, and the rest cant figure out a way to degrade gracefully when OOM anyway (usually because there just isnt one).
Oh, well, at least disk space is cheap nowadays.
For any webserver that regularly has 1000 people hit the site, having 1000+ processes is not uncommon or strange in any way.
Threads do not reduce memory usage. Any OS with a not-completely-braindead vm implementation shares any common memory between forked processes. It does not get copied until it's actually written to, which usually doesnt happen to code.
Processes blocking on IO is also a non-issue; you fork more processes to handle new requests. The overhead is minimal. Especially compared to the application logic guaranteeing thread safety on the database connection.
Threaded programs make no difference compared to forked programs in a multiprocessor environment. Threading only improves performance in SMP if you for some reason absolutely cannot fork (for example, a kernel).
Threading has been vastly overrated. It makes sense to use it in java since the language supports it, even as it may be more or less pointless, but in C it should be avoided unless you cannot get around it.
Like you say, threads dont really significantly impact performance (nor do I think it improves scalability beyond a process model), but threads do impact stability and reliability due to the increased difficulty of writing thread safe code.
Apache is mainly used on UN*X. Modules, both free and proprietary are usually available for UN*X. Those proprietary modules that exist on both Windows and UN*X usually exist for IIS on Windows and probably not for apache on Windows. If you're going to switch from IIS to apache it makes little sense not to switch to Linux or Solaris at the same time.
So for most users the gain in performance is insignificant, the potential loss of stability may be immensly irritating and the target groups on NT are either likely to not switch to apache for other reasons than performance and if they want to switch could easily switch completely to the group which gains little from the threading.
No, IPC isnt faster, nor is forking faster in any way. The problem with threading comes from the fact that everything you do (and everything you depend on) has to be threadsafe. You have to add mutexes for anything that could be concurrently accessed from different threads, and the slightest mistake (which is easy to make) can lead to data corruption and/or crashes, and a threaded application is more difficult to debug. Programmers are human, and threading is more difficult to design and implement right.
The advantage of processes (using IPC for communications if you need it) is that the code becomes simpler and you have a very well defined interface for the shared data.
Threading inherently violates Keep It Simple.
A threaded apache may very well be 'better' in some ways, but it will be more difficult to maintain and while it might not crash more often, more time will have to be spent ensuring that it remains of the same quality as a process based apache.
You're not forking a 15MB process for every concurrent connection. You're creating a PID for every concurrent connection; process memory with regards to fork under most UNIX systems is _copy_on_write_, which means it isnt getting copied until such a time as it is actually written to. There's no real gain in memory.
So. Why did they add threading at all? What were the advantages, apart from making the code more complicated and prone to breakage, breaking module interfaces and making modules more difficult to write and making it less portable?
Threading in general is a really really bad idea unless you absolutely need it. Stick with a process model, with IPC if needed, unless you're one of those poor sods who absolutely has to have threading.
In fact, the only engineering idea that could be worse for Apache would be to include C++ code... can you say 'unresolved symbol in xxxxx'? You'd never find two binary-only modules that could be loaded into the same server. I do so love trying to figure out exactly which version of which compiler I have to compile Apache with to link it to the proprietary modules we, unfortunately, have.
The funny thing is that it would be so easy for the RIAA corps to add more value. The only value they have to add is legitimacy, availability and merchandising.
If they could cobble together a site where pretty much any and all material people were interested in was available, on a legitimate basis, with lyrics, CD covers, previews, and a reasonable (50c-$1) price per track, easy payment and encoding available in ogg/mp3 in various bitrates, I'd buy it in a second.
Who cares if you can copy it? If I can get what I want faster and easier off a pay-per (permanent, reasonably priced) download site, I'd love to use it.
Either the RIAA corps will eventually figure that out, or some artists whose contracts expire will get together and do it for themselves, cutting the RIAA out of the loop.
... why do you really care? If you're getting the service you need, why bother? If you're satisfied with the current bandwidth and ping times through your T1, why buy something more expensive even if it is faster/less congested/has blinkity blinky florbs?
All reasonably priced providers will sell you shared capacity. And overselling is (usually) a question of what the other customers are doing and at what point your upwards link is going to get upgraded. You'll never get full bandwidth connectivity to the providers peering point for yourself unless you're willing to pay through the nose.
But do you really need that or are you satisfied? If you're satisfied, spending more is a waste of money, wether or not your current provider is using IP over avian carrier to connect you.
From the US constitution:
... to promote the progress of science and useful arts, by securing for limited times to authors and inventors the exclusive right to their respective writings and discoveries;
The Congress shall have power
The original intent of patents and copyright was about fostering innovation.
Not that the corruption of the idea we have today is about that tho.
MP3 is trivial. It does not deserve a patent. The evidence that MP3 is trivial is all around; since the development (and before) of it, there have been several other formats developed that solve the same problem.
Patents were meant to promote the development of new inventions for the benefit of humankind. Since the development of this or similar technology would have been accomplished and has been accomplished without patents, there is no benefit for humanity in granting a patent for such trivial technology. That the USPTO and other patent offices are incompetent enough that they cant tell a patent worthy invention from what it would take 5 monkeys five hours to make up (or at least what it would take 5 people experienced in the field five hours to make up) is really beside the point.
An automated sourcebased install might end up looking like... a source RPM (or ports, or various other automated source installs). There's nothing stopping you from rebuilding many of the RPM's from source, which wont even break your package management system. rpm --rebuild is your friend :)
A) The DOJ doesnt 'rule'. B) The court ruled they did break the law, and C) The appeals court ruled they did break the law. Read the finding of facts.
The only thing in question was the punishment and that was mostly because the Microsoft representatives behaved so much like juvenile delinquents in court that judge Jackson eventually broke and exploded in the media in a not entirely acceptable way. Judges arent allowed to get irritated in public. After being subjected to several months of MS representatives lying and whining in his courtroom I can underand why tho.
Patents are not laws. And with patents it doesnt matter wether or not you've read them; without being a patent lawyer you are not regarded as being competent to decide wether or not you're infringing, so reading them is rather pointless anyway.
Ignorance of the law is not a defense, but in the case of patents you have no choice. You can either stop developing software, or you can try to ascertain wether or not something you invented violates a patent (which you cant legally ascertain anyway so you just end up with a willful violation instead) which ends up worse than pointless or you can ignore the issue and hope you dont get legal action your way.
It's annoying, but it's a pretty solid and very common practice for anyone involved in software development. Dont Look At The Patents.
Patents have become such a complete minefield that if you spent time researching software patents while programming you might just as well quit the buisness. You cant develop anything beyond 'hello world' without risking running afoul of software patents. They're overly broad, they have decades of prior art, they're trivial and should never have been awarded in the first place, but they're there. And it will cost to get them overturned.
What it comes down to is that basically you have three choices. Either you dont know about them, or you know about them and violate them or you quit developing software.
And out of those choices not knowing about them is the least painful and/or dangerous one.
Because a second box running firewalling cant be turned off by the outlook virus of the day, or by a trojan, or any of the multitude of other ways a local firewall can be bypassed.