Hacker News new | past | comments | ask | show | jobs | submit login
FreeBSD Myths (freebsd.org)
152 points by type0 on July 30, 2016 | hide | past | web | favorite | 78 comments



> FreeBSD Has a Closed Development Model

Given that it took me 3 month to have Jack Vogel (then maintainer of the driver) acknowledge there was an uninitialized variable bug in the e1000(4) driver, leading to countless user frustration, despite detailed technical analysis and patch. Let me openly challenge this assertion... The issue ended up being fixed (or actually, buried in a huge patch) without attribution [ed. of course!].

My kind regards, but from experience, Linux folks is more open than BSD folks. YMMV.

> The BSD License Means Companies Don't Contribute Back They don't !

I've worked for 5 years in a [small] company using FreeBSD as the main development platform, heavily hacking the TCP and network stack. We leached plenty, and didn't contribute a single line back !


Let's just say that the Intel drivers have a pretty checkered history and your experience was not unique. There are new people at Intel working on their drivers, and they are more responsive. Also, iflib is coming, and it will move a lot of the stack-facing driver code from the Intel (and other) drivers to a common location. It is much higher performance and far less buggy than the vendor code it replaces.

The beauty of the BSD license is that you don't have to contribute back if you don't want to. Some companies contribute at lot. For example, the Netflix contribution of async sendfile, CAM support for NVME, etc.


My experience is not limited to the e1000(4) driver. The device tree driver subsystem is based on hardware model from the early 90s, the mbuf API is plagued with code duplication. Nobody want to touch this because the old guard is pretty much locking these interface. Everybody praise the Lord PHK, but his actual code in the tree is really sub-standard... The way to change things is to do what Adrian Chadd has been doing, sneaking in, and changing stuff behind's people back.

The way to contribute to BSD is easy, you have to be big to have enough influence (including monetary wise) to get stuff in. When you are a small nobody, you end up being treated as such.

Comparatively, I've had Linus look up at some issue I used to have with Linux USB stack (which were likely local interconnect issue). A world of difference.

edit: while I think about it, most large changes in FreeBSD are discussed in private. Public discussion on patch and technical discussion is frowned upon. At the end of the day, the dev submit at 10kloc patch that is unrewiewable, and it gets in with rather poor amount of discussion. The only public discussion held is pretty much bikeshedding. There is way more interesting technical conversation happening in a day on the LKML than will happen in a year on FreeBSD ml.


The problem with mbufs is that they have been around and been extended since the 80s. And Rototilling the interface will break a LOT of hardware. One of the nice things about iflib is that abstracts mbufs away from drivers. Of course that doesn't help much with crusty old drivers, but it does help some.

Having worked on both systems, there are some things I like better about mbufs as compared to skbs. But BSD badly needs the skb frags (eg, attached pages) concept to avoid excessive pointer chasing. We've been using an internal (not shared) patch that puts attached pages into an iovec, but it needs a lot of cleanup before upstreaming.

Oddly, I've had just the opposite experience as you. I've always found contributing to FreeBSD much easier. I was the author of network drivers for an IHV (not Intel) at a previous job. FreeBSD was a million times easier to deal with than Linux. I had a commit bit, and just developed my driver in head. Whereas with Linux, submitting even minor patches was a major ordeal thanks to davem and the netdev cabal. The Linux driver was often lacking features as compared to FreeBSD just because getting patches in was so time consuming.

There is actually quite a bit of public discussion of patches in Phabricator these days.


then maybe hardware vendors should contribute their code so that API could be changed all along, instead of keeping it paywalled. Though, I doubt they want people to look at how poor quality they are.

And yes, my job was also to "integrate" custom drivers for our appliances bells and whistles (eg. fail-to-wire interfaces, hardware sensors, etc.), in our source tree.


> edit: while I think about it, most large changes in FreeBSD are discussed in private. Public discussion on patch and technical discussion is frowned upon.

Ugh. That sounds pretty bad for an open source OS.


> I've worked for 5 years in a [small] company using FreeBSD as the main development platform, heavily hacking the TCP and network stack. We leached plenty, and didn't contribute a single line back !

