A short tale of my Serpent Journey

[vecst]

cpu: ryzen 7 5800x3d
gpu: Nvidia rtx 4070 12gb OC
mobo: 570x
ram: 64gb
Monitors: 2

Installation Process:
That's got to be one of the cleanest terminal installers I've seen. Installation was quick, and pretty easy.
It would be cool if it could find a completely empty drive and format it, It feels a bit off having to quit the installer, open gparted, set up partitions and reopen the installer.
Something as simple as the installer pausing and telling the user that it can't create the boot partition and or use unformatted space and let the user set up partitions and continue would be a great improvement.

First install:
I wanted to try cosmic, I saw the warning, but I figured why not. After I reboot it only loads one monitor, and the password field is selected, but there's no user name. I entered my password, but it didn't work.
I couldn't see a mouse and I couldn't navigate with tab, but if I clicked then it would take me off the password field box so I assumed a mouse was working.

Second install:
Gnome installation went even smoother, just because I already had the partitions set up. Everything booted up, both monitors came on and I gotta say everything felt smooth. I was impressed with the system monitor, moss ran quick, and default scaling looked great. For an Alpha it feels really good.
I didn't see apache httpd, nginx, or caddy in moss and because I'm most familiar with apache, I decided to try to build it. APR, APR-util, and APR-iconv are also not in the repo, which depends on having expat libs. The expat libs were in the repo, but apr-util couldn't find them. You must configure apr-util with the --with-expat=$dir --with-apr=$aprDir
I could have probably built apr where it installed the libraries better, but it defaulted to /usr/local/apr/, and the expat libs were in /usr/local/lib/
After all of that Apache httpd would finally build. I had to create a user and group for apache and configure httpd a bit, but it did start, and serve up a page.

After I got that running I decided to install the nvidia drivers and to a reboot, and that's where my journey ends. On the reboot, I am just presented with a black lit up screen, Nothing ever loads, no debug messages work, I can't access a tty, nothing.
I am very hopeful for this operating system though. I absolutely love the feel of it.

[ermo]

cpu: ryzen 7 5800x3d gpu: Nvidia rtx 4070 12gb OC mobo: 570x ram: 64gb Monitors: 2

Installation Process: That's got to be one of the cleanest terminal installers I've seen. Installation was quick, and pretty easy. It would be cool if it could find a completely empty drive and format it, It feels a bit off having to quit the installer, open gparted, set up partitions and reopen the installer. Something as simple as the installer pausing and telling the user that it can't create the boot partition and or use unformatted space and let the user set up partitions and continue would be a great improvement.

AerynOS/lichen#45 <- Would this be sufficient as a workaround for now?

[vecst]

That's definitely better than not having it. I would argue that it would be better if the installer could pause while the partitions are being setup and continue, but I've had worse install experiences from finished operating systems.
I don't recall the installer complaining about not having an XBOOTLDR, and I definitely didn't make one, maybe that's what caused my issue after updating nvidia drivers.
The only partitions I was required to create were the EFI and root

[ermo]

FAT32 (which is required by the ESP spec) is just not a very robust FS.

Hence, for dual-boot purposes, we are moving to require a Linux extended boot / XBOOTLDR partition, because we can then later add support for e.g. rescue images and a nicer file system for holding the kernels, initrds and (in a hypothetical future case) rescue images.

The installer currently runs its detection routines completely at startup. For what you propose to be relevant, we would have to basically restart the detection routines I think. Not a bad idea to have that capability in fact, but I am not sure that now is the time for this kind of refinement, just so that's said.

[vecst]

I'm not disagreeing with you, I'm just saying it didn't seem that having an XBOOTLDR was a requirement, my install went fine without it.
I was thinking even simpler than that, just some wrapper that prints the message and waits to start the installer, but maybe that would feel disconnected and clunky. I'm just rambling anyway the message is better than not having one

[ermo]

We are going to work on incorporating your suggestions FWIW.

[vecst]

Oh cool. When I get some spare time I wouldn't mind doing some regular testing or helping out wherever I could be useful

[moumn-almunawy]

Iam running it for about a week now, I have i3 1215u with 8 gigs of ram, the installation was smooth and I chose gnome, there is some flickering here and there but itis good, I wish kde was in the repo :)

[vecst]

I've never been big on kde, but if it's something you want why not work on porting it over?

[moumn-almunawy]

Sadly I can't, I don't know how nor do I have the resources to build such big project

[vecst]

What resources do you need? You have the internet and a computer. Just doing a quick search and I found a guide from LFS, and some guy who built it for ubuntu. Don't be scared to fail, sometimes that makes success more fun

[ermo]

For context, we don't have the necessary "is this actually sane from an ABI perspective?" machinery yet, so anything but the stuff that Ikey can maintain on pure experience + gut feel is not yet a priority.

I am personally a KDE user, but I will also have to wait until we've developed the necessary tooling for making maintaining KDE a good packager/maintainer/developer experience on Serpent OS, just so that is said out loud.

Behind the scenes, we are currently working on the actual design of the components and the pipeline into which said components fit. =)