Yes, without a doubt, there is code in Vista that in unchanged since the first version of NT and I suspect snippets of vulnerable Win9x code is still in there too. Scary, huh?
Without a doubt, there are code snippets on Unix, Linux and BSD systems that date back 30 years or more. How long has telnet been around? Sendmail? BIND? X? Assuming all that really, really old code is free from vulnerabilites simply because it is old is absolute folly.
So, how do they justify billing one bloke over $1000 bux and billing the next bloke $29 bux for the same damn thing? How? By trying to keep the underlying technology mysterious. By hiding this from the general public. By dirty tactics like delaying certain packet types. By being deceitful.
The primary cost differential between T1 and DSL is based on the reliability of the technology and the SLA. T1s can be more reliable in the face of a fiber cut because of the fast failover provided by ATM. We still lease some T1s for our business, because we are contractually guaranteed a very high uptime, and an equally short repair time. The penalties in the contract for breaching the SLA are much higher than for DSL. DSL lines typically provide "best effort" service, and the only protection you have is they don't bill you for the time the line is broken.
The only reason everyone uses Javascript to embed the files now is because of Microsoft's attempt to screw plug-ins.
Microsoft got sued by a patent troll. Like it or not, MS were the good guys in this particular case, and aren't intentionally screwing anybody. Microsoft is trying to do the smart (and decent) thing by starving Eolas of future revenue. Microsoft and its deep pockets "took one for the team".
The FOR command in the "legacy" Windows shell is pretty powerful, too. It even has horrible syntax, just like its UNIX fathers.
Yes, the legacy Windows shell sucks, but not as badly as most people assume. The NT shell can do a lot of stuff that most people don't even think to try. Great gobs of functionality have been added over the years, starting with Windows NT 3.5. And contrary to what many slashdotters think, the legacy shell on Windows NT-derived systems is not DOS, nor is it 16-bit. CMD.EXE is just another 32-bit or 64-bit process running on the NT kernel.
Seriously, this is how intellectuals do racism: they talk about overpopulation, and the "wrong" people reproducing. Far too many otherwise smart people assume that the world would be a better place if they ran things, because they believe they are smarter than the average Joe. How is this any different from , who decided the world would be better when they ran everything?
Every single one of the graphic artists and software developers in my company has a dual-Xeon system with 4 GB of RAM. Hardware is cheap; employee time is my organization's #1 expense by a factor of 10 or more.
First of all, when you call Microosoft Product Support Services, if it is an actual software bug that is causing your issue, they almost always refund your money. The support call fees they charge are really consulting fees, since the majority of the people calling have their issue resolved by correcting a mis-configuration or misunderstanding of the product. PSS will even walk you though a disaster recovery process which takes hours, all for $250, even though the disaster is almost never the fault of the Microsoft product in question.
We have had occasions where we were given hotfixes within a few days for some esoteric SQL Server bugs, and our support call money was refunded. In fact, one time Microsoft tracked a SQL Server index corruption problem down to a timing problem in the firmware of an Adaptec RAID controller, but still refunded our money without us even asking. They even coordinated with Adaptec support on the fix.
Those who say "Microsoft Support sucks" generally have no experience with anything other than the front-line "consumer" support for Office and Windows, which probably does indeed suck. But Microsoft's support for business customers is generally higher than every large IT vendor we deal with, except Speakeasy, which provides our branch-office connectivity.
GENERAL JUNK E-MAIL FILTERING RANT (You've been warned): If you're using an anti-spam technique which takes more cpu cycles to execute than it takes for the spammer to send the damn spam in the first place, you've already lost this war. In other words, as long as it's costing you more than it is costing him/her you will always be on the losing end of the deal.
Yes, the spammer will always win, since his CPU cycles and bandwidth are free. But those costs don't matter at all.
Bayesian and other resource-intensive spam filtering techniques are popular because they save people's time, which is far more expensive and valuable than CPU cycles. So you want your filter to catch the most spam. But false positives cost far more in people-time and lost opportunity than a missed spam, so reducing those is nearly as important as catching spam.
RBLs, SPF, greylisting, and most other protocol-oriented filtering techniques have comparatively high false positive rates. They also make recovering from false positives very difficult. A false positive will likely go unnoticed by the sender if they don't to recognize the bounce message (there's lots of "bounce spam") and take appropriate action to call by phone or use a website form or whatever. And then mail administrators need to get involved and whitelist the addresses.
Most businesses, including mine, find a high false postive cost unacceptable. So we accpet delivery of just about everything, and stick it in a "junk mail" folder if the content and protocol filters really, really don't like it. Yeah, it costs us in CPU cycles, storage, and bandwidth, but it's the best tradeoff at the moment.
Umm... neither Exchange Server, Excel, Word, or Outlook were acquired by Microsoft. They were completely written in-house, and are amongst the biggest cash cows Microsoft has.
Not that it matters much. Microsoft's longstanding value proposition has been integration amongst its verious offerings. They acquired PowerPoint and made it work well alongside Excel and Word, and they acquired SQL Server and gave it easy to manage Windows GUI tools, repeat ad nauseum. Microsoft's innovation has been in refining different categories of applications so that they are good enough, simple enough, and familiar enough for pepole to fit them in to their existing Windows infrastructure without much pain.
Reminds me of a joke I once read... Q: "Looking at the polls, a lot of people seem to support the war, so why aren't there any PRO-war demonstrations?" A: "Because Republicans don't have time for protests; they all have jobs!
Name a CD that had 15 tracks that were worth having.
The Led Zeppelin Box Set contains 44 tracks, and every single one is worth having. In fact, in Indiana, you had to know every measure of every single track to get through high school.
I'm not sure about even that -- how many remote exploits did MS-DOS 2.0 have?
Assuming you installed one of the contemporary networking stacks (IPX or NetBEUI or whatever was available), your typical networked DOS machine probably had shitloads of remote exploits. Nobody programming for PCs really thought much about security back then; I imagine the networking code was riddled with buffer overflows.
Also, one could count floppy-borne boot sector viruses as remote exploits. Which they are, in the sense that the attack comes in via "sneakernet" with no user interaction required other than the "normal" action of inserting a disk. In my opinion, this is no different than a "remote" exploit that requires a user to visit a web page or open an email message.
But then again, I've got 6 Gigabit NICS load balanced on a Gigabit backplane with the VMs all running on an independent SAS array on a quad processor hyperthreaded box with 32 GB of RAM. But perhaps your box has equally as good specs, I don't know.
Oh yeah? Well my Johnson is longer than yours, and my son can beat up your son.
Your information regarding Windows is somewhat outdated. In my testing, Windows 2000 (with SP4), Windows XP (with SP2) and Windows 2003 SP1 all run fine without any page-file whatsoever. I often run development virutal machines this way to reduce the size of differential backups of the VM file.
When you run without any paging file in Windows, you do lose some crash-dumping functionality, but other than that the Windows kernel doesn't seem to care.
With Linux you are not forced into an upgrade cycle (barring critical security flaws on an old kernel version that is no longer supported -- older than 2.4) and even if you are, it costs you nothing.
Your time is worth nothing? Staff costs are the greatest expense in almost any business, and usually overwhelm hardware and software costs quickly. We chose a commercial Java application running with JBoss on Win 2003 for a recent deployment, and the combined hardware/software costs were less than 5% of the total project expenses. The rest were staff and contractor time.
What Microsoft can sell effectively to some shops (including mine in this particular case, although we never actually talk to MSFT sales folks) is that retraining admins and developers to work with non-Microsoft tools is significantly more expensive (and risky) than sticking with what they know. Even with all the patch management, anti-virus, and other headaches that come with Windows.
Microsoft's real challenge is winning over open source alternatives in "green field" scenarios, where there is no investment in a particular infrastructure that would be painful to change. Startups are going with open source in droves.
NTP works only in UTC time, it is up to the NTP client to display time in the correct time zone. It was designed like this so the protocol wouldn't have to change as DST rules change, only the client devices "time zone tables". Adding time zone data would make packets bigger, and thus make the protocol less accurate. Plus, there is no official standard table(s) of time zone data (although zoneinfo comes close to being a de-facto standard).
Safeguard was positioned in N. Dakota to intercept missiles coming in over the pole to targets in the continental USA. Targets like the city of Chicago, Dallas, or the Strategic Air Command near Omaha, Nebraska. The missile interception would presumably happen hundreds of miles away from the Sprint launch site.
And I do think the near-complete loss of electricity and transporation for months due to EMP wouldresult in tens of thousands, if not millions of deaths. I think you're overlooking the fact that the majority of people in Wetern nations live nowhere near their food sources, and rely entirely upon municipal water pumped from reserviors. There's probably only a few weeks worth of canned or dry food in any particular city.
My impression is that the system wasn't considered very cost-effective.
I think the larger issue with the Sprint missile system and its bretheren were the fact that they essentially required the U.S. to cripple itself with EMP in order to stop incoming warheads. The economic damage of a single EMP event above densley populated U.S. soil would have been devastating in the 1970s, but far worse today (we have far more unshielded electronics on which everyday life depends).
Now imagine thousands of EMP events, one each for the thousands of warheads which would require interception in the event of an all-out Soviet attack. No cars running, no civilian radio or television, no Internet access, no electricity, human sacrifice, dogs and cats living together - mass hysteria!
The problem is that almost every application of any size has some form of scheduling that is in some way dependent on local time. CRM systems, warehousing, distribution, manufacturing, medical services, and backup applications all require scheduing. We even have marketing applications for which future campaigns are scheduled and run automatically. I fully expect the new refridgerator I am having delivered next week to show up at the wrong time.
Always use UTC and convert to local time on the fly, it avoids all these problems.
No, it really, really doesn't. Microsoft Exchange Server stores all appointments in UTC internally, and that is what is CAUSING the problem. When DST rules change, the appointment I scheduled for 4 pm local time before the patch is applied is suddently is happening at 5 pm local time.
We're having tons of problems with other applications, including some Linux-based systems which schedule everything in UTC. Customers keep calling asking why their scheduled events have changed times after the patches, even though the DB still has the same UTC time in it.
You really need to store a definition of the "source" timezone with a scheduled event (including UTC offsets and start/end dates), along with the time the event you're talking about was actually scheduled. Then you might just have enough information to do on-the-fly conversions, assuming all systems and applications involved use the same tzdata database. This is sort of what Windows Vista & Exchange/Outlook 2007 do, but it isn't exactly space-efficient to do the same thing in a database table with millions of entires. Oh, and of course there isn't a one-to-one mapping between windows time zones and tzdata zones. And Perl, Ruby, Java, etc. all have their own time zone tables (some based on tzdata, updfated at verying intervals through different means).
Basically, handling time zones properly really sucks. Almost as badly as writing systems that handle local sales tax propely. The rules aren't consistent, and they change frequently.
This is a load of BS. Time zone rules are not hard-coded in Windows; the DST rules are just in the registry. The registry is an editable configuration file, just like the zoneinfo configuration files on a Linux system. On Windows, you can edit the time zone rules yourself, and microsoft even provides instructions (and a GUI tool) for doing so if you don't want to deploy a patch.
MS did not release supported exectuable patches for its out-of-support products, because they don't want to do the QA and support required. I don't think that was a customer-friendly decision, and thier patching process for still-supported products is a horribly documented nightmare. But it is certainly not Microsoft's fault this DST legislation came up inthe first place.
Other vendors are doing the same sort of thing as Microsoft. I think if you look at Oracle, IBM, etc. you'll see that many of their older out-of-support products don't have DST patches available either. Mobile phone and PDA vendors are amongst the worst offenders in this area.
There's a lot more than a "CMYK implementation" needed to replace Photoshop. You need suppport for ICC color correction, a lossless "base" color space (e.g. L*a*b), high-bit-depth support, monitor/scanner/device calibration support, 6+ color separation support, PANTONE color library support, and a hundred other professional-level features.
GIMP is good for making JPEGs that target the web, where color fidelity is (lamentably) disregarded. And of course personal photo editing. GIMP's true competition at this point is Photoshop Elements, Paint.NET, Paint Shop Pro, and other "prosumer" tools.
OS X 10.0 was released from beta in 2001. The first release of Visual Studio.net was in 2002. You're clearly misinformed if you think there was a 5 year time difference.
More importantly, pervasive OS support for Unicode is one thing, but making i18n support easy for developers is someting else entirely. A more apt comparison would be.NET to WebObjects or Cocoa. I am not familiar enough with either of those to make a comparison.
Slashdot Mirror
Without a doubt, there are code snippets on Unix, Linux and BSD systems that date back 30 years or more. How long has telnet been around? Sendmail? BIND? X? Assuming all that really, really old code is free from vulnerabilites simply because it is old is absolute folly.
The primary cost differential between T1 and DSL is based on the reliability of the technology and the SLA. T1s can be more reliable in the face of a fiber cut because of the fast failover provided by ATM. We still lease some T1s for our business, because we are contractually guaranteed a very high uptime, and an equally short repair time. The penalties in the contract for breaching the SLA are much higher than for DSL. DSL lines typically provide "best effort" service, and the only protection you have is they don't bill you for the time the line is broken.
Microsoft got sued by a patent troll. Like it or not, MS were the good guys in this particular case, and aren't intentionally screwing anybody. Microsoft is trying to do the smart (and decent) thing by starving Eolas of future revenue. Microsoft and its deep pockets "took one for the team".
The FOR command in the "legacy" Windows shell is pretty powerful, too. It even has horrible syntax, just like its UNIX fathers.
Yes, the legacy Windows shell sucks, but not as badly as most people assume. The NT shell can do a lot of stuff that most people don't even think to try. Great gobs of functionality have been added over the years, starting with Windows NT 3.5. And contrary to what many slashdotters think, the legacy shell on Windows NT-derived systems is not DOS, nor is it 16-bit. CMD.EXE is just another 32-bit or 64-bit process running on the NT kernel.
Is there a -1 Racist mod?
Seriously, this is how intellectuals do racism: they talk about overpopulation, and the "wrong" people reproducing. Far too many otherwise smart people assume that the world would be a better place if they ran things, because they believe they are smarter than the average Joe. How is this any different from , who decided the world would be better when they ran everything?
Every single one of the graphic artists and software developers in my company has a dual-Xeon system with 4 GB of RAM. Hardware is cheap; employee time is my organization's #1 expense by a factor of 10 or more.
First of all, when you call Microosoft Product Support Services, if it is an actual software bug that is causing your issue, they almost always refund your money. The support call fees they charge are really consulting fees, since the majority of the people calling have their issue resolved by correcting a mis-configuration or misunderstanding of the product. PSS will even walk you though a disaster recovery process which takes hours, all for $250, even though the disaster is almost never the fault of the Microsoft product in question.
We have had occasions where we were given hotfixes within a few days for some esoteric SQL Server bugs, and our support call money was refunded. In fact, one time Microsoft tracked a SQL Server index corruption problem down to a timing problem in the firmware of an Adaptec RAID controller, but still refunded our money without us even asking. They even coordinated with Adaptec support on the fix.
Those who say "Microsoft Support sucks" generally have no experience with anything other than the front-line "consumer" support for Office and Windows, which probably does indeed suck. But Microsoft's support for business customers is generally higher than every large IT vendor we deal with, except Speakeasy, which provides our branch-office connectivity.
Yes, the spammer will always win, since his CPU cycles and bandwidth are free. But those costs don't matter at all.
Bayesian and other resource-intensive spam filtering techniques are popular because they save people's time, which is far more expensive and valuable than CPU cycles. So you want your filter to catch the most spam. But false positives cost far more in people-time and lost opportunity than a missed spam, so reducing those is nearly as important as catching spam.
RBLs, SPF, greylisting, and most other protocol-oriented filtering techniques have comparatively high false positive rates. They also make recovering from false positives very difficult. A false positive will likely go unnoticed by the sender if they don't to recognize the bounce message (there's lots of "bounce spam") and take appropriate action to call by phone or use a website form or whatever. And then mail administrators need to get involved and whitelist the addresses.
Most businesses, including mine, find a high false postive cost unacceptable. So we accpet delivery of just about everything, and stick it in a "junk mail" folder if the content and protocol filters really, really don't like it. Yeah, it costs us in CPU cycles, storage, and bandwidth, but it's the best tradeoff at the moment.
Umm... neither Exchange Server, Excel, Word, or Outlook were acquired by Microsoft. They were completely written in-house, and are amongst the biggest cash cows Microsoft has.
Not that it matters much. Microsoft's longstanding value proposition has been integration amongst its verious offerings. They acquired PowerPoint and made it work well alongside Excel and Word, and they acquired SQL Server and gave it easy to manage Windows GUI tools, repeat ad nauseum. Microsoft's innovation has been in refining different categories of applications so that they are good enough, simple enough, and familiar enough for pepole to fit them in to their existing Windows infrastructure without much pain.
Reminds me of a joke I once read...
Q: "Looking at the polls, a lot of people seem to support the war, so why aren't there any PRO-war demonstrations?"
A: "Because Republicans don't have time for protests; they all have jobs!
P.J. O'Rourke, I think.
The Led Zeppelin Box Set contains 44 tracks, and every single one is worth having. In fact, in Indiana, you had to know every measure of every single track to get through high school.
Assuming you installed one of the contemporary networking stacks (IPX or NetBEUI or whatever was available), your typical networked DOS machine probably had shitloads of remote exploits. Nobody programming for PCs really thought much about security back then; I imagine the networking code was riddled with buffer overflows.
Also, one could count floppy-borne boot sector viruses as remote exploits. Which they are, in the sense that the attack comes in via "sneakernet" with no user interaction required other than the "normal" action of inserting a disk. In my opinion, this is no different than a "remote" exploit that requires a user to visit a web page or open an email message.
Oh yeah? Well my Johnson is longer than yours, and my son can beat up your son.
Really? It just shows up as a blank image in IE7 on XPsp2. Imagine that... a MS product that's more stable than OSX.
Your information regarding Windows is somewhat outdated. In my testing, Windows 2000 (with SP4), Windows XP (with SP2) and Windows 2003 SP1 all run fine without any page-file whatsoever. I often run development virutal machines this way to reduce the size of differential backups of the VM file.
When you run without any paging file in Windows, you do lose some crash-dumping functionality, but other than that the Windows kernel doesn't seem to care.
Your time is worth nothing? Staff costs are the greatest expense in almost any business, and usually overwhelm hardware and software costs quickly. We chose a commercial Java application running with JBoss on Win 2003 for a recent deployment, and the combined hardware/software costs were less than 5% of the total project expenses. The rest were staff and contractor time.
What Microsoft can sell effectively to some shops (including mine in this particular case, although we never actually talk to MSFT sales folks) is that retraining admins and developers to work with non-Microsoft tools is significantly more expensive (and risky) than sticking with what they know. Even with all the patch management, anti-virus, and other headaches that come with Windows.
Microsoft's real challenge is winning over open source alternatives in "green field" scenarios, where there is no investment in a particular infrastructure that would be painful to change. Startups are going with open source in droves.
A great quantity of the US military's Hummers (basically the H1 model without leather seats) have more than 300K miles on them.
NTP works only in UTC time, it is up to the NTP client to display time in the correct time zone. It was designed like this so the protocol wouldn't have to change as DST rules change, only the client devices "time zone tables". Adding time zone data would make packets bigger, and thus make the protocol less accurate. Plus, there is no official standard table(s) of time zone data (although zoneinfo comes close to being a de-facto standard).
Safeguard was positioned in N. Dakota to intercept missiles coming in over the pole to targets in the continental USA. Targets like the city of Chicago, Dallas, or the Strategic Air Command near Omaha, Nebraska. The missile interception would presumably happen hundreds of miles away from the Sprint launch site.
And I do think the near-complete loss of electricity and transporation for months due to EMP wouldresult in tens of thousands, if not millions of deaths. I think you're overlooking the fact that the majority of people in Wetern nations live nowhere near their food sources, and rely entirely upon municipal water pumped from reserviors. There's probably only a few weeks worth of canned or dry food in any particular city.
I think the larger issue with the Sprint missile system and its bretheren were the fact that they essentially required the U.S. to cripple itself with EMP in order to stop incoming warheads. The economic damage of a single EMP event above densley populated U.S. soil would have been devastating in the 1970s, but far worse today (we have far more unshielded electronics on which everyday life depends).
Now imagine thousands of EMP events, one each for the thousands of warheads which would require interception in the event of an all-out Soviet attack. No cars running, no civilian radio or television, no Internet access, no electricity, human sacrifice, dogs and cats living together - mass hysteria!
The problem is that almost every application of any size has some form of scheduling that is in some way dependent on local time. CRM systems, warehousing, distribution, manufacturing, medical services, and backup applications all require scheduing. We even have marketing applications for which future campaigns are scheduled and run automatically. I fully expect the new refridgerator I am having delivered next week to show up at the wrong time.
No, it really, really doesn't. Microsoft Exchange Server stores all appointments in UTC internally, and that is what is CAUSING the problem. When DST rules change, the appointment I scheduled for 4 pm local time before the patch is applied is suddently is happening at 5 pm local time.
We're having tons of problems with other applications, including some Linux-based systems which schedule everything in UTC. Customers keep calling asking why their scheduled events have changed times after the patches, even though the DB still has the same UTC time in it.
You really need to store a definition of the "source" timezone with a scheduled event (including UTC offsets and start/end dates), along with the time the event you're talking about was actually scheduled. Then you might just have enough information to do on-the-fly conversions, assuming all systems and applications involved use the same tzdata database. This is sort of what Windows Vista & Exchange/Outlook 2007 do, but it isn't exactly space-efficient to do the same thing in a database table with millions of entires. Oh, and of course there isn't a one-to-one mapping between windows time zones and tzdata zones. And Perl, Ruby, Java, etc. all have their own time zone tables (some based on tzdata, updfated at verying intervals through different means).
Basically, handling time zones properly really sucks. Almost as badly as writing systems that handle local sales tax propely. The rules aren't consistent, and they change frequently.
This is a load of BS. Time zone rules are not hard-coded in Windows; the DST rules are just in the registry. The registry is an editable configuration file, just like the zoneinfo configuration files on a Linux system. On Windows, you can edit the time zone rules yourself, and microsoft even provides instructions (and a GUI tool) for doing so if you don't want to deploy a patch.
MS did not release supported exectuable patches for its out-of-support products, because they don't want to do the QA and support required. I don't think that was a customer-friendly decision, and thier patching process for still-supported products is a horribly documented nightmare. But it is certainly not Microsoft's fault this DST legislation came up inthe first place.
Other vendors are doing the same sort of thing as Microsoft. I think if you look at Oracle, IBM, etc. you'll see that many of their older out-of-support products don't have DST patches available either. Mobile phone and PDA vendors are amongst the worst offenders in this area.
There's a lot more than a "CMYK implementation" needed to replace Photoshop. You need suppport for ICC color correction, a lossless "base" color space (e.g. L*a*b), high-bit-depth support, monitor/scanner/device calibration support, 6+ color separation support, PANTONE color library support, and a hundred other professional-level features.
GIMP is good for making JPEGs that target the web, where color fidelity is (lamentably) disregarded. And of course personal photo editing. GIMP's true competition at this point is Photoshop Elements, Paint.NET, Paint Shop Pro, and other "prosumer" tools.
OS X 10.0 was released from beta in 2001. The first release of Visual Studio.net was in 2002. You're clearly misinformed if you think there was a 5 year time difference.
.NET to WebObjects or Cocoa. I am not familiar enough with either of those to make a comparison.
More importantly, pervasive OS support for Unicode is one thing, but making i18n support easy for developers is someting else entirely. A more apt comparison would be