kllrnohj

JerryRigEverything won't tell you how easily the hinge gunks up or cruft gets stuck in places it's not supposed to be or how quickly crease marks show up and how bad they are.

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.

do you know of any that actually exist? All I can find are active cables that go up to 15 feet which is a lot better than the 3ft of copper but still a far cry short of running to another room easily

HDMI over fiber is readily available. USB is more annoying depending on the speeds you desire, but again USB over optical exists.

And then of course once it's over fiber, nearly any length desired is easily achieved

Except people aren't leaving C++ for C, if they're leaving it at all they're likely leaving it for Rust or some other memory safe language.

In the case of this article, even assembly isn't low level. It's not possible at all to write low level code for a modern superscalar CPU.

So no, Mojo wouldn't be low level. It can't be.

So what should they do instead? Just give up? Assume that it's simply inevitable that Google will cancel AOSP entirely and so Graphene should hurry up and die?

Which wouldn't have actually done anything about this bug fwiw since this wasn't a memory safety issue with any C/C++ code itself

This "only" escapes the JavaScript sandbox. You still need to chain it with an escape for the process sandbox. So it's not just the boring stuff of turning a predictable crash into arbitrary execution, but also finding a second RCE vulnerability to chain this with

And yet I just installed Antigravity, and it had a default checked box to also install Antigravity IDE. So someone still cares enough to try and juice the install numbers

Indexing into an array is direct pointer access, there's just an addition in front of it but it's hard to imagine that showing up at all in even the tightest of benchmark loops

Apple's use of "Professional" is just a fancy alias for high end or premium, it in no way indicates anything about being "for professionals" (most extreme example: "professional" iPhone models)

Hence why they had to make up the "Studio" brand for the workstation market, because they'd already fully removed any meaning from "Professional"

If a process is allowed to execute code, it's always allowed to execute arbitrary code as well. Those two are fully intertwined, be it via dynamic executable code, ROP chains, because it has an interpreter, or because the initial binary itself already is the malicious payload in the first place.

To the OS those are all identical scenarios, it's irrelevant what caused the arbitrary code execution to happen.

No, you're not understanding mine. Nobody builds an OS/system expecting that every executable is perfectly well behaved with zero bugs and zero ill intent. Applications are allowed to run code. JITs just run code in that same process. They are already limited to what the process was already allowed to do in the first place.

And my point about C is literally that even without a JIT, applications can still have arbitrary execution vulnerabilities.

A JIT intended to run untrusted code as part of a sandbox, like a browser, is a big risk. But that's because of the untrusted code part, not the JIT. By comparison, something like a Python or Java JIT is as near as makes no difference completely risk free. The JIT is working on exclusively "trusted" code. Same basic concept applies here with this database usage.

No, it isn't. JITs don't grant capabilities abilities an equivalent interpreter doesn't already have.

Allowing code execution allows code execution, that's it, that's the entirety of it.

Nonsense, there's no "system wide implications". Mappings are per process, and W^X is just a strategy to help harden individual processes, not the entire system. There's no herd immunity here.

JITs do not grant the ability to bypass any OS/system sandboxes. The lack of W^X doesn't do that, either. If a process opts out of W^X, such as to enable a JIT, it's voluntarily making itself less hardened, but at the end of the day this isn't any more meaningful than the program being allowed to be written in, say, C, which also voluntarily reduces the processes security hardening.

> Android has always been more source-open than “open source”. The vast majority of community contributions that make it into the codebase are security fixes and small bug fixes.

I believe this isn't actually about "Android" at all but rather Pixel. Android is still openly accessible on git. But the kernel sources for Pixel devices is now behind this big song & dance for some fucking inexcusable reason.

Even AOSP has selinux enabled by default with very comprehensive and scoped policies. That, along with app isolation and permission system, already leaves desktop Linux far, far in the dust on security.

The remote tech support scam using screen sharing apps like team viewer is unfortunately very common and is basically why this exists.

It's also patronizing to ask during setup or whatever if the user is dumb enough to get scammed like this, even though that is kinda the actual piece of information needed

> Flutter has completely replaced it's rendering engine across all platforms

And that new rendering engine is also why apps like Immich are unable to show HDR photos. Apple & Google both pushed broad support for that a couple years ago, with things like Ultra HDR and subsequently ISO 21496-1.

Meanwhile Flutter still doesn't really have wide gamut support https://github.com/flutter/flutter/issues/189155

Of course they need to prioritize where to spend resources, like any project, but Flutter also doesn't seem to be on any critical path for fancy headlining new features, either.

LLMs make the dev environment almost irrelevant. llama.cpp supports AMD with both ROCm and Vulkan and that's nearly all that matters now. TBD how much AMD's AI Halo play will change things if at all, but they got a lot of positive press in launch reviews for having an actually robust software story for once.

That's fine, the device will have long since done the check-in and enabled the option.

And it's not contingent on "vendor support" in the typical sense it's used. As in, this doesn't stop working after the 5-7 year support window

Any storage device can die, that's why you have a robust backup system, right? Right...? :)

But the flash storage in a phone is going to be the eMMC variety which typically means a proper controller and TLC NAND. Not as robust probably as a "proper" SSD/NVME, but a lot more durable than most micro SD cards. And it'll have health indicators.

Building your own is cheaper, although not by a ton. Valve isn't taking a loss on them.

Well they still just do the same thing GPUs do where bad clusters are disabled. There's going to be a balance there for how big the clusters are and how many tiers they'll offer, but that's a known problem which can be well modeled.

Larger wafers has been attempted for over a decade now and doesn't seem to be going anywhere. See the 450mm wafer section of https://en.wikipedia.org/wiki/Wafer_(electronics)

Cerebras is literally the entire wafer, so it can't get bigger. So where is the jump from 30x to 100x coming from? Node improvements only yield like 10-20% gains these days...

> Author talks about 4k video, but AI tells me that for "4K production mastering (ProRes 422 HQ, 4:2:2, 10-bit)" the rate is under 2Gbps.

That'd be the rate for 1 stream at 1x playback. Multiple streams because of overlays/crossfades/etc... along with playback at >1x (such as during rendering in particular) will change that significantly.

it's hardly difficult to do that already. Like a Raspberry Pi Pico can be turned into a HID mouse rather easily: https://www.instructables.com/Raspberry-Pi-Pico-As-HID-Mouse...

and yes, hdmi/displayport capture -> ML object detection -> fake HID mouse to cheat is absolutely already a thing.

So the risk is the plug for that being yanked in the ~2-5 days between ordering it and unlocking it? So... not a big deal at all. Not even slightly lol.

> Not before connecting it to the internet, even Pixels will go through hundreds of megabytes of data before allowing you to unlock them (see 0)

oookay? Hardly seems like a big deal? It would indeed be nice if the unlocked phones were set from the factory as such instead of all being the same system image as the ones that locked carriers use, sure, but hardly significant since it's not like you have to sign in or anything?

> Also, will Google let me browse the web with "my own OS" without their proprietary services installed on it? (see 1)

Why are you even asking Google at all? Just use Firefox? Don't even need to root or use a custom ROM for that, even.