lexlash

The Home Assistant-branded ZBT-1 [0] is $30ish and, if your goal is Home Assistant, you're probably better off going that route especially now that IKEA is going all in on Thread/Matter (which the ZBT-1 supports in addition to Zigbee.)

I do have that particular Sonoff dongle - as well as a ZBT-1 - and I can vouch that the dongle works as well as the Hue hub it replaced, controlling a couple dozen lights.

(Obligatory prime-day-is-not-much-of-an-actual-discount so don't worry if you miss out on this sale - https://camelcamelcamel.com/product/B09KXTCMSC)

[0] https://www.home-assistant.io/connectzbt1/

I've introduced mithril at three different companies to audiences of non-UX engineers and it went well each time, resulting in small, static, API-driven single page applications. For my Software Engineering class, I'm able to get the basics across in a day and let students iterate without having to set up build tools for them. Huge fan.

React seems to be a self-perpetuating ecosystem at this point, and I keep reading about the next framework-of-the-month being tied to a specific vendor or having an uncertain future with funding/bugs/forks.

https://mithril.js.org/

Died fighting off a patent troll: https://www.theregister.com/2023/02/13/linux_ai_assistant_ki...

Saving some clicks:

$10/yr for the first year, $8 for the second, $6 for the third year and onwards uninterrupted.

$1/$0.80/$0.60 per month for the first/second/third year uninterrupted.

I paid for the VS Code theme. I will be passing on this.

https://plugins.jetbrains.com/plugin/26007-monokai-pro/prici...

I see; that's L3, L4, and L5 progression in a nutshell at Google - although leaving L3s alone doesn't _guarantee_ something will go wrong, it was more that there was no way for them to figure out optimal solutions without help thanks to the sheer complexity of Google.

I'd say the same held true at Amazon but I was in groups which were, at the time, at the periphery of the company's engineering efforts - we didn't have any associated principals to talk to, and maybe one SDE3/L6 to 10 SDE2/L5s mixed with SDE1/L4s.

The most interesting thing is the timeline at the end, which shows what they were successful at and promoted for (management-type roles) and what happened when they tried to transition from SRE management to SWE IC (they fell back into management).

I don't see that reflected in the rest of their postmortem learning - other than them being dissatisfied with doing what they were good at / promoted for - so that kind of helps me ignore the rest of the postmortem. :)

To be fair to her, those contributions are quite old and probably not representative of current skills.

I'm not sure what you mean by "junior" here.

L3 is early career, L4 is mid-career, L5 is senior. You can hit L5 on the strength of pure technical contributions regardless of business/org needs, usually.

L6+ is staff, and tends to involve a very different skillset. (If you're not looking to lead a team, you're probably not going to have the kind of impact that gets you to L6, let alone L7 or higher at Google.)

This is all to say that ICs in the L3/L4/L5 bucket generally show a clear progression in technical skills but beyond that it's fuzzier.

Yeah, as an ex-SWE, seeing this person take just over two years to get from L3 to L5 is kind of shocking.

https://www.levels.fyi/?compare=Amazon,Google&track=Software... is largely accurate. An L7 at Amazon would have an easy time getting an L6 interview at Google; an L6 at Google would not have an easy time getting an L7 interview at Amazon, barring prior experience and other modifiers.

Of note, The person who wrote this article spent the vast majority of their tenure as a SRE TL/M, from their timeline. That's not going to map cleanly into any career track at Amazon, and when this person tried being an L6 SWE, they transitioned back into management.

At Google, I knew L6/L7/L8 managers who were fantastic engineers; I knew L6/L7/L8 managers who were pure-management and excellent at that but hadn't written code in a decade and change. Varied dramatically by what the org needed - those engineer-managers tended to have a lot of lower-leveled engineers and the pure-managers had more highly leveled engineering reporting to them.

Anyways, while I was at Google, L5 was the lowest level where you could officially have a direct report (not counting interns), so yeah, anything of cross-team note was generally lead by an L6 or higher. (L5s routinely lead things that were critical _inside_ of a given group, but if you were having cross-team impact, well, that's L6 work.)

Off the top of my head:

1) glibc doesn't static link and musl requires you to understand how musl is different from glibc (DNS resolution being a favorite), so you always end up with at least that dynamic dependency, at which point might as well have more dynamic dependencies

2) static binaries take significantly more time to build, and engineers really hate waiting - more than they care about wasted resources :)

