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 second your recommendation. For various reasons I haven't been doing it the last few years, but it was really good for me and I'd like to get back into it.
Another non-team sport that has good problem solving aspects but on a faster pace is trail running. You don't get the same thinking through a route you might have with rock climbing, but leaping over rocks and ruts requires some quick subconscious analysis and careful pacing that can be quite exhilarating.
That sounds like it is very high engagement and requires presence. I get something similar riding a bike in traffic, which is logically stupid but experientially great.
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.
Tbh it might be as easy as recompiling it, Debian makes it very easy to recompile stuff, dpkg-buildpackage is trivial to run. Do it once on a throwaway image, keep the resulting package(s) forever - until new official ones land. This sort of approach can be a risk in production environments but for development images is fine and dandy.
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.
You may be correct that relatively little work is being done in this area, however I think you overstate the difficulty.
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. The methods of recovery are mostly well-known; the problem is more often the driver's inability to implement them in a timely manner.
Constant input from wheel speed and accelerometer sensor arrays, coupled with the vehicle's ability to individually brake/slow wheels (which also gives the vehicle the ability to accelerate individual wheels independently!) means that it could be a far easier 'problem' for self-driving cars to solve than it is for humans.
Again, if they're working on it :) But there's already been decades of work put into ABS, traction/stability control, etc.
> 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.
I use to live in an area that got heavy snow and had an all wheel drive vehicle (a WRX). I have lost control in the snow, even driving slowly in 2nd gear, under 30kph. For a human at least, your reactions need to be pretty automatic: point the wheels where you want to go and .. and this only applies to AWD/4x4: don't break. You don't really want to accelerate much, but you don't want to lose power to the wheels. Keep calm and the car will straighten.
It comes down to balancing, and we know we can build machines that can balance. Segways, bipedal robots, etc. So we have some of the tech and algorithms to do this in other applications, but applying it to autonomous vehicles will be its own beast.
I think such acts of control are one of the things where computers are naturally better than humans. We have a lot of experience in automatically controlling dynamic systems. Winter conditions are more of a problem because they might interfere with the sensors (e.g. radars and snow don't play together very well).
On the other hand a computer-controlled vehicle, possibly electric with 4-wheel drive, would have millisecond control over all those inputs (steering/brakes/acceleration)
I don't disagree. But without exception every winter slide-off I've witnessed first hand has been caused by excessive speed. You're driving along on a snow-covered interstate highway, someone in a BMW or 4x4 flies past you because "I have all wheel drive" starts to fishtail, overcorrects, spins out, and ends up backwards and stuck on the median.
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.
I have to agree as well. I've only had two winter driving accidents, both of them just me and one of them was unavoidable: I was travelling at very low speed down a plowed street and found a long streak of ice. I've been in plenty of winter skids and am decent and correcting them but I had 0 traction and essentially skated at 5mph into a telephone pole (which seemed safer than the cross street I was drifting toward).
I'm not sure how a self-driving car would have fixed that. I certainly believe one could but it would require a ton of learning beforehand and conditions vary widely in storms. I suppose with all-wheel drive and some selective application of the wheels in reverse it might have stopped the car before any damage was done, but how to handle situations where the AI can't stop the car before an incident and has to minimize the damage? That feels like a lawsuit waiting to happen in the US.
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.
Having a friendlier, good looking "Preferences" based on gtk would help newcomers. We could keep customize too but a new panel with simple familiar look would help a lot of people to get into emacs.
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.
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.
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.
