Slashdot videos: Now with more Slashdot!
We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).
Well... on GitHub the wiki _is_ actually stored in a Git repo... and all of the pages are simply Markdown. They are VERY easy to move to many other systems (or even to view locally).
GitHub even publishes an open source version of its wiki renderer to make it even easier: https://github.com/gollum/goll...
NOW: The bugtracker stuff is a little more difficult. You can use the GitHub API to pull out all of the info easily enough and store it locally... but you have to do some sort of transformation to get it into a new format if you're trying to move to a different service.
Personally, I've done this the other way around. We went from using Trac on our own servers to using GitHub. I wrote scripts to take all of our Tickets from Trac and upload them to GitHub as Issues using the GitHub API. It was a pain but not impossible....
If GitHub is down just:
git remote add bitbucket email@example.com:company/project.git
git push bitbucket
And then keep rolling.
Replace Bitbucket with any number of alternatives.
It simply doesn't matter if GitHub goes down. It has a convenient interface, for sure, but you can continue to work without it easily.
Same is true for subversion. In both cases you can develop and test your code and review your changes against what was last seen original copy
Subversion has gotten better recently... but in the past nearly every command required a round-trip to the central server. Like I say, that has recently changed for a few (like 'svn stat') but there are still MANY that require a live link to the central server.
Contrast this with Git where the _only_ time you need to access a server is for sharing.
When GitHub is down it only takes one command to push your whole repo to BitBucket so you can keep working with peers. Sure, you don't have access to any *data* (wiki, issues, etc) that you had on GitHub... but the most important thing (the code) is VERY mobile.
I somewhat agree... but the problem is not "is a driverless car better than a human" it's: who do we sue when something goes wrong.
In the proposed hypothetical, whoever gets hit is going to be suing someone. Who do they sue? The owner of the car (even if they weren't in the car the time?) the "passenger" or the company that makes the vehicle.
I tend to think that it will be the owner - and the owner will need to have insurance to cover whatever the autonomous car could do. There is no way a company like Google is going to put out a product like this where it's liable.
As for "rare/never seen in the real world situations" you have to remember that with a high enough saturation of these on the roads... those "rare" situations will happen all day long, every day (they already do with regular cars). The statistics makes this quite tricky...
Note that I am NOT an obstructionist and I am all for autonomous vehicles... but the legal aspects of self-driving cars is something that needs to get solved soon...