The top 400 people in the U.S. have the same wealth and the lowest 1650,000,000.
Given that the official population of the US is supposed to be 311,591,917 (Jul 2011, according to US census), you guys sure have a bigger problem with illegal immigrants than I thought!
If the attacked has lengthy, exclusive access to the chip and sufficiently advanced resources, basically nothing will stop them cracking it.
That's actually untrue. The trick is whether the memory can be read without powering up the chip; if not, then you can put in detection code (e.g., a rate limiter) that flushes the memory with crap if an attack is detected (which it's is easy to make the circuitry for). After that, the attacker might as well give up. Preventing reading the memory in unpowered state is the trick though, and the best techniques there tend to involve burying the secure memory elements under other parts of the chip so that you can't just grind them off and peek with an electron microscope. Of course, at that point the attacker has also invested many thousands in a decent microelectronics lab, and will need to break into a lot of chips just in order to recover their costs...
Or in other words, simple measures are actually quite sufficient.
a bunch of transit authorities use the word, there's metroPCS, some library consortium, a few other government entities, etc.
clearly, the word is common and abstract enough that anyone can claim it's usage
None of which would stop MS from using it as the name of their GUI system. More problematic is the fact that there's no chance of MS shifting anyone currently using a metro.tld website to something else; there's a lot of strong existing trademarks sitting there that would make any attempt to use legal mechanisms impractical and buying them all out very expensive.
Easier to just change the name to more closely identify with a different trademark; after all, only a limited number of developers know the UI by its current name.
Wrong, but the obviousness requirement is applied much more stringently so there are far fewer software patents granted. Getting a patent for being 6 months ahead of the competition is a problem, getting one for being 15 years ahead is not.
If you're a zealot, it's never possible to be pragmatic on the topic of your zealotry (that's pretty much the definition of "zealot"). Thus, to a Free Software zealot it is clearly impossible to be pragmatic on this topic: they feel that if it isn't Free, it's Wrong and so should be resisted with all possible effort. (I don't know if RMS is quite this zealous, but some of his adherents certainly are.)
Thankfully, such people are a small (but vocal) minority. For everyone else, pragmatism is indeed the best approach. Investment in improved graphics drivers would benefit many, whether or not their source is available. More worrying should be the fact that the Steam platform includes some DRM, so a kernel module would probably be desired by Valve to support this. OTOH, it's better to have it done well, once, than done badly many times.
IIRC BSD license basically says "do what you want, but credit us".
There's also a liability limitation clause and a prohibition on changing the license or removing the copyright notice. The variation in the BSD licenses (there's a few closely related ones) mostly stems from just how much attribution is required; some want rather more than others. The difference rarely gets BSD people very worked up.
The net effect of the BSD license is to disclaim economic rights while maintaining something as close to moral rights as is recognized by US copyright law. You'd word it differently in European copyright law, where moral rights are recognized as as separate concern completely to economic rights (and aren't normally traded).
There's nothing wrong with wanting credit for one's own work. If it's in public domain, however, people can just use it, and I believe it's not illegal to claim the work is yours, though they won't have licensing/ownership rights
If something is truly in the public domain, you can do anything with it. This includes adding text to it that looks like a copyright notice. (I think this wouldn't make your copy of the work be non-PD in itself, as copyright notices in themselves are not a substantive creative element of any work, but I can't be sure. But the placing of the text there, that can be done.) There are also jurisdictions (not in the US) where the only way a work can enter the PD is by having its copyright term expire. PD is way more complicated than BSD (or the GPL variations), even though it sounds like ought to be simpler at first.
Do you not think it was a flaw to target a spec towards a specific language/architecture?
From the perspective of someone on the outside of the process, it was both a mistake and not a mistake. It was a mistake in that it causes too many compromises to be made. It was not a mistake in that it allowed a great many deployments to be made very rapidly. IMO, they should have compromised a bit less and pushed back at the Apache devs a bit harder to get them to support making the necessary information available.
But I wasn't there, so I've very little room to criticize.
TLS is not broken at all. Using it properly can be difficult. This, as well as lack of redundant security mechanisms is the reason Eran Hammer didn't like relying on TLS solely. If you think TLS is broken, you may be confusing it with the public key infrastructure everyone uses for HTTPS. The problems with poorly run signing authorities are not fundamentally technological but administrative. Outside of accessing public HTTPS sites with a browser, you can take more control over the certificates and policies used for TLS authentication.
To be more exact, the key to using TLS well is controlling the code that determines whether a particular chain of certificates (the ones authorizing a connection) are actually trusted. HTTPS does this one particular way (a fairly large group of root CAs that can delegate to others, coupled with checking that a host is actually claiming to be able to act for the hostname that was actually requested) but it isn't the only way; having a list of X.509 certificates that you trust and denying all others is far more secure (though annoying from a deployment perspective). There are a number of other policies that you could use; there's no reason you couldn't build a web-of-trust model, or use cunningness in certificate extensions, or apply path length constraints, or...
The deep problem is that there are two key parts; authentication, and authorization. They're totally different things. Authentication gives you a token that describes someone or something with varying levels of detail, which could be anywhere from a bare UUID to a long list of descriptive information. Authorization is the process of taking the token, plus possible extra information supplied by various parties, and working out what you want to actually allow them to do. In the simple case, where you've got clients and servers and the servers don't talk to each other, it's very easy. The problem comes when the client wants to tell Server A to do something on Server B on their behalf (or even A controls something on B which controls something on C; I have situations were that depth of complexity is relevant, A being a portal, B a workflow engine, and C a filestore or database); that's the delegation problem, and it's been causing people trouble for many years.
The root of the delegation problem is that you can't do a zero-trust delegation; the parties in the delegation have to trust each other to not be evil and misuse the tokens being passed around. There are ways to minimize the trust required, but that's surprisingly difficult to get right. It's all not helped at all by the fact that there aren't any real standards for doing delegation (specifications, yes; accepted standards, no) and the fact that it can't be zero-trust makes the deep security hackers hate the whole idea. That in turn encourages them to work on the wrong parts of the problem; we don't need Yet Another scheme for limiting the amount of trust being delegated or for limiting who it can be delegated to (I've yet to see a scheme which can work in a real, messy deployment).
I prefer to avoid security as an area. It's a real mess, and the community isn't very cohesive.
I'm gonna stop you right there. You should get a big slap in the face for saying REST and SOAP are on the same level!
You're right about that, they're not the same thing. They're fundamentally different ways of viewing an application on the web (one is about describing things beforehand, the other at runtime; one is about factoring verbs first, the other is nouns first). But from the perspective of the big picture, they're really not that different.
SOAP sucks big monkeyballs and REST doesn't, period.
That's what it seems like to you, but when you're working with applications that you're building on top of these webapps, SOAP works better. The tooling is better. The separation of concerns is better. The message characterization is better. You might claim that that is because the messages can change over time, but the alternative that the REST architectural style tends to propose isn't a win.
My webapps expose both SOAP and (strict, HATEOAS) RESTful interfaces. Neither is superior to the other in all areas.
It refers to the plethora of web-services specifications, most of which take a fairly complicated protocol (XML over HTTP) and add huge new layers of mind-boggling complexity.
You don't ever need WS-*, except when you find you do because you're dealing with the situations that the WS-* protocol stack was designed to deal with. When that happens, you'll reinvent it all. Badly. JSON isn't better than XML, nor is YAML; what they gain in succinctness and support for syntactic types, they lose at the semantic level. REST isn't better than SOAP, it's just different, and security specifications in the REST world are usually hilariously lame. Then there's the state of service description, where WSDL is the only spec that's ever really gained really wide traction. WS-* depresses me; I believe we should be able to do better, but the evidence of what happens in practice doesn't support that hunch.
Spain and Greece would have problems regardless of whether or not they had their own currency.
If they had their own currencies it might help because it would enable shrinking some of the debts through printing money ("Quantitative Easing"). That in turn would allow some of the pain to be sneaked past people without them noticing immediately.
But the pain would still come. Greece is a complete basket case, and the root causes there are simple: far too much spending, not nearly enough taxing. Of course, that's not an easy position to sell to the people; paying more for less never is. What's worse, Greece has been in this position for decades. Even exiting the Euro (i.e., devaluing massively, since who would want drachmas?) and defaulting on lots of debts won't fix things. They are screwed. Indeed, the big question there is really how much public unrest can be tolerated?
Spain is more interesting, as that's got much closer to a functioning economy. The problem there is a mix of sclerotic labor markets and dodgy link-ups between local politicians and local banks. The problems with the labor markets over quite a few years had meant that young people tended to be employed in the construction industry, and that collapsed several years ago. Everything was exacerbated by the local political/banking tie-ups getting a good taste for foolish mega-projects that are impressive to look at but totally not justified by levels of actual use. They've predictably resulted in those local banks having massive bad debts (technically in the private sector) and the construction workers who used to be involved in them also being made redundant. So now they've got massive levels of unemployment and loads of near-bankrupt banks; the businesses that do exist mostly don't want the skills of the unemployed (they're not construction firms) and have trouble getting financing. The biggest problem is the unemployment, as that's a lot of people who can get into mischief (yes, most won't, but it's a numbers game), but changes of regulation can help. The banking problems are just going to have to result in some banks being wound up, though the entanglement of them with local politicians makes that harder.
But for every borrower there must be a lender. Who is lending unwisely so as to let these economies get into this state? Well, it's looking like the biggest lenders were French and German banks. (Sure, other international banks were involved too, but not on the same scale.) Guess what the next phase of this crisis is going to be?
Anyone with a single brain cell, indeed even most amoebas stayed far away from the Facebook IPO.
Amoebas, being single-celled organisms, don't have share holdings. This is an example of evolution perfectly equipping them to cope with the Facebook IPO.
So I ask myself: Why is this not in the html spec?
Because it doesn't belong there, WHATWG's ridiculous posturing and power-grabbing notwithstanding. Client certificates are a feature of the protocol layer. Specifically, they're an optional feature of the SSL/TLS part of HTTPS. If the server requests them (it's off by default) and the client knows them, they'll be negotiated during connection setup. From the perspective of HTTP, they're just contextual information. From the perspective of HTML, they don't exist at all (and shouldn't; HTML is a document format, not a security negotiation protocol).
I'm afraid I don't have quotes from USENET in 1992 at hand.
It's been like September for 20 years, but I'm guessing that over that time the total amount of intelligent posting on the internet (and its predecessors) has been an absolute constant. If only it wasn't spread out over an ever-increasing number of morons and shills, we'd be OK. OTOH, search has got a lot better than it used to be: searching for things in '92 was a PITA. If you actually wanted to find something back then, you wouldn't use the internet, you'd use a reference book. You know, one of those things on paper.
You don't have to trust the same people I do. So long as we can find identity providers who talk compatible protocols so that consumers of identities don't need to care, it doesn't matter. (Note that the majority of providers only really guarantee to tell sites "this is the same person who logged in as that other time" and not any information more than that, such as actual names. For a lot of uses that's good enough, but not all.)
Also what happens once the central repository is compromised?
You'd rather have logins on hundreds of badly-maintained blogs instead of a well-maintained central point with dedicated admins who actually know what they're doing? (You can even run your own "central" point if you want. I don't want to do that for my ID provision needs, but you've got the option with things like OpenID and OAuth.) Outsourcing to a specialist cuts the risk profile.
Six weeks is not really an unreasonably short release cadence, unless you work for a defense contractor or something.
Cool. Can we start doing updates to your C library on that schedule? We'll just introduce a few incompatible changes with every release, you'll hardly even notice them. Just restart your downstream dependencies and everything will be tickety-boo!
The problem is, that doesn't seem to be true. 4 out of 5 Americans support the use of full body scanners.
[...]
There have been other polls about the same thing with slightly different results, but they all show a significant majority favor their use - such as this one with 2/3 in support: [...]
Americans value the illusion very highly, and will trade almost any amount of freedom for it.
The problem with polls is that they are extremely susceptible to problems in the framing of the question; if you know what you're doing when you write the questions, you can get any answer you want. ("Do you want to be blown up by arab terrorists or do you support scanners in airports that prevent such terrible things from happening?") What's more, polls are easily skewed if the sampling isn't representative of the nation, and it's common to give the figures while omitting to mention what proportion of people polled didn't express an opinion. There's also the classic problem of the unreported sample size; ask too few, and you can get a misleading answer purely by chance even if you're not trying to be intellectually dishonest.
Polling is hard if you want to get proper, truthful answers out...
[I'm making no specific allegations about these particular polls. Just... don't believe everything you read, OK?]
No need to join them up. Send the cargo on ahead and you know it will be there when you get there.
Wouldn't work for a longer-term mission like going to Mars, as you've still got to send a lot of stuff for the astronauts to use along the way. You've also got to pack a lot more shielding due to the increased duration of exposure to solar radiation. Not impossible to deal with, but definitely a lot more mass overall and it's far easier to get that stuff to orbit in several pieces.
It's because we don't have professional standards for software engineers the same way as we have for other types of engineers. Software is still in the "bridge collapse" phase. At one time, anyone could build a bridge. You know what happened? A lot of them fell down, and that was just considered normal. Eventually, society got fed up with that crap and made standards, with jail time for violators.
I see you're advocating a large increase to the cost of software for very little gain in actual reliability. Any proper engineer (or True Scotsman) would know that it is important to balance cost and benefit; for a significant fraction of applications, that balance is firmly towards the cheap end. Guess what? Most of the cheap software is also perfectly fine for its purpose after a few iterations. (Well, that's true if we exclude anything written in PHP, which appears to be the only language and community ever to actively hate consistency to the point of working directly against it.)
Wasn't Marissa Mayer the one responsible for attempting to force a gigantic background image onto the search portal so Google could look cool like Bing? As I recall that lasted about 4 hours. The upcoming show ought be good for some entertainment if nothing else.
If she's able to back down when something just doesn't work as well as it should, despite the personal embarrassment, then she's better than the vast majority of people in managerial positions.
There is no way for plain English to be as clear as code. Code does what it says it does. English says what it wants or thinks should happen.
But keeping track of what you think should happen is important too. Code does what it says it does, but that's all it does. Documentation serves a different purpose.
Mind you, the best documentation I ever saw was a comment in the code that said that the algorithm implemented was documented in an academic paper from about 20 years previously (well, it said exactly what the paper was). It didn't say anything else, just pointed to the definitive explanation of what was going on and why to choose it. I suppose that for something newer I'd expect a URL or DOI; it's still conceptually the same thing.
Slashdot Mirror
The top 400 people in the U.S. have the same wealth and the lowest 1650,000,000.
Given that the official population of the US is supposed to be 311,591,917 (Jul 2011, according to US census), you guys sure have a bigger problem with illegal immigrants than I thought!
If the attacked has lengthy, exclusive access to the chip and sufficiently advanced resources, basically nothing will stop them cracking it.
That's actually untrue. The trick is whether the memory can be read without powering up the chip; if not, then you can put in detection code (e.g., a rate limiter) that flushes the memory with crap if an attack is detected (which it's is easy to make the circuitry for). After that, the attacker might as well give up. Preventing reading the memory in unpowered state is the trick though, and the best techniques there tend to involve burying the secure memory elements under other parts of the chip so that you can't just grind them off and peek with an electron microscope. Of course, at that point the attacker has also invested many thousands in a decent microelectronics lab, and will need to break into a lot of chips just in order to recover their costs...
Or in other words, simple measures are actually quite sufficient.
just look up metro on google
a bunch of transit authorities use the word, there's metroPCS, some library consortium, a few other government entities, etc.
clearly, the word is common and abstract enough that anyone can claim it's usage
None of which would stop MS from using it as the name of their GUI system. More problematic is the fact that there's no chance of MS shifting anyone currently using a metro.tld website to something else; there's a lot of strong existing trademarks sitting there that would make any attempt to use legal mechanisms impractical and buying them all out very expensive.
Easier to just change the name to more closely identify with a different trademark; after all, only a limited number of developers know the UI by its current name.
This is also why the only NON-science prize is the peace prize.
Literature is a science?
And they had great makeup artists!
One, there are no software patents in Europe.
Wrong, but the obviousness requirement is applied much more stringently so there are far fewer software patents granted. Getting a patent for being 6 months ahead of the competition is a problem, getting one for being 15 years ahead is not.
If you're a zealot, it's never possible to be pragmatic on the topic of your zealotry (that's pretty much the definition of "zealot"). Thus, to a Free Software zealot it is clearly impossible to be pragmatic on this topic: they feel that if it isn't Free, it's Wrong and so should be resisted with all possible effort. (I don't know if RMS is quite this zealous, but some of his adherents certainly are.)
Thankfully, such people are a small (but vocal) minority. For everyone else, pragmatism is indeed the best approach. Investment in improved graphics drivers would benefit many, whether or not their source is available. More worrying should be the fact that the Steam platform includes some DRM, so a kernel module would probably be desired by Valve to support this. OTOH, it's better to have it done well, once, than done badly many times.
IIRC BSD license basically says "do what you want, but credit us".
There's also a liability limitation clause and a prohibition on changing the license or removing the copyright notice. The variation in the BSD licenses (there's a few closely related ones) mostly stems from just how much attribution is required; some want rather more than others. The difference rarely gets BSD people very worked up.
The net effect of the BSD license is to disclaim economic rights while maintaining something as close to moral rights as is recognized by US copyright law. You'd word it differently in European copyright law, where moral rights are recognized as as separate concern completely to economic rights (and aren't normally traded).
There's nothing wrong with wanting credit for one's own work. If it's in public domain, however, people can just use it, and I believe it's not illegal to claim the work is yours, though they won't have licensing/ownership rights
If something is truly in the public domain, you can do anything with it. This includes adding text to it that looks like a copyright notice. (I think this wouldn't make your copy of the work be non-PD in itself, as copyright notices in themselves are not a substantive creative element of any work, but I can't be sure. But the placing of the text there, that can be done.) There are also jurisdictions (not in the US) where the only way a work can enter the PD is by having its copyright term expire. PD is way more complicated than BSD (or the GPL variations), even though it sounds like ought to be simpler at first.
Do you not think it was a flaw to target a spec towards a specific language/architecture?
From the perspective of someone on the outside of the process, it was both a mistake and not a mistake. It was a mistake in that it causes too many compromises to be made. It was not a mistake in that it allowed a great many deployments to be made very rapidly. IMO, they should have compromised a bit less and pushed back at the Apache devs a bit harder to get them to support making the necessary information available.
But I wasn't there, so I've very little room to criticize.
TLS is not broken at all. Using it properly can be difficult. This, as well as lack of redundant security mechanisms is the reason Eran Hammer didn't like relying on TLS solely. If you think TLS is broken, you may be confusing it with the public key infrastructure everyone uses for HTTPS. The problems with poorly run signing authorities are not fundamentally technological but administrative. Outside of accessing public HTTPS sites with a browser, you can take more control over the certificates and policies used for TLS authentication.
To be more exact, the key to using TLS well is controlling the code that determines whether a particular chain of certificates (the ones authorizing a connection) are actually trusted. HTTPS does this one particular way (a fairly large group of root CAs that can delegate to others, coupled with checking that a host is actually claiming to be able to act for the hostname that was actually requested) but it isn't the only way; having a list of X.509 certificates that you trust and denying all others is far more secure (though annoying from a deployment perspective). There are a number of other policies that you could use; there's no reason you couldn't build a web-of-trust model, or use cunningness in certificate extensions, or apply path length constraints, or ...
The deep problem is that there are two key parts; authentication, and authorization. They're totally different things. Authentication gives you a token that describes someone or something with varying levels of detail, which could be anywhere from a bare UUID to a long list of descriptive information. Authorization is the process of taking the token, plus possible extra information supplied by various parties, and working out what you want to actually allow them to do. In the simple case, where you've got clients and servers and the servers don't talk to each other, it's very easy. The problem comes when the client wants to tell Server A to do something on Server B on their behalf (or even A controls something on B which controls something on C; I have situations were that depth of complexity is relevant, A being a portal, B a workflow engine, and C a filestore or database); that's the delegation problem, and it's been causing people trouble for many years.
The root of the delegation problem is that you can't do a zero-trust delegation; the parties in the delegation have to trust each other to not be evil and misuse the tokens being passed around. There are ways to minimize the trust required, but that's surprisingly difficult to get right. It's all not helped at all by the fact that there aren't any real standards for doing delegation (specifications, yes; accepted standards, no) and the fact that it can't be zero-trust makes the deep security hackers hate the whole idea. That in turn encourages them to work on the wrong parts of the problem; we don't need Yet Another scheme for limiting the amount of trust being delegated or for limiting who it can be delegated to (I've yet to see a scheme which can work in a real, messy deployment).
I prefer to avoid security as an area. It's a real mess, and the community isn't very cohesive.
I'm gonna stop you right there. You should get a big slap in the face for saying REST and SOAP are on the same level!
You're right about that, they're not the same thing. They're fundamentally different ways of viewing an application on the web (one is about describing things beforehand, the other at runtime; one is about factoring verbs first, the other is nouns first). But from the perspective of the big picture, they're really not that different.
SOAP sucks big monkeyballs and REST doesn't, period.
That's what it seems like to you, but when you're working with applications that you're building on top of these webapps, SOAP works better. The tooling is better. The separation of concerns is better. The message characterization is better. You might claim that that is because the messages can change over time, but the alternative that the REST architectural style tends to propose isn't a win.
My webapps expose both SOAP and (strict, HATEOAS) RESTful interfaces. Neither is superior to the other in all areas.
What's WS-* supposed to mean...
It refers to the plethora of web-services specifications, most of which take a fairly complicated protocol (XML over HTTP) and add huge new layers of mind-boggling complexity.
You don't ever need WS-*, except when you find you do because you're dealing with the situations that the WS-* protocol stack was designed to deal with. When that happens, you'll reinvent it all. Badly. JSON isn't better than XML, nor is YAML; what they gain in succinctness and support for syntactic types, they lose at the semantic level. REST isn't better than SOAP, it's just different, and security specifications in the REST world are usually hilariously lame. Then there's the state of service description, where WSDL is the only spec that's ever really gained really wide traction. WS-* depresses me; I believe we should be able to do better, but the evidence of what happens in practice doesn't support that hunch.
Spain and Greece would have problems regardless of whether or not they had their own currency.
If they had their own currencies it might help because it would enable shrinking some of the debts through printing money ("Quantitative Easing"). That in turn would allow some of the pain to be sneaked past people without them noticing immediately.
But the pain would still come. Greece is a complete basket case, and the root causes there are simple: far too much spending, not nearly enough taxing. Of course, that's not an easy position to sell to the people; paying more for less never is. What's worse, Greece has been in this position for decades. Even exiting the Euro (i.e., devaluing massively, since who would want drachmas?) and defaulting on lots of debts won't fix things. They are screwed. Indeed, the big question there is really how much public unrest can be tolerated?
Spain is more interesting, as that's got much closer to a functioning economy. The problem there is a mix of sclerotic labor markets and dodgy link-ups between local politicians and local banks. The problems with the labor markets over quite a few years had meant that young people tended to be employed in the construction industry, and that collapsed several years ago. Everything was exacerbated by the local political/banking tie-ups getting a good taste for foolish mega-projects that are impressive to look at but totally not justified by levels of actual use. They've predictably resulted in those local banks having massive bad debts (technically in the private sector) and the construction workers who used to be involved in them also being made redundant. So now they've got massive levels of unemployment and loads of near-bankrupt banks; the businesses that do exist mostly don't want the skills of the unemployed (they're not construction firms) and have trouble getting financing. The biggest problem is the unemployment, as that's a lot of people who can get into mischief (yes, most won't, but it's a numbers game), but changes of regulation can help. The banking problems are just going to have to result in some banks being wound up, though the entanglement of them with local politicians makes that harder.
But for every borrower there must be a lender. Who is lending unwisely so as to let these economies get into this state? Well, it's looking like the biggest lenders were French and German banks. (Sure, other international banks were involved too, but not on the same scale.) Guess what the next phase of this crisis is going to be?
Anyone with a single brain cell, indeed even most amoebas stayed far away from the Facebook IPO.
Amoebas, being single-celled organisms, don't have share holdings. This is an example of evolution perfectly equipping them to cope with the Facebook IPO.
So I ask myself: Why is this not in the html spec?
Because it doesn't belong there, WHATWG's ridiculous posturing and power-grabbing notwithstanding. Client certificates are a feature of the protocol layer. Specifically, they're an optional feature of the SSL/TLS part of HTTPS. If the server requests them (it's off by default) and the client knows them, they'll be negotiated during connection setup. From the perspective of HTTP, they're just contextual information. From the perspective of HTML, they don't exist at all (and shouldn't; HTML is a document format, not a security negotiation protocol).
I'm afraid I don't have quotes from USENET in 1992 at hand.
It's been like September for 20 years, but I'm guessing that over that time the total amount of intelligent posting on the internet (and its predecessors) has been an absolute constant. If only it wasn't spread out over an ever-increasing number of morons and shills, we'd be OK. OTOH, search has got a lot better than it used to be: searching for things in '92 was a PITA. If you actually wanted to find something back then, you wouldn't use the internet, you'd use a reference book. You know, one of those things on paper.
It's impossible to find someone everyone trusts.
You don't have to trust the same people I do. So long as we can find identity providers who talk compatible protocols so that consumers of identities don't need to care, it doesn't matter. (Note that the majority of providers only really guarantee to tell sites "this is the same person who logged in as that other time" and not any information more than that, such as actual names. For a lot of uses that's good enough, but not all.)
Also what happens once the central repository is compromised?
You'd rather have logins on hundreds of badly-maintained blogs instead of a well-maintained central point with dedicated admins who actually know what they're doing? (You can even run your own "central" point if you want. I don't want to do that for my ID provision needs, but you've got the option with things like OpenID and OAuth.) Outsourcing to a specialist cuts the risk profile.
Six weeks is not really an unreasonably short release cadence, unless you work for a defense contractor or something.
Cool. Can we start doing updates to your C library on that schedule? We'll just introduce a few incompatible changes with every release, you'll hardly even notice them. Just restart your downstream dependencies and everything will be tickety-boo!
The problem is, that doesn't seem to be true. 4 out of 5 Americans support the use of full body scanners.
[...]
There have been other polls about the same thing with slightly different results, but they all show a significant majority favor their use - such as this one with 2/3 in support: [...]
Americans value the illusion very highly, and will trade almost any amount of freedom for it.
The problem with polls is that they are extremely susceptible to problems in the framing of the question; if you know what you're doing when you write the questions, you can get any answer you want. ("Do you want to be blown up by arab terrorists or do you support scanners in airports that prevent such terrible things from happening?") What's more, polls are easily skewed if the sampling isn't representative of the nation, and it's common to give the figures while omitting to mention what proportion of people polled didn't express an opinion. There's also the classic problem of the unreported sample size; ask too few, and you can get a misleading answer purely by chance even if you're not trying to be intellectually dishonest.
Polling is hard if you want to get proper, truthful answers out...
[I'm making no specific allegations about these particular polls. Just... don't believe everything you read, OK?]
No need to join them up. Send the cargo on ahead and you know it will be there when you get there.
Wouldn't work for a longer-term mission like going to Mars, as you've still got to send a lot of stuff for the astronauts to use along the way. You've also got to pack a lot more shielding due to the increased duration of exposure to solar radiation. Not impossible to deal with, but definitely a lot more mass overall and it's far easier to get that stuff to orbit in several pieces.
10.11 tons = 10.11 x 2000 x 12 troy oz of gold
At $1580/troy oz that is $383M
A pity for your argument that a ton is 29166.67 troy ounces; you're about $80M short. Still, much less than $16B...
It's because we don't have professional standards for software engineers the same way as we have for other types of engineers. Software is still in the "bridge collapse" phase. At one time, anyone could build a bridge. You know what happened? A lot of them fell down, and that was just considered normal. Eventually, society got fed up with that crap and made standards, with jail time for violators.
I see you're advocating a large increase to the cost of software for very little gain in actual reliability. Any proper engineer (or True Scotsman) would know that it is important to balance cost and benefit; for a significant fraction of applications, that balance is firmly towards the cheap end. Guess what? Most of the cheap software is also perfectly fine for its purpose after a few iterations. (Well, that's true if we exclude anything written in PHP, which appears to be the only language and community ever to actively hate consistency to the point of working directly against it.)
Wasn't Marissa Mayer the one responsible for attempting to force a gigantic background image onto the search portal so Google could look cool like Bing? As I recall that lasted about 4 hours. The upcoming show ought be good for some entertainment if nothing else.
If she's able to back down when something just doesn't work as well as it should, despite the personal embarrassment, then she's better than the vast majority of people in managerial positions.
If you look at all the data that's out there, most of it is managed using the database family known as "file systems".
Invalid point. Lots of databases host inside filesystems, so you would be forced to claim some data for both sides. Which is just nonsense.
There is no way for plain English to be as clear as code. Code does what it says it does. English says what it wants or thinks should happen.
But keeping track of what you think should happen is important too. Code does what it says it does, but that's all it does. Documentation serves a different purpose.
Mind you, the best documentation I ever saw was a comment in the code that said that the algorithm implemented was documented in an academic paper from about 20 years previously (well, it said exactly what the paper was). It didn't say anything else, just pointed to the definitive explanation of what was going on and why to choose it. I suppose that for something newer I'd expect a URL or DOI; it's still conceptually the same thing.