I guess I'm the only one who is still on x64. I don't like I'm pushed to migrate only because the software wants that, otherwise the hardware works with no problem.
"Does the hardware physically work" isn't ever really the question under consideration, though, for better or worse. For Macs specifically, it is going to get increasingly difficult to even test things in the coming years. Mac x86 builds are by far the flakiest on GitHub in my experience, there's no expanding capacity, only refurbished machines 6 years out, and the number of users is dwindling, not to mention the enormous performance gap. So what do you do? When we last asked about it in a project I work on a few users expressed interest, so we kept it, but that isn't forever. The JDK as a project probably has a different risk profile than most other projects too so the cost of keeping around that code can be relatively high.
Not saying it is always good, in fact I would say there is rarely a "good" happy outcome in these cases, just trying to give the alternative perspective when you have to make these calls.
The writing has been on the wall for the last 7 years and the LTS of JDK 25 goes until 2030, 11 years from the point Apple announced their intentions. Java for Mac apps or native Java backend development has always been niche as well. For Java development for Linux hosting, you still have a path forwards beyond 2030 with virtualization. How's your SPARC dev machine holding up?
That's just how things go. But, existing Oracle JDK versions will continue to work, and openjdk might continue to support osx/amd64 as a target.. so I wouldn't worry too much about this.
In the same way that PowerPC and m68k hardware still works, sure. Apple silicon is so performant that (much like those previous two hardware jumps) it's not worth maintaining support for the old arch at this point.
> I don't like I'm pushed to migrate only because the software wants that, otherwise the hardware works with no problem.
This is one of the problems with the switch from shrink-wrap software to always-upgrading software. Customers feel like they bought a thing so it should work forever but what they are really asking is that new software be continually written for the hardware they bought years ago.
If you want to run your old hardware with your old software forever, you can. But of course in a connected world where a million malicious parties are trying to take over your system, this is probably a bad decision, and that’s where the tension arises.
Java 25 is an LTS, I guess you can use that for a couple of years still. But at some point of time, macOS will be too old and all kinds of software will no longer install.
Intel Macs can run practically anything. Mine had a triple-boot between macOS, Windows and Arch Linux, back when that kind of thing was possible.
Apple's really cut off gaming for good. My only hope is that someone ports FEX/Proton to macOS, or finds a way to get it running with proper hardware acceleration.
Why? I can upgrade, that's not a problem. I'm just saying macOS works fine so far, almost all of the software works too. But I see increasing amount of announcements like this one suggesting that I'll have to replace hardware to get the latest versions. So I guess I will do that only to be able to use that software, not to get better performance.
I feel like Apple got a lot of devs who would otherwise be Linux users on board circa 2005 due to solid-feeling laptop hardware with drivers and power management that just worked. That pattern became self-propagating as startups scaled up, bought a lot of Macs and hired Mac IT people.
But Linux has gotten better in that time period, too. I wouldn’t say it’s quite as refined out of the box. But Linux is ahead in the ability to do whatever you want and keep using your old hardware.
For people who care about how computers work, I think Linux is a more stimulating environment than macOS to work in. Even though—or partly because—you may have to dig in a little deeper to get things working the ways you want.
LLMs have completely changed how I run Linux. I just got a brand new Lenovo and getting the fingerprint sensor PAM configuration going for sudo was a breeze. I was having issues with my wifi not switching APs properly on my mesh and debugging and implementing a stable permanent fix took the same amount of time as what would previously have been just the start of me googling to the problem. And now that it's done the experience is really nice. An absolute dream even.
Have just read above that it's possible. It's interesting actually. So I guess I'll do that once I buy a new mac. I have a maxed out pro, with i9 and so on, so throwing it await would be a shame
Exactly. The commit message is supposed to be for the future developer, not to generate changelog.
And the main case when that developer reads the commit message is when he doesn't understand _why_ that commit exists. Not what it changes, but what is the purpose of certain lines. So he runs "blame", sees commits, the original developers are not with the company anymore, the old JIRA may not exist too, and the only hint is the commit message.
Nice project, thank you for working on it. I was trying to figure out the architecture, and I understand that it runs a Deno VM to execute JS on the backend?
I was working on something similar, but for JVM backends [1]. And it seems there are a lot to learn from your project. For example, I'm using GraalVM that executes JS on the server. But I have to compile JS to WebAssembly because otherwise it produces a lot integration issues on the backend. Do you do the same?
Thanks for checking it out! rari uses V8 (via deno_core bindings) embedded directly in the Rust runtime, not a full Deno VM. We execute JavaScript directly on V8 without compiling to WebAssembly.
The key is that deno_core provides clean Rust bindings to V8's C++ API, which lets us run JS/TypeScript with minimal overhead. We handle module resolution, imports, and the React rendering pipeline all in Rust, then execute the actual component code in V8. No WASM compilation step needed.
Your JVM project looks cool! The GraalVM → WASM approach makes sense for JVM integration. We avoid those integration issues by keeping everything in the Rust/V8 ecosystem. The tradeoff is we're tied to V8, but we get native performance and direct access to V8's features.
That may sound strange, but it turns out I don't use WASM as well. Last time I touched this part was ~8 month ago, and WASM was just one of the experiments, and I forgot about this. Just remember it was hard to find a right approach initially, on how to execute JS without NodeJS environment. But with a right set of polyfills it works now.
Anyway, I see we have a bit different approaches on how to handle JS part, and I could get some ideas from that.
I'm curious why you can't legally pay in crypto?
I heard a few times about companies paying in crypto to their remote workers. In fact I heard that a US company was paying in BTC withing the US, though I'm not sure I trust this particular story. I also see that Deel accepts USDC, and to my understanding they convert to local currency of the remote worker.
Is that all illegal? Truly want to understand.
It's not illegal, but you have to do all the paperwork the same as if you pay in USD. That means tax withholdings and all that, on a per-pay-period basis. Doing this basically means going through a payroll provider. When I had an employee we paid in BTC, we had to go through a licensed company to actually do the BTC payment to our overseas worker (Circle).
The way it worked was our payroll provider would release the paycheck in USD to Circle, who would do conversion to BTC at prevailing exchange rates same day before executing the transfer.
If we already had the money in BTC, we would have had to convert the money to USD to send to our payroll provider so they could do withholdings and all that, and then have Circle convert it back to make the transfer.
There are foreign transfer reporting requirements and rules about currency conversion at payment time so that you can't skirt paying taxes. If you try to do it yourself you're making a lot of extra work for yourself.
You misread. You can't legally pay through transfers (between wallets). You need an intermediary that verifies identity linked to wallets and does escrow to satisfy anti-fraud requirements.
It's probably legal as long as you do all the same accounting/withholding that you would normally do. I suspect some companies are forgetting to do that, just as many people forget to report taxes on crypto.
I had a bad Cloudflare experience. So, my card on file got no balance one day (my bad, I forgot to update to a new card), and they just turned off the services.
They somehow managed to charge partial amount (like 80% of the bill), but decided to turn off everything anyway, even the services that could be covered by those 80%. They turned off what they offer for free, and we were unable to change the setting, like instead of their CDN point traffic to an S3 bucket, etc.
When they do that they basically freeze your account. I mean you cannot provide a new card to pay the outstanding bill, or do anything at all actually. You're not welcomed here anymore. Locked out. That's is a terrible way to react to a payment failure after being a paying customer for a few years.
It was hard to reach the support, and it took multiple days until I found someone on Reddit who looked at our ticket and it eventually helped.
PS I had much worse experience with GCP after being a loyal customer of them for like 15 years, so Clouflare is good.
We made a script to avoid such situations. It checks the dependencies, just by parsing the package.json (or the lock file), checking the relevant time on npm registry, and returns error if it finds a too fresh package added.
We run it on CI for each commit/PR, and if a developer tries to commit a change that updates a JS dependency to a too recent it prevents the build from running, and so on. Basically we expect that a Supply Chain attacks on NPM would be noticed in a couple of week, and we enforce this time window to our code.
Ah, I had a similar situation with them. They also closed my personal account immediately after closing the business account. I was really surprised it works that way.
I mean the arrest. But as I just learned [1] he is being allowed to make periodic travels to Dubai since recently. So things got better for him now, but that's just since July 2025. Before that he was physically staying in France since August 2024, which I would call as "living" as it's the place where he spent most of his time.
AFAIK the recommended way is to open a bank account through smaller banks (aka neobanks). They just send you a card to address specified and once you activated it you (first) get a bank account for payments and (second) can use it to prove address for others.
Also, if you legally rent then you get the council tax documents, though it takes roughly a month for them to send. This is another proof of address.
And the bills of course, but again it takes a month or so to receive the first letter.
So it's unclear how a digital ID solves anything in regarding the proof of address.
reply