Slashdot Mirror

I don't know of any such tutorials. The handbook is a pretty useful read for FreeBSD. It has a section on ports, which includes very light information on portsnap, portupgrade, and portmanager. It also has information on the older cvsup method of updating your ports tree (roughly equivalent to apt-get update.)

I use the portsnap/portmanager combination, personally. It works well for me.

I definitely think that the ports system could use some work, however FreeBSD still wins out over Linux for manageability, in my opinion. I'm a big fan of the way that the base system is separated from installed ports (all ports are in /usr/local/, compare to some Linux distributions where they can be all over the place and intermixed with the base system). This sometimes causes a 'gotcha' for new users, who expect all of the configuration files to be in /etc--for installed ports, they are in /usr/local/etc. And init scripts are similarly divided, so that to restart Apache (which is not a part of the base system), you'd run '/usr/local/etc/rc.d/apache restart', but to restart OpenSSH (which is a part of the base system), you'd run '/etc/rc.d/sshd restart'. Some people don't like this separation, and would prefer unity of all init scripts, but it makes a certain amount of sense to me (and a lot of other people who love FreeBSD).

Anyway, if you give it a try, I hope you enjoy the experience.

I don't know of any such tutorials. The handbook is a pretty useful read for FreeBSD. It has a section on ports, which includes very light information on portsnap, portupgrade, and portmanager. It also has information on the older cvsup method of updating your ports tree (roughly equivalent to apt-get update.)

I use the portsnap/portmanager combination, personally. It works well for me.

I definitely think that the ports system could use some work, however FreeBSD still wins out over Linux for manageability, in my opinion. I'm a big fan of the way that the base system is separated from installed ports (all ports are in /usr/local/, compare to some Linux distributions where they can be all over the place and intermixed with the base system). This sometimes causes a 'gotcha' for new users, who expect all of the configuration files to be in /etc--for installed ports, they are in /usr/local/etc. And init scripts are similarly divided, so that to restart Apache (which is not a part of the base system), you'd run '/usr/local/etc/rc.d/apache restart', but to restart OpenSSH (which is a part of the base system), you'd run '/etc/rc.d/sshd restart'. Some people don't like this separation, and would prefer unity of all init scripts, but it makes a certain amount of sense to me (and a lot of other people who love FreeBSD).

Anyway, if you give it a try, I hope you enjoy the experience.

You really want to use send-pr(1) for sending bug reports. The web interface is indeed horrible. Here's a great guide on sending PRs. There's also a GTK frontend for send-pr in ports.

You really want to use send-pr(1) for sending bug reports. The web interface is indeed horrible. Here's a great guide on sending PRs. There's also a GTK frontend for send-pr in ports.

To my understanding they are just kernels.

No. "Linux", strictly speaking, refers only to the kernel, but, for better or worse, it's also used to refer to complete systems ("distributions") built around that kernel, e.g. "Red Hat Enterprise Linux" or "SUSE Linux Enterprise" or "Mandriva Linux" (some distributions that use the L word in their names) or "Debian GNU/Linux" (a distribution that uses the L word in its name, but adds "GNU" to refer to the GNU project software in the distribution) or Ubuntu or Fedora (two distributions that don't use the L word). (I.e., if you will, people sometimes use the word "Linux" to refer to Linux distributions, not just the Linux kernel.)

{Free,Net,Open,DragonFly}BSD, and derivatives of them such as PC-BSD, are complete systems; if, for example, you go to http://www.freebsd.org/developers/cvs.html, it gives instructions for getting access to the CVS tree for the complete system - kernel, libraries, applications, daemons, etc..

Both using the gnu/fsf/x GPL'd code for the system.

The Linux kernel, the C library used in most distributions (GNU libc), many of the other libraries in most distributions, and many (most?) application programs and daemons in most distributions, are GPLed. GTK+/GNOME and Qt/KDE are also under the GPL or LGPL. Other software in the distributions might be under other licenses, e.g. BSD licenses, MIT license for X11, etc..

The BSD kernels are, not surprisingly, under a BSD license. The C libraries used in the BSDs are also under a BSD license, and are not based on the same code as GNU libc; the same applies to some libraries that are GPLed in Linux distributions. That also applies to utilities. In particular:

ls on BSD and linux I'm guessing is the same

