what missing features do you think *BSD should provide ?

[daemonfowl]

Hi BSD users & lovers !

it's a simple question .. what missing features do you think your favorite *BSD OS should provide ?

for me ,
I hope OpenBSD will some day support HFS+ filesystem and .dmg image ...

How about you ?

[vermaden]

Its not about what I would like FreeBSD support to for most of the cases (faster support for new/fresh hardware will be nice through), its the will for others to officially and fully support FreeBSD, like game designers (World of Goo for example), or enterprise solutions that does not support FreeBSD (SAP, Oracle, DB2, Tivoli Storage Manager, HP DataProtector, Veritas, ...).

[daemonfowl]

Hi Vermaden !
thanks for sharing the idea !

[comet--berkeley]

I wish that OpenBSD supports boot up from an FFS2 file system and becomes Y2K38 ready.

I wish that FreeBSD and NetBSD take more security ideas from OpenBSD and become more secure.

[daemonfowl]

Thank you for sharing , @comet--berkeley !

[RalphEllis]

I would like to see universal ZFS support in all BSDs. It is an amazing file system that maximizes data integrity and the ease of backup and recovery.
All BSDs could use more centralized administration software for servers. The Oracle people correctly argue that the real cost of many servers is less the servers than the very expensive people needed to administer them. Better centralized software control means fewer system administrators.
Better graphics performance from the open source drivers would be a positive move given the rise of multimedia.
Everyone could use security software that automatically sends a large man with a baseball bat to the door of anyone who tries to hack your systems.

[daemonfowl]

Such interesting points ..
Thanks very much RalphEllis !

[thirdm]

Also in file systems, I'd like to see hammer (or hammer2 when it's finished) ported to all the other BSDs (and Linux, the Hurd, or anything else I might one day try).

I just started using DragonFly on my laptop, because I can't get OpenBSD to run on it (it freezes early in boot around the time it tries to recognize the second CPU -- both amd64 and i386 on 5.1 -- some kind of asus laptop with a Core Duo -- if anyone's interested I can post more precise info later, perhaps). Hammer seems like the most interesting feature, at least that I've noticed. I love the snapshotting feature. Next I'd probably want to try mirroring to a slave system if I had another computer running DragonFly. If all BSDs ran Hammer, perhaps I could mirror files between them.

I keep meaning to (without telling anyone, at least not using my real name, else someone might expect me to be up to the task or to finish it) play at getting Wine working on OpenBSD (or DragonFly amd64? someone's started getting it at least compiling on i386 already) too. So I don't want anyone else to do it first, but I would like it if OpenBSD devs decided running programs compiled for i386 should run on amd64 system after all. I think I would want that to do the Wine port (Win32 is interesting to me, not Win64 at this point). Not a huge deal though. I should just run an i386 install instead.

The last thing is, now that disks are getting pretty big, I'd like the various BSD pkg systems to dump all dist source code under /usr/local/src (or /usr/pkg/src) and to use CFLAGS+=-g and not strip debugging symbols on install. Along with that, I'd like it if the pkg/ports systems would have features that make it easy to maintain your own modifications under ../src and use your tree version in preference to the dist tarball when building a port from source if the versions match (if your changes were substantial enough to require a change in the PLIST, then I guess it would be up to you to change to your own custom port, but most changes I'd envision doing wouldn't make that necessary).

Finally, though I'd never write this where I think many devs are, I'd like OpenBSD to migrate to git. I have to use too many different source control systems. CVS is one of the ones I'd like to forget.

[daemonfowl]

Thank you very much @thirdm

[backrow]

Originally Posted by thirdm

The last thing is, now that disks are getting pretty big, I'd like the various BSD pkg systems to dump all dist source code under /usr/local/src (or /usr/pkg/src) and to use CFLAGS+=-g and not strip debugging symbols on install.

Indeed, if I had time, money, and an extra machine, I would set up an OpenBSD package mirror with those options (and also sign the packages).

Originally Posted by thirdm

Along with that, I'd like it if the pkg/ports systems would have features that make it easy to maintain your own modifications under ../src and use your tree version in preference to the dist tarball when building a port from source if the versions match (if your changes were substantial enough to require a change in the PLIST, then I guess it would be up to you to change to your own custom port, but most changes I'd envision doing wouldn't make that necessary).

Can what you want be done with bsd.port.mk(5)’s PORTSDIR_PATH? Of course, if you have substantial port improvements, you should send them to ports@ so others can benefit.

My wishlist:

• Better open source graphics driver performance, and kernel modesetting. Maybe radeon(4) support will improve if AMD is dropping support for old‐but‐still‐common cards in the proprietary driver (though the only source I can find for that is Phoronix, which I’m very reluctant to trust).
• Better multicore performance. Better performance under heavy disk load. Raw “performance” is of course not OpenBSD’s main priority (and it shouldn’t be), but it certainly helps to have it!
• I find HAMMER very interesting and would love to see it in OpenBSD.
• I would also like to see OpenBSD move to Git. (Jörg Sonnenberger has been doing a lot of work on getting NetBSD’s CVS repo to play nicely with Fossil; I expect that switch to happen sooner rather than later.)
• A UTF‐8 locale by default.
• softraid(4) setup, with encryption, in the installer.
• A phone I can run OpenBSD on. Though I may settle with Inferno on Android!
• Not specifically a BSD thing, but the world needs a fully open‐source FPGA toolchain.
• More packages. (This, at least, is something I try to fix!)

[daemonfowl]

Thank you @backrow , such an interesting wishlist !

A UTF‐8 locale by default.

Yesssss ! thanks for mentioning this

[araby]

- a decent package manager like APT & YUM

- support more hardware , like linux does .

[vermaden]

Originally Posted by araby

- a decent package manager like APT & YUM

Search for PKGNG, its already in BETA stage.

[araby]

Originally Posted by vermaden

Search for PKGNG, its already in BETA stage.

thank you , i will wait for the stable release .

[Carpetsmoker]

Decent graphics support.

Originally Posted by araby

- a decent package manager like APT & YUM

*hickup* *cough*

It's been years since I last used apt, so I'll refrain from commenting on that, although my impressions 5-6 years ago were not good.
YUM is *NOT* a "decent" package manager. A "complete piece of junk" would be a more accurate description by any standard.

Things that are wrong with yum (in no particular order):
1) Slow .. SLOW ... SLOW ...
2) Unable to launch 2 instances: For example an install and search. The way it locks stuff is stupid.
3) It moves my config files around when upgrading, for example it saves /etc/dovecot/dovecot.conf to /etc/dovecot/dovecot.conf.rpmsave -- Very annoying.
4) It's very opaque and difficult to see/understand what's going on (and thus, un-UNIX).
5) It's actually just a front-end for another tool (rpm), why not just fix rpm instead of adding an extra layer?
6) I've had instances where it just crashes, and whatever I did, I was unable to get a meaningful error message (See lack of transparency above).

