[SOLVED] Why isn't Mageia rolling release distro?

[TabletHater]

I assume I'm in practice using Mageia as a rolling release distro and despite being noob (though not a completely virgin one) I've seen just one issue related with the package manager and that too has been sorted out easily. So why not really? I recall reading something like that some time ago: this to be a long term goal.

As far as I'm on Cauldron I don't need to install Mageia again, right? If so, this is a very great convenience.

[doktor5000]

Well, Cauldron is kinda rolling release. There have been numerous discussions about this topic before:

EDIT: Dang, damn common words list prevents me from using the search function for that. But Firefox awesomebar comes to the rescue:
viewtopic.php?f=4&t=23
viewtopic.php?f=15&t=709
viewtopic.php?f=15&t=1447

There have also been really long mailing list threads, i can point you at them if you want.

[jaywalker]

When MGA2 goes to final release, some time in May I think, a fully updated Cauldron will be the "same thing".

However, your software repositories, which have been set up for Cauldron, should then be switched over to MGA2 Release. If you forget, then when Cauldron activity starts up again a few weeks later you will likely find that your installation starts to break again as preparations start for MGA3.

Richard

[TabletHater]

Thanks guys. I've looked at the discussions briefly. All I can say is that I find Cauldron perfectly noob-friendly, stable and very convenient. I'll be using this.

What do you mean by this Jay:

If you forget, then when Cauldron activity starts up again a few weeks later you will likely find that your installation starts to break again as preparations start for MGA3.

Do you say "You haven't met a big issue now just because you've come to it at a pretty late, stable stage, but in newly started MGA3 you should expect breakages"?

[doktor5000]

All I can say is that I find Cauldron perfectly noob-friendly, stable and very convenient. I'll be using this.
[...]
Do you say "You haven't met a big issue now just because you've come to it at a pretty late, stable stage, but in newly started MGA3 you should expect breakages"?

Definitely! Cauldron is always prone to breakage and should normally not be used in productive environments.
Also have a look at: https://wiki.mageia.org/en/Cauldron and at my signature

[TabletHater]

All right! All right! I'll switch my software repositories to MGA2 and be a good boy! But how to switch?

[jaywalker]

Yes ... and No.
Yes, Beta2 is very close (by a couple of months) to release, but don't forget we have a release candidate to check out too, and yes. as each day and week passes it clearly must be getting more and more stable. However, you can see from the varied issues people experience with the evolving Beta stage that in places and in some situations it is still some way from being a stable platform.

When this eventually hardens into a Release then MGA2 will be as good as it is going to be. Updates will be issued to fix bugs and security issues as required, but the only new versions of applications or libraries you will get will be through the Backports mechanism.

Meanwhile, in another part of the forest, a small group of adventurous explorers is sitting around a camp fire plotting the next release. They have a whole year to get it ready and they are likely to be considering all kinds of changes; minor and major. Big changes (such as the switch from initscripts to systemd in the boot process in the current Cauldron) are quite likely to cause all sorts of problems and it is not unknown for early Cauldron developments to produce boot failures and unexpected crashes and every kind of annoyance you can think of.

You do not want this to happen on your daily workhorse machine if you value your data, productivity or leisure time. By all means keep a system/partition/bootable external disc for evaluating the next Cauldron and participating as a user/tester.

Of course, these are my opinions. I cannot easily accept not being able to use my system for a day or two while waiting for a critical bug-fix. Nevertheless, my brother is very happy to be using a late MGA2 Alpha 2 installation on his netbook, but he won't update it in case something he depends on now might be broken later. What he might do is ask me what is the "current" situation and if I think it will work for him then I can take a snapshot and put it on his machine.

So, you might do something similar if you like the idea of a "rolling release". You could have a working system based on Cauldron on which you have turned off auto-updating. You can have another experimental Cauldron system which you keep up to date which may well suffer all sorts of problems from time to time. When the experimental one is in a state you like then update your working installation to the same state. That way you should be able to avoid getting a disfunctional Cauldron on your working system.

[alf]

