Poorly-worded codes of conduct

Below is the actual text (minus personally identifying information) that I have sent to the FreeBSD team for consideration.

To: conduct@freebsd.org
From: A. Wilcox
Subject: Violation
Date: Mon, 19 Feb 2018 22:20:21 -0600
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0

Hello FreeBSD team,


My name:
A. Wilcox
[alt emails redacted]


Names of those involved:
A. Wilcox
IRC nicks: [redacted]


When and where the incident occurred:
2014-2016 on IRC, possibly 2017 in email traffic


Your account of what occurred:
I hugged a great many people.  Some were group hugs of celebration (we
fixed a bug!  *hugs*).  Some were hugs of consolation, like the loss of
a loved one.  Some were hugs to and from those I had not communicated
with in a great number of years.

There may have been some on mailing lists as well.  I am not very sure,
as that is not typically something I do on mailing lists (it is more of
a live / chat thing), but it is possible.  Likely, even, if you include
private traffic between me and some of the regulars that used to hang
out together all the time.


Any extra context:
This CoC is demeaning and insensitive to people like me who have
emotional disabilities and need to give and receive hugs (at least
virtually) to feel better, and has a chilling effect on discussion due
to poorly defined word choices.

For instance: why does it only ban "gratuitous" sexual images, but
typing a hug is an immediate violation?

Are truthful comments between two people that care that maybe they
should live a healthier lifestyle "unwelcome"?  I had a very long and
blunt talk with someone on IRC about their drug use, and they are now
years sober partially due to that "unwelcome" discussion.

In addition, making so many explicit bullet-points invites rule
lawyering, trolling about what is and is not a rule violation, and
leaves so many things up to interpretation as to be unhelpful.

I wish to be banned from this community so I am not tempted to
contribute to it again, as the CoC is almost as toxic as the behaviour
it is trying to prevent.


Is the incident ongoing:
Until the CoC is rewritten; yes.


Any other information you should have:
Yes, better CoCs that are not offensive, insensitive, demoralising, or
demeaning:

* https://www.djangoproject.com/conduct/

* https://www.alpinelinux.org/community/code-of-conduct.html


Sincerely,
--arw

--
A. Wilcox (awilfox)

The Joys of Unix Programming: MAP_ANON(YMOUS)

I was trying to do a little late-night hacking last night on SuperGameHerm, the Game Boy emulator my friends and I are writing, and I hit an error in the memory mapper. Specifically, certain OSes that used to be named after cats don't like calling mmap on /dev/zero (neither does Android). I thought it was odd that it was falling back to that code in the first place, though, because Apple's Mac OS X — I mean, certain cat themed OS — has always supported MAP_ANON, and I confirmed that by going to man mmap on a Mac.

What was going on? I dug deeper and saw MAP_ANON was guarded in sys/mman.h, so CMake wasn't finding it and it was instead compiling our fallback code. And so I started digging up other issues related to big endian machines and realised that I had only tested OS X and FreeBSD on big endian, and never tested OS X or FreeBSD on little endian. So was my big mistake.

This is a comprehensive guide to How to Make MAP_ANON(YMOUS) Visible, for every OS I could find information on:

Mac OS X

On 10.3 and below, this is easy; it's always there! It is not guarded by any #ifdef.

On 10.5 and above, it is slighly harder; you must define _DARWIN_C_SOURCE to cause MAP_ANON to be visible in a public scope.

On 10.4 only, it's much harder! It is only protected by #ifndef _POSIX_C_SOURCE, so to use MAP_ANON against the 10.4 SDK, you must completely undefine _POSIX_C_SOURCE. You don't have any other choice.

I suppose that means my overall advice then is to use the 10.5 SDK no matter what, if you have a Leopard computer handy, because it can target as low as 10.0. Otherwise, use the Panther SDK included with Tiger's Xcode Tools. Don't ever use Tiger's SDK if you want MAP_ANON.

FreeBSD

Before 5.0, it's always visible, just as in OS X 10.3. There are no preprocessor options to show or hide MAP_ANON.

On 5.0 or above, the only way to cause MAP_ANON to be visible is to define __BSD_VISIBLE somewhere. Undefining _POSIX_C_SOURCE won't save you here.

Other BSDs (NetBSD, OpenBSD, DragonFly BSD)

