Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
Get HideMyAss! VPN, PC Mag's Top 10 VPNs of 2016 for 55% off for a Limited Time ×

Comment Re:What does it do most of the time? (Score 2) 55

This isn't even the first word in farm automation.

It's the first word (or close to it) in small-scale home garden automation. Traditional farm automation is all about scale, enabling fewer people to farm larger areas effectively. This isn't that. This is about enabling lazy/busy people to grow a highly-effective garden in limited space and with limited attention -- and probably limited understanding of how to do it. You don't have to learn how to care for different types of food plants, you can instead rely on software configuration provided by others who do know, and you don't have to go out and work in the garden every day.

'take back the food' whatever that vapid statement means

Yeah, that part is pretty silly.

However, I like homegrown veggies but I'm too lazy to garden. I don't mind planting or harvesting, but the daily regimen of watering and weeding is too tedious for me -- but I do like automation, tinkering and I have disposable income. I could see myself buying one of these.

Comment Re:Better idea (Score 1) 172

For something as important as voting, how about paper only?

We actually have solutions that are much better than that. This wasn't true a few years ago when the whole voting machine fiasco started, but that discussion provoked a fair amount of research into secure voting systems, and security and cryptography experts have proposed a number of systems that provide verifiable end-to-end integrity. Each voter can verify that his or her vote was actually included correctly in the final count -- but without being able to prove to anyone else how he or she voted (important to mitigate vote buying/coercion). Each candidate/party can fully audit the ballots before the vote and the count after the vote, and audit results are provably correct.

The most thoroughly developed system is Chaum and Rivest's (this is the Rivest who is the "R" in "RSA") "Scantegrity" system. It actually does use paper ballots, slightly modified traditional "Scantron" forms. Rather than just filling in the bubble with a #2 pencil (though you can do that, and that will work, and it will only sacrifice one form of verifiability), instead bubbles are filled with a special marker that reveals a code. That code can be recorded by the voter and used by the voter after the election to verify that the voter's vote was counted correctly. Ballots are counted by normal Scantron scanners, and can easily be verified by hand.

But, thanks to the additional auditing steps (which rely on serial numbers on ballots and some carefully-defined processes) it's not possible to inject additional ballots into the process (no ballot box stuffing), nor to "lose" ballots, without detection. The system does make allowances for absentee and mail-in ballots, and has been used in a real election to verify that it's fully practical.

For more details about Scantegrity, see http://scantegrity.org./

And another thing, we should really do vote-by-mail nationwide just like Washington state does it.

There are signficant risks in that. OTOH, it doesn't seem like Washington is actually seeing them. Still, I'd move very carefully on that one.

Comment Re:A pattern emerges (Score 1) 163

I've been meaning to reply for some time; feel free to e-mail me as I know this discussion will be archived soon.

You're right that Google has relatively little control over Samsung. What they do have is control over the Android trademark, etc., and if Google can require that the Play Store be within one swipe's distance of the home screen when shipped, Google can make other requirements that reflect dedication to ensuring that devices are able to be flashed with AOSP software.

Those requirements are subject to negotiation. Google has some power to push, not based on the Android trademark so much as on the permission to install the Google Apps -- and especially the Play store. The Play store is the big carrot/stick, actually, because an Android phone without the Play store is much, much less useful... at present. It wouldn't be that difficult for Samsung to set up their own app store, and app developers would absolutely upload their apps to it because Samsung is such a huge part of the Android ecosystem. If Samsung were to form an alliance with the top two or three other Android OEMs, their app store would very quickly replace Play as the dominant app store, particularly if they also set out to license all the videos and music they need to reach full parity with the content on Play. Or perhaps they'd take a shorter path: Team up with Amazon which has already done most of this work. If new Samsung, HTC, Motorola and LG phones all shipped with the Amazon store, Amazon would almost immediately match Play.

So Google has to walk a fine line. It has to keep all of the OEMs moving in the same direction, make sure that direction keeps the ecosystem competitive with Apple and Windows (not that Windows has much of the market at the moment) which means making sure the user experience is good and continues to improve, but it also has to allow OEMs enough freedom to innovate and manage their business models so they don't feel like being part of Google's ecosystem is more of a burden than a benefit.

