> 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.
> "It is a valid tool to quickly and comprehensibly build a network of devices. Visit wiki and documentation to know more about the PJON Standard". If this is a wall of words that says nothing about what the project is for, we are not from the same universe.
Nope, this still does not say what it does and what to use it for. "Network"
is a term used on several different levels of abstraction.
> [...] considering the amount of time and effort has been invested in docs and specs.
Well, you should probably invest even more effort in your README. What
I thought is that it was a mind dump, given it carefully omits a description
where would I want to use it and what for (you only use ambiguous terms with
no concrete context, or at least ambiguous to somebody who does not wire
a bucket of Arduinos pin-to-pin to each other).
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.
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.
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.
> 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.
> 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).
> 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.