I haven’t written about 3D printing in a while, but I have both kept at it and actually doing a bit of market research–I’ve been considering either building an MMU or getting a multi-material printer, but I haven’t made up my mind yet, and the tariff war isn’t helping.

But one of my checklist features for any upgrade was is having integrated drying capabilities, so when EIBOS reached out to me about their Polyphemus filament dryer, I was intrigued.

Disclaimer: EIBOS sent me a Polyphemus and 3Kg expansion kit free of charge, and as usual this article follows my review policy.

Even though all my filament storage boxes have big, hulking car-grade dehumidifier bags, I have felt the need to resort to a dirt cheap filament dryer for PETG and other hygroscopic filaments, since it makes a significant difference in print quality. But the one I had was a simple, bit noisy box with a heater and a timer, and while it works well enough to keep around as a backup, it was a bit of a hassle to use.

I was curious to see how the Polyphemus would fare, but also how much of a difference it would make in terms of the overall experience. Print quality will always be a function of the filament and the printer, but the drying process itself can be a bit of a hassle.

The Polyphemus came in a kit–actually two kits, since I also got the skirt/extension to add enough height for 3Kg spools, which was welcome.

Assembly was pretty straightforward since (other than the extension) it was all done with the exact same kind of screws (always a good thing in kits) and the instructions were abundantly clear, so it took around 30 minutes, and even then mostly because I needed to clear some desk space.

That consisted mostly of laying down a part of the frame, slotting in corner rods (which look like aluminum extrusions but are actually some form of polycarbonate), sliding the acrylic panels in between, and fastening it all together.

I didn’t take any pictures of the assembly process, but here are some of the parts and a couple of pages from the manual, which I found to be very clear and easy to follow:

My first impressions of the Polyphemus just after assembly were very positive:

• Even if it is a kit, the build quality is great. The frame is made of what I assume to be polycarbonate “extrusions” that feel solid, and the combination of those and the acrylic panels make it feel solid and well-made.
• You get spare parts for the motor and some fixtures, which is a super nice touch.
• It has a built-in power supply, which allowed me to get rid of a power brick and rationalize cabling a bit.
• The cover is huge, but easy to handle and the lack of a hinge means you can take it off and put it back on easily, although running the filament through the top outlets will always be a two-step operation. But it provides a clear, unobstructed view of the filament rolls from every angle, so any tangles or spooling irregularities are plain to see (this is a marked improvement over my previous dryer, which is only partially transparent and has a fiddly cover).

As I started using it, I was pleasantly surprised by a few nice touches:

• It has five outlets for filament–two at the rear next to the dessicant compartments, and three through the top cover (the middle one is for 3Kg spools). I ended up using one of the top outlets for my enclosed printer (as seen above), but I might move it above my printers later on, and having the option to route filament through top or back is quite welcome
• It has dual dedicated dessicant compartments, which are easy to access and refill. For now I just tossed in a couple of bags of silica gel, but I will have a go at dropping in granules later on since the grills are fine enough to keep them in place. I don’t see a need to have two kinds of dessicant in there, but I suppose it’s another option.
• It is designed to rotate filament rolls automatically as they dry (with a few different speeds), which makes for more uniform drying and is done quietly and slowly enough that it doesn’t cause any tangles.

As to the drying process itself, the display and controls are easy to read and use, with a simple interface I found intuitive and that has presets for most common filaments (PLA, PETG, ABS, TPU, ASA, etc.), including a memory function for custom settings and power loss recovery (which feels like a luxury, but is actually a nice touch I was surprised to come across in the manual).

It is rated to go up to 70^oC (which is more than enough for most filaments), and the drying time is adjustable from 30 to 24 hours (with a “permanent” mode that keeps the dryer on indefinitely, but which I haven’t tried). I haven’t tried the permanent mode, but I used the target humidity mode for a couple of rolls of PETG and it worked great–and, importantly, it was very quiet.

I have been using it for almost three weeks now and have had no complaints–I tried mostly PETG because that is what I have the most trouble printing, but both PETG and PLA prints have come out great–I drop in the filament a few hours before, tap out the drying settings, and eventually start printing (typically in late afternoon). I haven’t had any issues with stringing or other artifacts that are common with wet filament, and the prints have been consistent, although I still need to tune the filament settings a bit more to take full advantage of the dryer.

