jgarzik

Skeptical of their engineering, with replies to questions like this: https://x.com/jgarzik/status/2031312666036146460?s=20

Rough draft for comment - passes core cpython 3.12 tests with an inspired design.

Does it isolate keys away from bots?

Already done, months ago, with better taste: https://github.com/rustcoreutils/posixutils-rs

I needed this for experimenting. Sharing with others. Please file issues, to extend.

The next iteration of awk?

Passes 100% of userland tests, supporting 99% of linux syscalls (though very few filesystems!)

Early boot and early page table setup, logging single characters to simulated serial console.

Then keep adding tests/features/tests/features/...

I always wanted a kernel where I can experiment with the device driver model, eBPF, device tree and more. Now I've built one:

Somewhat related, a kernel in Rust: https://github.com/jgarzik/hk

Accelerated by Claude Code, leashed tightly by unit and integration tests, and test-driven development.

Speaking as a compiler and kernel expert, the productivity boost for domain experts is real.

Compiler status: Full C99 compliance, test suites pass, alpha-beta stage, starting to test on Gentoo and open source package builds "real world builds"

Posixutils status: Very close to 1.0 (all POSIX utils, all POSIX util features, tests pass)

enums > defines

Love this! I had the same idea, and was pondering funding apps like this. Was going to call it "SimpleFree" and focus on privacy, offline, mobile, games.

Thanks! There is very little info available on useful, working Veo 3 techniques, so I cobbled together what I could find, with my own experiments: https://x.com/jgarzik/status/1926496820311605577

No, not using sqlite under the hood.

This is using Rust's native sqlparser crate, which is quite powerful, plus an internal memory database.

We can extend this beyond what sqlite SQL supports.

Suggestions welcome!

posixutils is far, far more utils than coreutils. posixutils includes awk, m4, a C compiler, etc.

At the same time, as you note, this does not include GNU extensions inside each utils.

The posixutils-rs project just merged a full, POSIX compliant shell.

By amusing coincidence, I wrote a Redis clone in Rust: https://github.com/bloq/memds

It is hoped that posixutil's awk's bytecode-based modern design should keep performance high, theoretically higher than ancient C-based awks.

Inspired by Ray Gardner's "wak" awk implementation https://github.com/raygard/wak

A volunteer benchmarking our awk on a 1-billion line text file would be welcome.

I wouldn't assume. The awk implementation likely stands up well for a 1-billion-row challenge, with its thoughtful bytecode-based design.

Redditors ran some quick performance tests on parsing, also: https://www.reddit.com/r/rust/comments/1fd7qgl/comment/lmelo...

Updated in 2024, no less! (2024 version still has UUCP though, heh)

Most people really, really do not understand the large amount of military traffic on Telegram, and the consequence of that during wartime... and how valuable that is to multiple nation-states around the world.

Strategic comms, soldier command and control, battlefield drone command and control, intel asset management.

Armchair analysts need to put on their big-boy military pants.

DKBTrace and POV-Ray were my introduction to CGI.

Open source meant it was possible for an Average Person with No Budget to do CGI animations and stills.

The entire repo is written in Rust. bc is one of 145 utils specified by POSIX.

posixutils is something more. (see README.md)

Most utils are 25+ years old. It is worth revisiting, dropping old cruft, entrenching UTF-8 support, and other areas.

Smaller and fresher.

Amazing work. Thanks and kudos. I definitely tested some early stuff vs your bc.

Just added this FAQ section to the README:

Because it is a FAQ, the major differences between this project and uutils are:

1. Wider scope: posixutils is far more ambitious than uutils from a breadth standpoint: posixutils will include bc, m4, c99 compiler, fort77 compiler, a cron daemon etc. uutils is far more limited in the scope of programs covered, mimicing GNU coreutils.

2. More minimalist: Each posixutils utility implementation is intentionally more minimalist, intending to avoid the bloat of supporting rarely-used, non-POSIX features. Our common denominator and baseline is the POSIX spec, then add non-POSIX features that users cannot live without.

3. Transportable: Each posixutils utility should look like normal Rust code, easily stand alone with little-or-no deps, and be used in another project. This project is MIT-licensed, not GPL licensed, to aid in that transportability goal.

Gotta be That Guy:

Some of the wisdom from the recent XZ backdoor incident was that cmake was a contributing factor, due to its internal complexity.

Some of the current trend is to strip out autotools and cmake, and go back to the basics, because modern OS support is a subset of what was relevant 20 years ago.