belthesar
Joined 18 years ago
Karma
1,094
Submissions
305
Member since
May 7
[ my public key: https://keybase.io/belthesar; my proof: https://keybase.io/belthesar/sigs/JEWdr1ik37zcC15gBkrWDSAk5zgAD80jPaJsUvEmINY ]
View on Hacker NewsRecent submissions
Comment · 2 months ago
I know this doesn't address all your concerns, but I switched from Ableton Live to Bitwig Studio for unrelated reasons to my leaving Windows behind, and I was thoroughly pleased with how easy the transition was between the two DAWs (I guess it shouldn't be too much of a surprise given how many ex-Ableton devs work on Bitwig), and how well the Linux build of Bitwig worked. Bitwig on Linux, with Pipewire as the audio engine for low latency operation, is essentially an identical operating experience for me.
Getting your plugins working is a different story. A small but growing number of mainstream audio plugins have native Linux builds available, a wide swath of them work quite well with yabridge (https://yabridge.org/ - so shim to expose Windows audio plugins running in WINE prefixes to Linux audio plugin hosts), and a few required alternatives to be found.
I found the workflow decent enough to use, but as one might expect, some plugins not working well via yabridge/WINE made things a little janky, and once I picked up a Mac device again, that became my production machine. That said, WINE's come a long say since I last tried this out a few years ago, and I'd be interested to see if things work better.
My point, I suppose, is to share a reasonably good success story (though perhaps still not of a grade that you'd be comfortable switching to for paid work), and perhaps to encourage you to consider some alternatives to the tools you use. Tool changes are expensive, sure in cost, but moreso in time, so I don't suggest it lightly. That being said, I think that it might be worth it to grab a Bitwig trial and see how you like it. I'd grab it both on Windows and Linux, so you can try it "how it should work" when your plugins and the DAW are working in harmony while also getting the Linux toolchain working. And from the cost perspective, Bitwig does not have crossgrade licenses, so you can buy Studio once, and run it on any supported platform.
Comment · 2 months ago
I see merit in both approaches. The emulation approach preserves the original experience, which is valuable when you want to experience the work in its original form. This is great for scratching the nostalgia itch, as well as anyone who wants to study the original work. The porting approach transforms the original work into a form that is approachable to the modern game player. This is great for people who want to play a game but are not as concerned with a "vanilla" or the as-it-was-released experience. This could mean the port surfaces new controls (touch controls for phone/tablet devices), or applies quality of life changes to patch out frustrations.
Comment · 2 months ago
macOS's OOM manager suspends and pages out processes when it hits a hard OOM event, and then usually (though not always) brings up a window to help you decide what to kill. However, once you do that, you have to then resume those processes that were suspended using that OOM window. If you don't do that (or if the process is terminated for you without the OOM window showing up, then a restart is the simplest solution to restart those processes.
Comment · 3 months ago
You're an order of magnitude off there. The 10 Gigabit connection was providing ~ 1 Gigabyte per second of throughput.
Comment · 3 months ago
I still find that, even after all these years, Pandora's recommendation engine still seems to be the best. I can tune into stations that I created, jeez, 15+ years ago, and it might play one or two tracks that I know, but it quickly diverges into new tracks that are still within the "flavor" of the station, but I've never heard of.
Comment · 4 months ago
During the days of my Powerbook G4 and 1st gen Intel Mac days, I used to use Path Finder [^1] over the native Finder, as it provided a richer and more comprehensive toolset. The base Finder wasn't bad, but Path Finder did more. Totally understand in today's era why you might jump to enshittification as the reason for this. Sometimes though, someone see the functionality a tool does, and goes "I wish it did this, but a little bit more".
Comment · 4 months ago
Point of clarification:
While Bungie had historically been tied to Xbox / Microsoft during the Halo era, Bungie spun out to be its own company in 2007, and then was bought by Sony in 2022. It was Sony, not Microsoft, driving the most recent layoffs at Bungie.
Comment · 5 months ago
Same here, haha. A very cool coworker a decade ago was the person finally able to convey to me how to change that up, and it was lifechanging.
Comment · 5 months ago
These were likely made with Foone's Death Generator. https://deathgenerator.com/#sc2k
Comment · 5 months ago
There is not an alternative frontend that I'm aware of, but as the article mentions, the clients are Apache 2.0 licensed, so in the event of a rug pull, a fork and rebrand of the clients would be what is needed to restore service.
Comment · 6 months ago
> but cell tower data isn't going to be as accurate as GPS
Worth noting that 6G MIMO beamforming requires being able to calculate incredibly accurate location information in order to tune the signal towards your device. I don't know enough to be able to speak more in depth about this, but my guess would be that the adage of cell AP based aGPS is likely to be able to surface far more accurate device location than before.
Comment · 7 months ago
Nested virtualization can be very handy in both the lab and in production. In the lab, you can try out a new hosting platform by running one atop the other. IE: Proxmox on VMWare, Hyper-V on KVM. This lets you try things out without needing fresh bare metal hardware.
In prod, let's say you run workloads in Firecracker VMs. You have plenty of headroom on your existing hardware. Nested virtualization would allow you to set up Firecracker hosts on your existing hardware.
Comment · 7 months ago
Cost-wise, there's a solid chance that the Pi would have been more expensive. Jeff Geerling ran some numbers (^1) on this last year, before the current chip crisis we're in, and it was bad enough already.
Home Assistant does a surprising amount of Disk I/O, if for nothing than for logs. Sibling commenters are also advising not running it on the SD card to avoid wearing it out, so there's definitely some truth here. This means we're adding a Pi M.2 hat + SSD into the mix. The Pi5 SSD kit for 256 GB, when it was available, was around $60 USD. A Pi5 with 8 GB of RAM is $130 USD. Now we need a cooler, a case that will fit the Pi5 with said M.2 hat, and a power supply. We're already well north of $250 USD, encroaching on $300, and we're not even using the core benefits of the Pi's platform. No need for GPIO pins, tightly integrated cameras or other sensors, none of that.
For all we know, the blog author did this assessment (or trusted the assessment of others, eg: Jeff) and came to the came conclusion - it wasn't worth the price of entry.
^1: https://www.jeffgeerling.com/blog/2025/intel-n100-better-val...
Comment · 8 months ago
We tried that in 1998! See Swatch Internet Time: https://en.wikipedia.org/wiki/Swatch_Internet_Time