246 private links
How it is optimized to be the fastest possible.
The author shares its point of view on Shuttle that needs little to nearly 0 configuration to get started.
Zerocal was the first project I deployed on Shuttle. The principle was very simple yet innovative: encode calendar data directly into a URL. [https://endler.dev/2022/zerocal/]
#project #idea improve the UI or make a custom one that calls the API
#project #idea use such API to generate other files. Contacts?
because it is possible
This project looks interesting.
- No VDOM
- Rust syntax
- CSS scoping
- Routing & SSR & SSG
- Tauri support
- Htmx integration
Dav1d is a new AV1 cross-platform decoder, open-source, and focused on speed, size and correctness.
It uses software instead of hardware to be compatible.
The projects of UnJs are awesome
Asahi Linux aims to bring you a polished Linux® experience on Apple Silicon Macs.
Protomaps is designed around static, read-only datasets that are deployed by simply copying large files to S3 or any compatible storage platform
Build a CLI tool, check with the other existing tools and make a UI for it. It can include a preview for example.
The project is no longer maintained, and a comparison exists with other tools: https://github.com/coolwanglu/pdf2htmlEX/wiki/Comparison
Get people to start their own websites as easily as possible.
At the time of writing, it is a great work in progress.
A backend compiler and an alternative of LLVM
A list of what to do after reading the rust book
Critics of Git, if someone had to improve from its weaknesses.
sha1 was a bad choice back then. The moral here is "treat your identifiers as opaque strings" along with "sometimes a sha1: prefix doesn't hurt anyone"
Email and names in every commits:
I guess when you read lkml, the notion of spam isn't too worrying, but putting names and emails into every commit means any time someone changes name or email, they might as well be a whole different person to the repo.
Sure enough, when you store names in the files, you have to rewrite history when someone changes email address, but in another world, you'd use a UUID and a file called .gitauthors that maps one to the other
There are two different mechanisms for almost every feature.
git forces you to make a choice. use merge and get a noisy, but representative history. use rebases and lose some of the work, but the log is a lot easier to navigate.
we could also have a version of git log that didn't make merges look like shit, but that's another problem altogether.
the unix philosophy is about building toolkits, not applications
in other words: have you ever accidentally committed inside a rebase? or accidentally committed a conflict? tough shit, fucko.
git commands are named after implementation, not use, and there's absolutely no excuse for it
flat files kind of suck if your state gets corrupted.
git is made from papercuts
there's bits where you can't check in an empty directory, or how you can set files to ignore but not files to include.