dozzie

> Please don't go into attack mode here. [...]

> 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.

Of course it doesn't need to be audio nor video. It doesn't change the fact that you used a term that has more than one meaning without providing any context in which to interpret it. If somebody misreads it, then the problem is with your prose, not with the reader.

That's a big surprise, I thoguht it's about sending audio and video somehow.

> Ciao dozzie, I have omitted "implementation" from the title because I thought that was obvious enough. It seems not.

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.

Protocol cannot be open source. It can have a full specification published. A protocol does not have a source code, it's something that its implementation can have.

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.

So basically you're using an overcomplicated chroot as nothing more than chroot.

Yes, I've seen. Even more unwieldy than OpenSSL's one, and you need whole Hashicorp's thing, too.

If only there was a certificate authority management tool that was convenient to use from command line and through an API, so it could be made into a company-wide service.

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.

> And unless you're aggressively tracking your distro's package releases you'd better hope that the new libdep doesn't introduce any breaking bugs.

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.

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

> 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.

> Are you including cookie banners,

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.

> Samsung stopped making drivers for their MFCs so I needed to toss a perfectly working laser MFC because it stopped working with Linux, just like that.

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.

Why? Because you want somebody to be able to censor out your whole website without notifying you and without giving you any meaningful way to protest (CA revoking your certificate and giving you as much support as Google gives to its non-paying users or PayPal to the sellers).

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