I think that's already started to happen. I had to buy the Essentials kit this week because a standalone Pi was not available from any distributor, with lead times of up to a year.

This. I have a friend with 1Gbps up/down at his house. I've been waiting for fiber for like 10 years but it's never been available at any place I've lived. This is despite the fact that we live in the same (relatively small) county. This situation could only be possible if they just didn't care about making fiber available to everyone.

I was thinking the same. I hear this company name all the time at my work, so when I saw the title, I did a double-take and thought there was a typo. They even have AI voice command, so I briefly thought it was the same company.

I had to stop driving for four months after I had a sudden major seizure episode. Changes to medication also meant not driving for a similar amount of time.

I have not had an event in years, and no longer take medication, but anxiety about driving and being independent is still something I carry with me.

This article didn't add anything to the conversation.

"Secret management" (i.e. having a non-ClickOps way to deploy secrets and a layer of security so that they're more than just not-configmaps) has been a black hole that has eluded our team for some time.

Should I use SOPS? Sealed Secrets? Vault? KMS? How does this integrate with our GitOps engine? Kustomize has no sensible way to pass secrets built in. ArgoCD actually has to be rebuilt from source to even try any of these options out.

Our current "best" practice is using Helm + Terraform, bootstrapping secrets with Terraform Cloud, and ensuring all services run in their own isolated namespace and service account. This feels inadequate.

At this point, I really have no idea how people are using secrets in the wild.

You can also quit the CLI editor, e.g. vim.

I thought that was a peculiar choice of words as well. I would understand these things under the banner of "Build Engineering", or even just "Tooling". I couldn't figure out the distinction they wanted to make by calling it "Metaprogramming".

Wow, all day? That's a lot!

My team and others have been having "office hours" meetings where everyone is just working, but often the cameras are off, mics are muted most of the time, and we only do it for a few hours a week.

I definitely agree that there is a lot of value in being able to jump in and ask questions in the moment. That's a big benefit of having these calls for us.

Maybe we should try having them more often. :)

It's really not been that bad - we had a few people who were remote initially and they had the cameras on in their home office so we could shout over and ask questions and it would feel like they were in the office.

Now we're all remote so we keep the same meeting open. I guess people have differing levels of comfort.

This tutorial looks amazing. I know what I'm going to be doing the next few weekends.

It’s such a great idea for a book!

I quite like Python but really I want a version all written in NodeJS, so it’s javascript all the way down :)

Hi mjgs. I'm one of the book's authors, and we debated this quite a bit. The reasoning for using Python is written up here: https://browser.engineering/blog/why-python.html

That said, it's pretty easy to follow along in JS if you really want and in fact... Stay tuned, there'll be an update in this space very soon.

Thanks for the reply. I like that you’ve chosen a scripting language, it makes the book much more accessible. If it were in c / c++ / rust etc, I would never read it.

Thanks for sending the writeup of why you chose Python.

As for javascript readability issues, IMO those are non-issues and actually in some ways beneficial to have one language, no need to context switch.

The web workers issue is perhaps a problem, but maybe it makes the implementation easier, even if it doesn’t look much like real browsers?

I don’t understand the networking issue you highlight, you can build any networking functionality using NodeJS, it’s actually very good in networked application settings.

With so many people that write code online in javascript, the book would be so much more accessible. It would be a great compliment to the Python version or any C / C++ version.

I’m interested to hear your update, what’s the best way to get that automatically?

One other thing...this passed by in my feeds last week, I’m not an expert in web workers or browser threads etc, but it seems like it might be relevant, so sharing it just in case:

“A fast, efficient Node.js Worker Thread Pool implementation”

https://github.com/piscinajs/piscina

Right! I'm working with the web since 2006 but still I find this book a must to read.

Yes! Apparently it's still being written.... and I NEED them to get to the CSS bits.

Book author here. A basic styling engine is the very next chapter, so it should be out in about two months, depending on how the writing process goes.

Incredible, thank you!

I believe expanding the simple version into a decently robust rendering engine will be the ultimate way for me to learn CSS.

Thanks so much again!

No doubt I'll do something crazy, that is, try to implement this in C.

I was going to > inb4 rust!, but, isn't Gecko built in Rust?

Gecko is (mostly, at least) traditional C++. Servo is written in Rust.

Would Rust be the best choice of language, given all the back pointers (previous, parent)?

Trees are not that bad in Rust, it's when you have a cyclical structure that Rust is really difficult.

Yes, that's what I meant by "back pointers". In the article, every node has a parent pointer and a child pointer (or several). You can't have both of these pointers without introducing cycles.

The style parts are in Rust, but layout is C++, I believe. servo does have an experimental layout engine (or two? layout 2020?) in Rust, but I don't think that ever reached a point where Mozilla were seriously considering replacing Gecko's with it.

I think Servo is basically a proving ground for replacing components in Firefox with Rust equivalents.

There is a real use case for a tool like this.

I once had to manage a large, locked-down installation of extremely custom Linux distros running on extremely custom legacy hardware.

Python was not available, and definitely not Ruby, so that eliminates a bunch of CM tools. Not sure if it'd even fit on the ROMs of some of them. The hardware was a mix of ancient MIPS and PowerPC and ARM and x86 in the same stack, so compiling anything for the targets would have been painful. Nevermind kernel/libc versions so old that lots of commonly available tools wouldn't even compile on them. Golang has a minimum kernel version, you know. :P

Guess what all these systems could run though. Good old sh and sshd. I could send/receive files with cat and tar. I could collect system info from /proc. I could do pretty much whatever I needed. I ended up writing a tool very similar to this one in spirit, though not nearly as polished, and I didn't get to take it with me when I left the company.

Shell syntax can be obscure and confusing, but when you have nothing else, a shell gets the job done. I'm happy to see someone had a similar problem and solved it, and then made it a thing. :)

Was is plain sh or bash?

I often deal with embedded systems, but they run busybox or ash for ahell. And they often didn’t have find, or sha256, or some other tools considered essential.

And the last thing I would want there is to download files directly from random 3rd party repos without any integrity checks - that is just direct path to weird undebuggable outages.

Yes, there are use cases for shell-based tools, but space.sh isn’t it.