NetBSD Planet

July 02, 2020

UnitedBSD Tutorial for playing music CDs on OS108 (NetBSD 9.0)

Hello everyone

If you want to listen to music on your computer without complications, follow
the tutorial below will help.

1) You must have the VLC software installed on your computer.

2) At the terminal as a user, type the command:

$ vlc cdda: /// dev / cd0

NOTE: Check the CDROM drive with the dmesg command.


July 01, 2020

UnitedBSD ARM devices

I'm trying to decide whether or not I should purchase a PineBookPro or a RockPro64 SBC to use as my secondary NetBSD device. There is bootable images for these and other ARM devices.

If anyone can provide some feedback on what is working/not working (built in wifi?) on such devices that might help me decide.
I know @nia uses a PineBookPro so your thoughts would be appreciated.

I would essentially be replacing my ThinkPad x230 if I was to buy the laptop and I'm not sure if a difference in performance would be noticeable or not and whether it would be overall worth it. If I purchased the RockPro64 SBC I'd likely build it to use as a desktop PC/NAS and install lots of storage.

Am I silly for thinking that 4GB of RAM isn't enough? is that just how I've been conditioned to think after many years on bloated Windows and Linux computers? Are there better SBC's for NetBSD specifically that will be more powerful for desktop applications?

I have read this and this and I've also been following @jmcwhatever & @astr0baby on twitter for a while now.

I'm just fishing for knowledge based on personal experience which might help me reach a conclusion. Any and all input is welcome 😃

June 30, 2020

Ruben Schade The second half of 2020

Today is the last day of the first half of 2020. We’re halfway through. I’m so overwhelmed, I can’t think what else to type.

tasty.yml---name: Install a bagelpkgin:  name: bagel  state: present  update_cache: yesregister: time_to_makan

Use Ansible, pkgsrc, and bagels, and make your life a little bit better.

This post originally appeared on Rubenerd.

June 29, 2020

Ruben Schade BSD Now discusses my encrypted ZFS on NetBSD post

I was wondering why traffic to my server had spiked in the last few days: Allan Jude and Benedict Reuschling discussed my encrypted ZFS on NetBSD post on their latest episode of the BSD Now podcast! I’ve had the privilege of meeting both of them in person a few times now, and they’re as knowledgable and friendly as you’d expect when listening to their show.

Back in May I tested NetBSD 9’s disk encryption for the first time, and used it to create an encrypted ZFS pool. I asked at the end without:

The next steps will be to research if I can (or should!) do ZFS send/receive with my FreeBSD ZFS boxes…

Allan Jude responded:

The BSD Now logo

The answer is… yes!

ZFS replication is designed to be fully forwards and backwards compatible, so even if you are sending from the very newest FreeBSD, a ZFS send—provided you don’t enable any extra features with extra flags—will be fully receivable on an old FreeBSD 8 machine, or an image you create on that FreeBSD 8 machine will be receivable on your FreeBSD 13 machine. Part of the point of ZFS send/receive is to enable this transition.

Now when you do a send/receive, that’s why you have to specify some extra flags if you want to enable newer features, like lowercase “c” to enable compression, so those compressed blocks will stay compressed during send/receive. That presupposes that the other side is going to understand that.

Since ZFS replication is a unidirectional protocol, we don’t ever talk to the other side about what features it supports, so it depends on you doing that, or having a script to do it for you.

Also, if you use hostnames to transfer, make sure they’re named for Star Trek ships and not anime characters or you’ll lose throughput in the secondary InfiniBand plasma manifold.

Thanks! And for the interests of transparency, one of those transcribed sentences was fake.

This post originally appeared on Rubenerd.

June 27, 2020

Ruben Schade Universally-applicable pip design decisions

pkgsrc lists these features of pip, emphasis added:

I’d say the emphasised lines would be useful for any tool, not least a package manager.

This post originally appeared on Rubenerd.

DragonFly BSD Digest In Other BSDs for 2020/06/27

Overflow again, finally.

June 26, 2020

UnitedBSD Mount Android phone on OS108 (NetBSD 9.0)

Hello, UnitedBSD People

I would like a help from you in the OS108 system (NetBSD 9.0). Referring to mounting the device on it. Below is the data:

Cell Phone: Samsung Galaxy J6

Android version: 9

On Fedora Linux I used the MPT driver, and it worked correctly. And to further complicate these devices and new versions of these phones has new "features" that actually complicate your connection to the computer.

When I connect my phone to the computer's USB port, android gives me the following options:

1) Transfer files
2) USB anchoring
4) Transfer files
5) Just charge the phone

And for each option the system delivers a form of connection, being them.

1) ucom0 at umodem0
2) urndis0: Ethernet
3) midi1 at umidi0: <0> 0 on umidi0
4) ugen0: SAMSUNG (0x4e8)
5) ucom0 to umodem0

But the options I use are 1 and 4.

How do I set up these options?

Attached are the prints

I am grateful for any assistance.

Thank you

June 23, 2020

Ruben Schade More FreeBSD HPE Microserver homelab answers

My homelab post generated a ton of questions and comments, most of them specific to running FreeBSD on a Gen8 HPE Microserver. I answered a question about how to boot off the optical drive SATA port, then promptly forgot to answer any more!

This post will be a grab-bag summary of some other questions that were asked a few times.

Is the budget spec’d G8 Microserver with a Celeron any good?

Short answer, yes. Here’s the specs of my lowest-end unit:

$ sysctl hw.model hw.ncpuhw.model: Intel(R) Celeron(R) CPU G1610T @ 2.30GHzhw.ncpu: 2

This may not seem like much, but it’s still a server board with ECC memory for your ZFS arrays, which I care about more than performance. It even has enough power for serving multiple file shares while transcoding PleX to our Apple TV at 1080p, and all under 35W TDP so the fans stay nice and quiet.

The only two things I don’t like about this CPU: no AES-NI offloading, and while it has VT-x, it doesn’t have VT-d. The former surprised me given how easily it delivers data off GELI-encrypted drives to our Macs with netatalk, but I suppose that shows the bottleneck there isn’t the crypto.

My other Microserver uses an old 4-core Xeon E31260L which has all the above features and lets me thinker with hypervisors. It also only hits 45W, so the fans don’t take off late at night while we’re trying to sleep.

Have you made any modifications to the hardware?

Save for running an SSD in the optical drive bay and adding a few more DIMMs, not really. The previous owner of my Xeon Microserver upgraded the CPU from its original Celeron.

The one other minor change was the addition of a passive heatsync on the Broadcom NIC chips as John Stutsman described. In Sydney summers and Singapore all year round, this one chip regularly exceeded 70°C which didn’t measurably impact performance, but still had me worried. I should do a proper post about this one day.

Play Cooling the Broadcom Chip at Location 13-LOM on my Gen8 MicroServer

What Linux distros have you used on it?

At work we use Debian with Xen, so I ran it on my Xeon Microserver too with OpenZFS and btrfs for testing, the former of which worked fine and the latter isn’t the fault of the hardware! I still do use Debian on one now, albeit as a bhyve guest.

While I’m talking about OSs, they’ve also run Oracle Solaris 11, VMware ESXi, and Windows Server 2012 R2. One day I intend to try OpenBSD as well.

Where did your hostnames come from?

Naming schemes are an incredibly important and detailed topic for which a dedicated post is warranted and forthcoming. For my Microservers, mio.lan is named for Akiyama Mio, the timid bassist from the K-On! franchise. And aino.lan was named for Minako Aino from Sailor Moon. They weren’t my favourite characters from their respective shows, but they played important supporting roles… like servers do.

As an aside, it’s it amazing how anime art has changed over the years. And K-On! is already almost a decade old itself, which makes me feel incredibly old.

What NICs does it have?

Mine have older Mellanox MT26428 QDR InfiniBand cards, after we upgraded hardware at work. But the two built-in NICs are Broadcom NetXtreme Gigabit Ethernet that Bill Paul’s excellent bge(4) drivers support out of the box on FreeBSD.

In a past life one of the servers also ran a 4-port Intel Gigabit PCIe card when I was using it as a glorified router and VPN end-point with some storage attached. I thought I had a dmesg saved, but I can’t remember.

I still owe people some answers about what my GELI and ZFS pool layouts look like, and how iLO works, but that’s it for now. Feel free to ping me at @Rubenerd on Twitter or my email if you need more info.

This post originally appeared on Rubenerd.

June 22, 2020

UnitedBSD Is NetBSD a good start to learn Unix?

I really like NetBSD, but some people keep telling me that I should learn FreeBSD and it's easy to start first. Is there anyone who have played around NetBSD and can understand how Operating Systems with NetBSD. Also, when you back to FreeBSD can you still understand how it works?

June 21, 2020

UnitedBSD Firefox userChrome.css

So besides wanting to see what your firefox looks like Share your screenshots and userChrome.css

I also wanted to start this thread because I am wanting to customise my firefox but where on earth is userChrome.css found on NetBSD? Or rather where should custom userChrome.css files be placed ?

I've looked in /usr/pkg/lib/firefox68/chrome/ as well as /usr/pkg/lib/firefox68/browser/chrome/ but cant locate it.

June 20, 2020

Benny Siegert Getting Started with NetBSD on the Pinebook Pro
If you buy a Pinebook Pro now, it comes with Manjaro Linux on the internal eMMC storage. Let’s install NetBSD instead! The easiest way to get started is to buy a decent micro-SD card (what sort of markings it should have is a science of its own, by the way) and install NetBSD on that. On a warm boot (i.e. when rebooting a running system), the micro-SD card has priority compared to the eMMC, so the system will boot from there.
DragonFly BSD Digest In Other BSDs for 2020/06/20

A relatively calm week.

June 18, 2020

Emile Heitor Fakecracker: NetBSD as a Function Based MicroVM
In November 2018 AWS published an Open Source tool called Firecracker, mostly a virtual machine monitor relying on KVM, a small sized Linux kernel, and a stripped down version of Qemu. What baffled me was the speed at which the virtual machine would fire up and run the service. The whole process is to be compared to a container, but safer, as it does not share the kernel nor any resource, it is a separate and dedicated virtual machine.

