jaromilrojo

hi! matter of timing I guess, development isn't stopping :^) a friend just prompted me to look at unx - fun to see if it all works with cjit

This article was never meant as a comparison between existing federated and decentralized protocols. But we do take up the challenge for the next, good idea!

Hi! thanks for your enthusiasm. I am writing a tutorial that can be fun both for experienced and newbie coders here https://dyne.org/docs/cjit

As a fun project we hacked a C interpreter (based on tinyCC) that compiles C code in-memory and runs it live. CJIT today is a 2MB executable that can do a lot, including call functions from any installed library on Linux, Windows, and MacOSX.

For anyone interested, benchmarks of the zero-knowledge proof signature closer to standardization today.

thanks for your review! tho you are referring to the tomb-portable unfinished experiment which is about to be dismissed since cross-platform experiments with veracrypt show very bad performance.

you are welcome to share a review of the tomb script, but be warned in that we use a lot of zsh specific features. It is a script that works since 15+ years so it has a discrete amount of patchwork to avoid regressions.

I really appreciate your tone and dialectic reasoning, thanks for your reply. And yes, as simple as it sounds, I believe that shell scripts help a lot to maintain mission critical tools. One hands-on example is https://dyne.org/software/tomb where I took this approach to replace whole disk encryption which is nowadays also dependent on systemd-cryptsetup.

It is 10 and more years that I experience such ad-hominem attacks.

You are so quickly labeling an identifiable professional as troll, while hiding behind your throwaway identity, that I am confident readers will be able to discern.

Meanwhile let us be precise and add more facts https://github.com/systemd/systemd/pull/31550

Our community is swamped by people like you, so I will refrain from answering further provocations, believing I have provided enough details to back my assertion.

You are distracting from facts with speculations and trolling FUD. I refer to what is known and has happened, you are speculating on what is not known.

This is another proof that systemd is an anti-pattern for security: with its crawling and ever growing web of dependencies, it extends the surface of vulnerability to orders of magnitude, and once embraced not even large distro communities can defend you from that.

A malware code injection in upstream xz-tools is a vector for remote exploitation of the ssh daemon due to a dependency on systemd for notifications and due to systemd's call to dlopen() liblzma library (CVE-2024-3094). The resulting build interferes with authentication in sshd via systemd.

The people's appreciation we get is impressive: desktop Linux users (a 3% niche in the world, I know...) really like Devuan and, in general report a better experience on distros without systemd, see https://distrowatch.com/dwres.php?resource=ranking

thanks for posting the news here, there is a lot of love and attention to detail in Daedalus <3

IMHO we should maintain GNU/Linux/BSD systems as tools that can free us, not entangle us or turn us into guinea pigs.

The world is already full of proprietary systems, including the one produced by the employer of systemd. WSL has improved a lot in the past years, he should be focusing on that, or at least use that as a testing ground.

Not confining new technology like systemd has lead to an infinite amount of CVEs to deal with in the past years, this could have been avoided by not allowing a tech prototype to bypass community adoption and impose itself as a ego-driven standard.

fixed thanks

also check https://www.devuan.org

we are very close to release Jessie stable, backed by a vibrant community

http://distrowatch.com/table.php?distribution=devuan

For those preferring an introductory video: https://www.youtube.com/watch?v=wMvyOGawNwo

I used my own C code generator for CGIs for years, along mongoose for other tasks. Nowadays I'm using https://kore.io and I'm VERY happy with it, great developer experience, well written and understandable code, minimal in dependencies and no bugs so far. I'm using it quite heavily in a project, it was easy to add templating and other amenities to it. Highly recommended.

yes... all you have to configure to be set is a file like this https://github.com/dyne/JaroMail/blob/master/doc/Accounts/de...

there can be one for each different account inside Mail/Accounts.

I think Mutt is really great software, but I cannot live without tab completion from my addressbook and I need it without spending 1h to configure it every time, so that's the gist of it...

forgot to mention it also seamlessly integrates mixmaster, so that you can just ESC-f and set `From: anonymous` directly in mutt before sending. Then `jaro send` will will weed headers and route it via the mixmaster running. Sort of handy.

You are both right. I've spent most time documenting this software into its manual, which is a PDF http://files.dyne.org/jaromail/jaromail-manual.pdf

And srsly I did not expected it to be #11 on HN all of a sudden. This is all so niche...

The code answering to your questions is mostly here https://github.com/dyne/JaroMail/tree/master/src/zlibs and here https://github.com/dyne/JaroMail/tree/master/src

The short answer is: makes it quick (make && make install) to setup all the mutt/fetchmail/abook/notmuch integrated yadayada plus adds whitelisting and folder filtering, both local and remote via sieve.

Hi there and thanks for your interest. I also started writing emails with Pine, straight after using Portal of Power as a pre-Internet BBS point ;^) Now keep in mind Jaro Mail is just a rather big wrapper around mutt / fetchmail / msmtp / notmuch with special support for generating sieve filters used by dovecot2. Credits are well due to all these programs for lasting so long and working well.

As I describe it in the manual, the primary use of JaroMail is to keep email local, yes. But as you well mention here there are situations in which it is very handy to have emails stored (or perhaps temporarily moved) on a server.

Jaro Mail so far works also in those situations, substituting the support for OSX-keyring and gnome-keyring with a simple "local keyring" storage using symmetrically encrypted (GPG) entries in an sqlite db. I'm not super-happy about that, but it works for now, it may change in the future.

Anything else is just the same, local or remote. To facilitate moving the stash around I use a Tomb which contains all what's needed - kudos to ZSh for being so lovely and portable, summed up to the small and very common unix programs used, you can imagine I never had a problem moving my setup around on desktops and servers really.

Please also note the difference between the 'peek' and the 'fetch' commands: you don't always need to use the latter, so one can have duplicate setups on servers where only peek is used and nothing is downloaded. Or perhaps one can fetch using the "keep" option as same options as fetchmailrc are supported per-account...