On 4 April 2010 00:01, <fons@kokkinizita.net> wrote:

On Sat, Apr 03, 2010 at 05:59:18PM -0400, Keith Hinton wrote:

...

First of all, if anyone is curious as to why I have posted to the Arch-General mailing list, I'm mainly doing this, in case any of the Arch Release team is actually hanging out on this list. I was curious, seeing as the last Arch Linux release was in August of last year, if there will be one for the lovely new year of 2010?

There are no 'releases', Arch is continuously updated. When you install you get the latest versions of everything, not some release that was frozen some time ago. After installation update you system e.g. once every few weeks. This just takes a single command, and you never have to do full re-install.

Ciao,

-- FA

O tu, che porte, correndo si ? E guerra e morte !

You still need some install CD/Flash/whatewer to do the initial install and the current one is rather old. I had a lot of headache caused by the old installer, because I need kernel >=2.6.31 (IIRC installer contains 2.6.29 or 2.6.30) to install Arch on my notebook.

...

You still need some install CD/Flash/whatewer to do the initial install and the current one is rather old. I had a lot of headache caused by the old installer, because I need kernel >=2.6.31 (IIRC installer contains 2.6.29 or 2.6.30) to install Arch on my notebook. archboot isos contain .32 kernel located here: ftp.archlinux.org/isos/archboot

-- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org

The problem is that if you don't know about this address you have (almost) no chance to find it. Most people will use other distribution instead. And others (eg. me) spent a day learning how to change a kernel package in the installation image. Lukas

On Sun, Apr 04, 2010 at 09:23:31AM +0200, Lukáš Jirkovský wrote:

You still need some install CD/Flash/whatewer to do the initial install and the current one is rather old. I had a lot of headache caused by the old installer, because I need kernel >=2.6.31 (IIRC installer contains 2.6.29 or 2.6.30) to install Arch on my notebook.

Either do a netinstall (available from the same image), or after the basic install do 'pacman -Syu' which will update everything. Ciao, -- FA O tu, che porte, correndo si ? E guerra e morte !

On Wed, 07 Apr 2010 12:44:22 -0500, "David C. Rankin" <drankinatty@suddenlinkmail.com> wrote:

... It doesn't matter whether you use the latest install set or the one from 3 'releases' back, after the first update, you will have the exact same, current Arch Linux we all have.

It's not entirely true. You always should install using the latest iso and it is also important to release new isos regularly. Due to our continuous updates and changes old isos and especially netinstall are broken. For example you cannot run a netinstall with an old iso (without updating it first) due to the switch to xz compressed packages. -- Pierre Schmitz, https://users.archlinux.de/~pierre

I missed that completely in my train of thought. But without the change in package compression it would still hold true. Prior to the xz compression change, I had had no problems using the 2/09 install media even after

On Wed, 07 Apr 2010 13:45:41 -0500, "David C. Rankin" <drankinatty@suddenlinkmail.com> wrote: the

8/09 install media was released. Thanks for keeping me honest ;-)

I remember several changes on our site that broke old install isos. I recently tested some of them and afaik those before 2009.02 don't work because that kernel is too old for our glibc or something similar. Or some day we had changed the repo layout etc.. In general Arch is moving to fast to keep old isos and install working. -- Pierre Schmitz, https://users.archlinux.de/~pierre

On Wed, 2010-04-07 at 12:44 -0500, David C. Rankin wrote:

( if the other distros were 1/2 as smart as Arch, they would all be using a rolling-release model... )

Not true. If you want a distro that "just works", you need to really test a lot before you change a version of the package and this is obviously feasible only if you change all versions at the same time. Arch is more about "do it yourself" than about "just works".

It would appear that on Apr 8, Lukáš Jirkovský did say:

Hi David,

...

It doesn't matter whether you use the latest install set or the one from 3 'releases' back, after the first update, you will have the exact same, current Arch Linux we all have. It is the smartest way to do a Linux distribution -- hands down.

I don't agree with you. For 99 % (just guessing) packages it's true, but if you need new kernel to correctly boot it's a problem. The fact that in the repo is kernel new enough for you to boot but installer has too old kernel is not really a way how to attract users.

I hope you don't mind an {Arch-newbie} jumping in here... ;-7 Perhaps what David should have said is something like: [paraphrase] It doesn't matter whether your Arch system was installed yesterday using the latest install set or was previously installed using the one from 3 'releases' back, after the next update, you will have the exact same, current Arch Linux we all have. It is the smartest way to do a Linux distribution -- hands down. [/paraphrase] My take on it is that while it's always a good idea to be using a current install medium, with Arch it only matters that your system is able to become current via update. The release of a new install set in itself should never be a reason to reinstall a working system. All I know for sure is that while Arch takes a bit more work to get a running desktop system than some other distros, The idea of not having to start from scratch every 6 months makes it "way worth it..." I've learned that if I can only find the right wiki entry, there is usually a good comprehensive walk through of whatever I need to do to my system. And this way, I wind up with a better understanding of my system. So as long as the rolling release process turns out to be consistently more reliable than updating a 'buntu system to the next release {by editing the sources list and doing an "apt-get dist-upgrade" (2 out of 5 such upgrades really hosed my my 'buntu installs...)} then I'll be singing praises to the rolling release concept for a long time. (I really detest having to recreate my user environment every 6 months...) Nuff said. -- | --- ___ | <0> <-> Joe (theWordy) Philbrook | ^ J(tWdy)P | ~\___/~ <<jtwdyp@ttlc.net>>

It would appear that on Apr 8, Isaac Dupree did say:

