|
|
|
|
|
|
by fao_
11 days ago
|
|
|
I think people are very justifiably angry that a very stable, well trusted tool, has started to immediately go downhill. The Linux Mint Timeshift tool has an issue open documenting a number of regressions that are currently open on the rsync issues page, that were only introduced post-vibecoding (https://github.com/linuxmint/timeshift/issues/548), one of those links goes to a larger aggregate of bugs reported downstream (https://github.com/void-linux/void-packages/issues/60825). I think it is incredibly rational and sane, given the reputation of vibecoded software as-such (where every professional who loves it is saying "you have to hold it in this very specific way so it doesn't cause bugs, and also you should probably only use it for version 0s so you can map out the domain"), for people to be angry that their load-bearing industry standard backup tool that is very, very well respected is suddenly pulling the rug out from under them because the maintainer wants to "add more features" and is doing it in what is clearly an unsafe way. Also from the timeshift thread: > not sure if this is just me, but after updating rsync, my cpu usage got so bad during my daily backups that i had to stop timeshift from running forever Or, phrased differently - People are frustrated and annoyed that the tool they trusted with their backups and data are seeing a huge number of regressions and new bugs that break their entire backup infrastructure, all because the main dev is vibecoding that software. Vibecoding experts like Simon Wilson explicitly state that vibecoding is 'viable' in the sense of "only if you hold the tool in a specific way", and this person is either not doing that, or that statement is untruthful. If you actually read the thread in question and just skim over the argument two people are having, there are multiple reports from users in industrial and government settings that now have to go through whole processes to update this software, simply because the software has become immediately untrustworthy in a way that directly harms users and defeats the entire point of the software in question. I think I would also be mad if I relied on this software for my 500gb+ backups, and I wonder how many more issues have been introduced that we simply won't learn about until a company has a $10 million dollar data loss because they were not testing their backups consistently. |
|
|
There are four actual regressions there. The commits that introduced two of them have been identified, and neither neither of those mentions Claude (or another LLM).
If you look at the actual commits that credit Claude, they are not huge commits (many are a few lines), most are tests and config. This is not vibe-coding.
> there are multiple reports from users in industrial and government settings that now have to go through whole processes to update this software
If people are handling such critical data with it they will be testing upgrades before deploying to production right?
> I wonder how many more issues have been introduced that we simply won't learn about until a company has a $10 million dollar data loss because they were not testing their backups consistently.
If a backup failure would cause a $10mn loss then its grossly irresponsible to not test your backups.