A chip too far? Where is your solution Mr Larkin?

You should also list here what the average price of such a system is (in inflation-adjusted dollars) -- I think you'll find that while the hardware requirements of Windows have increased markedly, the price of the hardware necessary to run it has fallen even more markedly.

As John Larkin points out, when CPU cycles are cheap, there's no good reason to try to get really fancy and save them for "run of the mill" day-to-day operations. This is exactly how software development has proceeded -- what used to be a lot of low-level code in assembly and C is now "very high level" C# or Python or whatever. Of course, now we've hit a bit of a wall -- hence all the discussions about the new methods needing for productively creating software for multi-core computers.

Hardware design hasn't "progressed" as rapidly, but it's certainly still there: 10 years ago, a generic low-speed interface would have been RS-232, right? Now it's USB, which requires perhaps 10,000 times as many transistors to implement as the RS-232 approach, but it's more reliably, faster, and easier to implement (in most cases) than the old approach.

Because if the new software -- bloated or not -- allows their workers to be more productive, if they don't buy it, their competition will.

There's a huge market for OSes and software to run on "low end" hardwre -- the specs of your (horribly power inefficient, BTW) 486 box there are comparable to many, e.g., $50 wireless router boxes on the market today -- a huge market (of which something like 4/5 seem to run Linux, 1/5 run VxWorks, and a few run something obscure.)

I don't really care that much if software is bloated so long as the costs of the hardware to run it at the same or greater productivity level as the last version is dropping. What's much more important to me is how bug-free software is, as a few bad bugs can completely cripple your productivity.

I would admit that there's a strong correlation between bloatware and more bugs, BTW. :-)

---Joel

CP/M? MP/M? Odin?

I actually meant the sourcecode (and therefore the requirement for compilers for those legacy languages going well into the future).

It is possible to emulate almost anything in the legacay hardware vein on a modern desktop PC given enough effort applied to it. VMWare virtuallisation is a nice way to keep such things in a sandbox.

Regards, Martin Brown

Sydex do/did a pretty good CP/M emulator including reading a lot of the old format disks. I expect you can still find it on Simtel.

You can even find emulators for historic mainframes like DEC-10, and ICL George 3 for the PC if you look hard enough. As well as numerous emulators for most popular antique home computers (of various quality).

I don't think any of them provide for a cassette tape input any more so if your programmes are still on that media or Sinclairs ill fated microdrives you are a bit stuck. 8" disk support is getting rarer too.

Regards, Martin Brown

I didn't say that at all. Hand written code has a worryingly high defect rate of about 0.2% (average) and as high as 5% worst case (IBM OS/360 study). So either you have to make every line do more by improving the languages to match specific application domains or weed out the human errors sooner by more sophisticated static code analysis.

Almost every language from the birth of computing with a significant codebase is still going strong more than half a century later. The languages have evolved a bit and standards committees have haggled over the small print but they still exist. And they are still used.

Cobol, Fortran, Algol, Basic, Lisp all have their roots in the late 1950's.

I fully expect new kids on the block like Java and SQL and the various web markup languages to last at least a similar length of time.

If I had to bet how software engineering will evolve in the future then I would say that formal specifications will become more common for mission critical work. Z and VDM that we have now are effective, but very few people can read or work with them and manipulate proofs.

Tools to support them and automatically convert the formal spec to a users view of how the interface will look and from that a conversion to functional code. Every path also has to handle changes and allow proof of correctness to be applied back to the specification. There are research projects trying to do this. It is distinctly non-trivial.

And yet again you quietly snip away the embarrassing failure of the Transputer and Occam which followed your proposed massively parallel hardware route though expensively and somewhat ahead of its time.

Regards, Martin Brown

On a sunny day (Wed, 20 Aug 2008 00:57:46 +0000) it happened Guy Macon wrote in :

I dunno about Vista, I think much encrypt /decrypt stuff for 'security' eats cycles in it.

True, I use 'joe' (should be on your Slackware system) as text editor, even to write this (it is called from the news reader). In an xterm, now compare that to MS-Word bloat... 'joe' is faster, cheaper (free), better (more efficient).

Ah, have an old 486 in the attic, but it has lost it power supply. hard disk, floppy drive.... But Slackware was very good when it ran on it.

Remember 'Slackware' is one man's work, maybe that is why.

I run grml

The main issue with 'new features' that requires more processor power, is HD video editing and processing, never enough speed. The multimedia PC is what people want, to edit the footage they shoot with their Canon HV20 cameras. The masses need ever more computing power for that, your 486 will not be able to cope.

Since that wikipedia page mentions C, Ada, Fortran and Pascal compilers by Inmos for their transputers, I wonder if there were any lessons learned then that could be used today. But I it looks like those compilers didn't have any automatic parallelization of anything, so I suppose they weren't that different than what threads provide today.

Hmm, I wonder if there are any consumer priced motherboards like that? Some retro computers implemented with FPGAs exist, but they don't exactly have 3 GHz C2Ds as the main CPU... More interesting FPGA boards tend to be a little pricey, like the Xilinx ML-505, which is shaped so that it can fit in an x4 PCIe slot.

Correction: I run all such legacy x86 PC applications in VMWare virtual machines under the x86 PC OS that they work best under, thus letting me choose the best main x86 PC OS available without regard to backwards compatibility.

