Liam on Linux

A HN poster questioned the existence of 80286 computers with VGA displays.

In fact the historical link between the 286 and VGA are significant and represent one of the most important events in the history of x86 computers.

The VGA standard, along with PS/2 keyboard and mouse ports, 1.4MB 3.5" floppies, and even 72-pin SIMMs, was introduced with IBM's PS/2 range of computers in 1987.

The original PS/2 range included:

• Model 50 -- desktop 286.

• Model 60 -- tower 286.

• Model 70 -- desktop 386DX.

• Model 80 -- tower 386DX. (I still have one. One of the best-built PCs ever made.)

All had the Microchannel (MCA) expansion bus, and VGA as standard.

Note, I am not including the Model 30, as it wasn't a true PS/2: no MCA, and no VGA, just MCGA.

IBM promised buyers that they would be able to run the new OS/2 operating system it was working on with Microsoft at the time.

This is the reason why IBM insisted OS/2 must run on the 286: to provide it to the many tens of thousands of customers it had sold 286 PS/2 machines to.

Microsoft wanted to make OS/2 specific to the newer 32-bit 386 chip. This had hardware-assisted multitasking of 8086 VMs, meaning the new OS would be able to multitask DOS apps with excellent compatibility.

But IBM had promised customers OS/2 and IBM is the sort of company that takes such promises seriously.

So, OS/2 1.x was a 286 OS, not a 386 OS. That meant it could only run a single DOS session and compatibility wasn't great.

