Closed What Would You Like to See FreeBSD Do Differently?

[BSD-Kitsune]

As long as it's optional, Xenocara sounds good. The only issue would be to select driver categories at time of install. Choices should just be down to Nvidia, Intel and ATI for modern graphics drivers, and for ancient hardware, VESA.

Many modern graphics drivers, especially for Radeon ATI, are already MIT, BSD, or ISC license compatible. It's just that Linux incorporated that code first. BSDs can either reverse engineer the compatible licensed driver from Linux, or just start from scratch importing the existing driver sourcecode. It is overdue for FreeBSD or Xorg to incorporate R series ATI and other modern graphic card drivers. It's not expected of anyone to do this, but eventually it will have to accept at least a few years recent modern graphics cards, or the OS will be left behind.

Old graphics drivers should be dropped and have VESA with possibly a compatible driver added to allow better video rendering.

The whole "old graphics drivers" thing is an upstream thing - take it up with Xorg to deprecate or make those drivers optional in their downloaded packages.

As far as your statements on the graphics stack, no. You're not correct.

There's two parts to a modern, KMS driver: Kernel code, and usermode code. For AMD, Intel and Nouveau, the USERMODE code is permissively licensed. But this is only one part. For Linux, their kernel drivers, AMD, Intel and Nouveau all alike are GNU GPL v2, same as the kernel. This is because LKML considers kernel modules derivative works of the Linux Kernel and therefore requires that ALL kernel modules be GNU GPL v2. The consequence of this is that projects using permissive licenses have to reimplement from scratch the KMS interfaces and kernel mode drivers - this has gotten easier a little considering with all new drivers the driver interface serves as a vehicle for a microcode blob loaded at runtime - reducing driver complexity to some degree.

This is in comparison with the older user-mode setting which usually is MIT licensed or proprietary and primarily interacted with X. The consequences of UMS are that X has to run as root, a huge security risk on a standard X install. Besides security considerations, KMS is better because you can display fatal errors, i.e. Kernel panics or BSODs, reliably in the event of a system crash. I will tell you that KMS is a good thing generally speaking. Windows has used it forever.

 

[sidetone]

Xorg won't depreciate old hardware, because that is their intended purpose. I was thinking about Wayland, until I looked up Xenocara, which is just an implementation of Xorg. Either way, older drivers should go into just VESA, with an added generic driver for better video rendering. But yes, that's Xorg.

Only the part that was released to BSD compatible licenses, usually by the manufacturer, can be used for FreeBSD. So projects, such as FreeBSD, drivers' cannot be built on upon additions to Linux/GPL drivers, (which as you said, their additions to their drivers are GPL) so it won't infringe on their license. The FreeBSD driver has to be worked from scratch from that point of the BSD compatible license, without GPL additions. GNU can't infringe on the BSD licensed code from the manufacturer either.

The link to AMD about Radeon (re-post), https://community.amd.com/thread/170233 , says about the graphics stack:

"Correct - we maintain a BSD-licensed open source graphics stack which then gets ported to a number of different OSes including FreeBSD. FreeBSD graphics support lagged behind Linux for a while during the transition from User ModeSetting (UMS) to Kernel ModeSetting (KMS) and addition of the TTM memory manager, but now seems to be pretty much caught up.​

For the R9 290x I believe two issues were open - picking up a sufficiently new X server to include the glamor 2D acceleration method, and picking up a sufficiently new Mesa driver to include HW support for Hawaii (the chip in R9 290x). Looks like X server 1.17 is running now, so once a newer Mesa version is available in FreeBSD the R9 290x should be supported."​

This is about Mesa, http://mesa3d.org/intro.html , which Xorg also focuses on.

 

[BSD-Kitsune]

Only the part that was released to BSD compatible licenses, usually by the manufacturer, can be used for FreeBSD. So projects, such as FreeBSD, drivers' cannot be built on upon additions to Linux/GPL drivers, (which as you said, their additions to their drivers are GPL) so it won't infringe on their license. The FreeBSD driver has to be worked from scratch from that point of the BSD compatible license, without GPL additions. GNU can't infringe on the BSD licensed code from the manufacturer either.

So yeah, you seem to be getting the general idea...

The link to AMD about Radeon (re-post), https://community.amd.com/thread/170233 , says about the graphics stack:

"Correct - we maintain a BSD-licensed open source graphics stack which then gets ported to a number of different OSes including FreeBSD. FreeBSD graphics support lagged behind Linux for a while during the transition from User ModeSetting (UMS) to Kernel ModeSetting (KMS) and addition of the TTM memory manager, but now seems to be pretty much caught up.​

