pbnjay

Yeah that's all I could tell at the time. Things were still snappy enough at my low usage, so I just assumed it was my older hardware being a bear. But it was definitely bumping up my power draw unfortunately.

Fun to see the emulation heading up the stack, I wish my employer could afford some real oxide racks!

About 4 months ago, I booted helios + omicron on bare metal on a server in my homelab (following the YouTube here: https://www.youtube.com/watch?v=qwXtS0-r1uQ). Performance wasn't great on my old hardware (32cores, dual Xeon 2.6ghz, 256gb DDR4), and it used like 30% CPU while idle, but it was fun poking around and playing with the software while I could.

Enrollment123 | https://e123insurtech.com | Staff Platform Engineer | REMOTE (US) | Full-time

We are SaaS platform that connects Insurance Carriers, Agencies and Agents, and enables sales to consumers.

My team is hiring a Staff Platform Engineer to keep things running smoothly and help our engineers modernize and build new products.

We are responsible for:

    - security for PCI and HIPAA data
    - AWS infrastructure that serves millions of people every month
    - developer tools and infrastructure to allow our teams to deliver
    - data engineering and operational support
    - automation, monitoring, and on-call rotations (especially during Open Enrollment!)

Our stacks include:

    (70% --) SQL Server + ColdFusion
    (25% ++) Postgres + node/typescript
    (5%) Airflow + python

It's not a flashy product or stack I'll admit, but we have a lot of opportunities to improve the product and a lot of growth potential to expand our impact. Happy to tell you more!

If you're interested, email me at [email protected] with your honest, hand-written resume. I don't want some super polished AI bullshit, show me your real experience! The interview process is hopefully short and sweet: 1) meet with me for a quick intro to ensure we'll be a good mutual fit, 2) advance to a technical interview with the team, then 3) a last culture + company info session so you have all the info to make a decision.

Sorry, given our industry and size, you must be in the US and able to work without visa sponsorship.

Re: the slight wobble, you should be able to find some inexpensive thin-sheet backing board at a hardware store. Use small ribbed tacking nails or glue around the edges to attach it at the back, and it should help stabilize and prevent racking.

Um a lot of US zip codes map to multiple cities. Some even to multiple states. If you build a picker for city/state this works fine but your premise is easily refuted if you look at the data!

Zip codes map to postal routes, not polygons

For anyone reading this later, I got my data export and deleted my account and got a pro-rated refund. So double whammy!

I had kept my Plus subscription just because I was lazy, and it was inexpensive and convenient… but this turn definitely helped me get off the fence. I am exporting and deleting my data now, and the cancellation is already done.

I feel like excluding French toast is a serious faux pas here!

Breakfast burritos are also at least as important as quiche (as in, neither are as tasty without addins - just like omelettes).

FYI this is not true in the US. Zip codes identify postal routes not locations

I’m building an ETL tool that “just works” and gets out of the way. I can write shell scripts and python to do this stuff but honestly I just want to drop my files/API results into a GUI tool and have it combine things for me. Landing page is at https://eetle.com

Yes I was very excited to see the new json encoding changes land, can’t wait to try them out! The new omitempty and map key marshalling in particular will help clean up some of my ugly code.

Dropping the kids off at the pool is a euphemism for a bodily function that diuretics like coffee help with…

Probably gets pretty costly if you’re running a lot of data through it. Now if you could implement a Tailscale DERP server in a lambda that would be pretty amazing: https://tailscale.com/kb/1232/derp-servers

Given the redundancy of multiple locations, I think even cutting power it would be difficult to cause an extended outage.

I have a variety of Shelly 1 devices in my house, one of which is on the oldschool Garage Door opener (with a reed switch for open/close tracking) - Very inexpensive, flexible for other applications, and works with HA etc.

https://us.shelly.com/products/shelly-1-gen3

Would be trivial to show the results live though, especially for atomic values: https://go.dev/play/p/PRzzO_skWoJ

Isn't it even simpler in Go? No channels necessary, Each goroutine gets an index or slice, and writes the results to a shared array.

All you need is the goroutines to report when done via a WaitGroup.

API tool to automate all the stuff Postman makes painful: https://callosum.dev Spec generation from request logs, automatic schema generation and validation, test generation (eventually), totally offline, no accounts or cloud sync necessary!

Been taking longer than I hoped but should be released soon (next few days)

Re: the grid connection backlog - much of the challenge of turning on new generation is simulating the increasingly complex ways the grid can fail due to all the interconnections. It’s a huge computational challenge and there’s really not much incentive to speed it up

API tool to automate all the stuff Postman makes painful: https://callosum.dev

Spec generation from request logs, automatic schema generation and validation, test generation (eventually), totally offline, no accounts or cloud sync necessary!

Been taking longer than I hoped but should be released soon (next week or two)

How granular are the durations? If days for example you could bucket into N-week intervals (eg intervals with 7N consecutive days) to reduce the search scope. Then you only need to store start times, and can join or use a set to combine other ranges with the same availability.

That's their math, the 23.8t/s is already the 64x but they didn't 64x the other stats.

Yeah... They are using a single-core 13W measurement to project out. For a 64x parallelization - no mention of any overhead due to parallelization or power needs of the supporting hardware. This is a key quote for me (page 12 of the PDF):

> The 1.3B parameter model, where L = 24 and d = 2048, has a projected runtime of 42ms, and a throughput of 23.8 tokens per second.

e.g. 64 x 13.67W = 874 Watts to run a 1.3B model at 23.8 t/s... I'm pretty sure my phone can do way better than that! Even half that power given their assertions in the table are still overpowered for such a small model.

I mean shared hosting certainly existed but "the cloud" as we think of it today was much simpler and not nearly as ubiquitous. It doesn't really change the principles themselves but it certainly affects aspects of the risk calculus that dominates the table of contents.

Published in 2010? Curious how much of it has survived since then?

I like “Design It” because of some of the workshop/activities that are nice for technical folks who need to interact with stakeholders/clients (I’m in a consulting role so this is more relevant). Also it doesn’t lean hard on specific technical architectural styles which change so frequently…

Wouldn’t be too hard to add a secondary “file” in the zip with an extra index