On 14/07/10 21:39, Steve wrote:

I guess that much of the content of these emails is soo far above my head I assumed the meets would be the same.

I've not been to an ALUG meet, but unless they're very different from other LUGs then you'll be just fine. There'll be plenty of content that goes over your head and plenty that is at just the right level. The same should be true here - you'll get long time users getting stuck on weird and wonderful issues that you really don't need to worry about, but that shouldn't put you off asking your own questions and you should get answers that help.

To clarify my question about repos, my understanding was that "mostly" linux is a core kernel that at some particular point is basically the same, some distros use the cutting edge version others stay back a bit.

Yes, but also it's possible to turn different features of the kernel on and off so different distros make different choices. An obvious difference might be the hardware the kernel is built to support, for example. Most common distros (eg Ubuntu) try to support most stuff you might find on an Intel x86 based system (ie the sort of system that would also run Windows).

If there's broadly a common basis and one overcomes the packaging differences (why can't they all be the same?), and the dependencies work themselves out shouldn't the bits basically all work.

Yes, all the bits should just work. Why different packaging systems? History. There didn't used to be any packaging system, and different distros developed their own. They generally achieve similar things in mostly-similar ways, the main jobs being to make sure that when you install any given package that any other requirements are installed as well, and then to take care of updates.

With Windows, there are lots of different packaging systems as well but the user doesn't generally care, because the issue of dependencies is mostly removed by having every package duplicate all of its requirements so it doesn't matter if two packages use the same system - they won't try to share a common base anyway. Also notice that when you update a Linux system, pretty much everything gets updated - try upgrading XP to Windows 7 and see if all your other applications also get upgraded to the latest versions. Again this is not an issue for Windows users - having an Office 2003 licence doesn't give you the right to Office 2007/2010 anyway, so having the upgrades managed for you doesn't make sense. But when you look at the whole system management capability of systems like apt and yum (and the graphical interfaces on top of them) the benefits justify their existence many times over.

With luck, one day someone will come up with a new packaging system which has all the best features of the other systems and is sufficiently compelling to make all of the main distros feel the need to upgrade to it. I doubt it'll happen any time soon, though.

It comes from not wanting to miss out on stuff it's the same thing that leads me to try different distros, Peppermint currently.

I've found over the years that for the most part, if a package is worth having it'll be in the repos for your distro and fairly current. There are exceptions, but using one of the main distros helps to reduce them.

Anyways, I didn't really get what the stuff about SFD was, but as I live near Syleham that location would get my vote for a meeting.

SFD = Software Freedom Day.

The freedom to use software the way you want, and to modify it if you want to, is key to how Linux (and other software, eg Firefox, OpenOffice, etc) have developed. SFD is about promoting that freedom.

On Wed, 2010-07-14 at 21:39 +0100, Steve wrote:

Thanks for the feedback and the invite to the meetings.

I guess that much of the content of these emails is soo far above my head I assumed the meets would be the same.

To clarify my question about repos, my understanding was that "mostly" linux is a core kernel that at some particular point is basically the same, some distros use the cutting edge version others stay back a bit.

If there's broadly a common basis and one overcomes the packaging differences (why can't they all be the same?), and the dependencies work themselves out shouldn't the bits basically all work.

Yes, the term Linux really refers to a kernel. The kernel provides various features such as CPU and memory management, inter-process communication, filesystems and networking and a way of sending data to/from more specialised hardware.

The exact way kernel features are invoked depend on the processor but usually involve some kind of trap. In practice this difference is hidden behind a set of stubs in the standard C library which provide the published interface.

Although in theory applications can be written to use the kernel features directly most applications tend to use the services of one ore more libraries and this provides another area where there can be different versions and why package management is a good idea.

In practice both the kernel and the major libraries try to remain backwards compatible where possible but this is not always guaranteed.

Anyways I don't really need a further response re repos as I have got the message from you guys that its best not to mix it up, and I suppose that the mainstream packages will appear in all the main repositories.

Most of the commonly used packages are available in many of the distributions. If you have specific needs you may want a distribution that specialises in that need otherwise a modern mainstream distribution will be fine. You'll find loads of packages to do lots of useful things and on the odd occasion you find something interesting that is not part of your distribution there are ways to make it work.

As an example, if you have a debian-based distribution and need to install something only available as an RPM (Redhat etc.) there is alien to convert the package from one to another.

Another route is to compile the odd package from source. This is perhaps not as daunting as it seems as the compiler and tools are free and generally available as part of your distribution and many packages use an automatic configuration system (e.g. GNU autoconf) to configure themselves to your system. This means in many cases all you need is:

./configure make make install

HTH, Steve,