OmniOS r151042i, r151040ai and r151038bi are now available.

### In r151040 and r151042

• OpenSSL 3.0.4 patched, fixing GSD-2022-1002526 heap overflow.

For further details, please see https://omnios.org/releasenotes

Any problems or questions, please get in touch.

OmniOSce v11 r151042 is out now!

On the 2nd of May 2022, the OmniOSce Association has released a new stable version of OmniOS - The Open Source Enterprise Server OS. The new release comes with many tool updates, brand-new features and additional hardware support. For details see the release notes.

Note, that r151030 LTS is now end-of-life. You should upgrade to r151038 to stay on a supported long-term-support track.

OmniOS is fully Open Source and free. Nevertheless, it takes a lot of time and money to keep maintaining a full-blown operating system distribution. Our statistics show that there are almost 2’000 active installations of OmniOS while fewer than 20 people send regular contributions. If your organization uses OmniOS based servers, please consider becoming a regular patron or taking out a support contract.

Any problems or questions, please get in touch.

In the late 90s, I messed a little bit with electronics but I stopped because I got interested in programming. This last January, I decided to revisit this hobby.

I went through my collection of random components and found one 555 timer chip—specifically a TS555CN. I played with it on a breadboard and very quickly concluded that I should have more than just one. Disappointingly, sometime over the past 25 years, STM stopped making TS555 in DIP packages, so I ordered NA555PE4s thinking that they should be similar enough.

When they arrived, I tried to make use of them but I quickly noticed that their output seemed…weird. I tweeted about it and then tweeted some more. I concluded that precision 555s just weren’t fundamental enough to most circuits using DIP packages, and that I would have to make do with the NA555 parts.

Fast forward a few months, and I noticed ICM7555IPAZ on Mouser. The datasheet made it look a lot like the TS555…so I bought one to benchmark.

I went with a very simple astable multivibrator configuration—the same one that every 555 datasheet includes:

 R1, R2 1kΩ C1 220nF C2 0.01μF C3 10μF

The TS555 datasheet suggested 0.01μF for C2, and it didn’t seem to harm the other two chips so I went with it.

The NA555 datasheet suggested 0.01μF for C3. That cleaned up the rising edge slightly for TS555 and ICM7555. NA555’s rising edge actually became an edge instead of a huge mess, however it still seemed to be limited so I went with a bigger decoupling capacitor—namely 10μF. That didn’t seem to harm the other two chips.

Finally, note that the output is completely unloaded. I figure that this is reasonable since there are plenty of high input impedance loads that the 555 output could feed into. (A quick sanity check with a 1kΩ resitor to ground shows that the output voltage drops by about a volt, but the general shape of the wave doesn’t change.)

I assembled it on a breadboard with plenty of space for my fingers to swap out the chip:

The orange and red wires go to +5V and the black one goes to ground. All 3 are plugged in just right of the decoupling capacitor (off image).

Looking at the three datasheets, they all provide the same (or slightly rearranged) formulas for the frequency and duty cycle. Since I used 1kΩ for the two resistors and 220nF for the capacitor, I should be seeing:

$f=\frac{1.44}{\left({R}_{A}+2*{R}_{B}\right)*C}=2182\mathrm{Hz}$

and duty cycle:

$D=\frac{{R}_{A}+{R}_{B}}{{R}_{A}+2*{R}_{B}}=\frac{2}{3}$ or 66.67%

Because I used a breadboard, there is some amount of stray capacitance which likely shifts the frequency a bit. Based on previous experience, that shouldn’t be too much of an issue.

I supplied the circuit with a power supply set to 5V and 0.2A. (It operated in constant-voltage mode the entire time.)

Unlike some of my previous experiments, I actually tried to get a nice clean measurement this time. I used the probe grounding spring to get a short ground and measured between pin 1 and 3 (ground and output, respectively).

Let’s look at the amplitude, frequency, duty cycle, and rise time of the three chips. I took screenshots of the scope as I was performing the various measurements. To make it easier to compare them, I made combined/overlayed images and tweaked the colors. This makes the UI elements in the screenshot look terrible, but it is trivial to see how the chips compare at a glance. In the combined images TS555 is always yellow, NA555 is cyan, and ICM7555 is magenta.

### Amplitude, frequency, and duty cycle

(Individual screenshots: NA555, TS555, ICM7555)

It is easy to see that the output of both TS555 and ICM7555 goes to (and stays at) 5V. The NA555 spikes to 5V during the transition, but then decays to 4.5V. More on this later.

