aidanhs

Honestly, I struggled with this overall.

For context: I'm mostly unaware of actions of US presidents (beyond the broad sweeps based on left vs right) and I've at most listened to Trump and Biden maybe a couple of times for a total of ~1min in the last few years - just doing this exercise has probably at least doubled my exposure.

I found the text and voice mostly impossible unless the content clued me in. Video was a little easier because I know to look for teeth, video with sound was fairly easy.

Is there a generic trick for recognising faked voices without really knowing the original (similar to looking for teeth on videos)?

This is missing a lot of detail around libc (can't comment on the others), but was published ~1.5 years after musl was first released - I can imagine the subtleties being missed in a glibc monoculture.

To expand a bit:

1. dlopen has interactions with static linking that you should understand if you use both at the same time. Different libcs expose different symbols for libc functions, so building your dynamic library against one libc may make it incompatible with another. And two libcs in the same program (one from the dylib, one from the binary) is a recipe for a very bad time - imagine freeing a pointer allocated with a different malloc implementation, or a different layout of libc structs

2. the complexity with glibc is it invokes dlopen as part of NSS, a feature that gets used as part of looking up users, among other things (it does this to allow integration with LDAP etc). You can actually see warnings at link time if you statically link glibc but pull in symbols that use NSS. You can disable NSS if you like at build time of glibc itself [0] (i.e. not your binary)

3. musl doesn't have the complexities of NSS and can be statically linked happily by default (I suspect that's probably what musl is most used for)

[0] https://sourceware.org/glibc/wiki/FAQ#Even_statically_linked...

I've created ~five new projects over the past year using SQLite and I've got into the habit of creating tables like this:

  CREATE TABLE tIssue (
    id   INTEGER PRIMARY KEY NOT NULL CHECK (typeof(id) = 'integer'),
    col1 BLOB NOT NULL                CHECK (typeof(col1) = 'blob'),
    col2 TEXT                         CHECK (typeof(col2) = 'text' OR col2 IS NULL)
  );

This has saved me from a lot of errors and has been useful, but it's just so easy to let things drift, e.g. removing `NOT NULL` constraint and forgetting to also update the check constraints. I'm also horrified at the auto-conversions that I've just learned about from this link that I'm not protected from.

I'm very much looking forward to using strict tables.

I've never used or looked at Typesense (I've been perfectly happy as a Meilisearch user), but your characterisation of interacting with Meilisearch is so alien it makes me wonder if we've been looking at the same project.

Across the assortment of Meilisearch repositories, I've raised two PRs (one accepted, one rejected), five issues, one feature request and pinged one issue for an update.

Every single time the Meilisearch team has been responsive, communicative and generally a delight to interact with - there are very few projects I would consider better.

Just thought I'd throw in my experience.

Context: O3DE is an open source (Apache 2) AAA game engine based on an updated Amazon Lumberyard

I've had the opportunity to work with O3DE over the past few months at work and I'm very excited to see where it goes.

There are two pieces of context if you don't work in the games industry (when I came in from an 'open source' background these surprised me):

1. the best game engine tech in the industry is proprietary (the biggest players are Unreal and Unity, lots of studios have purpose-built ones), there's relatively little open source [0]

2. in a games studio, the workflow of your company orients around the workflows of the game engine [1]

These two things combine in quite unfortunate ways, to the point where EA mandated the use of its own in-house engine...with mixed results so far [2][3]. Smaller players have three options: a) suck it up, b) use an open source alternative (i.e. Godot), c) get caught in the tarpit of "build your own engine"

O3DE has an opportunity to shake things up - particularly because of how modular it aims to be. At Hadean, our interest is in the networking layer (to drop in as netcode for Aether, our distributed simulation engine) as well as the 'core' simulation layer (to integrate with Aether in order to scale O3DE games/simulations across multiple machines). While doing all this, we will probably 'get involved' and contribute, so that our usage doesn't drift too far from mainline.

