evmar

8th added line in the patch has a stray period

I integrated Unicorn, the underlying qemu-as-a-library, into my emulator project:

https://neugierig.org/software/blog/2023/11/retrowin32-unico...

My experience with it was that it was a lot slower than my (not very good) emulator, I imagine because I was some using it wrong somehow (? qemu is high quality software). And also as I was using it I was managing to corrupt state somehow in a way that meant it didn't end up ultimately helping with the thing I was trying to debug.

FWIW the sandbox-disabling bit in xz was in CMake logic, not autoconf. (Or at least the obvious one is in the CMake part; maybe the autoconf is separately backdoored.)

https://git.tukaani.org/?p=xz.git;a=commitdiff;h=328c52da8a2...

Nice try, Jia Tan.

Not to defend this practice, but some missing context here (AFAIK, I wasn't involved): this isn't the FB app, but apparently "Onavo Protect" followed by "Facebook Research" apps, the latter of which reportedly explicitly paid people to install it for the express purpose of collecting this kind of data.

I did a little experiment with this here:

https://neugierig.org/software/blog/2023/01/compiling-advent...

They discuss this: "Table 1 illustrates that CoT paths do not consistently outrank non-CoT ones in the model’s probability assessment." and then look at table 1 to see some examples. E.g. in the first one the top 8 paths are wrong and it's the 9th that is correct.

Initially it was a combination of just for the fun of it (it's a small script, as OP described). Secondarily there was the feeling of "everyone is going to go work at [major competitor]" and I was curious whether I could collect the data to show it. (I never ended up looking into this, but maybe HR did.)

As a dumb script it was not designed to be especially flexible. One thing I remember needing to fix was that by its nature it was archiving old data and preserving it, which meant that it was accidentally deadnaming trans people. My recollection is this was a small code fix, but an interesting lesson in social consequences of oblivious software.

It was still going at the time I left (~2y). Most of the work of keeping it alive had been done by others for the last decade, so I hope someone else is still carrying the torch.

We had the occasional HR interaction but to my recollection never anything nasty.

You are both right. Originally you could not email, and like the OP I kind of liked the ceremony of entrusting someone with a message to send from beyond the grave. But someone contributed the code to make the email work, likely after the OP's time.

I made epitaphs! AMA

I'm sure the database is nice for other reasons, but also without really understanding the problem it sounds like you could represent two separate things here: (1) metadata about photos and their metadata sync state, (2) embeddings.

You could store a dense mapping to integers in (1) and then represent (2) as a separate file that is literally just packed floats. Photo number n has its embeddings start at file offset n * 512 * sizeof(float). Updating any given photo's embeddings is an easy seek+write.

Given that the use case of similarity search is to stream through the embeddings and not any complex seeking/rewriting/indexing/etc, feels like a relatively simple bit of code.

The post talks about serializing 100k photos. With 32-bit floats each embedding vector is 4*512=2048 bytes, so that's ~205mb of data, much less than the >500mb quoted in the post.

When I opened a Rust project I think the status bar said it was downloading Rust support, which supports your hypothesis. (Also it doesn't make much sense to bundle these things when they are all making new releases at different schedules.)

This looks really nice, but I am confused why the install is over 350mb, including a 300mb binary. I thought Electron-based stuff was big but this is even somehow more!?

This article seems to make performance assertions that are not supported by what actually happens.

E.g. "Passing by value is slower, since a new variable has to be created. Passing by reference just passes an address and the code uses that address – no new variable is created." is not right for the example involving an int*, as passing a pointer is clearly as much data to copy as an int (and in the non-pointer case it will all end up in (faster) registers).

Similarly if you paste the "Returning a copy of a structure" example into godbolt you'll see GetDateTime4 writes directly into the caller's pointer. https://godbolt.org/z/Wj4Gn1YaP

Man, I remember* getting "coffee encrusted filet mingon with a vanilla glaze" at Charlie's back around this time, and thinking both "this is amazing" and also "this can never last". Also I remember many years later when they were instead serving stuff like hot dogs. RIP the good times!

* likely corrupted by memory's distance

Side note, most comments here are talking about Linux, but despite Windows having a nice async IO API, it turns out that it sometimes is also just sometimes synchronous, yikes.

It includes some pretty big cases like "if the filesystem is encrypted" or "if the write extends the file": https://learn.microsoft.com/en-us/previous-versions/troubles...

Possibly another way of expressing your point: after writing my above comment, I found myself wondering how much a system that kept these UAF pointers alive longer (to eliminate the UAFs, e.g a GC) would actually reduce the attack surface -- the UAF-ish bugs are still bugs, and code poking at a GC-preserved object that the rest of the code doesn't really expect to still be alive might itself be pretty fraught.

I have written a lot of Rust, and I am describing something different. Rust lets you write code that cares a lot about memory (with lifetimes etc.) with either compiler assistance or without. What I am describing is code that doesn't much care about memory and would be happy to sacrifice performance for it.

It's interesting to browse the large collection under chrome/browser/ui and ponder over how many of them are use-after-free for data where the performance of manual memory management really doesn't matter. Like [1] which is around the lifecycle of a "choose a file" dialog.

It feels like in the big picture sense it would be better to just always using some sort of smarter/slower pointers in this kind of code just for extra defense. I saw in [2] there is some sort of `raw_ptr<T>` type [3] that seems to intend to help, so maybe the crash in [2] was actually successfully defended against?

It's too bad that there's not a good way to have a broader way to switch between dialects within a project where in one place it's "this portion of the code is perf-critical and carefully reviewed" and in another "this portion of the code is perf-oblivious and has lots of async state that's easy to get wrong". I've wondered if it's almost worth mixing two separate languages (like a GCed one for the latter) just to make the distinction clear.

[Disclaimer: worked on this code many years ago, wouldn't be surprised if I caused >0 of these bugs...]

[1] https://bugs.chromium.org/p/chromium/issues/detail?id=120103... [2] https://bugs.chromium.org/p/chromium/issues/detail?id=132323... [3] https://source.chromium.org/chromium/chromium/src/+/main:bas...

If you're looking into a .wasm file I wrote an interactive viewer called weave[1].

Here is a demo with some Rust output: https://evmar.github.io/weave/?wasm/rust.wasm be sure to click on 'code' to dive into individual functions.

[1] https://github.com/evmar/weave

Ironically in the US if your car is heavy enough you get a tax break, which the auto manufacturers know and target: https://www.mbotw.com/section-179-tax-exemption/

As a person who was initially disappointed by Go and who has come to love it, one of the biggest things I learned from watching it grow was the following:

As far as languages go, Go is relatively well-funded. You can of course imagine hypotheticals where there was more money behind it, but on the spectrum of PLs it's got more support than most. And further, I think the core developers who work on it like rsc and bradfitz are objectively great implementers. Despite that, the majority of complaints about Go are a lack of language features; you even see some in this thread.

In other words, a language with an above-average amount of effort and ability and 14 years behind it is still perceived as feature poor. But imagine how much more time it would have taken if they had taken on a larger scope, like if they had gone through all the complex design process for generics up front.

For me it is a great lesson on how important reducing scope is for shipping, and also how a reduced scope enables you to more judiciously choose what is important. If they had decided that features X, Y, Z were table stakes for their launch they would never have had the time to do the other things that I think have made Go great.

In n2[1] I needed a fast tokenizer and had the same "garbage factory" problem, which is basically that there's a set of constant tokens (like json.Delim in this post) and then strings which cause allocations.

I came up with what I think is a kind of neat solution, which is that the tokenizer is generic over some T and takes a function from byteslice to T and uses T in place of the strings. This way, when the caller has some more efficient representation available (like one that allocates less) it can provide one, but I can still unit test the tokenizer with the identity function for convenience.

In a sense this is like fusing the tokenizer with the parser at build time, but the generic allows layering the tokenizer such that it doesn't know about the parser's representation.

[1] https://github.com/evmar/n2

For apps that show incremental progress it can be useful for a demo. Here's my build system going:

https://asciinema.org/a/592924

Skimmed the code, seems like https://humungus.tedunangst.com/r/pledge/v/tip/f/pledge.go ought to call xUnveilEnd() (...right?)

I love how half the comments on here are about what a nice person the author of the site is. I, too, have had only positive interactions with Amit!

My project https://github.com/evmar/retrowin32 includes a (Windows-agnostic) pure Rust instruction level emulator for x86, and if anyone is interested on hacking on one I'd love the help!

This is a disappointing post -- they picked up a complex thing that they didn't fully understand, pushed some buttons, and then complained when it didn't work as they expected. I expect more from this blogger, whose content I think of as usually good.

I found the "snacking" metaphor that I think I learned from here[1] really helped me understand why I would sometimes get stuck in these kinds of corners. Its reframing helped me do it less. I find I reach for snacking when I'm confronted with something that is hard, as a way of avoiding it.

[1] https://lethain.com/work-on-what-matters/