HN user

isopede

289 karma
Posts1
Comments50
View on HN

Yeah, afaik arhitecture dynamic binary translation dates back to at least 1998 (VMware).

If you leave out the JIT part, binary translation dates back to at least 1966 (Honeywell).

Still one of the GOATs, agree.

I have such fond memories of the Nokia N810.

I did my master’s thesis on that device. I had a custom hypervisor running a guest kernel, virtualized networking, and a buildroot userspace. I could SSH into the host N810, then SSH into the guest. I even virtualized the framebuffer at some point and got the “dancing baby” animation playing from the guest. It only ran at a couple frames per second, but it was _amazing_.

It's been a few years since I last looked at it, but I've tried daily running it probably 4 or 5 times over the last 15 years. Usually on Arch, but also some Debian/Ubuntu-based distros. It's fuzzy now but I've tried probably every NVIDIA GPU generation since the GTX 500 series.

I can't remember all the bugs, but I've definitely at least encountered all flavors of flickering bugs, stale updates, GPU crashes, failed copy and paste, failed screenshares, failed videoconferences...

From comments on this thread, it sounds like things have drastically improved and its probably time to take another look.

Somebody sell me on these newfangled tiling WMs. I have been using basically the same xmonad configuration for 15+ years, pretty much updating it only on breaking or deprecated changes. What do all these new Wayland compositors have to offer except "tiling, but for wayland?"

Does Wayland actually work now? I've tried it every few years for over a decade now and every time I ran into showstopper bugs (usually on nvidia cards).

I strongly believe that we will see an incident akin to Therac-25 in the near future. With as many people running YOLO mode on their agents as there are, Claude or Gemini is going to be hooked up to some real hardware that will end up killing someone.

Personally, I've found even the latest batch of agents fairly poor at embedded systems, and I shudder at the thought of giving them the keys to the kingdom to say... a radiation machine.

Interference is a real problem with FMCW radars, either maliciously in the case of electronic warfare, or accidentally in the case you mentioned, with many radars in the same space using the same frequency band. Wifi and cell phones use time division or frequency division multiplexing techniques, but radars (at least current-gen) generally do not.

There are mitigation techniques like randomization of chirp frequencies, choosing different idle times between frames, and signal processing techniques to try to detect interference and filter it out. In the general case, FMCW techniques will always have interference problems.

This is one reason amongst many others that military radars do not use FMCW but instead coded pulse compression techniques.

Is it though? I can run Windows programs from 20 years ago on my Windows machine just fine.

Issues with Linux binary distribution meanwhile are ubiquitous, with glibc probably being the single biggest offender. What's worse is that you can't even really statically link it without herculean effort. I've spent an inordinate amount of my life trying to wrangle third-party binaries on Linux libraries and it's just a sorry state of affairs.

Try taking a binary package from a vendor from even just 5 years ago and there's a non-zero chance it won't run on your modern distro.

Among other things, tooling and vendor libraries. Vendor libraries are often composed of thousands upon thousands of lines of auto-generated C headers and written in some bespoke format. Demonstration code and/or sample drivers are almost invariably provided in C. Of course you _can_ rewrite these in Rust, but if you're an engineer trying to get shit working, you'd first basically have to reinvent the whole wheel just to do bringup.

I don't even want to talk about the state of proprietary vendor tooling...

C++ has long surpassed the point where mere mortals like me can understand it; It's so loaded with baggage, footguns, and inscrutable standards language that honestly I think the only thing keeping it going is institutional inertia and "backwards compatbility" (air quotes).

I work extensively in the embedded space and unfortunately C and C++ are still pretty much the only viable languages. I can not wait until the day rust or some other language finally supplants them.

I don't understand the backlash outside some sort of weird "anti-woke" attitude. Even ignoring all the problematic history, the Lena image hasn't been a good test image for years. It's a 512x512 scan of printed CMYK dots and not particularly representative of the types of files and images we share today. This was true even twenty years ago when I myself was using this test image to do wavelet transforms.

It's time we moved on.

I tried it a few months ago, back in November.

I looked through what I did and in the end, to bring in pw_result, I had to define a failure handler, pull in three separate cmake files for various definitions, define an ASSERT action (because a result type requires an ASSERT fail, apparently?), and set a backend and a handler for pw_assert. At some point I remember it complaining left and right about not having the right I/O methods for printing, etc. I just wanted to try the result type, and for some reason I needed to define I/O mechanisms for my platform.