Anyway, this is all very early days - it's just a developer preview, and the flows are a bit rough. It'll be a while before we see if this changes things (I'm hopeful!), but major credit to the people at Amazon who have made it happen so far!

p.s. a checkout with deps, plus fresh compile of O3DE, plus a new project that you've opened once (to process assets) will set you back 100-150GB at my last check - not unexpected if you're used to compiling Unreal!

[0] https://twitter.com/ID_AA_Carmack/status/1406427706980454406

[1] https://isetta.io/interviews/AmandineCoget-interview/#the-mo...

[2] https://twitter.com/kingcurrythundr/status/10837887204599726...

[3] https://screenrant.com/anthem-frostbite-engine-development/

I first came across this a while ago and after digging I found the way it worked (and possibly still works) behind the scenes is pretty cool: https://groups.google.com/g/emscripten-discuss/c/4Qw8OOgTvu0...

> A while ago I was pondering getting emscripten working under Wine, but realised that it's not quite as simple as a typical program (because Wine relies on being able to just provide a compatibility layer for syscalls, so the compatibility layer for x86 would have to be provided by the port to emscripten).

> Seeing this post, I wondered if you'd found some cunning way around this so downloaded the project. No, you've just gone straight ahead and implemented an x86 emulator! Ok, but how is wine able to run on bare metal? Oh right, you've actually implemented parts of linux, including most of the syscall interface, your own executable loader, parts of procfs and assorted special devices! Alright, but (as Alon asks) how does this actually render things? Ah I see, you've implemented your own display driver in Wine which, when methods are invoked, dispatches interrupts to the emulated CPU which then forwards and translates the interrupt to an equivalent sdl call (with opengl working a similar way, but with a dll)!

> Wow!

Yep, CCU = concurrent users.

We look at CCU alongside number of entities in the sim, since they're both axes of interest for customers - 2m+ entity scale is tricky, netcode at 10k+ player scale is tricky, we target both.

That said, I've found it interesting that people _generally_ want one or the other. Game companies like the idea of loads of entities/logic ('high fidelity'), but that ramps up cost per user - ultimately they just want more people in-game for cheaper. Whereas companies willing to put the money behind resources for high fidelity simulations, generally 'only' want a few hundred concurrent users.

Thanks for the thoughts on the scenario!

Disclaimer: I work at Hadean, thought I'd clarify a couple of things

Yes, the Hadean Platform is a general distributed compute platform. But 'EVE: Aether Wars' used Aether Engine, our spatial simulation engine built on top of the platform (and works similarly to how you describe Spatial OS). Some updated numbers: more recently we've hit 2 million entities with a few hundred CCU.

In terms of cross-cell ('cell' being our region) interactions, entities moving between cells has been a single tick (at 15-30Hz depending on sim) in all simulations we've built so far - 'EVE: Aether Wars' did torpedo and player transitions, as well as torpedo target tracking across cells and torpedo-ship collisions. We also have a demo of cross-cell PhysX - this has some pretty strict requirements on inter-cell interaction latency.

Out of curiosity, what would you see as a litmus test for 'simulation with lots of cross-region interactivity'?

I worked on adding distributed compilation to sccache [0]. Docs at [1] and [2]. Compared to existing tools, sccache supports:

- local caching (like ccache)

- remote caching e.g. to S3, or a LAN redis instance (unique afaik)

- distributed compilation of C/C++ code (like distcc, icecream)

- distributed compilation of Rust (unique afaik)

- distributed compilation on Windows by cross compiling on Linux machines (unique afaik)

Note that I think bazel also does a bunch of these, but you need to use bazel as your build system.

[0] https://github.com/mozilla/sccache

[1] quickstart - https://github.com/mozilla/sccache/blob/master/docs/Distribu...

[2] reference docs - https://github.com/mozilla/sccache/blob/master/docs/Distribu...

I highly recommend the 'interviews' part of this site [0]. Reading the honest opinions of professionals in this field helped me a huge amount when I was first digging into the internals of game engines and guided my thinking to understand some of the driving priorities.

For example - the role an engine plays in a content pipeline [1] and therefore the whole operation of a AAA studio may be something non-obvious to someone who hasn't working in the industry. These interviews give you enough to realise you may be missing something and point you in the right direction to read more.

[0] https://isetta.io/interviews/

[1] https://isetta.io/interviews/AmandineCoget-interview/#the-mo...

I lightly used Godot before and using GDScript was a bad experience. It has some confusing semantics relating to reference counting and in-place modification (e.g. [0]) that make it really hard to use as a 'real' language (as opposed to small bits of code for scripting).

The mitigating factor is that it's got good bindings support and a codebase that's very tractable to poke around in, so you can easily extend it in other languages.

[0] https://github.com/godotengine/godot/issues/15265

Primarily because, until you mentioned it now, I wasn't even aware it was an option!

That said, I generally shy away from shallow clones and probably wouldn't use it here:

- it's a trap for people who ever want to work in that repo normally (we use the trick for more than just LLVM) - I believe shallow clones, over time (e.g. for contributors), are less nefficient than deep clones - I would expect shallow cloning to reuse fewer objects and benefit less from git's design. [0] describes a historic issue on this topic

[0] https://github.com/CocoaPods/CocoaPods/issues/4989#issuecomm...

I sympathise a lot with this post! Git cloning can be shockingly slow.

As a personal anecdote, clones of the Rust repository in CI used to be pretty slow, and on investigating we found out that one key problem was cloning the LLVM submodule (which Rust has a fork of).

In the end we put in place a hack to download the tar.gz of our LLVM repo from github and just copy it in place of the submodule, rather than cloning it. [0]

Also, as a counterpoint to some other comments in this thread - it's really easy to just shrug off CI getting slower. A few minutes here and there adds up. It was only because our CI would hard-fail after 3 hours that the infra team really started digging in (on this and other things) - had we left it, I suspect we might be at around 5 hours by now! Contributors want to do their work, not investigate "what does a git clone really do".

p.s. our first take on this was to have the submodules cloned and stored in the CI cache, then use the rather neat `--reference` flag [1] to grab objects from this local cache when initialising the submodule - incrementally updating the CI cache was way cheaper than recloning each time. Sadly the CI provider wasn't great at handling multi-GB caches, so we went with the approach outlined above.

[0] https://github.com/rust-lang/rust/blob/1.47.0/src/ci/init_re...

[1] https://github.com/rust-lang/rust/commit/0347ff58230af512c95...

I can't comment on performance, but on a different note it seems to be generally accepted that 'real' container boot time is slow - fly.io mention this too [0]. To add some numbers:

- 40ms for nsjail run an isolated command and exit [1]

- 150[2]-250ms to boot a firecracker microvm

- ~450ms for docker startup [3]

There are probably very good reasons for the difference (e.g. docker has layered filesystems to set up), but the default experience makes a difference.

[0] https://news.ycombinator.com/item?id=24853660

[1] `nsjail --user 9999 --group 9999 -macvlan_iface wlp2s0 --chroot / -Mo --macvlan_vs_ip 192.168.0.44 --macvlan_vs_nm 255.255.255.0 --macvlan_vs_gw 192.168.0.1 -- /bin/true`

[2] https://blog.acolyer.org/2020/03/02/firecracker/

[3] `docker run -d ubuntu:18.04 true`

Similiar to GP, I too have been wondering about a Rc'd Rust.

Unfortunately Rune and Dyon[0] are dynamically typed, which isn't so attractive to me.

More promising are Gluon and Mun, both of which are statically typed. Of these two, Gluon has a somewhat alien syntax if you're coming from Rust (it notes it's inspired by Lua, OCaml and Haskell) so Mun is probably a better choice...but it seems very early, and the website notes as much (to serve the needs of a Rust-scripting-language I'd want seamless interop between it and Rust, which isn't quite there).

