nyan4

How about a FLOSS archive that provides peer-reviewed and signed application from a trusted source only? Automated security updates? A security team that can provide fixes independently from the upstream authors?

...because I just described how Debian worked for the last 20 years.

> It was also funny to see "Windows" as an approved security blessed OS and then Debian, Ubuntu, OpenBSD rejected

Bribes always help.

Project name an URL?

> Why did we go from [...] talking about how all software will some day be free to being afraid to seriously consider the proposition?

HN is clearly not attracting much of the FLOSS crowd.

The two are very connected. Yet, even with dynamic linking, the libraries could be always and only bundled with the application, and the application could be designed to work against the bundled versions and not even tested against other versions. On a practical level this makes it extremely expensive to perform updates.

...until the unfortunate end user that needs to run tenths of systems runs in a security issue. Then the admins cannot possibly learn how to fork, patch, rebuild, test, deploy in 20 different languages. And they cannot rely on security updates from Linux Distributions because they installed vendorized code blobs.

> And people wonder why big enterprises are scared of touching open source stuff.

some open source stuff. Most enterprises dig distributions, especially with LTS.

> before going into production

How about 3 years after a release? 5, 8, 10?

This is a decade old lesson, well understood by few developers that want their code to be around for a while.

The HN "web developers" are a different crowd.

This criticism usually comes from people that do not use Nim. I was very surprised as well at first - now after 1 year of using Nim I realize I never run into any trouble because of case/underscore insensitivity.

#1: those variables have to be in the same scope or be procs working on the same types to be an issue.

#2: I don't use nimgrep, I just keep a consistent style across my files. When reading somebody else's code, case-insensitive search is usually enough.

If only people stopped writing this stuff in javascript.

> Debian seems to have no problems with that.

Because Debian developers do not package all sort of crap.

A lot of people like to think that software fragmentation comes without any drawback. Having many tiny libraries and/or multiple versions hurts in the long term.

> Recursive dependency resolution is nice and all but isn't this going to create a massive technological debt that needs to be maintained?

Spot on. Imagine deploying an application, in 2018, that pulls down 1000 libraries, 300 of which are 6 years old versions and contain vulnerabilities (or just bugs) involving data on transit. Who is going to do all the work to backport fixes in every affected version of each library?

> web developers

That's the problem.

Nim has a powerful templating system that allows introducing new syntactic elements and semantics, but maybe you are thinking about generating output code in multiple languages (C, C++, JS...)?

This comparison is just silly, the context and the implications of the 4 points are entirely different.

"I have kids to feed" was used to justify many atrocities throughout history.

It's terrible indeed, and it works only if javascript is enabled.

Not illogical at all. Cost makes a huge difference.

Nim is really underrated.

*Tor

It's spelled Tor, non TOR

What's the threat model here? Is the potential adversary able to do MITM?

- The DHT does not anonymize the poster ipaddr, the post contents, posting time and other metadata

- same for the reader ipaddr, what was reading, and when

Nim GC is optional; It can be disabled to write system libraries.

> mvn, npm, composer, gem, and pip all work just fine

...for you.