2024: The year of desktop FreeBSD?

astyle said:
what gate-keeping? Windows and Apple certainly are guilty of non-technical gate-keeping... Back in 2000s, it was impossible to install any kind of database application (other than MS Access) on consumer-level Windows or Mac. But install Linux or FreeBSD on the same hardware - and wow, you can install the whole A(pache)M(ysql)P(hp) stack on it (actually running the stuff was limited by hardware specs).

As things stand now, an up-to-date UNIX-based DE can provide the exact same functionality as Windows and Mac - browsing the web (even Youtube), listening to music, watching videos, and more. When it comes to doing the same basic tasks and providing convenience, Open Source has reached feature parity with Win/Apple awhile ago.

BSD's are small volunteer-driven projects, so they don't have the resources necessary to support 'every piece of hardware imaginable'. Yeah, even Bluetooth and wi-fi did not get the level of attention needed to make them viable - there were other things on the devs' plates to worry about, while not exactly getting paid for the efforts.
Click to expand...

I already know all this. Gatekeeping happens when people disguise their system’s flaws or missing tools as 'features' and constantly compare their choices to others, trying to portray it superior or flawless. It's the same cult-like mentality that made me leave elitist communities like Arch Linux and Gentoo.

The entire conversation was about someone struggling with USB-related errors for years without finding help—neither from the Wiki nor the forum. Then, they tried GhostBSD, and the problem disappeared. I replied that GhostBSD solving these issues speaks volumes about FreeBSD’s priorities (focused on servers). Then, a bunch of people got 'triggered'.
 
fr0xk said:
The entire conversation was about someone struggling with USB-related errors for years without finding help—neither from the Wiki nor the forum.
Click to expand...
Sometimes you just can't read too deeply into it.

Hardware is cheap, just replace the crap that doesn't work with hardware that does. FreeBSD 14 still supports vastly more hardware than both Windows 11 and macOS 15 combined.
 
kpedersen said:
FreeBSD 14 still supports vastly more hardware than both Windows 11 and macOS 15 combined.
Click to expand...
I don't care if they support 30Y old hardware and some toasters. I can list a bunch if hardware that neither FreeBSD support nor Linux.

NVIDIA Jetson series, Clearpath Robotics' Husky and Jackal platforms, Intel RealSense cameras, and ABB RobotStudio, Agilent Technologies' GPC/SEC systems, Molecular Devices' plate readers, Horiba scientific instruments, and Thermo Fisher, Avid Pro Tools HDX systems, Universal Audio Apollo interfaces, MOTU audio interfaces, and Focusrite Scarlett interfaces

These are just few that went over my head. Now I'm not demanding FreeBSD or any Open Source operating system to support these. I'm not saying one should go and shop for hardware trashing existing hardware just to run FreeBSD. I'm saying that you are just gatekeeping FreeBSD and there's gatekeepers everywhere for different reasons but it's futile effort unless you are head of the project.

A better answer should be like this:

"FreeBSD is primarily designed as a server-centric command line operating system due to its multi-user design by default rooted from UNIX days, with most users and funding focused on server applications and that model has served well through large scale deployments. Although, you can download a display server and a desktop environment/window manager on top of it and use it like a desktop. FreeBSD supports various open source desktop environments and web browsers. If you are not used to them, adapting to these requires some time and effort to relearn workflows. FreeBSD's Wi-Fi and bluetooth support is limited, with compatibility varying by hardware model. Some wireless chipsets, like those from Atheros and Intel, work well with FreeBSD, but others may not. If you own compatible hardware, you're in a fortunate position; otherwise, the most effective solution is to acquire FreeBSD-supported hardware that meets your requirements and budget. If this isn't feasible, consider using alternative operating systems that offer broader hardware support without disrupting your existing workflow until FreeBSD support improves. I also recommend you to try desktop focused pre-configured BSD distributions like GhostBSD (based on FreeBSD-STABLE) and look for support in their forums where you'll likely get your question answered well.

Thank you for your interest in the FreeBSD project."

See, it's that easy. Gatekeeping is unnecessary and futile at best.
 
Cath O'Deray said:
That's not what it is.

forums.freebsd.org

ICYMI -$750k to improve modern laptop support

https://www.morningstar.com/news/globe-newswire/9234109/quantum-leap-research-and-freebsd-foundation-to-invest-750000-to-improve-laptop-support-and-usability Announced at EuroBSDCon 2024.
forums.freebsd.org forums.freebsd.org

And so on.
Click to expand...
I saw it like 20 mins ago. Really good news to be honest. Sufficient hardware support will bring a lot of developers who will able to focus on security & maintenance of FreeBSD. I hope this linuxemulator gets some improvement on it too and dhcpcd gets moved to the base system (ISC License). It can automatically configure DNS, default routes, and other settings based on DHCP information (if you use your smartphone internet connection through tethering, dhcpcd will able to automatically detect it and connect to it)
 
fr0xk said:
… just appears from nowhere
Click to expand...

1727213650367.pngAs if from nowhere, eleven commits changing eighteen files:

For a single commit to a single file.

Miracles happen every day.
 
fr0xk said:
dhcpcd gets moved to the base system (ISC License). It can automatically configure DNS, default routes, and other settings based on DHCP information (if you use your smartphone internet connection through tethering, dhcpcd will able to automatically detect it and connect to it)
Click to expand...
I thought dhclient is already in base and that's enough... After all, the base installer has it.
 
astyle said:
I thought dhclient is already in base and that's enough …
Click to expand...

I see a few bugs.

In addition, or overlapping, I like to think that dhcpcd will help to bring an end to palavers such as these:

Code: 
root@mowa219-gjp4-zbook-freebsd:~ # history | grep route\ delete\ default
   155  17:39   route delete default ; ifconfig gif0 down ; service netif stop em0 > & /dev/null ; ifconfig wlan0 destroy ; sleep 5 ; service netif start em0 > & /dev/null ; sleep 10 ; resolvconf -i ; route show default ; ping -4 -c 2 freshports.org
   249  9:15    route delete default ; ifconfig gif0 down ; service netif stop em0 > & /dev/null ; ifconfig wlan0 destroy ; sleep 5 ; service netif start wlan0 > & /dev/null ; sleep 10 ; resolvconf -i ; route show default ; ping -4 -c 2 freshports.org
   269  9:56    route delete default ; ifconfig gif0 down ; service netif stop em0 > & /dev/null ; ifconfig wlan0 destroy ; sleep 5 ; service netif start wlan0 > & /dev/null ; sleep 10 ; resolvconf -i ; route show default ; ping -4 -c 2 freshports.org
   276  10:14   route delete default ; ifconfig gif0 down ; service netif stop em0 > & /dev/null ; ifconfig wlan0 destroy ; sleep 5 ; service netif start wlan0 > & /dev/null ; sleep 10 ; resolvconf -i ; route show default ; ping -4 -c 2 freshports.org
   280  20:03   route delete default ; ifconfig gif0 down ; service netif stop em0 > & /dev/null ; ifconfig wlan0 destroy ; sleep 5 ; service netif start em0 > & /dev/null ; sleep 10 ; resolvconf -i ; route show default ; ping -4 -c 2 freshports.org
   363  10:22   route delete default ; ifconfig gif0 down ; service netif stop em0 > & /dev/null ; ifconfig wlan0 destroy ; sleep 5 ; service netif start em0 > & /dev/null ; sleep 10 ; resolvconf -i ; route show default ; ping -4 -c 2 freshports.org
   378  20:11   route delete default ; ifconfig gif0 down ; service netif stop em0 > & /dev/null ; ifconfig wlan0 destroy ; sleep 5 ; service netif start em0 > & /dev/null ; sleep 10 ; resolvconf -i ; route show default ; ping -4 -c 2 freshports.org
   571  18:15   route delete default ; ifconfig gif0 down ; service netif stop em0 > & /dev/null ; ifconfig wlan0 destroy ; sleep 5 ; service netif start em0 > & /dev/null ; sleep 10 ; resolvconf -i ; route show default ; ping -4 -c 2 freshports.org
   669  9:53    route delete default ; ifconfig gif0 down ; service netif stop em0 > & /dev/null ; ifconfig wlan0 destroy ; sleep 5 ; service netif start wlan0 > & /dev/null ; sleep 10 ; resolvconf -i ; route show default ; ping -4 -c 2 freshports.org
   747  2:45    route delete default ; ifconfig gif0 down ; service netif stop em0 > & /dev/null ; ifconfig wlan0 destroy ; sleep 5 ; service netif start em0 > & /dev/null ; sleep 10 ; resolvconf -i ; route show default ; ping -4 -c 2 freshports.org
   969  10:59   route delete default
   977  11:30   route delete default ; ifconfig wlan0 destroy ; service netif start wlan0 ; sleep 5 ; ping -4 -c 2 freshports.org
  1053  8:00    route delete default ; ifconfig wlan0 destroy ; service netif start wlan0 ; sleep 5 ; ping -4 -c 2 freshports.org
  1059  8:01    route delete default ; ifconfig gif0 down ; service netif stop em0 > & /dev/null ; ifconfig wlan0 destroy ; sleep 5 ; service netif start wlan0 > & /dev/null ; sleep 10 ; resolvconf -i ; route show default ; ping -4 -c 2 freshports.org
  1064  8:55    route delete default ; ifconfig gif0 down ; service netif stop em0 > & /dev/null ; ifconfig wlan0 destroy ; sleep 5 ; service netif start em0 > & /dev/null ; sleep 10 ; resolvconf -i ; route show default ; ping -4 -c 2 freshports.org
  1227  9:03    route delete default ; ifconfig gif0 down ; service netif stop em0 > & /dev/null ; ifconfig wlan0 destroy ; sleep 5 ; service netif start em0 > & /dev/null ; sleep 10 ; resolvconf -i ; route show default ; ping -4 -c 2 freshports.org
  1536  9:21    route delete default ; ifconfig gif0 down ; service netif stop em0 > & /dev/null ; ifconfig wlan0 destroy ; sleep 5 ; service netif start wlan0 > & /dev/null ; sleep 10 ; resolvconf -i ; route show default ; ping -4 -c 2 freshports.org
  1548  11:34   route delete default ; ifconfig gif0 down ; service netif stop em0 > & /dev/null ; ifconfig wlan0 destroy ; sleep 5 ; service netif start em0 > & /dev/null ; sleep 10 ; resolvconf -i ; route show default ; ping -4 -c 2 freshports.org
  1635  1:41    route delete default ; ifconfig gif0 down ; service netif stop em0 > & /dev/null ; ifconfig wlan0 destroy ; sleep 5 ; service netif start em0 > & /dev/null ; sleep 10 ; resolvconf -i ; route show default ; ping -4 -c 2 freshports.org
  1673  9:36    route delete default ; ifconfig gif0 down ; service netif stop em0 > & /dev/null ; ifconfig wlan0 destroy ; sleep 5 ; service netif start em0 > & /dev/null ; sleep 10 ; resolvconf -i ; route show default ; ping -4 -c 2 freshports.org
root@mowa219-gjp4-zbook-freebsd:~ #

It's not much of a palaver, with csh history and command autocompletion, but I would like things to be simpler for me.
 
fr0xk said:
It can automatically configure DNS, default routes, and other settings based on DHCP information (if you use your smartphone internet connection through tethering, dhcpcd will able to automatically detect it and connect to it)
Click to expand...
That is exactly the problem.

To be clear: dhcpcd is excellent quality software, and I say that after looking into the code of many dozens of software packages.
But, it does exactly what is stated in the quote: it takes away your system from you and tries to manage it over your head.

I am using it, because it was the only piece of software that did actually work for IPv6 prefix delegation - and I am using it ONLY for that. And I had a really hard time figuring how to disable all the other things it wants to do - and obviousely it did them wrong, because my systems are not designed to be managed by AI. (And since dhcpcd is capsicum-enabled and utilizes proper security, it is really difficult to look inside and see what it actually tries to do.)

