335 karma · joined March 17, 2011
In all seriousness, I would probably throw $10 at a project to design and implement a modern turbofan FADEC + all of the certification artifacts.
Frankly, I've always hated the Gmail web UI, so I never use it. Not in the 22 years I've had a Gmail account.
IMHO, Superhuman gets a ton right... A Superhuman clone (maybe in VIM or Emacs) would be ideal if you don't want the AI features or the $40/month fee. Don't even need to change your mail address, since it connects to Gmail.
Not really looking at colocation, as this machine would double as a heavy duty gaming and flight sim rig. That means at least one regular RTX 6000 Pro. Not sure if I can mix and match with the Max-Q version, or if I even want blower fans in a desktop case (last time I did that was about 16-18 years ago with an ATI card... wasn't a fan--pun intended.)
I envision NixOS at the core... then everything I need virtualized on top with KVM/QEMU. Maybe a dual boot setup with Windows for gaming and Flight Simulator (but I could virtualize that too with easy GPU passthrough.)
Lingering questions I'm working to figure out:
- Will 2 RTX Pro 6000s run on a 1600 watt PSU? Not sure how much higher I can go without calling an electrician. (standard US home.)
- Assuming I plop this into my home office, should I expect the PC to run significantly hotter than my current rig? (3960x threadripper, 128GB RAM, 1600watt psu, overclocked and watercooled 4090.) My water temp, measured at radiator, is about 60c at peak load. (This is the only number I care about, as this is what I have to consider to be comfortable sitting next to it.)
In the early days (before Claude Code mastered Rust,) I would get into this annoying pattern where Claude used different names for variables between tests and implementation, get confused, and then more times than not, would change the implementation to match the test (which was not written first--was not doing TDD and thus not the behavior I wanted.)
Static languages prevent that. I've had great success with Claude writing Rust, and I think it's an excellent language for LLMs not just for low level work, but for production-grade code of all types (I see rust as better aligned to compete with C++, Java, and C#.)
I've also had great success with Claude writing C#. Using Claude, I've built C#/.Net in Linux, deployed in Windows (via Visual Studio) with Claude Code running in WSL, and it's been a great experience all around.
I remember saying to myself, "every single meeting room and common area in this building is designed around the consumption of alcohol--the long bar downstairs, the meeting room modeled after an airport lounge, the meeting room modeled after a smoking club, the meeting room / roof deck...
A year or two later they had that public "me-too" snafu (years before me-too) that led to a founder's resignation, a whole bunch of other people leaving, and then Microsoft acquiring the company. I wondered back then, is this the end of the company?
Perhaps so, but perhaps not... Here we are, 8 years the acquisition, only now lamenting a slow demise. That's a nice run for a startup acquired by a behemoth enterprise software company. With the exception of Redhat (which is debatable,) IBM had no ability to keep a software acquisition's culture, verve, or ability alive past a year or two.
Can anyone with experience with either the AirPods Max 1s or XM-6s tell me what they feel like to sleep with on an airplane (business class with a lie flat bed?) Plane travel is my primary use-case for these type of headphones.
Exploring popular options and finding what works for you is easier than it has ever been, and fun too. The difference between Linux today and the Linux of old is that for most setups, all the pieces you choose can fit together nicely and "just work." Despite all the different flavors and variations and distributions and desktop environments and window managers and the like, pretty much every popular distro uses a recent or near recent version of the monolithic Linux kernel + system-d, so all the important stuff is more or less the same (with tweaks here or there.)
single-gpu-passthrough relies on a script (run outside the app) to disconnect the GPU from the current X.org or Wayland session and then to attach it to the running VM. When the VM is shut down, the script runs this process in reverse. This means you can only run one VM at a time with your main display and peripherals, and while you're running that VM, you can't access your host with your display and peripherals (you can always SSH into it while the VM is running.)
This is the common process for getting single-GPU-passthrough to work. vm-curator helps prepare the system and generates the scripts automatically.
multi-gpu-passthrough is designed to run with looking-glass, but it can also support physical KVM switching if the user prefers.
In the "i can only sort of use one OS at a time" sense, it is like dual booting, but the transition is much faster (since there is no reboot required) and, as mentioned, your host doesn't really go away (you can still SSH into it from another PC on your network.)