As for FreeBSD's "pkg-ng":
It seems sort of OK. I dislike that it uses sqlite, you can't grep sqlite. It does promise a somewhat more reliable database (one common issue is running make deinstall while there is still a +REQUIRED_BY file, this information is then lost... Then again, this file isn't really reliable anyway due to GNU autotools which links against binaries even though it's told not to)... Ah well, at least it doesn't use XML

[vermaden]

Originally Posted by Carpetsmoker

2) Unable to launch 2 instances: For example an install and search. The way it locks stuff is stupid.

The same for praised APT.

Originally Posted by Carpetsmoker

5) It's actually just a front-end for another tool (rpm), why not just fix rpm instead of adding an extra layer?

Because that's how Linux works, do not fix, add another layer (udev + HAL or ALSA + PulseShit seems good examples).

Originally Posted by Carpetsmoker

6) I've had instances where it just crashes, and whatever I did, I was unable to get a meaningful error message (See lack of transparency above).

Another Linux 'thingy', useless or none error messages and lack of documentation to cope with failures.

[phoenix]

Originally Posted by Carpetsmoker

As for FreeBSD's "pkg-ng":
It seems sort of OK. I dislike that it uses sqlite, you can't grep sqlite. It does promise a somewhat more reliable database (one common issue is running make deinstall while there is still a +REQUIRED_BY file, this information is then lost... Then again, this file isn't really reliable anyway due to GNU autotools which links against binaries even though it's told not to)... Ah well, at least it doesn't use XML

It's gotten much better since beta10. I managed to corrupt the database with earlier betas, but haven't been able to since beta10.

And, now, there are semi-public repos available for both 32-bit and 64-bit 9.0-RELEASE.

It's now possible to have a fully-binary-only FreeBSD setup using freebsd-update for the core OS, and pkgng for the apps.

Was able to update from a FreeBSD 8.3 install to a 9.0 install without compiling anything last weekend. And from KDE 4.7 to 4.8 without any issues.

[vermaden]

Originally Posted by phoenix

It's now possible to have a fully-binary-only FreeBSD setup using freebsd-update for the core OS, and pkgng for the apps.

With little * ...

* You will still not have binary lame package for example and You still would not have BUG FIXES (not security fixes) in the RELEASE branch, buts its better (less PITA) then my way [2]

[2] http://forums.freebsd.org/showthread.php?t=26140

[phoenix]

True, yes, any port that has a license preventing binary packages from being stored/distributed by the FreeBSD Project will need to be installed from the ports tree. But, these are few and far between now. And a patched portmaster works well for dealing with those.

It's not perfect, but pkgng is a very large step in the right direction.

[bashrules]

Better gdb support (gdb comes with the base system, so I assume it's not off-topic). I miss:

- reverse execution mode - I think that's currently tied to i386-linux http://sourceware.org/gdb/news/reversible.html

- following forks() - that's currently tied to linux and hpux http://sourceware.org/gdb/onlinedocs/gdb/Forks.html