rzimmerman

Yes I agree with the sentiment, but I think long comments are useful for explaining why a choice was made. Or an idiosyncrasy of the system like you said.

The COVID vaccines reduce the risk of infection by a factor of 4 and the risk of serious disease by a factor of over 100. You’re right that vaccinated people still get COVID but the vaccines do a very good (if not quite perfect) job of protecting people and stopping spread to others.

As an electrical and aerospace engineer this is something I get asked frequently. tl;dr it's very unlikely to cause an issue, but be a decent person and put your phone in airplane mode during a flight.

First safety. A properly functioning mobile phone from a reputable manufacturer is not likely to interfere with any digital aircraft systems. But that assumes:

* The phone is operating within specs and not damaged

* The aircraft shielding is fully intact and there are no other issues

It's only a matter of time before this causes some sort of issue. Like the Wikipedia article links to, it already probably has caused minor issues. Also, many important systems are analog (like pilot voice comms). I was on a plane that was forced to do a go around at landing because the pilots couldn't hear the control tower due to interference. I wouldn't be surprised one bit if it was someone's phone.

Second, basic decision making in a society. You're trading an extremely low likelihood of putting 200 people in danger or at great inconvenience against.... being able to make a call 6 minutes sooner? Checking your email? To tell someone... what - your plane is arriving? That's all online. Wait 10 minutes.

The number of people with no expertise in electrical engineering and electromagnetic interference who "heard on Reddit/YouTube/from a friend" that it's actually safe to use a phone on a plane and decide to do it is way too high. It's the same thought process as hearing something on Youtube about mRNA causing cancer/magnetism and then ignoring the medical community and skipping a vaccine.

An overwhelming majority of the time, using a cell phone on a plane doesn't matter. But don't do it. Put it in airplane mode. There's not a big conspiracy trying to make you miserable. Experts on this are actually worried about you.

You're right that it shouldn't be a problem but:

* That assumes a device that both meets specifications and isn't damaged (overwhelmingly true, but not universally true)

* Most of these airplanes were designed well before modern cell phones existed. I'd be less worried about highly mechanical systems from the 60s/70s, more worried about electronic systems from the 90s, and less worried about some of the most modern aircraft.

It’s widely accepted “best practice” to not run processes in docker containers as root but I think it does a disservice to not explain why. The top benefit in my mind is to be able to mark interpreted code (server side JS/python/ruby) as read only in case someone gains shell access in the container. It’s great to set up another user for execution, but you should also make sure to copy in code and build artifacts as read-only. I’m curious if people can name other direct benefits to a non-root user other than “I don’t trust docker/Linux process isolation”.

Rocket Lab | Site Reliability Engineer | Full-time | Long Beach, CA | ONSITE

Because operations at Rocket Lab is focused on automation, this engineer will need to develop tooling and metrics that are reliable and maintainable, while thriving in an agile environment where needs change often and software needs to grow to support new challenges. This person will be directly responsible for the design and implementation of network and platform tools (primarily AWS, but also GCP, Azure, and some on-prem assets).

This SRE role will report to the Spacecraft Operations Lead. The Spacecraft Operations group is responsible for on-orbit operation of Rocket Lab spacecraft after launch and orbit injection and works directly with the launch team for mission planning and operational support. The Spacecraft Ops team is also responsible for the backend services and user tools for operating the Photon satellites.

https://www.rocketlabusa.com/careers/positions/site-reliabil...

I think fzf is still a useful recommendation (better fuzzy matching for Ctrl-R). Or just Ctrl-R for reverse search in bash/zsh is a good thing to know.

I also prefer this method - rebase and force a merge commit. It’s pretty much the grouping functionality that the author wants. You can tell a short story or break a merge into a couple parts, and bisect + revert work. You can also link each merge with a merge/pull request and a ticket. Also, an occasional quick fix commit to master works fine and makes sense. Sometimes a merge without a rebase makes sense as long as it doesn’t make the graph too confusing. Different workflows work for different teams, but I like this one.

Also hiring SREs:

Rocket Lab | Site Reliability Engineer | Full-time | Long Beach, CA | ONSITE

Because operations at Rocket Lab is focused on automation, this engineer will need to develop tooling and metrics that are reliable and maintainable, while thriving in an agile environment where needs change often and software needs to grow to support new challenges. This person will be directly responsible for the design and implementation of network and platform tools (primarily AWS, but also GCP, Azure, and some on-prem assets).

This SRE role will report to the Spacecraft Operations Lead. The Spacecraft Operations group is responsible for on-orbit operation of Rocket Lab spacecraft after launch and orbit injection and works directly with the launch team for mission planning and operational support. The Spacecraft Ops team is also responsible for the backend services and user tools for operating the Photon satellites.

