4 ms·

Linus' and Alan's citations aren't incompatible. Actually, I think they're both true. Yes, massively parallel trial-and error works wonders, but if you favour

Linus' and Alan's citations aren't incompatible. Actually, I think they're both true. Yes, massively parallel trial-and error works wonders, but if you favour the first solutions, you'll often miss the best ones. Actually, effects such as first time to market, backward compatibility, or network effects often trump intrinsic quality by a wide margin. (Hence X86's dominance on the desktop.) Yes, Worse is better than Dead. But the Right Thing dies because Worse is Better eats its lunch. Even when Worse actually becomes Better, that's because it has more resources to correct itself. Which is wasteful. The only solution I can think of to solve this comes from the STEPS project, at http://vpri.org http://vpri.org : extremely late binding. That is, postpone decisions as much as you can. When you uncover your early mistakes, you stand a chance at correcting them, and deploying the corrections. Taking Wintel as an example, that could be done by abstracting away the hardware. Require programs to be shipped as some high level bytecode, that your OS can then compile, JIT, or whatever, depending on the best current solution. That makes your programs dependent on the OS, not on the hardware. Port the compiling stack of your OS, and you're done. If this were done, Intel wouldn't have wasted so much resources in its X86 architecture. It would have at least stripped the CISC compatibility layer over it's underlying RISC design. But of course, relying on programmers to hand-craft low-level assembly would (and did) make you ship faster systems, sooner.

icebraining 14y ago
Debian runs on many architectures without being slowed by bytecode JITs. I'd say that's a technically better solution.
- lnanek2 14y ago
  Yes, but the software has to be compiled to the architecture too using that solution. So it is just putting the problem on to others: the users, the software developers, etc. - many of whom will happily just use something else.
  - derleth 14y ago
    > the software has to be compiled to the architecture too using that solution Right. Which is why Debian has a package management system. Most people never have to compile any of the software they use.
- artsrc 14y ago
  JIT compilation of bytecode is only one option. There are others: http://en.wikipedia.org/wiki/IBM_System_i http://en.wikipedia.org/wiki/IBM_System_i The Debian ecosystem exists in the context on a more pervasive network than existed for DOS.
greenyoda 14y ago
"Taking Wintel as an example, that could be done by abstracting away the hardware. Require programs to be shipped as some high level bytecode, that your OS can then compile, JIT, or whatever, depending on the best current solution. That makes your programs dependent on the OS, not on the hardware. Port the compiling stack of your OS, and you're done. If this were done, Intel wouldn't have wasted so much resources in its X86 architecture." Unfortunately, that could have only happened in an alternate universe in which humans had developed more advanced technology by the 1980s. At the time Windows and the Intel x86 architecture were being developed (Windows 1.0 was released in 1985), computers did not have the speed or the memory to add another layer of abstraction. From http://en.wikipedia.org/wiki/Windows_1.0 http://en.wikipedia.org/wiki/Windows_1.0: "The system requirements for Windows 1.01 constituted CGA/HGC/EGA (listed as 'Monochrome or color monitor'), MS-DOS 2.0, 256 kB of memory or greater, and two double-sided disk drives or a hard drive." Yes, that's 256 KILO bytes. And a double-sided disk drive (5.25" floppy disk) was at most 1.2MB. The Intel 80386, the first 32-bit member of the x86 family, was released in 1985, so Windows had to be developed on and run on the 16-bit 80286. And it had to run all the old MS-DOS programs that were written in assembler, if Microsoft wanted to retain its existing customers. There were hardly any layers of abstraction to be had in those days. The OS kernel (MS-DOS) was still being written in hand-optimized assembler. The subsequent history of the x86 product line was determined by the requirement that object code had to be backward compatible. Which brought us to what we have today.
- loup-vaillant 14y ago
  > Unfortunately, that could have only happened in an alternate universe in which humans had developed more advanced technology by the 1980s. I agree. Too bad. > The subsequent history of the x86 product line was determined by the requirement that object code had to be backward compatible. Of course. My point is, this sucks. Collectively, we could have done much better much sooner, but our current organization scheme (mostly free market) compels us to do otherwise.
  - nasmorn 14y ago
    We are talking about the fastest spread pf a truly disruptive technology in the history of mankind prior to mobile communications. Why was anything too slow.
DenisM 14y ago
Another option is to design for easy migration, that is easy technically and business-wise. For example, iOS programs are native code, but if Apple decided to do switchearoo and use a different instruction set CPU such as x64 they can do that with relative ease: ship new Xcode, ask developers to recompile and produce fat binaries (current binaries are already fat - arm v6 and arm v7, so the foundation is laid out already), and developers will have been around and motivated to recompile becuase of the financial incentive of new sales. Where old developer is not around, competition is sure to spring up because the market place makes it easier for demand to elicit supply. So combination of technical and business decisions created situation where Apple can switch CPU if they need to. This clearly stems from their previous experience of switching from Motorola to PPC and from PPC to x86. Similarly, when designing a database I try to keep in mind that I will have to redo it, so I try to avoid irreversible operations and instead strive to preserve original data in my schema, so that I can always recompute all destructive operations (such as aggregates) later, even if the set of such operation changes over time.
- loup-vaillant 14y ago
  Works, but some programs will be orphaned, and thus won't be recompiled. Plus, this is an effort that could have been avoided through a more future-proof approach.
  - DenisM 14y ago
    It's ok for apps to be orphaned - when a healthy developer ecosystem is in place then a replacement will be coded to meet any substantial demand. And the effort could not be avoided - you can only trade present effort for future effort, that is more work put upfront into CPU design vs more work later on to convince developers to recompile the apps. The problem with the former is that you make all the effort and still don't get the flexibility, whereas in the latter case the extra flexibility can can in handy in more ways that one, and some of which we cannot foresee today. Code for flexibility, I say.
