Your argument fails at the starting line. Age verification is "necessary" because the law of the land requires it.

You can wail and gnash your teeth all you want at application authors, OS vendors, and so forth, but at the end of the day, it's their asses (and bank accounts) on the line, not yours. Don't like it? Direct your wrath towards your governmental representatives; the odds are they were directly responsible for enacting the shitty regulations that everyone else is stuck having to implement.

That makes as much sense as getting angry at Intel because IBM chose to use the 8088 in the 5150 PC.

Except you're comparing apples to oranges. In the systemd case you manually created a unit, interactively started it, and manually debugged it (also interactively). In the sysv case, you ... copied a file, manually started it, and assumed it worked properly because no errors were reported on the console (which is _very_ dependent on the service+script in question)

If it failed to start in systemd (ie step 4), you'd have been told immediately. you could also run 'systemctl status oolama' to get the, well, status including the last 10 or so log lines including stdout/stderr/syslog output. no need to play with mucking with the logs. Which is a much better starting point than debugging "sometihng went wrong" in the sysv script world.

(BTW, you created a bunch of extra work for yourself in the systemd case, 3+4 are trivially combinable. And do you really want a service manager to automatically reload+apply changes you're making while you're interactively editing its configuration? FFS...)

In other words, you learned to do something one way, and now you're too damn lazy to learn anything else.

The "Unix Way" is "do one thing" -- not "do one thing well", because the priority was on the simplicity of implementation -- over ease-of-use, consistency, and even correctness.

I'll grant you that sysvinit (barely) does one thing, but only Helsinki syndrome sufferers would think it does that one thing "well".

Please explain why is it okay to reference/look at other stuff in a SysvInit world, but not in the systemd world.

And, pray tell, what does logging format have to do with writing launcher scripts?

(Incidently, journald is so vastly superior to the previous logging environment because it captures *everything* a service produces -- stdout, stderr, and syslog -- and serializes/timestamps it into a single stream. No need to play games redirecting (or not) the program output and correlating that with syslog.

Pray tell, what "portability standards" apply to how a system boots and manages itself?

The only thing that UNIX(tm) and POSIX mandates is that PID1 is the ultimate child-reaper, and MUST NOT DIE. Otherwise.. every CertifiedUNIX(tm) did things entirely its own, non-portable way. Yet another reason why Linux won, even before systemd.

(Meanwhile, are you seriously asserting that you are running production workloads on a modern non-Linux UNIX? And if you are, please enlighten us as to how those UNIXen manage themselves. Hint: It's not sysvinit!)

Each 'config file' is a bog-standard "ini" file, whereas your script (which is likely *much much* longer than 20 lines and calls numerous external tools, each with their own cmdline syntax/configs etc) is freeform bash (or zsh, or csh, or heck, even a compiled binary) file.

Meanwhile, are you seriously saying that you can write a crontab or a new sysvinit script (or [x]inetd hook, or, or, or...) without *ever* looking at _any_ documentation (or another example)? Note that "write the script" is not enough here, you also have to properly integrate it into the correct place in your distro. Which is different from most other distros out there, because $freedom or sometihng. Quick, what's the correct set of symlinks you need for each runlevel? And if you answer "but my distro has tools to manage that for me", congrats, what's the syntax for the embedded comments in the individual scripts to enable those tools (eg chkconfig) to run and set things up in the correct order? And how, pray tell, did you know how those things worked without reading some sort of documentation?

FFS, y'all are such hypocrites.

You mean... like the former JCPOA with its sharp enforcement teeth? (that everyone other than Trump's ego agreed was actually working before he tore it up?)

Over the past half-decade (ie since the current "country" has existed), Iran has not been the aggressor in any of the conflicts it's been involved with, nor has it broken any treaty it has signed. Why do I bring this up? Because the other side -- namely US (and Israel's hand up Trump's posterior) has repeatedly been the [direct!] aggressor, and also demonstrated that it cannot be trusted to adhere to anything it signs.

Uh, Trump tore up the treaty we had with them and unilaterally re-imposed harsh economic sanctions.

That's practically a textbook definition of "stopping them from investing in their own future"

(Meanwhile, he's in the process of repeating the NAFTA->USMCA process and "negotiating" a *worse* deal than what we had before, and branding it as a victory)

It's not that "they removed 10Mbps support" so much as the underlying ethernet hardware (MAC and/or PHY) used by that new router simply doesn't support it. Might not even support 100Mbps either; once you cross into multi-gigabit world, sub-1Gbps support is the exception rather than the rule. Why? Because that would require a more complex (ie expensive) design and be utilized by almost nobody.

The 80486 processor was _technically_ capable of addressing 4GB of RAM. But given that the largest 30-pin SIMM produced was limited to 16MB (due to 24-bit addressing) in practice the upper limit was 128MB, using 8* 16MB SIMMs. (I'm not aware of any mass-market motherboard with over 8 30-pin SIMM slots, but I'm willing to be corrected) Late 486 boards supported 72-pin SIMMs which could theroretically go up to 128MB, but the largest FPM (not the later/faster EDO!) SIMM I was able to find is 64MB, and those 72-pin-equipped 486 boards appeared to still be limited to just two slots, again, for 128MB effective max.

(Additionally, many motherboards were limited to using only 16MB or 32MB max RAM due to cost-cutting with respect to the onboard L2 cache)

And sure, you could use a nice flashy GUI on an Amiga 500 with its M68K and 512K of RAM, but that doesn't mean the A500 is terribly usable for real-world tasks today. Like it or not, folks expect modern $10 systems to achieve far more than what was state-of-the-art thirty years ago.

...Because that's the upper limit of high-end 486 motherboards.

The 80486 was essentially e-waste by the year 2000. Even ultra-conservative Debian completely dropped support for the i486 over decade ago (with Squeeze going out of LTS in Feburary of 2016 after a 5 year run)

Incidently, the first Linux install I ever performed was in early 1997, on an ISA-only 486DX33 motherboard +200MB pre-DMA IDE drive that I literally rescued from the trash.

Hate to burst your bubble, but this scenario has played out under every adminstration... ever. A company cannot sponsor someone for a security clearance until after they are hired, and it can easily take months for the clearance process to complete... with no guarantees of success.

These delays -- or worse yet, the strong possibility that you might fail to get a clearance -- are why folks that already have security clearances are a _lot_ more valuable for DoD/etc contractors.

(FYI: I had a roommate who later went to for Lockheed Martin, and he effectively twiddled his thumbs for six months while the clearance paperwork worked its way through the bowels of the DoD. This happened during the first term of the notoriously liberal Bush/Cheney admininstration.)

Oh noes! In order to avoid spending a little bit of money to help ffmpeg maintain a quality codebase, they'll instead spend a *lot* more money switching to something else... and still be faced with the same "maintenance isn't free" problem when they continue to freeload off of someone else's work.

(And that's putting aside the basic problem that there isn't really "something else" that itself isn't built on top off ffmpeg, which drives up the costs of switching even more. Of course, there may be commercial products that do this stuff already, but .. that's still going to cost you more on an ongoing basis than just tossing some relative breadcrumbs towards ffmpeg's maintainers!)