Google is getting ready to take over the world, I know it.
Imagine the day where you search on Google for various symptoms you're experiencing and Google automatically notes on your records these symptoms. Depending on the severity of matching illnesses, Google might page your doctor and report on it.
The repercussions of this is both facinating and chilling. I don't know whether to be intrigued or scared.
I might be getting in over my head, here, having not listened yet to the episode. But there are about 36 million retirees in the U.S. and the poverty rate was about 12-13 percent in 2006, according to the Census Bureau. So there are some common sense figures behind the e-mail bit. The Bureau also showed in 2006 (the last figures I can easily find) that there are about 74 million children under the age of 18 -- and for many of them e-mail is obsolete. Why e-mail when you can AIM, Twitter, or MySpace?
I was one of the folks looking forward to this type of episode, but I found it much like staff meetings I attended when I worked in a production plant for Dow Chemical. The entire staff spoke in acronyms without respect for the newbie in the audience. I understand that the point of this episode was to speak to technical problems in the way you do to each other. As a long time listener and big fan of the show, I found it almost unlistenable. I really respect your depth of knowledge, but I would not want you to do an episode at this level again.
I think that discussing issues that are at a high level, but in terms that are understandable to the more common listener (something you both do very well) would strike a good balance. Thanks for the experiment though. You can't grow the show without trying new things.
I absolutely loved the show! This is the way I am accustomed to speaking to those I interact with. I felt you did still explain the acronyms used, but perhaps I am just used to this type of conversation. The last 5 to 10 minutes you babbled off and I think that is where you might find listeners drifting. Perhaps you can sometimes do in-depth shows like this and other times do what you were previously doing. Keep in mind those of us looking for this type of show would like to see this same type of thing on other nights now and then, like Thursdays. Often for example, you mention on other night's shows that you are not going to go into some topic, perhaps you could do a whole show on it sometime. Well, do one of those shows.
Regardless, this show was one of your better Monday night shows on technology in my opinion.
I would like to hear your opinions on privacy and whether Google is evil or nearing evil. Like yourselves I trust Google to my searches, my RSS feeds and my email.
I understood all of this episode and I hope theres more of these. I thought it was funny how Scott says chmod and chowned. I normally say "see-aych-owned" not "chuh-owned".
I'm not an incredibly techy person, but I feel like I was able to follow at least the general gist of both of the topics, and I found them interesting. There were a lot of references to programs and whatnots that I'm not familiar with, so that lost me a bit, but I think if that sort of thing were accounted for, this sort of episode could go over well for me.
I really liked this episode. I got most of it, and the little bit that I didn't get I was able to infer. I wouldn't have been able to describe it myself, but once it was pointed out to me, I could see exactly the problems.
I wasn't able to listen to the entire episode, but I was able to get the gist of both problems. I noticed that Rym's explanation of his solutions came out very quick, almost as though he was either really excited about it, trying to finish quickly, or purposely trying to confuse the audience. While I certainly appreciate this episode, I might suggest only covering one topic at a time.
Not bad, all I can say is to SLOW DOWN, yes I understand you have your own way of talking but you flew by the topics to the point where I had to rewind segments to catch things.
Thank you for doing this. This episode required thought on the part of the listener. While a lot of people don't want that, some do. Now and then, it can't hurt.
Scott, is it possible for you to use a file synchronization program as a workaround to your issue? That would stop the manual drudgery of copying files and it shouldn't change the file attributes. I don't know if that's possible through ssh?
Thank you for doing this. This episode required thought on the part of the listener. While a lot of people don't want that, some do. Now and then, it can't hurt.
Agreed. Don't drop down to the listener, make them step up. With the former, little learning takes place IMHO.
I thought this was a great episode! I really like having to really listen to keep up with what you are saying. It did require some more thought then a standard Monday episode, and that is what originally brought me into geek nights.
Would anyone here use Google for personal financial tracking? My wife and I are busy, connected people and we've found the best way to track a lot things is using gDocs and gCalendars. This includes quite a bit of financial information though we keep it fairly clean (no account information directly but information and analysis around what is spent).
Scott, is it possible for you to use a file synchronization program as a workaround to your issue? That would stop the manual drudgery of copying files and it shouldn't change the file attributes. I don't know if that's possible through ssh?
I did say that I could just checkout the source code repositories directly to my local machine. This defeats the purpose and benefit of even having a development server. I could use rsync or some other mechanism to allow me to work locally, but transfer the files to the dev server, but that is even worse. It adds an extra step to the development process, and slows me down.
I personally really liked this episode. I found Rym's issue more interesting and easier to understand, but I have worked (a little) with virtualization. I haven't ever ssh'ed into anything.
Anyway, high level technology and explanation aren't mutually exclusive.
Didn't understand jack about the show, it took me a few minutes to figure out VM = Virtual Machine (I think). I did understand what the problems were after a while, but thats about it.
At least it worked to create some background noise.
The 0.01% is due to me listening to the show on the train in the morning (7:30 onward) in my non-native language.
This was a really awesome episode, perhaps try the same on the Tuesday, Wednesday and perhaps Thursday (depending on if Thursday is still possible with the new awesome changes) shows. Say, go into crazy game theory depth with board games, explaining why they are broken and how the game can be predicted. Perhaps add a spoiler line. For Wednesdays I have no idea how to crank the level up, but I doubt that's needed.
This episode went way over my head. Too much tech that I didn't understand at all. I'm no tech retard, but this went well above my general understanding.
My comprehension level hovered somewhere around 10% or so.
However, I also think you should do more shows like this. Tuesdays, you don't beat around the bush about games. Wednesdays, there's no beating around the bush about anime/manga/comics. Thursdays, there's no beating around the bush about copping out.
You're tech guys, so your Mondays should be a very tech guy show. There's nothing wrong with throwing in a few "explain this concept to people" episodes, but I'm inclined to think that the majority should be more like this one.
This was a very linuxy episode. I'll bet that whatever your general tech level, this episode made a lot less sense to anyone who doesn't have any linux experience.
I liked this episode, I understood essentially everything in Scott's talk and everything but a few points of Rym's talk. As an MIT alumn I feel obliged to point out that he probably wouldn't be having that problem if he would only just switch to Emacs...
Can I recommend that for some future tech day you do an episode on reporting problems in open source programs? I was recently having a problem with Seg Faults in Pidgin when I was trying to use it as a Zephyr client (yes, I actually use Zephyr regularly) and I later realized that it would have been better to report it directly to the Pidgin guys rather than the people at Ubuntu.
As an MIT alumn I feel obliged to point out that he probably wouldn't be having that problem if he would only just switch to Emacs...
I think the defining moment in my use of EMACS was figuring out how to open a text file. To rehash the trite joke, EMACS is a great operating system with a shitty text editor.
Comments
Imagine the day where you search on Google for various symptoms you're experiencing and Google automatically notes on your records these symptoms. Depending on the severity of matching illnesses, Google might page your doctor and report on it.
The repercussions of this is both facinating and chilling. I don't know whether to be intrigued or scared.
I think that discussing issues that are at a high level, but in terms that are understandable to the more common listener (something you both do very well) would strike a good balance. Thanks for the experiment though. You can't grow the show without trying new things.
Regardless, this show was one of your better Monday night shows on technology in my opinion.
I would like to hear your opinions on privacy and whether Google is evil or nearing evil. Like yourselves I trust Google to my searches, my RSS feeds and my email.
Did you guys enjoy making this episode more?
Not bad, all I can say is to SLOW DOWN, yes I understand you have your own way of talking but you flew by the topics to the point where I had to rewind segments to catch things.
Scott, is it possible for you to use a file synchronization program as a workaround to your issue? That would stop the manual drudgery of copying files and it shouldn't change the file attributes. I don't know if that's possible through ssh?
Just curious what the forum thinks.
Anyway, high level technology and explanation aren't mutually exclusive.
At least it worked to create some background noise.
The 0.01% is due to me listening to the show on the train in the morning (7:30 onward) in my non-native language.
This was a really awesome episode, perhaps try the same on the Tuesday, Wednesday and perhaps Thursday (depending on if Thursday is still possible with the new awesome changes) shows. Say, go into crazy game theory depth with board games, explaining why they are broken and how the game can be predicted. Perhaps add a spoiler line. For Wednesdays I have no idea how to crank the level up, but I doubt that's needed.
This episode went way over my head. Too much tech that I didn't understand at all. I'm no tech retard, but this went well above my general understanding.
I like the "dumber" episodes.
Bring back the dumb! (for me, at least)
However, I also think you should do more shows like this. Tuesdays, you don't beat around the bush about games. Wednesdays, there's no beating around the bush about anime/manga/comics. Thursdays, there's no beating around the bush about copping out.
You're tech guys, so your Mondays should be a very tech guy show. There's nothing wrong with throwing in a few "explain this concept to people" episodes, but I'm inclined to think that the majority should be more like this one.
...I have a lot of work to do...
Can I recommend that for some future tech day you do an episode on reporting problems in open source programs? I was recently having a problem with Seg Faults in Pidgin when I was trying to use it as a Zephyr client (yes, I actually use Zephyr regularly) and I later realized that it would have been better to report it directly to the Pidgin guys rather than the people at Ubuntu.
To rehash the trite joke, EMACS is a great operating system with a shitty text editor.