I absolutely agree. From a global perspective, Microsoft is very wrong for not allowing all systems to receive the most important security updates.
But from Microsoft's business perspective, it is in their best interest to give just anybody updates, as doing so would suck away even more bandwidth. It also devalues the purchasing of valid licenses: "I can get all the updates with my pirated copy? Why the hell should I buy a copy then?"
[WARNING: M$-bashing in 3... 2... 1...] The only reason anybody even thinks about security now is because of how terrible Microsoft's implementation (or lack thereof) has been so far. People seem to believe that viruses are just a part of owning a computer. They think that Microsoft Office is the only word processing system there is, and all the ones I've seen that received a non-Microsoft document (like "*.odf") figured that the file was corrupt if they couldn't open it in Word.
I could sit and rant all day to just about any born-and-raised Microsoft user that there are other OS's out there that are free of viruses (not to mention free of cost), and they just won't care, because they can't even differentiate between the operating system and the software. Running 20 different programs on their computer just to get 80% of the viruses removed is commonplace, even if they have to pay a lot of money for several of them.
"Your Windows XP workstation got formatted because you were infected with a virus? Well, we got this fancy-dancy Windows 7 here for ya, for only $300. Come this way, and I'll show you all the hardware you're going to need to make your computer run..." [20 minutes later] "... or you could just spend $2000 on this brand new system that already has it."
IMHO, Microsoft doesn't give a damn about its users. Pirates are pirates. Even granny down the street that managed to reinstall Windows XP using some (perfectly valid, unused) key she got from her neighbor. MS doesn't care about the economy either, as long as they're getting paid.
Let's think about this not from a moral perspective, but from a business one. In all reality, it is better for Microsoft to ignore those with pirated copies of Windows and thereby allow botnets and viruses to flourish: they're "in bed" (or at least used to be) with anti-virus companies, and now they're making their own; what good is an anti-virus program if there isn't widespread infection? "Illegitimate" systems having high infection rates (and generally lowered performance) gives more validity to the idea that people should pay for a valid copy of Windows.
(I could add a great blurb here about switching to other systems that have only a tiny fraction of the vulnerabilities of Windows, but this isn't a Microsoft-bashing.)
Not only do some people enjoy the game, but some people also modify the game a bit to be more fun. For instance, my family plays using two boards joined at "Go". Twice the monopolies. We add a rule where the utilities are counted as transports ("Railroad Tycoon"), so a person with the entirety of transports on one board gets $800 instead of a measly $200. There's all kinds of other rules we add, like larger/more dice, which works very well on the double-board game.
Let's make an analogy to a real-world situation and I think you'll probably understand a bit better.
Just as an unknown security exploit has the potential to collapse a server, an engineering flaw can cause a building to collapse.
An engineer (think security expert) is underneath a building (this would be the server) making some checks for integrity (security). During this check, he discovers a very important beam has several bolts that appear to be coming out or have sheared off::: someone with malicious intentions could quickly and easily destroy the building; but it might also be possible for natural events (i.e. an earthquake) to cause it to topple as well. Realizing the situation is grave but not wanting to cause mass panic, he tells someone in charge about the situation. It is a very important problem to address, and there are a lot of complexities to deal with, so the engineer sits back and waits to hear something. After enough time goes by without any indication that something has been done to either temporarily or permanently fix the problem, the engineer tells the people in the building about it, causing a bit of mass panic, but quickly prompting those in charge to get the problem fixed.
But let's say the engineer decides NOT to announce it publicly. Sure, people in the building go about their business as though nothing is wrong, and the threat of a malicious person hearing of the problem is avoided. What happens when a natural event causes the building to collapse? Or when a "terrorist" finds the problem and exploits it? All the people in the building--if they survived--would be fuming mad about a problem that was known but not dealt with. Now instead of having "the people in charge" mad at him, the people that were affected are mad.
If you didn't catch the moral, here it is. Announcing the problem to the world will piss off the vendor, but will ultimately result in either a fix from them or some other form of mitigation from those that are affected and/or have the means to stop it. Ignoring the situation only gives the illusion of stability... the illusion that there isn't a problem, or that unspoken problems will never be exploited. Hmm.. there's lots of illusions in "ignore" scenario...
The problem with the "grab whatever if it's temporary" is that temporary solutions oftentimes become more permanent than anything. I have had many experiences where fixing a problem in the server room exposes some "temporary" fix from years ago that I never had time to make permanent (and since it worked, nobody thought twice about the problem it had fixed).
Or when developing web applications, somebody implements that "quick function" that does X, intended only for internal stuff. Another feature comes along, and pretty soon we're using that temporary function as the core of a new system... and sometimes it even gets embedded into the core of the system. But remember, it was only temporary.
At one point at a previous job, I was tasked with putting all of our projects into our project management software and prioritize. I built a tree structure with parent projects and sub-projects, where the furthest-out projects needed to be completed before the parent project could be done (so the root projects were easy to understand for the PHB, and we could deal with the smaller bits). Each level was prioritized based on the level, so I could tell what piece should be completed first (I worked that part out with the other developers so we all understood what it all meant, along with figuring out some of the lower-level priorities and building best-guess timelines).
After a week of prioritizing, arranging, and setting timelines, I brought it to the PHB. I explained the logic of the thing and how much I'd worked with the other developers in order to get it organized as such. He gave me a blank stare, asking why there were so many sub-projects and why he couldn't find the project he was looking for, etc. I explained the organizational logic, and he just gave me that blank, glazed-eye stares and then excused me.
The next morning I was called into his office, where he showed me (with a huge smile on his face) how he'd rearranged everything. There were no trees (projects with sub-projects) that explained dependencies. The timelines were changed to what he wanted them to be, causing 10-12 projects to overlap on very tight timeframes. EVERYTHING was a project (the sub-projects that were dependencies of parents were suddenly their own projects with incredibly low priority). Only the projects he was interested were prioritized, and there were dozens of projects set with the highest priority.
The funniest thing? Some time later we had a meeting where he told us adamantly that we should only EVER have ONE priority 1 (highest priority) item and that we shouldn't work on anything else until that priority 1 project was done. *sigh*
If there is no documentation, the answer to the question, "Is it ready?" is "No." It's likely that the PHB doesn't know enough about what you're doing to...
Sometimes PHB's just don't understand simple logic. Telling them you either need more time or they will have to deal with poorly tested and completely undocumented code doesn't sink in.
I had an employer (thankfully I was smart enough to get away from there) that took away our profit-sharing, holding it as "incentive" for the programmers to build this new feature quickly. Being the leader, I was forced to try reasoning with him.
I told him that we needed 4 more months than he was giving us, and that taking away our profit sharing and calling it "incentive" or saying that it is a "bonus" is BS (keep in mind, we'd had this for many years and were originally told that it would never be taken away). He smiled and offered two extra months, but that the money would still be held.
I pleaded with him, explaining that one of the devs just bought a house with his wife and that he would lose the house if he had to go that long without the money (these checks were literally 30-50% of our monthly income), but he wouldn't budge. "Fine, we'll push hard and get it done in your timeline, but there's probably going to be a metric ton of bugs to deal with because we won't have time to do much error-checking." His response? "Just get it done on time. And don't let there be any bugs."
The moral of the story: Some PHB's just don't care: "Documentation? I'm the PHB, I don't care." "Error checking? Don't waste your time. Oh, and don't allow any errors."
Forgive me, but it seems that you are simply arguing semantics:
searching: to inquire, investigate, examine, or seek; conduct an examination or investigation
theory: a proposed explanation whose status is still conjectural, in contrast to well-established propositions that are regarded as reporting matters of actual fact.
experiment:a test, trial, or tentative procedure; an act or operation for the purpose of discovering something unknown or of testing a principle, supposition, etc.
The existence of this particle is still theory and conjecture. Until there is empirical/verifiable evidence to support it's existence, there is no proof that it exists. There are many things that were thought to not exist that do throughout history (i.e. germs), and vice-versa.
The point to all this is still the same: one can definitively say something exists once it is discovered. Definitively saying it does not exist is infinitely more difficult to prove (as with the existence of aliens: it is a much better bet to propose they exist instead of saying they do not; we cannot even adequately explore planets in our own solar system let alone others to narrow the odds).
The problem with searching for something that only theoretically exists is that it is profoundly easier to prove that something exists (by finding it) versus proving that it does not exist ("we've done a lot of searching without result, but we cannot conclusively say this [x] does not exist"). If they find it, yay search is over. If they don't... well, they'll probably just keep looking until they rip a hole in the space/time continuum or create a blackhole that rips the Earth from existence... I'd rather them find it as not.
If turbidostato supposedly created a "new derogatory term for closed source software", what was it? I don't understand why there are such flame wars for open source vs. closed source software.
If Microsoft Word were (as a predominant example) an open source application, doesn't it stand to reason that more of the bugs would have been found and squashed? It also stands to reason that a piece of software with such a massive following would invariably become a much better product with hundreds or thousands (more) of talented programmers working to add features and such. The other beauty of it is that there generally seem to be just as many people testing changes to the code as there are coders, so bugs would be found faster and features would be solidified quicker.
So what's with the flame wars? I don't understand why so many people seem to think closed source software is so awesome. It seems to me the problem isn't with whether it's closed or open sourced, but rather the perception. I've talked to a few people who were very much attached to Microsoft products; when I mentioned anything about Linux or the software that runs on it, they got incredibly uptight for no good reason. They seemed to quickly grasp that "open source" mean NOT Microsoft, and quickly became terribly defensive about anything that went against them.
This is the "fanboy" concept to a tee. Listen for a minute to the concept instead of thinking we're somehow bashing this way of life that you want to cling to so much.
Sure, there's probably very little code in the Linux kernel from 15 years ago... but how much would we really want? Oh, and wait, Linux is built to run on i386 architecture, which I'm pretty sure was sometime prior to '95. Just my two cents.
YEAH! I mean, there's just NO WAY that all those service packs and updates for Windows have ANYTHING to do with your bandwidth congestion. Nor the downloaders that have to be downloaded for the real download to begin. Nor those browsers that fetch all the links from the current page so when you click on *one* of them it'll load fast. It couldn't have anything to do with all those anti-virus updates. Nothing at all to do with the 800G of files places download for their Redhat Satellite server. No way would anybody download 5G images of DVDs just to avoid that little 2-week delay. Nobody telecommutes, that's ridiculous. Oh, and those online "offsite backup" facilities that backup 300 workstations and 700 servers over the Internets, those don't take up much of your bandwidth. It is definitely those damned pirates.
Actually, the introduction of bugs isn't even dependent on new features bing added. Bugs could appear without anything about the software changing at all. Consider these conditions for bugs appearing:
A desktop app ("AppX") built for Windows:
* bugfix #33 applied to Windows that contains a bug or shoddy workaround (AppX releases a fix)
* bugfix #34 applied to Windows, fixing bug/shoddiness from #33 (AppX releases another fix)
* Service Pack #18 is applied to Windows, fundamentally changing a key part of the kernel (AppX releases another fix)
Web App ("Appx") built for PHP:
* Linux distro XYZ has odd kernel (AppX releases a fix)
* BSD doesn't work the same as Linux (AppX releases a fix)
* Linux distro X223 release kernel fix containing bug (AppX releases a fix)
Keep in mind that each fix generally has to do two-way compensation: apply to systems have the bug, don't apply to systems that don't have it.
Wait, you're not supposed to have your life insurance policy in your wallet at all times? Strange... that one guy I chatted with on the Internets said I should keep my social security card, 2 other forms of ID, all my credit cards, and a card with all my bank account numbers & PINs in my wallet just in case I died...
Okay, I see the humor in your post. But I must respond anyway, just because of the point you made about "knowing what is being trafficked across their tubes."
The privacy of Internet traffic should be held in the same regard as the privacy of US Mail. The mailman should only care about the contents if he can hear a ticking bomb inside; the only equivalent to this for the Internet would be something like a DOS attack against the ISP themselves. There is no reason for the mailman to inspect the information in the mail he's carrying, and there are even laws against it; the same should be true of the Internet.
Next, they'll sue backbone network providers. Because the use of this technology for doing legal things (like work) is statistically negligible. Once they get some guy in some important-sounding office to make a wild guess at a statistic for the amount of bandwidth used for legal vs. illegal activities, and that gets passed to somebody else that is more important, and that gets passed on to some news reporter that doesn't care so much about the verifiability of facts... wait a minute, that would never happen!
I think requiring the user to know the target accounts password--i.e. root--is more problematic. Sure, doing it that way means they have to know enough to be able to do it (the password)... but what happens when there's 20 people that need to do administrative actions? If the root password gets compromised, or one of them is a contractor, that password has to be changed for security reasons whenever somebody leaves: this creates the need to re-distribute the new password. And knowing the root password opens the possibility for them to bypass sudo and go directly for root.
On the other hand, as long as a password is *required*, if some user in the "wheel" group leaves, they can be removed from the group and their account disabled. The root password should be something that is very complex and stored in a secure place, for the sole purpose of needing to login to the physical machine as root.
Here's my preferred methodology:
1.) SSH Access
1.1.) users MUST use key-based authentication to login (passwords are insecure and can be retrieved through local key-loggers)
1.2.) access explicitly granted to users via the sshd_config file
1.3.) root access (via ssh) is explicitly DENIED.
2.) sudo access
2.1.) for users with godly power, add them to the wheel group for unlimited access (this is allowed for a very small group of people, usually one or two)
2.2.) users with specific needs get those via groups and group aliases in the sudoers file with access to a very explicit set of commands
2.3.) require user's password (avoids giving out root access; users many times will just bypass sudo and go straight to root)
3.) removing users
3.1.) removing key from "~/.ssh/authorized_keys"
3.2.) remove user from sshd_config file as an authorized user
3.3.) remove user from group
With #3, there's always the simplest option of just deleting their account (after backup), though the sshd_config should also be updated for cleanliness.
Yeah, because logging in as root is much more secure than sudo. I bet you were one of those that said using regular keys was much more efficient than RFID FOB/tags, right? (I mean, why reissue one key/FOB when you could just rekey all the doors and reissue all new keys?)
Slashdot Mirror
I absolutely agree. From a global perspective, Microsoft is very wrong for not allowing all systems to receive the most important security updates.
But from Microsoft's business perspective, it is in their best interest to give just anybody updates, as doing so would suck away even more bandwidth. It also devalues the purchasing of valid licenses: "I can get all the updates with my pirated copy? Why the hell should I buy a copy then?"
[WARNING: M$-bashing in 3... 2... 1...] The only reason anybody even thinks about security now is because of how terrible Microsoft's implementation (or lack thereof) has been so far. People seem to believe that viruses are just a part of owning a computer. They think that Microsoft Office is the only word processing system there is, and all the ones I've seen that received a non-Microsoft document (like "*.odf") figured that the file was corrupt if they couldn't open it in Word.
I could sit and rant all day to just about any born-and-raised Microsoft user that there are other OS's out there that are free of viruses (not to mention free of cost), and they just won't care, because they can't even differentiate between the operating system and the software. Running 20 different programs on their computer just to get 80% of the viruses removed is commonplace, even if they have to pay a lot of money for several of them.
"Your Windows XP workstation got formatted because you were infected with a virus? Well, we got this fancy-dancy Windows 7 here for ya, for only $300. Come this way, and I'll show you all the hardware you're going to need to make your computer run..." [20 minutes later] "... or you could just spend $2000 on this brand new system that already has it."
IMHO, Microsoft doesn't give a damn about its users. Pirates are pirates. Even granny down the street that managed to reinstall Windows XP using some (perfectly valid, unused) key she got from her neighbor. MS doesn't care about the economy either, as long as they're getting paid.
Let's think about this not from a moral perspective, but from a business one. In all reality, it is better for Microsoft to ignore those with pirated copies of Windows and thereby allow botnets and viruses to flourish: they're "in bed" (or at least used to be) with anti-virus companies, and now they're making their own; what good is an anti-virus program if there isn't widespread infection? "Illegitimate" systems having high infection rates (and generally lowered performance) gives more validity to the idea that people should pay for a valid copy of Windows.
(I could add a great blurb here about switching to other systems that have only a tiny fraction of the vulnerabilities of Windows, but this isn't a Microsoft-bashing.)
Not only do some people enjoy the game, but some people also modify the game a bit to be more fun. For instance, my family plays using two boards joined at "Go". Twice the monopolies. We add a rule where the utilities are counted as transports ("Railroad Tycoon"), so a person with the entirety of transports on one board gets $800 instead of a measly $200. There's all kinds of other rules we add, like larger/more dice, which works very well on the double-board game.
My IP address is 127.0.0.38.... wait, did you mean my REAL address? Okay, okay, its 127.0.0.1.
Here, let me fix that so Bigjeff5 can handle it:::
Do what Bill Gates and Steve Jobs did.
1: Create a huge tech company
2. ???
3. PROFIT!
Let's make an analogy to a real-world situation and I think you'll probably understand a bit better.
Just as an unknown security exploit has the potential to collapse a server, an engineering flaw can cause a building to collapse.
An engineer (think security expert) is underneath a building (this would be the server) making some checks for integrity (security). During this check, he discovers a very important beam has several bolts that appear to be coming out or have sheared off::: someone with malicious intentions could quickly and easily destroy the building; but it might also be possible for natural events (i.e. an earthquake) to cause it to topple as well. Realizing the situation is grave but not wanting to cause mass panic, he tells someone in charge about the situation. It is a very important problem to address, and there are a lot of complexities to deal with, so the engineer sits back and waits to hear something. After enough time goes by without any indication that something has been done to either temporarily or permanently fix the problem, the engineer tells the people in the building about it, causing a bit of mass panic, but quickly prompting those in charge to get the problem fixed.
But let's say the engineer decides NOT to announce it publicly. Sure, people in the building go about their business as though nothing is wrong, and the threat of a malicious person hearing of the problem is avoided. What happens when a natural event causes the building to collapse? Or when a "terrorist" finds the problem and exploits it? All the people in the building--if they survived--would be fuming mad about a problem that was known but not dealt with. Now instead of having "the people in charge" mad at him, the people that were affected are mad.
If you didn't catch the moral, here it is. Announcing the problem to the world will piss off the vendor, but will ultimately result in either a fix from them or some other form of mitigation from those that are affected and/or have the means to stop it. Ignoring the situation only gives the illusion of stability... the illusion that there isn't a problem, or that unspoken problems will never be exploited. Hmm.. there's lots of illusions in "ignore" scenario...
The problem with the "grab whatever if it's temporary" is that temporary solutions oftentimes become more permanent than anything. I have had many experiences where fixing a problem in the server room exposes some "temporary" fix from years ago that I never had time to make permanent (and since it worked, nobody thought twice about the problem it had fixed).
Or when developing web applications, somebody implements that "quick function" that does X, intended only for internal stuff. Another feature comes along, and pretty soon we're using that temporary function as the core of a new system... and sometimes it even gets embedded into the core of the system. But remember, it was only temporary.
I absolutely agree!
At one point at a previous job, I was tasked with putting all of our projects into our project management software and prioritize. I built a tree structure with parent projects and sub-projects, where the furthest-out projects needed to be completed before the parent project could be done (so the root projects were easy to understand for the PHB, and we could deal with the smaller bits). Each level was prioritized based on the level, so I could tell what piece should be completed first (I worked that part out with the other developers so we all understood what it all meant, along with figuring out some of the lower-level priorities and building best-guess timelines).
After a week of prioritizing, arranging, and setting timelines, I brought it to the PHB. I explained the logic of the thing and how much I'd worked with the other developers in order to get it organized as such. He gave me a blank stare, asking why there were so many sub-projects and why he couldn't find the project he was looking for, etc. I explained the organizational logic, and he just gave me that blank, glazed-eye stares and then excused me.
The next morning I was called into his office, where he showed me (with a huge smile on his face) how he'd rearranged everything. There were no trees (projects with sub-projects) that explained dependencies. The timelines were changed to what he wanted them to be, causing 10-12 projects to overlap on very tight timeframes. EVERYTHING was a project (the sub-projects that were dependencies of parents were suddenly their own projects with incredibly low priority). Only the projects he was interested were prioritized, and there were dozens of projects set with the highest priority.
The funniest thing? Some time later we had a meeting where he told us adamantly that we should only EVER have ONE priority 1 (highest priority) item and that we shouldn't work on anything else until that priority 1 project was done. *sigh*
If there is no documentation, the answer to the question, "Is it ready?" is "No." It's likely that the PHB doesn't know enough about what you're doing to...
Sometimes PHB's just don't understand simple logic. Telling them you either need more time or they will have to deal with poorly tested and completely undocumented code doesn't sink in.
I had an employer (thankfully I was smart enough to get away from there) that took away our profit-sharing, holding it as "incentive" for the programmers to build this new feature quickly. Being the leader, I was forced to try reasoning with him.
I told him that we needed 4 more months than he was giving us, and that taking away our profit sharing and calling it "incentive" or saying that it is a "bonus" is BS (keep in mind, we'd had this for many years and were originally told that it would never be taken away). He smiled and offered two extra months, but that the money would still be held.
I pleaded with him, explaining that one of the devs just bought a house with his wife and that he would lose the house if he had to go that long without the money (these checks were literally 30-50% of our monthly income), but he wouldn't budge. "Fine, we'll push hard and get it done in your timeline, but there's probably going to be a metric ton of bugs to deal with because we won't have time to do much error-checking." His response? "Just get it done on time. And don't let there be any bugs."
The moral of the story: Some PHB's just don't care: "Documentation? I'm the PHB, I don't care." "Error checking? Don't waste your time. Oh, and don't allow any errors."
Forgive me, but it seems that you are simply arguing semantics:
searching: to inquire, investigate, examine, or seek; conduct an examination or investigation
theory: a proposed explanation whose status is still conjectural, in contrast to well-established propositions that are regarded as reporting matters of actual fact.
experiment:a test, trial, or tentative procedure; an act or operation for the purpose of discovering something unknown or of testing a principle, supposition, etc.
The existence of this particle is still theory and conjecture. Until there is empirical/verifiable evidence to support it's existence, there is no proof that it exists. There are many things that were thought to not exist that do throughout history (i.e. germs), and vice-versa.
The point to all this is still the same: one can definitively say something exists once it is discovered. Definitively saying it does not exist is infinitely more difficult to prove (as with the existence of aliens: it is a much better bet to propose they exist instead of saying they do not; we cannot even adequately explore planets in our own solar system let alone others to narrow the odds).
The problem with searching for something that only theoretically exists is that it is profoundly easier to prove that something exists (by finding it) versus proving that it does not exist ("we've done a lot of searching without result, but we cannot conclusively say this [x] does not exist"). If they find it, yay search is over. If they don't... well, they'll probably just keep looking until they rip a hole in the space/time continuum or create a blackhole that rips the Earth from existence... I'd rather them find it as not.
If turbidostato supposedly created a "new derogatory term for closed source software", what was it? I don't understand why there are such flame wars for open source vs. closed source software.
If Microsoft Word were (as a predominant example) an open source application, doesn't it stand to reason that more of the bugs would have been found and squashed? It also stands to reason that a piece of software with such a massive following would invariably become a much better product with hundreds or thousands (more) of talented programmers working to add features and such. The other beauty of it is that there generally seem to be just as many people testing changes to the code as there are coders, so bugs would be found faster and features would be solidified quicker.
So what's with the flame wars? I don't understand why so many people seem to think closed source software is so awesome. It seems to me the problem isn't with whether it's closed or open sourced, but rather the perception. I've talked to a few people who were very much attached to Microsoft products; when I mentioned anything about Linux or the software that runs on it, they got incredibly uptight for no good reason. They seemed to quickly grasp that "open source" mean NOT Microsoft, and quickly became terribly defensive about anything that went against them.
This is the "fanboy" concept to a tee. Listen for a minute to the concept instead of thinking we're somehow bashing this way of life that you want to cling to so much.
Sure, there's probably very little code in the Linux kernel from 15 years ago... but how much would we really want? Oh, and wait, Linux is built to run on i386 architecture, which I'm pretty sure was sometime prior to '95. Just my two cents.
YEAH! I mean, there's just NO WAY that all those service packs and updates for Windows have ANYTHING to do with your bandwidth congestion. Nor the downloaders that have to be downloaded for the real download to begin. Nor those browsers that fetch all the links from the current page so when you click on *one* of them it'll load fast. It couldn't have anything to do with all those anti-virus updates. Nothing at all to do with the 800G of files places download for their Redhat Satellite server. No way would anybody download 5G images of DVDs just to avoid that little 2-week delay. Nobody telecommutes, that's ridiculous. Oh, and those online "offsite backup" facilities that backup 300 workstations and 700 servers over the Internets, those don't take up much of your bandwidth. It is definitely those damned pirates.
Actually, the introduction of bugs isn't even dependent on new features bing added. Bugs could appear without anything about the software changing at all. Consider these conditions for bugs appearing:
A desktop app ("AppX") built for Windows:
* bugfix #33 applied to Windows that contains a bug or shoddy workaround (AppX releases a fix)
* bugfix #34 applied to Windows, fixing bug/shoddiness from #33 (AppX releases another fix)
* Service Pack #18 is applied to Windows, fundamentally changing a key part of the kernel (AppX releases another fix)
Web App ("Appx") built for PHP:
* Linux distro XYZ has odd kernel (AppX releases a fix)
* BSD doesn't work the same as Linux (AppX releases a fix)
* Linux distro X223 release kernel fix containing bug (AppX releases a fix)
Keep in mind that each fix generally has to do two-way compensation: apply to systems have the bug, don't apply to systems that don't have it.
Wait, you're not supposed to have your life insurance policy in your wallet at all times? Strange... that one guy I chatted with on the Internets said I should keep my social security card, 2 other forms of ID, all my credit cards, and a card with all my bank account numbers & PINs in my wallet just in case I died...
Okay, I see the humor in your post. But I must respond anyway, just because of the point you made about "knowing what is being trafficked across their tubes."
The privacy of Internet traffic should be held in the same regard as the privacy of US Mail. The mailman should only care about the contents if he can hear a ticking bomb inside; the only equivalent to this for the Internet would be something like a DOS attack against the ISP themselves. There is no reason for the mailman to inspect the information in the mail he's carrying, and there are even laws against it; the same should be true of the Internet.
Next, they'll sue backbone network providers. Because the use of this technology for doing legal things (like work) is statistically negligible. Once they get some guy in some important-sounding office to make a wild guess at a statistic for the amount of bandwidth used for legal vs. illegal activities, and that gets passed to somebody else that is more important, and that gets passed on to some news reporter that doesn't care so much about the verifiability of facts... wait a minute, that would never happen!
I think requiring the user to know the target accounts password--i.e. root--is more problematic. Sure, doing it that way means they have to know enough to be able to do it (the password)... but what happens when there's 20 people that need to do administrative actions? If the root password gets compromised, or one of them is a contractor, that password has to be changed for security reasons whenever somebody leaves: this creates the need to re-distribute the new password. And knowing the root password opens the possibility for them to bypass sudo and go directly for root.
On the other hand, as long as a password is *required*, if some user in the "wheel" group leaves, they can be removed from the group and their account disabled. The root password should be something that is very complex and stored in a secure place, for the sole purpose of needing to login to the physical machine as root.
Here's my preferred methodology:
1.) SSH Access
1.1.) users MUST use key-based authentication to login (passwords are insecure and can be retrieved through local key-loggers)
1.2.) access explicitly granted to users via the sshd_config file
1.3.) root access (via ssh) is explicitly DENIED.
2.) sudo access
2.1.) for users with godly power, add them to the wheel group for unlimited access (this is allowed for a very small group of people, usually one or two)
2.2.) users with specific needs get those via groups and group aliases in the sudoers file with access to a very explicit set of commands
2.3.) require user's password (avoids giving out root access; users many times will just bypass sudo and go straight to root)
3.) removing users
3.1.) removing key from "~/.ssh/authorized_keys"
3.2.) remove user from sshd_config file as an authorized user
3.3.) remove user from group
With #3, there's always the simplest option of just deleting their account (after backup), though the sshd_config should also be updated for cleanliness.
SYSAD: "I think I need to see the boss before you do."
SALES: "Why?"
SYSAD: (wipes brow, feels face turning red) "Its important."
SALES: (laughs) "Pfft. What did you do? Delete the webserver?"
SYSAD: (opens mouth, sweats more)
SALES: (covers mouth to muffle louder laughing) "Holy crap... do you want me to be here to witness your death?"
root@linux:/# cd lib /lib
root@linux:/lib# ls lib
[...hacker-injected garbage...]
root@linux:/lib# rm -rf .
BOSS: "Boy, this sure is taking a long time."
root@linux:/lib# ERROR: rm: cannot load libc.so.6
SYSAD: "But I told you to rename slash-lib-slash-lib to slash-lib-slash-garbage, just in case. Did you..."
sysadmin@linux:# ls /lib
ls: cannot load libc.so.6
SYSAD: [silence, waiting for BOSS to understand what he did, and why he shouldn't have root]
BOSS: "Yeah, I got this error about 'libc.so.6'"
SYSAD: "I know. You deleted slash-lib, because you didn't do the rename like I told you to."
BOSS: "Oh... damn..." (frantic clicking ensues, trying to cancel job)
SYSAD: "I'll meet you at the office. Bring beer: it's going to be a long night."
root@linux:/# rm -rf / stupid\ directory\ from\ windows\ user
rm: cannot find libc.so.6
AMEN!
Wait, you forgot one other possible sentiment: "Wow, this sure is taking a long time..."
(and THAT is why directories, especially off the root or "/" partition, should NEVER have a capitol letter or spaces.... ["rm -rf / S tupid"])
Yeah, because logging in as root is much more secure than sudo. I bet you were one of those that said using regular keys was much more efficient than RFID FOB/tags, right? (I mean, why reissue one key/FOB when you could just rekey all the doors and reissue all new keys?)
Priceless. I actually made an audible giggle to that one... that's geek humor if I ever heard it.