Which is the best distro for a workstation
Posted 09 March 2003 - 04:55 PM
Or people that THINK they know whta is going on...
Try KNOPPIX first... From CD... If you REALLY like it...
do a "knx-hdinstall" and go from there.
It will install a fully capable Linux install and make it so everything works (cept maybe networking, you may have to re-configure it...)
Other than that use have to select a task from Debian with "base-config"
You then have to learn the "apt-get" commands and how to use them.
Posted 10 March 2003 - 06:50 AM
It is all about the Quality Control...
3.0r1 is Woody, also known as "STABLE"... which it is except for Bug-fixes and Security updates... nothing get's extended.
Next version is Sarge a.k.a. "TESTING" is very good... but it does break from time to time... rarely to the point where you cannot get things done... this will be the next "STABLE". I compare the stability of Testing to current Redhat and current Mandrake... they are comparable to this revision of Debian.
After that we get to UNSTABLE or Sid... it is definately UNSTABLE... Bleeding edge... really close to what you could term developmental...
Then we get to Experimental... OUCH... It is just that... as close to bleeding edge as you can be... except for it does not have a 2.5.x kernel.
Everything you want to do is available in Debian Package and source archives... TONS (~11,000 packages) are available... all there for the piking!
Posted 11 March 2003 - 09:46 PM
Posted 12 March 2003 - 02:59 AM
Id on't get what you are talking about... I have as much control and speed as I can get...
If you want you can rebuild your system nightly from source with debian... Stable is Just that STABLE.
knight:~# apt-build info apt-build 0.8 Usage: apt-build [options] [command] <package> apt-build is a simple command line interface for downloading, building and installing packages. Commands: update - Retrieve new lists of packages upgrade - Perform an upgrade install - Build and install new packages (pkg is libc6 not libc6.deb) source - Download and extract source in build directory remove - Remove packages clean-build - Erase downloaded archive and built files update-repository - Update repository world - Rebuild and reinstall packages on your system info - Info on a package building Options: --reinstall - Build and install an already installed package --rebuild - Rebuild program --remove-builddep - Remove build-dependencies installed by apt-build --no-wrapper - Do not use gcc/g++ wrapper --purge - Use purge instead of remove --build-command <comand> - Use this command to build package --patch <file> - Apply this patch before build --patch-strip | -p <number> - Prefix to strip on patch (0 = -p0, 1 = -p1...) --yes | -y - Assume yes --version | -v - Show version --no-source - Do not download source (assume source are already extracted in build dir) --build-only - Do not install builddep and <package> --build-dir - Specify build dir --repository-dir - Specify the repository dir knight:~#
You can see mastering Debian is not what you think it is... Lets look at a specific Package like Postgresql 7.2.3
knight:/var/cache/apt/archives/postgresql-7.2.1/debian# ls README.Debian libecpg3.shlibs pgaccess.1 postgresql-dump.in README.Debian.backups libpgperl.dirs pgaccess.README postgresql-guide README.Debian.bugs libpgperl.files pgaccess.copyright postgresql-pl.postinst README.Debian.migration libpgsql2.dirs pgaccess.dirs postgresql-startup.in README.ecpg libpgsql2.files pgaccess.fonts postgresql-test.dirs README.odbc libpgsql2.postinst pgaccess.menu postgresql-test.postinst README.passwords libpgsql2.preinst.in pgaccess.postinst postgresql-test.postrm README.postgresql.conf libpgsql2.prerm.in pgaccess.prerm postgresql-test.substvars README.security.WARNING libpgsql2.shlibs pgaccess.tcl postgresql.conf README.test libpgtcl.dirs pgaccess.xpm.uu postgresql.conf.5 alpha-fixes.dpatch libpgtcl.files postgres_mac.sql postgresql.env changelog libpgtcl.overrides postgresql-6.5.3.tar.gz.md5 postgresql.init conffiles libpgtcl.postinst postgresql-client.conffiles postgresql.logrotate control libpgtcl.shlibs postgresql-client.dirs postgresql.overrides copyright libpq.README postgresql-client.files postgresql.xpm.uu copyright.PyGreSQL logcheck.ignore postgresql-client.menu postinst cron.d logcheck.violations.ignore postgresql-client.postinst postinst.in dirs make_pg_version postgresql-client.preinst.in postmaster.conf do.maintenance odbc-postgresql.dirs postgresql-client.prerm.in postmaster.conf.5 dwww-index odbc-postgresql.files postgresql-contrib.dirs postrm enable_lang.in odbc-postgresql.overrides postgresql-contrib.overrides preinst.in extra.includes odbc-postgresql.postinst postgresql-dev.README prerm.in findoidjoins.1 odbc-postgresql.prerm postgresql-dev.dirs prerm.inc fix.access.inc odbc-postgresql.shlibs postgresql-dev.files python-pygresql.dirs genscript.sed odbc.copyright postgresql-dev.overrides readpgenv genscript.warning odbc.ini.template postgresql-dev.postinst rules get_old_bins.inc odbcinst.ini.template postgresql-dev.prerm save_db_schema indexpage.html password.cnf postgresql-doc.dirs shlibs.local libecpg3.dirs pg_dumpall postgresql-doc.postinst unixodbc.HOWTO libecpg3.files pg_dumpall7.1 postgresql-doc.preinst watch libecpg3.postinst pg_wrapper.1 postgresql-doc.prerm libecpg3.prerm pg_wrapper.c postgresql-dump.8
If we take a look we can see alot of files looking like they rely on special conditions. If a particular piece isn't there (for instance you run GNOME and only used Quanta for example) you will have to have the Qt support stuff for the KDE stuf (DCOP and such) before it'll even build Quanta... but the only parts there... wiil be built. Of course if you later decide to install KDE, you'll have to re-build that package again ti get the full KDE environment support there... BTW, you'll get few packages out of this build... postgresql-[ client | contrib | server(which is just postgreql) | test | docs | odbc | dev ] allowing you to not have to install the whole kit-n-kaboodle...
It's all kinda... automagically done for you. You have to understand that the pre-built binary packages are designed to work in many, many different situations, platforms and environments... Debian's policy is to support as many platforms as possible... it why it sometime feels "slow" in development... but STABLE is just that STABLE... now Unstable or unstable/experimental you WILL regularly Break your system as someitme depenanciess will be totally screwed... but that's why it's UNSTABLE/Experimental. Sid (unstable) is pretty good, doesn't have problem for to long after they are introduced... so it's ok. if you can deal with it... I also have alternate GNOME support in other window managers I have on the system...
Now, as for the patching system... it is awesome, automated and very easy to accomplish... especially for the Kernel... you just make sure you install the proper packages for building the Kernel, install the patches... when you run the make-kpkg command properly with the exported variable "PATCH_THE_SOURCE" = yes... it will... and you get your customized kernel and all...
Now I hope this just isn't too much for now... additional questions followed up on...
BTW out of the gate, Woody supported 10 hardware platforms plus Beowulf clusters in Linux... see Debian Ports. There are also Debian projects of NetBSD and FreeBSD... as well as i386-Hurd and one unreleased (in Alpha/Beta) for the Hitachi SuperH Processor...
Oh yeah... one last thing... if you can Boot a Debian Machine *AND* you can get it to see the network or CDROM... you can re-deploy that Debian machine and literally *NEVER* have to re-install it ever. And it will clean-up behind itself VERY well...
Posted 12 March 2003 - 06:07 PM
As I said, Debian is a very nice distro, however it can be slow to get new releases of *anything* and is *not* as customizable when compiling packages (you can compile from source just like any other distro if you wish, just count on using an older compiler in Debian) for your installation. In addition, using Gentoo you can upgrade your installation and never have to reinstall it (like many un-named RPM-based distros). Several people I have spoken to at #gentoo have their current installs still running from an old 1.2 installation that they have upgraded to 1.4rc3 (current) without having to format or anything like that.
Originally, I had planned on using Gentoo for workstations, and Debian/BSD for servers since they *are* older and a little more seasoned. But, I haven't had any issues with my mail/web/file server based on Gentoo 1.4 since I set it up (only 4 months ago or so), and I will probably just keep that for now. It is very stable, and is easily upgraded whenever necessary.
You will find that Gentoo users comprise mainly of 4 groups:
1. Former Debian Users: These are people (like myself) that really liked using Debian, but grew tired of waiting for packages that were constantly in "testing" and watching the "TESTING" branch of Debian even become grossly out of date.
2. Former BSD Users: These people probably still run BSD as servers, but switched to Gentoo for better application support and the ability to run newer apps.
3. Slack/LFS Users: These people just like using Portage as the package manager and find it much easier to get and install packages without dependency issues using it than the traditional way of having to hunt down all the different libraries just to get a "simple" application working.
4. Other: These people may have heard about it, and are coming from Red Hat, Mandrake, SuSE, etc. and wanted to see what the buzz was about. These people are generally less experienced, and have problems getting it installed. If they can get theirs to boot (like the earlier post mentioned) and get X running, they are usually set for life with Gentoo.
It sounds like you might not be familiar with Gentoo and haven't been away from Debian much, which is cool. But you might want to give it a shot and evaluate the differences in package availability (not only total packages, which Debian should win hands down, but current versions of them as well) along with workstation/server performance before passing judgement.
Posted 13 March 2003 - 08:25 AM
Since when do you put Pre-releases/beta/alpha into Production?? I am sorry... I don't. Tis what I mean about STABLE. Quality Control and Procedure and Process and Policy.
I am guessing, you don't know me... I have tremendous *NIX back-ground...
Do you remember Interactive/386? What about SLS? Maybe RedHat v3.0.3? Slack v1.3?
Sorry, you are talking to one very seriously "emerge"d Linux Distro people out there.
Let me ask you one thing, have you gotten Oracle to run on Gentoo? Or how about Bea's Weblogic on Slackware? OR maybe Coldfusion MX running on a 2.0.37 Kernel? What about SAPDB running as fast and doing the same work as an Oracle DB.
Okay, claiming I don't *KNOW* or am not Familiar with Gentoo compile system being able to set controls... and build options globally. To me... it sounds as though you've never used Solaris, BSDi, AIX, OSF/1, Tru64 or HP-UX... you ever used pinstall? What about pkg-inst? what about pkg-add? SAM? SMIT? System-Adminstrator?
Sorry, you have picked the wrong person to start claiming as though *I* don't have familiarity... I have put into production just about EVERY flavor of UNIX availabe in the past ten years... Have been using Linux since Late '94... First experience the *JOY* of FreeBSD in it fully featurelessness... Saw the burgeoning of the *OTHER* BSDs. Watched Novell literally RUIN UNIXware.
I am an Expert Generalist... andone of the true Artists in Information Technology. Making nearly ANYTHING work well together... I don't program as a Job... I leave that to those better atune to that... me I implement, put the puzzle togeter... I finger things well before most... and get things done in multiples of most.
So, if you think I am coming of this lightly... for YOUR information... I recently converted to Snobbian^H^H^H^H^H^H^H^HDebian from RPM based and "Source" based ditributions... I am in the process of converting all of my personal and "self-employment" machines to Debian... all out from underneath my users... and they don't even have a clue... Seems as though, RPM based Distrobution don't have an ONLINE Working while Upgrading, upgrade system.... SOMETHING I've always needed... I have ALWAYS had to manually update my RPM Distributions using scripts I have developed over the past 5 or so years. But, I need them not... For Debian's dpkg/apt system works *SO* much easier and without effort..
You must also, not know about pinning versions..or maybe making Debian track stable/testing/unstable all at the same time... using the pieces you want it to use when you want them to use them...
Less hassle, more time for me to swat you around...
Posted 14 March 2003 - 05:51 PM
As you can see, he (gfolkert) got really touchy about me suggesting that he try out Gentoo, and we go through this endless loop. Then, after I lock this thread he starts another one and I wind up just deleting that one. There is little information here to help anyone else, so I just canned all the stupid posts between us.
Posted 15 March 2003 - 06:52 PM
Debian's QC is pretty good but not perfect. For example, the first release of Woody (R0) comes with broken Bastille Linux packages, which has successful bypassed Debian's quality control in the first place.
"Stable" and latest packages:
It is not always a good idea to upgrade to the latest greatest immediately, especially when your are running a server. For example, PHP 4.2.x seems to work fine, but had some serious memory leak issues. The much older PHP 4.0.6 release had never any problems.
RPM based distros and upgrading:
There is a port of apt-get for Red Hat and other RPM based distros. This port has exactly the same features like the original Debian release, even apt-get dist-upgrade is supported.