But how to switch?

if you'd read jaywalker's posting carefully you'd better ask "but when to switch"


edit: he was a bit faster

[jaywalker]

But how to switch?

if you'd read jaywalker's posting carefully you'd better ask "but when to switch"

But they are both good questions. For myself, I normally grab the release iso and "update" my installation. You won't be able to switch your repositories until the mirrors are carrying the Mageia2 tree. I would reckon that a good time to switch would be within a few days of the release date.

The switchover should be almost automatic, if the previous Cauldron->Mageia 1 migration is anything to go by. There is an announcement in this forum which describes that (viewtopic.php?f=15&t=326). So when your Cauldron installation stops calling itself Cauldron and becomes Mageia 2 in the boot screen and console titles then your repositories should be pointing at the new release. It is worth waiting a bit to allow time for all the mirrors to be updated.

Richard

[TabletHater]

Just as I'm convinced to go back to regular, you say:

By all means keep a system/partition/bootable external disc for evaluating the next Cauldron and participating as a user/tester.

Do you really need a noob's input in these matters?!! A noob with only a 60 GB SSD?! No wifi or bluetooth or a separate video card (using just SandyBridge) to test?!

[jaywalker]

God yes! Every user counts! Take any one of us and you haven't got much, but put us all together and you have a universe of varied hardware and hardware combinations, an encyclopaedia of software experience and interests and use cases. If you have enthusiasm for testing and a desire to learn new problem analysis skills then the only one stopping you is yourself.

The single greatest thing about the Mageia community at the moment is that it is growing. As it grows, so do the opportunities for finding ways to contribute. Even asking questions is helpful. It can make people think and think again. Is there a better way? Is there a bigger problem? Is a nuisance becoming a deal-breaker?

I preach too much. I'll just say this; everyone here is a noob in some aspect of our shared interest.

[TabletHater]

All right. I'll be glad to help. At least I'll certainly and seriously try.

[TabletHater]

Jay,

So, you might do something similar if you like the idea of a "rolling release". You could have a working system based on Cauldron on which you have turned off auto-updating. You can have another experimental Cauldron system which you keep up to date which may well suffer all sorts of problems from time to time. When the experimental one is in a state you like then update your working installation to the same state. That way you should be able to avoid getting a disfunctional Cauldron on your working system.

In that scenario I should install the same DE on both partitions, not KDE on one and LXDE on the other?

[jaywalker]

Good question. Let me think. I have my own reasons for choice of desktop environment.

[TabletHater]

See below.

[jaywalker]

In that scenario I should install the same DE on both partitions, not KDE on one and LXDE on the other?

Always the easy questions...

If storage space is a constraint then pick one.
If storage space is a serious constraint then pick LXDE.
If the thrills and spills of an evolving modern DE excite you and you can make the space for it, then pick KDE.
If you need your CPU to focus its efforts on your needs rather than those of your desktop then pick LXDE.

There is no law against running different desktops on different instances of the same basic system. For most people it would maybe be a "no brainer" an obvious choice to install both desktops to get the different benefits of each. Even on a 60GByte drive there should be plenty of space for both as your own data files can expand if necessary on to additional external storage. As a rough guide we could imagine two systems sharing the drive - one for work and one for testing - taking, say 12 GBytes each. A single swap partition of 2G-4G would leave around 30G for /home which could be shared, with care.

If we run different DEs on each then I would recommend that you have LXDE on your working system and KDE on the testing system. You can hear my own predjudice coming out here. I prefer the efficiency of LXDE over the luxury of KDE because I didn't upgrade my computer when KDE went on their Vista-envy jaunt with KDE4. It was hard for me because I had loved using KDE through the good times and the bad times of KDE 2 and 3. LXDE is not (and now, hopefully, never will be) in competition with KDE. The "L" is for Light.

Forcing myself to be more objective I would say that recent versions of KDE 4 have been very very much improved over its earlier incarnations. Having KDE on the test system would allow you to assess for yourself if it is improving in a way you can use. With LXDE on your working system you will have a baseline against which to compare, and perhaps make the change one day.