https://www.rocketlabusa.com/careers/positions/site-reliabil...

Rocket Lab | Operations Software Developer (Full Stack) | Full-time | Long Beach, CA | ONSITE

Rocket Lab is seeking a Software Engineer to support the development of Photon, with an emphasis on operations software. In this role, you will be working to develop our Space Operations Software that is responsible for commanding and data handling for all of Photon’s operations in space. This role will involve developing software to work with cloud technologies, mission & ground software, customer APIs, and large databases. Especially looking for DevOps + AWS experience.

https://www.rocketlabusa.com/careers/positions/spacecraft-op...

Big fan of “786 - Try it now”

I think they are implying that blood sampling is not a random sample of people (more likely to be from someone who is sick), not that it is inaccurate.

His old posts are more than just solidarity with Palestinians or criticism of the Israeli government (which obviously should never get anyone fired).

> If I were a Jew I would be concerned about my insatiable appetite for war and killing in defense of myself. Self defense is undoubtedly an instinct, but I would be afraid of my increasing insensitivity to the suffering others.

It’s really hard to read stuff like that and not feel attacked as a Jewish person. I know it’s an old post and people change, but I don’t want people walking away from this thread thinking someone lost their job for merely being critical of Israel. That just feeds the cycle of distrust and makes it harder to discuss.

There’s a post (“If I Were a Jew”) that accuses Jews in general of responding to the collective trauma of the Holocaust with “an insatiable appetite for war and killing” in pursuit of self defense rather than compassion for the oppressed. It’s naive, muddles Jewish identity with Israel, and assumes the worst about the motivations of Jews in general. Imagine how offensive it would be to make a similar argument about any other minority group that had experienced oppression in America or elsewhere.

From the post:

> If I were a Jew I would be concerned about my insatiable appetite for war and killing in defense of myself. Self defense is undoubtedly an instinct, but I would be afraid of my increasing insensitivity to the suffering others. My greatest torment would be that I’ve misinterpreted the identity offered by my history and transposed spiritual and human compassion with self righteous impunity.

There’s definitely more than criticism of the Israeli government here (some dog-whistle and overt antisemitism, whether the author understood that at the time or not). But I agree with the commenter - people can change and grow up. I don’t know the full story so it’s hard to really say what’s justified and what’s an overreaction.

It’s widely accepted “best practice” to not run processes in docker containers as root but I think it does a disservice to not explain why. The top benefit in my mind is to be able to mark interpreted code (server side JS/python/ruby) as read only in case someone gains shell access in the container. It’s great to set up another user for execution, but you should also make sure to copy in code and build artifacts as read-only. I’m curious if people can name other direct benefits to a non-root user other than “I don’t trust docker/Linux process isolation”.

I suppose one benefit to docker compose over a strictly systemd setup (even one that runs units in containers) is on the dev side. If your dev team is working on macOS or windows the docker compose tooling will let them spin up the whole system just like on the AWS instance.

Also hiring SREs:

Rocket Lab | Site Reliability Engineer | Full-time | Long Beach, CA | ONSITE (Currently remote due to COVID)

Because operations at Rocket Lab is focused on automation, this engineer will need to develop tooling and metrics that are reliable and maintainable, while thriving in an agile environment where needs change often and software needs to grow to support new challenges. This person will be directly responsible for the design and implementation of network and platform tools (primarily AWS, but also GCP, Azure, and some on-prem assets).

This SRE role will report to the Spacecraft Operations Lead. The Spacecraft Operations group is responsible for on-orbit operation of Rocket Lab spacecraft after launch and orbit injection and works directly with the launch team for mission planning and operational support. The Spacecraft Ops team is also responsible for the backend services and user tools for operating the Photon satellites

https://www.rocketlabusa.com/careers/positions/site-reliabil...

Rocket Lab | Operations Software Engineer (Full Stack) | Full-time | Long Beach, CA | ONSITE (Currently remote due to COVID)

Rocket Lab is seeking a Software Engineer to support the development of Photon, with an emphasis on operations software. In this role, you will be working to develop our Space Operations Software that is responsible for commanding and data handling for all of Photon’s operations in space. This role will involve developing software to work with cloud technologies, mission & ground software, customer APIs, and large databases. Especially looking for DevOps + AWS experience.

https://www.rocketlabusa.com/careers/positions/spacecraft-op...

Rocket Lab | Operations Software Engineer | Full-time | Long Beach, CA | ONSITE (Currently remote due to COVID)

