Show more

Crazy week at work ended on a positive note. After making an insane number of commits and PRs across way too many projects it finally became clear where the blocking issue was hiding. With that fixed progress can continue. The lack of meaningful tests at any level, from the unit up through systems integration, is a serious problem.

Taking a break from a gazillion screen hours to make something with my hands.

@pbx I should take a look at the cost of the two resources in that app service plan. One is a “native” Function App, and the other is backed by a container image I developed. The latter is served out of a container registry I also pay for so the Function App is probably cheaper. I’ll take a look tomorrow.

Today I deployed an Azure Function App in . 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. vice.com/en/article/pkdyqm/sur

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.

@stevenroose and yes for the fpm case I’d use it with the same form as done in the docs here: fpm.readthedocs.io/en/latest/s

Just ship your binary, any applicable config defaults, docs, and your license. You can declare system dependencies as well, and should if they exist. Help options on fpm are a little better than the docs these days to be honest.

@friend @stevenroose yeah, native-tls will pull in openssl-sys as a dependency for Linux triples. This will not cause problems if your target is the same distro (and version) as your build machine. If it’s not all bets are off. For my specific case this left two options: enable the optional feature of including a vendored OpenSSL in my binary, or move to rustls. Either results in static linking of TLS libs in my project.

Need to write some tests for a system I’ve developed for $dayJob. I hit some unexpected corners today. They were easy enough to resolve, but they never should have happened in the first place.

@stevenroose check out fpm for making packages. Pretty easy to use.

@schrieveslaach cross is exactly what I used for the 62s run on my laptop. cross dropped support for openssl, with good reasons discussed in an issue on their repo. Using their image as a base and adding openssl is trivial, however the resulting binaries only work on all targets if you use the ‘vendored’ feature to include a static openssl. It was overall less hassle to change my project to use rustls. Thanks for the response!

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 toolchain on a 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.

crates.io/crates/connchk

@Gina if there's an "ideal" place to break down, that is definitely not it! Did you make it out yet?

@kyle @angdraug heh I remember having the FujiP out in public circa 2007 running Debian w/ XFCE and having someone want to know which Mac I had and how much it cost...

I never feel "held back" by LoTD. It's generally that I feel constrained to the point of being unproductive if I find myself in the unfortunate position of having to actually use my work laptop on Win10.

@angdraug @kyle It was circa 2.4.late/2.6.early when things were half OSS / half ALSA. The worst was having a laptop that would occasionally have the hd at /dev/hde instead of /dev/hda where was when the system was installed. Probably not actually Linux's fault, but fun anyway.

Now I never have an issue with a machine working. Debian, Ubuntu, Fedora, CentOS, Tails, Kali, whatever. My windows machine is reqd by work. I use it to change my password every 90 days.

@angdraug @kyle A good chunk of the pain 20yrs ago, IMO, was from finding one application that was great for the task you needed it to do only... it was then the ONLY app you could use that made sounds (to call back the pain of having 9000 different sound layers possible at the turn of the century). Things are much better now, and I seldom find myself deep in /proc trying to figure anything out anymore. I'm glad I had that experience for when truly outstanding problems do crop up today.

Right now my 'connchk' project is really only available if you're a 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.

Show more
Librem Social

Librem Social is an opt-in public network. Messages are shared under Creative Commons BY-SA 4.0 license terms. Policy.

Stay safe. Please abide by our code of conduct.

(Source code)

image/svg+xml Librem Chat image/svg+xml