you guessed incorrectly - Linux distributions have an ls from GNU, while the BSDs have their own BSD-licensed versions of ls.

However:

both run Xfree86 or X.org, apache, php, MySQL, gimp, whatever it is

that part is true - although it's also true of many commercial UN*Xes. So:

I bet if you had a FreeBSD box and a Linux box sitting next to each other, with the same UI (KDE/GNOME, OpenOffice, Gaim) running you wouldn't notice a difference.

you probably would notice few, if any differences - unless you opened xterm or Konsole or GNOME Terminal or... and started poking around, in which case you'd see more differences.

So besides that, what *IS* the difference from a user perspective

From the perspective of a non-power-user mainly using a GUI, probably very little, except to the extent that particular features of the GUI are or aren't supported by particular OSes; a command-line user might see more differences, which might make be more notable if they're differences from what they're used to on whatever flavor of UN*X they mainly use.

That also is true of many commercial UN*Xes, as almost all of them have X11 and could run, for example, KDE or GNOME (I think the primary GUI for Solaris is GNOME-based at this point, although I think CDE is still available). The primary exception is, of course, OS X.

or is it all lower level API differences (BSD not use int 0x80h sys calls?)

There are BSDs and Linux distributions that could run on the machine on which I'm typing this - and none of them would use "int 0x80" ("0x80h" is redundant, it's either "0x80" or "80h" to say "hex 80") system calls, because that instruction isn't present on PowerPC. :-) Even on x86 processors, with later processors a system might use "sysenter" or "syscall" rather than "int 0x80". And, in any case, system call traps are at a level below the API - read() is an API, the under

Also, this is the quick-and-dirty guide, try looking at The Handbook before trolling... /Mikael

Having used FreeBSD for a couple months, I'd say the biggest beef I've had is their bug handling (especially reporting) system. It's fantastically slow to submit (several minutes even when no files are attached), submissions are not acknowledged, it can take up to 15 minutes for submissions to show up in the system (making for ~30 minutes in total to verify submission of a single bug), it's hard to search properly (search "Text in single-line fields", WTF?), the default search lists all bugs on one page, searching for "State: Any" doesn't show closed bugs, it shows HTML escape codes for special characters (e.g., "ł"), and their wiki page on improving the bug tracking system is immutable. And yes, most of this has already been reported, but not fixed.

In open source, having an easy to use bug tracking system is IMO paramount.

Having used FreeBSD for a couple months, I'd say the biggest beef I've had is their bug handling (especially reporting) system. It's fantastically slow to submit (several minutes even when no files are attached), submissions are not acknowledged, it can take up to 15 minutes for submissions to show up in the system (making for ~30 minutes in total to verify submission of a single bug), it's hard to search properly (search "Text in single-line fields", WTF?), the default search lists all bugs on one page, searching for "State: Any" doesn't show closed bugs, it shows HTML escape codes for special characters (e.g., "ł"), and their wiki page on improving the bug tracking system is immutable. And yes, most of this has already been reported, but not fixed.

In open source, having an easy to use bug tracking system is IMO paramount.

Good to see Linux catching up. Too bad it won't be in the kernel for you ;).

Sorry for the naive question in advance, but I was under the impression that some flavors of BSD (OpenBSD?) were extremely secure as well.

You can use FreeBSD http://freebsd.org/ - another good OSS project in case Linux died (I don't think so it will but just in case...)

Ping was already taken... silly.

http://www.freebsd.org/cgi/man.cgi?query=ping

Once we're sure it's stable, because it looks like a massive improvement over the 1970s-style file systems we're using now. ZFS is now part of FreeBSD, Solaris will have ZFS "soon" and many Linux distros are also considering it. Good. Let's get to a common standard that's excellent and forget the tedium of these past, less effective file systems.

http://lists.freebsd.org/pipermail/freebsd-fs/2006 -June/001962.html

I don't know if it's actively in use, however it indicates that there is at least 1 JFS available for FreeBSD.

http://lists.freebsd.org/pipermail/freebsd-fs/2006 -June/001962.html

I don't know if it's actively in use, however it indicates that there is at least 1 JFS available for FreeBSD.

...a fairly large scale exodus to FreeBSD once the GPL v3 comes out.