Space permitting, you can sensibly run as many different desktops as you want to explore on your test installation and use one of these on your working installation. It makes sense to pre-test not just the environments which you find interesting, but also the one you are using for real work - you don't want any usability surprises when you update, do you?

So consider what you will be using the machine for; video, sound, art/design, 3D modelling, major works of fiction, bringing work home, software development. Each of these areas of activity will put different strains on different parts of your software and hardware system. Your desktop of choice should not get in the way and should help you use the tools you need.

That's enough from me. I have to be up early in the morning to fit two new brake discs to my car. I haven't tried this before so I am setting aside the whole day to give me a chance at overcoming the problems I'm bound to create for myself.

Richard

[jaywalker]

Didn't see the supplementals. They'll have to wait until tomorrow I'm afraid. I'm on GMT so give me about 12 hrs, OK?

[TabletHater]

Sure, sorry.

[TabletHater]

I prefer LXDE as well and though I strongly dislike some aspects of KDE, seeing not much difference between the CPU temp of LXDE and that of KDE, and considering a few advantages of it I might consider to give it a last chance! That said, I'd very likely use Razor in the test OS and LXDE in the work OS.

But my questioning stemmed from my (sometimes religiously minimalist) attitude: Thou shalt not mix DEs in the same OS. And I was trying to ask if non-issue in one DE with the testing OS would guarantee non-breakage in the other DE with the work OS. Anyway, I got your point. No need to bother with this subject any more.

I update my supplementals:

1. I'll partition my 55-60 GB SSD as: 15 GB /root1, 15 GB /root2, 25 GB /data. (I already have my music and video files on a network drive.) No swap (got 4 GB RAM). Any objection? Would you recommend reading a particular guide before doing this?
2. Can I install the huge TeX dependency of LyX on a separate/shared partition like /data?

[jaywalker]

Oops, overslept, but while I am enjoying my late breakfast coffee...ouch! 930MB on my box to install lyx.
lyx, texlive and cmsuper account for over 90% of that.

Just bite the bullet and allow the packages to install where they're expected to be. Then, when you have a bit of time to yourself, you could play with the disposition of those 4 BIG space-eaters on your test system and see if you can get them together on their own partition. The easiest way might be to provide symlinks in the expected places to the code/data in the lyx partition, otherwise you might have quite a few headaches sorting out any configured or compiled in path expectations.

Swap.
Yes, you can probably run without swap, but what is the lyx memory footprint like with a couple of documents open? You have the swapon and swapoff commands so maybe try it with a swap partition and seeing how it goes with swap turned off. Don't forget that the more memory you have, the more the system will take to cache stuff, and Mageia is making more use of tempfs these days - that's in memory too.
Gkrellm is an attractive multi-purpose desktop instrument panel for monitoring all sorts of resources. It can show you your memory and swap usage, system and hard disc temperatures, cpu usage, temperature, frequency - even your keyboard CAPS and NUM lock leds! Could be useful while you are tweaking your system.

Gotta go for a bit... later

Richard

[doktor5000]

But my questioning stemmed from my (sometimes religiously minimalist) attitude: Thou shalt not mix DEs in the same OS

That is seriously wrong, there's no problem with having multiple DE's on the same system, or even using multiple toolkits under one DE, which is rather common.

[TabletHater]

You guessed right Dok. Multiple toolkits're ruining my days and nights!

Richard, LyX uses around 45 MB with a normal size book. Guess, it's possible to have a TeX partition (in /opt partition in one example), but I don't want to install the whole of TeX (2-3 GB as far as I can remember), but only the LyX part. I'll ask them.

Burak (TabletHater)

[TabletHater]

All right, I'll install LyX only in the work OS.

[TabletHater]

Please help me here:

I had read that sharing /home between two OSes might be dangerous, better to have a shared /data partition. But sharing /home would make life much easier (shared MPD config etc.). Is there a safe way to share /home? Or can you point out another solution? Can I put .mpd/ and mpd.conf in the network drive (smb share)? If I should choose the /data partition scheme, would you recommend anything special?

