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.
Back when I did web stuff a number of years ago, we used jQuery pretty extensively. I've even been involved a bit, submitted performance patches, etc. (none of the code I touched is still present though). Having used other javascript toolkits, jQuery was by far my favorite (I still have nightmares about Dojo). Made a lot of things very easy that were otherwise cumbersome, lengthy, or errorprone to do. Note that when I say jQuery here I mean the core of it, not the UI components and such that came later.
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.
jQuery is a very helpful tool if you use it right, and I think it would be beneficial for most javascript developers to have played around with it. It's not all that complicated, it's easy to learn, and if you're javascript is novice level, figuring out how/why jQuery works will also improve your javascript skills significantly.
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.
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.
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).
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.
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...
Immediately after reading the summary, I suspected this would just use "getLastKnownLocation" and correlate that with the foreground app. From searching through TFA, that is indeed the case. Technically, not very interesting at all.
I have a few years old Samsung TV and it plays near anything over DLNA (stream over TCP/IP from your PC), though you have to do some searching to find the right DLNA server and setup. Serviio works best for me. Buffering at movie start may be one or two seconds but certainly not more if you're on a wired (!) connection. Over Wi-Fi it's crap, of course.
Last year I connected Samsung Blu-Ray player which supported even more formats and worked even better (faster). Now, DLNA is about as shitty a protocol as possible (really, if you get down to the tech nitty gritty, "frackin' terrible" would be a compliment) so not everything always works and codec support has some limits, but some brands (including Samsung) support some non-standard stuff like additional codecs and even SRT subtitle support. Ultimately, I hacked my BR player with "SamyGO" which allows you to use network shares directly instead of DLNA which made it even better.
I've used laptops for this purpose and have even built HTPCs, but if you take a little care about what you download, by far most things will play on a DLNA setup on modern TVs and BR players (support differs per brand). My PC is usually turned on in my office room, I download my shows and movies (usually x264 720p or 1080p in mkv format with optional srt) and play them back in the living room without any additional gadgets at all.
Then again, maybe none of your TV room playback devices support DLNA or your computer isn't always-on, both will ruin this setup:)
I'm not sure if this is still true, but I do know that last week the Play store was still using HTTP downloads for the actual APK files instead of HTTPS (even though the API calls do use HTTPS). As such, even downloads from Play may be susceptible to man-in-the-middle attacks. I can't possibly explain it better than this group of comments:
I'm not saying it's likely - but it doesn't seem impossible either. Seeing as it will be a long time before the average Android user will be running a phone with this patch, I would call "crisis averted" too soon. Of course, we don't know if the complete HTTP download is still verified with checksum gotten from the HTTPS API, but somethow I doubt it.
Even if it was $300, it would still be more than 6 times as expensive... the dollars come in here to show it is an absolute budget device, and as somebody else stated, how much effort went into the device.
These budget sticks usually have very slow RAM and flash (storage), with constant I/O stalling going on. This is a major part in the constant jerking and freezing. Especially noticeable the first few minutes after boot, but you'll pretty much notice it all over the place.
There's often kernel issues as well, as these budget OEMs often don't put in the time, effort and money to fix issues and/or optimize it. That's not a generic Android problem, it's an end-product problem.
The point is, what you're seeing is representative for the MK808B, not for Android. These things differ greatly per-device and their components. As such, "sluggish, jerky, freezing, ungainly and wonky" may not (or may) apply to other devices. There are many Android devices out there with lower specs than the MK808B that have much smoother performance...
I'm not saying Android isn't slower, more jerky, more sluggish, etc than iOS would be on identical hardware, that might well be so - it just doesn't make sense to reach that conclusion based on your experience with the MK808B vs your iPhone4, as the specs aren't the same, and the numbers you are looking at do not represent fluidity - you've left out some major components to that equation.
At 1 AM, "please, nooooooo" is all you're going to get out of me. But I do make my living developing for my Android...:)
Re:I've been using Android on one for a while
on
Android On the Desktop
·
· Score: 4, Insightful
I think it's awesome that you're using a highly customized $47 Android device to base your opinion about Android on, comparing it's performance and use to $600 iOS devices. Guess what - they aren't equals. This says a lot less about Android than it says about your reasoning capabilities.
I dabble in Android security myself, I just want to point out that every single app I have encountered that Trend Micro flagged has been a false positive warning about an exploit that isn't actually present. The cause of this appears to be that those apps include files or snippets of code also used by some well known exploits, but by themselves are not harmful. Rookie mistake.
Note that if you search well, you will find various security folk slamming Trend Micro all over the place. As such, I wouldn't put too much faith in whatever Trend Micro has published, they don't exactly appear up to speed on matters.
After some further investigation, it seems all these exploits are fixed in the latest 4.2 leaked firmware for the SGS3, so... they're actually fixed, just maybe not rolled out yet.
The Exynos memory bug (often referred to as ExynosAbuse exploit) was released publicly and fixed rather quickly. This seems to be the way for Samsung - responsible disclosure just doesn't work with them. This has been proven time and again.
Slashdot Mirror
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.
Back when I did web stuff a number of years ago, we used jQuery pretty extensively. I've even been involved a bit, submitted performance patches, etc. (none of the code I touched is still present though). Having used other javascript toolkits, jQuery was by far my favorite (I still have nightmares about Dojo). Made a lot of things very easy that were otherwise cumbersome, lengthy, or errorprone to do. Note that when I say jQuery here I mean the core of it, not the UI components and such that came later.
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.
jQuery is a very helpful tool if you use it right, and I think it would be beneficial for most javascript developers to have played around with it. It's not all that complicated, it's easy to learn, and if you're javascript is novice level, figuring out how/why jQuery works will also improve your javascript skills significantly.
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 ?
Immediately after reading the summary, I suspected this would just use "getLastKnownLocation" and correlate that with the foreground app. From searching through TFA, that is indeed the case. Technically, not very interesting at all.
I have a few years old Samsung TV and it plays near anything over DLNA (stream over TCP/IP from your PC), though you have to do some searching to find the right DLNA server and setup. Serviio works best for me. Buffering at movie start may be one or two seconds but certainly not more if you're on a wired (!) connection. Over Wi-Fi it's crap, of course.
Last year I connected Samsung Blu-Ray player which supported even more formats and worked even better (faster). Now, DLNA is about as shitty a protocol as possible (really, if you get down to the tech nitty gritty, "frackin' terrible" would be a compliment) so not everything always works and codec support has some limits, but some brands (including Samsung) support some non-standard stuff like additional codecs and even SRT subtitle support. Ultimately, I hacked my BR player with "SamyGO" which allows you to use network shares directly instead of DLNA which made it even better.
I've used laptops for this purpose and have even built HTPCs, but if you take a little care about what you download, by far most things will play on a DLNA setup on modern TVs and BR players (support differs per brand). My PC is usually turned on in my office room, I download my shows and movies (usually x264 720p or 1080p in mkv format with optional srt) and play them back in the living room without any additional gadgets at all.
Then again, maybe none of your TV room playback devices support DLNA or your computer isn't always-on, both will ruin this setup :)
I'm not sure if this is still true, but I do know that last week the Play store was still using HTTP downloads for the actual APK files instead of HTTPS (even though the API calls do use HTTPS). As such, even downloads from Play may be susceptible to man-in-the-middle attacks. I can't possibly explain it better than this group of comments:
http://it.slashdot.org/comments.pl?sid=3950207&cid=44220885
I'm not saying it's likely - but it doesn't seem impossible either. Seeing as it will be a long time before the average Android user will be running a phone with this patch, I would call "crisis averted" too soon. Of course, we don't know if the complete HTTP download is still verified with checksum gotten from the HTTPS API, but somethow I doubt it.
Even if it was $300, it would still be more than 6 times as expensive... the dollars come in here to show it is an absolute budget device, and as somebody else stated, how much effort went into the device.
These budget sticks usually have very slow RAM and flash (storage), with constant I/O stalling going on. This is a major part in the constant jerking and freezing. Especially noticeable the first few minutes after boot, but you'll pretty much notice it all over the place.
There's often kernel issues as well, as these budget OEMs often don't put in the time, effort and money to fix issues and/or optimize it. That's not a generic Android problem, it's an end-product problem.
The point is, what you're seeing is representative for the MK808B, not for Android. These things differ greatly per-device and their components. As such, "sluggish, jerky, freezing, ungainly and wonky" may not (or may) apply to other devices. There are many Android devices out there with lower specs than the MK808B that have much smoother performance ...
I'm not saying Android isn't slower, more jerky, more sluggish, etc than iOS would be on identical hardware, that might well be so - it just doesn't make sense to reach that conclusion based on your experience with the MK808B vs your iPhone4, as the specs aren't the same, and the numbers you are looking at do not represent fluidity - you've left out some major components to that equation.
At 1 AM, "please, nooooooo" is all you're going to get out of me. But I do make my living developing for my Android ... :)
I think it's awesome that you're using a highly customized $47 Android device to base your opinion about Android on, comparing it's performance and use to $600 iOS devices. Guess what - they aren't equals. This says a lot less about Android than it says about your reasoning capabilities.
I dabble in Android security myself, I just want to point out that every single app I have encountered that Trend Micro flagged has been a false positive warning about an exploit that isn't actually present. The cause of this appears to be that those apps include files or snippets of code also used by some well known exploits, but by themselves are not harmful. Rookie mistake.
Note that if you search well, you will find various security folk slamming Trend Micro all over the place. As such, I wouldn't put too much faith in whatever Trend Micro has published, they don't exactly appear up to speed on matters.
After some further investigation, it seems all these exploits are fixed in the latest 4.2 leaked firmware for the SGS3, so ... they're actually fixed, just maybe not rolled out yet.
The Exynos memory bug (often referred to as ExynosAbuse exploit) was released publicly and fixed rather quickly. This seems to be the way for Samsung - responsible disclosure just doesn't work with them. This has been proven time and again.
See comment subject. Doesn't come with Windows 8. Guaranteed.