BITCH about Trident-Beta HERE


You may want to search up “FreeBSD Ports”. FreeBSD (TrueOS) are basically the kernel and standard utilities. Pretty much all user applications are in the Ports tree. I don’t recall the current count but Ports cover pretty much everything available on Linux.

XFCE, LXDE, a bunch of others are already available as ports. Project Trident will make it easier to choose something other than Lumina, but even now one can install the packages for them (if they are available in the repos) or build them from source. There is nothing preventing you from running what you want; huge difference between “what is in the default install” vs “what can you do”.

I’m a good example of this: I don’t run Lumina, KDE, Gnome, or any of the popular Desktop environments. I run WindowMaker as my window manager (I don’t like DEs, too bloated), like I’ve been doing for a long time. But it was not available in the default install, so all I did was install the packages.


Oh I see, I guess I can get it to look like ArchLabs then.

Is it easy to build them from source?

Whats the difference between window manager and DEs?


Yes they are easy to build from source but if someone else has built the package, it’s easier to just install it.

The following is all in the context of the X Window system used on Linux, *BSD, etc and may be purely my opinion:
WindowManager simply manages Windows. (this is not opinion). Managing windows is basically, putting them on the screen, decorating them (buttons, borders, resize controls), drawing and redrawing them. Search for TWM as the classic minimalist Window Manager.

Desktop Environment manages everything related to a desktop: hooks into a window manager, hooks into configuration, typically they will have their own set of applications for “everything” (filemanagers, terminal windows, control panels, etc). DEs really only are good providing a consistent look and feel (hence Themes) for everything displayed. Problem is you are limited applications that understand a specific DE control. These controls can be standard (based on X protocol, like Lumina) or “own baked” like KDE and Gnome. Own baked means that some applications may not follow the themeing and control of a DE.

DEs typically wind up bloated and use a lot of resources. MS-Windows is a DE, not a “window manager”.


I see, so without xfce, I can just have openbox (for the window manager) and polybar (for the taskbar) and I can whatever I want to, is that correct mate?


Yep that should work. Configuration for some things will mean you hand edit files in your home directory, you get to learn about XResources, you get to choose the applications you like for any given task.


With BETA3 often but not always the system has no connection to the network after booting it up. The output of rc-status is:

root@trident-1126:/usr/home/rudy # rc-status
Runlevel: default
 sysadm                                                         [  started 00:04:03 (0) ]
 webcamd                                                                    [  started  ]
 netmount                                                                   [  started  ]
 sndiod                                                                     [  started  ]
 trident_init                                                               [  started  ]
 microcode_update                                                           [  started  ]
 ntpdate                                                                    [  started  ]
 powerd++                                                                   [  started  ]
 moused                                                                     [  started  ]
 ntpd                                                           [  started 00:04:07 (0) ]
 local                                                                      [  started  ]
 pcdm                                                                       [  started  ]
 cupsd                                                          [  started 00:04:07 (0) ]
Dynamic Runlevel: hotplugged
 dhcpcd.re0                                                                 [  crashed  ]
 moused.ums0                                                                [  started  ]
Dynamic Runlevel: needed/wanted
 ldconfig                                                                   [  started  ]
 var                                                                        [  started  ]
 devfs                                                                      [  started  ]
 tmp                                                                        [  started  ]
Dynamic Runlevel: manual
 pcdm.vt9                                                                   [  started  ]

So dhcpcd.re0 is crashed. The remedial action is very simple:

root@trident-1126:/usr/home/rudy # rc-service dhcpcd.re0 restart
pgrep: Cannot get process list (kvm_getprocs: No such process)
 * Starting DHCP Client Daemon (re0) ...                                           [ ok ]

After the restart the connection to the network is established immediately.
With BETA2 I have never seen this phenomenon. Even if I boot up the boot environment of BETA2 now, the system is always connected.
How is it possible to have this failure may be three times out of ten bootings of BETA3?
The lines from dmesg with ‘re0’ are:

root@trident-1126:/usr/home/rudy # dmesg |grep 're0'
re0: <RealTek 8168/8111 B/C/CP/D/DP/E/F/G PCIe Gigabit Ethernet> port 0xe000-0xe0ff mem 0xd0004000-0xd0004fff,0xd0000000-0xd0003fff irq 17 at device 0.0 on pci3
re0: Using 1 MSI-X message
re0: Chip rev. 0x2c800000
re0: MAC rev. 0x00100000
miibus0: <MII bus> on re0
re0: Using defaults for TSO: 65518/35/2048
re0: Ethernet address: c8:60:00:99:75:2b
re0: netmap queues/slots: TX 1/256, RX 1/256
re0: link state changed to DOWN
re0: link state changed to UP

On BETA2 the output of dmesg for ‘re0’ is exactly the same.


The BETA3 just updated automatically (with two reboots). On my system this update was successful. I am writing this post on the new version. In BETA3-first-version the application ‘easytag’ could not be launched but now in this BETA3-2 it is working again. (It was working fine on BETA2.)

Good luck - it spared me writing another bitching post about the easytag issue! :wink:

Unfortunately the connecting issue is unchanged. My first boot into BETA3-2 resulted in a crashed dhcpcd.re0.


Sorry, I can’t make a fresh install of BETA3, because when I have to choose the place for the new system “Select Installation location” the field is empty as it was with the BETA2:

therefore I can’t move further for the next step. Now if I click on the “Go to Terminal” option than the terminal will come (of course this is the normal method). When the installer boots up, it can see the SSD and the HDD, but later the “Select Installation location” field is empty. My motherboard is an Wistron BROOK_SL MB 14277 - 1M
In the terminal I can’t use the gpart command, because I can’t login :frowning:
And the system.ctl can’t to start, this is the last visible error message of the installer.