The Polyphemus is a great filament dryer that feels like a luxury item if (like me) you’ve never had something that went beyond heating things based on a timer. The build quality feels solid, the design is well thought out, and the drying itself is effective, although I am not really in a position to do a hyper-scientific comparison with my previous dryer.

But I now have empirical evidence that rotating the filament as it dries makes a substantial difference (at least for the PETG I have been using), and the fact that it has a built-in power supply and a couple of extra features (like the memory function) fit quite well into my setup and workflow, so I am happy to have it around.

As an inveterate tinkerer, I have spent a lot of time messing with LLMs in my side projects, and… it hasn’t sparked a lot of joy.

My news summarizer is still going strong (as are a few other toys I have to interpret snippets of environmental data), but nothing I’ve done recently has been particularly exciting.

There’s too much churn–models, frameworks, and tools are constantly changing, and trying stuff out is a pain, especially considering that we have been in a diminishing returns phase for a while now–latest models are not significantly better than previous ones, prompting is still brittle, and things like MCP certainly don’t help.

The only upside I’ve been able to find is that coding tools are getting better to a point where they feel more useful–but I think that is largely due to better integration, since right now neither Claude 3.7 nor o3 are at a point where I would trust them to write code for me (they can barely write useful tests).

It’s true that as an accelerator for dealing with boilerplate (comments, docstrings, etc.) and “rubber ducking” my way through front-end code AI has become quite useful, but I’ve found it risks becoming a distraction and a colossal time sink when it gets things wrong–which is still always a matter of “when”, not “if”.

But multiply that by the time spent trying out new models and new tools, and you get an almost quadratic increase in the amount of time you spend on something that is supposed to be a productivity booster.

Which is why I am constantly flabbergasted by the fact that actual decision makers persist in the belief that AI is going to magically improve productivity without thinking about quality and correctness–without proper domain expertise and critical thinking that is simply not going to happen, and it’s a shame that so many people are wasting their time (and their shareholders’ money) peddling that notion.

In the meantime, I’ve decided to dial back on random experimentation and see if I can get back to other things, although the current geopolitical situation has made that a bit difficult…

It’s been a little while since I last looked at regular mini-PCs, and considering that the market is flooded with cheap Intel N100 and N150 variants, you would think there isn’t a lot of diversity in the EUR 200 range.

Well, it turns out there are some interesting alternatives out there, and I’ve been running one for almost two months now–the Chuwi Larkbox S:

One of the reasons I decided to look at the Larkbox S was that it uses a Core i3-1220P CPU, which I had no experience with but which I knew that (like the Core i5-1235U I have on my TerraMaster F4-424 MAX) features a total of 10 cores–2 performance cores and 8 efficiency cores, which is a lot more interesting for a homelab setup than the N100/150-series’ 4 cores.

Disclaimer: Chuwi sent me a Larkbox S unit free of charge, and as usual this article follows my review policy.

The Larkbox S follows the usual semi-cubical look of most mini-PCs, but looks more polished than usual. Part of that is due to the polycarbonate top case, which feels very solid and cool to the touch and is subtly etched with a discreet geometric pattern.

Another distinctive design feature is an RGB LED ring around the front ports that, as usual, you can disable in the BIOS. This time, however, I actually left it on since unlike most similar decorations it wasn’t crazy distracting and was actually helpful when plugging in peripherals in the dark.

My machine came with the following configuration:

• Intel Core i3-1220P (10 Cores, 12 Threads), with Intel UHD Graphics
• 16GB DDR4 RAM (in a single SODIMM, leaving one slot free)
• 512GB PCIe 3.0 SSD
• 4 front USB ports (2 USB-C, 2 USB-A, plus 2 other USB-A in the back)
• 2 HDMI ports
• 1 Gigabit Ethernet (plus Wi-Fi 5, Bluetooth 5.1)
• 3.5mm audio jack

Sadly it doesn’t feature an SD card reader, but you can use the front USB-C ports for video output and power delivery, which is nice.

