mschaef

Many of those pictures look like great reasons for lockout tagout.

Even 256 meg of hard drive. That would have been impressively expensive in the 80s.

I only have a couple reference points around this scale:

My dad's company had a system set up with a searchable index of a bunch of legal testimony. It was a Compaq Deskpro 386 running Unix with an attached 1GB disk. The 1GB disk set up was as big as the machine itself.

A few years later, I worked with a Cyber mainframe equipped with around 30GB of total attached disk storage. The disk array literally filled a room.

256MB disk on an 80's PC would have definitely been quite a bit.

OK, but we spent a decade having to worry about this garbage, until the tooling finally caught up.

This was less about tooling than it was about economics - there was 32-bit hardware available in the personal computer space in 1984, if not before. The issue was cost. In today's currency, a 32-bit capable Mac was $8,000 with 128K. The first 32-bit capable PC was closer to $20,000.

That's a heavy lift in a world where a segmented architecture machine costs a fraction of that amount, runs software you might already have, and works the same way as your co-worker's machine.

There were literally millions of man-hours wasted on segment registers.

A software developer in 1986 was not forced to deal with segment registers... but they often chose to deal with them to gain access a (much) bigger audience of potential customers for their software.

A kludge that helped Intel conquer the world, but what a filthy, disgusting architecture, and what a waste of everybody's time and brain power.

The other side of the coin is that (for reasons I state above), segmented architectures got more capable software into more hands more quickly. It arguably did a lot for end users.

And this is the problem, it was very painful just to walk through a 200 KB buffer. This required compiler/runtime tricks, different selector increments in real vs protected mode, and special pointer types.

Most of that could be (and often was) hidden by the tooling. If you needed to bypass it, you could, but you didn't need to. That's not very different from today... there's a lot of hidden magic that can be bypassed if you need to for whatever reason.

I'd argue that these are useful engineering abstractions that made the best of a less than ideal situation. (The reality of the world being that there are no "ideal" situations... you have to work with what you have at the moment to solve the problem you have. These days, I'd argue that a pointer into a 'flat' memory space is counter productive to the extent it hides issues around cache hierarchy, NUMA, etc. In 1986, we had to worry that a flat memory space looked discontiguous. In 2026, we have to worry the a discontiguous memory space looks flat.