I wanna challenge that with my own experience. Some companies give back, others don't. I don't think it's based on license, but on company culture.

If you look at GPL and similar, what you find is that people:

- Modify for their own internal stuff, so they don't give anything back (happens with every tool)

- Modify and even publish binaries, not contributing back, acting against the license

- Modify it and release it in a way to comply with the license, but basically rendering it unusable and where it would be easier to just start from scratch

- Modify it and sometimes even release it in an obfuscated manner, sometimes with comments stripped, etc.

Now, doesn't prove you wrong. However the sentence starts with "The BSD License Means", which simply hasn't proven as true. Other examples of BSD license are: clang, Ruby, nginx, Go, node.js, OpenSSH, ...

Also this would largely apply to other licenses, such as MIT, zlib, etc. as well.

The main reason for releasing or not releasing is what the company thinks about it. Maybe they believe competition steals it, maybe they think it will lower maintenance needed for the patchset, maybe they care about broad support for their stuff, maybe they care for people finding and fixing bugs, maybe they wanna show off, etc.

Look at FreeBSD Release Notes and Commits. It's filled with companies working on it.

There is no doubt that many people don't contribute back, but from my limited personal experience the main factor is the company and I don't know a single case where it was the license deciding that.

You could also have your personal Linux patchset. If you just use it on your servers there is NOTHING forcing you to to contribute a single line back.


> Given that it took me 3 month to have Jack Vogel (then maintainer of the driver) acknowledge there was an uninitialized variable bug in the e1000(4) driver, leading to countless user frustration, despite detailed technical analysis and patch. Let me openly challenge this assertion... The issue ended up being fixed (or actually, buried in a huge patch) without attribution [ed. of course!].

Without seeing the actual conversations, I'm willing to give the guy the benefit of the doubt on this.

3 months isn't too bad of a turn around time, and I'm sure the guys maintaining FreeBSD are busy, so maybe not able to reply to everybody about every little thing.

Did you bring up the attribution on the mailing list or anything? Was it just a mistake? Was it a trivial change that could have been made as part of something else?

> I've worked for 5 years in a [small] company using FreeBSD as the main development platform, heavily hacking the TCP and network stack. We leached plenty, and didn't contribute a single line back !

Is that really something to brag about? But whatever, you get to use it that way if you want to. Still doesn't change the fact that a lot of companies do contribute back.


Your company can do that with Linux, too, if they don't deploy it outside of the organization. There's nothing prohibiting any one entity from making a million changes to any of the gnuutils or the kernel if they don't release them.


Indeed. There are also many phone/IoT/embedded device vendors that ship devices with the Linux kernel without ever fulfilling the obligations of the GPL.


If you haven't read the book "Design and implementation of the FreeBSD operating system" (https://www.amazon.com/Design-Implementation-FreeBSD-Operati...) you should. It's possibly the best "applied" OS book. It also contains some interesting code samples in the book which is surprisingly uncommon in comparable books.

FreeBSD has for years had some features that are only now reaching 'mainstream' popularity (e.g. jails, which containers are based on). This books explains all that in quite a bit of detail and manages to stay high level enough not to get boring with the details but gives you enough detail to have a pretty detailed understanding.