An example: when receiving a router advertisement, dhcpcd will configure the IP accordingly. That will suffice for simple configurations, but when doing things correctly, the new data must first be merged into the firewall tables, then the IP can get configured, and finally the old data will be merged out of the firewall tables.
(My firewalls support full inflight reconfiguration, dynamic address change without unneccessarily breaking links, and can compute NPTv6 checksum correction dynamically)

Some of it is described here (probably a bit outdated by now):
tech.daemon.contact

Tech dc - Using IPv6 Dynamic GU Addresses in Nested Subnets

tech.daemon.contact

BTW, talking DHCP: my machine needs some 5 extra minutes to boot, because each jail has to run into three timeouts before it can start:
Code: 
32-bit compatibility ldconfig path:
rtsol: sendmsg on nadmn1l: Permission denied
rtsol: sendmsg on nadmn1l: Permission denied
rtsol: sendmsg on nadmn1l: Permission denied
Starting Network: lo0 nadmn1l.

That is because somebody thought laptops would need rtsol before any network configuration (and so obviousely also before the firewall rules get loaded) in order to support DHCP (we here adhere to ZeroTrust, i.e. every node runs it's firewall). The recommendation I then got was to not use "default to deny" on the firewalls (I could hardly believe it). The still open question is, why are my jails mistaken as laptops?

These are examples of how those fancy "desktop" efforts actually and evidently break proper server operation. And that is what I meant above by unintellegible haywire: it could be done properly, but these "desktop" folks just don't bother to.
 
The year of the FreeBSD laptop. I have 10 or so laptops running FreeBSD about half I pulled the wifi card and replaced it with a supported card. Some of my thin clients use USB wifi. But Ethernet is where it's at for me. All my desktops work great. I've got Nvidia and Radeon systems I don't have any arc systems but I know they are supported. The system works great for me and if it didn't I would use a different system. Good stuff devs keep up the insanely great work!
 
Sam The Ripper said:
Linux is not broken by design.
Linux is just a kernel. And you're not supposed to run a kernel itself, but a product built on top of that.
And there are only few Linux-based products on the market. The rest of the distributions are just crap for people who like to waste their time in useless stuff.
Click to expand...

Don't nitpick semantics. "Linux" used as nomenclature for "GNU/Linux" as a complete base system; as we're all aware of. Both Linus and Stallman were both missing opposing parts of what constitutions a "base system"; which is what FreeBSD genetically embodies. Hell, they even argued on what they should officially call "GNU/Linux". One being "Lignux" proposed by Stallman. The community (and Linus) decided to adopt just "Linux" for simplicity sake and marketing. His practicality towards the GPL sort of aided him and his opinion on the naming matter also. The brokenness started at its inception. Both historically and technically.
 
PMc said:
That is exactly the problem.

To be clear: dhcpcd is excellent quality software, and I say that after looking into the code of many dozens of software packages.
But, it does exactly what is stated in the quote: it takes away your system from you and tries to manage it over your head.

I am using it, because it was the only piece of software that did actually work for IPv6 prefix delegation - and I am using it ONLY for that. And I had a really hard time figuring how to disable all the other things it wants to do - and obviousely it did them wrong, because my systems are not designed to be managed by AI. (And since dhcpcd is capsicum-enabled and utilizes proper security, it is really difficult to look inside and see what it actually tries to do.)

An example: when receiving a router advertisement, dhcpcd will configure the IP accordingly. That will suffice for simple configurations, but when doing things correctly, the new data must first be merged into the firewall tables, then the IP can get configured, and finally the old data will be merged out of the firewall tables.
(My firewalls support full inflight reconfiguration, dynamic address change without unneccessarily breaking links, and can compute NPTv6 checksum correction dynamically)

Some of it is described here (probably a bit outdated by now):
tech.daemon.contact

Tech dc - Using IPv6 Dynamic GU Addresses in Nested Subnets

tech.daemon.contact

BTW, talking DHCP: my machine needs some 5 extra minutes to boot, because each jail has to run into three timeouts before it can start:
Code: 
32-bit compatibility ldconfig path:
rtsol: sendmsg on nadmn1l: Permission denied
rtsol: sendmsg on nadmn1l: Permission denied
rtsol: sendmsg on nadmn1l: Permission denied
Starting Network: lo0 nadmn1l.

That is because somebody thought laptops would need rtsol before any network configuration (and so obviousely also before the firewall rules get loaded) in order to support DHCP (we here adhere to ZeroTrust, i.e. every node runs it's firewall). The recommendation I then got was to not use "default to deny" on the firewalls (I could hardly believe it). The still open question is, why are my jails mistaken as laptops?

These are examples of how those fancy "desktop" efforts actually and evidently break proper server operation. And that is what I meant above by unintellegible haywire: it could be done properly, but these "desktop" folks just don't bother to.
Click to expand...

Ofcourse, jails don't typically broadcast their nature or role, network services like dhcpcd will treat them similarly to laptops or other typical devices that depend on automatic configuration. You can easily fix it like following (you should use this method by default anyway, regardless you are using dhclient or dhcpcd)


Code: 
from dataclasses import dataclass
from pathlib import Path
import subprocess
from typing import Optional, List, Tuple

@dataclass(frozen=True)
class Config:
    jails_list: Path
    firewall_config: Path
    dhcpcd_conf: Path
    ip_config: Path

    def __init__(self):
        object.__setattr__(self, 'jails_list', Path("/etc/jails.list"))
        object.__setattr__(self, 'firewall_config', Path("/etc/pf.conf"))
        object.__setattr__(self, 'dhcpcd_conf', Path("/etc/dhcpcd.conf"))
        object.__setattr__(self, 'ip_config', Path("/etc/jail_ip.conf"))

def load_firewall(config: Config) -> Optional[str]:
    if config.firewall_config.exists():
        subprocess.run(["pfctl", "-f", str(config.firewall_config)], check=True)
        subprocess.run(["pfctl", "-e"], check=True)
        return None
    return "Firewall config not found"

def disable_dynamic_ip_for_jails(config: Config) -> Optional[str]:
    if not config.jails_list.exists():
        return "Jail list not found"
    
    with config.jails_list.open() as file:
        jails: List[str] = [jail_name.strip() for jail_name in file if jail_name.strip()]
    
    dhcpcd_content: str = config.dhcpcd_conf.read_text()
    with config.dhcpcd_conf.open("a") as dhcpcd_file:
        for jail_name in jails:
            if f"denyinterfaces {jail_name}" not in dhcpcd_content:
                dhcpcd_file.write(f"denyinterfaces {jail_name}\n")
    return None

def apply_static_ip(config: Config) -> Optional[str]:
    if not config.ip_config.exists():
        return "IP config not found"
    
    with config.ip_config.open() as file:
        ip_mappings: List[Tuple[str, str]] = [tuple(line.strip().split()) for line in file if line.strip()]
    
    for jail_name, jail_ip in ip_mappings:
        result = subprocess.run(["ifconfig", jail_name], capture_output=True)
        if result.returncode == 0:
            subprocess.run(["ifconfig", jail_name, "inet", jail_ip, "alias"], check=True)
        else:
            print(f"Interface for {jail_name} not found")
    return None

def main():
    config = Config()
    
    if error := load_firewall(config):
        print(error)
        return
    
    if error := disable_dynamic_ip_for_jails(config):
        print(error)
        return
    
    if error := apply_static_ip(config):
        print(error)
        return
    
    pri
nt("Configuration completed.")

if __name__ == "__main__":
    main()

A fun read: OpenBSD developer on "Boy vs Man"
 
Beastie7 said:
Don't nitpick semantics. "Linux" used as nomenclature for "GNU/Linux" as a complete base system; as we're all aware of. Both Linus and Stallman were both missing opposing parts of what constitutions a "base system"; which is what FreeBSD genetically embodies. Hell, they even argued on what they should officially call "GNU/Linux". One being "Lignux" proposed by Stallman. The community (and Linus) decided to adopt just "Linux" for simplicity sake and marketing. His practicality towards the GPL sort of aided him and his opinion on the naming matter also. The brokenness started at its inception. Both historically and technically.
Click to expand...
I don't care about your own definition about what the word "Linux" means and your opinions about that matter. I care about technical arguments.
And you still didn't explain how all these opinions of yours can prove your point about Linux being "broken by design".
You still didn't explain how the GNU userland, as bad as it is, installed on top of a Linux kernel can make the system "broken by design".
 
fr0xk said:
Ofcourse, jails don't typically broadcast their nature or role, network services like dhcpcd will treat them similarly to laptops or other typical devices that depend on automatic configuration. You can easily fix it like following
Click to expand...
You didn't fully understand the issue. The problem is not with DHCP acting (there is none active), it is with the base system software invoking rtsol before the firewall gets loaded. I would need to patch the OS to fix that - and I don't like having to maintain more and more local patches for the system.

fr0xk said:
(you should use this method by default anyway, regardless you are using dhclient or dhcpcd)
Code: 
def load_firewall(config: Config) -> Optional[str]:
    if config.firewall_config.exists():
        subprocess.run(["pfctl", "-f", str(config.firewall_config)], check=True)
        subprocess.run(["pfctl", "-e"], check=True)
        return None
    return "Firewall config not found"
Click to expand...
  1. I don't use DHCP on my jails (or anywhere else, except for v6 prefix delegation). I have kerberized single-sign-on, a couple of nameservers and automated deploy. and I do not have dozens of clients walking around with their laptops - which is the only use-case where DHCP would offer me any benefit. Otherwise it is just a PITA.
  2. I don't speak python (I speak ruby).
  3. I don't use pf, but ipfw
And this presents very muich the problem I am trying to describe: desktop "integration" means the automation of configuration tasks. This requires assumptions about how the system is operated, and these assumptions will conflict with anything that is not a plain desktop/laptop.

Consequentially, desktop "integration" will (very likely) sacrifice the versatility of the system as it is.
 
PMc said:
You didn't fully understand the issue. The problem is not with DHCP acting (there is none active), it is with the base system software invoking rtsol before the firewall gets loaded. I would need to patch the OS to fix that - and I don't like having to maintain more and more local patches for the system.


  1. I don't use DHCP on my jails (or anywhere else, except for v6 prefix delegation). I have kerberized single-sign-on, a couple of nameservers and automated deploy. and I do not have dozens of clients walking around with their laptops - which is the only use-case where DHCP would offer me any benefit. Otherwise it is just a PITA.
  2. I don't speak python (I speak ruby).
  3. I don't use pf, but ipfw
And this presents very muich the problem I am trying to describe: desktop "integration" means the automation of configuration tasks. This requires assumptions about how the system is operated, and these assumptions will conflict with anything that is not a plain desktop/laptop.

Consequentially, desktop "integration" will (very likely) sacrifice the versatility of the system as it is.
Click to expand...
No, you don't have to patch it in the OS. You can overwrite those rules in user space using python but I get it. You don't speak python, but your issues with desktop integrations are not technical, but emotional/personal. dhcpcd's default behaviour is optimal for 99% of use cases in server and it can be patched to integrate with jails and initiate sequences in user defined order (systemd in Linux can do this, SMF in Solaris can do it too). I know you don't use python but control flow of python is very similar to other scripting languages, so at least you'll able to understand basic control flow of it. Hopefully this patch helps (I've added comments where I have changed the sequence of orders). Python is great for these kinds of automation, rust too. I suggest learning one of them.

Code: 
from dataclasses import dataclass
from pathlib import Path
import subprocess
from typing import Optional, List, Tuple

@dataclass(frozen=True)
class Config:
    jails_list: Path
    firewall_config: Path
    dhcpcd_conf: Path
    ip_config: Path
    log_file: Path  # Added to handle dhcpcd logging

    def __init__(self):
        object.__setattr__(self, 'jails_list', Path("/etc/jails.list"))
        object.__setattr__(self, 'firewall_config', Path("/etc/ipfw.rules"))
        object.__setattr__(self, 'dhcpcd_conf', Path("/etc/dhcpcd.conf"))
        object.__setattr__(self, 'ip_config', Path("/etc/jail_ip.conf"))
        object.__setattr__(self, 'log_file', Path("/var/log/dhcpcd.log"))  # Log file for dhcpcd

def list_interfaces() -> List[str]:
    result = subprocess.run(["ifconfig", "-l"], capture_output=True, text=True)
    if result.returncode == 0:
        interfaces = result.stdout.strip().split()
        print("Available network interfaces: ")
        for idx, interface in enumerate(interfaces):
            print(f"{idx + 1}. {interface}")
        return interfaces
    else:
        print("Error retrieving interfaces.")
        return []

def select_interfaces(interfaces: List[str]) -> List[str]:
    # Allow user to select one or more interfaces
    selected_indices = input("Select interfaces by number (comma-separated for multiple): ").split(",")
    selected_interfaces = [interfaces[int(i.strip()) - 1] for i in selected_indices if i.strip().isdigit()]
    print(f"Selected interfaces: {', '.join(selected_interfaces)}")
    return selected_interfaces

def load_firewall(config: Config) -> Optional[str]:
    # Load firewall rules before rtsol
    if config.firewall_config.exists():
        subprocess.run(["ipfw", "flush"], check=True)  # Clear existing rules
        with config.firewall_config.open() as fw_file:
            rules = fw_file.read().strip().splitlines()
            for rule in rules:
                if rule.strip():
                    subprocess.run(f"ipfw {rule.strip()}", shell=True)  # Add rules
        return None
    return "Firewall config not found"

def disable_dynamic_ip_for_jails(config: Config) -> Optional[str]:
    if not config.jails_list.exists():
        return "Jail list not found"
   
    jails = [jail_name.strip() for jail_name in config.jails_list.open() if jail_name.strip()]
    dhcpcd_content = config.dhcpcd_conf.read_text()

    # Prevent dhcpcd from auto-configuring the jail interfaces
    with config.dhcpcd_conf.open("a") as dhcpcd_file:
        for jail_name in jails:
            if f"denyinterfaces {jail_name}" not in dhcpcd_content:
                dhcpcd_file.write(f"denyinterfaces {jail_name}\n")
   
    return None

def apply_static_ip(config: Config) -> Optional[str]:
    if not config.ip_config.exists():
        return "IP config not found"
   
    ip_mappings = [tuple(line.strip().split()) for line in config.ip_config.open() if line.strip()]
   
    for jail_name, jail_ip in ip_mappings:
        result = subprocess.run(["ifconfig", jail_name], capture_output=True)
        if result.returncode == 0:
            subprocess.run(["ifconfig", jail_name, "inet", jail_ip, "alias"], check=True)
        else:
            print(f"Interface for {jail_name} not found")
   
    return None

def configure_dhcpcd_logging(config: Config) -> None:
    # Enable verbose logging in dhcpcd.conf to aid debugging in Capsicum environments
    dhcpcd_content = config.dhcpcd_conf.read_text()
   
    if "logfile" not in dhcpcd_content:
        with config.dhcpcd_conf.open("a") as dhcpcd_file:
            dhcpcd_file.write(f"\nlogfile {config.log_file}\n") 

def manage_rtsol(interfaces: List[str]) -> None:
    # Run rtsol for each selected interface after firewall rules are loaded
    for interface in interfaces:
        result = subprocess.run(["/sbin/rtsol", interface], capture_output=True)
        if result.returncode != 0:
            print(f"Error running rtsol on {interface}: {result.stderr.decode()}")

def ipv6_config(interfaces: List[str], config: Config) -> None:
    # Core function to load firewall first and then run rtsol
    error = load_firewall(config)
    print(error) if error else None

    # Once firewall is up, run router solicitation
    manage_rtsol(interfaces)

def main():
    config = Config()

    interfaces = list_interfaces()
    if not interfaces:
        print("No interfaces found.")
        return

    selected_interfaces = select_interfaces(interfaces)
    disable_dynamic_ip_for_jails(config)
    configure_dhcpcd_logging(config)

    apply_static_ip(config)
    ipv6_config(selected_interfaces, config)

    print("Configuration completed.")

if __name__ == "__main__":
    main()
 
Beastie7 said:
Hey be nice. My Mac has far more application support than all open source OSs combined. ?
Click to expand...
In many ways, that kind of is the deciding factor for popularity (on the desktop at least). Hardware support doesn't really matter quite so much so long as a platform has a good catalog of programs and *some* hardware that is known to work.

The driver treadmill that some people expect FreeBSD to sprint on, is counter-productive. But I do understand that this is likely a symptom of context switching between what people new to open-source are used to with commercial products (particularly Windows).

fr0xk said:
I don't care if they support 30Y old hardware and some toasters. I can list a bunch if hardware that neither FreeBSD support nor Linux.
[...]
See, it's that easy. Gatekeeping is unnecessary and futile at best.
Click to expand...
Sounds like you are just upset that FreeBSD doesn't work on your consumer gaming PC.

I get it can be disappointing but just use something else or learn to bring up hardware youself. In ~10 years, you won't even remember that you had a dud of a machine.

You are confusing the term "gate keeping" with "being realistic". Developer resources are scarce and as such will not provide you with the level of cutting edge hardware support you need. You want full coverage of upstream Jetson support on FreeBSD... how to intend for that to happen exactly? Just making noise by complaining on forums, mailing lists, IRC simply contributes to developer fatigue and achieves nothing. We *all* already know that writing drivers is hard.
 
fr0xk said:
No, you don't have to patch it in the OS. You can overwrite those rules in user space using python but I get it. You don't speak python, but your issues with desktop integrations are not technical, but emotional/personal.
Click to expand...
I understand why others have given up talking to You.

fr0xk said:
dhcpcd's default behaviour is optimal for 99% of use cases in server and it can be patched to integrate with jails and initiate sequences in user defined order (systemd in Linux can do this, SMF in Solaris can do it too). I know you don't use python but control flow of python is very similar to other scripting languages, so at least you'll able to understand basic control flow of it. Hopefully this patch helps (I've added comments where I have changed the sequence of orders). Python is great for these kinds of automation, rust too. I suggest learning one of them.
Click to expand...
Okay, I put rust onto the list of things to avoid. (*NOW* I am emotional)
 
