HN user

Annatar

6 karma

Digging? Nice try but no cigar!

Posts4
Comments1,917
View on HN

The natural tendency is to tackle the hardest parts first, because it's intuitive that the low hanging fruit will be easy and therefore bring more satisfaction. However, I found that tackling what one knows first -- the low hanging fruit -- injects new energy and satisfaction and is critical to mustering the willpower to tackle the hard parts. I found out that solving the low hanging fruit often ends up offering insight into solving the hard problems, and thus finishing a project.

One could pipe that output directly to nroff or groff:

  | soelim | tbl | eqn | nroff -man - | $PAGER

  | soelim | tbl | eqn | nroff -man -Tpost - | /usr/lib/postscript/bin/dpost | ps2pdf - > ~/Desktop/blog.PDF

  | soelim | tbl | eqn | groff -Tps -man - | ps2pdf - > ~/Desktop/blog.PDF

Every time a socket is instantiated, Sun Microsystems comes alive; so too it is with NFS, and many other core technologies; there is lots that's left of Sun which still makes it live, even though it doesn't officially exist any more.

And any time 0xide Computer ships a cloud in a rack with the Helios operating system powering it, Sun Microsystems shines bright as a beacon of indestructibility due to quality.

Modern post-2012 Fortran is excellent, and the compiler produces very fast code, GPU or otherwise. And it is very portable.

This is an already solved problem:

  - package everything, *especially configuration*;
  - executables in /opt/someprefix/bin, no extensions;
  - daemons (services), executables with elevated privileges go into /opt/someprefix/sbin/;
  - read only data which the application needs to run goes int /opt/someprefix/share/application/;
  - logs should be streamed to syslogd, for example via the logger utility, so that centrally configured OS logging is honored and the application doesn't vomit out log files arbitrarily or at arbitrary, private locations;
  - application data should go to /var/opt/someprefix/application/;
  - configuration in /etc/opt/someprefix[/application] (if more than one configration file, otherwise /etc/opt/someprefix/);
  - configuration files should have a .conf or .cf postfix, and should be plain ASCII text files, but not YAML, JSON, or XML.
These are industry norms, formally written as specifications:

https://illumos.org/man/7/intro

https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#et...

https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#op...

https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#va...

...and most important of all: deliver quality manual pages in /opt/someprefix/share/man for your tools, with lots of examples! No wikis, markups, HTML web pages, none of that junk: straight, honest to goodness manual pages available at one's fingertips on the command line.

ZFS was made by Sun Microsystems, which was a dear, awesome company that educated, fed, clothed and put bread on the table for an entire generation of computer professionals outside of Sun Microsystems, not to mention paid millions out of their own coffers to open source a reference implementation of a System V Release 4.0 UNIX. And to top it all off, Sun Microsystems made awesome hardware.

  Sun kicked butt
  had fun
  didn't cheat
  loved their customers
  changed computing forever.

Solaris is used in life-critical environments, like for example medical systems or energetics. Anything that's absolutely life critical and must run for thousands of days without rebooting. And it's really nice for running software because of its advanced features like the runtime linker, zones containerization and fault management architecure features like SMF. It's awesome software on awesome hardware.

"How would a mirrored boot work in practice?"

The same way it has worked for the past 30+ years: the firmware boots from first designated boot device; if that device isn't bootable, it moves on to the next one. The next one boots since it's part of a mirror and has all the necessary data to do so, and in the rare case where the device is "half bootable" one would simply intervene and select the next good bootable device manually.

Not by hand! With configuration packages in OS-native format!

1. When a system comes in, it is scanned and entered into the asset management database, which then triggers a process to enter the scanned MAC address into the DHCP, by generating a new DHCP configuration package.

2. the previous version of the DHCP configuration package is upgraded with the new DHCP configuration package.

3. the system is hooked up to the network and powered on.

4. the firmware is permanently reconfigured to boot in this order: 1. HD0 2. HD1 3. network.

5. since HD0 and HD1 are not bootable, the system boots from the network, whereby the infrastructure automatically provisions it with the standard runtime platform, which consists solely of packages in OS-native format, including configuration packages which configure things which all servers have in common.

6. as part of the automatic installation, the server is automatically installed with additional configuration packages based on which profile it is in, turning it into a specific application server.

7. the server comes up after automatic installation, and reports back to the infrastructure that it is ready to serve.

NEVER by hand!

286 was a very shitty system: it had only a beeper, practically no DMA, no graphics hardware acceleration of any kind (not even hardware scrolling; sprites were science fiction). Almost everything in that shitty PC bucket was driven by the processor, and that processor was dog slow.

It takes a month to set up a Kickstart infrastructure (DHCP, TFTP, NFS, Kickstart profile(s)),

a day to three days for an experienced system engineer to package the components,

and a week to three weeks to test and package the configuration (by automating in %pre and %post of the RPM's).

That's far less than one year, and far less than it takes to set up Kubernetes, Terraform, Docker and a complete CI / CD pipeline.

I don't understand how anyone could leave the job half-finished and compromise in this way: in these scenarios, almost all the legwork is done to also build a compiler, for those times when the interpreted code runs just right and is ready for production. Why are such interpreters never finished into a compiler?

You are not supposed to "identify" anything on UNIX-like operating systems; that is what the file(1) command is for, specifically, especially so since the entire concept of UNIX is that everything is a stream of bytes.

Attempting to manually manage files in this way defeats the purpose of the OS abstracting it away for the user; and the users of your executable should not have to care what your executable is written in because you grew up on a PC-bucket whose operating system stems from CP/M -> MS-DOS!

This was a good article, and more such articles with examples are needed because understanding how pointer aliasing works can yield significant performance gains, since the compiler can be directed to make optimizations it would otherwise not make.

Maybe before starting to teach others, you should teach yourself how to cleanly package your software into OS packages, instead of peddling around MS-DOS style shell scripts with a .sh extension. Didn't anybody teach you that UNIX-like operating systems purposely do not use extensions, in order to abstract the implementation language of the executable from the user?

How the hell are you going to properly teach others, if you have such knowledge gaps yourselves?

It's blind leading the blind again; boy does this make me mad.

Dedicated controllers were absolutely out of the question because nobody could afford them, which is why Amigas were so popular: a fully multitasking, multimedia computer for 450 DM. That's 225 EUR! Somebody that cost sensitive won't even consider a dedicated controller; back then wasn't like it's today.

This was at a time when 3.5" floppy disks were expensive (and hard to come by), and hard drives were between 40 - 60 MB, so 130 MB was quite practical. The floppy drive in the Amiga read and wrote at 11 KB / s.

And yes, this was a DAC and an ADC in software, with added Reed-Solomon error correction encoding and CRC32. The goal was to be economical. The end price was everything; it had to be as cheap as possible.

This works on the same principle as the video backup system (VBS) which we used in the 1980's and the early 1990's on our Commodore Amigas: if I remember correctly, one three hour PAL/SECAM VHS tape had a capacity of 130 MB. The entire hardware fit into a DB 25 parallel port connector and was easily made by oneself with a soldering iron and a few cheap parts.

https://www.youtube.com/watch?v=VcBY6PMH0Kg

SGI IRIX also had something conceptually similar to this "YouTubeDrive" called HFS, the hierarchical filesystem, whose storage was backed by tape rather than disk, but to the OS it was just a regular filesystem like any other: applications like ls(1), cp(1), rm(1) or any other saw no difference, but the latency was high of course.