This page is a blog mirror of sorts. It pulls in articles from blog's feed and publishes them here (with a feed, too).
The sixth Reproducible Builds Summit took place exactly two months ago in Venice, Italy. These three days of workshops were filled with a succession of interactive sessions, where everyone attending had the opportunity to present or learn about anything related to Build Reproducibility. This included the status of specific Open Source projects, techniques to locate, analyse, and understand issues, or also how to explain and communicate better around this topic.
But what is this about?
Reproducible Builds are a set of software development practices that create an independently-verifiable path from source to binary code.
Why is this important?
Anyone may inspect the source code of Free and Open Source Software for correctness or vulnerabilities. However, most software is distributed pre-compiled, with no method to confirm whether it actually corresponds to the source code published. This allows attacks in a number of different situations, from a malicious developer to network attacks, or the compromise of build infrastructure.
What can be done about it?
The purpose of Reproducible Builds is therefore to allow the verification that no vulnerabilities or backdoors have been introduced during the compilation process. By promising identical results for a given source, Build Reproducibility allows multiple third-parties to compare “correct” results, and to flag any deviations as suspect and worthy of scrutiny.
How is NetBSD doing in this regard?
The base system of NetBSD can be built reproducibly since its 8.0 release! It can be enabled in mk.conf when building NetBSD for instance.
And in pkgsrc?
A first step has been implemented, when using GCC on NetBSD to build packages. Some important tools have been packaged, such as diffoscope. However, further aspects of build reproducibility are not covered in pkgsrc yet, and we welcome contributions to improve this situation! This would help bring this additional security mitigation to the NetBSD community as well as to other systems and users of pkgsrc.
Summary and conclusion
If not already, you should definitely consider Build Reproducibility for your environment or software projects. It also applies to firmware, when sources are available. Thankfully NetBSD offers this ability for the base system already, but more work is required for packages.
As for myself, it was an honour and a pleasure to attend the Summit, keep in touch with the community, participate to the event, learn from everyone attending, and obviously to represent the NetBSD Foundation there. I am looking forward to the next Summit, which should take place in Hamburg from October 30th to November 2nd of 2023.
In the meantime, do not hesitate to get in touch, including to the NetBSD Foundation or to the pkgsrc community specifically, if you want to get involved with any aspect of Build Reproducibility or represent the NetBSD or pkgsrc projects for the Reproducible Builds community.
After nearly 3 whole years of development (work started on NetBSD 10 in late 2019), BETA snapshots have finally been published for interested users to test. More changes will be backported from the development branch over the next few months before we tag a final release, so the BETA images will keep getting updated.
What to expect
While NetBSD 10.0 is expected to be a major milestone on performance, especially on multi-core systems, currently the BETA builds have some extra kernel diagnostics enabled that may reduce performance somewhat.
Among the features you can expect to find in NetBSD 10 are reworked cryptography, including compatibility with WireGuardⓇ, automatic swap encryption, new disk encryption methods, and CPU acceleration in the kernel. In hardware support, there are updated GPU drivers from Linux 5.6, support for more ARM hardware (including Rockchip RK356X, NXP i.MX 8M, Amlogic G12, Apple M1, and Raspberry Pi 4), support for new security features found in the latest ARM CPUs, and support for Realtek 2.5 gigabit and new Intel 10/25/40 gigabit ethernet adapters. compat_linux has been ported to AArch64 and DTrace has been ported to MIPS. For retrocomputing enthusiasts, there's improved multiprocessor support on Alpha, and more iMac G5 support. The Xen hypervisor support has received a major rework. There are various new userspace programs, including blkdiscard(8) to manually TRIM a disk, aiomixer(1) to control audio volume, realpath(1), and fsck_udf(8). And loads more...
There are many little details that might be relevant to admins when upgrading from NetBSD 9, so wait and read the final release announcement before you upgrade any production systems. Please note that networking setups using tap(4) as a bridge endpoint must be modified to use vether(4) instead, and compat_linux is no longer built into the kernel for security reasons (load it as a module instead). DisplayPort and HDMI audio is now enabled in the default x86 kernel, so you might need to change the default audio device with audiocfg(1) if you're not getting any sound output. blacklistd(8) was renamed to blocklistd(8).
Downloads
- Installation / USB stick image for 64-bit x86 (hybrid UEFI/BIOS image). Use gunzip and dd to write an .img.gz file on Unix, or Rawrite32 on Windows.
- Installation / USB stick image for 64-bit x86 (legacy BIOS only)
- Installation / USB stick image for 32-bit x86
- For images for various ARM devices, see armbsd.org. All Arm boards without UFEI or Raspberry Pi firmware also require U-Boot to be written the SD card separately when using a generic image.
- Live image for Raspberry Pi 0 or 1
- Live image for Cavium Octeon (also needs U-Boot)
- CD/DVD image for 64-bit x86 (for actual CD/DVDs and virtual machines only)
- CD/DVD image for 32-bit x86
- CD/DVD image for 64-bit Arm virtual machines
- CD/DVD image for SPARC64
- CD/DVD image for Alpha
- More? (e.g. Apple PowerPC/68K, Amiga, Dreamcast, PA-RISC, SGI MIPS, SPARC32, VAX...)
Packages
Third-party software is available from pkgsrc, as ever. Binary packages are available for amd64, and I hope to publish binaries for i386 shortly.
Reporting bugs
Support for running NetBSD on Oracle Cloud Arm-Based Compute Instances has been added to NetBSD -current.
A build of NetBSD/evbarm64 after 2022-10-15 will generate a bootable image (arm64.img.gz) that can be converted to a Custom Image that can run on Oracle Cloud.
To get started, the image needs to be converted to QCOW2 format:
$ gunzip arm64.img.gz $ qemu-img convert -f raw -O qcow2 arm64.img netbsd.qcow2
Next, upload the image to an Oracle Cloud storage bucket.
Once the QCOW2 file has been uploaded, switch to Compute / Custom Images and click Import image. Set an image name, make sure the Operating system field is set to Linux, and select the bucket and object name for your uploaded image. Make sure to select QCOW2 as the Image type. Set the mode to Paravirtualized mode.
After the image is imported, click Edit details and clear all checkboxes except for VM.Standard.A1.Flex. You could also try BM.Standard.A1.160 (bare metal instance) but this is untested. Once the compatible shapes have been updated, click Save changes.
Now click Edit image capabilities, and under the Firmware heading, uncheck BIOS and click Save changes.
Finally, to create an instance, click the Create instance button. Make sure to either provide SSH keys, or download the generated private key in the Add SSH keys section. Click the Create button to start the instance.
The Instance details page will assign you a public IP address. Once the instance has started, you can ssh to it with the SSH key used during image creation as user opc.
$ ssh -i ssh-key-2022-10-15.key opc@x.x.x.x
Last login: Sat Oct 15 18:50:51 2022 from y.y.y.y
NetBSD 9.99.101 (GENERIC64) #9: Sat Oct 15 15:35:49 ADT 2022
Welcome to NetBSD!
This is a development snapshot of NetBSD for testing -- user beware!
Bug reports: https://www.NetBSD.org/support/send-pr.html
Donations to the NetBSD Foundation: https://www.NetBSD.org/donations/
-- UNSAFE KEYS WARNING:
The ssh host keys on this machine have been generated with
not enough entropy configured, so may be predictable.
To fix, follow the "Adding entropy" section in the entropy(7)
man page and after this machine has enough entropy, re-generate
the ssh host keys by running:
sh /etc/rc.d/sshd keyregen
instance-20221015-1520$ sysctl machdep.dmi
machdep.dmi.system-vendor = QEMU
machdep.dmi.system-product = KVM Virtual Machine
machdep.dmi.system-version = virt-4.2
machdep.dmi.chassis-vendor = QEMU
machdep.dmi.chassis-type = QEMU
machdep.dmi.chassis-version = virt-4.2
machdep.dmi.chassis-asset-tag = OracleCloud.com
machdep.dmi.processor-vendor = QEMU
machdep.dmi.processor-version = virt-4.2
machdep.dmi.processor-frequency = 2000 MHz
Prologue
When I bought my house in 2004 I went shopping for a outside thermometer - and ended up with a full weather-station instead (a WS2300). When I unpacked it I found a serial cable inside...
Long story short - I was still in the process of recabling the house (running ethernet to every room) and added a serial cable from the machine room to the WS2300, and then did some pkgsrc work and got misc/open2300 and misc/open2300-mysql. I used those to log the data from the weather-station to a mysql database, and later moved that (via misc/open2300-pgsql) to a postgres database.
Now sometime this year the machine running that database had to be replaced (should have done that earlier, it was power hungry and wasteful). The replacement was an aarch64 SoC (a Pine64 Quartz64 model A) - and it had no real com ports (of course) any more. I had experimented with USB serial adapters and the WS2300 before, but for unclear reasons this time I had no luck and couldn't get it to work. Since some of the outdoor sensors of the old weather-station had started failing, I decided to replace it.
New Weather-Station, new Sensors
I picked a WS3500 because it comes with a nice remote sensor arrangement:
I attached it to a satellite dish mount about 1.2m above my garage and ran a two wire cable through the mount to supply it with 3V and get rid of any batteries. It does not have a connector for that, but the battery compartment had enough space for a 330µF elco and soldering that and the cable directly to the battery contacts was easy.
The sensors report to the weather-station via a proprietary protocol in the 868 MHz band.
New Weather-Station, new Reporting
The weather-station can connect to a wifi network but does not offer any services itself. The app used to configure the station offers several predefined weather collection services.
I found the idea a bit strange to have my local weather data logged to some server somewhere else in the cloud and then get it back via my browser, but for others this is a good thing. I found this article that describes exactly the remote-only, no machines required on-site setup. I used that article as inspiration for the data collection (but that part turned out to be quite trivial, see below) and copied a lot of the presentation site from it (also more details below).
So in my setup I created web servers on two dedicated ports of my tiny machine running the postgres server. One is used by the weather-station for reporting the data, the other is used to query the database.
The configuration of the weather-station for a custom server was easy:
I tested the ecowitt protocol first. It uses a post to a fixed URL and the form data has nearly identical data as we get with the solution I ended up with - only a few names (of form fields) are slightly different.
The blacked items "StationID" and "StationKey" appear verbatim in the reported data, you can set them to whatever you want - the scripts below do not check them.
The weather underground protocol does a simple http GET and provides all data as query parameters (I had to add the trailing question mark in the configuration). This makes it very easy to extract the data in a script on the server side.
But lets get there step by step. NetBSD comes with a http/https server in base, originally called "bozohttpd". It is very lightweight, but it can run various types of scripts - I picked the plain old simple CGI and /bin/sh as language, using a bit of awk to convert units.
First I added two users, so I could separate file access rights. This is how they look like in vipw:
weatherupdate:*************:1004:1004::0:0:Weather Update Service:/weather/home:/sbin/nologin weatherquery:*************:1005:1004::0:0:Weather Query Service:/weather/query:/sbin/nologinand two httpd instances for them
/etc/inetd entry to collect the incoming data:
88 stream tcp nowait:600 weatherupdate /usr/libexec/httpd httpd -q -c /weather/cgi /weather/files 89 stream tcp nowait:600 weatherquery /usr/libexec/httpd httpd -q -c /weather/cgi -M .js "text/javascript" - - /weather/files
The document root (/weather/files) would not be used for the instance on port 88, but httpd needs one.
Note that these lines use the quiet flag ("-q") which is only available in netbsd-current. You can replace it with "-s" for older versions.
The home directories of both users are mostly empty, besides a .pgpass file that contains the password for this
user connection to the postgres server. They look like this:
127.0.0.1:5432:weatherhistory:open2300:xxxxxxxxxxxxxx
where "weatherhistory" is the datebase and "open2300" is the name of the postgres user for the update script and the password is x-ed out. The other file looks very similar:
127.0.0.1:5432:weatherhistory:weatherquery:xxxxxxxxxxx
At the postgres level the user "weatherquery" needs to have SELECT privilege on the table "weather", and "open2300" needs to have INSERT privilege. The table schema (output of "pg_dump -s") looks like this:
--
-- Name: weather; Type: TABLE; Schema: public; Owner: weathermaster
--
CREATE TABLE public.weather (
"timestamp" timestamp without time zone DEFAULT '1970-01-01 00:00:00'::timestamp without time zone NOT NULL,
temp_in double precision DEFAULT '0'::double precision NOT NULL,
temp_out double precision DEFAULT '0'::double precision NOT NULL,
dewpoint double precision DEFAULT '0'::double precision NOT NULL,
rel_hum_in integer DEFAULT 0 NOT NULL,
rel_hum_out integer DEFAULT 0 NOT NULL,
windspeed double precision DEFAULT '0'::double precision NOT NULL,
wind_angle double precision DEFAULT '0'::double precision NOT NULL,
wind_chill double precision DEFAULT '0'::double precision NOT NULL,
rain_1h double precision DEFAULT '0'::double precision NOT NULL,
rain_24h double precision DEFAULT '0'::double precision NOT NULL,
rain_total double precision DEFAULT '0'::double precision NOT NULL,
rel_pressure double precision DEFAULT '0'::double precision NOT NULL,
wind_gust double precision DEFAULT 0 NOT NULL,
light double precision DEFAULT 0 NOT NULL,
uvi double precision DEFAULT 0 NOT NULL
);
ALTER TABLE public.weather OWNER TO weathermaster;
--
-- Name: weather weather_pkey; Type: CONSTRAINT; Schema: public; Owner: weathermaster
--
ALTER TABLE ONLY public.weather
ADD CONSTRAINT weather_pkey PRIMARY KEY ("timestamp");
--
-- Name: TABLE weather; Type: ACL; Schema: public; Owner: weathermaster
--
GRANT INSERT ON TABLE public.weather TO open2300;
GRANT SELECT ON TABLE public.weather TO weatherquery;
As noted above, I carried this database over (with minor modifications) from previous instances of the whole setup - so it may not be optimal or elegant. One thing that needs special attention is the "timestamp" column - it carries date/time in UTC and has no timezone associated. This looked like a natural choice, but has some unexpected consequences. When querying data in JSON format, "timestamp" will not get the JavaScript marker for "UTC", a "Z" suffix. So in the JavaScript code in the web pages you will find quite a few places that cover up for this.
Now when the weather station sends data to the configured server, inetd(8) runs httpd(8) and that invokes a shell script /weather/cgi/update.cgi
as the "weatherupdate" user.
This script uses awk(1) to do a few unit conversions and output a SQL command to insert the data into the "weather" table.
This SQL command is then piped to psql(1) with the connection string passed on the command line.
The corresponding password is found in ~/.pgpass of the "weatherupdate" user.
The script looks like this:
#! /bin/sh
TZ=UTC; export TZ
awk -v $( echo "$QUERY_STRING" | sed 's/\&/ -v /g' ) 'BEGIN {
temp=(tempf-32)/1.8;
indoortemp=(indoortempf-32)/1.8;
dewpt=(dewptf-32)/1.8;
windchill=(windchillf-32)/1.8;
windspeed=windspeedmph*1.609344;
windgust=windgustmph*1.609344;
rain=rainin*25.4;
dailyrain=dailyrainin*25.4;
totalrain=totalrainin*25.4;
rel_preasure=baromin/0.029529980164712;
printf("INSERT INTO weather VALUES ('"'"'%s'"'"', %f, %f, %f, %d, %d, %f, %d, %f, %f, %f, %f, %f, %f, %f, %f);\n",
strftime("%F %T"),
indoortemp,
temp,
dewpt,
indoorhumidity,
humidity,
windspeed,
winddir,
windchill,
rain, dailyrain, totalrain,
rel_preasure,
windgust,
solarradiation, UV);
}' | psql "hostaddr='127.0.0.1'dbname='weatherhistory'user='open2300'" > /dev/null 2>&1
Note that it explicitly sets the timezone to UTC. The input data comes (as defined by CGI) via the QUERY_STRING environment variable, as a set of "field=value" items, separated by &. They are converted to sets of "-v" args for the awk invocation via a simple sed script.
With this in place, the weather-station adds a record every five minutes to the database, and it was fun to check it via SQL, but for reasons not quite clear to me most of the rest of the family did not like that kind of access very much.
psql (14.5) SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, bits: 256, compression: off) Type "help" for help. weatherhistory=> select min(temp_out), max(temp_out) from weather; min | max -------+------ -18.1 | 80.9 (1 row)
I initially thought the 80.9°C were measured while I was soldering the power cable, but apparently they were fallout from the sometimes failing sensors of the old station. The database has 2840 rows with temp_out > 40°C and all of them are 80.something. I should replace them with an average of the neighbor records.
Presenting the data
So I needed an internal web site. Which needs access to the data.
The above setup already paved the way for that, via the second port I set up.
I wanted to show all the current data in one page, and variable history data on another - which meant two CGI scripts to query the data.
The /weather/cgi/latest.cgi script just fetches the last record logged and creates a JSON from it, and also uses pom(6) and the sunwait(1) program
from pkgsrc to supply some site and date specific data:
#! /bin/sh
PATH=/usr/games:/usr/pkg/bin:$PATH
GEOPOS="51.505554N 0.075278W" # geographic position of this weather station
UPDATE=300 # seconds between updates
# This script uses psql(1) from pkgsrc/databases/postgresql14-client,
# pom(6) from the NetBSD games set and pkgsrc/misc/sunwait.
# collect global site data: sunrise and friends
eval $( sunwait report ${GEOPOS} | awk -F": " '
/Sun directly north/ {
printf("zenith=\"%s\"\n", $2);
}
/Daylight:/ {
split($2,v," to ");
printf("sunrise=\"%s\"\nsunset=\"%s\"\n", v[1], v[2]);
}
/with Civil twilight:/ {
split($2,v," to ");
printf("dawn=\"%s\"\ndusk=\"%s\"\n", v[1], v[2]);
}
/It is: Day/ {
printf("day=true\n");
}
/It is: Night/ {
printf("day=false\n");
}
' )
# moon phase
eval $( pom | awk '-F(' '
/The Moon is Full/ { printf("moontrend=\"-\"\nmoon=100\n"); }
/The Moon is New/ { printf("moontrend=\"+\"\nmoon=0\n"); }
/First Quarter/ { printf("moontrend=\"+\"\nmoon=50\n"); }
/Last Quarter/ { printf("moontrend=\"-\"\nmoon=50\n"); }
/Waxing/ {
a=$0;
sub(/^.*\(/, "", a);
sub(/%.*$/, "", a);
printf("moontrend=\"+\"\nmoon=%d\n", a+0);
}
/Waning/ {
a=$0;
sub(/^.*\(/, "", a);
sub(/%.*$/, "", a);
printf("moontrend=\"-\"\nmoon=%d\n", a+0);
}
' )
# start the json output
printf "\n\n{ \"site\": { \"updates\": ${UPDATE},
\"dawn\": \"${dawn}\", \"sunrise\": \"${sunrise}\",
\"zenith\": \"${zenith}\", \"day\": ${day},
\"sunset\": \"${sunset}\", \"dusk\": \"${dusk}\",
\"moon\": { \"trend\": \"${moontrend}\", \"percent\": ${moon} }\n}, \"weather\":\n"
# fill database results
printf "WITH t AS ( SELECT * FROM weather ORDER BY timestamp DESC LIMIT 1 ) SELECT row_to_json(t) FROM t;\n" |
psql --tuples-only --no-align "hostaddr='127.0.0.1'dbname='weatherhistory'user='weatherquery'"
# terminate json
printf "\n}\n"
As you can see, if you would restrict output to plain data from the database, the script would be only four or five lines long. But I like the additional spicing.
The /weather/cgi/history.cgi script fetches rows between two timestamps passed to it (in JSON timestamp format)
and answers with a JSON containing an array of all the data in the requested time window:
#! /bin/sh
COND=$( echo "${QUERY_STRING}" | tr '&' '\n'| sed -e 's/%22/\"/g' -e 's/%3A/:/g' | awk '
/from=/ { v=$0; sub(/^[^"]*\"/, "", v); sub(/\".*$/, "", v); arg_from=v; }
/to=/ { v=$0; sub(/^[^"]*\"/, "", v); sub(/\".*$/, "", v); arg_to=v; }
END {
if (arg_from && arg_to) {
printf("timestamp >= '"'"'%s'"'"' AND timestamp <= '"'"'%s'"'"'\n",
arg_from, arg_to);
}
}
' )
if [ -z "${COND}" ]; then
# printf "could not parse: ${QUERY_STRING}\n" >> /tmp/sql.log
exit 0;
fi
# start output
printf "\n\n"
# printf "${COND}\n" >> /tmp/sql.log
# fill database results
printf "WITH t AS ( SELECT * FROM weather WHERE ${COND} ORDER by timestamp ASC ) SELECT json_agg(t) FROM t;\n" |
psql --tuples-only --no-align "hostaddr='127.0.0.1'dbname='weatherhistory'user='weatherquery'" # 2&>> /tmp/sql.err
Fetching this data now is easy in JavaScript.
We have a request URL defined as a const, like this:
const queryURL = 'http://weatherhost.duskware.de:89/cgi-bin/history.cgi?';
and then add (if needed) the paramaters for the query, like in this example function that gets passed a from-date and a to-date:
function showData(fromD, toD)
{
var url = new URL(queryURL);
url.searchParams.append("from", '"'+fromD.toJSON()+'"');
url.searchParams.append("to", '"'+toD.toJSON()+'"');
fetch(url).then(function(response) {
return response.json();
}).then(function(data) {
makeGraphs(data);
updateButtons();
}).catch(function(error) {
console.error(error)
});
}
When the answer from the server arrives, it is decoded as JSON and returned as input data to the next function that makes some graphs from the data array. Finally a few buttons are updated (in this example the time window is put into a start and a end date control.
Inspired by the post mentioned above I used canvas gauges for the display of the latest data and dygraphs for the display of historic data.
Here is an example of how the latest display looks:
And here is how the history display looks:
I have put an archive of the cgi scripts and web pages here, and also for the curious who just want to peek at the full glory of my web design skills the start page (showing the latest weather data) and the history page.
Besides those files, you will need
- a
/weather/files/favicon.icoif you like. - download
gauge.min.jsfrom canvas gauges and put it into/weather/files/. - download
dygraph.css,dygraph.min.jsfrom dygraph, plussynchronizer.jsfrom the dygraphextras/directory and put it also into/weather/files/.
Then you should be ready to go - easy, isn't it? And no heavy weight dependencies or pkgs needed.
What about other weather stations?
There are quite a few similar weather stations out there now that seem to run "related" firmware and have similar capabilities. Most likely the update script (and details in the presentation pages) will need adjustements for other types.
If you start with a different device, just log all the data it sends and adjust the cgi scripts/database/JavaScript accordingly. For protocol analyzis there are several easy means:
- Remove the "-q" flag in the httpd command (in
/etc/inetd.conf) and check/var/log/xferlogfor the quey paramaters sent by the weather station (when using the weather underground protocol). - Make the station log to a
debug.cgifirst to capture everything (including form data posted). This works for the ecowitt protocoll. - All this stations seem to use http only (not https), so you can sniff the traffic. Use
tcpdump -won the server to capture the data and analyze it with net/wireshark from pkgsrc.
Here is what a debug.cgi script could look like:
#! /bin/sh env > /tmp/debug.env printf "\n\nOK\n" cat > /tmp/debug.input &
This allows you to see the form input in /tmp/debug.input and the CGI environment in /tmp/debug.env.
No videos are available yet to provide much-needed context to presentations, but we'll keep you posted.
Day -2 - Arrival in Vienna
After being thoroughly delayed by Deutsche Bahn, I hopped off an InterCity Express train to check out the hotel room for people speaking at EuroBSDCon, which was An Experience in itself. There was a mural of a shirtless man with a sword covered in snakes next to my bed, what else do you need in life? Lots of coffee, obviously.
Begin the march to the conference to listen to Marshall Kirk McKusick lecture on schedulers.
Day -1 - NetBSD Developer Summit
Around 16 NetBSD developers gathered in a room for the first time in two years. I was a little bit distracted and late due to Marshall Kirk McKusick's very detailed lecture on filesystems melting my brain somewhat, but we had the opportunity to present various informal presentations, after we'd finished showing off suspend/resume support on our ThinkPad laptops.
Benny Siegert opened with a presentation on the state of the Go programming language on NetBSD (and whether it is "in trouble"), covering various problems with instability being detected inside the Go test suite. Go is particularly interesting (and maybe error-prone) because it mostly bypasses NetBSD libc, which is unusual for software running on NetBSD, instead preferring to implement its own wrappers around the kernel's system calls.
A few problems had been narrowed down to being (likely) AMD CPU bugs, others weren't reproducible in production (outside of the test suite) at all, and others may have been fixed in NetBSD 9.1 - the NetBSD machines running tests for Go do need to be updated. If you're from AMD, please get in touch.
We've got a very impressive test suite for NetBSD itself, but outside tests are always useful for identifying problems that we can't catch... that said, they do require a lot of work to maintain, and a lack of patience is understandable. We'd love any help we can get with this.
I pointed out that we get occasional failures bootstrapping Go in pkgsrc, and better debug output would be nice -- Benny was able to arrange this within the day, and we should get nice detailed bootstrapping logs for Go now.
Pierre Pronchery (khorben@) discussed cross-BSD collaboration on synchronizing our device driver code bases, including his recent NetBSD Foundation-supported work on the emuxki(4) sound card driver, where other BSDs have taken the same code base but improvements had not yet been universal. We all agreed that collaboration and keeping drivers in sync is important. We talked about the on-going project to synchronize NetBSD Wi-Fi drivers with FreeBSD.
Martin Kjellstrand then gave us a very nice demonstration of his NetBSD docker images, and how easy it is to spin up NetBSD on-demand to run a command (this also has wide potential for being useful for testing). In turn, I rambled a bit about my own experiments of dynamically creating NetBSD images. This would lead to a later discussion about whether we need to prioritize improving the resize_ffs(8) command's support for new filesystems.
The theme of creating NetBSD images "for the cloud" continued, with Benny Siegert presenting again about NetBSD on Google Compute Engine.
Stephen Borrill then stepped up to give us an incredibly detailed history of the British computer company Acorn Computers, complete with his personal experiences servicing Acorn machines in the early 90s. We discussed the history of the ARM CPU, and NetBSD/acorn32.
Nia Alarie (surprise) finished up with a very short unplanned demonstration of some of the projects she's been working on lately - using NetBSD as a professional digital audio workstation, improving the default graphical experience of NetBSD with dynamically generated menus, and (again) creating customized micro-images of NetBSD. We discussed support for MIDI devices (I'd later chat with some of the FreeBSD people about collaborating on JACK MIDI).
We then retired to Thomas Klausner (wiz@)'s favorite ramen restaurant and discussed, among other things, Studio Ghibli films, and trains. Trains would be a recurring theme.
Day 0 - start of talks
We began the day with two NetBSD presentations scheduled back-to-back. This mostly meant that I got to talk about some of NetBSD 10's upcoming features, and why it's taking so long to a small crowd of interested people who didn't have much prior experience with NetBSD, while in another room Taylor R. Campbell (riastradh@) discussed his very dedicated efforts to make suddenly disappearing devices more reliable and not crash the kernel (we're still waiting for a live demonstration).
Next, Pierre Pronchery (khorben@) discussed the power of pkgsrc for creating consistent environments across platforms for software developers, serving as a nice portable, classic Unix alternative to technologies like Docker and Nix.
The final presentation of the day was riastradh@ again, this time providing a live lecture (from Emacs!) about memory barriers in the kernel. We all learned to appreciate the nice abstractions technologies like mutexes provide to stop CPUs from re-ordering code on multi-processor machines in inexplicable ways.
Day 1 - final talks
The second day of EuroBSDCon presentations was mostly devoid of anything NetBSD-focused, so we had a nice opportunity for cross-pollination and to learn and collaborate with other BSD projects. I chatted a bit with an OpenBSD Ports developer about the challenge technologies like Rust pose to developing a cross-architecture packaging system, and with a FreeBSD person about the state of professional audio on our respective platforms. Michael Dexter finished the day of presentations with a very passionate speech about why we all need BSD in our lives, regardless of our preferred flavour.
More topics were discussed in the various break periods, including whether our newest update to the GPU drivers is stable enough to include in a release (verdict: works for me).
We then watched as various BSD t-shirts and boxes of chocolates were auctioned away to support a local refugee center. The organizing committee forgot to include the NetBSD Foundation on the list of sponsors, but we forgive them.
Other news from the Project
I've recently made sure the NetBSD 10 changelog is up to date with all the new goodness, so you should check that out.
The NetBSD Project is pleased to announce NetBSD 9.3, the third release from the NetBSD 9 stable branch.
It represents a selected subset of fixes deemed important for security or stability reasons since the release of NetBSD 9.2 in May 2021, as well some enhancements backported from the development branch. It is fully compatible with NetBSD 9.0. Users running 9.2 or an earlier release are strongly recommended to upgrade.
Aside from many bug fixes, 9.3 includes backported improvements to suspend and resume support, various minor additions of new hardware to existing device drivers, compatibility with UDF file systems created on Windows 10, enhanced support for newer Intel Gigabit Ethernet chipsets, better support for new Intel and AMD Zen 3 chipsets, support for configuring connections to Wi-Fi networks using sysinst(8), support for wsfb-based X11 servers on the Commodore Amiga, and minor performance improvements for the Xen hypervisor.
The general NetBSD community is very excited about NetBSD 10.0, but it was deemed necessary to make this bug fix release available while we wait for the resolution of some compatibility problems in NetBSD-current concerning FFS Access Control Lists preventing the netbsd-10 release.
The NetBSD Foundation has finalized the list of projects for this year’s Google Summer of Code. The contributors and projects are the following:
- Brian Schnepp - Raspberry Pi GPU Driver
- Arjun Bemarkar - inetd enhancements
- Piyush Sachdeva - Emulating missing linux syscalls
- Vihas Makwana - Introduce a new Wi-Fi driver
- Vivek Kumar Sah - Automating donor acknowledgement and information storage
The community bonding period has already started (from May 20) and it will last until June 12. During this time, the contributors are expected to coordinate with their mentors and community.
This will be immediately followed by the coding period from June 13 to September 4. After which, the contributors are expected to submit their final work, evaluate their mentors, and get evaluated by their mentors as well. Results will be announced on September 20.
For more information about the Google Summer of Code 2022 kindly refer to the official GSoC website.
We would like to express our gratitude to Google for organizing the yearly GSoC, and to The NetBSD Foundation mentors and administrators for their efforts and hardwork!
Let us welcome all the contributors to our growing NetBSD community!
The NetBSD Foundation has finalized the list of projects for this year’s Google Summer of Code. The contributors and projects are the following:
- Brian Schnepp - Raspberry Pi GPU Driver
- Arjun Bemarkar - inetd enhancements
- Piyush Sachdeva - Emulating missing linux syscalls
- Vihas Makwana - Introduce a new Wi-Fi driver
- Vivek Kumar Sah - Automating donor acknowledgement and information storage
The community bonding period has already started (from May 20) and it will last until June 12. During this time, the contributors are expected to coordinate with their mentors and community.
This will be immediately followed by the coding period from June 13 to September 4. After which, the contributors are expected to submit their final work, evaluate their mentors, and get evaluated by their mentors as well. Results will be announced on September 20.
For more information about the Google Summer of Code 2022 kindly refer to the official GSoC website.
We would like to express our gratitude to Google for organizing the yearly GSoC, and to The NetBSD Foundation mentors and administrators for their efforts and hardwork!
Let us welcome all the contributors to our growing NetBSD community!
We are happy to announce that The NetBSD Fundation is a mentoring organization at Google Summer of Code 2022!
Would you like to contribute to NetBSD or pkgsrc during the summer? Please give a look to NetBSD wiki Google Summer of Code page with possible ideas list and/or please join #NetBSD-code IRC channel on libera or get in touch with us via mailing lists to propose new projects!
Please note that unlike past years where Google Summer of Code was opened only to university students since this year if you are 18 or older you can be a GSoC contributor.
For more information about Google Summer of Code please give a look to the official GSoC website.
Looking forward to have a nice Google Summer of Code!
We are happy to announce that The NetBSD Fundation is a mentoring organization at Google Summer of Code 2022!
Would you like to contribute to NetBSD or pkgsrc during the summer? Please give a look to NetBSD wiki Google Summer of Code page with possible ideas list and/or please join #NetBSD-code IRC channel on libera or get in touch with us via mailing lists to propose new projects!
Please note that unlike past years where Google Summer of Code was opened only to university students since this year if you are 18 or older you can be a GSoC contributor.
For more information about Google Summer of Code please give a look to the official GSoC website.
Looking forward to have a nice Google Summer of Code!