I don't understand how they messed it up so badly. It's an idea they first tried in MS Office for Mac, and it was actually pretty useful in the implementation there -- they added a context-sensitive floating window that contained collapsable sections for each of several functional areas. It essentially made toolbars context-sensitive, floating, and collapsable. But they didn't take away the menu bar when they did it -- you could still get at everything via the menus. And they didn't try to put context-insensitive things, like "Save" or "Options" into the new floating window.
But then Office 2007 came out and said "What if we took away toolbars AND menus. That would be twice as cool as what we did in the Mac version 4 years ago." I've long since given up on using Word for document creation -- the last version I used regularly was Word 5.0a -- but just supporting other people in Office 2007 makes my head hurt.
So apparently it's not valid to complain that the new standard shouldn't need to support "truncateFontHeightsLikeWP6" in the first place? Wouldn't it be technologically superior to require MS Word to emulate "truncateFontHeightsLikeWP6" using standard formatting directives, rather than forcing every other implementer to code for compatibility with some file format that isn't even part of the spec?
Try this one one for size: "15 years ago we had a file format that stored text using EBCDIC encoding. While we no longer write any files using this encoding, we propose that the new standard file format include an EBCDIC mode. We realize that traditional arguments for "backward compatibility" don't apply -- obviously none of our 15-year-old products ever produced any output in the new file format being proposed -- and we concede that we could just convert to UTF-8 encoding when saving old documents into the new format. But such conversions would require more work on our part than simply adding another encoding mode to the new file format and reusing our existing code to render in that mode. We acknowledge that this formatting directive will only benefit our product, as no one else can read our 15-year-old, unpublished format, so we'll note that the EBCDIC mode is deprecated. In spite of that note however, we will generate new files using EBCDIC mode, and therefore competing implementations must implement it as well to be functionally compliant."
see firewire vs USB as a good example of a wonderful tech being maimed by its own creators
While I agree that FireWire has more expensive licensing than USB, that's not the only reason USB is more popular. FireWire simply requires more expensive and physically/electrically larger hardware to implement, making it the wrong choice for low-performance devices (like consumer flash drives, your cell phone, etc.) regardless of licensing issues.
Trust is antithetical to verification. It may be wise to place limits on your trust, and to take action to verify compliance when that those limits are exceeded. And finding that verification routinely falls one way or the other, you may even adjust the limits of your trust accordingly. But don't pretend that verification is part of trust -- verification is an action you take when you don't trust the presumed analysis of a situation.
You're disappointed that your level of trust was too high. And you may even be wise to reduce your level of trust in the future. But realize that you're no longer trusting as soon as you require verification.
For games with a single display, it's trivial. Just buy more keyboards and map the different players to different portions of the keyspace. I've played 2-player games that are designed to run this way even with only 1 keyboard. But console systems require you to buy extra controllers to play 4-player games, so I don't see why that would count as an extra limitation on PC systems.
As far as split-screen play goes, if you only wanted to give each player a 120x110 pixel display I'll bet any graphics card on the market could run 4 instances of the game display simultaneously. Even at 1080p you only get 480x270 per player, which still doesn't require any phenomenal processing capabilities, particularly when you consider that many aspects, like texture maps, could be shared between instances.
I realize that not many games are designed to allow multiple players on a single system, but that's a result of deliberate design, not of technical limitations of the platform. There are merits to both types of systems, and the availability of single-system, multi-player games for consoles is a plus for consoles if that's something you value. But it's silly to claim that PC systems are technically incapable of running multi-player games without multiple boxes.
Are you seriously suggesting that improved communications technology *wouldn't* improve the local economy? Did you miss the last 100 years of human existence?
If these people were starving in the street you're right, soup kitchens would be more useful. But that's not the case here -- the intent is to improve the local economy to be on-par with the rest of the nation. The people this project is intended to help aren't homeless, and many aren't even unemployed, they're just poor.
Having things like, the ability to use their Internet connection to be a work-at-home call-center rep, cheaper residential telephone service, the ability to easily search for jobs outside their immediate geographic area, or even just general access to the web and email, could all make practical improvements in the lives people who did not previously have access to cheap, moderate-speed Internet services.
A) To the best of my knowledge is no theory that places even moderately strict bounds on the Rho method. That was the point of the original post. B) RSA has discontinued their factoring challenges.
Authentication does not necessarily mean that those around me know who I am. Take a credit card transaction as an example -- the credit card company wants to know that I'm an authorized user of the card I hold. The merchant wants to know that my credit card company will pay them on my behalf. But the merchant doesn't have any fundamental interest* in knowing who I am -- only the credit card company does. So if I authenticate to the credit card company, and the credit card company authenticates to the merchant, we can all feel safe, and I can remain anonymous with respect to the merchant.
It's certainly possible to design the system to provide strong authentication for a variety of purposes without compromising privacy or even anonymity. Whether or not anyone will bother to do that/allow that to happen is debatable, but you shouldn't necessarily relate the ability to authenticate with an inability to provide privacy.
*I know they might like to know who I am for marketing purposes and whatnot, but they have no interest with respect to conducting a safe and reliable financial transaction.
Depending on one's situation you could just as accurately say: When you career won't support you, your family might. MIGHT. Gen Z may well figure out that "family" bails out on you when life changes occur, whereas a decent friend will stick with you. Relying on family is not a good way to go as far as I've observed, so I wouldn't say that Anonymous Coward has his stuff together just yet.
Or for that matter: When you career won't support you, your family or friends might. MIGHT. Gen Z may well figure out that "family" and "friends" bail out on you when life changes occur, and you can't depend on anyone but yourself. Relying on family and friends is not a good way to go as far as I've observed, so I wouldn't say that Anonymous Coward has his stuff together just yet.
I'm glad your family works for you. And I'm sorry your friends didn't. But it's naive to assume that your life is a valid model for all those around you. You don't even have anecdotes plural, let alone "data".
Yes, they can. States are free to run their elections by any means they see fit -- some states voluntarily choose to follow guidelines set by federal bodies, but they are under no obligation to do so. For one thing, most elections are not federal in nature, and therefore the federal government has no legitimate interest in how they are run. That includes the presidential election, as there is no requirement for a popular vote. Even for Representatives and Senators, for which the federal government does have some control over elections, there still aren't rules about which particular voting machines you can use, nor any requirement that a machine be used at all.
Both SIP and IAX are UDP-based, and won't tunnel via SSH's TCP tunnels. And UDP->TCP encapsulation is a bad idea for things like VoIP; you probably don't want to drop 2 seconds of the conversation just because 1 packet got mangled, and you sure don't want to waste bandwidth re-transmitting things that will never be played back.
However, IPSec's 3DES-CBC and AES-CBC modes both re-initialize for each datagram, so it can handle encryption on UDP packets without requiring in-order, complete reception or retransmission. And you can do IPSec pretty transparently at your gateway even in the generating device -- say a desk phone -- doesn't do IPSec or uses a wide range of ports.
You do *not* needs DHCP to get DNS addresses under IPv6. See http://tools.ietf.org/html/draft-ietf-dnsop-ipv6-dns-configuration-06 -- the RA method is site-local not link-local, so it works across routers if they are configured correctly. And once you have DNS you can configure everything else via SRV records.
On the "MAC addresses change" note, an ease solution is to simply change the MAC address of the replacement card to match the old one. Since the old one is no longer in use there's no conflict, and then there's no external change to be made anywhere on the network. You've have to type the new MAC address in somewhere to get the DHCP server to hand out the same address, so you might as well just do it locally.
Likewise DHCP is hardly the only option for reverse-DNS registration; it doesn't take a whole lot of scripting to submit the local hostname to some remote service that can update DNS. We've decided the DHCP server is a good place to do this, because it knows both those items and is centrally administered, but it's certainly not complicated to replicate with other mechanisms.
Now, you may prefer to do things via DHCP, and I wouldn't necessarily blame you, but it's not strictly necessary, and for many simple networks -- say home routers -- there's no reason for DHCP at all.
However, that is no longer how processors function - they are now two slower processors working together.
But there aren't two slower processors. Core for core modern processors are faster then 5-year-old processors. Even if they have lower clock speeds.
And while the average home user probably can't use 16 cores, they can use two cores. Their foreground app can get 100% of the cycles on core 1, and all the kernel-space calls can run on core 2 -- all the overhead of USB, TCP/IP, etc. can happen on a second core so the first core can run the user app exclusively.
A) The average office building could have the A/C off 65% of every week without affecting perceived quality of service. If IT had those kinds of maintenance windows on an email server I bet you'd never notice the downtime. Even for always-on systems like data-center cooling, the A/C undergoes regular maintenance and downtime, which is why no one installs a data center with a single cooling system.
B) Chiller maintenance is big business and even the techs they actually send out to do it make good money, on-par with grunt-level IT staff. And their bosses make more, just like yours do. The contracted cleaning crew making $8/hour is not doing your chiller maintenance (or if they are, you're gonna be in trouble next summer).
C) Comparing an "email service" to "lights" is like saying "but my bicycle never needs an oil change". Electric lights are 100+ year old technology with exactly one dependency -- electricity (and not even clean power at that) -- and one failure mode -- irreparably damaged. If your email server only needed electricity and could simply be replaced with a spare when it failed I'll bet IT could keep a few on-hand and give you similar reliability.
I can understand why people object to obvious patents, or to patents with not demonstrable implementation, but for all the whining people do about the evils of "software patents" I don't think people understand how similar the situation is with plain old mechanical patents. There are just as many bad patents on physical devices; why is the concern here only about software?
And as the parent suggests, I think a shorter term for software patents is a great idea. 17 months is probably a bit short -- I doubt many good ideas could make it from proof-of-concept to market in under 9-12 months, which doesn't leave a lot of protection time left on the patent. But certainly there's some single-digit number of years that would provide a workable balance.
For that matter I think the term of a patent could be variable in general. We'd want limits on the valid term range, but based on the patent type and things like regulatory barriers to market entry (for example in drugs, where drug X must get FDA approval which takes 2 years, but drug Generic-X can use the previous approval -- the government provides a barrier to market entry that is unique to the applicant and doesn't apply to other in the industry) we could certainly pick a more suitable term for almost all patents.
It doesn't have to be; the default password could be set (or even just randomized) on installation, or the account marked for "must change password" if the auth mechanism supports that concept. Either way users would be to required to pick a password before logging in. That obviously doesn't stop anyone from using bad passwords, but you can most certainly stop default passwords -- they've always been a bad idea from lazy installation systems.
Without commenting on whether or not seatbelts should be mandatory, I must question your logic. How are you drawing the line that makes "require seatbelts to save money" reasonable but makes these similar situations absurd? Or would you really apply the same logic to these situations?
Riding a motorcycle increases your chance of serious injury when compared to a riding in a car which increases the cost of accidents for the person at fault and increases the need for medical attention from the already limited pool of medics; we should therefore outlaw motorcycles are require people to ride only in cars.
Riding in a car increases your risk of serious injury when compared to a riding in a bus, which increases the cost of accidents for the person at fault and increases the need for medical attention from the already limited pool of medics; we should therefore require people to ride only in buses.
Poor eating habits increase your chance of chronic illness, which increases the cost of medial care. We should therefore mandate healthy eating habits.
That's the ticket. Convince them that it's no problem to give up "worthless" freedoms, because it's "for the public good". Then we can cite those changes later as the basis for the removal of more widely valued freedoms -- not only will they be used to giving up rights, but we'll have an easy-to-rationalize "logic" on which to sell the more offensive restrictions.
I think the US will start using the metric system as soon as the Brits do. But as long as they are driving 150 stone cars at 70 MPH to go get a pint of ale it seems a bit silly to pretend that they use the metric system.
any open router could record everything including passwords and perform man-in-the-middle attacks to bypass SSL
It's that sort of misinformation that makes it hard to take valid privacy concerns seriously. How exactly would a router bypass SSL?
You could spoof DNS to redirect all requests to your own HTTP server, and you could dynamically fetch pages from the far end to convincingly fake the remote website. And while you could generate SSL certificates on-the-fly to make it HTTPS, those certificates could only be signed by a certificate authority you control, which is not one that's particularly likely to be present in the target's list of trusted authorities.
It's almost like the people designing SSL thought that the entire route between the two communicating hosts might be insecure -- including the first-hop router -- and therefore provided verifiable, end-to-end encryption and authentication that did not rely (at least at communications time) on resources beyond what is stored or can be generated on those hosts.
Beyond that, any authentication and encryption technologies that would commonly be considered secure by knowledgeable users -- SSH, Kerberos, most VPNs, etc. -- can provide similar guarantees. They all provide verifiably-secure authentication from any endpoint, even if the entire route is hostile, and even if the endpoints have bad DNS, untruthful routes, or totally fake traffic.
It's worth time teach someone the difference between HTTP and HTTPS, but pretending that SSL only works over trusted routers is counter-productive at best; if people feel there's no safe way they can use in the Internet they'll either give up on the Internet or give up on safety.
I'm quite capable of setting up my own annuities which will likewise continue paying me forever. I do not want or need my employer to do it for me; I'd much rather have the cash, not only so I can invest whatever portion of it I see fit at the time, as opposed to the portion the my employer sees fit, but so that I can change employers without losing my investment.
Pensions are great in that they guarantee income for people who can't or won't save. But they're terrible insofar as I can't change jobs without significant threat to my ability to retire comfortably, and that's power that my employer doesn't need to have. Couldn't we just teach people to save, rather insisting that they're too dumb to plan for their own future?
Yet I wonder - what is computer science without the ability to actually program the computer? Discrete math, algorithms, and some theory. Interesting, but (not quite) useless.
While I don't entirely disagree I think you're discounting the huge amount of low-complexity programming work there is to be done, where you can make good use of code monkeys who don't really understand the project and/or couldn't design an effective solution on their own.
Try this plan: 1. Hire 1 good programmer 2. Hire 1 good analyst 3. Hire 1 good Q/Aer 4. Have 1 and 2 work together to produce comprehensive, prescriptive specifications of the system 5. Have 2 and 3 work together to produce a comprehensive, prescriptive test suite 6. Hire 6 code monkeys who can read the specs -- which will include descriptions of any complicated algorithms -- to code the thing 7. Hire 6 Q/A monkeys who can read the specs -- which will include acceptance parameters -- to test the thing
That's a team of 15 people, half of the coders, and only 1 of them who really needs to understand what's going on, or to be able to design complicated algorithms. There are certainly limitations to the kind of coding that can be done on such a team, but there are lot of things such a team *can* do, and can do quickly and cost effectively.
Re:What about the CONTRIBUTIONS?
on
Has Ron Paul Quit?
·
· Score: 2, Insightful
He sponsored bills to remove *federal* regulation of corporations. If only there were some form of government that could respond to the needs of workers on a regional basis. That would be really cool, because it would let us set regional minimum wages that actually reflected the cost of living in that region, or quickly respond to safety threats posed by a new form of manufacturing even if those threats only affected a small group of people in a single part of the nation.
If I walk into a brick and mortar store do they have the right to investigate my background and decide to tell me that they do not want to sell their goods to me because I did something they do not like in my past?
Yes, they do. "We reserve the right to refuse service to anyone." It's my right as a business owner to serve only the clients I choose, based on whatever criteria I find to be relevant, within the bounds of law. And there's certainly no law that say I can't do business with people I think are likely to screw me.
Or you could take the brick-and-mortar analogy to say, a brink-and-mortar bank that sell loans. They're going to "investigate your background" and if you have a bad credit history they will likely "decide to tell [you] that they do not want to sell their [loan service] because [you] did something they do not like in the past."
That depends on where you expect the attacker to be -- it's hard to read sticky notes on my monitor from across the Internet.
And it's hardly fair to assume that complex passwords are more likely to be shared than simple passwords. Sharing passwords is a separate behavior entirely. Not to mention the complex passwords are harder to share for the same reasons they are harder to remember.
How about a password generation algorithm that works like this: select two or more short dictionary words, append or prepend numbers to at least one of the words, and join them with punctuation/special characters. That produces passwords that are both complex to guess (even if you know the generation algorithm) and easy to remember.
The next step is to add a tool that generates good passwords and make it available from the password changing dialog box, so users don't have to come up with a good password on their own -- they can just copy one from the computer. OS X does exactly that, and it's a good time for everyone involved.
Slashdot Mirror
I don't understand how they messed it up so badly. It's an idea they first tried in MS Office for Mac, and it was actually pretty useful in the implementation there -- they added a context-sensitive floating window that contained collapsable sections for each of several functional areas. It essentially made toolbars context-sensitive, floating, and collapsable. But they didn't take away the menu bar when they did it -- you could still get at everything via the menus. And they didn't try to put context-insensitive things, like "Save" or "Options" into the new floating window.
But then Office 2007 came out and said "What if we took away toolbars AND menus. That would be twice as cool as what we did in the Mac version 4 years ago." I've long since given up on using Word for document creation -- the last version I used regularly was Word 5.0a -- but just supporting other people in Office 2007 makes my head hurt.
So apparently it's not valid to complain that the new standard shouldn't need to support "truncateFontHeightsLikeWP6" in the first place? Wouldn't it be technologically superior to require MS Word to emulate "truncateFontHeightsLikeWP6" using standard formatting directives, rather than forcing every other implementer to code for compatibility with some file format that isn't even part of the spec?
Try this one one for size:
"15 years ago we had a file format that stored text using EBCDIC encoding. While we no longer write any files using this encoding, we propose that the new standard file format include an EBCDIC mode. We realize that traditional arguments for "backward compatibility" don't apply -- obviously none of our 15-year-old products ever produced any output in the new file format being proposed -- and we concede that we could just convert to UTF-8 encoding when saving old documents into the new format. But such conversions would require more work on our part than simply adding another encoding mode to the new file format and reusing our existing code to render in that mode. We acknowledge that this formatting directive will only benefit our product, as no one else can read our 15-year-old, unpublished format, so we'll note that the EBCDIC mode is deprecated. In spite of that note however, we will generate new files using EBCDIC mode, and therefore competing implementations must implement it as well to be functionally compliant."
see firewire vs USB as a good example of a wonderful tech being maimed by its own creators
While I agree that FireWire has more expensive licensing than USB, that's not the only reason USB is more popular. FireWire simply requires more expensive and physically/electrically larger hardware to implement, making it the wrong choice for low-performance devices (like consumer flash drives, your cell phone, etc.) regardless of licensing issues.
Trust is antithetical to verification. It may be wise to place limits on your trust, and to take action to verify compliance when that those limits are exceeded. And finding that verification routinely falls one way or the other, you may even adjust the limits of your trust accordingly. But don't pretend that verification is part of trust -- verification is an action you take when you don't trust the presumed analysis of a situation.
You're disappointed that your level of trust was too high. And you may even be wise to reduce your level of trust in the future. But realize that you're no longer trusting as soon as you require verification.
For games with a single display, it's trivial. Just buy more keyboards and map the different players to different portions of the keyspace. I've played 2-player games that are designed to run this way even with only 1 keyboard. But console systems require you to buy extra controllers to play 4-player games, so I don't see why that would count as an extra limitation on PC systems.
As far as split-screen play goes, if you only wanted to give each player a 120x110 pixel display I'll bet any graphics card on the market could run 4 instances of the game display simultaneously. Even at 1080p you only get 480x270 per player, which still doesn't require any phenomenal processing capabilities, particularly when you consider that many aspects, like texture maps, could be shared between instances.
I realize that not many games are designed to allow multiple players on a single system, but that's a result of deliberate design, not of technical limitations of the platform. There are merits to both types of systems, and the availability of single-system, multi-player games for consoles is a plus for consoles if that's something you value. But it's silly to claim that PC systems are technically incapable of running multi-player games without multiple boxes.
Are you seriously suggesting that improved communications technology *wouldn't* improve the local economy? Did you miss the last 100 years of human existence?
If these people were starving in the street you're right, soup kitchens would be more useful. But that's not the case here -- the intent is to improve the local economy to be on-par with the rest of the nation. The people this project is intended to help aren't homeless, and many aren't even unemployed, they're just poor.
Having things like, the ability to use their Internet connection to be a work-at-home call-center rep, cheaper residential telephone service, the ability to easily search for jobs outside their immediate geographic area, or even just general access to the web and email, could all make practical improvements in the lives people who did not previously have access to cheap, moderate-speed Internet services.
A) To the best of my knowledge is no theory that places even moderately strict bounds on the Rho method. That was the point of the original post. B) RSA has discontinued their factoring challenges.
Authentication does not necessarily mean that those around me know who I am. Take a credit card transaction as an example -- the credit card company wants to know that I'm an authorized user of the card I hold. The merchant wants to know that my credit card company will pay them on my behalf. But the merchant doesn't have any fundamental interest* in knowing who I am -- only the credit card company does. So if I authenticate to the credit card company, and the credit card company authenticates to the merchant, we can all feel safe, and I can remain anonymous with respect to the merchant.
It's certainly possible to design the system to provide strong authentication for a variety of purposes without compromising privacy or even anonymity. Whether or not anyone will bother to do that/allow that to happen is debatable, but you shouldn't necessarily relate the ability to authenticate with an inability to provide privacy.
*I know they might like to know who I am for marketing purposes and whatnot, but they have no interest with respect to conducting a safe and reliable financial transaction.
Depending on one's situation you could just as accurately say: When you career won't support you, your family might. MIGHT. Gen Z may well figure out that "family" bails out on you when life changes occur, whereas a decent friend will stick with you. Relying on family is not a good way to go as far as I've observed, so I wouldn't say that Anonymous Coward has his stuff together just yet.
Or for that matter: When you career won't support you, your family or friends might. MIGHT. Gen Z may well figure out that "family" and "friends" bail out on you when life changes occur, and you can't depend on anyone but yourself. Relying on family and friends is not a good way to go as far as I've observed, so I wouldn't say that Anonymous Coward has his stuff together just yet.
I'm glad your family works for you. And I'm sorry your friends didn't. But it's naive to assume that your life is a valid model for all those around you. You don't even have anecdotes plural, let alone "data".
Yes, they can. States are free to run their elections by any means they see fit -- some states voluntarily choose to follow guidelines set by federal bodies, but they are under no obligation to do so. For one thing, most elections are not federal in nature, and therefore the federal government has no legitimate interest in how they are run. That includes the presidential election, as there is no requirement for a popular vote. Even for Representatives and Senators, for which the federal government does have some control over elections, there still aren't rules about which particular voting machines you can use, nor any requirement that a machine be used at all.
Both SIP and IAX are UDP-based, and won't tunnel via SSH's TCP tunnels. And UDP->TCP encapsulation is a bad idea for things like VoIP; you probably don't want to drop 2 seconds of the conversation just because 1 packet got mangled, and you sure don't want to waste bandwidth re-transmitting things that will never be played back.
However, IPSec's 3DES-CBC and AES-CBC modes both re-initialize for each datagram, so it can handle encryption on UDP packets without requiring in-order, complete reception or retransmission. And you can do IPSec pretty transparently at your gateway even in the generating device -- say a desk phone -- doesn't do IPSec or uses a wide range of ports.
You do *not* needs DHCP to get DNS addresses under IPv6. See http://tools.ietf.org/html/draft-ietf-dnsop-ipv6-dns-configuration-06 -- the RA method is site-local not link-local, so it works across routers if they are configured correctly. And once you have DNS you can configure everything else via SRV records.
On the "MAC addresses change" note, an ease solution is to simply change the MAC address of the replacement card to match the old one. Since the old one is no longer in use there's no conflict, and then there's no external change to be made anywhere on the network. You've have to type the new MAC address in somewhere to get the DHCP server to hand out the same address, so you might as well just do it locally.
Likewise DHCP is hardly the only option for reverse-DNS registration; it doesn't take a whole lot of scripting to submit the local hostname to some remote service that can update DNS. We've decided the DHCP server is a good place to do this, because it knows both those items and is centrally administered, but it's certainly not complicated to replicate with other mechanisms.
Now, you may prefer to do things via DHCP, and I wouldn't necessarily blame you, but it's not strictly necessary, and for many simple networks -- say home routers -- there's no reason for DHCP at all.
However, that is no longer how processors function - they are now two slower processors working together.
But there aren't two slower processors. Core for core modern processors are faster then 5-year-old processors. Even if they have lower clock speeds.
And while the average home user probably can't use 16 cores, they can use two cores. Their foreground app can get 100% of the cycles on core 1, and all the kernel-space calls can run on core 2 -- all the overhead of USB, TCP/IP, etc. can happen on a second core so the first core can run the user app exclusively.
I think you're wrong on all counts:
A) The average office building could have the A/C off 65% of every week without affecting perceived quality of service. If IT had those kinds of maintenance windows on an email server I bet you'd never notice the downtime. Even for always-on systems like data-center cooling, the A/C undergoes regular maintenance and downtime, which is why no one installs a data center with a single cooling system.
B) Chiller maintenance is big business and even the techs they actually send out to do it make good money, on-par with grunt-level IT staff. And their bosses make more, just like yours do. The contracted cleaning crew making $8/hour is not doing your chiller maintenance (or if they are, you're gonna be in trouble next summer).
C) Comparing an "email service" to "lights" is like saying "but my bicycle never needs an oil change". Electric lights are 100+ year old technology with exactly one dependency -- electricity (and not even clean power at that) -- and one failure mode -- irreparably damaged. If your email server only needed electricity and could simply be replaced with a spare when it failed I'll bet IT could keep a few on-hand and give you similar reliability.
I can understand why people object to obvious patents, or to patents with not demonstrable implementation, but for all the whining people do about the evils of "software patents" I don't think people understand how similar the situation is with plain old mechanical patents. There are just as many bad patents on physical devices; why is the concern here only about software?
And as the parent suggests, I think a shorter term for software patents is a great idea. 17 months is probably a bit short -- I doubt many good ideas could make it from proof-of-concept to market in under 9-12 months, which doesn't leave a lot of protection time left on the patent. But certainly there's some single-digit number of years that would provide a workable balance.
For that matter I think the term of a patent could be variable in general. We'd want limits on the valid term range, but based on the patent type and things like regulatory barriers to market entry (for example in drugs, where drug X must get FDA approval which takes 2 years, but drug Generic-X can use the previous approval -- the government provides a barrier to market entry that is unique to the applicant and doesn't apply to other in the industry) we could certainly pick a more suitable term for almost all patents.
It doesn't have to be; the default password could be set (or even just randomized) on installation, or the account marked for "must change password" if the auth mechanism supports that concept. Either way users would be to required to pick a password before logging in. That obviously doesn't stop anyone from using bad passwords, but you can most certainly stop default passwords -- they've always been a bad idea from lazy installation systems.
Without commenting on whether or not seatbelts should be mandatory, I must question your logic. How are you drawing the line that makes "require seatbelts to save money" reasonable but makes these similar situations absurd? Or would you really apply the same logic to these situations?
Riding a motorcycle increases your chance of serious injury when compared to a riding in a car which increases the cost of accidents for the person at fault and increases the need for medical attention from the already limited pool of medics; we should therefore outlaw motorcycles are require people to ride only in cars.
Riding in a car increases your risk of serious injury when compared to a riding in a bus, which increases the cost of accidents for the person at fault and increases the need for medical attention from the already limited pool of medics; we should therefore require people to ride only in buses.
Poor eating habits increase your chance of chronic illness, which increases the cost of medial care. We should therefore mandate healthy eating habits.
That's the ticket. Convince them that it's no problem to give up "worthless" freedoms, because it's "for the public good". Then we can cite those changes later as the basis for the removal of more widely valued freedoms -- not only will they be used to giving up rights, but we'll have an easy-to-rationalize "logic" on which to sell the more offensive restrictions.
I think the US will start using the metric system as soon as the Brits do. But as long as they are driving 150 stone cars at 70 MPH to go get a pint of ale it seems a bit silly to pretend that they use the metric system.
any open router could record everything including passwords and perform man-in-the-middle attacks to bypass SSL
It's that sort of misinformation that makes it hard to take valid privacy concerns seriously. How exactly would a router bypass SSL?
You could spoof DNS to redirect all requests to your own HTTP server, and you could dynamically fetch pages from the far end to convincingly fake the remote website. And while you could generate SSL certificates on-the-fly to make it HTTPS, those certificates could only be signed by a certificate authority you control, which is not one that's particularly likely to be present in the target's list of trusted authorities.
It's almost like the people designing SSL thought that the entire route between the two communicating hosts might be insecure -- including the first-hop router -- and therefore provided verifiable, end-to-end encryption and authentication that did not rely (at least at communications time) on resources beyond what is stored or can be generated on those hosts.
Beyond that, any authentication and encryption technologies that would commonly be considered secure by knowledgeable users -- SSH, Kerberos, most VPNs, etc. -- can provide similar guarantees. They all provide verifiably-secure authentication from any endpoint, even if the entire route is hostile, and even if the endpoints have bad DNS, untruthful routes, or totally fake traffic.
It's worth time teach someone the difference between HTTP and HTTPS, but pretending that SSL only works over trusted routers is counter-productive at best; if people feel there's no safe way they can use in the Internet they'll either give up on the Internet or give up on safety.
I'm quite capable of setting up my own annuities which will likewise continue paying me forever. I do not want or need my employer to do it for me; I'd much rather have the cash, not only so I can invest whatever portion of it I see fit at the time, as opposed to the portion the my employer sees fit, but so that I can change employers without losing my investment.
Pensions are great in that they guarantee income for people who can't or won't save. But they're terrible insofar as I can't change jobs without significant threat to my ability to retire comfortably, and that's power that my employer doesn't need to have. Couldn't we just teach people to save, rather insisting that they're too dumb to plan for their own future?
Yet I wonder - what is computer science without the ability to actually program the computer? Discrete math, algorithms, and some theory. Interesting, but (not quite) useless.
While I don't entirely disagree I think you're discounting the huge amount of low-complexity programming work there is to be done, where you can make good use of code monkeys who don't really understand the project and/or couldn't design an effective solution on their own.
Try this plan:
1. Hire 1 good programmer
2. Hire 1 good analyst
3. Hire 1 good Q/Aer
4. Have 1 and 2 work together to produce comprehensive, prescriptive specifications of the system
5. Have 2 and 3 work together to produce a comprehensive, prescriptive test suite
6. Hire 6 code monkeys who can read the specs -- which will include descriptions of any complicated algorithms -- to code the thing
7. Hire 6 Q/A monkeys who can read the specs -- which will include acceptance parameters -- to test the thing
That's a team of 15 people, half of the coders, and only 1 of them who really needs to understand what's going on, or to be able to design complicated algorithms. There are certainly limitations to the kind of coding that can be done on such a team, but there are lot of things such a team *can* do, and can do quickly and cost effectively.
He sponsored bills to remove *federal* regulation of corporations. If only there were some form of government that could respond to the needs of workers on a regional basis. That would be really cool, because it would let us set regional minimum wages that actually reflected the cost of living in that region, or quickly respond to safety threats posed by a new form of manufacturing even if those threats only affected a small group of people in a single part of the nation.
If I walk into a brick and mortar store do they have the right to investigate my background and decide to tell me that they do not want to sell their goods to me because I did something they do not like in my past?
Yes, they do. "We reserve the right to refuse service to anyone." It's my right as a business owner to serve only the clients I choose, based on whatever criteria I find to be relevant, within the bounds of law. And there's certainly no law that say I can't do business with people I think are likely to screw me.
Or you could take the brick-and-mortar analogy to say, a brink-and-mortar bank that sell loans. They're going to "investigate your background" and if you have a bad credit history they will likely "decide to tell [you] that they do not want to sell their [loan service] because [you] did something they do not like in the past."
That depends on where you expect the attacker to be -- it's hard to read sticky notes on my monitor from across the Internet.
And it's hardly fair to assume that complex passwords are more likely to be shared than simple passwords. Sharing passwords is a separate behavior entirely. Not to mention the complex passwords are harder to share for the same reasons they are harder to remember.
How about a password generation algorithm that works like this: select two or more short dictionary words, append or prepend numbers to at least one of the words, and join them with punctuation/special characters. That produces passwords that are both complex to guess (even if you know the generation algorithm) and easy to remember.
The next step is to add a tool that generates good passwords and make it available from the password changing dialog box, so users don't have to come up with a good password on their own -- they can just copy one from the computer. OS X does exactly that, and it's a good time for everyone involved.