But whenever something we publish reaches a new audience, we inevitably see naïve and often uneducated comments posted on forums and social media channels regarding our webpage design. Such is the price for being ahead of the curve, innovating, and having the guts to apply fresh new ideas to a real world website.

The thing is, there are a lot of broken browsers out there! Our CSS is expertly crafted by people who know the standards inside out, and we know that our loyal fans love it. But if somebody's system doesn't comply and renders our pages as neatly as Crystal's desk on a Monday morning, [hey, what!? - Crystal], we can see why they might mistakenly blame us. Ah, sweet summer child, you have much still to learn.

So start by reading our replies to various comments, and if you already knew all of this stuff, then have a good laugh on us this weekend.

But when we started to investigate why UTF-8 decoding didn't work properly on the OpenBSD console, the awful programming mistakes we quickly discovered surprised even us.

Programmers, let's remind ourselves of how important it is to get the basics right, with a detailed write-up of our latest debugging session.

And if you're new to this, or not even a C programmer, please still come along for the ride. These are pretty trivial errors we're discussing.

But do you know how /dev/null and it's friend /dev/zero are actually implemented? Ah, now that's interesting.

This weekend you can see how to add a shiny new device - /dev/fill - to the OpenBSD kernel, not to be confused with /dev/full that other systems have but OpenBSD is currently lacking. Come to think of it, let's add that too!

All in this weekend's look at memory special devices.

But it doesn't work with removable disk devices such as USB flash drives.

Let's look at how eject is implemented in the first place, and see what we need to do to add this re-loading functionality to the kernel in today's mini-explainer

Maybe you've even wondered what programming would be required to implement such a feature. Well, now you can find out!

Our latest in-depth write up covers adding new ioctls to the kernel, and a general poke around the wscons and rasops code. Of course, you can just download the pre-written patches too, if kernel programming isn't your thing.

If you track NetBSD-current, you should get the new code next time you do a cvs update. It's also in the latest daily snapshot build.

Based on what we're hearing, one feature that people would particularly like to see is italic text.

Well, the wait is, (almost), over!

We asked Crystal to work on this, and she's just finished a separate mini-patch to implement exactly that, (along with the bold font code as well, so you can do bold and italic together).

As if that wasn't enough, she's also contributed patches to remove the unused rasops_isgray lookup table, fixed a couple of off-by-ones, and added support to directly select the eight 'bright' colors, all of which is now already in -current. In fact, the off-by-one bugfixes have also been submitted to NetBSD and accepted there too!

And yet this still isn't the sum total of Crystal's work so far, because she's also floated a patch to add 256 color support, tidy up the rasops code to avoid some un-necessary bit-shifting, and display bold text as actually bold rather than just a brighter color. This hasn't landed in -current yet, so if you want these enhancements you'll need to apply the patches yourself and re-compile the kernel. If you're interested, drop Crystal an email and let her know what version you're running, and we'll keep nudging her until she sends you a suitable diff.

We're getting off to an early start here at Exotic Silicon, with a write-up about some work Crystal has been doing to make the framebuffer console on OpenBSD behave a bit more like xterm.

Wondering why this is a good thing? You can find all of the details in the article.

Don't forget to check back here regularly for the lastest updates from Exotic Silicon's research department throughout the year, and if you haven't already bookmarked our commerical services pages, now would be a good opportunity!

Except that judging by the amount of feedback we've had since Crystal published her article back in September about using optical discs on OpenBSD systems, it seems like a lot of you don't have a propper backup strategy in place at all!

Since we've been asked repeatedly for a practical guide to actual backup strategies rather then just writing the discs, we've cut short Jay's winter leave and asked him to produce an overview of the policies we use ourselves and how they can be applied more generally. Enjoy!

Actually, the patchset for OpenBSD 7.1 applies just fine to an OpenBSD 7.2 installation so we didn't bother to release an update to it.

However, it seems that a few of you were concerned about the offset reported by the patch utility as kern_sysctl.c has changed between the two versions, so we've prepared a new patchset that applies cleanly to OpenBSD 7.2. There is no functional change.

Well, actually no. Here at Exotic Silicon we're big users of optical for archival storage, and have been for as long as we can remember.

Now, Crystal's kindly taken some time out to show you a few neat tricks and techniques for recording BD-R media on BSD systems.

The good news is, yes, it can! And initial tests suggest that it works quite well. So if the thought of learning about IPSEC made you cringe seven months ago, head on over to our newly published SMTP via wireguard tunnels article and see if that feels more accessible.

With this simple but useful fix, the screen blanker can be disabled again after being enabled. From reading the original code and CVS history, it seems that the bug has been present since the screen blanking code was added back in 2001.

Oh, really? You think we're just making it up? You think that the C compiler knows better than we do? Ha! Let's have some fun doing some benchmarks...

Thanks for the feedback, but actually we were aware of this and deliberately did not update it immediately:

The way gemini checks certificates is different to a web browser. Gemini generally uses trust on first use, (TOFU), and the specification actually recommends this, (in section 4.2), as well as suggesting that self-signed certificates are at least considered equal to CA signed certificates in terms of level of trust.

When we set it up, we ignored this advice and used a ‘real’ CA certificate which expired after 90 days.

Unfortunately all of the users who had used the gemini server up to that point now had that certificate trusted, and if we change it then when those users visit the site again their browser will typically show a warning because the certificate has changed, (even if the new certificate is also a valid CA signed certificate).

So we deliberately left the expired certificate, because we wanted to see whether new users who had not visited the site before would see errors or whether their browsers would just accept the expired certificate as valid or not, I.E. we wanted to see how gemini browsers are implementing TOFU in the real world, (which, as a research organisation, is typical of the sort of thing we focus on).

But enough already... We'll change it to a self-signed one, so expect to be prompted to accept a new certificate when you next visit.

Thanks again for all the feedback we received about this! It's nice to see more people using the gemini server.

What's more, Exotic Silicon isn't just providing a patch, oh no, our research team will take you step by step through how the code was written, too.

Head on over to the candlelit console page, which as always is also available via our gemini server if plain text articles are your preference.

Visit the resizing softraid volumes page, which is, of course, available via gemini as well as https.

We chose the name ‘reckless guide’ as it covers lots of things that are not encouraged by the project's official documentation. Have fun!

Visit the reckless guide index page on our website, (available in ten themes), or for those who prefer the retro feel the content is also on our gemini server.

We've put our new gemini server online at gemini://gemini.exoticsilicon.com/. Currently it contains gemtext versions of most of the website articles on research.exoticsilicon.com, so you can enjoy our content in an even lower bandwidth format.

For those readers who are not familiar with the gemini protocol, it's somewhat like a modern version of gopher. If you're not familiar with the gopher protocol, you've probably not been in the IT industry as long as we have!

We've got lots planned for this year, and hope that you'll following along with our research and development here at Exotic Silicon.

After a much longer than expected haitus, Exotic Silicon is now fully operational again. What started out as a simple server move turned into something much larger, as we took advantage of the opportunity to do a complete overhaul of our infrastructure. All of our on-line services have now been moved to new servers, in a different datacenter. The back-end website code has been mostly re-written from scratch, for even better performance, and it's now running on a different operating system. We've even re-organised our office space and upgraded the air-conditioning, so we're nice and comfortable with high expectations for the future.

More things have changed than have stayed the same, but rest assured that if you enjoyed Exotic Silicon before, we're confident that you'll be even happier now!

Most of the old website content has either been updated or removed completely, but we've already got plenty of new material on-line that we created during the break, and there is more in the works, so stay tuned and check back regularly for updates.