You realize you pretty much described flying as it exists right now, right? Except for a small range (3000 ft AGL), altitudes ARE strictly controlled (IFR - thousands, VFR - thousands+500 ft), and it depends on which direction (track over the ground, yay wind) you're heading (East - odd thousands, West - even thousands).
Yup. But I'm talking about much tighter tolerances, using a combination of altimeters, GPS, RADAR/LIDAR, and computer control to maintain an exact altitude measured in double- or triple-digit feet.
Of course, you're also assuming that flying cars are more VTOL style craft - so far most of them are really more like planes. VTOL is surprisingly difficult and fuel-inefficient.
I'm assuming that because the alternative would be useless as a car. Most people don't drive a car when they're commuting across the country. They drive to work a few miles away. If they have to have a mile-long runway in their front yard and another mile-long landing strip in their employer's front yard, they'd barely get off the ground before they landed, if at all.
And you would never be able to reduce the density of a city, or even suburbia, sufficiently to allow for that anyway. You'd need a wide airstrip with fences to ensure that kids don't run across the runway, so it isn't as though you could just use a city street for that. Anything short of an ultralight would have to be going at highway speeds or faster.
In short, I'm assuming VTOL-style aircraft because the alternative is so impractical that it isn't worth putting any serious thought into.
Meanwhile, if you want a practical flying car before we develop antigravity, it's going to look and behave a lot more like a present day aircraft.
But almost certainly not like an airplane. That design is completely impractical for anything other than long-range travel because of the long strip of unoccupied runway required to take off and land. It would be completely useless in any sort of city environment.
That's because objects ARE just glorified key-value stores.
In principle, yes. In practice, it's a heck of a lot harder to properly document and verify the expected behavior of code if you have to write complex regular expressions just to get a complete list of all the different possible keys. I've fixed bugs in Perl code (which obeys that same design principle) where some subtle misbehavior was caused by a simple typo in the name of a key—an error that went undetected for months, yet would have been caught instantly in any programming language that requires you to actually define your classes.
If you want to be a good programmer, you have to be thinking below your current level of abstraction.
It is one thing to understand what's happening at lower layers of abstraction. It is quite another to provide no abstraction whatsoever, requiring the programmer to do significant portions of the work that the compiler should be doing for you. There's no good reason to take on that unnecessary cognitive load if you can prevent it by simply choosing a language that's a little bit more rigorous. Granted, a language can be too rigorous, but JavaScript is so far on the other side of that line that you can't even see the line from there....
Roger that. Most people don't realize the challenges of operating in a 3D enviroment where your senses may be fooling you. Couple that with some of the junkers that haven't seen maintenance since the Nixon era and you have. Are wipe for disaster.
I think you're misunderstanding what most of us mean when we talk about flying cars. I'm envisioning vehicles whose Z axis is maintained automatically except when you are about to park, with vehicles traveling in three or four altitude ranges, up to a couple hundred feet roughly above existing roads, not vehicles that fly along arbitrary paths, at arbitrary altitudes, etc.
I would expect the Z axis to depend entirely on which direction you're traveling. A left turn would require you to be above the left lane. (You'd have an augmented reality HUD windshield showing the driving lanes below you.) Then, you would turn the steering wheel to the left, causing the vehicle to bank and automatically ascend or descend as you approached the road you're turning onto. When you got to that point, you would curve towards the road, and right after the turn, you'd have to merge into a gap in the traffic to your right.
When you're ready to park, you would enter a designated landing zone, whereupon the vehicle would show you an image of the parking lot on the HUD, with an outline of your car superimposed. You would then find an empty parking space and tell the vehicle to descend into it.
It also has a number of rather large disadvantages: requiring an understanding of closures, no real notion of classes (objects are just glorified key-value stores), implicit variable scoping, implicit insertion of semicolons (in ways that can actually cause errors in some cases), and the confusing (ab)use of the plus operator for string concatenation... and that's just the language itself. As soon as you start adding in the brain damage that is the DOM, it quickly becomes one of the worst programming languages you can possibly use to teach young minds, posing a very real risk of turning them off to programming rather quickly as soon as they try to step outside the narrow confines of the lecture material.
Want to make someone swear off programming for good? Make them write any sort of complex web-based text editor using ContentEditable. It makes my i386 assembly days seem sane by comparison; you spend more than 99% of your time working around bugs in one browser or another, and less than 1% of your time actually writing code that actually does something useful.
Always keep your threat model in mind. Are you trying to protect against selected 3-6 letter government agencies with datacenters full of true supercomputers? Or are you trying to protect against a lesser threat?
These days, the non-government attacker isn't a lesser threat. They have armies of captured Winzombies in a botnet at their disposal.
You do make them authenticate over an encrypted channel, right? Yes, someone might compromise the device with the software token, but that in theory should be hard.
You know the difference between theory and practice, right? Sites like JailbreakMe and all the Windows drive-by download attacks demonstrate with incredible clarity why putting complete trust in any internet-connected device is a dubious proposition. Sure, right now, attackers aren't attacking sites that generate one-time passwords, but that's because they aren't used for much other than corporate VPNs. Get even one major bank using them, and you'll have people exploiting them within a week.
If you are allowing over a thousand bad guesses, you're doing something else wrong.
Not really. The only alternative is to lock people out of their accounts if they happen to be unlucky enough to have a common account name that people regularly mistake for their own, and that is seriously cumbersome. You can limit it to a few requests per IP, but again, the attacker has armies of....
No, no roll feed—I'm not aware of any laser printers that take roll paper, unless perhaps it's those industrial-grade monsters that fill half a room and cost as much as my printer plus another zero or two—but it will do up to 12.25" x 47.24" banner sheets. When I print dust covers, I cut the banner paper down to half length with a paper cutter (somewhere in the neighborhood of 9.25" x 22" post-trim size, IIRC). I also frequently print sheet music folios on 11" x 17" paper with it.
I should clarify: it's a two grand printer, not counting the duplexer unit or the 500-sheet second paper tray. I added the duplexer because I use this thing to print draft copies of my novels for editing purposes (a few hundred pages at a time, in color to make it easier to identify things like blockquotes, in-doc comments to myself, etc.) and because it makes music printing easier.
I added the 500 sheet (ream-sized) tray initially because I like to just shove in a whole ream at the same time instead of having to split it in half, but man, I'm glad I have it now. It makes life so much easier for music printing because I don't have to change out the paper when I do folio printing of music with a half-sized center sheet. I just let it send the 11" x 17" pages to the built-in drawer and the standard-sized pages to the full-ream add-on drawer. Because it can print one and then the other in alternation, there's no need for manually matching up the pieces at the end and accidentally giving half of the clarinets a copy with the middle two pages missing. (Sorry, guys.) So much simpler.
So yeah, with all of my unusual needs, a suitable printer costs a fortune. On the plus side, I expect to pass this thing on to my grandkids someday. Oh, and I think it is without a doubt the one piece of expensive hardware that I will never have to worry about anyone stealing. One of my coworkers helped my set it up. It took both of us to lift the thing, and that was without the additional paper tray and duplexer. In total, with the extra tray and duplexer, it weighs in at a whopping 190 pounds, give or take—19 pounds less if you remove the toner, waste toner tank, and print drums—about 15 pounds more if you fill it with 750 sheets of 11" x 17" paper....
The point of such software is the software alone is worthless. You still need that second factor of the "something you know" to make any use of it. For example, you must compromise both the device and the PIN in the SecurID case.
Not really. Typically, systems based on those sorts of devices use a four-digit PIN. Wanna guess how many seconds it takes to crack a four-digit PIN? Besides, chances are, the user will end up logging in to some of those systems from the phone, at which point you have the PIN, too.:-)
As I understand, the software somehow binds itself to some kind of machine identifier on installation, and that is used in device setup, making migration difficult if not impossible.
I'm guessing that's referring to using data protection APIs. That protects against someone physically messing with the device who doesn't know the passcode. As far as I know, it isn't useful against a remote attack (wherein the attacker is able to continue running code on the device over a period of time) because eventually the user is going to unlock the device, at which point those files become readable.
The old "security must be cumbersome" theory is one I'm constantly fighting in my job. My standard counterexamples are centralized security logs vs managing per system local logs, SSH keys vs local passwords. Even how we do SecurID is a lot simpler than local passwords for me.
Don't misunderstand me. I'm not saying that security has to be cumbersome, so much as that good security usually is, and that if it looks too easy to be robust, it usually is. More often than not, when someone makes security easier, they do it by adding shortcuts that weaken security. Being able to permanently authorize a particular computer so that it requires fewer (or no) credentials is a great example of such a shortcut. Being able to reset passwords by answering security questions is a shortcut. And so on. These make security less cumbersome at a significant cost to actual security.
When security seems convenient, I immediately start looking for the flaws. Usually it doesn't take very long to find at least one.
We want good authentication services, we don't want a central authentication repository that can invade our privacy by knowing everywhere we authenticate.
Eh. That's a pretty low concern for me. I mean ostensibly yes, but in practice, I'm more concerned about it from the opposite perspective—that compromising a single site would give someone near unlimited ability to screw with my digital life.:-) There are no companies out there that I would trust with that kind of power—not even my employer or any of my former employers.
Cumbersome is relative. Hardware tokens cumbersome so long as you only have one of them on your keychain. If every site used it, you'd need a chiropractor pretty quickly, not to mention stronger pants pockets. And if you switch to a model of central authentication, now you have one site that can be compromised and trivially turn hundreds or thousands of sites' security into a four-digit PIN, while simultaneously rendering hundreds of millions of dollars worth of hardware tokens useless until the users mailed in the tokens to get them rekeyed (or for devices that cannot be rekeyed, permanently useless).
In other words, if it isn't cumbersome for the user, it probably isn't particularly secure. In theory, there are ways of doing something that isn't too cumbersome and is still secure, but they would require smarter CryptoCard-like devices that let you generate new site-specific keys on the fly that you can type in (over a secure channel) as part of setting up an account with a website.
The fact that I can't copy that to another phone and have it "just work" suggests that it was done right here. (I'm not on the SecurID support team).
AFAIK, you can prevent migration just by storing the data in the keychain and setting a couple of flags so that it won't get backed up or migrated. However, I'm pretty sure none of those protections will help you in the slightest if the device actually gets compromised. It's a bit like trying to hide your files from root.
I am guessing you have not tried Google's 2-factor authentication?
I enabled it last week. I had to create a few application-specific pass codes and add a couple machine as trusted. Done. Not bothered since.
That's because most of the time, Google's two-factor authentication isn't real two-factor authentication. It requires something you know, plus something you know. A stored cookie in a browser is just a shared secret (something you know), as is a password. Therefore, it is not true two-factor authentication any more than asking for two passwords is two-factor authentication. True two-factor authentication requires two different factors, not two instances of the same factor.
And even to the extent that it tries to require a second factor (requiring you to confirm using your cell phone when you add a new machine), it isn't a very good second factor. If your password got cracked, odds are pretty good that they stole your password by cracking into your mobile phone, at which point your second factor is no better than the first.
When you experience real two-factor authentication, you'll know it. It is cumbersome. It has to be. Any factor that isn't cumbersome (read "not networked") is likely to be a terrible second factor, if it qualifies as a second factor at all.
What you're really pointing out here is the need for diferent tiers of authorization. Without any unlock, I would like to be able to:
Call numbers from my preferred phone number list (including hands-free use)
Run the music player app
Use the maps application
Use the web browser.
I would like to be prompted for my unlock password when:
I try to access notes, my calendar, or my mail.
I try to change any settings.
I try to do anything that could potentially cost me money.
I navigate to a web page for which a password or other autofill information exists.
Similarly, for online banking, I would like an easy-to-remember password for:
Checking account balances
Viewing my transaction history
I would like to be prompted or additional authentication when I:
Send a message to the bank.
Attempt to pay a bill to a new recipient or to a different account at an existing recipient.
Transfer money into or out of my account.
Amazon is a good example of this sort of distinction in action. With a single password, I can place orders and have them sent to me. However, if I add a new destination address, they make me type in the CVV code from my credit card.
I do my really large stuff on a color laser, too, but then again, I spent two grand on the printer specifically so that I could print draft copies of dust covers for hardcover books. I even do photo printing on my color laser. It claims 9600x600 DPI, which in practice means that as long as you aren't looking at it from such a steep angle that you can see the texture and semigloss reflection of the toner, it produces jaw-droppingly good photographic prints.
That has the effect of subjecting the whole file (assuming substantial modifications have been made) to the restrictions contained in both licenses...
No, it doesn't effectively change the license on the existing code. The portions that were under a BSD license remain so licensed, at least to the extent that the person who receives it can still figure out what parts were originally covered by the BSD license. The clause in the MS-PL requiring that distribution of that code in source code form must be under the MS-PL and that a copy of the license must be included is not really different from the clause in the BSD license requiring that the BSD license terms be included, at least in practice.
Pedantically, yes, there's a very slight difference. In practice, assuming people follow good code hygiene (keeping source code from different sources in separate files is a good practice anyway, because doing so makes it easier to keep things in sync with the original), there's no difference. Content in source code form (in separate files) inherently does not impose any restrictions on other files in the project unless you distribute the content in binary form, and the MS-PL does not, to the best of my understanding, impose any additional restrictions on the GPLed binary code above what GPLv3 allows. So to the extent that this is different from BSD at all, the differences solely affect code maintainers, and in a way that is generally considered to be positive.:-)
That's because the password-protected encryption doesn't encrypt the whole disk. It encrypts individual files. There is a full-disk encryption key, but its purpose is to make wiping the device a single block write operation (overwrite the key) instead of a complete wipe of tens of gigabytes.
If you don't care about size, I recommend networked color laser printers. No more clogged printheads, no more quirky drivers that break every other release (they speak PostScript), usually at least 5 PPM in color even for the small ones, and the bigger ones will do as much as 25 PPM in full color. Of course, they don't cost $50, but you also don't pay $50 in ink every time you need to refill the thing. (Okay, so you pay a couple hundred bucks in toner, but for home use, you refill the thing every five years instead of every month or two, so it works out to being a lot cheaper.) And instead of replacing the whole thing every couple of years when the print head finally gives up the ghost, you'll still be using the same color laser printer in a couple of decades.
Most BSD style licenses are unencumbered enough that you can relicense direct derivatives (not just composite works) under practically any terms you want.
But you cannot remove the copyright notice, as a rule, if you are distributing it in source code form, nor can you remove the license terms. All BSD licenses contain this clause:
Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
I'm not aware of any software licenses that do not contain similar provisions except for the WTFPL.
Uh... there's no such thing as a license that doesn't require you to distribute the code under that license, and requiring someone to include a complete copy of the license is also pretty much the norm. By your definition, all non-GPL licenses are incompatible with the GPL. Sorry, but licenses don't work that way. GPL-compatible does not mean that you can simply copy and paste code willy-nilly into a GPL project.
It's not true at all a 50 pct tax rate is required.
I never said it was. I said that 15% is way too low, and that most first-world countries had top-bracket tax rates of 50% or more. That's not the same thing as saying that we should have top brackets of 50% or more. I'd gladly settle for limiting the capital gains exemption to... say $50,000 per year of gains, with the ability to spread a single large gain (e.g. a house) over several years, but where you do eventually have to pay the piper at ordinary tax rates if you're averaging more than that.
Also, I agree with you about deductions. That said, most of those tax credits are nickel-and-dime. The few that aren't should be eliminated, and the capital gains exemption (special tax rate) just happens to be one of the biggest.
Check the numbers dipshit; the difference between the haves and have nots is increasing under the current government bloat.
Yes, which is why we have to fix the imbalanced tax system that is causing it.
And until threats of cap gains increases and dollar de-valuation came along they would invest it (which creates jobs) or put it in a bank (which then has more reserve money to loan out also leading to more jobs).... Now rich (and not so rich) people are putting their money into precious metals (not just as a hedge against the dollars instability) instead of investing because of impending cap gains increases.
Wrong at pretty much every level.
Nobody sensible is putting money into precious metals right now. The economy is turning around, which means the value of precious metals is going to go down as the value of the dollar goes up. Haven't you heard all the ads for precious metals lately? You don't really think they're telling people about it to help the buyers, do you?
Even if I'm wrong about that, the rich people will eventually have to sell those precious metals in order to do anything with the money, at which point it will be taxed. Or when they die and it gets sold as part of their estate. Either way, like stock, it isn't really worth anything until they sell it, at which point they take a capital gain just as they would if they bought and later sold stock. Therefore, there is exactly zero advantage of precious metals over putting the money into stocks or bank accounts. In fact, last time I checked, capital gains on precious metals were taxed at 28%, which although slightly lower than ordinary income for the wealthiest Americans, is much, much higher than capital gains on stocks (15%). And when I talk about increasing capital gains, I'm including precious metals.
If people truly don't invest the money at all, short of things getting so badly broken that we have a deflationary period, the value of their money is going to decrease over time. Therefore, only a complete idiot would choose to pout and take all their money and play over in the corner rather than investing it.
Thus, the argument that raising taxes on the rich would discourage investment is absolutely absurd beyond belief. You pretty much have to have zero understanding of economics to believe that drivel. Even somebody who just took high school econ should know better.
Cool. Yeah, GPLv2 is a touchy subject. For that matter, GPL in general is a touchy subject because of all the "no additional restrictions" stuff. That said, for something like Blender, it might make more sense to define a standard plug-in interface and then dynamically load this as a plug-in. Then, the license doesn't matter at all.:-)
Slashdot Mirror
Yup. But I'm talking about much tighter tolerances, using a combination of altimeters, GPS, RADAR/LIDAR, and computer control to maintain an exact altitude measured in double- or triple-digit feet.
I'm assuming that because the alternative would be useless as a car. Most people don't drive a car when they're commuting across the country. They drive to work a few miles away. If they have to have a mile-long runway in their front yard and another mile-long landing strip in their employer's front yard, they'd barely get off the ground before they landed, if at all.
And you would never be able to reduce the density of a city, or even suburbia, sufficiently to allow for that anyway. You'd need a wide airstrip with fences to ensure that kids don't run across the runway, so it isn't as though you could just use a city street for that. Anything short of an ultralight would have to be going at highway speeds or faster.
In short, I'm assuming VTOL-style aircraft because the alternative is so impractical that it isn't worth putting any serious thought into.
Like a helicopter.
But almost certainly not like an airplane. That design is completely impractical for anything other than long-range travel because of the long strip of unoccupied runway required to take off and land. It would be completely useless in any sort of city environment.
In principle, yes. In practice, it's a heck of a lot harder to properly document and verify the expected behavior of code if you have to write complex regular expressions just to get a complete list of all the different possible keys. I've fixed bugs in Perl code (which obeys that same design principle) where some subtle misbehavior was caused by a simple typo in the name of a key—an error that went undetected for months, yet would have been caught instantly in any programming language that requires you to actually define your classes.
It is one thing to understand what's happening at lower layers of abstraction. It is quite another to provide no abstraction whatsoever, requiring the programmer to do significant portions of the work that the compiler should be doing for you. There's no good reason to take on that unnecessary cognitive load if you can prevent it by simply choosing a language that's a little bit more rigorous. Granted, a language can be too rigorous, but JavaScript is so far on the other side of that line that you can't even see the line from there....
Roger that. Most people don't realize the challenges of operating in a 3D enviroment where your senses may be fooling you. Couple that with some of the junkers that haven't seen maintenance since the Nixon era and you have. Are wipe for disaster.
I think you're misunderstanding what most of us mean when we talk about flying cars. I'm envisioning vehicles whose Z axis is maintained automatically except when you are about to park, with vehicles traveling in three or four altitude ranges, up to a couple hundred feet roughly above existing roads, not vehicles that fly along arbitrary paths, at arbitrary altitudes, etc.
I would expect the Z axis to depend entirely on which direction you're traveling. A left turn would require you to be above the left lane. (You'd have an augmented reality HUD windshield showing the driving lanes below you.) Then, you would turn the steering wheel to the left, causing the vehicle to bank and automatically ascend or descend as you approached the road you're turning onto. When you got to that point, you would curve towards the road, and right after the turn, you'd have to merge into a gap in the traffic to your right.
When you're ready to park, you would enter a designated landing zone, whereupon the vehicle would show you an image of the parking lot on the HUD, with an outline of your car superimposed. You would then find an empty parking space and tell the vehicle to descend into it.
Either way, going to Mars would be a trip, but... I think it's gonna be a long, long time.
It also has a number of rather large disadvantages: requiring an understanding of closures, no real notion of classes (objects are just glorified key-value stores), implicit variable scoping, implicit insertion of semicolons (in ways that can actually cause errors in some cases), and the confusing (ab)use of the plus operator for string concatenation... and that's just the language itself. As soon as you start adding in the brain damage that is the DOM, it quickly becomes one of the worst programming languages you can possibly use to teach young minds, posing a very real risk of turning them off to programming rather quickly as soon as they try to step outside the narrow confines of the lecture material.
Want to make someone swear off programming for good? Make them write any sort of complex web-based text editor using ContentEditable. It makes my i386 assembly days seem sane by comparison; you spend more than 99% of your time working around bugs in one browser or another, and less than 1% of your time actually writing code that actually does something useful.
Every time I turn right, the manufacturer has to dump cash into the vehicle? I sense a flaw in that plan.
Can you imagine the seven-month journey with your kids, and the whole time they're screaming, "Are we there yet?"
No, and if you don't quit your whining, I'm going to turn this spaceship around.
These days, the non-government attacker isn't a lesser threat. They have armies of captured Winzombies in a botnet at their disposal.
You know the difference between theory and practice, right? Sites like JailbreakMe and all the Windows drive-by download attacks demonstrate with incredible clarity why putting complete trust in any internet-connected device is a dubious proposition. Sure, right now, attackers aren't attacking sites that generate one-time passwords, but that's because they aren't used for much other than corporate VPNs. Get even one major bank using them, and you'll have people exploiting them within a week.
Not really. The only alternative is to lock people out of their accounts if they happen to be unlucky enough to have a common account name that people regularly mistake for their own, and that is seriously cumbersome. You can limit it to a few requests per IP, but again, the attacker has armies of....
And with feature phones, the apps you can install are typically gated by your carrier, whereas with smartphones, they are not.
No, no roll feed—I'm not aware of any laser printers that take roll paper, unless perhaps it's those industrial-grade monsters that fill half a room and cost as much as my printer plus another zero or two—but it will do up to 12.25" x 47.24" banner sheets. When I print dust covers, I cut the banner paper down to half length with a paper cutter (somewhere in the neighborhood of 9.25" x 22" post-trim size, IIRC). I also frequently print sheet music folios on 11" x 17" paper with it.
I should clarify: it's a two grand printer, not counting the duplexer unit or the 500-sheet second paper tray. I added the duplexer because I use this thing to print draft copies of my novels for editing purposes (a few hundred pages at a time, in color to make it easier to identify things like blockquotes, in-doc comments to myself, etc.) and because it makes music printing easier.
I added the 500 sheet (ream-sized) tray initially because I like to just shove in a whole ream at the same time instead of having to split it in half, but man, I'm glad I have it now. It makes life so much easier for music printing because I don't have to change out the paper when I do folio printing of music with a half-sized center sheet. I just let it send the 11" x 17" pages to the built-in drawer and the standard-sized pages to the full-ream add-on drawer. Because it can print one and then the other in alternation, there's no need for manually matching up the pieces at the end and accidentally giving half of the clarinets a copy with the middle two pages missing. (Sorry, guys.) So much simpler.
So yeah, with all of my unusual needs, a suitable printer costs a fortune. On the plus side, I expect to pass this thing on to my grandkids someday. Oh, and I think it is without a doubt the one piece of expensive hardware that I will never have to worry about anyone stealing. One of my coworkers helped my set it up. It took both of us to lift the thing, and that was without the additional paper tray and duplexer. In total, with the extra tray and duplexer, it weighs in at a whopping 190 pounds, give or take—19 pounds less if you remove the toner, waste toner tank, and print drums—about 15 pounds more if you fill it with 750 sheets of 11" x 17" paper....
Not really. Typically, systems based on those sorts of devices use a four-digit PIN. Wanna guess how many seconds it takes to crack a four-digit PIN? Besides, chances are, the user will end up logging in to some of those systems from the phone, at which point you have the PIN, too. :-)
I'm guessing that's referring to using data protection APIs. That protects against someone physically messing with the device who doesn't know the passcode. As far as I know, it isn't useful against a remote attack (wherein the attacker is able to continue running code on the device over a period of time) because eventually the user is going to unlock the device, at which point those files become readable.
Don't misunderstand me. I'm not saying that security has to be cumbersome, so much as that good security usually is, and that if it looks too easy to be robust, it usually is. More often than not, when someone makes security easier, they do it by adding shortcuts that weaken security. Being able to permanently authorize a particular computer so that it requires fewer (or no) credentials is a great example of such a shortcut. Being able to reset passwords by answering security questions is a shortcut. And so on. These make security less cumbersome at a significant cost to actual security.
When security seems convenient, I immediately start looking for the flaws. Usually it doesn't take very long to find at least one.
Eh. That's a pretty low concern for me. I mean ostensibly yes, but in practice, I'm more concerned about it from the opposite perspective—that compromising a single site would give someone near unlimited ability to screw with my digital life. :-) There are no companies out there that I would trust with that kind of power—not even my employer or any of my former employers.
Ouch. Somehow, I lost a word from that second sentence. I meant to say "Hardware tokens aren't cumbersome...".
Cumbersome is relative. Hardware tokens cumbersome so long as you only have one of them on your keychain. If every site used it, you'd need a chiropractor pretty quickly, not to mention stronger pants pockets. And if you switch to a model of central authentication, now you have one site that can be compromised and trivially turn hundreds or thousands of sites' security into a four-digit PIN, while simultaneously rendering hundreds of millions of dollars worth of hardware tokens useless until the users mailed in the tokens to get them rekeyed (or for devices that cannot be rekeyed, permanently useless).
In other words, if it isn't cumbersome for the user, it probably isn't particularly secure. In theory, there are ways of doing something that isn't too cumbersome and is still secure, but they would require smarter CryptoCard-like devices that let you generate new site-specific keys on the fly that you can type in (over a secure channel) as part of setting up an account with a website.
AFAIK, you can prevent migration just by storing the data in the keychain and setting a couple of flags so that it won't get backed up or migrated. However, I'm pretty sure none of those protections will help you in the slightest if the device actually gets compromised. It's a bit like trying to hide your files from root.
That's because most of the time, Google's two-factor authentication isn't real two-factor authentication. It requires something you know, plus something you know. A stored cookie in a browser is just a shared secret (something you know), as is a password. Therefore, it is not true two-factor authentication any more than asking for two passwords is two-factor authentication. True two-factor authentication requires two different factors, not two instances of the same factor.
And even to the extent that it tries to require a second factor (requiring you to confirm using your cell phone when you add a new machine), it isn't a very good second factor. If your password got cracked, odds are pretty good that they stole your password by cracking into your mobile phone, at which point your second factor is no better than the first.
When you experience real two-factor authentication, you'll know it. It is cumbersome. It has to be. Any factor that isn't cumbersome (read "not networked") is likely to be a terrible second factor, if it qualifies as a second factor at all.
What you're really pointing out here is the need for diferent tiers of authorization. Without any unlock, I would like to be able to:
I would like to be prompted for my unlock password when:
Similarly, for online banking, I would like an easy-to-remember password for:
I would like to be prompted or additional authentication when I:
Amazon is a good example of this sort of distinction in action. With a single password, I can place orders and have them sent to me. However, if I add a new destination address, they make me type in the CVV code from my credit card.
I do my really large stuff on a color laser, too, but then again, I spent two grand on the printer specifically so that I could print draft copies of dust covers for hardcover books. I even do photo printing on my color laser. It claims 9600x600 DPI, which in practice means that as long as you aren't looking at it from such a steep angle that you can see the texture and semigloss reflection of the toner, it produces jaw-droppingly good photographic prints.
No, it doesn't effectively change the license on the existing code. The portions that were under a BSD license remain so licensed, at least to the extent that the person who receives it can still figure out what parts were originally covered by the BSD license. The clause in the MS-PL requiring that distribution of that code in source code form must be under the MS-PL and that a copy of the license must be included is not really different from the clause in the BSD license requiring that the BSD license terms be included, at least in practice.
Pedantically, yes, there's a very slight difference. In practice, assuming people follow good code hygiene (keeping source code from different sources in separate files is a good practice anyway, because doing so makes it easier to keep things in sync with the original), there's no difference. Content in source code form (in separate files) inherently does not impose any restrictions on other files in the project unless you distribute the content in binary form, and the MS-PL does not, to the best of my understanding, impose any additional restrictions on the GPLed binary code above what GPLv3 allows. So to the extent that this is different from BSD at all, the differences solely affect code maintainers, and in a way that is generally considered to be positive. :-)
That's because the password-protected encryption doesn't encrypt the whole disk. It encrypts individual files. There is a full-disk encryption key, but its purpose is to make wiping the device a single block write operation (overwrite the key) instead of a complete wipe of tens of gigabytes.
If you don't care about size, I recommend networked color laser printers. No more clogged printheads, no more quirky drivers that break every other release (they speak PostScript), usually at least 5 PPM in color even for the small ones, and the bigger ones will do as much as 25 PPM in full color. Of course, they don't cost $50, but you also don't pay $50 in ink every time you need to refill the thing. (Okay, so you pay a couple hundred bucks in toner, but for home use, you refill the thing every five years instead of every month or two, so it works out to being a lot cheaper.) And instead of replacing the whole thing every couple of years when the print head finally gives up the ghost, you'll still be using the same color laser printer in a couple of decades.
But you cannot remove the copyright notice, as a rule, if you are distributing it in source code form, nor can you remove the license terms. All BSD licenses contain this clause:
I'm not aware of any software licenses that do not contain similar provisions except for the WTFPL.
Uh... there's no such thing as a license that doesn't require you to distribute the code under that license, and requiring someone to include a complete copy of the license is also pretty much the norm. By your definition, all non-GPL licenses are incompatible with the GPL. Sorry, but licenses don't work that way. GPL-compatible does not mean that you can simply copy and paste code willy-nilly into a GPL project.
I never said it was. I said that 15% is way too low, and that most first-world countries had top-bracket tax rates of 50% or more. That's not the same thing as saying that we should have top brackets of 50% or more. I'd gladly settle for limiting the capital gains exemption to... say $50,000 per year of gains, with the ability to spread a single large gain (e.g. a house) over several years, but where you do eventually have to pay the piper at ordinary tax rates if you're averaging more than that.
Also, I agree with you about deductions. That said, most of those tax credits are nickel-and-dime. The few that aren't should be eliminated, and the capital gains exemption (special tax rate) just happens to be one of the biggest.
Yes, which is why we have to fix the imbalanced tax system that is causing it.
Wrong at pretty much every level.
Thus, the argument that raising taxes on the rich would discourage investment is absolutely absurd beyond belief. You pretty much have to have zero understanding of economics to believe that drivel. Even somebody who just took high school econ should know better.
Cool. Yeah, GPLv2 is a touchy subject. For that matter, GPL in general is a touchy subject because of all the "no additional restrictions" stuff. That said, for something like Blender, it might make more sense to define a standard plug-in interface and then dynamically load this as a plug-in. Then, the license doesn't matter at all. :-)