[quote]It's just irresponsible for the package maintainers to come back and say "we can't pull it, we're leaving it as is, and we're not patching it either".[/quote]
The package maintainers didn't say that. This package is in the universe repository. The entire purpose of this repository is that volunteers can upload packages that Canonical has decided they aren't going to support. So Canonical isn't the package maintainer and you can't really blame them for not supporting packages that they said they aren't going to support.

Furthermore, it sounds like the ownCloud developers want Ubuntu to either use the latest & greatest release, or remove the package entirely. If that is correct, then I think it is irresponsible on the developer's part. Version 7 only came out 3 months ago, so they really ought to be providing security patches for version 6.

While that is good information in general, SSL would help in this particular attack, as it would still block the Tor exit node from seeing the data.

Even if BTSync were to process one connection string per CPU clock cycle, it would still take 1e20 years to try all the possible 20-character Base64 strings that BTSync uses by default. If you choose a longer string, then it will take even more time. In otherwords, the standard strings have 120 bits of entropy, and you can increase that to up to 240 bits. This is less than is typically used for encryption these days, but btsync doesn't have to deal with offline attacks.

Rather than key size, I would be more concerned about whether the client potentially leaks data through timing attacks, or any MITM/sniffing attacks that speed up the cracking faster than brute force.

That isn't an open source implementation of btsync. It is just an unofficial debian package that installs the official proprietary btsync binary. It makes it easier to install and update btsync on debian based systems, but it is the exact same software that you download from the official site.

I have been using bittorrent sync for about the same amount of time, and the thing that is killing me is that it makes no effort to detect and warn when a file has been modified on multiple computer since the last sync. It just chooses the one that was modified most recently, and silently overwrites the other one. It does create a temporary archive backup of the modified file that was overwritten, but by the time you noticed you have lost data, it can be very difficult to wade through all the archive files on different computers and figure out which ones need to be merged. The resolution to conflicts will always have to be a manual process, but the sooner you know that a conflict occured the easier it is to resolve.

I've lost track of how many password resets I have had to do because I lost a newly randomly generated password saved to my keypass database, synced across computers.

Think of it this way. If you are a company that has a D3D application that you need to port to linux, does it make more sense to spend a small amount of time making wine-lib based port that works with any video card driver. Or to spend a larger amount of time to create a native port that only works with specific drivers, causing all sorts of complications for your potential user base. It's a no brainer; you take the path that is less work for you, and more compatible for your customers.

This native D3D9 support only works for drivers based on Gallium3D, which includes Noveau and the newer cards supported by the Radeon driver. If you are using the proprietary NVidia or AMD drivers, then this won't work. I can't imagine that any company would want to support a Linux port that required you to have specific graphics card drivers installed. Especially a company that didn't care enough about cross-platform support to use OpenGL from the start, and especially when many of the people who care about gaming on linux will be running the proprietary drivers, since that is what works best for most other games.

Wow, someone at the MLB must really hate Iowa.

When Arstechnica ran that WP story about corruption in the USPTO, several current and past patent examiners posted comments that are worth reading. Two key ones in particular are this and this.

Short story is that USPTO has stupid counterproductive performance metrics, so everyone games the system to look good by the metrics (we've all seen that before). Some managers recognize this and don't want to be assholes about time charging rules because of it, as long as employees are doing good work. Others get upset that the rules are being broken and assume it is blatant time card fraud, and blew the whistle to the news outlets.

They are evaluating different technologiess, some of which are implemented on and affect a single phone, others implemented with hardware in the car and affect all phones in the car. But even if it disables all phones in the entire car, I am completely fine with this. Yes it is inconvient, but it's not like it is being required as standard equipment on all cars all the time. It is only being applied to cars of people who broke the law and put others around them at risk. You want to keep using your phone when you are riding with a friend/spouse; then give them shit about texting while they are driving.

They measured multiple things! The statement "We depend too much on science and not enough on faith" was measuring attitudes about science, and neither the article nor the report present it as an example of scientific literacy. Here is what the article stated as proof of scientific literacy from the article:

The executive summary of the report goes on to list some tests as an additional assessment:

Commenting to undo accidental moderation. But since I have to say something anyways...
It makes since that they would draw 9-5 on the graph, for easy comparison and that they would label it the standard workday, since that is what is traditionally been considered as such. But I have no clue how they could look at that graph and come to the conclusion that most people still work from 9-5, as the article text claims.

Sure, I assume that all cars will have something like that. Heck, since the car will be doing navigation it will likely have found a gas/charging station and pulled over long before it even got to that. But regardless they will never be perfect. What if it sprung a leak and couldn't pull over in time because it judged that there was no suitable shoulder (mountain road, narrow bridge), and this info wasn't in it's database to enable it to plan ahead?

We have been mass producing cars for over 100 years, and by all reasonable measures they have never been as reliable as they are today. Yet they still break down on occasion. Self driving cars will have all the same mechanical and electrical problems that we have today, with software problem on top of that. You can mitigate some of these hardware problems with additional sensors, and fault-tolerant design of the driving computer, but only to the point where the sensors and software are significantly more reliable than the hardware they are monitoring, and only for the situations that are programed for.

There always will be situations where things break down in unexpected ways that the car isn't capable of handling on it's own. And based on the historical rate of reliability improvement, those situations won't be uncommon for quite some time.

They may never be removed. Everyone is focused on the split-second decision scenario when talking about this issue, and on that I agree that humans will cause more problems than they solve. But there are many more situations where manual override is needed and beneficial. What happens when the car runs out of gas/charge and you need to push it to the side of the road out of traffic. Or the computer is malfunctioning somehow (software bug, squirrel chewed halfway through a wire, dead battery/alternator). Or when I need to move the car somewhere off-road that the AI refuses to recognize as a valid driving path. There are plenty of not so time critical scenarios where some sort of manual override is needed and those aren't going to go away even when we trust the software to do all the driving. Once we admit that they don't have to be intuitive for split-second reactions, then they don't have to retain the traditional layout, nor be designed for comfortable everyday use, but some sort of steering, brake control, and neutral gear select will always be needed.