For the R9 290x I believe two issues were open - picking up a sufficiently new X server to include the glamor 2D acceleration method, and picking up a sufficiently new Mesa driver to include HW support for Hawaii (the chip in R9 290x). Looks like X server 1.17 is running now, so once a newer Mesa version is available in FreeBSD the R9 290x should be supported."​

​

And you lost it. There's other blocking issues here and there, yes but the big one glaring at us in the face at the moment is the fact that you still need to reimplement the kernel features. You still seem to not understand that neither AMD nor Intel provide us with kernel drivers. They don't. I've looked into this. So no matter what, the people in FreeBSD maintaining the graphics stack have to play persistent game of catch-up with Linux - Linux releases a new kernel with new merged AMD/Intel code, and we have to reimplement that. Which may be trivial or not. I'm not a graphics developer, so I am not sure.

And you seem to be stuck on AMD. AMD sucks on FreeBSD. Use Intel or Nvidia. I've never had a single AMD card work properly *and* perform well. I've had the former, never the latter. I blame AMD's crappy GPU and CPU architectures, as of late, and their complete and utter disconnect with the gaming community. Nvidia may not be open source friendly but the hiccups they've given are zilch. Ditto for Intel.

 

[sidetone]

Replace Sendmail with DMA (DragonFly Mailer Agent) now!

For FreeBSD 11, if you look at src.conf(5), DragonFly Mailer Agent is there, unless removed:

WITHOUT_DMAGENT
            Set to not build dma Mail Transport Agent
WITHOUT_MAIL
             Set to not build any mail support (MUA or MTA).  When set, it
             also enforces the following options:

             WITHOUT_DMAGENT
             WITHOUT_MAILWRAPPER
             WITHOUT_SENDMAIL

dma(8) is in the base system for 11.0, but in ports for previous releases.

 

[sidetone]

For any worries about desktop, x11-wm/jwm is now MIT licensed. Just go with that or i3.

As for Apache 2 and similarly licensed code, FreeBSD can leave it out of the base system, but embrace it, as having the LLVM compiler ready to download without needing ports, by it just being installed as the pkg package is. I think the Apache 2 license offers some protections. LLVM and all base code should be able to compile with PCC added to base. GNU and GPL options from make options, such as src.conf or make.conf, should be replaced with Apache 2 options. LLVM is better off added as a ports, bc it always has to be updates anyway.

Let PF, LLVM, and programs such as mksh be out of the box and suggestively installable from the base system, as the pkg package is, if they wont be in base. An advantage of having PF and LLVM installed from ports, is having an up to date installation of it ready, without waiting for the next FreeBSD release.

 

[tingo]

KMS is better because you can display fatal errors, i.e. Kernel panics or BSODs, reliably in the event of a system crash. I will tell you that KMS is a good thing generally speaking. Windows has used it forever.

I agree that KMS is a good thing. I do not understand why you drag Windows into this discussion at all, IMO comparing <thing> to Windows only detracts from any positive value <thing> might have.

 

[BSD-Kitsune]

I agree that KMS is a good thing. I do not understand why you drag Windows into this discussion at all, IMO comparing <thing> to Windows only detracts from any positive value <thing> might have.

Windows isn't perfect, but I'm not fanatically against proprietary software or Windows itself. I have to use it on a daily basis. Windows Server is also no worse than any old Linux server - IIS is a perfectly good web server and MSSQL is the industry standard, not MySQL, for high level SQL databases, as opposed to ORACLE DB, which has its own issues.

While I'm not particularly fond of praising Windows when it is a very flawed OS, it's necessary to give credit where it is due, and KMS was a Windows thing long before any form of UNIX used it. That isn't detracting from the conversation at all.

For any worries about desktop, x11-wm/jwm is now MIT licensed. Just go with that or i3.

Let PF, LLVM, and programs such as mksh be out of the box and suggestively installable from the base system, as the pkg package is, if they wont be in base. An advantage of having PF and LLVM installed from ports, is having an up to date installation of it ready, without waiting for the next FreeBSD release.

I'm gonna stop you for a second. Screw mksh. It's a terrible reject shell that was not good enough to use in OpenBSD. Use tcsh - it has basic tab completion, ! aliases, and other than the need to run rehash when installing new software or updating PATH, it's a perfectly useful shell. If you want something more featureful, include zsh then.

