Well I hire too, and I do not hire humorless and dispropotionate people like yourself who do not understand what professionalism means, but do revel in the limited private power granted to you by an employer as if it includes some kind of moral authority. Making some lowbrow jokes on a volunteer project is not a crime, and it does not merit being added to an extrajudicial employment black list.

How old are you that references to a penis is the height of comedy?

Is your argument that appropriateness is dependent on your taste?

I don't use it exclusively, but these features are what swung me. 1) mini map - a godsend when understanding quickly the structure of large files, particularly those you are lumbered with 2) slick multi-select and edit 3) fast search all files and interactive step though 4) same L&F on Mac, Windows, Linux since I need to use all three.

> GPS refers specifically to the system implemented by the NAVSTAR satellite constellation operated by the United States Air Force, > has for decades, and no one in the industry uses the term to refer to anything else. If an org wants to have domain squatting rights on the English language, maybe it could fucking well name its shit more creatively. It would be like a dreary large computer company calling their product the Personal Computer. If they made bread, they'd probably call it "Bread".

So? That book is not universally regarded by many grammarians (note the passive voice).

Computers are not an American invention. You did well though to nab Germans to build rockets for you.

20-30MB is larger than the deployment for enterprise applications I've written / worked on and would describe as "sprawling", but which also helpfully include substantial functionality and do useful work.

Adding that to every application download, and installing dozens of "WORA" libraries on every machine is way beyond being a little suboptimal (it's a nice demonstration of Java having completely failed to deliver on its original goals though).

> I mean, forgive me, but it seems that this is a vast improvement. Who wants a
> system that's basically a collection of scripts? That just seems so fragile and un-documentable.

Did someone tell you "script" is a bad word?

You have a choice to keep this represented in a higher layer (text file scripts laid out sensibly written in a high-level architecture-independent language), or as a set of compiled binaries forming a monolithic Windows-style system with a multiplicity of hidden inference rules.

And the current init files can be improved if you don't like the layout or want to make new facilities available - do you think it's impossible to add dependency graph tracking in a way that is accessible to scripts rather than having a "registry"?

> instead of bombing my system back into the 60s.
Ironically we were going to the Moon in the 60s and had supersonic passenger flight. We don't now.

> Why would you want to convert rich information into a string and shove it down a pipe before you make use of it?

I think you've lost sight of the purpose of an OS and the purpose of logs. An OS is not running for the sake of running an OS, and logs are not persistent structured application data, but ad-hoc information about the behaviour of the system for human consumption.

They need to be filtered, sliced, and flattened as needed *post-facto* to be of any use. Given that you don't even know what I want to log, from where, how is that going to be normalised in a centralized journal? Will it let me query by anything more than straight filter on app or PID etc - like I can already do?

> programmers need to start being held accountable for the quality of their work.
They are.

But I guess you mean that people who aren't paying for your work, and companies which aren't paying for the processes and professional services necessary for some level of quality, should hold programmers who don't have any kind of engineering or financial relationship with them accountable.

> If that really worked, there would be no QA dept. for software.
No, that's just poor reasoning.

Quality must be built-in, not added-on. QA expectations and improvement scope are largely imposed on any QA department, therefore the level of 'quality' reached can never be an absolute bar.

Developers in general need to minimise the vector product of bug count/severity that could be exposed before it gets to QA. This allows the bar to be raised, and focus to be spent on where it should be rather than catching obvious mistakes, or dealing with unnecessary performance/cognitive/configuration complexity.