The responses to the last few articles that have had anything to do with the GPL have been utterly toxic, on both sides. If the Linux community keeps this up, eventually there will only be the diehards left; nobody else is going to want anything to do with them.

Here's the link for those who want it. It might be a bit less polished than Ubuntu, but you won't have to put up with the toxicity that is standard around here, and if you make improvements to it and want to earn a living from such, nobody has a problem with it like Linux users do. Enjoy.

See http://www.freebsd.org/cgi/cvsweb.cgi/src/gnu/

Sounds similar to FreeBSD's GBDE http://www.freebsd.org/doc/en_US.ISO8859-1/books/h andbook/disks-encrypting.html which was funded by the DoD as far back as 2001 http://news.com.com/2100-1001-269644.html

You can get ZFS with FreeBSD also. http://lists.freebsd.org/pipermail/freebsd-current /2007-April/070544.html

Looks like the Linux Binary Compatibility layner of FreeBSD.

Looks like the Linux Binary Compatibility layner of FreeBSD.

They should adopt the FreeBSD ports system or NetBSD's pkgsrc. Pkgsrc already has some support for Solaris. Even with just a little bit of support from Sun, it would far exceed the capabilities and quality of apt.

http://www.freebsd.org/cgi/man.cgi?query=jail

... FreeBSD.

With which you can do pretty much as you please, especially keeping all the source code to your customizations and mods a secret from your customers. You only have to keep the BSD copyright notices intact.

With Linux, the GPL requires you to hand over (make public) your Intellectual Property to any customizations and mods you may make to it if you wish to redistribute it to paying customers.

And folks.... whether you like it or not... in the 21st Century, "Intellectual Property" *is* the new economy.

Mate: high 5 on wanting to help out. I'm a coder who doesn't contribute to existing projects (mostly due to time contraints and not for a lack of interest or desire) but releases the odd tool under a GPL or BSD license (or similar).

The lack of documentation in FLOSS aside (no flames please) you'd obviously be contributing to user documentation. I personally favour "complete" user documentation for a single system such as the FreeBSD Handbook (Gentoo and Debian have similar efforts). Of course even blogging HOWTOs may be useful to some one some day.

There are other ways to contribute. Hanging out on forums or IRC channels designed for helping end users in need is useful.

So, yes, Linux does have some catching up to do. ;-)

This is not even close to the same thing that is a BSD filesystem snapshot, but don't let interrupt your furious fanboy wankfest.

BSD snapshots are a lot like LVM snapshots (that have been available in Linux since 1998), except that under Linux, you are not limited to 20 snapshots.

What ext3cow does, which you would realize if you would have opened your ears before your mouth, give you true point in time recovery. In other words, without ever manually "taking a snapshot", like you'd have to under BSD, you can simply revert your filesystem to where it was at any arbitrary point in time. ("Oh crap, I need to revert to where we were at 8:52:12pm last Thursday!")

BSD, to my knowledge, does not support anything this advanced.

Yeah, the absurdly long kernel command lines in Linux really bug me. It's a symptom of the suckiness that is the PC BIOS, so I'm not really blaming the Linux people, but there are better solutions and have been for years. The FreeBSD loader, for instance, is capable of loading the kernel and any modules required to bootstrap the system, reading configuration files, and running Forth (!) scripts. Such a loader would completely eliminate the need for initrds on nearly all systems[1] without sacrificing any power. You could also emulate Openboot or EFI - or more realistically a subset of them - using the PC BIOS to prepare for the future.

[1] initrd is a really awesome feature and it shouldn't go away. But it's massive overkill the way it's typically used, which is to load modules required to mount the root filesystem.

Oh yeah.

Bill Gate's memo

That's an interesting email from 1999. Myself, I've been known to send emails to the tone of "how can we prevent the competition from leeching on our multi-million dollar R&D investment with our technology partners", but OK.

Would you like to point me to the follow up email from Eric Rudder that says "Hi Bill - As you requested, we've made the ACPI extensions specific to Windows so no one else can implement them. Cheers!" I can't seem to find it.

Oh, wait - here's ACPIfor Linux and ACPI for FreeBSD. Indeed, here's a quote from the WP entry:

The Advanced Configuration and Power Interface (ACPI) specification is an open industry standard first released in December 1996 developed by HP, Intel, Microsoft, Phoenix and Toshiba that defines common interfaces for hardware recognition, motherboard and device configuration and power management.

