Yeah, but not by default. I agree that this won't influence most businesses who are still running IE. But old grandma running IE 6 will find that her internet is broken, and will ask someone to fix it for her, which most likely will involve upgrading to an newer browser.
It may also bring back the days of banks requiring the use of IE, as none of the citi group websites support any version of TLS. Of course, those in the know should cancel their citi accounts. Even if you don't use their website, if their security is this lax in one area, it probably isn't great in others as well. Sucks for people with mortgages and such that are very expensive to move to another company, though.
Yeah, more test data across the spectrum of body types is always a good thing. The article mentions that they are working on building dummies to better model elderly people as well.
Nobody includes failures during component testing into the failure rate of a rocket. Doing so is completely meaningless and disingenuous.
[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.
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.