I started indoor climbing 3 months ago and it's done wonders for my grip strength, as well as my overall health. I can't recommend it enough for engineers and other problem solving addicts. I was, frankly, bored by weight training and other more traditional exercise routes. Now I look forward to a nice change of pace - solving physical problems as opposed to logic problems.
I'd strongly suggest you contact the maintainer of the python3 package and request a backport. 3.5.1 is in testing, so it should be possible, and perhaps even easy to backport.
Respectfully, I think this amounts to bias more than anything. It's a lot easier to believe that the slide-offs are caused by bad driving - and most probably are. But some are unavoidable.
> Winter driving is really no different from any other kind of driving in which the driver exceeds the limits of the vehicle's available traction.
I actually agree with this statement. The problem is that, in good conditions, low traction events are rare, and often caused by catastrophic conditions. In winter driving it's practically the norm, once you leave well traveled roadways.
I think AI could be trained to drive a car that only occasionally has full traction, and probably more effectively than a person given enough time. But again - it's like you said - someone needs to be addressing this case directly.
Having lived nearly my whole life in Michigan, I think this grossly oversimplifies the problem. I'm sure my Canadian friends will agree. This assumes there's some clear algorithm for determining a "safe" speed. There's not.
Even in highway driving you can lose traction in an instant if you hit a patch of black ice. Autonomous vehicles will need to be able to recover from a complete loss of traction safely. This isn't trivial - in fact it's probably the most complicated bit of driving I tend to do. Once you are sliding and your steering wheel becomes more of a suggestion than a command, the entire act of driving becomes a process of trying to coax the car off the road using a combination of steering, brakes, and even occasionally gas. I think it's possible for a computer to do this - but you can't avoid all slides just by driving slowly.
Then there's the plethora of other winter fun you run into with a vehicle: getting stuck (happens all the time on city streets) and all the techniques to get unstuck, going too slow and losing your momentum (and thus traction), having every indication you have traction and then discovering you actually don't (it's very easy to be driving at a "safe" speed and still slide through an intersection), white out conditions where you are guessing where the lane is... etc...
To be clear, I believe most of these conditions could eventually be handled by computers. I also believe a lot of people drive too fast in/on snow. However, winter driving is in no way simple. It's a problem domain unto itself, and one I've seen relatively little work being done on.
When you say "move M-x customize to gtk widgets", which text based would you replace with GTK widgets? Customize certainly doesn't initially seem as friendly as a traditional preferences dialog, but I would be hesitant to lose the "it's all text" navigability and consistency.
I'm no expert, but I believe the rationale is to simplify relicensing (GPLv2 -> GPLv3, for instance). I also think the papers disallow dual licensing the project with a proprietary license.
GNU requires contributors (and maintainers) to assign copyright for non-trivial contributions. Benno doesn't want to do this, thus in GNU's eyes, he can't be the maintainer.
You can argue (and it has been, to death) whether copyright assignment is right or wrong. When it comes to GNU projects, it's the rule of law. Based on mailing list posts and contribution history, it seems like the project had probably been in questionable GNU territory for awhile, given Benno's strong role and his unwillingness to assign copyright. I'm curious to see how the GNU project will respond.
You aren't going to get away from systemd with a Debian or Ubuntu system. Both Debian 8 and Ubuntu 15.04 (and beyond) use systemd. There are very few mainstream Linux distributions that haven't adopted it, Slackware being the notable exception.
You've probably lived somewhere with leaded pipes. They are very common. Across the country we are working to replace leaded pipes when we can, but the problem is very complex. As it turns out, it's much more cost-effective to treat water than embark upon giant infrastructure projects. Simply put, the MDEQ, and the EPA should have known to treat the water, which would have kept the lead from leeching into the water. Unfortunately, this wasn't done, and now the pipes are damaged - perhaps beyond repair.
Despite the above, the water problems in Flint can't be attributed to a single thing, but rather a culmination of failures in state and local government best described as a problem of culture. Instead of a culture of openness and communication, there are indications the state, and to a lesser degree, the local government embraced a culture of only communicating good news and spinning or squashing bad news - even internally.
> I thought the MIT License was always the best license to use.
This community in particular seems to like the MIT License because it is quite simple and perceived as commercial friendly. The truth is, like most things, it depends on what you are trying to accomplish. Open source licenses all have an agenda. If your agenda is "Anyone should be able to use this software, for any purpose, and not hold me liable," then the MIT License is perhaps the simplest option.
In my (non-lawyer) opinion, where the MIT License falls short is in assuming that all contributors, companies, and users share the basic ideal that licensing software for free use and modification is in our collective best interest. Other licenses (Apache, GPL) try to attack this problem in various ways. It turns out it's a complicated and not fully understood domain - which is why those licenses are more complex.
The point is that there is no "best" license to use because licensing is not a technical problem - it's a social problem. Licenses attempt to address the slippery concept of community using a legal framework. In choosing a license, you want to be thinking about not just the community you are currently contributing to, but the community you would ideally like to be contributing to.
> I was able to share 15 GBs of vacation videos with 10 of my non-techie friends by sending them a read only key to a shared folder. All of them got it right away with no technical questions or issues.
I appreciate SyncThing's security first stance, but it would be incredibly helpful if it was a bit easier to share specific synced things with non-techies.
This isn't as surprising as you might think. Roger and Me isn't a documentary, it's an editorial. It's actually used in film classes as an example of creative editing to make a point. I'm not saying that Flint isn't bad, but Moore did pretty much everything he could to make it look as bad as possible.
The feeling of most folks from Flint I've spoken to is that Moore made a disingenuous "documentary" about Flint not to raise awareness, but to make a buck. It's understandable he's not lauded as a hero.
I also think it's unfair to characterize the reaction of some residents of Michigan to a controversial figure at best as "Michigans backwardness".
If you are interested in a detailed breakdown of everything that's been happening over the past year or so, I would suggest reading Michigan Radio's excellent coverage: http://michiganradio.org/term/flint-water
Full disclosure: my wife works as a reporter Michigan Radio, but generally doesn't cover Flint.
I think a lot of the common idioms passed around about microkernels stem from the old Torvalds v. Tannenbaum argument [1]. It wasn't that Torvalds was right and Tannebaum was wrong. It was simply that Tannenbaum had reliability and theoretical correctness in mind, while Torvalds was concerned with performance. The less context switching you do, the more performant your computer will be. We can take this to the extreme and look at OSes like TempleOS [2] where EVERYTHING runs in kernel mode. Most people prefer a bit more reliability, and so modern desktop kernels are generally hybrid kernels (with the notable exception of Linux which is, of course monolithic). I don't think there's any real technical reason a microkernel couldn't work on today's hardware which is many orders of magnitude faster than what we had in 1992, but a hybrid kernel is always going to be faster.