sedachv 14y ago
> Taking Wintel as an example, that could be done by abstracting away the hardware. Require programs to be shipped as some high level bytecode, that your OS can then compile, JIT, or whatever, depending on the best current solution. That makes your programs dependent on the OS, not on the hardware. Port the compiling stack of your OS, and you're done. A much better idea is already practiced as the most successful method of software distribution ever: JavaScript, or as I call it, source-only distribution.

icebraining 14y ago

Debian runs on many architectures without being slowed by bytecode JITs. I'd say that's a technically better solution.

lnanek2 14y ago
Yes, but the software has to be compiled to the architecture too using that solution. So it is just putting the problem on to others: the users, the software developers, etc. - many of whom will happily just use something else.
- derleth 14y ago
  > the software has to be compiled to the architecture too using that solution Right. Which is why Debian has a package management system. Most people never have to compile any of the software they use.
artsrc 14y ago
JIT compilation of bytecode is only one option. There are others: http://en.wikipedia.org/wiki/IBM_System_i http://en.wikipedia.org/wiki/IBM_System_i The Debian ecosystem exists in the context on a more pervasive network than existed for DOS.

greenyoda 14y ago

"Taking Wintel as an example, that could be done by abstracting away the hardware. Require programs to be shipped as some high level bytecode, that your OS can then compile, JIT, or whatever, depending on the best current solution. That makes your programs dependent on the OS, not on the hardware. Port the compiling stack of your OS, and you're done. If this were done, Intel wouldn't have wasted so much resources in its X86 architecture." Unfortunately, that could have only happened in an alternate universe in which humans had developed more advanced technology by the 1980s. At the time Windows and the Intel x86 architecture were being developed (Windows 1.0 was released in 1985), computers did not have the speed or the memory to add another layer of abstraction. From http://en.wikipedia.org/wiki/Windows_1.0 http://en.wikipedia.org/wiki/Windows_1.0: "The system requirements for Windows 1.01 constituted CGA/HGC/EGA (listed as 'Monochrome or color monitor'), MS-DOS 2.0, 256 kB of memory or greater, and two double-sided disk drives or a hard drive." Yes, that's 256 KILO bytes. And a double-sided disk drive (5.25" floppy disk) was at most 1.2MB. The Intel 80386, the first 32-bit member of the x86 family, was released in 1985, so Windows had to be developed on and run on the 16-bit 80286. And it had to run all the old MS-DOS programs that were written in assembler, if Microsoft wanted to retain its existing customers. There were hardly any layers of abstraction to be had in those days. The OS kernel (MS-DOS) was still being written in hand-optimized assembler. The subsequent history of the x86 product line was determined by the requirement that object code had to be backward compatible. Which brought us to what we have today.

loup-vaillant 14y ago
> Unfortunately, that could have only happened in an alternate universe in which humans had developed more advanced technology by the 1980s. I agree. Too bad. > The subsequent history of the x86 product line was determined by the requirement that object code had to be backward compatible. Of course. My point is, this sucks. Collectively, we could have done much better much sooner, but our current organization scheme (mostly free market) compels us to do otherwise.
- nasmorn 14y ago
  We are talking about the fastest spread pf a truly disruptive technology in the history of mankind prior to mobile communications. Why was anything too slow.

DenisM 14y ago

Another option is to design for easy migration, that is easy technically and business-wise. For example, iOS programs are native code, but if Apple decided to do switchearoo and use a different instruction set CPU such as x64 they can do that with relative ease: ship new Xcode, ask developers to recompile and produce fat binaries (current binaries are already fat - arm v6 and arm v7, so the foundation is laid out already), and developers will have been around and motivated to recompile becuase of the financial incentive of new sales. Where old developer is not around, competition is sure to spring up because the market place makes it easier for demand to elicit supply. So combination of technical and business decisions created situation where Apple can switch CPU if they need to. This clearly stems from their previous experience of switching from Motorola to PPC and from PPC to x86. Similarly, when designing a database I try to keep in mind that I will have to redo it, so I try to avoid irreversible operations and instead strive to preserve original data in my schema, so that I can always recompute all destructive operations (such as aggregates) later, even if the set of such operation changes over time.

loup-vaillant 14y ago
Works, but some programs will be orphaned, and thus won't be recompiled. Plus, this is an effort that could have been avoided through a more future-proof approach.
- DenisM 14y ago
  It's ok for apps to be orphaned - when a healthy developer ecosystem is in place then a replacement will be coded to meet any substantial demand. And the effort could not be avoided - you can only trade present effort for future effort, that is more work put upfront into CPU design vs more work later on to convince developers to recompile the apps. The problem with the former is that you make all the effort and still don't get the flexibility, whereas in the latter case the extra flexibility can can in handy in more ways that one, and some of which we cannot foresee today. Code for flexibility, I say.

sedachv 14y ago

> Taking Wintel as an example, that could be done by abstracting away the hardware. Require programs to be shipped as some high level bytecode, that your OS can then compile, JIT, or whatever, depending on the best current solution. That makes your programs dependent on the OS, not on the hardware. Port the compiling stack of your OS, and you're done. A much better idea is already practiced as the most successful method of software distribution ever: JavaScript, or as I call it, source-only distribution.