Damien:
> You make some good points. However, compiling from source is not always
> possible. I don't think anyone will find it easy to setup a workstation
> from source. Compiling X, Gnome and what ever else one might need is
> crazy. Sure one might learn something but at some point I need to get
> work done. I only mention this because I've tried.
Compiling all that can be time consuming, and certainly not something you
want to do every time. However, with Nevaeh, the package management creates
a package manifest after install. So, you can compile once on your target
architecture, then use the manifest to create a binary tarball to
distribute to all the extra machines. Not far from what Gentoo does with
their binary install option.
That doesn't help you for that first workstation install, but, hey, that's
not what I made it for. I'm just as comfortable with a dumb terminal on a
serial tty. Nevaeh is primarily intended for servers.
> We could all run LFS.
>
> As a business owner and network/system engineer I have to evaluate
> everything I do. Lets use my current clients as an example.
>
> 1. New server
> 2. about 2 tarabytes of data at the moment
> 3. Website, data storage, email are all on this server
>
> Lets say I decided to use Slackware. It's stable and secure so why not.
> What happens if Patrick Volkerding ( the Slackware founder ) decides not
> to do Slackware any more. Or worse he dies. It almost happened. He got
> sick from brushing his teeth a few years back. It almost killed him.
> Back then he was the only guy maintaining Slackware. Lets say for
> argument sake there is no more Slackware. What do I do?
>
> 1. I've got an OS that can't be updated
> 1. No security patches
> 2. No upgrading to a new version
Damien, even when I ran Slack (years ago) this was still false. Slack has
always had a spotty record with timely security updates, so many admins
treat Slack just like a source-based system. Easy to do since on Slack's
FTP servers they have all the package build scripts. Update the rev in the
script, build a new package, and distribute as needed.
The only time this will cause a problem are for *some* major rev upgrades of
packages that dramatically increased their dependency list and complexity.
For most servers this isn't an issue from a maintenance perspective. And if
the Slack maintainers leap-frog you this typically doesn't prevent you from
going back to their packages, either.
> 2. I've got 2 tarabytes of data that need to go somewhere
> 1. Maybe I don't want the data on the server because it can't
> be updated (security)
> 2. Maybe the client doesn't want his/her data on the server
> because it can't be updated
As mentioned above, you're tossing out a red herring. These are bogus
arguments for any competent admin.
> 3. Who pays for the cost of the reinstall and data transfer
> 1. I was the one who recommended the Slackware OS
> 2. Who pays for the down time the business will experience
> while the server is down
Once again, this is just silly. You know, I've had to work on client
systems running RH EL whatever, and they *couldn't* upgrade because some
commercial package wasn't support on anything else. But we still needed
another package to be newer than what RH would publish for that distro rev.
What do you do? From that point on you become your own package maintainer
or become a source-based distribution for those packages. Working from
source should be second nature for any real UNIX admin.
As for 3.2., any consultant worth his salt should be able to figure out how
to manage that with minimal (read: minutes) downtime. That's a trivial
exercise.
> In this little scenario Linux didn't go away but Slackware did.
I fail to see the problem.
> Lets say I decide to compile all my applications from source to keep
> them updated. That will work for a while. However, the libraries in
> Slack will become old. At some point I will no longer be able to use
> them. One of my applications will look for a new library and I will be
> SOL. I could try and update the Libraries but then I'm maintaining my
> own distribution. I don't want to do that.
You sound like a Windows guy. That's the whole point of the open source
world -- you're not held hostage when one person/org/distro goes away. You
do have an option to keep yourself current and safe. If you're not willing
to use that option if it happens, then what's the point of using Linux? Why
not use Solaris? These days it's about as cheap, runs most of the same
software, and you're still dependent on one org for your updates. For that
matter, Sun probably has a much more viable and forecastable future than
Ubuntu...
> I should have used Novell for the above scenario. Think of all the
> servers out there running SUSE. What will they do when Novell is gone.
And Ubuntu will be gone at some point, too. Nothing you've mentioned to
date makes any sense as to why you would pick Slackware, Ubuntu, or Nevaeh
over any other. Support & updates are irrelevant when *all* of them are 99%
collections of pure open source from *third* parties.
> The above is the business side of me. The geek in me wants to compile.
> Maybe it's time I do LFS.
I highly recommend LFS as an educational project. It still has some fluff
in it, but it gives you a very good idea of just what a minimal Linux is: a
kernel and a small collection of utilities.
And maybe, perhaps, it will give you the skills and knowledge to start your
own distribution that makes sense to *you*, instead of having to live with
or compensate for the stupid design decisions of your distro of choice. Can
you honestly say you like *everything* about Ubuntu?
> Oh, hope those Slackware packages are working out for you. I could be
> wrong but aren't those just tar files? Also RTFM before you upgrade to a
> new version. You have to do it the "Slackware way". I guess they didn't
> like the "standard" method of upgrading Linux. If you do it wrong you
> could end up with a broken system. ;-)
Slackware packages are a tarball that contains binary files and an
installation script. As to RTFM, when wouldn't you? When you start
tinkering with critical packages like glibc, module-init, kernel, etc.,
you'd best know what you're doing. If you're trusting any distro to
completely idiot-proof something, you're asking for trouble. At one point
or another, they've all failed. And at some point, we've all done something
idiot-worthy.
And, BTW, what's the "standard" method of upgrading Linux?! RPMs? Debs?
Slack's the oldest surviving distro out there, it all started with tarballs
and cpio archives.
Discussions like this make one thing very clear: we're not educating admins
in the Linux community like we should. If anyone here really wants to
understand the nuts and bolts of *all* the distros, here's a self-study
track to try:
1) Install and run Slack for some basic Internet services: it's not
as bare metal as Nevaeh, but it'll definitely teach you more about
what's really happening on your box
2) Read /etc/inittab and Slack's /etc/init.d/rc.* scripts to see
what happens as the system is bootstrapped and run. Then, for more
entertainment, try reading the equivalent on a standard SysV-styled
distro.
3) Walk through building LFS and read *all* the documentation. It'll
give a lot more detail on the minimum requirements for a working
networked OS, and some rationale for certain configuration options.
And never, ever use Nevaeh Linux. You know the UNIX saying about UNIX being
user-friendly, just really picky about who its friends are? Nevaeh is the
manifestation of that phrase. It makes me look like a warm & fuzzy
free-lovin' hippy humanitarian extrovert in comparison.
And yet, it makes me all tingly inside. ;-> But don't use it. Ever.
--Arthur Corliss
Bolverk's Lair -- http://arthur.corlissfamily.org/
Digital Mages -- http://www.digitalmages.com/
"Live Free or Die, the Only Way to Live" -- NH State Motto
---------
To unsubscribe, send email to <aklug-request@aklug.org>
with 'unsubscribe' in the message body.
Received on Sat Dec 30 23:20:36 2006
This archive was generated by hypermail 2.1.8 : Sat Dec 30 2006 - 23:20:36 AKST