This is why OS/2 flopped. That in turn is why MS developed Windows 3, which could multitask DOS apps, and was a big hit. That is why MS had the money to headhunt the MICA team from DEC, headed by Dave Cutler, and give them Portable OS/2 to finish. That became OS/2 NT (because it was developed on Intel's i860 RISC chip, codenamed N-Ten.) That became Windows NT.

That is why Windows ended up dominating the PC industry, not OS/2 (or DESQview/X or any of the other would-be DOS enhancements or replacements).

Arguably, although I admit this is reaching a bit, that's what led to the 386SX, and later to VESA local bus computers, and Win95 and a market of VGA-equipped PCI machines: the fertile ground in which Linux took root and flourished.

PCs got multitasking combined with a GUI because of Windows 3 and its successors. (It's important to note that there were lots of text-only multitasking OSes for PCs: DR's Concurrent DOS, SCO Xenix, QNX, Coherent, TSX-32, PC-MOS, etc.) The killer feature was combining DOS, a GUI, and multitasking of DOS apps. That needed a 386SX or DX.

These things only happened because OS/2 failed, and OS/2 failed because there were lots of 286-based PS/2 machines and IBM promised OS/2 on them.

The 286 and VGA went closely together, and indeed, IBM later made the ISA-bus "PS/2" Model 30-286 in response to the relatively failure of MCA.

It was a pivotal range of computers and it sealed the future of the PC industry long after PS/2s themselves largely disappeared. They were a hugely important range of computers, and they introduced the standards that dominated the PC world throughout the 1990s and into the 2000s: PS/2 ports, VGA sockets, 72-pin RAM, 1.4MB floppies etc. Only the expansion bus and the planned native OS failed. All the external ports, connectors, media and so on became the new industry standards.               

A short extract of Neal Stephenson's seminal essay has been doing the rounds on HackerNews.


OK, fine, so let's go with it.

Since my impression is that HN people are [a] xNix fans [b] often quite young therefore [c] have little exposure to other OSes, let me try to unpack what Stephenson was getting at, in context.

The Hole Hawg is a dangerous and overpowered tool for most non-professionals. It is big and heavy. It can take on big tough jobs with ease, but its size and its brute power mean that it is not suitable for precision work. It has relatively few safety features, so that if used inexpertly, it will hurt its operator.

DIY stores are full of smaller, much less powerful tools. This is for good reasons:

• because for non-professional users, those smaller, less-powerful tools are much safer. A company which sells a tool to untrained users which tends to maim or kill them will go out of business.


• because smaller, less-powerful tools are better for smaller jobs, that a non-professional might undertake, such as hanging a picture, or putting up some shelves.


• professionals know to use the right tool for the job. Surgeons do not operate with chainsaws (even though they were invented for surgery). Carpenters do not use axes.

The Hole Hawg, as described, is a clumsy tool that needs things attached to it in order to be used, and even then, you need to know the right way or it will hurt you.

Compare with a domestic drill with a pistol grip that is ready to use out of its case. Modern ones are cordless, increasing their convenience.

One is a tool for someone building a house; the other is a better tool for someone living in that house.

That's the drill part.

Now, let's discuss the OSes talked about in the rest of the 1999 piece from which that's a clipping [PDF].

There are:

• Linux, before KDE, with no free complete desktop environments yet;


• Windows, meaning Windows 98SE or NT 4;


• Classic MacOS – version 9;


• BeOS.

Stephenson points out that Linux is as powerful as any of them, cheaper, but slower, ugly and unfriendly.

He points out that MacOS 9 is as pretty, friendly, and comprehensible as OSes get, but it doesn't multitask well, it is not very stable, and when a program crashes, your entire computer probably goes with it.

He points out that Windows is overpriced, performs poorly, and is not the best option for anyone – but that everyone runs it and most people just conform with what the mainstream does.

He praises BeOS very highly, which was 100% justified at the time: it was faster than anything else, by a large margin. It has superb multimedia support and integration, better than anything else at the time. It was standards-compliant but not held back by it. For its time, it has a supermodern OS, eliminating tonnes of legacy cruft.

But it didn't have many apps so it was mainly for people in narrow niches, such as music production or maybe video editing.

It was manifestly the future, though. But we're living in the future and it wasn't. This was 23 years ago, nearly a quarter of a century, before KDE and GNOME, before Windows XP, before Mac OS X. You need to know that.

What Unix people interpret as praise here is in fact criticism.

That Unix is very unfriendly and can easily hurt its user. (Think `rm -rf /` here.)

That Unix has a great deal of raw power but maybe more than most people need.

That Unix is, frankly, kinda ugly, and only someone who doesn't care about appearances would choose it.

That something of this brute power is not suitable for fine precision work. (Which it still mostly isn't -- Mac OS X is Unix, tuned and polished, and that's what the creative pros use now.)

Here's a response from 17 years ago.

EDIT: this post has attracted discussion and comments on various places, and some people are disputing its accuracy. So, I've decided to make some edits to try to clarify things.

When Windows 2 was launched, there were two editions: Windows, and Windows/386.

The ordinary "base" edition of Windows 2.0x ran on an XT-class computer: that is, an Intel 8088 or 8086 CPU. These chips can only directly access a total of 1MB of memory, of which the highest 384kB was reserved for ROM and I/O: so, a maximum 640kB of RAM. That was not a lot for Windows, even then. But both DOS and Windows 2.x did support expanded memory (Lotus-Intel-Microsoft-specification EMS). I ran Windows 2 on 286s and 386s at work, and on 386 machines I used Quarterdeck's QEMM386 to turn the extended memory that Windows 2 couldn't see or use into expanded memory that it could.

The Intel 80286 could access up to 16MB of memory. But all except the first 640kB was basically invisible to DOS and DOS apps. Only native 16-bit programs could access it, and there barely were any — Lotus 1-2-3 r3 was one of the few, for instance.

There was one exception to this: due to a bug the first 64kB of memory above 1MB (less 16 bytes) could be accessed in DOS's Real Mode. This was called the High Memory Area (HMA). 64kB wasn't much even then, but still, it added 10% to the amount of usable memory on a 286. DOS 3 couldn't do anything with this – but Windows 2 could.

Windows 2 and 2.01 were not successful, but some companies did release applications for them – notably, Aldus' PageMaker desktop publishing (DTP) program. So, Microsoft put out some bug-fix releases: I've found traces of 2.01, 2.03, 2.11 and finally 2.12.

When Windows 2.1x was released, MICROS~1 did a little re-branding. The "base" edition of Windows 2.1 was renamed Windows/286. In some places, Microsoft itself claims that this was a special 286 edition of Windows 2 that ran in native 80286 mode and could access all 16MB of memory.

But some extra digging by people including Mal Smith has uncovered evidence that Windows/286 wasn't all it was cracked up to be. For one thing, without the HIMEM.SYS driver, it runs perfectly well on 8088/8086 PCs – it just can't access the 64kB HMA. Microsoft long ago erased the comments to Raymond Chen's blog post, but they are on the Wayback Machine.

So the truth seems to be that Windows/286 didn't really have what would later be called Standard Mode and didn't really run in the 286's protected mode. It just used the HMA for a little extra storage space, giving more room in conventional memory for the Windows real-mode kernel and apps.

So, what about Windows/386?

The new 80386 chip had an additional mode on top of 8/16-bit (8088/8086-compatible) and fully-16-bit (80286-compatible) modes. The '386 had a new 32-bit mode – now called x86-32 – which could access a vast 4GB of memory. (In 1985 or so, that would have cost hundreds of thousands of dollars, maybe even $millions.)

However, this was useless to DOS and DOS apps, which could still only access 640kB (plus EMS, of course).

But Intel learned from the mistake of the 286 design. The 286 needed new OSes to access all of its memory, and even they couldn't give DOS apps access to that RAM.

The 386 "fixed" this. It could emulate, in hardware, multiple 8086 chips at once and even multitask them. Each got its own 640kB of RAM. So if you had 4MB of RAM, you could run 6 separate full-sized DOS sessions and still have 0.4MB left over for a multitasking OS to manage them. DOS alone couldn't do this!

There were several replacement OSes to allow this. At least one of them is now FOSS -- it's called PC-MOS 386.

Most of these 386 DOS-compatible OSes were multiuser OSes — the idea was you could plug some dumb terminals into the RS-232 ports on the back of a 386 PC and users could run text-only DOS apps on the terminals.

But some were aimed at power users, who had a powerful 386 PC to themselves and wanted multitasking while keeping their existing DOS apps.

My personal favourite was Quarterdeck DESQview. It worked with the QEMM386 memory manager and let you multitask multiple DOS apps, side by side, either full-screen or in resizable windows. It ran on top of ordinary MS-DOS.

Microsoft knew that other companies were making money off this fairly small market for multitasking extensions to DOS. So, it made a third special edition of Windows 2, called Windows/386, which supported 80386 chips in 32-bit mode and could pre-emptively multitask DOS apps side-by-side with Windows apps.

Windows programs, including the Windows kernel itself, still ran in 8086-compatible Real Mode and couldn't use all this extra memory, even on Windows/386. All Windows/386 did was provide a loader that converted all the extra memory above 1MB in your high-end 386 PC – that is, extended (XMS) memory – into expanded (EMS) memory that both Windows and DOS programs could use.

The proof of this is that it's possible to launch Windows/386 on an 8086 computer, if you bypass the special loader. Later on, this loader became the basis of the EMM386 driver in MS-DOS 4, which allowed DOS to use the extra memory in a 386 as EMS.

TBH, Windows/386 wasn't very popular or very widely-used. If you wanted the power of a 386 with DOS apps, then you probably were fine with or even preferred text-mode stuff and didn't want a GUI. Bear in mind this is long before graphics accelerators had been invented. Sure you could tile several DOS apps side-by-side, but then you could only see a little bit of each one -- VGA cards and monitors only supported 640×480 pixels. Windows 2 wasn't really established enough to have special hi-res superVGA cards available for it yet.*

Windows/386 could also multitask DOS apps full-screen, and if you used graphical DOS apps, you had to run them full-screen. Windows/386 couldn't run graphical DOS apps inside windows.

But if you used full-screen multitasking, with hotkeys instead of a mouse, then why not use something like DESQview anyway? It used way less disk and memory than Windows, and it was quicker and had no driver issues, because it didn't support any additional drivers.

The big mistake MS and IBM made when they wrote OS/2 was that they should have targeted the 386 chip, instead of the 286.

Microsoft knew this – it even had a prototype OS/2 1 for 386, codenamed "Sizzle" and "Football" – but IBM refused because when it sold thousands of 286 PS/2 machines it had promised the customers OS/2 for them. The customers didn't care, they didn't want OS/2, and this mistake cost IBM the entire PC industry.

If OS/2 1 had been a 386 OS it could have multitasked DOS apps, and PC power users would have been all over it. But it wasn't, it was a 286 OS, and it could only run 1 DOS app at a time. For that, the expensive upgrade and extra RAM you needed wasn't worth it.

So OS/2 bombed. Windows 2 bombed too. But MS was so disheartened by IBM's intransigence, it went back to the dead Windows 2 product, gave it a facelift with the look-and-feel stolen from OS/2 1.2, and they used some very clever hacks to combine the separate Windows (i.e. 8086), Windows/286 and Windows/386 programs all into a single binary product. The WIN.COM loader looked at your system spec and decided whether to start the 8086 kernel (KERNEL.EXE), 286 kernel (DOSX.EXE) or the 386 kernel (WIN386.EXE).

If you ran Windows 3 on an 8086 or a machine with only 640kB (i.e. no XMS), you got a Real Mode 8086-only GUI on top of DOS.

If you ran Win3 on a 286 with 1MB-1¾MB of RAM then it launched in Standard Mode and magically became a 16-bit DOS extender, giving you access to up to 16MB of RAM (if you were rich and crazy eccentric).*

If you ran W3 on a 386 with 2MB of RAM or more, it launched in 386 Enhanced Mode and became a 32-bit multitasking DOS extender and could multitask DOS apps, give you virtual memory and a memory space of up to 4GB.

All in a single product on one set of disks.

This was revolutionary, and it was a huge hit...

And that about wrapped it up for OS/2.

Windows 3.0 was very unreliable and unstable. It often threw what it called an Unrecoverable Application Error (UAE) – which even led to a joke T-shirt that said "I thought UAE was a country in Arabia until I discovered Windows 3!"... but when it worked, what it did was amazing for 1990.

Microsoft eliminated UAEs in Windows 3.1, partly by a clever trick: it renamed the error to "General Protection Fault" (GPF) instead.

Me, personally, always the contrarian, I bought OS/2 2.0 with my own money and I loved it. It was much more stable than Windows 3, multitasked better, and could do way more... but Win3 had the key stuff people wanted.

Windows 3.1 bundled the separate Multimedia Extensions for Windows and made it a bit more stable. Then Windows for Workgroups bundled all that with networking, too!

Note — in the DOS era, all apps needed their own drivers. Every separate app needed its own printer drivers, graphics drivers (if it could display graphics in anything other than the standard CGA, EGA, VGA or Hercules modes), sound drivers, and so on.

One of WordPerfect's big selling points was that it had the biggest and best set of printer drivers in the business. If you had a fancy printer, WordPerfect could handle it and use all its special fonts and so on. Quite possibly other mainstream offerings couldn't, so if you ran WordStar or MultiMate or something, you only got monospaced Courier in bold, italic, underline and combinations thereof.

This included networking. Every network vendor had their own network stack with their own network card drivers.

And network stacks were big and each major vendor used their own protocol. MS used NetBEUI, Novell used IPX/SPX, Apple used AppleTalk, Digital Equipment Corporation's PATHWORKS used DECnet, etc. etc. Only weird, super-expensive Unix boxes that nobody could afford used TCP/IP.

You couldn't attach to a Microsoft server with a Novell network stack, or to an Apple server with a Microsoft stack. Every type of server needed its own unique special client.

This basically meant that a PC couldn't be on more than one type of network at once. The chance of getting two complete sets of drivers working together was next to nil, and if you did manage it, there'd be no RAM left to run any apps anyway.

Windows changed a lot of things, but shared drivers were a big one. You installed one printer driver and suddenly all your apps could print. One sound driver and all your apps could make noises, or play music (or if you had a fancy sound card, both!) and so on. For printing, Windows just sent your printer a bitmap — so any printer that could print graphics could suddenly print any font that came with Windows. If you had a crappy old 24-pin dot-matrix printer that only had one font, this was a big deal. It was slow and it was noisy but suddenly you could have fancy scalable fonts, outline and shadow effects!

But when Microsoft threw networking into this too, it was transformative. Windows for Workgroups broke up the monolithic network stacks. Windows drove the card, then Windows protocols spoke to the Windows driver for the card, then Windows clients spoke to the protocol.

So now, if your Netware server was configured for AppleTalk, say — OK, unlikely, but it could happen, because Macs only spoke AppleTalk — then Windows could happily access it over AppleTalk with no need for IPX.

The first big network I built with Windows for Workgroups, I built dual-stack: IPX/SPX and DECnet. The Netware server was invisible to the VAXen, and vice versa, but WfWg spoke to both at once. This was serious black magic stuff.

This is part of why, over the next few years, TCP/IP took off. Most DOS stuff never really used TCP/IP much — pre-WWW, very few of us were on the Internet. So, chaos reigned. WfWg ended that. It spoke to everything through one stack, and it was easy to configure: just point-and-click. Original WfWg 3.1 didn't even include TCP/IP as standard: it was an optional extra on the disk which you had to install separately. WfWg 3.11 included 16-bit TCP/IP but later Microsoft released a 32-bit TCP/IP stack, because by 1994 or so, people were rolling out PC LANs with pure IP.

---

* Disclaimer: this is a slight over-simplification for clarity, one of several in this post. A tiny handful of SVGA cards existed, most of which needed special drivers, and many of which only worked with a tiny handful of apps, such as one particular CAD program, or the GEM GUI, or something obscure. Some did work with Windows 2, but if they did, they were all-but unusable because Windows 2's core all had to run in the base 640kB of RAM and it very easily ran out of memory. Windows 3 was not much better, but Windows 3.1 finally fixed this a bit.

So if you had an SVGA card and Windows/286 or Windows/386 or even Windows 3.0, you could possibly set some super-hires mode like 1024×768 in 16 colours... and admire it for whole seconds, then launch a few apps and watch Windows crash and die. If you were in something insane like 24-bit colour, you might not even get as far as launching a second app before it died.

Clarification for the obsessive: when I said 1¾MB, that was also a simplification. The deal was this:

If you had a 286 & at least 1MB RAM, then all you got was Standard Mode, i.e. 286 mode. More RAM made things a little faster – not much, because Windows 2 didn't have a disk cache, relying on DOS to do that. If you had 2 MB or 4 or 8 or 16 (not that anyone sane would put 16MB in a 286, as it would cost $10,000 or something) it made no odds: Standard Mode was all a 286 could do.

If you had a 386 and 2MB or more RAM, you got 386 Enhanced Mode. This really flew if you had 4MB or more, but very few machines came with that much except some intended to be servers, running Unix of one brand or another. Ironically, the only budget 386 PC with 4MB was the Amstrad 2386, a machine now almost forgotten by history. Amstrad created the budget PC market in Europe with the PC1512 and PC1640, both 8086 machines with 5.25" disk drives.

It followed this with the futuristic 2000 series. The 2086 was an unusual PC – an ISA 8086 with VGA. The 2286 was a high-end 286 for 1988: 1MB RAM & a fast 12.5MHz CPU.

But the 2386 had 4MB as standard, which was an industry-best and amazing for 1988. When Windows 3.0 came out a couple of years later, this was the only PC already on the market that could do 386 Enhanced Mode justice, and easily multitask several DOS apps and big high-end Windows apps such as PageMaker and Omnis. Microsoft barely offered Windows apps yet – early, sketchy versions of Word and Excel, nothing else. I can't find a single page devoted to this remarkable machine – only its keyboard.

The Amstrad 2000 series bombed. They were premature: the market wasn't ready and few apps used DOS extenders yet. Only power users ran OS/2 or DOS multitaskers, and power users didn't buy Amstrads. Nor did people who wanted a server for multiuser OSes such as Digital Research's Concurrent DOS/386.

Its other bold design move was that Amstrad gambled on 5.25" floppies going away, replaced by 3.5" diskettes. They were right, of course – and so the 2000 series had no 5.25" bays, allowing for a sleek, almost aerodynamic-looking case. But Amstrad couldn't foresee that soon CD-ROM drives would be everywhere, then DVDs and CD burners, and the 5.25" bay would stick around for another few decades.

Someone at $JOB said that they really wished that rsync could give a fairly close estimate of how long a given operation would take to complete. I had to jump in...

Be careful what you wish for.

Especially that "close" in there, which is a disastrous request!

AIUI...

It can't do that, because the way it works is comparing files on source and destination block-by-block to work out if they need to be synched or not.

To give an estimate, it would have to do that twice, and thus, its use would be pointless. Rsync is not a clever copy program. Rsync exists to synch 2 files/groups of files without transmitting all the data they contain over a slow link; to do the estimate you ask would obviate its raison d'être.

If it just looked at file sizes, the estimate would be wildly pessimistic, and thus make the tool far less attractive and that would have led to it not being used and becoming a success.

Secondly, by comparison: people clearly asked for this from the Windows developers, and commercial s/w being what it is, they got it.

That's how on Win10 you get a progress bar for all file operations. Which means deleting a 0-byte file takes as long as deleting a 1-gigabyte file: it has to simulate the action first, in order to show the progress, so everything now has a built-in multi-second-long delay (far longer than the actual operation) so it can display a fancy animated progress bar and draw a little graph, and nothing happens instantly, not even the tiniest operations.

Thus a harmless-sounding UI request completely obviated the hard work that went into optimising NTFS, which for instance stores tiny files inside the file system indices so they take no disk sectors at all, meaning less head movement too.

All wasted because of a UI change.

Better to have no estimate than a wildly inaccurate estimate or an estimate that doubles the length of the task.

Yes, some other tools do give a min/max time estimate.

There are indeed far more technically-complex solutions, like...

(I started to do this in pseudocode but I quickly ran out of width, which tells you something)

* start doing the operation, but also time it
* if the time is more than (given interval)
* display a bogus progress indicator, while you work out an estimate
* then start displaying the real progress indicator
* while continuing the operation, which means your estimate is now
inaccurate
* adjust the estimate to improve its accuracy
* until the operation is complete
* show the progress bar hitting the end
* which means you've now added a delay at the end

So you get a progress meter throughout which only shows for longer operations, but it delays the whole job.

This is what Windows Vista did, and it was a pain.

And as we all know, for any such truism, there is an XKCD for it.
https://xkcd.com/612/

That was annoying. So in Win10 someone said "fix it". Result, it now takes a long time to do anything at all, but there's a nice progress bar to look at.

So, yeah, no. If you want a tool that does its job efficiently and as quickly as possible, no, don't try to put a time estimate in it.

Non-time-based, non-proportional time indicators are fine.

E.g. "processed file XXX" which increments, or "processed XXX $units_of_storage"

But they don't tell you how long it will take, and that annoys people. They ask "if you can tell me how much you've done, can't you tell me what fraction of the whole that is?" Well, no, not without doing a potentially big operation before beginning work which makes the whole job bigger.

And the point of rsync is that it speeds up work over slow links.

Summary:

Estimates are hard. Close estimates are very hard. Making the estimate makes the job take much longer (generally, at a MINIMUM twice as long). Poor estimates are very annoying.

So, don't ask for them.

TL;DR Executive summary (which nobody at Microsoft was brave enough to do):

"No."

This was one of those things that for a long time I just assumed everyone knew... then it has become apparent in the last ~dozen years (since Vista) that apparently lots of people didn't know, and indeed, that this lack of knowledge was percolating up the chain.

The time it hit me personally was upgrading a customer's installation of MS Office XP to SR1. This was so big, for the time -- several hundred megabytes, zipped, in 2002 and thus before many people had broadband -- that optionally you could request it on CD.

He did.

The CD contained a self-extracting Zip that extracted into the current directory. So you couldn't run it directly from the CD. It was necessary to copy it to the hard disk, temporarily wasting ¼ GB or so, then run it.

The uncompressed files would have fitted on the CD. That was a warning sign; several people failed in attention to detail and checks.

(Think this doesn't matter? The tutorial for Docker instructs you to install a compiler, then build a copy of MongoDB (IIRC) from source. It leaves the compiler and the sources in the resulting container. This is the exact same sort of lack of attention to detail. Deploying that container would waste a gigabyte or so per instance, and thus waste space, energy, machine time, and cause over-spend on cloud resources.

All because some people just didn't think. They didn't do their job well enough.

So, I copied the self-extractor, I ran it, and I started the installation.

A progress bar slowly crept up to 100%. It took about 5-10 minutes. The client and I watched.

When it got to 100%... it went straight back to zero and started again.

This is my point: progress bars are actually quite difficult.

It did this seven times.

The installation of a service release took about 45 minutes, three-quarters of an hour, plus the 10 minutes wasted because an idiot put a completely unnecessary download-only self-extracting archive onto optical media.

The client paid his bill, but unhappily, because he'd watched me wasting a lot of expensive time because Microsoft was incompetent at:

[1] Packaging a service pack properly.
[2] Putting it onto read-only media properly.
[3] Displaying a progress bar properly.

Of course it would have been much easier and simpler to just distribute a fresh copy of Office, but that would have made piracy easier than this product is proprietary software and one of Microsoft's main revenue-earners, so it's understandable that they didn't want to do that.

But if the installer had just said:

Installation stage x/7:
Progress: [XXXXXXXXXX..........]

That would have been fine. But it didn't. It went from 0 to 100%, seven times over, probably because first the Word team's patch was installed, then the Excel team's patch, then the Powerpoint team's patch, then the Outlook team's patch, then the Access team's patch, then the file import/export filters team's patch, etc. etc.

Poor management. Poor attention to detail. Lack of thought. Lack of planning. Major lack of integration and overview.

But this was just a service release. Those are unplanned; if the apps had been developed and tested better, in a language immune to buffer overflows and which didn't permit pointer arithmetic and so on, it would have have been necessary.

But the Windows Vista copy dialog box, as parodied in XKCD -- that's taking orders from poorly-trained management who don't understand the issues, because someone didn't think it through or explain it, or because someone got promoted to a level they were incompetent for.

https://en.wikipedia.org/wiki/Peter_principle

These are systemic problems. Good high-level management can prevent them. Open communications, where someone junior can point out issues to someone senior without fear of being disciplined or dismissed, can help.

But many companies lack this. I don't know yet if $DAYJOB has sorted these issues. I can confirm from bitter personal experience that my previous FOSS-centric employer suffered badly from them.

Of course, some kind of approximate estimate, or incremental progress indicator for each step, is better than nothing.

Another answer is to concede that the problem is hard, and display a "throbber" instead: show an animated widget that shows something is happening, but not how far along it is. That's what the Microsoft apps team often does now.

Personally, I hate it. It's better than nothing but it conveys no useful information.

Doing an accurate estimator based on integral speed tests is also significantly tricky and can slow down the whole operation. Me personally, I'd prefer an indicator that says "stage 6 of 15, copying file 475 of 13,615."

I may not know which files are big or small, which stages will be quick or slow... but I can see what it's doing, I can make an approximate estimate in my head, and if it's inaccurate, well, I can blame myself and not the developer.

And nobody has to try to work out what percent of an n stage process with o files of p different sizes they're at. That's hard for someone to work out, and it's possible that someone can't tell them a correct number of files or something... so you can get progress bars that go to 87% and then suddenly end, or that go to 106%, or that go to 42% and then sit there for an hour, and then do the rest in 2 seconds.

I'm sure we've all seen all of those. I certainly have.

My previous post was an improvised and unplanned comment. I could have structured it better, and it caused some confusion on https://lobste.rs/

Dave Cutler did not write OS/2. AFAIK he never worked on OS/2 at all in the days of the MS-IBM pact -- he was still at DEC then.

Many sources focus on only one side of the story -- the DEC side, This is important but only half the tale.

IBM and MS got very rich working together on x86 PCs and MS-DOS. They carefully planned its successor: OS/2. IBM placed restrictions on this which crippled it, but it wasn't apparent at the time just how bad this would turn out to be.

In the early-to-mid 1980s, it seemed apparent to everyone that the most important next step in microcomputers would be multitasking.

Even small players like Sinclair thought so -- the QL was designed as the first cheap 68000-based home computer. No GUI, but multitasking.

I discussed this a bit in a blog post a while ago: http://liam-on-linux.livejournal.com/46833.html

Apple's Lisa was a sideline: too expensive. Nobody picked up on its true significance.

Then, 2 weeks after the QL, came the Mac. Everything clever but expensive in the Lisa stripped out: no multitasking, little RAM, no hard disk, no slots or expansion. All that was left was the GUI. But that was the most important bit, as Steve Jobs saw and nobody much else did.

So, a year later, the ST had a DOS-like OS but a bolted-on GUI. No shell, just a GUI. Fast-for-the-time CPU, no fancy chips, and it did great. It had the original, uncrippled version of DR GEM. Apple's lawsuit meant that PC GEM was crippled: no overlapping windows, no desktop drive icons or trashcan, etc.

( Read more... )

I have ruffled many feathers with my position that the touch-driven computing sector is growing so fast that it's going to subsume the old WIMP model completely. I don't mean that iPads will replace Windows PCs, but that the descendants of the PC will look and act more like tablets than today's desktops and laptops.

But where is it leading, beyond that point? I have absolutely no concrete idea. But the end point? I've read one brilliant model.

It's in one of the later Foundation books by Isaac Asimov, IIRC. (Not a series I'm that enamoured of, actually.)

A guy gets (steals?) a space yacht: a small, 1-man starship. (Set aside the plausibility of this.)

He searches the ship's crew quarters. In its few luxury rooms, there is no cockpit. No controls, no instruments, nothing. He is bemused.

He returns to the comfiest room, the main stateroom, i.e. cabin/bedroom. In it there is a large, bare dressing table with a comfy seat in front of it. He sits.

Two handprints appear, projected on the surface of the desk, shaped in light.

He studies them. They're just hand-shaped spots of light. He puts his hands on them.

And suddenly, he is much smarter. He knows the ship's position and speed in space. He knows where all the nearby planetary bodies are, their gravity wells, the speeds needed to reach them and enter orbit.

Thinking of the greater galaxy, he knows where all the nearby stars are, their masses, their luminosities, their planetary systems. Merely thinking of a planet, he knows its cities, ports, where to orbit it, etc.

All this knowledge is there in his mind if he wants it; if he allows his attention to move elsewhere, it's gone.

He sits back, shocked. His hands lift from the prints on the desk, and it all disappears.

That is the ultimate UI. One you don't know is there.

Any UI where there are metaphors and abstractions and controls you must operate is inferior; direct interaction is better. We've moved from text views of marked-up files with arcane names in folder hierarchies to today: hi-res, full-colour, moving images of fully-formatted documents and images. That's great.

Some people are happily directly manipulating these — drawing and stroking screens with all their fingers, interacting naturally. Push up to see the bottom of a document, tap on items of interest. It's so natural pre-toddlers can do it.

But many old hands still like their pointing hardware and little icons on screen that they can twiddle with their special pointing devices, and they shout angrily that it's more precise and it's tried and tested and it works.

Show them something better, no, it's a toy. OK for idly surfing the web, or reading, or watching movies, but no substitute for the "real thing".

It's a toy and the mere idea that these early versions could in time grow into something that could replace their 4-box Real Computer of System Unit, Monitor, Mouse and Keyboard is a nonsensical piece of idiocy.

Which is exactly what their former bosses and their tutors said about the Mac's UI 30y ago. It's doubtless what they said about the tinker-toy CP/M boxes a decade before that, and so on.

I'm guilty too. I am using a 25y old keyboard on my tiny silent near-unexpandable 2011 Mac mini, attached via a convertor that cost more than the keyboard and about a third as much as the Mac itself. I don't have a tablet; I don't personally like them much. I like my phablet, though. I gave away my Magic Trackpad - I didn't like it.

(And boy did my friends in the FOSS community curse me out for buying a Mac. I'm a traitor and a coward, apparently.)

But although I personally don't want this stuff, nonetheless, I think it's where we're going.

If adding more layers of abstraction to the system means we can remove layers of abstraction from the human-computer interface, then I'm all for it. The more we can remove, the simpler and easier and clearer the computers we can make, the better. And if we can make them really small and cheap and thus give one to every child in the poorer countries of the world — I'd be delighted.

If price was putting Microsoft and Apple out of business and destroying the career of everyone working with Windows, and replacing it all with that nasty cancerous GPL and Big-Brother-like services like Google — still worth it.

Facebook readers may have noted my post yesterday, when I mentioned that I was trying to resurrect an old notebook with a dead screen by using a screenreader. I commented:

"Just spent an hour trying to update a fresh install of Windows XP SP3 on a PC with no screen, using speech alone. Haven't felt so lost since 1988. It's currently on 100 of 125, though, which is a sort of success..."

Well, I've spent a little more time on it today.

According to http://update.microsoft.com I now have all essential updates installed. I'm not feeling brave enough to tackle the optional updates just yet - I'm still terrible at navigating web pages.

I've also managed to install MS Security Essentials, and currently, Ninite claims to be installing Opera, OpenOffice and a FOSS PDF reader.

It's a very chastening experience. I am a dab hand with driving Windows without a mouse - I learned on Windows 2.0 in the days when my employers didn't own a PC mouse. But much of the XP and Windows apps' UI is either inaccessible by keyboard, unreadable or just unlabelled.

For instance, stepping through the icons in the notification area, I get "icon... icon... NVDA... icon... Automatic updates... clock." Selecting each icon and opening it is the only way to find out what it's the icon for. One gives the wireless network connection info, for instance, but some lazy-ass Microsoft programmer forgot to give it a text label.

The entire UI of the MS Security Essentials consists of the following: "home... update... options... scan... exit." That's it. No legible text at all. I can open Task Manager and move between the tabs, but there's no way to sort the list of tasks to find what is hogging the system. That needs a mouse-click.

Progress bars are unreadable, but NVDA makes a series of rising beeps to tell you that something's happening. It's hard to tell how far you've got, though. The mandatory Windows Genuine Authentication installer stops at about 80%, every time, even after 3 reboots. I gave up and used a third-party WGA killer app to nuke it into oblivion.

And I've compared notes with ednun on this. Ubuntu seems to be about the best Linux for accessibility, with an integrated screenreader, Orca - but it can read considerably less than NVDA can. Windows does seem to be the best option.

It's quite scary. Certainly I'm nowhere near being able to post status updates from a screenless PC.

(Weird font changes courtesy of the LJ rich-text edit control. Sorry about that.)

So today's small victory was beating my HP Proliant ML110 - the original model from 2004, with a 3GHz P4 in it - into submission.

It used to run Windows Server 2003 Small Business Server. Not really from my choice...

I got it with an HP UltraSCSI adaptor in it, but no disks, & I don't have enough to populate it.

So, I swapped it with the PCI-X Dell CERC ATA-100 controller out of my Dell PowerEdge 600SC, acquired around the same time. The Dell has 3 IDE controllers on the motherboard anyway, meaning it can boot from a pair of more-than-big-enough-for-Ubuntu-Server 10GB UltraSCSIs and still has enough ports to drive 4 UltraIDE disks and an IDE CDRW drive to boot and install from.

This left me struggling to fit six UltraIDE drives into the Proliant - it's only really meant to take four, but a pair of cheapo 3½"-to-5¼" mounting kits from eBay let me use the two spare removable bays, too. I have six spare 80GB IDE drives and a seventh in case of failure, so this gave me a total of 372GB of RAID5 storage. OK, not a lot by modern standards, but actually, that is a lot of space. I don't game, I don't download a lot of movies or TV, and I don't want more space than I can back up onto one relatively inexpensive external disk.

Snag is, last year, no Linux distro could access a RAID5 on the CERC controller. It's really an ALI MegaRAID i4, bought to drive a mirror pair with Linux, but kernel 2.6.twenty-whatever-was-current-in-2009 couldn't see RAID5s on this controller. Windows could. So, finding an eval copy of W2K3 SBS in the garage, I went with that, and it worked fine.

But as mentioned in an earlier post, unfortunately, it timed-out at the start of Jan and my server stopped working for more than 1h at a time. Microsoft's elegant method for enforcing the evaluation period is to have the server automatically throw a bluey - a BSOD - after an hour of use. Nice.

So I decided to try this copy of Windows 2008 I have. Put an external screen on it, boot Ubuntu 9.10, move all of W2K3SBS into a "previous system" folder (that's what Mac OS X does when you "archive and install", so it seemed appropriate), boot Windows 2008 and install it. It all went swimmingly. It took an hour or 2 to get it running, but it even detected and installed the inbuilt Broadcom NIC for me, which is more than 2K3 could do. (According to a review I found, these damned boxes shipped with W2K3, so it ought to have worked - but it didn't. Had to faff around downloading the driver on another machine and transferring it across with a USB key. Of course, the HP setup disks I got with the machine don't contain anything as mundane as a NIC driver, oh no. Management tools agogo, but no actual, you know, drivers.
( And then the niggling issues started... )

I've not had a PC quick enough to really use PC-on-PC virtualisation in anger before, until ednun gave me the carcase of his old one. AMD Athlon64 X2 4800+, 2G RAM, no drives or graphics.

I've upped it to 4G, a couple of old 120GB EIDE hard disks, a DVD burner, a replacement graphics card (freebie from a friend) & a new Arctic Cooling Freezer7 Pro heatsink/fan from eBay to replace the old, clogged-up AMD OEM one. Total budget, just under £20; result, quick dual-core 64-bit machine with 64-bit Linux running very nicely.

For some work stuff. I've been using Linux-under-Linux in VirtualBox, which works rather well - but it's a kinda specialised need. There are still a few things that either don't work all that well in Linux or which I can't readily do, though. Spotify runs under WINE but crackles & pops then stops playing after 2-3 minutes & never emits another cheep. My CIX reader, Ameol, also runs OK under WINE, but windows don't scroll correctly. I don't think there's any Linux software to sync my mobile phone or update its firmware, although I'm not sure I'd want to try the latter from within a VM anyway, just in case...

So I decided to try running Windows in a VM under Linux just for occasional access to a handful of Windows apps, without rebooting into my Windows 2000 & Windows 7RC partitions. (Makes mental note: better replace that Win7 one before the RC expires.)

I've always had reservations about running a "full-sized" copy of Windows this way. It seems very wasteful of resources to me. That is, running one full-fat full-function OS under another full-fat OS, just for access to a couple of apps. (Also, you need a licence, if the guest is a modern, commercial product, not some ancient piece of abandonware.)

So I thought I'd try some "legacy" versions of Windows to see how well they worked. I have a fairly good archive here, from Windows 3.1 up to Win7.
( Read more... )