Live data from Hacker News

Ask HN: Can we talk about FreeBSD vs. Linux?

news.ycombinator.com

191–200 of 221 posts

Re: Ask HN: Can we talk about FreeBSD vs. Linux?

#191
post #185
post #114

Earlier quoted context omitted.

I'm not an FS expert and others have answered your question much better, but I don't want you think I am ignoring you, so I'll talk about this part instead: > the filesystem could offer an abstraction over a patch and pointer to the original file I've implemented a delta-based patching system before: the idea is that, given two binary buffers (ostensibly files), encode the differences between them. I have no idea how…

The basis for transferring file metadata is already there in zip in the form of -V for VMS file system metadata. This works well and can be used to transfer files via intermediate platforms which don't support that metadata. It's not as seamless as one might wish; you do have to use zip. do the transfer and then unzip on the target, and of course remember to use -V in the first place. FTP implementations also exist i…

Indeed, ZIP gets us part of the way there, and also handles the issue of transferring more than one file in one download request.

The downside to ZIP is that the information is cast away once you decompress it. If your file system doesn't maintain that metadata (eg Windows and file permissions), then it's just gone.

You also can't really just keep your files in ZIP because operating systems don't really natively integrate transparent ZIP support into files, and you probably don't want the file compressed in most cases (your app may want to read it often, and not want to pay the cost of decompressing the whole thing.)

But that is very close to what I am seeking, yes.

Re: Ask HN: Can we talk about FreeBSD vs. Linux?

#192
post #187

Earlier quoted context omitted.

Indeed. This thread should really be titled OpenBSD vs. Linux. I'm sure most people here don't even know it's the only OS in the world allowing you run Xorg as an unprivileged user. Just like Linux taught me to appreciate FreeBSD, FreeBSD taught me to appreciate OpenBSD. OpenBSD -- the world's simplest and most secure Unix-like OS. Creator of the world's most used SSH implementation OpenSSH, the world's most elegant…

Personally, I love FreeBSD's beastie. Don't care much if it is "satanical" or whatnot.

Beastie was much better than the new logo that looks like a shiny bauble.

Re: Ask HN: Can we talk about FreeBSD vs. Linux?

#193

Earlier quoted context omitted.

This is OT, but since you seem to know a fair bit about filesystem types and their trades and have an opinion on sane patching behavior, I have a question you might be able to answer: Why aren't modern filesystems based on a content-addressable-store where the content is 100% separated from the organization of the filesystem itself? It seems to me like it would make more sense to have only one copy of a file ever sav…

Plan 9 was designed this way. Except it's designed to never delete anything, so you don't have to worry about the garbage collection. Camlistore and TahoeLAFS are both designed this way. But they are more of a content store than a file system. In fact, BTRFS is implemented this way. The content and the metadata can be separately treated with mirrors vs raid. You can balance just the metadata or both data and metadata…

Plan 9 had Venti, which was indeed a content-addressable file system. But it was not the main file system for day-to-day use; it was intended to store backups only.

Btrfs is not content-addressable, although everything else you say about it is correct.

Re: Ask HN: Can we talk about FreeBSD vs. Linux?

#194
post #97

Earlier quoted context omitted.

This is OT, but since you seem to know a fair bit about filesystem types and their trades and have an opinion on sane patching behavior, I have a question you might be able to answer: Why aren't modern filesystems based on a content-addressable-store where the content is 100% separated from the organization of the filesystem itself? It seems to me like it would make more sense to have only one copy of a file ever sav…

That's called copy-on-write (CoW) and is supported by a few modern filesystems (including ZFS). In fact ZFS does do some very basic deduping in the way you suggest (ie you copy a file instead of move it, and ZFS will just issue a pointer). However full deduplication could never be free simply because of the overhead of keeping a table of all the duplicated data and scanning new content for duplications.

Copy-on-write is not the same thing as content-addressable.

ZFS has deduplication as an optional feature, which is implemented as a content-addressable store of filesystem blocks. In contrast to e.g. git the content-addressable aspect is an implementation detail that is not exposed to users.

http://blogs.sun.com/bonwick/entry/zfs_dedup

Re: Ask HN: Can we talk about FreeBSD vs. Linux?

#195
post #117

This is a brief (probably incomplete) summary of my understanding (many points also supported by the essays in your included link): --- Philosophy: FreeBSD has the concept of a base system: a set of tools intended to work together harmoniously, maintained by a core group of people. You can easily find evidence of this by looking at the source code; the userspace tools sit right next to the kernel[0]. This is in contr…

Your "Philosophy" section describes the current situation, but with the growing adoption of systemd the GNU/Linux ecosystem will move more and more in the FreeBSD direction here so its coherent development approach will be less of a differentiator.