June 17, 2020

Ruben Schade ARM Macs (but RISC-V would be cooler)

The rumours of an ARM-based Mac have only been getting louder with WWDC approaching. Old rumours have been reheated and served as fresh news, and pundits have worked themselves into a lather unlike anything I’ve seen in a while. It’s not the first architecture transition for many of us in the ecosystem, but while there are superficial similarities between Motorola to PowerPC, and PowerPC to Intel, there’s enough unique about this situation to be interesting.

I forgot that my earliest blog posts here were written on my beloved old iBook G3. It was the first machine I ran Mac OS X, FreeBSD, and NetBSD on, the latter two in part because their PowerPC support was so great. Two years later in 2006, I was writing about downloading universal binaries from Mozilla for my shiny new first-generation Intel MacBook Pro. That screenshot of Camino takes me back.

The PowerPC to Intel transition, and Apple’s handling of it, offered four compelling changes:

  1. Better performance. Intel’s CPUs were faster by that stage, but more importantly they offered better performance-per-watt. I also had a PowerPC G5 tower, but by that stage it had become obvious an equivalent PowerBook wasn’t feasible. Intel’s CPU roadmap also looked more assured.

  2. Instant access to PC software and games. We weren’t stuck with slow Virtual PC anymore, we could hack our machines to dual-boot into Windows when we needed to. I was so excited to beta test the first versions of Parallels Desktop and VMware Fusion. And eventually, Apple officially offered Boot Camp in 2006.

  3. Easier software porting. Games especially benefited from this.

  4. Decent (enough) compatibility. Universal binaries meant you didn’t have to worry about new software being compatible. Rosetta could also dynamically translate PowerPC to Intel fairly well, given how much faster the Intel silicon was. Four years later, and PowerPC started to disappear.

There’s every reason to believe an ARM-based Mac would offer all of the same benefits that Intel offered in point 1) above. Apple’s phones have the fastest CPUs in the industry, and the performance-per-watt could offer iPad-like battery life and performance in a Mac, for those of us who don’t like tablets.

The other points, perhaps selfishly, worry me.

Is there sufficient performance headroom on ARM to offer an amd64 translation layer that wouldn’t be so slow as to be practically useless? Would Apple even offer one? Will it only accelerate macOS’s devolution into a platform to run horrible Electron apps, or poorly-ported software from iOS?

A big part of the Mac value proposition for me was the fact I could use the desktop with which I was most familiar and enjoyed using, but could drop to PC land for a specific Windows tool or game. Yes I could use another dedicated PC that would sit there taking up space 90% of the time, but that’s another machine I have to maintain and keep in a tiny apartment. You also lose portability and convenience, something that nay gets a mention when someone brings it up.

Despite the architecture being more splintered than amd64, it’s easy to see the future is ARM. The Pinebook Pro is the most compelling hardware I’ve seen in a while. I like playing world-building and simulation games sometimes. And yes, I still prefer macOS to Windows or other *nix desktops. Reconciling these increasingly-conflicting needs in one machine to do it all perhaps says more about me than a CPU transition.

My daily carry is already a Panasonic Let’s Note running FreeBSD, and I already offload as much as I can to my FreeBSD and NetBSD Microservers, and FreeBSD and Linux in cloud instances. I suspect the game machine I was going to get rid of might end up sticking around; I’ll just have to clean the dust off and wait for Windows Update each month I turn it on.

Part of me wishes that if they were going to ditch amd64, they’d go full hog and announce iOS and macOS on RISC-V. They’ve done more unpredictable stuff before!

This post originally appeared on Rubenerd.

June 16, 2020

Stack Overflow screen fails on NetBSD, reporting "poll: Invalid argument"

I have installed and used screen many times on several different operating systems. Recently I installed it on a NetBSD-8.0 virtual machine.

$ sudo pkgin install screen
calculating dependencies...done.

1 package to install:

0 to refresh, 0 to upgrade, 1 to install
0B to download, 1098K to install

proceed ? [Y/n] Y
installing screen-4.8.0nb1...
screen-4.8.0nb1: setting permissions on /usr/pkg/bin/screen-4.8.0 (o=root, g=wheel, m=4511)
screen-4.8.0nb1: adding /usr/pkg/bin/screen to /etc/shells
screen-4.8.0nb1: registering info file /usr/pkg/info/
$NetBSD: MESSAGE,v 1.5 2005/12/28 17:53:24 reed Exp $
pkg_install warnings: 0, errors: 0
reading local summary...
processing local summary...
marking screen-4.8.0nb1 as non auto-removable

However, when I went to use it, I got an immediate failure.

$ uname -mrs
NetBSD 8.0 amd64
$ ls -l /usr/pkg/bin/screen
lrwxr-xr-x  1 root  wheel  12 Apr  6 02:50 /usr/pkg/bin/screen -> screen-4.8.0
$ groups
users wheel
$ screen
poll: Invalid argument

This problem persists even when I first remove, then reinstall the screen package. Any suggestions as to what's wrong?

June 13, 2020

DragonFly BSD Digest In Other BSDs for 2020/06/13

I like having shorter link texts so they all line up, but sometimes it’s unavoidably descriptive.

June 06, 2020

Frederic Cambus OpenBSD framebuffer console and custom color palettes

On framebuffer consoles, OpenBSD uses the rasops(9) subsystem, which was imported from NetBSD in March 2001.

The RGB values for the ANSI color palette in rasops have been chosen to match the ones in Open Firmware, and are different from those in the VGA text mode color palette.

Rasops palette:

Rasops palette

VGA text mode palette:

VGA text mode palette

As one can see, the difference is quite significant, and decades of exposure to MS-DOS and Linux consoles makes it quite difficult to adapt to a different palette.

RGB values for the ANSI color palette are defined in sys/dev/rasops/rasops.c, and here are the proper ones to use to match the VGA text mode palette:

#define	NORMAL_BLACK	0x000000
#define	NORMAL_RED	0xaa0000
#define	NORMAL_GREEN	0x00aa00
#define	NORMAL_BROWN	0xaa5500
#define	NORMAL_BLUE	0x0000aa
#define	NORMAL_MAGENTA	0xaa00aa
#define	NORMAL_CYAN	0x00aaaa
#define	NORMAL_WHITE	0xaaaaaa

#define	HILITE_BLACK	0x555555
#define	HILITE_RED	0xff5555
#define	HILITE_GREEN	0x55ff55
#define	HILITE_BROWN	0xffff55
#define	HILITE_BLUE	0x5555ff
#define	HILITE_MAGENTA	0xff55ff
#define	HILITE_CYAN	0x55ffff
#define	HILITE_WHITE	0xffffff

And here is a diff doing just that, which I sent to [email protected] back in January 2017.

DragonFly BSD Digest In Other BSDs for 2020/06/06

Remember, BSDCan 2020 is still streaming if you read this early enough.

June 05, 2020

NetBSD Blog VAX port needs help

The VAX is the oldest machine architecture still supported by NetBSD.

The support for it sometimes causes heated discussions, but it also has benefits:

This are severe challenges for a general purpose operating system like NetBSD, but also provides reality checks for our claim to be a very portable operating system.

Unfortunately there is another challenge, totally outside of NetBSD, but affecting the VAX port big time: the compiler support for VAX is ... let's say sub-optimal. It is also risking to be dropped completely by gcc upstream.

Now here is where people can help: there is a bounty campaign to finance a gcc hacker to fix the hardest and most immediate issue with gcc for VAX. Without this being resolved, gcc will drop support for VAX in a near future version.

May 31, 2020

Benny Siegert Pinebook Pro, First Impressions
Note: This post was written on the Pinebook Pro :) After seeing it in action at FOSDEM (from afar, as the crowd was too large), I decided to buy a Pinebook Pro for personal use. From the beginning, the intention was to use it for pkgsrc development, with NetBSD as the main OS. It was finally delivered on Thursday, one day earlier than promised, so I thought I would write down my first impressions.

May 30, 2020

DragonFly BSD Digest In Other BSDs for 2020/05/30

Something that makes me happy: Vermaden’s Valuable News and BSD Now have both been reliable as clockwork for a long time now.

May 27, 2020

Frederic Cambus OpenBSD/armv7 on the CubieBoard2

I bought the CubieBoard2 back in 2016 with the idea to run OpenBSD on it, but because of various reliability issues with the onboard NIC, it ended up running NetBSD for a few weeks before ending up in a drawer.

Back in October, Mark Kettenis committed code to allow switching to the framebuffer "glass" console in the bootloader on OpenBSD/armv7, making it possible to install the system without using a serial cable.

>> OpenBSD/armv7 BOOTARM 1.14
boot> set tty fb0
switching console to fb0

This prompted me to plug the board again, and having support for the framebuffer console is a game changer. It also allows running Xenocara, if that's your thing.

Here is the output of running file on executables:

ELF 32-bit LSB shared object, ARM, version 1

And this is the result of the md5 -t benchmark:

MD5 time trial.  Processing 10000 10000-byte blocks...
Digest = 52e5f9c9e6f656f3e1800dfa5579d089
Time   = 1.340000 seconds
Speed  = 74626865.671642 bytes/second

For the record, LibreSSL speed benchmark results are available here.

System message buffer (dmesg output):

OpenBSD 6.7-current (GENERIC) #299: Sun May 24 18:25:45 MDT 2020
    [email protected]:/usr/src/sys/arch/armv7/compile/GENERIC