So I don't think there's anything in this space right now, but there are some promising options.

If you're wiling to go a little further afield, I'm kind interested in assemblyscript[3] - it's 'just' another WASM-based language so it's not a huge leap of imagination to believe there could be tooling to enable the seamless Rust interop. Just a matter of effort!

[0] https://github.com/PistonDevelopers/dyon [1] https://github.com/gluon-lang/gluon [2] https://github.com/mun-lang/mun [3] https://www.assemblyscript.org/

Really happy to hear it's all going well, and I've been excited about V2 since I read the blog post about it - your product is awesome and solves a genuine need, and I really want you to succeed.

I'm kinda sad for you - I've been using and advocating zerotier for a while (it's amazing and indispensable)...but in my circles the word 'wireguard' has got people excited, which (anecdotally) is benefitting tailscale and generating more hype around them than zerotier ever got. Hopefully a rising tide will lift all ships and you find a way to capitalise on it :)

(I prefer device-based zerotier-style access rather than login-based tailscale-style so that does sway me to zerotier...but I have to admit tailscale looks more polished, e.g. the screenshot of seeing other devices on the network. I get it's not a fundamental feature! But I can't help but appreciate it)

This is great! I've been wanting to do something similar for a while, to call people out for making unfounded assertions - with the goal of trying to encourage more humility in making predictions.

Will follow with interest.

> To get things working comfortably I ended up porting the game loops to use Clang's support for the C++ coroutines TS, with a simple scheduler that yields control back to the browser after every screen flip.

Oh nice, is this code (or a write-up) available anywhere?

A couple of years ago I was working on porting Wesnoth and got it working...except it was too slow with the Emterpreter.

I'll try this new asyncify, but your approach sounds like an interesting backup if I were to resurrect my efforts.

comcast (https://github.com/tylertreat/comcast) is really helpful for simulating poor network connections. Particularly nice when used in Docker to do network simulations.

Hadean | Engineers | London | Full-time | ONSITE | https://www.hadean.com/

Hadean is a small (<10 engineers, for now!) startup looking for people who want to have an impact in the distributed computing space.

We're building an OS (yes, an actual OS) for distributed computing, and are looking for systems engineers looking for new challenges in a world that's becoming distributed by default. You'll probably be using Rust, C and assembly.

We're also building applications on top of this OS, with a current focus on gaming, and are looking for engineers with an interest in pushing the boundaries of MMO games and an appetite for tackling the hard technical problems involved. You'll probably be using C++.

Please apply for one of the roles on http://careers.hadean.com/ if something has caught your interest. We know hiring processes are often painful, so we try to be respectful of your interest by getting the basics right - keeping the ball rolling and giving you prompt updates on your application status. If you'd like to talk with an actual person to find out more, you can e-mail me at aidanhs@hadean.com - even if you don't find an exact match with our open positions, if you're excited about our vision and feel like you have something to add, please contact us!

Can you clarify what youre referring to with "decided to implement it in the compiler instead", be it from this blog post or elsewhere?

Clearly you need coroutines in the compiler, and the way Rust treats ownership means pinning is needed in some way (I've not been following closely so don't know if this is in libstd or a language-level feature), but the rest (according to this post) seems to be going in libstd so you can write your own if you want.

This seems like a good place to say I really enjoyed watching the video of your talk from Deconstruct Conf 2017 (https://www.deconstructconf.com/2017/kevin-lynagh-choosing-f..., referenced in your medium post) about your design process in removing CSS - gave me some nice insight into the thought that should go into the complexities you expose to users.

Definitely worth a watch for people interested in designing software for use by other people.

Author here: doing this in any language is probably going to depend on some implementation details of the language repl, which may require dropping down to a level where you have access to these internals - for example, I can't think of a way you could achieve it in strict mode JS.

Python may well be able to do it with just the stdlib since it has excellent debugging capabilities, but Tcl is relatively weak. You might be able to do something with `tcl::unsupported::getbytecode` and checking the frame level, but this was just a throw-away novelty so I'm not particularly motivated to find out.

One thing that may be non-obvious to people unfamiliar with Tcl is that it's syntactically a shell-like language, i.e. functions are invoked with a space-separated list of arguments and no parens. So `schro` on a line by itself executes the function and `[schro]` is equivalent to `$(schro)` in shell.

Fwiw, native-tls [0] is intended to solve this problem for the set of uses involving TLS (e.g. hyper [1], reqwest) by using the defacto standard on the platform you're on. This means no openssl is necessary on Windows.

Longer term, I would like to see some way for a crate consumer to optionally replace openssl with ring [2] where possible. But that's a harder problem, figuring out a common interface, specifying two crates satisfy that interface and are swappable by cargo...classic package management problems really.

[0] https://github.com/sfackler/rust-native-tls

[1] https://docs.rs/hyper-native-tls/0.2.2/hyper_native_tls/

[2] https://github.com/briansmith/ring

> £43k - and that's about right for a mid-level dev in London - and 45% on anything over £150k which is mid-size CTO territory

Clearly this depends significantly on role, but looking at your link indicates that £43k is a bit below-par (as I'd expect) for any of the more in-demand areas.

For example, if you can interview well (regardless of skill) then you can probably get a mid-level DevOps job for ~£60k if you shop around a little (or just put 'DevOps' on your linkedin profile and wait - I have multiple messages from recruiters suggesting £55k+ despite DevOps not really being what I do any more, and I suspect these aren't the top payers).

Yes. When I was younger, before I was capable of any programming (but still somewhat technically competent), I used to visit the freerainbowtables.com forums. There was a poster there (sc00bz) who posted highly technical/mathematical posts which were completely incomprehensible to me at the time [0], but made me highly motivated to always want to learn more so someday I could communicate on that level.

As it happens, I 'rediscovered' him on twitter via another hackernews post [1] a while ago, so dropped him a message to say thanks for being an unwitting inspiration :)

[0] This is a relatively simple example, it's hard to find better ones now the site is down - http://web.archive.org/web/20111111050908/https://www.freera...

[1] https://news.ycombinator.com/item?id=11691798

My 'favourite' bit of surprising (not undefined) behaviour I've seen recently in the C11 spec is around infinite loops, where

void foo() { while (1) {} }

will loop forever, but

void foo(int i) { while (i) {} }

is permitted to terminate...even if i is 1:

> An iteration statement whose controlling expression is not a constant expression, that performs no input/output operations, does not access volatile objects, and performs no synchronization or atomic operations in its body, controlling expression, or (in the case of a for statement) its expression-3, may be assumed by the implementation to terminate

To make things a bit worse, llvm can incorrectly both of the above terminate - https://bugs.llvm.org//show_bug.cgi?id=965.

"CVE-2016-5292: URL parsing causes crash" made me curious, given the talk I've heard about rust-url being integrated into Firefox.

For anyone else interested, it appears that the patch is still being reviewed - https://bugzilla.mozilla.org/show_bug.cgi?id=1151899 (though I don't know if rust-url would have actually prevented the issue).