What would you like to see in FreeBSD

Maybe we should kidnap François Tigeot, lock him up and only let him out when we we've caught up with DragonFly.
Or maybe get him to step over the fence by bribing him with a lifetime supply of beer. :D

On a more serious note I'd really love to see better power management and suspend/resume support with both desktop/workstations and laptops.
 
The native BSD C compiler is PCC. GCC replaced PCC due to political reasons. That is one of the biggest blunders in BSD history.
LLVM doesn't work on legacy architectures which matter to OpenBSD and NetBSD and its driven by Apple needs. There is nothing that gets bugs faster out of the system than natively compiling code on Vax, or similar slow architectures. Unfortunately FreeBSD was always about i386 and alike.
Since I do follow the PCC project, I think that switching from LLVM to PCC would be, now and in the short future, a big mistake. Sure, it still builds and runs on a pdp11, but that comes at a price. The code quality is not in the same levels as LLVM (heck, not even on the same continent), diagnostics are not nearly as good, there is no fortran support and trying to compile anything but C will simply not work. It is still a nice little compiler, sure, and it is fast - but I would not easily trust my mission critical code with it.

But getting bugs out of software is indeed much faster on more than one compiler and more than one architecture. And may I add that more than one endianes is a must here?
 
The code quality is not in the same levels as LLVM (heck, not even on the same continent), diagnostics are not nearly as good, there is no fortran support and trying to compile anything but C will simply not work. It is still a nice little compiler, sure, and it is fast - but I would not easily trust my mission critical code with it.
PCC is not usable and at this point it is far to say that the whole project is dead. All your point but one are valid. How in the world do you get the idea that the system compiler should support FORTRAN or any other language for that mater except C? PCC is a serial C only system compiler. No more no less. UNIX operating systems are written in C or they are not UNIX-es. End of story.

Between my first programming language was FORTRAN and I still list FORTRAN in my CV.
 
I don't find FreeBSD that hard to use as a desktop, and can set it up fairly quickly. I'd like for binary upgrades to be more reliable. (Though they get better all the time). I'd like better hardware support and for things like say, synaptic touchpads to work out of the box.

I'd like documentation to be more up to date at times, though now that I think of it, I can't remember anything I've had to look up in the last several months that was really out of date.

Though I would like it a bit smoother on the desktop, I wouldn't want it to go the way of some versions of Linux, where the good things about the desktop start taking precedence over using it as a server. Simple example, RedHat deciding to put no more effort into their curses based installation, so that if one is having video difficulties, or just doesn't have a mouse handy, they have to accept all defaults or else write a kickstart file.

TL;DR, Being able to, with few exceptions, not need to compile, but always be able to use binaries, (but, as this is just a wishlist, still having the ability to fairly easily work with ports or source code for the system itself.)

I'm not sure that flash is dying--isn't Hulu going to keep with it? (And Hulu is supposedly considering offering ad free next year)
 
  • Thanks
Reactions: Oko
You can blame GNU/Red Hat for that.

