Catch up on stories from the past week (and beyond) at the Slashdot story archive
All nuclear reactors will generate waste via activation as the materials of which they are constructed erode and become unstable under high neutron flux. I'm not pointing this out because I think it's a big deal — a few fusion advocates disingenuously tend to sell the process as if it were "100% clean." A low volume of non-recyclable waste from fusion reactors that is walk-away safe in ~100 years is doable. Let's do it. And likewise, the best comparable waste profile for fission is a two-fluid LFTR, a low volume of waste that is walk-away safe in ~300 years. Let's do it.
Why pursue both, with at least the same level of urgency? Because both could carry us indefinitely. LFTR is less complicated in theory and practice. It is closer to market. There is plenty of cross-over: LFTR's materials challenges and heat engine interface — and the necessity for waste management — are the same as they will be for commercial-scale fusion reactors. To get up to speed please see the 2006 fusion lecture by Dr. Robert Bussard on the Wiffle ball 6 plasma containment, likely the precursor to the Skunkworks approach. And see Thorium Remix 2011 which presents the case for LFTR.
Those traveling regularly will enjoy better support for time zones in the panel's clock, while those staying at home a revamped clipboard manager, allowing you to easily get at your past clipboard's content. The Breeze widget style is now also available for Qt4-based applications, leading to greater consistency across applications. The work to support Wayland as display server for Plasma is still ongoing, with improved, but not complete support in 5.1. Changes throughout many default components improve accessibility for visually impaired users by adding support for screenreaders and improved keyboard navigation. Aside from the visual improvements and the work on features, the focus of this release lies also on stability and performance improvements, with over 180 bugs resolved since 5.0 in the shell alone."
Matthew Green tackled iOS encryption, concluding that the change really boils down to applying the existing iOS encryption methods to more data. He also reviews the iOS approach, which uses Apple's "Secure Enclave" chip as the basis for the encryption and guesses at how it is that Apple can say it's unable to decrypt the devices. He concludes, with some clarification from a commenter, that Apple really can't (unless you use a weak password which can be brute-forced, and even then it's hard).
Nikolay Elenkov looks into the preview release of Android "L." He finds that not only has Google turned encryption on by default, but appears to have incorporated hardware-based security as well, to make it impossible (or at least much more difficult) to perform brute force password searches off-device.