[jaywalker]

[...]But my questioning stemmed from my (sometimes religiously minimalist) attitude:[,,,]

Oh brother, I know what you mean. That has got me into more trouble on this and the Mandriva forum than I care to recall

I think we are in the minority. After all, it is much easier to throw more money (memory, disc space, processing power) at a problem than to solve its root cause.

Well, it is what it is, this crazy world, but you can still do something about the problems associated with multiple desktop environments on one system. It is a common way to experiment with DEs and also to have different DEs set up for the applications for which they are best suited, but it can be a minor pain to manage the configuration issues which can arise. The most obvious area for strangeness to be seen is on the desktop itself. This is usually common to all DEs you may use, but it can be handled so very differently by each. If you are used to having one or two application icons on the desktop for rapid access, then you might be disconcerted to have KDE put warning signs on them and not let you use them before you have confirmed that you really do want to use them. Unless, of course, they don't appear on your KDE desktop at all. If so then they might also be missing when you revert to the previous desktop and you'll have to create them again.

Aside from problems arising from the different ways the desktop environment might be managed, the only other likely source of problems is in the hidden directories and files which hold application configuration data. If you have a program set up with default settings in your testing system and you use personalised tweaks in your working system then the settings will be changed for both. That will likely only ever be an annoyance; for example, you spend time getting your browser set just the way you like it, then in the test system you try out something different. As long as your test and working systems don't get too far apart in time (and program versions) then you are unlikely to encounter any real dramas.

I can give you a real-world example of sharing HOME between multiple OSs. I have a 931GByte USB drive with 1xMGA1-64, 1xMDV2010.2-32 and 1xMDV2010.2-64. The two 64 bit OSs share one user directory and the 32 bit one has its own. The users are called "richard" on the MDV installations and "rich" on MGA but they all have the same userid/groupid. The home directory for each is actually a symlink to the appropriate real directory - one for 32 bit use and one for 64.

The rationale: (separate 32 and 64 bit HOME) I build and run some apps from my home directory so I don't want to get confused when the app fails to run because it is the wrong binary format for the OS. I ran separate configurations of Opera in 32 and 64 bit modes because for a while Adobe let us down and wouldn't provide a 64 bit Flash player. Hint: don't try recording radio programmes from 32 bit Flash when you are running a 64 bit Jack server.

(shared HOME for 64 bit) Generally this works just fine. Despite MGA and MDV being quite a few months apart there are few issues with incompatibility between application settings files. As the MGA and MDV systems do not (and cannot) have the same applications installed, I have to be aware of which one I am using if, for example, I want to use Kaffeine or Qucs. The data is less troublesome. One directory for Documents, Pictures, Music, Audio and Videos is enough. Both (all three?) HOMEs share this single set using symlinks. Each HOME has its own Downloads, Apps, bin and src directory.

So, it can be done and it is either simple or complicated, depending on your needs. The sources of problems are obvious and easily accommodated. The best weapon in this regard is to remember which environment you are in

seeing not much difference between the CPU temp of LXDE and that of KDE

I would be more interested in actual performance of a task than in the temperature the CPU is running. For example, I can capture desktop video faster in LXDE than in KDE. Full screen video played back more smoothly under LXDE than KDE - that sort of thing.

Can I put .mpd/ and mpd.conf in the network drive (smb share)?

If these are both normally in your home directory then yes, you can. Just move them onto your network drive and replace them in your home directory with symlinks. Or maybe not. I suddenly have doubts. Read this for more information about symlinks and Samba http://www.samba.org/samba/docs/using_samba/ch08.html. Google will probably find more if that isn't enough.

Multiple toolkits're ruining my days and nights!

But I know what you mean. You have a lean green computing machine and then you develop a desire for something a little exotic from another desktop environment. You urpmi the app and get hit by a demand for hundreds and hundreds more than you were budgeting. Such is life in a world of human moderated dependency. Why can't we have real dependencies - those things that the program cannot do without if we want it to run?

Need more coffee.