belthesar

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.

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.

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.

You're an order of magnitude off there. The 10 Gigabit connection was providing ~ 1 Gigabyte per second of throughput.

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.

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".

^1: https://cocoatech.io/

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.

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.

These were likely made with Foone's Death Generator. https://deathgenerator.com/#sc2k

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.

> 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.

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.

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...

We tried that in 1998! See Swatch Internet Time: https://en.wikipedia.org/wiki/Swatch_Internet_Time

The same way that Element does - they host a service for you that relays push notifications their Firebase Cloud Messaging endpoint for Android or iOS Instant Notifications for Apple. I believe ntfy's hosted option is the way they offset the costs of hosting this, even if self-hosted options can take advantage of those servers free of charge.

I think it's reasonable for Zulip to ask for compensation for access to these gateways, since Apple and Google do not make them available to end users free of charge, and the burden of responsibility to ensure that these systems aren't abused is on them. Also, the fact that they offer mobile push notifications for any self hosted server of up to 10 users is pretty generous, and there seems to be a Community plan option for larger servers that includes "groups of friends" as a qualifier. It really seems they're offering quite a bit.

From a platform risk perspective, each tenant has dedicated resources, so it's their platform to blow up. If a customer with root access blows up their own system, then the resources from the MSP to fix it are billable, and the after-action meetings would likely include a review of whether that access is appropriate, if additional training is needed to prevent those issues in the future (also billable), or if the customer-provider relationship is the right fit. Will the on-call resource be having a bad time fixing someone else's screw up? Yeah, and having been that guy before, I empathize. The business can and should manage this relationship however, so that it doesn't become an undue burden on their support teams. A customer platform that is always getting broken at 4pm on a Friday when an overzealous customer admin is going in and deciding to run arbitrary kubectl commands takes support capacity away from other customers when a major incident happens, regardless of how much you're making in support billing.

Musicians who are being threatened by AI impersonating them, flooding the market with music like theirs, and otherwise actually harmed by this would disagree with you. Benn Jordan speaks at length about it in this video: https://www.youtube.com/watch?v=QVXfcIb3OKo

Lutris by default will use an older WINE version (something based on WINE8 IIRC) by default for reasons I don't quite understand. You can, however, configure Lutris to use proton-cachyos by default, to which I was able to get Battle.net to install and work correctly without issues. Not sure what feature was implemented in later WINE to make that work better, but it works.

"EAC supports Linux, but devs just won't turn it on" is the clickbait answer, but the details are more nuanced. EAC has multiple security levels that a title can set based on the threat model of the game, and most games with heavy MTX that use EAC shy away from it, largely because Fortnite doesn't do it. EAC is owned by Epic, and if Tim Sweeney says that you can't do MTX on Linux safely, then any AAA live services game with in-game MTX is going to shy away from it, regardless of how true the statement actually is.

I feel like this is kind of looking a gift horse in the mouth, especially for the cost of these units. Certainly not impossible to add, but an increase in the BOM vs. the loads of off-the-shelf super cheap HDMI capture chips available, and questionable compatibility (DP Alt Mode is getting better, but plenty of devices still have interesting quirks with it depending on implementation). These devices aren't made with daily driving a system in mind so much as for installation and recovery of a system.

Would it be handy to have this all in one cable on both ends? Sure, absolutely, that'd be killer. I personally don't think it's too big of an ask to use two cables in an installation or recovery case though, and if your devices only have USB-C ports for video out, an active USB-C to HDMI via DP-Alt cable can be had to meet that need.

For use cases like attaching to an SBC or really any other computer, I'm sure this is great, but there are also USB crash cart consoles that can be gotten pretty cheaply like the NanoKVM-USB[0] or Cytrence's KIWI[1]. This gets you both video, keyboard and mouse.

[0] https://wiki.sipeed.com/hardware/en/kvm/NanoKVM_USB/introduc...

[1] https://www.cytrence.com/product-page/cytrence-kiwi

Following the Obsidian model, which I love and support. Give folks the best part of the product, offer a paid option to enhance it, but allow folks to use alternatives as first class options.

Heads up - OP said they entered 400 apps over the past 1.5 months, not since they’ve been unemployed.

This doesn't address everything, but I thought I'd chime on specifically on the chat history question. It's still early days for support from most IRCd's, but IRCv3 has been slowly bringing protocol level support for many of the same features that Slack, Teams (chat), Mattermost, etc. have, including chat history support. It's likely not reasonable for the public IRC networks to ever support history, but for a self hosted IRC server to service your team/company/community/whatever, it would be totally feasible to connect and receive scrollback.

Hack Club is a non-profit community, so the bulk of their user count isn't non-profit employees or even volunteers or mentors, it's a bunch of kids hanging out and making cool stuff.

Maybe that doesn't move the needle on whether they're a small non-profit or not for you, but it's different than a massive non-profit like, say, the Prevent Cancer Foundation, which also receives millions of dollars per year to facilitate their mission.

“But why” is an ever present question on Hacker News, with the announcement of Dropbox being rebutted with “But why, we have FTP”.

Not every idea that rethinks an existing system will have the same merit or success of course, but I think it’s fair that sometimes a potential user will say that they think their existing system is fine and that others should adopt it vs consider something new.

With my v.92 soft modem, I was able to regularly connect at 48k, and sometimes 53.3k. I never connected at theoretical max of 56k.

Worthwhile to also mention that ISDN was full duplex, instead of half-duplex like dialup. The modems on either end would need to time-slice to allow bi-directional communication, which in a TCP laden world like the web meant that every interaction was orders of magnitude more latent than on ISDN, in which you had symmetrical, full-duplex 56k of bandwidth between you and the ISDN modem. That's the biggest reason why you had a significant decrease in latency.

Seems like the GP may have forgotten to paste/type the entire URL. https://duckduckgo.com/careers redirects to https://duckduckgo.com/hiring.

One of the big questions that I haven't seen a compelling answer for re: heat pumps in the US is why heat pumps are so expensive compared to AC exchanges. The amount of equipment differences between an AC and a heat pump are largely a valve to reverse refrigerant flow and the small bit of electronics to control said valve. Yet heat pump units in the US are significantly more expensive for effectively the same COP and operating efficiency ranges as their cooling-only brethren.

Oh this is exciting! I didn't know about this, thanks for sharing!