Comment Re:BSD loses support from Open Source (Score 1) 149
I find the situation somewhat the opposite, and have some wedged updates on a Debian system right now to prove it. I guess your mileage differs.
Has it ever occurred to you that despite having done some things wrong the Linux world has developed some very solid technology and BSD might, just might, benefit from pulling it's head out of the sand adopting some of them.
What are you talking about? FreeBSD makes use of Linux-based technology all the damned time -- just as soon as it can port it (because for some reason Linux developers are increasingly hostile to software portability) or reimplement it (because the Linux community seems inextricably wedded to using licenses that create compatibility problems with other licenses, thus making it illegal for BSD Unix projects to use the original implementations). The fact not all technologies are deemed worthy for adoption does not mean that all Linux-based technologies are avoided just because they came from the Linux world, y'know.
You can't have rational conversations with people who think the word "bloat" belongs in a discussion where the difference is like a meg.
I'm not sure it's possible to have a rational conversation with someone who makes comments like that as though intentionally creating a rift between participants in discussion as a pre-condition for conversation.
Hell last I checked BSD's still come with vi and not vim out of the box.
Vim potentially creates licensing problems for BSD Unix base systems.
Is there any legitimate justification for the fact I have a more capable tar out of the box on a Linux system than BSD?
citation needed
Also . . . licensing.
The Linux world has it's problems and if you use the cutting edge stuff you will have some glitches here and there. But at least it is doing SOMETHING. Those glitches will be worked out. Some things will be discarded in time others will stabilize into solid technology.
. . . by which point it will have already been deprecated in the community at large by something else half-created that is buggy and problematic. Some Linux distributions will of course be resisting the sudden jump to a new, unfinished replacement for the last unfinished replacement, but they'll have problems because other things that they want to use will jump to dependence on the new, unfinished toy.
BSDland is doing a whole lot of nothing and calling it a feature
I guess we can ignore all the stuff being created in "BSDland", including stuff that keeps getting ported to "Linuxland" because the Linux developers were too busy building half of something and making it technically very difficult to port to BSD Unix systems.
most of the software running on BSD is developed in projects that are cross platform because it is easy to be but those projects exist and thrive because they run on Linux not because of BSD.
Say what? I suppose new capabilities of, say, pf "only exist and thrive because they run on Linux not because of BSD", even though pf isn't portable to Linux. Right? Then, of course, there's the BSD ACL framework on FreeBSD that is widely regarded as being as capable as SELinux and easier to use. I think you just don't know what the hell you're talking about.
BSD has some nice technology but the only reason it continues to exist and talented people waste effort developing that technology there instead of on Linux (where more people will benefit from it) is because some people who felt l33t running a hard to use Linux in the 90's hated Linux going mainstream and because nostalgic old UNIX admins still perpetrate the myth that it is more stable/secure/somehow betterer because much of it originates from the old UNIX(TM) code base.
. . . or maybe you're just an OS bigot, and what you're saying is complete claptrap.
Of course, thanks to SCO we all know that any of that code that was worth having migrated into Linux a long long time ago.
You're kidding -- right? If it was true, SCO would have won its case rather than descending into blood-smeared bankruptcy, its CEO living in infamy with his reputation worth a bucket of feces, its shareholders' stock portfolios decimated, and its name a ludicrous joke.
It's a shame. If there wasn't so much resentment and hate there could be more collaboration between two communities that really should be staunch allies.
I agree. Why are you so resentful and hateful?
I've just noticed that whenever someone asks if FreeBSD has a feature that is already in Linux or if someone asks how they can do action ABC on FreeBSD that they do on Linux, the result is typically a flame fest. People in the FreeBSD community often use their hatred of Linux to defend their own lack of progress.
I haven't really seen that on the mailing lists and in IRC. Maybe what you observe is a problem with the forum, specifically.
Which you comment, appropriately enough, demonstrates.
I think this statement of yours demonstrates that you're just looking for reasons to hate FreeBSD users.
- 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.
All seems condemned in the long run to approximate a state akin to Gaussian noise. -- James Martin
