I work for a consulting company that sells implementation and customization services on top of an accounting software package. There's a fair amount of coding, phone support, and remote-control-their-workstation support, but there's also the periodic need for on-site work.
Obviously, the on-site work can't be outsourced (geographically; we do have one or two local contractors). The other stuff isn't outsourced because the communication overhead (both money and time) is deemed not to be worthwhile.
In particular, if the person who goes on site is the same person who did the other stuff - and thus knows it like the back of their hand, in a way that even well-documented outsourced work can't match - then simple requests can often be fulfilled on a same-day basis, sometimes even a matter of minutes. Clients love that.
In particular, when a system goes into live operation for the first time, it's not uncommon for the end users to come up with a metric buttload of "how do I do X? X is critical to me!" that they didn't think about until that point. Some of these require customization (especially if they already had us do some other customizations before going live), and some are just due to users not paying attention during training. We need to address the last-minute customization requests in a damn hurry, for two reasons: to prevent users from being stuck without X for days on end, and to free up time to deal with the last-minute training requests.
ISPs are supposed to follow the ARPA philosophy of "maintain multiple routes of communication, in case the Russkies nuke Kansas". Granted, this philosophy is ignored with alarming regularity.
1.)
" Like the dog that didn't bark in the night-time, these omissions are significant, because Microsoft marketing is thorough and ruthlessly opportunistic." The first part of this statement is rather confounding. I assume that you mean that that fact that they have dropped these arguments should be indicative of the thoroughness of the marketers.
I think it was meant differently:
If they're thorough, and they think (method) works, then they would be using (method).
But they're not using (method).
Therefore, either they're not thorough, or they think (method) doesn't work.
Someone literally did this at my first job, in a very limited form.
There was this software package with a bunch of modules and programs, all of which included the feature "hit F7 to bring up X". One of our custom packages included the option to globally change this to "hit F7 to bring up a utility menu" (with X as one of the options on that menu), and this option could be turned on/off. Of course, X was its own program, and all we really did was replace/restore it-- but someone decided to run a delay loop for a few seconds, so it would look like we were doing something more impressive (like patching code within all the other programs).
Later on, amongst some other code updates, we decided to remove the loop-- and claim credit for "speeding up the (de)activation utility". Which was technically true...
3. Yes, people creating malware can see the source code, but so can people defeating malware.
4. OSS authors are tech-savvy. If you know that your source code will be seen, then there's an incentive for you to write non-crappy code.
You're right about one thing: not everyone actually does read the source code, even among the tech-savvy.
Your first point is true, but (as you also correctly point out) it's not the whole story, like some Windows zealots make it out to be. Apache is more widely used than IIS, but IIS has had worse problems with vulnerabilities.
She's saying that for desktop "the timeframe is more like the next two years".
Let's put that in context, too. She's saying that desktops will grow significantly over the next two years, while servers will actually become a majority of new shipments in three. Here's the relevant excerpt (emphasis mine):
Do you think there will there be parity for the desktop?
Parity takes a long time... and especially against a convicted monopolist. I think the milestone to look for is when Linux takes 10% of the market. It's all about when corporate IT says that they will use Linux as their primary desktop operating system. This doesn't mean that users have to give up on Windows applications, but I think we will see a decline in the use of the Windows operating system on the desktop.
A number of companies are doing pilots right now, but I think the timeframe is more like the next two years. In that time we'll see tremendous growth in the Linux desktop. "Tremendous" means that we're going to see it move from being a fringe market to something that ISVs and hardware vendors are porting to and supporting.
Any thoughts when Linux might overtake Windows on the server side?
I think that's going to happen sooner. I believe we'll see Linux overtake Windows on the server within the next three to four years, as measured by new server shipments.
www.peoplesprimary.org appears to be a real site. (But you shouldn't trust me blindly, so at least turn your volume off before following that link.)
'whois' shows no similarity between the.org and.com sites, so I suspect the.com site was created specifically to be used in this type of troll.
Re:The biggest question of them all...
on
GNOME for Grandma
·
· Score: 1
> The only reason Windows and not Linux "needs" AV is because Linux isn't nearly as mainstream.
False, at least in large part. Mainstreaming Linux wouldn't magically subject it to the insecurity of IE/OE. Okay, some Induhviduals would insist on running IE/OE on top of Wine, and others would fall prey to social-engineering viruses.
If that somehow changed - and that's an awfully big if - then "Linux users don't usually run as root" may not be the end of the story. First, if the virus is coupled with a root exploit and you haven't patched against that exploit, then it can become root. Second, even without becoming root, the virus may be able to act as a spam zombie (connect to IRC, receive marching orders, send e-mail).
> Get Grandma Firefox and an e-mail client that won't automatically preview the body of an e-mail and she'll be fine.
True, at least in large part. Actually, viewing the body of an e-mail is fine, so long as the viewer doesn't blithely launch attachments. (In the interest of spam avoidance, you may want to restrict it to text + HTML-marked-up text + image placeholders. Or, in the interest of ugly-HTML avoidance, you may want to restrict it to plaintext.)
> Beyond that, it's not an issue of security. You could click some link, or give out your banking information in any OS.
I think you're tripping over the same thing that I tripped over at first.
Until you receive the decryption key, the encrypted patch is useless. You can't read it or apply it in any useful fashion - and if you can't apply it, then obviously you can't do a before/after diff.
You can, however, store it on your HD and wait for the decryption key to be posted - and this is exactly what the author is suggesting you do.
1) Encrypted patch is posted (it may be 500K) 2) Lots of machines download and store the patch (this takes a while, so you wait a while before moving on to the next step) 3) Decryption key is posted (it's only about 1K) 4) Lots of machines download the key (this is very fast because the key is small), unlock and apply the patch
After reading some other comments, I think I may have misunderstood the encrypted-patch concept. It seems to be an improvement on automating the "Tuesdays only" concept.
1) Encrypted-and-not-yet-usable patch is posted. 2) Machines subscribed to the patch service auto-download the patch and put it in a holding area. This takes a while. 3) After a while, the decryption key for the patch is posted. 4) Machines subscribed to the patch service auto-download the decryption key, decrypt the patch (making it usable), and install it. This is near-instantaneous, because the size of the decryption key is peanuts compared to the size of the patch itself. 5) Admins of non-subscribed machines can manually download the patch any time after step 1, and decrypt/install it any time after step 3. So can reverse-engineers, but now all the subscribed machines are one step ahead of them.
An intriguing idea, and not even anathema to OSS any more (the source becomes available within a reasonable time period). Automatic updates still deserve careful attention, though, especially given the past history of patches that broke something else.
Here's my analysis of some claims stated or implied in the article:
Some exploits are reverse-engineered insanely quickly from patches. (True, with an example cited.)
Slowing down patches will reduce the total severity of exploits. (Way too vague.)
Slowing down patches will delay the existence of exploits. (False; not all exploits are reverse-engineered from patches.)
Slowing down patches in a "Tuesdays only" fashion will make it easier for admins to check for patches on a predictable schedule, and install them soon after they're released. (True as far as it goes, but the reverse-engineers can also check for patches on a predictable schedule; this also totally ignores exploits that aren't reverse-engineered from a patch.)
Slowing down patches long enough to make sure they don't cause some other severe problem is a good idea. (True, but not mentioned in the article.)
Providing patches in an encrypted-but-usable form right away, and in a decrypted form later, will help admins keep ahead of reverse-engineers. (Obvious "this is anathema to OSS" aside, how would this actually work? Windows Update patches are already distributed in binary-only form, and they still get reverse-engineered.)
Managed-code languages like Java and C# will eliminate buffer overflows, which are a common source of exploits, but they're nowhere near universal. (Basically true, probably with numerous exceptions and caveats.)
> you can't just supply the Admin password, you have to logout, kill all your apps, login as admin, do what you were trying to do in the first place
C:\> RUNAS/?
RUNAS USAGE:
RUNAS [/profile] [/env] [/netonly]/user:<UserName> program
/profile if the user's profile needs to be loaded /env to use current environment instead of user's. /netonly use if the credentials specified are for remote access only. /user <UserName> should be in form USER@DOMAIN or DOMAIN\USER program command line for EXE. See below for examples
LostCluster:
The question that's really in dispute is not whether the code SCO is bringing forward looks like a duplicate of the code in Linux, but where the code that SCO is bringing forward has come from... is it in fact code SCO really owns, or is it code that SCO hacked up after looking at the GPL-available Linux code.
AC:
WHAT? You are a troll and a shill and I am fucking tired of it.
What code? Show me you shroll.
Read carefully. The crucial phrase is "looks like". The code SCO is bringing forward (and the amount of such code is laughably small, especially compared to their "millions of lines" claims) does look like Linux code... until you dig into the history, and learn that (for instance) virtually identical code has been widely circulated since the 1970s, and legally entered the public domain - possibly twice, even - well before SCO (new SCO, that is) got into the picture.
Crystal Reports is also a sort of functional system (though I've abused the hell out of its imperative capabilities, mostly to make up for lack of programming tools at other levels).
This sounds like Czechoslovakia in 1938 claiming that giving up part of their land to Germany relieved them of worries about Germany's territorial ambition. That worked out so well for Czechoslovakia, didn't it?
I hate to have to remind you of Godwin's Law (I really do think this was a boneheaded move on EV1's part), but...
SCO spokesman Blake Stowell declined to give the exact value of the deal but said it was worth at least $1 million.
EV1servers.net is a $99-per-month Web site hosting company. Formerly known as RadioShack.Net, the company has been in existence since 1999 and claims 400,000 customers in 42 states.
"They have 20,000 servers total," Stowell said. "The majority of those are Linux servers. This is a site license that covers those servers."
SCO has previous pegged its IP license at $699 per server processor and $199 per desktop processor. Using those figures, 20,000 server licenses would cost nearly $14 million, so the current agreement is likely a discounted arrangement.
You can search on e.g. (malamute -beagle) to find pages that contain "Malamute" and don't contain "Beagle". Still tricky, but sometimes it helps to weed out what you don't want.
Well, I'll be damned-- they actually fixed it. They used to have sponsored links listed on top, and so many of them that the non-sponsored links were off the screen. (AltaVista, AllTheWeb, AskJeeves, and Teoma all still have this annoying style.) MSN was truly obnoxious in that sponsored link #2 or so was "Microsoft dev tools and how to switch to them from open source". Now MSN lists sponsored links on the right, similar to Google, and the supremely obnoxious entry is gone. Credit where credit is due.
Google searches on certain keywords also offer a link to the relevant spot in the Google Directory (directory.google.com) hierarchy. If you remember what Yahoo used to be (a multi-level hierarchy of web site categories), that's basically what GD is. Whenever such a link is offered, I consider it one or two orders of magnitude better than other search engines' laundry lists of vaguely related topics and sub-topics. (However, some seemingly-common keywords - notably "open source" - don't return such a link.)
Google on "carbonless". The concept is a sound one: paper that you can run through a laser or ink-jet printer, then write on page 1 and have the image of your writing transfer to pages 2+. As far as the implementation... it's more expensive than regular typing paper, you have to tell the printer to print multiple copies of each page, and apparently there are health concerns. Worth looking into, though.
Oops, I changed foo@bar.com to joe@blow.com, but missed a couple instances. Anyway, you get the idea.
Just because a bounce message comes back to you, it doesn't necessarily mean that you or anyone you know was infected. It could just mean that an infected system poked around the web a bit, found your address somewhere, and used it as a phony From: wihle trying to spread the infection.
Slashdot Mirror
I work for a consulting company that sells implementation and customization services on top of an accounting software package. There's a fair amount of coding, phone support, and remote-control-their-workstation support, but there's also the periodic need for on-site work.
Obviously, the on-site work can't be outsourced (geographically; we do have one or two local contractors). The other stuff isn't outsourced because the communication overhead (both money and time) is deemed not to be worthwhile.
In particular, if the person who goes on site is the same person who did the other stuff - and thus knows it like the back of their hand, in a way that even well-documented outsourced work can't match - then simple requests can often be fulfilled on a same-day basis, sometimes even a matter of minutes. Clients love that.
In particular, when a system goes into live operation for the first time, it's not uncommon for the end users to come up with a metric buttload of "how do I do X? X is critical to me!" that they didn't think about until that point. Some of these require customization (especially if they already had us do some other customizations before going live), and some are just due to users not paying attention during training. We need to address the last-minute customization requests in a damn hurry, for two reasons: to prevent users from being stuck without X for days on end, and to free up time to deal with the last-minute training requests.
ISPs are supposed to follow the ARPA philosophy of "maintain multiple routes of communication, in case the Russkies nuke Kansas". Granted, this philosophy is ignored with alarming regularity.
Someone literally did this at my first job, in a very limited form.
There was this software package with a bunch of modules and programs, all of which included the feature "hit F7 to bring up X". One of our custom packages included the option to globally change this to "hit F7 to bring up a utility menu" (with X as one of the options on that menu), and this option could be turned on/off. Of course, X was its own program, and all we really did was replace/restore it-- but someone decided to run a delay loop for a few seconds, so it would look like we were doing something more impressive (like patching code within all the other programs).
Later on, amongst some other code updates, we decided to remove the loop-- and claim credit for "speeding up the (de)activation utility". Which was technically true...
Two more things:
3. Yes, people creating malware can see the source code, but so can people defeating malware.
4. OSS authors are tech-savvy. If you know that your source code will be seen, then there's an incentive for you to write non-crappy code.
You're right about one thing: not everyone actually does read the source code, even among the tech-savvy.
Your first point is true, but (as you also correctly point out) it's not the whole story, like some Windows zealots make it out to be. Apache is more widely used than IIS, but IIS has had worse problems with vulnerabilities.
Let's put that in context, too. She's saying that desktops will grow significantly over the next two years, while servers will actually become a majority of new shipments in three. Here's the relevant excerpt (emphasis mine):
www.peoplesprimary.org appears to be a real site. (But you shouldn't trust me blindly, so at least turn your volume off before following that link.)
'whois' shows no similarity between the .org and .com sites, so I suspect the .com site was created specifically to be used in this type of troll.
> The only reason Windows and not Linux "needs" AV is because Linux isn't nearly as mainstream.
False, at least in large part. Mainstreaming Linux wouldn't magically subject it to the insecurity of IE/OE. Okay, some Induhviduals would insist on running IE/OE on top of Wine, and others would fall prey to social-engineering viruses.
If that somehow changed - and that's an awfully big if - then "Linux users don't usually run as root" may not be the end of the story. First, if the virus is coupled with a root exploit and you haven't patched against that exploit, then it can become root. Second, even without becoming root, the virus may be able to act as a spam zombie (connect to IRC, receive marching orders, send e-mail).
> Get Grandma Firefox and an e-mail client that won't automatically preview the body of an e-mail and she'll be fine.
True, at least in large part. Actually, viewing the body of an e-mail is fine, so long as the viewer doesn't blithely launch attachments. (In the interest of spam avoidance, you may want to restrict it to text + HTML-marked-up text + image placeholders. Or, in the interest of ugly-HTML avoidance, you may want to restrict it to plaintext.)
> Beyond that, it's not an issue of security. You could click some link, or give out your banking information in any OS.
Definitely true.
I think you're tripping over the same thing that I tripped over at first.
Until you receive the decryption key, the encrypted patch is useless. You can't read it or apply it in any useful fashion - and if you can't apply it, then obviously you can't do a before/after diff.
You can, however, store it on your HD and wait for the decryption key to be posted - and this is exactly what the author is suggesting you do.
1) Encrypted patch is posted (it may be 500K)
2) Lots of machines download and store the patch (this takes a while, so you wait a while before moving on to the next step)
3) Decryption key is posted (it's only about 1K)
4) Lots of machines download the key (this is very fast because the key is small), unlock and apply the patch
After reading some other comments, I think I may have misunderstood the encrypted-patch concept. It seems to be an improvement on automating the "Tuesdays only" concept.
1) Encrypted-and-not-yet-usable patch is posted.
2) Machines subscribed to the patch service auto-download the patch and put it in a holding area. This takes a while.
3) After a while, the decryption key for the patch is posted.
4) Machines subscribed to the patch service auto-download the decryption key, decrypt the patch (making it usable), and install it. This is near-instantaneous, because the size of the decryption key is peanuts compared to the size of the patch itself.
5) Admins of non-subscribed machines can manually download the patch any time after step 1, and decrypt/install it any time after step 3. So can reverse-engineers, but now all the subscribed machines are one step ahead of them.
An intriguing idea, and not even anathema to OSS any more (the source becomes available within a reasonable time period). Automatic updates still deserve careful attention, though, especially given the past history of patches that broke something else.
Here's my analysis of some claims stated or implied in the article:
Some exploits are reverse-engineered insanely quickly from patches. (True, with an example cited.)
Slowing down patches will reduce the total severity of exploits. (Way too vague.)
Slowing down patches will delay the existence of exploits. (False; not all exploits are reverse-engineered from patches.)
Slowing down patches in a "Tuesdays only" fashion will make it easier for admins to check for patches on a predictable schedule, and install them soon after they're released. (True as far as it goes, but the reverse-engineers can also check for patches on a predictable schedule; this also totally ignores exploits that aren't reverse-engineered from a patch.)
Slowing down patches long enough to make sure they don't cause some other severe problem is a good idea. (True, but not mentioned in the article.)
Providing patches in an encrypted-but-usable form right away, and in a decrypted form later, will help admins keep ahead of reverse-engineers. (Obvious "this is anathema to OSS" aside, how would this actually work? Windows Update patches are already distributed in binary-only form, and they still get reverse-engineered.)
Managed-code languages like Java and C# will eliminate buffer overflows, which are a common source of exploits, but they're nowhere near universal. (Basically true, probably with numerous exceptions and caveats.)
> you can't just supply the Admin password, you have to logout, kill all your apps, login as admin, do what you were trying to do in the first place
/?
/user:<UserName> program
/profile if the user's profile needs to be loaded
/env to use current environment instead of user's.
/netonly use if the credentials specified are for remote access only.
/user <UserName> should be in form USER@DOMAIN or DOMAIN\USER
/profile /user:mymachine\administrator cmd /profile /env /user:mydomain\admin "mmc %windir%\system32\dsa.msc" /env /user:user@domain.microsoft.com "notepad \"my file.txt\""
/netonly.
C:\> RUNAS
RUNAS USAGE:
RUNAS [/profile] [/env] [/netonly]
program command line for EXE. See below for examples
Examples:
> runas
> runas
> runas
NOTE: Enter user's password only when prompted.
NOTE: USER@DOMAIN is not compatible with
Jokubonis Square Wheel (from crank.net)
AC: WHAT? You are a troll and a shill and I am fucking tired of it.
What code? Show me you shroll.
Read carefully. The crucial phrase is "looks like". The code SCO is bringing forward (and the amount of such code is laughably small, especially compared to their "millions of lines" claims) does look like Linux code... until you dig into the history, and learn that (for instance) virtually identical code has been widely circulated since the 1970s, and legally entered the public domain - possibly twice, even - well before SCO (new SCO, that is) got into the picture.
That link doesn't work. Fortunately, the folks at Neowin fixed it.
Crystal Reports is also a sort of functional system (though I've abused the hell out of its imperative capabilities, mostly to make up for lack of programming tools at other levels).
Microsoft Excel is a functional programming language. Discuss.
I hate to have to remind you of Godwin's Law (I really do think this was a boneheaded move on EV1's part), but...
Well, sure. It's not like the Catholics claim that Mars doesn't exist. Whether it has/had life is a whole other topic.
You can search on e.g. (malamute -beagle) to find pages that contain "Malamute" and don't contain "Beagle". Still tricky, but sometimes it helps to weed out what you don't want.
(goes to www.msn.com, searches for "Linux")
Well, I'll be damned-- they actually fixed it. They used to have sponsored links listed on top, and so many of them that the non-sponsored links were off the screen. (AltaVista, AllTheWeb, AskJeeves, and Teoma all still have this annoying style.) MSN was truly obnoxious in that sponsored link #2 or so was "Microsoft dev tools and how to switch to them from open source". Now MSN lists sponsored links on the right, similar to Google, and the supremely obnoxious entry is gone. Credit where credit is due.
Google searches on certain keywords also offer a link to the relevant spot in the Google Directory (directory.google.com) hierarchy. If you remember what Yahoo used to be (a multi-level hierarchy of web site categories), that's basically what GD is. Whenever such a link is offered, I consider it one or two orders of magnitude better than other search engines' laundry lists of vaguely related topics and sub-topics. (However, some seemingly-common keywords - notably "open source" - don't return such a link.)
WindX overview
WindX home
Google on "carbonless". The concept is a sound one: paper that you can run through a laser or ink-jet printer, then write on page 1 and have the image of your writing transfer to pages 2+. As far as the implementation... it's more expensive than regular typing paper, you have to tell the printer to print multiple copies of each page, and apparently there are health concerns. Worth looking into, though.
Just because a bounce message comes back to you, it doesn't necessarily mean that you or anyone you know was infected. It could just mean that an infected system poked around the web a bit, found your address somewhere, and used it as a phony From: wihle trying to spread the infection.