A friend forwarded me this blog: http://www.gdt.id.au/~gdt/blog/linux/autodeath.1024px
and I wondered if it would be something to consider for fedora releases.
This would NOT be as a default, but as a package you can install, if you wish, to drop the route on your box after whatever expiration date. We can set the release date in a file in the package and key from there.
If the package was included in a fedora repo we could have it have a death date of whenever the release started + 14months (some wiggle room for release slips) for example.
Any thoughts? -sv
A friend forwarded me this blog: http://www.gdt.id.au/~gdt/blog/linux/autodeath.1024px
and I wondered if it would be something to consider for fedora releases.
This would NOT be as a default, but as a package you can install, if you wish, to drop the route on your box after whatever expiration date. We can set the release date in a file in the package and key from there.
I agree that it should not be a default, but if you're not conscientious enough to patch, you're not going to be installing this package, either, and we're back to the original issue.
Other than that, it's an intriguing concept.
If the package was included in a fedora repo we could have it have a death date of whenever the release started + 14months (some wiggle room for release slips) for example.
Any thoughts? -sv
-- I only speak for me.
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
On Wed, 2008-08-20 at 14:02 -0500, Jon Ciesla wrote:
A friend forwarded me this blog: http://www.gdt.id.au/~gdt/blog/linux/autodeath.1024px
and I wondered if it would be something to consider for fedora releases.
This would NOT be as a default, but as a package you can install, if you wish, to drop the route on your box after whatever expiration date. We can set the release date in a file in the package and key from there.
I agree that it should not be a default, but if you're not conscientious enough to patch, you're not going to be installing this package, either, and we're back to the original issue.
Other than that, it's an intriguing concept.
I guess it is useful in the case that e.g. a sysadmin consciously wants to remember to remove a system from production/upgrade it after a certain time but then loses track or it, or whatever else. Not every environment has centralized tracking and management of systems :)
Jon.
seth vidal wrote:
A friend forwarded me this blog: http://www.gdt.id.au/~gdt/blog/linux/autodeath.1024px
and I wondered if it would be something to consider for fedora releases.
This would NOT be as a default, but as a package you can install, if you wish, to drop the route on your box after whatever expiration date. We can set the release date in a file in the package and key from there.
If the package was included in a fedora repo we could have it have a death date of whenever the release started + 14months (some wiggle room for release slips) for example.
Any thoughts?
I think it is much better to hookup preupgrade with PackageKit so you get notification on your desktop when there is a new release and a easy path to do so. Notifying and encouraging users to upgrade would solve the problem of people sticking to old unmaintained releases in a much nicer way.
Rahul
seth vidal wrote:
A friend forwarded me this blog: http://www.gdt.id.au/~gdt/blog/linux/autodeath.1024px
and I wondered if it would be something to consider for fedora releases.
This would NOT be as a default, but as a package you can install, if you wish, to drop the route on your box after whatever expiration date. We can set the release date in a file in the package and key from there.
If the package was included in a fedora repo we could have it have a death date of whenever the release started + 14months (some wiggle room for release slips) for example.
Any thoughts?
I think it is much better to hookup preupgrade with PackageKit so you get notification on your desktop when there is a new release and a easy path to do so. Notifying and encouraging users to upgrade would solve the problem of people sticking to old unmaintained releases in a much nicer way.
+1 Sounds like a job for the LiveUpgrade SIG.
http://fedoraproject.org/wiki/SIGs/LiveUpgrade
Rahul
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
On Wed, Aug 20, 2008 at 3:16 PM, Jon Ciesla limb@jcomserv.net wrote:
No, LiveUpgrade is a different (and IMO, bad/difficult-to-support) idea. PreUpgrade is here: http://fedoraproject.org/wiki/Anaconda/Features/PreUpgrade
On Wed, Aug 20, 2008 at 3:16 PM, Jon Ciesla limb@jcomserv.net wrote:
No, LiveUpgrade is a different (and IMO, bad/difficult-to-support) idea. PreUpgrade is here: http://fedoraproject.org/wiki/Anaconda/Features/PreUpgrade
I understand the distinction between the two, and the use cases differ. I think notification of a new release would benefit both.
On Thu, Aug 21, 2008 at 12:43:18AM +0530, Rahul Sundaram wrote:
seth vidal wrote:
A friend forwarded me this blog: http://www.gdt.id.au/~gdt/blog/linux/autodeath.1024px
and I wondered if it would be something to consider for fedora releases.
This would NOT be as a default, but as a package you can install, if you wish, to drop the route on your box after whatever expiration date. We can set the release date in a file in the package and key from there.
If the package was included in a fedora repo we could have it have a death date of whenever the release started + 14months (some wiggle room for release slips) for example.
Any thoughts?
I think it is much better to hookup preupgrade with PackageKit so you get notification on your desktop
Desktop machines typically aren't the problem in the 'setup once, and left abandoned running out of date code past EOL' scenario.
Dave
On Wed, Aug 20, 2008 at 2:09 PM, Dave Jones davej@redhat.com wrote:
On Thu, Aug 21, 2008 at 12:43:18AM +0530, Rahul Sundaram wrote:
seth vidal wrote:
A friend forwarded me this blog: http://www.gdt.id.au/~gdt/blog/linux/autodeath.1024px
and I wondered if it would be something to consider for fedora releases.
This would NOT be as a default, but as a package you can install, if you wish, to drop the route on your box after whatever expiration date. We can set the release date in a file in the package and key from there.
If the package was included in a fedora repo we could have it have a death date of whenever the release started + 14months (some wiggle room for release slips) for example.
Any thoughts?
I think it is much better to hookup preupgrade with PackageKit so you get notification on your desktop
Desktop machines typically aren't the problem in the 'setup once, and left abandoned running out of date code past EOL' scenario.
Oh I wouldn't be so sure.. We supposedly have over a hundred Windows 3.11 clients on our network.
On Wednesday, 20 August 2008 at 22:09, Dave Jones wrote:
On Thu, Aug 21, 2008 at 12:43:18AM +0530, Rahul Sundaram wrote:
seth vidal wrote:
A friend forwarded me this blog: http://www.gdt.id.au/~gdt/blog/linux/autodeath.1024px
and I wondered if it would be something to consider for fedora releases.
This would NOT be as a default, but as a package you can install, if you wish, to drop the route on your box after whatever expiration date. We can set the release date in a file in the package and key from there.
If the package was included in a fedora repo we could have it have a death date of whenever the release started + 14months (some wiggle room for release slips) for example.
Any thoughts?
I think it is much better to hookup preupgrade with PackageKit so you get notification on your desktop
Desktop machines typically aren't the problem in the 'setup once, and left abandoned running out of date code past EOL' scenario.
You'd be surprised. I know people still running FC-2 at home, because it still works and they can't be bothered to upgrade.
Regards, R.
On Wed, 2008-08-20 at 16:09 -0400, Dave Jones wrote:
On Thu, Aug 21, 2008 at 12:43:18AM +0530, Rahul Sundaram wrote:
seth vidal wrote:
A friend forwarded me this blog: http://www.gdt.id.au/~gdt/blog/linux/autodeath.1024px
and I wondered if it would be something to consider for fedora releases.
This would NOT be as a default, but as a package you can install, if you wish, to drop the route on your box after whatever expiration date. We can set the release date in a file in the package and key from there.
If the package was included in a fedora repo we could have it have a death date of whenever the release started + 14months (some wiggle room for release slips) for example.
Any thoughts?
I think it is much better to hookup preupgrade with PackageKit so you get notification on your desktop
Desktop machines typically aren't the problem in the 'setup once, and left abandoned running out of date code past EOL' scenario.
I agree here. I wasn't as worried about desktops as servers/appliance-like machines.
I put it down on my list to look at putting a simple cron job together in a package to do this.
If anyone wants to do this before I do, please feel free, otherwise, I'll get to it when I can.
thanks, -sv
Dave Jones wrote:
Desktop machines typically aren't the problem in the 'setup once, and left abandoned running out of date code past EOL' scenario.
Considering the typical Fedora audience and my experience, I would say desktop systems certainly are part of the target that you would want to address.
Rahul
On Wed, Aug 20, 2008 at 04:09:11PM -0400, Dave Jones wrote:
Desktop machines typically aren't the problem in the 'setup once, and left abandoned running out of date code past EOL' scenario.
They sure are around here.
On Thu, 2008-08-21 at 00:43 +0530, Rahul Sundaram wrote:
I think it is much better to hookup preupgrade with PackageKit so you get notification on your desktop when there is a new release and a easy path to do so. Notifying and encouraging users to upgrade would solve the problem of people sticking to old unmaintained releases in a much nicer way.
Funny you say that, we added functionality to do this about 2 days ago. The daemon parts are in place, we just have to write the yum code (copy out of preupgrade) and then launch preupgrade when we show the user some new UI.
Richard
Richard Hughes wrote:
On Thu, 2008-08-21 at 00:43 +0530, Rahul Sundaram wrote:
I think it is much better to hookup preupgrade with PackageKit so you get notification on your desktop when there is a new release and a easy path to do so. Notifying and encouraging users to upgrade would solve the problem of people sticking to old unmaintained releases in a much nicer way.
Funny you say that, we added functionality to do this about 2 days ago. The daemon parts are in place, we just have to write the yum code (copy out of preupgrade) and then launch preupgrade when we show the user some new UI.
Yes, I filed a RFE against packagekit and posted to the packagekit development list about this since a number of distributions are developing preupgrade like solutions and a common framework was needed. Thanks for doing this.
Rahul
Rahul Sundaram sundaram@fedoraproject.org wrote:
seth vidal wrote:
A friend forwarded me this blog: http://www.gdt.id.au/~gdt/blog/linux/autodeath.1024px and I wondered if it would be something to consider for fedora releases. This would NOT be as a default, but as a package you can install, if you wish, to drop the route on your box after whatever expiration date. We can set the release date in a file in the package and key from there. If the package was included in a fedora repo we could have it have a death date of whenever the release started + 14months (some wiggle room for release slips) for example. Any thoughts?
I think it is much better to hookup preupgrade with PackageKit so you get notification on your desktop when there is a new release and a easy path to do so. Notifying and encouraging users to upgrade would solve the problem of people sticking to old unmaintained releases in a much nicer way.
Also, some people I know stick to old versions for (closed source or inhouse developed) software that is hard/impossible to port forward, or just random inconsistencies between versions (automount troubles between CentOS 5, CentOS 4, Fedora 8 and 9 here were a recent example; we are working on open source related to the ALMA radioastronomy observatory, there they are still running ancient Red Hat Enterprise Linux versions due to software written in "C++" as understood by old GCC, newer GCCs just barf at the code and rewriting/retesting that huge mess is a titanic job just now really underway).
On philosophical grounds, I'm against forcing people forward, even for their own good... /encouraging/ them forward is a much better idea.
[Most tyrannies tried to force people "for their own good", some did it perhaps even in (mistaken?) good faith, a few were even right in this...]
Horst H. von Brand wrote:
Also, some people I know stick to old versions for (closed source or inhouse developed) software that is hard/impossible to port forward, or just random inconsistencies between versions (automount troubles between CentOS 5, CentOS 4, Fedora 8 and 9 here were a recent example; we are working on open source related to the ALMA radioastronomy observatory, there they are still running ancient Red Hat Enterprise Linux versions due to software written in "C++" as understood by old GCC, newer GCCs just barf at the code and rewriting/retesting that huge mess is a titanic job just now really underway).
On philosophical grounds, I'm against forcing people forward, even for their own good... /encouraging/ them forward is a much better idea.
Well, forcing people forward would be making the autodeath package (or whatnot) not removable. Even if it were installed by default (which would surprise me, admittedly), one could always remove or disable it.
Jima
On Thu, 2008-08-21 at 10:01 -0500, Jima wrote:
Horst H. von Brand wrote:
Also, some people I know stick to old versions for (closed source or inhouse developed) software that is hard/impossible to port forward, or just random inconsistencies between versions (automount troubles between CentOS 5, CentOS 4, Fedora 8 and 9 here were a recent example; we are working on open source related to the ALMA radioastronomy observatory, there they are still running ancient Red Hat Enterprise Linux versions due to software written in "C++" as understood by old GCC, newer GCCs just barf at the code and rewriting/retesting that huge mess is a titanic job just now really underway).
On philosophical grounds, I'm against forcing people forward, even for their own good... /encouraging/ them forward is a much better idea.
Well, forcing people forward would be making the autodeath package (or whatnot) not removable. Even if it were installed by default (which would surprise me, admittedly), one could always remove or disable it.
Let's be very clear, In my original suggestion I said I would NOT recommend installing this package by default.
that's not w/ a capital no. :)
-sv
Seth Vidal skvidal@fedoraproject.org wrote:
On Thu, 2008-08-21 at 10:01 -0500, Jima wrote:
Horst H. von Brand wrote:
Also, some people I know stick to old versions for (closed source or inhouse developed) software that is hard/impossible to port forward, or just random inconsistencies between versions (automount troubles between CentOS 5, CentOS 4, Fedora 8 and 9 here were a recent example; we are working on open source related to the ALMA radioastronomy observatory, there they are still running ancient Red Hat Enterprise Linux versions due to software written in "C++" as understood by old GCC, newer GCCs just barf at the code and rewriting/retesting that huge mess is a titanic job just now really underway).
On philosophical grounds, I'm against forcing people forward, even for their own good... /encouraging/ them forward is a much better idea.
Well, forcing people forward would be making the autodeath package (or whatnot) not removable. Even if it were installed by default (which would surprise me, admittedly), one could always remove or disable it.
Let's be very clear, In my original suggestion I said I would NOT recommend installing this package by default.
that's not w/ a capital no. :)
OK, understood. But it gives out free rope for later hanging... i.e., I go ahead and install shiny new Fedora 11 + autodeath (cool new feature, "I'll never paint myself into a corner" are famous last words, and all that), and forget about it... some 2 years later, the machine has acquired barnacles in form of un-forward-portable stuff, Fedora 13 shows up and the system kills itself.
If anything, do a nag screen when EOL nears, offer to set up for upgrade, show (current) pointers to scripts helping check if 3rd party stuff will still work, ... install /that/ by default, allow to disable/uninstall it (even while it is nagging).
On Thu, 2008-08-21 at 17:54 -0400, Horst H. von Brand wrote:
Seth Vidal skvidal@fedoraproject.org wrote:
On Thu, 2008-08-21 at 10:01 -0500, Jima wrote:
Horst H. von Brand wrote:
Also, some people I know stick to old versions for (closed source or inhouse developed) software that is hard/impossible to port forward, or just random inconsistencies between versions (automount troubles between CentOS 5, CentOS 4, Fedora 8 and 9 here were a recent example; we are working on open source related to the ALMA radioastronomy observatory, there they are still running ancient Red Hat Enterprise Linux versions due to software written in "C++" as understood by old GCC, newer GCCs just barf at the code and rewriting/retesting that huge mess is a titanic job just now really underway).
On philosophical grounds, I'm against forcing people forward, even for their own good... /encouraging/ them forward is a much better idea.
Well, forcing people forward would be making the autodeath package (or whatnot) not removable. Even if it were installed by default (which would surprise me, admittedly), one could always remove or disable it.
Let's be very clear, In my original suggestion I said I would NOT recommend installing this package by default.
that's not w/ a capital no. :)
OK, understood. But it gives out free rope for later hanging... i.e., I go ahead and install shiny new Fedora 11 + autodeath (cool new feature, "I'll never paint myself into a corner" are famous last words, and all that), and forget about it... some 2 years later, the machine has acquired barnacles in form of un-forward-portable stuff, Fedora 13 shows up and the system kills itself.
What the hell do you mean kills itself?
All it does is disable the default route.
-sv
On Thu, Aug 21, 2008 at 05:56:08PM -0400, seth vidal wrote:
What the hell do you mean kills itself? All it does is disable the default route.
Maybe the name is too dramatic. I suggest "fedora-end-of-life-safety-net".
Hi.
On Thu, 21 Aug 2008 20:42:00 -0400, Matthew Miller wrote:
Maybe the name is too dramatic. I suggest "fedora-end-of-life-safety-net".
fedora-for-the-good-of-all-of-us
fedora-for-the-greater-good
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
On Fri, 2008-08-22 at 09:36 -0500, Jon Ciesla wrote:
Hi.
On Thu, 21 Aug 2008 20:42:00 -0400, Matthew Miller wrote:
Maybe the name is too dramatic. I suggest "fedora-end-of-life-safety-net".
fedora-for-the-good-of-all-of-us
fedora-for-the-greater-good
fedora-take-one-for-the-team?
-sv
On Fri, Aug 22, 2008 at 04:32:33PM +0200, Ralf Ertzinger wrote:
Hi.
On Thu, 21 Aug 2008 20:42:00 -0400, Matthew Miller wrote:
Maybe the name is too dramatic. I suggest "fedora-end-of-life-safety-net".
fedora-for-the-good-of-all-of-us
Please... don't encourage the bike shed discussions.
josh
On Fri, Aug 22, 2008 at 10:53:46AM -0400, Josh Boyer wrote:
On Thu, 21 Aug 2008 20:42:00 -0400, Matthew Miller wrote:
Maybe the name is too dramatic. I suggest "fedora-end-of-life-safety-net".
fedora-for-the-good-of-all-of-us
Please... don't encourage the bike shed discussions.
Yes yes that's nice. But I'm serious.
Also Fedora sometimes lacks the latest packages of something for *many* releases. Take TeX for example. I've not upgraded my laptop, which I use mostly for typesetting from FC5 until F9 came out. Why? I've manually upgraded some LaTeX packages (and yes I reaaally had to delete the old ones, not just install the new ones privately). Anything in between FC6-FC8 would have been a downgrade for my laptop. It looks like the history is going to repeat itself with F10 and TeXLive 2008, but I'm digressing...
On Thu, Aug 21, 2008 at 5:39 PM, Horst H. von Brand vonbrand@inf.utfsm.cl wrote:
Rahul Sundaram sundaram@fedoraproject.org wrote:
seth vidal wrote:
A friend forwarded me this blog: http://www.gdt.id.au/~gdt/blog/linux/autodeath.1024px and I wondered if it would be something to consider for fedora releases. This would NOT be as a default, but as a package you can install, if you wish, to drop the route on your box after whatever expiration date. We can set the release date in a file in the package and key from there. If the package was included in a fedora repo we could have it have a death date of whenever the release started + 14months (some wiggle room for release slips) for example. Any thoughts?
I think it is much better to hookup preupgrade with PackageKit so you get notification on your desktop when there is a new release and a easy path to do so. Notifying and encouraging users to upgrade would solve the problem of people sticking to old unmaintained releases in a much nicer way.
Also, some people I know stick to old versions for (closed source or inhouse developed) software that is hard/impossible to port forward, or just random inconsistencies between versions (automount troubles between CentOS 5, CentOS 4, Fedora 8 and 9 here were a recent example; we are working on open source related to the ALMA radioastronomy observatory, there they are still running ancient Red Hat Enterprise Linux versions due to software written in "C++" as understood by old GCC, newer GCCs just barf at the code and rewriting/retesting that huge mess is a titanic job just now really underway).
On philosophical grounds, I'm against forcing people forward, even for their own good... /encouraging/ them forward is a much better idea.
[Most tyrannies tried to force people "for their own good", some did it perhaps even in (mistaken?) good faith, a few were even right in this...] -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile 2340000 Fax: +56 32 2797513
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
On Thu, Aug 21, 2008 at 06:03:01PM +0300, Vasile Gaburici wrote:
Also Fedora sometimes lacks the latest packages of something for *many* releases. Take TeX for example. I've not upgraded my laptop, which I use mostly for typesetting from FC5 until F9 came out. Why? I've manually upgraded some LaTeX packages (and yes I reaaally had to delete the old ones, not just install the new ones privately). Anything in between FC6-FC8 would have been a downgrade for my laptop. It looks like the history is going to repeat itself with F10 and TeXLive 2008, but I'm digressing...
Wouldn't your efforts be better spent helping to get TexLive 2008 in F10? Or maybe I should say "would have been better spent" at this point since it may be too late for F10.
You're probably unaware (because you haven't read my emails to this list) that with the 2008 edition TeXLive changed their packaging system significantly. They now allow incremental upgades of their packages.
If Fedora just did a rehash of how TeXLive 2007 is packaged I woudln't use it, because it won't allow fine-grained upgrades. It takes significant effort, even with automated tools to package and *test* 1500 rpms. AFAICT that's more than Fedora's repository currently has. And I can't justify the time this would take me. TeXLive's package manager is not as good a rpm, but the new 2008 version of it (finally) knows what a dependency is.
Besides, if *I* were to submit 1500 packages for review, they'd take 100+ years to get done at the rate at which my packages got reviewed. Flamesuit on.
On Thu, Aug 21, 2008 at 6:21 PM, Chuck Anderson cra@wpi.edu wrote:
On Thu, Aug 21, 2008 at 06:03:01PM +0300, Vasile Gaburici wrote:
Also Fedora sometimes lacks the latest packages of something for *many* releases. Take TeX for example. I've not upgraded my laptop, which I use mostly for typesetting from FC5 until F9 came out. Why? I've manually upgraded some LaTeX packages (and yes I reaaally had to delete the old ones, not just install the new ones privately). Anything in between FC6-FC8 would have been a downgrade for my laptop. It looks like the history is going to repeat itself with F10 and TeXLive 2008, but I'm digressing...
Wouldn't your efforts be better spent helping to get TexLive 2008 in F10? Or maybe I should say "would have been better spent" at this point since it may be too late for F10.
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
On Thu, 2008-08-21 at 18:38 +0300, Vasile Gaburici wrote:
You're probably unaware (because you haven't read my emails to this list) that with the 2008 edition TeXLive changed their packaging system significantly. They now allow incremental upgades of their packages.
You may be unaware of how long it takes to legally audit TeXLive before we can let it into Fedora. Last time, the number of things which were not kosher were in the double digits.
With all the other fires that I've had to put out lately, I haven't had time to even start on TeXLive 2008, which is the primary roadblock to inclusion in F10.
~spot
Le jeudi 21 août 2008 à 11:43 -0400, Tom "spot" Callaway a écrit :
On Thu, 2008-08-21 at 18:38 +0300, Vasile Gaburici wrote:
You're probably unaware (because you haven't read my emails to this list) that with the 2008 edition TeXLive changed their packaging system significantly. They now allow incremental upgades of their packages.
You may be unaware of how long it takes to legally audit TeXLive before we can let it into Fedora. Last time, the number of things which were not kosher were in the double digits.
With all the other fires that I've had to put out lately, I haven't had time to even start on TeXLive 2008, which is the primary roadblock to inclusion in F10.
This is one more reason to modularise this beast in separate packages, so the legal problems can be isolated and not block the rest from updating
On Thu, Aug 21, 2008 at 10:39:16AM -0400, Horst H. von Brand wrote:
On philosophical grounds, I'm against forcing people forward, even for their own good... /encouraging/ them forward is a much better idea.
It's not for their good. It's for *our* good as distribution developers and as network citizens.
And it's part of our responsibility: we're putting powerful software into their hands and then not providing security updates for it for very long at all. Turning off network access before they all become part of a gigantic botnet is the right thing to do.
Hi.
On Thu, 21 Aug 2008 12:02:27 -0400, Matthew Miller wrote
And it's part of our responsibility: we're putting powerful software into their hands and then not providing security updates for it for very long at all. Turning off network access before they all become part of a gigantic botnet is the right thing to do.
Well, as long as the project per se exists we do provide updates. Sometimes it's to a new major release.
Matthew Miller wrote:
On Thu, Aug 21, 2008 at 10:39:16AM -0400, Horst H. von Brand wrote:
On philosophical grounds, I'm against forcing people forward, even for their own good... /encouraging/ them forward is a much better idea.
It's not for their good. It's for *our* good as distribution developers and as network citizens.
And it's part of our responsibility: we're putting powerful software into their hands and then not providing security updates for it for very long at all. Turning off network access before they all become part of a gigantic botnet is the right thing to do.
Informing people of the dangers is the right thing to do, forcing them down your path is never the right thing to do.
On Thu, 2008-08-21 at 14:22 -0400, max wrote:
Matthew Miller wrote:
On Thu, Aug 21, 2008 at 10:39:16AM -0400, Horst H. von Brand wrote:
On philosophical grounds, I'm against forcing people forward, even for their own good... /encouraging/ them forward is a much better idea.
It's not for their good. It's for *our* good as distribution developers and as network citizens.
And it's part of our responsibility: we're putting powerful software into their hands and then not providing security updates for it for very long at all. Turning off network access before they all become part of a gigantic botnet is the right thing to do.
Informing people of the dangers is the right thing to do, forcing them down your path is never the right thing to do.
unless you're a sysadmin for a large university, for example.
-sv
Seth Vidal skvidal@fedoraproject.org wrote:
On Thu, 2008-08-21 at 14:22 -0400, max wrote:
Matthew Miller wrote:
On Thu, Aug 21, 2008 at 10:39:16AM -0400, Horst H. von Brand wrote:
On philosophical grounds, I'm against forcing people forward, even for their own good... /encouraging/ them forward is a much better idea.
It's not for their good. It's for *our* good as distribution developers and as network citizens.
And it's part of our responsibility: we're putting powerful software into their hands and then not providing security updates for it for very long at all. Turning off network access before they all become part of a gigantic botnet is the right thing to do.
Informing people of the dangers is the right thing to do, forcing them down your path is never the right thing to do.
unless you're a sysadmin for a large university, for example.
Hum... if you mean the sysadmin in such a case /has/ to force-feed updates to the systems under her care (or be shot at dawn without trial), you are right. If you mean sysadmins at large universities should be forced to update the systems under their care, I'd guess they don't need any "forcing", they'll do it on their own (or pay dire consequences long before the next Fedora rolls along ;-)
On Thu, Aug 21, 2008 at 02:22:41PM -0400, max wrote:
Informing people of the dangers is the right thing to do, forcing them down your path is never the right thing to do.
Here's the thing: they're on that path, the path we put them on by making Fedora so attractive. The path, however, leads to the top of a big cliff, below which swim hungry sharks. We should definitely put some signs at the top of the cliff. And we should do this: put a net to catch anyone who falls over anyway.
Matthew Miller wrote:
On Thu, Aug 21, 2008 at 02:22:41PM -0400, max wrote:
Informing people of the dangers is the right thing to do, forcing them down your path is never the right thing to do.
Here's the thing: they're on that path, the path we put them on by making
No. People choose Fedora and if they choose not to inform themselves that's their problem. We have to live with our choices that's an integral part of being free. If you need someone to make your decisions for you then go live somewhere that is the accepted ideal. I am not a robot and I won't stand for being treated like one. I have to make my own mistakes, learn from them and move on.
Fedora so attractive. The path, however, leads to the top of a big cliff, below which swim hungry sharks. We should definitely put some signs at the top of the cliff. And we should do this: put a net to catch anyone who falls over anyway.
Posting signs is one thing but if your informed that your coming up on a cliff and you keep the gas pedal to the floor then good riddance. Stupidity inspires its own demise, you start holding hands here and you'll never stop. People have to learn to accept the consequences of their actions and how to deal with the aftermath of bad judgement calls. You cannot have a free society otherwise. Ultimately that is what this is about, its not a matter of technical details it can be done, just because you can doesn't mean you should. You've been informed, now you must decide, that is the price of freedom and it cannot be avoided.
On Thu, Aug 21, 2008 at 8:51 PM, Matthew Miller mattdm@mattdm.org wrote:
On Thu, Aug 21, 2008 at 02:22:41PM -0400, max wrote:
Informing people of the dangers is the right thing to do, forcing them down your path is never the right thing to do.
Here's the thing: they're on that path, the path we put them on by making Fedora so attractive. The path, however, leads to the top of a big cliff, below which swim hungry sharks. We should definitely put some signs at the top of the cliff. And we should do this: put a net to catch anyone who falls over anyway.
If preventing network access is a good thing to do at end of life, shouldn't security updates be forced on users as well. If security updates aren't going to be mandatory, perhaps the system should use the autodie measures every few months to prevent network access as well. Un-applied security patches are just as bad as using an EOL system.
Also, I don't think that removal of a default route goes far enough. If there's one EOL system on the network, there are probably more. All networking should be disabled. Otherwise, a user may re-enable one machine only to have it compromised. The exploit could search out other machines on the local network, re-enable their default routes and use them for its nefarious purposes.
-- James Hubbard
On Thu, Aug 21, 2008 at 8:02 AM, Matthew Miller mattdm@mattdm.org wrote:
And it's part of our responsibility: we're putting powerful software into their hands and then not providing security updates for it for very long at all. Turning off network access before they all become part of a gigantic botnet is the right thing to do.
I think there is an argument to be made to encourage our users to choose responsible use of technology. A part of that is adequate education as to what responsibility actually means in context of making a personal choice. I'm not sure all efforts to disseminate best practises are always best achieved by silently active enforcement policies which do not have a timely educational component meant to educate the system admin or user when the enforcement engages.
Now I'm not saying we shouldn't consider doing something by default. I would think that something designed as autoannoy instead of autodeath would be more appropriate.
For desktop machines..hooking the concept behind autodeath into packagekit to give users a choice to use preupgrade or turn off the network..seems pretty reasonable...and it seems people are already thinking hard about that particular usage case.
For machines which aren't meant to be used like a desktop... remotely hosted machines with ssh remote logins or whatnot...would it be reasonable to have autoannoy change the motd or message at login to indicate to remotely logged in users that the machine is no longer able to receive updates and communicate the associated risks of that situation? Thus informing users of such remotely located Fedora systems that they need to take action, or their hosting company needs to take action...but without locking them out of the system entirely by bringing the network down? How many hosting companies out there sell access to Fedora systems to people without adequately informing them as to the EOL policies and are willing to continue to take money to host EOL'd Fedora systems with no due diligence on their part as a hosting company to help their clients handle Fedora release EOL? Can we give users of systems like that enough information to take steps to rectify the EOL related problems their hosting company didn't prepare them for.. without arbitrarily shutting them out of their own systems?
-jef
On Wed, Aug 20, 2008 at 02:57:17PM -0400, seth vidal wrote:
A friend forwarded me this blog: http://www.gdt.id.au/~gdt/blog/linux/autodeath.1024px and I wondered if it would be something to consider for fedora releases.
PLUS EIGHT MILLION.
On Wed, Aug 20, 2008 at 2:57 PM, seth vidal skvidal@fedoraproject.org wrote:
A friend forwarded me this blog: http://www.gdt.id.au/~gdt/blog/linux/autodeath.1024px
and I wondered if it would be something to consider for fedora releases.
This would NOT be as a default, but as a package you can install, if you wish, to drop the route on your box after whatever expiration date. We can set the release date in a file in the package and key from there.
If the package was included in a fedora repo we could have it have a death date of whenever the release started + 14months (some wiggle room for release slips) for example.
Any thoughts?
Sounds a lot like Windows Genuine Advantage where you can't use your machine anymore if you can't validate your installation. Someone (probably many someones) will install this by mistake and there will be a lot of screaming that not even Microsoft will disable your OS if it is running past the EOL/support period.
It would probably be better that during the last batch of updates a small program gets installed that will notify users when they login that the system is no longer supported. This could be in a terminal, a "balloon" in X, or a message on the X login screen.
Whatever is implemented, should be given a lot of thought and it should disable the system in any manner. It could alienate a lot of users. I haven't upgraded my work machine from F7 to F9 yet because I've not yet had time to test gcc 4.3 with some commercial libraries that have only been compiled against gcc 4.1.x. I know lots of other desktop/server users that are running system from FC2 - FC6. (Yes I know about RHEL.)
(As a side note: My wife hates the security balloons that pop up when there's a security related update. She's always comparing it to windows. )
My $0.02.
-- James Hubbard
Quoth James Hubbard:
On Wed, Aug 20, 2008 at 2:57 PM, seth vidal skvidal@fedoraproject.org
wrote:
A friend forwarded me this blog: http://www.gdt.id.au/~gdt/blog/linux/autodeath.1024px
and I wondered if it would be something to consider for fedora releases.
This would NOT be as a default, but as a package you can install, if you wish, to drop the route on your box after whatever expiration date. We can set the release date in a file in the package and key from there.
If the package was included in a fedora repo we could have it have a death date of whenever the release started + 14months (some wiggle room for release slips) for example.
Any thoughts?
Sounds a lot like Windows Genuine Advantage where you can't use your machine anymore if you can't validate your installation. Someone (probably many someones) will install this by mistake and there will be a lot of screaming that not even Microsoft will disable your OS if it is running past the EOL/support period.
It would probably be better that during the last batch of updates a small program gets installed that will notify users when they login that the system is no longer supported. This could be in a terminal, a "balloon" in X, or a message on the X login screen.
Whatever is implemented, should be given a lot of thought and it should disable the system in any manner. It could alienate a lot of users. I haven't upgraded my work machine from F7 to F9 yet because I've not yet had time to test gcc 4.3 with some commercial libraries that have only been compiled against gcc 4.1.x. I know lots of other desktop/server users that are running system from FC2 - FC6. (Yes I know about RHEL.)
(As a side note: My wife hates the security balloons that pop up when there's a security related update. She's always comparing it to windows. )
My $0.02.
-- James Hubbard
With a name like 'autodeath' do you really think many people will go out of their way to install it accidentally?
Regards,
"CM" == Conrad Meyer konrad@tylerc.org writes:
CM> With a name like 'autodeath' do you really think many people will CM> go out of their way to install it accidentally?
How many people still clamor for an "everything" install?
...
Actually, this package sounds better all the time.
- J<
On Wed, 2008-08-20 at 17:25 -0500, Jason L Tibbitts III wrote:
"CM" == Conrad Meyer konrad@tylerc.org writes:
CM> With a name like 'autodeath' do you really think many people will CM> go out of their way to install it accidentally?
How many people still clamor for an "everything" install?
...
Actually, this package sounds better all the time.
lol,
I've noticed that all the .edu people seem to get this. :)
-sv
devel@lists.stg.fedoraproject.org
-
Chuck Anderson -
Colin Walters -
Conrad Meyer -
Dave Jones -
Dominik 'Rathann' Mierzejewski -
Horst H. von Brand -
James Hubbard -
Jason L Tibbitts III -
Jef Spaleta -
Jima -
Jon Ciesla -
Jon Masters -
Josh Boyer -
Matthew Miller -
max -
Nicolas Mailhot -
Rahul Sundaram -
Ralf Ertzinger -
Richard Hughes -
Seth Vidal -
Stephen John Smoogen -
Tom Callaway -
Vasile Gaburici