It's never guarded. MAP_ANON is always available.

Solaris

I could only get my hands on OpenSolaris, but considering the header having a copyright date of 1989 (by AT&T), I can't imagine it's any different on Real Solaris (or Oracle Solaris). There are no guards here, either; that's to be expected since they invented the damn thing.

Linux

glibc: I don't understand /usr/include/bits in the slightest. It seems to be always available no matter what options I toss to clang, but it is guarded by.. __USE_MISC? I presume this is some sort of feature macro buried deep in glibc that I don't care about or understand.

musl: It's always available, at least on 1.1.11 which is what I have on my test box.

Android: After searching through their spaghetti of includes to get to the actual file that defines constants, it appears they are all completely unguarded, though that isn't surprising since it is Linux and embedded.

In conclusion

Perhaps it's best to avoid anonymous mmap(2) in applications that you want to actually be portable.

FreeBSD on Apple MacBook Pro 8,2: Epilogue.

It is with a fairly heavy heart that I write I am no longer running FreeBSD on my MacBook Pro.

What happened to improving?

Part of the problem is that I finally received gainful employment in March, and that work is almost impossible to do on FreeBSD. A lot of it involves Chrome (which I still have been unable to run on FreeBSD), Qt5-based applications (which crash due to known bugs in libv8 that Google do not care to resolve), and some Python libraries that have truly terrible performance on FreeBSD.

Why not run Linux in a VM for work?

Sure, I could have, if VirtualBox ever worked...

Weren't you excited to fix up FreeBSD?

I was. I still am, but something just feels different. For over a decade, FreeBSD has for me been the go-to operating system for any use case: servers, embedded projects, desktop systems, and more. But the current heading of development seems to strongly suggest this is no longer encouraged or desired.

When I first started out with Gentoo nine years ago, they were pretty much bent on making it for newer hardware only. Back then, Pentium computers were like the Pentium 4s of now - something you give your grandma or little sister for web browsing, but nothing too serious. And Gentoo developers did not really care if they broke compatibility with these older systems. I can understand that, given that compiling the entire system by hand is something that is pretty taxing for older hardware.

The nice thing about FreeBSD was their community never looked down on you for using these older machines, and realised they still have use. My first interactions with #FreeBSDHelp on EFnet were in 2006 and related to getting SLIP support working in sysinstall so I could remotely install FreeBSD 6 on my Pentium 90 laptop. They were happy to help.

The roles have largely reversed now. Running into issues with older hardware get me looks of disdain and "great, upgrade your hardware and try again" from the FreeBSD community. Meanwhile, the Gentoo team was happy to help me with an issue regarding my retro Intel486 box, in 2015. This computer has no business still functioning, and they were still willing to help me configure a kernel that would boot on it with its anaemic 20 MB RAM.

The other thing I have noticed is that even now, months later, none of my Ports bugs have been handled. In the same amount of time, I have filed three bugs against Portage packages... and all of them were closed within one week of being opened. I feel like my contributions matter to the Gentoo Linux team.

What have you learned?

FreeBSD is more fun to hack on than Gentoo. FreeBSD is harder to get things done on than Gentoo.

FreeBSD is lighter on resources than Gentoo. FreeBSD is heavier on bug backlog than Gentoo.

Ports updates for FreeBSD: Minecraft, HFS reading, and more…

I have been spending my time lately doing some maintenance with Ports, updating and fixing the software packages I use. I've submitted a couple of PRs to the FreeBSD team and hopefully my changes will be merged very soon.

Minecraft (games/minecraft-client)

The minecraft-runtime script wasn't working, and the JAVA_VERSION was, in my opinion incorrectly, bumped to 1.8 when it runs perfectly well on 1.7. I have submitted PR 197063 to rectify these issues, and additionally more correctly replace variables in the script templates.

HFSExplorer (sysutils/hfsexplorer)

The current version in Ports no longer exists on SourceForge, as they have moved to GitHub. With the move came a new release that brings some new features and enhanced compatibility. I have submitted PR 197209 to update the distfile location and version.

LWJGL (games/lwjgl)

This library, used by Minecraft, does not currently build with openjdk8. I am currently ironing out this bug so that I can submit a patch either upstream or to FreeBSD (or perhaps both), whichever one is necessary. I'll note further progress on this here on my blog.