PF should remain in base, in fact now that I know PF has more issues than just being behind the OpenBSD version, I'll be looking into how to make it better than ipfw. The alternative would be to give ipfw a more pf/npf like syntax. The script-as-a-config file is retarded.

I disagree with adding Apache software in base because that is a slippery slope we don't need to go down.

 

[drhowarddrfine]

I disagree with adding Apache software in base because that is a slippery slope we don't need to go down.

I thought I misread that when I first saw the original post so I didn't respond and I agree (twice in less than a week!). If FreeBSD does that then you'll get bombarded with why some-other-server wasn't used instead and, all of a sudden, every other port is brought into the discussion.

 

[scottro]

While I could see having a few ports installed in base, e.g., sudo (as an example), the problem comes when there's an emergency upgrade. Using ssh as an example, if there's a vulnerability, a patch may require a reboot. However, if it's a port, it becomes trivial, one upgrades the port or package and restarts the service and doesn't have to worry about a server restart with all the issues that might have.

 

[mfm]

Why do I have to go to SRC to read "Notes on the internal structure of dummynet (2010 version) by Riccardo Panicucci and Luigi Rizzo"?
https://svnweb.freebsd.org/base/rel...ipfw/dummynet.txt?revision=306280&view=markup

Shouldn't be more exposed - like in the man page?

It's not that I'm complaining. But I'm ordinary user, using FreeBSD on my T420 laptop as daily driver since year? and when I faced the problem of setting It up correctly for the first time - I'm mean configuring rc.conf, loader.conf, sysctl.conf it was a bit of pain... with lack of consistency in documentation..

For example Handbook doesn't cover an issue with suspending laptop when you close the lid. That's reflects a support for ACPI state S3 - it can be easily checked if your machine have that feature by issuing a 'piped' command: sysctl -a | grep hw.acpi , and if you have an right answer you can add hw.acpi.lid_switch_state=S3 to sysctl.conf - and must say before doing that my Thinkpad can't do suspend after closing the lid, and I mean we have 2017.

- For pity's sake OpenBSD knows how to do it from the first boot. I check it.

It's not that I'm saying the Handbook is bad. I mean that it's average in some very important aspects, like using FreeBSD as a desktop? - and don't say a word about preferences about window environments - it's irrelevant as it is simple as pkg install.

For example take a look at FAQ that can be found using the 'google' side of the Internet on how to do configuration of a decent workstation after the installation of the operating system: https://cooltrainer.org/a-freebsd-desktop-howto/ and then have a look at handbook topic: https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/book.html#x11

See the point?

Some say setting up of sysctl.conf, loader.conf, rc.conf, login.conf is the matter of particular hardware, taste, needs etc. I'm not saying it's not.

But it should be a "preflight" check list that handles and glues the most basic aspects of using FreeBSD as laptop OS.

Cheers!

 

[BSD-Kitsune]

While I could see having a few ports installed in base, e.g., sudo (as an example), the problem comes when there's an emergency upgrade. Using ssh as an example, if there's a vulnerability, a patch may require a reboot. However, if it's a port, it becomes trivial, one upgrades the port or package and restarts the service and doesn't have to worry about a server restart with all the issues that might have.

I think base should definitely be more complete like OpenBSD's base is. They could just throw in Xenocara, i3 and I'd be happy. The only reason I ever have said Xenocara specifically is because they're doing something with the X codebase to make it more sensible.

 

[Deleted member 9563]

I'm probably the only one who still has an interest in text so this is a personal request. I'd like to see the backspace and delete problem fixed once and for all. Linux did it, we can too.

 

[BSD-Kitsune]

What is the backspace/delete problem?

Are you talking Apple? If so... can't help you there. They chose to use a non-standard keyboard layout.

 

[Deleted member 9563]

BSD-Kitsune said: " What is the backspace/delete problem?
Are you talking Apple? If so... can't help you there. They chose to use a non-standard keyboard layout."

I see you don't use text. A quick google will bring up any number of posts on this problem going back decades should you wish to learn about it. The problem is that the backspace and the delete keys don't do as expected, and do different things in different contexts. FreeBSD is backward compatible with punched tape where you cannot "unpunch" a hole. Although there are still a few people using punched tape (you can still buy it) I don't think the problems this causes for most people (who use text) is worth the compatibility. As for keyboards, I've never tried an Apple one - and it's not a keyboard problem.

 

[tobik@]

hw.acpi.lid_switch_state=S3 to sysctl.conf - and must say before doing that my Thinkpad can't do suspend after closing the lid, and I mean we have 2017.