Is this the correct procedure? I have no idea, because the cmake documentation had (has?) _zero_ examples. If they existed, I couldn't find them. I eventually got it to compile with the following snippet, but I can hardly believe that this is the "intended" way to do it.

  FetchContent_Populate(pigweed)

  include(${pigweed_SOURCE_DIR}/pw_build/pigweed.cmake)
  include(${pigweed_SOURCE_DIR}/pw_assert/backend.cmake)
  include(${pigweed_SOURCE_DIR}/pw_assert_basic/backend.cmake)

  add_compile_definitions(PW_ASSERT_BASIC_ACTION=PW_ASSERT_BASIC_ACTION_LOOP)
  pw_set_backend(pw_assert.check   pw_assert_basic.check_backend)
  pw_set_backend(pw_assert.assert  pw_assert_basic.basic_handler)

  add_subdirectory(${pigweed_SOURCE_DIR} ${pigweed_SOURCE_DIR})

I don't think fiber cables are expensive. I ran CAT6 in my house and at the same time pulled an OS2 single-mode 30m fiber cable to my office for core switching. The 30m fiber cable was $17 on Amazon, plus two 10G-LR modules at $18 each. The equivalent CAT6 is more power hungry, has less range, the cable is the same damn price, and the 10GBase-T SFP->RJ45 transceivers are twice the price of the LR transceivers at $50 each.

I tried to evaluate pigweed a little bit by importing just a single module (pw_result) into my existing CMake-based MCU project. I guess you guys technically do have support, but it seemed unnecessarily difficult to pull in. Just pull the source code in, and link against pw_result right? Nope. I ended up having to spend a few hours working out what the heck facades are, various handlers for I/O, implement my own crash handlers, all the while having to poke through/model existing handlers that had "DO NOT USE IN PRODUCTION" written all over it.

I did end up getting it working, but it was clear that GN/Bazel is the blessed build system and CMake is just an afterthought.

In contrast, I pulled in expected-lite [1] with a single line of CMake's FetchContent, #include'd the header, and it just worked.

[1] https://github.com/martinmoene/expected-lite

I have a rather extensive homelab, painstakingly set up over time. It works great, I love it. Few questions for you guys:

- My real problem is disaster recovery. It would take me forever to replicate everything, if I could even remember it all. Router configurations, switch configurations, NAS, all the various docker containers scattered across different vlans, etc. I mapped out my network early on but failed to keep it up to date over time. Is there a good tool to draw, document, and keep up-to-date diagrams of my infra?

- Backup and upgrading is also a persistent problem for me. I will often set up a container, come back to it 6 months later, and have no idea what I did. I have dozens of containers scattered across different machines (NUCs, NAS, desktops, servers, etc). Every container service feels like it has its own convention for where the bind mounts need to go, what user it should be run as, what permissions etc it needs. I can't keep track of it all in my head, especially after the fact. I just want to be able to hit backup, restore, and upgrade on some centralized interface. It makes me miss the old cattle days with VM clone/snapshot. I still have a few VMs running on a proxmox machine that is sort of close, but nothing like that for the entire home lab.

I really want to get to a point, or at least move towards a solution where I could in theory, torch my house and do a full disaster recovery restore of my entire setup.

There has to be something simpler than going full kubernetes to manage a home setup. What do you guys use?

I miss Car Talk dearly and have wished for a reboot/modern version of it on more than a few occasions. Anyone have recommendations for a contemporary show with a similar bent? The fact that it was a car show hardly mattered, I just loved listening to those guys riff.

So while it is nice that MIT claims to not use legacy now, the process I experienced 20 years ago suggests that alumni still had influence then and even athletics mattered too.

Not to discount your experience, but I don't believe what you experienced would fall under "legacy" or "alumni relations." For those, you would either need to have had parents/family that attended MIT, or a close relation to an alumni. It doesn't appear either of those applied to your situation.

All of the answers have 180 degree rotational symmetry!

For the acrosses, the top left corner begins with DAP. The bottom right ends with PAD. Then OGRE/ERGO, REED/DEER, and so on.

For the downs, it's DORA/AROD, AGES/SEGA, PRET/TERP.

And right in the middle, two palindromes STETS and RACECAR.

Every single letter in the top left has a matching letter in the bottom right. It's an insane feat of puzzle construction.

I've been reflecting a bit on how nature of the internet has changed, and how niche communities that I used to rely on all had specialty forums, mailing lists, etc, with history often stretching back years.

It seems like more and more of these old-school discussion forums are disappearing, and their modern equivalents (discord? subreddits?) just don't seem to have the same feel. DPReview is probably the most recent example, but I occasionally I will still visit specialty forums like eevblog.com for EE, or VW forums for my car. It's hard to imagine finding the same sort of expertise and years-long knowledge base on current discussion platforms.

Where do we go next? What happens when these communities are lost? Where are we to go if, for example, HN were to disappear?