Symbola (x11-fonts/symbola)

Elly has submitted PR 197090 to add the Symbola Unicode 7.0 font to FreeBSD. Look for this coming soon.

An article about more MacBook stuff is coming shortly, but for now I'm still working out some issues. Until then, happy hacking everyone!

FreeBSD on Apple MacBook Pro 8,2: Now with more features

As an update to my last post, I have been able to make more of the features of my 13" Late 2011 MacBook Pro work on FreeBSD 11.0-CURRENT.

Sensor Readings.

Simple: kldload coretemp. To have on boot, add coretemp_load="YES" in /boot/loader.conf.

Cool Temperatures and Power Saving.

You will need to ensure i915kms is loaded and add drm.i915.enable_rc6=7 to your /boot/loader.conf. This was pointed out by the FreeBSD wiki which I could not find, so thank you Elly for helping me find these docs.

Additionally, you can add hw.pci.do_power_nodriver=3 to power down unused PCI cards. They re-enable when you kldload the modules, so this will help if you do not use the SD card reader or FireWire port very much.

Touchpad Gestures.

The atp(4) driver is flaky, but does work. Just add atp_load="YES" to /boot/loader.conf. Two fingers = right-click, three fingers = middle-click. Three finger tap is somehow hilariously much more reliable than two fingers, but with a little persistence they work. Two-finger scroll is a bit wonky and scrolls at unpredictable speeds, but I have a feeling this is a sysctl that may be fixable.

Bluetooth.

This actually does work right out of the box. I can pair with my phone and use the nifty obexapp utility to transfer files to my Android phone, an HTC One (M8). Unfortunately I was unable to transfer any files or pictures from the phone; obexapp consistently reported "0 bytes streamed in 2 seconds". I think it may be a permissions error as I able to upload files to my phone's Download/ directory correctly but no other directory.

To establish a Bluetooth connection (with an Android phone at least), you have to do the following:

1. Add your phone to /etc/bluetooth/hcsecd.conf. The examples are quite good. Remember your PIN.
2. Enable hcsecd in /etc/rc.conf and set flags to ubt0.
3. Enable sdpd in /etc/rc.conf.
   Your /etc/rc.conf should now have at least the following lines:

   hcsecd_enable="YES"
   hcsecd_flags="ubt0"
   sdpd_enable="YES"
   

4. Start both services...
   

   /etc/rc.d/hcsecd start
   /etc/rc.d/sdpd start
   

5. Now run obexapp -a phone:bluetooth:mac -C FTRN. Your phone will ask you for the PIN you specified in /etc/bluetooth/hcsecd.conf. Enter it, and you can see files on your FreeBSD computer!

Some More Bumps.

With all of these things fixed, I have had two more snags. One was that my tilde key (the ~ next to the 1 key) on my MacBook's internal keyboard was not working. This was fixed by adding the following line to ~/.xmodmaprc and running xmodmap ~/.xmodmaprc:

keycode 94 = grave asciitilde

My other new bump is that when I plug in headphones, the sound still comes out of the external speakers (and there is no sound in the headphones). This is probably due to some weirdness in the Apple HDA and I will have to take a closer look at this.

In conclusion, I am still quite happy with this change and am looking forward to fixing the rest of these issues.

FreeBSD 10.1 on UltraSPARC Sun Ultra 60: Booting and initial packages

As noted in my previous article, my friend Madeline and I set out yesterday to fix my Sun Ultra 60's boot problems so that it could run FreeBSD. The issue ended up being that the disk alias in OpenBoot had been scrambled (probably from the NVRAM reset I did to force it to boot), and was reading from a SCSI target that did not exist. I fixed this and it instantly booted up FreeBSD!

Now comes the fun part. I would really like to use pkg-ng and avoid building packages on a 360MHz computer if at all possible. Even though the UltraSPARC-II's 360MHz is closer to an Intel's 800-1000MHz, it's still a pretty poor platform for compiling some of the things I plan to use on it. I would like to run things like CMake and the new Clang 3.5 vs the very old, broken GCC 4.2.1 that FreeBSD on sparc64 ships.

