- a *lot* of times a software gets a new version and the ports skip it. So you install mediawiki 1.18.1 and then update to 1.18.4. (just an example).
That's not the fault of the ports system. That's the fault of the maintainer of that specific port.
- patch backport: I really hate backporting of patches. so sometimes you have version 1.1 of a software and then you get version 1.1_1 which is actually almost 1.2. never liked it, I prefer the vanilla software.
That's kind of a strange gripe. Are you really complaining about how version numbers are represented?
- there *are* software conflicts. Try to install a couple of things that requires icu and keep them up to date. most likely you will not be able to update une of the packages 'cause it doesn't work with the old/new version of icu. Avahi still requires icu 3.8, guess what, it's not in the ports anymore.
It was stated that software conflicts are rare -- not that they never happen. They happen for every software management system, including those used by popular Linux distributions and what we might, with a laugh, call a software management system on MS Windows. Such is life.
It took over forty seconds(!!) on an otherwise idle system (Ivy Bridge i5 w/ SSD) to list all the installed ports and their versions (pkg_version).
Regarding your only specific problem mention . .
Do people still use pkg_version? Are you aware portversion is faster, and has been for a long time -- and pkg_* tools are reaching EOL?
Anytime Linux comes up on the FreeBSD forums it turns into a huge flame fest.
Maybe that wouldn't happen if you didn't keep trolling there with hostile claims about how awful FreeBSD is, and how unpleasant its users are.
After entering protected mode and going to _main with the far jump simply return EOL; or something similar. That's all there is for a new BSD release. Nothing else.
alternative interpretation:
Woohoo! FreeBSD 9.1-RELEASE comes with support for new Intel HD graphics. Hot damn. I finally get to get rid of the non-deterministic, obese, constantly agonizing experience of dicking around with half-baked bullshit in the Linux world on this laptop.
I mean, really . . . who wouldn't want to get out from under the horrid experiences Lennart Poettering, the GNU Project, and Canonical have foisted onto the Linux world in recent years?
If the driver needs to be integrated into a monolithic whole with the code that makes it compatible with something distributed under the GPL (such as the Linux kernel), there's some danger of being liable for license violation if someone wants to make a stink about it -- and it's not just the GPL that may be the problem, remember: Oracle is the owner of the ZFS copyrights, and the ZFS is distributed under the terms of a copyleft license.
How you go about getting the pieces of software to play well with each other determines the potential for being sued or otherwise having issues related to license incompatibility. The current thinking on the matter in the Linux world seems to be "Well . . . I doubt anyone will sue us for making the ZFS driver into a module. I guess we're safe. Hope so, anyway."
Some of the push to relax and just use stuff together had something to do with embarrassment over licensing conflicts with the GPL, I think -- more so than because of actual honest analysis of the GPL resulting in a feeling that it's safe to use ZFS as a distinct module.
ZFS has me locked in now. I wish the linux guys had gone for it instead of relying on btrfs.
Do you mean you wish Linux used a more broadly compatible license than the GPL so it wouldn't have had problems figuring out how to directly support ZFS without violating either license?
After Goliath's defeat, giants ceased to command respect. - Freeman Dyson