landr0id

Apple relaxed these rules shortly after the initial Epic vs Apple lawsuit: https://www.cnn.com/2021/09/02/tech/apple-app-store-changes-...

Apologies for being unable to find a better source at the moment, but it links to this press release: https://www.apple.com/newsroom/2021/09/japan-fair-trade-comm...

I have no problem with their opinions but I don’t think it should have been said in a Foundation post.

It may have been updated, but nobody is reading the update.

I'm surprised Firefox didn't warn me when I went to the page. Hostile teleco/MITM waiting for HTTP traffic are a real-world way that nation states deliver exploits.

Hey Andrew, question for you about something the article litely touches on but doesn't really discuss further:

> If the programmer uses async() where they should have used asyncConcurrent(), that is a bug. Zig's new model does not (and cannot) prevent programmers from writing incorrect code, so there are still some subtleties to keep in mind when adapting existing Zig code to use the new interface.

What class of bug occurs if the wrong function is called? Is it "UB" depending on the IO model provided, a logic issue, or something else?

I read the same complaint about the language from people I follow who love and actively promote Nix. So it's not just you.

Sorry for adding to your frustration of "just follow what someone else did" but I recently went all-in on managing my Mac (programs, dotfiles, configs, etc) via Nix* when setting up a new machine recently. https://github.com/landaire/config/tree/main/modules

*Nix + homebrew, mostly because Homebrew packages more macOS applications.

> Your point about exercising caution with forks of encrypted messaging apps is a great rule of thumb, and in general, social proof should NOT substitute for competent software security specialists reading and evaluating source code

Also a great point :) And thank you for the reference.

>As they say in the Github readme, FCM and Google Maps.

Thanks, I didn't notice that. Reading this, I'm kind of surprised that Signal doesn't offer an OpenStreetMaps build as it seems like it'd be more inline with their philosophy.

> Contains no proprietary blobs, unlike Signal

What "proprietary blobs" does Signal have?

I'll also just add: it's probably not a good idea to use any modifications to an E2EE messenger unless you are comfortable with those privacy/security guarantees possibly being violated by the 3rd party code.

The only exception to this would be if I really trusted the goals of the 3rd party, like Graphene.

First sentence:

>I have been writing production applications in Go for a few years now. I like some aspects of Go. One aspect I do not like is how easy it is to create data races in Go.

Their examples don't seem terribly convoluted to me. In fact, Uber's blog post is quite similar: https://www.uber.com/blog/data-race-patterns-in-go/

>However, as already implied in my article, you can get most of the guarantees without losing your sanity.

Yeah sure, but what compares that gives you similar perf, safety, and language features to Rust? I'll use "safety" in a loose term to say "you really infrequently encounter odd memory safety issues". Go for example still has the occasional memory corruption issues with maps in particular although these don't show up too often and the race detector exists.

C# is probably the closest I can think of for AOT? I don't really know what the deployment story for a .NET application looks like these days though.

Go has some language design things that turn people off.

>but they are not the sole source of bugs in applications — as developers of Zed found out.

You called out Zed in the blog post as well but I've not seen the Zed devs expressing regret of using Rust. Is this just an assumption on your part? As someone who's written many UI applications with egui and one with GPUI, I've felt some minor pain points but nothing show-stopping.

I used to write a lot of C#. I used to write a lot of Go. I now write either and basically exclusively write Rust these days and a bit of C/C++ at work. The only time I've really felt the pain of `Rc<RefCell<...>>` gross types was recently when trying to port a game engine's data loader to Rust. It makes heavy use of OOP patterns and trying to emulate that in Rust is asking for a bad time, but I did it out of just out of trying to one-shot the migration and keep logic similar. Not fun, but I knew what I was getting myself into.

Rust has its issues and there are plenty of things to not like about Rust, but this article is giving me the impression that this person has not written much Rust. Unfortunately, many such cases with Rust criticism.

> Memory safety is not that sacred. In fact, for many applications malfunctioning is better than crashing — particulary in the embedded world where Rust wants to be present. You cannot get 99.999% reliability with Rust — it crashes all the time.