I prefer to run CP/M applications on my Commodore 128, but emulators are available that allow it to run under a x86 PC OS.

On a sunny day (Wed, 20 Aug 2008 15:27:36 +0300) it happened Anssi Saari wrote in :

Well, 'mass production' will help... A Stratix 4 with 680k logic elements in quantities that we see for PC sales would perhaps be possible. What needs to be invented is a way to interface it to the CPU and rest of the system, in such a way that each program can reserve and use some of those gates at the same time. Lots of IO I'd imagine. Yes PCIe boards exist, I like this picture too:

There is a whole lot of issues to be solved, clock domains, what not, but at least the FPGA approach should increase speed. It is a proven concept... unlike using n cores on sequential code...

SMOP.

I have not proposed a "massively parallel hardware route". I have observed that most CPU makers are going multicore, and that hundreds of cores, and maybe 1000 threads, will be available soon. And I have speculated on how that might affect OS design and programming. What's remarkable to me is how entrenched the current bloated and broken programming models are in the minds of programmers. Virtually everyone has responded to my speculations by telling me how good things are now, and how things will not change. So much for "design."

As far as failed architectures go, lots of good stuff didn't make it.

John

On a sunny day (Wed, 20 Aug 2008 07:53:03 -0700) it happened John Larkin wrote in :

Not to be so in envy, You can learn C too, it is a beautiful language:

// test.c #include #include

int main(int argc, char **argv) { #define SMART 10 #define c_programmer SMART int he;

for(he = 0; he

Here's what Charles Wenzel did: (a beautiful story, but top-posted. Start at bottom.)

Cheers, James Arthur

On a sunny day (Wed, 20 Aug 2008 08:38:48 -0700 (PDT)) it happened James Arthur wrote in :

No, 'I never touched the command line' is WRONG. Recently somebody at IBM, in command of the Linux stuff, stated: 'Do not immitate MS windows'.

A lot of GUI stuff is just screening you from the simple basic computer interface that the command line provides.

For example, what will be faster: Typing firefox in an xterm, or finding it in a file browser, and then clicking on it. OK, maybe you have a Firefox icon on your desktop. But you know, there are thousands of commands, and you cannot possibly have them all as icon on the desktop. So if I type route or uptime or ls -rtl or basically _ANY_ Unix command, like for example invoking a text editor joe mytext.txt Then I am thousands of times faster then somebody searching trough file menus.

Maybe the reason Suse is in bed with MS (and now recently even more egain), is that both use bloat. Suse uses KDE, KDE is based on Trolltech's Qt. Qt-4 is an example of bloat.

The command line provides an English speaking interface to your computer, can easily be coupled to speech recognition too.

MS wants to make people into dumb mouse clickers, preventing them to understand the computer, binding them to their weird interface.

It's getting harder and harder to justify Win__ for technical stuff; it's so cumbersome; slow.

Years ago I gasped at the inefficient code output by Microsoft QuickBasic, needlessly stacking a load of registers and constants, then calling functions to do simple math (very slow operations on the 8088). Repeat. I re-wrote some tight-loop stuff in assembly. An all-integer FFT, I think.

Then I traced the system calls--OMG, a new height in useless cycle-burning. Maybe 1% efficient.

QuickBasic 4.0's still a great compiler for the user though; good debugging, nimble response, full access to graphics and the hardware.

Fast forwarding to today, I just wrote a simulator for a stepper+driver+tricks. It runs faster on the Win3.11 computer I used writing it than on my 2.5GHz P-IV WinXP machine. Roughly a 100x increase in CPU, for a net decrease in performance.

Thanks again Bill!

Cheers, James Arthur

Autodesk did the same to us, sicced a lawyer on us demaning that we prove we weren't abusing their license rules. They sure cured us of ever buying Autocad products again.

John

SMOP.

I suspect that what will happen is that most of the spare CPUs will sit idle because there is not enough for them to do. And then people will stop buying new computers when there is no compelling reason to do so. CPU makers and OS developers will get burned badly. Essentially we are seeing the endgame of Moores Law playing out in the marketplace.

Clock speed increases on a single CPU made marketing trivial. Now they will really have to work hard at persuading the sheeple to buy new kit every couple of years.

Yes you can have a much faster performance for the right problem using a multicore chip. But unless you do have the right problem then it is a waste. The extra security you believe comes from every thread in its own CPU is largely illusary - particularly if they share any external memory or cache. Virtualisation can acheive the same end result.

N remarkable to me is how entrenched the current bloated and broken

That is because your speculations are wildly inaccurate.

Their turn will come again. VAX was fabulous. Although I at least partially blame their VT100 on screen editors for the 25 line coherence length of a lot of modern programmers.

Cutting edge reliablity stuff developed by the likes of Praxis using a subset of Ada for high integrity work is still one route that offers promise. Not everything in the world is allowed to BSOD on a daily basis.

I think you blame C far too much for all of our ills. It is no worse than any other macro assembler and only marginally more cryptic.

BCPL was a much stranger vaguely related precursor to C - though it had some nice features you could really shoot yourself in the foot with it.

Regards, Martin Brown

On a sunny day (Wed, 20 Aug 2008 15:27:36 +0300) it happened Anssi Saari wrote in :

IDF: QuickAssist-Coprozessoren mit Altera-Stratix-FPGAs In German:

Now 100 times sounds good, how many extra cores would that not take if at all possible? English: