What would you like to see over the next few FreeBSD versions?

I believe FreeBSD has a significant opportunity to lead in the broader code ecosystem, beyond just focusing on its next versions.

Even from my perspective as someone without deep technical expertise, I can see that navigating application dependencies is a major challenge. For instance, I've encountered issues where building applications requires a specific Python version that only works with a particular Java and JDK version, which in turn demands a certain Qt and Perl version – a complex web of dependencies; The complexity is perhaps far greater than what I have experienced.

Years ago, there was talk of 'Version Control' in Java – perhaps meaning compartmentalizing applications to specific code versions, or maybe suggesting a way for them to function despite updates? FreeBSD could explore a similar concept: ensure that applications run smoothly REGARDLESS of code updates on the computer; on the other hand, encourage applications to be built to work WITH different versions- older and newer versions- of languages. Ideally, an application built with Java 17 should still work well even after the computer's Java is updated to version 24. This is a significant challenge, and one might argue that features from Java 17 could be obsolete. However, application code needs to anticipate these updates, or be designed with enough flexibility to 'grow' with changes in code versions.

This, in turn, places an onus on languages and frameworks like Python, Perl, Java, Qt, Ruby Go, Cuda and many others that power up hardware and software, to prioritize robust design with backward (and perhaps 'forward') compatibility in mind; The current code ecosystem, while amazing, can feel disconnected and somewhat chaotic.

As programmers cautiously embrace AI, this complex task of achieving compatibility across the ecosystem could be tackled with structured use of AI's code intelligence. This could bring a new level of harmony, allowing older applications to be revitalized, current applications developed, for example, on Java 24 and Python 3.1 to have extended lifespans, and preventing 'pkg update' and 'pkg upgrade' from accidentally rendering installed applications unusable.

Irrespective of the validity of this reasoning, building in compatibility and bringing about harmony between frameworks is essentially a good practice. It's a way to ensure newer versions of application code, hardware, and operating systems work seamlessly and remain functional for years. Would FreeBSD initiate a conversation around this? Would freeBSD reach out far and wide to take this forward?
 
Sivan! said:
I believe FreeBSD has a significant opportunity to lead in the broader code ecosystem, beyond just focusing on its next versions.

Even from my perspective as someone without deep technical expertise, I can see that navigating application dependencies is a major challenge. For instance, I've encountered issues where building applications requires a specific Python version that only works with a particular Java and JDK version, which in turn demands a certain Qt and Perl version – a complex web of dependencies; The complexity is perhaps far greater what I have experienced.
Click to expand...
Dependency nonsense is much worse on Linux. Trust me. Instead of just affecting your third-party software, it also affects your main system too. GNU/Linux doesn't have base, it's all packages from the same repository as the third party software.
 
RetroComputingCollector said:
Dependency nonsense is much worse on Linux. Trust me. Instead of just affecting your third-party software, it also affects your main system too. GNU/Linux doesn't have base, it's all packages from the same repository as the third party software.
Click to expand...
This is freeBSD forum, so I addressed freeBSD, my post is not in any manner a criticism on freeBSD. Please don't read "freeBSD" as freeBSD, but as freeBSD, Linux, Windows amd Android; Java or python is mentioned, but this doesn't exclude many other widely deployed languages. No one, neither frameworks, nor Corporations are singled out by the example names thrown about in this post, nor is it to be taken as insensivity to the enormous brilliance of those who write code. The comment is about the disconnect between the environments and the innovations and NOT about the names mentioned.
 
RetroComputingCollector said:
Dependency nonsense is much worse on Linux.
Click to expand...
I know. When LLVM came in, it made it so a lot of dependency hell from Linux got cleaned up. That was a low hanging fruit to spot, which could have gone unnoticed for a decade. More got cleaned up a bit more over time having to do with LGPL with some GCC. After LLVM in FreeBSD's ports helped get dependencies cleaned up, it made it so they were able to see GCC that its dependencies later got cleaned up.

To improve much more will take improving the structure of upstream programs.
 
vermaden said:
Also as ZSH is MIT licensed - inclusion into the FreeBSD Base System.
Click to expand...

I'm not sure. Zsh is not quite bourne shell compatible. I prefer bash for that reason. Actively leading new users to zsh might lead to lots of code being thrown around that isn't working in actual shellscripts anymore.

I think it is good the way it is, let people install one of zsh or bash with no influence.
 
Some kind of FreeBSD-specific equivalent of Docker that is based on Jails that enables you to deploy web apps rapidly.
While I understand that there are things like CBSD and AppJail, I would like more of a first-party built-in solution like the way jails is.
 
Officially supports upgrade by extracting base.txz/kernel.txz, or using bsdinstall. So one can download the txz files or the image with torrents or from other non-official mirrors, then check sha256 hashes with the offical ones before installation. This will accerlate the upgrade compared with freebsd-update -r release fetch, compiling from source, or maybe pkgbase, and someone with intermittent internet connection will also benefit. I guess adding the feature is not very hard, since FreeBSD can also be installed with just extracing base.txz/kernel.txz manually.
 
cracauer@ said:
I'm not sure. Zsh is not quite bourne shell compatible. I prefer bash for that reason. Actively leading new users to zsh might lead to lots of code being thrown around that isn't working in actual shellscripts anymore.

I think it is good the way it is, let people install one of zsh or bash with no influence.
Click to expand...
Unfortunatey, I think both are NOT likely to be in base.

shells/bash is GPL'ed. Would NOT be in consideration with it.

shells/zsh BUILD_DEPENDs on lang/perl5.36, so to incorporate shells/zsh into base, lang/perl5.36 needs to be incorporated, too. But perl has a history that once included into base but removed afterwards. So unlikely.

In my humble opinion, most possible options would be allowing shells to be installed into /bin, if NOT depending on shared object OUTSIDE /lib (including statically linked), just like kmod ports are allowed to be installed under /boot/modules, which is outside of /usr/local.
This way, under PkgBase environment, it would be almost seamless with base.
 
raul_comodoro said:
I would like to see a special edition using KDE Trinity, honestly it has not so very problems and is very light using memory ans resources in general.
Click to expand...
I really like Trinity desktop, but I do not think it is secure: it is a very small development team and does not have security updates. If they find issues in the next version of the desktop (which comes out quite often) they simply fix them. I wish this were not the case because I like it much more than the current Kde, but unfortunately, that is my impression.
 
Whattteva said:
Some kind of FreeBSD-specific equivalent of Docker that is based on Jails that enables you to deploy web apps rapidly.
Click to expand...
I only entertain bare-metal, but FreeBSD could use more compatibility with whatever Node does.

Joomla CMS uses it, and some module didn't install on 14.3 (couldn't run one of my websites). bun.js also doesn't have a native FreeBSD build (can't run up-to-date 2004Scape/have to use an older build still using node/npm).
 
cracauer@ said:
I'm not sure. Zsh is not quite bourne shell compatible. I prefer bash for that reason. Actively leading new users to zsh might lead to lots of code being thrown around that isn't working in actual shellscripts anymore.

I think it is good the way it is, let people install one of zsh or bash with no influence.
Click to expand...
You misunderstood me.

I write all scripts in POSIX /bin/sh - and all UNIX scripts are meant to be written this way.

FreeBSD also comes with CSH/TCSH - does anyone write shell scripts in them? Mostly no because its useless.

ZSH is a POSIX /bin/sh compatible shell - meaning that all POSIX /bin/sh code will run perfectly fine inside ZSH - but that is not what ZSH is for - ZSH is for INTERACTIVE use - not for scripts.

Of course if there is some case where you need - for example - arrays - then it does no matter if you use ZSH or Bash - its NOT POSIX /bin/sh and its already bad.

So - to summarize.

Keep /bin/sh as DEFAULT FreeBSD shell.

Keep CSH/TCSH for historical reasons.

Include ZSH for interactive shell for people like me (and many others) that want to be sure that ZSH will be working even if all third party packages are broken on FreeBSD.
 
vermaden said:
You misunderstood me.

I write all scripts in POSIX /bin/sh - and all UNIX scripts are meant to be written this way.

FreeBSD also comes with CSH/TCSH - does anyone write shell scripts in them? Mostly no because its useless.

ZSH is a POSIX /bin/sh compatible shell - meaning that all POSIX /bin/sh code will run perfectly fine inside ZSH - but that is not what ZSH is for - ZSH is for INTERACTIVE use - not for scripts.

Of course if there is some case where you need - for example - arrays - then it does no matter if you use ZSH or Bash - its NOT POSIX /bin/sh and its already bad.

So - to summarize.

Keep /bin/sh as DEFAULT FreeBSD shell.

Keep CSH/TCSH for historical reasons.

Include ZSH for interactive shell for people like me (and many others) that want to be sure that ZSH will be working even if all third party packages are broken on FreeBSD.
Click to expand...
Zsh requires perl, which was kicked out of base for a good reason. The project would have to make a deperled fork of zsh for it to work, and even though I would want zsh, I can't see them doing that.
 
LoganGreystone said:
I really like Trinity desktop, but I do not think it is secure: it is a very small development team and does not have security updates. If they find issues in the next version of the desktop (which comes out quite often) they simply fix them. I wish this were not the case because I like it much more than the current Kde, but unfortunately, that is my impression.
Click to expand...
Thereis a linux Q4OS using KDE Trinity version now, it is very secure and can be updated and upgraded without any problems
 
raul_comodoro said:
Thereis a linux Q4OS using KDE Trinity version now, it is very secure and can be updated and upgraded without any problems
Click to expand...
I known Q4OS, but it is secure? I think if Trinity desktop is secure, why is not offer by default in distros like Debian, Fedora, OpenSuSE or in others BSDs like OpenBSD, who kept KDE3 alongside KDE4 in their repositories for a long time? Mate (from GNOME2) have in other distros, but Trinity not. There are logs from Q4OS' updates to see if it have more security updates than Debian (for the packages from Triniry desktop)? I have doubts that Trinity's Konqueror is safe.
I seriously do not hate Trinity, if I see that it is really secure I will join your call for someone to port it to FreeBSD because I would use it myself.
 
You must log in or register to reply here.
Back
Top