On 04/08/10 07:21, Joe(theWordy)Philbrook wrote:

...

My take on it is that while it's always a good idea to be using a current install medium, with Arch it only matters that your system is able to become current via update. The release of a new install set in itself should never be a reason to reinstall a working system.

Good description (although I'm willing to bet there's some little bit of unimportant cruft on a system originally installed several years ago, due to various organizational updates, in addition to you as admin forgetting which files you've left around in /etc...)

No doubt. But cleaning out a build up of "cruft" on ones own system is a separate thing from needing to reinstall simply because somebody released a new install image... Though I'll acknowledge, that if I felt my system was due for that intense a "spring" cleaning, I think I'd probably time it to right after a new install set has been "sprung" on us... ;-7

...

All I know for sure is that while Arch takes a bit more work to get a running desktop system than some other distros, The idea of not having to start from scratch every 6 months makes it "way worth it..."

if you don't mind running old versions of software... which I do...

I take it that you don't feel that "pacman -Syu" or if applicable something like "yaourt -Syu –aur" Will bring your Arch system as fully up to date as installing the latest Ubuntu release, followed by an apt-get dist-upgrade would??? As a dedicated multi-Linux, multi-booter I usually have three or more distros installed. I've noticed enough variance in "software versions" between fresh installs of the "latest" OS releases of enough distros to know that a new install of a new OS release is no guarantee that *_ALL_* of the software will be the latest possible release.

...

I've learned that if I can only find the right wiki entry, there is usually a good comprehensive walk through of whatever I need to do to my system. And this way, I wind up with a better understanding of my system.

oh indeed! Over the years, the Gentoo wiki has been a pretty good source of info too (whatever distro you're on), and even the Ubuntu wiki has some nice info for specific hardware (MacBooks at least), etc. Arch has a pretty good wiki now also!

I'll agree that there's good stuff in the other wiki(s). But the Arch wiki impressed me with how it approaches how-to instructions with regard to helping users who really don't have a clue yet, work their way through it. At least, that's the impression I got from the Beginners Guide, And nothing in the 17 arch wiki bookmarks I've added to my ~/lynx_bookmarks.html so far. Along with the fact that all of them lend themselves well to using a console browser like lynx. Which was helpful when I was trying to get X up and running..

...

So as long as the rolling release process turns out to be consistently more reliable than updating a 'buntu system to the next release {by editing the sources list and doing an "apt-get dist-upgrade" (2 out of 5 such upgrades really hosed my my 'buntu installs...)}

You did it wrong, according to Ubuntu documentation. Ubuntu (unlike Debian) (well, I'm not sure about ubuntu-server...) only supports the GUI update manager as an update path (I believe it does a few more things than a mere dist-upgrade, depending on the particular upgrade; and by not doing those things, you're asking for trouble...). On the other hand, I can't vouch for the official upgrade path being terribly reliable (I usually reinstalled in a separate partition because there was no way to roll back on the same partition if the new release had different hardware problems that I didn't yet figure out how to solve).

Yeah I know the "U"buntu devs only recommend using a Gui method. BUT: 1)My 'buntu experience started with "KU"buntu, Where (at least at the time) the apt-get method WAS still recommended. (kde users didn't much like depending on a gnome gui tool...) 2) Even now if you look deep enough, there still exist valid command line methods... For example check out this excerpt from" http://ubuntuguide.org/wiki/Ubuntu:Karmic -> Upgrading Intrepid or Jaunty to Karmic -> -> * Also see the official Ubuntu desktop upgrade documentation. -> -> There are several methods for upgrades from the command-line interface -> (Terminal) (which can be used for both the desktop and server editions of Ubuntu/Kubuntu). -> -> * This is the preferred method: -> -> sudo apt-get install update-manager-core -> sudo do-release-upgrade -> -> * You can also use the update-manager (all editions): -> -> sudo apt-get install update-manager -> sudo update-manager -d -> -> * You can also use: -> -> sudo apt-get update -> sudo apt-get upgrade -> sudo apt-get dist-upgrade -> -> (Note: the first two lines simply make sure your current distribution is -> current before upgrading the entire distribution, and are optional.) Though I note that they don't mention the step of manually updating the sources list for the dist-upgrade method. Also I saw something from ubuntugeek that suggested that in between installing update-manager-core, and running do-release-upgrade one should edit the file /etc/update-manager/release-upgrades to set Prompt=normal. I guess I've always tried to use cli methods because I've never been comfortable attempting major upgrades while depending on the X server. Now that kde4 has chased me away from using Kubuntu, I still have an Xubuntu installation, And I think I'll give the do-release-upgrade method a try when I'm ready to "upgrade" from karmic to lucid But I gotta say, Arch has become my default boot choice... Incidentally Isaac, if you've got the spare partition to do a 'parallel' fresh install, you could still do an upgrade without risking the existing installation... 1) Duplicate current installation on the separate partition. You could use partimage {I think} But I've always used: tar -czf filename . from the mountpoint of the source partition, then after running mkfs on the target partition I mount that and from it's mountpoint I do a: tar -xzf filename --numeric-owner . (of course, as a multi-boot user, I usually have a running Linux in a third partition to do the tar commands in. (Making a tgz BU of the current root partition isn't a good idea... {too many moving targets}) 2) edit target fstab to reflect it's new location. 3) add an appropriate entry to grub 4) assuming the cloned installation works properly, you can upgrade one, while keeping the the other untouched... Well I gotta go to bed soon so, See Ya... -- | --- ___ | <0> <-> Joe (theWordy) Philbrook | ^ J(tWdy)P | ~\___/~ <<jtwdyp@ttlc.net>>