You'd roll back much the same way, or even perhaps by rebooting into the previous kernel image from disk.
Every production environment I've ever administered had a smaller version set aside for testing. We'd configure the machines identically and just make the cluster smaller. Then we'd test on the test machines any action that was to be made part of the admin process of the production machines. If it passes on the test machine and fails in production, then you didn't make the machines sufficiently similar.
Round robin upgrades take ( ( (time_to_idle + time_to_upgrade + time_to_reboot) * machines ) / 2) on average to get a machine upgraded. If you have a "Critical" upgrade, that might be longer than you want.
Not everyone has the exact same QA requirements you do, either. Some of us are happy with proving that it works, then proving that it worked on the production machine, then resuming our normally scheduled maintenance.
You mean how my ATA, Serial ATA, Ethernet, and filesystem modules work now? When's the last time you configured a Linux kernel? Sure, there are some things you can't do. Try Minix with a faulty video driver sometime, though, if you think a microkernel is a cure-all.
You can do that with many filesystem drivers. It's a bit harder to do it for the filesystem driver for your boot drive, but that's what initrd images are for.
A microkernel can theoretically do more of this sort of thing, but Linux does a fair amount already. Type "make menuconfig" and poke around a bit, and your eyes might be opened past your dogma and chanting.
It depends on who your boxes are serving. IF you're running boxes for in internal IT department, that's fine. If you drop a port with a 99.9999% uptime guarantee to your client who's using you as his phone or Internet provider, you've either causing him to be down or you're forcing him to switch all of his load over to his other provider.
Yes, but you end up taking one machine out at a time, giving it time to simmer down, and then bringing it back up. If you have 100 boxes and it takes 30 minutes to simmer down to idle, you have 30 * 100, or 3,000 minutes to do the upgrades. On average, your boxes go unpatched for 1500 minutes.
So you have this security hotfix you really want to apply, but it's going to 25 hours on average to fix a box and 50 hours to fix them all.
You could, with ksplice and a good concurrent control system, make your average time to fix 5 minutes in over 80% of kernel upgrade scenarios rated "Critical". Your boxes could still be rebooted on a regular basis later.
If you change something in a configuration that requires a change to the startup script, then you also change the startup script.
A patch to the kernel almost never requires changes to startup scripts. They're not talking about adding new functionality with user-space-addressable interfaces with this tool. They're talking about being able to install about 84% of security hotfixes in a hurry outside your scheduled reboots then rebooting on your regular maintenance schedule.
One of the things telephony servers do these days is handle ports, traffic, or both for live calls.
Hey, as long as it's your calls that get dropped and not mine, it's fine with me if the servers drop calls. If you'd rather not have any calls dropped, then this is nice.
You could take the server to be rebooted out of the load balancer's control, in which case existing calls would eventually end and no new calls would get assigned. You could then reboot once no calls would be effected. This solution, though, leaves the kernels unpatched on average (num_machines * time_to_idle) / 2.
If you combine this hotfix capability with scheduled simmer down reboots, then you can fix all your servers right now, then reboot them one at a time later as well. That gets your security fixes rolled out faster than just waiting for idling down then rebooting one server at a time.
You're right in certain situations, but I don't think this is to keep your computer safe from trojans placed in the drive firmware that report on the data while the computer runs later. It's designed to protect the data on a drive or computer that's stolen while it's turned off. You wouldn't use the computer again if it was recovered for fear of a trojan.
The IO bus being slow gives the processor on the drive plenty of time to get its work done before the results are actually needed.
It'd be much harder for the drive electronics to decrypt the data fast enough if the interface was faster.
When you're decrypting and encrypting on the CPU, not only are you using CPU cycles that could be doing other things, but you're also still waiting on the IO bus to move the data once it's encrypted. You're on the wrong side of the link.
If you're expecting the average credit bureau or government agency employee to remember a 32-character password, you have either wonderful security because nobody will ever get the data or terrible security because there will be a sticky note.
If you're generating a 256-bit AES key from less than 32 bytes of user input, then you're not really getting the full benefit of 256 bits.
No. It isn't. The particular article linked in the summary doesn't make that clear, but it's calculated over again every boot time. This article has at least a bit more info.
Hopefully there's some way to keep the thing from figuring the key once it's stolen, as most people will try to, you know, use the PC as a whole before they resort to stripping the drives out of it.
The news.com story says the hard drive doesn't store the key at all. It's figured during the POST process within the hard drive's BIOS config and isn't known to the drive itself when the power is down.
What it sounds like is that if you keep the computer from booting, like a pre-boot password, the drive is utterly useless to a thief. If they can get it to boot instead of staring blankly at the password prompt, the thing will recalculate the key and go merrily on its way.
Hopefully it figures the key on stored CMOS config values so that if you reset the CMOS to get rid of the boot password it'll still not generate the right key.
Ideally, big companies would do things that only big companies can afford to do and little companies would do what they do best.
Some big companies start from huge investments, but some start out as small shops, too. Google and Yahoo! actually started out as small companies, BTW, and much of their success is thanks in part to OSS. Microsoft also started out small, and one big contract with a nonexclusive buyer clause and royalties involved made them huge. Apple was just two guys about three decades ago. Dell was started in a dorm. These folks got big and then started to do things big companies can do, for better or worse.
Trickle down economics works in some situations, but not all. Some company like Southwest Airlines or Intel employs a lot of people and makes their goods and services much less expensive than small companies ever could. It's good for the people needing the jobs, it's good for the people wanting the goods or services who couldn't afford them otherwise, and it's much more efficient to attack problems of scale with scale.
OTOH, we have companies like Starbucks and Yum! Brands that give us monotonous flavor from sea to shining sea in lots of little locations. Markets like that would probably be better served by locally owned restaurants, but most Americans seem to like predictability.
OSS makes software a commodity. It works well economically when the quality, the usability, and the stability, of the software are most important and there's plenty of time to build up the functionality. It helps when there's broad enough need, too.
In fast-moving or specialized fields where timeliness of new functionality means big money, OSS will generally lag. Vertical niches that serve fewer users with more depth of expertise demand more refined UIs, more specialized code, and more domain experience. It's not impossible for OSS to compete, but it would be much more difficult.
There's an overhead to open development that is manageable, but which means an OSS project cannot easily match a small, highly skilled programming team in close physical proximity in turnaround time. Of course, someone always manages to do the hard things, so don't count on it going undone just because it's hard.
There are support costs when you need support. For proprietary software, you're often paying for support up front that you never recover. You often also end up paying for more support down the road that your initial investment in the software doesn't include.
The initial investment in proprietary software can be thousands of dollars or millions of dollars to start a business, depending on business type and scale. Both have ongoing costs. Which is more likely to save money, if ongoing support costs are comparable? Which is a small startup more likely to be able to finance?
Truthfully, the Open Source and Free Software probably hasn't cost proprietary vendors much at all. The people who want to pay for support contracts and warranties still do so.
The biggest economic difference is that thousands or tens of thousands of businesses that never would have had a chance to start or that would have started deep in debt are now running software they didn't have to borrow to buy. People are running businesses on software in which they've made little or no investment above the cost of the hardware on which to run it.
These people are loosening the labor market since they're not working for someone else any longer. They pay rents for office space, they need accountants either on staff or on a consulting basis, they need business insurance and legal advice, and they advertise. These are expenses they never had while they were employed elsewhere, and those companies that get paid for rent or for legal, marketing, accounting, or insurance services make more money.
What's better in the long run? Is it better for a few dozen big and a few hundred small software vendors to make the money and grow bigger, or is it better for the money to be spread out among tens of thousands of businesses in thousands of communities?
It's a little extra effort, but using the root account only for the exact changes you're going to make isn't exactly "exotic". The difference in security really is worth it.
I'm not saying I'm always 100% tied to those practices myself, BTW, although I try to be. It's really second nature after a while, especially if you're using sudo. There's still that odd moment when I log straight in as root and go when I'm in a great hurry, but that is the exception. It actually takes mental effort now for me to log into a box as root rather than as a user account and using sudo or su.
I don't believe the motherboard specs or the case design are at all being infringed by PsyStar.
That's kind of the point, don't you think? It's not Apple kit, and that's why it's called a clone or a Hackintosh.
If they were going to use Apple-patented motherboards and Apple-patented cases, the machines wouldn't be made from the dirt cheap commodity parts they are.
So yes, "Mr. I Worked at Apple and Feel the Need to Be Pedantic", Apple has patents on their hardware that have absolutely nothing to do with the functionality that makes them able to run OS X. So what? What patents are PsyStar infringing by using stock PC hardware with and EFI emulator?
C was and is a systems language. Large applications aimed at unskilled end-users with lots of graphics and features were not really part of its design criteria. It's quite possible for a skilled C programmer to use C correctly in the scope and problem domain for which it was designed.
Problems like this stem from people using a language well-suited to OS kernels, system libraries, and bit-twiddling to do things better suited to other languages. The reasons for that involve installed base of C/C++, poor solutions for distributing code without massive runtimes for other languages, the difficulty of mating programs in some other languages to the libraries provided by the OSes for C, the speed sacrifices many other languages make, and the need to run in tiny spaces on some of the targets of programs like Flash.
Certain other languages fit the application domain of Flash much better, but for various reasons Macromedia chose C. Despite being a poor fit for the domain, it was what they felt was the best fit for their needs overall. That's not high praise for C, but a problem for the implementations, performance characteristics, and supporting environments for languages which otherwise would have been better suite.
You might want to consider sudo or consider having two separate sessions open, one root and one not. You can manage the multiple sessions with screen or with multiple virtual consoles. You might also consider not installing Flash and not enabling JavaScript on your browsers installed on servers.
Slashdot Mirror
You'd roll back much the same way, or even perhaps by rebooting into the previous kernel image from disk.
Every production environment I've ever administered had a smaller version set aside for testing. We'd configure the machines identically and just make the cluster smaller. Then we'd test on the test machines any action that was to be made part of the admin process of the production machines. If it passes on the test machine and fails in production, then you didn't make the machines sufficiently similar.
Round robin upgrades take ( ( (time_to_idle + time_to_upgrade + time_to_reboot) * machines ) / 2) on average to get a machine upgraded. If you have a "Critical" upgrade, that might be longer than you want.
Not everyone has the exact same QA requirements you do, either. Some of us are happy with proving that it works, then proving that it worked on the production machine, then resuming our normally scheduled maintenance.
"what do you do when the building catches fire or a tanker truck full of toxic waste hops the curb and plows through the wall of your datacenter"
;-)
Well, that's when you use your 0.0001% of downtime, because you didn't use it for rebooting when you didn't need to.
You mean how my ATA, Serial ATA, Ethernet, and filesystem modules work now? When's the last time you configured a Linux kernel? Sure, there are some things you can't do. Try Minix with a faulty video driver sometime, though, if you think a microkernel is a cure-all.
You can do that with many filesystem drivers. It's a bit harder to do it for the filesystem driver for your boot drive, but that's what initrd images are for.
A microkernel can theoretically do more of this sort of thing, but Linux does a fair amount already. Type "make menuconfig" and poke around a bit, and your eyes might be opened past your dogma and chanting.
It depends on who your boxes are serving. IF you're running boxes for in internal IT department, that's fine. If you drop a port with a 99.9999% uptime guarantee to your client who's using you as his phone or Internet provider, you've either causing him to be down or you're forcing him to switch all of his load over to his other provider.
Can we please kill the 24/7/265 phrasing? Where do you people live that there are 365 weeks in a year?
Why not 24/7/52 or 24/7/4.3/12 or just 24/365 (or 24/365.242 for the pedants).
Yes, but you end up taking one machine out at a time, giving it time to simmer down, and then bringing it back up. If you have 100 boxes and it takes 30 minutes to simmer down to idle, you have 30 * 100, or 3,000 minutes to do the upgrades. On average, your boxes go unpatched for 1500 minutes.
So you have this security hotfix you really want to apply, but it's going to 25 hours on average to fix a box and 50 hours to fix them all.
You could, with ksplice and a good concurrent control system, make your average time to fix 5 minutes in over 80% of kernel upgrade scenarios rated "Critical". Your boxes could still be rebooted on a regular basis later.
Which do you prefer?
If you change something in a configuration that requires a change to the startup script, then you also change the startup script.
A patch to the kernel almost never requires changes to startup scripts. They're not talking about adding new functionality with user-space-addressable interfaces with this tool. They're talking about being able to install about 84% of security hotfixes in a hurry outside your scheduled reboots then rebooting on your regular maintenance schedule.
One of the things telephony servers do these days is handle ports, traffic, or both for live calls.
Hey, as long as it's your calls that get dropped and not mine, it's fine with me if the servers drop calls. If you'd rather not have any calls dropped, then this is nice.
You could take the server to be rebooted out of the load balancer's control, in which case existing calls would eventually end and no new calls would get assigned. You could then reboot once no calls would be effected. This solution, though, leaves the kernels unpatched on average (num_machines * time_to_idle) / 2.
If you combine this hotfix capability with scheduled simmer down reboots, then you can fix all your servers right now, then reboot them one at a time later as well. That gets your security fixes rolled out faster than just waiting for idling down then rebooting one server at a time.
You're right in certain situations, but I don't think this is to keep your computer safe from trojans placed in the drive firmware that report on the data while the computer runs later. It's designed to protect the data on a drive or computer that's stolen while it's turned off. You wouldn't use the computer again if it was recovered for fear of a trojan.
The IO bus being slow gives the processor on the drive plenty of time to get its work done before the results are actually needed.
It'd be much harder for the drive electronics to decrypt the data fast enough if the interface was faster.
When you're decrypting and encrypting on the CPU, not only are you using CPU cycles that could be doing other things, but you're also still waiting on the IO bus to move the data once it's encrypted. You're on the wrong side of the link.
If you're expecting the average credit bureau or government agency employee to remember a 32-character password, you have either wonderful security because nobody will ever get the data or terrible security because there will be a sticky note.
If you're generating a 256-bit AES key from less than 32 bytes of user input, then you're not really getting the full benefit of 256 bits.
No. It isn't. The particular article linked in the summary doesn't make that clear, but it's calculated over again every boot time. This article has at least a bit more info.
Don't leave it in standby mode...
I had this same question, but no. It figures the key at boot time.
Hopefully there's some way to keep the thing from figuring the key once it's stolen, as most people will try to, you know, use the PC as a whole before they resort to stripping the drives out of it.
The news.com story says the hard drive doesn't store the key at all. It's figured during the POST process within the hard drive's BIOS config and isn't known to the drive itself when the power is down.
What it sounds like is that if you keep the computer from booting, like a pre-boot password, the drive is utterly useless to a thief. If they can get it to boot instead of staring blankly at the password prompt, the thing will recalculate the key and go merrily on its way.
Hopefully it figures the key on stored CMOS config values so that if you reset the CMOS to get rid of the boot password it'll still not generate the right key.
Ideally, big companies would do things that only big companies can afford to do and little companies would do what they do best.
Some big companies start from huge investments, but some start out as small shops, too. Google and Yahoo! actually started out as small companies, BTW, and much of their success is thanks in part to OSS. Microsoft also started out small, and one big contract with a nonexclusive buyer clause and royalties involved made them huge. Apple was just two guys about three decades ago. Dell was started in a dorm. These folks got big and then started to do things big companies can do, for better or worse.
Trickle down economics works in some situations, but not all. Some company like Southwest Airlines or Intel employs a lot of people and makes their goods and services much less expensive than small companies ever could. It's good for the people needing the jobs, it's good for the people wanting the goods or services who couldn't afford them otherwise, and it's much more efficient to attack problems of scale with scale.
OTOH, we have companies like Starbucks and Yum! Brands that give us monotonous flavor from sea to shining sea in lots of little locations. Markets like that would probably be better served by locally owned restaurants, but most Americans seem to like predictability.
OSS makes software a commodity. It works well economically when the quality, the usability, and the stability, of the software are most important and there's plenty of time to build up the functionality. It helps when there's broad enough need, too.
In fast-moving or specialized fields where timeliness of new functionality means big money, OSS will generally lag. Vertical niches that serve fewer users with more depth of expertise demand more refined UIs, more specialized code, and more domain experience. It's not impossible for OSS to compete, but it would be much more difficult.
There's an overhead to open development that is manageable, but which means an OSS project cannot easily match a small, highly skilled programming team in close physical proximity in turnaround time. Of course, someone always manages to do the hard things, so don't count on it going undone just because it's hard.
There are support costs when you need support. For proprietary software, you're often paying for support up front that you never recover. You often also end up paying for more support down the road that your initial investment in the software doesn't include.
The initial investment in proprietary software can be thousands of dollars or millions of dollars to start a business, depending on business type and scale. Both have ongoing costs. Which is more likely to save money, if ongoing support costs are comparable? Which is a small startup more likely to be able to finance?
Truthfully, the Open Source and Free Software probably hasn't cost proprietary vendors much at all. The people who want to pay for support contracts and warranties still do so.
The biggest economic difference is that thousands or tens of thousands of businesses that never would have had a chance to start or that would have started deep in debt are now running software they didn't have to borrow to buy. People are running businesses on software in which they've made little or no investment above the cost of the hardware on which to run it.
These people are loosening the labor market since they're not working for someone else any longer. They pay rents for office space, they need accountants either on staff or on a consulting basis, they need business insurance and legal advice, and they advertise. These are expenses they never had while they were employed elsewhere, and those companies that get paid for rent or for legal, marketing, accounting, or insurance services make more money.
What's better in the long run? Is it better for a few dozen big and a few hundred small software vendors to make the money and grow bigger, or is it better for the money to be spread out among tens of thousands of businesses in thousands of communities?
It's a little extra effort, but using the root account only for the exact changes you're going to make isn't exactly "exotic". The difference in security really is worth it.
I'm not saying I'm always 100% tied to those practices myself, BTW, although I try to be. It's really second nature after a while, especially if you're using sudo. There's still that odd moment when I log straight in as root and go when I'm in a great hurry, but that is the exception. It actually takes mental effort now for me to log into a box as root rather than as a user account and using sudo or su.
I don't believe the motherboard specs or the case design are at all being infringed by PsyStar.
That's kind of the point, don't you think? It's not Apple kit, and that's why it's called a clone or a Hackintosh.
If they were going to use Apple-patented motherboards and Apple-patented cases, the machines wouldn't be made from the dirt cheap commodity parts they are.
So yes, "Mr. I Worked at Apple and Feel the Need to Be Pedantic", Apple has patents on their hardware that have absolutely nothing to do with the functionality that makes them able to run OS X. So what? What patents are PsyStar infringing by using stock PC hardware with and EFI emulator?
C was and is a systems language. Large applications aimed at unskilled end-users with lots of graphics and features were not really part of its design criteria. It's quite possible for a skilled C programmer to use C correctly in the scope and problem domain for which it was designed.
Problems like this stem from people using a language well-suited to OS kernels, system libraries, and bit-twiddling to do things better suited to other languages. The reasons for that involve installed base of C/C++, poor solutions for distributing code without massive runtimes for other languages, the difficulty of mating programs in some other languages to the libraries provided by the OSes for C, the speed sacrifices many other languages make, and the need to run in tiny spaces on some of the targets of programs like Flash.
Certain other languages fit the application domain of Flash much better, but for various reasons Macromedia chose C. Despite being a poor fit for the domain, it was what they felt was the best fit for their needs overall. That's not high praise for C, but a problem for the implementations, performance characteristics, and supporting environments for languages which otherwise would have been better suite.
Don't be silly. Humans are quite inflatable. Past a certain point, though, I imagine it gets quite uncomfortable.
You might want to consider sudo or consider having two separate sessions open, one root and one not. You can manage the multiple sessions with screen or with multiple virtual consoles. You might also consider not installing Flash and not enabling JavaScript on your browsers installed on servers.