Now, ACPI has its shortcomings. It's complicated. It might not be your ideal of a standard. But it is an open standard, which Linux indeed implements. It might be broken in some ways in Linux as it is in Windows, but implemented it is. It's an important standard because it takes hardware out of the equation, which is important for a general OS that's supposed to support a wide range of it.

I still use APM for the most part

Really? That's also a Microsoft-defined standard (along with Intel):

Advanced Power Management (APM) is an API developed by Intel and Microsoft

Is that standard "shit" as well? And if you all these standards from Microsoft are "shit", then why do you use them at all? You use Linux, right? Why don't you come up with your own standard and give it to the free software world so they can stop using all these "shit" open standards that Microsoft has bothered to make open for anyone to use? Which reminds me, I'd love to see that other email about ACPI I mentioned. Thanks.

Linux Documentation Project ~ Rute User's Tutorial and Exposition ~ Linux Newbie Administration Guide ~ LinuxCommand.org ~ Linux From Scratch ~ FreeBSD Hypertext Man Pages for Red Hat 9

I thought it was Stallman getting locked out of the MIT computers

http://www.freebsd.org/cgi/man.cgi?query=su&apropo s=0&sektion=0&manpath=SuSE+Linux%2Fi386+6.0&format =html#end

Real linux users use BSD, http://www.lemis.com/grog/

http://www.freebsd.org/
http://www.apple.com/macosx/
http://www.openbsd.org/
http://www.netbsd.org/
http://www.dragonflybsd.org/

That condition is not a whim, is the only mechanism known to work to protect Free as in Speech in software. Free code as in the BSD and MIT licenses is how software was created at the beginning, and it quickly derived into an incompatible set of compiting closed, proprietary systems.

Yeah, it was awful. All the BSDs went away, and nobody used their code anymore.

Seriously, though, the BSD license has worked out well for many projects. I don't know who said this, but "the goal of the GPL is to make all software free; the goal of the BSD license is to make all software better."

http://www.freebsd.org/ calling... Seriously, I don't think that there will be a morality to oppose Stallman within the FOSS community for some time. He's appealed to a number of developers, but mainly to end users irritated at stuff like DRM (but don't kid yourself; most of these armchair advocates are running Flash and watching whirlycubes spin with the help of the nVidia driver, and using amaroK to sort their mp3 playlists. Their indignation begins and ends at what other people do). Notice also that he doesn't involve himself in the debate; proxies like Moglen, PJ, or Perens flush the game so he can sit there and go "Aw shucks, what's all the fuss about?" The open source movement died because, ultimately, pragmatism isn't a morality; it's expediency in the clothing of one. I appreciate the software from the kernel team, the FSF, and the multitude of others that I have on my machine, but I run it by their grace, not because I claim any kind of right or fundamental freedom to do so.

For FreeBSD, you may also use freebsd-update http://www.freebsd.org/cgi/man.cgi?query=freebsd-u pdate&sektion=8&manpath=FreeBSD+6.0-stable, which is very convenient... not only the "commercial Linux verdors" give you binary patches.

The article describes a technique which is in large very inefficient, and wasteful. It is analagous to the notion that a process must be completely copied on fork, however this is not true. Typically the pages used by a child process are copy-on-write, and are only duplicated as the child writes to them. To see the analogy, consider that the article describes this basic process:

(1) Create a new directory (the author creates something in /var).
(2) Unpack a brand new OpenBSD distro and source distro to this directory.
(3) chroot this directory as /
(4) Create a timestamp file using touch (the author calls this a "cookie").
(5) Unpack the modifications to the dummy system. Scripts which refer to absolute path names will work now.
(6) Create a timestamp file using touch.
(7) using find, collect all files that were modified during the time the first and second cookies were made into a tar ball.

This is analagous to copying an entire system, then working on the copy. Rather, why not using a unioning file system? Mount the file system as a unioning file system, thus when a write occurs on a file, it will actually not be modifying the system file system, but a dummy file system, mounted in /tmp or where ever. Once the patch is complete, collect all modified files (the file system will read from the dummy file system automatically) into a tarball as before. This technique has several advantages:

