Like I said in my previous post, this is a long project and it relies on a lot of things 🙂
Wrapping libxo was fun, but wrapping libucl was way more complicated. However, it is done. It’s not a complete port, however, it has the basics to get started. The goes is to have all wrappers match the their libraries.
The source is at antranigv/voclibucl and here’s a screenshot of what it can do.
Next, I will be improving these wrappers and then work on lzc, a.k.a. Lib_ZFS_Core 😉
See you soon 🙂
I’m working on a new project, which is still only 10% done. For that project I chose to use the Oberon–2 programming language and the Vishap Oberon Compiler.
After seeing libxo on FreeBSD, I’m not sure I can go back to write or printf, so I decided to write an Oberon wrapper for it.
I just finished the basics but it’s already usable for day-to-day outputs, containers/lists/instances and exit codes.
The source is at antranigv/voclibxo and here’s a screenshot of what it can do.
Next, I will be wrapping libucl in Oberon.
See you soon 🙂
After weeks of thinking, I decided that I need to fork Jailer. Yes, I want to fork my own code. There are two reasons to do this.
The fork is going to be named bant, which is Armenian for jail. I think we’re all tired of Greek names at this point 🙂
I’ll share the details of bant as soon as I have a prototype, which means at least couple of weeks.
Meanwhile, Jailer will be the very-compatible-with-FreeBSD version, that doesn’t brake things and allows new users to use Jails with ease.
Fingers crossed…
One of the design guidelines of Jailer is don’t break FreeBSD. As in if someone installed and used Jailer, and then deleted the Jailer binary and libraries, their Jails would still run without any issues. We do this with minimal intervention, for example, jailer init patches FreeBSD’s /etc/rc.d/jail, but in a way that you wouldn’t feel the difference much. We don’t create new rc.conf variables, we just change couple of loops. In a way, you can keep these changes even if you delete Jailer so your system would be much improved. Obviously, we do sent these patches to FreeBSD src.
But I’m in front of an issue right now. On one side, I want to keep these guidelines, on the other, pushing the limit will allow me to improve Jailer way more than I expected.
These are the things that I think about before sleep, or during the shower. I gave a promise, that I will not break the Jail ecosystem. But what if, just what if, the ecosystem was broken in the first place?
Some of you might know, that we’ve been working on integrating libucl with Jail. The experiments have been going well, in such that I feel I want to integrate these experiments with Jailer already, even before they get into FreeBSD (and they might even not get in at all).
My dream of Jailer and its ecosystem is complex. I feel that these integration would do good on the long-term, but I want to keep the short term alive as well.
One idea is to fork Jailer, keep two versions of it. One version that’s FreeBSD compliant, and another one that is pushing the limits.
This is going to be an interesting week…
That’s all folks…
Well, it’s finally here! After a week of sleepless work, I cleaned up the Jailer codebase and added many features (and removed some as well!) that I wanted since last year 🙂
If you are reading this, please consider testing Jailer on FreeBSD. The codebase is at illuria/jailer.
The README.md should have all the info that you need to run Jailer.
If find any issues, please report to illuria/jailer/issues or you can email me personally at antranigv [at] freebsd [dot] am
Here’s the roadmap for what’s coming next
jng.Jailerfile, which will be something similar to Dockerfile, allowing developers to create consistent images.jailerd and jailerctl, for remote jailer automation. This will be an open-source port of what illuria has already developed.jailerctl list will show not just what’s on a remote machine, but on a remote datacenter, inspired by Triton. Again, we have this at illuria, but we need to create an open-source port.This release is dedicated to
Thank you for reading 🙂
That’s all folks…
I’ve been working very intensively with Jailer the last couple of days.
The first thing I added, which I personally needed it is a dry run, where Jailer says what it would do. Here’s an example.
by adding -D Jailer would display what it would do, including post the jail.conf file, ZFS commands and any network setup commands.
A while back kfv has made a jailer init
subcommand that initializes the system. Things like rc.conf variables, ZFS datasets and applying our own patches. I just added some coloring and confirmation to that!
I think I will be making an official Jailer v0.1.0 release in the coming days!
A while back, when I was working on some changes for FreeBSD, I wanted to checkout our source tree. A very typical thing that every developer does every day, that is
git clone https://git.FreeBSD.org/src.git
However, the FreeBSD git server is pretty far from me. There’s a GeoDNS system in the front so I usually hit the one in Frankfurt, Germany.
Still, it’s pretty slow!
root@devbsd14:~ # git clone https://git.FreeBSD.org/src.git Cloning into 'src'... remote: Enumerating objects: 4234853, done. remote: Counting objects: 100% (381211/381211), done. remote: Compressing objects: 100% (28321/28321), done. Receiving objects: 3% (152416/4234853), 48.97 MiB | 1.08 MiB/s
Okay, 1.08 MiB/s is not that bad, but I’m sure we can do better.
How about GitHub?
root@devbsd14:~ # git clone https://github.com/freebsd/freebsd-src/ Cloning into 'freebsd-src'... remote: Enumerating objects: 4793378, done. remote: Counting objects: 100% (398/398), done. remote: Compressing objects: 100% (233/233), done. Receiving objects: 16% (780550/4793378), 223.95 MiB | 2.13 MiB/s
Okay, 2.13 MiB/s is also not bad, but I have a faster connection than that!
Regardless, I needed just the last state of the code, without the history, so in order to save time and bandwidth I can do
git clone --depth 1 https://git.FreeBSD.org/src.git
And now I can work.
The problem is that this was months ago, and I totally forgot about it.
While I was debugging some issue, I ran git blame and I realized that I can’t see anything older than 3 months. what?
Lucky me, I was able to understand what I did by looking into the shell history.
Okay, so two questions.
Turns out, I had to ask these questions in reverse.
First, I setup a FreeBSD source tree mirror in my home server (which also serves this blog). The connection to that server is fast, the download speed is around 500Mbps, compared to the 50Mbps that I get in this apartment. Yes, I have to apartments, but one of them is only for servers 😀
That was pretty easy to do, I just needed to tell Gitea to mirror https://git.FreeBSD.org/src.git, and in couple of minutes, it was all ready.
Next, I had to make my local checkout… unshallow. After setting up the appropriate remotes, all I had to do was
git pull --unshallow mirror main
and now I have the history all the way back to Jun 12, 1993.
Oh, right! The clone speed test!
root@devbsd14:~ # git clone git@git.bsd.am:antranigv/freebsd-src.git Cloning into 'freebsd-src'... remote: Enumerating objects: 4235021, done. remote: Counting objects: 100% (4235021/4235021), done. remote: Compressing objects: 100% (824757/824757), done. Receiving objects: 18% (762304/4235021), 207.13 MiB | 3.53 MiB/s
Okay! now this does use a lot more speed!
Lessons Learned?
--depth=1) make sure to read the docs on how to undo that later.That’s all folks…
Turns out when you start MariaDB for the first time it prints technical messages and theeen it says:
Please report any problems at https://mariadb.org/jira The latest information about MariaDB is available at https://mariadb.org/. Consider joining MariaDB's strong and vibrant community: ⠀https://mariadb.org/get-involved/ Starting mysql.
I love this!
I think we should add something similar to FreeBSD, where after the installation is done it says something like:
Please report any problems at https://bugs.freebsd.org/ The latest Handbook is available at https://freebsd.org/handbook/ Consider joining FreeBSD’s worldwide community: https://docs.freebsd.org/en/articles/contributing/ Thank you for choosing FreeBSD!
Wait, maybe we have such a message? I have to check and then patch if we don’t 🙂
That’s all folks…
In 2020 I blogged that
[…] macOS is becoming less Unix-y every year,
date(1)is outdated […]
While I was coding, I thought that I’m (SSH’d to) on my FreeBSD machine but I was on macOS, I noticed that the -I flag suddenly works.
I wondered if Apple has updated the date(1) command in macOS Ventura.
Luckily, I have macOS Monterey at home as well.
Here’s the date(1) command on macOS Monterey
Here it is on macOS Ventura
Ah, so it works!
Did Apple update something? I’m pretty sure it’s mentioned in the history section of the man page.
Here’s the man page of date(1) on macOS Monterey
Wait, what?
What about the man page on macOS Ventura?
Well… Either someone forgot to update the man page on macOS Ventura, or someone forgot to merge the code properly on macOS Monterey
In either cases, I’m happy that Apple noticed the change and pulled the updated code from FreeBSD!
That’s all folks…
Well, it time to do upgrades on my server. expect this blog will be offline for a while as well.
How long were we up anyway?
root@pingvinashen:~ # uptime 9:41PM up 270 days, 18:36, 4 users, load averages: 0.15, 0.36, 0.38
Not bad, huh?
See you soon!