HN user

almindor

39 karma
Posts2
Comments18
View on HN
AiGPL 4 months ago

Introducing the AiGPL, the AGPLs more up to date cousin. Protect your free software by refusing it to be used for any Ai/LLM related purposes whatsoever with the AiGPL.

And while this is done partially in jest, it's a jest similar to https://malus.sh/ which started it.

I am so glad someone said this. This also shows nicely how async is wrong, not just that it's viral, but it's bad design because it forces code duplication.

Middleware/library writers that touch on anything that could be async (db, SPI, network etc.) will now have to write two versions of their API and duplicate most code.

It'll show tomorrow :)

I wanted to avoid people just taking this out of the javascript source so it's using some hash tricks to prevent that. Maybe I over engineered that a bit though.

How Bees Argue 7 years ago

This happens regularly, the bee cluster doesn't wait for late comers. There are some scouts that keep going there and back but there are also scouts that do that with the "Correct" destination, so they "lead" the stray ones to their new home eventually. In the end most bees end up where they're supposed to.

It's much worse when a beekeeper takes the swarm tho. Speaking from experience, you can see "lost" scouts going to and from the temporary cluster from their destinations for days after you moved the cluster into a new hive. The reason is because there's noone going from cluster to new hive since no scout found that destination. It's a bit heartbreaking.

I collected the "leftover" mini-clusters 4 times in a row coz I felt responsible...

I'm not disputing that. In theory Rust should outperform even today but of course reality is a different beast and implementation details are important.

Then you also get into architecture specifics etc.

dodobirdlord described the two major advantages Rust has on the language level very well so I won't repeat them, but the gist I'm making is that Rust simply allows more optimizations purely on the language level. Specifics of backend implementations are of course another topic completely (and is one of the reasons why I'm excited for the possibility of a GNU Rustc)

Rust will outperform C consistently soon. It already does in some cases. It will also do so with safe idiomatic code in most cases. The reason behind my statement is simply more opportunity for the optimizer. Rusts rules allow for a more aggressive optimization. The reasons why it's not outperforming C yet are LLVM bugs and some missing Rust language features and fixes. LLVM in particular is driven by C needs so they rarely fix bugs present only Rustc generated IR.

This is untrue. Hifive1 supports the privileged instructuons and comes with machine mode and user mode. Cost is ~50$

State of Postgres 7 years ago

The mongodb migration story is so prevalent it could make a great meme. The website is terribad tho, please don't use the scroll-a-page approach.

I've built the Texel ASCII Art Editor (https://crates.io/crates/texel) using Specs (https://crates.io/crates/specs) as my first experience with ECS.

The original goal was an ASCII game but since I needed to create the resources for it it morphed into Texel. I think the use of ECS here wasn't a bad decision but Specs proved to be just too cumbersome and overoptimizing.

As others have mentioned ECS is a bit "loosly defined" and each implementation seems to go over the line to add more specializing one way or the other. I want to switch to something more simple and elegant like DCES (https://crates.io/crates/dces) for my next refactor.

I think for "runtime resource management" ECS is fine if you need a fairly large, distinct pool of entities to handle. One of my main usage problems was the re-use of same components in the same entity.

E.g. imagine having an entity with a global world position, but also an internal position for something like "last cursor position". It's not possible to just "add another Position component" to the same entity, for good internal reasons, but still. It's pretty important people take these kind of limitations into account before planning out their entity/component maps.

No, I asked on the IRC channel and forums as well as a friend who does embedded. The answer was basically "because clippy doesn't know the target arch it has to be a conservative-guess" which I agree with.

My friend also explained how it's a REALLY tricky question to answer properly especially given specific embedded architectures and setups where the answer is very hard.

I've had a smaller but similar dive recently while working on embedded machine (32 bit) with Rust. Clippy was pushing me to use move/copy instead of reference for passing a [u8; 8].

I thought this strange on a 32bit machine so I dived in and it turned out the "rule" is supposed to be "up to 2 register sized" variables are supposed to be copied, anything bigger is supposed to be referenced.

The trick here is that due to compatibility and no knowlege of target platform and setup clippy assumes 32bit register size. So on 64 bit platforms you'll only get this warning up to 8 bytes as well for example.

I never went in to actually see if it makes any sense on that particular 32bit platform, so good to see someone taking a dive on the actual compiled code side.