Today I deployed an Azure Function App in #python. When it was all said and done, and my machine sullied by MS libraries, I was left wondering how this was any different than any other container I could have deployed behind an app service. The logs showed me the answer: there is no technical difference. Also, the container MS selected is significantly less performant than the one I rolled for a different service. I may just rewrite the thing tomorrow.
❌ NSA analysts spied on significant others.
❌ Ring employees were caught looking at off-limits footage.
❌ Verkada staff use their own facial recognition tech to harass other employees.
Abuse of dangerous tech often starts with the people who build it. https://www.vice.com/en/article/pkdyqm/surveillance-startup-used-own-cameras-to-harass-coworkers
I really should do TDD more often. Or I feel like it is helpful for me. Particularly now with something like seven active (semi-related) projects. It’s pretty rough when use of one from the other reveals a bug that has impacts on four different projects. I was able to fix one such case today without impacting the public API but it was less than fun.
Going to look into some CI so I can automate builds to provide packages for my projects. Just to see how long it would take to ‘cargo install connchk’ on a small system, I installed the #Rust toolchain on a #beagleboneblack and checked: 69min. Cross compiling on my T460s takes 62s.
Any thoughts on which tooling to use?
After spending several hours fighting with OpenSSL variations in my array of Linux hosts, I have released v 0.2.0 of connchk to remove the OpenSSL dependency completely. TLS is now handled by rustls.
Now the project builds easily with cargo or cross on x86_64-unknown-linux-gnu, armv7-unknown-linux-gnueabihf, and x86_64-pc-windows-gnu.
Right now my 'connchk' project is really only available if you're a #Rust user who can `cargo install connchk`.
This weekend I think I'll add some automation to at least provide binaries for x86_64-unknown-linux-gnu, armv7-unknown-linux-gnueabihf, and x86_64-pc-windows-gnu targets. Maybe later I'll package .rpm and .deb versions too.
It's been long enough now that we are back to the pre-golden era world where people don't understand the risks of vendor lock-in and proprietary protocols. To me this means there's an opportunity for a new golden era, if we can get people to appreciate why the "freedom" part of FOSS is so important.
The following era saw priority shift from "freedom" to "open" throughout FOSS. Linux webapp development was primarily done on Macs and that changed how FOSS development happened overall, as devs had to adapt to homebrew libraries instead of curated packages. Dev tools changed to solve the problem of inconsistent library versions between Mac and Linux distros, which ultimately led to docker. I believe the primary reason docker was created was to serve Linux webapp development on OSX.
I'd love to see a history of FOSS in its "golden era" (early aughts) to the early teens. There was this great momentum at the time, giant advances in the Linux desktop and server, and a large focus worldwide on open standards (XMPP became, briefly, the standard chat protocol).
This progress stalled. My theory is that it's in large part due to OSX convincing FOSS developers "it's UNIX" and with FOSS devs on Macs, Linux desktop advances slowed down.
Updated my vim-config repo: https://github.com/anthonyjmartinez/vim-config with an important announcement: emacs is probably actually the best version of #vim once you've got EVIL installed.
I really only use EVIL because in the server (and embedded) administration game you're always going to find at least vi on your target host. Those motions will always be part of my day to day. I really only `M-x evil-mode RET` when I know I'll be in and out of remote systems all day.
Standard Emacs bindings are fine.
Not much sleep was had last night, so I took advantage of the situation and finished another #Rust project: https://crates.io/crates/connchk
The structs defined thus far let me define what path to take for HTTPS services. Now I just need a struct that takes a one or more elements of each exiting struct so I can create them based on TOML contents. Making surprisingly fast progress. #Rust
Moving hard coded values into a TOML file to ingest at runtime and define the actions taken by my latest #Rust project providing a tool for my factories to determine the true source of perceived network issues. For most critical services establishment of a TCP connection is sufficient. For some of the HTTPS services a 200 is self explanatory, but for others a 400 may actually indicate success (a garbage request making it past certain checks) while a 403 is problematic.
Machine design hat on for a second: if you’re designing some structure and require fasteners exclude the Phillips head screw from consideration. In 2020 there is no reason this weak design should still be used. #thismaybetheonlythingIsayrelatedtomyactualdegreein2020
Well now that I’ve got a working POC I’m inclined to make it a bit more generic and extensible tomorrow. I see some more Box<dyn Trait> use in my future. #Rust
Time to sit down with reqwest and std::net::TcpListener for a bit. Need to hammer out a diagnostic tool to help our production facilities troubleshoot network issues. #rust
The last #IKEA bookshelf was mis-packaged. There are two right sides, and no left side. Guess I'm going to have to physically go to the store since the customer service number doesn't work and the two social media contact options are for services I don't have.
Thanks for over 2,500 app votes so far! Already at 25% of our 10,000 vote goal!
Help fund the apps you desire with "Fund Your App":
I like to work with my hands. That may mean hammering out solutions to complex problems in #Python or #Rust, building things in my shop, or spinning yarn to knit something warm. You’ll likely see some of all of that here. By day (and sometimes night) I keep >13k nodes and services alive in the Electric Vehicle sector.
PGP: FCBF 31FD B34C 8555 027A D1AF 0AD2 E852 9F5D 85E1