The Move from Linux to FreeBSD
nileshgr.com
nileshgr.com
https://lists.debian.org/debian-devel-announce/2014/09/msg00...
http://www.reddit.com/r/linux/comments/2hvikt/kfreebsd_port_...
- swappiness: they said they switched swappiness to zero but my guess is that by that time their mind was made up. Also, from the mention of swapping and the mention of apps being slow to come back to life, I really think this was the main reason for their memory issues. For reference, high swappiness will make the kernel will push memory for apps into swap to the benefit of caches. Default is 40, I have not seen one single case where that is a good thing in 12 ro 15 years. Do yourself a favour, make your first CM rule to switch swappiness to zero!
- the myriad of small apps in a lot of modern Linux distro (pieces of systemd, pieces of gnome (even on servers!), dbus, etc...). They are minimalistic distors out there which use a very small footprint
- the way memory is reported: If you look at free, the first line shows free memory as what's not in use by apps, cache nor buffers. If anything, free memory on the first line is memory that the OS is wasting (not using). If you want to know what is available for use by apps, you have to look at the second line (-/+ buffers/cache)
Also, if maximizing billable time is the goal, maybe the guy learnt a lot playing with another UNIX and increases his worth :p.
The biggest difference was memory usage: "FreeBSD is just too good at managing memory. My server earlier used to consume over 1 GB of memory for running PHP, MySQL and Nginx. Now, it doesn’t even touch 500 MB! It’s always less than 500 MB. Everything is just same, configuration, etc. Only OS changed"
Later in the article, a recount of desktop memory shortage issues under Linux and much improvement under FreeBSD. He even reports single applications like Chromium performing better and with no swapping.
Oftentimes this ends up being something like aggressively caching file data so that it doesn't have to write to disk very often. While this does get labeled as "used" memory, it can very quickly be freed up by the operating system by evicting this cached data back to disk if that memory is needed elsewhere.
This can make Linux appear more memory-hungry, but in actuality a better description might be that Linux is more effectively using the resources at its disposal. I'm not saying that this is what's happening in this case, but it's a possibility.
Active is fully-fledged in use memory, mapped into one or more processes
Inactive is where Active goes when it's less in-use. Cheap to reactivate, but relatively costly to free: can still be mapped into processes, and may be dirty (modified) and thus require writing to disk before being unmapped and cleared for reuse.
Cached is where lesser used Inactive cached data goes before it dies. More costly to reactivate, but cheap to free: No longer mapped directly into any process, and strictly consists of only clean (unmodified) pages that don't need writing back to disk before clearing.
Wired is pinned-down memory that can't be swapped out. ZFS's data and metadata caches are counted here, since it maintains its own (known as the ARC - Adaptive Replacement Cache, after the algorithm it's based on) instead of just relying on the traditional VM page cache.
free -h
An application doesn't magically allocate less memory when running under a different kernel. The underlying idea must be that LLVM wins over gcc in a real world scenario, which certainly would be interesting, but there is really nothing to suggest it here.
The kernel VM is all about heuristics. In a memory pressure situation, it's constantly discarding cached pages that it thinks are better used for other data, making decisions about whether to swap out some data to make room for more cache, etc.
If you remember/look at the history of Linux VM and swap behaviour tuning and algorithms, there have been large improvements and regressions in this area historically.
But even the server part, due to vague phrasing, could mean that his VMs are doing OK with 500MB under FreeBSD and needed more with Linux.
But yeah, it might be due to different configurations or misinterpretation of memory stats too.
Different default allocator can make a difference, though - FreeBSD defaults to jemalloc iirc.
Yes, Linux uses spare memory extensively as caches which can be dumped immediately as applications need the memory for usage.
Unfortunaltely, he didn't mention how he measured memory usage on both OSes.
Functionality like this is basic OS design knowledge.
The modern VM architecture was definitely introduced after 3BSD or 4BSD, since NetBSD only introduced a unified buffer cache in 2000 and is also derived from 4.4BSD.
[1] https://www.usenix.org/legacy/publications/library/proceedin...
I don't think anyone's trying to say that Linux is so special and glorious (beyond BSD).
Most likely I'd have used the system monitor that comes with KDE.
Yeah I could get some more RAM, but this box is a good testbed for software with a leaner streak, bloat does not excite me as much, sorry. Funnily enough this seems to offend a whole lot of people, as if I owe it to them to have more RAM on my m/c. It is probably worth it just for that amusement.
Definitely interested in giving *BSD a shot. The thing that has stopped me so far is the difficulty in sharing data between them.
EDIT @DanBC
> 70 tabs is not normal and 700 is just, well, weird.
So I have been told :)
Firefox manages it well enough though, I would assume Dillo would too. Dont want to hijack the thread with why I abuse tabs so, but I still contend that 1 GB is enough if the code is tight. 1 GB is a huge freaking load of memory if you think about it.
I'd be interested in what happens if you run 700 Dillo instances?
I'm willing to bet that the vast majority of computer users don't ever have more than 5 tabs open at any time.
Totally off-topic, but Yes :-)
.Net has a compiler built-in (you may need the SDK to get the command-line version), many systems have a compiler for a shader language, and your packet filter may ship with one.
The apps code is very close and linux doesnt magically needs to allocate more memory. What changes is just libc.
Freebsd is one of my favorite OSes regardless.
That's quite something to drop just like that. Any links?
I am actually using devel/android-tools-adb with the SDK under Linux emulation and it works quite well.
Although important, GNU projects are a very small percent of the 2376 packages that make up my desktop's userland right now.
In the end I've gained more than I lost, it's just that a catalyst was needed to get past the inertia of changing operating systems again.
Do you have any number to justify this statement?
I also note that all the tools you mentioned are of interest mostly in a server context (of course if you manage servers you will happily use them on your desktop too).
Right now it isn't really that bleak, because some distros still give you a choice, but people are worried that the choice will be sacrificed in favor of easier maintanability in the future.
Like ELF, glibc2, egcs, devfs, hotplug (the old script-flavored version), udev, eglibc, etc.
I am mentioning these, because all of them caused a controversy with a vocal minority. It is evolution. None of these are controversial anymore. Some of them were replaced, because they were bad ideas in hindsight (devfs).
By definition any fundamental part of the system (such as init or the C library) that changes is 'forced upon' the user.
"In layman's terms, the hardware interface is called Linux, while the rest of the part: the shell, core tools, etc are GNU.It's a piece from there, another from somewhere else and merging the whole thing into one collectively known as GNU/Linux. [...] In FreeBSD, the whole thing is a complete unit."
I think the OA will be quite happy with a mature systemd based GNU/Linux OS. Seems to like complete units.
PS: 'Many' is a hard concept when the OS is freely downloadable and not particularly monitored. One hopes the refugees actually make donations/buy DVDs.
I must admit shellshock and last security flaws also made me aware of my love for bloatwares. I find it sane to question my former choices.
A lot of components (OpenSSL? GCC? LLVM?) are in that repository merely for convenience but ARE NOT developed on internally (except for patches to make them work, eventually).
This IS NOT the same of "everything developed internally here, from syslog to dhcpcd" mentality of systemd.
Here's a list of systems that are both monolithic and modular:
* Linux
* the FreeBSD kernel
* the Solaris kernel
* Apache HTTPD
* Postfix
* OpenJDK
* XOrg
* EMACS
* LibreOffice
A modular, non-monolithic alternative to the kernels would be MINIX or HURD.
You can't mix and match (say) an Xorg taken from somewhere else and your own special cat program.
My understanding of the systemd project - especially later versions with kdbus in the kernel and udev integrated in along with networking and the console - is that you may need to 'lockstep' your choice of kernel, systemd packages and possibly the DE if using Gnome in order to have a functioning system. I can see advantages in this but it does represent a considerable cultural change in the Linux world which has previously been a little bit like a Lego set.
If I have this wrong, please advise and correct.
Given the licensing issues of combining GPL with CDDL code, ZFS will probably never be included in major distributions (assuming that the license will not change), so they will never have the same amount of integration as e.g. FreeBSD has in the installer.
https://www.freebsd.org/doc/en_US.ISO8859-1/books/arch-handb...
enought memory like 8GB+ you don't have to use swap at all.
...depending on usage. We have 64GB+ machines at work that regularly go swapping. It depends on various factors: how quick do you want the OOM killer to kick in, how slow do you want the system to get as a result of swapping, and how much budget is there available to buy machines that can take more memory.
Better suggestion: Be careful when listening to anyone making absolute judgments based on generalizations.
Some operating systems, just like some applications, are better for certain purposes (often because they were designed and built specifically to be suitable for those purposes). "You can do anything with anything" is a very idealistic oversimplification that's implied by the idea that no OS is ever better than any other.
No, it didn't save you any money. Delaying a purchase is NOT saving money.