VorpalWay

Reading the linked bug report about executable stacks they fixed it? So they did the right thing. I'm not saying there will never be bugs (no non-trivial software is bug free), but as long as those are handled correctly that seems reasonable to me.

Glibc is backward compatible though, they even have symbol versioning to provide multiple versions of the same symbol. So as long as you have the same or a newer version of glibc (than what was built against) you should be good to go. And I don't remember hearing about breakages for this.

Other libraries on the system is far more hit and miss, but glibc is quite compatible.

The other way around is harder though, you can't take a program built against a newer glibc and run it on an older version. So you generally need to spin up a container with some LTS distro and build your binary in it if you want it to be maximally compatible. (However, zig apparently is able to deal with this by shipping a mapping between glibc versions and symbol versions and doing the linking themselves. You can even use zig to link rust code using cargo-zigbuild and get that benefit.)

But if you want to be maximally portable: static linking against musl. Though beware that many things are slower in musl, such as the allocator.

Benchmarks show that per-paragraph recompilation achieves O(1) latency, constant regardless of document size, whereas Typst’s [3] incremental compilation scales linearly (O(n)).

The tradeoff is temporary inconsistency: pages the user is not viewing may lag until a background compile converges, [...]

There doesn't seem to be any reason functionality like this couldn't also be added to Typst though. In general the authors of this paper seem dismissive of typst, but Typst also fixes so many other things about LaTeX, like the awful syntax. Not sure why they act like that.

