I wish I had more free time, a gearbox or a 4-way differential can probably be used on the extruder head to control the mixing ratios.

Regarding the necessary research, I can picture it being cracked either by hobbyists, or industrial-scale (patent-heavy) players. I imagine that consumer-facing players such as Prusa do not have the means to heavily invest in R&D.

* the simplest is just mixing filaments, like one mixes paint. The article doesn't spell out the reason it doesn't work, I am curious as to why.

* together with alternating layers, colors could be alternated in the same layer. Some purging may be necessary, but I think you could either: accept some mixing (compute its impact to compensate) / take into account the volume in the nozzle (extrusion "latency") / discard the unwanted part in the infill (at the cost of less smooth edges)

Of course, the hard work with any approach, including their current work, is calibration, as the article highlights. I wonder if off-the-shelf monitor calibration sensors could help with measuring the filament you have at hand.

It didn't use to be complicated, but an update messed stuff up a few months ago (halo infinite).

A few thoughts:

1. Linux VTs kind of have this feature already: there is the normal buffer, the alternate buffer (that something like htop would draw on), and an IOctl can change them to/from graphics mode.

2. It makes sense for interactivity. Kitty's graphics protocol is quite useful for static shapes, can be abused for animations, but doesn't really cut it for interactivity (say, pan a graph around). Wayland is designed for this.

3. Wayland would be a good fit: isolate each command from another, let them request buffers, but keep control of where to display them, do not update them when off screen, etc.

4. One downside is that terminals excel for one-shot tasks. What's the purpose of the display when you are done with it? Should you kill the process driving it? Due to this, it may make more sense to delegate more features to the terminal emulator (displaying the 3D model, etc). Or maybe just allow the app to temporarily take over the window.

5. Once you have it up and running, have it talk directly to the direct rendering manager. Your "kmscon" is now your compositor / desktop environment. That's a fun thought! Add some basic terminal features like tabs and tiling, and you've inverted the usual setup.

6. One downside is accessibility. I really like that I can copy-paste any part of the interface for reference, "screenshots", etc. It's good for screen readers, too. You lose these advantages by going to Wayland.

7. Another current terminal limitation is fonts. Power line, yazi & other make use of custom fonts for drawing part of the interface, logos, etc. AFAIK there is no good way to query their availability (which is also an issue for color emoji). Custom fonts or a new protocol could be useful, but client apps could draw it themselves if given a surface (that can already do that with the kitty graphics protocol, mind you)

