deepwiki.com is untrustworthy AI slop. A true cancer.
deepwiki.com's generated page on my project contains several glaring errors. I hate to think of the extra support burden I will have to bear because of deepwiki.com publishing wrong information.
I asked the authors of the site (Andrew Gao) to remove their page on my project, but they ignored my request.
This is really cool and innovative thinking, but anything aerodynamic does not scale linearly. It's really easy to make something light fall slowly. Baby spiders use "ballooning" -- a single thread -- to fall so slowly that they can travel far in thermal updrafts.
What's missing here is any evidence that the same cool parachutes will work on anything of significant mass, e.g. a parcel weighing 2kg or an average human weighing 80kg.
>Baby spiders use "ballooning" -- a single thread -- to fall so slowly that they can travel far in thermal updrafts.
It's even cooler. Spiders probably also exploit the Earth's natural electrostatic gradient (100 volts per meter!) to "ride" on electrostatic repulsion. This would even give up and down control, simply by changing the length of silk.
I've worked on mission planning software for parachute systems and the precision we can achieve is already extremely high. Given how poorly this seems to scale, the only use case that makes any sense to me would be something like sensor drop, which are the only payloads small enough for these chutes. Or potentially for drogues on multi-stage systems, but I'm not sure they'd even be useful there because usually a fast descent is part of the appeal of a drogued payload, and not just to reduce time exposed to wind drift (e.g., to reduce time it is vulnerable to enemy fire).
Depending on the use case, a hot-air balloon sized parachute to safely drop a person might be perfectly acceptable.
It looks like adding flexible ailerons or whatever they'd be called could give a big advantage in precision landing, with slower forward/sideways speeds but much better control.
Making it modular, with interlocking but separate parts, might make great sense for repairability and safety for skydiving? From the little I know of the sport, things tend to fail catastrophically, going from perfect condition to total disaster without a whole lot of graduated steps in between. I also wonder if there's some utility in paramotoring - multiple kirigami stabilizers, maybe, with a central parafoil, or one big kirigami rig with the fan blowing straight up its skirt?
This is awesome research. Paper drone-delivery parachutes are definitely a use case, but maybe some of the more dangerous flying sports could be made much safer, as well.
edit: Apparently no, 100 meter radius kirigami chute would be needed for a single person parachute, not exactly practical. Apparently it's just really, really good at ensuring things drop straight down with a lot of drag.
Spider ballooning is an interesting phenomena. I also assumed that the spider is just falling a bit slower than the air is rising, due to convection. However some people think there is also a strong electrostatic component to spider ballooning. I'm not sure how that works once the spider is well clear of the ground though.
It looks like it depends on the stiffness of the material (paper), so scaling it up to human (or bigger) sized will come with "interesting" challenges :(
My dashboard-feed is pretty much useless unfortunately, I have rarely used it but when I did it was useful now though there 2 out of 20 that might be useful.
> Often my changes are speculative or experimental. So I checkout, edit, apply and only then discover I’ve messed up. Or I can edit in place. Voila vimdiff!
Personally, I tend to use `chezmoi edit` and then use git in my source directory to `git add -p . && git commit` the changes I want to keep and `git checkout` to discard the changes I don't want.
chezmoi includes secret scanning from https://gitleaks.io/ by default to catch when you accidentally add a file with a secret in it. To be even more confident, you should add gitleaks as a git hook to your repo however.
How do you automatically set up the hooks, e.g. when you clone the repo on a new computer?
Also, is there a way to automatically edit a chezmoi managed file in the chezmoi directory? I accidentally type stuff like "nvim .bashrc" way too often and then forget I never added the changes to chezmoi. It would be neat if there was a vim plugin or something that just opened the chezmoi file instead if it's managed.
Please can you open an issue or discussion for these questions on https://github.com/twpayne/chezmoi - this way more people will both be able to help and more people will see the answer.
It's not a question of share everything or share nothing - with https://chezmoi.io you can choose exactly what you want to share:
* You can keep your entire dotfile repo secret by using any private git hosting, including your own git hosting or a private GitHub repo.
* You can keep individual files secret by using age or gpg encryption. If you repo is public, this only reveals the existence of the file, not its contents.
* You can keep individual parts of your dotfiles secrets, e.g. API keys, by encrypting them or storing them in your password manager. All popular password managers are supported.
Chezmoi has been a blessing to use. It is one of the only tools I've used that had been able to survive me neclecting it for months and then getting back to it. I'd love a more interactive diff when my dotfiles have driften too much. But otherwise it is perfect for my needs.
Meta had an internal tool called "dotsync". It persisted multiple revisions of dotfiles across multiple machines associated with a particular user's account. It supported ignoring history and secret files by patterns. This is a superset of simply storing all dotfiles in a single git repo. This unmaintained project seems suspiciously similar including the name: https://dotsync.org
As the maintainer of several popular open source projects (e.g. https://chezmoi.io), the forms of help I appreciate the most are:
* User support. Answering questions in discussions, social media, and GitHub issues. This helps on multiple levels: it saves me time that I would otherwise have to spend, and builds a community around the project.
* Documentation improvements. Better documentation means less user support work and helps everybody.
* Issue reports with a clear, minimal, way to reproduce the problem.
* Pull requests that follow the contributing guidelines of the project. This means that they follow the project's conventions, include tests, don't break any existing tests, and so on.
I don't write open source software to make money. I write open source software because I enjoy building high-quality software and I get a buzz from helping people.
https://www.chezmoi.io/reference/commands/ssh/