# Call for Foundation-supported Project Ideas



## jrm@ (Nov 23, 2021)

Hello all,

There is a thread on the freebsd-hackers@freebsd.org mailing list seeking project ideas.  If you have ideas about projects that the Foundation could support, please leave your feedback.

--
Joe (with Foundation hat on)


----------



## drhowarddrfine (Nov 24, 2021)

Seems to me they should finish what they already have to work on.


----------



## jrm@ (Nov 24, 2021)

drhowarddrfine, could you elaborate?

There is always room for improvement and we are open to constructive criticism, but the project completion rate seems reasonable.  https://freebsdfoundation.org/our-work/projects/


----------



## eternal_noob (Nov 24, 2021)

Wifi and sound (over HDMI) for the Raspberry Pi 400 would be nice.


----------



## drhowarddrfine (Nov 24, 2021)

jrm@ I'm just noting there are a lot of things already going on that people could be working on and pulling in new work removes them from that. Perhaps I'm being unfair because I'm including bugs and getting Chrome to work


----------



## rootbert (Nov 24, 2021)

an application container framework like Linux OCI (I refuse to name d..... since most people here do think about the company and the bloated daemon that comes with it and not about the concept behind), something simple and neat, like develop runj and potluck to a production ready solution; also maybe some further improvement on linuxulator so we can run Linux OCI containers. There are various nice projects out there e.g. https://akhramov.github.io/posts/2021-09-16-FreeBSD-OCI-jails.html - a hub/repository thing and a possibility to download/distribute those containers easily would be really really awesome.
fuse for unprivileged users in jail
security: more mitigations (like from HardenedBSD?; FreeBSD lacks some features that have been standard on other OSes for years), make veriexec production ready (+ docs)
update to smb protocal version 3.11 so we can mount windows shares from current proposed configurations!
performance improvements is always nice of course ;-)
bhyve: suspend/resume, also a shared storage solution to migrate VMs around hosts so one can update the kernel and reboot
improvement on HAST - for more than 2 nodes; maybe "steal" some ideas from the current Linux/DRBD versions, encrypted connection
ipfw: filter icmp not only on icmptype but also on icmpcode
ggate: encrypted connection


----------



## Beastie7 (Nov 24, 2021)

My top three are .11ac support, Scott Longs Thunderbolt/USB4 work, and Bluetooth support.


----------



## jrm@ (Nov 24, 2021)

Beastie7, improving wireless support is something that the Foundation has funded and is still funding. https://freebsdfoundation.org/project/wifi-update-intel-drivers-and-802-11ac
Your other two suggestion are noted.

rootbert, all your ideas have been logged.

drhowarddrfine, I can't say much about Chrome, but www/chromium, is a challenging situation.  Upstream has decided to stop accepting patches from Free- or OpenBSD, so the port now has over 1000 local patches.  Matthias Wolf (krumel here, I think) has been putting in a tremendous amount of work to keep it usable.  Everything is on the table though.  The Foundation is listening and projects will be carefully chosen after a lot of discussion.  There will still be gaps and those who will argue that different choices should have been made.  There is just much more work than resources.


----------



## _martin (Nov 24, 2021)

Hardware acceleration with qemu. I know with bhyve trying its best it's wishful thinking but I did want to share my opinion.


----------



## Alain De Vos (Nov 25, 2021)

dropping python 2 for build.


----------



## BSD-Kitsune (Nov 25, 2021)

A few things:

1. I'd rather FreeBSD find a conventional FS to replace UFS2, either a from scratch or an implementation of a better one. 20 years ago, UFS2 wasn't terrible, but nowadays it's pretty ehhh at best.
2. Nouveau support.
3. Panfrost/Lima support for Mali graphics on ARM.
4. Switch focus for POWER projects to POWERel. If we had to lose Alpha support in 2008 for 7.x, we're well and truly past the point where dropping ancient POWER/PowerPC makes sense. I know some people are fans of obsolete Apple gadgets, but there's zero future for eb POWER as there's no vulkan, OpenGL 4+, most graphics drivers for newer stuff won't work, etc. If you have focus for POWER on POWERel, it's towards the future and will improve Talos/POWER8 and up support immensely and bring it closer to parity with Linux -- as it stands, when my blackbird is in my posession I can't justify running FreeBSD, or OpenBSD for that matter, on it. Probably gonna need to be Linux KVM which is annoying because there's no good support in the BSDs for POWERel.


----------



## eternal_noob (Nov 25, 2021)

Just fork Chromium and make a Beastie browser. Problem solved.


----------



## a6h (Nov 25, 2021)

eternal_noob said:


> Just fork Chromium and make a Beastie browser. Problem solved.



You are welcome to do that. Just send the diff.
A diff-less proposal is not a proposal.


----------



## eternal_noob (Nov 25, 2021)

1. I am not the Foundation.
2. I am happy with Firefox.


----------



## drhowarddrfine (Nov 25, 2021)

BSD-Kitsune said:


> 20 years ago, UFS2 wasn't terrible, but nowadays it's pretty ehhh at best.



I have never heard anyone say that before.


----------



## jbo (Nov 25, 2021)

jrm@ said:


> I can't say much about Chrome, but www/chromium, is a challenging situation. Upstream has decided to stop accepting patches from Free- or OpenBSD, so the port now has over 1000 local patches.


I would like to know more about this. Is there some resource you can refer me to (eg. a link) to learn what lead to this decision?


----------



## Jose (Nov 25, 2021)

Alain De Vos said:


> dropping python 2 for build.


Accept Olivier Certner's Tauthon port.


----------



## Phishfry (Nov 25, 2021)

Yes I second that. Some python 27 shim is needed to get Seamonkey back into ports tree.
jmos has been doing an excellent job keeping an unofficial SeaMonkey build for us.

How about getting NanoBSD to create UEFI images. I hate so see such an excellent build tool rot on the vine.


----------



## jrm@ (Nov 25, 2021)

jbodenmann said:


> I would like to know more about this. Is there some resource you can refer me to (eg. a link) to learn what lead to this decision?








						upstreaming all the *BSD related patches to chromium
					






					groups.google.com


----------



## BSD-Kitsune (Nov 27, 2021)

drhowarddrfine said:


> I have never heard anyone say that before.


Because you've never benchmarked the filesystems?
When the abortion that is GNU/Linux's ext4 is beating your filesystem by a wide margin, you have a problem. 

XFS would be fantastic, and I actually have looked into such a thing, but gods above it cannot be done by a single person so nobody give me some condescending "SEND A DIFF" comment.


----------



## drhowarddrfine (Nov 27, 2021)

BSD-Kitsune said:


> Because you've never benchmarked the filesystems?


All you said previously was that UFS2 was a bad filesystem. You gave no reason for saying that. UFS2 is not a bad filesystem. It's just not as fast as the others in benchmarks and there seems to be disagreements about that, too.


----------



## BSD-Kitsune (Nov 27, 2021)

I said it's pretty "ehh' at best. doesn't mean terrible. 

The bones of it are good... ish. But the soft-updates system has failed. Soft-updates lost out to journaling and nowadays I/O performance from more modern filesystems is better. We don't need to force everyone who wants decent performance onto ZFS. 

In particular, though, I can name three entrenched issues:

1. It's based on 1970s-era technology with all the same deficiencies and short-sighted aspects of it. UFS had a benefit years ago when all the BSDs were relatively speaking the same dialect. Nowadays, none of them really understand each other as each has gone in a different, incompatible direction. The 1970s were nearly 50 years ago, and documentation for the FS is not as good as some better ones.

2. XFS in particular is extremely well documented, enough that making an independent reimplementation of directory structure v2 era XFS is basically quite possible and then merging newer changes in shouldn't be terrible. 

3. The amount of work to correctly document UFS2, get it speaking even the OpenBSD dialect (impossible mostly because OpenBSD's is a pure-soft updates version) and get it up to modern performance standards is more work than porting a new filesystem.

4. Even if you did all that it would lack many of the better aspects of say XFS, Reiser4 or other filesystems.


----------



## jbo (Nov 27, 2021)

I think it would be appreciated not to go off-topic - especially in a thread like this.

jrm@ and his collegues are putting efforts into providing resources to improve the FreeBSD platform. What we're doing now is having a bitch-fight about something completely irrelevant/unrelated. Lets try to keep the signal-to-noise ratio high - at least in threads like this.


----------



## D-FENS (Nov 27, 2021)

I would love to see an enhancement in jail(8) for including configuration files in /etc/jail.conf, so that one could split one's jail configuration files somewhere under /etc/jail.conf.d/*.conf or /usr/local/etc/jail.conf.d/*.conf.
My company has a product that manages multiple jails but the pain point is that after changing each jail /etc/jail.conf needs to be locked and regenerated. It would be much better to simply generate a config file per jail and then include them all in /etc/jail.conf:


```
# /etc/jail.conf
some global options
# ...
include /etc/jail.conf.d/*.conf
```

*Edit:* I tried to patch "jail" to support include files but while editing the source I noticed that includes are already supported by the "jail" service.
If the respective jail names are added to /etc/rc.conf in `jail_list`, then the files with paths /etc/jail.conf.d/$jailname.conf can be used separately and get recognized by the jail service.
I find this great! There is only one thing I don't like: jail dependencies are not possible. It works as if every conf file is independent from the rest and dependencies cannot be implemented.

Does anyone know how can jails can be dependent on each other?

In any case, one could add the jails in the correct order to `jail_list` in rc.conf and they will be executed in the proper order.


----------



## mark_j (Nov 27, 2021)

Alain De Vos said:


> dropping python 2 for build.


Yes, because soon python 4 will be up and 3 will be useless/obsolete and incompatible ... 
(Only 1/2 joking)


----------



## mark_j (Nov 28, 2021)

Jose said:


> Accept Olivier Certner's Tauthon port.


It's already a port, or do you mean changing all python2 references/uses to use this port? (I know nothing about Tauthon).


----------



## BSD-Kitsune (Nov 28, 2021)

For those here, I did not mean to make things go OT -- I simply was replying to someone's chatter on my comments. It got outta hand fast.

I'm out. Good luck guys.


----------



## grahamperrin@ (Nov 28, 2021)

jrm@ said:


> … There is a thread …



Thanks, and for reference: 
<https://lists.freebsd.org/archives/freebsd-hackers/2021-November/000394.html> | <https://docs.freebsd.org/cgi/getmsg.cgi?fetch=183038+0+current/freebsd-hackers> | <https://marc.info/?l=freebsd-hackers&m=163770725102781&w=2>


----------



## Jose (Nov 28, 2021)

BSD-Kitsune said:


> For those here, I did not mean to make things go OT -- I simply was replying to someone's chatter on my comments. It got outta hand fast.
> 
> I'm out. Good luck guys.


Well, I think a new file system generally, and porting XFS specifically are very much on-topic.

I'm very interested in this suggestion because the lack of zero-copy sendfile(2) in ZFS makes it unsuitable for some high performance applications. It's also my understanding ZFS does not play nice with Postgresql. The Freebsd workaround is to use UFS2. Maybe having XFS as an option would improve the suitability of Freebsd for these applications.


----------



## Jose (Nov 28, 2021)

mark_j said:


> It's already a port, or do you mean changing all python2 references/uses to use this port? (I know nothing about Tauthon).


That port was in the tree for less than 24 hours before it was removed in what has been described as a rage commit. Mr. Certner had added it specifically to work around the Python 2 dependency in the Palemoon build. He even went to the trouble of getting the obstreperous Palemoon upstream to agree they were ok with this workaround. He got treated very poorly for his trouble.

I get the feeling there are contentious discussions about the Chromium port in particular and the Python 2 build dependency in general that are being conducted behind closed doors. All we see is the fallout which is frankly embarrassing for the project. "No Python 2 in the tree!!!1! All these ports with build dependencies on it will be removed post-haste! Please don't look over at the Chromium port."


----------



## grahamperrin@ (Nov 28, 2021)

PostgreSQL



Jose said:


> … my understanding ZFS does not play nice …



July 2021, with reference to a 2017 article:



hardworkingnewbie said:


> … According to the well known Postgres consultant company 2nd Quadrant ZFS and Postgres do perform really well with ZFS' COW features being turned on. So snaphots and all the advanced stuff. …



Also from 2017: PostgreSQL + ZFS – Best Practices and Standard Procedures (thanks to Eric A. Borisch for the pointer).


----------



## grahamperrin@ (Nov 28, 2021)

Chromium

Upstream – _Issue 942720: Make our code work with Python 3_ – various comments followed a July 2021 progress report but (sorry) I lack the knowledge to decipher the technical aspects.

A blocker – _Issue 1251670: Make sure test_runner and utils for iOS are py3 compatible/converted to py3_ – was updated nine days ago. Essentially (with added emphasis):



> … starting to plan wrap up for the chromium/src Py3 migration, actually, we are *targeting to stop supporting Py2 by EO2022Q1*, but we cannot do that until all test systems are done. …



– in plain English, targeting end of the first quarter of 2022.



Jose said:


> I get the feeling there are contentious discussions about the Chromium port in particular and the Python 2 build dependency in general that are being conducted behind closed doors. All we see is the fallout …



I'm blissfully unaware of fallout probably because I have not looked where I should not  but (like many people, I guess) understanding of the reasons, not least Chromium, for lang/python2/ remaining in the ports tree for so long after its end of life.


----------



## Alain De Vos (Nov 28, 2021)

That why i dont run kde/plasma/chromium.

PS1, my tuning for postgresql is the following (feel free to comment):

```
recordsize 8K
checksum skein
compression lz4
atime off
primarycache all
logbias throughput
```

PS2, filosofical question, regarding UFS are all these features really needed or can't some be dropped,
-background fsck
-fsck pruning
-snapshots


----------



## bakul (Nov 28, 2021)

Jose said:


> Well, I think a new file system generally, and porting XFS specifically are very much on-topic.


When SGI open sourced XFS, they put it under GPL so it won’t become part of any BSD licensed OS.

What should be done, but is likely very difficult, is a better integration of zfs code and virtual memory and caching so that extra copies are avoided.


----------



## Jose (Nov 28, 2021)

grahamperrin said:


> PostgreSQL
> 
> 
> 
> ...


Those are generic ZFS + Postgresql howtos. There are significant problems with ZFS (and other COW filesystems) in write-intensive applications. See slide 39 here:








						PostgreSQL on EXT4, XFS, BTRFS and ZFS
					

One of the most common question I'm asked by users and customer about configuring a Linux-based system for PostgreSQL is "What file fystem should I use to get…




					www.slideshare.net
				



Some googling around leads me to believe XFS is the performance leader for Postgresql, but a lot of the benchmarks out there are suspect because they use ZFS without tuning it for Postgresql's idiosyncrasies.


----------



## Jose (Nov 28, 2021)

bakul said:


> When SGI open sourced XFS, they put it under GPL so it won’t become part of any BSD licensed OS.


XFS is licensed GPL-2 and is in the Linux kernel so it will likely not ever change to GPL-3. The latter is incompatible with the BSD license, but the former is not. Witness the large chunks of Linux kernel source in graphics/drm-kmod.


----------



## Alain De Vos (Nov 28, 2021)

Postgresql Note: The more you tune for performance the more data you lose on a power outage. Because stuff is longer held in memory and not synced to disk.
So you can not blindly look to numbers.
[& Primary cache metadata is not always a good idea, eg when database data does not fit in memory or for large selects]


----------



## bakul (Nov 28, 2021)

XFS can at best be a port but who will do the work? I suspect the foundation will prioritize funding work that directly goes into FreeBSD. The work is likely to be fairly involved but may be if interested people can raise enough money to support it, it can happen!


----------



## grahamperrin@ (Nov 28, 2021)

Alain De Vos said:


> … UFS …background fsck …



IIRC background checking is appropriate where the file system is tuned for soft updates but not soft update journaling.


----------



## grahamperrin@ (Nov 28, 2021)

Jose said:


> … a lot of the benchmarks out there are suspect because they use ZFS without tuning it for Postgresql's idiosyncrasies. …



FWIW the one paragraph at <https://openzfs.github.io/openzfs-docs/Performance and Tuning/Workload Tuning.html#postgresql> although (again, sorry) that might be too generic.

Thanks for the SlideShare link. There's a slightly more recent (2016) set with a _TL;DR: Use ZFS, even in the cloud_, however it was a lightning talk so maybe not suitably in depth.


----------



## grahamperrin@ (Nov 28, 2021)

lang/python2



eternal_noob said:


> I don't get why this is still in ports. Just get rid of this old junk. All ports which depend on it can go too.





Alain De Vos said:


> … www/qt5-webengine …



FreeBSD bug 249337 – [meta] Ports broken by Python 2.7 End-of-Life and removal

depends on three open bugs and
blocks  249547 – Remove Python 2.x support from ports


----------



## Alain De Vos (Nov 28, 2021)

bakul said:


> XFS can at best be a port but who will do the work? I suspect the foundation will prioritize funding work that directly goes into FreeBSD. The work is likely to be fairly involved but may be if interested people can raise enough money to support it, it can happen!


There is (only) read-write userspace xfs via fusefs-lkl


----------



## BSD-Kitsune (Nov 28, 2021)

bakul said:


> When SGI open sourced XFS, they put it under GPL so it won’t become part of any BSD licensed OS.
> 
> What should be done, but is likely very difficult, is a better integration of zfs code and virtual memory and caching so that extra copies are avoided.



XFS can be reimplemented under another license. 



bakul said:


> XFS can at best be a port but who will do the work? I suspect the foundation will prioritize funding work that directly goes into FreeBSD. The work is likely to be fairly involved but may be if interested people can raise enough money to support it, it can happen!



It's a nontrivial task for sure. I'd be open to another filesystem, but ZFS is unsuitable as a main filesystem, and UFS2 is simply deficient.


----------



## Beastie7 (Nov 28, 2021)

BSD-Kitsune said:


> I said it's pretty "ehh' at best. doesn't mean terrible.
> 
> The bones of it are good... ish. But the soft-updates system has failed. Soft-updates lost out to journaling and nowadays I/O performance from more modern filesystems is better. We don't need to force everyone who wants decent performance onto ZFS.
> 
> ...



This says absolutely nothing. Exactly how, and what areas of storage management is UFS lacking in? I'd like to see technical details and benchmarks too. Are you familiar with the GEOM framework in FreeBSD? UFS has been trailing, if not, exceeding Linux's options. (_mainly due to GEOM_). If your main use case is the desktop or embedded, UFS is perfectly fine. If it's enterprise storage; ZFS is second to none obviously.


----------



## BSD-Kitsune (Nov 28, 2021)

Beastie7 said:


> This says absolutely nothing. Exactly how, and what areas of storage management is UFS lacking in? I'd like to see technical details and benchmarks too. Are you familiar with the GEOM framework in FreeBSD? UFS has been trailing, if not, exceeding Linux's options. (_mainly due to GEOM_). If your main use case is the desktop or embedded, UFS is perfectly fine. If it's enterprise storage; ZFS is second to none obviously.


ZFS is bloated. I like it, I use it, but it's bloated and not suitable for all workloads. 






						Can DragonFlyBSD's HAMMER Compete With Btrfs, ZFS? - Phoronix
					






					www.phoronix.com
				








						UFS vs. ZFS File-System Performance On FreeBSD 9.0 - Phoronix
					






					www.phoronix.com
				








						FreeBSD's UFS vs Ext4
					






					muc.lists.freebsd.questions.narkive.com
				




I once emailed Larabel on why he doesn't test UFS anymore, and it's because performance-wise it always trails to the point it isn't worth setting up test systems. 

If you're in denial about UFS2's deficiencies performance-wise, maybe the fact it's not well-documented compared to say, XFS, will convince you.

Every interface of XFS is documented, and its codebase is easy to understand with lots of comments and easy to understand functionality. 






						XFS Overview & Internals
					

XFS Training Course



					web.archive.org
				





			Wayback Machine
		


Here's some examples of SGI-derived documentation. 

There is no whitepaper on FreeBSD's UFS2, let alone any modern implementation. There's no mutual-intelligibility between the different BSDs UFS2 versions, let alone with the System V UFS. The codebase is ancient, and has been limped along into the modern era. There's been no promises of fixing UFS2. There's been no promises of improving its performance. People in the community will say "Well ackshually if you want good performance you should use ZFS." and that's a non answer. That's admitting that a filesystem that requires paravirtualizing parts of the OpenSolaris kernel has a massive footprint is superior to your native, default filesystem.

Ask yourself: Is that a good look?

A small team could easily implement XFS from scratch using documentation alone. I am just one person. If there's such a team in the future, sign me up.


----------



## astyle (Nov 28, 2021)

OK, this looks like a good opportunity for me to chime in... to answer jrm@ 's opening post, I have a few items on my wishlist:

1. Get AMD GPU programming going under FreeBSD. OpenCL would be nice, but even better - get the HIP API going.
2. Clean up KDE upgrading in ports, as opposed to pkg. Right now, I'm kludging things together with Poudriere and portsnap, and I'm writing tons of little helper scripts that use find, grep, sed, awk, and other utilities to go through lists and files. Fun project that I'm doing for myself, but I'm hoping there's something in the official project that makes this kind of chore easier. I want to upgrade just KDE (KF5 and Plasma), compile fresh tarballs against an existing base. In the past, upgrading KDE with pkg would mean pulling in strange deps that I would not set if I prepared my own packages. And the procedure always came with the risk of messing up my entire system, forcing a clean re-install.
3. Start using Calamares installer for the system?


----------



## hardworkingnewbie (Nov 28, 2021)

It's not a new topic: for FreeBSD if you want to use Postgres for more than just tinkering around, it's either ZFS or begone. 

There was even 2020 a talk at the BSDCAN about that phenomenon: 


			https://papers.freebsd.org/2020/BSDcan/munro-PostgreSQL_on_FreeBSD.files/munro-PostgreSQL_on_FreeBSD.pdf
		


One issue with UFS from that talk: 
UFS doesn’t recognise this access pattern as sequential.  Linux does, due to read-ahead “window”.  ZFS apparently does too.


----------



## Alain De Vos (Nov 29, 2021)

An easy way to improve postgresql performance is to change the postgresql tunables:

```
fsync=
synchronous_commit=
wal_sync_method=
```
In that case, after a power outage database inconsistency & data-loss will be inevitable.


----------



## grahamperrin@ (Nov 29, 2021)

astyle said:


> … to answer _*[FONT=monospace]jrm@[/FONT]*_ 's opening post, …





Detailed discussion of XFS might continue here:

XFS on BSD

There's also <https://forums.freebsd.org/tags/xfs/>, and these two XFS-specific topics (although neither is tagged as such), both solved: XFS support (2017–2021), Where can I find the status of XFS for FreeBSD (2021).



astyle said:


> … OpenCL would be nice, …



astyle's topic on the subject, for anyone who'd like to continue there:









						Using OpenCL on FreeBSD
					

I'm trying to get OpenCL going on FreeBSD.  The GPU that I have is an Asus Radeon RX 550 4 GB. Per these instructions, I installed lang/clover, benchmarks/clpeak, devel/ocl-icd, deve/clinfo, and graphics/drm-kmod. I successfully got a Plasma Wayland session going, so I know graphics/drm-kmod is...




					forums.freebsd.org
				






astyle said:


> Clean up KDE upgrading in ports, as opposed to pkg.



XenForo can not find the required topic(s). astyle please, do you have a link handy? I'm almost certain that we have prior discussion.


----------



## astyle (Nov 29, 2021)

I don't think I ever had a complete discussion of cleaning up the KDE upgrading... I used a Google search (https://www.google.com/search?q=KDE+astyle+site:forums.freebsd.org) to see what in the world I could have been saying on the topic. I discovered that I mostly made random comments promoting usage of ports over pkg for installing KDE and setting options in makefiles:









						Akonadi won't start
					

The error from akonadictl start --verbose is  org.kde.pim.akonadiserver: Failed to connect to database! org.kde.pim.akonadiserver: Database error: "Can't connect to local MySQL server through socket '/var/run/user/10 01/akonadi/mysql.socket' (2) QMYSQL: Unable to connect"  is the database...




					forums.freebsd.org
				



or









						Wasting time on ...
					

My waste time was sometime trying to get good "use-flags" for  Gentoo-linux. (side-node it is impossible, because they always clash, you can never get them right). What was your waste time , a technical impossible task ?




					forums.freebsd.org
				



or









						Shell - Getting a handle on sh syntax
					

I'd like for some help with getting a handle on sh syntax... The goal of my rather simple script is to generate a list of all installed ports whose category is kde or kde-applications... To this end, I have the following in list_kde_ports.sh: for port in `cat port_list.txt` do if [ -x pkg query...




					forums.freebsd.org
				



The last one is the closest I was able to find on having a complete conversation... But even this one was just me getting some help to get over a hurdle (making lists of ports that I need to compile with Poudriere), I'm nowhere close to achieving what I said I want to do with Poudriere in post #46


----------



## a6h (Nov 29, 2021)

Beastie7 said:


> If your main use case is the desktop or embedded, UFS is perfectly fine. If it's enterprise storage; ZFS is second to none obviously.





BSD-Kitsune said:


> ZFS is bloated


You cannot remove UFS2, because lower-end systems need that. XFS and ZFS are heavy on CPU and RAM, respectively. Unless they want to cut off all old laptops, and other lower-end use case scenarios, they have to keep UFS2 in the kernel. Otherwise, they need to change the slogan to, "The Power to Serve 8GB+".

ZFS is going to remain in the kernel too. Some say HAMMER2 could be a better option. However, it really does not matter, which one is the better one. They will not remove ZFS from the kernel. ZFS is the FreeBSD main selling point -- beside the BSD licence, of course.

Therefore, introducing another FS to the kernel means addition, not replacement, i.e. three filesystems, side-by-side, in the kernel. UFS2, ZFS, and XFS for example. This will not happen either. Either you need many new kernel developers to implement, test and debug it -- for a very long period, or you have to hire developers. I do not bet on the former, and the latter needs money, which according to the latest fundraising it is an impossibility. And even if that happens, then you have larger kernel, more bugs .... To conclude, for better or worse, I am sure that both UFS2 and ZFS will remain the default filesystem in the kernel, for a long time.

[EDIT]
P.S. I'm not a ZFS user, I don't like it, and I'm not defending ZFS. However, the FreeBSD Project policy on keeping and promoting ZFS is understandable.


----------



## BSD-Kitsune (Nov 29, 2021)

vigole said:


> You cannot remove UFS2, because lower-end systems need that. XFS and ZFS are heavy on CPU and RAM, respectively. Unless they want to cut off all old laptops, and other lower-end use case scenarios, they have to keep UFS2 in the kernel. Otherwise, they need to change the slogan to, "The Power to Serve 8GB+".



Uhh, you do realize that IRIX, the OS that XFS originates from, operates on as little as 16M of RAM? XFS came about in IRIX version 6.1, and you can run it easily. These are slow, R3000/4000 class CPUs (think the Nintendo 64 or Dreamcast if you're nooby here, or like 386/486)

Also FreeBSD has basically stopped being ran on 386-class hardware, I'm not even sure if it will compile and run on anything less than i486?

I'm not sure what your logic is that XFS is heavy on CPU. It is a standard journaling FS, and UFS is that plus soft-updates in default config. You can configure it for synchronous mode but that rarely reduces CPU/memory usage. 



vigole said:


> ZFS is going to remain in the kernel too. Some say HAMMER2 could be a better option. However, it really does not matter, which one is the better one. They will not remove ZFS from the kernel. ZFS is the FreeBSD main selling point -- beside the BSD licence, of course.



HAMMER2 is well designed, but likely non-portable to non-x86 systems. 

ZFS on the BSDs doesn't bother me, nor did I offer XFS as a replacement for ZFS. For UFS, maybe. And it won't likely replace it -- I'm being idealistic.



vigole said:


> Therefore, introducing another FS to the kernel means addition, not replacement, i.e. three filesystems, side-by-side, in the kernel. UFS2, ZFS, and XFS for example. This will not happen either. Either you need many new kernel developers to implement, test and debug it -- for a very long period, or you have to hire developers. I do not bet on the former, and the latter needs money, which according to the latest fundraising it is an impossibility. And even if that happens, then you have larger kernel, more bugs .... To conclude, for better or worse, I am sure that both UFS2 and ZFS will remain the default filesystem in the kernel, for a long time.



XFS could be implemented by a team of 3-5 people in a year or less likely if they utilized existing docs. I would be able to help, but I have three issues:

1. I've looked at a CRAPLOAD of GPL XFS and proprietary XFS code in the course of the last 5 years, so it's possible I could screw something up if I was a lead for such a project, not that I believe I have the skills to do so. We would need an auditor or someone checking up on us.
2. Full time worker in a non-tech field. I'm also a volunteer dev for other OSes than FreeBSD. 
3. I am not interested in directly working with the FreeBSD devs, so I would have to leave that to someone else.

And let me remind you, I'm not demanding we put effort here to do this. Grahamperrin requested I migrate my discussion here after I mentioned it in the foundation soliciting development input and ideas. Overall, I'm not pleased with the recent changes the FreeBSD project has made, so I'm likely jumping ship and was just musing a wishlist.


----------



## Beastie7 (Nov 29, 2021)

I think you're underestimating how long it takes to properly develop and stabilize a file system. File systems aren't whimsical toys. It took nearly a decade for ZFS obtain it's stability; APFS four years given Apple-like engineering resources.

Here's a better idea; study the UFS/GEOM code, and experiment with improvements yourself.


----------



## a6h (Nov 29, 2021)

BSD-Kitsune said:


> I'm not sure what your logic is that XFS is heavy on CPU.


Sure. I can't compare two filesystems. But I was refering to following article. The article is stating that "_XFS also consumes about twice the CPU-per-metadata operation compared to Ext3 and Ext4_". I've just drawn a conclusion. If the comparision and my conclusion are wrong, I'll take back my words.
Redhat | How to Choose Your Red Hat Enterprise Linux File System


----------



## bakul (Nov 29, 2021)

BSD-Kitsune said:


> I'm not pleased with the recent changes the FreeBSD project has made, so I'm likely jumping ship


Never mind!


----------



## BSD-Kitsune (Nov 29, 2021)

Beastie7 said:


> I think you're underestimating how long it takes to properly develop and stabilize a file system. File systems aren't whimsical toys. It took nearly a decade for ZFS obtain it's stability; APFS four years given Apple-like engineering resources.
> 
> Here's a better idea; study the UFS/GEOM code, and experiment with improvements yourself.



That assumes writing one from scratch. I'm not suggesting that. This also assumes a nearly direct free-time focus with at least 10-20 hours of work and QA a week towards a project from each person in a team. 

And no thank you. GEOM is decently written, but I'm not screwing with ancient UFS2 code. The conversation between you and me beastie is over. Condescending attitude...



vigole said:


> Sure. I can't compare two filesystems. But I was refering to following article. The article is stating that "_XFS also consumes about twice the CPU-per-metadata operation compared to Ext3 and Ext4_". I've just drawn a conclusion. If the comparision and my conclusion are wrong, I'll take back my words.
> Redhat | How to Choose Your Red Hat Enterprise Linux File System



And that's referring to a Linux-specific workload for things that RHEL is working on. I'm not even suggesting build an XFS driver that's similar to Linux's 100% -- it's entirely possible to start with the IRIX-era driver with XFS directory structure v2 and selectively integrate new changes upstream.


----------



## a6h (Nov 29, 2021)

BSD-Kitsune said:


> And that's referring to a Linux-specific workload for things that RHEL is working on. I'm not even suggesting build an XFS driver that's similar to Linux's 100%


Fair enough. I take back my words on XFS CPU high-usage.


----------



## BSD-Kitsune (Nov 29, 2021)

It was completely unnecessary to apologize. I'm not here to be some 'ackshually' person on XFS or anything else. My goal is to get people talking so someone decides to answer the case for it. If not, then well, it doesn't matter for me in the long run.


----------



## Jose (Nov 29, 2021)

hardworkingnewbie said:


> It's not a new topic: for FreeBSD if you want to use Postgres for more than just tinkering around, it's either ZFS or begone.
> 
> There was even 2020 a talk at the BSDCAN about that phenomenon:
> 
> ...


That talk does not support your contention. The word "apparently" is key there. These are proposed enhancements, not actual ones. There's also this


> Joyent reported that both of these things make no sense on ZFS, which
> overwrites anyway, so you might as well have a fresh inode rather than one
> you haven’t touched for ages that might not even be in memory.  They
> proposed new settings wal_init_zero and wal_recycle to control that.
> ...



Again these are proposed, enhancements, not ones that have been made. And even if they are, all COW filesystems are inadequate for OLTP (i.e. heavy write) workloads. See here:


			https://blog.dijit.sh/friends-dont-let-friends-use-btrfs-for-oltp
		



> (F2FS and ZFS) provide ~2500 tps, i.e. about half the performance of EXT4. Which may initially look bad, but if you create the EXT4 on LVM and create a snapshot, you’ll generally see ~50% performance drop exactly because you’ve just turned EXT4 into a COW filesystem. So this is actually pretty good - it’s simply a cost for the features provided by the COW design.


So if your application can take a 50% performance hit, by all means, use ZFS. This is not always the case.

With XFS you get a modern journaling filesystem with performance comparable to or event better than EXT4.




__





						XFS / EXT4 / Btrfs / F2FS / NILFS2 Performance On Linux 5.8 - Phoronix
					






					www.phoronix.com


----------



## mark_j (Nov 30, 2021)

BSD-Kitsune said:


> ZFS is bloated. I like it, I use it, but it's bloated and not suitable for all workloads.
> 
> 
> 
> ...


Benchmarks are a crock.  You mentioned phoronix so let's use them as an example.
The last I looked at one, many years ago, made me decide he's full of excrement. He takes a custom designed OS, tuned, Linux/GNU distribution and compares it to an out-of-the-box FreeBSD install and muses as to why the latter is slower. Really? Maybe try to set up a system?
He knows nothing of ANY *BSD so he needs to either learn to tune the OS or stop doing benchmarks on *BSDs vs Linux DISTRIBUTIONS.
And look, regardless of whether it's the fastest or not, if people are happy using it, why trash it just as some form of motivation for needing XFS. It doesn't make any sense.

This one you posted is just silly. Their test is FTP? Seriously. What are you testing, your network or your disk I/O? Perhaps ext4's buffering?





						FreeBSD's UFS vs Ext4
					






					muc.lists.freebsd.questions.narkive.com
				




(I didn't read the rest).



BSD-Kitsune said:


> If you're in denial about UFS2's deficiencies performance-wise, maybe the fact it's not well-documented compared to say, XFS, will convince you.
> 
> Every interface of XFS is documented, and its codebase is easy to understand with lots of comments and easy to understand functionality.
> 
> ...



Bravo that it's well documented. UFS is not without documentation. However the real question is why this is held against a file system? Why is better documentation a decider in the worthiness of a file system? There's plenty of good file systems that aren't particularly well documented and some are just not at all.

I don't understand this direction of argument. If you're arguing you cannot port it because UFS is poorly documented, then this is just spurious. The code is not that hard to read, there are chapters in books about it so it's not impossible. If you're willing and able I'm sure it can be done.
You have the author available to ask in the mailing lists, as well.





BSD-Kitsune said:


> Here's some examples of SGI-derived documentation.
> 
> There is no whitepaper on FreeBSD's UFS2, let alone any modern implementation. There's no mutual-intelligibility between the different BSDs UFS2 versions, let alone with the System V UFS. The codebase is ancient, and has been limped along into the modern era. There's been no promises of fixing UFS2. There's been
> no promises of improving its performance. People in the community will say "Well ackshually if you want good performance you should use ZFS." and that's a non answer. That's admitting that a filesystem that requires paravirtualizing parts of the OpenSolaris kernel has a massive footprint is superior to your native, default filesystem.



This smells of the same stink that infests gnu/systemd/linux. Once a particular piece of software reaches maturity and is no longer enhanced, bug fixed etc (because it's apparently bug free), then it must be replaced with a shiny new object so that the cycle can continue.


----------



## BSD-Kitsune (Nov 30, 2021)

I'm not a GNU/Linux shill, Mark. I have no interest in that. I won't however have people tell me how to use my time, my precious time, to try and see what I want as an improvement to the OS. I would like a BSD, any BSD, to adopt XFS under a reimplementation, and for it to be an alternative to UFS. If I ran my own OS, I would remove UFS stuff with prejudice because it's an ancient filesystem that's more akin to ext4 in its poor documentation and understandability. The dual-layer approach it takes (FFS and UFS layers) is also pretty dumb. 

So when Beastie7 quite condescendingly told me to IMPROVE THE GEOM/UFS2 CODE because he thinks he knows better than me how to resolve the problems, it definitely doesn't make me receptive to arguments from pro-UFS people. 

If you want to say his benchmarks are a crock (and I think Larabel is a kind of shady character whose forum is a horrible place with a strong GNU/Linux bias) that's fine, but you can't use that as a basis to dismiss the criticism. UFS is inadequate, for my needs, and I think FreeBSD could benefit from XFS. But judging from how FreeBSD has been doing boneheaded things in the last 3-4 years, I'm not about to die on this hill for an OS I'm not willing to continue using. Between ZFS crap, the ragecommits regarding Tauthon and other ports, and other dramatics, plus... well there's plenty of users in the community who are toxic, it's not interesting to me. It's why I signed up for development to help with a freebsd fork.


----------



## shkhln (Nov 30, 2021)

This is way backwards, we aren't trying to convince you in anything. We are reminding you that trash talking something doesn't help you find collaborators. Also, you should definitely lead by example and start working on it yourself.



BSD-Kitsune said:


> for an OS I'm not willing to continue using





BSD-Kitsune said:


> It's why I signed up for development to help with a freebsd fork


Right. Let them deal with idea people.


----------



## phalange (Nov 30, 2021)

jrm@ said:


> Hello all,
> 
> There is a thread on the freebsd-hackers@freebsd.org mailing list seeking project ideas.  If you have ideas about projects that the Foundation could support, please leave your feedback.
> 
> ...



11ac
wireguard
qemu kvm
How about porting Flatpak to FreeBSD?


----------



## shkhln (Nov 30, 2021)

"Flatpak" as an idea, some specific technology or Linux binaries packaged with it? That would be 3 different things implementation-wise.


----------



## shepper (Nov 30, 2021)

Encryption/Network security is taking a more prominent role.  In-Kernel encryption for wireless would be a good place to start.

IBM is bankrolling iwd development and I'm using it with linux in-kernel encryption - I think it will be the future.


----------



## astyle (Nov 30, 2021)

mark_j said:


> The last I looked at one, many years ago, made me decide he's full of excrement. He takes a custom designed OS, tuned, Linux/GNU distribution and compares it to an out-of-the-box FreeBSD install and muses as to why the latter is slower. Really? Maybe try to set up a system?


I disagree. The Phoronix guy makes an effort to make sure that the benchmarks are academically valid, and to produce numbers that can be fairly compared. Same hardware, same minimal, out-of-the-box setup, same versions of benchmarks run. You do have to pay attention to make sense of what's being written.


----------



## phalange (Nov 30, 2021)

shkhln said:


> "Flatpak" as an idea, some specific technology or Linux binaries packaged with it? That would be 3 different things implementation-wise.



Well, the point would be that rather than investing significant effort into porting multiple programs, focusing all that energy on one gateway app is more efficient. Getting the Linux layer into better shape would be equally compelling. For some of us using FreeBSD as a desktop, there are valuable apps missing.


----------



## Menelkir (Nov 30, 2021)

phalange said:


> Well, the point would be that rather than investing significant effort into porting multiple programs, focusing all that energy on one gateway app is more efficient. Getting the Linux layer into better shape would be equally compelling. For some of us using FreeBSD as a desktop, there are valuable apps missing.


About a flatpak for linux applications on freebsd is another animal, so...
FreeBSD have a lack of contributors to ports (that's why the valuable apps are missing), so if we have flatpak (which I'm against, since it's a security flaw by itself) we're about to divide the chance of having a contributor to ports with the freebsd-flatpak? I don't think it's a wise idea.


----------



## BSD-Kitsune (Nov 30, 2021)

shkhln said:


> This is way backwards, we aren't trying to convince you in anything. We are reminding you that trash talking something doesn't help you find collaborators. Also, you should definitely lead by example and start working on it yourself.
> 
> 
> 
> Right. Let them deal with idea people.



To get such a thing working by myself would be near impossible. As I said, I cannot be a project lead. This is a pragmatic approach. if nobody is interested in leading the project, then there's no damn point.

I'm not trash talking. I said freebsd has done boneheaded things. That's not exactly wrong.


----------



## astyle (Nov 30, 2021)

BSD-Kitsune said:


> I'm not trash talking. I said freebsd has done boneheaded things. That's not exactly wrong.


Unfortunately, I have to agree with shkhln ... This is an example of trash talk.  And, even if FreeBSD is doing some things you disagree with, it's still your time and your machine. You can set them up the way you like. UNIX is not a religion.


----------



## Beastie7 (Nov 30, 2021)

Some people seem to think FreeBSD and Linux are on equal grounds. They’re not. FreeBSD is literally a platform derived from highly skilled researchers.

Making bold claims like that without any objective discourse is disrespectful IMO. Not one reasonable deficiency was mention in comparison to XFS. Seriously, atleast give us something to look at. 

Read my sig.


----------



## mark_j (Nov 30, 2021)

astyle said:


> I disagree. The Phoronix guy makes an effort to make sure that the benchmarks are academically valid, and to produce numbers that can be fairly compared. Same hardware, same minimal, out-of-the-box setup, same versions of benchmarks run. You do have to pay attention to make sense of what's being written.


You're kidding?
The issue is *out-of-the-box*. He chooses something from GNU/Systemd/Linux tuned for his tests and versus them against his chosen victim. He may use the same hardware and the same meaningless software, but comparing a purpose-built OS to a generic OS like, especially, FreeBSD is just nonsense.
Once bitten, twice shy with that fellow and his "benchmarks".

Anyway, I've polluted this topic enough. It should go back to on-topic.


----------



## mark_j (Nov 30, 2021)

BSD-Kitsune said:


> I'm not a GNU/Linux shill, Mark. I have no interest in that. I won't however have people tell me how to use my time, my precious time, to try and see what I want as



I wasn't saying you were, just that this is the same type of issue that infests linux. NIH==must write our own *and* stable==must replace ASAP.
That's all fine and good when you drag in 10s of millions of dollars PA.



BSD-Kitsune said:


> an improvement to the OS. I would like a BSD, any BSD, to adopt XFS under a reimplementation, and for it to be an alternative to UFS. If I ran my own OS, I would remove UFS stuff with prejudice because it's an ancient filesystem that's more akin to ext4 in its poor documentation and understandability. The dual-layer


What do you want? A file system or an academic research topic?

The so-called dual layer approach was for pragmatic reasons because it re-used a large swathe of code. There's nothing inherently bad about this approach. If I recall correctly, I read McKusick originally looked at XFS but realised it would take too long to get it working under FreeBSD. So, they took UFS1 and made it UFS2. Stable and quick to be developed.



BSD-Kitsune said:


> If you want to say his benchmarks are a crock (and I think Larabel is a kind of shady character whose forum is a horrible place with a strong GNU/Linux bias) that's fine, but you can't use that as a basis to dismiss the criticism.


Oh but I can. For the reasons I stated.



BSD-Kitsune said:


> UFS is inadequate, for my needs, and I think FreeBSD could benefit from XFS. But judging from how FreeBSD has been doing boneheaded things in the last 3-4



Ok, fine. You've proposed FreeBSD should adopt it. All good. I suspect people take umbrage with the fact in order to justify XFS you trash UFS. I've used UFS in commercial environments from year dot up to and including now. I don't need a whitepaper to know it's rock-solid and does its job. Is it faster than X and slower than Y? I don't know, nor care. (And I don't have a choice in whether it's used or not).

With FreeBSD I think it's: cool kid == ZFS, nerd == UFS. Just saying.


----------



## BSD-Kitsune (Nov 30, 2021)

Beastie7 said:


> Some people seem to think FreeBSD and Linux are on equal grounds. They’re not. FreeBSD is literally a platform derived from highly skilled researchers.



That's 30+ years ago. it doesn't count anymore. That's about the same amount of time that GNU/Linux has been around. Resting on the laurels of the BSD's birthright is akin to a hypothetical son of Einstein saying "I'm the son of Einstein, I don't need to prove I'm smart."



Beastie7 said:


> Making bold claims like that without any objective discourse is disrespectful IMO. Not one reasonable deficiency was mention in comparison to XFS. Seriously, atleast give us something to look at.
> 
> Read my sig.



I've given metrics indicating that UFS has worse performance, and others dismissed it. I have no sources that will fit someone's criteria, because they have a preconceived notion of what's acceptable. Nothing less than confirmation bias that UFS2 is on equal/superior ground to Linux-based filesystems will work. It's the same as a bad defense attorney trying to dismiss evidence on the basis of bias, but presenting nothing here.

I've mentioned the UFS2 codebase is archaic and difficult to understand. You want support?

Kernel source for UFS2:


```
~/devel/freebsd-src/sys/ufs % cloc .
      36 text files.
      36 unique files.
       2 files ignored.

github.com/AlDanial/cloc v 1.90  T=0.17 s (195.8 files/s, 257508.4 lines/s)
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
C                               21           2645           9399          28793
C/C++ Header                    13            273           1646           1965
-------------------------------------------------------------------------------
SUM:                            34           2918          11045          30758
-------------------------------------------------------------------------------
```


```
~/devel/linux-4.4.293/fs/xfs % cloc --exclude_dir libxfs .
     103 text files.
     103 unique files.
       2 files ignored.

github.com/AlDanial/cloc v 1.90  T=0.18 s (565.5 files/s, 331021.6 lines/s)
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
C                               55           5774          12736          32808
C/C++ Header                    46            796           1714           5760
make                             1              9             24             91
-------------------------------------------------------------------------------
SUM:                           102           6579          14474          38659
-------------------------------------------------------------------------------
```

Exclusion of libxfs is for direct comparison sake. They're on the surface about the same size, but there's some glaring differences. 

1. UFS is organized into much larger files, which can make for difficult reading. This is purely a stylistic choice, but coming from a System V background I prefer this for kernel code.

2. Comments are 36% of the size of the UFS codebase, 38% for XFS.
3. I won't share GPL code, but if you aren't under a prohibition to look at V2 from your employer (I'm not, but I try to avoid v3) look through a few files, read the difference in the quality of comments. Actual comments from each:

UFS:

```
/*
     * Restore user's disk quota because allocation failed.
     */
```


```
/*
 * A virgin directory (no blushing please).
 */
```


```
/*
 * Open called.
 */
```


XFS:


```
/*
     * Invalidate any cached ACLs if the user has bypassed the ACL
     * interface. We don't validate the content whatsoever so it is caller
     * responsibility to provide data in valid format and ensure i_mode is
     * consistent.
     */
```


```
/*
 * xfs_find_handle maps from userspace xfs_fsop_handlereq structure to
 * a file or fs handle.
 *
 * XFS_IOC_PATH_TO_FSHANDLE
 *    returns fs handle for a mount point or path within that mount point
 * XFS_IOC_FD_TO_HANDLE
 *    returns full handle for a FD opened in user space
 * XFS_IOC_PATH_TO_HANDLE
 *    returns full handle for a path
 */
```

There's a much higher verbosity in the XFS comments. Much of the files in the ufs code are also directly recycled from the mid-90s UCB code -- the codebase has certainly changed in nearly 30 years but this is not a good sign.

The original XFS implementation in IRIX was much, much bigger (80k+ lines in the kernel) and has been touched and tuned extensively. It's certainly possible for someone to make it even smaller than Linux has it. 

As for mark's comments:



mark_j said:


> I wasn't saying you were, just that this is the same type of issue that infests linux. NIH==must write our own *and* stable==must replace ASAP.
> That's all fine and good when you drag in 10s of millions of dollars PA.



Not that I don't agree,  but outright aversion to replacement of a codebase that may take as much money to refurbish is something to consider. By the time someone rewrite UFS to be more acceptable to modern tastes (which necessitates removal of soft updates, as NetBSD did, among a lot more) you will be left with a case of theseus' ship. 



mark_j said:


> What do you want? A file system or an academic research topic?



Nothing I posted was academic in nature. It was papers and docs published by the men who wrote it.



mark_j said:


> The so-called dual layer approach was for pragmatic reasons because it re-used a large swathe of code. There's nothing inherently bad about this approach. If I recall correctly, I read McKusick originally looked at XFS but realised it would take too long to get it working under FreeBSD. So, they took UFS1 and made it UFS2. Stable and quick to be developed.



Design decisions made 30 years ago need to be questioned man. Why has nobody else other than the BSDs done this? Why did all the System V UNIXes go on to develop their own proprietary filesystems and discard UFS (Hint hint, it's not licensing!). This design has obfuscated code that desperately needs to be understandable. 

As for your comments... here's my problem and a problem that in large part extends to other debates:

Someone sets an impossibly high burden of proof/quality of evidence. When the person struggles or fails to offer proper evidence, the original person declares "I WIN" by default. This is not a court case, you are not iudex, jury, bailiff and such. We are having a debate, and you have to actually go in and debunk what's said -- which by and large you didn't do, and netiher has anyone else. It's also worth noting that if you apply what I just said to non-technical topics, it immediately shows the weakness in not entertaining ideas brought forth. Frankly, I'm not here to convince you XFS is the way to go -- if you've made up your mind it isn't, then so damn be it. I want someone to see this who may have the skills to lead such an effort, and say "Hey he's got a good idea, and he's offered to help on some  capacity. Let's talk and see what we come up with." Which would be swell. I'd gladly consider that, though I'd insist my work be done on the freebsd fork I am doing work for rather than the direct upstream. I won't ever deal with the FreeBSD upstream again after seeing the gross problems that are weighing down the project and causing boneheaded decisions to be made. 

IN CONCLUSION

I've stated all on the topic I feel inclined to. You have the evidence. I'm not the jury, you're not the jury. Make your mind and grow up, if you got angry or emotional over me attacking or questioning code that's been taken for granted and is trash IMHO, then you should re-evaluate things


----------



## hardworkingnewbie (Nov 30, 2021)

Beastie7 said:


> Some people seem to think FreeBSD and Linux are on equal grounds. They’re not. FreeBSD is literally a platform derived from highly skilled researchers


That's true, Linux dominates market segments like Top 500 super computers with 99.6% market share, so High Performance Computing, where FreeBSD is not even a thing. It's also supported on IBM mainframes, where IBM itself did the port.


----------



## grahamperrin@ (Dec 1, 2021)

phalange said:


> … Getting the Linux layer into better shape would be equally compelling. For some of us using FreeBSD as a desktop, there are valuable apps missing.



+1 from me, however this is not to suggest that things are in _poor_ shape. 

Noted with thanks, completed in the first quarter of 2021: 

Targeted Linuxulator Compatibility Improvements | FreeBSD Foundation



grahamperrin said:


> … for some applications for Linux I simply can't be bothered …





grahamperrin said:


> When I last experimented, there was an unwanted consequence of `linux_enable="NO"`.


----------



## shkhln (Dec 1, 2021)

That reminds me a few things. Completing Firefox Capsicum support would be a worthwhile project. Another usually ignored thing is incompatibility between C++ binaries compiled with Clang and GCC. The latter is decidedly not great and actually interferes with my CUDA library loading hack.


----------



## astyle (Dec 1, 2021)

shkhln said:


> Another usually ignored thing is incompatibility between C++ binaries compiled with Clang and GCC. This is decidedly not great and actually interferes with my CUDA support hacks.


This is actually interesting... never occurred to me before. I did read about how the two projects are rather differently designed. Is there a good blog that you can point to that highlights the differences and incompatibilities between the two?


----------



## shkhln (Dec 1, 2021)

astyle said:


> This is actually interesting... never occurred to me before. I did read about how the two projects are rather differently designed. Is there a good blog that you can point to that highlights the differences and incompatibilities between the two?


Nope. ABI conflicts aren't particularly exciting anyway: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236344#c9.


----------



## john_rambo (Dec 2, 2021)

I am dying to use FreeBSD as my daily driver but for that I need a easy to use sandbox tool like firejail. Please create an equivalent of firejail for FreeBSD. Under Linux if you want to run Firefox inside firejail all you need to do is $firejail firefox. That's it.
https://forums.freebsd.org/threads/...-the-only-reason-i-moved-back-to-linux.83175/

https://firejail.wordpress.com/


----------



## tux2bsd (Dec 2, 2021)

PkgBase


----------



## astyle (Dec 2, 2021)

john_rambo said:


> I am dying to use FreeBSD as my daily driver but for that I need a easy to use sandbox tool like firejail. Please create an equivalent of firejail for FreeBSD. Under Linux if you want to run Firefox inside firejail all you need to do is $firejail firefox. That's it.
> https://forums.freebsd.org/threads/...-the-only-reason-i-moved-back-to-linux.83175/
> 
> https://firejail.wordpress.com/


The handbook offers a good section on jails. If you want, there's an '*ezjail*' port, and a '*bastille*' port. Both offer jail management, and you can run Firefox inside a jail that was managed by either tool.


----------



## drhowarddrfine (Dec 2, 2021)

john_rambo said:


> Please create an equivalent of firejail for FreeBSD.



Wrong place to ask. This is a user's forum, not a developer's.


----------



## astyle (Dec 2, 2021)

drhowarddrfine said:


> Wrong place to ask. This is a user's forum, not a developer's.


Yeah, until you consider that a dev actually started a thread in a user forum, looking for project ideas.


----------



## drhowarddrfine (Dec 2, 2021)

astyle this is still not the place to request new software. Very unlikely the right person will ever see it


----------



## GoNeFast_01 (Dec 2, 2021)

THE ONLY thing I am missing is PCIe pass-through... Why can't I pass my INTEL habanero GPU, NEC Aurora GPU, NVIDIA A100 GPU and AMD Instinct GPU on different jails instead of an emulated environment like Bhyve or QEMU... Anyways not sure if it is a JAIL/EMULATION feature but something tells me it might need kernel edits.


----------



## astyle (Dec 2, 2021)

Watitsthis said:


> AMD Instinct GPU


You're making owners of water-cooled RX 6900 XT jealous here...


----------



## sidetone (Dec 2, 2021)

Here's from the FreeBSD Journal magazine (Sep/Oct 2014) about UFS, how it's good for science related data storage on FreeBSD:








						FreeBSD Journal DE Sept/Oct 2014 Page 4
					





					issue.freebsdfoundation.org
				



This makes it sound very good. I'm happy with it. The only issue is when my harddrive fails, though that's about the harddrive, and I have important data backed up. I use TMPFS for compiling and such.

I'd like to see a NeXtaw implementation (Xaw toolkit) that's ported to XCB. or even halfway to XCL. Then this be its own ecosystem that remains simple. A few BSD-like window managers ported to XCB or halfway to XCL. Edit - NeXtaw's last update is 20 years old. libXaw3dxft is the only modern Athena Widget toolkit that has Unicode and Freetype, thus internationalization support. This is a better target to port to XCB.

LibCanberra being forked or replaced for basic sounds. If forked, simply remove ALL graphical dependencies from it. Make dbus optional on it. Make it separate from Pango, which that can have graphical dependencies. Pango can be indicated by message from a LibCanberra install, or made optional, but not used as the default install. Pango would be the only exception for libCanberra options related to graphical dependencies.

Making Bonjour (net/mDNSResponder) or net/openmdns the default Zeroconf implementations. Allow Avahi as an option, but not be the default.

Improve the dependencies structure, where some options or versions aren't hardset. This is a little difficult to explain. Let's say, a port asks for a specific version of ImageMagick and many versions conflict with each other. Installing a port, makes an existing version of ImageMagick be removed, and replaced with another version or x11 variant.

Make this improved either through port messages, or have it so dependency requirements are met by a class that for example is of ImageMagick port. Back to a previously made point, let "Zeroconf" be the dependency, and this will be as a class. Allow it so the user can select whether they want Bonjour, openmdns or Avahi from make.conf. Also, make CUPS not be a hardwired dependency, let it be installed and queried for to the user by pkg install message. "Print" can also be a dependency class which includes CUPS as a choice.

Another example is how window managers and Xorg are kept separate, because of this, upgrading a window manager doesn't require all of Xorg to be reinstalled. There's often a chain reaction of dependency requirements that requires much to be rebuilt, including from the toolchains and other dependencies. In some case, use messages to tell that more dependencies are needed for a certain functionalities.

In short, dependency classes, where a dependency can be satisfied by a few varying specific options, along with package messages for dependency features.

Edit - package messages was referring to pkg-message that exists under many individual ports in the /usr/ports/ tree. This message shows when those ports are finished compiling, and can be shown using `pkg info -D`.


----------



## freezr (Dec 2, 2021)

Better support for the Odroid boards


----------



## astyle (Dec 2, 2021)

sidetone said:


> Also, make CUPS not be a hardwired dependency, let it be installed and quiered for to the user by pkg install message. "Print" can also be a dependency class which includes CUPS as a choice.





sidetone said:


> In short, dependency classes, where a dependency can be satisfied by a few varying specific options, along with package messages for dependency features.


This is why I stick with ports - in packages, deps are hard-wired.


----------



## Menelkir (Dec 2, 2021)

Watitsthis said:


> THE ONLY thing I am missing is PCIe pass-through... Why can't I pass my INTEL habanero GPU, NEC Aurora GPU, NVIDIA A100 GPU and AMD Instinct GPU on different jails instead of an emulated environment like Bhyve or QEMU... Anyways not sure if it is a JAIL/EMULATION feature but something tells me it might need kernel edits.


Jail/Bhyve != emulation, unless we're talking about different architectures.


----------



## GoNeFast_01 (Dec 2, 2021)

Menelkir said:


> Jail/Bhyve != emulation, unless we're talking about different architectures.





			bhyve/pci_passthru - FreeBSD Wiki
		


VGA/GPU NOT supported with passthru unless I dive neck deep in the code to get it working with latest GPU drivers and other hacks. Believe me I am not the only one that is trying EMULATION section is full of people/gamers mostly trying GPU passthru for a while.... I don't care too much about gaming anymore but ML (Machine Learning) models is something I am working on would love this for that BUT game developers, digital twinning developers, AI professionals, Research Labs, Scientist in Physics, (_____INSERT_BLANK______) will need parallelization this will be the start.


----------



## sidetone (Dec 2, 2021)

astyle said:


> This is why I stick with ports - in packages, deps are hard-wired.


I need to clarify. This is about ports. Packages are also dependent on that (besides the point). I'm referring to pkg-message that exists under many individual ports in the ports tree. The message shows when compiles are completed.

CUPS has been hardwired to a few ports as a dependency, at least the last time I checked.

Edit - when CUPS is selected for builds, it becomes ingrained or hardwired with those packages, including from the default repository. Let CUPS be modular, so it can be uninstalled and installed without uninstalling builds that were selected to depend on it.


----------



## Jose (Dec 2, 2021)

john_rambo said:


> I am dying to use FreeBSD as my daily driver but for that I need a easy to use sandbox tool like firejail. Please create an equivalent of firejail for FreeBSD. Under Linux if you want to run Firefox inside firejail all you need to do is $firejail firefox. That's it.
> https://forums.freebsd.org/threads/...-the-only-reason-i-moved-back-to-linux.83175/
> 
> https://firejail.wordpress.com/


Firejail is a security disaster


> And, yes, I'm aware that Firejail is both complex and setuid root. I think that's an inadvisable design, and a significant security risk.











						Can ease of use be closer to that of firejail? · Issue #266 · containers/bubblewrap
					

Firejail has profiles and provides lots of default ones. Analogous to the commandline arguments, as far as i can see. To make things defaultly run with firejail, you symlink from a directory with p...




					github.com
				




Please let's not have the Foundation support any such nonsense.


----------



## grahamperrin@ (Dec 4, 2021)

tux2bsd said:


> PkgBase



 although it's already on the Foundation's Technology Roadmap, from which I assume (jrm@ please correct me if I'm wrong) that there's Foundation support; a _funded development effort_.









						Technology Roadmap
					

https://freebsdfoundation.org/blog/technology-roadmap/  Enjoy.




					forums.freebsd.org
				



▲
▼








						PkgBase
					

… how to safely update the system (regardless of how far out of date) reliably. …   Let's assume that PkgBase is the way forward.   and so on.  https://lists.freebsd.org/mailman/listinfo/freebsd-pkgbase  In addition to the list, there's sometimes discussion of PkgBase in IRC for FreeBSD...




					forums.freebsd.org


----------



## Jose (Dec 4, 2021)

grahamperrin said:


> although it's already on the Foundation's Technology Roadmap, from which I assume (Jose please correct me if I'm wrong) that there's Foundation support; a _funded development effort_.


Not sure why I'm expected to have any special knowledge of this. Am I get a rep for correcting people?


----------



## grahamperrin@ (Dec 4, 2021)

Sorry! A typo. I meant Joe jrm@ not Jose.



jrm@ said:


> Joe (with Foundation hat on)


----------



## Alain De Vos (Dec 4, 2021)

Something simple. To write mbr, partition & label gpt partitions i use linux. Formatting to ufs/zfs i do with freesd.
Linux feels smoother and streamlined , for this simple job.
Or in other words there is room for improvement on the freebsd "tooling".


----------



## ralphbsz (Dec 5, 2021)

jrm@ said:


> There is a thread on the freebsd-hackers@freebsd.org mailing list seeking project ideas.  If you have ideas about projects that the Foundation could support, please leave your feedback.


For the past week or two, I've been thinking about that: What would I personally want to be improved in FreeBSD? Unfortunately, this thread here was terribly disrupted by two topics (KDE and XFS). And the bigger problem is that in my use of FreeBSD (as a small home server, with PF, firewall/routing, DNS/DHCP/NTP server for internal uses, web server, and some monitoring/control software), it is nearly perfect. I really can't point at "make this one thing much better".

In general, it's not the foundation's main task to get ports under control. It develops FreeBSD, not Chromium, Python or KDE. That division of labor between base and ports is one of the things that keeps the FreeBSD ecosystem healthy.

What I ended up with is two areas where improvement would be helpful.

First, the 802.11 access point support (not client!). Today, you can configure Linux machines to be APs, and they supposedly work nearly perfectly for a single-node access point. I've tried this with both Open- and FreeBSD several years ago, and the AP driver stack just has too many bugs to be reliable, and I've switched back to using dedicated APs (first Apple, now TP). Since I have not tried again, it might be that FreeBSD today can do it perfectly, in which case please ignore this request.

Second:


eternal_noob said:


> Wifi and sound (over HDMI) for the Raspberry Pi 400 would be nice.


I would go further. It would be wonderful if FreeBSD worked "perfectly" on the Raspberry Pi series, with feature parity with "Raspbian" (yes, I know that OS has been since renamed, but the content stays the same, a Debian Linux distribution compiled for the Pi). That includes hardware support (WiFi, sound, HDMI, as eternal_noob said), but also things like GPIO flexibility without rebooting, without having to build DTS overlays, with full kernel support for typical RPi accessories (hats) such as i2c and 1wire. I know that many of these things can be done using FreeBSD, but there they are dastardly tricky and time-consuming, and on Raspbian, they are smooth and effortless. I've been very impressed with how well the RPi ecosystem works with Raspbian: You plug a random hat on, and things just work.

Now, doing this is a huge task. Two reasons: The universe of potential hardware accessories for the RPi is *HUGE*, so supporting all this requires a massive test and QA infrastructure. And getting "desktop" use of the Pi to work perfectly would also mean getting the DE port system under control, which (see above) should probably not be in this list of tasks. So this is a difficult request.


----------



## himay (Dec 5, 2021)

roccobaroccoSC said:


> I would love to see an enhancement in jail(8) for including configuration files in /etc/jail.conf, so that one could split one's jail configuration files somewhere under /etc/jail.conf.d/*.conf or /usr/local/etc/jail.conf.d/*.conf.
> My company has a product that manages multiple jails but the pain point is that after changing each jail /etc/jail.conf needs to be locked and regenerated. It would be much better to simply generate a config file per jail and then include them all in /etc/jail.conf:


Not sure if you had already run across this feature request (PR 233310, but there has been some progress on it: Add support for jail.d


roccobaroccoSC said:


> I find this great! There is only one thing I don't like: jail dependencies are not possible. It works as if every conf file is independent from the rest and dependencies cannot be implemented.
> 
> Does anyone know how can jails can be dependent on each other?


As you got me reading jail(8) a bit more thoroughly, it should be noted that there _is_ dependency support baked into jail.conf with the pseudo-parameter `depend`:


```
depend Specify a jail (or jails) that this jail depends on. When
       this jail is to be created, any jail(s) it depends on must
       already exist.  If not, they will be created automatically,
       up to the completion of the last exec.poststart command,
       before any action will taken to create this jail. When jails
       are removed the opposite is true: this jail will be removed,
       up to the last exec.poststop command, before any jail(s)
       it depends on are stopped.
```


----------



## astyle (Dec 5, 2021)

ralphbsz said:


> In general, it's not the foundation's main task to get ports under control. It develops FreeBSD, not Chromium, Python or KDE. That division of labor between base and ports is one of the things that keeps the FreeBSD ecosystem healthy.


This point, I would like to voice my disagreement about. The ports (as in software packages, not TCP/IP variety) are something that is part of the FreeBSD project. I would think that the Foundation has quite a bit of say in how that part of the project is managed. I know that the ports are a rather open and unwieldy part of the FreeBSD project, so I hope the Foundation will put in some effort into implementing a bit more discipline into ports.


----------



## ralphbsz (Dec 6, 2021)

astyle said:


> The ports (as in software packages, not TCP/IP variety) are something that is part of the FreeBSD project. ... I hope the Foundation will put in some effort into implementing a bit more discipline into ports.


While this is a desirable goal, it is also a huge amount of work. Perhaps it would make sense to have a two-tier system, with an upper tier of audited and supported ports/packages, and a lower tier of volunteer-prepared and maintained ones?

The problem is: What to put into the upper tier of foundation-supported packages? I'm sure a lot of people would immediately say "At least one DE", including the whole hairball of what a desktop needs (printing, web browsing, productivity tools). And that right there is a huge pile of stuff already. Others might say "a small set of commonly used servers (NTPD, Apache, some database such as MariaDB or such). I have opinions, but I'm sure few people share my opinions.


----------



## D-FENS (Dec 6, 2021)

himay said:


> As you got me reading jail(8) a bit more thoroughly, it should be noted that there _is_ dependency support baked into jail.conf with the pseudo-parameter `depend`:


Indeed, there is, and our code relies on it.
`depend` does not work across different files in jail.d though, that was my point.


----------



## astyle (Dec 6, 2021)

ralphbsz said:


> While this is a desirable goal, it is also a huge amount of work. Perhaps it would make sense to have a two-tier system, with an upper tier of audited and supported ports/packages, and a lower tier of volunteer-prepared and maintained ones?
> 
> The problem is: What to put into the upper tier of foundation-supported packages? I'm sure a lot of people would immediately say "At least one DE", including the whole hairball of what a desktop needs (printing, web browsing, productivity tools). And that right there is a huge pile of stuff already. Others might say "a small set of commonly used servers (NTPD, Apache, some database such as MariaDB or such). I have opinions, but I'm sure few people share my opinions.


OpenBSD does audit their ports collection, IIRC. Limiting what goes into the ports tree is a good idea. OpenBSD's version of KDE seems to lag behind FreeBSD's, though.

Edit: just remembered that Debian does have 'community repos' that are used by derivative projects like Ubuntu... and so does Arch. Haven't checked Slackware, but I imagine it's pretty 'hands off' on its package management. There are some ideas from the Linux world that FreeBSD can look at and see what might work in their case.


----------



## richardtoohey2 (Dec 6, 2021)

astyle said:


> OpenBSD does audit their ports collection, IIRC


I don't _think_ so but could be wrong.


----------



## a6h (Dec 6, 2021)

astyle said:


> OpenBSD does audit their ports collection





> The ports & packages collection does NOT go through the thorough security audit that the OpenBSD base system does.








						OpenBSD Porter's Handbook
					

the OpenBSD Porter's Handbook



					www.openbsd.org


----------



## himay (Dec 6, 2021)

roccobaroccoSC said:


> Indeed, there is, and our code relies on it.
> `depend` does not work across different files in jail.d though, that was my point.


Ah, my apologies. I missed that in my reading.


----------



## Jose (Dec 6, 2021)

ralphbsz said:


> For the past week or two, I've been thinking about that: What would I personally want to be improved in FreeBSD? Unfortunately, this thread here was terribly disrupted by two topics (KDE and XFS). And the bigger problem is that in my use of FreeBSD (as a small home server, with PF, firewall/routing, DNS/DHCP/NTP server for internal uses, web server, and some monitoring/control software), it is nearly perfect. I really can't point at "make this one thing much better".


The only thing I can think of is traffic shaping support using dummynet for pf. I believe that's already in progress:








						FreeBSD Quarterly Status Report 2nd Quarter 2021
					

FreeBSD is an operating system used to power modern servers, desktops, and embedded platforms.




					www.freebsd.org
				





ralphbsz said:


> First, the 802.11 access point support (not client!). Today, you can configure Linux machines to be APs, and they supposedly work nearly perfectly for a single-node access point. I've tried this with both Open- and FreeBSD several years ago, and the AP driver stack just has too many bugs to be reliable, and I've switched back to using dedicated APs (first Apple, now TP). Since I have not tried again, it might be that FreeBSD today can do it perfectly, in which case please ignore this request.


I second this. I also tried both with Openbsd and Freebsd and failed. It would be so nice to be able to replace the Chinese plastic boxes running some dodgy version of Linux with a nice PC Engines box running vanilla BSD.


----------



## jrm@ (Dec 6, 2021)

drhowarddrfine said:


> Wrong place to ask. This is a user's forum, not a developer's.


In this particular thread it's fine to make such requests.  We'll be collecting all the requests in one place and some will be candidates for supported work.

There is always more work than resources for funded work, but we'll still collect all requests so anyone interested in tackling a problem can find the requests in one place.  I'll update everyone here when this is ready.


----------



## Phishfry (Dec 6, 2021)

I would like to elaborate on the NanoBSD request I made.
I don't like to ask for things blindly so I have looked at the problem.

So stock NanoBSD scripts generate MBR images. There is a slow move to EFI on the embedded box front.
What we have in source tree is /tools/tools/nanobsd/ with PHK's work slightly extended.
Then under /tools/tools/nanobsd/embedded/ we have some improvements by Warner.
In general I am speaking about the UEFI formating section of /nanobsd/embedded/custom
As you might know it is possible to enhance nanobsd builds with custom functions.
Warners work under ./embedded extended that to include filesystem builds.

So what I would like is to see that work folded into NanoBSD to create optional UEFI image formats.
Some of the stuff in the ./nanobsd/embedded folder may need updating due to Arm changes.
From /tools/tools/nanobsd/embedded/custom (2015)


> o need to promote much of this to nanobsd.sh and friends



I am a willing volunteer to help in any way although I am a script novice.
In the past I have modified Warners ./embedded/custom script to make it work for me.

There is a viable alternative in 'poudriere image' but the images just are not the same as NanoBSD.
It _can_ create just about any image format you desire.


----------



## mark_j (Dec 6, 2021)

I know this is a _pigs might fly_ request, but, I would like to see Solaris RBAC introduced and be an alternative to MAC which is tedious to set up and maintain and just plain counter intuitive especially for new admins to learn (compared to RBAC).

Yes, I know there's arguments for and against. It's my 2c worth.


----------



## richardtoohey2 (Dec 7, 2021)

ralphbsz said:


> And the bigger problem is that in my use of FreeBSD (as a small home server, with PF, firewall/routing, DNS/DHCP/NTP server for internal uses, web server, and some monitoring/control software), it is nearly perfect. I really can't point at "make this one thing much better".


Since feedback/requests are being requested, my situation is similar to the above except it's for more than home servers.  FreeBSD has been rock solid and performs well for my production uses - Apache, PHP, MySQL, pf, UFS, wired networking, etc.  So please don't lose sight of the server-orientated core/use cases, including the work required to support modern server hardware (e.g. 10G NICs, lots-of-cores CPUs, ARM, NVMe, EFI, etc.)

This isn't a "don't change anything it's perfect" request - there's obviously plenty that people would like added/changed for their use cases (and might prove useful for me, too, one day, obviously).


----------



## ralphbsz (Dec 7, 2021)

richardtoohey2 said:


> FreeBSD has been rock solid and performs well for my production uses - Apache, PHP, MySQL, pf, UFS, wired networking, etc.  So please don't lose sight of the server-orientated core/use cases, including the work required to support modern server hardware (e.g. 10G NICs, lots-of-cores CPUs, ARM, NVMe, EFI, etc.)


Completely agree. As a server, FreeBSD is not only rock solid, it is also well built and engineered. One of the reasons I like to use it is: it doesn't make me mad with crappy decisions, half-baked ideas, and sloppy implementations. It's just more pleasant to work with something that was put together with good craftsmanship. OpenBSD is the same way, only things are even neater and tighter. Linux is not at all that way, it's a good-awful mess and cluttered (even though it works well).

The other part I agree with: Make sure normal boring server workloads (the typical FAMP stack) runs well, and runs efficiently on server hardware. Not necessarily on tiny servers (people who use their Raspberry Pi 0 as a database server are like people who build a model of a cathedral out of matchsticks: fun hobby, but not very practical), nor necessarily on gigantic servers (folks who own $2M mainframes or $100M supercomputer have plenty of operating systems available already, and are probably not a good target for FreeBSD efforts), but anything from a $100 motherboard with 8gig and a handful of cores, to the SMP with $5000 worth of CPUs, 1/4TB of RAM and a few hundred cores, the typical server gamut.


----------



## Alain De Vos (Dec 7, 2021)

Supercomputers run linux. So a logical question is where did bsd took a "wrong turn" ?


----------



## drhowarddrfine (Dec 7, 2021)

Alain De Vos said:


> Supercomputers run linux. So a logical question is where did bsd took a "wrong turn" ?



Supercomputer companies are the ones who took the wrong turn, not BSD. Probably for the same reason Google started with Linux. It's cause it's what they were comfortable with and used in school and no other reason.


----------



## Alain De Vos (Dec 7, 2021)

In school , that is 30 years ago, we mainly used solaris. At the job it was sco.


----------



## eternal_noob (Dec 7, 2021)

Since BSD originated from Berkeley, a hippie infested, liberal Sodom and Gomorrah, i believe the conservative CEOs just were scared of it.


----------



## sidetone (Dec 7, 2021)

Alain De Vos said:


> Supercomputers run linux. So a logical question is where did bsd took a "wrong turn" ?


It doesn't mean FreeBSD took a wrong turn. Maybe didn't have the right software or lacked for graphical processing, or didn't move fast enough in the market place. Popularity is a big reason, and also FreeBSD is a product that markets itself by showing what it can do, than have the exposure that Linux has. One reason for the lack of popularity is the amount of setup and customization required for FreeBSD, especially for a desktop.


----------



## freezr (Dec 7, 2021)

Alain De Vos said:


> Supercomputers run linux. So a logical question is where did bsd took a "wrong turn" ?



The issue lies in the license.


----------



## Beastie7 (Dec 7, 2021)

I'm sure much of these markets were heavily saturated by Red Hat since it was the first major open source company. SUN was too complacent with SPARC and didn't follow the intel gravy train. Then CentOS/Scientific Linux came along and gobbled up all HPC type customers. I remember when Dell became the first OEM to ship RHEL with their servers. That was when Linux really blew up in the server space.


----------



## mark_j (Dec 7, 2021)

Alain De Vos said:


> In school , that is 30 years ago, we mainly used solaris. At the job it was sco.


To answer that, I think I would answer more broadly.
In my experience, high school & college/university kids get exposed to Windows, Mac and Linux. Why Linux? Well the back history goes into the BSD law suit and everything that surrounds it but that's sort of irrelevant. Regardless those 3 are what are in their consciousness. Then later they become CIO, CEO or whatever acronym and when pushed to save a buck go to the first free OS they know; Gnu/linux.  Universities and schools adopt gnu/linux because it's free.

It's then self perpetuating. Students become managers, lecturers, high school teachers and they fall back on what they know. Then corporations see money in supporting it and the cycle continues.

Look at gnu/systemd/linux now especially with SOCs where the likes of the Raspberry Pi now dominate (in my experience) high school technology coursework, where gaggles of kids learn linux and, eek, python.

I think the foundation should push hard to align itself with a SOC like Odroid or RPI to get it out into schools and spread the love and critical mass for freebsd and perhaps add another free OS to the psyche of future CEOs, CIOs, lecturers, teachers, managers etc.


----------



## drhowarddrfine (Dec 7, 2021)

mark_j said:


> I think the foundation should push hard to align itself with a SOC like Odroid or RPI to get it out into schools and spread the love and critical mass for freebsd and perhaps add another free OS to the psyche of future CEOs, CIOs, lecturers, teachers, managers etc.



That's an actual grassroots call for action. Something we could all do on our own locally and, eventually, form a national organization aligned with and supported by the foundation.

For that matter, it's something the foundation can start and get interest generated nationally.

Someone should grab the ball and run with it.


----------



## mark_j (Dec 7, 2021)

Indeed, it is somewhat grass roots. You are correct.

I have had two approaches, both unsuccessful.

*1*. I am friends with a high school technology teacher. They use RPIs for teaching robotics, programming etc. It's more fun than super serious, but nevertheless. (Edit: The kids are 15+ years of age, they can probably root/jailbreak a phone for crying out loud!)

I asked him to try using FreeBSD (what's FreeBSD he says! ). He was willing but the school would only accept those on the website because the kids had to install and run their own systems and they deemed it too hard. (You'd think LEARNING was a problem given that attitude!)

I even wrote a step-by-step guide. That didn't help, the school administration still didn't entertain the idea.

Now, if I had got the Raspberry Pi Foundation to make FreeBSD an official OS on their website, I think things would be different.

*2*. I have used (professionally and privately) a lot of SolidRun SBCs and SOCs and have tried to convince them to put work into providing official support for FreeBSD. I might as well hit my head on a brick wall. They have somewhat supported them on non-networking appliances like the Cubox et al, but it's a desert elsewhere.


----------



## astyle (Dec 7, 2021)

mark_j said:


> I asked him to try using FreeBSD (what's FreeBSD he says! ). He was willing but the school would only accept those on the website because the kids had to install and run their own systems and they deemed it too hard. (You'd think LEARNING was a problem given that attitude!)


gotta sell the idea of FreeBSD a bit better than that. Otherwise,  you just come across as a FreeBSD fanboi who doesn't care what others think, and just chants. 'FreeBSD is the greatest, FreeBSD is the greatest, FreeBSD is the greatest! Try it!'. Figure out what their difficulty is with getting stuff to run on Pi, and show them how FreeBSD does the same thing so much better. If you look at comments people make about what prompts them to move to FreeBSD from Linux - the reasons vary by the person. 
--
The school board would rather stick with officially listed stuff, because it's supported and easier to support and troubleshoot if something goes wrong. It's actually the exact same logic employed by the Forums and Foundation, if you think about it.
--
One idea for the tech class could be an 'extra credit' challenge:  Make a backup image that you can burn right back onto the board later (if need be), install FreeBSD, share results with class. And if you can stick with FreeBSD for the rest of the class, that's guaranteed 10% extra credit. \
--
Man, I just went off topic and hijacked the thread...


----------



## bakul (Dec 7, 2021)

mark_j said:


> Now, if I had got the Raspberry Pi Foundation to make FreeBSD an official OS on their website, I think things would be different.


This is simply not going to happen. 'Pi founders all use Linux and originally did substantial work to get Linux working on it. A huge user community has coalesced around the 'Pi running Linux and for them FreeBSD doesn't buy anything -- its API is just like Linux but far fewer devices work with it.

What would help users of FreeBSD on 'Pi is a framework or a stub driver that allows you run drivers in user mode. Sort of like _fusefs_ but for drivers. The same driver should work as a kernel mode driver with a #define change. Such a thing would speed up driver development for simple IO devices, the kind one attaches to a 'Pi.


----------



## mark_j (Dec 7, 2021)

astyle said:


> gotta sell the idea of FreeBSD a bit better than that. Otherwise,  you just come across as a FreeBSD fanboi who doesn't care what others think, and just chants. 'FreeBSD is the greatest, FreeBSD is the greatest, FreeBSD is the greatest! Try it!'. Figure out what their difficulty is with getting stuff to run on Pi, and show them how FreeBSD does the same thing so much better. If you look at comments people make about what prompts them to move to FreeBSD from Linux - the reasons vary by the person.



Excuse me? I stated what their reasons were and their objections. I cannot be clearer, I would have thought. 

(Though I never mentioned this, I suggested FreeBSD purely because he wanted to try headless computing where they installed putty on their laptops, connected to the PI via SSH and ran commands as a user; giving them concepts of multi-user systems etc).

Anyway, this is just two examples I have of coming up against established bias.


----------



## mark_j (Dec 7, 2021)

bakul said:


> This is simply not going to happen. 'Pi founders all use Linux and originally did substantial work to get Linux working on it. A huge user community has coalesced around the 'Pi running Linux and for them FreeBSD doesn't buy anything -- its API is just like Linux but far fewer devices work with it.



Yes I realise this. It was never about the RPI foundation putting FreeBSD on their website. It was an example about established bias and how the foundation could align to an SBC/SOC and push it and get kids in schools using their OS. 

I don't believe ARM is the chip to align to either. It's RISC-V.

It's another pie-in-the-sky musing requiring lots of money and is never going to happen. Enough from me.


----------



## astyle (Dec 7, 2021)

mark_j said:


> Excuse me? I stated what their reasons were and their objections.


You did.  I'd suggest that you re-read my post to find out what I said about that.


mark_j said:


> (Though I never mentioned this, I suggested FreeBSD purely because he wanted to try headless computing where they installed putty on their laptops, connected to the PI via SSH and ran commands as a user; giving them concepts of multi-user systems etc).


Why would Raspbian be *unable* to do that? If the whole class is having difficulty setting that up, or if Raspbian only accepted a specific version of the SSH server that has a Heartbleed bug, then yeah, you'd have a case for FreeBSD.


----------



## Beastie7 (Dec 8, 2021)

mark_j said:


> I think the foundation should push hard to align itself with a SOC like Odroid or RPI to get it out into schools and spread the love and critical mass for freebsd and perhaps add another free OS to the psyche of future CEOs, CIOs, lecturers, teachers, managers etc.



You're onto something. Kind of like a Linaro-style project for FreeBSD. I think the concept of Jails fits perfectly embedded stuff since it's so lightweight.

I hope you're watching Foundation!


----------



## Menelkir (Dec 8, 2021)

astyle said:


> Edit: just remembered that Debian does have 'community repos' that are used by derivative projects like Ubuntu... and so does Arch. Haven't checked Slackware, but I imagine it's pretty 'hands off' on its package management. There are some ideas from the Linux world that FreeBSD can look at and see what might work in their case.


Slackware have slackbuilds. And actually, I wouldn't mind having something similar to zugaina for gentoo, since we can have _OVERLAYS=_ for an *unsupported* extra port (in gentoo, you can use your own ports picked by hand from zugaina, but you're on your own if you do crap, I would accept this kind of risk in some scenarios).


----------



## mark_j (Dec 8, 2021)

astyle said:


> You did.  I'd suggest that you re-read my post to find out what I said about that.
> 
> Why would Raspbian be *unable* to do that? If the whole class is having difficulty setting that up, or if Raspbian only accepted a specific version of the SSH server that has a Heartbleed bug, then yeah, you'd have a case for FreeBSD.


I never said raspbian would be unable to do it. The 'case' for FreeBSD was to expand their knowledge to other systems, especially those designed as servers...  otherwise they would all just use windows 10.


----------



## astyle (Dec 8, 2021)

mark_j said:


> I never said raspbian would be unable to do it. The 'case' for FreeBSD was to expand their knowledge to other systems, especially those designed as servers...  otherwise they would all just use windows 10.


That is where the 'extra credit' idea comes in. Expanding the knowledge beyond what's 'officially available and supported'. But even in that case, gotta prepare a good discussion for the class, about how to mentally handle the idea that 'officially supported' fits the scenario of 'easy to maintain', but should not be a limiter. Some people treat 'officially supported' idea like it's the end to everything, and don't bother to venture beyond that. But the flip side of that is, 'officially supported' means it's relatively easy to support, and not get lost in the complex scenarios that can be difficult to debug and get right. There's a saying that too many cooks spoil the broth.


----------



## Jose (Dec 8, 2021)

I thought of one thing. Porting IP balancing from Openbsd's CARP.


			carp(4) - OpenBSD manual pages
		


The last time I used Freebsd in a professional setting, I configured a set of outgoing gateways that would back each other up with CARP. Because Freebsd's CARP does not have a load-balancing option, I had to  use stupid Ansible tricks to ensure that 1/n hosts used each gateway, where n is the number of gateways. This gets awkward very quickly when there are a large number of gateways, and requires constant maintenance. The Ansible script had to be re-run weekly to account for hosts being added to, and decommissioned from the running fleet.


----------



## hardworkingnewbie (Dec 9, 2021)

From my perspective there are a few things I'd like see to happen...

1. Bringing up Pf to the level of features it has in OpenBSD.
2. Polishing Bhyve more, e.g. adding SPICE as remote protocol, and less picky in other things, e.g. location of EFI files
3. Making the Raspberry Pi 4 fully functional
4. Implementing a GUI installer - partitioning disks e.g. is easier understandable for most in graphics than in text form
5. Replacing Sendmail as default MTA with Postfix 

These are my opinions only, and I will not discuss them here, since the topic is about "bring your ideas to the Foundation", not "defend your ideas before other users." Thanks.


----------



## jrm@ (Dec 9, 2021)

Thank you to everyone who took the time to contribute project ideas.  Here is a summary of what was submitted.  If your idea was missed or misrepresented, feel free to add or edit it.

2021 Foundation Call for Project Ideas


----------



## angry_vincent (Dec 11, 2021)

+1 for base jails orchestration ( tool shipped in base )


----------



## grahamperrin@ (Dec 11, 2021)

I added a missing link, a table of contents, and links to the calls.

Should I merge these two sections?

_Other Third-party Software Improvements_
_Other_
– some of what's already under _Other_ is third party software.


----------



## Erichans (Dec 11, 2021)

jrm@ said:


> [...]
> 2021 Foundation Call for Project Ideas



I noticed a reference to the wrong forum message (current reference).

I think the intended reference for the _- Wifi for the Raspberry Pi 400_ at Networking is:
https://forums.freebsd.org/threads/call-for-foundation-supported-project-ideas.83069/post-543609


----------



## grahamperrin@ (Dec 11, 2021)

Corrected – in two places – thanks Erichans


----------



## jrm@ (Dec 11, 2021)

grahamperrin said:


> I added a missing link, a table of contents, and links to the calls.
> 
> Should I merge these two sections?
> 
> ...


Sure.  If you think the organization is clearer that way.  Thanks.


----------



## grahamperrin@ (Dec 12, 2021)

<https://old.reddit.com/r/freebsd/comments/rdwcmu/-/>


----------



## grahamperrin@ (Dec 19, 2021)

Bluetooth manager for FreeBSD (GUI)
					

Hello,   I just want to tell you about a new desktop app for FreeBSD - Bt4BSD. It's a simple bluetooth manager (frontend for obexapp) specially for FreeBSD/PC-BSD. Not too functional now, but I think it's useful for users who use the system as a desktop.  So here it is...




					forums.freebsd.org
				






> … FreeBSD is an amazing system, but all the … configuration, tweaking, … time consuming … Bluetooth, … drives me up the wall. …





Beastie7 said:


> … Bluetooth support.



<https://wiki.freebsd.org/action/info/2021FoundationCFI?action=diff&rev2=21&rev1=20>



Beastie7 said:


> … Scott Longs Thunderbolt/USB4 work,



<https://wiki.freebsd.org/action/info/2021FoundationCFI?action=diff&rev2=20&rev1=19>


----------



## Alain De Vos (Dec 20, 2021)

Audio on a beaglebone black (AD1938).


----------



## shiorid (Dec 21, 2021)

john_rambo said:


> I am dying to use FreeBSD as my daily driver but for that I need a easy to use sandbox tool like firejail. Please create an equivalent of firejail for FreeBSD. Under Linux if you want to run Firefox inside firejail all you need to do is $firejail firefox. That's it.
> https://forums.freebsd.org/threads/...-the-only-reason-i-moved-back-to-linux.83175/
> 
> https://firejail.wordpress.com/


What about Capsicumizer? Not the same thing, but quite useful tho


----------



## Moth (Dec 21, 2021)

I think driver support, work on the Linux compatibility layer, and some sort of container orchestration are the areas I would like to see improvement. I saw other people suggesting the same in this thread.

I appreciate tools like Docker because they make it easy to see exactly what’s necessary to build a piece of software. Nix/Guix have similar benefits. It’d be cool to see some sort of practical, declarative package management on FreeBSD. I‘ve only seen one example of using Nix on FreeBSD, and it was pretty daunting to me.

I’ve got a five-year-old laptop with hybrid graphics that I’ve been running NixOS on for a while. I want to try FreeBSD out on it, but since Nvidia Optimus/Prime or any other hybrid graphics configurations aren’t really supported I’ve been hesitant. I can’t exclusively use the discrete GPU because the power consumption would be awful on battery, and the temperature increase can cause the device to halt. Nvidia’s recent inclusion of Vulkan support has been good to see though.

I’ve also tried FreeBSD out on the RPi2B+ and the experience wasn’t all that great. My best experience was running it on a 32-bit computer that should’ve been recycled long ago.


----------



## grahamperrin@ (Dec 21, 2021)

Moth said:


> … work on the Linux compatibility layer, … other people suggesting the same …



Summarised as _Application container framework like Linux OCI_, with reference to rootbert's <https://forums.freebsd.org/posts/543634>.



shiorid said:


> What about Capsicumizer? …



FYI the proposer's original thread (focused discussion): 









						Someone please create a FIREJAIL equivalent for FreeBSD ..... Lack of a sandbox tool is the only reason I moved back to Linux
					

Hi, I tried FreeBSD some months back. I am paranoid about security. I asked here how to configure PF and I got help almost instantly. Everything was going fine except running Firefox inside a sandbox. I tried very hard to run Firefox inside a Jail but unfortunately I didn't succeed. So I had no...




					forums.freebsd.org


----------



## Alain De Vos (Dec 23, 2021)

Raspberry ARM. Some sdcards are badly detected/working.


----------



## grahamperrin@ (Dec 27, 2021)

jrm@ said:


> … If your idea was missed or misrepresented, feel free to add or edit it.



jrm@ please, is it too late to add an idea that was _not_ expressed (here) before the summary was published?


----------



## kpedersen (Dec 27, 2021)

hardworkingnewbie said:


> 3. Making the Raspberry Pi 4 fully functional


Indeed, I would like to see this. There are more Pis out in the wild than almost any other brand of PC (I wonder if they have surpassed the entirety of i686 in terms of numbers?) and it is always sad to have half working SoCs lying around which are only partially usable. Basically the same problem with Android mobiles running custom images and probably the new vendor lockin Apple chips.

But I believe developers alone can't solve this. Possibly the FreeBSD foundation may need to provide financial incentive to the Pi foundation or Broadcom to get accelerated GPU or fully comprehensive power management (i.e for Firmware rights or Documentation).


----------



## astyle (Dec 28, 2021)

kpedersen said:


> Indeed, I would like to see this. There are more Pis out in the wild than almost any other brand of PC (I wonder if they have surpassed the entirety of i686 in terms of numbers?) and it is always sad to have half working SoCs lying around which are only partially usable. Basically the same problem with Android mobiles running custom images and probably the new vendor lockin Apple chips.
> 
> But I believe developers alone can't solve this. Possibly the FreeBSD foundation may need to provide financial incentive to the Pi foundation or Broadcom to get accelerated GPU or fully comprehensive power management (i.e for Firmware rights or Documentation).


I frankly see more Pi-related content on the Internet than FreeBSD-related stuff (Even with the bias of me specifically seeking out FreeBSD-related content most of the  time). I would imagine that from the FreeBSD camp, the closest we can come is GPIO-driven fartd.


----------



## grahamperrin@ (Dec 28, 2021)

astyle said:


> Pi-related content



Installing FreeBSD for Raspberry Pi | FreeBSD Foundation : freebsd


----------



## Ambert (Jan 6, 2022)

Suggestion: When the swap is nearly completely used (less than 2 GiB left), awaken the OOM killer early and make it send SIGTERM 5 seconds before sending SIGKILL (until the amount of free swap becomes greater than 2 GiB). If the swap becomes completely used anyway, go back to the default behaviour and make the OOM killer send SIGKILL without delay. Bonus point: allow the sysadmin to configure those two values (2 GiB of swap, 5 seconds delay) in a config file.


----------



## grahamperrin@ (Jan 6, 2022)

Ambert if you have not already seen it: 









						FreeBSD Foundation Soliciting Project Proposals
					

Hello everyone,  The call for proposals has been sent out.  -- Joe (with Foundation hat on)




					forums.freebsd.org


----------



## ram00 (Jan 10, 2022)

I favor

• anything that improves the flexibility and ease of use of security features

• anything that improves the flexibility and ease of use of jails

  [The py-focker port looks interesting.]

• a more up-to-date handbook and wiki

On the FreeBSD wiki, there are 29 Jail Management Tools!! "Some of them can be used only on older versions of FreeBSD (4.x / 5.x) ". Which ones is not shown.


----------



## Isoux (Jan 11, 2022)

Phishfry said:


> jmos has been doing an excellent job keeping an unofficial SeaMonkey build for us.


How can we find this port?


----------



## grahamperrin@ (Jan 11, 2022)

Isoux said:


> How can we find this port?











						Disaster strikes - SeaMonkey removed from ports tree
					

Without warning, like most disasters, SeaMonkey was deleted from the ports tree overnight. No note in UPDATING which I check before each port upgrade run.  I'm using the same mail spool dating back to Netscape Communicator on Windows NT in 1996.  Fear not, I've rescued my SeaMonkey port from the...




					forums.freebsd.org


----------



## cederom (Jan 12, 2022)

Solid AMDGPU + OpenCL please


----------



## grahamperrin@ (Jan 13, 2022)

grahamperrin said:


> … add an idea that was _not_ expressed (here) before the summary was published?



Two or three things repeatedly drifted into, then out of, mind. More than anything: *GParted*. 









						Gparted-like program for disk analysis
					

Can anyone suggest a FreeBSD program similar to Gparted which can analyse a disk in terms of partitions and filesystems. I have a disk where I am unable to identify the filesystems on the partitions, and don't know how to identify them...




					forums.freebsd.org
				




The idea, here, is not _solely_ for analysis. 

It's not something for which I could write a proposal at this time.


----------



## grahamperrin@ (Jan 20, 2022)

aimeec1995 gnath meine I should have thought of this in November, when ideas were called for:

*Widevine*.
For anyone who would like to discuss:

a Widevine-specific topic.


----------



## grahamperrin@ (Feb 19, 2022)

Looking forward to funding decisions (some time in March, I guess). 

jrm@ or anyone at the Foundation: how many proposals were received? 

Just curious …


----------



## ziomario (Feb 19, 2022)

This is my proposal :

After 1 month of research we have found the technical reasons why a modern Nvidia GPU if passed through inside a Windows 10 / 11 vm produces the error 43 (actually the error 12). It happens because it misses "line interrupts support for passed through devices" ; actually there is the need of a massive change inside the bhyve source code. As you probably know,this change is not a priority for the developers. To achieve the goal will be a very step forward for bhyve and for all the freebsd community. Let me know your thoughts. thanks.


----------



## jrm@ (Feb 23, 2022)

grahamperrin said:


> Looking forward to funding decisions (some time in March, I guess).
> 
> jrm@ or anyone at the Foundation: how many proposals were received?
> 
> Just curious …



For this call for proposals, we only received a few applications and are considering one for funding.  This was fewer responses than for past calls, but anecdotally it's recently been difficult to fill positions for skilled developers across the tech industry.  Other than these responses, we do have a few pending applications, one from a company that we have had good results with in the past.  Other sponsored FreeBSD work continues: wireless, OCF/Wireguard, and the pull request for RAID-Z expansion looks like it will be merged into the OpenZFS repository soon.

We send these calls out periodically to remind the community that we are keen to fund FreeBSD work (thanks to all your donations) that may be difficult for volunteers to complete.  Deadlines are often good motivators, but just because the deadline has ended, doesn't mean that we won't still accept good proposals.  When skilled FreeBSD developers or documentation writers are available with good proposals, we are ready to work with them.


----------



## twoface (Feb 27, 2022)

I am not sure if these suggestions can be considered in the Project Ideas, but here some that will need some funds…

Better HID driver support​Well, enhance the new HID subsystem, as it can be quite buggy, even with ~16 years old USB keyboard that used to work fine… (Moreover I am not alone in this kind of situation, take a look at the forum).

Make INIT(8) faster​INIT(8) make any system start/reboot very slow. If there is a way to reduce the boot time, no matter how many time in a year you reboot your machine, it should be done.

Having to reboot for any reason your server (to get ride of zombie processes or whatever) takes too many time, especially for a server that host critical services and applications…

We are no more in 90 or in 2000; now things have to run fast, as people wants things right now.

Yes INIT(8) works fine, but it is very slow. And if “working fine” means no change, well stop working on anything trying to accelerate changes in the operating system, as it just works. Do not try to bring more people to the BSD hold, and just let FreeBSD die…

I insist, I write here MAKE INIT(8) FASTER (through parallelism?), not replace it.

Better workstation experience​Increase efforts on laptop and desktop usage of FreeBSD. Indeed, we can have over 30,000 open source software packages that are easy to install, but some are outdated, others are buggy or broken, while others are missing…

FreeBSD as laptop is almost impossible, and some users experience some lags with their desktop computer, even with a descent machine. Maybe, somebody should really investigate on the causes of these issues.

Here, I have a descent and recent PC (6 cores CPU, 32GB, relatively big GPU), and experience me too some lags even when listening audios, with no reason, while under Windows or any Linux distribution the system works perfectly fine.

Pkg​Provide a better mirror management​It can be very difficult to get a decent speed with pkg. It takes sometimes more than 1 hour to get llvm90-9.0.1_3.pkg downloaded (that was the case two days ago on this setup).

Unfortunately, tweaking `/usr/local/etc/pkg/repos/FreeBSD.conf` does not guaranty to have the fastest mirror (behind a vpn, I can download faster with an US mirror than the EU one)…

Add pkg new options​`search -file`​Provide a way to find files inside packages. When developing, we often have to use some libraries, especially when porting a software from a system to another. Packages that provide a library file have not the same name across systems, so I too often have to go to pkg.org to find out which package I have to install on FreeBSD.

`-no-recommended`​We do not need everything that came with a package by default. According to our need, the Internet plan, and disk size, etc, it would be great to control on how to install packages, for example, by installing only required packages. Moreover, it will reduce the attack surface in such system. For now, there is no real policy, so some packages are well sliced, but other not.

Better “decoupling policy” in ports and packages​Offer ports and packages with less superficial dependencies, particularly useful for limited system (among other, limited SSD size, raspberry):

for LibreOffice add in ports support for `–enable-split-app-modules`, and offer the installation of individual application (writer, cal, and so one) with pkg ;
not gluing Gnome with unnecessary applications like Cheese, Glade GTK demo, Print Editor…
TexLive in ports is old, if we download it from the official web, we do not need gigs of old TexLive that is glued with Gnome Latex…

Try to get more “languages supported”​There are missing languages for the documentation (yeah a lot), as well as missing myths dictionaries, for language like Arabic, Hebrew, Turkish (yeah I know, these are not inside the OS "core"), etc… Maybe we should find a way to increase widely language support.

Jail​Provide us unprivileged jail​For now, we have to be root or in wheel group (via `sudo`) to create and to start a jail. Please provide us a way to do the same thing as unprivileged user. `jailme` allows to start a jail as unprivileged user, but not to create jail, like `lxc-create`.

Orchestration tools​Some orchestration tools like lxd could be very helpful to manage lot of jails.

Better documentation and Wiki​It will be very helpful to get a better documentation, as well as a better Wiki especially for new users.

Here some subjects that are not well documented:

how to get Internet access for jails, virtual machines, etc.
how to setup different kind of virtual network, for which use case;
how to use vale(4).
how to get Wayland working with any supported DE.
Try to have a better upstream cooperation​Maybe by dedicating, upstream, some developer on some project, could be beneficial, as well as more “meeting” between “FreeBSD” and leaders of major projects too.

The goal? To get more abstraction layer upstream that will facilitate the work downstream for FreeBSD ports and package, and maybe to stop this Systemd assimilation, acting like Borgs, in more and more projects.

I see too often (to my taste) FreeBSD maintainers acting alone, even when being stuck on issue for months, without trying to reach the maintainers of the initial project (if ever)…

LibreOffice​Why LibreOffice cannot be build directly from sources while there is some work already done? Why we need to add more patch downstream?

Eclipse and other IDE​To be competitive as a workstation, FreeBSD must have more Opensource IDEs. For now, the choices are pretty limited, and even Eclipse is outdated and a real pain to get work outside the port. Atom is missing too, and very painful to build from upstream sources. It probably contributes to the fact that BSD are used by only 0.18% developer, when Linux distributions are used by 25.32% of them, competing with MacOS.

Host some ports inside FreeBSD​Make some critical ports and packages (like Firefox, and so one) run not by benevolent, but by some FreeBSD developers. Maybe through a vote, or after some consultation, decide which package will be chosen. Yes, it means to maybe increase the FreeBSD "core" responsability.

"_The Power to Server_", a failure?​The Power to Server what? How? Whom? When?

Try to understand why FreeBSD keep failing to attract people that prefer to go to Gentoo or ArchLinux, and the like, while these distributions often do a bad coping/pasting of FreeBSD (if only by choosing Systemd). Yes they have a better hardware support, but what lead Intel and others to start ignoring FreeBSD and to keep ignoring it?

Now FreeBSD is lagging even in server field. Again, why almost all web hosters propose only some Linux based distributions, and not FreeBSD (it hasn't always been the case)? What these Linux based distributions do better?

Yes, I know, the foundation have increased marketing support, and try "to increase the awareness and use of FreeBSD", but there is a big *OLD* issue there. Even Deb Goodkin “now” sees Linux as a threat for FreeBSD.

Finally! 15 years ago, FreeBSD fanboys mocked me when I was saying and writing that Linux was a threat. The most stupid of them keep answering that Linux is only a kernel, FreeBSD is not a desktop OS, and do not need to evolve…

Anyway, if nothing is done, FreeBSD will probably die, soon or later, as it will deem useless.

Whonix, QubesOS, Tor browser​Indeed, why Whonix choose to use Debian as a base, 10 years ago? Why Qubes Os did not choose FreeBSD but Fedora, 10 years ago? Yet, at that time, Debian and FreeBSD were pretty equivalent.

FreeBSD is supposed to be more secure, yet it was not chosen. There is obviously something wrong…

Why Tor browser is not available for FreeBSD?

Why “big projects” for those privacy and security count do not choose FreeBSD as their base or add support for FreeBSD?

Kill the Mascott​Finally, maybe more subjective, I really thing that FreeBSD should discard its mascot that looks like Elmer Fudd looking at himself experiencing satanic acid trip.

Yeah, I hate it. I disagree with Robert Watson (with all due respect it should let marketing people working on that issue). FreeBSD need a new mascot or simply get ride of it, as it is tacky, and stink old fashion.

Did you ever asked people how they find him? I have been told by young IT people that they find him crappy, and pretty representative of the redneck FreeBSD users…

Pay survey if needed, as a bad image will not attract people and moreover young people, toward FreeBSD.


----------



## shkhln (Feb 27, 2022)

twoface said:


> "_The Power to Server_", a failure?​The Power to Server what? How? Whom? When?


Consider reading that slogan again.



twoface said:


> FreeBSD fanboys mocked me when I was saying and writing that Linux was a treat.


Who wouldn't?


----------



## hbsd (Feb 27, 2022)

twoface said:


> Why Tor is not available for FreeBSD?


security/tor


----------



## twoface (Feb 27, 2022)

shkhln yeah, fixed…

hbsd I mean Tor browser


----------



## drhowarddrfine (Feb 27, 2022)

twoface Your list contains items that are strange, false, have nothing to do with what FreeBSD has control over and personal preference. pkg is NOT slow. I've used FreeBSD as my workstation for nearly 20 years. And any attempt to make FreeBSD a personal computer for the average user is misguided.

btw, Beastie, the current version, was created by John Lasseter of Pixar. Maybe you've heard of him. He offered me a job once.

But posts on lists like this happen every month and we have to put up with it as we push forward with ease and get real work done.


----------



## hbsd (Feb 27, 2022)

twoface said:


> _*[FONT=monospace]hbsd[/FONT]*_ I mean Tor browser


There is nothing special about Tor Browser
Tor Browser is just: Firefox + Tor 

[HOWTO] use Tor network and web proxy


----------



## rootbert (Feb 27, 2022)

hbsd said:


> There is nothing special about Tor Browser
> Tor Browser is just: Firefox + Tor
> 
> [HOWTO] use Tor network and web proxy


sorry for being offtopic again, but I have a strong need to educate users.
aaaand again: *NO, IT IS NOT! *Tor Browser is a modified version of Firefox! If you use your normal firefox behind tor you can pretty easily be traced.









						Tor Browser
					

Hello everyone, I have been looking for Tor Browser (torproject.org) for x86 and ARM. I've noticed a few old threads but not actually any solutions. Any experience or suggestions how to get Tor browser on FreeBSD? Thank you.




					forums.freebsd.org


----------



## twoface (Feb 27, 2022)

> twoface Your list contains items that are strange, false, have nothing to do with what FreeBSD has control over and personal preference.



You are too vague…



> pkg is NOT slow. I've used FreeBSD as my workstation for nearly 20 years.



Well, I found on the forum at least one topic about pkg being too slow… Maybe you are in some area where pkg works fine, but seems not being the case for everyone.



> And any attempt to make FreeBSD a personal computer for the average user is misguided.



Never wrote that, but why this would be misguided?



> btw, Beastie, the current version, was created by John Lasseter of Pixar. Maybe you've heard of him. He offered me a job once.



Ok, so no need to redraw Superman, nor Batman. Yeah, let's keep their crappy old design from 30's in 2022.



> But posts on lists like this happen every month and we have to put up with it as we push forward with ease and get real work done.



Wow, what arguments…

@hbsd what you wrote is just dangerous.


----------



## hbsd (Feb 27, 2022)

rootbert said:


> sorry for being offtopic again, but I have a strong need to educate users.
> aaaand again: *NO, IT IS NOT! *Tor Browser is a modified version of Firefox! If you use your normal firefox behind tor you can pretty easily be traced.
> 
> 
> ...





rootbert said:


> If you use your normal firefox behind tor you can pretty easily be traced.


Yes you can always be traced even with tor browser. tor is not secure as you think it is:

Is Tor Really Anonymous and Secure?

Unfortunately, there is no such thing as 100% security. You are at risk even if you use JavaScript in your browser!
Can you name some of the features that made Tor Browser better than Firefox or even Chromium?


----------



## Beastie7 (Feb 27, 2022)

twoface said:


> stuff



Found an Ubuntu user. Don't let the door hit you on your way out.


----------



## drhowarddrfine (Feb 27, 2022)

twoface said:


> You are too vague…


You list too many items this early in the morning. We tire of these repetitive lists posted by the occasional new user ad nauseam.


twoface said:


> I found on the forum at least one topic about pkg being too slow


You can find one of anything if you search long enough. In the meantime, pkg works great for the rest of us and I use it every day.


twoface said:


> let's keep their crappy old design from 30's in 2022.


Beastie was first created in the 1970s and updated in the 1980s. That it is old and not to your liking is personal preference and has no meaning to the majority who find him entertaining. Your statement is no reason to change it.


----------



## sidetone (Feb 27, 2022)

twoface said:


> Better HID driver support​Well, enhance the new HID subsystem, as it can be quite buggy, even with ~16 years old USB keyboard that used to work fine… (Moreover I am not alone in this kind of situation, take a look at the forum).





			https://freebsdfoundation.org/wp-content/uploads/2021/08/Human-Interface-Device-HID-Support-in-FreeBSD-13.pdf
		


It describes many of the improvements in the HID system in FreeBSD 13.0, and it describes how HID functions on NetBSD. I think it will be a lot closer by the time of the next FreeBSD version. I bet it can be improved on from there. It's a matter of time before the foundation is layed for getting multimedia keyboard keys and other devices to work. Once that happens, people will start getting more functions and devices to work, and start documenting those steps.


twoface said:


> I insist, I write here MAKE INIT(8) FASTER (through parallelism?), not replace it.


When I used linux, there were different run levels, and that was confusing. The only way I can see parallelism, is if instead of being numbered runlevels, each run level is separated by the type, for instance: a runlevel for Internet start up, while the other runlevel is labeled desktop, one for filesystems, and another runlevel for everything else starts up starting at the same time. Firewall startup tasks may be better inside an Internet runlevel, that starts up in the section before the net comes up.


twoface said:


> Add pkg new options


There are many package and ports management utilities in ports, it has its own category of ports-mgmt. I use portmaster.


twoface said:


> Better documentation and Wiki​


Use the How-to Guides section in the forums and other documentation. The official wiki in my opinion took a step back from what it was before. From what I understand, editing it became easier. I've tried before, and one day will try it with the new system. What's really discouraging is what it takes for commits, and how in comparison Bugzilla for unmaintained ports doesn't get addressed.


twoface said:


> LibreOffice​Why LibreOffice cannot be build directly from sources while there is some work already done? Why we need to add more patch downstream?


For office software: the best way requires a company to get behind it. Apache OpenOffice makes more sense for companies to get behind, but this one has dependencies on Java. Also, this is something that would be better of all of the BSD's got together and collaborated on, and I don't see this until there's a native or improved graphical toolkit. Maybe QT5 or Lumina will do in the meantime. LibreOffice is good for now.


twoface said:


> Finally, maybe more subjective, I really thing that FreeBSD should discard its mascot that looks like Elmer Fudd looking at himself experiencing satanic acid trip.


It's odd to me how the Beastie mascot wears Converse and ends up advertising for that brand. Any mascot should avoid any clothing brand. I know feet are difficult to draw, and it often comes out wrong. In video games and cartoons, they tend to draw the feet and hands of characters correctly. If it's going to wear shoes, they can be changed to something more generic. Keep the mascot, except loose the current shoes.


Each item needs to be refined so what it takes is shortened and so nonessential wants can be removed. Learning about what already exists, and as much about how it works. Coming up with something that makes it easier and what works with the bulk of what's already there, functionwise. A lot of learning in the How-tos and other places can reduce a few needs on a list, and reduce the requirements to get them. It's about what's essential, and what makes it easier yet better for implementation of better features. The list being unrefined seems to offer more problems than solutions.


----------



## kpedersen (Feb 27, 2022)

twoface said:


> Ok, so no need to redraw Superman, nor Batman. Yeah, let's keep their crappy old design from 30's in 2022.


Absolutely the next generation should design and implement something new and "modern".

If you think you can produce a design that is popular and captures the legacy of FreeBSD, who knows, it might be accepted by the community. For example, I am not perfectly content with the strange red sphere with horns that has been adopted as the official logo.


----------



## grahamperrin@ (Feb 27, 2022)

Beastie7 said:


> … Don't let the door hit you on your way out.



Please, let's all show the kinder side of our nature.

Publicly dismissing people gets us no closer to technical discussion.



twoface said:


> … not well documented:
> 
> how to get Internet access for jails, …



Yeah, there's a confusing mishmash of scattered information.









						jails - Jails: stopping (prolonged deaths), starting, networking et cetera
					

Below, what's wrong?




					forums.freebsd.org
				




<https://forums.freebsd.org/posts/558165> in particular.
Defocusing from networking: this morning I made some minor improvements to <https://wiki.freebsd.org/Jails>, but still, it's categorically stale.


----------



## twoface (Feb 27, 2022)

> Unfortunately, there is no such thing as 100% security.


hbsd No body wrote such a thing.


drhowarddrfine


> You list too many items this early in the morning. We tire of these repetitive lists posted by the occasional new user ad nauseam.


You can ignore me. For information, I joined the forum 13 years ago. Occasional user? Maybe, but what makes me a new user?


> You can find one of anything if you search long enough. In the meantime, pkg works great for the rest of us and I use it every day.



Can you define what is “the rest of us”? What are your proofs? So those who suffers from slow mirrors have no say?



> Beastie was first created in the 1970s and updated in the 1980s. That it is old and not to your liking is personal preference and has no meaning to the majority who find him entertaining. Your statement is no reason to change it.



What are your proofs? Did the FreeBSD Foundation ever made a survey? Does the Foundation have any information to share on this subject?

Thanks God, there are users that are open-minded here. Unfortunately, I can see that some of you are trapped in an “ideological” frame that keep you in a state of intellectual isolation. You only produce an echo chamber effect leading you to mental rigidity.

There is a call for ideas, and I found nothing preventing me to write down some of my thoughts. Maybe some of you share my ideas, other not, and it is perfectly fine, but know that there is a world outside your own world conception.

grahamperrin I just ignore this kind of troll.

kpedersen, maybe one day if I have time.

Anyway, these off topics are useless. As far as I'm concerned, the subject is closed.


----------



## drhowarddrfine (Feb 27, 2022)

twoface said:


> these off topics are useless


That's what I'm telling you. Glad you finally noticed


----------



## grahamperrin@ (Feb 27, 2022)

twoface said:


> … Maybe some of you share my ideas, other not, and it is perfectly fine, but know that there is a world outside your own world conception. …







> … As far as I'm concerned, the subject is closed.



It'll be smart to have a little more follow-up on some of your points, but there's no rush. 

In the meantime, recently updated: 

FreeBSD Google Summer of Code Ideas

includes a link to <https://wiki.freebsd.org/IdeasPage>, which was new to me.



> … what makes me a new user? …



I once made the mistake of blindly trusting the _New Member_ statement that's automatically generated by XenForo. Context, including a date, appears when pointing at a person's name or avatar:






There's probably discussion of the statement at <https://xenforo.com/community/>.


----------



## ralphbsz (Feb 27, 2022)

twoface said:


> Better HID driver support
> Better workstation experience
> LibreOffice
> Eclipse and other IDE


I remain of the (unpopular) opinion that GUI/DE use of FreeBSD is less important than the base system (CLI, server). If there isn't enough money and manpower for both, we need to focus on the latter.



> Make INIT(8) faster
> I insist, I write here MAKE INIT(8) FASTER (through parallelism?), not replace it.


On modern SSD-based machines, does it really matter? Can this be done without a major (incompatible) redesign of how services get controlled? Before we commit to this, let's measure how much we could save. And come up with a good design; parallelism is hard.



> (Pkg) Provide a better mirror management
> (behind a vpn, I can download faster with an US mirror than the EU one)


It seems to me that the root cause here is your VPN being configured strange. Let's fix that first, before throwing the baby out with the bathwater.



> Add pkg new options: `search -file`


That seems like a good idea.



> `-no-recommended`
> Better “decoupling policy” in ports and packages


Part of the problem is that the user (you!) need to understand the difference between packages and meta-packages. The latter are intended to install a lot of stuff at once.
Another part of the problem is that package maintenance is done by volunteers, who may have different styles. Training and guidance might help here. As would ignoring problems in DE/GUI packages.



> Try to get more “languages supported”


I18n and a11y take a massive amount of effort. Nearly all of it is used for GUI/DE efforts. This is in the "nice to have, but not vital" category.



> Provide us unprivileged jail


What is the purpose of a jail? Privilege separation mostly. If you have just one non-privileged user, why would one want to do privilege separation? Please explain a clear use case for this.



> Orchestration tools


The goal of these tools (whether it's docker, kubernetes, containers or lxd) is to make installation of complex software packages easy, by bundling prerequisites with the package. To some extent, they are a work-around for the balkanization of Linux distributions. To some extent, they are a work-around for continuous integration workflows, where you want to package a snapshot of the state of prerequisite libraries. None of these problems exist in FreeBSD, which has only one distribution, and uses a release workflow.

If your idea is to create ways to run existing Linux containerized packages on FreeBSD: Why? There is a perfectly good OS available to run them on (namely Linux).



> Better documentation and Wiki


Where the handbook is outdated or incomplete, let's get it updated. It is an excellent form of documentation.



> Host some ports inside FreeBSD


I agree that some packages are so commonly needed, and when needed so vital, that they need to be really well maintained. Examples include python, perl, apache, some databases (MySQL, BerkeleyDB, SQlite). But I have not seen problems with the maintenance of these crucial packages.

I consider Firefox mostly irrelevant. It is not a core function of an operating system.



> _The Power to Server_", a failure?


I can summarize all your writing in this section as: FreeBSD has a very low market share. I don't see that as a problem. It is a very good operating system. It had a low market share 15 and 20 years ago, and hasn't died yet. A rush to popularity would be suicidal.


----------



## astyle (Feb 27, 2022)

twoface said:


> Well, I found on the forum at least one topic about pkg being too slow… Maybe you are in some area where pkg works fine, but seems not being the case for everyone.


If you actually pay attention to the topics and finish reading them - you will discover solutions. You kind of have to make it clear that you're making an offhand observation, otherwise it's hard to take you seriously.
Edit:
It's probably just me being anal, but spelling mistakes do drive me nuts. It's "power to serve", not "power to server". Just take a look at the very top of this page, where I took this snip:




I guess I'm like a compiler, where typos mean I refuse to compile the whole thing.
Edit 2: For updating the Beastie - Just look for FreeBSD -themed wallpapers. I can also point to someone on these forums who has undeniable skill with Gimp, and a sense for what makes good art - Trihex - he's the one who created quite a few cool-looking wallpapers.


----------



## kpedersen (Feb 27, 2022)

twoface said:


> kpedersen, maybe one day if I have time.


That is fair and is pretty much the answer I was kind of baiting for. Basically the old designs and stuff from the 70's (not quite the 30's!) is "good enough". There is no point re-implementing it when there are plenty of new interesting problems to solve.

I think it is fair to say that no-one has time for that.


----------



## grahamperrin@ (Feb 27, 2022)

twoface said:


> … find out which package …



ports-mgmt/pkg-provides

An example:


```
% pkg provides bin/sndio
Name    : sndio-1.8.1
Desc    : Small audio and MIDI framework from the OpenBSD project
Repo    : FreeBSD
Filename: usr/local/bin/sndiod
          usr/local/bin/sndioctl
% uname -KU
1400053 1400053
% pkg -vv | grep -e url -e enabled
    url             : "http://pkg0.bme.freebsd.org/FreeBSD:14:amd64/latest",
    enabled         : yes,
    url             : "https://alpha.pkgbase.live/current/FreeBSD:14:amd64/latest",
    enabled         : no,
    url             : "file:///usr/local/poudriere/data/packages/main-default",
    enabled         : yes,
%
```



twoface said:


> … parallelism?), …




```
% sysrc rc_parallel_start ; uname -KU
rc_parallel_start: YES
1400053 1400053
%
```

I think of it as dormant.









						the new  parallel boot
					

thanks for vermaden  and their useful posts  I decide to give a try  rc: implement parallel boot  I am like fish in the water :rolleyes:  the steps was this:  patch the kernel file /usr/src/libexec/rc/rc  then I added rc_parallel_start="YES" in /etc/rc.conf reboot and for final step execute...




					forums.freebsd.org
				






twoface said:


> … INIT(8) make any system start/reboot very slow. …











						What is the minimum boot time of FreeBSD?
					

The FreeBSD init system just takes a looooong time and although I am just running it in a VM right now when I actually use FreeBSD for desktop usage the bootup time might be a problem. When windows took too long to boot I would end up doing nothing productive. It breaks the flow. I am gonna use...




					forums.freebsd.org
				




<https://forums.freebsd.org/posts/556953> keyword TSLOG



twoface said:


> … mascot …



It's no longer seen unless the user requires it. I don't require it. From my loader.conf(5):


```
# <https://gist.github.com/priyadarshan/7e1a69f019150a0c9dbc3b881f584c18#file-freebsd_11_notebook_install-txt-L76-L77>
# loader_logo="beastie"
```


----------



## astyle (Feb 27, 2022)

kpedersen said:


> That is fair and is pretty much the answer I was kind of baiting for. Basically the old designs and stuff from the 70's (not quite the 30's!) is "good enough". There is no point re-implementing it when there are plenty of new interesting problems to solve.
> 
> I think it is fair to say that no-one has time for that.


Hey, right now, we're going into 20's anyway (*Modern *version of Roaring 20's  ), 30's are not that far away, either. There are fans of old-school art out there, y'know.


----------



## kpedersen (Feb 27, 2022)

astyle said:


> Hey, right now, we're going into 20's anyway (*Modern *version of Roaring 20's  ).


Haha, yeah good point. With the age and lifespan of some of this software, this might actually start to overlap and get confusing


----------



## grahamperrin@ (Mar 2, 2022)

twoface said:


> … some users experience some lags with their desktop computer, even with a descent machine.



Yeah, I read that a few days ago, but didn't follow up 'cause (a) troubleshooting there is off-topic (the poll ended, with a good number of voters); and moreover, (b), "I use FVWM2" is not nearly enough to form the basis of an investigation.



> Maybe, somebody should really investigate on the causes of these issues.



Certain, people _do_ investigate. There's plenty of evidence of this.

Where there's no knowledge of hardware, the version of FreeBSD is not known, and so on: expect investigation to be slow, or nonexistent ;-)



> … FreeBSD is lagging even in server field. …



<https://forums.freebsd.org/profile-posts/3729/> – don't shoot the messenger


----------



## grahamperrin@ (Mar 3, 2022)

twoface said:


> *Provide us unprivileged jail*
> 
> For now, we have to be root or in wheel group (via `sudo`) to create and to start a jail. Please provide us a way to do the same thing as unprivileged user. `jailme` allows to start a jail as unprivileged user, but not to create jail, like `lxc-create`.











						Unprivileged jails
					

Linux has Unprivileged containers, through which a user can manage containers if admin allows him via a special config file, faking some parts with user subuids and subgids, and others, like create devices, etc… are "bypassed" during the installation process of "tweaked" templates of lxchub (or...




					forums.freebsd.org
				





Also: <https://cgit.freebsd.org/src/commit/?id=a40cf4175c90142442d0c6515f6c83956336699b>



> Implement unprivileged chroot


----------



## SirDice (Mar 4, 2022)

/moderator hat on

Deleted a couple of the last posts as they were veering the thread in a political direction.


----------



## sidetone (Apr 11, 2022)

The shoe style of this mascot for MiniBSD is much better. Some other aspects of this mascot are very good.


----------



## obsigna (Apr 11, 2022)

Hopefully, impact on energy consumption does not turn this idea too much into a political one.

I started using FreeBSD mainly as server OS in 2007 (v7.x), now all my system are on 13. That time we were using GCC 4.2.1 which was replaced by Clang in FreeBSD 10. Ever since we happily built the kernel, world and the software from the ports with -O2 optimization.

I myself started programming on DOS and Macs in 1984, later MacOS X, Windows and finally FreeBSD in C, C++ and Objective-C. I always built and still do build my software, which all over the decades amounts to a few hundred thousand of lines, using the -O3 optimization for the Release builds and -O0 for the Debug builds. With one exception, I did not experience a singe issue, I mean difference in execution results between -O3 and -O0. The difference was a bug in the C++ compiler of MPW (Macintosh Programmer’s Workshop), and this became quickly fixed, after I submitted a bug report. Anyway this is ages ago, and no one does even remember MPW anymore, does one?

Talking about clang, The performance difference between -O0 and -O3 is upto 50 % and between -O2 and -O3 about 10 %. When compiling on Core iX processors we can get another boost by -O3 together with -march=native of in total 25 % compared to -O2.

All that said, I think it would be time to switch at least building the kernel and world from -O2 to -O3.

Considerable amounts of FreeBSD servers are running 24/7 all over the world, and I can imagine that the drop of energy consumption by going from -O2 to -O3 may perhaps not be of an earth shaking quantity but yet a significant one. Think about how the savings are doubled by reducing the cooling necessities.
Doing this in general for the ports as well, may have a negative effect, since -O3 built times would be higher and hence increase the energy consumption. Perhaps this would be useful for daemons (Apache, nginx, etc) and build & runtime environments (llvm/clang, python, openjdk, php, etc.), but not for utilities which are running for short period of times once in a while.

A suggestion, like everybody can do this as they like falls short the purpose, i.e. general energy saving of some significant amount. The impact would be of some significance if everybody would receive the prebuilt -O3 kernel & world compared to a few dozens of people building their k&w with -O3 by themselves.

PS: This could be a first step of a bigger optimization project. Think about LTO.


----------



## sidetone (Apr 11, 2022)

If it's better, it doesn't have to be about that particular reason. It should be better, when it can be. A lot of good comes out of things being better. I know these sound like empty words, but there's sometimes resistance to things being made better. A kernel's better use of energy has benefits that help with a better computer system, maybe slightly faster, and personal energy savings. Compiling times maybe, but how often is it compiled in a month? Anyone who criticizes it to be political, is making up excuses to be political and to perhaps have phony outrage.

Aside from that, if the kernel can be optimized to -O3 by default, the code has to be made consistently better so there won't be inherent crashes and vulnerabilities to crashing. That works. Maybe for the base system, it could also be done.

Airplane manufacturers and engine manufactures go for increases of 1%. Which would too extreme for these purposes, except reasons for testing, though they want competitive savings. Solar panel manufacturers also go for small increases, perhaps not for mass manufacturing, but for purposes of those small percentages tallying up over time to a significant percentage which then can be for manufacturing purposes.


obsigna said:


> Doing this in general for the ports as well, may have a negative effect, since -O3 built times would be higher and hence increase the energy consumption.


For ports, it would cause more problems than it solves. Much wouldn't be compiled, and it would take up too much time in both compiling and in effort that would never get achieved.


----------



## mark_j (Apr 12, 2022)

obsigna said:


> [...]
> The difference was a bug in the C++ compiler of MPW (Macintosh Programmer’s Workshop), and this became quickly fixed, after I submitted a bug report. Anyway this is ages ago, and no one does even remember MPW anymore, does one?



Me, I was Think C then Codewarrior. Think C had a great IDE, much like Turbo C's suited DOS real well.



obsigna said:


> All that said, I think it would be time to switch at least building the kernel and world from -O2 to -O3.



I'm willing to bet there would be too many "optimized out" messages to make debugging anything but useless.


----------



## Brian546 (Apr 12, 2022)

In no particular order:

- Ability to delete files from a tar file. Yes I know, GNU tar. I still prefer native tools. 
- Ability for IPFW to keep state on related icmp packets, not just the connection itself. 
- Clean up spilled messes in the base system (like local unbound since it's already in the ports)
- Make mergemaster compatible with Git so those of us who've used it over the last few decades can continue using it


----------



## grahamperrin@ (Apr 12, 2022)

obsigna said:


> … -O2 optimization. …



Is that, <https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html>?


----------



## sidetone (Apr 12, 2022)

grahamperrin said:


> <https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html>?


It's like that, except for LLVM/Clang compiler. Many of those arguments are the same. These options can go into make.conf. I set my kernel build to be optimized.

IDR, if building world with too many optimizations caused crashes, warnings or errors. I stopped building world anyway and get performance gains by installing a custom kernel.


----------



## ralphbsz (Apr 13, 2022)

Brian546 said:


> - Ability to delete files from a tar file. Yes I know, GNU tar. I still prefer native tools.


Is there a common use case for this? It's certainly possible to implement (more on that below), but is it needed often enough?

Also, this is actually quite limited and inefficient. The way it has to be implemented is: seek to the point where the deleted file is stored (which requires reading the header for each file, since tar files don't contain a manifest, so lots of strided reads), then copy the remainder of the tar file over itself to re-use the space freed by the deleted file. For this reason it can only work if the tar file is stored uncompressed, and on a modifiable format (like in a file on disk); it doesn't work in a pipe or on tape. Efficiency: if you get unlucky and the deleted file is near the beginning, you'll read and write most of the tar file. It's still slightly better than manually extracting everything, deleting one file, and re-archiving, but not by much.

I even wonder whether the GNU implementation is safe against interruptions, because it needs to overwrite a file in place. Assuming an example implementation, I can easily construct a scenario where a badly placed Control C leaves the tar file permanently damaged. Someone should read the source code to check. Implementing this in a transactional fashion (safe against interrupts) is hard enough, I could use it as an interview problem for hiring computer scientists.


----------



## Brian546 (Apr 13, 2022)

ralphbsz said:


> Is there a common use case for this? It's certainly possible to implement (more on that below), but is it needed often enough?



I create a lot of archives and frequently change what is in them. Like you said though, it's probably not needed often enough by users, so definitely should not be a priority. I have no problem recreating the files.


----------



## astyle (Apr 13, 2022)

I'm not a mod, but even I can see that the last few replies are already a totally different conversation than the original topic of the thread. The only connection is that we seem to have latched onto somebody's wish list and used that as a conversation starter...

I have to admit, it is some effort to do it properly: 

Starting a new thread, 
linking to the original post in another thread,
Typing out a coherent explanation that encourages conversation.
It's much easer to pretend that you're standing in line for beer, and make comments to pass the time.


----------



## grahamperrin@ (Apr 13, 2022)

jrm@ said:


> For this call for proposals, we only received a few applications and are considering one for funding. … Other than these responses, we do have a few pending applications, one from a company that we have had good results with in the past. …



Noted with thanks: 

Q1 2022 Software Development Projects Update | FreeBSD Foundation


----------

