For those who haven't experienced this: it's really painful. Your entire desktop becomes completely unresponsive for 5-10 full seconds while a picture very slowly loads.
export MOZ_DISABLE_IMAGE_OPTIMIZE=1
Now, some of the about:config options that were proposed as alternate workarounds definitely caused very weird rendering glitches, but this one seems mostly side-effect free.
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 firewall PF, the world's most elegant mail server OpenSMTPD, and the OpenSSL rewrite LibreSSL. OpenBSD -- the cleanest kernel, the cleanest userland and the cleanest configuration syntax.
FreeBSD -- growing overly complex [1], lagging on security [2], packing itself with unnecessary, experimental technologies, and representing itself with a satanic mascot and a shiny, dildo-looking logo.
--
[1] http://lists.freebsd.org/pipermail/freebsd-hackers/2012-Janu...
[2] http://itwire.com/business-it-news/open-source/62641-crypto-...
Maybe the first, but these articles claim Fedora can do it too, although currently you need to edit a config file, and it only works if you invoke startx(1), not when logging in from gdm.
http://hansdegoede.livejournal.com/14446.html http://hansdegoede.livejournal.com/14268.html
"X is now rootless with the help of systemd-logind, this also means that it must be launched from the same virtual terminal as was used to log in, redirecting stderr also breaks rootless login. […]"
https://www.archlinux.org/news/xorg-server-116-is-now-availa...
This is obviously not a feature of archlinux itself, but an upstream x.org feature.
Attempting to talk about "Linux", as if some single operating system - lack of pluralism between commenters to handle the differences notwithstanding - is a problem with this thread.
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 saved and when modifications are made you get a new pointer to the changed file. Obviously it wouldn't make sense to do full copy on modifications for files over a certain size, but in this situation the filesystem could offer an abstraction over a patch and pointer to the original file until the system is idling and a full copy could be made.
The reason I ask about this is because it would make updating anything and rolling things back trivial since it would simply be a pointer change in the file hierarchy hash map from the new file to the old file and back again. Furthermore, such a system would give you dedupe for free and files could be marked for deletion only once the last pointer to the file in the CAS has been deleted.
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. When you convert an ext2/3/4 file system to BTRFS, it just sets up it's own metadata pointing to the same blocks that the ext used. You get a free snapshot of your data pre-conversion and it's all COW from then on. I believe the B-Tree of BTRFS is the metadata and the content never changes on disk until no more pointers exist. If you decide to go back, it just restores the superblock and the old data is still in the same spot. You would only regain that space after you delete the snapshot and the last pointers to the data are gone.
Btrfs is not content-addressable, although everything else you say about it is correct.
This does make rolling things back trivial.
It doesn't give you dedupe for free, though. Think about what would have to happen: every modification would mean rehashing the modified block (not a problem, that should happen anyway to verify integrity). Let's say we dedupe at the block level rather than the file level to avoid the need for more expensive hashing operations, and to increase the likelihood of actually sharing stuff. Now, to determine whether we can deallocate the new block, we need to look up the hash. So we need an index of every block on the file system by hash. That necessarily involves either a big chunk of memory or a bunch of random I/O. Both are at a premium for a filesystem - the former for cache, the latter for throughput.
If you just want file dedupe, it's a smaller problem, but is less likely to create gains - most people don't store many copies of the same file, unless they're in the third party file storage business. So it isn't really suited to a general file system. If this is something you want, you could periodically go through your file system, hash all files with only one link count in the inode, and hard link them using the hash as a file name, into an set of directories fanning out by hash prefix. There may be some wrinkles with permissions; I believe btrfs has a different kind of copy with copy-on-write semantics that might be useful here.
But I don't think you'd have this problem. Just like we have an inode telling every block of a file, a filesystem like that would need a similar structure telling every hash of the file. When you delete a block, you look at this structure, the same way you look at an inode.
The only thing missing is that you'll need a counter at the blocks. And this counter will create some synchronization problems that may turn out more important than saving disk space.
It's also worth noting that ZFS has been available as a root file system long before FreeBSD added ZFS to RELEASE. I remember running OpenSolaris (and some of it's forks, eg Nexenta) with ZFS root about 6 years ago. Possibly longer actually.
The issue with ZFS as root was more of a problem with the boot menu than the OS. OpenSolaris used GRUB where as FreeBSD obviously doesn't, so FreeBSD needs to either port their ZFS drivers to their bootloader, or employ a hacky method of having a UFS boot volume that then points to a ZFS root partition (which, sadly, is how FreeBSD currently works).
Interestingly, since GRUB is GPL, it meant that technically there were GPL ZFS drivers even before Btrfs started life (never mind the various Linux ports of CDDL-licenced ZFS drivers that have appeared since). Albeit those GPL ZFS drivers were read only
A ZFS-aware loader hit CURRENT in late 2008, and a dedicated zfsloader for use from (gpt)zfsboot hit the stable branches in late 2009.
Anyhow, thank you for the correction :)
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.
http://open-zfs.org/w/images/7/71/Fast_File_Cloning-Pavel_Za...
> 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 Xdelta (VCDIFF-based) and bsdiff manage to do this at reasonable speeds (their code is too much for me to understand), but the best I could manage for this was O(n^2). It's a very complicated and difficult thing to do efficiently. But indeed it can result in massive file space savings. You could cheat a bit by intercepting fwrite commands, but that won't catch insertions or deletions. Nor programs that overwrite files instead of updating them in-place (eg most of them.) As you can guess, to really make something like this efficient would require program authors to rethink how they write to files, which is unlikely to ever gain traction.
What I'd really like to see, but know that we'll never get thanks to xkcd.com/927, is a metadata system for files that is portable. Instead of relying on file extensions or unreliable magic byte header detection, you'd have the MIME type included in this metadata. Along with the displayed file name that can have any characters in them (sans maybe the path separator), the file attributes (read/write/exec/user/group/owner/hidden), creation+modification+access times, etc. And then when you'd send a file through your e-mail client or FTP it up to some web server, it'd copy over the metadata along with it. So when you moved your file from extfs over to NTFS, and then copied that over to ZFS, you wouldn't lose all of that metadata.
But good luck getting all file system authors and browser vendors to agree to a common format to transparently wrap files with.
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 in the VMS world for transferring the file metadata, but I haven't used these myself so can't comment on their usability in practice.
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.
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.
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.
I know that. But CoW does cover a few points raised by the previous poster.
> 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.
I know what dedup is and how ZFS utilises it (I've been running ZFS for about 8 years now - I'm quite familiar with it).
If you read my post again, you'll see I was discussing two separate points: 1) that CoW file systems do provide the pointer-like methods the former commenter raised. And 2) deduping isn't free.
What you're arguing with me is semantics and if you read the former post again, you'll understand why I chose the language I chose.
You now get the regular repository (binary packages updated once per week), or the 'Quarterly Branch' (a known-good snapshot of the packages, with security updates)
Or you can build your self from ports (or build your own packages using poudriere), which is up-to-the-minute bleeding edge.
"I just apt-get install xfce and I'm done" isn't learning how anything works.
If you want a ready-made desktop, use PC-BSD. If you want to learn to install a desktop from scratch, use vanilla FreeBSD. However, don't claim you want to know how it works, then whine when you have to gasp actually configure it to work.
Actually ... you're absolutely right. Sorry about that.
I guess a better way of putting it is that Debian is the upstream, and FreeBSD is the upstream, and that's what I was comparing. I'd personally feel a bit uneasy using PC-BSD, like I do with Ubuntu. But that's my hang up. It is a trade-off though. Things like the consolekit.pkla file I'd rather have done for me (there's only one way it should ever be done), things like font rendering I'm happy to know how to do myself now (in case I want to tweak things.)
But yes, for anyone looking to try FreeBSD on the desktop, definitely look into PC-BSD, as it may solve a lot of the complexities I discussed.
These Just Worked for me. My only real annoyance with Xfce is that it's unresponsive to mouse clicks for the first few seconds after starting.
> I really, really appreciate Debian's branches. If you install Wheezy, you can get security updates for packages, but not get version bumps. With FreeBSD, you have to choose between "the packages made at release time", or "the absolute bleeding edge."
There are quarterly port branches now to give people more of a choice: https://lists.freebsd.org/pipermail/freebsd-ports-announce/2...
> encrypted swap
Be nice to see this on by default these days, but if you're not already using it: swapoff -a && $EDITOR /etc/fstab && plop ".eli" at the end of the swap device name && swapon -a. Done.
> I also really like pf a whole lot more than iptables
I just wish it were more actively maintained and kept at least vaguely in-sync with upstream. Makes me reluctant to switch from ipfw.
Under a regular user account? I even added my user to wheel and operator, and no go. I've helped a few people on forums.freebsd.org set up this pkla file, too.
> There are quarterly port branches now to give people more of a choice
The quarterly branches are definitely a step in the right direction, but still not really what I want. I want patches for Heartbleed and Shellshock, but without any software version number bumps. I know their team is much smaller so it's just not feasible, but it's definitely something that would be greatly appreciated.
> I just wish it were more actively maintained and kept at least vaguely in-sync with upstream.
Definitely. Is OpenBSD's MP-safe yet? I believe that's partly related to why FreeBSD's has ALTQ disabled (but it's hard to find good information on why that choice was made.)
Yep. Only special factors I can think of are VirtualBox guest additions and passphraseless sudo - though I don't recall any similar problems when I last had it on my laptop which had neither.
Also starting from console and not a display manager, because they're vile things that are almost as bad as splash/boot screens.
> I know their team is much smaller so it's just not feasible, but it's definitely something that would be greatly appreciated.
Very much so - the biggest thing I miss from the Debian world is unattended-upgrades. Maybe with some more commercial support..
> Is OpenBSD's MP-safe yet? I believe that's partly related to why FreeBSD's has ALTQ disabled
It's still under a big giant lock as far as I'm aware. They're also removing ALTQ in favour of a simpler framework: http://undeadly.org/cgi?action=article&sid=20140419151959
As much as I would love to have the newest OpenBSD pf config syntax available in FreeBSD I do appreciate them not breaking my firewall config as part of an OS update.
As a side note, I'd love to have something like "freebsd-update rollback" for most Linux distros. I've seen attempts at it, but the only one that worked well for me was openSUSE integration of btrfs snapshots and the package manager. That's kind of swatting a fly with the complete works of Knuth, but it did the job.
http://www.freebsd.org/doc/handbook/updating-upgrading-freeb...
https://forums.freebsd.org/threads/howto-freebsd-zfs-madness...
I have my VPS (production) and a local HDD I use for testing (stage), configured exactly the same way. I'll update stage first, and if all looks good, then I'll update production.
Curious then as to your choice of licensing your Higan/BSnes emulators under GPLv3.
The reason in higan's case, is because of the culture of the emulation community. There's a long, dark history of closed source emulators (even now with SuperGNES, no$sns and SNESGT), and I feel that emulation is a bit different from ordinary software: here, we are working under the threat of time. We realistically only have another 10-20 years to improve SNES emulation before finding a working system and persons interested in reverse engineering it are impractical.
I think it's very shallow and narcissistic to take the research of others, and not contribute back your own findings. I view this as more of an academic / historical preservation project than a regular desktop application. To end users, it's just for playing games, and not tied to any other system components, so I feel less bad about it.
To give a real world example, I encountered a bug in SuperFX (GSU1) emulation, and found that FuSuYa had a tracer-based fork of Snes9X: he basically added in a few fprintf() statements, and then refused to release the source to his changes. That would have been fine, but he botched something and introduced a very serious bug, one that I was also experiencing in my emulator. If I were able to diff his source to the official Snes9X source, I would have found and been able to fix that bug in a few minutes. Instead, it took me about two weeks to track it down.
Once I feel that SNES emulation has reached its limits in terms of research, I'll likely release the emulator under an ISC license as well.
Now I'm sure you can view this as me being hypocritical, and maybe it is, but that's my answer: I feel there's something more important than licensing at stake here.
Comparing a full system like FreeBSD to a kernel like Linux doesn't really get us anywhere. You can't really talk about the desktop experience comparisons when Linux can't even boot without a userland. If you tried to do it in an abstract sense, you'd be guaranteed to get responses of, "yes but Mouse Rat Linux supports ZFS and is also run by an elected core team!"; since there's pretty much a Linux distro for everything imaginable.
I'm curious if anyone who knows more than me would disagree, though (maybe for some purposes?).
I would like to try FreeBSD again. Does anyone know if this works now?
edit: clarified the reason I ask is because I want to know.
It's funny how little things like this affect where you go with systems. On the uni systems, emacs was set up to reformat your code by default (as you typed it in). This drove me bananas, and I didn't realise it was configurable. So I went off and found another editor, and I'm still using it.
I think the biggest worry is that if you need to do something like boot into single user mode for an emergency recovery, and /usr or /usr/local (with root's shell in it) is on a different or unmountable partition then you will not be able to do anything.
This is a really bad place to be.
With zsh you even get tab completion of ports, packages, and other command specific arguments.
Personally I run Ubuntu on my work desktop so I can focus on work and not managing the OS. I run a private irc server on a busted old desktop running Arch Linux for the opposite reason :)
However, in the FreeBSD ports tree, I guarantee you there is a bash package you can install, and then you can just switch your shell to be bash instead of sh.
The default root shell on FreeBSD is csh (tcsh) [1] and has been that way for at least 21 years (at least if I read the revision history [2] correctly, my own memories only go back about some 15 years).
As per Wikipedia article, tcsh natively supports tab completion since about 1983 [3] (which I can confirm always worked without an issue as far as my memories go, so again, give or take 15 years).
Permanently switching any user shell to tcsh (if it happens to be sh) is pretty much a single `chsh` command away, so as far as strictly tab completion goes, manual installation of bash is not required at all.
The required steps (step) to setup tcsh for tab completion can be found i.e. in this 2004 FAQ [4]:
Tip#7: List possible completions
I often see Bash users complain that Tcsh does not give a list of completions with the tab key. This is not true. Not only can Tcsh list complentions, but it can do it in color. Just add this to your ~/.tcshrc
set autolist set color set colorcat
[1] https://www.freebsd.org/doc/en/articles/linux-users/shells.h...
[2] https://svnweb.freebsd.org/base/head/etc/master.passwd
Also want to add that csh comes stock with historical auto completion which I very much enjoy.
Typing "tail " and pushing the up arrow will auto complete with the last command you typed starting with "tail ".
/bin/sh in 10.x has tab completion.
I didn't see tab completion when I was running the installer and I gave up.
Thank you for answering my question.
I really like how easy Debian on the desktop is: install it, apt-get install xfce, and I have a nice desktop. It's very easy to add Adobe Flash, Steam, Skype, etc.
The FreeBSD desktop isn't as nice. You can add things like Flash and Skype on FreeBSD, but you have to fight harder and often use the Linux emulator. We're missing nouveau, I've had some kernel panics with the nvidia binary drivers (caused by nvidia's own shoddy code, not FreeBSD's fault), there's a lot of missing and unstable features due to developers primarily targeting Linux these days (Thunar's file refresh is glitchy and often fails to update, Thunar volman only really works with udev/Linux, mousepad crashes when you open a file an even multiple of 4KiB due to a bug in their code and a quirk of Linux mmap, livbte-based terminals tend to crash sometimes when you open them due to a bug somewhere between libvte and FreeBSD's /bin/sh, file-roller explodes when you try and extract large archives, Firefox has freezing issues with loading gigantic images unless you set MOZ_DISABLE_IMAGE_OPTIMIZE=1 in your environment, on and on.)
And it's also not really configured well out of the box for the desktop. I have to make this org.freedesktop.consolekit.pkla file and add entries to it in order to get the restart and shutdown buttons in Xfce to work. I have to create a fontconfig/fonts.conf file and substitute Helvetica with Sans in order to get Firefox to anti-alias text on web pages. And so on.
You are also doing all the setup from scratch. You install xorg, you install your video drivers, you set up xorg.conf, you create .xinitrc, you install a display manager if you want one, etc. This is both good and bad. It's great if you love tweaking your system, it's bad if you just want to throw it on a box and run it.
Moving on ... I really, really appreciate Debian's branches. If you install Wheezy, you can get security updates for packages, but not get version bumps. With FreeBSD, you have to choose between "the packages made at release time", or "the absolute bleeding edge." These updates can and do break workflows, especially on the desktop (Firefox pushed Australis on me, ibus moved to this braindead, slow-as-molasses super+space IME changer, etc.) The actual package installs are about the same for binary (apt-get vs pkg), but I much prefer FreeBSD's ports for building software (which is great when you need to patch software bugs.)
But if you're patient and good at fixing problems, you can end up with a rock-solid desktop. And hey, maybe PC-BSD will save you all of the above steps, too. I kind of look at FreeBSD vs PC-BSD as I do Debian vs Ubuntu: I'd rather know how things work than have it all done for me.
In terms of features, I really like FreeBSD's ZFS, even though it does eat a lot of RAM. Snapshots, whole-disk encryption on root, encrypted swap, mirroring/striping/RAID even across different disks, easy resilvering, etc. I also really like pf a whole lot more than iptables, as I find the syntax a whole lot more readable and flexible, although I will lament that FreeBSD's pf ships with ALTQ (QoS) off by default. I prefer the base system being maintained by the FreeBSD team. I like the consistency, the minimalism, and the great documentation.
Whenever I spot a difference between FreeBSD and Linux, I almost always favor the former's design: /dev/random behavior, jails vs cgroups, SO_NOSIGPIPE socket opt instead of needing the MSG_NOSIGNAL flag, etc.
I like that FreeBSD avoids a lot of the 'licensing wars' BS of Linux. I have Firefox instead of Iceweasel, I have cdrtools instead of cdrkit (I continue to this day to have issues with burning on Linux), I have ZFS instead of btrfs, we had sound mixing in an OSS fork instead of ALSA, and just in general I favor the BSD/MIT/ISC licenses to the GPL.
I very much like that FreeBSD is much more conservative about major changes, and open to choice, so we don't get things like systemd, Pulseaudio, etc pushed on us before they are ready for production. I used to love this about Debian as well, but they've really lost their way as of late in pushing systemd on everyone before it was ready. I greatly value stability over whiz-bang bleeding edge features. I like that FreeBSD is run by a democratically elected core team instead of by a benevolent dictator (I don't have to read what crazy thing Linus or Theo said today in the news.) I like that FreeBSD isn't balkanized into hundreds of different distros. I love not having people telling me to say "GNU/FreeBSD" whenever I mention FreeBSD. I like that third-parties like Redhat don't exert so much control over upstream.
I like the community of FreeBSD more, as it feels that most of the members are more technically oriented. Distros like Ubuntu have brought in a lot of users with little to no experience nor interest in learning the unix way of doing things. I'm not saying this is a bad thing, or that I think less of eg Ubuntu users, just that I prefer the company of sysadmins and developers over gamers and web surfers. I dislike that I can't really discuss the OS with anyone in real life, because it's too niche.