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.
You know, it has a GUI that lets you click on File->Open File to open a text file. Or you can type emacs filename.txt at the command line. Its really not that hard.
In general the learning curve may be shallow, but it goes up for a very long ways I seem to recall a similar difficulty the one time I tried to use vi as well.
Scott's bit was pretty clear. He didn't use any unnecessary jargon. I can see how it might be confusing to a person who doesn't have a basic familiarity with Linux. Rym's was a bit more cryptic. Hehehee... Unix Santa.
To rehash the trite joke, EMACS is a great operating system with a shitty text editor.
Oh, there's a quote from alt.religion.emacs that I feel is highly relevant to the point you bring up.
Emacs (let His name be honoured forever) is not only an OS; it is an OS *and* a programming language (The One Programming Language -- see alt.religion.lisp) *and* a set of editors, the programming language being the personnification of the link between the editors and the OS. Whether Emacs is One in Three or Three in One remains an open theological question.
Further theological discussion on these important issues can be found at this site. Remember kids, using vi isn't a sin, its a penance.
I didn't understand almost anything in this episode. I have no Linux experience and I haven't studied any stuff computer stuff (yet). Maybe if I would gave some attention to episode, but I usually play something with my znes while listening podcasts. I should try to listen this again with some concentration, but I don't believe that I will understand much more than at first time, because episode was full of terminology that is unknown to me.
You forgot the most important part: "Real programmers set the universal constants at the start such that the universe evolves to contain the disk with the data they want." Also, note how the vim user mocks the emacs user, also note it's the emacs user who starts that brag fest, had it not been for said emacs user said brag fest would not have occurred, think about that for a few seconds.
And stop hitting return after the closing blockquote tag.
I just use Nano because it's incredibly easy to use.
But it is very weak. If you actually learn vim, you can do very powerful things with very little effort.
Think of it like the difference between a handsaw and a chainsaw. It's much easier to learn how to use the handsaw, and much less dangerous. However, if you do decide to learn how to use the chainsaw, and take proper safety precautions, you can get the work done a zillion times faster and more easily.
I got about 90% (lost me a bit on the Ubuntu stuff) but even the 10% I didn't understand I at least followed. Definitely would like more of these episodes. If I wasn't swamped today (only got to the episode on the way to work this morning) I'd looking up some of the Ubuntu stuff. I just downloaded Sun's VirtualBox (open source virtual software on ALL platforms) to run XP on my mac. Might mess around with Ubuntu on it a bit.
On paper, I should have hated this show. I'm not a computer geek at all. I came to this podcast because of boardgaming.
And yet I enjoyed it quite a bit. It made me think, and that's a good thing. There have been many shows that cover something I'm interested in, but don't make me think. Those are the shows that I daydream during.
Would I want this type of show all of the time? Probably not. But it ought to have its place in the rotation.
I loved this episode. It's nice to be able to relate to the VM time issue. My employer uses a CRAZY old version of XenServer (back in the days when everything was still called MetaFrame and CPS) that spawns a new instance of our administration app every time a CSR/tech connects. We have to force the Citrix client to kill the connection before the application idles server-side, because that application instance loses cycles, stalling the app's internal clock (we can't trust the client's time), and thus letting agents book service installations two weeks into the past. Process VM's have time issues too, just not as many as full-blown system VM's :P
The crows video was fantastic, I smell a market for waste removal with trained birds/monkeys/children. As for the tech discussion, I think the perfect level is for Rym to explain his topic/problem to Scott, and vise versa. The lowest common denominator of your Scrym's shared tech knowledge is still a healthy bit above my own, though I pick up on maybe 70-80% of it. I take it as a learning experience, and as such I was very happy with the format.
I am a very non-techy type person when it comes to computers. I need computers, computers don't need me. But this episode was really good fun. I looked at the problems as a kind of riddle. I have no clue about the acronyms or anything, but could understand the problems with the timings and permissions.. Of course I had nothing to say about the solution, but understood what you were getting at.
This is from someone who has to call a friend to connect a computer to a wifi modem. I have very little knowledge, but can admire a high level problem and how you solve it. You go on like this on Tuesdays (I like boardgames, and living in Berlin helps with my "German Boardgames Fix") and I'm sure people who aren't so into games can keep up. I guess you also go into this much depth on Wednesdays, but I rarely listen past the news and things of the day.
Keep it up! And you can always go more into depth about your newses.
Hmmmm, yeah, I was always all for making shows more techy, but the majority of this episode went over my head. I understood most of the stuff about clock syncing, but most of the ubuntu stuff went right over my head. Either way, though, I still like that better than the dumbed down-ness of "what is a programming language". This way I can at least learn new things and potentially listen to the episode later when I understand it all.
Dkong pretty much said exactly what I was going to (damn you, Dkoooooooong!) - I could follow the clock syncing problem, but Scott's Ubuntu issue was almost all Greek to me. Whenever I for the life of me couldn't follow Scott anymore, this was the image my mind seemed to default to:
I also agree that even though I couldn't follow a lot of this episode and I felt quite pedestrian while listening to it, you shouldn't stop doing episodes like this just because a bunch of us also like the layman's terms episodes. I think as long as you have a balance between the two types (as well as episodes that fall between the two extremes), you guys should do all right.
This was so much better than your usual lite coverage of topics,
Please please please do more tech episodes like this. I'd love to here Scott's thoughts on online "APIs" vs actual C/C++/etc APIs; X11-devel, DirectX *gag*, SDL, &etc. &Please, pretty please, Scott learn some science stuff.
I would have to say that my comprehension of this episode (the main bit) was about 75%. I understood the Ubuntu thing (I think), and most of the Virtual Machine stuff, but the last part lost me.
I was wondering what ever became of vmware issue you had? I started watching the time on my servers after this episode and virtualbox seems to keep things remarkably accurate (at most 1 or 2 seconds behind actual system time.)
-gedavids, an IT newb trying to become knowledgeable.
Comments
In general the learning curve may be shallow, but it goes up for a very long ways
Oh, and the pidgin/zephyr bug I filed is here.
And stop hitting return after the closing blockquote tag.
Think of it like the difference between a handsaw and a chainsaw. It's much easier to learn how to use the handsaw, and much less dangerous. However, if you do decide to learn how to use the chainsaw, and take proper safety precautions, you can get the work done a zillion times faster and more easily.
Also, that's a very nice analogy Scott.
And yet I enjoyed it quite a bit. It made me think, and that's a good thing. There have been many shows that cover something I'm interested in, but don't make me think. Those are the shows that I daydream during.
Would I want this type of show all of the time? Probably not. But it ought to have its place in the rotation.
Anyways, I say go for Google next week. I'm curious and I'd like to hear more.
For the thing of the days- when I first heard "crow vending machine", I thought the machine sold crows. WOW that was a dumb moment for me...
This is from someone who has to call a friend to connect a computer to a wifi modem. I have very little knowledge, but can admire a high level problem and how you solve it. You go on like this on Tuesdays (I like boardgames, and living in Berlin helps with my "German Boardgames Fix") and I'm sure people who aren't so into games can keep up. I guess you also go into this much depth on Wednesdays, but I rarely listen past the news and things of the day.
Keep it up! And you can always go more into depth about your newses.
I'm looking forward to an episode about Googles possible evilness.
[2] there ARE alternatives to predator!
[iii] I also vote for Gevil.
Either way, though, I still like that better than the dumbed down-ness of "what is a programming language". This way I can at least learn new things and potentially listen to the episode later when I understand it all.
I also agree that even though I couldn't follow a lot of this episode and I felt quite pedestrian while listening to it, you shouldn't stop doing episodes like this just because a bunch of us also like the layman's terms episodes. I think as long as you have a balance between the two types (as well as episodes that fall between the two extremes), you guys should do all right.
Please please please do more tech episodes like this. I'd love to here Scott's thoughts on online "APIs" vs actual C/C++/etc APIs; X11-devel, DirectX *gag*, SDL, &etc. &Please, pretty please, Scott learn some science stuff.
I was wondering what ever became of vmware issue you had? I started watching the time on my servers after this episode and virtualbox seems to keep things remarkably accurate (at most 1 or 2 seconds behind actual system time.)
-gedavids, an IT newb trying to become knowledgeable.