3) static linking means having to re-ship your entire app/binary when a dependency needs patching - and I'm not sure how many tools are smart enough to detect vulnerable versions of static-linked dependencies in a binary vs. those that scan hashes in /usr/lib and so on. If your tool is tiny this doesn't matter, but if it's not, you end up in a lot of pain

4) licensing of dependencies that are statically linked in is sometimes legally interesting or different versus dynamic linking, but I'm not sure how many people actually think about that one

I've also personally had all kinds of weird issues trying to build static binaries of various tools/libraries; since it's not as common a need, expect to have to put in a bunch of effort on edge cases.

Resource usage _does_ come up - a great example of this is how Apple handled Swift for awhile - every Swift application had to bundle the full runtime, effectively shipping a static build, and a number of organizations rejected Swift entirely because it lead to large enough downloads that Apple would push it to Wi-Fi or users would complain. :)

You don't need to run bleeding edge versions unless you feel like it; there's a stable release with rolling security patches every 6 months (current is 24.05, next will be 24.11).

You don't need to keep multiple copies of each library - but you _can_ when you find out that an update broke something you care about while still updating everything else on your system. You aren't rolling back your entire system state, just the...light-cone of the one tool that has issues.

The problem with SO numbers is that your Python/Ruby/Java/NodeJS packaging and tooling doesn't respect that at all. If you can satisfy all of your dependencies using the Debian-maintained repositories great! When you can't, Nix provides a harm-reduction framework.

Nix also makes certain hard things trivial - like duplicating the exact system state that someone else used to build a thing some months/years ago, or undoing the equivalent of a `dist-upgrade` gone awry.

And then when there's a security problem, who goes and checks that every version of every dependency of every application has actually been patched and updated?

The nixpkgs maintainers, same as the Debian maintainers. Repology's down right now but nixpkgs seems to do quite well on a CVE level.

Why would I want to roll a system back to an (definitely insecure) state of a few months ago?

Insecure is sometimes preferable to down. Being able to inspect an older/insecure state with new/secure tools is neat.

I have many of the same questions about Snap and even Docker.

Snap and Docker solve similar problems that most people don't have. Same with k8s. You might just not have these problems - I have a screwdriver on my desk that's specifically for opening up GameCube consoles (so it's longer than the one I use to open up N64 cartridges, even though it's the same shape); unless you have that specific need, it'd be completely pointless in your toolbox and cause you trouble every time you tried to use it.

NixOS aside, Nix manages state _outside_ of / independent with respect to your operating system, which is why it's so damn useful.

With Nix, I can build OCI images the exact same way every time; with Docker, I have to hope that the `apt update` thrown in at the top doesn't accidentally put me on a new major version of some dependency that breaks the rest of the script. I tend to deal with Dockerfiles written five or more years ago, so I will admit to bias here.

I'll also admit that I don't really enjoy NixOS. It's neat enough on my headless devices but not something I'd want to try to daily drive; I'm more a fan of the Universal Blue / Project Bluefin approach.

Chiming in to say that direnv is one of the greatest projects I've ever come across and it gets damn near everything right out of the box - you can also use it without any Nix at all. (It makes a nice gateway to Nix, though; once you have your directory-based env vars, it's a shorter hop to directory-based package configuration...)

Nix, and NixOS, are designed for those of us who have to clean 10,000 proverbial litter boxes every day. I use Nix fairly extensively at work; I use it very little at home, where I don't need to worry about what dependency someone took on a specific version of Python five years ago, etc.

It's like k8s, imo - it solves some real problems at scale but is rarely going to be a good idea for individual users.

https://www.nixhub.io/ - and I’ve seen others - make the searching easy. It’s odd to me that I rely so much on web based tools (like search.nixos.org!) to look up nixpkgs details for my commandline but eh.

For a flake, you’d specify an input of that specific revision of nixpkgs and then refer to your CMake dependency with respect to that input. You may end up with - by design - a lot of duplicated dependencies, but it’d work.

https://blog.mplanchard.com/posts/installing-a-specific-vers... is a nice writeup (not mine) with examples of a few different ways to do this in flakes and not-flakes.

Cheap clones of the DE-10 Nano ($99 target) are allegedly on the way along with new boards that make different tradeoffs with the pins. Should be interesting - there’s a lot of life left (PSX/N64/Saturn are all very recently added) imo but the price and availability issues are unfortunate.

Like `tmux -CC` and iTerm2?

https://iterm2.com/documentation-tmux-integration.html

Having been down this path - asdf didn’t go far enough in creating reproducible/sealed environments, the quality of the plugins per language varied dramatically, shims made a lot of assumptions about how tools will be used, and you can expect to throw asdf away the moment you need to deploy and then have to build something else.