Re GEOM: does it have any features that Linux device-mapper lacks? Both look very similar to me in capabilities. For example, device-mapper has support for thin provisioning (thinp) and GEOM has gvirstor(8).

Re: Ask HN: Can we talk about FreeBSD vs. Linux?

#196

Why, FreeBSD is an advanced UNIX-like system for servers , derived from original BSD sources I don't remember exactly when. My first experience was with FreeBSD 2.0 It confirms to recent UNIX standards, such as various POSIXes (pthreads, rt extensions), UNIX98 (I guess), etc. and obviously don't have any Linuxisms, like udev, systemd (thank god!) fuse, you name it, which aren't that important for a server . So you co…

> It confirms to recent UNIX standards, such as various POSIXes (pthreads, rt extensions), UNIX98 (I guess), etc. and obviously don't have any Linuxisms, like udev, systemd (thank god!) fuse

I don't believe any BSD has ever been certified for UNIX98 (or any version). http://www.opengroup.org/openbrand/register/

And instead of Linux-isms you get BSD-isms like strlcpy(3) and devfs (which is the equivalent of udev).

https://wiki.freebsd.org/WhatsNew/FreeBSD10 lists "FUSE support in the base system" as a new feature.

Also the "native ZFS support" is not a "technology of FreeBSD's own" but ported from OpenSolaris.

Re: Ask HN: Can we talk about FreeBSD vs. Linux?

#197

Earlier quoted context omitted.

This is why OpenBSD is the superior desktop operating system. Fixed months ago. :)

Indeed. This thread should really be titled OpenBSD vs. Linux. I'm sure most people here don't even know it's the only OS in the world allowing you run Xorg as an unprivileged user. Just like Linux taught me to appreciate FreeBSD, FreeBSD taught me to appreciate OpenBSD. OpenBSD -- the world's simplest and most secure Unix-like OS. Creator of the world's most used SSH implementation OpenSSH, the world's most elegant…

[deleted]

Re: Ask HN: Can we talk about FreeBSD vs. Linux?

#198
post #186

Earlier quoted context omitted.

At this point, I don't think it's fair to imply that btrfs is lagging behind ZFS. Yes, there are quite a few things that ZFS does better than btrfs, but btrfs isn't following in ZFS's footsteps and has some killer features that ZFS will never have, like on-the-fly changing between RAID modes and resizing arrays in either direction.

ZFS would need block pointer rewrites to implement those features, right? I don't think ZFS developers are opposed to that, but progress is just stalled. So I think "will never have" is a bit strongly worded.

https://www.youtube.com/watch?v=G2vIdPmsnTI#t=44m53s

The above video is an explanation of a bunch of the barriers to implementing block pointer rewrites. The conclusion is that it would make the code a lot more complicated and break a lot of the layering, and probably make addition of other new features a lot harder. Even a standalone offline rewriting tool wouldn't necessarily be accepted into the OpenZFS codebase because of the maintenance burden. Their advice is that if you think you need that feature to solve a particular problem, you should be looking for a workaround to solve that problem without requiring the huge block pointer rewrite project (which nobody's working on), even if the workarounds have a significant and permanent performance impact.

When you take into account how long the feature's been in demand and been on the roadmaps under "eventually", it's clearly not going to happen anytime soon and won't happen without a major change to how ZFS development is being done. It's not definitely impossible, but it's perpetually several years away from happening. With btrfs already having it's equivalent to that feature and stealing an ever-growing slice of the users who need that feature, it's probably never going to happen for ZFS.

Re: Ask HN: Can we talk about FreeBSD vs. Linux?

#199

There's the old "FreeBSD vs. Linux vs. Windows 2000" document which caused quite the stir: http://people.freebsd.org/~murray/bsd_flier.html

That comparison is either dated or biased. Linux supports more hardware, supports many filesystems, and is definitely version-controlled. The GPL vs. BSD license discussion is political and has no place in a comparison like this, IMHO.

Re: Ask HN: Can we talk about FreeBSD vs. Linux?

#200

Earlier quoted context omitted.

Full end to end checksumming. ZFS can find and correct errors on the fly, and can ensure data integrity. Even on a single disk ZFS can notify the user what files have been damaged and should be restored from backup. That is the most important thing for me, I want to make sure that my data is safe.

This is only guaranteed with ECC RAM, right?

As an anecdotal data point, I see ECC corrections much, much more often than ZFS CKSUM errors. If you're in any way concerned about bitrot, ECC memory should be the first thing you go for regardless of your choice of filesystem.
Post reply on HN