What!? And then next you’ll tell me they are not wombs either?! I don’t believe you
What!? And then next you’ll tell me they are not wombs either?! I don’t believe you
Removed by mod
I am guilty of this but for a different reason: setting up debugging for clis in rust is hard
I love the debugger. I use it all the time I can. But when debugging cli it’s a pain as you need to go back in the launch.json file, remake the argument list, then come back to run debug, find out why tf it doesn’t find cargo when it’s the PATH… again, then actually debug.
I oversimplified it but the actual process was to zip files to send to an FTP server
The cron zipped the files to send in the same directory as the zipped files, then sent the zip, then deleted the zip
Looks fine, right? But what if the FTP server is slow and uploading take more time than the hourly cron dispatch? You now have a second script that zip all the folder, with the previous zip file, which will slow down the upload, etc…
I believe may have been started by an FTP upload erroring out and forcing an early return without having a cleanup, and progressively got worse
… I suppose this happened. The logs were actually broken and didn’t actually add the message
part of the error object, and only logging the memory address to it
Well it’s not that simple… Because whoever wrote that made it way too complicated (and the production version has been tweaked without updating the dev too)
A clean rewrite with some guard clauses helped remove the haduken ifs and actually zipping the file outside of the zipped directory helped a lot
Oh no need. The client didn’t noticed anything in 6 years, and the reason why we had to check is because they wanted us to see if we could add this feature… That already existed.
Meanwhile, had to debug a script that zipped a zip recursively, with the new data appended. The server had barely enough storage left, as the zip took almost 200GB (the data is only 3GB). I looked at the logs, last successful run: 2019
TBF, if your step by steps instructions works, it doesn’t matter how complicated the command is.
Oh come on! I at least type the beginning so that it filters the history
Rust made me have an habit of using snake_case… .rs
Knowledge of your passwords
Uh… What password?
I kinda hate the push towards passkeys. If you have two factor Auth, going to passkeys makes you go back to 1 factor, aka less secured.
There’s also more and more 2FA fatigue attacks going on, and they can affect passkeys too, and if you don’t have a 2FA that involves the user writing a code on the 2FA device, passkeys could be quite possibly worse than passwords
TBH I thought it was for refactoring type safety. Making sure that the type is understood and not ready to just change wildly accidentally.
I do love rust. But I do like making fun of it too.
Although I don’t see how rust is immature? Unless I missed the joke?
I don’t get it either. OP might be angry at compile time (Couldn’t be worse than rust)
This is also part of my death, because it’s much easier to not deadlock when you are FIFO.
Personally I went for the nuclear option, and any transaction is sent as a tokio task to make sure the transaction keeps getting polled despite other futures getting polled. Coupled with a generous busy timeout timer (60secs) and Wal mode, it works pretty well.
Probably should also put the mutex strategy (perhaps a tokio semaphore instead?) although due to lifetimes it might be hard to make a begin()
function on my DB pool wrapper.
… Congratulations. You nerd snipped me. Time for it to go on the todo stack.
Hyped for it too, but wouldn’t use until sqlx suport. Compile time checked queries are just so good. I don’t use rustsqlite for that reason alone (you often don’t need async SQLite anyways)
Whose to know Glenda isn’t manipulating the fish uh? Uh!?