Oof, please report that as an issue (if it hasn't been done already). KDE uses https://bugs.kde.org

Linux usability has come a long way in recent years. I switched full time to Linux in 2006, but I can absolutely understand those who wouldn't back then.

These days? Unless there is a specific piece of software that can't run on Linux (or under Wine), and there is no suitable replacement for it? Yeah I don't know why you would voluntarily stay on Windows (note voluntarily, if IT policy says you must that doesn't count).

There is no reason we need a badly coded vendor control panel to install firmware upgrades though. On Linux https://fwupd.org/ is a database for vendor firmware, and you use one shared open source took to install upgrades for all devices attached to your system.

And then what, ever single gaming mouse/keyboard config is going to appear in the Windows UI dialog?

Actually, why not? The driver could declare a list/tree of extra configurable options, and windows could generate a configuration dialog for them. I think this is already is thing in Windows for NICs, I remember seeing TCP offload options when I go into properties for a NIC in the device manager.

You just need to make it a bit more accessible to non-tech users and with more modern control options such as colour wheels for RGB.

And the Linux software for these sort of devices (when such software exist) don't tend to be as bloated. Usually the driver just exposes some control files under /sys and someone else builds a GUI or such on top. But there is no reason you couldn't also expose a schema that describes what the options do to make a more generic GUI for those.

Dont forget they own github too. The vast majority of open source software is on there these days.

Yes there are other options: gitlab.com, some project specific gitlab instances (freedesktop for example), forejo / codeberg, and the Linux kernel is off doing it's own thing with mailing lists instead. I even come across code on SourceForge every now and then still. But all of these are super niche.

Outside of Embassy in embedded, tokio is the only realistic choice though, because it is likely that any third party async crate has a dependency on it already. Yes, smol, monio, glommio etc exist, but they are marginalised (and as far as I can tell they don't really help that much with mixed IO / compute workloads).

In fact, async/await in Rust falls apart with a mixed IO / compute workload since scheduling is cooperative. As soon as you want preemption (most of the time for what I do), it is not the right choice.

Seeing how embassy (embedded async rust) handles preemption reinforces this: it uses a separate scheduler per preemption level. This works fine, but is a bit clunky. Basically you are at this point just using async to help write a state machine per preemptive thread, which can be useful for some code patterns (in particular those common in embedded, where you are often waiting for IO). But to talk between threads you are back to channels, mutexes etc.

Apple is also a record label (that existed before the computer company), specifically one owned by the Beatles.

There were even some legal battles between them, see https://en.wikipedia.org/wiki/Apple_Corps_v_Apple_Computer

Apparently it ended with Apple Computers buying the trademark from Apple (record company) and then licencing it back (weird but ok).

Well, they could have used a less generic and misleading name (it is not very open, as noted in the article). OpenAI only really have themselves to blame here.

Much better than modern insurance!

Sort of, unless you lost it to a fire or flooding, which the thieves guild presumably wouldn't cover.

Also, is this really true or an urban myth? I'm not finding sources googling this, at most I can find mentions that there were during some norr unstable periods maffia-like structures with large unofficial power.

In Swedish "korn" is a specific species of grain (called barley in English). For grains in general we use the term "sädesslag".

Something like Anubis in front of the server to protect it might be an option. It sucks that we have to resort to that yes, but it seems the least bad option currently (better than the entire internet going through Cloudflare at least).

Even in other industries it is common that spare parts and consumables have a very high margin (while the initial purchase has a much smaller margin or in some cases is even subsidised).

The most well known example is probably printer ink/toner. (Razors is another often quoted example.) But this applies to car parts too. I needed a new small plastic clip to my Dacia. I was quoted 100 SEK (about 10 USD) for that. I 3D printed a sturdier version that will last longer for less than 5 SEK in materials (less than 0.5 USD).

From that you can estimate the approximate margins many companies have for spare parts. Of course being able to prevent cheaper third party parts will seem enticing if they want to maximise shareholder value. And this is why we need regulation.

That is interesting (and I recommend you flash stock openwrt instead, I did on mine). But no, the parent comment I replied to claimed Israeli / IDF connections.

Source? A cursory check on their website shows a Hong Kong and a US address. Some people seem to be claiming mainline China associations as well, which could be true, can't find anything on that in either direction.

But Israeli, no can't find that. Sure you didn't confuse it with some other company?

I happily own a car with nothing fancier than a bluetooth radio. No touch screens and no Android Auto is a blessing.

But from this and sibling comments it seems that CoMaps have nothing to offer me (except possibly better search).

Hm, I guess there is no law. But why would so many manufacturers include this unless there is some legal reason or other pressure on them to do so?

This is interesting, but it seems to be a crowdfunding campaign only. I wish them the best of luck (the cause is worthy for sure), but buyer beware at this point.

(I myself don't 2D print enough that an ink based printer makes sense for me. Ink tends to dry, so for me a laser printer that can sit for months at a time makes more sense. I use the scanner as well as my 3D printer far more often.)

I wonder how they will handle the nonsense around yellow tracking dots[1] etc. Hopefully that doesn't become a problem.

[1] https://en.wikipedia.org/wiki/Printer_tracking_dots

I have been a happy user of OsmAnd+ for over 15 years at this point, I can strongly recommend it if you need power user features.

(Yes the OsmAnd+ is the paid version, but it is the old pay-once version and I have definitely got my money's worth at this point, and it supports an open source project.)

I have used OsmAnd+ for well over 15 years by now, which also uses OSM data, just like these. And I have used JOSM on my PC to fix the OSM data myself.

Does Organic maps / CoMaps offer anything OsmAnd+ doesn't for someone who uses it for car navigation (especially on back roads in the wilderness) as well as hiking? (All in the Nordic countries.) I also record tracks with it.

Well sure, but that isn't what my original comment that you were replying downthread of said. I specifically recommended safety critical embedded. :)

The issue with AI isn't that it can't write embedded code (though it is noticeably worse at it), the issue is specifically with the safety certification of code the AI produced. There is a lot of paper trail to show that you followed all relevant standards, a lot of which pertains to your development process.

It is not just what you do or don't do in the code (e.g. MISRA or CERT C) but there is also a lot about how you test, review, show that your tests cover everything relevant (not just code coverage, but also specification coverage), show how you check that everyone involved followed the process, etc.

One idea to consider might be going into safety critical embedded work (e.g. brake controllers, critical systems for airplanes/trains, medical devices, some industrial systems, ...). AI hasn't penetrated much here yet. It isn't at all clear how or if you would be able to certify the process for example.

That might change with time, but for now, all I see AI used for is additional code review and side scripts/tooling that don't need to be safety rated.

Of course, that might mean entirely switching language (C, C++ or increasingly but still in minority Rust), learning entirely different skills (control system theory, real time systems, possibly formal verification but usually not), etc.

I did some ACPI reverse engineering on an old Toshiba laptop some years ago, with the goal of improving the Linux ACPI drivers. Learnt a lot from it, and wrote a blog post that you might find interesting: https://vorpal.se/posts/2022/aug/21/reverse-engineering-acpi... (100% human written, and I hate that I have to specify that these days).

Not if it causes contact allergies with your mouth, as soy milk does for me. Same with coconut milk. I have to stick to oat, almond or animal milk. (Goat milk tastes pretty good too by the way.)

And non-homogenized full fat milk is delicious.

For baking: depends on the recipe. In one recipe of a sort of muffin style bread that uses egg to rise (no baking powder, yeast, etc), oat milk makes it not rise properly and you get dense bricks instead. Other recipes have been fine. YMMV.

(Though, I quite like the non-homogenized full fat milk with bits of thick cream floating on top too. Oat milk, while pretty good, got nothing on that. Perfect on the porridge for breakfast.)

I don't care about aesthetics in factory games (which is a reason I prefer Factorio to Satisfactory, there is way less focus on building pretty factories), that probably helps. I'll happily build a massive factory with very few pillars to hold it aloft, with a bunch of train stations on the side. And to be fair, many machines in Satisfactory are also massive.

I found that the way the resources are spread out in the games and the amount needed for various recipes and the amount of scale you needed to beat the game lead to more trains in Satisfactory. In particular it made it such that spread out smaller factories near resources that then transported intermediate products to big central factories made more sense. In addition, since resource nodes are infinite you don't need to keep moving the mines all the time like in Factorio, so building additional local infrastructure is more viable than in Factorio.

Because the world is hand crafted and more rugged it also means running belts all over the map is less viable, building one long difficult rail that can be used by a bunch of separate transports makes even more sense than in Factorio.

So in summary, I think it is a bunch of small things that all nudge me more towards trains in Satisfactory than in Factorio.

I haven't played the space expansion, but from old vanilla I only used trains for bringing ores to the main base. For rare low throughout recipies the flying bots (I forget the name for them) worked well, and towards the end of the game they got pretty fast as well.

As a longtime fan of trains in games like OpenTTD, it always felt like there wasn't enough of a focus on trains. Arguably this is something that Satisfactory did slightly better, there was more reason to use them there (that game certainly has other weaknesses though, and overall I prefer Factorio).