real mem  = 964190208 (919MB)
avail mem = 935088128 (891MB)
random: good seed from bootblocks
mainbus0 at root: Cubietech Cubieboard2
cpu0 at mainbus0 mpidr 0: ARM Cortex-A7 r0p4
cpu0: 32KB 32b/line 2-way L1 VIPT I-cache, 32KB 64b/line 4-way L1 D-cache
cpu0: 256KB 64b/line 8-way L2 cache
cortex0 at mainbus0
psci0 at mainbus0: PSCI 0.0
sxiccmu0 at mainbus0
agtimer0 at mainbus0: tick rate 24000 KHz
simplebus0 at mainbus0: "soc"
sxiccmu1 at simplebus0
sxipio0 at simplebus0: 175 pins
sxirtc0 at simplebus0
sxisid0 at simplebus0
ampintc0 at simplebus0 nirq 160, ncpu 2: "interrupt-controller"
"system-control" at simplebus0 not configured
"interrupt-controller" at simplebus0 not configured
"dma-controller" at simplebus0 not configured
"lcd-controller" at simplebus0 not configured
"lcd-controller" at simplebus0 not configured
"video-codec" at simplebus0 not configured
sximmc0 at simplebus0
sdmmc0 at sximmc0: 4-bit, sd high-speed, mmc high-speed, dma
"usb" at simplebus0 not configured
"phy" at simplebus0 not configured
ehci0 at simplebus0
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "Generic EHCI root hub" rev 2.00/1.00 addr 1
ohci0 at simplebus0: version 1.0
"crypto-engine" at simplebus0 not configured
"hdmi" at simplebus0 not configured
sxiahci0 at simplebus0: AHCI 1.1
scsibus0 at sxiahci0: 32 targets
ehci1 at simplebus0
usb1 at ehci1: USB revision 2.0
uhub1 at usb1 configuration 1 interface 0 "Generic EHCI root hub" rev 2.00/1.00 addr 1
ohci1 at simplebus0: version 1.0
"timer" at simplebus0 not configured
sxidog0 at simplebus0
"ir" at simplebus0 not configured
"codec" at simplebus0 not configured
sxits0 at simplebus0
com0 at simplebus0: ns16550, no working fifo
sxitwi0 at simplebus0
iic0 at sxitwi0
axppmic0 at iic0 addr 0x34: AXP209
sxitwi1 at simplebus0
iic1 at sxitwi1
"gpu" at simplebus0 not configured
dwge0 at simplebus0: address 02:0a:09:03:27:08
rlphy0 at dwge0 phy 1: RTL8201L 10/100 PHY, rev. 1
"hstimer" at simplebus0 not configured
"display-frontend" at simplebus0 not configured
"display-frontend" at simplebus0 not configured
"display-backend" at simplebus0 not configured
"display-backend" at simplebus0 not configured
gpio0 at sxipio0: 32 pins
gpio1 at sxipio0: 32 pins
gpio2 at sxipio0: 32 pins
gpio3 at sxipio0: 32 pins
gpio4 at sxipio0: 32 pins
gpio5 at sxipio0: 32 pins
gpio6 at sxipio0: 32 pins
gpio7 at sxipio0: 32 pins
gpio8 at sxipio0: 32 pins
usb2 at ohci0: USB revision 1.0
uhub2 at usb2 configuration 1 interface 0 "Generic OHCI root hub" rev 1.00/1.00 addr 1
usb3 at ohci1: USB revision 1.0
uhub3 at usb3 configuration 1 interface 0 "Generic OHCI root hub" rev 1.00/1.00 addr 1
simplefb0 at mainbus0: 1920x1080, 32bpp
wsdisplay0 at simplefb0 mux 1: console (std, vt100 emulation)
scsibus1 at sdmmc0: 2 targets, initiator 0
sd0 at scsibus1 targ 1 lun 0: <SD/MMC, SC64G, 0080> removable
sd0: 60906MB, 512 bytes/sector, 124735488 sectors
uhidev0 at uhub2 port 1 configuration 1 interface 0 "Lenovo ThinkPad Compact USB Keyboard with TrackPoint" rev 2.00/3.30 addr 2
uhidev0: iclass 3/1
ukbd0 at uhidev0: 8 variable keys, 6 key codes
wskbd0 at ukbd0: console keyboard, using wsdisplay0
uhidev1 at uhub2 port 1 configuration 1 interface 1 "Lenovo ThinkPad Compact USB Keyboard with TrackPoint" rev 2.00/3.30 addr 2
uhidev1: iclass 3/1, 22 report ids
ums0 at uhidev1 reportid 1: 5 buttons, Z and W dir
wsmouse0 at ums0 mux 0
uhid0 at uhidev1 reportid 16: input=2, output=0, feature=0
uhid1 at uhidev1 reportid 17: input=2, output=0, feature=0
uhid2 at uhidev1 reportid 19: input=8, output=8, feature=8
uhid3 at uhidev1 reportid 21: input=2, output=0, feature=0
uhid4 at uhidev1 reportid 22: input=2, output=0, feature=0
vscsi0 at root
scsibus2 at vscsi0: 256 targets
softraid0 at root
scsibus3 at softraid0: 256 targets
bootfile: sd0a:/bsd
boot device: sd0
root on sd0a (f7b555b0fa0e8c49.a) swap on sd0b dump on sd0b

Sensors output:

$ sysctl hw.sensors
hw.sensors.sxits0.temp0=39.50 degC
hw.sensors.axppmic0.temp0=30.00 degC
hw.sensors.axppmic0.volt0=4.95 VDC (ACIN)
hw.sensors.axppmic0.volt1=0.03 VDC (VBUS)
hw.sensors.axppmic0.volt2=4.85 VDC (APS)
hw.sensors.axppmic0.current0=0.11 A (ACIN)
hw.sensors.axppmic0.current1=0.00 A (VBUS)
hw.sensors.axppmic0.indicator0=On (ACIN), OK
hw.sensors.axppmic0.indicator1=Off (VBUS)

May 26, 2020

NetBSD Package System (pkgsrc) on DaemonForums conky vs torsmo
What's important for me is a seamless integration of the system monitor into the root window. When I click on the system monitor, I expect the window manager, in my case fvwm2, to respond, e.g. its menus should show up.

Conky: I use the default .conkyrc configuration file which sets own_window_type to desktop. When I click on conky, nothing happens. The mouse pointer remains unchanged; no fvwm2 menu pops up. That's not what I want.

Torsmo: I use the default .torsmo configuration file. When I click on torsmo, an fvwm2 menu pops up. Torsmo is truly transparent. Great.

The only problem is that torsmo has not been nicely ported to NetBSD 9. Every second, it emits on the console:


torsmo: cannot kvm_nlist: No such file or directory
I thought both programs draw on the root window and so they should not intercept clicks on the root window. Conky is doing that on my setup.

Anyone has an idea how to seamlessly integrate conky into the root window? If not, I'll look into kvm_nlist. That's a function from libkvm and comes with a man-page. How difficult can that be :-/

- - - - - - - - - - - - - - - - - - - -

Update two hours later: From a quick look. The torsmo error message comes from retrieving network stats

Up:$color ${upspeed eth0} k/s${color grey} - Down:$color ${downspeed eth0} k/s
My network interface is called re0. Renaming in .conkey eth0 to re0 works for conky. Renaming eth0 to re0 in .torsmorc continues to result for in the same error message.

I also noticed that the values for mem, memmax, swapmax are not correct. I think torsmo is broken beyond repair.

May 20, 2020

Amitai Schlair notqmail 1.08 released

notqmail logo

I’m pleased to announce notqmail 1.08, the latest update to notqmail. It addresses security vulnerabilities in qmail 1.03 reported yesterday by Qualys. As a fork, we’ve inherited qmail’s relatively few bugs; as an active qmail fork, we’ve addressed the vulnerabilities with a timely release; and as the community-driven open-source successor to qmail, we show our work.

The 1.08 release also includes many other small improvements we’ve made since 1.07, including fewer compiler warnings, less dead code, published intent to remove more presumed-dead code, my QMAILREMOTE patch, and our first few unit tests. For more detail, see the notqmail 1.08 release notes.

May 13, 2020

Server Fault Non-standard IP address with dashes

I ran the who command on a shared NetBSD box, and this weird user IP came up:

<redacted> pts/33   May 13 02:13  (XXX.XXX.XXX.XXX)
<redacted> pts/35   May 12 20:59  (202-172-110-147-)
<redacted> pts/36   May  6 20:36  (XXX.XXX.XXX.XXX)

I've never seen an IP like that. Obviously, ping 202-172-110-147- will complain with "Cannot resolve ... (Unknown host)".

There was a similar question posted 7 years ago, which posited that it was a non-standard way of denoting IP ranges, but seeing there's a - at the end of the address, it doesn't seem like a similar thing.


I've tried reverse DNS with nslookup 202-172-110-147-, which errors with "** server can't find 202-172-110-147-: NXDOMAIN"

Doing w <user> returns:

9:49AM  up 89 days,  7:46, 1 user, load averages: 0.23, 0.18, 0.17
USER          TTY     FROM              [email protected]  IDLE WHAT
<redacted>    pts/35  202-172-110-147- Tue08PM  4:13

Edit 2: This is on NetBSD, not Linux like I mentioned at the beginning (I thought the box was Linux):

$ uname -rsv
NetBSD 8.1 NetBSD 8.1 (GENERIC) #0: Fri May 31 08:43:59 UTC 2019  [email protected]:/usr/src/sys/arch/amd64/compile/GENERIC

Edit 3: Following @NStorm update, I ran w -n to display network addresses as numbers. I still see the same result

$ w -n <user>
 9:57AM  up 89 days,  7:54, 1 user, load averages: 0.12, 0.12, 0.14
USER          TTY     FROM              [email protected]  IDLE WHAT
<redacted>    pts/35  202-172-110-147- Tue08PM  4:22

May 07, 2020

NetBSD Blog Announcing Google Summer of Code 2020 projects

Google Summer of Code logo We are very happy to announce The NetBSD Foundation Google Summer of Code 2020 projects:

The community bonding period - where students get in touch with mentors and community - started on May 4 and will go on until June 1. The coding period will be June 1 to August 24.

