What would you like to see in FreeBSD

Most duplicate Linux programs of already native FreeBSD programs are better off being dropped. Keep the plugin or other emulation, and improve it to run on top of native FreeBSD programs, with the freed up resources from dropping duplicate Linux versions.

Linux emulation is better off being for when a program becomes newly available to FreeBSD, until it becomes natively ported. emulators/linux-f10 and dependent programs can already go, since that port has been replaced by emulators/linux-c6.

I wonder, what if so many improvements will bring the wrong crowds or attention? Maybe it won't and possibly more good can be done than bad?

Your suggestion does not really fit this thread that is about FreeBSD as an operating system. All of the Linux software in FreeBSD comes from ports that is not part of the FreeBSD operating system but is contributed third party software with people who often have no direct affiliation with the FreeBSD project as maintainers.
 
Here's what I posted on the Reddit discussion:

I would love to see an equivalent of OpenBSD's bsd.rd ramdisk kernel. That is an awesome way to upgrade your system. You just need to download the ramdisk kernel of the new release from an FTP mirror, place it on the root filesystem of your system and boot from it using the loader prompt. The ramdisk kernel can then run the full upgrade process from start to finish.
 
Your suggestion does not really fit this thread that is about FreeBSD as an operating system. All of the Linux software in FreeBSD comes from ports that is not part of the FreeBSD operating system but is contributed third party software with people who often have no direct affiliation with the FreeBSD project as maintainers.
Many others on this thread brought up both subjects up before I did.
 
Allow the installation process to allow manual entry of Wireless Network information in wpa_supplicant, especially on bootonly disks. It can only pick up network scans, and doesn't have an option to input hidden networks. It's not urgent, since this can be worked around.

This one is based on a suggestion above. USB installation disks typically have their files damaged/changed during installation, if something happens during the process. Then the installs have to be recopied to USB drives. It would be better if USB installation media is better protected as read-only, then load into RAM.
 
Hello,

I would like to see more better preconfigured stuff. An example for using k3b on different platforms:
Debian
As root:
Code:
apt-get install k3b k3b-i18n
As user: Starting k3b and then happy ripping and burning

Arch Linux
As root:
Code:
pacman -S k3b
As user: Starting k3b and then happy ripping and burning

openSUSE
As root:
Code:
zypper install k3b
As user: Starting k3b and then happy ripping and burning