The PSU is huge and rated for 90W, which feels overkill and had me concerned about power consumption for a while. However (as you’ll see below), my initial stress testing of the LarkBox S (by using Blender and Cycles) didn’t push wall power overly past 50W, so I guess Chuwi is simply using an existing part and leveraging economies of scale.

Using either Windows or Proxmox the machine idled at 7W, which is very close to the 5-6W I’ve seen from N100/N150 mini-PCs.

The BIOS is a standard AMI affair, and as such pretty easy to navigate:

I didn’t find any performance management options, but that might be because Windows 11 has its own power management settings (which did work fine for me) and BIOS settings are usually overridden by the OS.

The Larkbox S ships with Windows 11 Pro 23H2 (which passed my malware checks), and I had no issues upgrading it to 24H2 and exercising it thoroughly–in fact, I spent most of the time running Windows on it, since I had a small shortlist of things I wanted to try out:

• Visual Studio Code (+WSL) with the Arduino and Nordic MCU toolchains
• KiCad (which I typically run on Linux)
• Unity
• Godot
• Android Studio
• Blender
• Davinci Resolve
• Bitwig

The first few are a sample of the random development and electronics stuff I do on the side (with Android Studio being more of a stress test) and the last three are more on the creative side.

I had no trouble running Fedora or Proxmox on it, and the device tree is pretty straightforward, so there should be zero driver issues with any other Linux variant.

I decided to test the Larkbox S primarily as a Windows machine because I wanted to see how the Core i3-1220P CPU dealt with real-life usage as a development machine–and for industrial and embedded systems, that still means using Windows due to the proprietary tooling.

And I was pleasantly surprised by what its 10 cores/12 threads can do in real life (yes, you can run Geekbench if you want to, but I find that kind of benchmark rather pointless).

Right out of the box, the Larkbox S was able to run Visual Studio Code with WSL and the Arduino IDE without any issues, and I was able to compile and upload code to my Nordic nRF52840 boards without any issues. I found that the Larkbox S makes for a very snappy office and web development machine, and that it worked quite well for embedded development and electronics (KiCad worked very well).

Pushing it a bit further was interesting:

• Android Studio works, but, as usual, you won’t enjoy the experience unless you have a lot more RAM. There’s just no working around that.
• Unity Editor 6 actually ran surprisingly well, even if the iGPU and CPU were constantly pegged. But I could get 30fps out of the default 3D first person shooter demo, which I would rate as “good enough” to begin with.
• Godot (as usual) worked a lot better than unity, although the iGPU didn’t much like rendering some of the 3D demo projects. All the 2D stuff was very nice and snappy.

This may look limiting but is way beyond what I could do on an N100/N150, so I’d say the Larkbox S is actually a quite nice entry-level development machine–provided you’re not doing triple-A gaming. But low-end 3D, 2D gaming, web development and even some (patient) mobile development are well within its reach (Hades ran perfectly, but it was the only game I tried).

The challenges with 3D are partly because the i3 range does not have the new Xe integrated graphics that Intel decided to reserve for Core i5 and above. But the Larkbox S iGPU comes with 64 execution units rather than the 24 in the N100/N150, so I was intrigued at what it could do.

As it happens, they work fine with Intel QuickSync video encoding, so I was able to use Handbrake to transcode 1080p footage into H.265 at a blistering 400fps, very much like on the Core i5-1235U I have on my TerraMaster F4-424 MAX.

That included converting the original ripped DTS soundtrack into EAC-3, so the Larkbox S used 100% GPU and around 40% CPU during that 30m transcoding session–and I measured 35W power consumption with Windows set to “Balanced” power mode, which was quite good for a mini-PC under that kind of load.

In comparison, trying to render one of the Blender benchmarks and taking the CPU to 100% peaked at 54W with Windows set to “Best Performance”–which was the most I could get the machine to take from the wall.

To get a better feel for what the Larkbox S could do in this day and age of video, I took the Handbrake output, imported it into Davinci Resolve and was able to do a bit of editing and adding transitions with ease–it’s not a buttery smooth experience, but you can actually see live previews of effects and transitions, and there was practically no stuttering while skimming the timeline, so I think that for occasional video editing the Larkbox S passes muster.