Similarly, it is easy to see that the TS555 and NA555 have a very similar positive cycle time but different enough negative cycle time that their frequencies and duty cycle will be different.

TS555 got close with the frequency (2.20 kHz) while NA555 got close with the duty cycle (65.75%). ICM7555 was the worst of the bunch with 2.28 kHz and 63.23% duty cycle.

### Rise time

(Individual screenshots: NA555, TS555, ICM7555)

The NA555 has a comparatively awful rise time of 74.88 ns. The TS555 appears to be a speed demon clocking in at 18.69 ns. Finally, the ICM7555 appears to split the difference with 41.91 ns.

I still think that it is amazing that a relatively inexpensive scope (like the Siglent SDS 1104X-E used for these measurements) can visualize signal changes on nanosecond scales.

### Revisiting amplitude

In a way, looking at the amplitude is what got me into this evaluation—specifically, the strange output voltage on the NA555 chip. Let’s take a look at the first microsecond following a positive edge.

(Individual screenshots: NA555, TS555, ICM7555)

After the somewhat leisurely rise time of ~75 ns, the output stays near 5V for about 200 ns, before dipping down to about 3.75V for almost 200 ns and then recovering to about 4.5V over the next 400 ns. The output stays at 4.5V until the negative edge.

This is weird and I don’t have any answers for why this happens. I tried a handful of the NA555s (all likely from the same batch), and they all exhibit this behavior.

### NA555 decoupling

As I mentioned in the introduction, I didn’t follow the NA555’s decoupling capacitor suggestion. I wasn’t planning on writing this section, but I think that it is interesting to see just how much the output changes as the decoupling capacitor is varied.

As before, I made combined/overlayed images for easier comparison. This time, yellow is no decoupling capacitor, magenta is 0.01μF (suggested by the NA555 datasheet), cyan is 0.1μF, and green is 10μF (used in chip comparison circuit).

(Individual screenshots: no cap, 0.01μF, 0.1μF, 10μF)

As you can see, not having a decoupling capacitor makes the output voltage go to nearly 7V in a circuit with a 5V supply. Adding the suggested 0.01μ certainly makes things better (the peak is at about 5.8V) but it looks like the chip is still struggling to deal with the transient. Using 0.1μF or more results in approximately the same waveform with a peak just around 5V.

The suggested 0.01μF has another problem in my circuit. It makes the NA555’s output ring:

(Individual screenshots: no cap, 0.01μF, 0.1μF, 10μF)

Neither the TS555 nor the ICM7555 have this issue. They are both quite happy with a 0.01μF capacitor. Without any capacitor, they have a little bit of a ring around 5V (1.2Vpp for TS555, 200mVpp for ICM7555) but it subsides promptly. The ICM7555’s ringing is so minor, that it probably isn’t worth it to even use a decoupling capacitor.

### Summary

I’ve collected the various measurements from the screenshots and put them into the following table:

 Calculated TS555CN NA555PE4 ICM7555IPAZ f (kHz) 2.182 2.20 (+0.8%) 2.24 (+2.7%) 2.28 (+4.4%) D (%) 66.67 64.68 (-3.0%) 65.75 (-1.4%) 63.23 (-5.2%) Rise (ns) — 18.69 74.88 41.91 Logic high peak (V) 5 5.08 5.12 5.08 Logic high steady state (V) 5 5.08 ~4.5 5.08

So, what does this all mean? Ultimately, not a whole lot. The 555 is a versatile chip, but not a magical one. Despite what the NA555 datasheet says, the 555 is not a precision device by modern standards, but it is still an easy way to get a square(-ish) wave around the desired frequency.

With that said, not all 555s are created equal.

The NA555 with all its flaws still works well enough and has a low price. So, for any sort of “crude” timing, it should work well. If, however, the circuit making use of the timer output requires a cleaner signal, then I’d reach for something better.

The ICM7555 is very good. It produces a nice clean output with reasonably fast edges, but not as fast as the TS555. Unfortunately, the performance costs extra—an ICM7555 is about twice the cost of a NA555.

All things being equal, the TS555 and ICM7555 are on par. One has a faster edge, the other has less ringing (and is still actively manufactured). I’ll save the TS555 for future benchmarks. Depending on the application, I’ll either use a NA555 or ICM7555.

I have the misfortune of maintaining some things using CMake. One major annoyance is that `__FILE__` is an absolute path, and that can’t be changed in CMake itself. Like most CMake annoyances, you can find a discussion online from about 15 years ago, but no sign of an actual fix.

Instead, you need a hack: this - I think - is the simplest one.

First, in our top-level `CMakeLists.txt`, we’ll define this helper function:

``````function(add_srcs NAME)
set(\${NAME} \${ARGN} PARENT_SCOPE)
foreach(f IN LISTS ARGN)
file(RELATIVE_PATH b \${CMAKE_SOURCE_DIR}
\${CMAKE_CURRENT_SOURCE_DIR}/\${f})
set_source_files_properties(\${f} PROPERTIES COMPILE_DEFINITIONS
"__FILE__=\"\${b}\"")
endforeach()
endfunction()
``````

This will take each of arguments, convert each file into a path relative to the top-level directory, then re-define `__FILE__` on a per-source-file basis. We also `set()` a variable for our parent scope to use.

We’ll also need `-Wno-builtin-macro-redefined`.

Then, in each child `CMakeLists.txt`, we will do something like:

``````add_srcs(MYCODE_SRCS mycode.c mycode.h)

``````

With merge of PR #8390 we updated lighttpd to the latest version 1.4.64 which removed support for the deprecated option server.set-v6only.
This option’s default was true in upstream since our update to version 1.4.46 but we disabled it with a patch to prevent breaking existing lighttpd installations.
The new update doesn’t allow to disable it anymore, meaning we break existing installs which used server.set-v6only.
If you’re affected, please change your lighttpd configuration to use different sockets for ipv4 and ipv6 connections.

This was originally a twitter thread, this is a more permanent expanded version.

When support for Solaris and SPARC was removed from Java, the code that was removed fell into a number of distinct classes, not all of which are equally valuable.

## Solaris platform support

First, there's the support for Solaris (and thus illumos) as an operating system (the os tree in hotspot, specifically, but there are other places in the tree that have OS-specific code), which we definitely want to retain in the illumos port of openjdk.

There really isn't much difference between Solaris and illumos from Java's point of view. We have a tiny bit of illumos-specific code in the patches, but that fact is that you can take what I've done and build it on Solaris pretty easily.

## Solaris x86 cpu support

Then there's support for the x86 architecture on Solaris (and thus illumos) as a specific platform (the os_cpu tree in hotspot, specifically), which I also want to retain.

## SPARC cpu support

Then there's support for SPARC systems (mostly Solaris, but it took out any other OS that wanted to support SPARC too), which I've decided to pass on (if anybody wants it, they're free to do the work, but it's too large a task for me).

With SPARC removed, the remaining platform (x86) is supported by multiple other operating systems, so the basic processor port is no longer my concern. What this means, also, is that it should be relatively straightforward to add in support for arm, for example, if we ever got to the stage where illumos gained a new hardware port.

## Studio toolchain support

Then there's support for the (now legacy) Studio toolchain, which was a right pain, was a great motivator for the removal, and I can only say good riddance.

There's some junk around the fact that Studio uses different command line flags to gcc. Sometimes the code has to differ based on idiosyncracies of the Studio compiler. A larger part is the way that Studio and gcc handle inline assembler, which I've almost (but not quite) fully cleaned out.

## Support for legacy Solaris versions

Then, when you look closer, there's actually bits of code to support really old Solaris versions or other components that's simply no longer relevant and it would be a good thing to get rid of all that complexity.

Some of this is complex workarounds for bugs that have long been fixed. Some things use dlopen() to handle the fact that not all releases have all the shared libraries. There are still some comments mentioning old Solaris versions that you wonder if they're still relevant.

## Support for various quirks and peculiarities

Finally, there's a bunch of code to simply do weird or idiosyncratic things on Solaris just because you can, and I'm actually quite keen to rip all that out and just do things the correct and easy way. Historically, there have been certain interesting peculiarities on Solaris waiting to trip up the unwary, mostly for no good reason whatsoever.

As an example of that last one, Java contains its own implementation of the way that Solaris falls back on the NIS/NIS+ domain for dns searches, and even looks for LOCALDOMAIN in the environment. Oh dear. I've eradicated that.

Another example is that there's still quite a lot of font handling code that's specifically referencing /usr/openwin, and has interesting knowledge of bugs in the OpenWindows font files.

Something I ought to look at is the way that printing is handled. Java thinks SunOS is SYS5 from the point of view of printing, which (thankfully) hasn't really been the case for a very long time. In illumos the state of printing is a mess, as we have a bunch of legacy support built in, while ideally we would just move to CUPS.

I'm also wondering whether to remove DTrace. I haven't seen it working for a while, the native DTrace in Java was always a bit problematic (the performance hit was massive and quite discouraging), and I've always disabled it in my builds.

