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, ...).

__________________religions, worst damnation of mankind"If 386BSD had been available when I started on Linux, Linux would probably never had happened." Linus TorvaldsLinux is not UNIX! Face it! It is not an insult. It is fact: GNU is a recursive acronym for “GNU's Not UNIX”.vermaden's:linksresourcesdeviantartspreadbsd

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.

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.

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).

Quote:

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.)

__________________religions, worst damnation of mankind"If 386BSD had been available when I started on Linux, Linux would probably never had happened." Linus TorvaldsLinux is not UNIX! Face it! It is not an insult. It is fact: GNU is a recursive acronym for “GNU's Not UNIX”.vermaden's:linksresourcesdeviantartspreadbsd

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

__________________
UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things.

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

The same for praised APT.

Quote:

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).

Quote:

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.

__________________religions, worst damnation of mankind"If 386BSD had been available when I started on Linux, Linux would probably never had happened." Linus TorvaldsLinux is not UNIX! Face it! It is not an insult. It is fact: GNU is a recursive acronym for “GNU's Not UNIX”.vermaden's:linksresourcesdeviantartspreadbsd

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.

__________________religions, worst damnation of mankind"If 386BSD had been available when I started on Linux, Linux would probably never had happened." Linus TorvaldsLinux is not UNIX! Face it! It is not an insult. It is fact: GNU is a recursive acronym for “GNU's Not UNIX”.vermaden's:linksresourcesdeviantartspreadbsd

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.