Sure, they did develop a rather awfull sound system, but the real problem as I see it is application support (and the lack of alternatives). Last time I tried to install Firefox it required PulseAudio, so did Skype (though I don't exactly expect a program that uses the linuxulator to work the same as a native program). The lack of alternatives is the problem here.

8. I like the fact that developers are talking about better NTP daemon. Please do it. I would like to see an alternative to OpenNTPD (or NTP bloat-ware) This actually could be much higher on my list.

As I understand it, the developers are pondering whether to go with OpenNTPD or PHK's NTimed. PC-BSD is going to replace NTPD with OpenNTPD for their next release.

9. mandoc should be the only document formatting system allowed and mdoc should be only format allowed.

This is ongoing. There were still some issues regarding some parts of the GNU documentation tools that needed to be implemented. I hope the work is completed for 11.0.

17. Create native BSD tool chain.

The developers replaced most of the GNU Binutils with their elftoolchain equivalents (those that are ready to be replaced anyway).

https://wiki.freebsd.org/GPLinBase

18. Port the video drivers from DragonFly BSD so that people can actually use FreeBSD as a desktop OS.

There is supposedly some work going on regarding this (and set to be completed in august IIRC), although it should probably be funded, it's becoming a major usability issue, and we're already lagging behind every other BSD.

21. Port Truecrypt DragonFly implementation to FreeBSD.

I think GELI already does something similar.

IPF nearly went away, but was saved at the last moment because it is apparently very similar to what some commercial equipment uses (Juniper?).

I knew it was something like that. I couldn't find the conversation on the mailing lists, though. Did they state their reasons for prefering IPF? Maybe it really is better in some aspects.
 
  • Thanks
Reactions: Oko
The developers replaced most of the GNU Binutils with their elftoolchain equivalents (those that are ready to be replaced anyway).

https://wiki.freebsd.org/GPLinBase
That is the best news coming out of FreeBSD camp in the very long. Kudos to FreeBSD developers. Replacing GNU binutils with high quality BSD licensed software is the most development for the long term success BSDs


Just few comments about your other points. I am obviously aware of GELI and I use GELI. However in the real world in many cases sensitive information is shipped encrypted with TrueCrypt. While it looked like TrueCrypt might be dead which will inevitably change this trend I have fired up DragonFly work station numerous times just to have the data decrypted and imported into our servers. All other comments seems like a great news except the first one.

We (all BSDs) should just drop that Linux crap all together and forget about things which nobody uses anyway. If I want to Skype people I will take my Android device and not bother with Linux emulation. I am sure Firefox can be compiled without PulseAudio as otherwise I would not be able to listen to the music right now from my natively compiled Firefox on my OpenBSD workstation.
 
PCC is not usable and at this point it is far to say that the whole project is dead. All your point but one are valid. How in the world do you get the idea that the system compiler should support FORTRAN or any other language for that mater except C? PCC is a serial C only system compiler. No more no less. UNIX operating systems are written in C or they are not UNIX-es. End of story.

Between my first programming language was FORTRAN and I still list FORTRAN in my CV.
Oh, that is simple. When you extract PCC, you find the code for the FORTRAN front-end, but it is not building (and surely not working). I had started a small discussion about that on the pcc mailing list about that.

But there are some brave souls (at least one) out there which try to build the NetBSD core with pcc, so it may be back some day.
 
Sure, they did develop a rather awfull sound system, but the real problem as I see it is application support (and the lack of alternatives). Last time I tried to install Firefox it required PulseAudio, so did Skype (though I don't exactly expect a program that uses the linuxulator to work the same as a native program). The lack of alternatives is the problem here.

Well, it was GNU who kick started the open source desktop world, which ended up breeding and captivating other desktop related projects. While the FreeBSD focused on making the best open implementation of BSD UNIX there is. So it's merely historical, GNU did it first. FreeBSD has a lot of catching up do to (and incentives to give) if you want FreeBSD centric alternatives.

Or

Get a Mac, and live stress free. :)
 
To say something on the topic of this thread - I would like to see working suspend-to-disc provided from the kernel layer. Maybe even the possibility to generate named snapshots of the system at any point, but with the ability to start them again later if need be. It should be sufficient to snapshot the user processes, so no complete snapshot including the file systems and all that. I would really like this...
 
To say something on the topic of this thread - I would like to see working suspend-to-disc provided from the kernel layer. Maybe even the possibility to generate named snapshots of the system at any point, but with the ability to start them again later if need be. It should be sufficient to snapshot the user processes, so no complete snapshot including the file systems and all that. I would really like this...
+1 to the suspend to disk statement. I'm not sure I'm understanding the second part of your post though it sounds to me like what most mainstream mobile operating systems like Android and iOS do to some extent. If that's what you're referring to I could certainly see that being a useful feature.
 
Well, it was GNU who kick started the open source desktop world
No it didn't! Open source pre-dates GNU free software movement over 10 years. Open source movement was born in early 70s when RMS was in still in the middle school.
 
+1 to the suspend to disk statement. I'm not sure I'm understanding the second part of your post though it sounds to me like what most mainstream mobile operating systems like Android and iOS do to some extent. If that's what you're referring to I could certainly see that being a useful feature.
"Traditional" suspend-to-disc saves the memory image of the machine and restarts that one. Is there really any need to store the kernel space at all? What if you only store the user land processes and their states and resume those when the kernel has been restarted? You would not get problems with the disc cache as you get with other systems when you access the disc while they sleep. You would get the benefit of something like sessions for everything from init to end. Your laptop could resume by default into a X11 session running solitare and a fluffy xteddy for the customs agent to look at while it could also resume to the snapshot where you just left off in the plane writing some TeX code which would hopelessly confuse that guy and make you miss your next plane. Something like that. On a server you might also take a snapshot of a running system which "behaves fishy", reboot the applications (maybe here make a snapshot of the file system to have the data bases in sync) and come back later to check what it was. No guarantee that this would work, but it would be better than nothing. And if you really power the thing off and do not change the disc contents you should be fine.
 
Ok, I think I understand what you are saying. You are saying it would be great if you could suspend a snapshot of the entire userland process tree independent of the kernel. I have no idea if that's possible but that would indeed be really cool. Unfortunately these sort of ideas are a bit above my level of understanding at this point yet. :)

Oh, also lol @ "fluffy xteddy".
 
FreeBSD has a lot of catching up do to.

Nearly all BSD's do. FreeBSD still doesn't support Wayland (well, it's been ported but it hasn't been tested yet), neither does [Open/Net/Dragonfly/Bitrig]. In fact, I want to add that to my wishlist.

Or

Get a Mac, and live stress free. :)