And now FreeBSD
As root:
Code:
pkg install k3b
and then as root:
1. The FreeBSD k3b port supports SCSI drives only. If you have IDE CD or DVD
drives, use them through the cam system. See Chapter 18.6.9 of the handbook
(http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/creating-cds.html#ATAPICAM)
2. k3b has to be started from a root console, which is not recommended.
Alternatively, do ALL of the following:
a. Set the suid flag on cdrecord and cdrdao. The 'Notes' chapter of
'man cdrecord' discusses this.
b. Set the vfs.usermount sysctl variable to 1.
# sysctl vfs.usermount=1
Add the line vfs.usermount=1 to /etc/sysctl.conf
Note that this has negative security implications
c. Every user must have read and write access to /dev/cdX:
- add to your /etc/devfs.rules under '[system=10]':
add path 'cd*' mode 666
- or if you prefer allow access for a group XXX only add instead:
add path 'cd*' mode 660 group XXX
to enable it, add to your /etc/rc.conf a
devfs_system_ruleset="system"
d. Every user who should be able to use k3b must have read and write access
to all pass through devices connected with CD and DVD drives and to the
/dev/xpt0 device. Run 'camcontrol devlist' to identify those devices (seek
string 'passX' at the end of each line). Note, that this is a security
leak as well but that there is no alternative!
- add to your /etc/devfs.rules under '[system=10]':
add path 'pass*' mode 666
add path 'xpt0' mode 666
- or if you prefer allow access for a group XXX only add instead:
add path 'pass*' mode 660 group XXX
add path 'xpt0' mode 660 group XXX
- to enable it, add to your /etc/rc.conf
devfs_system_ruleset="system"
- to apply these changes without reboot, run as root:
/etc/rc.d/devfs restart
3. Check, that DMA is activated for atapi devices: 'sysctl hw.ata.atapi_dma'
If not, set it to 1 and put 'hw.ata.atapi_dma=1' into /boot/loader.conf
As user: Starting k3b and k3b crashes (trying to solve this, I've opened a thread)

Sorry, but all quoted output from terminal after installing k3b under FreeBSD also could be managed with postinstall scripts of package k3b.

Please don't understand me in a wrong way: I don't want that FreeBSD becomes a Linux clone. The configuration and package management of FreeBSD is different and when coming from Linux and using FreeBSD I've to learn this.
But that some things have to be configured in another way does not mean that this has to be more complicated. And to edit a lot of stuff manually after installation of a simple desktop application like k3b on a modern desktop system should not to be necessary in year 2015.

I like FreeBSD. A lot of stuff works now (audio, video, xorg with nvidia driver, kde4, firefox with german menu, libreoffice, claws-mail, cups remote access, nfs access, ssh access, digikam) and FreeBSD seems to be a rock solid operating system. But sometimes .... k3b for example ... argh :D

Kind regards,
Holger
 
Not really a feature request, but I would like to see better documentation. Lately a lot of things are poorly documented - if even. As example from the handbook the "VPN over IPsec" page - as nice as it is having it all there, where's the part on how to do things via rc.conf (meaning the GIF interface). Or how do to - even if it doesn't make much sense to build a IPv4 tunnel over IPv6:

Code:
ifconfig inet 172.16.0.1 172.16.0.2
ifconfig inet6 tunnel ::1 ::2

It's not a big deal putting the lines there, it would just be nice to have it in the handbook. The Poudriere page would need some work too, running into a problem I found on a mailing list launching poudriere -x ... gives some debug output - that's not even documented in the manpage.

I know there's the "internet" where to find nearly anything one needs, still it would be nice to not having to rely on a search in your favorite search engine.
And of course, documentation is no replace for "${PREFIX}/bin/brain" ;)
 
  • Thanks
Reactions: Oko
KDE Plasma 5, good (as it is in Linux) WINE , Skype and Dropbox support.
Are you aware that you are talking about third party proprietary or semi-proprietary software which is developed outside of FreeBSD project. Asking FreeBSD developers to "improve Skype support" is like asking Chinese government to improving public transport in New York city.

On another hand you do have a point. Lack of proprietary software and commercial support renders FreeBSD semi-usable or non-starter in many domains. I could care less about Skype or Dropbox but I run RHEL on two dozen or more computing nodes in my lab because MathWorks doesn't have FreeBSD edition of MATLAB and its tool boxes. Similarly we were forced to use RHEL for few applications because Oracle doesn't have FreeBSD of JDK (I heard that FreeBSD foundation was in negotiation with Oracle about that). Unfortunately there is very little or nothing FreeBSD project leadership can do about it.
 
Last edited:
Hello,

I would like to see more better preconfigured stuff. An example for using k3b on different platforms:
Debian
As root:
Code:
apt-get install k3b k3b-i18n
As user: Starting k3b and then happy ripping and burning

Arch Linux
As root:
Code:
pacman -S k3b
As user: Starting k3b and then happy ripping and burning

openSUSE
As root:
Code:
zypper install k3b
As user: Starting k3b and then happy ripping and burning

And now FreeBSD
As root:
Code:
pkg install k3b
and then as root:

As user: Starting k3b and k3b crashes (trying to solve this, I've opened a thread)

Sorry, but all quoted output from terminal after installing k3b under FreeBSD also could be managed with postinstall scripts of package k3b.
I respectfully disagree with you. Idea of postinstall scripts and starting daemons after software installation which I believe comes from Debian kitchen is beyond dumb. It is adopted by Ubuntu. I am not sure what OpenSUSE and Arch are doing but they are irrelevant here in U.S.

Imagine updating 100 servers using automation tool like Ansible, Puppet, of Chef just to find out that servers are broken because somebody decided in your behalf how your daemons are suppose to be configured and even had a power to start them. apt-get and more particularly those postinstall scripts are prime reasons many data centers here in U.S. swear by RHEL or one of its clones like CentOS.
 
Hello Oko,

Idea of postinstall scripts and starting daemons after software installation which I believe comes from Debian kitchen is beyond dumb. It is adopted by Ubuntu. I am not sure what OpenSUSE and Arch are doing but they are irrelevant here in U.S.

When installing cups under Debian, then systemd will be also configured so that cups is ready-to-use directly after installation. On openSUSE it's similar, with Arch I've to enable and start cups service manually after installation like in FreeBSD. But I've not written about things like cups, I've written about a simple desktop application like k3b and such applications are ready-to-use directly after installation on several Linux distributions like Arch, Debian, openSUSE, Mageia ...

Imagine updating 100 servers using automation tool like Ansible, Puppet, of Chef just to find out that servers are broken because somebody decided in your behalf how your daemons are suppose to be configured and even had a power to start them.

I've no experience with servers, but I've written about using FreeBSD on desktop computers. Apart from that I guess that k3b would not be installed on a server.

Kind regards,
Holger
 
I think this way is good. Package management doesn't make any change in devfs or any system-wide thing. The package manager manages the packages and inform you if it needed and if you think you'll make the changes or delete the package.

Check the 2.c: you can choose you'll add read and write access to every user or only one group. Should the package manager ask what do you want (every user or only one group)?
Plus: what should happen if you'll delete k3b? The uninstall script should set vfs.usermount to zero? It's possible that the user set it to 1 earlier.
 
This has been a very educational thread for me. I had to look up quite a number of these technologies as I had never heard of them before. I think for my use case I'd have to second a few of the already mentioned comments, namely:

LibreSSL - It may not be a drop in replacement just yet, but it would be nice to see a roadmap for eventual adoption.

HAMMER 2 - Once it is complete it will be the only BSD licensed file system capable of multi-master mirroring and networked storage failover. The list of features is very impressive and I think all the BSD's would benefit from having such an inspired filesystem.

Updated pf. A no brainer.

Unicode in console. As far as I know only OpenBSD has this. For those of us who operate in multi-lingual environments, being able to type characters like ö, á, ø and not have user directories and files look like gibberish would be nice.

An updated road map for improving security features of FreeBSD. Having MAC is not enough. There are real concerns but they seem to fall on deaf ears - http://networkfilter.blogspot.fi/2014/12/security-openbsd-vs-freebsd.html and
(Theo at 1:18)

All in all FreeBSD is an amazing project and contrary to what some others have said, it makes for a very nice desktop system for daily work. Its stable and highly resilient.
 
I think this way is good. Package management doesn't make any change in devfs or any system-wide thing. The package manager manages the packages and inform you if it needed and if you think you'll make the changes or delete the package.

I admit that this makes sense but on a server machine. A user of desktop computer just wants to install stuff and directly use it.

Check the 2.c: you can choose you'll add read and write access to every user or only one group. Should the package manager ask what do you want (every user or only one group)?
Plus: what should happen if you'll delete k3b? The uninstall script should set vfs.usermount to zero? It's possible that the user set it to 1 earlier.

You think here about using a desktop computer like a server machine again. I think, that things like vfs.usermount=1 should be standard when setting up a FreeBSD installation as a desktop system. And if necessary a pre- or postinstall script also could ask how to handle stuff for users and groups. A lot of packages from Debian come with such scripts and with
Code:
dpkg-reconfigure packagename
you can tune those packages even after installation. And you also can tune it with modifying config files manually. To administrate a server is a full time job but people at home with needs like office, e-mail, printing, internet browsing, photo management, audio management mostly are not professionals. They spent time with a job and with there family, computer and operating systems maybe a hobby but not more. Please don't misunderstand: I don't want that Linux becomes like MS Windows and I also don't want to have a FreeBSD that imitates Linux. I've to learn the differences between this systems when using it. But it should be possible to preconfigure packages of desktop applications also for FreeBSD which makes it a little bit more easy for non-professional users. And the possibility to make a mistake when setting up k3b on FreeBSD for those users is higher than on a Linux system with preconfigured stuff.

The situation for using a desktop machine today often is the following, that a computer is used by one person, maybe by a family. And on those machines I see no problem to setup things during first installation like vfs.usermount=1.

But one question for clarification: Should FreeBSD be an universal operating system for different needs (server, NAS, desktop computer, embedded, Raspberry Pi), or should FreeBSD primary be a server operating system? In second case I understand your argumentation but when I see pkg list of FreeBSD then I think the intention for the developers is to offer an universal operating system.

Kind regards,
Holger
 
Any type of desktop oriented abstractions and pre-configurations is exactly what PC-BSD is for. FreeBSD is defined as a "general" base OS although heavily deviated towards server/embedded devices. It has always shipped with minimum tooling to get users started with development, administration, etc. For anything else, you have to surf ports/pkg and configure your base.

Bloating the base with pre-configured non-sense is an anti-pattern.
 
I think non-professional users doesn't choice FreeBSD.
These desktop-specific things should done once so you don't need waste many-many times to use and configure your system. If you want "desktop-user-friendly" FreeBSD can choose PC-BSD or GhostBSD.

Yes, FreeBSD is an universal operating system. You can install it to server, NAS, desktop computer, RPi, embedded. You can install programs too.
 
Hello Beastie7, hello uzsolt,

thanks for your answers and for giving different perceptions. I accept that FreeBSD has another conception than a Debian GNU/Linux. But this
Bloating the base with pre-configured non-sense is an anti-pattern.
could be formulated a little bit more factual. There are different reasons for using a BSD or Linux as server OS. And there are also different reasons for preferring FreeBSD or Linux as desktop system. And preconfiguration maybe a good thing also for some needs on a server OS, for other needs it maybe better to avoid it. An operating system has to serve different human needs.

If you want "desktop-user-friendly" FreeBSD can choose PC-BSD or GhostBSD.
Sorry, but one reason for me not using PC-BSD is the support of ZFS as only file system. This might be usable on a workstation with more than 8 GB fast DDR3 RAM and a very fast multicore CPU. Beastie7 has written something about bloating a system with preconfigured stuff. Well, another kind of bloating is using ZFS as file system for desktop computers, it is taking a sledgehammer to crack a nut, needs a lot of resources and this is not acceptable for me. I've installed it on Notebook of my wife, a Fujitsu with a quad core CPU and 4 GB RAM. The system was creeping, a current Debian GNU/Linux with kde4 is sprinting on the same hardware. And on my desktop system with 8 GB ram and a fast quad core CPU from Intel PC-BSD also is slow, but FreeBSD with UFS2 and Linux with ext4 are very fast on my hardware. And GhostBSD with its focus to Gnome stuff also is not an alternative for me.

But these are different perceptions of handling operating systems, meanwhile I also can work with FreeBSD, while writing this comment I prepare an audio file with Opera of Berlioz for my broadcast station and I do this with Audacity under FreeBSD.

Kind regards,
Holger
 
I have not been following this thread since the beginning, so forgive me if I missed this somewhere.

I have been using FreeBSD since 1997 as a desktop primarily and you could call me a professional user since I am a programmer by day... but it doesn't revolve around FreeBSD.

That said, I like to point something out that people may be missing in hwagemann's argument:
  • If you are installing ports/packages such as sysutils/k3b-kde4 then you're intention is to most likely use FreeBSD as a desktop, at least partially.
  • Ports such as sysutils/k3b-kde4 have these post install messages on how to actually get the application to work for non-root users, which 99.999% of the time is the user than will be using the port. I never understood why the port install didn't just make the changes or at least present a dialog that would ask if you would like the changes made for you. Since effectively not making the changes makes the application unusable, unless you run everything as root which is a big no no.
 
And preconfiguration maybe a good thing also for some needs on a server OS, for other needs it maybe better to avoid it. An operating system has to serve different human needs.
Do you think should be release a server-edition and desktop-edition from FreeBSD? :)

Sorry, but one reason for me not using PC-BSD is the support of ZFS as only file system.
Really? I've installed it about a year ago and could choose UFS. I want check on homepage but their homepage is unavailable :(
Wiki says PCBSD supports UFS.
I think the installer decide that you want use ZFS and that's all. This is what you want, or not? You shouldn't read and do anything, the system does everything without any question and it doesn't care what do you want :p (I'm only joking)
I'm using ZFS too on an old laptop (about 5 years old, with 4G RAM) but I don't notice any slowness. The reason of ZFS: before FreeBSD I used many Linux distributions, the last was Arch. And I wanted common home partition and the ZFS was the solution (can read/write on both system). But I want delete and use UFS (it's "only" question of time).

And GhostBSD with its focus to Gnome stuff also is not an alternative for me.
As I see you can choose XFce "edition" :) And it seems GhostBSD supports the FreeBSD's ports collection so you can build your KDE (or any other desktop/window manager) - and IMHO can install packages too (I don't see the repository).
And FreeBSD doesn't ship any preconfigured desktop ;)
 
