fathyb

> On macOS memory can be paged to/from disk. On iOS it isn’t and applications must free memory when asked or be terminated

Not sure what you meant by that, you always could `mmap` files into memory on iOS. Back in the 32 bits days there was a ~700 MB limit due to the address space, but there aren't anymore nowadays with 64 bits. If `didReceiveMemoryWarning` is called on your app, then you need to free resident memory but the kernel will take care of dumping file-backed memory pages for you.

Apple advertised the first iPhone to run OS X: https://youtu.be/VQKMoT-6XSg?t=506

> on the server that is hosting this service

I’m not sure if it changed, but last time I heard HN was running on FreeBSD: https://news.ycombinator.com/item?id=16076041

> just imagine how much performance could be gained if game vendors didn't ignore it

In the case of FreeBSD, Sony used it as the base for the OS on PlayStation since PS3.

If anybody is interesting in learning more about that smearing campaing: https://www.ajiunit.com/investigation/the-labour-files

> An investigation based on the largest leak of documents in British political history. The Labour Files examines thousands of internal documents, emails and social media messages to reveal how senior officials in one of the two parties of government in the UK ran a coup by stealth against the elected leader of the party.

Agreed. For spicier chords also recorded by the Nat King Cole Trio on the same set check out Mona Lisa: https://www.youtube.com/watch?v=NIDX18Xl16s

Link for Europe: https://archive.ph/IHdjm

Now imagine how limited computers are with their ability to count to only 1.

Isn't because in Cars the character itself is the IP, not the actor? For example, if Owen Wilson started cosplaying as the Cars character and making money out of it, he could be sued.

Reminds me of an Archer bit: https://youtu.be/c9uuITbtl-g?t=2

- Oh my god, Slim Goodbody!

- No! No, this is absolutely not that trademark character. Just a unitard with the systems of the human body on it. On a guy.

- On a guy named TV's Michael Gray.

> I don’t know if signatures are verified before or after running but the binary probably won’t even run without being signed by a paying Apple Developer anyways.

It's before. You can code sign and verify macOS binaries with any certificate you wish, including a self-signed one (useful in case you want your private iTerm fork). Note the plugin should be signed with the same certificate as the iTerm app [1], just using a paid account won't work.

[1] https://gitlab.com/gnachman/iterm2/-/blob/b0e6b336a6be9bca00...

Isn't opioid addiction the root cause? People dying of fentanyl are mostly opioid addicts who started with prescription meds [1] such as Oxycontin.

Heroin is close to fent in lethality, and oxycodone is next in line [2].

[1] https://nida.nih.gov/publications/research-reports/prescript...

[2] https://www.cdc.gov/nchs/data/nvsr/nvsr67/nvsr67_09-508.pdf - Figure 1.

I didn't know browser vendors supported WASI! I said that as some of us do not use WASI at all, just WebAssembly itself, so they can save some time by not reading this if they're not interested in WASI and/or its limitations.

I agree, my personal take: if you don't want to get your hands dirty, WebAssembly is not ready for you yet. It'll take at least 5 more years before the tooling gets into a state where things should just work (especially DWARF support). I mean, we still cannot free memory! (actually there is a crazy way by recreating a new WebAssembly instance with a shrunk'd `ArrayBuffer`, but it requires you writing your own memory allocator)

My point is: if you're comfortable working with a slightly obscure microcontroller, then you won't have much problems. LLVM supports WebAssembly out of the box, so it mostly feels like programming for one of those.

Anecdotally: we run a large Rust app in under 1 MB of WebAssembly at Zscaler.

> If you are using WebAssembly in a web browser then you are good, WASI does not concern you.

In case you absolutely do not care for WASI but love WebAssembly for the web.

Just had it too, refreshing worked.

> moving between release or debug affects nothing

I'd start with that, it's an obvious red flag. Switching between both should create huge differences. Also look into `wasm-opt` from the Binaryen project for post-link optimizations, `wasm-ld` from LLVM isn't that great at DCE.

It really depends on what you're using. If you use Rust with `wasm32-unknown-unknown`, you'll likely get small binaries (<200 kB). If you use C++ and Emscripten with all features enabled, then yeah you'll have multiple megabytes with all the libcxx and musl stuff.

Alacritty uses OpenGL ES 2.0 which is not deprecated. It's shipped OOB in macOS through the ANGLE project by Google, mainly because Safari depends on it to provide WebGL support (it's kind of OpenGL ES for JavaScript). ANGLE translates OpenGL ES so that it runs on top of Metal, D3D, or desktop OpenGL.

OpenGL ES 2.0 is probably the most portable GPU rendering API there is, it pretty much runs anywhere. That said, using Metal or D3D should definitely bring noticeable improvements, especially when it comes to memory bandwidth (eg. on Metal no need to send pixels to the GPU memory for atlas-based text rendering).

