LWN: Comments on "Interview with Andrew Tanenbaum (LinuxFr.org)"

Interview with Andrew Tanenbaum (LinuxFr.org)

paulmfoster — Wed, 28 Dec 2011 05:29:40 +0000

Poor Tanenbaum. He just can't get over it.

Still more nonsense...

cmccabe — Mon, 05 Dec 2011 19:07:23 +0000

It looks like that bug was not a Chrome bug, but an Adobe Flash bug.

See http://www.reddit.com/r/netsec/comments/h9vax/is_the_vupe...

> "As usual, security journalists don't bother to fact check. VUPEN
> misunderstood how sandboxing worked in chrome, and only had a flash bug."
> - Tavis Ormandy, Information Security Engineer at Google - via
> http://twitter.com/taviso

It's all about the license... NOT

dag- — Fri, 02 Dec 2011 21:50:07 +0000

I doubt it's only the license. It's also some form of pragmatism and leadership Linus has clearly shown over the years. One can argue about what could have worked, but that's mostly wishful thinking and ignoring many subtleties that can fail any project.

For all I know, if the license was the only factor of success, we would have a thriving Hurd kernel today, right ?

Interview with Andrew Tanenbaum (LinuxFr.org)

wookey — Thu, 01 Dec 2011 10:42:22 +0000

I don't know, but they are all rapidly in the process of getting 32-bit microcontrollers (which is pretty remarkable but seems to be the way the world is headed).

Interview with Andrew Tanenbaum (LinuxFr.org)

butcher — Sat, 26 Nov 2011 17:25:11 +0000

I guess recent research into alternate universes gives anyone the right to credibly postulate what might have been. Maybe Successful Minix exists in the same universe as Evil Kirk and Conniving Spock...

Snarkiness aside, those who have used Linux in some form since the early days know the (in my universe... :) foundations of its success - contributors adding things that others found useful. So IMHO the crux of it probably was, who was more accommodating of others' stuff, AT or LT?

Interview with Andrew Tanenbaum (LinuxFr.org)

dvdeug — Sat, 26 Nov 2011 10:26:20 +0000

One thing AT said at one point about microkernels has long annoyed me. He claimed that one of the advantages of a microkernel was if your filesystem crashed, you could reboot it, and keep on going. In the normal case, if my filesystem crashes, I want my system to be stopped; we need to check the disk to make sure the bugs in the code didn't write trash to the disk before crashing. Moreover, everytime my filesystem crashes, I'm losing data; I don't want my kernel to paper over that, I want my system to start waving red flags so I get it fixed ASAP.

There are strong corellation...

paulj — Fri, 25 Nov 2011 19:13:07 +0000

I like the GCC 'pure' and 'const' function attributes, and to try and get as much of the code as possible filed under such marked functions.

There are strong corellation...

nix — Fri, 25 Nov 2011 17:52:57 +0000

Quite. Writing little bits of procedural programs in functional style remains useful, though, but it's rare that you can write anything substantial in that straitjacket.

Security of verified code

mgedmin — Fri, 25 Nov 2011 04:07:08 +0000

Have you seen the Sig11 FAQ?

Interview with Andrew Tanenbaum (LinuxFr.org)

jwarnica — Thu, 24 Nov 2011 17:29:13 +0000

Is it sad that I keep seeing "AT" and then am left wondering why there is no following "DT"?

Comment #131

pr1268 — Thu, 24 Nov 2011 07:11:56 +0000

What? AST has ugly criticisms of Linux? Gee, I thought he and Linus were on good terms now since they buried the hatchet over that silly flame war back in 1992. Oh, wait! That was before AST got his commercialization grant. So now Linux is a competitive threat to Minix (and Tux is a sworn enemy of that silly raccoon)... Fine. Bring it on, Mr. Raccoon (or whatever your name is).

Minix's "success" (er, lack thereof) might have been all about licensing. If only AST has licensed Minix under the GPL way back in 1991, I could very well be typing this on a Minix box right now instead of a Linux box. Something to ponder...

P.S. If this has already been discussed above, then I'm sorry—please understand that it's way past my bedtime and I'm just a little un-motivated at the moment to scan 130 comments above. But I did feel the need to vent. And, besides, I fully acknowledge that posting comment #131 implies a seriously late arrival to this discussion party.