I would, but sadly I don't have that much money at the moment (and Macs are really expensive :( ).

Just few comments about your other points. I am obviously aware of GELI and I use GELI. However in the real world in many cases sensitive information is shipped encrypted with TrueCrypt. While it looked like TrueCrypt might be dead which will inevitably change this trend I have fired up DragonFly work station numerous times just to have the data decrypted and imported into our servers.


Bringing it as a port sounds feasible, I don't reckon it's an urgent thing for most users though.

We (all BSDs) should just drop that Linux crap all together and forget about things which nobody uses anyway. If I want to Skype people I will take my Android device and not bother with Linux emulation.

I agree with the first part. However Skype-Like software is IMHO, very useful. I used Skype a lot to talk to the group of people I was working with during college projects.
In the case of Skype, I believe a replacement might be better than trying to support propietary Microsoft software, but there is still need for one.

I am sure Firefox can be compiled without PulseAudio as otherwise I would not be able to listen to the music right now from my natively compiled Firefox on my OpenBSD workstation.

I might be mistaken on that one, but last I checked pulseaudio was the default on FreeBSD (and required for HTML5 audio/video). Maybe we should all switch to Xombrero (wich IIRC was made by OpenBSD people).
 
I might be mistaken on that one, but last I checked pulseaudio was the default on FreeBSD (and required for HTML5 audio/video). Maybe we should all switch to Xombrero (wich IIRC was made by OpenBSD people).
I am not using Xombrero due to my strong disliking for WebKit rendering engine. Between Marco Peereboom who started Xombrero lost his CVS commit privileges from OpenBSD over 2 years ago due to disagreement with Theo. Xombrero is not affiliated in any shape or form with OpenBSD project and has not being affiliated even when Marco was developer. His tiling window manager spectrwm formerly known as scrotwm manager has been removed from the base at the time of Marco's departure as a developer. However his code still lives in OpenBSD in particularly anything storage related (Hardware RAID drivers, controllers and similar).
 
I think oss is the default on FreeBSD, isn't it? I know I don't put any work into getting sound going and usually control it with the mixer.

As for xombrero, I tried it for awhile but it seemed relatively slow. I didn't try very hard, just installed it, used it a bit, even made a dwm shortcut for it, but wasn't all that impressed.
He's the one who wrote spectrwm. I always figured the name got changed when the author turned 15 or so. :) Seriously, I like that window manager, and even have a page about it.

http://srobb.net/spectrwm.html

Anyway, I just chimed in to say that I think oss is the default. :)
 
The problem with www/firefox is that it either wants pulseaudio or ALSA - both are not OSS and are some Linux-isms creeping upstream.
We need to be careful not to add to this thread what we want to see in ports but in the OS itself (almost wrote kernel here).
 
I've occasionally wanted to use shutdown -r and/or reboot from within a Jail to do what jail -rc does on the host. This might allow Jail owners to intuitively put patches to their Jails in to effect (or test rc.conf changes), without requiring intervention from the host system's owner.

Yet I guess this could lead to a Jail userland newer than the kernel, so some amount of coordination with the host system's owner would probably be required anyways.
 
I would love to see FreeBSD catching up with current hardware. :(
I have no idea what are you talking about. Check out the dmesg of my new file server. It doesn't get any newer than that.
Code:
[root@uranus] ~# zpool list
NAME  SIZE  ALLOC  FREE  FRAG  EXPANDSZ  CAP  DEDUP  HEALTH  ALTROOT
archive  21.8T  1.27M  21.7T  0%  -  0%  1.00x  ONLINE  -
backups  36.2T  13.5T  22.7T  23%  -  37%  1.00x  ONLINE  -
data0  36.2T  1.23M  36.2T  0%  -  0%  1.00x  ONLINE  -
data1  36.2T  1.27M  36.2T  0%  -  0%  1.00x  ONLINE  -
tank  109G  1.70G  107G  0%  -  1%  1.00x  ONLINE  -
That is 133 TB in total :cool: These babies don't come cheap. This one was 21K and change U.S. dollars.
 

Attachments

  • dmesg.txt
    33.3 KB · Views: 277
Back
Top