Tag Archives: FreeBSD

libxo wrapper in Oberon-2 for Vishap Oberon Compile

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.

Screenshot 2023 04 05 at 4 40 45 PM

Next, I will be wrapping libucl in Oberon.

See you soon 🙂

Reply via email.

Antranig Vartanian

March 29, 2023

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.

  1. Keep the promise of Jailer being “very compatible with FreeBSD”
  2. Have a new version that pushes these limits of compatibility.

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…

Reply via email.

Design Guidelines vs Pushing The Limits

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…

Reply via email.

Call For Testing: Jailer v0.1.1

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

  1. Complete NetGraph support using jng.
  2. Jailerfile, which will be something similar to Dockerfile, allowing developers to create consistent images.
  3. jailerd and jailerctl, for remote jailer automation. This will be an open-source port of what illuria has already developed.
  4. Distributed Jailer, where 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…

Reply via email.

Antranig Vartanian

March 3, 2023

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.

Screenshot 2023 03 02 at 8 48 08 PM

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!

Screenshot 2023 03 03 at 3 27 35 PM

I think I will be making an official Jailer v0.1.0 release in the coming days!

Reply via email.

Unshallow Git

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.

  1. Can I get the rest of the depth/history?
  2. If GitHub and git.FreeBSD.org is slow, can I setup a local mirror?

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?

  1. Latency matters! If the distance between my two apartments is $2 worth of commute, while the FreeBSD server is $2000 worth of commute, then my apartments are also close to each other digitally.
  2. When you do anything non-standard with git (e.g. --depth=1) make sure to read the docs on how to undo that later.

That’s all folks…

Reply via email.

Antranig Vartanian

February 8, 2023

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…

Reply via email.

Apple updated macOS’s date(1)!

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

Screen Shot 2022 12 29 at 4 14 21 PM

Here it is on macOS Ventura

Screenshot 2022 12 29 at 4 22 45 PM

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

Screen Shot 2022 12 29 at 4 25 18 PM

Wait, what?

What about the man page on macOS Ventura?

SCR 20221229 mr9

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…

Reply via email.

Antranig Vartanian

December 16, 2022

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!

Reply via email.

FreeBSD arm64.aarch64 on QEMU/UTM with better (but not perfect) graphics

A week ago I posted about Running arm64.aarch64 FreeBSD on QEMU/UTM.app on Apple Silicon, and looks like

  1. Many people liked that post
  2. Everyone asked about running graphics (Xorg)

It took me a while but in the end it was, again, a simple change.

All you have to do is to add this single line to /boot/loader.conf

efi_max_resolution="1920x1080"

Now, QEMU’s display will not be 1080p, but it will be the following

VT(efifb): resolution 1024x768

Here are some screenshots

Here’s also Firefox doing an HTML5 test. As you can see, it passed the exam!

However, I’d like to get more resolution out of this. If you know how, please let me know.

That’s all folks…

Reply via email.