This is only really a question in the Microsoft world. In the Unix world it's old hat. Possibilities:
Have a central fileserver with all your software on it, have all the workstations mount that central store to a known location and add the appropriate directories to the PATH (or use them as the target of desktop menus and links). Then all you have to do is update the central server and all workstations automatically see the updates. Extra points for the small scripts to insure that each workstation is logged out and the central server unmounted before the update and that everything's remounted after the update.
Remember that in Unix the console is just another terminal. Have a script that ssh's out to each workstation in turn and performs the update on the workstation
Remember that in X11 the local display is no different from a remote display. ssh out to each workstation, run the GUI installer and install the update on each workstation from the comfort of your desk. Then write a nastygram to your software vendor asking why they insist on a manual GUI for installation and why can't they provide a nice scriptable installer?
Set up a cron job on each workstation that will poll a central server for updates at regular intervals and update any packages found. Your workstation distribution probably includes an update utility (eg. up2date, rpm --freshen, apt-get and so on).
There is a better way. Get reliable SMTP server software (there are several), keep up-to-date on security patches, follow best practices for securing your systems and restrict access to only what's needed. In fact, segregate your mail servers so seperate machines handle incoming mail from the world, that way you can monitor the machines the crackers can reach more thoroughly. Internally, use e-mail clients and browsers that have the best records for not being susceptible to attack. If anyone gripes, point to the cost of dealing with infestations and tell them that dollars decide, deal.
Also, monitor both your outgoing mail and your own network for suspicious activity or evidence of infestation. If you spot a problem, shut the offending machine down stat and keep it off the network until it's been cleaned up. If the same person keeps getting infected repeatedly, revoke their network privileges. If they can't learn after several lessons, they'll just have to accept the consequences.
When a blacklist does contact you about a problem, don't stall and don't deny. If you knew about the problem already, simply tell them what the problem was and what steps you took to deal with it. If you didn't know about the problem, acknowledge the report and give them a time you expect to have it investigated. Then investigate it and send a followup within the timeframe you gave telling them what you found and what you did about it. For the big blacklists, this is all you'll need to do to stay off them. And the people who run them do have memories. If you've a history of good behavior and cleaning up the mess ASAP, they'll be more inclined to cut you slack if a truly major problem occurs because they know it'll be dealt with. By the same token, if you've a history of not acknowledging problems and letting them persist, they'll cut you no slack at all.
If there's a person on your network actually causing problems repeatedly, present the situation to management in dollars: kicking that person will cost $X, keeping them will cost $Y, Y is far greater than X. Management should be receptive to hard numbers that affect the bottom line, and once the problem person's gone that's one less headache and one less reason for you to wind up on a blacklist.
I'd say you're right, comments are more important. Clearly-written code should make how it's doing things obvious, yes. Comments, though, should say what is being done and why it's being done the way it is.
No, I'm thinking in desktop terms. Always on doesn't matter, the standard logic in Unix systems is to read the hardware clock early in the boot process, then force a sync to the time servers later just before (or as part of) starting the time-sync daemon. As long as there's a time-server accessible, the standard logic will keep your time correct without you having to set it manually whether you leave the machine on all the time or shut it down every day when you're done. Though frankly on a Unix system there's no reason to shut it down. Just enable power-saving features and let the hardware power down when you're not using it. My experience is that that nets you 90-95% of the power savings you'd get from turning the power completely off and reduces the wear and tear on the hardware by an order of magnitude.
Just because a user wants to do something doesn't mean they should be allowed to do it. Look at the state of the Windows world, most of it comes from the insistence on letting users do whatever they want regardless of whether it's a good idea or not. We don't let people drive cars without knowing how to drive first, regardless of how much they might want to drive or how important it might be for them to be allowed to drive. I fail to see why the logic for computers should be different.
There is. The owner of the domain is the only one who knows what the TTL should be. For example, they're the only ones who know how stable the IP address of a server will be which directly impacts what the TTL should be. They're the only ones who know that they'll be doing a network renumbering next week and that TTLs should thus be shortened in preparation for propagating the changes promptly.
The problem is that domain owners applied other criteria than correct DNS operation when setting TTLs. TTLs of 10 seconds aren't sane. Neither are TTLs measured in months. Myself, I'd handle this by capping TTLs, not overriding them. I'd put a bottom limit of 1 hour on the TTL, and a top limit of 1 day to 1 week (depending on record type), on the records. If a record's TTL was within those sanity limits, it'd remain unaltered.
Actually, changing the date should require an explicit password entry. Think about it. On a Unix system, most often the system date's maintained by the NTP daemon or something similar. If everything's working right, the date's always correct automatically. If you're trying to change it, either you're doing something very very strange or you have a problem with the system daemons. Either way, you should probably be thinking about why you're doing what you're doing before you do it. In all likelihood you should be fixing the underlying problem instead of trying to patch around a symptom. And if you need an incorrect date for some reason, you should be very very careful about why you want it since system-wide date changes can have lots of nasty consequences you weren't thinking about (viruses and trojans here are the least of your worries).
When someone mentions "ease of use", I feel a need to point out that it's probably a bad idea to make it easier for a burglar to break into your home or an arsonist to burn it down. "Ease of use" should only be considered after "having a system to use" has been considered.
Yes, it does. If the rest of the system, particularly the system programs like your backup and restore utilities, is still intact you can quickly recover your deleted home directory from your backups. You did keep backups, right?
Also, viruses and trojans will tend not to be able to infect your system, since the programs on the system the malware could infest to spread further will tend to be installed as part of the system and not be owned or writable by you.
Just because a system only has one user doesn't make it a single-user system.
The advertisers would surely like us to accept the "social contract" mentioned in the article. The problem is, based on behavior the vast majority of net users don't agree with the advertisers. A contract, social or otherwise, is an agreement, so if the parties don't agree there is no contract. How much the advertisers pretend otherwise doesn't change that.
Also, the advertisers seem to try and confuse a couple of concepts. Yes, the Web site and the advertiser has the right to show ads. But that's a far different thing from the right to force me, a user visiting the site, to watch those ads. Same as television: the station has the right to show commercials, but they don't have the right to chain me to my chair and force me to watch them instead of, say, going to the bathroom or to get a drink. The advertisers may not like this, but that's Not My Problem.
The advertisers might consider this: while I go to great lengths to block lots of ads, I don't mind the ads on Google. In fact I find myself using them quite often. Those ads don't get in the way of the search results and don't try to confuse me about what's advertisement and what isn't, and they're for the most part relevant to what I was searching for. If I'm not looking to buy something I'm not going to check them out, but if I am already looking for a product I find the Google ads worthwhile. Advertisers might want to consider this when thinking about ever more intrusive and distruptive advertising.
Consider the changing nature of the people they face in patent fights. Traditionally, thier opponents in a patent fight were other companies that made things. IBM could pull out their patent portfolio, show the other guys how much trouble they'd be in if this turned into dueling infringements, and negotiate an acceptable cross-licensing deal without having to pay any money.
Today, the other guy in a patent fight's likely to be a company whose only product is patent litigation. They don't make any real products, so they can't infringe on any of IBM's patents. IBM now doesn't have any leverage to negotiate a deal, it's pay up or go to court and hope you can overturn the patents. So, IBM's accepting that patents are now more of a threat to their revenues than they are a revenue source.
Part of the problem is that the NT permissions model, while incredibly powerful and flexible, is massive overkill for most users and purposes. It's so complex that your average user just can't make it work right, and even the experts have to think about exactly how to get the result they want. And in the end, most of that power ends up wasted because what's actually needed often falls into a very limited set:
The owner's permissions vs. the permissions everybody else has.
Accesses allowed:
For ordinary files: read, write and execute (important for telling which things are supposed to be programs and which aren't).
For directories: access a known element, alter elements (add or delete files, basically), search elements (list all files even if you don't know their names).
At the network level, you sometimes need to be able to say that remote users of shares (or remote users other than the actual owner) should be limited to read-only access.
The NT permissions model makes it too hard to get those fairly simple cases right, so it ends up not being used at all. And what good's a powerful, flexible permissions system if nobody uses it?
Windows already has seperate registry and file areas for system-wide and per-user data. In the registry there are seperate keys for system and user configuration. There's also seperate "All Users" and individual user local settings directories in the Documents&Settings area. Software simply needs to check permissions and use the appropriate areas:
If the user doesn't have administrative privileges, install registry entries and settings only in the per-user areas. Software will only be usable by the user that installed it.
If the user has admin privs (or if the installer is run with admin privs), ask the user whether they want to install for all users or only themselves. If they want to install for all users, put system-wide settings into the system-wide areas. The application should create appropriate per-user settings based on the system-wide settings the first time it's run by a user.
If the app absolutely must be system-wide (eg. part of it's a driver, or it's a program that has to start at start-up before any user's logged in), then either the user needs admin privileges or the installer needs to run with admin privileges. Only the minimum should be installed system-wide, this shouldn't be used as a loophole to continue the current bad practices.
This is pretty much the model Unix follows for software installation.
Cheap shot: if Microsoft is such a great, innovative company, why's it taken them 20 years to catch up to 30-year-old software in this area?:)
I think you make a fundamental mistake. Correctly identifying the sources of spam isn't a goal of the RBLs. Their first goal is to get spam stopped. Correctly identifying the source is the first step to that goal, but never make the mistake of assuming the first step is the goal. When playing whack-a-mole, trying to hit just the mole tends not to be very productive, so when it become apparent from the ISP's behavior that it's going to become that the RBLs take another option: get a bigger hammer and hit the entire board at one shot. Doesn't matter which hole the mole (spammer) was in, he's now flat.
Also, financially damaging the companies that host or support spammers isn't a goal. It's again one step in the process of getting spam stopped. If the only thing those companies pay attention to is dollars, then you make your case in dollars in a way they can feel directly.
My mail provider's a local ISP in Utah, not one of the big boys, yet their system blocks approximately two hundred thousand spam attempts a day. Spam would occupy 80% of their incoming e-mail bandwidth if they didn't block it. I for one find expecting ISPs to buy 500% of neccesary bandwidth an unacceptable demand.
And quite frankly, every time I've heard someone griping, it turns out in the end that either a) they were the ones spamming or b) their provider had been informed, knew full well what was happening, and had stalled on doing anything about it for months before the boom was finally lowered. When it comes to people being blocked because they're on the same networks as spammers, I'm afraid my attitude has become "A failure to do due diligence on your part doesn't constitute an emergency on my part.". I wasn't this way when Canter and Siegel started it, but better than a decade of watching spammers get more and more obnoxious while continuing to whine the same whine as C&S has pretty much wiped out my supply of patience.
Re:The False Positive/True Positive Ratio
on
Should You Trust MAPS?
·
· Score: 2, Informative
Your point is correct. It's also the reason MAPS expands blocked netblocks. If they only block the specific IPs that originated the spam, unscrupulous ISPs merely move the spammers to different IPs and let them continue. Note that this isn't a theoretical statement, it's observed behavior. If an ISP does that, MAPS responds by expanding the block to include more and more of the ISP's assigned addresses, until (if the ISP doesn't get the hint first) the ISP has no unblocked address space left.
Yes, non-spammers get affected. That's the point. The recipients of the spam are the ones being damaged, but since they aren't paying customers of the ISP hosting the spammer that ISP has no reason to do anything about their complaints. Once non-spamming customers start being affected, though, they start complaining. Now the ISP's facing real financial impact: if they don't do something about the spammer, they may begin losing customers.
ISPs don't like this, it makes them have to choose whether they want the spammers' money or their legitimate customers. They'd much rather have both. As a recipient of spam, I've no sympathy for their plight at all.
Based on the decisions handed down by the arbitrating bodies, even expressing an interest in selling if they ask first can give the other party the opening to take the domain away from you on cybersquatting grounds. The only safe response is (assuming you really are using the domain for something legitimate) "Sorry, I've no interest in selling.".
Let me rephrase your comment: "Ordinary users shouldn't be allowed to hot-rod their cars, but installing a turbocharger and nitrous system and upgrading the brakes and installing a sports suspension shouldn't be considered hot-rodding.". You can't mess around with the basic building blocks of the system (drivers, system-wide installed programs, etc.) without exactly the risks that you don't want users to have to take.
You can create a bullet-proof (from the user's POV) OS, but to do it you have to prevent the user from installing drivers, arbitrary software, etc.. That isn't an OS-design issue, it's a fundamental principle: you can't give someone power without giving them power. Failure to grasp this simple concept, applicable to every aspect of human society, is why Windows is such a mess right now.
The only problem is that you've given two mutually exclusive conditions. The design of the OS is irrelevant, you can't give the user complete control over the system and at the same time keep them from using that control to hurt themselves. Trying is like trying to give someone the ability to drive as fast as they like in a car while still protecting them from driving too fast into that turn, losing it and splattering themselves all over the landscape. The only way to protect them is to prevent them from driving faster than is safe, and that directly conflicts with letting them drive as fast as they want.
I think a better solution is to start dividing users into categories. Let's face it, when it comes to cars we don't expect Aunt May who's never gone over 25mph in her life to be able to drive the same kinds of cars a Formula One driver could. Similarly, why should a secretary who needs only to answer e-mail, write letters and deal with a few spreadsheets, and a software developer who needs to compile new programs and dig around at the lowest levels of the system to debug software that didn't even exist last week, be expected to be using the exact same kinds of systems with the exact same capabilities?
Actually most open-source projects do have traceability. Most of them use CVS for source-code version control, and CVS lets you trace back any piece of code to the user who commited that piece of code. That person is responsible for what they commited, and probably knows the original source of the code if they didn't write it themselves.
And frankly, I think the ubiquity of version control in open-source projects is one of the reasons you don't see lawsuits about IP infringement against those projects. The plaintiff would have to claim, as part of any suit, that the code in the FOSS project infringed his IP. Now, in the case of patents for example, prior art invalidates a patent. Proving prior art, though, tends to be hard because the patent-holder can claim that some minor difference makes his work different from yours. But if he's the one claiming in the lawsuit that your work is equivalent to his and hence infringes, he can't slip out of the way of your prior-art claim without abandoning his own infringement claim. Then all you have to do is prove that your work preceeded his filing for a patent, which version control makes easy.
I think the question isn't whether IE uses any undocumented system calls, it's whether the system uses any IE-provided functions that are a) not part of the documented IBrowser interface and other relevant APIs (Javascript, etc.) and b) are actually neccesary (that is you can't do that via documented functions (eg. one doesn't need ActiveX to provide a clickable-image next-page icon in HTML, one can do that via the IMG and A tags and maybe a bit of Javascript)). An admission that it doesn't would be an admission that one should be able to remove IE and replace it with something else without affecting the rest of the system at all. Likewise, an admission that there are undocumented IE functions neccesary for system function would be an admission of abusive tying.
Well, what Word should do, according to the Microsoft developer documentation everybody else is supposed to read and follow, is use COM to request an object implementing the Media Player interface, and then make calls on that object to play media. As long as the underlying provider implements the complete interface as documented, the calling application isn't supposed to have to care exactly what the underlying provider is. This is, again according to Microsoft, exactly what COM is supposed to be for: allowing applications to use an interface without worrying about who's providing the implementation of that interface.
Obviously if I don't have anything implementing the Media Player COM interface installed applications will fail trying to get an instance of that interface, but if I install say RealPlayer that correctly implements the documented Media Player COM interface then applications trying to play media should succeed (modulo supported codecs) and the media should play without problems.
If COM (in it's latest naming) is good enough for Microsoft to tell the rest of the world to use it for this purpose, why isn't it good enough for Microsoft to use it as well?
If they're openly renting it to me, the way the local video store makes no bones about the fact that they're renting me a DVD for a limited time, then I'll accept DRM (provided that the DRM system works on my computers and doesn't impose itself on parts of the system not being used to view that particular content). If they want to have the transaction look and feel like a sale, then they're selling me a copy just like a bookstore sells me a copy of a book and, once the sale's completed, the seller and/or copyright owner should have no more control over that copy than they do the copy of the book I bought.
And it wouldn't even be hard. All that'd be needed is an even-handed rule: an ISP can tag any kind of traffic they want any way they want, but they have to tag all of any particular kind of traffic the same way. If they want to give VoIP traffic priority over other traffic, they have to give all VoIP traffic on their network the same priority. Giving some (theirs) priority and others (the competition's) not would be a regulatory violation.
No, on Unix fork() creates a new process that, usually temporarily, shares a (usually copy-on-write) memory space, file descriptors and other things with it's parent. Threads are created via the pthread_create() call (or thr_create() on Solaris).
Now underneath, some popular OSes implement threads as full processes which happen to share a page table and system resources with their parent process, but you still don't create them with fork().
How about the counter-question: "Did you use all available means to insure legally mandated data was preserved as required?". This question would come up when someone outside the company used Trusted Computing to restrict access to information too much, eg. to prevent saving of it when the company was legally required to keep copies. Or how about when something happens to the one machine that's got access to the data and Trusted Computing won't let you access it on another computer because you no longer have the appropriate keys? Or when the one critical application upon which your entire business depends is declared obsolete by the vendor, it's signature revoked and none of your hardware will run it anymore? (If you think this last isn't going to happen, I have three words for you: Visual Basic 6.)
The check goes beyond programs. The idea is that during boot the BIOS/hardware checks the signature on the OS being booted, and will refuse to boot any unsigned OS.
As for RedHat being able to get their software signed, that's fine for RedHat. Now, I go and recompile the kernel on my RedHat system to include IPSec software like OpenSWAN. My new kernel's no longer signed. How do I get it to boot?
Slashdot Mirror
This is only really a question in the Microsoft world. In the Unix world it's old hat. Possibilities:
There is a better way. Get reliable SMTP server software (there are several), keep up-to-date on security patches, follow best practices for securing your systems and restrict access to only what's needed. In fact, segregate your mail servers so seperate machines handle incoming mail from the world, that way you can monitor the machines the crackers can reach more thoroughly. Internally, use e-mail clients and browsers that have the best records for not being susceptible to attack. If anyone gripes, point to the cost of dealing with infestations and tell them that dollars decide, deal.
Also, monitor both your outgoing mail and your own network for suspicious activity or evidence of infestation. If you spot a problem, shut the offending machine down stat and keep it off the network until it's been cleaned up. If the same person keeps getting infected repeatedly, revoke their network privileges. If they can't learn after several lessons, they'll just have to accept the consequences.
When a blacklist does contact you about a problem, don't stall and don't deny. If you knew about the problem already, simply tell them what the problem was and what steps you took to deal with it. If you didn't know about the problem, acknowledge the report and give them a time you expect to have it investigated. Then investigate it and send a followup within the timeframe you gave telling them what you found and what you did about it. For the big blacklists, this is all you'll need to do to stay off them. And the people who run them do have memories. If you've a history of good behavior and cleaning up the mess ASAP, they'll be more inclined to cut you slack if a truly major problem occurs because they know it'll be dealt with. By the same token, if you've a history of not acknowledging problems and letting them persist, they'll cut you no slack at all.
If there's a person on your network actually causing problems repeatedly, present the situation to management in dollars: kicking that person will cost $X, keeping them will cost $Y, Y is far greater than X. Management should be receptive to hard numbers that affect the bottom line, and once the problem person's gone that's one less headache and one less reason for you to wind up on a blacklist.
I'd say you're right, comments are more important. Clearly-written code should make how it's doing things obvious, yes. Comments, though, should say what is being done and why it's being done the way it is.
No, I'm thinking in desktop terms. Always on doesn't matter, the standard logic in Unix systems is to read the hardware clock early in the boot process, then force a sync to the time servers later just before (or as part of) starting the time-sync daemon. As long as there's a time-server accessible, the standard logic will keep your time correct without you having to set it manually whether you leave the machine on all the time or shut it down every day when you're done. Though frankly on a Unix system there's no reason to shut it down. Just enable power-saving features and let the hardware power down when you're not using it. My experience is that that nets you 90-95% of the power savings you'd get from turning the power completely off and reduces the wear and tear on the hardware by an order of magnitude.
Just because a user wants to do something doesn't mean they should be allowed to do it. Look at the state of the Windows world, most of it comes from the insistence on letting users do whatever they want regardless of whether it's a good idea or not. We don't let people drive cars without knowing how to drive first, regardless of how much they might want to drive or how important it might be for them to be allowed to drive. I fail to see why the logic for computers should be different.
There is. The owner of the domain is the only one who knows what the TTL should be. For example, they're the only ones who know how stable the IP address of a server will be which directly impacts what the TTL should be. They're the only ones who know that they'll be doing a network renumbering next week and that TTLs should thus be shortened in preparation for propagating the changes promptly.
The problem is that domain owners applied other criteria than correct DNS operation when setting TTLs. TTLs of 10 seconds aren't sane. Neither are TTLs measured in months. Myself, I'd handle this by capping TTLs, not overriding them. I'd put a bottom limit of 1 hour on the TTL, and a top limit of 1 day to 1 week (depending on record type), on the records. If a record's TTL was within those sanity limits, it'd remain unaltered.
Actually, changing the date should require an explicit password entry. Think about it. On a Unix system, most often the system date's maintained by the NTP daemon or something similar. If everything's working right, the date's always correct automatically. If you're trying to change it, either you're doing something very very strange or you have a problem with the system daemons. Either way, you should probably be thinking about why you're doing what you're doing before you do it. In all likelihood you should be fixing the underlying problem instead of trying to patch around a symptom. And if you need an incorrect date for some reason, you should be very very careful about why you want it since system-wide date changes can have lots of nasty consequences you weren't thinking about (viruses and trojans here are the least of your worries).
When someone mentions "ease of use", I feel a need to point out that it's probably a bad idea to make it easier for a burglar to break into your home or an arsonist to burn it down. "Ease of use" should only be considered after "having a system to use" has been considered.
Yes, it does. If the rest of the system, particularly the system programs like your backup and restore utilities, is still intact you can quickly recover your deleted home directory from your backups. You did keep backups, right?
Also, viruses and trojans will tend not to be able to infect your system, since the programs on the system the malware could infest to spread further will tend to be installed as part of the system and not be owned or writable by you.
Just because a system only has one user doesn't make it a single-user system.
The advertisers would surely like us to accept the "social contract" mentioned in the article. The problem is, based on behavior the vast majority of net users don't agree with the advertisers. A contract, social or otherwise, is an agreement, so if the parties don't agree there is no contract. How much the advertisers pretend otherwise doesn't change that.
Also, the advertisers seem to try and confuse a couple of concepts. Yes, the Web site and the advertiser has the right to show ads. But that's a far different thing from the right to force me, a user visiting the site, to watch those ads. Same as television: the station has the right to show commercials, but they don't have the right to chain me to my chair and force me to watch them instead of, say, going to the bathroom or to get a drink. The advertisers may not like this, but that's Not My Problem.
The advertisers might consider this: while I go to great lengths to block lots of ads, I don't mind the ads on Google. In fact I find myself using them quite often. Those ads don't get in the way of the search results and don't try to confuse me about what's advertisement and what isn't, and they're for the most part relevant to what I was searching for. If I'm not looking to buy something I'm not going to check them out, but if I am already looking for a product I find the Google ads worthwhile. Advertisers might want to consider this when thinking about ever more intrusive and distruptive advertising.
Fast sanity check: if Windows is such a superior platform for servers, why is Windows having such a hard time making it into the server room? :)
Consider the changing nature of the people they face in patent fights. Traditionally, thier opponents in a patent fight were other companies that made things. IBM could pull out their patent portfolio, show the other guys how much trouble they'd be in if this turned into dueling infringements, and negotiate an acceptable cross-licensing deal without having to pay any money.
Today, the other guy in a patent fight's likely to be a company whose only product is patent litigation. They don't make any real products, so they can't infringe on any of IBM's patents. IBM now doesn't have any leverage to negotiate a deal, it's pay up or go to court and hope you can overturn the patents. So, IBM's accepting that patents are now more of a threat to their revenues than they are a revenue source.
Part of the problem is that the NT permissions model, while incredibly powerful and flexible, is massive overkill for most users and purposes. It's so complex that your average user just can't make it work right, and even the experts have to think about exactly how to get the result they want. And in the end, most of that power ends up wasted because what's actually needed often falls into a very limited set:
- The owner's permissions vs. the permissions everybody else has.
- Accesses allowed:
- For ordinary files: read, write and execute (important for telling which things are supposed to be programs and which aren't).
- For directories: access a known element, alter elements (add or delete files, basically), search elements (list all files even if you don't know their names).
- At the network level, you sometimes need to be able to say that remote users of shares (or remote users other than the actual owner) should be limited to read-only access.
The NT permissions model makes it too hard to get those fairly simple cases right, so it ends up not being used at all. And what good's a powerful, flexible permissions system if nobody uses it?Windows already has seperate registry and file areas for system-wide and per-user data. In the registry there are seperate keys for system and user configuration. There's also seperate "All Users" and individual user local settings directories in the Documents&Settings area. Software simply needs to check permissions and use the appropriate areas:
- If the user doesn't have administrative privileges, install registry entries and settings only in the per-user areas. Software will only be usable by the user that installed it.
- If the user has admin privs (or if the installer is run with admin privs), ask the user whether they want to install for all users or only themselves. If they want to install for all users, put system-wide settings into the system-wide areas. The application should create appropriate per-user settings based on the system-wide settings the first time it's run by a user.
- If the app absolutely must be system-wide (eg. part of it's a driver, or it's a program that has to start at start-up before any user's logged in), then either the user needs admin privileges or the installer needs to run with admin privileges. Only the minimum should be installed system-wide, this shouldn't be used as a loophole to continue the current bad practices.
This is pretty much the model Unix follows for software installation.Cheap shot: if Microsoft is such a great, innovative company, why's it taken them 20 years to catch up to 30-year-old software in this area? :)
I think you make a fundamental mistake. Correctly identifying the sources of spam isn't a goal of the RBLs. Their first goal is to get spam stopped. Correctly identifying the source is the first step to that goal, but never make the mistake of assuming the first step is the goal. When playing whack-a-mole, trying to hit just the mole tends not to be very productive, so when it become apparent from the ISP's behavior that it's going to become that the RBLs take another option: get a bigger hammer and hit the entire board at one shot. Doesn't matter which hole the mole (spammer) was in, he's now flat.
Also, financially damaging the companies that host or support spammers isn't a goal. It's again one step in the process of getting spam stopped. If the only thing those companies pay attention to is dollars, then you make your case in dollars in a way they can feel directly.
My mail provider's a local ISP in Utah, not one of the big boys, yet their system blocks approximately two hundred thousand spam attempts a day. Spam would occupy 80% of their incoming e-mail bandwidth if they didn't block it. I for one find expecting ISPs to buy 500% of neccesary bandwidth an unacceptable demand.
And quite frankly, every time I've heard someone griping, it turns out in the end that either a) they were the ones spamming or b) their provider had been informed, knew full well what was happening, and had stalled on doing anything about it for months before the boom was finally lowered. When it comes to people being blocked because they're on the same networks as spammers, I'm afraid my attitude has become "A failure to do due diligence on your part doesn't constitute an emergency on my part.". I wasn't this way when Canter and Siegel started it, but better than a decade of watching spammers get more and more obnoxious while continuing to whine the same whine as C&S has pretty much wiped out my supply of patience.
Your point is correct. It's also the reason MAPS expands blocked netblocks. If they only block the specific IPs that originated the spam, unscrupulous ISPs merely move the spammers to different IPs and let them continue. Note that this isn't a theoretical statement, it's observed behavior. If an ISP does that, MAPS responds by expanding the block to include more and more of the ISP's assigned addresses, until (if the ISP doesn't get the hint first) the ISP has no unblocked address space left.
Yes, non-spammers get affected. That's the point. The recipients of the spam are the ones being damaged, but since they aren't paying customers of the ISP hosting the spammer that ISP has no reason to do anything about their complaints. Once non-spamming customers start being affected, though, they start complaining. Now the ISP's facing real financial impact: if they don't do something about the spammer, they may begin losing customers.
ISPs don't like this, it makes them have to choose whether they want the spammers' money or their legitimate customers. They'd much rather have both. As a recipient of spam, I've no sympathy for their plight at all.
Based on the decisions handed down by the arbitrating bodies, even expressing an interest in selling if they ask first can give the other party the opening to take the domain away from you on cybersquatting grounds. The only safe response is (assuming you really are using the domain for something legitimate) "Sorry, I've no interest in selling.".
Let me rephrase your comment: "Ordinary users shouldn't be allowed to hot-rod their cars, but installing a turbocharger and nitrous system and upgrading the brakes and installing a sports suspension shouldn't be considered hot-rodding.". You can't mess around with the basic building blocks of the system (drivers, system-wide installed programs, etc.) without exactly the risks that you don't want users to have to take.
You can create a bullet-proof (from the user's POV) OS, but to do it you have to prevent the user from installing drivers, arbitrary software, etc.. That isn't an OS-design issue, it's a fundamental principle: you can't give someone power without giving them power. Failure to grasp this simple concept, applicable to every aspect of human society, is why Windows is such a mess right now.
The only problem is that you've given two mutually exclusive conditions. The design of the OS is irrelevant, you can't give the user complete control over the system and at the same time keep them from using that control to hurt themselves. Trying is like trying to give someone the ability to drive as fast as they like in a car while still protecting them from driving too fast into that turn, losing it and splattering themselves all over the landscape. The only way to protect them is to prevent them from driving faster than is safe, and that directly conflicts with letting them drive as fast as they want.
I think a better solution is to start dividing users into categories. Let's face it, when it comes to cars we don't expect Aunt May who's never gone over 25mph in her life to be able to drive the same kinds of cars a Formula One driver could. Similarly, why should a secretary who needs only to answer e-mail, write letters and deal with a few spreadsheets, and a software developer who needs to compile new programs and dig around at the lowest levels of the system to debug software that didn't even exist last week, be expected to be using the exact same kinds of systems with the exact same capabilities?
Actually most open-source projects do have traceability. Most of them use CVS for source-code version control, and CVS lets you trace back any piece of code to the user who commited that piece of code. That person is responsible for what they commited, and probably knows the original source of the code if they didn't write it themselves.
And frankly, I think the ubiquity of version control in open-source projects is one of the reasons you don't see lawsuits about IP infringement against those projects. The plaintiff would have to claim, as part of any suit, that the code in the FOSS project infringed his IP. Now, in the case of patents for example, prior art invalidates a patent. Proving prior art, though, tends to be hard because the patent-holder can claim that some minor difference makes his work different from yours. But if he's the one claiming in the lawsuit that your work is equivalent to his and hence infringes, he can't slip out of the way of your prior-art claim without abandoning his own infringement claim. Then all you have to do is prove that your work preceeded his filing for a patent, which version control makes easy.
I think the question isn't whether IE uses any undocumented system calls, it's whether the system uses any IE-provided functions that are a) not part of the documented IBrowser interface and other relevant APIs (Javascript, etc.) and b) are actually neccesary (that is you can't do that via documented functions (eg. one doesn't need ActiveX to provide a clickable-image next-page icon in HTML, one can do that via the IMG and A tags and maybe a bit of Javascript)). An admission that it doesn't would be an admission that one should be able to remove IE and replace it with something else without affecting the rest of the system at all. Likewise, an admission that there are undocumented IE functions neccesary for system function would be an admission of abusive tying.
Well, what Word should do, according to the Microsoft developer documentation everybody else is supposed to read and follow, is use COM to request an object implementing the Media Player interface, and then make calls on that object to play media. As long as the underlying provider implements the complete interface as documented, the calling application isn't supposed to have to care exactly what the underlying provider is. This is, again according to Microsoft, exactly what COM is supposed to be for: allowing applications to use an interface without worrying about who's providing the implementation of that interface.
Obviously if I don't have anything implementing the Media Player COM interface installed applications will fail trying to get an instance of that interface, but if I install say RealPlayer that correctly implements the documented Media Player COM interface then applications trying to play media should succeed (modulo supported codecs) and the media should play without problems.
If COM (in it's latest naming) is good enough for Microsoft to tell the rest of the world to use it for this purpose, why isn't it good enough for Microsoft to use it as well?
If they're openly renting it to me, the way the local video store makes no bones about the fact that they're renting me a DVD for a limited time, then I'll accept DRM (provided that the DRM system works on my computers and doesn't impose itself on parts of the system not being used to view that particular content). If they want to have the transaction look and feel like a sale, then they're selling me a copy just like a bookstore sells me a copy of a book and, once the sale's completed, the seller and/or copyright owner should have no more control over that copy than they do the copy of the book I bought.
And it wouldn't even be hard. All that'd be needed is an even-handed rule: an ISP can tag any kind of traffic they want any way they want, but they have to tag all of any particular kind of traffic the same way. If they want to give VoIP traffic priority over other traffic, they have to give all VoIP traffic on their network the same priority. Giving some (theirs) priority and others (the competition's) not would be a regulatory violation.
No, on Unix fork() creates a new process that, usually temporarily, shares a (usually copy-on-write) memory space, file descriptors and other things with it's parent. Threads are created via the pthread_create() call (or thr_create() on Solaris).
Now underneath, some popular OSes implement threads as full processes which happen to share a page table and system resources with their parent process, but you still don't create them with fork().
How about the counter-question: "Did you use all available means to insure legally mandated data was preserved as required?". This question would come up when someone outside the company used Trusted Computing to restrict access to information too much, eg. to prevent saving of it when the company was legally required to keep copies. Or how about when something happens to the one machine that's got access to the data and Trusted Computing won't let you access it on another computer because you no longer have the appropriate keys? Or when the one critical application upon which your entire business depends is declared obsolete by the vendor, it's signature revoked and none of your hardware will run it anymore? (If you think this last isn't going to happen, I have three words for you: Visual Basic 6.)
The check goes beyond programs. The idea is that during boot the BIOS/hardware checks the signature on the OS being booted, and will refuse to boot any unsigned OS.
As for RedHat being able to get their software signed, that's fine for RedHat. Now, I go and recompile the kernel on my RedHat system to include IPSec software like OpenSWAN. My new kernel's no longer signed. How do I get it to boot?