Suspend doesn't work correctly on a lot of laptops. I always have to fiddle with sysctls to make laptops properly suspend/resume with FreeBSD (if it works at all).

( sysctl -a | grep hw.acpi is equivalent to sysctl hw.acpi btw)

- For pity's sake OpenBSD knows how to do it from the first boot. I check it.

OpenBSD only recently enabled suspend on lid close by default (in OpenBSD 5.7 I believe; not so long ago... and only after a several releases long testing and fine tuning period of their ACPI stack).

Until FreeBSD does the same it's good that it's off by default.

For example take a look at FAQ that can be found using the 'google' side of the Internet on how to do configuration of a decent workstation after the installation of the operating system: https://cooltrainer.org/a-freebsd-desktop-howto/ and then have a look at handbook topic: https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/book.html#x11

See the point?

No. The cooltrainer.org howto is becoming outdated fast (last update 2014-12-26). For example the way it describes setting up x11/nvidia-driver will lead to problems. The way it recommends kernel knobs without explaining why they are needed. Why set kern.maxproc=10000 (it's autotuned)? Why load sdhci(4) from /boot/loader.conf when it is in GENERIC? Why, why, why set the mode of all disks to 666!? Why yet another /etc/pf.conf without using interface groups? Also sysrc(8) is awesome. Why run X -configure? I could go on and on here ;-).

I think my point here is that it adds lots of noise to something that is very simple to setup already.

sysutils/desktop-installer was an effort to automate setting up a FreeBSD desktop, but I don't know what the current state of it is. I don't see any reason we couldn't have e.g. an Ansible playbook for setting up a GNOME, KDE, XFCE, ... desktop automatically.

They could just throw in Xenocara, i3 and I'd be happy.

Base == "Things I want"? In that case add sndio, tmux, and mg to your list please

The Xenocara website says that Xenocara is not a Xorg fork and that changes they do are pushed back upstream if possible. So the changes that are applicable to non-OpenBSD systems are already in x11/xorg.

What are the benefits of a bundled Xorg? The release cycle of FreeBSD and supporting multiple releases at once will mean that ports will have to support multiple (eventually outdated) Xorg versions at the same time. It's never going to happen. See the countless bug reports, problems, and workarounds in ports that arise from having to support multiple OpenSSL versions from FreeBSD 9, 10 and 11.

 

[NewGuy]

• Safer defaults - having a basic PF policy enabled, enforcing many of the sysctls/configurations that are optional in bsdinstall by default, etc.
• Focus on PF - first thing I'd do would be to nix the other firewalls from supported codebase - allow them to be community supported if the community chooses, but focus on PF, and perhaps work towards a PF codebase that could be considered portable between the BSDs, and Linux, if they so chose.
• Ship with X in base - as an optional component. I'd take the opportunity to switch from PAM to BSD Auth and adopt Xenocara as the X distribution.
  
• Eliminate unnecessary architectures. Namely, SPARC, PC-98, POWERPC(32) and maybe even i386. These would still be available if the community decided to support the efforts. I think this is only fair with the dropping of IA-64, completely uncalled for considering the cost of IA-64 hardware is about equal with SPARC and POWER of equal performance.
  
• Migrate entirely to LibreSSL.
• Adopt lld and other LLVM tools in lieu of GNU binutils whereever possible.

That's just me though - this is purely a thread to open this for discussion.

I found it interesting looking through this list that, with the exception of focusing on PF as the default/primary firewall, I want the opposite of pretty much everything on this list. I want diverse architecture support, I like the slow-and-steady approach of OpenSSL vs LibreSSL's tendency to break backward compatibility, I don't want X in the core system, I don't want a firewall enabled by default. Going with the suggested defaults in the OP, would make FreeBSD a less appealing solution for my use cases. I like FreeBSD, in part, because it is lean, conservative and flexible. The suggestions above seem to me to be taking the OS in the opposite direction.

 

[ANOKNUSA]

For example Handbook doesn't cover an issue with suspending laptop when you close the lid. That's reflects a support for ACPI state S3 - it can be easily checked if your machine have that feature by issuing a 'piped' command: sysctl -a | grep hw.acpi , and if you have an right answer you can add hw.acpi.lid_switch_state=S3 to sysctl.conf - and must say before doing that my Thinkpad can't do suspend after closing the lid, and I mean we have 2017.

- For pity's sake OpenBSD knows how to do it from the first boot. I check it.

It's not that I'm saying the Handbook is bad. I mean that it's average in some very important aspects, like using FreeBSD as a desktop? - and don't say a word about preferences about window environments - it's irrelevant as it is simple as pkg install.

First, as you already stated, you can suspend your laptop on lid close. It works. Complaining that it doesn't work out of the box to make you and you alone happy is asinine. systemd automatically handles tihs as well, and it was the first thing I disabled whenever I performed a new Arch install. (See how much you love it when you step out for a walk, only to return and discover that your laptop suspended in the middle of installing the operating system and/or packages. Or have the system crash as you move from one room of the house to another because some process didn't take well to being interrupted.) So it works; you just have to turn it on yourself, if you prefer it. Nothing worth complaining about.