(1) You don't have to re-create the entire system (and upgrade it as necessary).
(2) The dummy file system typically runs in memory (which is very fast, and usually plenty large for a diff-like 'patch').
(3) It seems like a perfect fit for a unioning file system.

I am actually a fan of transactional file systems, but unionfs seems perfect for this. There is a BSD unionfs it seems here: http://people.freebsd.org/~daichi/unionfs/. Also, if you are in Linux, and you want copy-on-write for some reason, check this out: http://www.am-utils.org/project-unionfs.html.

I did my old FreeBSD systems yesterday. The procedure was as follows:

1) Fetch the new rules file. I got it from:
          http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/s rc/share/zoneinfo/northamerica?rev=1.31

2) Save it as /usr/src/share/zoneinfo/northamerica

3) In /usr/src/share/zoneinfo do a 'make install' - this compiles the rules into /usr/share/zoneinfo/.

4) Run tzsetup - this copies the proper file from /usr/share/zoneinfo/ to /etc/localtime.

5) Do a 'locate localtime' to see if you have any copies of /etc/localtime in chroot trees, e.g. /etc/bind/. If so, copy the new one there too.

If you have multiple identical systems you can do this on one and then copy the new /etc/localtime to the rest.

I know that nobody is going to read this a week later, but anyway...

The main reason for patches in FreeBSD ports is to remove Linux specifics, and to install things into the conventional FreeBSD locations (/usr/local etc.). Two ways of looking at this: 1) if the original author of the software had done things to be more portable, this wouldn't be needed. And 2) if you are doing it for Linux, most of it shouldn't be needed since it was developed for Linux in the first place. Have a look at the patches of most modern FreeBSD ports - there just won't be any. There will just be the port system wrappers: a generic Makefile (defining dependencies, probably offering a pretty interface to build options, and often causing the use of gmake), a pkg-descr, and a pkg-plist file. Sure there are lots that don't fit this mold, but they will generally be older apps or ones that are very Linux specific. To pick a (semi-)random example that I built the other day: try gaim-devel (gaim 2.0.0b6).

Who gives a fuck?
http://www.freebsd.org/

It is a bit annoying that there's no change log, although in fairness there are a surprising number of changes in the average revision.
A bit of googling gives us http://cvsup.pt.freebsd.org/cgi-bin/cvsweb/cvsweb. cgi/src/share/zoneinfo/northamerica - yes, 2006g has the 2007 US changes.

Apple right now is, for all intents and purposes, a minority player in the computer arena. The popularity of the iPod plus the feature set of OS X is attracting customers to the Mac product line, but Apple isn't a threat, yet. However, that doesn't mean their isn't room for concern. Apple's latest OS is built on the free, open source FreeBSD user land. Their web browser's rendering engine is based on KHTML, an open source toolkit developed in Konqueror. But Apple hasn't given much back to the community. Even what they are required by law to give back (enhancements to KHTML) has been done in large dumps rather than providing useful contribution to the Konqueror development team.

Why does any of this matter? It matters because it illustrates Apple's intent. Apple, just like MS, doesn't want to play nice, support open software or even standards. Apple sells DRM'd media on a closed platform that can only be played with Apple software and devices (iPod).

But the Catch 22 is, do you support them? Recently I've been encouraging friends and family to move to the Mac, and for now I still think it's a good idea. Why? Because Microsoft is still the number one bad guy and platform diversity will take away power from them. I think we should all be mindful of Apple's practices but their own arrogance will never allow them to be so dominant that they will be a threat. For instance, Apple demands that you use their platform to run their media and their OS. When new device X comes out that's more popular than the iPod, it will force Apple to support the device for have iTunes become irrelevant. Apple's choice not to allow their OS to be run on commodity hardware will hinder them from market dominance. I've long believed that the illusion of choice is part of what helped MS become a monopoly. People when their buying computers think, "should i get an HP, a Dell or an IBM?" When really all their getting is a Windows box.

Additionally, the shift away from traditional computing to the internet will also hinder Apple from being the next MS or Big Blue. Personally, I'm more worried about Google than Apple

okay, i did it. now what?

I know I am being redundant but, for all intents and purposes, Linux is a UNIX clone. I also know that my previous statement is an oversimplification but Linux and UNIX behave similarly with similar commands. In some cases, software is fairly portable between the two. Also what about the BSDs? I'd argue that they are actually closer to their UNIX ancestors. Look at Explaining FreeBSD for an excellent comparison and history.

