Language Selection

English French German Italian Portuguese Spanish

Project Trident 2020 OS Migration

Filed under
OS
GNU
Linux
BSD

After several months of examination and testing of the various operating systems that are available right now, we have reached a conclusion. Project Trident will rebasing with Void Linux.

Read more

Also: Project Trident Switching From TrueOS/FreeBSD Distribution To Basing On Void Linux

Project Trident Ditches BSD for Linux

  • Project Trident Ditches BSD for Linux

    Recently, Project Trident announced that they had been working behind the scenes to move away from FreeBSD. This is quite a surprising move (and an unprecedented one).

    According to a later post, the move was motivated by long-standing issues with FreeBSD. These issues include “hardware compatibility, communications standards, or package availability continue to limit Project Trident users”. According to a conversation on Telegram, FreeBSD has just updated its build of the Telegram client and it was nine release behind everyone else.

    The lead dev of Project Trident, Ken Moore, is also the main developer of the Lumina Desktop. The Lumina Desktop has been on hold for a while because the Project Trident team had to do so much work just to keep their packages updated. (Once they complete the transition to Void Linux, Ken will start working on Lumina again.)

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

More in Tux Machines

Raspberry Pi 4 V3D Driver Reaches OpenGL ES 3.1 Conformance

  • Raspberry Pi 4 V3D Driver Reaches OpenGL ES 3.1 Conformance

    The V3D Gallium3D driver that most notably offers the open-source graphics support for the Raspberry Pi 4 is now an official OpenGL ES 3.1 implementation. Consulting firm Igalia has continued working on the V3D driver since Eric Anholt left Broadcom. Igalia had ironed out OpenGL ES 3.1 support and last month also went on to begin tackling geometry shaders and more.

  • Iago Toral: I am working on the Raspberry Pi 4 Mesa V3D driver

    Yeah… this blog post is well overdue, but better late than never! So yes, I am currently working on progressing the Raspberry Pi 4 Mesa driver stack, together with my Igalian colleagues Piñeiro and Chema, continuing the fantastic work started by Eric Anholt on the Mesa V3D driver. The Raspberry Pi 4 sports a Video Core VI GPU that is capable of OpenGL ES 3.2, so it is a big update from the Raspberry Pi 3, which could only do OpenGL ES 2.0. Another big change with the Raspberry Pi 4 is that the Mesa v3d driver is the driver used by default with Raspbian. Because both GPUs are quite different, Eric had to write an all new driver for the Raspberry Pi 4, and that is why there are two drivers in Mesa: the VC4 driver is for the Raspberry Pi 3, while the V3D driver targets the Raspberry Pi 4.

  • Raspberry Pi 4 V3D driver gets Geometry Shaders

    I actually landed this in Mesa back in December but never got to announce it anywhere. The implementation passes all the tests available in the Khronos Conformance Tests Suite (CTS). If you give this a try and find any bugs, please report them here with the V3D tag.

  • Raspberry Pi 4 V3D driver gets OpenGL ES 3.1 conformance

    So continuing with the news, here is a fairly recent one: as the tile states, I am happy to announce that the Raspberry Pi 4 is now an OpenGL ES 3.1 conformant product!. This means that the Mesa V3D driver has successfully passed a whole lot of tests designed to validate the OpenGL ES 3.1 feature set, which should be a good sign of driver quality and correctness. It should be noted that the Raspberry Pi 4 shipped with a V3D driver exposing OpenGL ES 3.0, so this also means that on top of all the bugfixes that we implemented for conformance, the driver has also gained new functionality! Particularly, we merged Eric’s previous work to enable Compute Shaders.

today's howtos

Software tips for nerds

I use Vim for almost a decade now, which is probably the longest I’ve sticked to some application. During that time, I repeatedly tried to use it as an IDE but inevitably failed each time. Let’s remember eclim as my Java IDE. I work almost exclusively on projects written in Python, which can be beautifully done in Vim but because of a gap in my skills, I was reliant on PyCharm. Thankfully, not anymore. My biggest issue was misusing tabs instead of buffers and poor navigation within projects. Reality check, do you open one file per tab? This is a common practice in other text editors, but please know that this is not the purpose of tabs in Vim and you should be using buffers instead. Please, give them a chance and read Buffers, buffers, buffers. Regarding project navigation, have you ever tried shift shift search in PyCharm or other JetBrains IDE? It’s exactly that thing, that you wouldn’t even imagine but after using it for the first time, you don’t understand how you lived without. What it does is, that it interactively fuzzy-finds files and tags (classes, functions, etc) that matches your input, so you can easily open them. In my opinion, this unquestionably defeats any other way of project navigation like using a file manager, NerdTree, or find in the command line. Fortunately, both of these problems can be solved by fzf.vim, which quickly became one of my most favorite Vim plugins. Please read this section about fzf plugin. I am forever grateful to Ian Langworth for writing VIM AFTER 11 YEARS, EVERYTHING I MISSED IN “VIM AFTER 11 YEARS” and VIM AFTER 15 YEARS articles. If you are a Vim user, those are an absolute must-read. Read more

today's howtos