Cheaper and easier to convince the PHB to buy a certificate signed by a public CA, than install your own CA certificate on every browser in your company.
Then your organization's IT department needs to learn about Group Policy and its counterparts on other common personal computing platforms.
Yeah, but getting all that to work when dealing with the reality of BYOD in many organisations (universities have a particular problem with this) is massively more complicated and expensive than ponying up for an externally-signed certificate. Heck, even getting an externally-signed local CA certificate is cheaper. Group policy (and equivalent) works relatively well for desktops and other wholly-owned devices, but ceases to be nearly so useful once you have to deal with anything external, and that's more and more common.
To put things in perspective - the old owners had plants in 5 different states. Each of the other plants consistently lost money. Our plant consistently MADE MONEY, despite mismanagement. Quarter after quarter, the accountants posted profits from our plant. In effect, we carried four other money losing plants for years. The owners could never bring themselves to unload the money losers, instead taking the profits we earned to shore up the other plants. They followed that policy until bankruptcy put them out of the game completely.
Were any of those plants making key inputs for yours? If they were, and it wasn't practical to consolidate that function, then closing them down would have crippled you. Which individual plants make money is one thing, but where there's internal transfer of items between units of the business, the value attached to those items is fairly nominal in practice; it's the overall business that really makes the profit or the loss.
Or maybe they're just incompetent fucks. That could be true too. Hard to say without the full facts, but the fact that bankruptcy hit is strongly indicative.
A masters in computer science program means taking about 10 three credit courses to get the degree. That means learning potentially 10 different languages. Which 10 would you choose? Which of those 10 are a must to learn, which would be merely advantageous to know?
Take at least one OO language (Java's fussy and bureaucratic, but its a pretty good example of the breed and is likely to be useful after you get your masters), at least one functional language (probably Haskell these days), at least one declarative language (Prolog or SQL), and don't just learn programming languages. You also need to learn about data, about data structures, about algorithms and their analysis, about parsing and compilation, and about concurrency; these are all independent of any programming language.
But computing is well served by not just learning about computing. If you have time, learn about math, stats and logic too, and learn how to communicate your ideas effectively; you'll never get far if you can't communicate with other people well.
If hardware isn't the problem, then it must be an algorithmic one. So, why can't an algorithm be discovered that is a breakthrough?
The problem is that it requires a true breakthrough, and there's no way to predict when that will happen. It also doesn't help that we don't really know what intelligence really is; all we've got is lots of things it isn't. I suspect that when someone cracks it, there'll be lots of people going "Is that all?! Anyone could have got that." and they'd be right, except that nobody did and it involves something both trivial and non-obvious. It might also require a lot of parallel processing, which we're still learning how to do well.
As we don't have any handy breakthroughs right now, we should instead study how brains really work and how to make computers do useful things (including stuff like "understanding" speech, "understanding" written natural language, drive cars safely, etc.) Those might or might not make the breakthrough easier, but they'll have other benefits along the way so they're still right to do.
Don't worry about that! They had their own classes of blunders instead. (Every programming language has a characteristic set of problems that come up, and a set of recommended programming practices that avoid those blunders.)
Actually it's about non-standard-conforming "security" hacks causing unexpected results. If the result of an operation is undefined, the compiler can insert code to summon Cthulhu if it wants to.
If your compiler is doing that, you should choose a different compiler. Summoning elder gods just because signed arithmetic might wrap around is not a good cost/benefit tradeoff!
Except browsers can actually send a header that lists your preferred languages, in order. Chrome can actually does this, although it's buried away under "Advanced Settings". Google just don't pay any attention to it on their servers (apparently).
If a lot of browsers are getting it wrong in what they send, the incentive to support it is not strong. Guess what? A quick test with Chrome, Safari and Firefox indicate that they all get it wrong by default. Safari doesn't provide an option to change it that I can find; the other two pick the wrong default for me, instead of using the system language settings (which are correct and available for software to read) even if those are imperfect for the task. (I'm on the wrong platform for testing IE and I don't have Opera.)
Why would you make your website use a feature that no browser gets close to right by default?
Turing also didn't say anything about crippling the test by making it a child who doesn't speak fluent English.
He also didn't specify that the software couldn't do that. The test isn't about knowledge, it's about intelligence. Computers are starting to get good at the more knowledge-y side of things, but intelligence has got to be more about establishment of shared context, dealing with weird semi-out-of-the-blue digressions, and so on. Language fluency is someone else's research project.
He is a "useful idiot" with a lot of information in his pocket. When they are finished with him, he is either going to be returned to the U.S or he is just going to "disappear" into the abyss.
Snowden's principal value to the Russians is for propaganda purposes, and this was the case all along. Making one's opponents look very bad is quite thoroughly valuable from a diplomacy perspective, since it persuades third parties (e.g., most of Latin America and Africa) to be more receptive to your message.
ARM is SO not going to be competing in servers any time soon. Our "cheap" x86-64 servers are already at 24 cores and 64-96GB RAM. Once ARM gets anywhere near that those server specs will be 4x that, or more...
With large server deployments, performance per watt is a very relevant metric. This is because the limiting factor is actually keeping the server cluster from cooking itself, even with very good cooling in place. PPW is an area where ARM is generally quite a lot better than the x86 variants. After all, who cares if a system is slower when you can compensate by just cramming more cores in? (I don't know if ARM's floating point handling is good enough yet to compete in this area though; the big server guys really care about their number crunching.)
That said, ARM's really large advantage over at least x86 is that they're a design that they license out to others to manufacture. This does mean that they can't typically use all the very latest fabrication technologies, but it also means that for a third party manufacturer who has some of their own secret sauce for a specific market, they can get an ARM core for a reasonable amount and integrate it (rather than having to send it elsewhere for fab where they won't know who is watching). This is an advantage that it is hard to overstate; there will be lots of ARMs about for a long time to come.
The other thing to consider in mobile applications is what the noise ceiling of the CPU is; lower noise means less shielding and so less weight and cost. You've got to think in terms of optimising the whole system, not just the CPU core.
Taxis take your credit card after the ride is over. A serial killer has plenty of time to do bad stuff to you before your card is used. Uber knows who you are from the moment you hail the cab.
Not if the serial killer has stolen someone else's phone (and killed them too, natch).
Agreed, LHR makes no sense to me. I never know where I am or how to get where I'm going. The only place that comes close is Japan's NRT, but that's only a maze in the 4th floor shopping area.
LHR (except T5, and possibly the new T2 but that only opened this week) is like one of these intelligence testing devices for mice, but for people. You just have to follow the signs and hope. I find that FRA and ZRH are pretty bad that way too, at least for transit passengers, and BRU was managing to hide where the gates were at all earlier this year. (Past the bar and hidden behind some large advertising stands promoting an anonymous sports-car that were also covering up the signs saying where the gates were; yeah, hiding the absolute #1 thing that people want in an airport is idiotic.) And please don't route me via LIN. I'll be good, I promise.
In the US, the places to really avoid are JFK and LAX. Both are horrible places to change planes (especially between terminals). ATL, DTW, MSP, ORD, IAD and SFO are all much better. (MEM is OK, but a bit twisty, and I hate BOS for other reasons that aren't the airport's fault. I've yet to change planes elsewhere in the US.)
In an airport, a place with substantive overt security, likely many cameras, and where the government sees passenger manifests before takeoff? Oh noes!
That's a lambda term (i.e., anonymous function) and not a closure. You tend to use them together, but they're formally different. A closure would be having a variable defined in the outer function being accessed and/or updated in the inner one.
The shared libs approach is like the legacy of a chemical waste dump... it's there, it seemed like a good idea at the time, and there is not a whole lot anyone is doing to deal with the problems it causes simply by existing. Memory and disk space are no longer expensive, but catch-22 shared library hell is forever.
The original Linux shared library system was the toxic waste dump, being basically impossible to use if you weren't a distribution maker (every shared library had to have its own unique address in memory because code was just mmap()ed in without relocation). What we've got now is better, with just the problems of ensuring that versioning across effectively-independent software products works (and that's just plain hard for everyone).
Memory and disk have only recently become effectively too cheap for anyone (excluding embedded) to worry about the size of code; that's a new phenomenon.
Slashdot Mirror
Cheaper and easier to convince the PHB to buy a certificate signed by a public CA, than install your own CA certificate on every browser in your company.
Then your organization's IT department needs to learn about Group Policy and its counterparts on other common personal computing platforms.
Yeah, but getting all that to work when dealing with the reality of BYOD in many organisations (universities have a particular problem with this) is massively more complicated and expensive than ponying up for an externally-signed certificate. Heck, even getting an externally-signed local CA certificate is cheaper. Group policy (and equivalent) works relatively well for desktops and other wholly-owned devices, but ceases to be nearly so useful once you have to deal with anything external, and that's more and more common.
Get with the programme.
To put things in perspective - the old owners had plants in 5 different states. Each of the other plants consistently lost money. Our plant consistently MADE MONEY, despite mismanagement. Quarter after quarter, the accountants posted profits from our plant. In effect, we carried four other money losing plants for years. The owners could never bring themselves to unload the money losers, instead taking the profits we earned to shore up the other plants. They followed that policy until bankruptcy put them out of the game completely.
Were any of those plants making key inputs for yours? If they were, and it wasn't practical to consolidate that function, then closing them down would have crippled you. Which individual plants make money is one thing, but where there's internal transfer of items between units of the business, the value attached to those items is fairly nominal in practice; it's the overall business that really makes the profit or the loss.
Or maybe they're just incompetent fucks. That could be true too. Hard to say without the full facts, but the fact that bankruptcy hit is strongly indicative.
A masters in computer science program means taking about 10 three credit courses to get the degree. That means learning potentially 10 different languages. Which 10 would you choose? Which of those 10 are a must to learn, which would be merely advantageous to know?
Take at least one OO language (Java's fussy and bureaucratic, but its a pretty good example of the breed and is likely to be useful after you get your masters), at least one functional language (probably Haskell these days), at least one declarative language (Prolog or SQL), and don't just learn programming languages. You also need to learn about data, about data structures, about algorithms and their analysis, about parsing and compilation, and about concurrency; these are all independent of any programming language.
But computing is well served by not just learning about computing. If you have time, learn about math, stats and logic too, and learn how to communicate your ideas effectively; you'll never get far if you can't communicate with other people well.
The default 'package' access is rarely used.
Huh. I use it quite a bit when implementing an API. (You hardly need to use public at all inside interfaces.)
And by booboo I naturally mean something along the lines of
if(target->ThreatRating == ThreatRating::American) { target->Kill(); } // booboo
I'd guess something like:
if(target->ThreatRating = ThreatRating::Trrist) { target->Kill(); }
Let that be a lesson to you: Trrist must evaluate to 0, for humanity's sake!
If hardware isn't the problem, then it must be an algorithmic one. So, why can't an algorithm be discovered that is a breakthrough?
The problem is that it requires a true breakthrough, and there's no way to predict when that will happen. It also doesn't help that we don't really know what intelligence really is; all we've got is lots of things it isn't. I suspect that when someone cracks it, there'll be lots of people going "Is that all?! Anyone could have got that." and they'd be right, except that nobody did and it involves something both trivial and non-obvious. It might also require a lot of parallel processing, which we're still learning how to do well.
As we don't have any handy breakthroughs right now, we should instead study how brains really work and how to make computers do useful things (including stuff like "understanding" speech, "understanding" written natural language, drive cars safely, etc.) Those might or might not make the breakthrough easier, but they'll have other benefits along the way so they're still right to do.
If I want to strongly encrypt a cooking recipe that I email to my grandmother, then it is my business and my business alone.
And your grandmother's business too, assuming you want actually communicate that cooking recipe to her.
It's Norway, how would they even know a "localized ice age" kicked in?!?
When their glaciers start growing. Duh!
No, but I don't know of any Chinese companies producing steppers or any other of the multi-million dollar tools required to fab a processor.
That's what you might call a market incentive. Capitalism sees national security and arms export controls as damage and routes around it.
Most made entire classes of C blunders impossible
Don't worry about that! They had their own classes of blunders instead. (Every programming language has a characteristic set of problems that come up, and a set of recommended programming practices that avoid those blunders.)
Actually it's about non-standard-conforming "security" hacks causing unexpected results. If the result of an operation is undefined, the compiler can insert code to summon Cthulhu if it wants to.
If your compiler is doing that, you should choose a different compiler. Summoning elder gods just because signed arithmetic might wrap around is not a good cost/benefit tradeoff!
Are you suggesting a Martian penal colony? I don't see that ending well for anyone.
Better than a Lunar one I suppose.
It's lingual, "could be 1000 times faster" includes every portion thereof. Heck, "could be 1000x faster" includes 2000x faster too.
I always preferred the phrasing "up to 1000 times faster, or more!" Totally devoid of meaning.
Except browsers can actually send a header that lists your preferred languages, in order. Chrome can actually does this, although it's buried away under "Advanced Settings". Google just don't pay any attention to it on their servers (apparently).
If a lot of browsers are getting it wrong in what they send, the incentive to support it is not strong. Guess what? A quick test with Chrome, Safari and Firefox indicate that they all get it wrong by default. Safari doesn't provide an option to change it that I can find; the other two pick the wrong default for me, instead of using the system language settings (which are correct and available for software to read) even if those are imperfect for the task. (I'm on the wrong platform for testing IE and I don't have Opera.)
Why would you make your website use a feature that no browser gets close to right by default?
Turing also didn't say anything about crippling the test by making it a child who doesn't speak fluent English.
He also didn't specify that the software couldn't do that. The test isn't about knowledge, it's about intelligence. Computers are starting to get good at the more knowledge-y side of things, but intelligence has got to be more about establishment of shared context, dealing with weird semi-out-of-the-blue digressions, and so on. Language fluency is someone else's research project.
He is a "useful idiot" with a lot of information in his pocket. When they are finished with him, he is either going to be returned to the U.S or he is just going to "disappear" into the abyss.
Snowden's principal value to the Russians is for propaganda purposes, and this was the case all along. Making one's opponents look very bad is quite thoroughly valuable from a diplomacy perspective, since it persuades third parties (e.g., most of Latin America and Africa) to be more receptive to your message.
This setup allows for plug-in charging, as well as high density fuel usage.
At a cost of quite a lot of complexity and weight. That might be justifiable, but it sure isn't free.
ARM is SO not going to be competing in servers any time soon. Our "cheap" x86-64 servers are already at 24 cores and 64-96GB RAM. Once ARM gets anywhere near that those server specs will be 4x that, or more...
With large server deployments, performance per watt is a very relevant metric. This is because the limiting factor is actually keeping the server cluster from cooking itself, even with very good cooling in place. PPW is an area where ARM is generally quite a lot better than the x86 variants. After all, who cares if a system is slower when you can compensate by just cramming more cores in? (I don't know if ARM's floating point handling is good enough yet to compete in this area though; the big server guys really care about their number crunching.)
That said, ARM's really large advantage over at least x86 is that they're a design that they license out to others to manufacture. This does mean that they can't typically use all the very latest fabrication technologies, but it also means that for a third party manufacturer who has some of their own secret sauce for a specific market, they can get an ARM core for a reasonable amount and integrate it (rather than having to send it elsewhere for fab where they won't know who is watching). This is an advantage that it is hard to overstate; there will be lots of ARMs about for a long time to come.
The other thing to consider in mobile applications is what the noise ceiling of the CPU is; lower noise means less shielding and so less weight and cost. You've got to think in terms of optimising the whole system, not just the CPU core.
Taxis take your credit card after the ride is over. A serial killer has plenty of time to do bad stuff to you before your card is used. Uber knows who you are from the moment you hail the cab.
Not if the serial killer has stolen someone else's phone (and killed them too, natch).
Agreed, LHR makes no sense to me. I never know where I am or how to get where I'm going. The only place that comes close is Japan's NRT, but that's only a maze in the 4th floor shopping area.
LHR (except T5, and possibly the new T2 but that only opened this week) is like one of these intelligence testing devices for mice, but for people. You just have to follow the signs and hope. I find that FRA and ZRH are pretty bad that way too, at least for transit passengers, and BRU was managing to hide where the gates were at all earlier this year. (Past the bar and hidden behind some large advertising stands promoting an anonymous sports-car that were also covering up the signs saying where the gates were; yeah, hiding the absolute #1 thing that people want in an airport is idiotic.) And please don't route me via LIN. I'll be good, I promise.
In the US, the places to really avoid are JFK and LAX. Both are horrible places to change planes (especially between terminals). ATL, DTW, MSP, ORD, IAD and SFO are all much better. (MEM is OK, but a bit twisty, and I hate BOS for other reasons that aren't the airport's fault. I've yet to change planes elsewhere in the US.)
Don't know NRT well enough to comment.
You are being tracked.
In an airport, a place with substantive overt security, likely many cameras, and where the government sees passenger manifests before takeoff? Oh noes!
That would be the farm budget; this is robotics we're talking about here.
That's a lambda term (i.e., anonymous function) and not a closure. You tend to use them together, but they're formally different. A closure would be having a variable defined in the outer function being accessed and/or updated in the inner one.
But I'm sure they'll all be bullet-proof secure, don'tcha think?
What kind of glass are you using?
Oh, that kind of "bullet-proof". Not the Chicago Musicians' Union kind...
The shared libs approach is like the legacy of a chemical waste dump... it's there, it seemed like a good idea at the time, and there is not a whole lot anyone is doing to deal with the problems it causes simply by existing. Memory and disk space are no longer expensive, but catch-22 shared library hell is forever.
The original Linux shared library system was the toxic waste dump, being basically impossible to use if you weren't a distribution maker (every shared library had to have its own unique address in memory because code was just mmap()ed in without relocation). What we've got now is better, with just the problems of ensuring that versioning across effectively-independent software products works (and that's just plain hard for everyone).
Memory and disk have only recently become effectively too cheap for anyone (excluding embedded) to worry about the size of code; that's a new phenomenon.