To be fair, back in the day browsers were a lot more quirky and getting even simple scripts to work in the big five was a major hassle. These frameworks took a lot of that away. These days, that issue is much less prevalent.
I've actually read the linked articles (*gasp*), and it seems the one referenced to imply that developers distrust it in large projects (really, summary?) is simply elaborating on how they have been using jQuery in a way that doesn't work very well, and found a different way of using it where it does work well. Surprise, jQuery is a tool, and crafting solutions requires you to use the right tool, in the right way, at the right time. Screwdrivers are great for screws, but nails pair better with the hammer.
I haven't heard of any other controversy regarding jQuery either but I haven't really been paying attention to it lately. Anyone care to elaborate?
As probably many others, I've been looking into this exact problem for a while, comparing a lot of available options. Ultimately, I want something to run on Android, iOS, Windows (+ Phone), Linux, and OS X. The very complex core logic should be a write-once affair, while not having a single shared UI is not such a major issue, nor is writing some platform-specific utility classes. I have also come to the conclusion that C++11 for that core is the most viable option.
Some interesting tidbits not mentioned in the summary is that they used DropBox's djinni to generate C++, ObjC and Java bindings; and they used the Flux unidirectional data flow architecture. Both of these things are worth reading about, more so than any thing that is actually mentioned in the summary.
I'm usually thoroughly annoyed by people asking this question, but I really don't get why this is news. So many good tech articles go around in the Firehose that never make it, then cruft like this floats up. If only my uid was shorter I could yell for you all to get off my lawn.
"Its own OS" ? It's just a bloody stock Android build with Google Apps and a handful of 5 minutes tweaks courtesy of the Paranoid Android developer they hired. It's literally 2-3 guys who 'built' this in a couple of weeks.
There really is nothing special about this whatsoever, many OEMs have this. OnePlus (A handful of Oppo rejects) marketing strikes again, and you all fell for it (again). Heck, OnePlus is more of a virtual OEM than a real one, relying on Oppo for their funding and production.
The only tiny part news about this is that they did this to have an alternative to CM, which isn't really news, as it's been known for quite a while that they'd be doing this.
Actually this tablet is expected to be officially announced -and available- within weeks.
Interesting, that. I've heard a lot of people make similar claims, but the three units I have myself (development purposes) work fine. However, some guys I work with recently started using the N7 2013 as base for a university automation project, and have gotten hundreds of them. Apparently, dozens of their units were dead on arrival, and of those that work out-of-the-box a significant number of them randomly just die. Less than a year after the start of the project, near to a third of the units is dead.
I had also expected the N7 to stay available alongside the N9, but according to these same guys it is very difficult to still get units in significant amounts. Shops are starting to delist them, which to me indicates that they are end-of-life and the soon to be released N9 will replace the N7, rather than augment it. I sincerely hope I am wrong here.
... for quite some time now. WSJ posting it doesn't suddenly make it news.
PNO is implemented in the Wi-Fi firmware, and generally only active if the main device CPU is asleep.
wpa_supplicant tells the Wi-Fi firmware which networks it is interested in, then when the main CPU sleeps, the Wi-Fi chip keeps scanning for those networks periodically, which takes less power than waking the main CPU periodically to do this. In PNO's scanning process, it broadcasts all the names. There's no technical reason this is needed aside from hidden SSIDs (and indeed non-PNO wpa_supplicant scans don't do this either). The PNO feature however doesn't make that distinction and broadcasts all the names instead of the hidden ones. From the sources I've read, it seems there's no way to tell the firmware to make a distinction between active (for hidden) and passive (for non-hidden) SSIDs.
So yes, in effect, anything based on wpa_supplicant and PNO may do this. However, this is not wpa_supplicant's fault per se, rather PNO's. I don't think my laptop bothers scanning for Wi-Fi networks when it's sleeping at all, or even supports PNO, but your mileage may vary on that. There's no rule saying PNO can only be used when the main CPU is asleep either, though that is what's built for. Your software could be using it all the time (unlikely, but possible).
Irrelevant - the issue on Android is not limited to hidden networks.
Unfortunately, that just isn't true. The affected Android devices leak all known networks, not just the manually configured ones. Go ahead and test it.
Good job intentionally not seeing the point just to be able to make a trollish/sarcastic remark. You must do great at parties.
Of course. I'm not even advocating the need for change - I'm just trying to point out that cameras like these not being very secure appears to be the rule, not the exception, though not everyone appears to be aware of this. I could see an article like this leading to talk that you shouldn't buy Samsung because it isn't secure, advising other brands instead - but those aren't necessarily any better.
While this camera should of course be more secure - what exactly are we comparing it to ?
Do you think your Canons and Nikons are safe? Lots of models allow remote control using either USB or Wi-Fi. USB requires a cable from your smartphone running the malicious software, while Wi-Fi obviously does not. For Wi-Fi you need to get past the encryption, but the joke is, lots of people actually run their camera's Wi-Fi without encryption (surprisingly, some photo blogs advise it for ease of use). You're still not home free though as there's a pairing process when Wi-Fi is used, but if the camera owner's smartphone is active on Wi-Fi (not necessarily even the same network - just turned on), this is not hard to beat either.
If you can get connected to these cameras either via USB (completely unprotected) or Wi-Fi, it is not just possible to manipulate, retrieve, replace, wipe, etc all images present, you can fully control the camera's settings and even send malformed commands to completely disable the camera, only to be (potentially - it depends on the model) revived by a Canon/Nikon repair center. This while most users think the worst that can happen is someone copying their pictures
You think the NX300 is bad? Consider that pretty much nobody owns an NX300, while virtually all photojournalists active in countries with questionable rights to free speech have one of these affected Canons and Nikons
As usual with a Slashdot article title ending with a question mark, the answer is no?
These are not the same class of vehicle. Around these parts there are quite a number of Tesla Model S's - in fact I would have gotten one myself if it had been possible to get it delivered before January 1 (long story, tax breaks) - and all the owners I know of are small to medium business owners with money to spare. Had they not gone for the Model S, they would have gotten one of the bigger models Audi, BMW, or Mercedes - electric or not. I can't see a single one of these folks getting a Leaf instead, not even at half the price.
Then again, maybe the target demographic for the Model S is different on your side of the pond
Did you actually test this ?