Together, eliminating these peculiarities reduces the size of the port, makes it easier to maintain (because I don't have to keep fixing the patches as the source changes for other reasons), and makes the Java behaviour consistent with other platforms rather than being needlessly different - after all, Java is supposed to be cross-platform.

This post is about two of the  fox hunts organized by the Bristol County Repeater Association in 2021. (Information about the last/next fox hunting event.)

### July 31st, 2021

This was my first fox hunt of any kind. To improve the chances of success I teamed up with KM1NDY and AA1F. They participated in at least one BCRA fox hunt before, so they knew what to expect. (You can read KM1NDY’s thoughts about the hunt on her blog.)

The “parameters” of the hunt were simple: find the transmitter transmitting every 5 minutes from somewhere within 5 miles of exit 13 on MA 24.

Everyone likes to talk about gear, but at least in my opinion it is much more important to have a good strategy than to invest in specialized gear. That idea, combined with not knowing whether I’d like fox hunting or not, meant that I was going to use what I already owned. That meant WA5VJB’s cheap yagi and an Alinco DJ-G7 handheld. As far as non-radio gear is concerned, I brought my iPad to use for an annotated map.

I already talked about the antenna in my ARRL June VHF contest writeup, so I won’t repeat myself here. I got the Alinco handheld because I wanted a handheld with a third band. That narrowed my options down a lot. Since I heard good things about the Alinco and having a 1.2 GHz capability seemed cool, I went with it, even though the Boston area doesn’t have any sort of 1.2 GHz activity.

We decided to meet up at  Massasoit State Park. That made it easy for me to do a POTA/WWFF activation after the hunt.

My co-conspirators were running a bit late, so I got to make the first “measurement” from the park parking lot alone. You can see it on the map labeled as #1:

As you can see, I went relatively low-tech on the map annotation. I just took a screenshot of a reasonably zoomed map and hand-drew the 5 mile circle. Then, during the hunt itself, I just eyeballed the direction of each measurement and noted it down.

When KM1NDY and AA1F arrived at the park, I shared with them my measurement. After a brief discussion about where to go next, I hopped into their car and we headed west to get back to the highway.

I won’t bore you with turn by turn retelling of the whole trip. I will, however, mention a few observations. In no particular order:

1. Even the eyeballed arrows on the map are more than sufficient to get an idea where the transmitter is.
2. The built-in attenuation in the Alinco handheld is super convenient, and pretty much all that I needed.
3. Knowing the fox can help a ton—E.g., Skip (KB1CNB), acting as the fox, is known to like coffee shop parking lots, so looking there first is wise.

### October 23rd, 2021

Between this and the previous BCRA fox hunt, I got a chance to do some on-foot fox hunting thanks to K1MJC who hid a fox several times in nearby  Waltham. This time, I decided to try the hunt by myself (well, with Holly) and left KM1NDY and AA1F to fend for themselves—or “once our partner and now our competitor” as KM1NDY put it in her writeup.

This was a bigger hunt. The radius was 10 miles centered on the Veterans Memorial Bridge in Fall River and there were two transmitters!

Given the size, I decided to make a better blank map. I stitched together a couple of screenshots and then drew 5 mile and 10 mile circles. This turned out to be mostly useless since both foxes were within the 5 mile circle and we hadn’t even picked them up before entering the inner circle. Just look at the annotated map:

I didn’t even bother to try to capture all the information on this map because of how close everything was. When I got home, I ended up redrawing the map to show all the detail based on the above map, notes I made on the side, and what I remembered.

As you can see, we started off getting measurements for both foxes, but soon afterwards thought that we were relatively close to the blue fox. After driving between the two banks of the river far too many times, we gave up on the blue fox and tried our luck with the red fox.

Hunting the red fox was pretty straightforward, and before long we found Skip (KB1CNB) in his car playing the role of the fox. Skip told us that the other fox (blue on our map) was on the other side of the river. This sort of helped. So, we headed across the river.

Looking at the map now, it is clear which measurements were real and which were erroneous, but it is much harder to sort it all out when you are driving around not knowing where the fox is. :) We got really close at stop #20 where we got two equally promising directions. Sadly, we followed what turned out to be the reflection instead of the real one because we assumed that the blue fox was, much like Skip’s, a car in a parking lot. It wasn’t. The fox was on a step ladder in someone’s yard. We were clued in to this when someone mentioned it on the BCRA repeater.

I should know better, but I’ll promise anyway to write about my fox hunting strategy at some point in the future.

hamwaves.com — A cornucopia of amateur radio content.

Software type content — Assorted (mostly DSP) software by Jonti.