This forum is in permanent archive mode. Our new active community can be found here.

GeekNights Monday - When your Meat Dies

edited May 2013 in GeekNights

Tonight on GeekNights, we consider what happens (and should happen) to your bits (i.e., your emails, tweets, hard drive, and collected digital output of a human lifespan), when your meat stops working (i.e., you die). Law, society, human drama, and fear make it a much more complicated issue than you might realize. Do the dead have rights? Should they?

In the news, the Ask.com Toolbar is malware, Ninite is the closest thing to a Windows repo you'll ever find, and Google Authenticator just implements TOTP, which you can totally use for two-factor authentication in anything. Also, Adobe updated their software suite to be subscription only (and this is a good thing).

Download MP3
Source Link
«13

Comments

  • The Penguicon Chaos Machine:

    image
    image
    image

    Also, when we accidentally blew off Steve Jackson.
  • I've been using Ninite for years, it's really useful.
  • You JUST found out about Ninite? Wow I thought everyone knew that
  • You JUST found out about Ninite? Wow I thought everyone knew that
    I usually get all my software straight from the source because I don't trust weird download sites for shit. How would I come across Ninite with that policy?
  • Ah, I look forward to listening to this after my exam tonight.
  • You JUST found out about Ninite? Wow I thought everyone knew that
    I usually get all my software straight from the source because I don't trust weird download sites for shit. How would I come across Ninite with that policy?
    Good point, I had to build PCs and that's how I came across it, you must be in the 10 percent today.
  • You JUST found out about Ninite? Wow I thought everyone knew that
    I usually get all my software straight from the source because I don't trust weird download sites for shit. How would I come across Ninite with that policy?
    Good point, I had to build PCs and that's how I came across it, you must be in the 10 percent today.
    I also built many PCs. Then I would go around downloading a few drivers, then download launchy and a browser. Then I would only download individual apps one at a time from the legit sources as I used those apps.
  • But Scott, the Hole Hawg of word processing is LaTeX ^_~
  • Scott, why are you still using Launchy?
  • Scott, why are you still using Launchy?
    Just looked up Launchy, they have a picture of a Cake song on their site. :)

  • Why does everyone recommend LibreOffice instead of OpenOffice now?
  • If I remember correctly, Oracle java bullshit.
  • Seriously?

    If you're an user interface designer, and you manage to make cosmetic improvements to your original design every so often, THEN YOUR ORIGINAL DESIGN WAS SHIT.

    Fuck you

    http://www.penny-arcade.com/comic/2011/02/11
  • Damn. Props to Adobe!
  • Scott, why are you still using Launchy?
    So I don't have to take my hands off the keyboard to launch apps, and it is faster and slightly better than the thing built into the start menu.
    Why does everyone recommend LibreOffice instead of OpenOffice now?
    OpenOffice died and LibreOffice is the real deal now. It's the same way that XFree86 died (years ago) and Xorg is the real deal now. It's a thing that happens with open source projects. There are forks and deaths and rebirths.
  • As far as I know, Google has a system in place for your account access when you die.
    http://googlepublicpolicy.blogspot.com/2013/04/plan-your-digital-afterlife-with.html
  • As far as I know, Google has a system in place for your account access when you die.
    http://googlepublicpolicy.blogspot.com/2013/04/plan-your-digital-afterlife-with.html
    A basic practical tool for one of the many repositories of bits, but it doesn't cover everything, is unknown to many users, and doesn't give a way to ensure even reasonably that one's wishes are followed through.

  • edited May 2013
    NPR had a recent segment on this, in which they highlighted this blog dedicated to the topic and this book, by the same people. During the segment, they confirmed that, yes, you need to put this shit in your will.
    Post edited by Matt on
  • edited May 2013
    Facebook has three ways of dealing with your death, your family can petition to set your account as memorial, which means no one can search for it and friends can write on the wall, or you can leave it be and everyone still can access it or you can get it deleted depending on what you want to do it with.
    Post edited by Cremlian on
  • Facebook has three ways of dealing with your death, your family can petition to set your account as memorial, which means no one can search for it and friends can write on the wall, or you can leave it be and everyone still can access it or you can get it deleted depending on what you want to do it with.
    I know someone who went the memorial route and the little dirty secret is that the account will still recommend things to its follower to get you to buy things. Scummy is scum.
  • "Cremlian suggests that if he was alive right now, he's recommend you buy the new Zelda game"
  • Aw man, I thought this was going to be an episode about animal slaughter. I am disappoint.
  • Aw man, I thought this was going to be an episode about animal slaughter. I am disappoint.
    On a Monday?
  • Aw man, I thought this was going to be an episode about animal slaughter. I am disappoint.
    On a Monday?
    Usually technology of some kind is used in slaughtering animals. Perfectly valid Monday show.
  • Maybe we could do a live report during the slaughter of Death Cluck. Or a photo journal. I mean, I need to document the process anyway. Send it in as a guest episode.
  • So about the whole Git GUI vs CLI thing: first, as I only use Git for some of my personal projects and never used it at work (except for keeping track of some of my personal scripts and such that I don't usually share with co-workers), my Git skills are probably on a par with Rym's -- mostly because I haven't had need to do anything much more than commits, some basic branching, etc. I have yet to need to do some of the fancier features like rewriting history, rebasing, etc., as I'm not exactly working with a bunch of other developers with their own branches where I need to properly merge and sync things. Second, I use both Git GUIs (TortoiseGit on Windows is really nice) and the CLI, although I use the CLI much more often as it's where I started and usually quicker for the vast majority of Git operations I've had to do thus far.

    The thing to keep in mind with how much Git is okay to learn (and how much Git a GUI should expose) is the 80/20 rule. 80% of the time, you're only going to be using 20% of the features, so make those 20% features easy to get to and use, even if that means your GUI wrapper doesn't expose the other 80% of the features. For example, while 'git bisect' can be a very useful command for tracking down bugs (although, admittedly, I only know about it anecdotally as in my small-scale Git usage I have yet to use it myself), someone whose sole job is to produce art for a website or game would probably have no need for it. In that case, it's okay if whatever Git wrapper they're using doesn't include bisect functionality (although, I would agree with the statement that a proper general-purpose Git UI, command-line or GUI, should include bisect -- this is a contrived example for illustrative purposes). Now, if said artist for some reason needed to drop down to the CLI to do something the GUI doesn't do once in a blue moon (AKA the features only used 20% of the time), then it's okay to Google for it or ask the programmer in the cube next door for help.
  • Ok, Lou. You like flying. Look in the cockpit of a commercial jet. There's about a zillion different switches and buttons in there. I asked a few pilots how many of those buttons they actually use. They said they knew what all of them did, but most of them do not get used on most flights. It's really just a subset that is used extensively.

    Git is the same way. You are a professional. Git is one of many tools you use for your job. It is your job to know it inside and out, even though you will only use a small percentage of it on a day to day basis.

    Now, we are lucky. Unlike pilots lives are not on the line. It's ok for us to stop and Google how to do something at the moment we have to do it. There is no time limit. The world won't end because you read some documentation and instructions for ten minutes before committing. Even though I'm a Git hipster (using it since before it was cool) I don't know everything. I look stuff up all the time. I know how to bisect, but I do it so rarely I would still look up the man page if I had to do it right now.

    What I oppose is the avoidance of learning. I lose huge respect for people with the anti-intellectual attitude of trying to learn as little as possible. It's one thing to get a gui when you understand what it's doing and use the command line when the GUI fails. I use the GitHub Windows GUI client sometimes. It's another thing to use a GUI and other shortcuts to cover everything with abstractions in an attempt to conceal and avoid learning or thinking about what is beneath those abstractions.
  • Ok, Lou. You like flying. Look in the cockpit of a commercial jet. There's about a zillion different switches and buttons in there. I asked a few pilots how many of those buttons they actually use. They said they knew what all of them did, but most of them do not get used on most flights. It's really just a subset that is used extensively.
    That's true. On the flip side, they also don't memorize all the procedures those switches are used for either. They are required to fly with checklists, flight manuals, and so on. For routine stuff, sure, they're familiar with what every one of those switches do. They also probably have all the appropriate checklists memorized, although they are still required to refer to them as a safety measure, given how human brains are fallible. However, when something non-routine comes up, like say they have an engine failure, they'll often turn to the manuals to look up what the proper procedures are to recover from the failure (keep in mind that unless this failure happens immediately after takeoff or immediately before landing, there is often a good stretch of time where the plane will glide without any power to allow you to look up what to do in the appropriate manuals). The important thing is that when the manual says, "activate the APU and keep it running for 30 seconds until oil pressure in the #2 engine reaches 50 psi" they know what the APU is, where its controls are, and where the gauge that says what the oil pressure in the #2 engine is and how to read it. So yeah, being familiar with what all the switches and buttons do is one thing, but memorizing every situation when they are to be used is another. This would be like, "I know what 'git bisect' does and the command line to use the feature, but I need to look up the proper procedures to use it."
    Git is the same way. You are a professional. Git is one of many tools you use for your job. It is your job to know it inside and out, even though you will only use a small percentage of it on a day to day basis.

    Now, we are lucky. Unlike pilots lives are not on the line. It's ok for us to stop and Google how to do something at the moment we have to do it. There is no time limit. The world won't end because you read some documentation and instructions for ten minutes before committing. Even though I'm a Git hipster (using it since before it was cool) I don't know everything. I look stuff up all the time. I know how to bisect, but I do it so rarely I would still look up the man page if I had to do it right now.
    Fair enough. This is akin to looking up the proper mid-air engine restart procedure in the emergency situations manual when you have an engine failure.
    What I oppose is the avoidance of learning. I lose huge respect for people with the anti-intellectual attitude of trying to learn as little as possible. It's one thing to get a gui when you understand what it's doing and use the command line when the GUI fails. I use the GitHub Windows GUI client sometimes. It's another thing to use a GUI and other shortcuts to cover everything with abstractions in an attempt to conceal and avoid learning or thinking about what is beneath those abstractions.
    I'm also opposed to the avoidance of learning, but I don't see too much of a problem with "on-demand" learning (or referring to references as necessary) either. I'm willing to bet that a pilot whose gone through a midair engine failure procedure once will have a pretty good idea how to handle it should it turn up in the same type of aircraft again (although regulations do state that they should still refer to the published checklists just in case). If you come across the situation in Git where you need to use an obscure command that maybe you've never needed to use before, then it's okay to look it up or ask your buddy for help. Hopefully, should you need to use this feature again in the future, you'll at least have learned the basics behind it and only need a quick refresher for the procedures behind using it. At least, that's the ideal, and I think that's something we both agree upon.

    The other thing to keep in mind is that a lot of the git features are more "plumbing" (to use the developers' terms for it) than stuff that's typically exposed to the user, AKA "porcelain." Going back to the pilot example, yes, a pilot is expected to know what every switch, button, and gauge in his/her cockpit does. However, a pilot isn't required to know how to change the oil in a jet engine -- that's the mechanic's job. A Git user would probably be fine knowing all the features directly related to source control management without knowing all the intricacies of repository maintenance if you have a complicated setup. I will concede that which features are considered essential for source control management vs. repository maintenance could be a highly contentious issue.
  • You don't need to know every detail of the plumbing, but you need to have a general idea about the plumbing. I couldn't take a car engine apart and put it back together. But I understand the general principle of fuel coming into a cylinder via an injector, pressure + spark plug igniting the fuel pushing the piston down, exhaust getting sucked out, etc.

    What percentage of Git users could even tell you even the basic structure of how Git does what it does? It's sort of important to know this even to use basic features like add, merge, and rebase that I use pretty much constantly. When Git says "Fast-forward" versus when it says "Merge made by the 'recursive' strategy" you better know what that means or you might find yourself not having the files you expected to end up with.
Sign In or Register to comment.