Yeah until that memory safety issue causes memory corruption in a completely different area of code and suddenly you're wasting time debugging difficult-to-diagnose crashes once they do start to surface.

> We actually had a recent Cloudflare outage caused by a crash on unwrap() function: https://blog.cloudflare.com/18-november-2025-outage/

There were multiple failures before that `unwrap()` and the argument can easily be made that this is no different than an unchecked exception or a release assertion.

> Sync/Send, Mutex and reference counting (Arc)? Unfortuantely, those lock or simply mess with CPU caches badly, so they are inefficient for multithreaded communication, at least an intensive one. They are safe, but inefficient. Which kinda destroys the first uncompromising thing in Rust — performance.

Doing this the "correct" way in other languages has similar impact? So I'm not sure why Rust forcing you to do the correct thing which causes perf issues is uniquely a Rust issue. Doing this the "just get it done" way in other languages will likely come back to bite you eventually even if it does unblock you temporarily.

There are plenty of times I did a `static mut` global in Rust just to get some shit done and oops, accidentally hit some UB as the project grew.

If it wasn't obvious I am not serious. On the contrary I'm actively making contributions to jujutsu (none involving a quicksave command... yet)

totally. the fact git-quicksave isn't a standard command that commits with an "Autosave" message is pretty short-sighted.

Thank you.

>By the way, could the nonsensical offsets be checksums instead?

If you're referring to those weird "addresses" that quickly became irrelevant, there's a CRC32 somewhere in the header immediately after them. The address value is the same across files with different contents too.

I was talking to a friend of mine about it and he suggested that maybe whatever process generated the files included the file's load address in case it could be mapped to the same address for some other optimization?

For this file in particular I'm unsure.

common.lin is a separate file which I believe is supposed to contain data common to all levels _before_ the level is loaded.

There's a single exported object that all levels of the game have called `MyLevel`. The game attempts to load this and it triggers a load of the level data and all its unique dependencies. The common.lin file is a snapshot of everything read before this export. AFAIK this is deterministic so it should be the exact same across all maps but I've not tested all levels.

When loading a level, the training level for instance contains two distinct parts. Part 1 of the map loads 0_0_2_Training.lin, and the second part loads 0_0_3_Training.lin. These parts are completely independent -- loading the second part does not require loading the first. It does a complete re-launch of the game using the Xbox's XLaunchNewImage API, so all prior memory I think should be evicted but maybe there's some flag I'm unaware of. That is to say, I'm fairly confident they are mutually exclusive.

So basically the game launches, looks In the "Training" map folder for common.lin, opens a HANDLE, then looks for whichever section it's loading, grabs a HANDLE, then starts reading common.lin and <map_part>.lin.

There's multiple parts, but only one common.lin in each map folder. So no matter what it's not going to be laid out in a contiguous disc region for common.lin leading into <map_part>.lin. Part 1 may be right after common.lin, but if you're loading any other part you'll have to make a seek.

I don't know enough about optical media seek times to say if semi-near locality is noticeably better for the worst case than the files being on complete opposite sector ranges of the disc.

I agree and don't think there's any unused data. For `common.lin` for instance my parser reads it basically to the end and there's some small amount of data that's unused. I never actually quantified the amount but I'm fairly certain it's <100 bytes. Probably a bug in there.

The goal post has shifted so far beyond my original intentional at this point. The devs working on the EnhancedSC mod have a strong desire to port some Xbox assets/maps to PC, so I'm mostly doing it at this point as an attempt to help them out.

*On second thought, there's definitely some unused scripting functionality. Script functions which are unused are still included in their parent classes and are loaded if the parent object is loaded, even if never directly called. Whether or not any of this is interesting is another story.

Textures and models though will definitely not be present unless they're used in some non-visible way.

>This is probably a linear (lin) record of how the data was loaded unoptimized from the disk.

Yes, it's buried deep in the details but it's basically just every byte read being written in a linear stream to an output file.

