On 11/2/2011 6:23 AM, Linux Tyro wrote:
On Wed, Nov 2, 2011 at 2:30 PM, Felix Miata
wrote: openSUSE is much like RedHat in that both use the basic RPM package management (underneath the friendlier Yum and Yumex overlays, which roughly correspond to Zypper and YaST2) and similar (1,2,3,5) runlevels. Debian runs on only two runlevels, and basic deb packaging (underneath the friendlier apt& aptitude overlays). These elementary similarities and differences have little to no impact to most users, but can confuse those trying to learn how the underpinnings and command line tools work. Keep this in mind when books talk about similarities and differences between RedHat& Debian, and remember to focus on the RedHat discussion. For most purposes books about RedHat have applied to openSUSE, but note that RedHat is a commercial distribution with a free counterpart called Fedora, similar in concept to openSUSE's relationship to commercial counterparts SLED& SLES.
Oh well, it means basically there are two types of linux - 1) rpm 2) deb and I am going for 1) rpm. NOW in this rpm man distros come like openSUSE, fedora, etc.. and in deb other distros come like ubuntu, debian, etc.. , is it like this?
Not really. rpm and deb are merely packaged software management systems. There are many ways to manage software installation and removal, and these two are by far the most common, but by no means the only ways. They are only the most common because debian and redhat, and their spin-offs like centos and ubuntu, happen to be the most popular linux distributions currently. Technically .apk is probably the most popular linux software package fomat since there are probably more Android devices in use than linux desktops even though redhat and debian have been around a lot longer. Package management is a detail. Don't get too hung up on details at this point. There are not two types of linux. Depending on how you want look at it, or how you want to categorize, there is either only one linux, or there are an uncountable number of linux's. It's not like Windows. There is no overall system written by any one entity or group. There is this big bag of software parts all written by different people, and most of it has nothing to do with the rest of it other than it's all written to be compatible and work according to a common set of general principles, loosely defined as UNIX, and/or POSIX, and/or in the case of Linux specifically, the LSB (linux standard base). Much of the sofware in a linux system is not even written specifically for linux, but is written for any unix/posix compatible system, which includes freebsd, opensolaris, and a host of commercial unixes like sco, sun, hp, ibm. Systems like redhat, debian, ubuntu, suse, etc... these are called "distributions" not "linux" because that's what they are. They take all the various components of a typical unix-like system and assemble them into a coherent system. This is a significant and complex job and it's why distributions even exist. They have to pick which components to include, and then customize or configure them to fit into an overall system to work with other components. For example, one common component of any unix-like system is "getty" this is a basic program that opens up a tty (a serial port or a console generally) and prints the login prompt and waits for logins, and hands off the tty to /bin/login or some other login authentication method and ultimately to a shell instance (command prompt, ie /bin/sh or /bin/bash). There are several different getty programs written by different people over the years with different features and details, although they all do roughly the same basic job. Maybe one has special support for detecting incoming faxes or PPP connections on modems, maybe one has support for full-screen color menu/dialog "pretty" login prompts, maybe one is stripped of everything except the absolute minimum required to use the vga console only so it's fast/lighter/smaller, etc. A distribution evaluates many of the possible getty programs, picks one based on whatever that distributions guiding principles are, then configures or customizes it as necessary to fit in with the rest of that distribution. For example, Typically getty's used to be configured by a file called /etc/gettytab and/or a file called /etc/inittab. /etc/inittab is really a config file for /bin/init, which is the fist program that is run at boot up, and it starts everything else, and is responsible for watching and restarting certain things if/when they are killed. This includes, all the getty's on all the tty's. But some systems do not have a standard /sbin/init anymore. There are now starting to be alternatives like upstart and systemd that do the job init used to do, but do it in somewhat different ways. (Choosing what style of init to use is yet another of the many things a distribution does.) So, for instance, the next version of opensuse, or possibly the one after that, it's still a bit too early to be sure, will be using systemd instead of init. But the author of mingetty (the minimal getty for use on the local consoles only) may or may not have written any special systemd support into his getty app. For example the Makefile for compiling and installing the app, and the documentation, may just assume that the app will be started from /etc/inittab and that's it. Suse will have to slightly alter _their_ mingetty package so that it includes a systemd service script instead of one or more lines in /etc/inittab, and possibly alter the man-page to reflect that also. And, related, if the systemd package happens to include a default service start script for some other standard getty, suse may have to alter that a little to use mingetty. These are all _details_ that are different for every distribution. They do not make the different distributions into different types of linux. Every distribution has it's own unique pile of these details that makes it different from every other linux. And yet, there are certain principles that are the same on just about every linux. Almost every distribution has the same major _features_ such as * some version of linux kernel * some sort of libc * some sort of init * some sort of getty * some sort of ssh server * some sort of shell * some sort of package management system The ssh serevr is usually OpenSSH, but does not have to be. There are others and some special purpose distributions use them instead. For instance you might use Dropbear on a WebOS device or a linksys router running OpenWRT. The libc is usually gnu libc, but there are others. You would probably use uclibc on an embedded device or router. You might use a commercial libc with distributed computing support or support for using gpu's or other special vector processors on a big cluster. The package management system might be deb or rpm, or as in the case of gentoo, most software might be managed similar to the freebsd ports system where a package is just a set of compile and install instructions and everything is compiled-to-order on your own machine right when you install it. So again. Try not to get too focused on any details yet if this is all new to you. Go ahead and read distribution-specific books and articles if you don't happen to find any really good generic ones, but _at first_ don't worry too much about actual details like program names and file locations and command line arguments. All that stuff is subject to change from one distribution to another, and also changes all the time from one version(*) to the next. For the purpose of getting started, pick really any distribution, and read documentation that IS specific to that distribution, and see how things work and get familiar. You do have to start somewhere. If you're not going to take a class where a professor will describe general principles abstractly, then you have to learn by actually playing with something, and there is no such thing as a perfectly generic linux distribution. Maybe slackware or linux-from-scratch come the closest. So you will necessarily have to play with some distribution, which necessarily will be different from all others, so you will necessarily only partly be learning "linux". You will be learning "ubuntu" or "opensuse" which just happens to have a lot in common with other linux's and with other unix-like systems like freebsd and solaris. But at first you really have no way of knowing what things are general and what things are specific to ubuntu, or opensuse, etc. Just as long as you understand that that is what is happening, that should help you not to be too confused when you come across discrepancies or ambiguities. For instance, some document may say "run this command: fdisk <device>" without saying what <device> is. Frustrating. Well unfortunately they are not being lazy or unhelpful. They _can't_ say what <device> is. Not because they don't know. They know, but they know for themselves, they can't know for you. It's like they know how to buy a new tire for a car, and they know the exact size of their own tires for their own car, but they can not know the exact size of your tires for your car. So they can't give you the full exact directions that you would actually need in order to actually get a tire that would actually work. They may supply a "for example /dev/sda1" but you CAN NOT take that and use it yourself. There is only a small chance that that is correct for you. You have to know how your own system names it's hard drive devices. In fact, on linux, the first hard drive is very often /dev/sda only because of a push the last few years to consolidate the most common disk controller drivers for scsi, sata, and ide to all use the same driver called libata, abd that driver happens to use the same naming scheme as most scsi drivers. But there is absolutely no rule that says disk drive device nodes must be named /dev/sd<something>, and indeed sometimes they are not. In fact, that's actually becoming the LESS preferred way to refer to drive devices now. Now it's usually better to refer to the devices by /dev/disk/by-id/some-long-drive-maufacturer-model-serial-partition or /dev/disk/by-uuid/some-long-uuid-number etc.. because nowadays, the way motherboards and the kernel detects hardware during boot up, it's too dynamic and variable and user-configurable, you can not count on /dev/sda to point to the same physical drive from one boot to the next, so you have to reference something like uuid that is unique to that drive no matter what order it was detected in at boot time. Also on non-linux systems the names vary quite widely. However, the general principles you can apply to almost any unix-like system, devices are almost always accessed via a special kind of file called a device node, almost all disks are such devices, and the devices nodes to access them almost always come in the form of one or more files under /dev. Baically, the one core principle of all unix-like operating systems is that it is made up of a big tool box full of small low level tools that do specific things. And all high level functionality is built out of connecting those tools in different ways. It's all intentionally as generic and non-specific as possible. The "cat" command does not care if it's reading a file or a tty or a pipe from some other program. It is a generic, low level tool that does one tiny thing that seems to be pretty useless by itself. And it is by itself, just like a single Lego block or a single screwdriver. But combine the screwdriver with a screw and a nut and a couple sheets of metal and you start to have a higher level object that is good for something. It might be a dog house or camera or a toilet. And all screwdrivers have certain principles in common, yet, the exact details, all screwdrivers have some details different from each other. Unix is intentionally like that. It's a tool box that you build whatever you want out of. And linux is just one of several unix-like systems. And opensuse is just one of several linux systems. Have I made it confusing and baffling enough ? :) -- bkw (*) Heck, the very concept of a "version" isn't even a universal concept. You asked about the meaning of "rolling release" before. Arch Linux is a distribution that doesn't really have such a thing as a version. All the individual packages in it have versions that are always changing, but the overall distribution never picks any fixed set of packages and says "This defined collection is Arch Linux version 2.0" Instead all packages are always whatever is current at the time you install, and they all update to whatever is current whenever you run an update. That's called a rolling release. The release is always rolling along, it never stops at any milestones. This can be a good thing or a bad thing depending on what your needs and priorities are. It's a live saver is some situations, it's death in others. This is why there are so many distributions of linux. There is no such thing as one way of doing things that is best. -- bkw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org