I don't really understand why OEMs seem to feel so strongly that their devices should be locked down, but they do, and they're unwilling to negotiate on this point.

Unless I misunderstand how the Nexus system works, Google *does* have say over how those function, and those have a locked bootloader

So, I think your fundamental error here is that you're thinking locked bootloaders are a bad thing. They're not. They're a good thing.

Locked bootloaders (the way Nexus does them, at least) are there for user security. The purpose of the lock isn't to prevent users from flashing software that does what they want, it's to prevent attackers from flashing software that does what they want -- to give them access to data on the device, bypassing all of the protections built into the stock OS. So, the reason there is an "unlock" step is so that we have an opportunity to forcibly wipe all user data from the device. Someone who finds or steals your locked phone can unlock it (maybe; we made that a little harder in Lollipop), but the unlock process wipes all of your data.

This, BTW, is why I always tell modders that they should re-lock their bootloader after they flash their custom image. Not re-locking it allows anyone who gets hold of their device to flash a new system image that gives them full access to anything on the device (though we're tightening that down in Nougat as well).

That's the main purpose for a locked bootloader, but there are some other benefits as well. They protect devices against inadvertent as well as malicious modification, and they provide a good way to differentiate between a normal device that should implement the full boot chain of trust and those that are in a modifiable state. The vast majority of users never want or need to unlock, and we want to make things very secure for them. Developers (including Android engineers at Google!) and modders do want/need to bypass many of those security protections, so it makes a lot of sense to have a boolean switch that changes between "production device" and "development device" modes.

As for the fuse that the article claims records whether the device has ever been unlocked... that I don't know anything about. I'm sure it's not something that the Nexus team ever asked Qualcomm for. Our requirements to the OEMs who build Nexus devices are that the devices have unlockable bootloaders, and we specify how those should behave. We don't care if a device has been unlocked in the past or not, just about its current state. However, Qualcomm doesn't develop firmware specifically for Nexus devices, and other OEMs do care about whether or not a device has been unlocked. So my guess is that that Qfuse is a Qualcomm feature that has implications on other devices (most likely, unlocking just voids warranties, since flashing bad firmware can damage hardware -- come to think of it, it's possible that if you return a Nexus device for warranty repair/replacement, and the damage is something that could have been cause by bad firmware, and that fuse is blown... maybe you won't get warranty support for your Nexus either).

If Google decides to mandate locked bootloaders or bring an end to the work done by the folks at XDA-Dev, there's just no reason whatsoever for them not to...and that does, in fact scare me.

I do understand your fear. All I can tell you is that the Android engineering team feels quite strongly that users should own their own devices, which means they should be able to install their own software. Probably the best way to see how the Google team feels about it is to look at the Pixel C, which is the first device from Google that uses a Google-provided bootloader. The Pixel C's entire boot sequence is all open source code, and there's a physical switch in the device (modeled very much on the Chromebook "dev mode screw") which allows you to take complete control... after flipping that switch you can flash any part of the system up to and including providing your own implementation of the TrustZone OS. Note, though that your custom trusted OS will not have access to the DRM keys needed to decrypt HD and 4K video from Netflix, etc.

For that matter, if you want to see how Google's engineers look at these things, take a look at how Chromebooks work. Unlike Android, the Chromebook architecture is completely under Google's control. Chromebooks are built by various vendors, but Google's relationship with them is very different, and Google can dictate exactly how they work, within the constraints of the available components.

Comment Re:Cant say i'm surprised (Score 1) 308

I don't understand why people think AVRs need to be programmed in Arduino-C++ dumbed-down. avr-gcc (WinAVR on windows) is extremely nice to use and doesn't hold your hand. True C (or C++, if you like) programming.

I don't think anyone thinks they have to be programmed in Arduino C++, but the tools work well, so why look any further? What do you actually gain with avr-gcc?

Comment Re:74 at time of crash (Score 1) 603

It's easy to drift off your speed - that's why I use cruise control even in moderate (but obviously not stop and go or slow and go traffic. At the same time, even when it's very light traffic, if I've been catching up to someone slowly for miles, then try to pass, at least 3/4 of the time they speed up.

Comment Re:As a C programmer (Score 2) 308

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.

Slashdot Top Deals

Asynchronous inputs are at the root of our race problems. -- D. Winker and F. Prosser

Working...