A primary factor in choosing my latest job was having an office to go into. I’ve been going in M-F and love working in person again. I don’t think forcing everyone back is necessarily the right strategy, but instead encouraging teams to re-form around people with similar preferences.
I've also been going in 4 days a week since we signed our office lease a few months ago, I really like it. We still do full remote (since day 1, back in 2018!) but I find that the office really helps with communication, especially amongst leadership. Doesn't bother me if any of the devs are FT remote, but I definitely prefer seeing the CEO, head of business, head of product, etc. all in person.
I haven’t been going into the office M-F but I’m up to a couple days a week and it’s been good to recalibrate to what a full day in the office feels like. The morning ritual of preparation. The commute creating bookends to the workday. Going out to lunch or grabbing drinks after work with colleagues. Maybe I’m the only one, but I really let myself go during part of the pandemic and by going back to the office it feels like I’m coming out of it in some way. I may go back to the office full time for a while just to know I’m making the decision to work remotely for the right reason and not because I ended up that way 2 years ago.
Location: San Francisco
Remote: No, hybrid considered
Willing to relocate: No
Technologies: rust, k8s, video, applied cryptography, xr, rendering
Résumé/CV: https://implfuture.dev
Email: hello @ ^website
Hi HN!
I'm an infra engineer with video and applied cryptography experience. I'm also branching out into xr and rendering, with my eye on hard-tech use cases. I'm never afraid to dive into an RFC (I've implemented pieces of SSH, PGP, VP8, RTP). My k8s experience also runs deeper than just deploying yamls -- I have written controllers/operators for more specialized workloads.
I have been a rustacean since the 1.0 release in 2015. In my experience the steeper learning curve has paid off in dividends as codebase size scales. I love teaching and have helped multiple coworkers learn rust to proficiency. I'm comfortable being the first to bring rust to an org (microservice best practices, CI setup, dev environments etc) and have deployed rust to most targets (server, lambda, macOS, Windows, iOS, android, web frontend, steamVR, Oculus).
If you think there's a potential fit let's chat! :)
If you'd like to play with shaders, instead of using the common balls and sticks, you might try using electron densities. Something vaguely like this[1], which renders (with pedagogically unfortunate representation) densities from GPAW[2] with the python Mayavi renderer. With GPAW, one can precompute and compress densities for small molecules, allowing interactives with realistic dynamics and electron density. How young might atoms be introduced, and how well, if it were done with ipad pass-through AR, hand-tracked hands-on interaction, with physically realistic sticky fuzzy little balls?
WebAuthn is based on public key cryptography. U2F signs website's challenge ("transaction") with your private key that sits in the key fob ("wallet"). SSH and TLS client certs work the same (I can take your public ssh key, and I'll know when you try to log in to my server, obviously).
You don't need a blockchain for identity. The unique feature that Blockchains provide is protection against double spending (without reliance on a single party), but that isn't a concept relevant to authentication.
Everything else in "crypto" is the old boring cryptography. All the zero-knowledge proofs, secret sharing, anonymity, proofs of identity are just general-purpose tools that blockchain systems happen to use.
"I've used a transaction to log in — we should use wallets for identity" is like "I've used my car radio to listen to music — we should replace ipods with cars!"
The root of identity is still not a public key. To perform essential actions on such a website doesn't need your public key. You are only proving that you have access the private key correspondent to the public key stored in the database entry, and nothing else. Authz is still database records and not inherently trustless akin to cryptographic authentication.
Imagine I had a entirely PGP-based comment system, where the key used to sign comments serves as the identity rather than a database record. The software remaining the same, not even the owner of the database can change the text of the comment without also changing the key, which would immediately destroy the utility of such an action. Applications utilizing MetaMask are actually able to develop this kind of application where it's trustless end to end. Furthermore, comments could also be embedded as a transaction to a hash of the URL (or something akin to that), where anyone with an access to a ethereum node, public or private can access a global comments system.
>You don't need a blockchain for identity. The unique feature that Blockchains provide is protection against double spending (without reliance on a single party), but that isn't a concept relevant to authentication.
Blockchain doesn't solve the Authn problem, it only solves the Authz problem. I can hypothetically make my own game which has a DRM that can only be unlocked if your private key owns the access NFT. They are complementary.
> Furthermore, comments could also be embedded as a transaction to a hash of the URL (or something akin to that), where anyone with an access to a ethereum node, public or private can access a global comments system.
Why not just sign content with a private key? Buy a YubiKey for $50, generate a key, announce it to the world via an account you control, continue to host content on non-blockchain servers. Your content can be verified with the same public key and no one can forge it.
I guess I just don't see the benefit of blockchain-distributing your public key, and how that helps protect from forgery. What's to stop me from publishing a 2nd message impersonating you with a new key saying "oops I lost the first key"? Or, conversely, what if you needed to generate a new key with no way of signing it with the older key? Or much worse: what if you haven't posted your key yet and I publish a key for @somebody first? Whatever medium you then use to announce "this person isn't me" can also be used by an attacker to discredit the real public key, or by you to announce your public key.
> the search experience from the taskbar is one such example of an end-to-end experience that is not designed to be redirected
The bing searches that appear in my taskbar search have never been useful and just pollute the local results I’m looking for. I’ve tried disabling them with regedit tricks to no avail.
Nice post! Might be worth mentioning that some data structure implementations already exist in std or as a crate, i.e. std::collections::BTreeSet and petgraph. While it’s good to understand how Rc/Weak/raw pointers work, I always check if there is a battle-tested version of what I need before reaching for them.
My daily driver is Debian WSL2, using wezterm (highly recommend) + tmux for terminal, and vscode integration for IDE. Aside from struggles getting custom subdomains to point to localhost, things have been quite stable.
I never thought I’d be saying this, but I find the Windows window manager the best out of the box, and as a bonus I get to do my unreal/vr dev side projects without booting into another OS.
I stayed on WSL1 for the shared localhost. And WSL2 still have some performance issues related to memory usage and Disk IO.
But yeah, I agree, Windows 10 has a great UX. I switched to windows because of the WSL, and I end up using it less and less over time: ssh, ansible, and avoiding cross-compiling toolchains when building releases, that's about it.
Yeah, I am in a similar boat. WSL 2 with Docker build environments gives me faster build times than my Mac. My default Windows Terminal is a Linux prompt with Zsh. It works surprisingly well. I built a Windows gaming rig and then wondered, “hmmm-this thing is fast. Can I work on it too?” And was delighted that our tool chain didn’t need any tweaking.
Does this replace the winapi crate? I’ve been using that crate for things like IAudioClient3, but it seems to have fallen out of regular maintenance https://github.com/retep998/winapi-rs
It's meant to cover the entire Windows API, so that includes everything the winapi create covers. I've successfully ported over my projects that used winapi with few problems.