Rocket Lab is seeking a Software Engineer to support the development of Photon, with an emphasis on operations software. In this role, you will be working to develop our Space Operations Software that is responsible for commanding and data handling for all of Photon’s operations in space. This role will involve developing software to work with cloud technologies, mission & ground software, customer APIs, and large databases. Especially looking for DevOps + AWS experience.

https://www.rocketlabusa.com/careers/positions/operations-so...

It’s technically even more complicated than just scaling the day/seconds by to match a Martian sol. There are relativistic corrections that add up over time (Earth clocks would observe Mars clocks ticking at a different and non-constant rate). Good thing this is real :)

Rocket Lab | Operations Software Engineer | Full-time | Long Beach, CA | ONSITE (Currently remote due to COVID)

Rocket Lab is seeking a Software Engineer to support the development of Photon, with an emphasis on operations software. In this role, you will be working to develop our Space Operations Software that is responsible for commanding and data handling for all of Photon’s operations in space. This role will involve developing software to work with cloud technologies, mission & ground software, customer APIs, and large databases.

Especially looking for DevOps + AWS experience.

https://www.rocketlabusa.com/careers/positions/operations-so...

If you can reset your password via email it’s effectively a login mechanism - you’re right. I guess passwords are quicker so it’s another more convenient login mechanism. There are a lot of other “prove you are who you say you are” mechanisms: SMS, rotating auth keys, hardware tokens, biometrics. All with upsides and downsides in security and usability.

Passwords that humans remember are on the low end of both security and usability, so I understand your frustration! Password managers work fine but really they’re duct tape pretending to be something like a hard token.

I’ve seen websites do what you say - always log in with an email verification. It’s not bad. My favorite is a push notification to my phone + watch.

“Don’t run as root in the container” definitely gets parroted without the nuance you describe. Gaining root in a container does not generally mean anything has been compromised on the host. Unless you do something odd (like mounting the host docker socket, weird setuid stuff, or run as privileged) it should be fine to run the container processes as root. It’s kind of the main point of running a process in a docker container.

I understand the motivation of marking scripts and binaries as non-writable inside the container as an extra layer of assurance (along with a non-root user that can only execute). But it’s a disservice to developers if you don’t explain why. A lot of people walk away from this thinking they’re protecting the host OS and wind up cargo-cult-creating a container user with full write/execute permissions.

Rocket Lab USA | Long Beach | Onsite | Full-Time

Hiring an Operations Software Engineer (Space Systems) - https://www.rocketlabusa.com/careers/positions/operations-so...

Looking for someone to help build our Photon satellite mission operations software and services.

Develop software for the operation of space systems and associated ground infrastructure (such as ground stations, mission control, etc)

Develop and evolve ground-based software architecture for spacecraft operations Work closely with flight software developers, operations personnel, and systems engineers to understand requirements and functional needs

Similar to the recommendations to use a YubiKey/hardware token, SeKey on a Mac lets you use a key generated in the Secure Enclave in an unexportable form (https://github.com/sekey/sekey)

> or Bluetooth (which works maybe 97% of the time

Best description of Bluetooth I've ever read.

You can (on most MacBooks at least) restart in recovery mode and do a partition wipe + fresh install with a WiFi connection.

These lists can be fun because they’re a list of inside jokes, but there’s nothing useful or actionable here. I’m not a fan of this type of self-congratulating stuff about budgets and schedules never being right and launch vehicles being too hard. This type of mentality is why most of the industry is stuck in the 60s. Honestly it sounds analogous to wondering why anyone would want a personal computer 40 years ago.

The use of the word “else” bugged me enough that when I put together syntax for Kal (now defunct, but here’s a link https://github.com/rzimmerman/kal) I added “otherwise” as an alias. It’s interesting to see I’m nowhere near the first to come up with that!

Some example syntax:

    unless name is 'Steve'
      print 'Impostor!'
    otherwise
      print 'Steve'

“if” and “else” work, too. But I really did like the “unless” and “but” keywords.

Just because code is touched during the test process doesn’t necessarily mean it has been tested. Coverage is more useful for finding chunks of code that aren’t exercised at all by tests. Branches that never get hit that probably deserve extra scrutiny. Coverage is an interesting heuristic but 100% code coverage is not 100% bug free code.

Likewise, there’s stuff that’s just not worth it to wrap in a test. The effort involved in mocking/wrapping/abstracting sometimes isn’t worth the effort for some code, like simple calls to common libraries, reading a file, CLI help strings, etc. This stuff generally is better served by end-to-end or integration tests. Or just gets exercised naturally as part of development. Or can crash without much consequence.

My point is coverage is a tool that tells you where to look, not the one and only metric that tells you how reliable your code is.