The rule for species survival is simple: adapt or die. There are historical events of much greater scale and effect than this global climate change will be. If a species can't adapt, then it will die out. A species that can't adapt to a minor change in environment was probably doomed to extinction anyways regardless of Man's contribution to global climate change.
I dunno about you, but most everything in my/etc directory is chmod 644 with root as the owner. If a program or user has the ability to write to/etc, there's generally very little to stop that program from ballocksing up the entire system.
I don't know about anybody else's experiences, but every time I've tried to use a Sage product I've found it buggy and prone to data loss. ACT! in particular is the worst piece of software that I've ever had the displeasure of using. The ridiculous part is that it gets slower and more buggy with every release.
Part of the problem is that if IT is done right then it's invisible. Nothing breaks, there are no downtimes, no service outages, requests are completed in a timely and efficient manner, etc. You know good IT when you no longer have to think about the technology. You wouldn't not even know your company has an IT department. Everything just works.
Then the problem is that bean-counters come in and say "Do we really need to be spending all this money for IT? We don't have any problems with technology that would require an annual budget this size. Let's outsource it and save money. We don't need new versions because what we have clearly works just fine." That line of thinking will quickly get you into a position where nothing at all works and you're absolutely certain your company hasn't got an IT department because you can't get anything fixed.
Seriously, how often do you think about the service lines running to homes and businesses? Never unless there's a problem, and then you realize how big of a problem it is. Electricity is plug and play, flick a switch. Gas, water and sewer are totally invisible. IT is the same. It's either invisible or there's a problem.
Of course they have motivation to give a damn. In spite of all this short-term thinking that pervades modern media business, if you piss off your customers or produce a shit product, people will not buy it.
I'm not buying a game with time lock on it. Or a countdown meter. Or anything like that. I have a hard enough time using Steam, which is convenient, cheap, offers services to go with the games, and offers games not available in stores. It's all but directly better than a pressed disc and I still hesitate to buy from it because Valve going under means I lose all my games.
I will not buy Spore. I will not buy C&C Red Alert 3 either. I already made the mistake of buying BioShock. Fool me once, EA. There's a lot of games out there. Nothing is an absolute "must play" anymore. The market is too big, and my library of games is too large. I can go back and play any of a hundred other games. Spore isn't so revolutionary that I'm willing to deal with SecuROM.
You say that like it's a bad thing. If I need telnet I'll just get PuTTY anyways. The only thing telnet is good for anymore is checking to make sure SMTP traffic works and configuring devices that won't talk with anything else. Otherwise you *don't* use it any more that you use rsh or rcp.
Frankly, I'm more irritated that Windows doesn't ship with a built-in ssh and sshd. And no, remote desktop does not count.
You might want to ask insurgents in Iraq about how effective they can be against the most expensive, best equipped military force in the history of war using nothing but the cheapest, most common military equipment around and their own wits.
You're making the mistake of assuming the US government and her forces are a monolithic entity. They're not. The problem with the US Armed Forces is that they're almost completely populated with American citizens. If there were ever a wide-scale revolt, many of the revolutionaries would themselves be members of the armed forces. An attack helicopter is only useful so long as it can be supplied with fuel, ammunition, a pilot and gunner, repair crew, landing zone, etc. And no amount of artillery, cruise missiles or attack helicopters will capture and hold territory.
In any case, "government" need not mean the Federal government. Local governments are arguably more susceptible to abuse. Witness the Battle of Athens in 1946: http://en.wikipedia.org/wiki/Battle_of_Athens_(1946)
If it does mean the Federal Government, like it did in 1861, well, you're very likely to have states against states. You'll notice how many of the Confederate officers were previously in the US Army.
I'm certain you could rebrand one of those Sharper Image "Ionic Breeze" things and say it improves sound quality and make a killing on them. Just tell people to run the device for 30 to 60 minutes before playing sound. You could do it with any number of environmental controls: space heater, air conditioner, humidifier, etc.
Oh, I quite agree, but given the complaint about query speed here and the limitations of MyISAM on MySQL, the only situation I could envision was one that involved some highly complex query on the order you'd see in OLAP. Or some poorly designed database. What kind of query would take so long with no need for procedural SQL, triggers, writable views, or foreign key constraints? Obviously, I haven't seen the DB in question, but it's suspicious.
Simply put, MyISAM isn't meant for data sets that large. It's meant to be fast with less regard for data integrity than the alternatives. That's by design. When you increase the max size of of the table, you change the bit length of the addresses used for indexing the table and such. Increasing the bit length slows the system, particularly when the bit length exceeds the bit size of the processor. I'd argue more that the default engine should be InnoDB rather than MyISAM, and that internal tables should also be run as InnoDB now.
Additionally, I'd argue that comparing a MyISAM table to SQL Server (or any other transactional, ACID-compliant RDBMS) is not a fair comparison. If all you care about is speed, then you can get even more if you go with an embedded database like Firebird or SQLite. Or try a flat file. Those are terrifically fast if you do them right. Why do you think file systems are so much more efficient than RDBMS's?
Honestly, there are better ways to optimize most databases which don't involve sacrificing data integrity to do so. Examine your indices and views. Maybe your DB isn't normalized properly. IMO, sacrificing OLTP integrity to satisfy OLAP speed is like taking supports from the first floor to finish the roof.
Well, they can't license anything that they don't have copyright to. End users create the content, and thus own the copyright. It's not a derivative work (as defined by 17 U.S.C. 101).
Internal data files are exactly code. They're data objects in descriptive binary code necessary for the program to function, they're owned and copyrighted by the code author, and they've necessarily already been distributed as a component of the program under the same licensing restrictions. How do we know? Because they're in the same distribution that contains the source code and LICENSE.TXT.
This assertion can be extended to ridiculous lengths. Music would by copyrighted by microphone manufacturers. Television and photographs would be owned by camera manufacturers. Oh, except those tools were built from other tools, so cameras are all owned by chemical producers, which are all owned by oil companies, which are all owned by oil field owners, who are all middle eastern nations.
Copyright only applies to the work itself and derivative works (which has already been strictly defined). That's it.
What a load of crap - the GPL doesn't cover this in any way. If a lawyer did indeed give this advice, they should be fired. And FYI, GPL is NOT "GNU Protective License". Its GNU/GPL and stands for GNU General Public Licence.
Yeah, by that logic Microsoft's EULA grants them ownership over anything you create in Excel or Word. Or Outlook. Or SQL Server. Heck, pretty much any data file created on Windows suddenly becomes property of Microsoft.
Of course, I'd imagine that Intel has a similar EULA for the microcode on their processors....
Here's a hint: Input and output files are data files, not code. They have nothing to do at all with the licensing of the input or the output.
Because... what, you don't have to know how to boot Linux into non-GUI mode, know where xorg.conf is, and know the syntax of the file? I have to look these up almost every time I do it. I don't think I've ever forgotten how to press F8 on Windows for VGA Mode and Safe Mode.
The problem as asserted by TFA is that the patch process of Windows -- namely, Windows Update -- was inherently insecure because the patch can be reverse engineered with public information to discover the vulnerability. This truth is that this is neither a new problem, nor a problem unique to Windows, nor a problem with a realistic solution (none of the suggestions are reasonable, as other users have posted). Second, since the problem as asserted by TFA
I did not argue that Linux was less secure. I argued that the assertion of TFA is more appropriately applied to Linux because it is more severe there. With Windows, you can't reverse engineer until the patch is available to the end user. With Linux, you can reverse engineer with public information before the patch has even been committed to the code repository. That's before the code has been checked, before the revision has been compiled, before the news has been released, before your distribution updates their repository, and thus before it's readily available to the end user (downloading source code, running a diff, and recompiling is far, far from "readily available"). So unless you as an end user are also on every dev list and reading every bug tracker for every service on every Linux system in your Enterprise, you're not going to get security updates anywhere near as fast as hackers can reverse engineer them.
This doesn't mean that Windows is more secure than Linux. It means that security through obscurity works when the exploits are predicated on the system being transparent, which is exactly what this "problem" is.
My point is that this is a non-issue and an irrelevant problem in as much as it's an artifact of the system that can't really be corrected.
First, KB946723 isn't the time zone patch. It's a Vista patch for hibernation blue screen errors.
Next, your problem is that the Windows Update client is broken on your system. To fix it: 1. Stop the BITS and Automatic Updates services. 2. Delete C:\Windows\SoftwareDistribution\. It will be recreated later. 3. Start BITS and Automatic Updates and go back to Windows Update.
If you're not sure what Windows Updates is doing, check the log file located at C:\Windows\WindowsUpdate.log (NOT 'Windows Update.log'). You can always search that for the error numbers the updates are throwing.
Just because it's Windows doesn't mean you don't have to know how it works.
Yeah, exactly. If this is a problem with Windows, then it's a worse problem with Linux!
Not only can you reverse engineer the binary, but you have access to the source code and it's modifications. If you read bug trackers or dev mailing lists, you can even pick up security vulnerabilities before the patch is even released just by looking at bugs and diff files.
You can't put the toothpaste back in the tube, people. Arguing that that means you shouldn't brush your teeth is ridiculous.
Exactly, it's a basic misunderstanding of what MTBF means.
Let's say you buy quality SAS drives for your servers and SAN. They're Enterprise grade, so they have a MTBF of 1 million hours. Your servers and SAN have a total of 500 disks between them all. How many many drives should you expect to fail each year?
IIRC, this is the calculation:
1 year = 365 days x 24 hours = 8760 hours per year 500 disks * 8760 hours per year = 4,380,000 disk-hours per year 4,380,000 disk-hours per year / 1,000,000 hours per disk failure = 4.3 disk falures per year
So a 500 disk server farm should expect 4-5 disk failures annually.
Personally, I'm hoping they come up with a good model for combating cross-site scripting (which AFAIK is still a problem in every browser... except perhaps lynx).
And why was ActiveX bad? Not just because it was platform specific, but because it was insecure and prone to malware abuse. The model behind ActiveX was inherently flawed because it had too much trust for remote code to be automatically executed. Firefox and Opera are both billed as more secure because they are not subject to the kinds of broad attacks that IE 5 and 6 were.
Mozilla, Safari, and Opera gained market traction by having features that users or developers wanted that were not otherwise available. Security is a feature that many users, developers, and particularly network administrators desire. Say you have a choice between deploying your workstations with Firefox or with Secure Firefox, which one do you pick?
We're nearly to the stage where interface features (bookmarks, tabs, toolbars, javascript, flash, java) are reasonably complete and rendering speed and quality (Acid2, Acid3) is reasonably complete. So we can assume that any modern browser (including this new one) will be fully-featured and acid-compliant when released. It would be inane to do otherwise. So how do you improve browsers from here? Security *is* still an issue with browsers because they are *the* platform of the decade. Why not improve that?
Prove to me that security in IE, Firefox, Opera, and Safari is "good enough".
The Pentium Bug isn't going to happen again. Or rather, it still happens but it doesn't matter.
Since the Pentium, all Intel (and AMD) processors have used microcode. That is, there is a layer of abstraction between machine code that the processor executes and the actual electronic logic on the chip. It's a layer between the physical processor and Assembly. What it allows you to do is provide bug fixes for processor design errors. It's slightly slower because it's an extra decode operation, but it allows for much more complex and risky designs because you can fix errors you find after the chip is in production.
Microcode updates are loadable by the BIOS or by the OS. They are loaded each time the PC is powered on. BIOS updates are preferable, of course, but those "drivers" you can download for AMD processors, and certain updates available through OS vendors (http://support.microsoft.com/kb/936357) apply updates to the OS microcode.
Slashdot Mirror
The rule for species survival is simple: adapt or die. There are historical events of much greater scale and effect than this global climate change will be. If a species can't adapt, then it will die out. A species that can't adapt to a minor change in environment was probably doomed to extinction anyways regardless of Man's contribution to global climate change.
Nature rule, Danial-san.
I dunno about you, but most everything in my /etc directory is chmod 644 with root as the owner. If a program or user has the ability to write to /etc, there's generally very little to stop that program from ballocksing up the entire system.
I don't know about anybody else's experiences, but every time I've tried to use a Sage product I've found it buggy and prone to data loss. ACT! in particular is the worst piece of software that I've ever had the displeasure of using. The ridiculous part is that it gets slower and more buggy with every release.
Part of the problem is that if IT is done right then it's invisible. Nothing breaks, there are no downtimes, no service outages, requests are completed in a timely and efficient manner, etc. You know good IT when you no longer have to think about the technology. You wouldn't not even know your company has an IT department. Everything just works.
Then the problem is that bean-counters come in and say "Do we really need to be spending all this money for IT? We don't have any problems with technology that would require an annual budget this size. Let's outsource it and save money. We don't need new versions because what we have clearly works just fine." That line of thinking will quickly get you into a position where nothing at all works and you're absolutely certain your company hasn't got an IT department because you can't get anything fixed.
Seriously, how often do you think about the service lines running to homes and businesses? Never unless there's a problem, and then you realize how big of a problem it is. Electricity is plug and play, flick a switch. Gas, water and sewer are totally invisible. IT is the same. It's either invisible or there's a problem.
Of course they have motivation to give a damn. In spite of all this short-term thinking that pervades modern media business, if you piss off your customers or produce a shit product, people will not buy it.
I'm not buying a game with time lock on it. Or a countdown meter. Or anything like that. I have a hard enough time using Steam, which is convenient, cheap, offers services to go with the games, and offers games not available in stores. It's all but directly better than a pressed disc and I still hesitate to buy from it because Valve going under means I lose all my games.
I will not buy Spore. I will not buy C&C Red Alert 3 either. I already made the mistake of buying BioShock. Fool me once, EA. There's a lot of games out there. Nothing is an absolute "must play" anymore. The market is too big, and my library of games is too large. I can go back and play any of a hundred other games. Spore isn't so revolutionary that I'm willing to deal with SecuROM.
You say that like it's a bad thing. If I need telnet I'll just get PuTTY anyways. The only thing telnet is good for anymore is checking to make sure SMTP traffic works and configuring devices that won't talk with anything else. Otherwise you *don't* use it any more that you use rsh or rcp.
Frankly, I'm more irritated that Windows doesn't ship with a built-in ssh and sshd. And no, remote desktop does not count.
No more than the aluminum ore refining industry.
They aren't in France. Many nations have professional jurists. "Jury of peers" is an English idea.
You might want to ask insurgents in Iraq about how effective they can be against the most expensive, best equipped military force in the history of war using nothing but the cheapest, most common military equipment around and their own wits.
You're making the mistake of assuming the US government and her forces are a monolithic entity. They're not. The problem with the US Armed Forces is that they're almost completely populated with American citizens. If there were ever a wide-scale revolt, many of the revolutionaries would themselves be members of the armed forces. An attack helicopter is only useful so long as it can be supplied with fuel, ammunition, a pilot and gunner, repair crew, landing zone, etc. And no amount of artillery, cruise missiles or attack helicopters will capture and hold territory.
In any case, "government" need not mean the Federal government. Local governments are arguably more susceptible to abuse. Witness the Battle of Athens in 1946:
http://en.wikipedia.org/wiki/Battle_of_Athens_(1946)
If it does mean the Federal Government, like it did in 1861, well, you're very likely to have states against states. You'll notice how many of the Confederate officers were previously in the US Army.
I'm certain you could rebrand one of those Sharper Image "Ionic Breeze" things and say it improves sound quality and make a killing on them. Just tell people to run the device for 30 to 60 minutes before playing sound. You could do it with any number of environmental controls: space heater, air conditioner, humidifier, etc.
Oh, I quite agree, but given the complaint about query speed here and the limitations of MyISAM on MySQL, the only situation I could envision was one that involved some highly complex query on the order you'd see in OLAP. Or some poorly designed database. What kind of query would take so long with no need for procedural SQL, triggers, writable views, or foreign key constraints? Obviously, I haven't seen the DB in question, but it's suspicious.
Simply put, MyISAM isn't meant for data sets that large. It's meant to be fast with less regard for data integrity than the alternatives. That's by design. When you increase the max size of of the table, you change the bit length of the addresses used for indexing the table and such. Increasing the bit length slows the system, particularly when the bit length exceeds the bit size of the processor. I'd argue more that the default engine should be InnoDB rather than MyISAM, and that internal tables should also be run as InnoDB now.
Additionally, I'd argue that comparing a MyISAM table to SQL Server (or any other transactional, ACID-compliant RDBMS) is not a fair comparison. If all you care about is speed, then you can get even more if you go with an embedded database like Firebird or SQLite. Or try a flat file. Those are terrifically fast if you do them right. Why do you think file systems are so much more efficient than RDBMS's?
Honestly, there are better ways to optimize most databases which don't involve sacrificing data integrity to do so. Examine your indices and views. Maybe your DB isn't normalized properly. IMO, sacrificing OLTP integrity to satisfy OLAP speed is like taking supports from the first floor to finish the roof.
No. MyISAM uses a 32-bit address for row pointers for tables. A 32-bit address limits you to a 4GB addressable size.
Besides, the last file system to have a 4GB file size limit was FAT32. NTFS's and HFS+'s limits are in exabytes and ext2's is in terabytes.
Well, they can't license anything that they don't have copyright to. End users create the content, and thus own the copyright. It's not a derivative work (as defined by 17 U.S.C. 101).
Internal data files are exactly code. They're data objects in descriptive binary code necessary for the program to function, they're owned and copyrighted by the code author, and they've necessarily already been distributed as a component of the program under the same licensing restrictions. How do we know? Because they're in the same distribution that contains the source code and LICENSE.TXT.
This assertion can be extended to ridiculous lengths. Music would by copyrighted by microphone manufacturers. Television and photographs would be owned by camera manufacturers. Oh, except those tools were built from other tools, so cameras are all owned by chemical producers, which are all owned by oil companies, which are all owned by oil field owners, who are all middle eastern nations.
Copyright only applies to the work itself and derivative works (which has already been strictly defined). That's it.
Yeah, by that logic Microsoft's EULA grants them ownership over anything you create in Excel or Word. Or Outlook. Or SQL Server. Heck, pretty much any data file created on Windows suddenly becomes property of Microsoft.
Of course, I'd imagine that Intel has a similar EULA for the microcode on their processors....
Here's a hint: Input and output files are data files, not code. They have nothing to do at all with the licensing of the input or the output.
Because... what, you don't have to know how to boot Linux into non-GUI mode, know where xorg.conf is, and know the syntax of the file? I have to look these up almost every time I do it. I don't think I've ever forgotten how to press F8 on Windows for VGA Mode and Safe Mode.
While all true, those are all straw men.
The problem as asserted by TFA is that the patch process of Windows -- namely, Windows Update -- was inherently insecure because the patch can be reverse engineered with public information to discover the vulnerability. This truth is that this is neither a new problem, nor a problem unique to Windows, nor a problem with a realistic solution (none of the suggestions are reasonable, as other users have posted). Second, since the problem as asserted by TFA
I did not argue that Linux was less secure. I argued that the assertion of TFA is more appropriately applied to Linux because it is more severe there. With Windows, you can't reverse engineer until the patch is available to the end user. With Linux, you can reverse engineer with public information before the patch has even been committed to the code repository. That's before the code has been checked, before the revision has been compiled, before the news has been released, before your distribution updates their repository, and thus before it's readily available to the end user (downloading source code, running a diff, and recompiling is far, far from "readily available"). So unless you as an end user are also on every dev list and reading every bug tracker for every service on every Linux system in your Enterprise, you're not going to get security updates anywhere near as fast as hackers can reverse engineer them.
This doesn't mean that Windows is more secure than Linux. It means that security through obscurity works when the exploits are predicated on the system being transparent, which is exactly what this "problem" is.
My point is that this is a non-issue and an irrelevant problem in as much as it's an artifact of the system that can't really be corrected.
First, KB946723 isn't the time zone patch. It's a Vista patch for hibernation blue screen errors.
Next, your problem is that the Windows Update client is broken on your system. To fix it:
1. Stop the BITS and Automatic Updates services.
2. Delete C:\Windows\SoftwareDistribution\. It will be recreated later.
3. Start BITS and Automatic Updates and go back to Windows Update.
If that doesn't work, then IMX following this KB article will fix it eventually:
http://support.microsoft.com/kb/822798
If you're not sure what Windows Updates is doing, check the log file located at C:\Windows\WindowsUpdate.log (NOT 'Windows Update.log'). You can always search that for the error numbers the updates are throwing.
Just because it's Windows doesn't mean you don't have to know how it works.
Yeah, exactly. If this is a problem with Windows, then it's a worse problem with Linux!
Not only can you reverse engineer the binary, but you have access to the source code and it's modifications. If you read bug trackers or dev mailing lists, you can even pick up security vulnerabilities before the patch is even released just by looking at bugs and diff files.
You can't put the toothpaste back in the tube, people. Arguing that that means you shouldn't brush your teeth is ridiculous.
Exactly, it's a basic misunderstanding of what MTBF means.
Let's say you buy quality SAS drives for your servers and SAN. They're Enterprise grade, so they have a MTBF of 1 million hours. Your servers and SAN have a total of 500 disks between them all. How many many drives should you expect to fail each year?
IIRC, this is the calculation:
1 year = 365 days x 24 hours = 8760 hours per year
500 disks * 8760 hours per year = 4,380,000 disk-hours per year
4,380,000 disk-hours per year / 1,000,000 hours per disk failure = 4.3 disk falures per year
So a 500 disk server farm should expect 4-5 disk failures annually.
This is correct.
The correct word here, people, is tyranny.
Personally, I'm hoping they come up with a good model for combating cross-site scripting (which AFAIK is still a problem in every browser... except perhaps lynx).
And why was ActiveX bad? Not just because it was platform specific, but because it was insecure and prone to malware abuse. The model behind ActiveX was inherently flawed because it had too much trust for remote code to be automatically executed. Firefox and Opera are both billed as more secure because they are not subject to the kinds of broad attacks that IE 5 and 6 were.
Mozilla, Safari, and Opera gained market traction by having features that users or developers wanted that were not otherwise available. Security is a feature that many users, developers, and particularly network administrators desire. Say you have a choice between deploying your workstations with Firefox or with Secure Firefox, which one do you pick?
We're nearly to the stage where interface features (bookmarks, tabs, toolbars, javascript, flash, java) are reasonably complete and rendering speed and quality (Acid2, Acid3) is reasonably complete. So we can assume that any modern browser (including this new one) will be fully-featured and acid-compliant when released. It would be inane to do otherwise. So how do you improve browsers from here? Security *is* still an issue with browsers because they are *the* platform of the decade. Why not improve that?
Prove to me that security in IE, Firefox, Opera, and Safari is "good enough".
Don't be so close-minded. The same could have been said for Gecko (Mozilla) or Webkit (Safari) or Opera back in the IE 5/6 heydays.
The Pentium Bug isn't going to happen again. Or rather, it still happens but it doesn't matter.
Since the Pentium, all Intel (and AMD) processors have used microcode. That is, there is a layer of abstraction between machine code that the processor executes and the actual electronic logic on the chip. It's a layer between the physical processor and Assembly. What it allows you to do is provide bug fixes for processor design errors. It's slightly slower because it's an extra decode operation, but it allows for much more complex and risky designs because you can fix errors you find after the chip is in production.
Microcode updates are loadable by the BIOS or by the OS. They are loaded each time the PC is powered on. BIOS updates are preferable, of course, but those "drivers" you can download for AMD processors, and certain updates available through OS vendors (http://support.microsoft.com/kb/936357) apply updates to the OS microcode.