kpedersen said:
In many ways, that kind of is the deciding factor for popularity (on the desktop at least). Hardware support doesn't really matter quite so much so long as a platform has a good catalog of programs and *some* hardware that is known to work.

The driver treadmill that some people expect FreeBSD to sprint on, is counter-productive. But I do understand that this is likely a symptom of context switching between what people new to open-source are used to with commercial products (particularly Windows).


Sounds like you are just upset that FreeBSD doesn't work on your consumer gaming PC.

I get it can be disappointing but just use something else or learn to bring up hardware youself. In ~10 years, you won't even remember that you had a dud of a machine.

You are confusing the term "gate keeping" with "being realistic". Developer resources are scarce and as such will not provide you with the level of cutting edge hardware support you need. You want full coverage of upstream Jetson support on FreeBSD... how to intend for that to happen exactly? Just making noise by complaining on forums, mailing lists, IRC simply contributes to developer fatigue and achieves nothing. We *all* already know that writing drivers is hard.
Click to expand...

It seems there’s a misunderstanding regarding my perspective. I’m not into gaming either, so please refer to the previous conversation history for context.

To summarize, someone mentioned experiencing USB-related errors in FreeBSD over his 10-15 years of experience, which got resolved after switching to GhostBSD. I pointed out that GhostBSD’s ability to address issues that FreeBSD either overlooked or chose not to prioritize highlights FreeBSD's focus on server functionality. This prompted some defensive reactions from gatekeepers (that's not realistic view at all)

One user made strong assertions about the risks of proper desktop integrations—like WiFi and Bluetooth—leading to system instability, suggesting that tools like dhcpcd could compromise the system's versatility. Now these claims may have some merit, they lack thorough testing and are not strictly technical. System behavior can be modified in user space by various programming/scripting languages to some extent as I demonstrated to someone who's more interested in the philosophical “right way” to approach these issues rather than practical implementation.
 
You must log in or register to reply here.
Back
Top