I don’t like Nix but I haven’t found anything else that scales along those critical requirements. I don’t think it’s a good idea to simply replace rbenv/nvm/etc with asdf-ruby-plugin and so on - unless your software isn’t intended to leave your development machine?

(Docker for me fails in the opposite direction - fairly miserable to develop with but trivial to deploy.)

There’s some really annoying edge cases I’ve found once Xcode gets involved and graphical apps are a bit hit and miss (Wireshark failed pretty completely for me a few weeks back.) I’d still call it a major improvement over the alternatives.

Re: onboarding - I’m doing the same thing at a somewhat larger scale. Same username on twitter if you want to start a support group. :)

That’s every solution, honestly - you’re just choosing what % of users will need help, and frankly asdf has a lot of edges. Nix’s self-contained declarative stuff is a pain to learn, certainly, when used to brew install $whatever - but it’s far easier to support.

Also it plays really nicely on macOS unless you’re trying to share nix config across macOS and Linux which…just fork and move on, it’s not worth it. :)

In my experience, nix-darwin and home manager are a little awkward to install together (you’ll want both) and central management is…tricky. All of these being large company problems, mind - I can’t rely on the median user googling to fix issues, they expect (reasonably) an actively supported platform.

I’ve also had issues with GUIs and Xcode as noted in other comments but I don’t mind that - those are much more of a solved problem than, say, keeping seven different JDKs around.

95% of the difficulty I have at $DAYJOB is nix installation and dealing with enterprise certificate/auth crud…sadly devenv doesn’t help much there.

Our pilot is quite a bit larger. Sticking to plainer flakes has made it easier for folks to self-service for now but we do intend to re-evaluate devenv.

Same username on twitter if you’re interested in chatting.

Having tried asdf - among other tools - for awhile, dropping it for nix+flakes+direnv was great.

Devenv seems nice (in fact it’s how I started down this path) but I haven’t found anything it does for me that I can’t get out of flakes - so far.

“Guillable” says it was maybe only half way edited, at least the version I just read.

So something in the realm of Proxmox or PVC or xcp-ng?

I would agree that the three things I can list here are a hard sell compared to any integrated cloud provider - they all focus on VMs and the rest is up to you, or so my experience has gone so far. Looking forward to trying this out!

At least they gave sizes in American and metric this time.

Snark aside, rounds to 30mm diameter and 6.5-8.5mm height, if memory serves.

Your link discusses how to install fusefs-exfat, which is a separate package, which is what all Linux distributions did before the 2019 licensing - Android had a separate licensed kernel module, etc. I can’t speak to the current state of BSD but a cursory search yields a lot of discussion.

Regarding the encumbrances in general, https://en.wikipedia.org/wiki/ExFAT covers this, notably:

Companies can integrate exFAT into a specific group of consumer devices, including cameras, camcorders, and digital photo frames for a flat fee. Mobile phones, PCs, and networks have a different volume pricing model.

exFAT is the official file system of SDXC cards. Because of this, any device not supporting exFAT, such as the Nintendo 3DS, may not legally advertise itself as SDXC compatible, despite supporting SDXC cards as mass storage devices by formatting the card with FAT32 or a proprietary file system tied to the device in question.

On 28 August 2019, Microsoft published the exFAT specification and released the patent to the Open Invention Network members. The Linux kernel introduced native exFAT support with the 5.4 release in November 2019.

So yes, this has been annoying for years (2006-2019, at a minimum) and left a very bad taste in my mouth as someone who has a few dozen SD cards that regularly move around various embedded devices that are expensive, rarely receive updates, and work just fine (e.g. 3d printers, digital frames, regular printers, local storage on security cameras, adapters for retro hardware, etc.). The Wikipedia article notes that the Nintendo 3DS - 75.94 million units sold during its 2011-2019 lifespan [1] - lacked exFAT support, so it’s not like this only affected low-end/cheap/uncommon devices from small companies.

Windows “helpfully” disabled all ways to format large SD cards as FAT32 so I end up having to rely on a third party tool.

Of course, whenever possible, I use a sane and journaled filesystem but it’s rare that I have a choice. :)

[1] Numbers sourced from https://en.wikipedia.org/wiki/Nintendo_3DS

True. I have to say I enjoy the 3’s standard strap so far - huge improvement over the 2 - but the elite strap was part of my day one order :)

Far, far more usable. You’ve got a much wider FOV and much better head tracking (6DoF vs 3DoF) and that’s before the basic improvements you get from having more resolution to play with.