I plan on setting up a buildbox on amd64 that will cross-compile ports for sparc64. There is only a single reference I can find for setting up such a system, and the instructions aren't too clear to me, so I will be writing up my experiences. For now, I have built ports-mgmt/pkg from source and it works. Unfortunately FreeBSD runs no mirrors, so I will have the "honour" of setting up my own local pkg mirror. If I'm able to make it work and compile enough useful ports I may make it public.

FreeBSD 10.1 on UltraSPARC Sun Ultra 60: The adventure begins

Today begins a new adventure for me. After trying to like Solaris 8 and finding it too old, and trying to like Solaris 11 and finding it too Enterprisey EnterpriseWare™, and unsuccessfully trying to boot Linux plenty of times, I am going to install FreeBSD 10.1 on my Sun Ultra 60. Some specs...

• UltraSPARC-II 360MHz (supposedly equivalent to a Pentium III, which at the time was huge)
• 512MB RAM (again, at the time it was released, this was more than anyone would ever need)
• 18.6GB Fujitsu SCSI disk, which doesn't give me a whole lot of room but is sufficient (I've run FreeBSD 9 on a P4 with a 20GB disk, with KDE and X, so...)
• Creator 3D UPA graphics - full 1080p, with 3D and 2D acceleration - in 1999.
• OpenBoot 3.31

You may be asking why I would use this computer. I have a few reasons. One is that I love utilising different CPU architectures and computers for what they do best. I'm thinking about playing around with some older graphics demos and seeing what I can get OpenGL/SDL2 to do with this. Considering that at the time it was 10x more powerful than any PC around, it may be enough to get some small-ish demos running at good speed. Another reason is that it's just a fun project, and another big-endian architecture besides PowerPC that I can use for endianness testing. I also am looking forward to porting SuperGameHerm to the SPARC architecture if I am able.

I'll be blogging about using and maintaining this system as I continue to use it, but for now, some installation notes!

Booting the System.

This computer is notoriously fickle to boot. I had to hold the STOP+N keys to clear the NVRAM to be able to see video at all. STOP+D is also a useful key combo, as it turns on the POSTs and ensures all the devices are working properly. All devices passed in my unit, so I proceeded at the OpenBoot "

ok

" prompt to type boot cdrom and watched the system boot up.

Booting the Kernel.

I watched with glee as the system booted the FreeBSD 10.1 kernel, but the glee quickly turned to dismay as I saw...

cd0: cd present [269120 x 2048 byte records]
Trying to mount root from cd9660:/dev/iso9660/10_1_RELEASE_SPARC64_CD [ro]...
warning: no time-of-day clock registered, system time will not be set accurately
|

No disk activity. The CD drive was quiet. The fans weren't even spun up, so there was no CPU activity. It was quiet... Too quiet... Eerily quiet for what was supposed to be a noisy, happy FreeBSD install. I pressed STOP+A to try and break into OpenBoot. The system was locked solid and it would not respond. Fortunately, it seems to be a glitch, and resetting the system (power down and power up) fixed this issue.

Installing the FreeBSD.

Since the Linux install failed and I already saved the contents of the SPARC slices, I used the Automatic Disk partitioning, which created a 17 GB / and 800 MB swap slice. This should be enough for most builds. It may not be enough for Qt, but I will probably not build Qt on here anyway. Now the fun part: Installing the distributions (somewhat akin to package sets on Linux, I guess). I downloaded the full Disc 1 ISO and burned it to a CD so I did not have to configure the network or wait for the - sadly only 10Mbit - Happy Meal Ethernet to download any files. It verified the checksums and immediately began installing to my local disk drive.

Note that I saw a few odd errors: "sym0: unexpected disconnect". This didn't seem to affect the installation any, so I'm not sure what exactly is going on here.

After that was finished, it was time to set up the devices. I configured networking (v4 + v6), added users for myself and my partner in crime, and then set out to install pkg-ng, the FreeBSD package management tool that makes FreeBSD so amazing and easy to use. Sadly, it does not support SPARC64, only the Intel x86 family of systems. The first order of business, then, is making a pkg-ng server for myself. I will cover that later, when I'm able to get that going. For now, it's ports (building from source) only.

Booting into the FreeBSD!

And now, everything is finished. Eject the CD and reset the system. This is going to be wonder----ful?

Luckily, one of my friends is an experienced SPARC sysadmin so she is going to help me fix it. Later today I will post the resolution, but first we have to find it. Until then, happy hacking!