You can't even load a CA signing cert, or permanently accept a specific cert.
Sure you can. To add a custom CA cert, just make a link to it and have the user explicitly touch that link. Make sure the MIME type for the reply is application/x-x509-ca-cert. Try it and if it doesn't work, shout, but it should.
I'd imagine the same thing will work for a site cert, only with a different MIME type, but I'm not certain. Either way, given that StartCom issues free basic SSL certificates, the only sane reason to use a self-signed cert is for doing over-the-air enrollment with SCEP. For everything else, you should just spend five minutes at http://www.startssl.com/ and create yourself a real SSL cert.
That's great, until your huge refactoring introduces a new bug.
This is why you refactor the code alongside the original. Fix bugs in parallel. When there's a new bug, you roll back to the old, non-refactored code and see if it goes away. If so, you stay on the old, crappy code until you can fix the new, cleaned up code. Then you swap back to the new code. You repeat this testing phase until switching on the new code doesn't introduce any critical regressions, then continue living on the new code for a few months before nuking the old code.
Yes, this is slower than doing development on a single version of the code, but it's a short-term penalty until the code is cleaner and more flexible, at which point you then make up for the period of slowness in the minds of your bosses by proceeding to successfully add twelve new features in a single week---you know, the ones that have been punted for six years because they were too risky to make in the current fragile code base.
The trick is to alternate between rewrites and enhancements. Don't stay focused on rewrites too long or you'll seem unproductive. Don't ignore it for too long or you'll find yourself blocked and eventually become unproductive. The only way to survive is to stay somewhere in the middle.
Artificially bending the market to do what you want it to do is not improving anything.
Spoken like someone who wants to have to view ads every five minutes to continue a phone call. This was proposed a few years ago by one of the telecoms, IIRC. I'm just waiting for the telecoms to start mandating such abuses.
If Apple gave app developers the ability to use this API, do you really think that would not get abused? Are you actually that naive? An API that allows the developer to completely take over whatever the device is doing, and you think this is a positive step forward?
One could presumably choose to hit the home button, thus killing the app, and then delete it. I'm guessing here. I haven't read the patent, merely the summary presented here. As for whether the developers would abuse it, they might, but those apps would quickly get deleted and never run again, and there would be lots of negative ratings as a result. Thus abusing such an API would be counter to the developers' best interests.
I hope Jobs has other things in mind than attempting to actually use this "feature".
I can't imagine this being part of the built-in software., but I can actually see a use for this. If it were an API for those iPhone app writers who make two versions of their app---a free, ad-supported version and a paid version---then it would help support that model.
The other thought that comes to mind is that if Apple has a patent on this and refuses to license that patent, they can in some small way improve the cell phone industry by ensuring that no one ever designs a free phone or a low cost cellular plan that is subsidized in this way.:-D
It's conveniently ignored because these people believe in talking snakes, burning bushes, people being created from ribs, and unicorns.
Catholics generally believe that the Old Testament should be interpreted metaphorically, not literally. And unicorns don't appear anywhere in the Bible, AFAIK.... Try again.
Well, that's partly because a cell phone is the wrong implementation for this sort of thing. I thought about doing something similar a few years ago, but for a laptop. You have a keyboard that hooks into the bottom of the screen, forming a screen-protecting lid to carry it around. When you unlatch it, the hook parts flip upside down and lock into place, forming a keyboard stand. Another stand flips out of the back of the screen to hold it up. This way, you have the simplest, least breakable hinges with no wires running through them. That would eliminate what is probably the second most common cause of laptop failures behind hard drive crashes.
Since you're the one that complained, they will naturally suspect you when the BSA or someone else shows up.
I was going to say just the opposite, recommending that the original poster not wait. Why? Two reasons:
At this point, it isn't just an unknowing violation. It's clear that your management chain knows that this is happening and is deliberately allowing it to continue.
Someone is eventually going to turn them into the BSA, and when that happens, they're going to blame you anyway. Therefore, you might as well be the one who collects the reward.
In your very first contact with them, be sure to ask to be part of the "BSA End User Reward Program", or else you can't collect your reward. You're going to need that reward to tide you over while you look for a new job....:-)
Aaargh. Saw the typo just after I hit submit. I drop calls at a couple of intersections. I was thinking about driving and... you get the idea. Woe be onto anyone who drops cars at an intersection. The other drivers won't be happy with you.
Won't work in the long run, though. CNET just started rolling out a new site (only in certain geographic areas for now) in which they provide comparisons of various providers' service in various areas. Expect this and other sites like it to decimate a lot of the carriers' scare tactics in the not-too-distant future. In my area, guess who has the best coverage? Sprint. Yeah, shocked the heck out of me, too. Either way, my iPhone gets solid enough reception that I only drop cars at a couple of intersections (and I reliably drop calls at each of those intersections, so their towers clearly just aren't aimed right). All in all, it's good enough until LTE rolls out and starts tearing down barriers.
For now only VZW and Sprint have announced they're going to LTE
Uh, no, I'm not sure where you got that, but you're pretty much completely and utterly wrong.
First, Sprint is using WiMax, not LTE for their 4G solution. They are experimenting with LTE, but as recently as a few months ago, their CEO was bashing it publicly.
Furthermore, both AT&T and T-Mobile have made it very clear that they plan to roll out LTE.
I was on Verizon for several years. After a phone went bad (dropped in a stream), I went back to get a new one and they required me to change my cell plan to a new plan where nights and weekends moved an hour later. Well, that was somewhat annoying having it move to 8:00 because most of the people I call are two time zones over. Unfortunately, that phone was an utter piece of excrement and after a few months, it started dropping calls very frequently. I called Verizon to complain, and they said there was a tower down that might be affecting things. A few months later, I moved to a different area where there was no such problem and still dropped calls. After a few months of this, I decided to get another new phone that actually worked.
Now they wanted me to move my nights and weekends to 9:00 P.M. I basically said "No way in hell. Can I get a phone without changing contracts if I pay full price?" They said no, and their only suggestion was to buy a phone on eBay. I looked at my options, priced out what I would get from other carriers, and switched to AT&T the next day. I even kept my old phone number. Even though AT&T's nights and weekends started at 9:00 just like Verizon's, I got so many more minutes than with my Verizon plan that it more than covered the difference. And when Cingular took them over and I changed to a plan with roll-over minutes, the difference became even more dramatic. Now, I'm on an iPhone plan. Every so often, I think about the friends and family who are still stuck on that nickel-and-dime-you-to-death Verizon network, and I feel sorry for them. AT&T sucks, too, of course, but not like Verizon does. It's good to see this news and know that they still haven't changed.
As for me, I can't wait for LTE rollouts to become widespread. At that point, AT&T, T-Mobile, and Verizon will all be using compatible networks and people will be able to switch without changing phones. Then, these companies will have to start actually competing with each other instead of paying lip service to competing. You'll also see massive screaming to put an end to early termination fees if you provide your own equipment. Life will be better. Here's hoping, anyway. The only question is how long it will take before Sprint joins in and makes us a single-standard country as we should be....
Agreed for the most part. As you said, if one were to implement something in Linux, odds are they would implement it as part of the install process, not part of the app, and it would make the permissions changes needed (and do this once), not run the entire tool as root where the user could accidentally save a scanned image as/boot/vmlinuz or whatever....:-)
On the other hand, one could reasonably ask why xsane should need elevated privileges to capture and control a non-keyboard, non-disk USB device in the first place. I tend to prefer the Mac OS X policy on this one. In Mac OS X, an application can control a scanner from user space with ordinary user (not admin) privileges. That seems much more sensible to me as a general policy. Secure things that reasonably need to be secured for reasons of data privacy (disks and keyboards) or system protection (certain parts of the filesystem hierarchy such as/etc,/usr, and/var), let daemons request exclusive access for devices where it is needed (like printers), and leave things that don't really need a security policy unsecured.
Unless, of course, you're talking about an ancient SCSI scanner, in which case I can understand the desire to keep those interfaces reserved for use by code running as root, if only because of the complexity of sorting out these rights relative to other SCSI devices like disks....
The vast majority of helper tools I've seen are application-specific. There's nothing stopping you from running something built-in through that mechanism, but it isn't commonly done, judging from the apps I've seen. That said, your mileage may vary.:-)
I'm not sure what way you think I think heat pumps work.... I'm just talking about a reversible air conditioner hooked up to forced air ducts except that the waste heat would be dumped in the dryer when it is running instead of outdoors, and while the A/C is off, the waste cooling is dumped outdoors.
I totally agree about refrigerators. That's another application where you could significantly improve things by adding a few more freon lines and doing some smart valve work. For that matter, with a refrigerator, in many houses, it would be trivial to put the coils outside because the refrigerator is against an exterior wall anyway.... Not much inefficiency at all by doing that. It's a couple of holes in the wall and an extra few feet of flexible freon lines so that you can pull the thing out to service it.
Regarding climate control for individual rooms, a much easier way to handle that is by using a series of thermostats in each room and electrically controlled baffles on the ducts. You then set thresholds for maximum and minimum temperature allowed, plus a second set of thresholds for preferred temperature. If a significant number of rooms go outside the preferred range or if a single room goes outside the absolute limits, the A/C or heat kicks on. Then, the system looks at the rooms and checks to see which rooms need heat/cooling. It then opens up the baffles for the rooms that need it and closes the baffles for rooms that don't. An ideal system has a variable baffle that can open... say 25% of the way in the room that is just a little off and 100% of the way in the room that is way off. That said, the same net effect can also be achieved with cheaper hardware by simply closing off the baffle for each room as it reaches the target temperature.
An ideal system also detects if one room is consistently getting too hot or too cold and uses that room as the key for driving the blower, but not the compressor. The average temperature should drive the compressor (or gas), while the blower should be driven by the peak or trough temperatures in individual rooms. Hot spot/cold spot problems with HVAC are generally caused by having an oversized system that cools or heats too efficiently. The system kicks out because the areas near the thermostats have gotten cool or warm long before enough air has moved to evenly distribute the cooling throughout the building. (HVAC contractors usually blame this on poor placement of the thermostat, but that's a load of crap. If you moved that thermostat because it was kicking the system out too early, then you'd just be moving the problem around. Instead of some other spot not getting cool enough, the spot where the thermostat used to be gets too cold.... By using the average temperatures to drive the compressor, you get the temperature right on average, and by using the peaks and troughs to drive the fans, you ensure that hot and cold spots average out (assuming good duct placement). Oh, and all baffles should be open when the compressor or gas is off. This maximizes the fans' ability to redistribute air and reduce temperature variation.
Yes, I've put way too much thought into the way I would design an HVAC system.:-D
For the person who chooses not to consume pirated content, the ideal is a world where producers are maximized, and pirates exist only to make producers greatful for paying customers and provide incentive toward price moderation.
Sort of. MPAA members are like the corporations to whom workers owe their souls from 9 to 5. Pirates are like the unions. They prevent the MPAA from having so much control that they start to abuse consumers.
I'll explain. The MPAA members, like any corporation, have no real incentive to do any more than is necessary for the consumer. Their natural tendency is to charge the highest price they can, offer as little as they can get away with, and maximize profits by forcing people to repeatedly purchase the same content. If they could, they would use an all-rental model as the DIVX debacle demonstrated, and nobody would ever own anything. Consumers rejected that because they had DVDs as an alternative, but there's nothing preventing the industry in all its near-suicidal goodness from moving steadily toward that model.
The existence of pirates makes such goals impossible. Pirates find ways around DRM that limits rentals to being rentals. The analog hole is the last guaranteed trivial way to achieve this, and as such, it is the last resort of those who feel we should be allowed to own content. Similarly, it provides limits on how high the price of media can get because if it gets too expensive, people will just pirate it.
The real problem here is the cost of making movies. We live in an era where the technical costs of making a movie are rapidly dropping, but the cost of hiring big name stars remains insanely high, and a significant number of people think that these big names are important when choosing what movie to watch because they are a sign that the movie has the full support of a major studio and is thus less likely to suck. While there is some truth to this, that means that it is nearly impossible to significantly increase competition due to scarcity of that resource. So no matter how abusive the MPAA member companies become, there's no reason to believe that new competition will come in to fix things---no reason to believe that the free market will correct the gouging. Add to this the nature of the relationships between studios and the movie theaters, and you have a very, very difficult market to enter without tying yourself somehow to one of the major studios (e.g. the Disney/Pixar relationship before Disney bought them).
In the absence of a free market, something has to provide controls over the operation of the monopoly or oligopoly. Piracy provide those controls. In the absence of piracy, it would necessary for the government to provide those controls to protect consumers from the industry, and I'm not convinced that our politicians have the intestinal fortitude to take on the MPAA members and limit them....
Im not saying that piracy is good---it isn't. I'm merely saying I'm certain that a lack of piracy would lead to an industry that is so abusive that it would make the current industry seem like Mother Teresa.
How is this different from the Linux sudo model or Apple's AuthorizationExecuteWithPrivileges? With that model, you start a process under sudo and it gets admin rights for the duration of the process.
With AuthorizationExecuteWithPrivileges, privileges are elevated for a single helper binary that (assuming it was written well) is a narrowly defined piece of code that does the task requiring elevated privileges and then quits, shedding any additional privileges it may have obtained. This makes a much smaller target for attack because in order to compromise the security of the root helper, you would have to first compromise the non-root application sufficient to execute arbitrary code, then find a second exploitable vulnerability in the much smaller root helper code. By contrast, if you elevate the privileges of the main process, you just have to wait for the user to do something that elevates privileges on the process, then compromise the much larger, more easily attacked main application process.
With sudo, reality is somewhere in-between, because you could conceivably type "sudo -s" or "sudo/usr/bin/startx", but I think you'll still agree that for most practical uses, running sudo is safer than su because your shell isn't elevated in privileges and you can't hose certain things without explicitly requesting extra privileges with sudo.
As opposed to Sudo, which doesn't check the signature of the executable being run at all (at least AFAIK)?
I was thinking more of the ServiceManagement framework in Mac OS X (new in 10.6), whose SMJobBless function requires the helper to be signed and provides additional security around that signature.
It depends on where you live, but out here on the West (U.S.) Coast, the prevalent heating fuel is natural gas...
The ironic part of that is that electricity is probably cheaper at this point, given how much natural gas prices have increased.
I've always thought someone should design a clothes dryer based on tying into your home's heat pump system. Have a three-way switching valve on the freon lines. When you're heating clothes, you're either cooling your house (if it needs to be cooled further) or cooling the outside coils. That way, for half the year, in addition to making your dryer cost less, you're also making your air conditioning cost less.... Not sure how feasible this would be in terms of getting the interior of the clothes dryer up to the needed temperatures, though.
This patent was filed more than four years ago, in April of 2005. This filing predates Red Hat's announcement of PolicyKit by about a year. And PolicyKit probably wouldn't cover this even if it predated the Microsoft concept because it doesn't meet the "automatic" criteria, AFAIK.
And for anyone thinking that this is a patent on sudo, it is not. It also is not a patent on Apple's AuthorizationExecuteWithPrivileges, though it is much closer to that. It differs from the Mac OS X design in that it:
Executes when the privilege violation occurs without requiring the app to be aware. This is, of course, a really dangerous idea for reasons I'll get into momentarily.
Displays a list of accounts with the appropriate privilege. This is arguably not that useful on most OSes, but it is important if you have a rights system that is way too complicated....
It further differs from sudo in that it presents a GUI (in addition to the two ways above).
Regarding launching a GUI window when a privilege violation occurs, this is precisely why Windows got the "Allow or Deny" reputation it got. You really don't want to authorize every little action. Further, when it comes to a typical desktop environment, a rights system should not be so complex that there are more than about two classes of users anyway---those who have the rights to modify system files and those who are limited to their own files. Therefore, something like sudo, PolicyKit, AuthorizationExecuteWithPrivileges, etc. is generally a much better design because it puts the application in control of the experience and allows you to run a series of actions with elevated privileges, forcing apps to be designed with proper privilege separation, and reserving elevated privileges for only the minimum portion of the code necessary. The Windows "automatically throw up a GUI when you get a permission denied" design has a significant risk of creating user indifference towards important security notifications, which results in a significantly less secure system in the long run.
Also, I'm under the impression (based on the patent) that Windows is temporarily elevating the privileges of the application itself, which means that you now have a much larger chunk of code that must be checked for security holes, lest malicious individuals co-opt the application for nefarious purposes. Such a design also makes it very hard to adequately use code signing to ensure the authenticity of the code running with elevated privileges, thus allowing security holes in the app to readily be exploited and turned into the equivalent of root holes just by the user clicking "Allow".
In short, it's a terrible security design filled with myriad fundamental design flaws, all codified in a patent filing for all to mock. I certainly won't lose sleep over this patent getting approved. No one should reasonably want to implement the sort of security architecture that would violate this patent.
Slashdot Mirror
Sure you can. To add a custom CA cert, just make a link to it and have the user explicitly touch that link. Make sure the MIME type for the reply is application/x-x509-ca-cert. Try it and if it doesn't work, shout, but it should.
I'd imagine the same thing will work for a site cert, only with a different MIME type, but I'm not certain. Either way, given that StartCom issues free basic SSL certificates, the only sane reason to use a self-signed cert is for doing over-the-air enrollment with SCEP. For everything else, you should just spend five minutes at http://www.startssl.com/ and create yourself a real SSL cert.
Huh? Safari on iPhone definitely supports JavaScript and SSL.
This is why you refactor the code alongside the original. Fix bugs in parallel. When there's a new bug, you roll back to the old, non-refactored code and see if it goes away. If so, you stay on the old, crappy code until you can fix the new, cleaned up code. Then you swap back to the new code. You repeat this testing phase until switching on the new code doesn't introduce any critical regressions, then continue living on the new code for a few months before nuking the old code.
Yes, this is slower than doing development on a single version of the code, but it's a short-term penalty until the code is cleaner and more flexible, at which point you then make up for the period of slowness in the minds of your bosses by proceeding to successfully add twelve new features in a single week---you know, the ones that have been punted for six years because they were too risky to make in the current fragile code base.
The trick is to alternate between rewrites and enhancements. Don't stay focused on rewrites too long or you'll seem unproductive. Don't ignore it for too long or you'll find yourself blocked and eventually become unproductive. The only way to survive is to stay somewhere in the middle.
Spoken like someone who wants to have to view ads every five minutes to continue a phone call. This was proposed a few years ago by one of the telecoms, IIRC. I'm just waiting for the telecoms to start mandating such abuses.
One could presumably choose to hit the home button, thus killing the app, and then delete it. I'm guessing here. I haven't read the patent, merely the summary presented here. As for whether the developers would abuse it, they might, but those apps would quickly get deleted and never run again, and there would be lots of negative ratings as a result. Thus abusing such an API would be counter to the developers' best interests.
I can't imagine this being part of the built-in software., but I can actually see a use for this. If it were an API for those iPhone app writers who make two versions of their app---a free, ad-supported version and a paid version---then it would help support that model.
The other thought that comes to mind is that if Apple has a patent on this and refuses to license that patent, they can in some small way improve the cell phone industry by ensuring that no one ever designs a free phone or a low cost cellular plan that is subsidized in this way. :-D
Oh, you mean Dick Cheney's new company?
Catholics generally believe that the Old Testament should be interpreted metaphorically, not literally. And unicorns don't appear anywhere in the Bible, AFAIK.... Try again.
What are you talking about? iPhone OS has supported that since at *least* 3.0. You just enable Airplane mode first, then turn Wi-Fi back on.
Kind of, but that still has a nontrivial hinge design.
Finally found one linked from the web. http://reviews.cnet.com/cell-phones/at-t-formerly-cingular/4599-6454_7-32137726.html?carrier=&mode=voice
Well, that's partly because a cell phone is the wrong implementation for this sort of thing. I thought about doing something similar a few years ago, but for a laptop. You have a keyboard that hooks into the bottom of the screen, forming a screen-protecting lid to carry it around. When you unlatch it, the hook parts flip upside down and lock into place, forming a keyboard stand. Another stand flips out of the back of the screen to hold it up. This way, you have the simplest, least breakable hinges with no wires running through them. That would eliminate what is probably the second most common cause of laptop failures behind hard drive crashes.
I was going to say just the opposite, recommending that the original poster not wait. Why? Two reasons:
In your very first contact with them, be sure to ask to be part of the "BSA End User Reward Program", or else you can't collect your reward. You're going to need that reward to tide you over while you look for a new job.... :-)
Aaargh. Saw the typo just after I hit submit. I drop calls at a couple of intersections. I was thinking about driving and... you get the idea. Woe be onto anyone who drops cars at an intersection. The other drivers won't be happy with you.
Won't work in the long run, though. CNET just started rolling out a new site (only in certain geographic areas for now) in which they provide comparisons of various providers' service in various areas. Expect this and other sites like it to decimate a lot of the carriers' scare tactics in the not-too-distant future. In my area, guess who has the best coverage? Sprint. Yeah, shocked the heck out of me, too. Either way, my iPhone gets solid enough reception that I only drop cars at a couple of intersections (and I reliably drop calls at each of those intersections, so their towers clearly just aren't aimed right). All in all, it's good enough until LTE rolls out and starts tearing down barriers.
Uh, no, I'm not sure where you got that, but you're pretty much completely and utterly wrong.
First, Sprint is using WiMax, not LTE for their 4G solution. They are experimenting with LTE, but as recently as a few months ago, their CEO was bashing it publicly.
Furthermore, both AT&T and T-Mobile have made it very clear that they plan to roll out LTE.
I was on Verizon for several years. After a phone went bad (dropped in a stream), I went back to get a new one and they required me to change my cell plan to a new plan where nights and weekends moved an hour later. Well, that was somewhat annoying having it move to 8:00 because most of the people I call are two time zones over. Unfortunately, that phone was an utter piece of excrement and after a few months, it started dropping calls very frequently. I called Verizon to complain, and they said there was a tower down that might be affecting things. A few months later, I moved to a different area where there was no such problem and still dropped calls. After a few months of this, I decided to get another new phone that actually worked.
Now they wanted me to move my nights and weekends to 9:00 P.M. I basically said "No way in hell. Can I get a phone without changing contracts if I pay full price?" They said no, and their only suggestion was to buy a phone on eBay. I looked at my options, priced out what I would get from other carriers, and switched to AT&T the next day. I even kept my old phone number. Even though AT&T's nights and weekends started at 9:00 just like Verizon's, I got so many more minutes than with my Verizon plan that it more than covered the difference. And when Cingular took them over and I changed to a plan with roll-over minutes, the difference became even more dramatic. Now, I'm on an iPhone plan. Every so often, I think about the friends and family who are still stuck on that nickel-and-dime-you-to-death Verizon network, and I feel sorry for them. AT&T sucks, too, of course, but not like Verizon does. It's good to see this news and know that they still haven't changed.
As for me, I can't wait for LTE rollouts to become widespread. At that point, AT&T, T-Mobile, and Verizon will all be using compatible networks and people will be able to switch without changing phones. Then, these companies will have to start actually competing with each other instead of paying lip service to competing. You'll also see massive screaming to put an end to early termination fees if you provide your own equipment. Life will be better. Here's hoping, anyway. The only question is how long it will take before Sprint joins in and makes us a single-standard country as we should be....
But not nearly as quickly because most electricity is made from other things.
Agreed for the most part. As you said, if one were to implement something in Linux, odds are they would implement it as part of the install process, not part of the app, and it would make the permissions changes needed (and do this once), not run the entire tool as root where the user could accidentally save a scanned image as /boot/vmlinuz or whatever.... :-)
On the other hand, one could reasonably ask why xsane should need elevated privileges to capture and control a non-keyboard, non-disk USB device in the first place. I tend to prefer the Mac OS X policy on this one. In Mac OS X, an application can control a scanner from user space with ordinary user (not admin) privileges. That seems much more sensible to me as a general policy. Secure things that reasonably need to be secured for reasons of data privacy (disks and keyboards) or system protection (certain parts of the filesystem hierarchy such as /etc, /usr, and /var), let daemons request exclusive access for devices where it is needed (like printers), and leave things that don't really need a security policy unsecured.
Unless, of course, you're talking about an ancient SCSI scanner, in which case I can understand the desire to keep those interfaces reserved for use by code running as root, if only because of the complexity of sorting out these rights relative to other SCSI devices like disks....
The vast majority of helper tools I've seen are application-specific. There's nothing stopping you from running something built-in through that mechanism, but it isn't commonly done, judging from the apps I've seen. That said, your mileage may vary. :-)
I'm not sure what way you think I think heat pumps work.... I'm just talking about a reversible air conditioner hooked up to forced air ducts except that the waste heat would be dumped in the dryer when it is running instead of outdoors, and while the A/C is off, the waste cooling is dumped outdoors.
I totally agree about refrigerators. That's another application where you could significantly improve things by adding a few more freon lines and doing some smart valve work. For that matter, with a refrigerator, in many houses, it would be trivial to put the coils outside because the refrigerator is against an exterior wall anyway.... Not much inefficiency at all by doing that. It's a couple of holes in the wall and an extra few feet of flexible freon lines so that you can pull the thing out to service it.
Regarding climate control for individual rooms, a much easier way to handle that is by using a series of thermostats in each room and electrically controlled baffles on the ducts. You then set thresholds for maximum and minimum temperature allowed, plus a second set of thresholds for preferred temperature. If a significant number of rooms go outside the preferred range or if a single room goes outside the absolute limits, the A/C or heat kicks on. Then, the system looks at the rooms and checks to see which rooms need heat/cooling. It then opens up the baffles for the rooms that need it and closes the baffles for rooms that don't. An ideal system has a variable baffle that can open... say 25% of the way in the room that is just a little off and 100% of the way in the room that is way off. That said, the same net effect can also be achieved with cheaper hardware by simply closing off the baffle for each room as it reaches the target temperature.
An ideal system also detects if one room is consistently getting too hot or too cold and uses that room as the key for driving the blower, but not the compressor. The average temperature should drive the compressor (or gas), while the blower should be driven by the peak or trough temperatures in individual rooms. Hot spot/cold spot problems with HVAC are generally caused by having an oversized system that cools or heats too efficiently. The system kicks out because the areas near the thermostats have gotten cool or warm long before enough air has moved to evenly distribute the cooling throughout the building. (HVAC contractors usually blame this on poor placement of the thermostat, but that's a load of crap. If you moved that thermostat because it was kicking the system out too early, then you'd just be moving the problem around. Instead of some other spot not getting cool enough, the spot where the thermostat used to be gets too cold.... By using the average temperatures to drive the compressor, you get the temperature right on average, and by using the peaks and troughs to drive the fans, you ensure that hot and cold spots average out (assuming good duct placement). Oh, and all baffles should be open when the compressor or gas is off. This maximizes the fans' ability to redistribute air and reduce temperature variation.
Yes, I've put way too much thought into the way I would design an HVAC system. :-D
Sort of. MPAA members are like the corporations to whom workers owe their souls from 9 to 5. Pirates are like the unions. They prevent the MPAA from having so much control that they start to abuse consumers.
I'll explain. The MPAA members, like any corporation, have no real incentive to do any more than is necessary for the consumer. Their natural tendency is to charge the highest price they can, offer as little as they can get away with, and maximize profits by forcing people to repeatedly purchase the same content. If they could, they would use an all-rental model as the DIVX debacle demonstrated, and nobody would ever own anything. Consumers rejected that because they had DVDs as an alternative, but there's nothing preventing the industry in all its near-suicidal goodness from moving steadily toward that model.
The existence of pirates makes such goals impossible. Pirates find ways around DRM that limits rentals to being rentals. The analog hole is the last guaranteed trivial way to achieve this, and as such, it is the last resort of those who feel we should be allowed to own content. Similarly, it provides limits on how high the price of media can get because if it gets too expensive, people will just pirate it.
The real problem here is the cost of making movies. We live in an era where the technical costs of making a movie are rapidly dropping, but the cost of hiring big name stars remains insanely high, and a significant number of people think that these big names are important when choosing what movie to watch because they are a sign that the movie has the full support of a major studio and is thus less likely to suck. While there is some truth to this, that means that it is nearly impossible to significantly increase competition due to scarcity of that resource. So no matter how abusive the MPAA member companies become, there's no reason to believe that new competition will come in to fix things---no reason to believe that the free market will correct the gouging. Add to this the nature of the relationships between studios and the movie theaters, and you have a very, very difficult market to enter without tying yourself somehow to one of the major studios (e.g. the Disney/Pixar relationship before Disney bought them).
In the absence of a free market, something has to provide controls over the operation of the monopoly or oligopoly. Piracy provide those controls. In the absence of piracy, it would necessary for the government to provide those controls to protect consumers from the industry, and I'm not convinced that our politicians have the intestinal fortitude to take on the MPAA members and limit them....
Im not saying that piracy is good---it isn't. I'm merely saying I'm certain that a lack of piracy would lead to an industry that is so abusive that it would make the current industry seem like Mother Teresa.
With AuthorizationExecuteWithPrivileges, privileges are elevated for a single helper binary that (assuming it was written well) is a narrowly defined piece of code that does the task requiring elevated privileges and then quits, shedding any additional privileges it may have obtained. This makes a much smaller target for attack because in order to compromise the security of the root helper, you would have to first compromise the non-root application sufficient to execute arbitrary code, then find a second exploitable vulnerability in the much smaller root helper code. By contrast, if you elevate the privileges of the main process, you just have to wait for the user to do something that elevates privileges on the process, then compromise the much larger, more easily attacked main application process.
With sudo, reality is somewhere in-between, because you could conceivably type "sudo -s" or "sudo /usr/bin/startx", but I think you'll still agree that for most practical uses, running sudo is safer than su because your shell isn't elevated in privileges and you can't hose certain things without explicitly requesting extra privileges with sudo.
I was thinking more of the ServiceManagement framework in Mac OS X (new in 10.6), whose SMJobBless function requires the helper to be signed and provides additional security around that signature.
The ironic part of that is that electricity is probably cheaper at this point, given how much natural gas prices have increased.
I've always thought someone should design a clothes dryer based on tying into your home's heat pump system. Have a three-way switching valve on the freon lines. When you're heating clothes, you're either cooling your house (if it needs to be cooled further) or cooling the outside coils. That way, for half the year, in addition to making your dryer cost less, you're also making your air conditioning cost less.... Not sure how feasible this would be in terms of getting the interior of the clothes dryer up to the needed temperatures, though.
This patent was filed more than four years ago, in April of 2005. This filing predates Red Hat's announcement of PolicyKit by about a year. And PolicyKit probably wouldn't cover this even if it predated the Microsoft concept because it doesn't meet the "automatic" criteria, AFAIK.
And for anyone thinking that this is a patent on sudo, it is not. It also is not a patent on Apple's AuthorizationExecuteWithPrivileges, though it is much closer to that. It differs from the Mac OS X design in that it:
It further differs from sudo in that it presents a GUI (in addition to the two ways above).
Regarding launching a GUI window when a privilege violation occurs, this is precisely why Windows got the "Allow or Deny" reputation it got. You really don't want to authorize every little action. Further, when it comes to a typical desktop environment, a rights system should not be so complex that there are more than about two classes of users anyway---those who have the rights to modify system files and those who are limited to their own files. Therefore, something like sudo, PolicyKit, AuthorizationExecuteWithPrivileges, etc. is generally a much better design because it puts the application in control of the experience and allows you to run a series of actions with elevated privileges, forcing apps to be designed with proper privilege separation, and reserving elevated privileges for only the minimum portion of the code necessary. The Windows "automatically throw up a GUI when you get a permission denied" design has a significant risk of creating user indifference towards important security notifications, which results in a significantly less secure system in the long run.
Also, I'm under the impression (based on the patent) that Windows is temporarily elevating the privileges of the application itself, which means that you now have a much larger chunk of code that must be checked for security holes, lest malicious individuals co-opt the application for nefarious purposes. Such a design also makes it very hard to adequately use code signing to ensure the authenticity of the code running with elevated privileges, thus allowing security holes in the app to readily be exploited and turned into the equivalent of root holes just by the user clicking "Allow".
In short, it's a terrible security design filled with myriad fundamental design flaws, all codified in a patent filing for all to mock. I certainly won't lose sleep over this patent getting approved. No one should reasonably want to implement the sort of security architecture that would violate this patent.
Or the "what". Substitute "when" or "whether" and "it" makes sense, too.