Please welcome all our students and a big good luck to students and mentors!

A big thank you to Google and The NetBSD Foundation organization mentors and administrators!

Looking forward to having another nice Google Summer of Code!

May 05, 2020

Unix Stack Exchange NetBSD/FreeBSD and TP-Link TL-WN727N: Second encounter

Moved from SU.
First part at

So, I've installed NetBSD 7 and device shown again as ugen(ugein, lol).

ugen0 at uhub4 port 8 
ugen0: Mediatek 802.11 n WLAN, rev 2.01/00, addr 2

Then I'm installed FreeBSD 10.2 and ugen again.

usbconfig gives me ugen4.3: <product 0x7601 vendor 0x148f> at usbus4, cfg=0 md=HOST spd=HIGH(480Mbps) pwr=ON (90ma)

So, what's next? Buying new dongle is a last thing, which I'll make.

May 04, 2020

NetBSD Blog The GNU GDB Debugger and NetBSD (Part 2)
The NetBSD team of developers maintains two copies of GDB:

The base-system version of GDB (GPLv3) still relies on a set of local patches. I set a goal to reduce the local patches to bare minimum, ideally reaching no local modifications at all.

Over the past month I've reimplemented debugging support for multi-threaded programs and upstreamed the support. It's interesting to note that the old support relied on GDB tracking only a single inferior process. This caused the need to reimplement the support and be agnostic to the number of traced processes. Meanwhile the upstream developers introduced new features for multi-target tracing and a lot of preexisting code broke and needed resurrection. This affected also the code kept in the GDB basesystem version. Additionally over the past 30 days, I've also developed new CPU-independent GDB features that were for a long time on a TODO list for NetBSD.

After the past month NetBSD has now a decent and functional GDB support in the mainline. It's still not as featured as it could and CPU-specific handling will need a dedicated treatment.

Signal conversions

GDB maintains an internal representation of signals and translates e.g. SIGTRAP to GDB_SIGNAL_TRAP. The kernel independent management of signal names is used by the GDB core and requires translation on the border of kernel-specific implementation. So far, the NetBSD support relied on an accidental overlap of signal names between the GDB core and the NetBSD definitions, while this worked for some signals it wasn't matching for others. I've added a patch with appropriate NetBSD->GDB and GDB->NetBSD signal number conversions and enabled it in all NetBSD CPU-specific files.

Later, newly added code respects now these signal conversions in the management of processes.

Threading support

I've implemented the NetBSD specific methods for dealing with threads. Previously the pristine version of GDB was unaware about threading on NetBSD and the basesystem GDB relied on local patches that needed reimplementation to meet the expectations (especially rewrite to C++) of the upstream maintainers.

I have upstreamed this with the following commit:

Implement basic threading support in the NetBSD target

Use sysctl(3) as the portable interface to prompt NetBSD threads on
all supported NetBSD versions. In future newer versions could switch
to PT_LWPSTATUS ptrace(2) API that will be supported on NetBSD 10.0
and newer.

Implement as part of nbsd_nat_target:
 - thread_name()         - read descriptive thread name
 - thread_alive()        - check whether a thread is alive
 - post_attach()         - updates the list of threads after attach
 - update_thread_list()  - updates the list of threads
 - pid_to_str()          - translates ptid to a descriptive string

There are two local static functions:
 - nbsd_thread_lister()  - generic LWP lister for a specified pid
 - nbsd_add_threads()    - utility to update the list of threads

Now, GDB on NetBSD can attach to a multithreaded process, spawn
a multithreaded process, list threads, print their LWP+PID numbers
and descriptive thread names.

ELF symbol resolver

The NetBSD operating system relies on the ELF file format for native applications.

One of the features in GDB is to skip single-stepping over the internal ELF loader code. When a user of GDB instructs ther debugger to step a line in a source code, and whenever we land into an unresolved symbol in the GOT table, we could step internal code of the ELF loader, for the first usage of a public symbol, which is not necessarily wrong, but could be confusing. This is typically worked around with a generic code that tries to detect such scenario examining among others the code sections of the stepped code, but the default fallback is not functional on every NetBSD port, especially Alpha and ARM. The new code merged into GDB uses the same logic for all NetBSD ports, trying to detect the _rtld_bind_start symbol and act acordingly in case of detecting it.

SVR4 psABI parsers of AUXV entries

The ELF format ships with a mechanism to transfer certain kernel level information to the user process. AUXV is a key-value array located on the stack and available to an ELF loader. While Linux uses a different format than the one specified in SVR4 psABI, NetBSD follows the standard and stores the key value in a 32-bit integer always. This caused breakage on 64-bit CPUs and the NetBSD developers used to patch the Linux AUXV code to be compatible with the NetBSD behavior. I've added a dedicated function for the NetBSD AUXV handling and switched to it all NetBSD CPUs.

Process information (info proc)

As documented by the GDB project: Some operating systems provide interfaces to fetch additional information about running processes beyond memory and per-thread register state. If GDB is configured for an operating system with a supported interface, the command info proc is available to report information about the process running your program, or about any process running on your system.

Previously the info proc functionality was implemented only for Linux and FreeBSD. I've implemented support for the following commands:

All of these pieces of information are retrieved with the sysctl(3) interface. Example of an execution of the command is below:

(gdb) info proc all
process 26015
cmdline = '/usr/bin/cal'
cwd = '/public/binutils-gdb-netbsd'
exe = '/usr/bin/cal'
Mapped address spaces:

          Start Addr           End Addr       Size     Offset   Flags   File
            0x200000           0x204000     0x4000        0x0  r-x C-PD /usr/bin/cal
            0x404000           0x405000     0x1000     0x4000  r-- C-PD /usr/bin/cal
            0x405000           0x406000     0x1000        0x0  rw- C-PD 
      0x7f7ff6c00000     0x7f7ff6c10000    0x10000        0x0  rw- C-PD 
      0x7f7ff6c10000     0x7f7ff6db0000   0x1a0000        0x0  rw- CNPD 
      0x7f7ff6db0000     0x7f7ff6dc0000    0x10000        0x0  rw- C-PD 
      0x7f7ff6dc0000     0x7f7ff7000000   0x240000        0x0  rw- CNPD 
      0x7f7ff7000000     0x7f7ff7010000    0x10000        0x0  rw- C-PD 
      0x7f7ff7010000     0x7f7ff7200000   0x1f0000        0x0  rw- CNPD 
      0x7f7ff7200000     0x7f7ff7260000    0x60000        0x0  r-x CNPD /lib/
      0x7f7ff7260000     0x7f7ff7270000    0x10000    0x60000  r-x C-PD /lib/
      0x7f7ff7270000     0x7f7ff73c6000   0x156000    0x70000  r-x CNPD /lib/
      0x7f7ff73c6000     0x7f7ff75c6000   0x200000   0x1c6000  --- CNPD /lib/
      0x7f7ff75c6000     0x7f7ff75d1000     0xb000   0x1c6000  r-- C-PD /lib/
      0x7f7ff75d1000     0x7f7ff75d7000     0x6000   0x1d1000  rw- C-PD /lib/
      0x7f7ff75d7000     0x7f7ff75f0000    0x19000        0x0  rw- C-PD 
      0x7f7ff75f0000     0x7f7ff76e0000    0xf0000        0x0  rw- CNPD 
      0x7f7ff76e0000     0x7f7ff76f0000    0x10000        0x0  rw- C-PD 
      0x7f7ff76f0000     0x7f7ff77e0000    0xf0000        0x0  rw- CNPD 
      0x7f7ff77e0000     0x7f7ff77f8000    0x18000        0x0  rw- C-PD 
      0x7f7ff7800000     0x7f7ff780e000     0xe000        0x0  r-x CNPD /lib/
      0x7f7ff780e000     0x7f7ff7a0d000   0x1ff000     0xe000  --- CNPD /lib/
      0x7f7ff7a0d000     0x7f7ff7a0e000     0x1000     0xd000  r-- C-PD /lib/
      0x7f7ff7a0e000     0x7f7ff7a0f000     0x1000     0xe000  rw- C-PD /lib/
      0x7f7ff7c00000     0x7f7ff7c0f000     0xf000        0x0  r-x C-PD /libexec/ld.elf_so
      0x7f7ff7c0f000     0x7f7ff7e0f000   0x200000        0x0  --- CNPD 
      0x7f7ff7e0f000     0x7f7ff7e10000     0x1000     0xf000  rw- C-PD /libexec/ld.elf_so
      0x7f7ff7e10000     0x7f7ff7e11000     0x1000        0x0  rw- C-PD 
      0x7f7ff7eed000     0x7f7ff7eff000    0x12000        0x0  rw- C-PD 
      0x7f7ff7eff000     0x7f7fffbff000  0x7d00000        0x0  --- CNPD 
      0x7f7fffbff000     0x7f7fffff0000   0x3f1000        0x0  rw- CNPD 
      0x7f7fffff0000     0x7f7ffffff000     0xf000        0x0  rw- C-PD 
Name: cal
State: STOP
Parent process: 11837
Process group: 26015
Session id: 15656
TTY: 1288
TTY owner process group: 11837
User IDs (real, effective, saved): 1000 1000 1000
Group IDs (real, effective, saved): 100 100 100
Groups: 100 0 5
Minor faults (no memory page): 292
Major faults (memory page faults): 0
utime: 0.000000
stime: 0.003510
utime+stime, children: 0.000000
'nice' value: 20
Start time: 1588600926.724211
Data size: 8 kB
Stack size: 8 kB
Text size: 16 kB
Resident set size: 1264 kB
Maximum RSS: 2000 kB
Pending Signals: 00000000 00000000 00000000 00000000
Ignored Signals: 98488000 00000000 00000000 00000000
Caught Signals: 00000000 00000000 00000000 00000000

Event handling

I've implemented event handling for the following trap types:

While there, I have added proper support for ::wait () and ::resume () methods.

Syscall entry/exit tracing

