15 Apr
2008
15 Apr
'08
5:18 p.m.
Hi,
there's a vivid discussion on opensuse-buildservice about the
consequenses of "end of life" announcements to the buildservice.
See
http://lists.opensuse.org/opensuse-buildservice/2008-04/msg00185.html
The question was raised if it is possible to keep older distributions
available for download (e.g. unsupported.opensuse.org) and building.
Adrian pointed to opensuse-project to get this question answered.
Klaus
---
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-project+help(a)opensuse.org
15 Apr
15 Apr
9:58 p.m.
Klaus Kaempf wrote:
there's a vivid discussion on
opensuse-buildservice about the
consequenses of "end of life" announcements to the buildservice.
See
http://lists.opensuse.org/opensuse-buildservice/2008-04/msg00185.html
The question was raised if it is possible to keep older distributions
available for download (e.g. unsupported.opensuse.org) and building.
Adrian pointed to opensuse-project to get this question answered.
You said it very well on -buildservice:
>I think we should differentiate between
>- supported
>and
>- available for download/build
>
>I do not see anyone asking for ongoing support and maintenance. But I
>do see requests for availability.
I agree completely. I see no reason why the availability of a
particular product should be tied to the active Novell/openSUSE product
support life cycle. I think someone said it already, but never mind -
once you're running servers in a 24h production environment, changes
and upgrades are few and far between. Which is why people are still
running SUSE 6, 7 and 8. I've got a firewall still running 7.1, and a
major production system still running 8.2.
/Per Jessen, Zürich
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-project+help(a)opensuse.org
10:34 p.m.
Am Dienstag, 15. April 2008 21:58:29 schrieb Per Jessen:
Klaus Kaempf wrote:
I agree, too.
And for discontinued releases i would vote for preserving it in the
build-service one more term (e.g. 10.1 until 10.2 is discontinued).
So people have the opportunity to softly migrate.
Best regards
Jan-Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-project+help(a)opensuse.org
there's a vivid discussion on
opensuse-buildservice about the
consequenses of "end of life" announcements to the buildservice.
See
http://lists.opensuse.org/opensuse-buildservice/2008-04/msg00185.html
The question was raised if it is possible to keep older distributions
available for download (e.g. unsupported.opensuse.org) and building.
Adrian pointed to opensuse-project to get this question answered.
You said it very well on -buildservice:
>I think we should differentiate between
>- supported
>and
>- available for download/build
>
>I do not see anyone asking for ongoing support and maintenance. But I
>do see requests for availability.
I agree completely. I see no reason why the availability of a
particular product should be tied to the active Novell/openSUSE product
support life cycle. 
10:37 p.m.
On Tue, Apr 15, 2008 at 10:34:42PM +0200, Jan-Simon Möller wrote:
Am Dienstag, 15. April 2008 21:58:29 schrieb Per
Jessen:
Btw,
the buildservice could be used by community members to provide
security update services even after we discontinue it.
Just needs some volunteers. ;)
Ciao, Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-project+help(a)opensuse.org
Klaus Kaempf wrote:
I agree, too.
And for discontinued releases i would vote for preserving it in the
build-service one more term (e.g. 10.1 until 10.2 is discontinued).
So people have the opportunity to softly migrate. there's a vivid discussion on
opensuse-buildservice about the
consequenses of "end of life" announcements to the buildservice.
See
http://lists.opensuse.org/opensuse-buildservice/2008-04/msg00185.html
The question was raised if it is possible to keep older distributions
available for download (e.g. unsupported.opensuse.org) and building.
Adrian pointed to opensuse-project to get this question answered.
You said it very well on -buildservice:
>I think we should differentiate between
>- supported
>and
>- available for download/build
>
>I do not see anyone asking for ongoing support and maintenance. But I
>do see requests for availability.
I agree completely. I see no reason why the availability of a
particular product should be tied to the active Novell/openSUSE product
support life cycle.
10:44 p.m.
Am Dienstag, 15. April 2008 22:37:14 schrieb Marcus Meissner:
Btw,
the buildservice could be used by community members to provide
security update services even after we discontinue it.
Just needs some volunteers. ;)
Btw. ;)
If 10.1 gets removed, there won't be the chance for volunteers to do so.
Best regards
Jan-Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-project+help(a)opensuse.org
16 Apr
16 Apr
9 a.m.
On Tuesday 15 April 2008 22:44:39 wrote Jan-Simon Möller:
Am Dienstag, 15. April 2008 22:37:14 schrieb Marcus
Meissner:
there will. However, it is better to speak up now.
but the downside of this is (if no one wants to fix the end of life systems):
We help people run their systems after end-of-life, this mean there will be
an increasing number of systems out there where _documented_ ways to comprise
them. This means a large number of people (not only some high skilled
hackers) have the chance to steal credit card numbers, create more spam or
trash foreign data. It is one point to kill the system of someone who is
knowing that he runs an unsave system (and I think we can make this clear).
But it would be a bad press, if it is known that openSUSE systems are used
widely to attack other systems.
Don't you fear that the openSUSE project could made resonsible for that ?
--
Adrian Schroeter
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
email: adrian(a)suse.de
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-project+help(a)opensuse.org
Btw,
the buildservice could be used by community members to provide
security update services even after we discontinue it.
Just needs some volunteers. ;)
Btw. ;)
If 10.1 gets removed, there won't be the chance for volunteers to do so. 
12:38 p.m.
On Wednesday 16 April 2008 09:00:59 Adrian Schröter wrote:
Don't you fear that the openSUSE project could
made resonsible for
that ?
That's a matter of documentation and clear communication.
If it's clearly stated that the buildservice only provides the means to
build packages for that version and does not provide any extended
lifetime for the distribution itself, I don't see how anybody can be
made responsible.
And the old systems are out there already. People will just run them
unpatched. With the buildservice we at least have the chance that some
if not all issues get fixed by newer releases distributed via the
buildservice.
-Daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-project+help(a)opensuse.org
2:32 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
The Wednesday 2008-04-16 at 12:38 +0200, Daniel Rahn wrote:
And the old systems are out there already. People will
just run them
unpatched.
Many of those old systems are intranet, perhaps not much risk. And many
are old machines that simply will not run a modern version.
- --
Cheers,
Carlos E. R.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4-svn0 (GNU/Linux)
iD8DBQFIBfHRtTMYHG2NR9URAtZvAJ9z0T0l4Fo7QZQJ49MF2bxLOa1h6wCfb6WX
lUhxf0kq7WiHWTo7qnczVKk=
=ilzU
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-project+help(a)opensuse.org
3:35 p.m.
This whole thread brings back a point I've been trying to make for over
a year now. The point, openSUSE should not bother itself with LTS(long
term support) for 3 (4 if SLE counted) distributions. I say, starting
with 11.0 provide only support and fixes until 11.1(which should be an
online upgrade via zypper)then only support 11.1 until 11.2, then 11.2
until 11.3 then give 11.3 a full three years support bringing us around
to 12.3, this means that the team is only ever supporting 2 community
distro's and one enterprise at a time and the *.3s can become new
releases for SLE. This would make it clear that the other versions are
truly community and that, to get the 5+ years a server should have, a
person needs to subscribe to SLE. This should not offend openSUSE\SUSE
customers and it should please and even entice non-enterprise
subscribers to look more closely at SLE. While allowing more resources
to be available to packaging a really nice retail box for the *.3s.
Can anyone estimate the energy used to patch 10.3 that could have been
avoided if the Devs were not back porting fixes to 10.1 and 10.2, but
already working full-time on only 10.2+ when 10.3 was due to begin?
These interim releases aren't much different than a SP anyway why not
release them that way? openSUSE has a patch disk mechanism.
Does anyone else see the wheel being reinstalled every time we take the
car for a drive? Isn't a Distro that upgrades rather than replaces more
flexible for the enthusiast and more reliable to the consumer? How much
Alpha testing can be removed if *.2 truly is *.1 plus fixes?
My vision in practice:
Joe Consumer running 9.3: "Hey cool, 10.3 is out, I can't wait to see
the new .....I have been hearing a lot of cool stuff about 10 and 9 has
been so good to me!"
Joe Enthusiast running 10.2: "Hey cool, 10.3 is out, I wonder if they
included that new version of .... the one I'm running now is so buggy."
How many sour moments, defections and poor reviews concerning 10.0 could
we have been avoided? I see those reviews going from utter condemnation
to "hey guys, the new interim from openSUSE has a few bugs, but, these
guys really fix this stuff quick. check back later."
Maybe, I've just been reading to much stuff like this;
http://en.wikipedia.org/wiki/IT_Service_Management
or I could just be nuts, let me know.
--
James Tremblay
aka, SLEducator
Director of Technology
Newmarket School District
Newmarket NH 03857
Founder http://en.opensuse.org/education
"Let's make a difference!"
Registered Linux user #440182
CNE 3,4,5
CLP 9
CLE in training ;)
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-project+help(a)opensuse.org
4:15 p.m.
James Tremblay a écrit :
This whole thread brings back a point I've been
trying to make for over
a year now.
If I understand well, one distro with 3 years and two with only one year?
may be.
There is an other road we could (may be) use.
That is work more on *upgrading cleanly* a distro.
That is when 11 is out, makes it possible to upgrade from 10.3 without
fear. Possibly asking for change from kde3 to kde4 (or have them
together for some time).
and 11 to 11.1, 11.1 to 11.2 (but not 11 to 11.2)
like this we could have end of life date for *products*, not for distro.
I don't know how mozilla do the daily update they do automatically,
but I beg doing so is a way to make distro work easier, no need to
wonder about mozilla now...
I have a hosted server with 10.2, and little way to use anything else
(openSUSE). I would be much easier for me to use only one distro, but
I fear the online update...
after all, changes like kde3->kde4 or kernel 2.4->2.4 are not that
frequent
jdd
--
http://www.dodin.net
http://clairedodin.voices.com/
http://www.clairedodin.com/
http://claire.dodin.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-project+help(a)opensuse.org
18 Apr
18 Apr
12:44 p.m.
On Wednesday 16 April 2008 16:15:06 wrote jdd:
James Tremblay a écrit :
Sure, this is always wanted. But you need to take into account that this is
something we have only partly in our hands.
Enough open source projects do not care about this, so we need either to write
update scripts (to adapt a configuration for example) or ask the users to fix
it manually.
This whole thread brings back a point I've
been trying to make for over
a year now.
If I understand well, one distro with 3 years and two with only one year?
may be.
There is an other road we could (may be) use.
That is work more on *upgrading cleanly* a distro. That is when 11 is out, makes it possible to upgrade
from 10.3 without
fear. Possibly asking for change from kde3 to kde4 (or have them
together for some time).
and 11 to 11.1, 11.1 to 11.2 (but not 11 to 11.2)
like this we could have end of life date for *products*, not for distro.
I don't know how mozilla do the daily update they do automatically,
but I beg doing so is a way to make distro work easier, no need to
wonder about mozilla now...
I have a hosted server with 10.2, and little way to use anything else
(openSUSE). I would be much easier for me to use only one distro, but
I fear the online update...
k, but that will not help us to improve it ;)
after all, changes like kde3->kde4 or kernel
2.4->2.4 are not that
frequent
jdd
--
Adrian Schroeter
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
email: adrian(a)suse.de
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-project+help(a)opensuse.org
11:25 p.m.
Hello,
on Freitag, 18. April 2008, Adrian Schröter wrote:
I think the best way is something between "do everything automatically
and perfect" and "ask the user to fix it" ;-)
Of course automatically updating all config files is nice, but I also
understand that it is not always possible or too difficult.
I'm pragmatic enough to prefer a 95% working update (with 5% "ask the
user to fix it") over a wannaby-perfect update that will never be
available because it takes too much time for the developers *g*.
I always install new openSUSE versions as updates and can happily report
that things usually just work[tm]. The only exception is my radeon
xinerama setup which is well-known by several X developers at
SUSE ;-) - however, this is caused by changes in the radeon driver and
not really SUSE's fault.
OK, I have to check some *.rpmnew or *.rpmorig files after the update
(hint: diff and patch are useful utilities!) but basically the update
never broke my system and it would also have worked without checking
the *.rpm* files.
*.rpm* files usually appear if a config file was manually changed, which
means the user/admin hopefully knows what he is doing. So he should
also know how to merge the configuration to the new config files.
For normal desktop users, this also means that *.rpm* files shouldn't be
a real problem because most desktop users don't change config files
in /etc.
...
Network installation / update work, at least for me ;-)
I updated a remote web server from 10.1 to 10.2 some months ago
(installation started with a bootloader entry, network installation
source and ssh -X to start YaST).
(It is still a good idea to have a recovery system available in case
something goes wrong. I didn't need it, but better safe than sorry...)
I even had a copy of the system running in a chroot, so the websites
were available during the update ;-) (with a minor downtime for
rebooting, mounting everything and starting the services in the
chroot). [1]
That said: The easier way to go would be updating the running system.
Basically this means that "zypper dup" and its graphical variant (which
is now called "Factory update") should be officially supported for
distribution updates.
Is this possible? (Un?)fortunately I have no idea how difficult this is
on the technical side. Feel free to enlighten me ;-)
Regards,
Christian Boltz
[1] Some notes for people who want to do this:
- mount --bind /proc, /sys and /dev into the chroot, otherwise many
things won't work
- choose the services to start carefully - for example, (re)starting
rcnetwork is not the best idea ;-) because the installation system
has already done that. Also avoid ssh and the firewall.
- starting daemons like Apache, MySQL etc. shouldn't be a problem
--
Früher mußte man den Müll heimlich im Wald verbuddeln;
Heute gibt es EBAY :-) [Axel Lindlau in suse-linux]
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-project+help(a)opensuse.org
On Wednesday 16 April 2008 16:15:06 wrote jdd:
...
That is work
more on *upgrading cleanly* a distro.
Sure, this is always wanted. But you need to take into account that
this is something we have only partly in our hands.
Enough open source projects do not care about this, so we need either
to write update scripts (to adapt a configuration for example) or ask
the users to fix it manually. I have a
hosted server with 10.2, and little way to use anything
else (openSUSE). I would be much easier for me to use only one
distro, but I fear the online update...
k, but that will not help us to improve it ;)
11:41 p.m.
Christian Boltz a écrit :
OK, I have to check some *.rpmnew or *.rpmorig files
after the update
may be a central report with links to such file? I always wonder where
files where modified and where there was none. knowing when the
original file is backed up or when it's let alone and a sample file
written is also not obvious, so the use of a central log
*.rpm* files usually appear if a config file was
manually changed, which
means the user/admin hopefully knows what he is doing.
but may have done this in a hurry and forgot about that...
Network installation / update work, at least for me
;-)
remember I can't boot a cd :-(. I can only reinstall a fresh 10.2
system and start again... or boot a rescue system
one thing I don't understand: upgrade system say it must be done from
booting a cd/dvd, but we can update kernels, so why? I can update and
reboot.
I even had a copy of the system running in a chroot,
so the websites
were available during the update ;-) (with a minor downtime for
rebooting, mounting everything and starting the services in the
chroot). [1]
?? an you chroot, install a new system (for example 11)? how?
I could install in virtualbox, but the power loss is high
That said: The easier way to go would be updating the
running system.
Basically this means that "zypper dup" and its graphical variant (which
is now called "Factory update") should be officially supported for
distribution updates.
If I understand well, this is great!
[1] Some notes for people who want to do this:
do you mean you have this chrooted in an other partition?
jdd
--
http://www.dodin.net
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-project+help(a)opensuse.org
19 Apr
19 Apr
6:44 p.m.
Hello,
on Freitag, 18. April 2008, jdd wrote:
People will find the *.rpm* files as soon as some configuration differs
from what they have set up and expect *g*
Booting with a grub entry could be a solution for you. The details are
somewhere in the wiki - or just ask for an example menu.list section.
It seems I should add more details, step by step ;-)
- recommended: have some spare partition(s) available. If none is
available, a directory with enough space will do also.
- mount this partition as /oldsys (and /oldsys/var etc. if you want to
use multiple partitions)
- create an fstab entry for /oldsys (and /oldsys/var etc.)
- copy most parts of the system into /oldsys. Leave out /srv and /home
and mount --bind it later.
mount --bind of /var/lib/mysql is a bit problematic in case the
rpm %post restarts mysql. The better solution is probably to copy it
to the new system after the end of the installation, before reboot.
- create a bootloader entry for the /oldsys partition - in case
something goes wrong, you can go back faster.
- also create a bootloader entry for network installation, and activate
it with grubonce.
- boot to the installation
- start YaST
- let it mount all partitions
- mount --bind /proc, /sys and /dev into /oldsys
- chroot /oldsys
- rcapache2 start :-)
- run the installation
- remember to copy /oldsys/var/lib/mysql to the new system
Disclaimer: No warranty for completeness (I just wrote this out of my
mind) - but people who run a rootserver should notice if something is
missing or wrong and be able to do it right ;-)
I hope so ;-)
Can someone with enough technical knownledge comment about it, please?
Regards,
Christian Boltz
--
In its default setup, Windows XP on the Internet amounts to a car parked
in a bad part of town, with the doors unlocked, the key in the ignition
and a Post-It note on the dashboard saying, "Please don't steal this".
[Washington Post, 23.8.2003]
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-project+help(a)opensuse.org
Christian Boltz a écrit :
There is even an initscript (/etc/init.d/rpmconfigcheck) which reports
them - but hidden behind the nice splash screen ;-)
Maybe the better solution would be a mail to root?
I would also like to propose moving this script to another place, for
example SuSEconfig. Running it at each boot is pointless.
OK, I have to check some *.rpmnew or *.rpmorig
files after the
update
may be a central report with links to such file? I always wonder
where files where modified and where there was none. knowing when the
original file is backed up or when it's let alone and a sample file
written is also not obvious, so the use of a central log *.rpm* files
usually appear if a config file was manually changed,
which means the user/admin hopefully knows what he is doing.
but may have done this in a hurry and forgot about that... Network
installation / update work, at least for me ;-)
remember I can't boot a cd :-(. I can only reinstall a fresh 10.2
system and start again... or boot a rescue system one thing I don't understand: upgrade system say
it must be done from
booting a cd/dvd, but we can update kernels, so why? I can update and
reboot.
I also wonder about this...
I even had a
copy of the system running in a chroot, so the
websites were available during the update ;-) (with a minor
downtime for rebooting, mounting everything and starting the
services in the chroot). [1]
?? an you chroot, install a new system (for example 11)? how?
I could install in virtualbox, but the power loss is high That said: The
easier way to go would be updating the running
system. Basically this means that "zypper dup" and its graphical
variant (which is now called "Factory update") should be officially
supported for distribution updates.
If I understand well, this is great! 
7:21 p.m.
Am Samstag, 19. April 2008 schrieb Christian Boltz:
Hello,
on Freitag, 18. April 2008, jdd wrote:
Which is the reason we
don't that since about 10.0 - but people doing
update over update won't notice we change such things :)
Greetings, Stephan
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-project+help(a)opensuse.org
Christian Boltz a écrit :
There is even an initscript (/etc/init.d/rpmconfigcheck) which reports
them - but hidden behind the nice splash screen ;-)
Maybe the better solution would be a mail to root?
I would also like to propose moving this script to another place, for
example SuSEconfig. Running it at each boot is pointless. OK, I have to check some *.rpmnew or *.rpmorig
files after the
update
may be a central report with links to such file? I always wonder
where files where modified and where there was none. knowing when the
original file is backed up or when it's let alone and a sample file
written is also not obvious, so the use of a central log
11:07 p.m.
Hello,
on Samstag, 19. April 2008, Stephan Kulow wrote:
OK, you got me ;-)
I was probably worried by the fact that /etc/init.d/rpmconfigcheck still
exists (on 10.3, I'll update ;-) to 11.0 beta1 tomorrow). But yes,
according to the changelog this script isn't insserv'ed since some
years.
Regards,
Christian Boltz
--
But for now is the most important to find how to put more hours in
the day. The 24 is too little :-) [Rajko M in opensuse-wiki]
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-project+help(a)opensuse.org
Am Samstag, 19. April 2008 schrieb Christian Boltz:
> on Freitag, 18. April 2008, jdd wrote:
> > Christian Boltz a écrit :
...
There is even
an initscript (/etc/init.d/rpmconfigcheck) which
reports them - but hidden behind the nice splash screen ;-)
Maybe the better solution would be a mail to root?
I would also like to propose moving this script to another place,
for example SuSEconfig. Running it at each boot is pointless.
Which is the reason we don't that since about 10.0 - but people doing
update over update won't notice we change such things :)
21 Apr
21 Apr
1:56 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
The Saturday 2008-04-19 at 19:21 +0200, Stephan Kulow wrote:
Why? Why don't you do the change for updated systems? Or send an email to
root so that he does the change?
I do have that script, of course, my system has been updated in steps
since 8.1 to 10.3. Should I remove it?
I haven't noticed suseconfig running a similar task.
- --
Cheers,
Carlos E. R.
There is even
an initscript (/etc/init.d/rpmconfigcheck) which reports
them - but hidden behind the nice splash screen ;-)
Maybe the better solution would be a mail to root?
I would also like to propose moving this script to another place, for
example SuSEconfig. Running it at each boot is pointless.
Which is the reason we
don't that since about 10.0 - but people doing
update over update won't notice we change such things :) -----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4-svn0 (GNU/Linux)
iD8DBQFIDIDstTMYHG2NR9URAgoFAJ4z2AZVMdUGMnALXruV283piP57ZQCcDpgH
ZYttcP5W8LUZ8H7qNxACCOU=
=p/vi
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-project+help(a)opensuse.org
19 Apr
19 Apr
7:26 p.m.
Christian Boltz a écrit :
- boot to the installation
- start YaST
ssh capable? can I connect during the install part?
AFAIK, I can only start the default grub entry (I don't see any grub
boot menu !!)
- let it mount all partitions
- mount --bind /proc, /sys and /dev into /oldsys
- chroot /oldsys
this "oldsys" system seems very promising, I have to investigate :-)
>> system. Basically this means that "zypper
dup" and its graphical
as apt can do for debian... (at risk :-()
but having a backup start is nice. I should be able to setup a backup
system of my own in some partition and use the possible choice of
starting system (like the kde reboot options, I don't know how this
feature is called)
thanks for the ideas, great!
jdd
--
http://www.dodin.net
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-project+help(a)opensuse.org
11:23 p.m.
Hello,
on Samstag, 19. April 2008, jdd wrote:
Christian Boltz a écrit :
Yes, you can even use the nice graphical installer via ssh -X :-)
Please read http://en.opensuse.org/Network_Install for all the details.
- boot to the installation
- start YaST
ssh capable? can I connect during the install part? AFAIK, I can only start the default grub entry (I
don't see any grub
boot menu !!)
...
but having a backup start is nice. I should be able to
setup a backup
system of my own in some partition and use the possible choice of
starting system (like the kde reboot options, I don't know how this
feature is called)
Call "grubonce" in your existing system. It doesn't have a manpage
AFAIK, but is easy to use.
Of course, you can also change the default grub entry to point to the
installation, but this makes things more difficult if something doesn't
work.
Regards,
Christian Boltz
--
We have a "Reinheits-Gebot" (pureness requirement) in Germany per law
for beer (showing that our politicians indeed know what they talk about
on this matter) [Eberhard Moenkeberg in opensuse]
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-project+help(a)opensuse.org
20 Apr
20 Apr
9:06 a.m.
Christian Boltz a écrit :
Please read http://en.opensuse.org/Network_Install for
all the details.
oh... names are misleading! I always think this page was about using
the mini cd/network install, not the other way round!!
nice thanks
jdd
--
http://www.dodin.net
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-project+help(a)opensuse.org
16 Apr
16 Apr
6:12 p.m.
On Wed, 16 Apr 2008, James Tremblay wrote:
This whole thread brings back a point I've been trying to make for over
a year now. The point, openSUSE should not bother itself with LTS(long
term support) for 3 (4 if SLE counted) distributions. I say, starting
with 11.0 provide only support and fixes until 11.1(which should be an
online upgrade via zypper)then only support 11.1 until 11.2, then 11.2
until 11.3 then give 11.3 a full three years support bringing us around
to 12.3, this means that the team is only ever supporting 2 community
distro's and one enterprise at a time and the *.3s can become new
releases for SLE. This would make it clear that the other versions are
truly community and that, to get the 5+ years a server should have, a
person needs to subscribe to SLE. This should not offend openSUSE\SUSE
customers and it should please and even entice non-enterprise
subscribers to look more closely at SLE. While allowing more resources
to be available to packaging a really nice retail box for the *.3s.
Can anyone estimate the energy used to patch 10.3 that could have been
avoided if the Devs were not back porting fixes to 10.1 and 10.2, but
already working full-time on only 10.2+ when 10.3 was due to begin?
These interim releases aren't much different than a SP anyway why not
release them that way? openSUSE has a patch disk mechanism.
Does anyone else see the wheel being reinstalled every time we take the
car for a drive? Isn't a Distro that upgrades rather than replaces more
flexible for the enthusiast and more reliable to the consumer? How much
Alpha testing can be removed if *.2 truly is *.1 plus fixes?
My vision in practice:
Joe Consumer running 9.3: "Hey cool, 10.3 is out, I can't wait to see
the new .....I have been hearing a lot of cool stuff about 10 and 9 has
been so good to me!"
Joe Enthusiast running 10.2: "Hey cool, 10.3 is out, I wonder if they
included that new version of .... the one I'm running now is so buggy."
How many sour moments, defections and poor reviews concerning 10.0 could
we have been avoided? I see those reviews going from utter condemnation
to "hey guys, the new interim from openSUSE has a few bugs, but, these
guys really fix this stuff quick. check back later."
Maybe, I've just been reading to much stuff like this;
http://en.wikipedia.org/wiki/IT_Service_Management
or I could just be nuts, let me know.
So you want all openSUSE users to upgrade every 8 months?
That is impossible. 2 years is acceptable and sometimes even that is too
short.
Another use of e.g. 10.1 is as a additional repo for SLES10, because you
don't get all the software you need on a Server from the SLES, SLED and
SLE SDK repos.
You said x.1 should be x.0+SP. But it is hopefully not.
A SP for a SLE product does not change the kernel and probably glibc.
A newer openSUSE version always had newer Kernel, glibc, gcc, X, KDE, ...
A possible way to go is enlarging the time between releases even more. We
already moved from 6 months to 8 months. Maybe even more.
--
Mit freundlichen Gruessen,
Andreas Vetter
Fakultaet fuer Physik und Astronomie
Universitaet Wuerzburg
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-project+help(a)opensuse.org
18 Apr
18 Apr
3:23 p.m.
So you want all openSUSE users to upgrade every 8
months?
That is impossible. 2 years is acceptable and sometimes even that is too
short.
No, What I am saying is let the enthusiast upgrade every 8 months, it's
what we do anyway. Joe consumer doesn't even like to upgrade every 10
years. It was MS that brought out Vista not consumer demand. XP sp3
could have improved security just as much as Vista "uhm" does.
Another use of e.g. 10.1 is as a additional repo for SLES10, because you
don't get all the software you need on a Server from the SLES, SLED and
SLE SDK repos.
I'm not advocating the removal of the buildservice tree or the
application repository. just let the download tree for the OS and the
security\patch updates die when the next interim is available.
You said x.1 should be x.0+SP. But it is hopefully
not.
A SP for a SLE product does not change the kernel and probably glibc.
A newer openSUSE version always had newer Kernel, glibc, gcc, X, KDE, ...
SP's for SLE have little if nothing to do with the openSUSE interim
releases. The interim\new releases from any distro really are not much
more than "look what we learned last year" updates from the entire Linux
community.
A possible way to go is enlarging the time between releases even more. We
already moved from 6 months to 8 months. Maybe even more.
I disagree, extending the release schedule actually retards bug fixing
because a smaller group of users (the internal team) is working on them.
The team should merely be relieved of the burden of applying fixes to
older versions of the kernel\glibc\X\KDE\Gnome that came with the
previous interim. Because as you point out, the interim may have a
different kernel and a security fix for a x.1 that may need to be
applied to an x.0 may need a completely different solution to solve the
same issue. This wastes valuable development cycles.
--
James Tremblay
aka, SLEducator
Director of Technology
Newmarket School District
Newmarket NH 03857
Founder http://en.opensuse.org/education
"Let's make a difference!"
Registered Linux user #440182
CNE 3,4,5
CLP 9
CLE in training ;)
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-project+help(a)opensuse.org
16 Apr
16 Apr
12:10 p.m.
Marcus Meissner wrote:
the buildservice could be used by community members to
provide
security update services even after we discontinue it.
Just needs some volunteers. ;)
Rebuilding newer versions for older distributions is in a way a security
update service. One might need to update his config files or get used to
a slightly different behavior, but it plugs security holes. E.g. for
someone using a 10.0 at home for web broswing and reading mail with
Firefox and Thunderbird, Wolfgang's mozilla project might be a good
enough update service. Better than nothing at least.
So there are volunteers already :), they don't cover the whole code base
of course...
Michal
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-project+help(a)opensuse.org
12:39 p.m.
* Jan-Simon Möller <dl9pf(a)gmx.de> [Apr 15. 2008 22:35]:
And for discontinued releases i would vote for preserving it in the
build-service one more term (e.g. 10.1 until 10.2 is discontinued).
So people have the opportunity to softly migrate.
Are we so limited on disk space nowadays ?
One uinque feature of the openSUSE build service could just be
availability of a lot of 'old' distributions combined with the ability
to build packages for them.
Klaus
---
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-project+help(a)opensuse.org
4655
days inactive
4661
days old
23 comments
13 participants
participants (13)
-
Adrian Schröter -
Andreas Vetter -
Carlos E. R. -
Christian Boltz -
Daniel Rahn -
James Tremblay -
Jan-Simon Möller -
jdd -
Klaus Kaempf -
Marcus Meissner -
Michal Marek -
Per Jessen -
Stephan Kulow