Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
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) 60

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) 178

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:Windows 10, Windows 10, Windows 10! (Score 1) 483

That doesn't seem like a particularly believable reason. ARM SoCs that might end up in tablets and phones all have at least moderately competent GPUs and the requirements of Aero Glass are pretty trivial even by modern mobile GPU standards (compositing, a token amount of pixel shader). More importantly, offloading rendering to the GPU is more power efficient (which is why Apple pushed as much as possible there starting when laptop sales began to outnumber desktops and continued when iDevices started to become popular).

Comment Re:Yeah so (Score 1) 175

If you expected Sanders to be non-compromising, you clearly haven't done your research on him. The man has a solid track record of a pragmatic idealist - he has clear ideals that he strives to fulfill, but at the same time, he is perfectly able and willing to work with people whom he disagrees with, so long as it gets him one step closer to his goals. Look at what he did in Congress - constant scheming to add riders to bills. Go even further back, and look at what he did as a mayor.

And it's exactly what made Sanders such an awesome presidential candidate. Most "revolutionaries" dismiss incremental change outright. This guy realized that it's the only chance that he and his platform has, and mastered it. I actually put more faith in his ability to navigate through the gridlock in Congress as a president, than Hillary's. Alas...

Comment Re:dark patterns huh? (Score 1) 126

Is it any wonder that UX designers are getting a horrible reputation among some segments of the tech-savvy crowd?

The main reason for this is that people who self-describe as UX experts, as opposed to HCI experts, tend to be the ones that favour form over function and ignore the last 40 or so years of research into how to design useable interfaces. Most of them wouldn't know Fitts' Law if it dragged them to the corner of the screen and made them infinitely long.

Comment Re:How do you regression test that stuff? (Score 1) 308

There isn't much testing of the C bindings. They're also in the process of being deprecated in favour of machine-generated ones that are less API stable and have no ABI stability guarantees (precisely because most people don't actually use them from C, they use them from some other language with C bindings). For everything else, there's a bit regression test suite that works by feeding some code (source code when testing clang, IR or assembly when testing bits of LLVM) into one of the tools and then checking that the output matches. Bugs still slip in quite easily, unfortunately. The second tier of tests involves compiling and running a bunch of benchmarks and similar sample code and checking that they haven't got slower (by a statistically significant margin) and that they still produce the right answers. There's a network of buildbots that runs on a variety of operating systems and architectures that first builds and runs the regression test suite on every commit and then (less frequently) runs the executable tests. These catch most regressions, but not all - the rest are caught by users testing betas and filing bug reports.

There's been a lot of research work on improving this. The LLVM Miscompilation Detector, for example, had a semantic model of LLVM IR and would feed real and randomly-generated IR through the optimisation pipeline and then use a theorem prover to attempt to prove that the semantics of the before and after versions were the same. This could then be combined with the LLVM bugpoint tool to find the optimisation pass that performed an invalid transform.

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

It's a tradeoff. Blowing away the i-cache is a good way of killing performance, but so is having a load of function calls that do almost no work. If you had to do a virtual method call for comparing two unsigned integers and a different virtual function call for comparing two signed integers when inserting them into a set then you'd have a lot more overhead. In a typical std::set implementation, the compare operations are inlined and so the costs are very low.

The real problem with C++ is that the programmer has to make the decision about whether to use static or dynamic dispatch up front and the syntax for both is very different, so you can't trivially switch between them when it makes sense to do so.

Comment Re: Nothing of value was lost (Score 1) 39

What is this chat you're speaking of?
I don't see too many people on IRC. Perhaps you mean something as backward as Skype? No thanks.

Anyway, sorry but mail and mailing lists still are very relevant. I'll miss GMane dearly myself and wouldn't mind donating a few grands to keep it alive.
It's still the best format for discussion with people in open-source and other projects.

Comment Re:Trump Trolling (Score 1) 1006

I don't think that it is actually a tactic, in a sense that he's not consciously trolling. If that were the case, he would not be doing it when the story-of-the-day is in his favor - but that's not what's happening. Remember that judge thing? Everyone was talking about Clinton's emails then, and it was a good thing for Trump - and if he were the master troll that some claim him to be, he'd be throwing gasoline onto that fire. But instead, he made a bunch of stupid remarks that shifted attention elsewhere.

No, I really think he's just a child emotionally, in a near-constant tantrum mode whenever there's any visibility afforded to him at all.

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?

Slashdot Top Deals

Waste not, get your budget cut next year.