File Transfer, Pad-tech, TOAST, Projects, Software Development
Tested two modern file transfer tools like: croc (@ GitHub) and ffsend (@ GitHub). Both are different solutions, but good and can be self hosted for optimum performance and security. ref: send (server) (@ GitHub). It's also good idea not to forget the true classic: magic-wormhole (@ GitHub).
Specification meeting fun. It SHOULD ALWAYS, haha. Should always?!? So is it mandatory? - No, it isn't. Excellent, what it then means? IDK!
Pad-tech (@ pad.tech) is centralized secret sharing service, yet I didn't fully understand the benefits of it. Ok, someone authorized can request the secret, and the access is logged. That's clear, but I didn't totally understand the point of trustees, except that they monitor the fact that the request is legitimate. Yet, there's no higher concept like in case of x, it's just that trustee makes the request. As far as I understood there are no additional optional conditions for the response to the request to be fulfilled, but it simply happens in automated fashion. In that sense classic secret sharing is better, where N of X people you trust must agree to be able to get extract the necessary secret. Of course that option does not have audit log. So these options aren't directly comparable. Or maybe they'll later add option where multiple guardians are required, yet that wasn't clearly said in the documentation. Depending on the type of the secret, damage can be substation, of course in that case necessary extra steps should be required and maybe the shared secret isn't "the secret" directly and requires additional steps.
Lots of discussion how PostgreSQL TOAST (@ wiki.postgresql.org) compression differs from SQL Server page compression. Practically there isn't too much difference because TOAST already splits larger data into the rows and pages.
Again too many projects to maintain, especially on free time. I'm looking to trim down some projects. It's likely that DNSKV and Matrix (self-destructing messages) TTL BOT projects will be "shaved off" soon. Those were just fun projects to do, but there's very little actual use and there's no reason to maintain the projects without user base. Servers need maintenance, updates, security, and protocols like Matrix evolve all the time, so things which isn't constantly being updated gets broken. So, it's time to drop those hobby, learning and fun project(s).
Process and organization fun, the usual case. There's parameter X in process Y that needs to be changed. Ok, the change can be made by: customers power user, customers admin, suppliers project staff, suppliers project related power user(s), suppliers system Administrator(s), integration configuration, changing one field in database, integration data receiver integrator, receiver side configuration, and or final data destination settings. Do we now have enough people whom are able to change one freaking value Boolean value? No, clearly not. - So ridiculous, this issue has been now discussed for two weeks.
Once again totally fed up with developers whom think that fixing $hit code means running manual repair ops repeatedly and then waiting for complaints and wondering if data happens to be still corrupted. Also trying to guess repeatedly what's wrong, instead of taking a good look at the obviously shitty broken program logic. Not a first, and obviously not the last time this is going to happen. It's just pointless to even discuss things which are so seriously flawed. Unfortunately this seems to be quite common with different programs.
Updated my shared secret sheet generator (@ s.sami-lehtinen.net). True random, full sheet with ID and field references. Each field is 10 alpha numerical characters, including small and capital letters. Depending on need you can of course use multiple fields, or combine those or whatever, what's your personal preference.
True classic: "We need a system that fulfills our all current and future requirements. We're very disappointed that the system hasn't been delivered yet and it's delayed and so on." - "Ok? Cool, what exactly are your requirements for the system." - "UhHmmHmm, I don't know." - This is always kind of funny, but on the other hand quite depressing.
2023-07-02