> Edit: it looks like we've already had to warn you about not being a bully on Hacker News. Moreover, it looks like you've been posting like this a lot.

OK then, please be more specific here. You're being so generic that I can't tell what exactly is wrong with my posts (apart from being disliked) and what should I change to keep me from being banned. The only thing I can think of is to stay away from any commenting at all. If you criticise from your high horse of being a moderator and wielding the power to ban people, at least be constructive in doing so.

Keep the proper terminology. If you omit words left and right, it becomes incomprehensible garbage.

> If you want to know what it does, read the specifications

The whole point of README is to say what it does so I don't need to read specification that will be useless to me.

> or at least the first sentences of the README :)

I read it. The wall of words you cited says nothing about what it does and what purpose it serves.

Also, what the heck does it do? Neither README nor title says anything about that. The closest thing to such description is mentioning that it "supports multimedia", whatever that means.

There is this old tinyCA that comes with OpenVPN, but it's awful and can't do much (I don't even remember if it could revoke a certificate). There are a few instances of WWW-only CAs, and there are desktop/GUI applications. But command line? /usr/bin/openssl only, and it's unwieldy. Even worse situation with a CA library.

People like to fetishize OpenSSH's CA (for both client keys and server keys), but there still a lot to do before it becomes usable. (Though the same stands for the traditional save-on-first-use method, honestly.) You're basically proposing to deploy software that maybe will be usable in a few years, with a big "maybe", because until now it haven't materialized.

Or use a distribution that does not break shit left and right, like Debian or Red Hat (CentOS).

> Unless you have the wall clock time to actually define and test supported distributions you probably want to pretend the system python doesn't exist.

If you write software that will be run by others (which usually means open source, probably libraries), yes. If you write software that will only be run by you (pretty much all dynamic websites a.k.a. webapps land in this category), you don't want to have three different distributions in half a dozen different versions anyway, so you can pin yourself to the target environment just as well.

> What about simple session cookies? You need to give end-users the information on how your service uses cookies, if I understand it correctly.

No, from what bigger half of the internets says, you don't need consent for session cookies (the ones that are necessary for login form).

> if you have something like a login form, you'll need to collect email addresses (or something else users can use to reset their lost passwords). This is personal information, which is subject to GDPR.

Nope. For keeping login (especially if you don't require logging in) you don't need separate explicit consent.

>> Open source that doesn't steal users' data is already GDPR-compatible.

> I don't think it's that simple.

I think it is.

Those were never necessary for operational purposes. If you were selling your users to get Google's analytics, that's a different matter.

> privacy statements or EULAs in your product, so it's easier for your users to deploy the software legally to their audience?

Don't collect user's data, then you don't need privacy statements nor EULAs about that.

> Do you leave it to your users to collect and provide the information about your product?

Are you Microsoft or Homebrew team that you steal users' data unless opted out?

> And also: How do operators handle the issue if the Open Source product they are hosting did not prepare for GDPR?

Open source that doesn't steal users' data is already GDPR-compatible.

The BEAM Book shared by armitron disagrees: https://happi.github.io/theBeamBook/#_scheduling_non_preempt...

Though an Erlang programmer never sees this in practice, because compiler inserts yield points appropriately.

Erm... The old drivers stopped working with this particular device?

I had a very similar case with perfectly good HP laser printer, which doesn't work on Window 10 anymore because... dunno? No drivers from HP, though. I'm sure it would work just fine with generic PCL or PostScript driver under CUPS.

> Later, a HP MFC caused endless pain, seemingly every other Arch update broke one of Bluetooth / printer of MFC / scanner of MFC.

Well, that's probably self-inflicted because of your choice of Arch, not because Linux (e.g. Debian).

> Plain Wifi eventually worked more or less (but see the endless string of bugs with 5GHz) but enterprise wifi always has been a pain.

Enterprise Wi-Fi has always been a pain, also under Windows.

> The strange F5 VPN our company used was not particularly Linux friendly

VPNs are usually that way. Very few companies can write sensibly working software that would run under Linux.

> -- I could only get it to work by running Firefox as root (yuck!).

You get pretty much the same under Windows, though you don't see it as clearly.

I don't get why you bash Linux. Windows has the exact same problems.

Now we have the same situation with DNS, but let's add more choking points, it surely is a good idea.

Ansible gives you merely a way to execute commands on remote servers. Much touted idempotency is not a game changer, it's quite easy to achieve even if you write everything yourself.

CFEngine requires a different mindset, you need to (a) think of the servers running independently and (b) configure groups (classes) of servers, not individual servers, even grouped in a list of some kind, like Ansible works. Suddenly an environment becomes much easier to manage.

It's not something to regularly rely on, but something that helps in debugging and troubleshooting. Not for a programmer, but for a sysadmin.

> Having shared objects on the machine actually makes this impossible because your tests are running with different libraries than in production.

In such a case you have your deployment process broken. And if your testing and production environments differ in this matter, they differ enough bite your ass even with your statically linked binary.

> Shared libraries on a machine are a non-hermetic input to your build and are to be avoided.

This is merely stating a generic opinion. I want to see a concrete, coherent, technical argument supporting this.

> In addition, runtime shared objects (especially of something performance-critical like crypto) inhibit all of the most important compiler optimizations like inlining.

Especially crypto should not be called in a tight loop, but passed a large chunk of data. Otherwise you inhibit all of the most important defence against side channel attacks, and I guarantee that you are not competent enough to defent against that on your own.

> As for ltrace, there's a million ways to trace function calls these days, like uprobe or perf.

So let's break one of them for no good reason?

And still, lack of any of the mentioned things is merely an annoyance once you hit it, but as I said, they are numerous and add up, while the other option, static linking, provides little benefit apart from supporting broken workflows (like different environment in testing and production).

And then there's also sharing memory between different processes that use the same library. You don't have that for a statically compiled binary.