It's also one of the few books that talks about networking in very practical terms (and not like OSI layers and whatnot) which makes me say that it's also possibly one of the best books on networking (you learn quite a bit about networks from how OS's work with them).

It also has the hands down best file system around (the book also talks about that).

And unlike large parts of linux, the kernel source is actually pretty legible.


> FreeBSD has for years had some features that are only now reaching 'mainstream' popularity

It's also lacking a bunch of features that reached "mainstream popularity" a long time ago.

Example: ASLR, the most important exploit mitigation technique

  - 2001 - PaX Linux
  - 2003 - OpenBSD
  - 2005 - Upstream Linux
  - 2007 - Windows
  - 2007 - OS X
  - 2011 - iOS
  - 2016 - NetBSD
FreeBSD is still lacking ASLR support despite a number of attempts and an actively maintained fork.

Linux even has Kernel ASLR (even though its effectiveness is debatable and it's much better with the Grsecurity patchset).

I'm a FreeBSD user and run it on a number of firewalls, but FreeBSDs approach at security worries me and I consider porting everything to OpenBSD or Linux.

It did not even have signed packages until recently!


As a lifelong Windows user, I've always been surprised about the obsession Unix users seem to have with filesystems.

I mean, as an end user (developer, but I assume that doesn't matter), what I expect from a filesystem is:

    * let me save a file in a directory
    * let me open it again
I also appreciate how many tools can use stats (eg filemtime) for good effect, and how fine grained permissions help keep my computer secure. All filesystems I've ever used let me do these things, and have for a long time.

This probably makes me a Blub programmer in file system terms. What am I missing? Why should I be dissatisfied with NTFS? I mean, in all honesty I don't even know which filesystems my various hard drives and sd cards have - I just save and open files.


Windows handles a lot of abstractions, to hide users from the nitty gritty details (OS X does the same thing). One of those things is hiding as much of the file system as possible.

Unix usually has users engaged at a lower level, adding a startup daemon means moving a file to a certain place. That shows that filesystems are much more the direct interface for the operating system.

Also, it is possible to have a Unix operating system, but have a completely different filesystem underneath. This is just not possible for Windows users. So there is no choice, so it is nothing Windows users think about in general.


>> let me open it again This is the tricky part, you should about worry as a user

Will it open exactly the same ? How likely is data corruption ? Will it work if I mount it on another OS or another version ? Is versioning supported ? Can it save all the modifications to a file and can I roll back to previous version if I want to ?. Can I take periodic backups without copying/transferring entire drive or entire files even ? Will using "a" file system improve/change my disk life time ?


NTFS is a quite decent filesystem – even more so when it was introduced – and there is a lot to be said for having a one standard.

But would you really want to work with FAT or even exFAT as your main OS? It's about 20% slower and doesn't support ACLs or journaling, so you can lose data in a crash.

So filesystems matter and Linux still doesn't have a standard choice that's as good as other OSes had 5 years ago.


The extra features and differences in the ways the filesystems work make workflows practical which, while they might be theoretically possible on older one work, are too inefficient, or need task-specific userspace tooling to achieve.

Sparse files are one example. They weren't in the original NTFS, although I'm not sure when they were introduced. If your workflow involves lots of files that happen to be mostly zeroes (which is surprisingly common), then you can save a lot of space and time by simply not writing those zeroes to disk. You could achieve the same result by compressing the files, but then everything you might want to use to manipulate those files has to be aware of that compression, and you've got added CPU overhead you might not want.

Copy-on-write snapshots are another. If you've taken a point-in-time backup and want to update it, you can take a snapshot and just copy the changed files across. That's not the clever bit, you can obviously do that with things like rsync. The clever bit is that you can make both the snapshot and the new version fully working file trees, which any of your other tools will work transparently with, and still take advantage of the space saving of the shared, unchanged parts. Again, you could mimic this by either fully copying the file tree first (in which case no space saving, and extra time to duplicate the files) or with hardlinks (which rsync does, but especially on Windows not all tools work well with).

I think one of the reasons Unix users seem to be more interested in filesystems than Windows users is that it's far, far harder to develop a new filesystem (or new filesystem features) on Windows than elsewhere. The Linux kernel interface was specifically designed to make it easy to plug new filesystem implementations in, so people have. On Windows, you're pretty much reliant on MS doing it for you, so you might not even notice when significant new NTFS features go in which would be headline news in other ecosystems. NTFS doesn't have to compete, and its users are in a sense locked in.


It's about how the FS does this stuff.

Take for instance the old FAT filesystem from MS-DOS. If you use it on an SD/SSD (or even a USB key, that's more or less the same tech), you're likely to burn it fast, unless the device does "wear-leveling" internally. Journaling filesystems like Ext4 avoid that by make it so that they don't overwrite again and again the same sector even if the system overwrites the same file again and again.

Another aspect is resilience to system crashes or power outages. A sudden power outage can leave data half-written, including the file allocation table, which may result in severe data corruption. This is especially important for embedded devices, but not only. Some file systems are designed with that possibility in mind.

Then there are performance considerations. FAT had to group sectors into clusters because of the limited number of FAT entries, so a little 1Kb file would actually use something like 8Kb on the disk (Windows still display both sizes BTW). There's also caching policies. If you want something "crash-proof", you don't want any write cache. But if you want something fast, you want a big cache. some filesystems pick resilience, others pick performance, others let you set the parameters you want.


I think you have confused journaled with log structured filesystems.


Yes I had.


Are you talking about high-performance high-reliability server applications, or more about end-user front-end applications?

There's a bit of a difference when it comes to running servers with thousands of users where you want to squeeze every drop of performance out of your hardware and without ever losing data, as to developing an end-user POS interface or other GUI applications. FreeBSD might be picked more often for back-end applications and Windows more for user-facing applications. It's the difference between keeping one user happy versus keeping many as happy as possible.

It probably doesn't matter much what kind of car you drive in the city centre – the requirements and limits are very different than on a race track where every little detail matters in the performance equation.


I think the best thing about FreeBSD is the incredibly high quality of its users; I don't know how that would fit into a "myths" page, but it's worth knowing. Maybe in a section covering how much less popular FreeBSD is than Linux and other operating systems. It could point at that while there are (many) fewer users, they are, on average, extremely well-educated about their system.

I'm nearly always impressed by the quality of bug reports we get from FreeBSD users. They're more likely to include a patch, more likely to include specific details about how to reproduce the problem and reasonable theories about why the problem is happening. I don't know if this is correlation or causation (or which direction the cause/effect goes; i.e. are FreeBSD users better educated and that's why they choose FreeBSD, or are they better educated because they have to be in order to survive on a more challenging platform...thus it could be survival bias, rather than any real cause/effect) and I don't know if it is self-reinforcing (i.e. smart users breed more smart users because they're better able to guide new users in smart directions).

All that said, lest I begin to sound too positive about FreeBSD, I still use Linux exclusively for my production servers and desktop/laptop. It's a great system with great users, but the sheer inertia of the Linux ecosystem is overwhelming. The Linux kernel alone has more contributors in each release than the entirety of the 400 commit bit havers on the whole of FreeBSD.

Luckily, of course, FreeBSD gets to leverage lots of things that are mostly driven by the Linux ecosystem (Gnome, KDE, etc. all sorts of things that are predominantly funded by Red Hat, Canonical, SuSE, IBM, etc. for their Linux products).


> I think the best thing about FreeBSD is the incredibly high quality of its users;

I suspect survivor bias in action here. At least I would consider a possibility that these users are so well-educated about their system because they have no choice. And that's not always what one wants. I don't really want to be extremely well-educated about the details of my car. I just want to operate a couple of buttons, levers and other gadgets and get quickly and safely from point A to point B. I couldn't care less how the car does it, for all I care it could have magical pixies inside.

Now, I'm not saying BSD users doing it wrong. On the contrary, if it works for them that's great, and becoming the master of your tools is both personally rewarding and enriching. But - if you're preaching to outside audience, one has to mention that "BSD users are very knowledgeable about the details of their system" might also mean "you can't use this system unless you become an expert in it, if you're just interested in being a casual consumer you're in trouble".


It's difficult to use FreeBSD without becoming a 90s-style expert sysadmin, and the handbook doesn't really help even if it's possible to do better.

Setting up a server should be as secure and fast as possible with no work, you should get backups, and you shouldn't need a C compiler installed, let alone /usr/src. But the docs still act like you need to be checking out the whole OS and recompiling it for every machine, and then recompile again for jails. And once you get traffic to your web server there's a few pages of sysctl numbers to increase because it won't autotune anything.

On the power user topics, is there a way to get a changelog of port/pkg updates or OS beta releases? It's hard to know when you should bother testing something.


I suspect self-selection: Right now, Linux is the most popular Unix. If you're going to another system, there's probably a reason, either technical or ideological. But to know enough to know why you might want to move already requires a lot of technical knowlege. And the will to actually do it, stick it out, and learn the different ways the system works requires a certain willingness to learn (although the excellent docs DO help).

It's not so much that you can't use the system if you're a casual consumer, it's that if you're a casual consumer, you won't bother.

Also, it's not a bias: We're trying to root-cause why the freeBSD community is so knowledgable. if it's because only the most knowlegable are capable of using it, that isn't a bias, it's just a result.

/nitpick


It's bias in a meaning that the cause is not BSD making their users somehow knowledgeable, but only users having enough motivation and knowledge to become power-users continue to use BSD. So if you approach it as a new user evaluating whether to use BSD, saying "BSD users are very knowledgeable" may mislead you as to the reason why.


I actually would be scared of anyone being a sysadmin (or devop for that matter) and not know their system very well.

Also I actually think it's a community thing. What is way stronger in the BSD community is people not being missionaries and wanting to aggregate users as much as you see it in the Linux or MacOS world (not saying that's bad!!!).

If you join the BSD community and are like "Why would I use BSD" people will often will be like "Why bother, unless you wanna learn something new? If you don't have a reason for using it, we won't convince you". This is pretty unique to the BSD community.

That also means that you are expected to not as dumb questions.

I was active in both BSD and Linux communities, and even in the more "know your stuff" communities (Arch and Linux for example) asking dumb questions wasn't frowned upon.

Yeah, you may call this elitism. Maybe it is. I don't think so, because there is no "I am too good for answering this" and in general less politics, but then it of course you can't completely deny it, if you are supposed to adhere to the typical "How to ask good questions" guide.

And really, it's not that one is better. It certainly isn't. It's a different approach. It more likes me think of how I once watched the Standford Programming Introduction Class and the guy talked about how there is different courses and some are more about being nice and holding your hand at all time and the the other is more pushing.

It's a culture thing and just like companies are successful with different cultures you can't say one is better for everyone.

Also it depends on what you count your success on. And that can be so many things, having something stable, having great bleeding edge, having a large community, a smart community, having a few big success stories or having everyone use it.

One can maybe compare it to a business plan or describing target audiences. Nobody will say that the target audience is wrong. (even though that's more the case when your goal is to make money)


Something about this seems slightly wrong to me. Perhaps it's the assumption that users are a thing that is a property of the software? I guess it isn't clear what way the causation goes, or even if it exists - just as the GP points out above. Would you say Windows had _low_ quality users? Or just _more_ users? I think early or niche adopters by their nature have to have a lot invested, and this manifests itself in commitment to producing documentation, bug reports, evangelising and so on. Essentially you are sampling from the far end of the long tail, whereas with commodity software the gaussian distribution comes into play and pretty much everything is normal (pun intended) or at least average.


I think I've been pretty clear that I don't know why FreeBSD users are on the high end of the knowledge scale, and that survival bias is a plausible explanation.

And, yes, Windows users, taken as a whole, do average out to be (very) low quality users. Linux users are somewhere in between. I'm not making a argument about causation, merely one of correlation and probably something about the mean level of knowledge.


The "user quality" associated with FBSD may be "higher", though it's a hard parameter to measure. Worth considering if the user quality has something to do with properties of FBSD itself vs. user characteristics.

Since I run a number of systems, each of the 3 OS (FBSD, Linux, Windows) is represented. Two OS attributes define important differences, ease of administration, and ease of user applications (including installation of app software).

Here's my theory:

As I see it the OS sort out in opposite directions based on these attributes. For ease of admin I rank them as: FBSD > Linux > Windows. Ease of use/apps is the reverse order: Windows > Linux > FBSD.

From an admin point of view, FBSD is the most straightforward to configure and maintain. Windows is an admin nightmare. Linux is more complex than FBSD partly because of its heterogeneous origin and more frequent, less predictable changes.

No doubt non-tech savvy users are more comfortable and feel more productive with Windows and don't have to learn much about the OS itself. FBSD can be used as a desktop/laptop OS but that's much more difficult to accomplish. Linux has more options/apps vs. FBSD, but fewer than Windows.

These factors favor FBSD in the role of server and Windows for general users. Linux can be a server or desktop. The reason Linux is more often used in the server role is probably an outcome of FBSD's relative obscurity, not inherent Linux superiority.

When it comes to servers, given a choice, in a Linux-dominated world relatively few will select FBSD. When there's a chance to get familiar with both, the lower admin burden of FBSD makes it an attractive option.

In my view FBSD, especially in the server niche, is simpler and easier to master which encourages admins to learn it in depth, therefore its users tend to more consistently appear to have a higher knowledge level.


The problem with these lists is that they are technically correct but misleading. E.g. yes, you can run Linux software with some plugins and Windows software with WINE. Except not every software would run, you'd have to jump through hoops that very well may be too high for your level of technical expertise and worst of all, you have no idea upfront if it'll work or not. Choosing OS is a big step, but it's also a foundational step which by itself does nothing for you - you then need apps. And when you read this list, say "OK, cool, all my software is Windows but I'm sure Wine will handle that" and then discover you can't really do any work - that's be bad for you.

Same with drivers - sure, BSD supports "wide range" of hardware. However, unless you are very skilled in hardware specs, there's no way for you to know whether your card that you just bought in the store/on amazon is in this range. This is the problem that bothers people - that their card would not be supported, not the global number of supported cards.

Same for binary packages - it's nice that it has binary packaging tools, but how I know the software I want will be available in package form? E.g. on Linux I can look into Redhat or Debian package repos and see what they ship, or see download page of any major software vendor and look for "Download for Linux" button - but while I see a lot of DEB/RPM/APT/YUM distribution instructions, I rarely see any BSD instructions.


Packages currently available for FreeBSD 10: http://pkg.freebsd.org/freebsd:10:x86:64/latest/All/

See also Freshports: http://www.freshports.org


Is there a cli tool to browse that, or do you have to go to the web?


If you have the ports tree [0] installed, you can browse through /usr/ports. There's a subdirectory in there for each port, named "category/port". You can search the ports tree using (replace foo with your search term):

  $ make -C /usr/ports search key=foo
You can install the ports tree by running:

  # portsnap fetch extract
[0]: http://www.freshports.org


An alternative with less typing:

    $ whereis foo
This will return the path to the relevant port if it exists.


Thanks. I'm a deb/ubu bloke, but always curious as to the details of other package management systems.


In addition to searching through ports, pkg-ng has a really nice search command. pkg search $string will search through the pkg database for matching strings.


You can also display a list of all packages in the repository with

    pkg search -g '*' | less
Better pipe it to less because there are over 25000 packages.


Yes, "pkg search <pkg name>" generates list of available matching packages. "pkg search -f <pkg name>" will give salient pkg info in a multi-line format. Use "pkg help search" to pull up the man page for "pkg search" with all the gory option details. "pkg help" shows a list of available pkg commands.

"pkg" has become a very useful, reliable tool.


Wide? You sure? Suspend/resume is broken for a lot of hardware configs.

I tried to install FreeBSD 10.3 on a new Skylake laptop. Resume doesn't work, so I asked on the forum. The answer? A stupid joke and nothing more. Are all FreeBSD users like this?


No, we are not. :-( For what it's worth I just tried to answer your question on the forums.


Can someone debunk the myth I read about the FreeBSD package management system?

In Debian/Ubuntu/Mint style Linux it's enough to use

  apt-get update
  apt-get upgrade
and only the changed packages including all interdepencies are downloaded and installed in the correct binary form (x86/x64/arm...).

How does FreeBSD really handles package management and is it ahead or behind the current state-of-art in this respect? And what is on the roadmap to improve the status-quo (in case there is a need)?


That particular case - upgrading everything - is actually supported pretty well. Of course, there's the distinction between the base system and app packages - the base still needs to be upgraded another way (freebsd-update).

It's the much more useful case of upgrading complete subgraphs of package dependencies that still wasn't implemented when I last looked at it a year ago.

If you have application packages A1 and A2 installed, and a library package L on which both of them depend on, then if you upgrade A2 to a newer version which requires (and is linked against) a newer version of package L, pkgng will simply not upgrade both L and A1. The pkgng devs simply declared this to be out of scope.

For a time, pkgng (now just "pkg" as it's the only one) looked like it could be the best thing since sliced bread, only for the devs to arrogantly dismiss the most common dependency-related operation used in practice. It's the single biggest issue which turned me away from FreeBSD, since I don't want to write package manager code, don't want to maintain my own package repos, and don't want to track "snapshots" (i.e. 6-months old "freezed" package repos, without security updates) which are the three "workarounds" proposed to me at the time.

This is important because FreeBSD's ports and packages are on a "rolling release" model, i.e. often (daily/weekly, depends on the maintainer) updated to the latest upstream version, so the lack of complete subgraph package upgrades regularly leaves you with broken apps.


pkg-ng was added a few years ago, and makes updating super easy. pkg update pulls a new package list, pkg upgrade installs. For installs, pkg add, for deinstalls, pkg delete. It also uses sqlite as its database format, so it's a lot easier to build tools around for querying and maintaining systems.


If you just want to update your system it's:

    pkg update
    pkg upgrade
Or just:

    pkg upgrade

This will do mostly what apt-get does (unlike apt and more like many others) it won't start or restart services.

You also have stuff like autoremove, clean, which (for checking which package owns a file), etc.

See the commands section for pkg: https://www.freebsd.org/cgi/man.cgi?query=pkg#COMMANDS


re: FreeBSD is Just OS X Without the Good Bits

The "good bits" are things like Photoshop, Illustrator, and Quark.

Sure, I'm aware there are alternatives like Gimp and [whatever]. But the alternatives are kludges for edge case experts; and not for people who need to Get Stuff Done.

PS. I operate a FreeBSD server. It's great for that.


The 'good bits' of OSX is that there is no such a thing as 'drivers' from the users perspective.

If you have to use the word 'driver' - it's not user friendly.

If you have to 'build' anything - it's not user friendly.

99% of people want to use their apps - even most devs just want a clean, stable, bug-free, well documented and consistent platform to develop on.

I have nothing against any of the unix flavours - all the power to them, but I'm not sure that these kinds of articles are hitting the mark when it comes to anything remotely resembling mass adoption.

Free BSD is not a 'product' really, I would argue that it's 'technology'.


The 'good bits' of OSX is that there is no such a thing as 'drivers' from the users perspective.

Well, unless you buy some hardware that is not from Apple. Buy a 802.11ac USB stick (because your Mac has 802.11n and you cannot upgrade the hardware) with Mac drivers. The vendor decides to release a (buggy) driver update for El Capitan half a year after it's released.

Pretending that the driver problem does not exist on macOS does not make it go away.

(Mac user since 2007.)


"Pretending that the driver problem does not exist on macOS does not make it go away."

I never said there was not a driver problem.

I alluded to the user perception of drivers.

Users in this day and age should have absolutely no need to be aware of the concept of 'drivers'.

Do you have any drivers for your Android? iPhone?

The very concept may very well be dated and perhaps there is a a better solution in 2016.


You make a good point and don't deserve the downvotes. Some OS projects don't aim for mass desktop adoption, although I'm sure all would like more visibility and users.

The barrier to entry for most UNIX-related tools is quite high for "non technical" users. I don't think that's a controversial thought. And one can hardly deny that some UNIX users like that i.e. if you can't read the MAN pages and figure it out, then perhaps UNIX isn't for you.


Some other good bits: development tools (malloc_history, spindump, leaks, crash logs, panic logs, dSYMs, powermetrics), security (code signing, ASLR, Time Machine), system APIs (Mach ports, XPC, launchd).


does FreeBSD not have ASLR? I thought that was, like, standard among all modern popular OS's: Windows, OS X, Linux... right?


Nope. There were some patches but it never made it in somehow.

I think it's worse there's no sandboxing. Ports just runs all kinds of code downloaded off the internet as root. Latest version does have the very beginnings of some in Capsicum but it's not like OS X where every daemon is syscall and FS sandboxed.


Nope no ASLR. They're working on it but not yet.


From the "FreeBSD is good for servers, not for Desktops"

> If even this is too much effort, PC-BSD is a full-featured desktop system built on top of FreeBSD, with an easy-to-use installer and the option of commercial support.

Seriously, it is this sort of "the user is so stupid if they can't compile their own software easily" attitude that turns me off about projects like FreeBSD. How hard is it to simply not say this stuff, and gain a lot more users into the bargain? Just say something friendly, like "If you would prefer an OS that works out of the box, PC-BSD is also available".


I don't see that attitude in what you are reading.

Any OS which the user has to install themselves has to assume a certain amount of knowledge in the user. It's completely fair to say "And there's an even easier way if you prefer" as well.


Your version, "and there's an even easier way...", does sound nicer than, "If even this is too much effort, ..."

There's a difference in tone there.


Well, perhaps, but it feels incredibly minor to me. Even if true, I don't think the tone represents the intention.


Last time I tried to use PC-BSD, updates were painfully slow. It lead me to believe that there were not enough mirrors to serve packages. This was about 5-6 years ago.

How is PC-BSD doing nowadays? Is it really worth installing and using?


> How is PC-BSD doing nowadays? Is it really worth installing and using?

Anecdotally, I installed it on a spare laptop last month and the first main hurdle was that the disk partitioner kept failing until I first manually fdisked the disk to a single partition.

The second hurdle was that when it booted to the desktop there was no system tray icon to enable wireless networking and select an SSID, despite the 4965 chipset being fully supported. Presumably it requires some messing-around with wpa_supplicant.

I haven't had time to go back to it but both would be deal-breakers for the 'common person'.


I use FreeBSD, but if you think FreeBSD 4.x was great (related to the "everything after was bad" myth) and also if performance is your thing you should take a look at DragonFly BSD. Matthew Dillon who is largely responsible for FreeBSD works on this now.

But don't fear. People of both projects share a lot, just try different approaches. :)

https://www.dragonflybsd.org/ (also, if you think the website isn't the nicest I agree)


I tried using FreeBSD for my web dev environment once. It was nice, I just hated the fact that I didn't have Dropbox and some node packages (like node-webkit) didn't quite work as expected.


FreeBSD is a second class citizen when it comes to the JVM.

Myth?


No, very true, sadly. I wonder if the C-school hackers on BSD just look down on Java as far too 'Enterprisey' for them? Or has this changed?


Noteworthy that they say it can run as a xen domU, but not whether as PV or HVM. HVM is a huge performance hut.


It supports both PV and HVM installations.


Not only it supports both PV and HVM (with PVHVM in works) but also it can run as a dom0.


Last time I checked PV was only supported on i386.


I just want a single download freebsd distro for the desktop to play around with. Doesn't seem to exist.


Maybe DesktopBSD? http://www.desktopbsd.net/ I dunno, I haven't used it but others have said that it's a simple install.

I bought a Lenovo Thinkpad to run a FreeBSD laptop and don't feel that the amount of work I had to do to get it to a useful state was all that different from the amount of work with Fedora on my desktop computer but I've been using both FreeBSD and various Linux distros for several years and don't know your amount of previous experience with either FreeBSD or Linux so YMMV.


Does FreeBSD have anything to compete with V4L/DVB ?


Yes, it has V4L/DVB support via the multimedia/webcamd port/package, which is essentially a user space port of Linux' V4L/DVB drivers.

https://www.freshports.org/multimedia/webcamd


From 2013


More accurately: from 2012, with minor updates from 2013 and 2016 [1].

1: https://wiki.freebsd.org/action/info/Myths?action=info


Indeed. There is 100G support now, for example.


Bhyve not being mentioned under their virtualization section is a pretty big hole, too.


Bhyve's in the second paragraph of the virtualization section. It talks about virtualbox, then bhyve.


D'oh, don't know how I missed that.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: