What would you like to see in FreeBSD

Juniper networks have vetoed. So the secret is out. JunoOS is actually using IPF.

I know something like that happened (and I knew Juniper *was* using IPF), but I had the impression that it happened long ago (I couldn't find any recent discussion on the subject). Anyway, IPFilter in base is quite old, doesn't support many of the new fetures, the newest versions are GPLed (I think the version in base is the last non-GPLed release) and the latest release happened 3 years ago.... I can't see what bennefit Juniper can have in keeping it vs migrating to something else. And if we really want to have 3 firewalls in base Instead of IPF we can have IPFW-JIT (one of the GSOC projects this year) or port NetBSD's NPF.

I just tried recently when 7.0 was released. I am not impressed at all neither with the installer nor with NetBSD. Just as a side note it would take so much work to adopt that installer to installations to ZFS pools that practically mean writing things from scratch.

That was just a joke, I doubt anyone will want to go through the trouble of rewriting the installer. I just like how it looks like Windows' Blue Screen Of Death.
 
Last edited by a moderator:
I would like a tool like Cobbler or Solaris AI to automate distributed installs of FreeBSD. Scripting bsdinstall(8) is fine a couple of machines but for spinning up a fleet of custom Jails or nodes it can be a pain.
 
A system-wide fix for the backspace/delete keymapping problem. This would be especially handy for those not using punched tape. :)
 
I'd like to see a marketing shift. Transition away from the use of a 'project' concept, to a 'heavy duty mission critical OS'. Show the enterprise and industrial worlds that FreeBSD can run factories, power plants, NASA, railroads, etc. If some work needs to be done to make FreeBSD better to tackle certain applications then so be it. Its time for FreeBSD to be the OS of choice for heavy duty work.
 
I am using FreeBSD for fun and exploration/learning. Currently running it on a cheap laptop from eBay which has it's own issues, but that's what I'm left with. To that end, further desktop/hardware support would be appreciated.
I'm looking at replacing a couple of non-critical virtual home servers currently running Linux, again for fun, exploration, and learning.
I am currently not looking to run FreeBSD on high-end hardware in an enterprise/corporate environment, but I certainly hope that what I learn at home could be used to help me into working with FreeBSD in the future.

I think to that end, my wish is for a place to ask somewhat stupid questions (people will have varying definitions of a stupid question) and get answers that are friendly and approachable while being somewhat informative - rather than getting abrupt/blunt complaints about the quality of the question. I think such a place helps to get people through the door and can act as a place to condition new users to ask questions better and perhaps to ask less trivial questions in less "newbie"/more technical channels.
The "Resources for newbies" page lists the freebsd-questions mailing list as well as a couple of newsgroups, but there is no mention of the forum - which I'd have thought would be the most newbie friendly interface?

I think FreeBSD has made a some headway with this, the guys running freebsdhelp on Twitter really do a grand job at promoting and helping, but Twitter is rather limited for support/Q&A.
 
OpenStack support. We have the tools (bhyve, Jails, ZFS, VIMAGE, glusterfs (kind-of)), we just need someone who cares. If I could write python fluently I'd be all over this and promoting it.
 
Last edited by a moderator:
What about shells/pdksh in the base system? It has built in arithmetic, and sh (Bourne shell, not Bourne Again shell) scripts are upward compatible with it. If not, I'd like to see pdksh (Public Domain Korn Shell) being used more in BSD as an alternative to other custom shells.
 
I would personally be interested in improved ATI/AMD Radeon support. I'm enjoying my nVidia GT 610 with the proprietary drivers a lot, but I believe Radeons also deserve some proper open-source lovin'. I know AMD contributes greatly to the open-source radeon driver, however it's nowhere near its Windows counterpart. Maybe an adventure in the form of splitting the mainline driver for Windows and *nixes?
 
Kernel stuff that is essential for using FreeBSD as desktop or laptop OS:
1. Suspend/hibernate, *not* depending on BIOS doing the work.
2. Bluetooth stack.

Sadly, both things have been broken and abandoned for years.

Actually, I was going to do a rewrite of the power management code. I even have a workable layout, but the device drivers needed some work to make it happen. I posted my project idea on here about summer 2012 and I couldn't really get any takers from the developers.

The idea was to use a kernel thread that ran once a minute. It would look at the interrupt deltas to see if any had changed. It would use the same information that vmstat -i uses. The interrupts that it would look at was for the video/keyboard/mouse (console stuff), harddisks, serial ports, and networking. After a preset amount of time, it would shutdown the video, spin down the HDs, etc.... I am not sure about putting the system into suspend and sleep modes, but that's part of the system hardware. I know Microsoft has generic drivers to do this via the ACPI specification. But my method would use software timers in the kernel and not bother with the hardware timers for maximum compatibility. Things like closing the lid of a laptop could put the system into a suspend state.

The driver support that I needed was a couple of function calls to put the attached device to sleep and to wake it up. But for the hard disk drivers, I need a function to spin the drive up/down. But, as I said, I couldn't really get any help to do it. I have the kernel thread part of it worked out though.

If anyone is interested, I would get back on it, but I would have to review the ACPI specs again and my original code design to get that back into my head as it's been 3-4 years since I last looked at it.
 
  • Jail live migration: I'd like the ability to move a Jail with running processes from one FreeBSD host to another, while handling the storage using either shared storage, or by actually moving it along with the processes using ZFS replication.
  • Jailed NFS service: I'd like to be able to make NFS exports from within a Jail, without having to use any tricky configuration settings (so long as NFS service is running in Jails only, and not also on the host).
 
  • Jail live migration: I'd like the ability to move a Jail with running processes from one FreeBSD host to another, while handling the storage using either shared storage, or by actually moving it along with the processes using ZFS replication.
  • Jailed NFS service: I'd like to be able to make NFS exports from within a Jail, without having to use any tricky configuration settings (so long as NFS service is running in Jails only, and not also on the host).

First one is no different from generic process migration, once that is solved we have jail migration. Second one is hard to implement because NFS is very old design and makes some big assumptions such as use of Sun RPC and full control of the host system.
 
Thanks so much for replying, kpa.

First one is no different from generic process migration, once that is solved we have jail migration.

Thanks; this concept's interesting.

Second one is hard to implement because NFS is very old design and makes some big assumptions such as use of Sun RPC and full control of the host system.

Yeah, it'd be nice if there were a good alternative to Samba in Jails.
 
Looks like I can (sort of) cross one item off my list:

beastDemian said:
2) Get i915 driver up to speed with Linux.

https://svnweb.freebsd.org/base?view=revision&revision=296548
This is initial support for Haswell graphics. It still has some issues, but it works.

Or two....

beastDemian said:
7) Bring in LLDB as the default debugger.

For AMD64 (which is what I use) it's already the default.

And there is progress in making LLD the default linker, so the amount GPL'd software in base is being reduced.
 
Back
Top