[opensuse-project] End of life - what does it mean ?
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@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
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@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Am Dienstag, 15. April 2008 21:58:29 schrieb Per Jessen:
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 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@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
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:
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 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.
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@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
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@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Tuesday 15 April 2008 22:44:39 wrote Jan-Simon Möller:
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.
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@suse.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
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@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
-----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@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
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@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
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@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Wednesday 16 April 2008 16:15:06 wrote jdd:
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.
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.
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@suse.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Hello, on Freitag, 18. April 2008, Adrian Schröter wrote:
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 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. ...
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 ;)
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@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
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@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Hello, on Freitag, 18. April 2008, jdd wrote:
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
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.
*.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...
People will find the *.rpm* files as soon as some configuration differs from what they have set up and expect *g*
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
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.
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
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 ;-)
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!
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@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Am Samstag, 19. April 2008 schrieb Christian Boltz:
Hello,
on Freitag, 18. April 2008, jdd wrote:
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
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 :)
Greetings, Stephan --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Hello, on Samstag, 19. April 2008, Stephan Kulow wrote:
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 :)
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@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Saturday 2008-04-19 at 19:21 +0200, Stephan Kulow wrote:
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 :)
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. -----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@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
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@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Hello, on Samstag, 19. April 2008, jdd wrote:
Christian Boltz a écrit :
- boot to the installation - start YaST
ssh capable? can I connect during the install part?
Yes, you can even use the nice graphical installer via ssh -X :-) Please read http://en.opensuse.org/Network_Install for all the details.
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@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
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@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
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@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
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@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
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@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
* Jan-Simon Möller
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@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
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