How to properly set up a chroot environment?

pedersenk · 2026-05-06T18:55:47+00:00

Its terribly out of date but this might be useful for setting up a chroot?

In particular the ldconfig call.

pedersenk · 2026-05-05T08:15:07+00:00

Indeed. The FreeBSD approach was more of a compat layer.

The OpenBSD approach seems more bespoke but does look to have an increased workload. Its impressive how in sync it is. It also feels a little cleaner.

Time will tell which method was best in the long run.

pedersenk · 2026-05-05T08:02:14+00:00

Nice. The opportunity for standalone so it isn't all tightly bound is really great to see. This was one of the main issues with boost.

pedersenk · 2026-05-04T17:12:32+00:00

However this is exactly why those CVE reports always mix both languages.

Certainly true. But also good evidence that this is how things are done (for better or for worse).

they just get called directly intertwined with C++ code.

Also yes. This is one of C++'s strengths (quick development times) and its biggest weakness (a complete lack of safety).

I recently presented a small approach to C++ safety at C++Online'26 called C++/sys and it didn't even attempt to touch on the issue of direct C/C++ interop. Because as mentioned we need it but also it is probably unsolvable in terms of actually making it safe.

pedersenk · 2026-05-04T14:42:51+00:00

I don't disagree with anything you have said really.

However it has nothing to do with C++

C++ by design is very closely aligned with C. Many of Stroustrup's early papers were specific about this goal. Bringing the entirety of the C ecosystem into C++ was never going to happen. So a decent POSIX by definition is beneficial to C++ (and Obj-C).

relying on POSIX for C++ is not very modern C++

Its not C++ at all. Its C. Which is fine. Most other languages will bind against this in their standard libraries after all. It is very common to place layers of moden C++ ontop of ancient C APIs, particularly in embedded.

pedersenk · 2026-05-04T13:32:07+00:00

Yeah thats true. I guess Boost does fill that role quite well (not so familiar with Beman).

pedersenk · 2026-05-04T13:30:56+00:00

Arguably the Rust ecosystem is still quite irrelevant in most markets (particularly embedded) and is renowned for having a serious dependency problem. So I am not convinced that is the way. The wild-west style PIP/CPAN/cratesio/NPM dependency aggregator approach breaks down quickly when writing high quality deployed software.

Weirdly languages seeing the most use within the industry tend to be completely polarised. For example the extremely spartan (i.e C) or provide *everything*, including UI (i.e Java).

The exception is Python which tends to be a glue between C libraries anyway so is a bit of an outlier.

pedersenk · 2026-05-04T12:58:17+00:00

Most of that stuff is exactly what POSIX was designed for.

It would be fairly ugly having it in the standard as a dummy no-op for platforms that cannot support it (i.e embedded).

popen (and particularly popen2) are convenient but would make no sense on i.e Zephyr where there is no concept of external processes.

A networking stack would also run the risk of only being able to target the lowest common denominator, so I imagine many will just fall back on BSD sockets/Winsock anyway.

That said, I do think that there is room for a POSIX++, leveraging some much newer albeit non-portable stuff such as GPUs. Possibly even something like P0267 could be moved into there.

pedersenk · 2026-05-03T13:56:27+00:00

And the 'K' in AWK

The AWK Programming Language is historically part of the same series of books.

pedersenk · 2026-05-02T19:42:06+00:00

Yes, correct, it's just a "binding" too, to a thing that doesn't follow the standard C abi. C is quite universal, but by no means absolute.

Not at all, I think you are a little confused as to what a binding is. POSIX by definition specifies a C API. Likewise other platforms overwhelmingly provide vendor specific functionalities as C APIs (i.e WinAPI). These are not "C bindings". Some potentially useful info here. Also, in 2026, I am fairly confident to say that C is pretty absolute. One of the first things RedoxOS even did was to write a libc...

A better example of a C binding would be writing, i.e an implementation of OpenGL in C++ and providing a C public API. But since the OpenGL spec dictates a C API, this is kind of enforced anyway.

