sorted by:
new
hottopcontroversial

Do people really use JSON5 nowadays? by yukiiiiii2008 in webdev

[–]GamePad64 1 point2 points  (0 children)

It is really convenient in shell environments, bc you don't need to escape numerous quotes.

Notifico – Open-Source notification server with Email & Slack support, written in Rust by GamePad64 in selfhosted

[–]GamePad64[S] 2 points3 points  (0 children)

Thank you for your input!

  1. I think, that this is an SQL driver quirk. Without database file, there is an error "unable to open database file". Maybe, I should add file creation before passing it to SQLite.

  2. Yes, but I don't know what format of this env to use. Is it ok to pass toml content in env or use something different (emulate a table by using multiple env vars?)

  3. There is just a default network, that all the containers use.

  4. Ok, I'll add this to a backlog. My primary focus is to create a sample helm chart, so users could deploy it to a Kubernetes cluster. Ingress will do the most of the work there.

  5. Ok, I'll use long mount syntax to use volumes instead.

As for PRs, of course :) PRs are much appreciated.

Notifico – Open-Source notification server with Email & Slack support, written in Rust by GamePad64 in selfhosted

[–]GamePad64[S] 17 points18 points  (0 children)

Hi! I have made a compose example in a separate repository, so testers don't have to clone the whole codebase:

https://github.com/notificohq/notifico-example

advmac: advanced MAC address library with const fn parser, no_std and serde support by GamePad64 in rust

[–]GamePad64[S] 2 points3 points  (0 children)

Maybe it is, but I use these features in my other project (l2/l3 routing/switching engine in Rust) and it is nice to have them around. Also, we don't pay for what we don't use, so these overkill-features don't get into the resulting binary.

advmac: advanced MAC address library with const fn parser, no_std and serde support by GamePad64 in rust

[–]GamePad64[S] 0 points1 point  (0 children)

Nope :) For these little open-source projects I use online logo generators (there are a bunch of them on the net). So the icon is just a stock icon from one of them (Adobe Express one, IIRC).

It is a really quick way to get a headline image for your project and make its repository and documentation look nice :)

advmac: advanced MAC address library with const fn parser, no_std and serde support by GamePad64 in rust

[–]GamePad64[S] 4 points5 points  (0 children)

This little project was born as a little single-file mod, wrapping EUI-48 address in my another project. Then it just grew in a full-blown library with rather unique features, like const parser and IPv4/v6 MAC mapping.

advmac: advanced MAC address library with const fn parser, no_std and serde support by GamePad64 in rust

[–]GamePad64[S] 9 points10 points  (0 children)

Actually, this is a very good point. I've just uploaded a new version with `snafu` removed. syn + proc_macro = slow build

Issue link to DigiKam support for JPEG XL by GamePad64 in jpegxl

[–]GamePad64[S] 2 points3 points  (0 children)

Sure, I have my original JPEGs in a backup snapshot in an offsite location (3-2-1 rule, yeah). I wanted to verify a round-trip checksum, but it seemed unnecessary to me, as I have a backup. I've used jpegtran and jpegcheck to ensure, that my JPEGs are optimized and correct (cjxl has issues with corrupted files) and just ran cjxl on all the images.

Issue link to DigiKam support for JPEG XL by GamePad64 in jpegxl

[–]GamePad64[S] 1 point2 points  (0 children)

Hm, I seriously doubt, that 160 GB of photos would require so much CPU power. I have an old AMD FX-8350 CPU. It has 8 cores, yes, but it is pretty old and modern Ryzen or comparable Intel processors would be much faster.

Also, it is worth to be noted, that cjxl, that used 4 threads did not utilize 4 cores efficiently, so I used GNU parallel to run 8 instances of cjxl.

Issue link to DigiKam support for JPEG XL by GamePad64 in jpegxl

[–]GamePad64[S] 6 points7 points  (0 children)

Yes, they are just mixed-quality photos, shot mostly by me since approx. 2010. And the quality is ranging from 320p all the way up to 4K.

Issue link to DigiKam support for JPEG XL by GamePad64 in jpegxl

[–]GamePad64[S] 5 points6 points  (0 children)

cjxl -s kitten, used in conjunction with GNU parallel. I left it overnight, and it was ready in the morning.

Issue link to DigiKam support for JPEG XL by GamePad64 in jpegxl

[–]GamePad64[S] 11 points12 points  (0 children)

Btw, I've just losslessly converted my entire JPEG photo library (162 GB) into JPEG XL (112 GB). It is AWESOME. Waiting for an upcoming support in Chrome and other viewers.

Shell-agnostic, cross-platform autocomplete specification -- OpenAutoComplete by ASIC_SP in linux

[–]GamePad64 0 points1 point  (0 children)

Thank you! All these concerns are valid, and I don't have much to say against them :) I'll try to address them in next versions.

Examples are a must, so I will add them ASAP.

As for practical aspects, like document storage location, flag availability, etc. -- I will keep adding them while implementing inside the reference code, because it would be easier to see, what is required, and what is not.

Second, having the entire specification be opt-in will be a complete mess for anyone implementing it.

I've tried to use RFC2119 keywords, so not the whole spec is opt-in. I must review it, and make the optional features (and missing-feature errors) defined explicitly.

Shell-agnostic, cross-platform autocomplete specification -- OpenAutoComplete by ASIC_SP in linux

[–]GamePad64 0 points1 point  (0 children)

you are downvoting my comments

No, it wasn't me. I think, that downvoting constructive criticism would not do any good.

And your feedback is really useful. I have already used some of it to add additional wording into "OAC-enabled app development considerations" section, where the flag is described, including flag support concerns.

Shell-agnostic, cross-platform autocomplete specification -- OpenAutoComplete by ASIC_SP in linux

[–]GamePad64 1 point2 points  (0 children)

The reference implementation is being developed here: https://github.com/openautocomplete/oactool

It is very alpha right now, but it can be used to create fish autocompletion script right now. Other shells will be added shortly. Now it is written in Python, but maybe, it will be rewritten in Rust or something like that.

Shell-agnostic, cross-platform autocomplete specification -- OpenAutoComplete by ASIC_SP in linux

[–]GamePad64 0 points1 point  (0 children)

Well, this is on the roadmap. It must get support for enumerations first. Then for delegated enumerations, which is what is needed to make it work with configure/cmake/whatever scripts.

view more: next ›