darnir

Paperless-ng (https://github.com/jonaswinkler/paperless-ng) is the way to go. I have an instance of it running on a RPI 4 and a network attached scanner. New documents that I need stored are either immediately scanned using the app on my phone (And its free software, get it from FDroid) or via the actual scanner which obviously gives better quality.

Paperless then OCRs the documents and stores the original and a PDF/A version for long term archival. It learns from my tagging and classification and auto classifies them in the future.

The web interface is also pretty slick and allows you to do full text search on all your documents really fast.

Tagging and categories is also a more superior form of organisation than simple folders.

Public SMTP server issues reminds of the classic 500 Mile Email: https://www.ibiblio.org/harris/500milemail.html

Would you mind sharing the paper on pinning? I'd be interested

BTW, the Wget that comes built-in with Powershell is not GNU Wget. But a weird abomination from Microsoft. They just call it Wget despite it having nothing to do with the original

Or even simpler use `sudoedit /path/to/file/`

> This was never meant to be anything serious.

Remember the Linux kernel was introduced to the world with pretty much those exact words.

The Ultimate Hackers Keyboard has exactly that as a module you can attach to the keyboard.

HTTP/1.x is anything but simple. They were under defined and overly complex in many ways. The original RFC was so complex that when reworked, they split it into 6 documents.

I've worked heavily on some HTTP implementations and its ridiculously hard to get them right.

Not to mention, this "server" only responds to a simple well formed GET request. Without handling about 90% of what the HTTP specifications talk about. Its a nice project, but it doesn't speak to the simplicity of HTTP

Well, for GNU Wget, we've moved to Matrix since two years now. The public room is bridged to IRC.

I absolutely dislike it when people decide to simply gloss over the licensing parts of code. Code licenses are a crucial component and you should really know and understand the implications of the license you pick.

This is even more important in the kernel as it changes the set of symbols available to your module.

You can reach me on my username on the gnu org domain

You can always contact various GNU projects directly. The list of projects we had available for 2021 are listed here: https://www.gnu.org/software/soc-projects/ideas-2021.html

You can also try to get in touch with multiple projects via the gnu-soc mailing list on the gnu domain.

If you'd like to contact me directly, you can reach me on my username on the gnu domain.

I'm a long term GSoC mentor and org admin. In my experience most free software projects are always happy to have new contributors. And if you ask, many will gladly hand hold you through the initial stages.

In fact, personally speaking, I would be more willing to do so outside of GSoC than within the confines of a Summer of Code program. Usually because it indicates a slightly greater level of interest, and more importantly we're not under a time pressure to get things done. It's more relaxed this way making the whole process more enjoyable.

Hit me up and I can introduce you to multiple projects within the GNU ecosystem that would love to have a new contributor.

The larger GNU projects that have the manpower and ecosystem to deal with this on their own usually apply separately. The GNU ecosystem is much much bigger than them though. And its the smaller projects that usually benefit the most out of GSoC. So its quite unfortunate that GNU has been left out this year.

I started out as a GSoC student for GNU Wget 10 years ago and am now the maintainer. Many smaller projects like GNU Poke, MHD, coreutils, lilypond, Guix, etc. do really rely on a fresh batch of contributors every year that we try to convert into regular long term contributors.

Is that on the roadmap? I was under the impression that native video calls will never happen. They might bundle jitsi automatically with the homeserver though

And then also, please don't parse the PSL yourself. Use an existing library[1] for that. The formal algorithm for finding the TLD is more complicated than you realise at first glance.

I would recommend libPSL[2]. It was written by one of the maintainers of GNU Wget and is currently used by both GNU Wget and libcurl.

Disclosure: I was one of the early contributors to libpsl and closely involved in its initial formation.

[1] https://publicsuffix.org/learn/ [2] https://github.com/rockdaboot/libpsl

Awesome! Now show me how this is done in Mercurial

Even that is not enough. The cache may make everything faster, but it could lead to higher contention on a different physical resource slowing things down there. The cache cannot be guaranteed to prevent that.

Nice work! I've actually been working on writing something like this for a while now.

Do take a look at https://gitlab.com/darnir/matrix-shell-suite

It's a basic matrix client written in pure POSIX sh.

Configurable. Default extension type is sig. However you can specify a list of extensions and it will attempt to verify against the first it finds.

Another feature not mentioned in there is support for verifying GPG signatures of binaries you download.

If a gpg signature file exists, Wget2 will automatically verify the binary against that signature file

Debian packages the alpha version. Arch AUR has it as well.

Other distros will follow soon

For now you need to explicitly use wget2 as the binary.

Over time, the wget binary will be replaced with wget2. The transition should happen smoothly and slowly the same way as the gpg -> gpg2 transition happened.

Source: Am maintainer

Yes. It does not support plaintext http2.

Nope.

Wget2 was required since we wanted to break some backward compatibility with Wget 1.x releases. So we decided that a major version bump is warranted.

It is also an entire rewrite of Wget in order to support HTTP/2. But this won't be required again when HTTP/3 or other protocols come out

Wget2 has been in development for a few years now. It is meant to be a drop in replacement for Wget with nearly full backward compatibility with all the old switches. In most cases you can replace wget with wget2 and not really realize the difference. For the known differences, please refer to the documentation in the gitlab repo.

There's still a few rough edges though. And we very much welcome any criticisms / bug reports about the same.

Yes. On Arch Linux you would use just pip. pip2 for Python 2.

GitLab. We at GNU Wget have almost entirely moved all our development processes to Gitlab and its been amazing.

The CI integration is far better than what github + Travis offer.

Gitlab has been steadily improving and I don't see any lags and slowdowns which used to be a thing in the past.

Not to mention that they are far more open about their platform and don't enforce propriety scripts on you.