Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
BSD Operating Systems

Migrating from Linux to FreeBSD 81

Posted by timothy from the two-nice-destinations dept.
Eugenia writes: "OSNews published a guide that could help users migrate from Linux to FreeBSD by spotting the main differences between the two popular systems. Interesting read & relevant to the recent FreeBSD 4.5 release a few days ago."
This discussion has been archived. No new comments can be posted.

Migrating from Linux to FreeBSD More

Migrating from Linux to FreeBSD

Comments Filter:

  • FreeBSD Has Some Merits (Score:2, Insightful)

    by trg83 ( 555416 )
    Unlike certain Linux distributions, the FreeBSD package system seems to work great, even on packages that are on an FTP site somewhere else.

    • Re:FreeBSD Has Some Merits (Score:1, Insightful)

      by Anonymous Coward
      Like some, not all.

      If I developed a FreeBSD distribution that sucked, would you like it (FreeBSD) any less than you do now?
      • Well, let's pick one. Package maintenance with Mandrake using Software Update, or whatever their buzzword is, blows. I have had no success applying any upgrades to Mandrake completely over an FTP connection. FreeBSD doesn't install nearly so much software in a default installation, but the default features are useful rather than bloatware.
    • Some of the small but annoying problems I've been bitten with is whenever I'm running a slightly older version of FreeBSD and the ports system wants to go grab a version of a particular package that isn't on the FTP site anymore, because there's a newer version that's come out in the meantime.

      What's that, you say? Just CVSup the ports collection and everything will be OK? What if I / the customer needs it working NOW and don't really have time to CVSup or even manually drop in the particular port and all the new dependencies I need for that port to compile? Well, I could have the source handy and compile it from scratch, and I'm certainly not afraid of doing that, but then I've got a system that's part ports-maintained and part manually maintained, so until I have time to go back and make it right, anyone else who comes along will not be in the loop as to what's where, and why.

      What's the point of using automated tools when one has to do so many backflips to get around then when they're trying to be Smarter or More Correct than the situation dictates?

      And I haven't even touched on upgrading the complete OS. I am aware of _no way_ to do a complete system upgrade under any of the Free/Net/Open BSDs without visiting the box and taking it down to single user mode to "make world" the whole thing.
      (If I am wrong or out of date about this, I will humbly accept correction.)

      Now, as someone who's been on the Net since 1992 and has been playing with UNIX for about that long, I respect the whole "life is better when you compile from source on your own box" philosophy. You don't have to worry about the guy who built a binary package being a maniac or using bleeding edge versions of libraries or other utilities Just Because, etc. On the other hand, kernel compiles back then were more like kernel LINKS because your vendor didn't give you much access to the source code, so you'd recompile mainly to change something now considered silly like number of simultaneous VTYs or other system-wide settings that everyone now is used to with either sysctls or some other mechanism. But as far as system upgrades go, instead of wandering into the server room at my theoretical company on a Friday afternoon, reminding everyone within earshot on my way there that I had sent out a systemwide memo a week ago saying I was going to be upgrading the system today, walking over to the server, starting the download, bringing down the box, et al (thereby putting out the few hundred people who rely on the box but should have scheduled their day around its downtime anyway), I'm pissing off thousands of users at my theoretical ISP who access the box 24/7 and affecting thousands of other users who are attempting to surf to my customer's web sites, send them mail, etc.

      Now, take the same situation with, say, Debian or RedHat. I want to upgrade a package? apt-get or rpm it. That particular program will be down for precisely the amount of time it takes the package manager to replace the appropriate files, which would be a minute or two, TOPS. Want to make my own modifications but still have the package be touchable/upgradeable by the package management system (AKA "The Best of Both Worlds"?) In Debian, it's apt-get source "package name"...I know RedHat has source RPMS but I've forgotten the procedure for RPMing them right now. :) Compile the package with modifications, install as above. Same amount of downtime.
      Kernel upgrade? Either do it thru the particular package manager or get the source yourself, compile while the box is running, install, notify users the box will be back in less than five minutes, and you've bought yourself time to reboot the box onto the new kernel and even to regress back to the old kernel if you need to.

      Now, I completely understand that there have been stability issues (cough) in the more recent Linux kernels that the BSDs do not have. Without getting into the whole chicken/egg thing of "well, don't upgrade the minute a new kernel comes out!" and "but how are we supposed to KNOW if there are any more bugs if people DON'T upgrade?" But a little user education solves this. For example, several of my boxes are on 2.2.19, and they've been running fine for many moons now. I'm anxious to move up to 2.4, and in some cases have, but IMHO we're beginning to get to the point (at least on the server end) where there aren't too many new features going in that people NEED. Not that they're not useful, but we got along just fine without them. Pre-emptable kernels, kernelspace SMP (as opposed to just userspace) and n(0) schedulers are nice, but I wasn't lusting after them in 2.2. So just following the discussion lists will clue you in if, in general, the new kernels are right for you.

      And I will go on record as saying that I WANT a Debian BSD so I can have the same admin tools I have grown to love but I have the oppotunity to play with the BSD kernels without having to put up with all the other differences moving to a BSD distro would make me live with.

      I don't knock people who choose to use ANY operating system, unless they made their choices based on FUD or other stupidity. But if someone who could use any (or a least a wide choice of) OS he wants to has chosen a particular one, chances are good he has his own valid reasons and trying to convert him away "because the other one is better" is specious at best. The best OS for someone is one that does what the user wants it to, at the speed the user wants it to, at the price the user can afford.
      • You write a lot but don't seem to be well informed on FreeBSD:

        If you can fetch the package from an FTP server, you can also cvsup to make sure your ports tree is up-to-date (it just takes a few minutes). The ports tree doesn't need to be very up-to-date b.t.w., since tar-balls that vanished from the sites are kept for a long time on ftp.freebsd.org, which is used as a fall-back. If you don't want to bother with net-access, then just install packages (the binary form of a port) and use the ports that are delivered on CD-ROM with an official FreeBSD set.

        make world (I've been doing it regularly for years) has never taking down your box during the process. It uses 2 steps by the way, which you can execute separate if you wish: make buildworld builds everything (in /usr/obj), then make installworld to copy /usr/obj to the system itself, which is a quick process. Even during this step your system remains up and running. A reboot is advisable afterwards but not absolutely necessary (running processes shall still use the old libraries of course).

        Upgrading a Linux box (which often comes down to a reinstall) takes much much more time. Upgrading FreeBSD is a routine operation which takes only 1-2 minutes of operator intervention, then takes some hours to complete (compiling) during which your box keeps running. No physical accesss is needed (it remains in multi-user mode and this has always been the case).

        You can say much about cons and pros about FreeBSD w.r.t. Linux, but there is absolutely no doubt possible on which one has the superior package management (ports) and system-update system, ease of system administration etc.

        At home I run my "production server" on FreeBSD because really, I'm too lazy for Linux.

        For those times that I'm not lazy and want to try some neat cool new stuff, I run Linux, Slackware of course. Because if/when I'm not lazy, I want to do everything myself and only deal with the source. I hate being bitten by incompatible packages, vague conflicts between unknown shared libraries etc. The only way to avoid is to recompile from source, and use statically linked software if no source is available (such as commercial software like Opera).
      • I am aware of _no way_ to do a complete system upgrade under any of the Free/Net/Open BSDs without visiting the box and taking it down to single user mode to "make world" the whole thing.

        No single-user mode necessary:

        # cvsup cvsupfile.src
        # cd /usr/src
        # make buildworld
        # make buildkernel
        # make installkernel
        # make installworld
        # mergemaster
        # reboot

        Now, take the same situation with, say, Debian or RedHat. I want to upgrade a package? apt-get or rpm it. That particular program will be down for precisely the amount of time it takes the package manager to replace the appropriate files, which would be a minute or two, TOPS.

        # pkg_add -r packagename

        or, better yet,

        # pkg_add -r portupgrade
        # pkg_update packagename

        ...which will handle all dependencies as well. Portupgrade is an awesome package!

        HTH.

  • Bad article -- frankly not worth the /. link (Score:4, Informative)

    by Anonymous Coward on Thursday January 31, 2002 @05:50PM (#2933783)
    The article spends waaaay to much time talking about the licensing differences. When we want to migrate from one OS to another, reading the licesnsing is probably near the bottom of our lists. We want to know what the OS does, and if it'll perform well in our situation.

    No mention of the different CPU types that BSD runs on, how many drivers are available (just that the authors look down their noses at the "flashy new features" that new hardware offers, migrating user accounts, does CRON or anything have to be dealt with, etc. A little bit of information on the different directory structure.

    His main bitch seems to be that the default install of FreeBSD is small, and the default install of SuSE isn't.

    This thing reads like it was written by a C.S. major for a 200 level English course. /. is not the intended audience.

  • License Differences (Score:3, Informative)

    by ulmanms ( 106454 ) on Thursday January 31, 2002 @09:38PM (#2935046)

    ...the GPL requires any changes to the source code to be made public and be licensed under the GPL...

    Small things like this are what contribute to the FUD about the GPL. Say it with me - you only have to release your changes if you distribute them. It's these misinterpretations that allow MSFT to claim that using Linux will 'infect' your company.

    For reference, it's here [gnu.org] in the GPL.

    • And if you don't distribute the software you created or modified how would you make money off of that software? That is the virus type nature of the GPL that Microsoft speaks to.
      • Not every company is in the business of selling computer software. The market would be rather overcrowded if that were the case.
        • But it's those companies that are in the business of selling computer software that are leery of the GPL. Your banks, grocers and auto manufacturers could care less.
      • Tivo and Akamai are two great examples of making money while living with in the GPL. They both sell a service, while using GPL software to power their services. In the case of Tivo, they do release some kernel patches and whatnot, but everything else is closed-source. Akamai has made a lot of changes to the Linux kernel to speed up the TCP code, but since they're not distributing the kernel, there's no need for them to distribute the source code.
      • Inhouse software is great for development. Can you say "compiler backends"?

        I've been hired by companies which are typically closed source companies, but still have used GPL'd stuff inhouse for development. And most of the time, the inhouse developers are good persons, and distribute the changes back to the community, eventhough they are not obligated. Pretty much BSD spirit.

  • few things left out (Score:5, Informative)

    by Partisan01 ( 547933 ) on Friday February 01, 2002 @03:21AM (#2936064) Homepage
    I think a couple points need to be made. I'm a avid linux user, OpenBSD user and FreeBSD user. I also have a win98 box laying around. But I think when migrating to BSD most linux users don't realize that the GNU utils arn't there anymore. This is a big thing, same with the bash shell. Another point to be made is that for webserving FreeBSD is about as fast as you can get. If you want high loads and need to serve up lots of info FreeBSD is the answer.


    Nate Tobik
    • Uhrm, you can just install Bash by going to /usr/ports/shells/bash and make install. Same goes for most other utilities.

    • Re:few things left out (Score:3, Informative)

      by Metrol ( 147060 )
      But I think when migrating to BSD most linux users don't realize that the GNU utils arn't there anymore.

      Ahh, you mean like this tiny sampling [freebsd.org] of GNU applications?

      This is a big thing, same with the bash shell.

      Are you referring to, like, bash [freebsd.org]?? Perhaps you didn't know how to properly install it [mostgraveconcern.com]?

      You say you've actually used FreeBSD???

      • You're talking about ports, while the author was talking about the core OS. AFAIK there is some GNU in the core OS, but most GNU code running in FreeBSD is installed from ports.

        My $0.02 (Canadian)

        Steve
        • bash isn't in the "core" OS of Linux either. All but one Linux distro has allowed me to deselect it. Now getting rid of fileutils and binutils may be rather difficult, but most of the GNU stuff is entirely optional.
          • NOTE: I use netBSD, but the packages system is based off of the freebsd ports system.

            (taken from the DESCR file from /usr/pkgsrc/sysutils/sh-utils)

            These are the GNU shell utilities. Most of these programs have significant advantages over their Unix counterparts, such as greater speed, additional options, and fewera rbitrary limits.

        • Re:few things left out (Score:3, Insightful)

          by Metrol ( 147060 )
          You're talking about ports, while the author was talking about the core OS.

          Of course I'm talking about the port installs. The reason I replied was that the original post had a VERY misleading statement about bash and GNU utilities being unavailable in FreeBSD. It would be way too easy to assume you couldn't even get these things to run had they no experience with FreeBSD.

          If core OS means that you can install these things initially when you install the OS, then FreeBSD does that as well! Just like a Linux distro install you can select packages to be added along with the rest of the OS.

          As a Linux distro is really not much more than the kernel and selected packages I could just as easily state that GNU utilities aren't a "part" of any of those either. Certainly they aren't a part of Linux, as Linux only includes a kernel if we wanted to get all kinds of nit picky.

  • Get ready to be a cheerleader or maybe jeerleader (Score:4, Interesting)

    by teambpsi ( 307527 ) on Friday February 01, 2002 @11:02AM (#2937146) Homepage
    First up, I'm not a purist -- not by any stretch of the imagination -- i tend to migrate to a "best fit solution"

    I develop FreeBSD based embedded server apps for clients -- but until recently I had to use Linux in order to get support for my commercialware programmers editor (slickedit) -- took over two years of sending "nastygrams" or rather good natured pokes to get them to make an honest port instead of trying to get it work under the emulator.

    Oracle would be great on freebsd, but that seems unlikely for awhile.

    Coldfusion would be awesome on freebsd -- but considering Macromedias arcane licensing policy even when it comes to the Solaris version (jeezus I spent less money on my SparcEngine ATX motherboard then I did on my last Intel supermonster -- do they care? no they think their server is worth $5000 for the privilege to run on sparc -vs- the reasonable windows/linux server pricing they have)

    The fact is, unless you can live with all the portable "free" stuff, get used to either being a cheerleader or a jeerleader when dealing with commercialware vendors.

    Yeah, like its that friggn difficult for them to recompile on freebsd ;)
    • Yeah, like its that friggn difficult for them to recompile on freebsd ;)

      Recompiling is a snap. Any commercial Unix program can be ported to FreeBSD in about a day. The developers at these companies know this. But that not the roadblock. The management at these companies don't want to support another platform. Simple. They don't want to write another help script for the techsupport crew. They'll have to invest in people who know FreeBSD inside and out so that when a customer calls with a tough support question they can handle it.
      • this is the exact sort of thing that was the argument against linux early on

        and the sort of thing that you could either "download without support" at a reduced price etc

        but seriously, for most application level issues, the fundamental differences between the two is almost non-existent.

        if anything it gets their developers to write autoconf scripts, and helps to reduce the number of things that are "taken for granted"
    • "Yeah, like its that friggn difficult for them to recompile on freebsd ;)"

      Well, the recompiling might not be difficult. ;-) You have to remember that not all commercial code is as "clean" as many open-source projects are, mainly because they simply don't target anywhere near the number of platforms. I can't think of any commercial products of the top of my head (Oracle maybe?), but I do know *MANY* of them include enhancements (read: hacks) to get them to run on different platforms, like Linux, or Solaris. Sure, they're all UNIX, so to speak, but there remains differences between the two, and it is those differences that commercial vendors are worried about; it's never just a simple recompile, though it would be nice. And the cost of doing a port The Right Way is prohibitive, especially for more "exotic" operating systems like FreeBSD. From a commercial point of view, Linux is growing at a faster pace than FreeBSD, and *THAT'S* what companies care about. We aren't in the dot-com mode of spending anymore; money has to be allocated towards those areas where companies will make the most money, because that is their job. Sorry for the rant . . . this just hit upon something I've been thinking of lately. :-)
  • For the first time that I can remember somebody acrtually god the meaning of the acronym correct: Berkeley Software Distribution. Who told the secret?
  • The article has been written with good intentions. As a sys admin/developer, I am personally more concerned about the immediate job, i.e. the issue of migration. It would be helpful to have a precise/specific checklist of things to worry about DURING the migration. Following which, a relative comparison (tabular, fairly specific) would be very helpful.

    This is what I am talking about:

    Unix Guide [addr.com]

    Hopefully this should help others.
    Best Wishes!!

Slashdot Top Deals

"It's the best thing since professional golfers on 'ludes." -- Rick Obidiah

Close