I've added a support for syscall entry/exit breakpoint traps. There used to be some support for this mode in the basesystem GDB, however we missed a list of mapping of syscall number to syscall name. I've borrowed the script from FreeBSD to generate netbsd.xml with the mapping, based on definitions in /usr/include/sys/syscall.h. This approach of mapping syscalls for NetBSD is imperfect as the internal names are not stable and change whenever a syscall is versioned. There is no ideal approach to handle this (e.g. debugging programs on NetBSD 9.0 and NetBSD 10.0 can behave differently), and end-users will need to deal with it.

Threading events

As threading support is mandatory these days, I have implemented and upstreamed support for thread creation and thread exit events.

Other changes

As in general, I oppose to treating all BSD Operating Systems under the same ifdef in existing software, as it leads to conditionals like #if defined(AllBSDs) && !defined(ThisBSD) and/or a spaghetti of #define symbol renames. There was an attempt to define support for all BSDs in a shared file inf-ptrace.c, however in the end developers pushing for that reimplemented support part of the code for their kernels in private per-OS files. This left a lot of shared, sometimes unneeded code in the common layer.

I was kind to fix the build of OpenBSD support in GDB (and only build-tested) and moved OpenBSD-specific code from inf-ptrace.c to obsd-nat.c. Code that was no longer needed for OpenBSD in inf-ptrace.c (as it was reimplemented in obsd-nat.c) and in theory shared with NetBSD was removed.

My intention is to restrict common shared code of GDB to really common parts and whenever kernels differ, implement their specific handling in dedicated files. There are still some hacks left in the GDB shared code (even in inf-ptrace.c) for long removed kernels that obfuscate the support... especially the Gould NP1 support from the 1980s and definitely removed in 2000.

Plan for the next milestone

Finish and upstream operational support of follow-fork, follow-vfork and follow-spawn events. Rewrite the gdbserver support and submit upstream.

May 01, 2020 New Developer in April 2020

April 27, 2020

NetBSD Blog Improving libossaudio, and the future of OSS in NetBSD

There's two ways user applications can communicate with the kernel audio layer in NetBSD:

Linux drifted away from OSS and towards ALSA due to licensing disagreements.

Because of this drift, we're seeing increasing problems with OSS adoption today, even if the licensing concerns are no longer relevant, and other implementations of OSS have surpassed the original Linux OSSv3 implementation as far as their feature set and usability are concerned.

So, in NetBSD, it's recommended to use the native API for new code and only rely on the OSS layer for compatibility with existing code.

I spent a while working on third-party software to improve support for native NetBSD audio. These included Firefox, SDL, PortAudio, ffmpeg (working with [email protected]), and more.

However, I've turned my attention to the OSS translation layer. Since a lot of older and less popular software still relies on it, I wanted to go over the OSSv4 specification and iron out surprising differences.

Audacity/PortAudio's OSS usage is strange

I should note that most of these fixes were to enable Audacity to work without patching. Audacity is interesting because it hits a lot of edge cases as far as OSS API usage is concerned. Once I fixed the most notable issues, I made sure Audacity also supported the native API. Writing the necessary PortAudio glue for Sun/NetBSD audio and implementing these fixes took approximately two days.

Incompatibility 1 – SNDCTL_DSP_SPEED

[Out of range sample rates are now handled properly by the OSS layer in NetBSD-current.]

The NetBSD 9 kernel supports sample rates up to 192kHz. Specify anything higher, and NetBSD's audio API returns an error code and keeps the sample rate at its original value, or the legacy default of 8000 Hz (not particularly useful with modern devices).

However, OSS applications expected setting the sample rate to always succeed. The specification states that the actual set sample value may be an approximation and will not always use the exact requested value. So, if the requested value is out of range, NetBSD will now return as if the call succeeded, and set the sample rate to the current configured hardware rate (usually some multiple of 48kHz).

During its startup process, Audacity requested an overly high sample rate of 384kHz. This is well above the maximum supported. I'm still not sure why it does this, because it later configures the audio device to standard CD rate, but it meant that Audacity couldn't properly start without our local patches.

Incompatibility 2 – SNDCTL_DSP_CHANNELS

[Out of range channel numbers are now handled properly by the OSS layer in NetBSD-current.]

This was a very simple fix, similar to that of SNDCTL_DSP_SPEED. The NetBSD kernel supports between 1 and 12 channels for audio playback. Most commonly 1 is mono, 2 is stereo, and higher numbers are used with surround sound systems. The limit of 12 comes from the USB audio device specification.

If an out of range number is specified, libossaudio will now set the channel count to the currently configured number in use at the hardware level.

However, we encounter a more difficult difference between OSS and NetBSD audio when using the audio device in full duplex (recording from and playing back to the same device simultaneously). If your mic is mono and your speakers aren't, how do you set the channel counts to different numbers in OSS? You can't. There is one ioctl for setting both the recording and playback channels. In the native API, this is possible by setting info.record.channels and separately. We should ensure that the recording channels are always duplicated to be same as the number of playback channels.

Incompatibility 3 – SNDCTL_DSP_SETTRIGGER

[NetBSD-current now implements SNDCTL_DSP_SETTRIGGER.]

SNDCTL_DSP_SETTRIGGER is a somewhat more obscure part of the OSS API, in that it's only really useful if you are using poll() or another event notification mechanism on an audio device before performing any I/O, or you're performing I/O via mmap(), neither being particularly common in practice. It has the ability to force initialisation of playback/recording for the device if this isn't already the case.

In terms of the native API, this means that playback/recording becomes unpaused.

Previously in NetBSD, this part of the OSS API wasn't implemented and simply did nothing. However, it became obviously needed due to an incompatible change in NetBSD 9, as discussed on tech-kern.

Basically, we needed recording to be properly triggered without a read() so a few applications using poll() without prior I/O wouldn't block indefinitely.

Incompatibility 4 – SNDCTL_DSP_SETPLAYVOL

OSSv4 has special bits to manipulate the volume of an individual stream in an application while doing all the maths for this inside the kernel.

We don't support this properly yet (but reasonably could)... so code needs to be modified to do the volume manipulation in the application, or the OSSv4 support disabled.

I've only found a couple of applications that try to use this feature (audacious, qmmp). Currently, they're configured to avoid using OSSv4 and layer the audio through SDL or qt-multimedia instead.

I've at least fixed SNDCTL_DSP_GETPLAYVOL to return conforming values. NetBSD audio uses 0-255 for the gain of all channels. OSSv4 uses a range of 0-100 and encodes two channels into an integer, which is very odd in my opinion, and also limits surround sound support.

The future of libossaudio in NetBSD?

Hopefully, after my changes, OSS compatibility is in a much better shape when dealing with unusual parameters and uncommon API usage. The quality of the code also improves – in the process of this work, [email protected] pointed me towards a related information leak in the Linux OSSv3 compatibility layer in the kernel, and I was able to deal with it properly after looking at the OSS specification and Linux headers. All the fixes should be pulled up to 9-stable.

However, I'd personally like to eventually reach a point where we no longer need libossaudio. I've been writing a lot of code towards this goal.

In many cases, the applications relying on it could be easily modified or told to use libao/SDL2/PortAudio/OpenAL/etc instead, which all have native NetBSD audio support.

OSS aside...

We probably need to start thinking about supporting 24-bit PCM in the kernel, since I've found a few audio players that can't handle making the samples 32-bit before writing them to the device. The Sun audio implementation in Solaris has supported this for a long time now.

April 21, 2020

Kimmo Suominen Serial console for NetBSD

I’ve been switching my NetBSD machines to using a serial console lately, as it is easier to copy output from it (no more screen shots). I would still need to figure out how to setup rtty1 to log console output, so unexpected output could also be inspected later (hello, panic).

On the NetBSD VM its bootblocks must be reinstalled to select a serial port as the console. I’ve been using the auto option, so I can easily switch between the VGA and serial consoles. I set speed to zero, which will use the speed configured in BIOS. The only available “speed” with qemu is 115200 bps.

installboot -v -o console=auto,speed=0 /dev/rsd0a /usr/mdec/bootxx_ffsv2

In Proxmox a serial port must be added to the VM on the Hardware tab. It is important to leave the Display setting at Default (or VGA) — for some reason input from the serial console will not work in the boot menu otherwise. (It will work in BIOS and at the login prompt.)

  1. Also known as remote-tty in Debian. 

April 16, 2020

Brett Lymn Thomas E. Dickey on NetBSD curses

I was recently pointed at a web page on Thomas E. Dickeys site talking about NetBSD curses.  It seems initially that the page was intended to be a pointer to some differences between ncurses and NetBSD curses and does appear to start off in this vein but it seems that the author has lost the plot as the document evolved and the tail end of it seems to be devolving into some sort of slanging match.  I don't want to go through Mr. Dickey's document point by point, that would be tedious but I would like to pick out some of the things that I believe to be the most egregious.  Please note that even though I am a NetBSD developer, the opinions below are my own and not the NetBSD projects.

The first thing that I would like to mention is that the author seems to be incapable of spelling my name correctly.  It isn't hard, 4 whole letters but the only time that it is spelt correctly is when the text is copied from a NetBSD commit.  If you ever do read this Mr. Dickey, I am not offended, plenty of people struggle with my last name, I am quite used to it.

Before going further, just a bit of background as to how I started working on the NetBSD curses library.  I originally was using a commercial x86 port of System V UNIX on my home PC but started looking elsewhere when I found that the SL/IP implementation was bugged.  At the time Linux had no networking at all but the BSD source code had just been ported to the PC in a project known as 386BSD.  Since this had networking I picked this up and then switched to NetBSD early on.  Being used to the SYSV curses I was disappointed to find that there was no real way of handling cursor and function keys in a terminal independent manner as there is in the SYSV curses.  I developed and submitted a patch to the NetBSD curses library that added the support for the keypad() function and modified getch() to perform the conversion of key sequences into key symbols.  It was on the basis of this patch that I was offered the opportunity to be a NetBSD developer.

