Annatar

We all have our delusions.

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.

Clean bash would mean that it is portable; that bash script will only work on Linux, whereas it will horribly break everywhere else.

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

The problem wasn't that he didn't care, but that he sunk his own private fortune made at Commodore into ATARI, and that ATARI was always teetering on the brink of bankruptcy. They never had enough money, it's amazing that they were able to produce anything at all! And the ST you describe was before Jack's time.

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.

Which compiler did you use?

Did you generate an executable machine code image with it?

How are you drawing graphics with Lisp (SDL, DirectX, OpenGL, something else)?

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 UNIX 03 certified. Solaris is actually a reference implementation platform for:

- TCP / IP; - NFS; - POSIX; - XPG4; - XPG6; - SVR4.

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!

Ansible is like a fifth wheel on a car, since all of the configuration can be done inside of OS packages, and orchestration can be done via SSH (which is exactly how Ansible does it). Put those two together and Ansible is a solution to a non-existent problem.

It's not a shallow dismissal, it's the scourge of our industry; I can't wait to retire so that I would never have to look at it again. Give it a rest with virtue signalling.

How is inventing yet another complicated machinery to churn out some HTML and JavaScript innovation?

Utter nonsense. People are laughing their asses off at the amount of idiocy on this web site.

Who exactly is being influenced?

You've heard of this thing called "Twitter"?

Actually “Hacker” “News” has been a point of ridicule for quite a while now outside of the bubble here, so arguing that it’s an opinion forge plays right into its notoriety.

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.

Except that a JIT is still not a compiler in the conventional sense. I am specifically referring to a program capable of generating and permanently storing machine code on stable storage.

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?

It does not benefit me: you mistake niceness for kindness. There is little I can learn from you and your guideliness when you yourself cannot tell which is which.

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.