Obviously I am not seriously considering to make such a terminal emulator, but it would be an interesting experiment (heck, maybe something I should try this "vibe coding" with, since I wouldn't want to spend too much time on it).

Here are a few ideas:

1. Geoblocking. Not ideal, but it can make your resolver public for fewer people.

2. What if your DNS only answers queries for a single domain? Depending on the system, the fallback DNS server may handle other requests?

3. You could always hand out a device that connects to the WLAN. Think a cheap esp32. Only needs to be powered on when doing the resolution. Then you have a bit more freedom: ipv6 RADV + VPN, or try hijacking DNS queries (will not work with client isolation), or set it as resolver (may need manual config on each LAN, impractical).

4. IP whitelist, but ask them to visit a HTTP server from their LAN if it does not work (the switch has a browser, I think), this will give you the IP to allow, you can even password-protect it.

I'd say 2. Is worth a try. 4. Is easy enough to implement, but not entirely frictionless.

You could also say it's up to the user to implement a fully-fledged timer/counter in a BIO coprocessor if they need one, though ideally there would be a shared register (or a way to configure the FIFOs depth + make them non-blocking) to communicate the result.

Small cores like these are really fun to play with: the constraints easily fit in your head, and finding some clever way to use the existing HW is very rewarding. Who needs Zachtronics games when you have a BIO or PIO?

I ordered a few, thinking it would make a good logic analyzer (before the details of the BIO were published). Obviously, it's going to be a stretch with multiple cycles per instructions, and a reduced instruction set. I'll see how far I can push it if I rely on multiple BIOs, perhaps with some tricks such as relying on an external clock signal. At first glance, they seemed to be perfect for doing some basic RLE or Huffman compression on-the-fly, but I am less sure now, I will have to play with it. Bit-packing may be somewhat expensive to perform, too.

One thing stood out to me in this design: that liberal use of the 16 extra registers. It's a very clever trick, but wouldn't some of these be better exposed as memory addresses? Or do you foresee applications where they are in the hot path (where the inability to write immediate values may matter). Stuff like core ID, debug, or even GPIO direction could be hard-wired to memory addresses, leaving space for some extra features (not sure which? General purpose registers? More queues? More GPIOs? A special purpose HW block?).

I really like the "snap to quantum" mechanism: as you wrote, it is good for portability, though there should be a way to query frequency, if portability is really a goal.

Anyway, it's plenty for a v1, plenty of exciting things to play with, including the MMU of the main core!

I put new in quotes because I use another little-known feature, "ControlMaster". Multiplexes multiple connections into one, it makes making " new" sessions instant (can also be configured to persist a bit after disconnecting). Also useful for tab-completing remote paths. It does not prompt for authentication again, though. And it's a bit annoying when the connection hands (can be solved with ssh -o close, IIRC).

I personally feel like I will downscale my homelab hardware to reduce its power draw. My HW is rather old (and leagues below yours), more recent HW tends to be more efficient, but I have no idea how well these high end server boards can lower their idle power consumption?

With zha, you can bind them together from the Home Assistant device page.

I usually favor an architecture that can work without Home Assistant, such as standalone ZigBee dimmers, or contactors that can work with existing wiring. Home Assistant brings automation on top, but it doesn't matter much if it breaks (I mostly notice the shutters not opening with sunrise). Then Internet connectivity can bring additional features, but most things still work if it's down.

I'd say it has been pretty solid for years, and I don't stress too much when I have server issues.

In practice, this can be done with phase change materials (heat/cool materials to change their index), or micro ring resonators (to divert light from one wave guide to another).

The beam then self-interferes, and the resulting interference pattern (constructive/destructive depending on the direction) are used to modulate the beam orientation.

You are right that a single source is needed, though I imagine that you can also use a laser source and shine it at another "pumped" material to have it emit more coherent light.

I've been thinking about possible use-cases for this technology besides LIDAR,. Point to point laser communication could be an interesting application: satellite-to-satellite communication, or drone-to-drone in high-EMI settings (battlefield with jammers). This would make mounting laser designators on small drones a lot easier. Here you go, free startup ideas ;)

You have probably addressed that somewhere, but would it be possible to run your UI stack somewhere else? (PostmarketOS).

My other wish for AsteroidOS would be for it to leverage Wi-Fi better. Not sure how much more energy it would use, but having a longer range for my notifications would be nice (at least on LAN). Being able to perform a few other actions independently of my phone would be great: weather % time updates, e-mail notifications, home assistant control, etc. I get that it may affect battery life as well.

While I'm at it: tiny bug report, but I adjusted the time while the stopwatch was running, and this affected the stopwatch result.

This is outdated. Look at page 4 of this report for instance: https://www.kielinstitut.de/publications/europe-steps-up-ukr...

Their data is not perfect as they rely on public sources, and some governments are more transparent than others, but the reality is that US funding all but vanished in 2025.

Back to the topic, there is also a pattern of promising European startups being bought by wealthy USA incumbent companies. This is also happening to established compagnies: see ARM, Alstom Power, etc. As Europe de-couples from the USA in the current context, I suspect (and hope) that such acquisitions will come under more regulatory scrutiny.

1. It lays down the policy explicitly, making it seem fair, not arbitrary and capricious, both to human observers (including the mastermind) and the agent.

2. It can be linked to / quoted as a reference in this project or from other projects.

3. It is inevitably going to get absorbed in the training dataset of future models.

You can argue it's feeding the troll, though.

IPv6 firewall disabled by default. There is only one config for the firewall: on / off. Accept all inbound or reject all inbounding.

To think that they used to brand themselves as "for the geeks", with reverse DNS customization, built-in user-configurable server on the router (all of their routers offer a Wireguard VPN, torrent client, audio output with DLNA & others), a m3u for IPTV, etc. I wouldn't advise anyone to use them due to this issue.

This ticket said they would reopen an internal ticket, back in 2022: https://dev.freebox.fr/bugs/task/27613

Their basic firewall dates back to 2019: https://dev.freebox.fr/bugs/task/27268 (a lot of spam in the replies there). There was none before, and it is still off by default.

This is no small ISP either, they have more than 50 millions clients (including mobile), and are in the top 10 ISPs in Europe. Baffling.