When working on NetBSD curses my overall philosophy is to follow The Single UNIX® Specification, Version 2: X/Open Curses, Issue 4 Version 2 
(I will refer to this as SUSv2 from now on) where possible, if a behaviour is undefined then I look to ncurses and match the behaviour there if appropriate on the basis that this normally results in less issues for someone porting an application.  I add ncurses extensions in response to problem reports (PRs).

Let's now have a look at Mr. Dickey's comments (I am tempted to use the word diatribe but that seems a bit strong...).  I won't go over all of them but will pick up the topics that he has mentioned going down his page.

I would like to pick up on the comments about making the window structure opaque.  I don't apologise for this, I believe that the fact that WINDOW * was available for applications to poke at is a violation of software layering and just wrong.  Later in Mr. Dickey's page he takes NetBSD to task over error checking (more on this later) but by making the contents of WINDOW available for the application there is little use in error checking if the application can just write what they want anyway.  It took ncurses until 2007 to opaque WINDOW.  Mr. Dickey makes some ominous sounding statements about adding functions to compensate for the opaquing.  As far as I am concerned the interface to update a window is specified by SUSv2, if there are extensions that need to be added they will be added as they are needed.
Given I made WINDOW opaque nearly 20 years ago, I have yet to see a PR to indicate that more is needed.  The positives of making WINDOW opaque are not only enforcing correct layering of software but it also means that the contents of WINDOW can be modified without requiring a major bump of the library since nothing outside the curses library has access so backward compatibility is maintained.

Making the character string in scanw const just makes sense the function does not need to modify the string so it should be a constant.  The NetBSD project does not need to worry about the compiler objecting because the base compiler works with this statement.

Wide curses was a Google Summer of Code project that was done by Ruibiao Qiu.  I think that this was a great success and added some very useful functionality to NetBSD curses.  It seems that Mr. Dickey is a bit confused by this, in actual fact, he is totally wrong on a number of points:
  1. The non-spacing characters are not stored as a linked list, they are an array
  2. The interface for setting non-spacing characters is anything that uses the complex character type (cchar_t)
He seems a bit mystified by the term non-spacing character, this term comes from SUSv2 described here
The non-spacing characters are dynamically added when required, this was my design as I thought that simply having a fixed array for every character cell in the display was a waste of memory, it would be more efficient to only allocate memory as required for the non-spacing characters.

The function specification for ungetch is ambiguous in SUSv2, NetBSD will accept the output from getch on the basis that the input stream has already been processed and it makes no sense to save the last character in what could be a multi-byte sequence.

As for testing of curses, yes, this is mine.  I am happy that at least some of our curses functions are being tested to ensure that any changes made don't affect the on-screen output and that if there are changes that they are highlighted and can be analysed for correctness.  It is too easy with terminal output to have something that "looks right" but is doing the wrong thing in the background.

Now we get to something I wrote on a mailing list:
Re: curses: create panel from stdscr?

I stand by my comments there.  I was referring to my attempt to report what I thought was an issue with the ncurses libmenu implementation.  I no longer have the email nor the reply from Mr. Dickey but my clear recollection of the tone and attitude was that I would not be bothered raising issues about ncurses with Mr. Dickey ever again.  I wrote the libmenu and libform libraries for NetBSD using the book "Programmer's Guide: Character User Interface (FMLI and ETI)", this is UNIX System Laboratories book so I regard it as definitive for the libraries.  I noticed a variance in the ncurses libmenu implementation but as I have stated my efforts of reporting that were not fruitful.  Mr. Dickey did reach out to me in late 2017 asking for the email I was referencing, his comment was that my response was vague, actually, my exact words were:
I will try and dig it up.  It was a very long time ago.  I think it was
related to some behaviours in libmenu.  I will try and dig back through
my mail history but it may take a bit of time.
Alas I never found the original email but looking at my commits around libmenu I would have sent that email in 1999 some time so I don't think that this is very surprising.  At the time of the reply I thought that perhaps there was some interest in actually addressing the issue but the actual fact is that all it was was a fishing expedition to provide more ammunition for an attack on NetBSD curses which is disappointing.

Getting back to the email quoted above, in the book I have create_panel() is documented as taking a WINDOW as parameter.  Though, internally, stdscr is treated as a window the books description of create_panel() does make it clear that WINDOW is expected to be the return from newwin() not just stdscr.

As for missing functions, they will be added as and when the developers have time.  A PR may guide us in what is needed first but given that NetBSD is a volunteer project the time that the developers can devote to adding new features can be variable.  We are aiming to have something that is useful and not necessarily a clone of ncurses.

Mr. Dickey makes a point about portability.  I myself have never been concerned about making NetBSD curses portable, this is not an aim that I have ever had.  I would much rather be adding new features and fixing bugs for NetBSD than struggling with the complexities of making the NetBSD curses library portable.  If others wish to do this and feed back fixes then they will be considered but in the main, portability is not a focus.

He also turns on some random gcc flags and then berates NetBSD curses for producing extra warnings.  It is difficult to determine what flags he has turned on to produce these warnings.  The NetBSD build system treats any warnings as errors and the build terminates, the NetBSD curses library builds with the standard NetBSD gcc options without issue.  Without knowing what options were uses and what defines were in effect the information that Mr. Dickey has presented is useless.  He is welcome to submit a PR using the public interface and it will be looked into.

He then notes the output differences in the wide character implementations.  Unfortunately he has not reached out to me (at least) with this information.  It would be useful to have the tools to test this issue and rectify it.  I will note that he used a rather old version of NetBSD, it would be interesting to see if these issues still exists.

We then have a snide little bit about the number of error returns and error checking.  He says "Error-checking in NetBSD curses is seen as a problem by its developers" which is absolutely untrue and uncalled for.  He seems to be forgetting at this by that, by his own admission, that NetBSD curses does not have all the functions that ncurses has so there should be less returns of status simply from that.  Even if this were not true, if we look at the ratio of ERR/OK returns per number of statements - using the numbers from his page - NetBSD curses has 12987 statements which translates to a ERR/OK return every 25 statements where as ncurses has 24566 statements which translates to a ERR/OK return ever 38 statements.  So NetBSD curses actually assigns status codes more often than ncurses.  Regardless, I view this metric as specious - simply counting returns is rubbish, look at this:

if ((x > maxx) || (y > maxy))
         return ERR;


if (x > maxx)
        return ERR;

if (y > maxy)
        return ERR;

Both do the same thing but we get double the ERR returns in the second one.  I am not saying this is what is happening but just pointing out the fallacy of counting ERR/OK assignments and trying to draw a conclusion from it without properly analysing the code.

He lambasts NetBSD for commenting out unsupported functions in pycurses, this is just a reflection of the NetBSD curses not having all the functions at the moment.  This is a pkgsrc thing and locally applied, pycurses is unique in that it wants all the curses functions so it can provide bindings, since NetBSD curses doesn't have them then the unsupported ones are commented out.  It would be ideal if they all existed, hopefully one day they will.

The final thing I would like to pick up on is the comment:

"Without documentation, there is no point in making bug reports."

Which is just a lame excuse, even the lack of documentation is something that can be a bug report.  There is a public interface for reporting bugs.  Not using it and then complaining on your own website is not helpful to NetBSD but then again, perhaps that is the intention after all.

April 08, 2020

NetBSD Blog Wifi renewal restarted

Back in 2018, Phil Nelson started a long needed WiFi-refresh, basically syncing our src/sys/net80211/ with the version from FreeBSD. He got a few things working, but then ran out of time and was unable to spend enough time on this to complete the task. I am now taking over this work, Phil hopes to join in again later this summer.

The main idea is to get better SMP (locking) support, support for newer (faster) WiFi standards, and support for virtual access points, while also making future updates (and import of drivers) from FreeBSD easier.

I have collected quite a few WiFi cards and USB dongles, but will ask for help with other hardware I don't have handy later.

I hope to have a working setup and a few working drivers by the end of this months.

Thanks to the NetBSD Foundation for funding this work! Please note that we are looking for donations again, see Fundraising 2020.

P.S.: for the curious: the first drivers I hope to have working are the ones we have already drivers for and I have hardware:

followed by things other developers can convert and have hardware (with me assisting where needed), optionally followed by some of the ones where I have hardware but we have no driver yet:

April 06, 2020 pkgsrc-2020Q1 released

April 02, 2020 NetBSD 8.2 released Extended support of the netbsd-7 branch

April 01, 2020 New Developer in March 2020

March 20, 2020

Unix Stack Exchange How to change the font size in NetBSD (TTY no GUI)

NetBSD 7.1 (GENERIC.201703111743Z) amd64

In TTY without gui , the better screen resolution is set at boot time but the font is really to small.
So how to change that

On debian dpkg-reconfigure console-setup
in grub GRUB_GFXMODE=800x600

I find wsconscfg with a example :

wsconscfg -t 80x50 -e vt100 3

but I get

wsconscfg: WSDISPLAYIO_ADDSCREEN: Device not configured

I look at man wsconscfg wsconsctl wscons wsdisplay vga etc..
All of them link to the other but I can't find a way.

March 17, 2020

Super User Most Windows-like text editor that can be used through PuTTY in NetBSD?

Please help me find an editor that behaves more like the modern Windows editors do, that I could use on a NetBSD box through PuTTY.

This includes the absense of the distinction between view/insert/append modes, basic shortcuts such as Ctrl+Left/Right to jump a word at a time, and other niceties such as perhaps Home/End and PageUp/Down moving the cursor around (in my vi they just ding).

I can live without macros because I only ever tweak an occasional setting this way, and nothing else.

pico is pretty close, but I was wondering if there are other editors that might fit this bill?

March 15, 2020

Unix Stack Exchange pkgin installation problem (NetBSD)

I just installed NetBSD 7.1.1 (i386) on my old laptop.

