4 ms·

Recall a project back in the days where the customer wanted to upgrade their workstations but also save money, so we designed a solution where they'd have a bee

Recall a project back in the days where the customer wanted to upgrade their workstations but also save money, so we designed a solution where they'd have a beefy NT4-based Citrix server and reusing their 486 desktop machines by running the RDP client on Windows 3.11. To make deployment easy and smooth, it was decided to use network booting and running Windows from a RAM disk. The machines had 8MB of memory and it was found we needed 4MB for Windows to be happy, so we had a 4MB RAM disk to squeeze everything into. A colleague spent a lot of time slimming Windows down, but got stuck on the printer drivers. They had 4-5 different HP printers which required different drivers, and including all of them took way too much space. He came to me and asked if I had some solution, and after some back and forth we found that we could reliably detect which printer was connected by scanning for various strings in the BIOS memory area. While not hired as a programmer, I had several years experience by then, so I whipped up a tiny executable which scanned the BIOS for a given string. He then used that in the autoexec.bat file to selectively copy the correct printer driver. Project rolled out to thousands of users across several hundred locations (one server per location) without a hitch, and worked quite well from what I recall.

brnt 3y ago
And here I am, in a shop of about 3K FTE, where we are squeezed 6 persons onto a single socket Xeon which barely beats an iPhone 15 Pro rendering those 12 screen worth of data slowing down to a crawl, huge latency, crappy disk latency too (feels like were all on the same spinning Rust, but it's Windows and some VMWare middleware so who knows why this is slow). Somehow snappyness is completely eradicated.
- fuzzfactor 3y ago
  >Somehow snappyness is completely eradicated. Barely inadequate engineering by design. Actually that's a difficult target to hit accurately and there's a fine line between it and barely adequate engineering leadership. And even if it's adequate, is barely adequate what you wanted anyway?
n6h6 3y ago
Beautiful work
- magicalhippo 3y ago
  It was quite something to behold. I also learned some valuable lessons in project planning and execution... they had a few guys who sat for 1.5 years to plan the rollout, working with suppliers to plan deliveries of the hardware etc. When the time came we rolled out all the several hundred locations in just over 3 months, which included assembling and basic configuration of the servers at base, shipping the servers and then migrating data onsite from the old UNIX server (mailboxes, home directories etc). We only had two issues, one server had gotten the hard disk cables disconnected during transport, easy fix had the technician on site been Compaq certified (had to get shipped back to base and out again), and another had a weird hardware error which caused the server to freeze when scrolling large log files in Notepad (replaced the server and all was good). Beyond that it went flawless.
RulerOf 3y ago
>it was decided to use network booting and running Windows from a RAM disk. What tech did that use? I imagine a "modern" system doing this would use a small RAM disk for the base Windows installation to boot from with any critical apps inside, and a second disk image mounted via HTTP for any "bulk" data, all via a custom iPXE build. But NT4 predates the PXE standard by a number of years, and also the concept of mounting disk images via HTTP (or other SAN protocol). Was this some Netware stuff perhaps?
- harikb 3y ago
  Novell netware type LAN, with network book, existed for even DOS, pre Windows 3.1 Edit: yes, wikipedia seems to confirm my recollection https://en.wikipedia.org/wiki/NetWare https://en.wikipedia.org/wiki/NetWare
- cduzz 3y ago
  bootp / tftpboot were used to provision diskless systems (diskless workstations / X-terminals) even in the very early 1990s (and likely before, but I didn't interact with them until college computer labs). On scanning my brain-based archives I can't recall how IP addresses were assigned and a brief asking of google "bootp vs dhcp" leads me to believe that with bootp there was just a static list of IP / MAC mappings for already-known diskless devices. Old network cards could have a boot rom in them; this https://www.vogons.org/viewtopic.php?t=86741 https://www.vogons.org/viewtopic.php?t=86741 discusses the magic and a couple of the non-pxe protocols.
  - fuzzfactor 3y ago
    I think you're correct about bootp. A bootp server app generally listens for a MAC broadcast which appears when another physically connected device sends a "bootp request" into the network, so the bootp server can compare the MAC against its whitelist and assign its corresponding designated fixed IP address on the local network. Which IP address will then be remembered by the requesting device and is used from that point forward, not much differently than an address assigned by DHCP. Some hardware like early HP ethernet printers did not retain their assigned IP address through a power failure. So there had to be a functional bootp server app up and running before you powered up the printer or the printer's initial bootp request would go unanswered and it was no good to anybody.
magicalhippo 3y ago
> a beefy NT4-based Citrix server This was also when I learned about the pitfalls of multithreading... I had started trying to use multithreading, and had implemented it in my raytracer. It worked like a charm on my machine. During that project they brought a 4-socket server in the lab for testing, so after hours I fired up my raytracer on it, excited to see the promised 4x speedup... only to be met by an immediate access violation. I had of course missed a lock, but it worked fine on my computer because it only had a single CPU (core) so even if I spawned multiple threads, the chances of them tripping over each other at that point was very low. Not so when they could actually run simultaneously.

brnt 3y ago

And here I am, in a shop of about 3K FTE, where we are squeezed 6 persons onto a single socket Xeon which barely beats an iPhone 15 Pro rendering those 12 screen worth of data slowing down to a crawl, huge latency, crappy disk latency too (feels like were all on the same spinning Rust, but it's Windows and some VMWare middleware so who knows why this is slow). Somehow snappyness is completely eradicated.

fuzzfactor 3y ago
>Somehow snappyness is completely eradicated. Barely inadequate engineering by design. Actually that's a difficult target to hit accurately and there's a fine line between it and barely adequate engineering leadership. And even if it's adequate, is barely adequate what you wanted anyway?

n6h6 3y ago

Beautiful work

magicalhippo 3y ago
It was quite something to behold. I also learned some valuable lessons in project planning and execution... they had a few guys who sat for 1.5 years to plan the rollout, working with suppliers to plan deliveries of the hardware etc. When the time came we rolled out all the several hundred locations in just over 3 months, which included assembling and basic configuration of the servers at base, shipping the servers and then migrating data onsite from the old UNIX server (mailboxes, home directories etc). We only had two issues, one server had gotten the hard disk cables disconnected during transport, easy fix had the technician on site been Compaq certified (had to get shipped back to base and out again), and another had a weird hardware error which caused the server to freeze when scrolling large log files in Notepad (replaced the server and all was good). Beyond that it went flawless.

RulerOf 3y ago

>it was decided to use network booting and running Windows from a RAM disk. What tech did that use? I imagine a "modern" system doing this would use a small RAM disk for the base Windows installation to boot from with any critical apps inside, and a second disk image mounted via HTTP for any "bulk" data, all via a custom iPXE build. But NT4 predates the PXE standard by a number of years, and also the concept of mounting disk images via HTTP (or other SAN protocol). Was this some Netware stuff perhaps?

harikb 3y ago
Novell netware type LAN, with network book, existed for even DOS, pre Windows 3.1 Edit: yes, wikipedia seems to confirm my recollection https://en.wikipedia.org/wiki/NetWare https://en.wikipedia.org/wiki/NetWare
cduzz 3y ago
bootp / tftpboot were used to provision diskless systems (diskless workstations / X-terminals) even in the very early 1990s (and likely before, but I didn't interact with them until college computer labs). On scanning my brain-based archives I can't recall how IP addresses were assigned and a brief asking of google "bootp vs dhcp" leads me to believe that with bootp there was just a static list of IP / MAC mappings for already-known diskless devices. Old network cards could have a boot rom in them; this https://www.vogons.org/viewtopic.php?t=86741 https://www.vogons.org/viewtopic.php?t=86741 discusses the magic and a couple of the non-pxe protocols.
- fuzzfactor 3y ago
  I think you're correct about bootp. A bootp server app generally listens for a MAC broadcast which appears when another physically connected device sends a "bootp request" into the network, so the bootp server can compare the MAC against its whitelist and assign its corresponding designated fixed IP address on the local network. Which IP address will then be remembered by the requesting device and is used from that point forward, not much differently than an address assigned by DHCP. Some hardware like early HP ethernet printers did not retain their assigned IP address through a power failure. So there had to be a functional bootp server app up and running before you powered up the printer or the printer's initial bootp request would go unanswered and it was no good to anybody.

magicalhippo 3y ago

> a beefy NT4-based Citrix server This was also when I learned about the pitfalls of multithreading... I had started trying to use multithreading, and had implemented it in my raytracer. It worked like a charm on my machine. During that project they brought a 4-socket server in the lab for testing, so after hours I fired up my raytracer on it, excited to see the promised 4x speedup... only to be met by an immediate access violation. I had of course missed a lock, but it worked fine on my computer because it only had a single CPU (core) so even if I spawned multiple threads, the chances of them tripping over each other at that point was very low. Not so when they could actually run simultaneously.