The SSD, however, is relatively slow–I was only able to get a little over 6100 IOPS (read or write) from it, which is twice what you’d get from a SATA SSD but less than half what I get from a 1TB Corsair SSD–so improving the stock SSD would certainly help with video editing.

As to fan noise, the Larkbox S is pretty quiet under normal use, but the fan does ramp up quite quickly when you push it hard–enough to be a little annoying if you’re in a quiet room, but easily drowned out by music or silenced by moving it to under the desk.

I swapped the SSD for a 1TB Western Digital Blue to install Proxmox, and migrated both my default Fedora workspace and my media stack to it for a week with zero issues–everything ran as well as on my TerraMaster’s Core i5-1235U (except that I was limited to the 16GB that shipped with the machine), and the 4+8 thread mix ensured that I got good interactive performance when using KiCad on Linux.

Server-side media transcoding was, as you’d expect, seamless, and everything I tried just worked. As usual, running iperf3 under Linux allowed me to saturate the single gigabit interface at around 950Mbps, and although I would have preferred a 2.5Gbps interface I don’t think it will be a problem for most people.

I will look into getting more RAM for it over the coming weeks, and once I get it I will revisit the Larkbox S as a “permanent” homelab machine–it will be a good fit alongside my TerraMaster F4-424 MAX and allow me to consolidate the N100/N150 machines I have lying around.

However, I went back to Windows for a surprising use case: music.

While testing Bitwig I realized that the Larkbox S was able to load and play one of the most demanding projects with ease (although with a 95% CPU load), and so I decided to load my Arturia suite on it and use it as a music workstation–it can play at multiple tracks of external plugins with a few effects layered on without any issue, so I’ve been having a little fun with it that way.

This is, again, a use case where those 10 cores/12 threads make a sizable difference (and Bitwig also uses the iGPU for real time visualizations), and something I was able to do (but not as well) in the N5095 and N100 machines I used in the past.

The LarkBox S is a very competent mini-PC that, for the price I’m seeing at retail right now (around €270), feels like a better option than any of the cheaper N100/N150 machines out there for a relatively small extra.

Sure, it’s not a gaming machine, and the Core i3-1220P chip on it is in somewhat of an odd place regarding graphics performance, but it is much better than an N100/N150 and, even if it doesn’t have the Xe graphics of its revised Core i5-1235U cousin, comes close to them in performance for media work.

Like I expected, the 12 cores on it (even if only 2 are performance cores) make for a much nicer desktop and office experience than the other Intel mini-PCs I’ve tried recently, and it is that kind of CPU power that makes it very interesting as a sort of entry-level homelab machine–all those cores make it very responsive for running multiple VMs, and the iGPU is good enough for media transcoding and video work.

The only caveats for me as a small server are the single gigabit port, the single NVMe slot and its power consumption–it is, on average, slightly above the N100/N150 machines, but for light workloads that shouldn’t really be a problem, and if all you want is a Plex server with a little more muscle than usual, it can very comfortably do that and host a couple more VMs for additional services.

However, this experience has made me think that, at current price levels, the cheap mini-PCs that we are getting with N100/N150 CPUs might not be the best bang for the buck–I still haven’t explored the N300 range and how it compares in both power consumption and raw compute, but I’m pretty sure it won’t be better than the Core i3-1220P.

Of course, with the current state of the market and new US tariffs, things are going to be a little weird for a while… But only time will tell.

I have now officially reached the point where I have more KVM devices than I actually need (at least for now), and I think this one will be the last for a while–so this is my attempt to finish the series on a high note.

Read More...

I know I’m late to this party, but I’ve been reading John Gruber’s piece “Something Is Rotten in the State of Cupertino”, and finally found time to share my thoughts.

Read More...

This is going to be a slightly different review, since it is not about a finished product–I’ve been sent an early sample of ArmSom/BananaPi’s upcoming AI module 7 (which will be up on CrowdSupply soon), and thought I’d share my early impressions of it.

Read More...

Reviewing things is an interesting experience–no matter what, I learn something from dealing with the various hardware and software bits I get, and every now and then you come across something you really like despite some challenges along the way.

Read More...