So it's easy for you to be smug and treat your vote like the bauble you think it is, because to you it is insignificant. You're set no matter what.
So you don't think the Republican candidate for the Presidency of the US inviting a foreign power, one that is at the best of times in a rather tense relationship with the United States, to hack into US systems just to gain dirt on the other party's nominee is reasonable?
It's obvious to a native speaker of English (who isn't astroturfing the Democrats' talking points) that Trump was NOT inviting the Russians to initiate a new crack on his opponent's servers.
He was ribbing his opponents, and keeping their lax security (and their "The Russians are aiding him!" attempt at distraction) in the public eye, by pointing out that the Russians probably ALREADY have the emails that Clinton's people "can't find", and inviting them to dig them out of their own archives and provide them to investigators and/or the press.
People claiming he is inviting new espionage don't just look foolish. They also play into his hands, by keeping the issue in the face of prospective voters.
But feel free to continue. B-)
The people producing Python or C++ libraries abandon those libraries when they move to a new language - they don't have a choice.
That's certainly true of Python. Hell, you practically need to abandon your Python libraries when you move to the next version of Python.
But it's not true of C++. Binding well-written C++ libraries to other languages sometimes takes a little work (you do need to write a glue layer if there's a serious impedance mismatch, but then you need to do that with C too), but it does work and largely works quite well. Python, Java, Rust, Go, Haskell, O'Caml... you name it, you can The only languages which don't work well with C++ libraries are old languages like Tcl.
Look at LLVM as an instructive example. It's a large complex beast written in heavy C++, but there are bindings for every language you'd ever want to seriously write a compiler in.
I spent about fifteen years of my career in the non-profit sector, so I have some perspective on this.
Raising money in a non-profit is just like selling stuff is for a for-profit. Generating gross revenue is relatively easy -- if you spend a lot of money you can rake in a lot of dough. What's a bitch to generate is net profit. In the non-profit sector we don't use the term "profitability" very much, so the metric that's often used to describe financial is "cost to raise a dollar." For typical fundraising activities cost-to-raise-a-dollar runs from 0.25 to 1.5 dollars/dollar.
Take junk mail. The cost to raise a dollar for a well-run direct mail campaign is in the range of $1.25 to $1.50, so if I want to raise $115,000 to spend on other things I have to scale my direct mail campaign to bring inover $258,000 gross. As you can see I chose a net target that was exactly 1/1000 the size of the ALS bucket challenge net, so you can compare the efficiency of the processes readily. The cost to raise a dollar for the ALS bucket challenge is actually better than a well-run direct mail campaign -- $0.91.
And it should be more efficient than direct mail, because direct mail is about the least efficient method there is. The marginal costs are huge because you pay for the names and addresses as well as printing and mailing of each piece, and most of those pieces will end up in the landfill unopened. So if direct mail is so inefficient, why use it? Because the financial inefficiency doesn't matter to the organization doing the fundraising. The end result of my hypothetical direct mail campaign is that my organization has $115,000 it didn't have before. That probably pays for one and half full time staff positions (at the low do-gooder wages we pay) for a year.
So the ALS challenge was in the financial efficiency range of methods normally used by non-profits, albeit a little towards the inefficient end. That doesn't really tell us if the campaign was responsibly run or not; to know that you'd have to look at all the expenses and compare those to costs in other viral Internet fundraising campaigns. But the bottom line is that the ALS association ended up with $115 million it didn't have before.
Can you think of a way of raising $115 million in a few months? I thought not. So presuming the guys who ran the campaign didn't spend the money on hookers and blow, I wouldn't be unduly concerned by a cost-to-raise-a-dollar of $0.91 if I was on the board.
Should donors care that the ALS challenge was a little high on the cost-to-raise-a-dollar metric? Well, I look at it this way. People did it because it was fun and for a good cause, and two years later we can point to concrete and significant scientific results from the money raised. That's not only pretty good, it's pretty damned awesome.
I see you do not understand what a mobile app is. There is no real logic in the app, it's just UI for a web service.
That's true in many cases, but it's far from the whole story. Well-written mobile apps try to minimise network communication because that can drain battery life much faster than a modest amount of computation.
Even badly-written mobile apps, like the Facebook client, do DSP on the device for things like its spyware voice recognition feature.
Have they rewritten the Java runtime in Java yet?
Last time I looked, it was written in C.
Not all of it. The original Sun class loader has been written in Java since 1.0.
(ok, C++ does too but C is where you get all the amazing well written, optimized libraries you'd want on most devices).
You have clearly never had to support on very many third-party C libraries. The standard open source ones that have been around for decades (e.g. zlib, Berkeley DB) are indeed well-written and high-quality, but they are not the common case.
I recall from my C class that the language only has 34 keywords and that one of its advantages is that it doesn't come with unnecessary baggage.
What that typically means in practice is that for anything beyond a certain scale, you need to write the unnecessary baggage yourself. And believe me, you will.
As an embedded engineer, I appreciate this and also have never had to use a string package, or library, in my professional career.
Some embedded devices do have complex UIs which might find it useful. I've never written the firmware for a modern digital TV or DVR might need to do some of that. But yes, most firmware (and I have worked on some) doesn't need to manipulate strings.
In other news, ten times as many people die each year from brain-eating amoeba as have died from Tesla's "autopilot" feature. Is it too soon to talk about common-sense amoeba control laws in this country?
I've never used any c++ specific constructs in any of my arduino programs.
So you've chosen not to use C++ features, but your code is compiled as C++, and all of the framework code that calls your code is C++ -- and it definitely uses C++ features. C++ is the Arduino language, not C.
If you stick to a C-only subset of C++ you can write your library in C++, but at that point why bother with C++ anyway?
Or you could write your library in C++ but put it behind a C interface. Then you can use all of the expressive power of C++ internally, and provide an API that can be called from any language. And it will still be very close to as portable as if it were written in plain C, because we now have decent C++ compilers on very nearly every platform.
So you're going to evade the anti-money-laundering laws by having a third party in some other country launder money for you.
Do you know how *else* I know you didn't read the relevant parts of these EU Directives?
I wish that there were more phones running plain Android with fast updates.
This article is exactly what we need to make that happen, though ideally we need it to be on CNN, not just Ars. But Ars is a good step. When consumers demand good update policies, manufacturers will provide them. It's a competitive market.
Actually, I think we're further down that road than it may appear. Stagefright was a big kick in the butt for the Android ecosystem. Not because it actually affected any real users, but because it got a *lot* of press. I think many OEMs have realized they need to fix their update problems, because consumers are beginning to care. The problem is that the OEMs product plans for the last few years have not included plans for monthly updates. Planning for that sort of update cycle requires them to change a lot of things in the way they do business. One is closely related to what you mentioned about carrier-specific builds: The OEMs just have too danged many products. It's not uncommon that what appears to the end user as a single model (e.g. Samsung Note 4) is actually one or two *dozen* different devices... each with its own software build. Not because they actually need that many SKUs and not because all of them actually need different software, it's just been easier to do it that way. Now that the pressure to provide updates is being turned up, I think they're looking at how to streamline their product lines and processes to make it more feasible to deliver them. Oh, and they also have to build the cost of the update-related work into their business plans.
However, building phones is a complex process, and device design and planning cycles often run more than two years, so it takes time for changes in approach to reach the market. I think it'll start getting a lot better in the next 1-2 years.
That's why I'm just sticking with Nexus phones.
Me too. Of course, in my case it helps that I get them for free
Of course you didn't talk at all about "handling the current situation" you talked about "self driving" which isn't actually related at all.
I actually don't agree with that, though that's Tesla's position. I don't think semi-autonomous driving is realistic. Once the car can drive itself sufficiently well that people feel safe looking away to text or whatever, they will. Any system that expects that a human will continue paying attention and be ready to take over at a moment's notice is asking for trouble.
Retirement means that when someone says "Have a nice day", you actually have a shot at it.