I doubt that, legally, a server is a legal entity, or counts as a "communicating party".
It's operating on behalf of a legal entity, its owner (or someone that its owner is working for, which covers hosting). Its owner has specified (whether directly, by someone they hired, or by someone they trusted to work in their interests) that they want communications with it to be secured. There's quite clearly sufficient legal justification to say that they might have standing in this matter. If you use HTTPS to communicate with your bank, its clear you're talking to the bank, not just some random server that happens to belong to the bank.
Here's some free advice: try to avoid committing felonies, since you'll clearly be your own worst enemy in court with such stupid logic chopping as you show in your post.
as the number of IE7 using customers decreases, the rate of tax will have to increase
That would only follow if there was a requirement to cover the costs of IE7 out of the revenue obtained from the customers. Private businesses do not have to follow such a restrictive rule (and in fact almost always don't). Nor really do governments, but politics is a dirty game run by people who feel it necessary to act like morons.
Look at the details, and you'll see that the costs of supporting IE7 were already wildly disproportionate to the revenue obtained from it, so increasing the charges still won't cover the costs anyway. It might encourage migration though, which is OK too. The only time things really screw up is when some moron decides that each sub-group of customers has to cover all the costs involved with serving them, as that promotes really odd pricing policies. That moron would be you it seems...
Not really. You're just exchanging one set of risks for another. The risk of messing up on your own shouldn't be underestimated; a fat-fingered rm can cause a lot of damage. Of course, if you're really competent then you'll be aware of the single-point-of-failure problem in the first place and so will replicate as appropriate (and according to budget) but for a lot of people the risks from keeping their data in the cloud are actually lower than from keeping the data locally. It's a trade-off (and so must be optimized to particular situations, as with all trade-offs).
Things get more complex when you've got data which you want to keep confidential yet available (e.g., health records) but a lot of stuff doesn't need that level of caution.
Someone needs to figure out a way to get the people who are out of work in touch with these companies who are "desperate" to fill these open positions. It's a win-win situation.
Won't work. Many of those Americans aren't skilled in tech, and none of them are willing to be treated as slaves. That means that they'll have the temerity to demand proper training and pay! That would never do, as it might slightly cut into the fat bonuses given to part of the 1% lording it over the tech industry...
Since patents are used to limit the number of people who can do something, having a patent on something stupid will lead to limitations on the number of people doing said stupid thing.
Think of it like a tax on stupid. "Sure, I'm happy to license this technology to you. All it requires is the small fee of $1000 per student per course, plus a minor administration fee per course per year of $25000. Just tack it onto your charges, which they'll have to pay in order to graduate. Profit!"
The fact that it would lead to students not taking the course in the first place would even be considered to be a good thing by many professors with tenure...
To be fair, that all happened 60 years ago and many of those rules (including the ones making homosexuality illegal) are long gone. So too are virtually all the people involved (and the ones still alive are certainly no longer in a position to do much about it). About the only thing we can do now is say that it was a terrible shame that he died so young, and celebrate what he did achieve.
Cool! If I can find two stories that tell the same slant I want push, you'll believe them uncritically.
Anecdotes might indicate that there's something worth investigating, but even a great many of them can't indicate whether there's a real effect there if you don't know whether there are selection biases or other systematic problems. Once you've got "anecdotes" that are known to be representative of a population and that are verified as being actually true, you've got pretty good data, but simply having a lot of anecdotes isn't enough. If it was, you'd be totally happy to believe everything Big Tobacco says about the tremendous health benefits of smoking 40 cigarettes a day (especially if they're premium brands too).
And no kids. A screaming 1 year old is a major distraction.
Nothing that a quick pistol whipping won't sort out.
But seriously, a screaming 1 year old would indeed be a major distraction (and a really good reason to stop and do something about it) yet not all all 1 year olds are screaming terrors. Some really are good as gold; my niece would always go to sleep after about 20 minutes and a sleeping infant is no problem at all.
2) We also know that no DNA from 'before' the big bang could have made it into this universe for the simple reason that early conditions were incompatible with the existence of molecules.
Initial conditions were also incompatible with the existence of atoms, or even atomic nuclei. Yes, the Big Bang was very harsh indeed.
Java has the same issues, also using an immutable string class, but they fixed it by hacking the compiler to recognise where you are doing string concatenation in a loop and make a StringBuilder out of it instead.
That was always how Java did string concatenation (except in the cases where the compiler detecting it was concatenating literals, where it did the obvious optimization) and it's the only sane way to do it if you're not using a mutable string model and yet still have string identity other than by value. (Languages that don't expose object identity can pull some clever tricks to hide the details.) If you're ever stuck trying to optimize some Java code, the first thing to look for is whether they are doing string concatenation in a loop; if they are, expose the StringBuilder and go from quadratic to (amortized) linear performance, a very nice win for a virtually-mechanical change.
Well, technically Java used a StringBuffer in 1.4 and before, which is just like a StringBuilder but thread-synchronized (and that was a mysterious decision, which is why it was changed).
It's not a trademark because it's not a distinctive non-functional symbol or name intended to identify the product or the business that created it (Apple's logo, that's a trademark). Design patents cover non-functional aesthetic aspects of a particular product (or group of related products, such as different models of laptop from the same manufacturer). Trademarks and design patents are not the same thing, but they are definitely closely related: in particular, both are required to be non-functional and both are intended to prevent confusing similarity between products, services and companies.
Look at the nuclear industry to see how this works. The cost of an accident can easily be in the hundreds of billions range and no-one can afford that kind of insurance so the government covers it. Otherwise, they argue, we would not have nuclear power, or it would be "less efficient" and somehow cost more.
It happens in other industries too; above a certain level of catastrophe, the government ends up paying. The main difference with nuclear power seems to be that there's been a long history of military meddling (e.g., that's why we use uranium as fuel in the first place) and there's a significant lobby that completely panics every time someone says "nuclear accident"; the level of safety demanded by such people following an incident is often unrealistic, so they should bear some of the costs of reaching that level.
Then chemical weapons killed so many people all at once, the game wasn't fun anymore, but you could still send your plebians out to rattle your sabres.
Unfortunately for your thesis, it wasn't chemical weapons that made things "not fun" (they were too uncertain to be reliable weapons) but rather more prosaic things like machine gun nests and artillery.
An attack on 100s of accounts could rotate between accounts to get around the time limit. So now you are storing a short history in that database; or tracking an IP address but not being too aggressive with the IP due to NAT users... and bot nets do not have as much trouble getting IP addresses.
You are aware that such large-scale attacks are pretty rare? The vast majority involve one or two hosts. (You can tell this by looking at logs and overall net traffic levels.) They also tend to try all sorts of obvious things first; it's really easy to spot what's going on, and it usually reads like a litany of all that's wrong with IIS and PHP... but I digress. While theoretically, a botnet could be used to get past techniques like denyhosts, most botnets work on far more valuable things than breaking into a single account on a single computer. Hardly anyone has data valuable enough to be worth that effort (and with those I know who do, no botnet could break in anyway, as the data is held strictly offline).
So estimate the lifetime of the company, and the number of working hours that the company might operate, and assume that the remaining life of the company will be dedicated to supporting that product (?).
No, use an hourly rate plus incident fee. Tie them both to some independent inflation measure so you don't get messed over by external factors too much.
No non-trivial real-world program has ever been bug-free.
That's not strictly true. Some of the real safety-critical and mission-critical stuff really is that good off the bat (well, once it's reached deployment). You don't really want to think about how much it costs to develop to that standard though; it's usually reserved for things like signaling systems, interplanetary space probes, that sort of thing where bugs can have awful consequences or where fixes are potentially very difficult to deploy. Everyone else develops software the way they do, with the risk of bugs that it entails, because it's a gamble that usually pays off.
But people with trivial passwords never had any hope of security anyway, we can discount those accounts and identities and write them off with or without this leak. It's everyone else I'd be worried about.
Gosh, aren't we elitist today! Do you really think that lots of people use super-strong passwords for LinkedIn of all sites?
The real question is how well salted the passwords are; with appropriate salting, it's still going to be awkward to crack since you won't be able to use techniques like rainbow tables. (Also, if the salt is different from that found on other sites, it is still not very much use to find a solution to what can produce the SHA-1 hash, since a different site that uses a different salt source will have different collisions; about all the attacker could count on doing is log into LinkedIn...)
I call FUD. 64-bit is only "what people are after" because of marketing. Nothing more or less. I mean, think about it, what really is the point of 64-bit?
Being able to address more than 2GB of memory without the code getting horrific. Yes, you could conceivably run up to 4GB with only some problems, such as oddness with ptrdiff_t, but after that and you'd need some sort of manual paging solution with overlays or something like that; it was tried in the bad old DOS days (except with lower limits) and it was truly nasty so expanding to 64-bit (i.e., getting a wider address bus) is much better.
I suppose the other possibility would be to make the smallest addressable unit larger than a byte, but that causes lots of problems elsewhere (a lot of software assumes that all pointers to data are the same size). It also wouldn't help very long. A 32-bit minimum addressable unit would still only give an effective maximum memory of 8GB, and we're pushing past that on desktops now. (Things were held back by the 32-bit limit; now that's gone, normal growth rates have resumed.)
Killing the competition accomplishes the same thing. Think about it, would Google have asked for phone numbers and insisted on using real names a decade ago? They've got power now and their going to use it.
So you plan to use a poorly-implemented and unsustainable service deliberately instead? OK, it's your choice, but it is kind-of silly. Yes, competing with Google is hard, very hard, but nobody has the right to get web traffic, especially if they don't provide a service that is any good. Nor is it going to be possible for a service provider to keep providing the service unless they get money from somewhere, and I wouldn't want it to be done by government handouts!
Slashdot Mirror
I doubt that, legally, a server is a legal entity, or counts as a "communicating party".
It's operating on behalf of a legal entity, its owner (or someone that its owner is working for, which covers hosting). Its owner has specified (whether directly, by someone they hired, or by someone they trusted to work in their interests) that they want communications with it to be secured. There's quite clearly sufficient legal justification to say that they might have standing in this matter. If you use HTTPS to communicate with your bank, its clear you're talking to the bank, not just some random server that happens to belong to the bank.
Here's some free advice: try to avoid committing felonies, since you'll clearly be your own worst enemy in court with such stupid logic chopping as you show in your post.
Simply put, as Intel has no standing in the ARM market (and AMD has now), Intel has every motivation to distort the facts.
Did you know that Intel used to make ARM processors (StrongARM, XScale)? And that they are (probably) still an ARM licensee?
"Elon Musk" is a much better Bond villain name than "Richard Branson". The rest of your argument is superfluous.
We don't need to worry until he hires a giant with steel teeth...
as the number of IE7 using customers decreases, the rate of tax will have to increase
That would only follow if there was a requirement to cover the costs of IE7 out of the revenue obtained from the customers. Private businesses do not have to follow such a restrictive rule (and in fact almost always don't). Nor really do governments, but politics is a dirty game run by people who feel it necessary to act like morons.
Look at the details, and you'll see that the costs of supporting IE7 were already wildly disproportionate to the revenue obtained from it, so increasing the charges still won't cover the costs anyway. It might encourage migration though, which is OK too. The only time things really screw up is when some moron decides that each sub-group of customers has to cover all the costs involved with serving them, as that promotes really odd pricing policies. That moron would be you it seems...
Single point of failure is always bad
Yes. This, a thousand times, this.
trusting someone else to manage it is worse
Not really. You're just exchanging one set of risks for another. The risk of messing up on your own shouldn't be underestimated; a fat-fingered rm can cause a lot of damage. Of course, if you're really competent then you'll be aware of the single-point-of-failure problem in the first place and so will replicate as appropriate (and according to budget) but for a lot of people the risks from keeping their data in the cloud are actually lower than from keeping the data locally. It's a trade-off (and so must be optimized to particular situations, as with all trade-offs).
Things get more complex when you've got data which you want to keep confidential yet available (e.g., health records) but a lot of stuff doesn't need that level of caution.
First of all, you need a way to distinguish child abuse imagery from everything else
Just make all cameras and image manipulation software set the Evil Bit on all images that they produce that contain depictions of child abuse. Simple!
Someone needs to figure out a way to get the people who are out of work in touch with these companies who are "desperate" to fill these open positions. It's a win-win situation.
Won't work. Many of those Americans aren't skilled in tech, and none of them are willing to be treated as slaves. That means that they'll have the temerity to demand proper training and pay! That would never do, as it might slightly cut into the fat bonuses given to part of the 1% lording it over the tech industry...
Since patents are used to limit the number of people who can do something, having a patent on something stupid will lead to limitations on the number of people doing said stupid thing.
Think of it like a tax on stupid. "Sure, I'm happy to license this technology to you. All it requires is the small fee of $1000 per student per course, plus a minor administration fee per course per year of $25000. Just tack it onto your charges, which they'll have to pay in order to graduate. Profit!"
The fact that it would lead to students not taking the course in the first place would even be considered to be a good thing by many professors with tenure...
To be fair, that all happened 60 years ago and many of those rules (including the ones making homosexuality illegal) are long gone. So too are virtually all the people involved (and the ones still alive are certainly no longer in a position to do much about it). About the only thing we can do now is say that it was a terrible shame that he died so young, and celebrate what he did achieve.
I would guess the total cost would be less than ten billion dollars, if we were able to keep the government pork under control.
So... no chance of that happening. (Remember, the opposite of progress is Congress!)
The plural of anecdote is data.
Cool! If I can find two stories that tell the same slant I want push, you'll believe them uncritically.
Anecdotes might indicate that there's something worth investigating, but even a great many of them can't indicate whether there's a real effect there if you don't know whether there are selection biases or other systematic problems. Once you've got "anecdotes" that are known to be representative of a population and that are verified as being actually true, you've got pretty good data, but simply having a lot of anecdotes isn't enough. If it was, you'd be totally happy to believe everything Big Tobacco says about the tremendous health benefits of smoking 40 cigarettes a day (especially if they're premium brands too).
I've worked in IT for years in various functions. I do not trust computers to drive my car for me.
I've seen how bad many people seem to drive without computer assistance, and I also work in IT. I'm looking forward to the self-driving car.
And no kids. A screaming 1 year old is a major distraction.
Nothing that a quick pistol whipping won't sort out.
But seriously, a screaming 1 year old would indeed be a major distraction (and a really good reason to stop and do something about it) yet not all all 1 year olds are screaming terrors. Some really are good as gold; my niece would always go to sleep after about 20 minutes and a sleeping infant is no problem at all.
2) We also know that no DNA from 'before' the big bang could have made it into this universe for the simple reason that early conditions were incompatible with the existence of molecules.
Initial conditions were also incompatible with the existence of atoms, or even atomic nuclei. Yes, the Big Bang was very harsh indeed.
Better than the hobbled up shit they use today with Access databases linked to Excel dumps...
I see that you are familiar with VBA.
Java has the same issues, also using an immutable string class, but they fixed it by hacking the compiler to recognise where you are doing string concatenation in a loop and make a StringBuilder out of it instead.
That was always how Java did string concatenation (except in the cases where the compiler detecting it was concatenating literals, where it did the obvious optimization) and it's the only sane way to do it if you're not using a mutable string model and yet still have string identity other than by value. (Languages that don't expose object identity can pull some clever tricks to hide the details.) If you're ever stuck trying to optimize some Java code, the first thing to look for is whether they are doing string concatenation in a loop; if they are, expose the StringBuilder and go from quadratic to (amortized) linear performance, a very nice win for a virtually-mechanical change.
Well, technically Java used a StringBuffer in 1.4 and before, which is just like a StringBuilder but thread-synchronized (and that was a mysterious decision, which is why it was changed).
It's not a trademark because it's not a distinctive non-functional symbol or name intended to identify the product or the business that created it (Apple's logo, that's a trademark). Design patents cover non-functional aesthetic aspects of a particular product (or group of related products, such as different models of laptop from the same manufacturer). Trademarks and design patents are not the same thing, but they are definitely closely related: in particular, both are required to be non-functional and both are intended to prevent confusing similarity between products, services and companies.
Look at the nuclear industry to see how this works. The cost of an accident can easily be in the hundreds of billions range and no-one can afford that kind of insurance so the government covers it. Otherwise, they argue, we would not have nuclear power, or it would be "less efficient" and somehow cost more.
It happens in other industries too; above a certain level of catastrophe, the government ends up paying. The main difference with nuclear power seems to be that there's been a long history of military meddling (e.g., that's why we use uranium as fuel in the first place) and there's a significant lobby that completely panics every time someone says "nuclear accident"; the level of safety demanded by such people following an incident is often unrealistic, so they should bear some of the costs of reaching that level.
People are crap at managing risk.
Then chemical weapons killed so many people all at once, the game wasn't fun anymore, but you could still send your plebians out to rattle your sabres.
Unfortunately for your thesis, it wasn't chemical weapons that made things "not fun" (they were too uncertain to be reliable weapons) but rather more prosaic things like machine gun nests and artillery.
An attack on 100s of accounts could rotate between accounts to get around the time limit. So now you are storing a short history in that database; or tracking an IP address but not being too aggressive with the IP due to NAT users... and bot nets do not have as much trouble getting IP addresses.
You are aware that such large-scale attacks are pretty rare? The vast majority involve one or two hosts. (You can tell this by looking at logs and overall net traffic levels.) They also tend to try all sorts of obvious things first; it's really easy to spot what's going on, and it usually reads like a litany of all that's wrong with IIS and PHP... but I digress. While theoretically, a botnet could be used to get past techniques like denyhosts, most botnets work on far more valuable things than breaking into a single account on a single computer. Hardly anyone has data valuable enough to be worth that effort (and with those I know who do, no botnet could break in anyway, as the data is held strictly offline).
So estimate the lifetime of the company, and the number of working hours that the company might operate, and assume that the remaining life of the company will be dedicated to supporting that product (?).
No, use an hourly rate plus incident fee. Tie them both to some independent inflation measure so you don't get messed over by external factors too much.
No non-trivial real-world program has ever been bug-free.
That's not strictly true. Some of the real safety-critical and mission-critical stuff really is that good off the bat (well, once it's reached deployment). You don't really want to think about how much it costs to develop to that standard though; it's usually reserved for things like signaling systems, interplanetary space probes, that sort of thing where bugs can have awful consequences or where fixes are potentially very difficult to deploy. Everyone else develops software the way they do, with the risk of bugs that it entails, because it's a gamble that usually pays off.
But people with trivial passwords never had any hope of security anyway, we can discount those accounts and identities and write them off with or without this leak. It's everyone else I'd be worried about.
Gosh, aren't we elitist today! Do you really think that lots of people use super-strong passwords for LinkedIn of all sites?
The real question is how well salted the passwords are; with appropriate salting, it's still going to be awkward to crack since you won't be able to use techniques like rainbow tables. (Also, if the salt is different from that found on other sites, it is still not very much use to find a solution to what can produce the SHA-1 hash, since a different site that uses a different salt source will have different collisions; about all the attacker could count on doing is log into LinkedIn...)
I call FUD. 64-bit is only "what people are after" because of marketing. Nothing more or less. I mean, think about it, what really is the point of 64-bit?
Being able to address more than 2GB of memory without the code getting horrific. Yes, you could conceivably run up to 4GB with only some problems, such as oddness with ptrdiff_t, but after that and you'd need some sort of manual paging solution with overlays or something like that; it was tried in the bad old DOS days (except with lower limits) and it was truly nasty so expanding to 64-bit (i.e., getting a wider address bus) is much better.
I suppose the other possibility would be to make the smallest addressable unit larger than a byte, but that causes lots of problems elsewhere (a lot of software assumes that all pointers to data are the same size). It also wouldn't help very long. A 32-bit minimum addressable unit would still only give an effective maximum memory of 8GB, and we're pushing past that on desktops now. (Things were held back by the 32-bit limit; now that's gone, normal growth rates have resumed.)
Killing the competition accomplishes the same thing. Think about it, would Google have asked for phone numbers and insisted on using real names a decade ago? They've got power now and their going to use it.
So you plan to use a poorly-implemented and unsustainable service deliberately instead? OK, it's your choice, but it is kind-of silly. Yes, competing with Google is hard, very hard, but nobody has the right to get web traffic, especially if they don't provide a service that is any good. Nor is it going to be possible for a service provider to keep providing the service unless they get money from somewhere, and I wouldn't want it to be done by government handouts!