• mOnOwall - firewalling
• IPCop - firewalling
• Metadot - CMS
• Apache - web server
• Bind - Name Server
• asterisk - telephony/voip
• Sendmail - cussed but stable MTA
• SpamAssassin - spam filtering
• MIME-Defang - email content filtering/manipulation
• ClamAV - Virus filtering
• Freebsd - the best OS since sliced bread (IMHO)
• Centos - Not to shabby an OS either
• ...

Well, just another reason to switch to FreeBSD then, which tastes great:
"35% of the volunteers said that FreeBSD tasted sort of orange, whereas Linux tasted like purple haze."
http://www.freebsd.org/doc/en_US.ISO8859-1/books/f aq/funnies.html#VERY-VERY-COOL

It's called FreeBSD or you can use PC BSD.

Plus they're free, unlike Windows or OSX.

"It sounds like, by eliminating block devices, that they basically remove the kernel from doing any re-ordering or caching of data, which makes things "safer""

No; FreeBSD's shifted the buffer cache away from individual devices and into the filesystem/VM, where it caches vnodes rather than raw data blocks. The IO queue (below all this block/character/GEOM stuff) is scheduled using a standard elevator algorithm called C-LOOK. It's showing it's age in places, and there's been some effort towards replacing/improving it, making it pluggable etc (e.g. Hybrid); sadly it's a tricky problem to solve properly. See this recent thread.

"It sounds like, by eliminating block devices, that they basically remove the kernel from doing any re-ordering or caching of data, which makes things "safer""

No; FreeBSD's shifted the buffer cache away from individual devices and into the filesystem/VM, where it caches vnodes rather than raw data blocks. The IO queue (below all this block/character/GEOM stuff) is scheduled using a standard elevator algorithm called C-LOOK. It's showing it's age in places, and there's been some effort towards replacing/improving it, making it pluggable etc (e.g. Hybrid); sadly it's a tricky problem to solve properly. See this recent thread.

Does BSD handle I/O differently in some fundamental fashion than Linux? It sounds like, by eliminating block devices, that they basically remove the kernel from doing any re-ordering or caching of data, which makes things "safer" (in the event of a crash) but seems like it would have big performance penalties

Good question.

The FreeBSD people claim that no one is using block devices anyway (source):

no serious applications rely on block devices, and in fact, almost all applications which access disks directly take great pains to specify that character (or "raw") devices should always be used. Because the implementation of the aliasing of each disk (partition) to two devices with different semantics significantly complicated the relevant kernel code FreeBSD dropped support for cached disk devices as part of the modernization of the disk I/O infrastructure.

So does Oracle not rely on the block layer they pay Axboe to maintain? Or did FreeBSD's block layer implementation simply suck so badly that no one was using it? I'm using FreeBSD btw, and I don't really notice much of a difference to Linux wrt disk i/o (but I don't run busy databases).

I'd like to get a satisfying answer from a disk i/o guru as well please :-)

You can find a solution(s) to your problem at one or more
of the following locations:

http://www.centos.org

http://fedoraproject.org/wiki/

http://en.opensuse.org

http://www.opensolaris.org/

http://www.ecomstation.com/

http://www.redhat.com

http://www.reactos.org/en/index.html

http://www.debian.org/ports/hurd/

http://www.openbsd.org/

http://www.freebsd.org/

http://www.netbsd.org/

http://www.dragonflybsd.org/

http://www.osfree.org/doku/en:start

http://www.skyos.org/

http://www.freeos.com/

http://www.minix3.org/

Added to bypass the stupid slashdot lameness filter which apparently doesn't like a post full of links. WTF is wrong with the
stupid lameness filter? Jeez, what does it want, for us to type paragraphs of meaningless drivel just to get past the lameness filter?
Sheeesh. OK, this is really stupid. Why don't ajfajf al;djal a fa fa lkdf jaa fal ja;ljf af af ajf;lajf alfjalf a fjal;fjafl; jaflakjf af;laj
jalkfaj fjf af af fajjjajal jajfa f afjdlakej2233 2235t2352 dsfalkfjal f 222j2 afdkja f23 2 2 2t2352322 233252352 2323232.