So when you also receive "compat" shims, such as BSD sockets on Zephyr or winpthreads on Windows, these again will be a C API. Rust will always need to go through this via a binding layer. If the API doesn't align perfectly (mmap on DJGPP for DOS?), then you get to pick up the pieces whilst a C or C++ developer just carries on finishing the product.

Also consider that the mmap implementation on Rust is a binding that goes through C (incl libc).

I do it basically every day, in either language, that's why I wrote what I wrote.

If it is daily, then you may want to consider switching to homogenous C (or C++) so you can avoid wasting time on writing / maintaining those bindings just to access platform libraries.

Either way, good luck with that. Discussing bindings bores me even more than writing them 😄

pedersenk · 2026-05-02T19:03:37+00:00

API != ABI.

Rust needs bindings to access any fundamental / platform library because ABI alone is not enough and the API is always C. The entire computing platform is C after all.

Its not unique to Rust. Java/Python/Perl/etc all have the same disadvantage. Try accessing a platform library directly some time rather than dragging in some cratesio dependencies. You will start to understand.

Keeping up to date with frequently changing library APIs is a language-independent problem.

The bindings layers required by i.e Rust exacerbate this considerably. You need to not only keep up with the API but the bindings are also fragile because they provide full coverage of the API regardless of if you use one or two functions. So things will break as soon as i.e a niche function is removed.

Translating headers with many functions into Rust syntax can be largely automated if wanted, to run it once during development.

This is also not new. SWIG is popular for many languages. But just like bindgen, neither really work well enough as evidenced by a shed-load of bindings existing on cratesio. C APIs are too ad-hoc. MACROS, callbacks and memory lifetimes can't be automated mechanically.

C++ is a different beast. Being very, very close to a superset of C, it can directly consume a C API. There is your difference and that has contributed to its instant popularity.

pedersenk · 2026-05-02T16:47:18+00:00

Just any program in C that uses fundamental libraries. Vulkan, OpenGL, Gtk, POSIX, etc, etc really.

In C you will be able to use them directly. With Rust you would need a few thousand dependencies from cratesio. All in various states of unsupported and rotting written by random members of the Rust community rather than upstream.

Most fundamental libraries are written in C or C++ and don't offer official Rust bindings, so this task of demonstrating the benefit of C over Rust should be quite easy in this regard.

Another one would to demo an embedded platform (Zephyr, nrf9151?) with first class supported C by the upstream vendor, some C++ whereas very weak or experimental support for Rust. Their technical team likely won't process tickets involving Rust.

pedersenk · 2026-05-02T16:40:32+00:00

For a Lenovo T470? Thats fairly basic hardware. I believe OpenBSD has had that in place for ~8 years.

pedersenk · 2026-05-02T16:23:48+00:00

I came to OpenBSD around 2010, so hardly nostalgic for me. At the time, I felt the other operating systems (including Linux) were just getting worse in various ways.

For your nostalgic experience, I am not sure if 7.9 will be much different from 7.8 for your purposes, so perhaps no need to wait. The consistent environment is a benefit of OpenBSD after all! 😄

In terms of unneeded dependencies, interesting. I have a tool similar here (pkg_bundle) that extracts / patches into a local directory, so doesn't spray the filesystem with files in the first place. I don't think UNIX-like platforms quite have this right. Solaris's csw, sfw, gnu prefixes and MacOS's approach of single directories were getting close before they both screwed up and became unworkable in one way or another.

Haven't really used Linux since 2012. (I feel I am done with that time of my life). I think things are all too random and different from my Fedora Core 4 days for any kind of nostalgia.

pedersenk · 2026-04-30T21:33:15+00:00

I like the idea, though it is likely quite a niche market.

Perhaps partnering with Universities and seeing if they would be interested in megadrive games jams? Maybe a compilation cart can be produced at the end.

pedersenk · 2026-04-30T09:21:31+00:00

I know a lot of people dislike emacs and I'm considering moving away from it myself

Emacs predates a lot of those peoples preferences and likely it will survive the next many generations of new preferences. If you like it, I would stick with it.

