Announcement

Collapse
No announcement yet.

A Call For More Collaboration & Harmony Among BSD Hardware Drivers

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • kylew77
    replied
    Originally posted by danboid View Post
    I'm pretty sure FreeBSD (and Linux) runs on more platforms now so I don't really see the point in them being separate projects.
    Linux runs on far more architectures than FreeBSD, the 13.X series only supports AMD64, i686, ARM64, Arm7(32bit), MIPS (going away with 14.X), RISCV, 32bit POWER PC, 64 bit POWER PC, SPARC 64 (12.4 is last supported version). So with 14.0 it will be AMD64, i686, ARM64, some 32bit arm, RISCV, 32bit and 64 bit POWER PC. Only ARM64 and AMD64 are tier 1 and support binary updates. i686 is supported with binary updates when possible but is tier 2.
    Alpha, Itanium, SPARC64 soon, some arm, and something called pc98 all went the way of the dodo.

    NetBSD on the other hand supports more processors than I will list here but as TIER 1! Supports the regular AMD64, i386, ARM64, and 32 bit arm, but also MIPS, SPARC64, POWER PC, and XEN (virtual). Along with tier 2 and 3 stuff as esoteric as the Sega Dreamcast, VAX, Amiga, etc.

    I would say it is a toss up between what supports more: Linux or NetBSD. Finding a Linux distro that supports a VAX or Amiga might be hard with so many focusing on the "4 core architectures" of AMD64, ARM64, POWER PC 64, and RISC V 64. Gentoo or Debian would be your best bet.

    OpenBSD is also supported on many architectures including one or two that NetBSD doesn't but have pruned away support for several architectures over the last couple of years because in OpenBSD everything has to be self compiling and able to build the OS and ports on the hardware in question so support for architectures like Longson were dropped. But Open still supports Alpha and SPARC 64 when a lot of OS are dropping these once great power houses. luna88k is only supported by OpenBSD to the best of my knowledge.

    DragonFly BSD just supports AMD64 only.

    Leave a comment:


  • dacha
    replied
    Originally posted by kylew77 View Post
    The first paragraph sounds an awful lot like a microkernel approach which how monolithic *BSD kernels are other than DragonFly I don't see gaining much traction..
    Actually FreeBSD already took that approach for webcamd and fusefs-lkl. They both use parts of the Linux kernel in a user-space application, webcamd using it to provide video4linux drivers for webcams, fusefs-lkl using it to provide filesystem drivers for BTRFS, Ext4, and XFS.

    Leave a comment:


  • danboid
    replied
    NetBSD should merge with FreeBSD (and DragonFly). NetBSD's USP used to be its portability but I'm pretty sure FreeBSD (and Linux) runs on more platforms now so I don't really see the point in them being separate projects.

    I think there's room for two BSD's. FreeBSD for most BSD fans and OpenBSD for those who are willing to sacrifice performance for security.

    Leave a comment:


  • mxan
    replied
    The macOS screenshot on the presentation isn't helping the perception of the BSDs as toy OS's only run in virtual machines :P

    Leave a comment:


  • toves
    replied
    Originally posted by stormcrow View Post
    ... Reality is a cast iron bitch, you know. She doesn't care if you believe in her.
    I would have gone for wrought iron. Cast iron is pretty brittle.

    I have used all three BSDs for actual work - netbsd on a DEC Alpha 3000 turbochannel machine.
    Usually a lot nicer than the proprietary Unixes of the day. All Linux now but the stability of various interfaces in BSDs is quite refreshing - if you administered a BSD box ten years ago then you wouldn't be too out of place with the current version. Cannot really say that about Linux distros in general.

    A few years ago building a redundant router from commodity hardware (primary/secondary failover) with two FreeBSD boxes was much simpler than struggling with Linux. Not sure if that is still the case.

    ZFS on Linux is pretty decent once the licensing nonsense is taken out of the equation. The kABI tracking packages make it pretty painless.

    Horses for courses. Having choices when the reality bitch is on the prowl is a good thing.


    Leave a comment:


  • kylew77
    replied
    Originally posted by binarybanana View Post
    Maybe they could put device specific drivers outside the kernel. Run a minimal VM that talks to the hardware and communicates over some device class specific high level protocol with the host system which then exposes this as just eth0 or /dev/snd or whatever, as usual. This works best with actual hardware support but even low-end SBCs come with virtualization extensions and IOMMUs nowadays. Performance should be acceptable to native like. I guess this sounds kind of like Plan9, just locally.

    For some things like networking or sound you can already kinda do this manually in a hacky way. If some PCIe NIC (maybe even wireless) isn't supported on your system. Just fire up a Linux VM which connects to the network and route your traffic through it however you prefer. You can now browse the web. This also helps if the drivers are just buggy and crash your kernel.
    The first paragraph sounds an awful lot like a microkernel approach which how monolithic *BSD kernels are other than DragonFly I don't see gaining much traction.

    The second paragraph is actually very interesting in the FreeBSD space to get wireless AC and AX working. They are implementing a basically small Linux VM that runs the Linux Intel driver for stuff like the newer iwx wifi stuff. The project is called Iwlwifi.

    Leave a comment:


  • binarybanana
    replied
    Maybe they could put device specific drivers outside the kernel. Run a minimal VM that talks to the hardware and communicates over some device class specific high level protocol with the host system which then exposes this as just eth0 or /dev/snd or whatever, as usual. This works best with actual hardware support but even low-end SBCs come with virtualization extensions and IOMMUs nowadays. Performance should be acceptable to native like. I guess this sounds kind of like Plan9, just locally.

    For some things like networking or sound you can already kinda do this manually in a hacky way. If some PCIe NIC (maybe even wireless) isn't supported on your system. Just fire up a Linux VM which connects to the network and route your traffic through it however you prefer. You can now browse the web. This also helps if the drivers are just buggy and crash your kernel.

    Leave a comment:


  • kylew77
    replied
    This would be a good initiative. Back when Intel was king they developed a few drivers for FreeBSD but now not so much since AMD is pulling away in the server market. OpenBSD seems to do a good job supporting the latest Intel NICs and Wireless NICs and a good job pulling in Intel and AMD DRM whereas FreeBSD is the only BSD OS with official Nvidia support and NetBSD is the only BSD OS with Novouru Nvidia support. ZFS is supported on free and net but not DragonFly or Open. All 4 major *BSDs have incompatible UFS/FFS implementations that is also incompatible with Linux's primitive UFS support (seriously the make config option for UFS support in Linux says don't use it!). So I guess having intercompatiable file systems would be a good start!

    Leave a comment:


  • kiffmet
    replied
    The driver situation in the BSD space is a bit frustrating for users. I'd totally like to experiment a bit with FreeBSD, but its AMDGPU drivers are too old. OpenBSD has the most recent GPU drivers, but lacks a Linux compat layer on the other hand…

    It's kinda sad, that there is so much duplicated effort being made, and porting drivers between these two BSDs isn't straightforward either. I would very much appreciate a collaborative effort in this regard. Pls agree on a shared interface and work together on GPU drivers.

    Leave a comment:


  • Nozo
    replied
    Originally posted by Velocity View Post
    If BSD is dying, explain then what that means? https://freebsd.org is dead? Cannot download the sourcecode? Sourcecode does not compile? Compiled sourcecode does not work?

    Or you mean that BSD remains a niche among operating systems, with a very stable user base that is loyal and continues to improve the operating system at a relatively slow pace, particularly compared to Linux. But.... is that dying?

    Here is what FreeBSD itself says:
    Teaching others and spreading the word about FreeBSD is an important part of the Foundation’s mission. This includes sponsoring and attending many BSD and non-BSD conferences, supporting work on creating FreeBSD curriculum to be taught in schools and universities, publishing the high-quality FreeBSD focused magazine, The FreeBSD Journal, and developing collateral to spread the word about the


    Personally I have used FreeBSD since 4.x and it works well for me. Just not as a desktop, that requires many drivers to be up to date and even Linux is struggling with that quite a bit. FreeBSD makes an excellent server OS though and has many strong keypoints, my favorite being the excellent integration of ZFS - without all the bullshit lawyer stuff that you cannot distribute with ZFS compiled. Thanks to its permissive license, i do not need to be a lawyer but can instead focus on productivity. I simply love technology, but i hate all the judicial stuff. If all lawyers were removed from this planet.... well, you get my point.
    *Laughs at iXsystems after they killed TrueNAS CORE in favor of SCALE like they did to PC-BSD/TrueOS years ago
    And that will happen sooner than many imagine.

    Leave a comment:

Working...
X