I see lots of people requesting Linux stuff. If you need Linux than run Linux.
I totally agree.

FreeBSD is like that quiet beach that no one knows about. As soon as someone finds out, it gets ruined by all the others who quickly come in and make a mess of things.
Well said.

But it should be possible to preconfigure packages of desktop applications also for FreeBSD which makes it a little bit more easy for non-professional users. And the possibility to make a mistake when setting up k3b on FreeBSD for those users is higher than on a Linux system with preconfigured stuff.
I disagree.
I think that it will be far better to make things simpler for professional users rather than non-professional ones. If a user wants to become a professional one, he must get his hands dirty: clicking buttons on KDE dialogs won't make you an expert. If I want to become an expert, a "click-and-dont-care" gui it's just an obstacle.

If you concentrate your efforts to make the OS more accessible to non-professional users, you will end with a non-professional OS, because the project's resources (developers) will be occupied more on making things easier for those who don't have the will/skill to learn how the OS works, than on improving the system itself. FreeBSD is a professional tool, and in my opinion trying to make it more easier to unskilled people it's just wrong: it's like trying to simplify a book about polynomial interpolation for a 10-years-old kid who has just learned to solve first degree equations. Maybe in the future he will win the Fields medal, but in the immediate he will not learn anything and you have ruined a book.

