My EC2 wishlist

I've been using Amazon EC2 since 2006, and I've been maintaining the FreeBSD/EC2 platform for over a decade. Over those years I've asked Amazon for many features; some of them, like HVM support (EC2 originally only support Xen/PV) and bidirectional serial console support (EC2 originally had an "output-only" serial console) eventually arrived, but I'm still waiting for others — some of which should be very easy for AWS to provide and would yield very large benefits.

While I've made engineers inside Amazon aware of all of these at various times, I think it's time to post my wishlist here — both so that a wider audience inside Amazon can hear more about these, and so that the FreeBSD community (especially the people who are financially supporting my work) can see what I'm aiming towards.

AWS Systems Manager Public Parameters

FreeBSD release announcements currently include a long list of AMI IDs — two for each EC2 region — and I would publish more AMIs if it weren't for the impracticality of putting all the AMI IDs into the announcements. One might say "there's got to be a better solution" — and indeed there is: AWS Systems Manager Public Parameters. Amazon publishes AMI IDs for Amazon Linux and Windows via the AWS Systems Manager Parameter Store, and Ubuntu AMI IDs are also published via the same mechanism (I assume by Canonical). I wrote code over a year ago to allow FreeBSD to publish AMI IDs the same way, but we can't use it until Amazon authorizes the FreeBSD release engineering account to publish these parameters — and we're still waiting.

In addition to allowing us to publish multiple AMIs (e.g. ZFS and cloud-init), if we had this then we could publish updated AMIs after every security update — using the Parameter Store to allow users to look up the latest updated version — which would dramatically speed up the process of launching new FreeBSD/EC2 instances.

Wishlist item #1: Please give the FreeBSD release engineering account access to store AWS Systems Manager Public Parameters.


A few months ago, Amazon started supporting UEFI booting on newer x86 instances. (ARM instances already used UEFI.) This is great news for FreeBSD, since we can boot much faster on UEFI than via the "legacy" BIOS boot mode — I/O is much faster since UEFI doesn't need to bounce disk reads through a small buffer in the bottom 1 MB of address space, and console output is much faster since we can use the UEFI console rather than a shockingly slow emulated VGA text mode. In fact, the total loader + kernel time (starting when the boot loader starts running, and stopping when the init process is spawned) drops from 10.9 seconds down to 3.9 seconds!

There's just one problem with this: AMIs are marked as either "legacy-bios" or "uefi", and while legacy-bios AMIs can boot on all of the x86 instance types, the UEFI-flagged AMIs can only boot on the instance types which support UEFI. FreeBSD's AMIs are built from disk images which support both boot methods — but when we make the EC2 RegisterImage API call, we have to specify one or the other. While we would love to make FreeBSD AMIs boot faster, we don't want to drop support for customers who are using older instance types.

Wishlist item #2: Please add a new "BootMode=polyglot" option, which marks AMIs as supporting both legacy-bios and uefi boot modes, with UEFI being used on instances where it is available and legacy-bios being used otherwise.

Attaching multiple IAM Roles to an EC2 instance

IAM Roles for EC2 are a very powerful — but very dangerous — feature, making credentials available to any process on the instance which can open a TCP connection to Last year, I released imds-filterd, which allows access to the EC2 Instance Metadata Service (and thereby IAM Roles) to be locked down; as a result, you can now attach an IAM Role to an EC2 instance without the risk that a user-nobody privilege escalation allows an attacker to access the credentials.

There's only one problem: You can only attach a single IAM Role. This means that — even with imds-filterd restricting what each process can access in the metadata service — there's no way to give different credentials to different processes. This becomes a problem if you want to use the AWS Systems Manager Agent, since it requires credentials exposed as an IAM Role; there's no way to use the SSM Agent and another process which also uses IAM Role credentials without them both having access to each other's privileges. This even became a problem for Amazon a few years ago when they wanted to provide "extra" credentials to EC2 instances which could be used to manage SSH host keys: Because these credentials couldn't be attached as an IAM Role, they were exposed via the Instance Metadata Service as meta-data/identity-credentials/ec2/security-credentials/ec2-instance which Amazon's documentation helpfully marks as "[Internal use only]".

As it turns out, the EC2 API already supports attaching an array of IAM Roles to an instance, and the Instance Metadata Service already supports publishing credentials with different names — but the EC2 API throws an error if the array of IAM Roles has more than one name listed in it. Get rid of that restriction, and it will become much easier to properly effect privilege separation... and also easier for Amazon to provide credentials to code it has running on customer instances.