During the installation, I could not install pgkin (I don't know why), so I skipped it and now I have a NetBSD 7.1.1 installed on my laptop without pkgin.

My problem is "How to install pkgin on NetBSD (i386) ?"

I found this Unixmen tutorial and I followed it:

I tried :

#export PKG_PATH=""
# pkg_add -v pkgin

And I got :

pkg_add: Can't process*: Not Found
pkg_add: no pkg found for 'pkgin',sorry.
pkg_add: 1 package addition failed

I know this is a wrong command because this ftp address is for amd64 while my laptop and this NetBSD is i386. (I can't find the correct command for i386 )

I also followed instructions of, and I did

git clone

on another computer and copied the output (which is a folder name pkgin) to my NetBSD (my NetBSD doesn't have 'git' command)

and then I did :

./configure --prefix=/usr/pkg --with-libraries=/usr/pkg/lib --with-includes=/usr/pkg/include

and then :


but I got :

#   compile  pkgin/summary.o
gcc -O2    -std=gnu99    -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-sign-compare  -Wno-traditional  -Wa,--fatal-warnings -Wreturn-type -Wswitch -Wshadow -Werror    -DPKGIN_VERSION=\""0.9.4 for NetBSD-7.1.1 i386"\" -DNETBSD  -g -DLOCALBASE=\"/usr/local\"           -DPKG_SYSCONFDIR=\"/usr/local/etc\"         -DPKG_DBDIR="\"/var/db/pkg\""           -DDEF_LOG_DIR="\"/var/db/pkg\""         -DPKGIN_DB=\"/var/db/pkgin\"            -DPKGTOOLS=\"/usr/local/sbin\" -DHAVE_CONFIG_H -D_LARGEFILE_SOURCE -D_LARGE_FILES -DCHECK_MACHINE_ARCH=\"i386\" -Iexternal -I. -I/usr/local/include  -c    summary.c
*** Error code 1

make: stopped in /root/pkgin

I think this error occurs because of the dependencies. (which is mentioned in but still, don't know how to install those dependencies.

EDIT: I found "" but it still says

no pkg fond for 'pkgin', sorry


** I solved the problem by writing 7.1 instead of 7.1.1**

March 06, 2020

Stack Overflow How do I set root password for mysql 5.7 on netbsd

I'm trying to get mySQL 5.7 working on NetBSD (unix). When I try "mysql -u root" I get

ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: NO)

When I try "mysqld --initialize-insecure" I get

[ERROR] --initialize specified but the data directory has files in it.

What do I do?

March 02, 2020

Emile Heitor Let's Encrypt certificates using LEGO

This post is more like a self-reminder on how I setup automatic SSL/TLS certificate renewal on my servers.

I chose LEGO to handle my certificates renewal with Let’s Encrypt because it’s simple to use, has no dependency, great documentation and is worked on at a constant pace.

I found this and this articles very useful, but they are outdated in their use of the tls and http parameters. So here are my notes.

This procedure is Debian GNU/Linux based but I also used it pretty much as-is on NetBSD and FreeBSD, only nginx related PATHs changed.


In /etc/nginx/sites-available/default:

include /etc/nginx/sites-available/letsencrypt;

Which contains:

location /.well-known/acme-challenge {
proxy_set_header Host $host;

Check nginx.conf syntax then reload it.

$ sudo nginx -t
$ sudo nginx -s reload

Let’s Encrypt

Go to a writable directory where LEGO will write the challenges

$ cd ~/www/letsencrypt

To request and install a new certificate, first prepare nginx.conf:


listen443 ssl;
listen[::]:443 ssl;;


# ...

# for future use of the tls challenge
location /.well-known/acme-challenge {
proxy_set_header Host $host;

# ...

Then execute LEGO with desired parameters:

$ sudo lego --email="[email protected]" --domains="" --http.port :8181 --http --path=/usr/local/etc/letsencrypt run

And check / reload nginx.

If you need a multi-domain certificate, simply add multiples --domains.

To renew the certificate using the tls challenge if it expires within 30 days:

$ sudo /usr/local/bin/lego --email="[email protected]" --domains="" --tls.port :4444 --tls --path=/usr/local/etc/letsencrypt renew --days 30

Automatic renewal

$ cat bin/

cd /home/imil/www/letsencrypt
/usr/local/bin/lego --email="[email protected]" --domains="" --tls.port :4444 --tls --path=/usr/local/etc/letsencrypt renew --days 30
nginx -s reload


00 3 * * * /home/imil/bin/ >/home/imil/log/lerenew.log 2>&1

reload mail system

My mail system also uses Let’s Encrypt certificates, it is hosted on virtual machines in the same subnet as the web server, which exports /usr/local/etc/letsencrypt/ via NFS. The mail server runs NetBSD. In order to watch any modifications in the certificates directory, I use direvent, which will call a script to reload both dovecot and postfix:

$ cat /usr/pkg/etc/direvent.conf
syslog {
facility local0;
tag "direvent";
print-priority yes;

watcher {
path /usr/local/etc/letsencrypt/certificates;
event write;
command "/home/imil/bin/";
$ cat bin/

/usr/sbin/postfix reload
/usr/pkg/bin/doveadm reload

su imil -c 'echo "done"|mail -s "postfix and dovecot reloaded" imil'

direvent is started from /etc/rc.local as there’s no init script given with the package.

/usr/pkg/bin/direvent /usr/pkg/etc/direvent.conf

February 17, 2020

OS News NetBSD 9.0 released

The NetBSD Project is pleased to announce NetBSD 9.0, the seventeenth major release of the NetBSD operating system. This release brings significant improvements in terms of hardware support, quality assurance, security, along with new features and hundreds of bug fixes.

Support for the ARM architecture seems to be a major pillar of this new release.

February 13, 2020

Unix Stack Exchange Difference between `pkgin` and `pkg_*`, and which to use?

Coming from Linux land, I assumed that pkgin is some sort of higher-level frontend for pkg_add et al, something like what apt is to dpkg or yum/dnf to rpm. But pkg_add appears to handle installation from network, dependencies, as well as automatic updates (the things that on Linux would be the responsibility of the front-ends rather than the underlying package tool), so now the roles of pkgin and (what I gather are the more traditional) pkg_ tools seem a bit unclear to me. The only difference that I'm presently aware of is that pkgin does not handle installation from sources.

February 03, 2020

Benny Siegert How to do Pull-ups to pkgsrc-stable
I am part of the pkgsrc releng (release engineering) team. My main task there is handling pull-ups into the stable branch. pkgsrc creates a stable branch every three months and names it after the respective quarter – for example, the last branch was called 2019Q4. Pull-ups are tickets to “pull up” one or more commit from the development branch into the stable branch. Typical justifications for pull-ups are: security updates build fixes important bug fixes (such as when the package crashes on startup) In addition, sometimes we pull up updates to packages if they are “leaves” and stop working without regular updates.
Kimmo Suominen Updated sudo

I updated security/sudo to 1.8.31. A fix for CVE-2019-18634 is included.

Originally only versions before 1.8.26 were thought to be vulnerable. Later analysis, however, showed that versions 1.8.26 – 1.8.30 are also vulnerable.

Here’s what’s new:

January 25, 2020

Stack Overflow Alternatives to Vagrant for OS emulation/development [closed]

I am the maintainer psutil project. Since psutil supports different operating systems, I've been using Vagrant in order to to emulate them and develop on them from my Linux box. This worked flawlessly for many years (due to Vagrantfiles, which are great), but unfortunately I got to a point that Vagrant is no longer usable anymore. Problems derive mostly from the inability to mount shared folders, freezes when connecting via SSH and occasional incompatibilities between Vagrant and VirtualBox after a system upgrade. Are there viable alternatives to Vagrant? My working environment is Ubuntu and the systems I need to emulate are BSD*, MacOS and OpenSolaris (for Windows I use VirtualBox directly).

January 24, 2020

Kimmo Suominen Added patches to libxml2

I added patches to textproc/libxml2 from an upstream commit and an upstream pull request to address CVE-2020-7595 and CVE-2019-20388 respectively. Version 2.9.10nb1 includes the patches.

January 19, 2020

Kimmo Suominen Patch for HTTP Request Smuggling

I added a patch to www/nginx from an upstream commit to address CVE-2019-20372. Version 1.16.1nb2 includes the patch.

January 11, 2020

Kimmo Suominen Cherry-picked patches for ncurses

In order to reduce the number of vulnerabilities on my systems, I added some patches to devel/ncurses (and devel/ncursesw) to address CVE-2018-19211, CVE-2019-17594, and CVE-2019-17595. Version 6.1nb7 includes the patches.

January 08, 2020

Amitai Schlair NYCBUG: What is notqmail?

On Wednesday, January 8, I attended the New York City BSD User Group to present What is notqmail?, a perhaps not entirely surprising followup to my March talk. At the time, I’d been trying to avoid creating yet another qmail fork. This talk is about my failure — notqmail is alive and well — and about our success thus far.


We all use email, so we all use email servers. notqmail is software for running an email server. Someday, if we do a good job, some of the many articles about how and why to run your own will recommend notqmail.

notqmail is a community-driven fork of qmail, beginning where netqmail left off: providing stable, compatible, small releases to which existing qmail users can safely update. notqmail also aims higher: developing an extensible, easily packaged, and increasingly useful modern mail server.

Work with me

Would you personally benefit from an individualized session with an experienced, inquisitive, and empathetic conversation partner? Maybe you’re facing a challenging situation at work, a learning opportunity in some code — or both. Last week a new client went from “frustrated” to “energized” in the span of an hour. Get in touch:

Would your org benefit from a rare combination of technical coaching and impactful conversations? (Take other people’s word for it, not mine.) It’s not too late to book some time with me in 2020. Let’s talk about what fits for you.

January 06, 2020

Unix Stack Exchange Is there anything similar to CrystalDiskMark for UNIX?

If you're shopping for an SSD, you've surely seen one of those screenshots from CrystalDiskMark with a few green squares, and the 2x4 matrix with results of doing read/write tests for the given hardware:

However, I've never seen anything similar for UNIX — at most what you get is a dd for sequential read/write tests, which gives no indication on the IOPS parameters of the hardware in question.

Is there anything similar to CrystalDiskMark for UNIX to perform various read/write tests like 4KiB Q8T8 etc?

I searched and found the following items in OpenBSD ports, but they seem rather stale (to say the least — randread is still hosted on SourceForge in 2020 and BYTE magazine has reportedly ceased online publication in 2013), and none of these tools make any mention of evaluating modern SSD performance, for which you probably have to have some sort of extra code to deal with the IO queues and threads or whatnot:

December 21, 2019

Stack Overflow Rump unikernel compile successfully on a server but error on Ubuntu 19.04

I downloaded rumprun and followed the Tutorial to compile and install it.

git submodule update --init
CC=cc ./ hw

I have compiled successfully on a Ubuntu 18.04 system. When I copied the same code on that system to my system Ubuntu 19.04 to compile. It failed to compile. There were many error messages. Many of them are some warning. For example,

rumprun/src-netbsd/sys/rump/dev/lib/libbpf/../../../../sys/conf.h:129:19: error: cast between incompatible function types from 'int (*)(void)' to 'int (*)(dev_t,  int,  int,  struct lwp *)' {aka 'int (*)(long unsigned int,  int,  int,  struct lwp *)'} [-Werror=cast-function-type]
 #define noclose  ((dev_type_close((*)))enodev)
rumprun/src-netbsd/sys/rump/dev/lib/libbpf/../../../../net/bpf.c:184:13: note: in expansion of macro 'noclose'
  .d_close = noclose,
rumprun/src-netbsd/sys/rump/dev/lib/libbpf/../../../../sys/conf.h:130:18: error: cast between incompatible function types from 'int (*)(void)' to 'int (*)(dev_t,  struct uio *, int)' {aka 'int (*)(long unsigned int,  struct uio *, int)'} [-Werror=cast-function-type]
 #define noread  ((dev_type_read((*)))enodev)
rumprun/src-netbsd/sys/rump/dev/lib/libbpf/../../../../net/bpf.c:185:12: note: in expansion of macro 'noread'
  .d_read = noread,

I searched for these compiling errors but I haven't found the same bugs. I don't know why this happens. How can I do to solve this problem? Thanks for your help!

December 13, 2019

Super User NetBSD - no pkg

After full installation of latest NetBSD I'm tried to launch pkgin, but received pkgin not found, also I've got same for pkgsrc. Then I've found, that there's no /usr/pkg location.

That's normal or I've did something wrong?

December 01, 2019

Server Fault ssh tunnel refusing connections with "channel 2: open failed"

All of a sudden (read: without changing any parameters) my netbsd virtualmachine started acting oddly. The symptoms concern ssh tunneling.

From my laptop I launch:

$ ssh -L 7000:localhost:7000 [email protected] -N -v

Then, in another shell:

$ irssi -c localhost -p 7000

The ssh debug says:

debug1: Connection to port 7000 forwarding to localhost port 7000 requested.
debug1: channel 2: new [direct-tcpip]
channel 2: open failed: connect failed: Connection refused
debug1: channel 2: free: direct-tcpip: listening port 7000 for localhost port 7000, connect from port 53954, nchannels 3

I tried also with localhost:80 to connect to the (remote) web server, with identical results.

The remote host runs NetBSD:

bash-4.2# uname -a
NetBSD host 5.1_STABLE NetBSD 5.1_STABLE (XEN3PAE_DOMU) #6: Fri Nov  4 16:56:31 MET 2011  [email protected]:/m/obj/m/src/sys/arch/i386/compile/XEN3PAE_DOMU i386

I am a bit lost. I tried running tcpdump on the remote host, and I spotted these 'bad chksum':

09:25:55.823849 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 67, bad cksum 0 (->3cb3)!) > P, cksum 0xfe37 (incorrect (-> 0xa801), 1622402406:1622402421(15) ack 1635127887 win 4096 <nop,nop,timestamp 5002727 5002603>

I tried restarting the ssh daemon to no avail. I haven't rebooted yet - perhaps somebody here can suggest other diagnostics. I think it might either be the virtual network card driver, or somebody rooted our ssh.


November 25, 2019

Super User What device does NetBSD use for a USB modem?

I'm testing some software on NetBSD 8.1 x86_64. The software opens a USB modem and issues AT commands. The software tested OK on Debian, Fedora, OS X, and OpenBSD. The software is having trouble on NetBSD.

NetBSD's dmesg shows:

umodem0 at uhub1 port 1 configuration 2 interface 0
umodem0: U.S.Robotics (0xbaf) USB Modem (0x303), rev 2.00/2.00, addr 2, iclass 2/2
umodem0: data interface 1, has CM over data, has break
umodem0: status change notification available
ucom0 at umodem0

If I am parsing the NetBSD man pages properly (which may not be the case), I should be able to access the modem via /dev/ucom0. Also see UMODEM(4) man page.

The test user is part of the dialer group. The software was not able to open /dev/ucom0, /dev/umodem0, ucom0 or umodem0. All open's result in No such file or directory. Additionally, there are no /dev/ttyACMn or /dev/cuaUn devices.

How do I access the modem on NetBSD?

November 17, 2019

Stack Overflow Compile only kernel module on NetBSD

Is there a way to compile only a kernel module on NetBSD? I can't seem to figure out how to do so without recompiling the entire kernel. Thanks!

August 20, 2019

Super User How to run a Windowed JAR file over SSH without installing JRE and without root access on NetBsd?

First, I can use Java, but for what I want to achieve (building a database where othe only application supporting the format is in Java), I need 100Gb of RAM during 20 hours.

I have access to a server with the required RAM, but not as root and no JRE is available. The same is true for the Xorg libraries.

Here’s the uname :

8.0_STABLE NetBSD 8.0_STABLE (GENERIC) #0: Sun Feb 24 10:50:49 UTC 2019  [email protected]:/usr/src/sys/arch/amd64/compile/GENERIC amd64

The Linux layer is installed, but nothing else is installed : not even Glibc, so the only applications which can be run are the ones which are statically compiled.

So not only Java isn’t Installed, but some of the require shared libraries are missing…
However, I have full write access to my $HOME directory, and I can run my own executables from there.

Is a way to convert a Jar file into a NetBsd Executable or Linux statically linked executable ? I have also the source code of the Jar file if compiling is an acceptable solution.

I only found about ɢᴄᴊ, but I’m unsure if Java 7 is supported…

Amitai Schlair Announcing notqmail

Running my own email server has its challenges. Chief among them: my favorite mail-server software hasn’t been updated since I started using it in 1998.

The qmail logo
qmail logo

Okay, that’s not entirely true. While qmail hasn’t been updated by its original author, a group of respected users created netqmail, a series of tiny updates that were informed, conservative, and careful. By their design, it was safe for everyone running qmail to follow netqmail, so everyone did. But larger changes in the world of email — authentication, encryption, and ever-shifting anti-spam techniques — remained as puzzles for each qmail administrator to solve in their own way. And netqmail hasn’t been updated since 2007.

One fork per person

In the interim, devotees have continued maintaining their own individual qmail forks. Some have shared theirs publicly. I’ve preferred the design constraints of making minimal, purpose-specific, and conflict-avoidant add-ons and patches. Then again, these choices are motivated by the needs of my qmail packaging, which I suppose is itself a de facto fork.

I’ve found this solo work quite satisfying. I’ve learned more C, reduced build-time complexity, added run-time configurability, and published unusually polished and featureful qmail packages for over 20 platforms. Based on these experiences, I’ve given dozens of workshops and talks. In seeking to simplify system administration for myself and others, I’ve become a better programmer and consultant.

Still, wouldn’t it be more satisfying if we could somehow pool our efforts? If, long after the end of DJB’s brilliant one-man show, a handful of us could shift how we relate to this codebase — and to each other — in order to bring a collaborative open-source effort to life? If, with netqmail as inspiration, we could produce safe updates while also evolving qmail to meet more present-day needs?

One fork per community

My subtle artwork
notqmail logo == qmail logo overlaid by a red circle with a slash through it

Say hello to notqmail.

Our first release is informed, conservative, and careful — but bold. It reflects our brand-new team’s rapid convergence on where we’re going and how we’ll get there. In the span of a few weeks, we’ve:

I say “bold” because, for all the ways we intend to hew to qmail tradition, one of our explicit goals is a significant departure. Back in the day, qmail’s lack of license, redistribution restrictions, technical barriers, and social norms made it hard for OS integrators to create packages, and hard for package users to get help. netqmail 1.06 expressed a desire to change this. In notqmail 1.07, we’ve made packaging much easier. (I’ve already updated pkgsrc from netqmail to notqmail, and some of my colleagues have prepared notqmail RPM and .deb packages.) Further improvements for packagers are part of what’s slated for 1.08.

What’s next

Looking much further ahead, another of our explicit goals is “Meeting all common needs with OS-provided packages”. We have a long way to go. But we couldn’t be off to a better start.

By our design, we believe we’ve made it safe for everyone running qmail to follow notqmail. We hope you’ll vet our changes carefully, then update your installations to notqmail 1.07. We hope you’ll start observing us as we continue the work. We hope you’ll discuss freely on the qmail mailing list. We hope you’ll be a part of the qmail revival in ways that are comfortable for you. And we hope that, in the course of time, notqmail will prove to be the community-driven open-source successor to qmail.

July 15, 2019

Benny Siegert A Tale of Two Spellcheckers
This is a transcript of the talk I gave at pkgsrcCon 2019 in Cambridge, UK. It is about spellcheckers, but there are much more general software engineering lessons that we can learn from this case study. The reason I got into this subject at all was my paternal leave last year, when I finally had some more time to spend working on pkgsrc. It was a tiny item in the enormous TODO file at the top of the source tree (“update enchant to version 2.