The situation for using a desktop machine today often is the following, that a computer is used by one person, maybe by a family. And on those machines I see no problem to setup things during first installation like vfs.usermount=1.
There are several desktop OS and a plethora of desktop-oriented (or should we say desktop-wannabe?) OS around there, why insist on using a server-oriented OS? FreeBSD can definitely be a desktop OS (indeed, I use it as a desktop both at home and at work) but it was not designed for this purpose

Should FreeBSD be an universal operating system for different needs (server, NAS, desktop computer, embedded, Raspberry Pi)
Absolutely, like creating a car which is also a bicycle which is also an helicopter which is also a boat which is also a.... :D
 
Hello,

once again, I accept way of FreeBSD administration and your opinions which differ from my opinion, apart from comment of roddierod who seems to be encourage my argumentation.

uzsolt: The ufs support in PC-BSD has gone since a while. I've reading some threads about this decision in forum of PC-BSD and I've checked the installer for it. Before posting about PC-BSD and its filesystem support I've informed me about this, I'm not a person who spread FUD but get impression you think so.

If you concentrate your efforts to make the OS more accessible to non-professional users, you will end with a non-professional OS, because the project's resources (developers) will be occupied more on making things easier for those who don't have the will/skill to learn how the OS works, than on improving the system itself
Dies_Irae: I know this kind of argumentation, if you are consequent with that position, you should postulate a BSD from scratch, then you will learn a lot of more than with current FreeBSD. For me an operating system is a tool, which has to serve my needs, a carpenter for example also hasn't to know how to construct a plow, he has to know, how to use it to make furniture.

