Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
Open Source Linux

Rare Recordings of 1994 Talks By a 24-Year-Old Linus Torvalds Re-Discovered (archive.org) 34

71-year-old Jon "maddog" Hall has been involved with Linux from the very beginning, and for Christmas shared two of the earliest recordings ever made of young Linus Torvalds speaking about Linux — recordings long thought to be lost.

Hall shares the story at Archive.org. In February of 1994 the chair of a user group for the Digital Equipment Computer Users' Society "started sending emails (and copying me for some reason) about wanting to bring this person I had never heard about from Finland (of all places) to talk about a project that did not even run on Ultrix or DEC/OSF1.... After many emails and no luck in raising money for this trip I took mercy...and asked my management to fund the trip. I sat down to use it, and was amazed. It was good. It was very, very good."

24-year-old Torvalds was giving his first talks ever at a major conference — this one attended by 19,000 people — and he was nervous. In the end only 40 people showed up for "An Introduction to Linux" and "Implementation Issues in Linux", but Hall remembers that "there was great applause." Unfortunately the talks that Linus gave were lost.

Until now.

As I was cleaning my office I found some audio tapes made of Linus' talk, and which I purchased with my own money. Now, to make your present, I had to buy a good audio tape playback machine and capture the audio in Audacity, then produce a digital copy of those tapes, which are listed here...

Here is your Christmas present, from close to three decades ago. Happy Linuxing" to all, no matter what your religion or creed.

This discussion has been archived. No new comments can be posted.

Rare Recordings of 1994 Talks By a 24-Year-Old Linus Torvalds Re-Discovered

Comments Filter:
  • by freax ( 80371 ) on Sunday December 26, 2021 @04:30AM (#62115845) Homepage

    "Also, I'm a performance freak. I actually compile into assembly code every once in a while just to look at what the compiler says. And if I don't like that I'll change the C code to compile better."

    gcc -S ftw,

    • "Also, I'm a performance freak. I actually compile into assembly code every once in a while just to look at what the compiler says. And if I don't like that I'll change the C code to compile better."

      Is there anybody here who doesn't do that?

      • Is there anybody here who doesn't do that?

        Java programmers?~~

        More seriously:

        Nowadays there's even Godbolt's Compiler Explorer [godbolt.org] to make the assembly analysis even more convenient, with a dash of cloud-base on top for "modernity", and suports a bit more languages than C.

      • Is there anybody here who doesn't do that?

        To be honest, I haven't looked at the assembly output in years.

        But one of my new year's resolutions is to learn RISC-V, and looking at compiler outputs is a great way to learn.

      • by HiThere ( 15173 )

        I don't think I've looked at assembly code in the last two decades, perhaps three. I kept switching between processor families, and assember just wasn't portable...but C code was.

        OTOH, I don't think I've run code that was CPU speed limited since the days of the Mac II. Almost everything is I/O bound.

      • Embedded work often requires converging own-code, tool chain, and SoC vendor SDK at points along their not quite independent version paths. I had a case several years ago that required assembly code examination. SDK code had omitted volatile somewhere, and our newer gcc optimized to reveal the incorrect source code that a different gcc with less aggressive optimization concealed. Same for chasing what turned out to be an individually bad CI build that dropped 16 bytes of crud into what should have been e
    • by tlhIngan ( 30335 )

      I've done it when I've had to write some assembly code in an architecture I wasn't familiar with. I wrote the code in C and then ran it through the compiler to get it into assembly which I then keyed into the basic monitor program you usually have.

      I've done it just to sanity test a new platform - if you can write a little piece of code that blinks an LED, you can often get a bit of debugging done.

      On one platform, I did it with a JTAG debugger and got it to blink. I then dumped the memory bytes to a file and

    • "Premature optimization is the root of all evil" - Donald Knuth
      • by HiThere ( 15173 )

        And he's (sort of) right. But if you've already written the code in C then it makes sense (if you're CPU limited) to figure out whether the assembler is optimal. The problem is (or was) that different architectures find different approaches to be better. So what you really need is both high level optimization (i.e. algorithm, not code) AND low level optimization (i.e. a good optimizing compiler).

  • Looking back now, I think it's hilarious that computers back then had discrete math coprocessors. I had one too, back in the day.
    • Modern CPUs also have discrete math coprocessors. You can read Linus' rants about AVX512 being so awful for real world workloads because they were designed to beat benchmarks. That pretty much makes them effectively a coprocessor which you want nothing to do with real workloads.
  • nobody remembers the bomb threats towards the conference and the emails implying freedom was the purpose?

  • I especially like Torvalds describing how Linux came about as a terminal emulator for Minix (around 16:30 in the introduction talk):

    ...and then I kind of added features, and soon it was the GNU Emacs of terminal emulators, and I called it Linux.

  • recordings that we all either lived or are this recent matter for what reason? To catch him in a lie or something? What is the point?
  • I attended that lecture and I have a "DEC" Linux CD signed by Linus! I think I knew the DEC employee who brought Linus in.

As of next Thursday, UNIX will be flushed in favor of TOPS-10. Please update your programs.

Working...