Second, I can see the value of a separate official or semi-official guide to getting a desktop up and running, but including all of that information in the Handbook would be insane. And yes, I will say a several words about window manager preference, because if installing the WM of your preference is so simple, then griping about it, expecting someone else to give you what you personally prefer, and expecting everyone to either be happy with what you personally prefer or go through the extra work to change it, are all pretty selfish and lame.

 

[BSD-Kitsune]

The Xenocara website says that Xenocara is not a Xorg fork and that changes they do are pushed back upstream if possible. So the changes that are applicable to non-OpenBSD systems are already in x11/xorg.

What are the benefits of a bundled Xorg? The release cycle of FreeBSD and supporting multiple releases at once will mean that ports will have to support multiple (eventually outdated) Xorg versions at the same time. It's never going to happen. See the countless bug reports, problems, and workarounds in ports that arise from having to support multiple OpenSSL versions from FreeBSD 9, 10 and 11.

Xenocara has a shitload of changes that will never be upstreamed. It runs rootless, for example, without the use of systemd via a user called _x11. They've also started stripping xdm and other binaries of their XDMCP (network functionality) so that people that do not need network transparency can run much smaller code with less of an exploit. I mean, not to be rude but I'm sure you realize that X is a huge security problem and the main reason it continues to be is because of backwards compatibility. What OpenBSD's Xenocara has done has given an alternative to dealing with this - you can simply have an X that isn't network capable. Not one with the functionality disabled, simply doesn't exist.

Benefits of a bundled X include the ability to customize X further for FreeBSD, to not have to hack scripts or add symlinks to /etc/X11 so that scripts work, etc.

I support simply trashing OpenSSL. Put it in ports, remove anything in base that can't handle LibreSSL. I would also say FreeBSD should only support two releases at a time. In this case, no more 9.x. 10.x and 11.x are plenty a full plate by themselves. Now keep in mind I hate rolling releases, so I'm not suggesting crap like that either.

 

[Phishfry]

Benefits of a bundled X

Totally disagree. The minimalist fashion is what makes FreeBSD an ideal operating system for either a web server or a wifi accesspoint as well as an router OS and a NAS OS. None of those want X.

This is build your own to perfection. Berkley style. Without the odors.
Just the way I like it.

 

[BSD-Kitsune]

Phishfry when I say it should be bundled I mean it should be an optional component installable at anytime.

You're free to not install lib32, src etc.

 

[Phishfry]

OK I would see value to including it with the installer.

 

[Phishfry]

Naw take that back. That is what PCBSD and TrueOS and GhostBSD do best...A desktop.

 

[BSD-Kitsune]

Phishfry Maybe you enjoy having to symlink to /etc/X11 and hack your xorg.conf to work properly. But some of us don't and some of us don't want Consolekit or other rubbish installed by those BSD 'distros'. As long as it is optional it isn't unreasonable.

 

[bcomputerguy]

I'd like to see the graphics stack reworked and implement DRM, KMS, GEM and all those modern features WITHOUT relying on linuxkpi. I think that kpi is a virus honestly, this might make a few people upset but I think it makes BSD weak.

I will work to bring all those graphics features to BSD w/o relying on Linux headers!

Once that's done we can update the input drivers to something like evdev and also get the latest xorg and then linux will not have much over BSD.

 

[bcomputerguy]

Naw take that back. That is what PCBSD and TrueOS and GhostBSD do best...A desktop.

The way those *BSD systems implement graphics is very brittle and will most likely break in the future at which point it will be REALLY hard work to rewrite their graphics stack from scratch.

Currently Linux has improved their graphics stack sufficiently where they even have atomic updates, I doubt they'll be doing any major code breaking changes.

I think this is a good time to port the graphics stack to FreeBSD without depending on linuxkpi.