Date: Thu, 21 Jun 2012 18:55:38 +0200 From: Polytropon <freebsd@edvax.de> To: Fred Morcos <fred.morcos@gmail.com> Cc: freebsd-questions@freebsd.org Subject: Re: New to FreeBSD - Some questions Message-ID: <20120621185538.a9aa6e5b.freebsd@edvax.de> In-Reply-To: <CAH3a3KUWc_a_8Ts8m2VHEYx5TNoGKGv_zCgMxhRkPbC9wvziaQ@mail.gmail.com> References: <CAH3a3KWEik7nViy2VDBka-a7X9Ew-NrFrW5hPQMT1d2UgGLpzA@mail.gmail.com> <jrt7n5$3js$2@dough.gmane.org> <alpine.BSF.2.00.1206202155100.2866@wojtek.tensor.gdynia.pl> <CAH3a3KUWc_a_8Ts8m2VHEYx5TNoGKGv_zCgMxhRkPbC9wvziaQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 21 Jun 2012 13:24:26 +0200, Fred Morcos wrote: > On Wed, Jun 20, 2012 at 9:58 PM, Wojciech Puchar > <wojtek@wojtek.tensor.gdynia.pl> wrote: > >> I'm quite new to FreeBSD too (RHEL/Fedora background), and am most > >> impressed with it so far. > > > > > > rather huge difference. If you use the "right" Linusi, you can gain lots of useful knowledge. Basics are important, and older versions of Linux can really teach them. Of course a "click'n'grunt" environment won't teach you much. > >> Secondly (and probably stating the obvious), the handbook > >> > >> <http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/>; > >> > >> is the place I always look first. > > > > and third - manuals. They are in sync with system and actually VERY useful. > > > > while i was still (long time ago) using linux most common manual was like > > > > "this manual is outdated. Use texinfo documentation". and texinfo docs was > > often outdated too. > > > > Today it is most probably "look at wikipedia" ;) > > > > Of course i means FreeBSD base system, ports are not part of FreeBSD and > > quality varies. In "modern applications", documentation is often left out ("Who ever reads that?!"), or it's scattered across web forums, user web pages and wikis. Some ports for FreeBSD have good manpages (e. g. "man mplayer", "man xmms" or even "man opera"), some don't (try to find manpages for KDE programs, also no "man firefox"). > I have been using GNU/Linux for quite a while and I am most > comfortable with Archlinux. That should have provided you with essential basic knowledge that you can apply in FreeBSD without problems. > The reason I like it is it's simplicity > from the ground up without wasting too much time on unimportant > details (unless you want to). You will find that aspect in FreeBSD. > Another strong point is that it provides > binary packages by default, user-building of packages if you want to, > and the same level of customization you can achieve with - say - > Gentoo Linux. FreeBSD seems to provide that. FreeBSD offers two methods: Source-based or precompiled. Both of them are build from the ports collection, a kind of means to control dealing with sources and automatically build from them. > I learned over the years that (re-)compilation of packages is not > something I want to do regularly, but something I would like to do > only when I need and want to (ie, to strip out or add a certain > compile-time feature from/to a package). A prominent example is mplayer / mencoder to deal with codecs. It's also typically needed to build OpenOffice with non-US language and "unusual" settings like no integration with KDE or Gnome (if you're not using them). > I also learned that the > performance gains of tuning compiler flags for a certain CPU are not > that drastic for a desktop/laptop/workstation machine workflow and > that this category of computing is mostly bound by IO speed > (especially with HDDs). It's only needed when you have to get things running on older hardware. Again, mplayer is a good example for where you intendedly would deal with compiling in such a constellation. > q) Is it possible to run a FreeBSD system without much building? In > other words, can I survive by depending on packages and only resorting > to ports when really needed? It is. You're basically using "pkg_add -r <name>" to install the packages you want. The required dependencies will automatically be installed. > What set me off, and got me tired of dealing with Linux-based systems > is a set of patterns that have been repeating over for some years > now. Generally: > > 1. Too often, core system components break (especially with every > Linux kernel release). They don't in FreeBSD. Only tested and verified modifications will be committed to the non-experimental branches (the security branch of -RELEASE, and the -STABLE branch). If you're following the experimental development branch -HEAD, it _might_ happen that the system doesn't even compile, but updated 30 minutes after that "accident", it runs fine again. :-) > 1. Yesterday I spent 30 minutes until my webcam worked, dealing with > v4l, gstreamer and cheese. FreeBSD - unlike Linux! - has a differentiation between the OS (FreeBSD itself, the operating system) and 3rd party applications ("everything else", the ports collection). Even if you mess up all your ports, you _never_ will end up with a defective OS. So even in such a worst case, you can still access system means for diagnostics and repair. > 2. Sudden drastic changes that are deviating from simplicity. > 1. The sudden flood of daemons that are designed to do everything > for me, without giving me much say in the matter. My computer is > supposed to help me, not decide for me or replace me. The concept of FreeBSD includes to have several system-level deamons available, but only few of them are running by default. You have to enable them if you feel you need them. This is done in centralized (!) system configuration files. The most important one is /etc/rc.conf. Did I already mention the problem of documentation? On FreeBSD, you can always do "man rc.conf" to find out what this file is. The manpages include documentation for system binaries and services, configuration files, kernel interfaces, library calls and maintenance procedures. Your Linux background will have taught you how to deal with "apropos", "whatis" and "man", and on FreeBSD, they actually work! > 2. Those daemons are hard to get rid of and are tightly integrated > into higher-level components in the stack (ie, into the desktop > environment). As many software for FreeBSD is ported over from Linux, it might be neccessary to run some of those deamons, e. g. DBUS to enhance the functionality. But _you_ need to enable it, it won't do by itself, so _you_ stay in control. The case of being "Linux-centric" already shows some downsides when there are interfaces needed that FreeBSD doesn't have (because it has other interfaces, and had them for many years). A known example is Xfce where the unavailability of some Linux-specific component reduces its functionality. > 3. Those daemons are increasingly hard and obscure to configure > (ie, huge XML files, complex hierarchies, etc). Again, this is something you'll also sadly find on FreeBSD. I remember dealing with HAL - already deprecated in Linux. You needed to fiddle with XML in order to get your non-US keyboard working again. The standard means to do so would have been the X configuration file where _all_ X related settings are present without being tied to a specific desktop environment. Rebuilding X without HAL and creating xorg.conf the traditional way solves such problems. > 5. I think many of the developers of those components are trying to > reach a Mac-like experience? I am not against that in any way, but > it needs to be working well. Not sure. Bloat, as I've been told, is a natural means of modern application development. However, I don't believe that. The problem is that most software wants to be wide-spread, so it needs compatibility across many platforms, therefore lots of abstraction layers and libraries are used. This all adds up to a pile of... software... that requires increasing resources in order to get the simplest things done. > Those are dbus, hal, udev, udisks, upower, pulseaudio, systemd, > consolekit and policykit. Except u{dev/disks/power} and systemd, you'll find them on FreeBSD too. Luckily they're optional. > q) Where does the FreeBSD project stand on this matter? From what I > noticed is that the base system seems to adhere to the tranditional > flat text files for configuration and simple tools that do a good job, > leaving it up to the user to combine those small tools to create > larger, more complex ones (a UNIX inheritance). FreeBSD (the operating system) exactly follows this approach. Others (ports, at least some of them) do not. > q) Is a FreeBSD stable base system with "current" high-level > components possible? Yes, follow the -RELEASE branch and use freebsd-update (a binary updating tool for your OS installation). > Will it avoid the issues I experienced on > Linux-based systems? Possibly. > q) I would assume UFS with J+SU is "fast enough" for a laptop? I think so. For a laptop, you _might_ consider adding encryption. Just in case. You never know. > q) Does ZFS make sense on a laptop? Any advantages of using it over > USF with J+SU? I am not interested in any striping or mirroring on > the laptops, but the compression features is very attractive for the > HDDs in the first laptop. I would not recommend ZFS for this specific kind of use, as you can easily create striping and mirroring settings with gstripe and gmirror, using UFS. > q) The second laptop has an SSD, would UFS with/without J and > with/without SU or ZFS make more sense for it? There are several parameters that you can tweak (see "man tunefs"), I would suggest a single partition spanning the whole SSD, and journaling would not be contraproductive. > q) Can I live with a desktop environment (Gnome or KDE) and desktop > applications (Firefox, Libreoffice, etc) by relying only on packages? I think so. LibreOffice... I'm not sure about the language versions that are offered precompiled. Is your required language (unless it's English) present? If yes, no problem. > q) Does ntfs-3g from ports work reliably with external HDDs or USB > flash drives with read and write support? I would like to hear > personal experiences with that. I can't answer that, except forensic analysis and data recovery I'm not a MICROS~1 person. :-) > q) Does the NVIDIA binary driver work reliably? I would like to hear > personal experiences with that. I'm using it here (nVidia GeForce 7600 GS - G73), nvidia-driver-270.41.19 using xorg-7.5.1. No problems, except the GPU is broken and sometimes locks the system. :-) > I am also planning to setup a micro-server for home use (either a > ready-built one or by simply building a PC and using it as a server), > questions about that will come later. The main use of it would be > hosting my multimedia, streaming music and making backups of the > laptops on it (cron + rsync). Also, maybe some web/ftp and git > servers. You'll find all required parts to do that in ports. It doesn't sound much complicated. > I installed the base system into Virtualbox and everything works quite > well. Everything is so... clean, and tidy, and consistent, and > simple. Very well thought out. I may add that I'm happy to experience that every day since 4.0. :-) > I am also very impressed with the > amount of properly written man pages and with the handbook. I would > like to thank and congratulate all of the people who work on the > FreeBSD base system, a true masterpiece. You actually _do_ recognize that this voluminous and quality documentation is accessible for you even without Internet connection? In a worst case scenario, it's a real benefit. > q) Does the bsdinstall align partitions to device blocks by default > for optimal speed? If not, I have found that I can use gpart with -a > and -b which will require me to calculate the start and end offsets of > each partition manually. Is there a tool that can automatically do > that for me? I've not bsdinstall, so I can't comment on that. I prefer using a live media (CD or USB stick) and then use the command line tools according to the requirements (either fdisk, disklabel and newfs for the "MBR approach", or gpart and newfs for the "GPT approach"). > q) Is it possible to get native resolution on the console? I played > with vesa and vidcontrol but could never get what I wanted. Native > resolution would require KMS? As far as I know, KMS (kernel mode settings) is specific to Linux. FreeBSD has several VESA modes bigger than 80x25. But I have to admit that I don't see a problem in using this default mode during initialization time. Later on, xterms (also those containing SSH and screen sessions) can be configured any size under X. > q) Adding tmpmfs="YES" to /etc/rc.conf is analogous to a tmpfs /tmp on > Linux-based systems, correct? Any other directories that might make > sense to have as an mfs (ie, in /var)? Maybe subdirectories of the /var tree. Note that /var/db contains important databases for the system, and /var/log contains logs that you don't want to loose in case of a system crash. Things like /var/spool may be well in volatile memory. Note that the use of /var/tmp vs. /tmp is also debatable: While /tmp is really temporary, as it can be erased on system startup (see rc.conf option clear_tmp_enable) or when residing on a RAM disk, /var/tmp is often considered to be kept across reboots. > q) Is there a place where all sysctl variables are documented? It > occurred to me when I was trying to find the memory usage on my system > but `sysctl -a | grep mem' shows a whole bunch of stuff. See "man sysctl", you can use the -d option to see the description. Also there definitely is some source code where everything is stored. > q) How can I set proxy settings system-wide? Same for PACKAGESITE (for > the pkg_* tools), how can I set a mirror system-wide? /etc/profile? Depending on your shell, you can set it in /etc/csh.cshrc (for the C shell, which is FreeBSD's default dialog shell). > q) I noticed all file/data-sizes are in bytes (ls, dd, etc), is there > a way to change that system-wide to be in human-readable format? What's not "human-readable" in bytes? I always thought 8k blocks where non-"human-readable"! :-) Aliases can do that. For example, you could use something like this: alias ls 'ls -FG -D "%Y-%m-%d %H:%M:%S"' alias ll 'ls -laFG -D "%Y-%m-%d %H:%M:%S"' See "man ls" and add options for dealing with sizes (display of SI units). Also you can "setenv BLOCKSIZE K" in your csh config file ~/.cshrc. > To assess my understanding, the system is split into kernel, base, > documentation, games, lib32 (on 64-bit systems) and ports. Those are sometimes called distributions (do not confuse with the Linux term). > There is > another split between base and ports where base includes everything > previously mentioned minus ports. Now, there are 3 "branches" of the > base system: RELEASE, STABLE and CURRENT. RELEASE means 9.0 and stays > that way until 10.0 is released. No. RELEASE means 9.0, 9.1, 9.2 and so on. This branch also considers the security updates ("patches"), often denoted as 9.0-p1, 9.0-p2 and so on. > STABLE means 9.0, 9.1, 9.2, > etc. No. STABLE is a continuous branch of approved development where the minor version number "disappears", e. g. 8-STABLE and 9-STABLE. Those branches have tested and verified development in them which is "newer" than -RELEASE, but might result in a future security patch. There are no patchlevels or version numbers per se. > CURRENT means "trunk" in SVN terms. CURRENT or HEAD is the "faster" continuous development branch. It contains stuff that might not be stable, e. g. experimental changes. > Is all that correct? Almost. :-) > Also, > when somewhere is mentioned `make world', this means to rebuild all > installed ports which doesn't include base, I assume? No. "make world" means to build and install all components of the operating system (but not the kernel). See /usr/src/Makefile, the comment header, where the most common "make targets" are explained. Basically: make world = make buildworld + make installworld make kernel = make buildkernel + make installkernel Also note that a specific order is important here. > q) The files in /etc/rc.d are all executable, from my understanding, > those files will get executed and it is their duty to check the > variable `<rc-script-name>_enable' for whether they should start or > not. Wouldn't it be more efficient to chmod -x or +x them to > disable/enable? I don't think so. Settings are centralized in a "control file", even if it just consists of "setting variables". So everything is in one place. > q) What is analogous to /etc/rc.local from Linux-based systems? It's /etc/rc.conf and maybe /etc/rc.conf.local. See "man rc.conf" as well as /etc/defaults/rc.conf for details. > q) Is there something analogous to the Linux magic sysrq key? I don't think so. FreeBSD isn't about magic, it's about power, the power to serve. =^_^= > I must say, the ports collection being built on makefiles was a > welcome enlightenment, it just, naturally, made sense. The *-recursive > make targets are a blessing, especially for configs. True. If you want to make the work with ports more easy, use a port management tool. For example portmaster (considered the best one), but there's also portupgrade and portmanager, as well as helpful tools in bsd-admin-scripts (also a port). > q) Is there a tool that can test a set of mirrors for connection time > and speed (for packages and ports)? Analogous to Archlinux's > rankmirrors? I'm not sure, but it can easily be implemented. :-) > q) Is it possible for the pkg_* tools (especially pkg_add -r) to > display progress? Maybe the -v option? :-) No, there is no real progess indicator, especially not an overall indicator (regarding dependency traversal), as far as I know. > q) I noticed in the ports collection that there were some outdated > packages (skype-2.2, gimp-2.6), should I report that and where? (A > PR?) _If_ they are in ports, they still work, so why get rid of them? Only ports that do not work anymore, aren't maintained or cannot be fetched anymore (no distfile mirrors) will be removed. There are also some versioning: "portname" is the current version, "portname<n>" is the older version n which still works, and "portname-devel" is the development version with "bleeding edge" features. > q) Is it possible to have the ports system compile into an mfs (to > avoid disk access)? Yes, there is a variable to control it. See "man 7 ports" and maybe /etc/make.conf. I have to admit that I forgot it currently. $WORKDIR? $WRKPREFIX? > q) Is it possible to have the user asked to change their password the > first time they log in (using an OTP) in a simple way? I looked at > OPIE but it seems to be much more complex than what I need. I think this is possible. Maybe see "man passwd" and "man adduser" for this step. > Also, I would like to have a system where user home directories are > encrypted based-on and using the user's password. From what I could > find, gbde and geli don't really provide that without any > administrator intervention. Correct, they work on "system level", not directly on user level. > q) What should I be looking at to achieve the above? You can generally encrypt the /home partition (implying that this is a separate partition or whole disk), and using per-user userland tools to deal with (typically changing!) passwords. I'm leaving out the ZFS questions as those have been already very nicelyn answered, and my ZFS knowledge is already too old. It's still from Solaris. :-) > q) I would like to hear anyone's recommendation of a cheap, low-power > ready-made hardware for such a purpose which is supported by > FreeBSD. Everything that contains standard-compliant components will do. Dell servers are known to work very well. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120621185538.a9aa6e5b.freebsd>