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.
A recent survey of scientific education and attitudes showed the Canadian population to have the highest level of scientific literacy in the world, as well as the fewest reservations about the direction of scientific progress
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:
Among the most striking results from the survey is that Canada ranks first in science literacy, with 42 per cent of Canadians able to read and understand newspaper stories detailing scientific findings.
The executive summary of the report goes on to list some tests as an additional assessment:
Average score on OECD PISA 2012 science test: 525 (10th out of 65 countries)
Average score on OECD PISA 2012 math test: 518 (13th out of 65 countries)
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.
such as people who clearly don't understand basic science drawing conclusions from unfiltered scientific data.
Those people come to their predetermined conclusions with or without the the raw data, but removing restrictions on distribution of data does help real researchers.
Or statistics? How many people are easily manipulated by presentations of statistics that they don't even understand?
Again those presenters would be manipulating opinion with or without openly available data.The fact that the statistics are openly available is the only chance people have to prove them wrong.
So neither of the examples of negative aspects are actually negative. At best the open information gives other groups the opportunity to debunk the lies and correct public knowledge, at worst people will ignore the facts for the opinions they prefer which is no worse than before the facts were available.
change.gov and change.org are two completely different sites. The
Thanks for posting a link that actually mostly explains the issue. Much more helpful than the summary that posted a link to a huge list of links, and of the ones I clicked, half weren't applicable to the issue, and the other half were just opinion pieces that assumed you were already familiar with the controversy. Horrible editing.
The purpose of security is to prevent unauthorized people from accessing the account. There are tons of accounts that are legitimately shared, and there is nothing wrong with sharing passwords in those situations, if the account doesn't have any technical mechanism to allow for multiple users/profiles on a single account. For example bank accounts, utilities, Netflix, Hulu, wireless router administration, all have been shared accounts with my wife (some have since added profiles, but not all).
Furthermore, even with accounts that we keep separate, like email, there are useful reasons to share the password, like when my wife is away from internet at work and wants me to print a boarding pass that was emailed to her. Sure I could snoop through her email, but I don't just like I could snoop through her purse or journal, but I don't.
I've seen several comments here saying "Well, I'm just CC'ing people who need to be kept in the loop!" Ok, I get that. If it's that important, why don't you just wait until they get back and give them a short briefing? If it's not that important, why did you bother sending it in the first place?
Becaused they asked me to CC them on such issues, and I don't feel like keeping a log of when everyone was gone and what happened that they might care about, so I can resend it when they get back. If it is something I care about I will talk to them when they get back. If it is something that they care about and know about then they can ask me. The problem is the stuff that they care about but don't know to ask about. Skimming an inbox full of CCs works well for that.
Absolutely. There are many advantages to this approach:
* Users can get info they need more quickly as they are already in the correct context to get help on that feature, and don't have to search a document.
* Users are more likely to use integrated help than a huge user manual, saving you support time.
* It is easier to enforce a policy of updating documentation when you update code.
The only thing your separate documentation needs to cover are high-level concepts of the application, and common HOWTOs. If you must have a monolithic reference document, then use a system like docbook that generates HTML and PDF, and integrate HTML help into your application.
Of course this is assuming that these are GUI apps. Server apps or anything that needs configuration outside of a GUI must have full reference documentation.