I don't know which stage of grief this is, but since I wrote this blog post I've now ported my IDA debugger scripts to a dedicated QEMU plugin which logs all I/O operations and some other metadata. I tried using this technique to statically rewrite files by basically following DataLoad (with unique identifier) -> Seek -> Read patterns.

There's some annoying nuance to deal with (like seeking backwards implying that data was read, tested, then discarded) but I got this working. Unfortunately some object types encode absolute offsets in them that need to be touched up, so a couple of object types fail to load correctly in external tooling and the PC build of the game.

Now I'm just using this data to completely reimplement the game engine's loading logic from scratch using a custom IO stream which checks the incoming IO operation (seek/read) against what I logged from the game engine to ensure a 1:1 match with how the game loads data.

It's a possibility. Graphene has some traction though and if a potential high-importance target is running the OS, Cellebrite wouldn't want to be doing emergency vulnerability research to respond.

>that doesn’t mean that editing or inserting values to dnsmasq as an unprivileged user doesn’t exist as functionality in another application or system.

The developer typically defines its threat model. My threat model would not include another application inserting garbage values into my application's config, which is expected to be configured by a root (trusted) user.

The Windows threat model does not include malicious hardware with DMA tampering with kernel memory _except_ maybe under very specific configurations.

I say "strangely" because honestly it just seems large for any application. I thought they might not be doing LTO or something but they do thin LTO. It's just really that much code.

Strangely it's the actual binary's .text section that's about 400MB. Time to dive in!

From a previous thread on this topic: https://news.ycombinator.com/item?id=23089745

>It's literally in past WebGPU meeting minutes: Apple objected to SPIR-V due to disputes with Khronos. Tint is a compromise, it doesn't matter who proposed it.

>"MS: Apple is not comfortable working under Khronos IP framework, because of dispute between Apple Legal & Khronos which is private. Can’t talk about the substance of this dispute. Can’t make any statement for Apple to agree to Khronos IP framework. So we’re discussing, what if we don’t fork? We can’t say whether we’re (Apple) happy with that. NT: nobody is forced to come into Khronos’ IP framework."

>https://docs.google.com/document/d/1F6ns6I3zs-2JL_dT9hOkX_25...

I love typing python commands that are 10x longer than a shorthand.

Yes it's easy to set up an alias or shell command or whatever, but that's besides the point :p

I like my Moonlander, but if you want to see a real scam of a keyboard try buying (please don't) one of "WORK LOUDER"'s keyboards like the Nomad E. $350-500, gimmicks you'll never use, non-open-source firmware, cheap build quality, no refunds.

>Xbox One, 2012? Never hacked.

Not publicly :)

Did you reach out to `git` commands to make changes to the repo? If you use jj in a colocated repo you should _only_ use jj to manage the repo to ensure it's kept in-sync with jj's data.

If you messed up with jj commands, you can use the op log to fix https://jj-vcs.github.io/jj/latest/operation-log/

Yes. There are plenty of folks who submit to the company I work for who live in regions of the world that are extremely low cost of living/salary (in USD terms) and most BB programs pay out fixed USD rates. It can be very lucrative.

Just search for vulnerability or 0day acquisition platforms and do some research into the companies. All of them are kinda shady but there are some which only sell to Five Eyes if you want to be “moral”

You can also go through ZDI (owned by Trend Micro), but the payout will be lower. It’s in Trend Micro’s interest so they can get ahead in detections.

I hate to be one of those people that asks “what differentiates this from X”, but is there a selling point for why I’d want to use this over https://github.com/theseus-rs/file-type if I’m in a sync + std context and don’t really care about dependency count?

Honestly one of the biggest selling points of jujutsu for me is its `op log`. You can fuck up your repo in git and that's it -- you're screwed. Or you find some extreme magic on the internet that saves you.

With jj you just "jj op undo <operation_id_that_fucked_your_repo>" and you're fine.

Editing prior commits is also pretty easy, which in turn makes fixing merge conflicts pretty easy too.