Wishlist item #3: Allow multiple IAM Roles to be attached to a single EC2 instance.

If you work at Amazon and can make one or all of these wishes come true, please get in touch ( I really don't think any of these should be very difficult to provide on Amazon's side, and they would provide a huge benefit to FreeBSD. Alternatively, if you work at Amazon and you're screaming at your laptop "it's not that simple Colin!", please get in touch anyway (yes, I've signed the necessary NDAs).

And if you don't work at Amazon but you work at a large AWS customer: Please draw this list to the attention of your Amazonian contacts. Eventually we'll find someone who can make these happen!

Posted at 2021-06-16 01:45 | Permanent link | Comments

107 Lightbulbs

I bought a house last summer, and after moving in on October 1st, one of my first priorities was to replace all of the old (mostly incandescent) light bulbs with efficient LED bulbs. This turned into a five month saga.

Growing up, I thought that light bulbs were generally interchangeable. OK, there were fluorescent tube bulbs; but aside from that, while bulbs came in 40W, 60W, and 100W varieties, they were all the same size and screwed into the same sockets. Well, maybe that was the norm in the late 70s, but the house I bought was built in the late 90s and things definitely changed; there turned out to be no less than 14 different types of bulbs needing replacement:

If you're wondering what a house worth of assorted light bulbs looks like, here you go:

In total, replacing these bulbs cost $856.80 — but the power consumption (if I hypothetically had all the lights turned on at once) dropped from 5.8 kW down to 800 W. Based on an average 3 hours/day of usage (the Internet gives me estimates ranging from 1.5 hours/day up to 5 hours/day), the bulbs will pay for themselves in just one year — quite apart from the fact that the LED bulbs should last much longer than the incandescent bulbs they replaced.

Posted at 2021-03-04 03:20 | Permanent link | Comments

On the use of a life

In a recent discussion on Hacker News, a commenter posted the following question:
Okay, so, what do we think about TarSnap? Dude was obviously a genius, and spent his time on backups instead of solving millennium problems. I say that with the greatest respect. Is this entrepreneurship thing a trap?
I considered replying in the thread, but I think it deserves an in-depth answer — and one which will be seen by more people than would notice a reply in the middle of a 100+ comment thread.

First, to dispense with the philosophical argument: Yes, this is my life, and yes, I'm free to use — or waste — it however I please; but I don't think there's anything wrong with asking if this is how my time could be best spent. That applies doubly if the question is not merely about the choices I made but is rather a broader question: Is our society structured in a way which encourages people to make less than the greatest contribution they could?

That said, I do object somewhat to the premise of the question — specifically the statement that I "spent [my] time on backups".

On one hand, it is true: Tarsnap has been my full time job since 2006. I do occasional consulting — more in the early years than I have recently — but financially speaking that's a rounding error; it's Tarsnap which pays the bills (including allowing me to buy the house which I'll be moving into next week). On the other hand: My work on Tarsnap has extended considerably into adjacent fields.

In 2009, having had many users ask for passphrase-protected Tarsnap key files, and having determined that the current state of the art of password based key derivation was sorely lacking, I invented scrypt — and in the process, opened up a whole new field of cryptography. Sure, I was doing this because it was something I could do to make Tarsnap more secure; but it would be a stretch to place this under the umbrella of "spending my time working on backups".

In 2011, wanting to connect daemons on disparate hosts together securely, and not being happy with the existing TLS-based options, I wrote spiped. While I think it remains largely underappreciated by the world at large, I nonetheless consider it a significant contribution to computer security — and, like scrypt, while I created it to serve Tarsnap's needs, it would be a stretch to place such a general-purpose open-source tool under the narrow umbrella of "working on backups".

Around the same time, I started working on kivaloo, my high performance key-value data store. This may be the least used of all of the software I've written — I'm not aware of anyone else using it at present (although being open source software that doesn't necessarily preclude the possibility) — but I consider it to be some of my best code and I think it may become used in more niches than merely Tarsnap in the future.

Starting in 2006, and accelerating significantly after Amazon launched the "M3" family of HVM-enabled EC2 instances in 2012, I've been creating and maintaining the FreeBSD/EC2 platform. While I don't have any precise statistics on its usage, a survey last year found that 44% of people running FreeBSD in the cloud use Amazon EC2; so — despite the fact that only 22 people currently provide sponsorship for my efforts — it's clear that my work here has been productive. Again, while I was working on this because I wanted to run FreeBSD in EC2 for Tarsnap, I don't think it can be placed entirely into the category of "working on backups".

Of course, the question at hand isn't whether I've done anything useful, but rather whether this was the most useful way I could have spent these years. Judging by the reference to the Millennium Problems, I imagine that the specific alternative they had in mind was a research career; indeed, between my Undergraduate studies in number theory under the late Peter Borwein and my Doctoral studies in Oxford I might have considered seriously working on the Birch and Swinnerton-Dyer conjecture had my life taken a different path. (A very different BSD from the one with which I am currently involved!)

So why am I not an academic? There are many factors, and starting Tarsnap is certainly one; but most of them can be summarized as "academia is a lousy place to do novel research". In 2005, I made the first publication of the use of shared caches in multi-threaded CPUs as a cryptographic side channel, and in 2006 I hoped to continue that work. Having recently received my doctorate from Oxford University and returned home to Canada, I was eligible for a post-doctoral fellowship from Canada's National Sciences and Engineering Research Council, so I applied, and... I didn't get it. My supervisor cautioned me of the risks of doing work which was overly novel as a young academic: Committees don't know what to make of you, and they don't have any reputational prior to fall back upon. Indeed, I ran into this issue with my side channel attack: Reviewers at the Journal of Cryptology didn't understand why they were being asked to read a paper about CPU design, while reviewers at a computer hardware journal didn't understand why they were being asked to read about cryptography. It became clear, both from my own experiences and from advice I received, that if I wanted to succeed in academia I would need to churn out incremental research papers every year — at very least until I had tenure.

In many ways, starting my own company has given me the sort of freedom which academics aspire to. Sure, I have customers to assist, servers to manage (not that they need much management), and business accounting to do; but professors equally have classes to teach, students to supervise, and committees to attend. When it comes to research, I can follow my interests without regard to the whims of granting agencies and tenure and promotion committees: I can do work like scrypt, which is now widely known but languished in obscurity for several years after I published it; and equally I can do work like kivaloo, which has been essentially ignored for close to a decade, with no sign of that ever changing.

Is there a hypothetical world where I would be an academic working on the Birch and Swinnerton-Dyer conjecture right now? Sure. It's probably a world where high-flying students are given, upon graduation, some sort of "mini-Genius Grant". If I had been awarded a five-year $62,500/year grant with the sole condition of "do research", I would almost certainly have persevered in academia and — despite working on the more interesting but longer-term questions — have had enough publications after those five years to obtain a continuing academic position. But that's not how granting agencies work; they give out one or two year awards, with the understanding that those who are successful will apply for more funding later.

In short, academic institutions systemically promote exactly the sort of short-term optimization of which, ironically, the private sector is often accused. Is entrepreneurship a trap? No; right now, it's one of the only ways to avoid being trapped.

Posted at 2020-09-20 22:10 | Permanent link | Comments

Some new FreeBSD/EC2 features: EFS automount and ebsnvme-id

As my regular readers will be aware, I've been working on and gradually improving FreeBSD/EC2 for many years. Recently I've added two new features, which are available in the weekly HEAD and 12-STABLE snapshots and will appear in releases starting from 12.2-RELEASE.

The first of these features is automounting Amazon Elastic File System filesystems. For those of you not familiar with it, Amazon EFS is essentially NFS-as-a-service; it provides a POSIX filesystem with scalable performance, replicated across Availability Zones. To use EFS automounting, specify it in the automounter configuration and enable the automounter

# echo '/efs -efs' > /etc/auto_master 
# sysrc autofs_enable="YES"
then either reboot or start the required services
# service automountd start
# service autounmountd start
# service automount start
Having done this, any access to the path /efs/FSID (e.g., /efs/fs-01234567) will automatically and transparently mount that filesystem.

This feature is long overdue — I had intended to add this three years ago after Rick Macklem and I got FreeBSD's NFS code working with Amazon EFS — and really just comes down to a single script (/etc/autofs/special_efs) which implements the -efs automount map. That said — overdue or not, trivial or not — I think this will be a useful feature.

The second feature is the addition of ebsnvme-id and the new /dev/aws/disk tree. Users of Amazon Linux may be familiar with ebsnvme-id; this is a utility which prints information about the disks attached to EC2 "Nitro" instances (where they are exposed as NVMe devices). In particular, the ebsnvme-id tool allows you to see the EBS volume ID of EBS volumes and the "Linux device name" which was specified when the volume was attached — which is not particularly meaningful on FreeBSD, but theoretically knowing that /dev/nda1 was attached via the EC2 API as "/dev/sdh" might be useful?

The ebsnvme-id which I wrote for FreeBSD is compatible with the version in Amazon Linux but has some additional functionality: You can also ask it about "Instance Store" (aka. "Ephemeral") disks, for which it will identify the disk serial number.

Using the tool and some devd magic, FreeBSD now maintains a tree under /dev/aws/disk containing the symlinks of the forms

which point at the appropriate device nodes (typically /dev/ndaX for some value X).

I hope these new features prove useful to FreeBSD users! If you'd like to support my continuing work on the FreeBSD/EC2 platform, please consider contributing to my FreeBSD/EC2 Patreon; it's much easier to justify taking time away from my day job when it feels like people appreciate my work!

Posted at 2020-05-31 03:50 | Permanent link | Comments

My new FreeBSD Laptop: Dell Latitude 7390

As a FreeBSD developer, I make a point of using FreeBSD whenever I can — including on the desktop. I've been running FreeBSD on laptops since 2004; this hasn't always been easy, but over the years I've found that the situation has generally been improving. One of the things we still lack is adequate documentation, however — so I'm writing this to provide an example for users and also Google bait in case anyone runs into some of the problems I had to address.

A few months ago, after my System76 Galago Pro had its second experience with a dead/swelling batery, I decided that it was time to replace it. On February 15th, I ordered a Dell Latitude 7390.

This is an older model of laptop — it originally launched in 2018 — but I've always found that Dell Latitudes are well built, and this one came with a very attractive price tag: Rather than the original price of $3599 CAD ($2600 USD), Dell Canada was selling it for $1049 CAD ($750 USD). I can only assume that it was the last of their stock and they wanted to clear out that production line.

The laptop came with:

The laptop arrived on March 6th, and I made a couple upgrades:

In addition to giving me double the disk space, upgrading the disk allowed me to keep the Windows installation intact in case I ever want to put this laptop back into use running Windows.

After these upgrades, I didn't quite have my ideal laptop — I would have preferred 32 GB of RAM (Dell's specifications state that this laptop supports a maximum of 16 GB), a second disk (theoretically the "WWAN" PCIe slot can hold an M.2 2242 NVMe disk, but comments online suggest that the Dell BIOS doesn't allow SSDs in that slot) and a TrackStick — but for what I paid I really can't complain.

Installing FreeBSD

I downloaded the "memstick" image from the latest FreeBSD 12.1-STABLE weekly snapshot using my old laptop and wrote it to a USB Disk. Normally I would use a RELEASE image (which would make some later steps easier too) but a few recent changes I had made and some of the code needed to support the I2C touchpad weren't in the last release. (If you're reading this a few months into the future, use 12.2 or a later release instead of the 12-STABLE branch.)

To boot from a USB stick on the Dell Latitude 7390, I needed to press F12 when I turned the system on to enter the boot disk selection menu.

Installing FreeBSD was easy for me, as I've done it many times in the past; but I did change several defaults:

After the installation completes, I asked the installer to reboot the system and removed the USB disk.

Initial FreeBSD configuration

The first thing I did was to turn off the annoyingly loud console beep:
# echo kern.vt.enable_bell=0 >> /etc/sysctl.conf
and then I told FreeBSD to use "link aggregation" networking, failing over automatically from the wired ethernet (if connected) to the WiFi network
# sysrc wlans_iwm0="wlan0"
# sysrc ifconfig_wlan0="WPA"
# sysrc ifconfig_em0="ether MY:WI:FI:MAC:ADD:RESS"
# sysrc cloned_interfaces="lagg0"
# sysrc ifconfig_lagg0="laggproto failover laggport em0 laggport wlan0 DHCP"
provided my WiFi network credentials via /etc/wpa_supplicant.conf
and started the network (service netif restart). I want a firewall, so I enabled FreeBSD's pf with a very simple configuration:
# echo "block in all" > /etc/pf.conf
# echo "set skip on lo0" >> /etc/pf.conf
# echo "pass out all keep state" >> /etc/pf.conf
# sysrc pf_enable="YES"
# service pf start

Now for the most annoying part: Because I'm running 12.1-STABLE rather than 12.1-RELEASE (due to the aforementioned patches and recently added support fo the I2C touchpad) I couldn't rely completely on packages built by the FreeBSD Project. Instead, I needed to build two packages of kernel modules — drm-kmod and iichid — via the ports tree.

This meant:

  1. Downloading and extracting a ports tree:
    # portsnap fetch extract
  2. Building the ports:
    # make -C /usr/ports/graphics/drm-kmod install clean BATCH=YES
    # make -C /usr/ports/sysutils/iichid install clean BATCH=YES
  3. And locking those packages to ensure that they won't be "upgraded" automatically to versions compiled on FreeBSD 12.1-RELEASE:
    # pkg lock -y -g '*kmod*' iichid
If I had been able to install 12.2-RELEASE (which does not exist yet at the time I am writing this), those steps would simply have been pkg install iichid drm-kmod.

Now that I had those packages in place, I could download the other ones I needed to get a basic GUI running:

# pkg install xorg kde5 sddm

And then do some basic configuration to turn on the GUI:

At this point I could reboot and watch my laptop boot into a GUI where I logged in as cperciva, opened a console (Ctrl-Alt-T), and used su to become root so I could do more configuration.

More FreeBSD configuration

The BIOS on the Dell Latitude 7390 configures the speakers and headphone jack as being independent audio outputs. This isn't what I want — I want to have sound go to the speakers by default but switch to the headphone jack and mute the speakers automatically if I plug in headphones. To do this, I told FreeBSD that the headphones (which are nid33 on this laptop) are part of the same audio set (as=1) as the speakers but should use mute-and-switch-to-headphones behaviour (seq=15):
# echo 'hint.hdaa.0.nid33.config="as=1 seq=15"' >> /boot/loader.conf
Speaking of audio, there's a bug in the HDMI codec which results in annoying warnings ("Unexpected unsolicited response with tag 63" and "Command timeout on address 2") being logged to the kernel console. Ed Maste has been working on fixing the underlying issues, but he provided a workaround which let me silence the warnings:
# echo 'compat.linuxkpi.i915_disable_power_well="0"' >> /boot/loader.conf
My preferred (KDE) environment doesn't need D-Bus for much, but one place it is needed is to allow the GUI tools to see the battery state and interact with power management:
# sysrc dbus_enable="YES"
CPU bugs often get fixed via microcode patches, so I want to have those:
# pkg install devcpu-data
# echo 'cpu_microcode_load="YES"' >> /boot/loader.conf
# echo 'cpu_microcode_name="/boot/firmware/intel-ucode.bin"' >> /boot/loader.conf
I want my laptop to boot faster — which means not having the boot loader wait 10 seconds in case I want to change how I boot, and not having the FreeBSD kernel wait for USB devices before mounting the root filesystem (I know that my root filesystem is on the NVMe disk):
# echo 'autoboot_delay="0"' >> /boot/loader.conf
# echo 'hw.usb.no_boot_wait="1"' >> /boot/loader.conf
As mentioned above, I like to use qmail rather than sendmail; I also use spiped to tunnel email to and from my mail server:
# pkg install netqmail ucspi-tcp spiped
# echo `hostname` > /var/qmail/control/me
# echo ":" > /var/qmail/control/smtproutes
# rm /var/qmail/alias/.qmail-*
# echo cperciva > /var/qmail/alias/.qmail-default
# cp /var/qmail/doc/mailer.conf.sample /etc/mail/mailer.conf
# sysrc qmailsend_enable="YES"
# sysrc qmailsmtpd_enable="YES"
# sysrc qmailsmtpd_host=""
# echo "" > /etc/tcp.smtp
# sysrc spiped_enable="YES"
# sysrc spiped_pipes="SMTP POP3"
# sysrc spiped_pipe_SMTP_mode="client"
# sysrc spiped_pipe_SMTP_source="[]:8025"
# sysrc spiped_pipe_SMTP_target=""
# sysrc spiped_pipe_SMTP_key="/etc/spiped/smtp.key"
# sysrc spiped_pipe_POP3_mode="client"
# sysrc spiped_pipe_POP3_source="[]:110"
# sysrc spiped_pipe_POP3_target=""
# sysrc spiped_pipe_POP3_key="/etc/spiped/pop3.key"
And finally while the webcam daemon is installed already (the kde5 package pulls it in as a dependency) I want it to be enabled and I want the cperciva user to be able to access it:
# echo 'cuse_load="YES"' >> /boot/loader.conf
# sysrc webcamd_enable="YES"
# pw groupmod webcamd -m cperciva

Desktop configuration

At this point I had a fully functional desktop environment, but it wasn't set up exactly how I wanted. I don't like the default KDE wallpaper, so I installed new wallpaper
# pkg install wallpapers-freebsd-kde
and told KDE to use it (right click on desktop; "Configure Desktop"; scroll down and select the right wallpaper).

I want to be able to print from within KDE, so I enabled CUPS (which was already installed as a KDE dependency) and started it (necessary since I wanted to use it without rebooting):

# sysrc cupsd_enable="YES"
# service cupsd start
and then told KDE about my printer ("System Settings" -> "Printers" -> "Add Printer"; manual URI of and the Generic PostScript Printer driver).

I want to be able to control the brightness of the screen (aka. the backlight connected to the Intel video chipset):

# pkg install intel-backlight
and in particular to be able to control it via the function keys (Fn+Up, Fn+Down) which Dell exposes via ACPI:
# echo 'acpi_video_load="YES"' >> /boot/loader.conf
# cp /usr/local/share/examples/intel-backlight/acpi-video-intel-backlight.conf \

There's a long list of software I want to be able to use (or in some cases, would prefer to avoid, but need nonetheless):

# pkg install firefox libreoffice thunderbird chromium
# pkg install nano konversation
# pkg install xournal ImageMagick7 pdftk
# pkg install texlive-full
# pkg install git subversion diffstat portlint sloccount
# pkg install autoconf autoconf-archive automake libtool
# pkg install base64 wkhtmltopdf
# pkg install tarsnap

And finally I want to perform hourly backups to Tarsnap — but in the background, and not spinning up the CPU to perform them (line wrapping added in the first line to avoid breaking web browsers):

# echo '47 * * * * root nice /usr/local/bin/tarsnap -c --keyfile /root/tarsnap.key
    -f `date +\%Y-\%m-\%d:\%H` /root /etc /usr/local/etc /usr/home' > /etc/cron.d/tarsnap
# sysrc powerd_flags="-N"

KDE configuration

Like most desktop environments, KDE has a myriad settings which can be adjusted, and I change many to match my personal taste, ranging from the Application Launcher (I prefer the "menu" version) to the keyboard shortcuts for changing desktops (I use Meta+Tab for this, since I don't make use of KDE "Activities").

The one particularly noteworthy option I set is to tell KDE to "Sleep" when the laptop lid is closed; in combination with the (default) setting to lock the screen when sleeping, this gives me a convenient way to "put the laptop away" when I don't want to shut it down completely. (Note however that it is unable to "Hibernate" since FreeBSD does not have the necessary support for Suspend-to-Disk.)

Current status

So where are we at now? Here's a short summary:

After the above installation and configuration — which took 75 minutes, mostly spent downloading 4 GB worth of packages — there's just one things left to do: Copy all my data across from my old laptop.

What didn't work the first time

While the above installation and configuration process all worked in the end, it wasn't nearly as smooth the first time — or the second time, or the third time. Some of the issues I ran into:


Is FreeBSD ready for the desktop? Yes and no. Yes, in that I have a very nice FreeBSD laptop where everything works the way I want. But no, in that it took me two months worth of fiddling with this in my spare time to fix some of the "glitches" which arose; while there wasn't anything particularly challenging, I expect that most people would give up long before they fixed all of the issues I ran into.

On the other hand, can FreeBSD be ready for the desktop? Absolutely. I've fixed the issues I ran into — and once we have FreeBSD 12.2-RELEASE with packages built for that release the process of bringing up a GUI will be much easier, as well. The biggest thing FreeBSD needs is to have developers acquiring laptops and carefully working their way through the issues which arise; the FreeBSD Foundation has already started doing this, and I hope in the months to come they — and other FreeBSD users — will publish reports telling us which laptops work and what configuration they need.

Posted at 2020-05-22 01:20 | Permanent link | Comments

Recent posts

Monthly Archives

Yearly Archives