Hacking on https://smallweb.run, my pet project of building a self-hostable serverless platform mostly based on SSH, contained in a single golang binary.
Recovering from writing and rewriting a long blog post, which I now see I probably totally overcomplicated, and made too long :P (on the front page). Hopefully I learned something for the next time.
Otherwise, regular job, which is not that exciting or unique.
We have that old Rockland FFT analyzer with failed supply to the EL backlight for some time now. Going in to see if it could be an easy fix.
Also working on integrating Modbus TCP interface to our product. For a long time we relied on middleware over our WebSocket API done by integrators to do the job. However it’s a bit of headache for everyone to have an extra party involved in every round of changes.
Sure, it’s this one. Our phone products have Modbus integration too as it’s very common requirement in the automation world. But Evacsound interface is quite a bit more elaborate.
Week 4 of baby bonding leave! Besides learning how to be a good dad I am finding a fair amount of time to learn embedded Rust and work on a personal project related to automatically updating documentation.
Still working on adding clustering & replication to FlowG.
I started with Raft for consensus, but I think it brought more problems than solutions:
I need an odd number of nodes so that leader election can always have a quorum
during testing, I had many different scenario that lead to no leader at all in the cluster, and recovering from that was hard
it’s a leader/follower pattern, all writes must go through the leader, which would simply kill performance
In terms of CAP theorem, Raft is CP, meaning that by design, there are situations where the cluster can become unavailable. That just won’t do in my case.
I ended up getting rid of it, and instead will go with SWIM (a gossip protocol for nodes to discover each other and exchange information) and a CRDT.
SWIM is actually AP, has no constraint on the number of nodes, is far easier to implement (hashicorp/raft vs hashicorp/memberlist), but produce a lot more network traffic. For the eventual consistency part, I get that with the CRDT. And for logs, eventual consistency is more than fine (log storage is “append only”, I do support a “purge” operation, but with accurate timestamps and “last write wins” strategy, I get a decent behavior, a purge operation does not happen often anyway).
It’s still a work in progress, and adding all this code makes me refactor some parts of the application, I might introduce Uber’s fx library to manage the exploding number of settings that need to be injected in the deep layers.
I haven’t had so much fun on a challenging topic in years.
Welp, I have found some software that seems to do everything we want for our package and update repository at work: https://inedo.com/proget. And it’s $2,400/yr instead of $24,000/yr, which is what Sonatype, PackageCloud, Cloudsmith, Artifactory etc all wanted, give or take some. The new monetization strategy for these things seems to be “offer 150 GB of storage free and then charge $1/GB for the AWS object storage that costs us $0.02/GB”, which is maybe acceptable when you’re just publishing your own software and it’s a few hundred megs, but a lot less fine when you want to actually be able to reproduce the full build environment and dependencies for multiple versions of software and thus need 2.5 TB of storage. It’s amazing how all of these services have about the same prices and cost structures with little differentiation; it’s almost like capitalism only works if the people participating in it don’t know how it works and aren’t smart enough to say “we’re not gonna explicitly cooperate to fix prices, but we’re sure not gonna lower our price when we can use other ways to manipulate our customers instead”.
ANYway, rant aside, ProGet lets us use our own storage backends and does everything else we want so far, which sadly the open-source Artiepie does not. And it isn’t the laggy, hard-to-search, opaque, memory-leaking mess of bullshit that Artifactory is (or at least, Artifactory’s frontend; gotta give credit where it’s due, the backend has been pretty bulletproof). So, I’m going to be setting that up and making it ready for production.
Artifactory’s backend (had to) got a lot better over the pandemic. I can’t understand how their frontend is still so terrible.
Are all your engineers and tooling located relatively close to your object storage? My last org was globally distributed, so we were forced to use CDNs in fairly short order…
Relatively, yes; 90% of the company works in the same office, and while trips to customer sites are common they’re mostly on the same continent. Not sure how much 100 ms of latency will matter for us even when we do the occasional thing in Japan or wherever though, most of our artifacts are big chonky bois that are infrequently altered, and download time outweighs query time by a lot. I’ve frequently considered an in-office cache so we can spend more time getting stuff at 10 gigabit/sec over the office network rather than 100 megabit/sec from S3, but that’s a nice-to-have more than anything else.
That said, I’m still a relative novice at all this; what did the CDN get you that you needed for package downloads? Lower latency? Lower egress fees? Higher speeds? Something else?
write: drop one more post on untested (something really short, probably more of a #TIL)
examples: a script that collects all of my TODOs in the current branch, the scripts I use to automate some of my prototyping workflow, using SVG filters to generate squiggly boxes, or a prototype of a visual search app for Mac I made for myself
I won’t do all of it, but I’d like to get 1-2 things done. I’ll play it by ear.
Hacking on https://smallweb.run, my pet project of building a self-hostable serverless platform mostly based on SSH, contained in a single golang binary.
I’m focusing on the cloud version right now (https://smallweb.live)
Recovering from writing and rewriting a long blog post, which I now see I probably totally overcomplicated, and made too long :P (on the front page). Hopefully I learned something for the next time.
Otherwise, regular job, which is not that exciting or unique.
We have that old Rockland FFT analyzer with failed supply to the EL backlight for some time now. Going in to see if it could be an easy fix.
Also working on integrating Modbus TCP interface to our product. For a long time we relied on middleware over our WebSocket API done by integrators to do the job. However it’s a bit of headache for everyone to have an extra party involved in every round of changes.
You’ve definitely piqued my interest… can you share what the product is? Modbus isn’t something that most software people have to
dealwork with.Sure, it’s this one. Our phone products have Modbus integration too as it’s very common requirement in the automation world. But Evacsound interface is quite a bit more elaborate.
Thanks! That’s really cool!
Week 4 of baby bonding leave! Besides learning how to be a good dad I am finding a fair amount of time to learn embedded Rust and work on a personal project related to automatically updating documentation.
Congratulations! The first few months are a dream. 🥰
We’re on month nine … and I only just to got back to my side projects.
Still working on adding clustering & replication to FlowG.
I started with Raft for consensus, but I think it brought more problems than solutions:
In terms of CAP theorem, Raft is CP, meaning that by design, there are situations where the cluster can become unavailable. That just won’t do in my case.
I ended up getting rid of it, and instead will go with SWIM (a gossip protocol for nodes to discover each other and exchange information) and a CRDT.
SWIM is actually AP, has no constraint on the number of nodes, is far easier to implement (hashicorp/raft vs hashicorp/memberlist), but produce a lot more network traffic. For the eventual consistency part, I get that with the CRDT. And for logs, eventual consistency is more than fine (log storage is “append only”, I do support a “purge” operation, but with accurate timestamps and “last write wins” strategy, I get a decent behavior, a purge operation does not happen often anyway).
It’s still a work in progress, and adding all this code makes me refactor some parts of the application, I might introduce Uber’s fx library to manage the exploding number of settings that need to be injected in the deep layers.
I haven’t had so much fun on a challenging topic in years.
Going to London to visit our office there and attend the Datadog Summit. Maybe see somebody over there?
Wanted to break into lower level in cpp so will learn some of it
Welp, I have found some software that seems to do everything we want for our package and update repository at work: https://inedo.com/proget. And it’s $2,400/yr instead of $24,000/yr, which is what Sonatype, PackageCloud, Cloudsmith, Artifactory etc all wanted, give or take some. The new monetization strategy for these things seems to be “offer 150 GB of storage free and then charge $1/GB for the AWS object storage that costs us $0.02/GB”, which is maybe acceptable when you’re just publishing your own software and it’s a few hundred megs, but a lot less fine when you want to actually be able to reproduce the full build environment and dependencies for multiple versions of software and thus need 2.5 TB of storage. It’s amazing how all of these services have about the same prices and cost structures with little differentiation; it’s almost like capitalism only works if the people participating in it don’t know how it works and aren’t smart enough to say “we’re not gonna explicitly cooperate to fix prices, but we’re sure not gonna lower our price when we can use other ways to manipulate our customers instead”.
ANYway, rant aside, ProGet lets us use our own storage backends and does everything else we want so far, which sadly the open-source Artiepie does not. And it isn’t the laggy, hard-to-search, opaque, memory-leaking mess of bullshit that Artifactory is (or at least, Artifactory’s frontend; gotta give credit where it’s due, the backend has been pretty bulletproof). So, I’m going to be setting that up and making it ready for production.
Artifactory’s backend (had to) got a lot better over the pandemic. I can’t understand how their frontend is still so terrible.
Are all your engineers and tooling located relatively close to your object storage? My last org was globally distributed, so we were forced to use CDNs in fairly short order…
Relatively, yes; 90% of the company works in the same office, and while trips to customer sites are common they’re mostly on the same continent. Not sure how much 100 ms of latency will matter for us even when we do the occasional thing in Japan or wherever though, most of our artifacts are big chonky bois that are infrequently altered, and download time outweighs query time by a lot. I’ve frequently considered an in-office cache so we can spend more time getting stuff at 10 gigabit/sec over the office network rather than 100 megabit/sec from S3, but that’s a nice-to-have more than anything else.
That said, I’m still a relative novice at all this; what did the CDN get you that you needed for package downloads? Lower latency? Lower egress fees? Higher speeds? Something else?
Trying to arrange my work and personal tasks so that I can play hooky on Friday and go to a demonstration.
What is the demonstration?
The March for Science.
I won’t do all of it, but I’d like to get 1-2 things done. I’ll play it by ear.