At current PCB prices that's kinda not worth it. Hell, even actual assembly isn't that expensive (at least if you have "a lot of few components" vs "big variety of components").
I feel like just leaving PCB routing and schematics for it is just waste of tokens.
Once you have initial design (what chips to use, what each of them needs in terms of other components etc.) the schematic/PCB isn't the hard part but it is the hard part for the AI.
It's great at stuff that humans take a lot of time like say "get me buck converters in that range of voltage in power, and put price of chip and supporting components in the table", and at least in not heavily analog designs, finding chips that fit the purpose, are available and in price range is good part of the work
I used them a bunch just for the component shopping, I can route PCBs just fine, that's not a throttling factor in any project, but ability to "send it shopping" and not only get the price/availablity for the options but look thru datasheet for quirks and parameters is very useful.
Accepts stuff from pipe too so you can just pipe mysqldump or pg_dumpall without intermediate files
Very decent options for checking repo integrity, personally (well, at work too, we use it on few hundred user machines and servers) I also added "roll a dice for backup and try to restore it" test script to make sure it is working
Decent deduplication too so "store year's worth of weekly snapshot" is very sensible strategy once you exclude the "constantly changing and useless" (caches etc.) files out of it
can mount FUSE directory with all backups on sensible OSes.
https://kopia.io/ does the same +GUI but a bit worse on CLI front (it insists on keeping local config which makes scripting a bit more involved, but not much)
IMHO, the easiest way to perform a restore test is to use your production backups to refresh a lesser environment on a weekly cadence. Naturally this has to be appropriate to the type of data you're restoring, e.g., our E2E (end to end) testing environment has been built to the same risk tolerances of production so it's suitable for production data and the PII (Personally Identifiable Information) it hosts. If this isn't in your own risk tolerances, you can still perform the same test but ensure the data from prod is anonymised or alternatively destroyed, and perform a second restore after production restore with the dataset that preceeded it that has no PII data or similar.
With this the E2E tests confirm the backups are expected and you can tick a box that when shit does eventually hit the fan, data corruption isn't a problem. Normal caveats apply, you must make sure your backups are immutable so they cannot be modified or changed _after_ the tests have been ran.
I was using Restic + Backrest as well for my personal Windows machines and it was great. Then I found out that Backrest stores the vault password (among other things) in a simple plaintext file on your local hard drive. Not sure if this applies to all platforms but for Windows users that is a huge security hole in today's environment.
We actually do use some of our backups in anonymize -> test environment pipeline so it gets dual use on top of just testing restores.
We also use S3 versioning in case something gets the keys and just erases it. Then it's replicated to the cloud S3-compatible store to get the offsite location.
Only feature I really miss is "turn this restore into .tar", both for testing restores and for convenience when we get requests of "we need this directory from 4 weeks ago"
Kopia does not let you pipe into it without intermediate files, or at least not in a friendly way I could figure out.
Kopia seems quite designed around the backup server being the place where the config is set. IMO it's harder to configure if you have your own declarative config tooling (like Ansible, NixOS, etc)
The nicest way I found to ignore files declaratively is to configure a ignore-file pattern in the repository policy and then declaratively create `.kopiaignore` files.
The Kopia server is convenient if you have a server at home and want to back up laptops to it, with them being in a shared deduplicated repository without having to trust the clients not to get pwned and wipe out the backups. However I'm not aware of a nice way to then transfer those backups to aggregate them into a bigger repository. (So I just rsync them off-site and don't worry about getting deduplication with other backups)
Also learnt the hard way that you can't set a bandwidth limit when backing up to the kopia server, which can tank wifi performance on laptops during the backup.
I am thinking of switching to Restic as it seems like it is more suitable for people who want a tool at the complexity level of tar/git CLI with declarative config, rather than something imperatively configured.
We tested both and used Restic precisely because it was better in CLI/scripting department. Kopia is better for maybe less advanced user as it gives them GUI to click on
> he Kopia server is convenient if you have a server at home and want to back up laptops to it, with them being in a shared deduplicated repository without having to trust the clients not to get pwned and wipe out the backups.
Neither can do it well. We just used S3 + versioning for that reason, worst case we would just rollback the bucket
importantly, does your die have a side that corresponds to a multi-continental cataclysmic natural disaster of magnitude only known unknown to pre-recorded-history
It's so much worse than just that. Because they will also decide on how problem should be solved by prompting LLM and ask you to argument doing it any other way vs the LLM slop they pasted
Not as a rule for all prs you want to reject, but any time it seems to be no-effort pure ai. Both to waste as little of your own time and effort as possible, but also to to help make this activity not rewarding.
I wouldn't worry about false positives and being unfair. This is self defense and also community defense. Anyone legit will manage to get your attention. You'd be filtering not on any specific detail or rule but on simply "care".
If a legit person fails to convince you that they are a human that cares, then that's just an unfortunate industrial accident. It's unfortunate but trying to do anything about it is worse.
Besides, any actual adult understands that if they can't prove their age right now, then they can't buy a drink right now, even though they normally have that right, and is never the one trying to cry about the travesty of justice at being denied. If I submit a pr that fails your ai sniff test, I get it and don't think you're abusing me. I can try harder and we can be friends later no problem at all.
I put something like that right into AGENTS.md in one of my open source repositories -- disclose the usage of AI (it's super obvious anyway) and be prepared to act on review comments, otherwise the PR is closed and submitted could be banned depending on my mood. And I only got like 3 PRs before I put it.
Those weren't even that bad code-wise, some have uncovered realy problems, but I ended up asking /my/ LLM to ponytail them into shape, because the submitter didn't bother.
> comes at a premium. Why should this premium be applied on a 99 USD Smartphone?
It's entirely software. It's R&D cost, with basically none of it in hardware (you technically just need the private key store which even very cheap devices have)
reply