Funnily enough, self hosting is why I can't use IPv6. I want vlan isolation, but only get a /64 from my ISP.
Fortunately the lack of IPv6 also isn't a meaningful loss anyway so whatever
12,804 karma · joined March 7, 2013
Funnily enough, self hosting is why I can't use IPv6. I want vlan isolation, but only get a /64 from my ISP.
Fortunately the lack of IPv6 also isn't a meaningful loss anyway so whatever
Fanless just means slower.
It's an Armish not an Androidism. It's an embedded legacy that really doesn't make sense anymore. But inertia is powerful enough that even Apple is still using device trees, even on their M series SoCs ( https://asahilinux.org/docs/fw/adt/ )
Zig and Rust are equivalently "low level". Zig isn't any closer to the hardware than Rust is.
> but I believe its advantage over Rust for that specific application is that you have tighter control over exactly when memory is allocated and deallocated, and how data is laid out in it.
Rust gives you all this, too.
Zig's primary (possibly only) advantage over Rust is that it has much faster compilation times.
The industry where it seems strongest positioned is embedded. Will it actually break into that domain? No idea.
I haven't used the relatively new C++17 polymorphic_allocator, though, maybe it fixes this.
The important part is a language where the standard library isn't special, and Rust has this property, too. So in domains where things like per-frame allocators are useful, you can still have them. That capability just isn't cluttering up the more common path where that isn't useful.
And of the 4 non-preview JSRs in the Java 27 release, only 1 of them is actually part of the "platform version".
The other 3 are strictly changes to Hotspot internals with no platform involvement at all. They did not change any aspect of any Java platform in any way whatsoever. That is what I'm referring to. I'm not referring to the fact that the core library, language syntax, and runtime specs are all part of the same version. I'm referring to the fact that Hotspot specific behaviors and adjustments are also branded as being part of the platform release.
Like there's no Java 27 platform spec that says that G1 is the default garbage collector. That would of course be an absurd platform spec change. But that is still somehow a "feature" of the Java 27 release according to Oracle.
Is that actually a good thing?
But Oracle started playing a game, for better or worse, where they decided to couple the "language version" with a single specific runtime's release schedule. For example, in "Java 27" there are exactly 0 language changes and 1 minor feature addition to the TLS library.
Everything else is OpenJDK runtime internals which don't impact the language or how you use it. So if you don't use OpenJDK (such as if you use Oracle's other runtime, GraalVM), then Java 27 basically doesn't even exist at all. Skimming the past couple of C# releases, it doesn't look like Microsoft is playing that game, so the release cadence will of course be different.
Really? That's going to be your measuring stick? So anything that isn't as successful as GTA 6 is a failure that shouldn't ever exist again? In fact any genre that isn't as successful as GTA 6 should just be wholesale cancelled?
A game is successful if it makes a profit. Other games making more profit doesn't suddenly make them failures. This isn't a zero-sum game.
> A lot of that player based has aged out of the game
What does this even mean? Gamers don't "age out". We're long past the era of pretending Nintendo is a children's toy...
That seems like the obvious player base for a Starcraft 3, and it seems more than large enough for a major release.
Meanwhile how many AAA hero shooters and extraction shooters have we watched get released and been massive commercial flops? Yet we don't consider those to be dead genres?
Otherwise GPUs typically do context "pre-emption" by basically being cooperative and just injecting yield statements in the command queue or on things like tile boundaries for tile based renderers. So the smallest chunk of work they can yield between ends up actually being quite large, and with a full user-supplied program in the middle
It doesn't even need to be computationally difficult, you can also slam the memory bus with "far away" fetches that are randomly distributed, ensuring each fetch doesn't share a cache line with any surrounding fetches. There are popular UX effects with basically this workload, even, that's a naive implementation of a large radius gaussian blur basically...
That's not a thing. Straight from Apple:
"When a photo is taken in the new Reference mode, the camera captures signed sensor data that Private Cloud Compute develops into an unalterable reference image. Reference images can be viewed in the Photos app alongside the main image"
So this only helps prove anything if you can share the original, unedited image. You can share it alongside an edited one, but you must also be comfortable sharing the unedited original if you want to prove you own an iPhone 18 Pro. Er, I mean prove it's "authentic"
Now I think C2PA had allowances for what you're talking about, but that also ended up resulting in it being easier to break.
The problem is real, but this solution seems to not really solve it in any practical sense.
This feature is also standard in existing folding phones. It's a pretty obvious feature tbh.
While Apple certainly looked at the competitors to see what problems they had, it's far from a given that Apple has managed to actually solve the durability issues, either, much less on their first attempt.
And then of course once it's over fiber, nearly any length desired is easily achieved