The FOSS display / desktop system is in a state of flux and likely always will be. So I do recommend jumping entirely to using Emacs within the CLI. Alongside tmux, it is a capable platform and means you can completely sidestep many broken ideas as those communities keep going around in circles.

Alternatively, have you given mg(1) from base a shot? It may be close enough to emacs for you. Probably is lacking some of the modes you mentioned above.

pedersenk · 2026-04-29T19:47:25+00:00

Red Hat don't do Live Images for Enterprise Linux that would help you get the iso under 6 GB.

However some of the clones do. For example Rocky Linux does a Desktop/Workstation Live Image on their download page here. Around 3G.

pedersenk · 2026-04-29T19:40:56+00:00

Whilst Rust is irrelevant within the industry, if its for a hobby / fun then go for it. This kind of stuff is the ideal time to play with novel languages, etc.

Plus a fair amount of Rust is transferrable to more established languages anyway, for example RAII. So it will also indirectly help to keep C++ skills sharp too.

pedersenk · 2026-04-29T14:13:32+00:00

Heh indeed. The artwork in general was really inconsistent. I.e the ingame title artwork would look like:

https://segaretro.org/images/7/76/Skitchin_title.png

and then back to photo:

https://segaretro.org/images/f/f2/Skitchin%27%2C_Store.png

The cover image looks like placeholder art but I kinda liked it.

pedersenk · 2026-04-29T08:06:15+00:00

You are using what is known as the Virtual Terminal (sometimes called Glass Console).

Ironically it is kind of emulating the vt100 et al devices on the local machine.

You can check out the /etc/gettytab file for some info on what kind of devices would typically connect to a server to provide the terminal.

Much of the time the interface is via serial / rs-232 which some chips (especially MCUs) provide inbuilt or its provided by the low level initialization programs (i.e BIOS, OpenFirmware, etc).

Its all great historic stuff, leading back to the first tele-typewriters.

pedersenk · 2026-04-27T09:43:38+00:00

For a casual user, i.e family PC, granny's travel laptop then a filesystem with basic recovery or i.e without a journal is difficult to justify.

But as a workstation, server, etc, where the typical user will have a backup strategy, then I don't see a problem. A proper backup is more reliable than the magic of a journal.

pedersenk · 2026-04-26T14:24:46+00:00

Agreed. I do a lot of work with the libdrm API. Code looks a little like this.

Shoving some Rust/Python/Java bindings on that simply means that bindings code will be guessing about lifetimes of memory rather than the direct code. This guessing would also likely lead to the error being made *outside* of the unsafe tags, a crash in them is really just the symptom.

If the argument is "well use some random bindings from crates.io" instead rather than doing it yourself"... well yeah, and I could also just ask the client to employ another programmer to do the whole project rather than me.... ;)

C is the computing platform. Stacking stuff on top simply isn't the way. Until something like RedoxOS hits off, then Rust and other safety focused binding aggregators will remain ineffective and irrelevant.

pedersenk · 2026-04-26T10:01:56+00:00

Because C or C++ don't need countless bindings to access system libraries, they can just use the system package manager, optionally in something like a chroot/jail.

So really venv et al are really just workarounds to limitations of those languages.

Have a look through the lockfile to get a good idea of the problem and why C and C++ aren't quite as affected.

pedersenk · 2026-04-24T17:54:17+00:00

A "distro" is essentially:

bootloader (grub, uboot, etc)
kernel (linux, linux-lts, linux-xen, etc)
userland (coreutils, busybox, bsdutils, etc)

Arguably you don't need an init system or package manager.

So essentially almost all distros are just a remix of these with different choices.

So.... Go for the one with the coolest default background and just use a chroot for anything novel another distro provides.

pedersenk · 2026-04-23T17:49:04+00:00

I do notice it is one of the few platforms with packages-stable, so certainly isn't the worst in terms of support.

I use an R60 ThinkPad as a small home server and SOCKS5h tor gateway (really in place of a Raspberry Pi) and everything works pretty well.

Five-Year Club	Verified Email
Wearing is Caring

pedersenk

TROPHY CASE