JeanMertz

I love the work you are doing in Bevy. I often filter the PR list based on your handle just to see what big graphics/performance work you are cooking up.

I unfortunately do agree with you on the BSN syntax, I guess it's a matter of tradeoffs, but I don't think backward breaking changes are off the table for the foreseeable future, so curious what can be done to improve the syntax in the next couple of releases.

Although what I really look forward to is auto-formatting of the syntax, I care about the feel and look of the syntax, but I care even more about consistency across my code base.

I have my LLM/gaming PC tucked in a rack in my basement:

- 100ft DisplayPort + USB cables going to my home office's monitor - 100ft HDMI cable going to the TV on the wall in my home office - 30ft HDMI + USB cables going to my receiver in the upstairs gaming/tv room

Works great. I can control/game from any of the three screens, and I also have Moonlight to sometimes control the PC remotely either in the house (bedroom) or externally via Tailscale.

I have an old Steam Link lying around, but I never have a use for it anymore, so while I can understand that there is an audience for Steam Machine, if you are capable, and have a dedicated gaming machine, a couple of long active/fiber HDMI+USB cables is all you really need.

  Location: CEST TZ
  Remote: Yes, exclusively.
  Willing to relocate: No
  Technologies: Rust (4y), Golang (5y), Ruby (5y)
  Résumé/CV: https://jeanmertz.com/career
  Email: [email protected]
  Call: https://cal.com/jeanmertz

I am a senior software engineer focused on the combination of high-level abstract APIs and low-level performance-driven systems. I am an avid learner and an excellent communicator. I am a pragmatic ethical engineer with a knack for software architecture, an eye for user experience and a capacity to lead.

Clippy has an (off by default) lint to warn/deny using multiple versions of the same crate.

We've been discussing potential solutions, and came up with three avenues, listing their pros and cons. We're leaning towards a "Sandbox accounts in production" approach at the moment, but recognize that none of the solutions are free, and whatever we decide on will have a big impact going forward.

Production-like environment

  + Clear, separate environment
  + No impact on production data / users (events, emails)
  + Not a problem if we mess up data without cleaning up afterwards
  + Runs the same code as on production
  + Requires very little changes to existing code

  - non-production code can (and will be!) deployed, making it no longer "production-like"
  - data needs to be kept in sync, to be usable by clients
  - every service needs to run both a production instance, and a production-like instance
  - all external services need to work with this production-like setup (payments, emails, etc...)
  - higher ongoing maintenance overhead
  - requires "manual agreements" on how to manage/manipulate this environment

Individual temporary environments

  + all the pros of the "Production-like environment"
  + even more isolated, higher guarantee of your expected state of the environment

  - requires a lot of CI/operational changes
  - requires ongoing maintenance to keep working
  - requires "operational" knowledge to make new changes work with this setup
  - requires more syncing of data
  - higher costs of running

Sandbox accounts with special "capability" flags, in production

  + All test-data is scoped to a (sandbox) user account, single "source of truth" on wether some piece of data is test-data
  + One single environment to maintain, no divergence
  + Data is always the same as production
  + Whatever code runs on production, is what you test
  + Because you want to test your changes, you automatically make sure your new code works with sandbox accounts / capability flags
  + You deploy your pre-production changes behind a capability flag, for testing
  + A preference page allows you to enable/disable certain capabilities to enable real/fake PSP environments, pre-release functionality, etc...

  - Much more complex to realise
  - Only works (well) for user-scoped test-data
  - Might result in higher learning curve to ship a feature that works with sandbox+capability flags
  - Production data can be changed accidentally, there's nothing but our own code between test and production data
  - Other systems need to be able to handle (and/or ignore) test data
  - Only suitable to the specific use-case of testing user-flows, not for testing f.e. if a library upgrade broke anything

We booted a fresh GKE 1.4 cluster yesterday to migrate from our old 1.3 cluster.

Looking at the machine, it looks like this is a fork(?) of CoreOS:

  $ grep core /etc/passwd
  core:x:5000:5000::/home/core:/bin/bash

  $ cat /etc/os-release
  BUILD_ID=8820.0.0
  NAME="Container-VM Image"
  GOOGLE_CRASH_ID=Lakitu
  VERSION_ID=55
  BUG_REPORT_URL=https://crbug.com/new
  PRETTY_NAME="Google Container-VM Image"
  VERSION=55
  GOOGLE_METRICS_PRODUCT_ID=26
  HOME_URL="https://cloud.google.com/compute/docs/containers/vm-image/"
  ID=gci

  $ toolbox
  Spawning container core-debian-jessie-backports on /var/lib/toolbox/core-debian-jessie-backports.
  Press ^] three times within 1s to kill container.

If not a direct fork, it certainly uses the same base Chromium OS (which is no surprise) and uses some of the same toolsets that CoreOS uses.

Not sure if you are serious, but while Azure is from Microsoft, it is definitely not Windows only. In fact, most of the products coming out of the "new" Microsoft pipeline aren't in any way tied to Windows.

Kudos to them, and awesome to see people working to get Kubernetes to work on Azure.

Whoops, that shouldn't happen. The team is unable to reproduce this though. Could you share the link where you tried to sign up?

If you want, you can send me an email (see other comment) and we'll get this sorted.