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.

The BEAM is a preemptive VM.

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.

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.

Vacation is not about having less work. Vacation is about doing something different than you do usually, on a different schedule and probably with no big expectations to meet. Helping one's uncle to build a shed can be vacation to some people. Writing a program one wanted to write for a long time can be vacation, too. Spending three weeks in one's shop on woodworking can be a fulfilling vacation as well. So can be going on an international tour or doing nothing but reading seven different novels one after another.

My guess is that it's because learning a different paradigm is difficult and you don't see its benefits until you're proficient with it. It's like learning functional or logic programming.

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.

So you have discovered how we were using chroot for decades. Congratulations.

That's not disrespecting HTTP standard. That's the consequence of using HTTP in place of a proper RPC protocol.

All those things sound like antipatterns to me. If your application is supposed to fetch HTTPS pages then there should be an integration test for that [...]

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

Sure I can remember. Checking libraries the binary uses ("why this cURL fails on HTTPs? oh, it's linked against GnuTLS, that explains everything"), injecting your own library, intercepting a function (maybe syscall, or rather its libc wrapper), tracing function's execution (ltrace). All these things merely annoy if you used to have them but now you don't and it's hard to remember them all, but there's a lot of them.

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.

I doubt anyone can answer this for you, but why shouldn't it be [popular in the industry at the moment]?

Its build system is poor if you want to rebuild the binary from the same sources (you can't precompile the libraries used), and the statically linked binary may be nice for a one-off deployment ("fire and forget" mode), but for repeated deployments and multiple versions running at the same time it reminds me the Chinese torture "death by a thousand cuts" in what you can't do with such a binary (dozens of small things that are hard to remember, each on its own not being enough to go away from static linking, but boy, they do add up).

My company-supplied Dell Latitude 7480, running Debian stable with its stock kernel:

- M2 SSD requires changing some BIOS preferences to work on Linux

No BIOS fiddling, except for disabling Thunderbolt security for docking station to work (external monitor, network card, USB ports including keyboard, second sound card (though no volume control here)). But this is because Linux kernel doesn't support it yet.

Or maybe I did change its "RAID" to something that's not a lie, I don't really remember.

- Nvidia graphics card is a pain on Ubuntu. Do a Google search for nouveau.modeset

Mine has Intel. I had no problems with running it.

- The fans are on most of the time, even during idle. The machine isn't hot either - it just likes to run the fans

Quiet most of the time.

- The 1920x1080 screen isn't that great and a "4K" option is quite expensive

1920x1080 gives way too small bitmap fonts on a 14" screen. I'd rather have 1280x800 or similar, but nobody ships that resolution anymore.

- The carbon-fibre looking plastic looks cheap and is a magnet for finger prints. It does not look good and is difficult to clean

The plastic seems OK, but maybe I don't know what to look at.

- It's not a great machine to move about with. Mine weighs almost 2KG

1.5kg

- No Ethernet port unlike a T470. You need a USB adapter

Ethernet port present.

I know you'd happily bash PHP author for such an incomprehensible error message, but it's not his own message, but something that comes from Yacc/Bison, when the next parsed token is not what can legally follow whatever the parser read up until now. It's just the tokens (or maybe just this one; I haven't read the grammar) were not named in currently canonical English.

Ada?

Note that blockchains are not distributed databases. They're document timestamping services.

Who the hell even prints anymore from a personal computer?

Dude, I print fsckin' source code to read. I specifically bought an office-grade laser printer with a print server built in so I could do so. I also occasionally print parts of books and helpers for role playing games (character sheets, snippets of the handbooks, tables with prices and test difficulties and whatnot).

Printing for personal use is very much alive.

And then we go back to processes, System V-like IPC (shmget()/semget()/msgget()), and network configuration subsystem (routing, firewall, bringing interfaces up or down, and the like; netlink is only a recent development, after 2000).

What was it about the mantra again?

Note that he only yells at people who have a long track of submitting patches, so he already has an established relationship with them. From what I hear repeatedly, he's polite and helpful towards the newcomers.

And then you hit ioctls, which are necessary even by the very file-like way of working with terminals. The slogan in the unix world never matched anything well, or at least never since '90s.

[SIOCSIFADDR] is a thing, although it targets a socket on the interface, not the interface itself.

If we're cheating by using file descriptors instead of files, then you could go all the way and used AF_NETLINK sockets, they allow you even to set routing or firewall. That's kind of not the point.