bennyboy64 (1437419) writes "Ever since the Heartbleed flaw in OpenSSL was made public there have been various questions about who knew what and when. The Sydney Morning Herald has done some analysis of public mailing lists and talked to those involved with disclosing the bug to get the bottom of it. The newspaper finds that Google discovered Heartbleed on or before March 21 and notified OpenSSL on April 1. Other key dates include Finnish security testing firm Codenomicon discovering the flaw independently of Google at 23:30 PDT, April 3. SuSE, Debian, FreeBSD and AltLinux all got a heads up from Red Hat about the flaw in the early hours of April 7 — a few hours before it was made public. Ubuntu, Gentoo and Chromium attempted to get a heads up by responding to an email with few details about it but didn't, as the guy at Red Hat sending the disclosure messages out in India went to bed. By the time he woke up, Codenomicon had reported the bug to OpenSSL."
Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!
Phil Shapiro often loans his Chromebook to patrons of the public library where he works. He says people he loans it to are happily suprised at how fast it is. He wrote an article earlier this month titled Teachers unite to influence computer manufacturing that was a call to action; he says that if 20,000 teachers demand a simple, low-cost Chromebook appliance -- something like a Chrome-powered Mac mini with a small SSD instead of a hard drive, and of course without the high Mac mini price -- some computer manufacturer will bite on the idea. Monitors? There are plenty of used ones available. Ditto speakers and keyboards, not that they cost much new. The bottom line is that Phil believes Chromebooks, both in their current form factor and in a simpler one, could be "the" computer for schools and students. Maybe so, not that Android tablets are expensive or hard to use. And wait! Isn't there already a Chromebox? And even a Chromebase all-in-one Chrome-based desktop? In any case, Chrome-based computers look pretty good for schools and libraries, especially if and when prices for the simplest members of the family get down to where Phil thinks they should be. (Alternate video link)
superboj writes "Forget Deepwater Horizon or Three Mile Island: The biggest industrial disaster in American history actually happened in 2008, when more than a billion gallons of coal sludge ran through the small town of Kingston, Tennessee. This story details how, five years later, nothing has been done to stop it happening again, thanks to energy industry lobbying, federal inaction, and secrecy imposed on Congress. 'It estimated that 140,000 pounds of arsenic had spilled into the Emory River, as well as huge quantities of mercury, aluminum and selenium. In fact, the single spill in Kingston released more chromium, lead, manganese, and nickel into the environment than the entire U.S. power industry spilled in 2007. ... Kingston, though, is by far the worst coal ash disaster that the industry has ever seen: 5.4 million cubic yards of coal ash, containing at least 10 known toxins, were spilled. In fact, the event ... was even bigger than the Deepwater Horizon oil spill in April 2010, which spewed approximately 1 million cubic yards of oil into the Gulf of Mexico."
sfcrazy writes "Google's Chromium team is working on an alternative of Gtk+ for the browser, called Aura. Elliot Glaysher, a Google developer explains, 'We aim to launch the Aura graphics stack on Linux in M35. Aura is a cross-platform graphics system, and the Aura frontend will replace the current GTK+ frontend.' The Free Software community is debating: is Google trying to do Canonical? Couldn't Google just switch to Qt, which is becoming an industry standard?"
An anonymous reader writes "Months after Intel ported the Chromium open-source web browser to Wayland, Chromium is now running on Ubuntu's Mir. The Mir display server port ended up being based on Wayland's Chromium code for interfacing with Google's Ozone abstraction framework. The Ubuntu developer responsible for this work makes claims that they will be trying to better collaborate with Wayland developers over this code." Grab the code hot off the press.
An anonymous reader writes "Citing 'code we consider to be permanently "experimental" or "beta,"' Google Chrome engineers have no plans on enabling video acceleration in the Chrome/Chromium web browser. Code has been written but is permanently disabled by default because 'supporting GPU features on Linux is a nightmare' due to the reported sub-par quality of Linux GPU drivers and many different Linux distributions. Even coming up with a Linux GPU video acceleration white-list has been shot down over fear of the Linux video acceleration code causing stability issues and problems for Chrome developers. What have been your recent experiences with Linux GPU drivers?"
An anonymous reader writes: "It doesn't take a Columbo to figure out that the 'previous employer, a small browser vendor that decided to abandon its own rendering engine and browser stack' is referring to Opera in this comment answering the question 'Do you actually use the product you are working on?' It appears to originate from Andreas Tolfsen, a former Opera developer who is now part of the Mozilla project. From releasing a unified architecture browser including Linux support since 2001, Opera decided to put Linux development on indefinite hold, communicated through blog comments, and focus on Windows and Mac for their browser rewrite centered around the Blink engine that had its first beta release last spring. The promise to bring back the Linux version in due time was met with growing skepticism as the months went by, and clear answers have been avoided in the developer blog. The uncertainty has spawned user projects such as Otter browser in an attempt to recreate the Opera UI in a free application. Tolfsen's statement seem to be in line with what users have suspected all along: Opera for Linux is not something for the near future."
mikejuk writes "Google and Opera split from WebKit to create Blink, their own HTML rendering engine, and everyone was worried about the effect on standards. Now we have the first big example of a split in the form of CSS Regions support. Essentially Regions are used to provide the web equivalent of text flow, a concept very familiar to anyone who has used a desktop publishing program. The basic idea is that you define containers for a text stream which is then flowed from one container to another to provide a complex multicolumn layout. The W3C standard for Regions has mostly been created by Adobe — a long time DTP company. Now the Blink team has proposed removing Regions support to save 10,000 lines of code in 350,000 in the name of efficiency. If Google does remove the Regions code, which looks highly likely, this would leave Safari and IE 10/11 as the only two major browsers to support Regions. Both Apple and Microsoft have an interest in ensuring that their hardware can be used to create high quality magazine style layouts — Google and Opera aren't so concerned. I thought standards were there to implement not argue with." Although mikejuk thinks this is a bad thing, a lot of people think CSS Regions are awful. Mozilla has never intended to implement them, instead offering the CSS Fragmentation proposal as an alternative. One major flaw of CSS Regions is its reliance upon markup that is used solely for layout, violating the separation of content and style that CSS is intended to enforce.
mikejuk writes "Google's Dart just reached version 1.0, but now it seems that it has aspirations to being an international standard. The question is will this make any difference to the language's future? Given that Google effectively owns Dart, what advantage does standardization bring? The answer to what Google thinks it brings is indicated in the Chromium blog: 'The new standardization process is an important step towards a future where Dart runs natively in web browsers.' and this seems reasonable. A standard is something that would be required before other browser makers decided to fall in line and support native Dart. It is probably a necessary but far from sufficient condition, however, with Microsoft, Apple and Mozilla having other interests to further. Last but not least, having the backing of a standard might just encourage possible users to believe that the language won't sink if Google gets distracted with other projects and decides that Dart is dispensable. However, a strong open source development community capable of supporting Dart without Google's input would be a better reassurance. If you want to help, Google would like you to join the committee. After all, it still doesn't have a Vice Chair. So can we expect to see ECMA CoffeeScript or TypeScript in the near future? Probably not."
An anonymous reader writes "Google really wants Chrome apps to take off. Not only has the company added rich notifications, in-app payments, and an app launcher into its browser, but now it's developing ephemeral apps that launch by just clicking a link. There are two separate components here. Ephemeral apps (you can enable this under the chrome://flags/#enable-ephemeral-apps flag) let you try a Chrome app before installing it. Linkable ephemeral apps (under the chrome://flags/#enable-linkable-ephemeral-apps flag) meanwhile allow you to launch said apps from hyperlinks."
An anonymous reader writes "Google today released Chrome version 31 for Windows, Mac, and Linux. The new version includes support for Web payments, Portable Native Client, and 25 security fixes. 'Under the hood, PNaCl works by compiling native C and C++ code to an intermediate representation, rather than architecture-specific representations as in Native Client. The LLVM-style bytecode is wrapped into a portable executable, which can be hosted on a web server like any other website asset. When the site is accessed, Chrome fetches and translates the portable executable into an architecture-specific machine code optimized directly for the underlying device. This translation approach means developers don’t need to recompile their applications multiple times to run across x86, ARM or MIPS devices.' You can update to the latest release now using the browser's built-in silent updater, or download it directly from google.com/chrome."
agizis writes "Google presented their new QUIC (Quick UDP Internet Connections) protocol to the IETF yesterday as a future replacement for TCP. It was discussed here when it was originally announced, but now there's real working code. How fast is it really? We wanted to know, so we dug in and benchmarked QUIC at different bandwidths, latencies and reliability levels (test code included, of course), and ran our results by the QUIC team."
sfcrazy writes "Chromium developers have started porting Chromium to X11 alternatives such as Wayland. Tiago Vignatti sent a message to the freedesktop mailing list, 'Today we are launching publicly Ozone-Wayland, which is the implementation of Chromium's Ozone for supporting Wayland graphics system. Different projects based on Chromium/Blink like the Chrome browser, ChromeOS, among others can be enabled now using Wayland.'"
An anonymous reader writes "Google today announced it is dropping Netscape Plugin Application Programming Interface support in Chrome. The company will be phasing out support over the coming year, starting with blocking webpage-instantiated plugins in January 2014. Google has looked at anonymous Chrome usage data and estimates that just six NPAPI plug-ins were used by more than 5 percent of users in the last month. To 'avoid disruption' (read: attempt to minimize the confusion) for users, Google will temporarily whitelist the most popular NPAPI plugins: Silverlight, Unity, Google Earth, Google Talk, and Facebook Video." Google offers NaCl as an alternative, and "Moving forward, our goal is to evolve the standards-based web platform to cover the use cases once served by NPAPI."