> The iPads have had the hardware in the M-series chips and the software in the form of Apple's hypervisor framework in iPadOS for a couple of generations now, but Apple hasn't enabled it to be used officially.

They removed the hypervisor framework in addition to the kernel support for virtualization a few months ago unfortunately.

An allocator is free to only `mmap` addresses that are within a range. I think jemalloc could allow you to do that using custom arenas.

Makes it easy to migrate from containers to VMs using the same tooling.

That makes a lot of sense, thank you!

If this was intentional, shouldn't it also affect `mach_absolute_time` which is used by the standard libraries of most languages and accessible to Swift?

Also note you can get precise JavaScript measurements (and threading, eg. using pthreads and Emscripten) by adding some headers: https://developer.mozilla.org/en-US/docs/Web/API/Window/cros...

I believe `CACurrentMediaTime` depends on `QuartzCore.framework` and `Date` is not monotonic.

I would also find it confusing if I found code doing something like network retries using `CACurrentMediaTime`.

`Box<[u8]>` stores the pointer and its length (2 x size_t), `std::unique_ptr<const uint8_t[]>` only stores the pointer.

That's for slices, for dynamically sized types (eg. `Box<dyn ToString>`) it contains a pointer to the virtual table.

https://doc.rust-lang.org/nomicon/exotic-sizes.html

The Rustonomicon is a good start, on fat pointers: https://doc.rust-lang.org/nomicon/exotic-sizes.html

> Because they lack a statically known size, these types can only exist behind a pointer. Any pointer to a DST consequently becomes a wide pointer consisting of the pointer and the information that "completes" them (more on this below).

Another reason it is not true: Rust has fat pointers, eg. `std::unique_ptr<const uint8[]>` and `Box<[u8]>` both contain the same allocation data, but `Box` will be 128-bit on 64-bit systems.

I think that's where you're confused: `Arc` does not do any synchronization, again it's pretty much the same as `std::shared_ptr` (hence the name Arc: Atomically Reference Counted).

Your `Locker` does not do what `Arc` does, even at compile time, because it does not allow concurrent access, like an `Arc<AtomicBool>` would. Your `Locker` is more like an `Arc<RwLock<T>>`.

Best equivalent you can get in C++ is `Arc<T>` = `std::shared_ptr<const T>`.

https://doc.rust-lang.org/std/sync/struct.Arc.html

> Shared references in Rust disallow mutation by default, and Arc is no exception: you cannot generally obtain a mutable reference to something inside an Arc. If you need to mutate through an Arc, use Mutex, RwLock, or one of the Atomic types.

I guess you could get the final pieces to get something similar by creating `Send` and `Sync` traits in C++: https://doc.rust-lang.org/nomicon/send-and-sync.html. I think the main pain point here is that you cannot auto-derive `Send` and `Sync` so it would end up being very verbose.

What is worrying is what it’ll mean for the access to the West Bank and Gaza, as they’re currently the only international media outlet on the field, and are documenting various atrocities that are currently being looked at by the ICJ.

Both are true, Rust just has more restrictions. It’s not completely equivalent, but you can think of `Arc<T>` as `std::shared_ptr<const T>` as in if you use `unsafe` or `const_cast` you can bypass mutability restrictions. Otherwise to mutate you need another abstraction doing `unsafe` things for you, such as `Mutex`.

I mentioned Chromium because they also differentiate between thread safe and non-thread safe shared pointers.

If anything, Rust shared pointers are more similar to C++ std pointers because in Chromium the reference count is inside the class, which is very handy because you can reconstruct a smart pointer from a raw pointer (like `this`), at the cost of needing `T` to extend `base::RefCounted`.

Rust `Box` = C++ `std::unique_ptr`, both have the same ABI (just pointers)

Rust `Arc` = C++ `std::shared_ptr`

Rust `Rc` = C++ `std::shared_ptr` but using a simple integer instead of an atomic so it is not thread safe

`Arc` and `Rc` do not allow you to mutate their contents directly so instead you should use "interior mutability" using something like a `Mutex` (thread-safe) or `RefCell` (not thread-safe), which have runtime checks to ensure no undefined behaviour is introduced. So `Arc<Mutex<T>>` makes it possible to mutate `T`, but `Arc<T>` cannot. Some types like atomics do not require mutability at all, so an `Arc<AtomicBool>` can be mutated directly.

An example of a big C++ codebase using something similar is Chromium, where `std::shared_ptr` is forbidden and `base::RefCounted` (Rust `Rc`) and `base::RefCountedThreadSafe` (Rust `Arc`) should be used instead. WebKit does this too.