jph

#1 thing helping me with GUI Rust is sccache for crate compilation caching. and #2 is building independent-compilable subcrates. This improves build times by 10x.

Also shoutout to ratatui because even though it's technically a TUI not GUI, it's superb.

I'm the author and the patient. Ask me anything here or email me joel@joelparkerhenderson.com.

Because of so many GitHub problems, I'm adding GitLab.com and Codeberg.org.

Setup is simply 3 steps:

1. Sign up on each service, ideally with the same username.

2. For each repo you want to share, create the same repo name as a blank repo; do not automatically create a README.

3. Edit your local file .git/config to add push URLs, then push as usual.

Example:

    [remote "origin"]
        url = git@github.com:foo/bar.git
        pushurl = git@codeberg.org:foo/bar.git
        pushurl = git@github.com:foo/bar.git
        pushurl = git@gitlab.com:foo/bar.git
        fetch = +refs/heads/*:refs/remotes/origin/*

Asserts in my Rust code use a custom runtime macro "assert_eq_as_result" which does what the article is describing, by returning Rust Ok or Rust Error.

The Rust crate: https://crates.io/crates/assertables

All the macros have forms for different outcomes:

    assert_gt!(1, 2) // panic
    assert_gt_as_result!(1, 2) return Result (Ok or Error)
    debug_assert_gt!(a, b) // panic when running in debug mode

If anyone here wants to help me port it to Zig, I'm happy to do it.

Excellent info thank you. Your explanation makes perfect sense, and leads to the security compliance info that I'm reading.

I'm seeking to stop supply chain attacks as described at https://wiki.debian.org/Rust

Could there potentially be a way for a program to include all the source code of all its dependencies, at least for any that aren't on Debian?

You're welcome, thanks for the shout out. Glad it's helping you. <3

I see in your posts that you do a lot with Rust and biology. Broadly, the same way you can use the tool "cargo install" to fetch a bunch of dependency crates from one source and be sure their versions can all run well together and update together, I can use the tool "apt install" to do the same for applications.

The concept is called a "package manager" and it greatly helps me achieve a concept called "reproducible builds", as I gradually migrate the work toward a package manager for reproducible builds called "Nix".

https://en.wikipedia.org/wiki/Package_manager

https://en.wikipedia.org/wiki/Reproducible_builds

https://en.wikipedia.org/wiki/Nix_(package_manager)

Good info, thank you. I'll aim for the next version with $100 to get it into Debian 14. <3

Good idea, thank you. I'll add examples in the documentation. Currently there are example repos that show all the components for each flavor: React, Vue, Svelte, Blazor, Nunjucks, HTML. Angular coming soon.

AI use is mixed: I write everything by hand in the specifications, and the components.tsv file, and in the Svelte version because it's my stack of choice. If you dig in, you'll see lots of hierarchies that are all hand-written to help Svelte caching, for example. I also research other major design systems, especially government-oriented public-sector systems such as GOV.UK and Reuters, and fold them in.

Then Claude Opus tranforms the Svelte version into the other stacks. Claude does a lot of the documentation text because I'm aiming for clear and consistent explanations, suitable for novice developers.

I'm developing Lily Design System because I work with multiple teams that each use a different tech stacks, each with their own ad hoc HTML tag names and semantic names. As a salient example, for a hospital form one team used terminology "health banner area" and another used terminology "medical red box". Lily is my attempt to converge these into something that works better internationally and across multiple stacks.

That said, I'm seeking help doing human proofing and improvements for the stacks, because we all know AI isn't perfect, and needs tuning, guardrails, expert feedback, and the like.

Great idea, yes you're right. I'll add that now.

Really? I ask because there's already an epub TUI reader, written in Rust, and open source, and I'm already using it in the terminal. I want it or something similar within Fresh because the two together will greatly help me with Fresh IDE epub docs in projects.

See https://github.com/bugzmanov/bookokrat

Update: a developer just now created a Fresh IDE pull request, thanks to this incentive.

See https://github.com/sinelaw/fresh/pull/2093

I'm the author. I'm seeking HN feedback for how to improve this CVD documentation, because AI attacks are escalating and some are turning up new kinds of security issues.

I have this floating-point problem at scale and will donate $100 to the author, or to anyone here, who can improve my code the most.

The Rust code in the assert_f64_eq macro is:

    if (a >= b && a - b < f64::EPSILON) || (a <= b && b - a < f64::EPSILON)

I'm the author of the Rust assertables crate. It provides floating-point assert macros much as described in the article.

https://github.com/SixArm/assertables-rust-crate/blob/main/s...

If there's a way to make it more precise and/or specific and/or faster, or create similar macros with better functionality and/or correctness, that's great.

See the same directory for corresponding assert_* macros for less than, greater than, etc.

If you're open to questions, I'm switching my teams from Docker to Podman on macOS. I'm hitting blockers for multi-user setups i.e. each developer has a non-admin account on the machine, whereas brew runs in its own account with admin permissions.

I would love a way to have Podman installable in userspace meaning in a non-admin account, or installable without brew, or with a dependency list such as QEMU or whatever else needs to be installed by an admin ahead of time, or with a sudousers config list, etc.

I know this is an atypical setup. Any advice from anyone here is much appreciated about multi-user non-admin macOS container setup for Podman or Docker or equivalent.

Clever hack! <3 I also do namespacing yet in a different way.

I create a home directory "x" for executables that I want to manage as files, and don't want on PATH or as alias.

To run foo: ~/x/foo

For example I have GNU date as ~/x/date so it's independent of the system BSD date.

Good questions.

For shell syntax, I aim for POSIX because for anything more advanced I switch from shell to a more powerful programming language.

Currently POSIX doesn't have the 'declare' statement, nor the '\e' syntax consistently, nor the 'echo -e' syntax consistently.

As for exporting, I do it because I have many quick scripts that I run often, and I prefer to switch the colors in one place such as in the evening from light mode to dark mode.

When you say the print statements aren't going to work by default, can you say more about this? Anything you can explain or point me to about this will be a big help. Thanks!

Yes good points both, thank you. The source code link has more explanation about color choices and my preference of POSIX compatibility. You can also see the color function that checks NO_COLOR, CLICOLOR_FORCE, TERM = "dumb", -t 1, etc.

For color operands, I use raw escape codes because I aim for POSIX compatibility. If I'm working on something that needs more capabilities then I switch to a more powerful programming language e.g. python, rust, etc.

As far as I understand, POSIX tput defines some terminal operands (clear, init, reset, etc.) but not color operands (setaf, setab, sgr0, etc.).

I maintain multiple open source projects. In the past two months I've seen an uptick in AI-forgery attacks, and also an uptick in legitimate code contributions.

The AI-forgery attacks are highly polished, complete with forged user photos and fake social networking pages.

The legitimate code contributions are from people who have near-zero followers and no obvious track record.

This is topsy-turvy yet good news for open source because it focuses the work on the actual code, and many more people can learn how to contribute.

So long as code is good enough to get in the right ballpark for a PR, then I'm fine cleaning the work up a bit by hand then merging. IMHO this is a great leap forward for delivering better projects.

If you want a quick easy way to add some colors to your own shell scripts:

    export STDOUT_COLOR_START=''
    export STDOUT_COLOR_STOP=''
    export STDERR_COLOR_START=''
    export STDERR_COLOR_STOP=''

In your shell script:

    print_stdout() {
        printf %s%s%s\\n "${STDOUT_COLOR_START:-}" "$*" "${STDOUT_COLOR_STOP:-}"
    }

    print_stderr() {
        >&2 printf %s%s%s\\n "${STDERR_COLOR_START:-}" "$*" "${STDERR_COLOR_STOP:-}"
    }

Source: https://github.com/sixarm/unix-shell-script-kit

The source also has functions for nocolor, and detecting a dumb terminal setup that doesn't use colors, etc.

I'm in the affected group because I'm a US citizen working in the UK. There's much more to the story because the UK has many digital ID aspects already in place-- such as for work visas and residence permits-- but these not coordinated into a whole.

What I experienced last year was many digital verification steps that were all required: open a UK bank account, sign up for a UK phone number, secure a UK residential postal address, apply for UK right-to-rent codes, generate a UK national insurance number, file for UK healthcare registration, and more.

Each step had different digital workflows and UI/UX. To traverse all these steps took hundreds of hours and a couple months wall time.

Many steps had catch-22s. The UK bank account needed a UK phone number, while the UK phone company needed a UK bank account. The UK payroll company needed a permanent residence, while the UK landlord needed UK payroll stubs. None of the steps had a quick simple way to digitally verify my UK work visa.

IMHO federation could be a big help here, such as for government agencies and government-approved businesses doing opt-in data sharing and ideally via APIs. For example, imagine each step can share its relevant information with other steps. This could make things more efficient, more accurate, and ideally more secure.

Links:

https://github.com/joelparkerhenderson/demo-rust-lettre-sync

https://github.com/joelparkerhenderson/demo-rust-lettre-asyn...

https://github.com/joelparkerhenderson/demo-rust-lettre-asyn...

Monodraw for Mac is my favorite. I'm a customer. $10 license. https://monodraw.helftone.com/

UK government agencies have opportunities to improve cyber security in a pragmatic way by phasing in coordinated vulnerability disclosure.

This matches the article's point that the UK CSR bill may be a first step that helps to phase in bespoke legislation to improve UK national security.

For me this is professional because my work involves UK software engineering for medical information.

Coordinated vulnerability disclosure: https://github.com/joelparkerhenderson/coordinated-vulnerabi...

These examples could both be much better IMHO with a top comment block that describes the purpose of the functionality and shows good usage examples. Something like this below, and ideally using runnable doc comments to help keep the comment correctly explaining the code.

Replace symbol placeholders in the input string with translated values. Scan the string for symbol placeholders that use the format "$foo". The format uses a dollar sign, then optional ASCII letter, then optional word characters. Each recognized symbol is replaced with its corresponding value.

Symbols are only replaced if the symbol exists i.e. getSymbol(String) returns non-null, and the symbol has not already been replaced in this invocation.

Example:

  - input = "Hello $name, welcome to $city!"

  - output -> "Hello Alice, welcome to Boston!"

Return the string with symbol placeholders replaced.

Great project. Want to contact me when you'd like to talk? I do software engineering for clinicians at a health care organization, and I'd love to have my teams try your work in their own contexts. Email joel@joelparkerhenderson.com.

I worked at Sun and had the ring. We had a great demo where you could walk along a row of Sun workstations, and your X session would move with you, leaping from monitor to monitor, keeping pace with you. The idea at the time was "The Network is the Computer".

IIRC there was some coding that enabled each workstation to know where it was physically, so the security systems could know "User is signed into workstation X, and is requesting a move from workstation X to workstation Y, which is physically one meter away, so AOK to keep signed in."

Yes small features help enormously. I've used ROPE and work breakdown structures (WBS) to estimate multiple projects at thousands of staff hours to under 4% of actual. The ROPE advantage is that it uses multiple perspectives, which gets stakeholders understanding that the estimates are imperfect and depend on many factors.

Yes except in practice it's worked out more like this... Realistic is favored by tech teams. Optimistic is favored by salespeople and marketers. Pessimistic is favored by lawyers and compliance people. Equilibristic is favored by project managers and military.

Each stakeholder gets the kind of fortune they want. The important aspect (to me) is that the four viewpoints show all the stakeholders that their viewpoints are quite different.

Yes you're correct. PERT 3-point was my starting point and I wanted to add a critical chain 50% estimate.

BTW the SixArm name and ROPE is merely my personal work. Way back when, I had to put on the trademark because someone else said my work was theirs.

Critical chain planning has a purpose for the 50%. It's not perfect-- but it's better than other ways, in my experience.

Wikipedia: "The justification for using the 50% estimates is that half of the tasks will finish early and half will finish late, so that the variance over the course of the project should be zero... Because task duration has been planned at the 50% probability duration, there is pressure on resources to complete critical chain tasks as quickly as possible, overcoming student's syndrome and Parkinson's Law."