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.
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.
This is factually incorrect, which is why you were (formerly) downvoted. The ST was Jack's baby, the project he started (along with Shiraz Shivji, etc) after Atari Corp founding -- definitely not before Jack's time. In fact I believe prototype development started under another company name before Atari Corp was official.
Not to mention Jack was pulling same crap at Commodore, constantly pumping more and more pointless incompatible systems claiming to fight imaginary war against bottom of the barrel Sinclair (already going bankrupt at the time), Timex, TI, Tandy etc, all while Commodore was already commanding almost 50% market share https://jeremyreimer.com/rockets-item.lsp?p=137 with just one model (c64).
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.
- 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:
...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.
I hear people say that, yet Sun Microsystems is the company which created the CDDL to be intentionally GPL-incompatible[1] and then made a filesystem which they licensed under the CDDL. Then they sold themselves to one of the worst tech companies. Not exactly the behaviour I would expect for an awesome company.
Yep. Two of my local colleagues were actively working with Open Group until then, fixing UNIX compliance bugs, running the test suites, producing the reports etc.