If a user wants to become a professional one, he must get his hands dirty: clicking buttons on KDE dialogs won't make you an expert. If I want to become an expert, a "click-and-dont-care" gui it's just an obstacle.
Dies_Irae: Go on, continue with characterisation of my skills to handle an unix based operating system, it is interesting and funny for me :)

I'll still follow this thread but this is my last comment here, feel free to discuss about it or to ridicule it, I want to concentrate for solving an issue with qt4 stuff and k3b on FreeBSD know.

Kind regards,
Holger
 
Ports such as sysutils/k3b-kde4 have these post install messages on how to actually get the application to work for non-root users, which 99.999% of the time is the user than will be using the port. I never understood why the port install didn't just make the changes or at least present a dialog that would ask if you would like the changes made for you.

Because pkg(8) would then also need to undo those changes for you, and now we're getting into more complex territory. You, the user, are empowered to make those changes on your own, and in the process you become informed precisely how your system is being crafted and configured, making it easier to maintain. This is precisely where the asinine debate over the ever-mythical "perfect desktop OS" falls on my eminently deaf ears: what people are arguing for is willful ignorance. FreeBSD is not a magic lamp, it's a minimal toolbox. Users who want something else should choose any of the numerous "something else's" that are already available.

For me an operating system is a tool, which has to serve my needs, a carpenter for example also hasn't to know how to construct a plow, he has to know, how to use it to make furniture.