That would make more sense. I was trying to imagine what sort of (custom?) hardware would accommodate that amount of memory back then. That was large storage even for mainframes the time. (The Cray 2 in the mid-1980's had 2GB, which was considered notably large.)

I should preface this by saying I'm taking about x86 segmentation in general. On the 8086 you're right, but the 8086 can't address 2MB of memory to begin with. On the 80286 in protected mode, the situation is different in the way I'm about to describe.

The memory itself doesn't have to be contiguous.

2MB of 64K segments maps to 32 segments. So you need 32 locations in physical memory capable of storing 64K.

The programming model for addressing that block of memory necessarily includes both segment selectors and offsets. The segment selectors are indices into a segment table that contains the base address of each of the 32 segments. As long as the segment selectors themselves can be allocated contiguously in the segment table, you have enough to be able to compute which segment you need for which address in the 2MB range. It's the indirection through the segments table that maps it to physical addresses that do not need to be contiguous.

Raymond Chen talks a bit about how it worked in Windows 3.x here: https://devblogs.microsoft.com/oldnewthing/20171113-00/?p=97...

There is no such thing as a "2MB program".... all you have is a program composed of <=64K segments, which are easy enough to fit into the hole.

If you do need something approaching a 2MB block of memory, you don't need a contiguous range of memory, what you need is a contiguous range of selectors, which is a different (and probably easier) problem to solve.

I had to use it to do image processing on a 256MB image buffer back in the 1980s in assembly language.... Give me a flat 32 bit memory address space any day (e.g. MC68000 around the same time.)

Huh?

There were no segmented x86 machines capable of addressing 256MB of RAM, aside from the 386 (maybe).

If you had a 386 and the $130K of memory your statement implies, you probably also could afford a Unix (or something else) license to get to that 32-bit address space. (If you weren't doing it all in memory, then you're having to depending on paging stuff out to disk, implying you either have a real OS or a flat memory model isn't enough to save you since you're manually having to page stuff to disk and back anyway.)

That's a super strange scenario you're describing.

The 8086 was a stopgap measure to accommodate the fact the iAPX432 was in the middle of turning into the disaster it did. Given the engineering resources and timelines involved in the 8086, it wasn't a bad compromise approach.

But more importantly it kept the x86 world for too long in that dead end that was 8086 mode programming "Oh if developers would just..." They won't. They haven't. And they will not ever.

8086 real mode programming in the mainstream lasted from 1981 until 1991 or so. The last 35 years have 32-bit (and later 64-bit) flat model addressing with pages for the most part. Seems like a reasonable transition period, really.

In hindsight maybe a binary level translator from 8080 to 8086 would have worked better (and be simple enough)

Part of the reason they liked the segmented model is that it was possible to set the segments to the same value and then ignore them entirely. That gave a programming model for the 8086 that was sufficiently close to the 8080 that it was possible to use a sort of cross assembler to do something like what you suggest. You could then opt into 8086 specific instructions and segmentation as you needed. (Which took a few years... the first IBM PC's shipped with as little as 16K of RAM.)

This is a small one, but significant to me.

I asked Claude to add support for multiple lights to my toy ray-tracer. It correctly added the support and then suggested adding colored lights to make it easier to diagnose. It felt more like a colleague making a useful suggestion than any sort of pure engineering tool.

From the sound of it, You may know this already, but there was a 1950's era plan to do something very similar to what you imply here:

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

I think there are a couple questions you need to ask yourself - the first is why is it hard for you to be alone? You're the one person you're stuck living with for your entire life - it shouldn't be hard to be alone with yourself. That's where it began. That's where it will end.

You mentioned you have a therapist - this is something you might wish to explore with them.

The second question is related - what are you looking for in the "not alone"? What do you want? What would bring you peace? Are you looking for a relationship? A friend? Sex? etc? While you have to be comfortable with yourself, part of that comfort is knowing and being confident in what you're looking for. It may be that the world won't or can't provide it, but that's why I put this question second.

The final point I'll make is that there's nothing stopping you. You're an adult... within the constraints of the laws of your society, you CAN do what you want and there's nothing stopping you. It may not go the way you want, but it might, and wouldn't it be fun to try?

Agreed, re: DeMuro.... I'm long past tired of hearing how "The ____ is the ____!"

I do like Tedward's videos, though. He seems a lot more honestly enthusiastic about it, and definitely has fun with the cars.

That's a $125 salad spinner... I get the appeal, but it's definitely a premium product.

I have half a dozen of them (including my father's from college) that I cherish, but do not use. I love the simplicity and elegance of the design. (Slide rules do a lot with operations that essentially boil down to addition, subtraction, and looking up function values in tables.)

The disinterest programmers have in using 80 bit arithmetic.

I don't know, other than to say there's often a tendency in this industry to overlook the better in the name of the standard. 80-bit probably didn't offer enough marginal value to enough people to be worth the investment and complexity. I also wonder how much of an impact there is to the fact that you can't align 80-bit quantities on 64-bit boundaries. Not to mention the fact that memory bandwidth costs are 25% higher when dealing with 64-bit quantities, and floating point work is very often bandwidth constrained. There's more precision in 80-bit, but it's not free, and as you point out, there are techniques for managing the lack of precision.

A bit of background - I wrote my one numerical analysis programs when I worked at Boeing. The biggest issue I had was accumulation of rounding errors.

This sort of thing shows up in even the most prosaic places, of course:

https://blog.codinghorror.com/if-you-dont-change-the-ui-nobo...

In any event, while we're chatting, thank you for your longstanding work in the field.

Does this have any similarities at all to the fact that the Pentium 4 used a 16-bit ALU?

Thank you. As always.

What do you mean by respect? Here's a layperson's perspective, at least.

Up through the 486 (with its built in x87), the x87 was always a niche product. You had to know about it, need it, buy it, and install it. This is over and on top of buying a PC in the first place. So definitionally, it was relegated it to the peripheries of the industry. Most people didn't even know x87 was a possibility. (I remember distinctly a PC World article having to explain why there was an empty socket next to the 8088 socket in the IBM PC.)

However, in the periphery where it mattered, it gained acceptance within a matter of a few years of being available. Lotus 1-2-3, AutoCAD, and many compilers (including yours, IIRC) had support for x87 early on. I would argue that this is one of the better examples of marginal hardware being appropriately supported.

The other argument I'd make is that (thanks to William Kahan), the 8087 was the first real attempt at IEEE-754 support in hardware. Given that IEEE-754 is still the standard, I'd suggest that x87's place in history is secure. While we may not be executing x87 opcodes, our floating point data is still in a format first used in the x87. (Not the 80-bit type, but do we really care? If the 80-bit type was truly important, I'd have thought that in the intervening 45 years, there'd be a material attempt to bring it back. Instead, what we have are a push towards narrower floating point types used in GPGPU, etc.... fp8 and f16, sure... fp80, not so much.)

I'm curious what the CX-83D87 and Weiteks look like.

The Weitek's were memory mapped. (At least those built for x86 machines.).

This essentially increased bandwidth by using the address bus as a source for floating point instructions. Was really a very cool idea, although I don't know what the performance realities were when using one.

http://www.bitsavers.org/components/weitek/dataSheets/WTL-31...

Then for many years it was standard for software to have help files, and it seemed anachronistic for Emacs to loudly proclaim it is self-documenting.

Emacs' notion of self documentation refers to something slightly different than the fact it has online help files. The help facilities can query the Lisp runtime for things like functions and keybindings. These update dynamically as the system is reconfigured. The result is something that isn't quite as cleanly presented as an online help document, but has the benefit of being deeply integrated into how the system is actually configured to behave at the moment. Very cool, and very much dependent on the open source nature of emacs.

Knowing what I know now, I'd have appreciated it much more than I did at the time. (Also, fixing the link rate on the C64 would've been nice too.)

My first idea was to get the source cleaned up a bit and compile it again to 32 bit with Visual Basic 4, but I couldn't figure it out, it required some 3rd party libraries that I just couldn't get a hold of.

This was super common for VB apps. The original architecture of VB was, loosely speaking, a GUI container for various pluggable controls connected to a BASIC runtime. The number of controls that came in the box would vary depending on how fancy a version of VB you bought, and you could plug in additional third party controls in the form of "VBX's" - Visual Basic eXtensions. Even though VBX's were designed mainly for GUI controls, they were the easiest extension point for VB and got extensively used for all sorts of integrations until OLE Automation became more prevalent. (Roughly contemporaneous with the switch to 32-bit.)

He's been blogging continuously for close to twenty years - he was one of the original wave of Microsoft bloggers (along with Larry Osterman, Michael Kaplan, and several others I can't remember).

It is very much an engineer's engineering blog, and written by someone deeply in the trenches.

That derives logically from the way Commodore implemented disks. If you bought a 1540 or 1541 (or any other Commodore drive) for a C-64 or VIC-20, it had an onboard 6502 to run the disk drive. The interaction between the computer and the disk drive was somewhat similar in concept to fetching a file from a network server.

This could be useful to save on costs in computer labs... my grade school used multiplexer boxes to share a single 1541 across four C-64's.

I had it done about eight years ago... there's nothing quite like waking up after a fifteen minute procedure and seeing better than you have without correction since you were five.

It's nothing short of a man-made miracle but I have to say it's also very umconfortable and stressful for the patient.

I think I must be strange, either in my reaction to the stress or the way I chose to manage it during my surgery.

I explicitly wanted to be somewhat awake during the procedure to see what was going on (how many chances do you get to see your lens emulsified from the inside)... and I remember having short conversations with the surgeon during the procedure. (She'd been concerned about zonular laxity, and we discussed during the procedure that she didn't see evidence.)

This is not something I'd want to reproduce if I didn't have to, nor would I suggest it as a general approach, but given that it was necessary for me, it was amazing to see it first hand.

My second procedure (second eye) was a little more stressful than the first, but for me all the material stress (which was significant) was in the run up and anticipation.

The Mac Desktop is vastly inferior to the Linux world

Asking out of curiosity, why is this? What's the functionality you miss on Mac?

The RX100 has had wifi transfer since the 3rd gen.

On an iPhone, I can take the picture and I'm immediately a button press away from a photo editor and then whoever I want to send it to.

(A camera that automatically tethered to a phone and dumped pictures into the phone's camera roll would mostly solve the workflow issues I'm mentioning here. Would not surprise me if this already exists.)

I understand the "second device to carry around" but it isn't a real point for baby pics you might take at home.

Maybe. The camera still has to be charged and in mind and hand. (Then as soon as the kids leave the house you're back to where you were and having to carry something around that you might not otherwise.)

I also know a number of people who don't leave home with their smartphone anyway

I see that... different people have different sorts of relationships with personal electronics. For me, it wound up being that I'd carry a cell phone and that was about it. Even in the pre-smartphone days, when I might have carried a PDA, I either wouldn't or couldn't.

Some of it's size, some of it the fact that the camera is a second device, and some of it's workflow.

I tried a Sony RX100 (1" sensor) when they first came out, optimistic about the possibility of using it for 'general purpose' photography. After all, it's small enough.

The problem was, it's a second device to carry around and keep charged. Then once you capture the image, it's largely stuck on the device until you find a way to offload your images. I briefly experimented with cables that would let me do things like transfer images from the RX100 to my (Android at the time) mobile phone, for archiving and sending to family and friends. That turned the whole thing into the sort of science fair project that I didn't have time for as the parent of a very young child. (Although in fairness, I can't think of a single time in my life when I'd have had the patience, kids or not.)

This is why, for all the arguments you can make against them as cameras, I've come to be very thankful for the amount of effort that Apple and others have made to get appealing images out of devices I always carry around anyway. I can take a set of pictures, edit them, have them automatically archived to cloud storage, and send them to whoever I want.. all with a single device I was carrying around anyway.

This leaves open the fact that the 'real' camera workflow is still an option when there's the need for higher image quality and the time (or money to hire a photographer) to take advantage of what a DSLR or the like can do.

(When I compare what I can do with my iPhone to what my parents had available to them (a 110 format camera and 35mm Nikons), I like the tradeoffs a lot better. the image quality available now is definitely better than the 110. Some of those 35mm exposures are probably better quality than what I can get out of an iPhone, but they're all stuck in albums and slides, and nobody ever looks at them. )

I have a couple DSLR's and a large frame compact, and I wholly get your point. The image quality on even an older DSLR is better, mainly due to the physics of the optics - there's nothing like a high quality lens dumping a bunch of light on a large sensor.

However.... it's really hard to overstate the workflow and convenience aspects of shooting with a phone. (Particularly as a parent, and even moreso when I was a new parent of a small child.) The phone has the twin benefits of 1) being present almost always and 2) being immediately able to process and transmit an image to the people you might want to see it. For the 99% case, that's far more useful than even a very significant improvement in image quality. For the 1% where it matters, I can and do either hire a professional (with better equipment than my own) or make the production of dragging out my DSLR and all that it entails. This is like so many other cases where inarguable technical excellence of a sort gives way to convenience and cost issues. IOW, "Better" is not just about Image Quality.