The base system #6

thomholwerda commented 2025年02月11日 12:04:19 +01:00

One of the first decisions that needs to be made is the base system. Since I think it's wisest to use a popular, well-regarded distribution as our base, the choice for Debian seems obvious. Furthermore, since I think Chisel should be a system with a classic init system, Devuan seems like the right Debian flavour to work off of. There are more exotic options here, like, say, Void or Alpine, but I think Debian's popularity and community support is the way to go.

The first, initial milestone, then, could be to have a Devuan base with the current version of CDE as the desktop, augmented by some current, maintained Motif applications like the ones made by fastestcode.org. This would give us a system to work from and further explore which elements of a modern UI and applications we'd need to implement in Motif (think everything from a wifi manager to really complex stuff like an email client and web browser).

Of course, this is just my take, and I'm open to any suggestions, especially from programmers and developers with experience in these matters.

One of the first decisions that needs to be made is the base system. Since I think it's wisest to use a popular, well-regarded distribution as our base, the choice for Debian seems obvious. Furthermore, since I think Chisel should be a system with a classic init system, Devuan seems like the right Debian flavour to work off of. There are more exotic options here, like, say, Void or Alpine, but I think Debian's popularity and community support is the way to go. The first, initial milestone, then, could be to have a Devuan base with the current version of CDE as the desktop, augmented by some current, maintained Motif applications like the ones made by [fastestcode.org](https://fastestcode.org/). This would give us a system to work from and further explore which elements of a modern UI and applications we'd need to implement in Motif (think everything from a wifi manager to really complex stuff like an email client and web browser). Of course, this is just my take, and I'm open to any suggestions, especially from programmers and developers with experience in these matters.

KyleCardoza commented 2025年02月11日 17:55:32 +01:00

There is also the possibility of starting with Linux from Scratch as a base, and using the Unix SVR4 packaging tools to create a truly independent Linux distro.

There is also the possibility of starting with Linux from Scratch as a base, and using the Unix SVR4 packaging tools to create a truly independent Linux distro.

KyleCardoza commented 2025年02月11日 17:57:31 +01:00

In any case, ultimate responsibility for updating packages and following security patches falls on package maintainers -- that is, volunteers who track a third-party package and create updated distro packages as needed.

In any case, ultimate responsibility for updating packages and following security patches falls on package maintainers -- that is, volunteers who track a third-party package and create updated distro packages as needed.

thomholwerda commented 2025年02月11日 22:56:45 +01:00

While it would be insanely cool to go with SVR4 packaging tools, the packaging burden would be so massive... Is it worth it? Is it even realistic? Ideally that would be awesome, but I fear reality might stump this one.

While it would be insanely cool to go with SVR4 packaging tools, the packaging burden would be so massive... Is it worth it? Is it even realistic? Ideally that would be awesome, but I fear reality might stump this one.

vooshy commented 2025年02月11日 23:07:32 +01:00

Tried an initial test on Devuan with CDE on Qemu, downloaded devuan_daedalus_5.0.1_amd64_netinstall.iso ran through the install selecting "standard system tools" only on task select. Once logged in used a script from sourceforge as a basis (was missing xinit)

apt-get -y install autoconf automake libtool git build-essential g++ apt-get -y lib{xt,xmu,xft,xinerama,xpm,pam,motif,ssl,xaw7,x11,xss,tirpc,jpeg,freetype6,utempter,xrender}-dev apt-get -y tcl-dev ksh m4 ncompress xfonts-100-dpi-transcoded xfonts-75-dpi-transcoded rpcbind bison patch xbitmaps x11proto-fonts-dev flex opensp x11-xserver-utils liblmdb-dev xinit git clone https://git.code.sf.net/p/cdesktopenv/code cdesktopenv-code cd cdesktopenv-code/cde ./autogen.sh ./configure make sudo make install startx /usr/dt/bin/Xsession

Tried an initial test on Devuan with CDE on Qemu, downloaded devuan_daedalus_5.0.1_amd64_netinstall.iso ran through the install selecting "standard system tools" only on task select. Once logged in used a script from [sourceforge]([url](https://sourceforge.net/p/cdesktopenv/wiki/LinuxBuild/)) as a basis (was missing xinit) `apt-get -y install autoconf automake libtool git build-essential g++ apt-get -y lib{xt,xmu,xft,xinerama,xpm,pam,motif,ssl,xaw7,x11,xss,tirpc,jpeg,freetype6,utempter,xrender}-dev apt-get -y tcl-dev ksh m4 ncompress xfonts-100-dpi-transcoded xfonts-75-dpi-transcoded rpcbind bison patch xbitmaps x11proto-fonts-dev flex opensp x11-xserver-utils liblmdb-dev xinit git clone https://git.code.sf.net/p/cdesktopenv/code cdesktopenv-code cd cdesktopenv-code/cde ./autogen.sh ./configure make sudo make install startx /usr/dt/bin/Xsession`

KyleCardoza commented 2025年02月11日 23:15:49 +01:00

That's very interesting as a way to get started. It'll need some tweaks, to get the dtlogin started automatically at boot, but still, very cool.

That's very interesting as a way to get started. It'll need some tweaks, to get the dtlogin started automatically at boot, but still, very cool.

KyleCardoza commented 2025年02月11日 23:16:25 +01:00

@thomholwerda wrote in #6 (comment):

While it would be insanely cool to go with SVR4 packaging tools, the packaging burden would be so massive... Is it worth it? Is it even realistic? Ideally that would be awesome, but I fear reality might stump this one.

As a first step, no, not realistic. However, it could be a longer term goal, as part of the agenda of "doing it the Unix way".

@thomholwerda wrote in https://codeberg.org/ChiselOS/chisel/issues/6#issuecomment-2813103: > While it would be insanely cool to go with SVR4 packaging tools, the packaging burden would be so massive... Is it worth it? Is it even realistic? Ideally that would be awesome, but I fear reality might stump this one. As a first step, no, not realistic. However, it could be a longer term goal, as part of the agenda of "doing it the Unix way".

r1w1s1 commented 2025年02月11日 23:31:21 +01:00

I like Slackware because it's very simple to customize :) the package system also simple.

I like Slackware because it's very simple to customize :) the package system also simple.

thomholwerda commented 2025年02月12日 00:24:21 +01:00

@vooshy wrote in #6 (comment):

Tried an initial test on Devuan with CDE on Qemu, downloaded devuan_daedalus_5.0.1_amd64_netinstall.iso ran through the install selecting "standard system tools" only on task select. Once logged in used a script from sourceforge as a basis (was missing xinit)

apt-get -y install autoconf automake libtool git build-essential g++ apt-get -y lib{xt,xmu,xft,xinerama,xpm,pam,motif,ssl,xaw7,x11,xss,tirpc,jpeg,freetype6,utempter,xrender}-dev apt-get -y tcl-dev ksh m4 ncompress xfonts-100-dpi-transcoded xfonts-75-dpi-transcoded rpcbind bison patch xbitmaps x11proto-fonts-dev flex opensp x11-xserver-utils liblmdb-dev xinit git clone https://git.code.sf.net/p/cdesktopenv/code cdesktopenv-code cd cdesktopenv-code/cde ./autogen.sh ./configure make sudo make install startx /usr/dt/bin/Xsession

That looks like a great start, assuming Devuan is the way we want to go.

@vooshy wrote in https://codeberg.org/ChiselOS/chisel/issues/6#issuecomment-2813120: > Tried an initial test on Devuan with CDE on Qemu, downloaded devuan_daedalus_5.0.1_amd64_netinstall.iso ran through the install selecting "standard system tools" only on task select. Once logged in used a script from sourceforge as a basis (was missing xinit) > > `apt-get -y install autoconf automake libtool git build-essential g++ apt-get -y lib{xt,xmu,xft,xinerama,xpm,pam,motif,ssl,xaw7,x11,xss,tirpc,jpeg,freetype6,utempter,xrender}-dev apt-get -y tcl-dev ksh m4 ncompress xfonts-100-dpi-transcoded xfonts-75-dpi-transcoded rpcbind bison patch xbitmaps x11proto-fonts-dev flex opensp x11-xserver-utils liblmdb-dev xinit git clone https://git.code.sf.net/p/cdesktopenv/code cdesktopenv-code cd cdesktopenv-code/cde ./autogen.sh ./configure make sudo make install startx /usr/dt/bin/Xsession` That looks like a great start, assuming Devuan is the way we want to go.

KyleCardoza commented 2025年02月12日 17:47:52 +01:00

There is also the option of using "buildroot" to build a base system image, baking in tools to build native packages (in whatever format, such as dpkg, txz, or SVR4 pkg).

There is also the option of using "buildroot" to build a base system image, baking in tools to build native packages (in whatever format, such as dpkg, txz, or SVR4 pkg).

KyleCardoza commented 2025年02月12日 17:48:52 +01:00

Traditional Unix systems, IIRC, didn't put everything into packages like Debian, they had a big fat base system tarball, and packaged extras in .pkg files. That simplifies things considerably, no?

Traditional Unix systems, IIRC, didn't put everything into packages like Debian, they had a big fat base system tarball, and packaged extras in .pkg files. That simplifies things considerably, no?

thomholwerda commented 2025年02月12日 23:53:54 +01:00

I've been trying to find a proper description of pkg in classic UNIX and how they work, and I haven't found anything yet that makes sense to me. I'm most familiar with what HP-UX does - its depot package management system is awesome - but I'm not sure if that's even related to SVR4 pkg.

I've been trying to find a proper description of pkg in classic UNIX and how they work, and I haven't found anything yet that makes sense to me. I'm most familiar with what HP-UX does - its depot package management system is awesome - but I'm not sure if that's even related to SVR4 pkg.

KyleCardoza commented 2025年02月13日 02:04:13 +01:00

https://heirloom.sourceforge.net/pkgtools.html (though the source from there is not buildable currently, there is a maintained fork here: https://github.com/mamccollum/pkgsuite)

https://heirloom.sourceforge.net/pkgtools.html (though the source from there is not buildable currently, there is a maintained fork here: https://github.com/mamccollum/pkgsuite)

KyleCardoza commented 2025年02月13日 02:07:31 +01:00

There is also a ksh93 script that makes building pkg files easier: https://www.lighterra.com/pkgmake/manual.html

There is also a ksh93 script that makes building pkg files easier: https://www.lighterra.com/pkgmake/manual.html

KyleCardoza commented 2025年02月13日 02:25:22 +01:00

As an experiment, I'm currently going through the "Linux from Scratch" process, with the modification of adding the above linked tools, and when I get to building the final system, each package will get made into a .pkg, which then gets installed. Strictly an experiment, but I feel it's worth trying.

As an experiment, I'm currently going through the "Linux from Scratch" process, with the modification of adding the above linked tools, and when I get to building the final system, each package will get made into a .pkg, which then gets installed. Strictly an experiment, but I feel it's worth trying.

r1w1s1 commented 2025年02月13日 02:26:15 +01:00

@KyleCardoza wrote in #6 (comment):

Traditional Unix systems, IIRC, didn't put everything into packages like Debian, they had a big fat base system tarball, and packaged extras in .pkg files. That simplifies things considerably, no?

Slackware uses that way, big tarball and use a Slackbuild which is a shell script to build the package and the pkgtools (makepkg, upgradepkg and so on)

A example of Slackbuild
https://git.sr.ht/~r1w1s1/slackbuilds/tree/main/item/feh/feh.SlackBuild

@KyleCardoza wrote in https://codeberg.org/ChiselOS/chisel/issues/6#issuecomment-2814638: > Traditional Unix systems, IIRC, didn't put everything into packages like Debian, they had a big fat base system tarball, and packaged extras in .pkg files. That simplifies things considerably, no? Slackware uses that way, big tarball and use a Slackbuild which is a shell script to build the package and the pkgtools (makepkg, upgradepkg and so on) A example of Slackbuild https://git.sr.ht/~r1w1s1/slackbuilds/tree/main/item/feh/feh.SlackBuild

KyleCardoza commented 2025年02月13日 02:48:59 +01:00

Ultimately, it may be simpler to just do basically that -- but we would still need to decide on a standard way to run non-base-system stuff.

Ultimately, it may be simpler to just do basically that -- but we would still need to decide on a standard way to run non-base-system stuff.

miah commented 2025年02月14日 18:31:55 +01:00

@r1w1s1 wrote in #6 (comment):

@KyleCardoza wrote in #6 (comment):

Traditional Unix systems, IIRC, didn't put everything into packages like Debian, they had a big fat base system tarball, and packaged extras in .pkg files. That simplifies things considerably, no?

Slackware uses that way, big tarball and use a Slackbuild which is a shell script to build the package and the pkgtools (makepkg, upgradepkg and so on)

A example of Slackbuild https://git.sr.ht/~r1w1s1/slackbuilds/tree/main/item/feh/feh.SlackBuild

Building on this, the BSD's have file sets for the system, and a packaging system for the rest.

OpenBSD for example:

https://www.openbsd.org/faq/faq4.html#FilesNeeded

The complete OpenBSD installation is broken up into a number of file sets:
bsd 	The kernel (required)
bsd.mp 	The multi-processor kernel (only on some platforms)
bsd.rd 	The ramdisk kernel
base76.tgz 	The base system (required)
comp76.tgz 	The compiler collection, headers and libraries
man76.tgz 	Manual pages
game76.tgz 	Text-based games
xbase76.tgz 	Base libraries and utilities for X11 (requires xshare76.tgz)
xfont76.tgz 	Fonts used by X11
xserv76.tgz 	X11's X servers
xshare76.tgz 	X11's man pages, locale settings and includes

If you were going the LFS route, these file sets might be useful to think about when building your PKG's.

The upgrade process is also divided up between system and packages; which might be a interesting thought for Chisel. syspatch/sysupgrade for the "OS", and pkg_add -u for the rest.

@r1w1s1 wrote in https://codeberg.org/ChiselOS/chisel/issues/6#issuecomment-2816783: > @KyleCardoza wrote in #6 (comment): > > > Traditional Unix systems, IIRC, didn't put everything into packages like Debian, they had a big fat base system tarball, and packaged extras in .pkg files. That simplifies things considerably, no? > > Slackware uses that way, big tarball and use a Slackbuild which is a shell script to build the package and the pkgtools (makepkg, upgradepkg and so on) > > A example of Slackbuild https://git.sr.ht/~r1w1s1/slackbuilds/tree/main/item/feh/feh.SlackBuild Building on this, the BSD's have file sets for the system, and a packaging system for the rest. OpenBSD for example: https://www.openbsd.org/faq/faq4.html#FilesNeeded ``` The complete OpenBSD installation is broken up into a number of file sets: bsd The kernel (required) bsd.mp The multi-processor kernel (only on some platforms) bsd.rd The ramdisk kernel base76.tgz The base system (required) comp76.tgz The compiler collection, headers and libraries man76.tgz Manual pages game76.tgz Text-based games xbase76.tgz Base libraries and utilities for X11 (requires xshare76.tgz) xfont76.tgz Fonts used by X11 xserv76.tgz X11's X servers xshare76.tgz X11's man pages, locale settings and includes ``` If you were going the LFS route, these file sets might be useful to think about when building your PKG's. The upgrade process is also divided up between system and packages; which might be a interesting thought for Chisel. syspatch/sysupgrade for the "OS", and `pkg_add -u` for the rest.

thomholwerda commented 2025年02月14日 18:58:57 +01:00

The BSD way is such a nice, clean way of handling this. If we can realistically bring this to Linux, I'm 100% for it.

The BSD way is such a nice, clean way of handling this. If we can realistically bring this to Linux, I'm 100% for it.

KyleCardoza commented 2025年02月15日 22:46:59 +01:00

I had a brief conversation with the guy behind Toybox, which is a busybox-like thing with an associated build script called mkroot, which has the goal of being a minimal self-hosting, reproducible base for Linux systems. That is exactly the sort of thing I feel we should keep an eye on, once we have something to run on a distro.

I had a brief conversation with the guy behind Toybox, which is a busybox-like thing with an associated build script called mkroot, which has the goal of being a minimal self-hosting, reproducible base for Linux systems. That is exactly the sort of thing I feel we should keep an eye on, once we have something to run on a distro.