An operating system is indeed a tool, one that is increasingly versatile and powerful in the hands of a skilled and knowledgeable user. The same goes with carpentry tools. A carpenter who knows how to make a plow is admirable but a carpenter who doesn't know how to make a plow may still be good at making other things. Both can be quite skilled and knowledgeable. A carpenter who uses a plow to build furniture, however, is most certainly ignorant and incompetent, and a carpenter who demanded that a manufacturer make a plow that's better at carving wood should rightly be considered sick in the head.

tl;dr: Some people want an automatically usable desktop. FreeBSD is not for those people.
 
Just to point out that a great deal of desktop setup can be done with a metaport. That would be just one big port that depends on X, a desktop manager, and any other packages that are desired to be included. Local modifications can be included in the metaport's files directory, and even scripts that set preferred defaults.
 
I swear it's like the migration crisis in these forums lately. Big ol' Red Hat is evil, so all the refugees are flocking to BSD-land expecting to get the same environment.
 
I know this kind of argumentation, if you are consequent with that position, you should postulate a BSD from scratch, then you will learn a lot of more than with current FreeBSD.
This is quite extremists. There's no need to reinvent the wheel.

For me an operating system is a tool, which has to serve my needs, a carpenter for example also hasn't to know how to construct a plow, he has to know, how to use it to make furniture.
Just to confirm the fact that there's no need to reinvent the wheel, here is my reply (Thanks ANOKNUSA, I could not have said it better!):
An operating system is indeed a tool, one that is increasingly versatile and powerful in the hands of a skilled and knowledgeable user. The same goes with carpentry tools. A carpenter who knows how to make a plow is admirable but a carpenter who doesn't know how to make a plow may still be good at making other things. Both can be quite skilled and knowledgeable. A carpenter who uses a plow to build furniture, however, is most certainly ignorant and incompetent, and a carpenter who demanded that a manufacturer make a plow that's better at carving wood should rightly be considered sick in the head.

Go on, continue with characterisation of my skills to handle an unix based operating system, it is interesting and funny for me :)
Why do you take this personally? The word "you" in my post was not aimed at *you* personally, but to any generic FreeBSD user.

I swear it's like the migration crisis in these forums lately. Big ol' Red Hat is evil, so all the refugees are flocking to BSD-land expecting to get the same environment.
:D
 
Back
Top