P.P.S. Actually licensing probably wouldn't have mattered one bit; Linus and AST would have likely still had their nasty debate, and Linux would see development like it did. If AST were really a good academician, then he'd at least acknowledge the commercial and engineering successes of monolithic kernels (not just Linux, but weren't early WinNT kernels monolithic?), instead of pushing his narrow-minded "microkernels are the only way" philosophy. Okay I'm done now. Really.

There are strong corellation...

elanthis — Thu, 24 Nov 2011 05:29:32 +0000

And then there's those of us who don't think that "buy new specialized" hardware is a real solution and develop large, complex, real-time apps for consumers' existing devices, and we are both knowledgable enough and skilled enough to recognize and capitalize on the very imperative nature of actual hardware. We can't stand functional languages, because they model academic nonsense rather than reality. Functional languages work great for little processing scripts or massively scalable data tranformation. They don't work at all for UIs (egads! state changes!) or anything that needs to eck out 60fps on 6 year old consumer-grade hardware.

The trick to being a _real_ programmer has nothing to do with being a functional programming guru or an imperative master or an OOP professor. It had to do with recognizing the right tool for the job and being able to implement maintainable, efficient, usable architectures on whatever that tool is.

Functional languages just aren't that tool in many cases.

Interview with Andrew Tanenbaum (LinuxFr.org)

mpr22 — Wed, 23 Nov 2011 19:19:28 +0000

Well, I said ARM7 because the person I was replying to did. Looks like some nice parts there, I'm pleasantly impressed.

Interview with Andrew Tanenbaum (LinuxFr.org)

andreasb — Wed, 23 Nov 2011 18:03:33 +0000

Why specifically ARM7? ARM7 is pretty old at this point. Cortex-M is what you're looking for when you want ARM microcontrollers and aren't bound by legacy ARM7 software you would have to port. Well okay, they don't have the ARM instruction set as such and understand only Thumb2, but that is in the end mostly just a different encoding of the same instruction set.

If you need low pin count packages then boy did NXP announce some interesting chips for you. How about Cortex-M SoCs in SO20 and TTSOP20? I bet you're just going to love the one in a DIP28.

Seriously, if all you want is under 50 edge pins (something like QFP48) then there's lots of choice in the 32 bit ARM world.

Provably correct hardware not possible

Cyberax — Wed, 23 Nov 2011 15:28:10 +0000

These are defects. Barring really bad design, you can't predict them or use them to reliably exploit something.

Don't make me laugh

mpr22 — Wed, 23 Nov 2011 15:22:03 +0000

I'd liken most recipes to programs in a high-level (hence the abstraction of details), parse-before-execution (you need to read the whole thing before you start doing anything), imperative (it's definitely a sequence of commands, and it's probably written in the imperative) language.

Don't make me laugh

nix — Wed, 23 Nov 2011 14:33:19 +0000

people who are good at programming are also likely to be good at maths. Now that I'm thinking about it, that assumption doesn't seem too sound.

It isn't sound. I'm fairly terrible at mathematical reasoning: I can do it but it feels like wading through treacle. Verbal / linguistic reasoning, by contrast, is utterly effortless. So I web my programs together with skeins of words, not with maths, even though the maths might be shorter or less ambiguous at times.

Don't make me laugh

nye — Wed, 23 Nov 2011 14:14:44 +0000

>*some* people under *some* circumstances, find functional programming easy and inituitive. Mostly people with a strong grasp on math.

Now this is very interesting, because it exposes a hidden assumption I hadn't realised I was making - namely that people who are good at programming are also likely to be good at maths. Now that I'm thinking about it, that assumption doesn't seem too sound.

[Digression follows...]

>Meanwhile, just about everyone, mathematically inclined or not, are already accustomed to complex procedures being described as a series of steps to be performed in sequence. If you've ever followed a recipe to bake cake, or indeed followed instructions to do *anything* you're already familiar with this mode of thinking.

I'm not especially convinced about this. I don't think instructions aimed at humans can really be said to resemble imperative programming more than other styles because they generally don't rigourously break things down into sets of steps and routines - they tend to give instructions out of order[0], make lots of assumptions, elide important steps etc. In some cases, I'd actually say recipes can bear resemblance to a more declarative style.

[0]As an experiment, try following a non-trivial cooking recipe strictly in order; you will most-likely find it doesn't work when you get to a step that says 'transfer immediately to a pre-heated oven', or some step which, taken literally, requires you to have four or more arms.

Provably correct hardware not possible

pjm — Wed, 23 Nov 2011 12:52:53 +0000

> Digital circuitry is _digital_. It's specifically designed to not care about small deviations in voltage levels.

In practice, it's quite common for PC hardware not to behave according to spec (bits flipped in transit): common enough that I've noticed it myself on more than one machine, and common enough that I'm quite surprised that you apparently haven't noticed it.

Interview with Andrew Tanenbaum (LinuxFr.org)

mpr22 — Wed, 23 Nov 2011 10:42:37 +0000

How many pins on a typical ARM7 SoC, and how are they laid out? Because the 16-bit microcontroller has under 50, and they're all at the edge of the part.

Don't make me laugh

ekj — Wed, 23 Nov 2011 08:30:35 +0000

*some* people under *some* circumstances, find functional programming easy and inituitive. Mostly people with a strong grasp on math.

Meanwhile, just about everyone, mathematically inclined or not, are already accustomed to complex procedures being described as a series of steps to be performed in sequence. If you've ever followed a recipe to bake cake, or indeed followed instructions to do *anything* you're already familiar with this mode of thinking.

I suspect your problems, of adapting to a change from functional to imperative, is untypical, my experience has been that most people who can do Lisp, can also do imperative. (whereas the converse is *not* the case)

I don't think it's an accident that functional programming is fairly marginal whereas imperative programming, together with various proportions of OO, runs most things.

Changing paradigms, especially the first time you do it, is always going to be somewhat painful. (but useful, because there's useful lessons to be had from all the major modes of thinking)

Interview with Andrew Tanenbaum (LinuxFr.org)

JanC_ — Tue, 22 Nov 2011 21:49:29 +0000

Once an ARM7 SoC costs not significantly more than a 16-bit PIC (that could also do the job), the flexibility & familiarity of the former for average developers (and thus the cost of development) might be more important for a manufacturer...

There are strong corellation...

khim — Tue, 22 Nov 2011 21:27:13 +0000

Most people who can understand math easily understand functional programming (they may not love it, but they understand it). But people who don't understand math usually just can not "get it".

Sadly most programmers, not just most people fall in this category. Now, it does not mean you can build something for "monkeys" on top of functional language - you can. Problem with managed code is different.

Linux vs BSD

JanC_ — Tue, 22 Nov 2011 21:25:26 +0000

Linus was actually using Minix while developing that terminal client & later the kernel now known as Linux... (The Minix filesystem was also the first Linux filesystem, as Linus needed to be able to read files from his development system's disk.)

Don't make me laugh

mathstuf — Tue, 22 Nov 2011 18:07:35 +0000

Hmm. I was a "math whiz" in grade school, but my first languages were BASIC, TI-BASIC, and C. Haskell ranks among my favorite languages today though. Using functional programming idioms in C++ and Python makes things much nicer there too, IMO.

I'd modify your hypothesis from "first experience of" to instead state "favorite languages for".

Don't make me laugh

mpr22 — Tue, 22 Nov 2011 17:32:07 +0000

It seems likely to me that prior exposure to mathematics, and prior experience of computer use (most user interfaces are effectively imperative), are comparably significant to what language is used for your first experience of computer programming.

Don't make me laugh

nye — Tue, 22 Nov 2011 17:13:04 +0000

>Of course, writing in Lisp requires quite literally PhD-level understanding of algorithms and software design, just like a microkernel

That statement is absurd. I'd love to see a study on learnability of programming paradigms looking at new programmers with no prior experience.

My first programming course (less than ten years ago) used Scheme, which I found immediately understandable, intuitive, and simple to use. Then we went on to do a lot more work in imperative languages, which were a lot harder to get into, but coming back to functional programming everything now seems harder than when it was new because I can't stop myself from wanting to translate everything into a series of discrete steps to perform in order (simplification, but you get the idea).

I think my brain has been permanently damaged by prolonged exposure to imperative languages, but if I hadn't seen functional programming *first* I would never have known that.

Provably correct hardware not possible

Cyberax — Tue, 22 Nov 2011 04:10:39 +0000

Digital circuitry is _digital_. It's specifically designed to not care about small deviations in voltage levels. If one circuit behaves differently from another one then it's a defect, which can in theory be diagnosed during manufacture.

Of course, it's possible that a passing OhMyGod particle would knock your CPU off, but that's outside of range of provable hardware and software.

Provably correct hardware not possible

cmccabe — Mon, 21 Nov 2011 23:54:52 +0000

"As far as the laws of mathematics refer to reality, they are not certain; and as far as they are certain, they do not refer to reality."
- Albert Einstein

Provably correct hardware not possible

jhhaller — Mon, 21 Nov 2011 21:21:51 +0000

While it is possible to have a provably correct hardware design, it is impossible to build hardware which always matches the provably correct design. The design is likely to be based on digital circuits, while the implementation is based on analog circuits made from imperfect materials subject to environmental conditions ranging from cosmic rays to more mundane things like electromigration, thermal stress, and analog artifacts like reflections on transmission lines. What can be designed is something that works like the design most of the time, with deviations detected most of the time. This makes it impossible to depend on provably correct software, which depends on provably correct hardware, which doesn't exist. Some of the deviations may be common to an entire production run, which can be exploited, while others are more random, and the random ones are more difficult to purposefully exploit.

It's not question of contribution - it's question of unification...

cry_regarder — Mon, 21 Nov 2011 14:33:16 +0000

Yes, it certainly does!

Linux vs BSD

spaetz — Mon, 21 Nov 2011 14:23:22 +0000

> Linus couldn't get a cheap Unix-like (or even just a cheap) OS for his new 386.

This motivation is far from certain. Linux started out as a terminal emulator and increasingly got extended until it was a full fledged kernel. It essentially was a research/hobby project, and it is far from certained that it wouldn't have happened if somehand had handed Linux a free Minix CD at that time.

Too much speculation :-)

Interview with Andrew Tanenbaum (LinuxFr.org)

nix — Mon, 21 Nov 2011 12:56:36 +0000

the idea that the equivalent of virtual memory can now be implemented in software, algorithmically

This has been doable for many decades. They called them "overlays". OS/360 had it. Language runtimes on DOS had it (Borland did it for both Pascal and C). Some implementations even added magic proxying so that no code changes were needed (though generally you had to divide your program into overlays by hand).

Interview with Andrew Tanenbaum (LinuxFr.org)

Pawlerson — Mon, 21 Nov 2011 10:47:43 +0000

The reason why bsd has lost the battle is very simple - it has stupid license that disqualifies it completely as a competitor. It seems Tanenbaum can't accept the fact that Linus was right and that's why he's still whining about Linux.

Ah, that again...

khim — Mon, 21 Nov 2011 08:21:49 +0000

To have a secure system you need your hardware to enforce safety. That can be done with the help of architectures with TAL (Typed Assembly Languages) which Azul system essentially is.

Well, Azul hardware systems will be interesting exhibits in Computer History Museum (next to Intel iAPX 432 and LISP machines), I'll grant you that, but I fail to see how these museum pieces are relevant to the discussion.

Define large enough...

Cyberax — Mon, 21 Nov 2011 07:49:18 +0000

Yup. Most (note this!) current implementations of VMs are written in unreliable unmanaged languages so they are not secure. And I wouldn't expect them to be.

To have a secure system you need your hardware to enforce safety. That can be done with the help of architectures with TAL (Typed Assembly Languages) which Azul system essentially is.

In this way you can build the system using safe languages from ground up. And small unsafe parts can be audited to hell and back.

Define large enough...

khim — Mon, 21 Nov 2011 07:34:02 +0000

There are literally no large enough unmanaged systems without buffer exploit vulnerabilities.

And the same is true for managed systems. But security is not binary. Number of successful exploits against JVM and .NET dwarfs the number of successful exploits against memory-managed systems.

So your best case shows that MEMORY PROTECTION WITH UNMANAGED LANGUAGES IS NOT SECURE

No, my best case shows that you can make it secure enough that break-ins will make the news. JVM and .NET-based break-ins are just accepted as "fact of life", even if they make the news they are reported as "oh, well, yet another vulnerability is found and fixed in XXX product". Often they don't make the news at all. If your idea of improving security is to replace poorly behaving system with utterly broken system then I'm glad you are not working here.

Still more nonsense...

Cyberax — Mon, 21 Nov 2011 04:30:32 +0000

Oh, Chrome has been broken multiple times.

http://www.zdnet.com/blog/hardware/google-chrome-pwned-on... - this is a complete pwnage.

'Page local' exploits are even more numerous.

So your best case shows that MEMORY PROTECTION WITH UNMANAGED LANGUAGES IS NOT SECURE and can not be made so with any rational amount of investment. There are literally no large enough unmanaged systems without buffer exploit vulnerabilities.

Counterpoint

man_ls — Sun, 20 Nov 2011 20:26:58 +0000

Yes. Notice that Linus in his seminal message spoke about the Hurd as the competition, not about BSD. And even that "big and professional" kernel did not stop him from starting his pet project. So your point is not too credible, that is my point.

Linux vs BSD

vonbrand — Sun, 20 Nov 2011 20:23:00 +0000

Linus himself said in 1993 that if 386BSD had come out before (0.0 came out in 1992) Linux would never have happened. I did compare roughly contemporary MCC and 386BSD versions from the 1992-1993 timeframe, and 386BSD sure was a much more polished system. I was using 4.1 BSD during my PhD studies in 19984 to 1987, it wasn't exactly a long shot imagining porting most of that to a PC in the starting 1990s. But the lawsuits and concurrent assorted wild claims of infringement did make people somewhat nervous about ending up stranded with BSD, and so looked around for alternatives.