Re: unstable is unstable; stable is outdated
On Tue, 5/Feb/02 23:03:40, [EMAIL PROTECTED] wrote: Hello! On Sat, Feb 02, 2002 at 06:39:46AM +0800, Jason Lim wrote: ... aspect of their distro pretty good. They are business people over there, and they know how frequent business users like to have updates, and when ... People here around *only* know RedHat, and it's *the best*, because each half year you can buy a new Version. It seems that RH learnt much from M$ ;) Regards, Chris -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unstable is unstable; stable is outdated
Last Debian Weekly News says that a Maintainer dropped 18 packages out of frustration with the slow pace of Debian 3.0. It also says that this slow pace is because Bugs are simply not fixed. Yes, I read about that in the Debian Week too. If companies would a) adopt Debian packages (by inhouse programmers), and/or b) sponsor packages Maintainers, there would be some economic thrive behind the Debian Releases, and it would just be fair, because Debian is thriving a lot of companies, isn't it? True... but not to the point (at least for us) to hire a person to specifically maintain debian packages and such. We run a mirror in HK :-) It would have been nice if Corel's spin on Debian took off, as they could then really sponsor some developers to work on debian/corel's distro. Hum... i wonder if any other distro's based on Debian are helping out... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unstable is unstable; stable is outdated
aspect of their distro pretty good. They are business people over there, and they know how frequent business users like to have updates, and when ... People here around *only* know RedHat, and it's *the best*, because each half year you can buy a new Version. It seems that RH learnt much from M$ ;) Then perhaps Debian should also head that way more (not completely) and release a new version more often, rather than waiting so long? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unstable is unstable; stable is outdated
On Tue, 5/Feb/02 23:03:40, [EMAIL PROTECTED] wrote: Hello! On Sat, Feb 02, 2002 at 06:39:46AM +0800, Jason Lim wrote: ... aspect of their distro pretty good. They are business people over there, and they know how frequent business users like to have updates, and when ... People here around *only* know RedHat, and it's *the best*, because each half year you can buy a new Version. It seems that RH learnt much from M$ ;) Regards, Chris
Re: unstable is unstable; stable is outdated
Last Debian Weekly News says that a Maintainer dropped 18 packages out of frustration with the slow pace of Debian 3.0. It also says that this slow pace is because Bugs are simply not fixed. Yes, I read about that in the Debian Week too. If companies would a) adopt Debian packages (by inhouse programmers), and/or b) sponsor packages Maintainers, there would be some economic thrive behind the Debian Releases, and it would just be fair, because Debian is thriving a lot of companies, isn't it? True... but not to the point (at least for us) to hire a person to specifically maintain debian packages and such. We run a mirror in HK :-) It would have been nice if Corel's spin on Debian took off, as they could then really sponsor some developers to work on debian/corel's distro. Hum... i wonder if any other distro's based on Debian are helping out...
Re: unstable is unstable; stable is outdated
aspect of their distro pretty good. They are business people over there, and they know how frequent business users like to have updates, and when ... People here around *only* know RedHat, and it's *the best*, because each half year you can buy a new Version. It seems that RH learnt much from M$ ;) Then perhaps Debian should also head that way more (not completely) and release a new version more often, rather than waiting so long?
Re: unstable is unstable; stable is outdated
Hello! On Sat, Feb 02, 2002 at 06:39:46AM +0800, Jason Lim wrote: ... aspect of their distro pretty good. They are business people over there, and they know how frequent business users like to have updates, and when ... People here around *only* know RedHat, and it's *the best*, because each half year you can buy a new Version. So I can tell by what I see at others (i.e. not from personal experience) that RedHat a) changes essential issues every time it makes a new version, so on has to learn again, b) uses also some outdated software. I suppose the latter is, to not provoque the dependency avalanche. critical updates should be released. Your Point, Best Regards, Jorge León -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unstable is unstable; stable is outdated
Hello! On Sat, Feb 02, 2002 at 04:55:44AM +0800, Jason Lim wrote: ... I know that as a company, we could donate a bit of money (with the economy as it is, not much though), but from what I can see, money isn't really where the problem lies... it is somewhere else. ... Last Debian Weekly News says that a Maintainer dropped 18 packages out of frustration with the slow pace of Debian 3.0. It also says that this slow pace is because Bugs are simply not fixed. I'd love to become a Debian Maintainer or Bug-Squasher, if I could make a living out of it, whole or parttime. Your company could send me an offer. This is meant serious, although not intended to be an abuse of the list. If companies would a) adopt Debian packages (by inhouse programmers), and/or b) sponsor packages Maintainers, there would be some economic thrive behind the Debian Releases, and it would just be fair, because Debian is thriving a lot of companies, isn't it? Best Regards, Jorge-León -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unstable is unstable; stable is outdated
Hello! On Sat, Feb 02, 2002 at 06:39:46AM +0800, Jason Lim wrote: ... aspect of their distro pretty good. They are business people over there, and they know how frequent business users like to have updates, and when ... People here around *only* know RedHat, and it's *the best*, because each half year you can buy a new Version. So I can tell by what I see at others (i.e. not from personal experience) that RedHat a) changes essential issues every time it makes a new version, so on has to learn again, b) uses also some outdated software. I suppose the latter is, to not provoque the dependency avalanche. critical updates should be released. Your Point, Best Regards, Jorge León
Re: unstable is unstable; stable is outdated
Hello! On Sat, Feb 02, 2002 at 04:55:44AM +0800, Jason Lim wrote: ... I know that as a company, we could donate a bit of money (with the economy as it is, not much though), but from what I can see, money isn't really where the problem lies... it is somewhere else. ... Last Debian Weekly News says that a Maintainer dropped 18 packages out of frustration with the slow pace of Debian 3.0. It also says that this slow pace is because Bugs are simply not fixed. I'd love to become a Debian Maintainer or Bug-Squasher, if I could make a living out of it, whole or parttime. Your company could send me an offer. This is meant serious, although not intended to be an abuse of the list. If companies would a) adopt Debian packages (by inhouse programmers), and/or b) sponsor packages Maintainers, there would be some economic thrive behind the Debian Releases, and it would just be fair, because Debian is thriving a lot of companies, isn't it? Best Regards, Jorge-León
Re: OT: *****SPAM***** Re: unstable is unstable; stable is outdated]
On Mon, 4 Feb 2002 12:41, Jason Lim wrote: ORDB (ordb.ORG) lists open relays, SPEWS lists spammers. Using ORDB is very effective for blocking spammers who abuse open relays, but SPEWS can stop the direct spammers and their hosts. How are the spammers going to get their emails out? Most, if not all must use open relays to send them out. Nowadays I think nearly all ISPs block They also use the mail servers of their ISPs and the PCs that they connect to the Internet as regular ISP customers. ISPs in Asia are notorious for allowing spammers to use their services. I have been seriously considering blocking my servers from receiving any mail from China and Taiwan as I seem to only receive spam from those countries. direct sending of email from their IPs (that is, they cannot send direct to MX email anymore, they must use either their ISP's email servers, or an open relay somewhere). I think this is a good move by ISPs as it is effective and is technically easy to do (simple port blocking) so even the smallest of ISPs can implement this. Following that logic, it makes sense that if you block the method spammers use to send out emails, then no spam will be sent out. Yes. Unfortunately most asian ISPs appear to like hosting spammers. Exactly.. when they block an innocent network to pressure a major corporation thay have crossed the line from being a good blacklist to being a tool for extortion and libel. I read the summaries of email blocked by the blacklists from the ISPs I run. The vast majority of email blocked by the spews list is obviously spam (the From: addresses are obviously bogus or spam addresses), so for me it is provably working well! -- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: OT: *****SPAM***** Re: unstable is unstable; stable is outdated]
On Mon, 4 Feb 2002 12:41, Jason Lim wrote: ORDB (ordb.ORG) lists open relays, SPEWS lists spammers. Using ORDB is very effective for blocking spammers who abuse open relays, but SPEWS can stop the direct spammers and their hosts. How are the spammers going to get their emails out? Most, if not all must use open relays to send them out. Nowadays I think nearly all ISPs block They also use the mail servers of their ISPs and the PCs that they connect to the Internet as regular ISP customers. ISPs in Asia are notorious for allowing spammers to use their services. I have been seriously considering blocking my servers from receiving any mail from China and Taiwan as I seem to only receive spam from those countries. direct sending of email from their IPs (that is, they cannot send direct to MX email anymore, they must use either their ISP's email servers, or an open relay somewhere). I think this is a good move by ISPs as it is effective and is technically easy to do (simple port blocking) so even the smallest of ISPs can implement this. Following that logic, it makes sense that if you block the method spammers use to send out emails, then no spam will be sent out. Yes. Unfortunately most asian ISPs appear to like hosting spammers. Exactly.. when they block an innocent network to pressure a major corporation thay have crossed the line from being a good blacklist to being a tool for extortion and libel. I read the summaries of email blocked by the blacklists from the ISPs I run. The vast majority of email blocked by the spews list is obviously spam (the From: addresses are obviously bogus or spam addresses), so for me it is provably working well! -- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page
Re: *****SPAM***** Re: unstable is unstable; stable is outdated]
On 02 Feb 2002, Jason Lim (of Zentek?) wrote: Unfortunately, Spews and OSIRUS (they use Spews' list, so essentially the same applies) have listed many ISPs in Hong Kong and around Asia Because they run open relays or insecure proxies, host spamware or spamvertised web sites, and ignore abuse reports. Just like rogue ISPs in Europe and the Americas are listed. I am not surprised if Zentek is blocked. In Q1 2001 I received many UCEs advertising sites hosted at zentek.net, and last week I even started getting spam to message-ids of abuse reports I had sent to zentek.net! http://spews.org/html/S475.html That is why we suggest that businesses use ORDB (http://www.ordb.com) as it blocks most spam, but ONLY blocks spam and very rarely legitimate emails (we use this list for our personal emails too). ORDB (ordb.ORG) lists open relays, SPEWS lists spammers. Using ORDB is very effective for blocking spammers who abuse open relays, but SPEWS can stop the direct spammers and their hosts. Unless one's customers are clueful enough to be able to report spam I would recommend using relays.ordb.org and relays.osirusoft.com (or bl.spamcop.net when it is ready). I have found that my users are more understanding of the possibility of a legitimate e-mail being bounced when it comes from a bad source, than their e-mail address on a web site resulting in all sorts of dubious offers. Spews is supposedly early warning, hence if the owner of Spews thinks there may be spam coming from a certain place, they block if off first, whether or not spam will really come through there or not. Not in my experience. They block networks owned by spammers and they block networks which host spammers. I have yet to see SPEWS block a responsible user on a clean network. It is all too easy for spammers to spew from one location while hosting at another, and SPEWS recognises that. automated testing to block mail servers, rather than rely on the decision of one or two unaccountable people with their own ideas. SPEWS is accountable to every person who uses SPEWS. If we don't like their decisions we don't use their list. At the moment it seems the number of people who use SPEWS is growing, because it is proving very effective at blocking spammers and encouraging networks to be more responsible. -- Mark -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unstable is unstable; stable is outdated
On Fri, Feb 01, 2002 at 06:18:34PM -0800, Jeremy C. Reed wrote: On Sat, 2 Feb 2002, Donovan Baarda wrote: [...] This paritions the dependancies, making it all easier to manage, speeding the release cycle and potentialy allowing people to mix-n-match stable-core with unstable-gnome if they wish. So do you mean that these sub-distros don't have any dependencies on any packages within the other sub-distros? The normal approach to solving dependancy hell in large projects is to collect all the little components into larger sub-components in a way that minimizes the coupling between those sub-components. The top-level dependancies are then dealt with at the sub-component level. For example; debian-gnome 2.0 depends on debian-core =3.0, 4.0. Provided the total API is backwards compatible for all minor versions of debian-core 3.x, debian-gnome 2.0 should work. Any change to debian-core that breaks debian-gnome 2.0 either must go into debian-core 4.x, or is a bug that needs fixing in debian-core 3.x. How you would use this approach and introduce it into Debian is not entirely clear. You could use something like a dummy sub-project package that requires, recommends, and suggests packages included in that sub-project as necissary. This dummy package could optionaly depend on appropriate versions of other sub-project's dummy packages. Packages could either depend directly on (optional) packages in other sub-projects, or on the other sub-project dummy package (which gaurentees the required packages of that sub-project). Alternatively, you could just continue on as is, doing nothing special beyond parititioning into sub-projects. This would mean packages in debian-gnome would depend directly on packages in debian-core. In this case I believe there would still be benefits, as developers of frozen debian-gnome could target stable debian-core and be comfortable in the knowlege things like libc would not change under them mid development cycle just before a release. Someone mentioned not liking the idea of having multiple apt-sources just to get a complete working system. There is no reason why there couldn't also be a single Debian stable apt-source that consisted of a single Packages file that included all the stable versions of all the sub-projects. Then people could put just stable debian in their apt-sources for a complete stable Debian, and then optionaly add unstable debian-gnome if they wanted. But ideas are cheap... implementing them is the real work. Feel free to forward this to debian-devel or debian-policy or wherever :-) -- -- ABO: finger [EMAIL PROTECTED] for more info, including pgp key -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
OT: *****SPAM***** Re: unstable is unstable; stable is outdated]
That is why we suggest that businesses use ORDB (http://www.ordb.com) as it blocks most spam, but ONLY blocks spam and very rarely legitimate emails (we use this list for our personal emails too). ORDB (ordb.ORG) lists open relays, SPEWS lists spammers. Using ORDB is very effective for blocking spammers who abuse open relays, but SPEWS can stop the direct spammers and their hosts. How are the spammers going to get their emails out? Most, if not all must use open relays to send them out. Nowadays I think nearly all ISPs block direct sending of email from their IPs (that is, they cannot send direct to MX email anymore, they must use either their ISP's email servers, or an open relay somewhere). I think this is a good move by ISPs as it is effective and is technically easy to do (simple port blocking) so even the smallest of ISPs can implement this. Following that logic, it makes sense that if you block the method spammers use to send out emails, then no spam will be sent out. Unless one's customers are clueful enough to be able to report spam I would recommend using relays.ordb.org and relays.osirusoft.com (or bl.spamcop.net when it is ready). I have found that my users are more understanding of the possibility of a legitimate e-mail being bounced when it comes from a bad source, than their e-mail address on a web site resulting in all sorts of dubious offers. Not in my experience. They block networks owned by spammers and they block networks which host spammers. I have yet to see SPEWS block a responsible user on a clean network. It is all too easy for spammers to spew from one location while hosting at another, and SPEWS recognises that. Well, Perhaps this converstaion with a person who got caught, just like others in Spews, will enlighten you: - I *do* believe some of Sprint's customers (not you) may be spamming. I am not in the USA and not sure of the whole picture over there, but I do believe if a Sprint customer is spamming, you should block whatever the spammer is using, rather than block the whole ISP, and not care what happens. In SPEWS: -- -- Sprint just keeps assigning him new network blocks, safer to list entire Sprint ranges, eg: 65.172.0.0 - 65.173.255.255 -- - Exactly.. when they block an innocent network to pressure a major corporation thay have crossed the line from being a good blacklist to being a tool for extortion and libel. What makes it worse is then they hide and don't take responsability. Even Orbs had a contact email address. What Spews has done is gone from a good guy to a bad guy in my book. No blacklist is a good one if if it blocks the innocent and refuses to remove them even though no spam is coming from them. Open relays.. yes. KNOWN spammer ip's and netblocks.. yes. A whole class B of a major provider just to be safe.. NO. Spews is just going to hurt THE CAUSE just like ORBS did. Spews goal should be the blockage of spam. If its main goal is to pressure companies it does not like it will get into trouble, again..just like ORBS did. I have a friend who also does this. We both dropped spews because of too much legit mail being blocked. This was before all this happened.. several weeks ago we tried them for awhile. I bet that most nets don't use them just like we decided not too. Yes, and with additional information and facts sent to the remaining nets that do, they will probably drop Spews too. I'll check the logs and see if any other prominent sites also use Spews, and I'll notify them too (not that i'd have much say compared to outblaze, but it's worth a shot, and if a few more ISPs send these companies information like this, they would not want to bother with Spews anymore). What do you think? Thats a good plan and the one I am going to use. I will forward you a copy of my letter when I can. Now that Ive thought about this more I think Spews will dig its own grave. The reason we are on their list is unjust and will cause others to drop them as the word gets out. automated testing to block mail servers, rather than rely on the decision of one or two unaccountable people with their own ideas. SPEWS is accountable to every person who uses SPEWS. If we don't like their decisions we don't use their list. At the moment it seems the number of people who use SPEWS is growing, because it is proving very effective at blocking spammers and encouraging networks to be more responsible. Well, the sad fact is that most people do not take the time to fully understand what is going on. Spews *sounds* like a good idea, until you actually check the content of the database. Anyway, if one chooses to continue to use Spews and/or other blocklists that operate in such a fashion, then let them go ahead.
Re: *****SPAM***** Re: unstable is unstable; stable is outdated]
On 02 Feb 2002, Jason Lim (of Zentek?) wrote: Unfortunately, Spews and OSIRUS (they use Spews' list, so essentially the same applies) have listed many ISPs in Hong Kong and around Asia Because they run open relays or insecure proxies, host spamware or spamvertised web sites, and ignore abuse reports. Just like rogue ISPs in Europe and the Americas are listed. I am not surprised if Zentek is blocked. In Q1 2001 I received many UCEs advertising sites hosted at zentek.net, and last week I even started getting spam to message-ids of abuse reports I had sent to zentek.net! http://spews.org/html/S475.html That is why we suggest that businesses use ORDB (http://www.ordb.com) as it blocks most spam, but ONLY blocks spam and very rarely legitimate emails (we use this list for our personal emails too). ORDB (ordb.ORG) lists open relays, SPEWS lists spammers. Using ORDB is very effective for blocking spammers who abuse open relays, but SPEWS can stop the direct spammers and their hosts. Unless one's customers are clueful enough to be able to report spam I would recommend using relays.ordb.org and relays.osirusoft.com (or bl.spamcop.net when it is ready). I have found that my users are more understanding of the possibility of a legitimate e-mail being bounced when it comes from a bad source, than their e-mail address on a web site resulting in all sorts of dubious offers. Spews is supposedly early warning, hence if the owner of Spews thinks there may be spam coming from a certain place, they block if off first, whether or not spam will really come through there or not. Not in my experience. They block networks owned by spammers and they block networks which host spammers. I have yet to see SPEWS block a responsible user on a clean network. It is all too easy for spammers to spew from one location while hosting at another, and SPEWS recognises that. automated testing to block mail servers, rather than rely on the decision of one or two unaccountable people with their own ideas. SPEWS is accountable to every person who uses SPEWS. If we don't like their decisions we don't use their list. At the moment it seems the number of people who use SPEWS is growing, because it is proving very effective at blocking spammers and encouraging networks to be more responsible. -- Mark
OT: *****SPAM***** Re: unstable is unstable; stable is outdated]
That is why we suggest that businesses use ORDB (http://www.ordb.com) as it blocks most spam, but ONLY blocks spam and very rarely legitimate emails (we use this list for our personal emails too). ORDB (ordb.ORG) lists open relays, SPEWS lists spammers. Using ORDB is very effective for blocking spammers who abuse open relays, but SPEWS can stop the direct spammers and their hosts. How are the spammers going to get their emails out? Most, if not all must use open relays to send them out. Nowadays I think nearly all ISPs block direct sending of email from their IPs (that is, they cannot send direct to MX email anymore, they must use either their ISP's email servers, or an open relay somewhere). I think this is a good move by ISPs as it is effective and is technically easy to do (simple port blocking) so even the smallest of ISPs can implement this. Following that logic, it makes sense that if you block the method spammers use to send out emails, then no spam will be sent out. Unless one's customers are clueful enough to be able to report spam I would recommend using relays.ordb.org and relays.osirusoft.com (or bl.spamcop.net when it is ready). I have found that my users are more understanding of the possibility of a legitimate e-mail being bounced when it comes from a bad source, than their e-mail address on a web site resulting in all sorts of dubious offers. Not in my experience. They block networks owned by spammers and they block networks which host spammers. I have yet to see SPEWS block a responsible user on a clean network. It is all too easy for spammers to spew from one location while hosting at another, and SPEWS recognises that. Well, Perhaps this converstaion with a person who got caught, just like others in Spews, will enlighten you: - I *do* believe some of Sprint's customers (not you) may be spamming. I am not in the USA and not sure of the whole picture over there, but I do believe if a Sprint customer is spamming, you should block whatever the spammer is using, rather than block the whole ISP, and not care what happens. In SPEWS: -- -- Sprint just keeps assigning him new network blocks, safer to list entire Sprint ranges, eg: 65.172.0.0 - 65.173.255.255 -- - Exactly.. when they block an innocent network to pressure a major corporation thay have crossed the line from being a good blacklist to being a tool for extortion and libel. What makes it worse is then they hide and don't take responsability. Even Orbs had a contact email address. What Spews has done is gone from a good guy to a bad guy in my book. No blacklist is a good one if if it blocks the innocent and refuses to remove them even though no spam is coming from them. Open relays.. yes. KNOWN spammer ip's and netblocks.. yes. A whole class B of a major provider just to be safe.. NO. Spews is just going to hurt THE CAUSE just like ORBS did. Spews goal should be the blockage of spam. If its main goal is to pressure companies it does not like it will get into trouble, again..just like ORBS did. I have a friend who also does this. We both dropped spews because of too much legit mail being blocked. This was before all this happened.. several weeks ago we tried them for awhile. I bet that most nets don't use them just like we decided not too. Yes, and with additional information and facts sent to the remaining nets that do, they will probably drop Spews too. I'll check the logs and see if any other prominent sites also use Spews, and I'll notify them too (not that i'd have much say compared to outblaze, but it's worth a shot, and if a few more ISPs send these companies information like this, they would not want to bother with Spews anymore). What do you think? Thats a good plan and the one I am going to use. I will forward you a copy of my letter when I can. Now that Ive thought about this more I think Spews will dig its own grave. The reason we are on their list is unjust and will cause others to drop them as the word gets out. automated testing to block mail servers, rather than rely on the decision of one or two unaccountable people with their own ideas. SPEWS is accountable to every person who uses SPEWS. If we don't like their decisions we don't use their list. At the moment it seems the number of people who use SPEWS is growing, because it is proving very effective at blocking spammers and encouraging networks to be more responsible. Well, the sad fact is that most people do not take the time to fully understand what is going on. Spews *sounds* like a good idea, until you actually check the content of the database. Anyway, if one chooses to continue to use Spews and/or other blocklists that operate in such a fashion, then let them go ahead.
Re: unstable is unstable; stable is outdated
Donovan Baarda wrote: What do you think of having a mini distribution that limits the number of packages allowed? Why not just call it debian-core. Then you can have debian-gnome, debian-kde, debian-xfree etc. Each of these can be implemented as seperate distro's with their own releases, using Packages files pointing into the pool. I was thinking something similar to this would be cool, just I wouldn't like to have to add a lot of lines in my sources.list. Maybe something like tasks with versions could be used. Packages from other tasks (or the task itself) could depend on a certain version of another task instead of depending on many packages within that task. Tasks that are not yet released could be called unstable, testing, and stablish (maybe somthing better). Unstable would have new untested packages. Testing would have packages that passed some automated tests. Stablish would have packages that were in testing and didn't have any important bug reports within a certain amount of time. Maybe there could be one more for alplha and beta versions of packages. If all works well, unstable should have the lastes packages and be a little stable, testing should be a little less stable than Red Hat, stablish should be a little more stable than Red Hat, and stable should be as stable as it's always been, but more up to date. :) This paritions the dependancies, making it all easier to manage, speeding the release cycle and potentialy allowing people to mix-n-match stable-core with unstable-gnome if they wish. Yup. :) P.S. I think we need a better name than stablish... Maybe call that stable and the current stable rockstable??? Also maybe they souldn't be called tasks but something new. I'm not good at making up names. -- Ivan Jager -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
*****SPAM***** Re: unstable is unstable; stable is outdated]
Hi, Thank you for telling me. Unfortunately, Spews and OSIRUS (they use Spews' list, so essentially the same applies) have listed many ISPs in Hong Kong and around Asia, meaning many of us over here are blocked from sending emails to the USA if a company uses Spews. That is why we suggest that businesses use ORDB (http://www.ordb.com) as it blocks most spam, but ONLY blocks spam and very rarely legitimate emails (we use this list for our personal emails too). Spews is supposedly early warning, hence if the owner of Spews thinks there may be spam coming from a certain place, they block if off first, whether or not spam will really come through there or not. ORDB, on the other hand, uses automated testing to block mail servers, rather than rely on the decision of one or two unaccountable people with their own ideas. Telstra in Australia, PCCW (Pacific Century Cyberworks/ Hong Kong Telecom), Singtel, and others in Asia have many netblocks listed in Spews. Sprint is also has large chunks of netblocks blocked. We used it before and had too much legitimate business email blocked. So, again, thanks for telling me, but there is little I can do to unblock Asian ISPs. Spews is unaccountable to anyone and no one can contact them (which they say on their website). They have banged heads with many ISPs in Asia... maybe the owner of Spews is overly patriotic to the USA to the point of being racist (but I'll leave that discussion there). Sincerely, Jason - Original Message - From: Oliver Andrich [EMAIL PROTECTED] To: Jason Lim [EMAIL PROTECTED] Sent: Saturday, February 02, 2002 8:52 AM Subject: [EMAIL PROTECTED]: *SPAM* Re: unstable is unstable; stable is outdated] Hi, may be it is of interest to you, that the mailservers of your provider are in a anti-spam list. If not, just delete this mail. Discovered it, when my spamassassin caugth your email. Best regards, Oliver -- -- --- Oliver Andrich | Tel.: 0261-5009075 IT Projektmanagement,| Mobil: 0172-6538591 Systemprogrammierung und -design | Fax: 069-13305990076 | Email: [EMAIL PROTECTED] -- --- Fingerpring: 2AB5 B998 8BD2 AC3A E12A 3A8A 171E 5B1B EC4B 3C2B -- ---
Re: unstable is unstable; stable is outdated
This paritions the dependancies, making it all easier to manage, speeding the release cycle and potentialy allowing people to mix-n-match stable-core with unstable-gnome if they wish. So do you mean that these sub-distros don't have any dependencies on any packages within the other sub-distros? I think that is what he means... that you could throw a hybrid system together. For example... most ISPs would probably want the most up to date apache and proftpd (or whatever your combination is). They don't really care to have the most up to date compilers or libraries or anything else... only what is required to get the latest apache and proftpd. I can see a problem in this idea though, as many packages have cross depedancies. EG. apache needs library A version 2, while proftpd needs library A version 3. How would that be handled? Upgrading to libarary A version 3 might break apache...
Re: unstable is unstable; stable is outdated
Donovan Baarda wrote: What do you think of having a mini distribution that limits the number of packages allowed? Why not just call it debian-core. Then you can have debian-gnome, debian-kde, debian-xfree etc. Each of these can be implemented as seperate distro's with their own releases, using Packages files pointing into the pool. I was thinking something similar to this would be cool, just I wouldn't like to have to add a lot of lines in my sources.list. Maybe something like tasks with versions could be used. Packages from other tasks (or the task itself) could depend on a certain version of another task instead of depending on many packages within that task. Tasks that are not yet released could be called unstable, testing, and stablish (maybe somthing better). Unstable would have new untested packages. Testing would have packages that passed some automated tests. Stablish would have packages that were in testing and didn't have any important bug reports within a certain amount of time. Maybe there could be one more for alplha and beta versions of packages. If all works well, unstable should have the lastes packages and be a little stable, testing should be a little less stable than Red Hat, stablish should be a little more stable than Red Hat, and stable should be as stable as it's always been, but more up to date. :) This paritions the dependancies, making it all easier to manage, speeding the release cycle and potentialy allowing people to mix-n-match stable-core with unstable-gnome if they wish. Yup. :) P.S. I think we need a better name than stablish... Maybe call that stable and the current stable rockstable??? Also maybe they souldn't be called tasks but something new. I'm not good at making up names. -- Ivan Jager
unstable is unstable; stable is outdated
On Fri, 2002-02-01 at 01:42, Jason Lim wrote: We have production boxes running unstable with no problem. Needed to run unstable because only unstable had some new software, unavailable in stable. Its a pity stable gets so outdated all the time as compared to other distros like Redhat and Caldera (stable still on 2.2 kernel), but thats a topic for a separate discussion. This is really a shame. It's my biggest complaint with Debian by far. The tools work very well, but the release cycle is such that you can't use a stable revision of the distribution and have modern packages available. I can't imagine this issue is being ignored, but is it discussed on a policy list, probably? It seems like FreeBSD's -RELEASE, -STABLE, -CURRENT scheme works much better than what Debian has. I've never seen big political arguments on this mailing list, but I always hear that Debian as an organization is often too burdened with internal bickering and politics to move forward with big changes. Is that the case here? Just curious, not trying to start a flame war. -- Jeff S Wheeler [EMAIL PROTECTED] Software DevelopmentFive Elements, Inc http://www.five-elements.com/~jsw/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unstable is unstable; stable is outdated
On Fri, 2002-02-01 at 01:42, Jason Lim wrote: We have production boxes running unstable with no problem. Needed to run unstable because only unstable had some new software, unavailable in stable. Its a pity stable gets so outdated all the time as compared to other distros like Redhat and Caldera (stable still on 2.2 kernel), but thats a topic for a separate discussion. This is really a shame. It's my biggest complaint with Debian by far. The tools work very well, but the release cycle is such that you can't use a stable revision of the distribution and have modern packages available. I agree. What I would like to know is how other Linux distros like Redhat (only mentioning Redhat because that is what many of our cusomters request, and nearly everyone knows it) can have pretty new stable releases? No release is going to be totally bug-free, and I think just about everyone (business and personal) know and accept this. Perhaps people are willing to trade in a few more bugs to have a far more up-to-date system? I know Debian likes to have stable REALLY VERY stable... but perhaps it is SO stable that is too outdated to be used in a production environment. I mean, I think Debian is the only Linux distro still shipping with a 2.2 kernel; everyone else has gone ahead with 2.4 for quite a long time now. I pretty much work with Linux exclusively in a business environment... so from a business of view (and I hate to say this... but...) I like Redhat more than Debian, in that a default install of Redhat comes with a 2.4 kernel, ext3, and lots of up-to-date tools, whereas with Debian I have to recompile a new kernel, download the various new tools to support the new kernel, etc... and as we all know, jumping from stable to unstable is problem-prone and doesn't worth flawlessly every time. I can't imagine this issue is being ignored, but is it discussed on a policy list, probably? It seems like FreeBSD's -RELEASE, -STABLE, -CURRENT scheme works much better than what Debian has. I've never seen big political arguments on this mailing list, but I always hear that Debian as an organization is often too burdened with internal bickering and politics to move forward with big changes. Is that the case here? Just curious, not trying to start a flame war. I also do not believe in flame wars, which are not at all constructive. I'd be very willing to engage in some constructive discussion with anyone, with ideas that are doable rather than ideals. I think Debian MAY be too weighed down in ideals, rather than focusing on getting a good opensource linux distro out there. Of course, there are probably many factors affecting Debian and making it slow to move, but surely something can be done to improve the situation? I know that as a company, we could donate a bit of money (with the economy as it is, not much though), but from what I can see, money isn't really where the problem lies... it is somewhere else. I don't know what I can personally do to help policy changes or anything like that, but I'd be willing to give my perspective and ideas on the matter, if that helps at all. Perhaps other business users out there would also like to give Debian a bit more input, so Debian becomes a viable business distro that isn't so out-of-date? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unstable is unstable; stable is outdated
kernel, etc... and as we all know, jumping from stable to unstable is problem-prone and doesn't worth flawlessly every time. Why jump all the way to unstable, why not use testing? Testing is usually stable enough for most applications plus the various software packages are pretty up to date. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unstable is unstable; stable is outdated
*** REPLY SEPARATOR *** On 2/1/02 at 4:25 PM Tim Quinlan wrote: kernel, etc... and as we all know, jumping from stable to unstable is problem-prone and doesn't worth flawlessly every time. Why jump all the way to unstable, why not use testing? Testing is usually stable enough for most applications plus the various software packages are pretty up to date. In my experience unstable is pretty damn stable as well. I upgraded a couple of boxen from stable to unstable a little over a year ago and haven't been bit by any of the big bugs. I just check the mailing lists and debian planet to see if anything big has popped up before doing an apt-get update apt-get upgrade. Obviously these aren't servers. I think the only problem with debian is the naming. Changing nothing but the name from unstable to cutting edge or something and there wouldn't be close to the outcry about how 'behind' debian is. IMHO. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- Lang Is uniformity attainable? Millions of innocent men, women, and children, since the introduction of Christianity, have been burnt, tortured, fined, imprisoned; yet we have not advanced one inch towards uniformity. What has been the effect of coercion? To make one half of the world fools, and the other half hypocrites. -- Thomas Jefferson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unstable is unstable; stable is outdated
On 2/1/02 at 4:25 PM Tim Quinlan wrote: kernel, etc... and as we all know, jumping from stable to unstable is problem-prone and doesn't worth flawlessly every time. Why jump all the way to unstable, why not use testing? Testing is usually stable enough for most applications plus the various software packages are pretty up to date. In my experience unstable is pretty damn stable as well. I upgraded a couple of boxen from stable to unstable a little over a year ago and haven't been bit by any of the big bugs. I just check the mailing lists and debian planet to see if anything big has popped up before doing an apt-get update apt-get upgrade. Obviously these aren't servers. In my experience as well. As I said in a previous post, i've heard that testing is the last to get security updates, which is not acceptable if you're running servers. I think the only problem with debian is the naming. Changing nothing but the name from unstable to cutting edge or something and there wouldn't be close to the outcry about how 'behind' debian is. IMHO. Well, there more or less needs to be more frequent stable releases... something along the lines of Redhat's quick releases. Okay... Redhat again.. i know i know... but you've got to admit they've got the release aspect of their distro pretty good. They are business people over there, and they know how frequent business users like to have updates, and when critical updates should be released. I'm just wondering if it is even POSSIBLE to follow the frequent release schedule that Redhat follows, or if it is not possible because most/all of the developers for Debian are volunteers and won't work to such a tight schedule. If we can find and identify the problems not allowing up-to-date releases, perhaps a solution can be found? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unstable is unstable; stable is outdated
I thinking the problem here, as I mentioned before, is one of semantics as opposed to a real problem. Options are: 1) unstable pros: Very up to date, cons: Occasion big bug that can do damage user: Someone who knows there way around Linux pretty well and likes to say,I use unstable 'cause I'm so cool! 2) testing pros: Pretty up to date, very stable cons: May have the latest-greatest version of an app a week or two after your buddy using unstable. Last to get security upgrades. user: Someone who actually uses their computer to get work done and is less worried about being the latest greatest cool guy. Someone who laughs at their co-working trying to figure out why init keeps bombing after his last unstable upgrade. 3) stable pros: Rock stable, quicker security updates than testing. cons: old user: critical server. Most of these characterization are user standpoint. If I had a server that was super critical, I'd use stable (or *BSD). The two servers I have don't have a huge load and it's not a big deal if they go down (not to sound like a huge power user, 'cause I'm talking about a home network and a minor server at work). I have testing on them. In short, if you're a user, it doesn't make sense to use stable. Use testing or unstable and you're system will be as up to date, if not more, as any distro. If you're running a server, just use testing, unless security is a big issue. Then use stable. Or use testing and keep a watch on the linux security pages, and manually apply the newest patches when they come out. IMHO, there is a level for any use inside the various debian trees. The biggest problem from a PR standpoint for debian is in the names. Feel free to disagree with any point I made, 'cause I'm not as good as I sound. On 2/2/02 at 6:39 AM Jason Lim wrote: On 2/1/02 at 4:25 PM Tim Quinlan wrote: kernel, etc... and as we all know, jumping from stable to unstable is problem-prone and doesn't worth flawlessly every time. Why jump all the way to unstable, why not use testing? Testing is usually stable enough for most applications plus the various software packages are pretty up to date. In my experience unstable is pretty damn stable as well. I upgraded a couple of boxen from stable to unstable a little over a year ago and haven't been bit by any of the big bugs. I just check the mailing lists and debian planet to see if anything big has popped up before doing an apt-get update apt-get upgrade. Obviously these aren't servers. In my experience as well. As I said in a previous post, i've heard that testing is the last to get security updates, which is not acceptable if you're running servers. I think the only problem with debian is the naming. Changing nothing but the name from unstable to cutting edge or something and there wouldn't be close to the outcry about how 'behind' debian is. IMHO. Well, there more or less needs to be more frequent stable releases... something along the lines of Redhat's quick releases. Okay... Redhat again.. i know i know... but you've got to admit they've got the release aspect of their distro pretty good. They are business people over there, and they know how frequent business users like to have updates, and when critical updates should be released. I'm just wondering if it is even POSSIBLE to follow the frequent release schedule that Redhat follows, or if it is not possible because most/all of the developers for Debian are volunteers and won't work to such a tight schedule. If we can find and identify the problems not allowing up-to-date releases, perhaps a solution can be found? -- Lang Is uniformity attainable? Millions of innocent men, women, and children, since the introduction of Christianity, have been burnt, tortured, fined, imprisoned; yet we have not advanced one inch towards uniformity. What has been the effect of coercion? To make one half of the world fools, and the other half hypocrites. -- Thomas Jefferson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unstable is unstable; stable is outdated
Feel free to disagree with any point I made, 'cause I'm not as good as I sound. I'll throw my $.02 here. I think there is a more fundamental problem here. That is somehow incorporating the latest apache into stable will somehow make stable break. What needs to get done is to build a distro which isolates applications to a sufficient degree that they don't break each other. If you are able to build a distro like that then all you have to worry about is the application itself. If postgres 7.2 is deemed stable then you add it to your stable distro. Apple has done very interesting things with their bundle system if anyone cares to look, encap also looks pretty interesting. Ideally a distribution should act like this. Applications should not overly interfere with each other. It should be possible to install multiple versions of the same application. The distribution should be able to incorporate manually installed applications (make install) It should be possible to reconstruct the package database from the disk drive. all that and apt goodness too of course. feel free to add your own to the list. :wq Tim Uckun US Investigations Services/Due Diligence http://www.diligence.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unstable is unstable; stable is outdated
On 1 Feb 2002, Jeff S Wheeler wrote: On Fri, 2002-02-01 at 01:42, Jason Lim wrote: We have production boxes running unstable with no problem. Needed to run unstable because only unstable had some new software, unavailable in stable. Its a pity stable gets so outdated all the time as compared to other distros like Redhat and Caldera (stable still on 2.2 kernel), but thats a topic for a separate discussion. This is really a shame. It's my biggest complaint with Debian by far. The tools work very well, but the release cycle is such that you can't use a stable revision of the distribution and have modern packages available. Some up-to-date packages are located in the testing distribution. This probably has been (and currently) discussed elsewhere. I think the problems are that there are too many packages and too many dependencies. Maybe a solution would be to have a fourth collection (beside stable, testing and unstable): mini. It would not have thousands of packages. For example, it would only have about 150 to 300 packages. Only new packages are added if a vote approves. The mini collection can be done similar to the testing distribution: The mini distribution can be automatically-generated from the unstable distribution by a set of scripts which attempt to move over packages which lack important bugs and don't have dependency conflicts. Look here for ideas: http://people.debian.org/~jules/testingfaq.html What do you think of having a mini distribution that limits the number of packages allowed? I can't imagine this issue is being ignored, but is it discussed on a policy list, probably? It seems like FreeBSD's -RELEASE, -STABLE, -CURRENT scheme works much better than what Debian has. I've never seen One difference is that FreeBSD's ports collection is different than their base collection. The base (or main) collection has the -stable and -current development branches. But the ports collection is only developed in one: -current. (FreeBSD builds packages for -current and recent releases, but they only use one, the current, ports collection. Because of this, some consider the -current ports collection to be like unstable.) Jeremy C. Reed p.s. I am writing an article about the BSD ports collections, in regards to *stable* ports collections. If you are interested in reviewing a rough draft, let me know off-list. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unstable is unstable; stable is outdated
If ONLY there was some way to make testing get security updates faster... then I am almost sure testing would become the choice for many people running servers and such. It almost sounds like Redhat 7.2 (compared side to side). Options are: 1) unstable pros: Very up to date, cons: Occasion big bug that can do damage user: Someone who knows there way around Linux pretty well and likes to say,I use unstable 'cause I'm so cool! 2) testing pros: Pretty up to date, very stable cons: May have the latest-greatest version of an app a week or two after your buddy using unstable. Last to get security upgrades. user: Someone who actually uses their computer to get work done and is less worried about being the latest greatest cool guy. Someone who laughs at their co-working trying to figure out why init keeps bombing after his last unstable upgrade. 3) stable pros: Rock stable, quicker security updates than testing. cons: old user: critical server. Most of these characterization are user standpoint. If I had a server that was super critical, I'd use stable (or *BSD). The two servers I have don't have a huge load and it's not a big deal if they go down (not to sound like a huge power user, 'cause I'm talking about a home network and a minor server at work). I have testing on them. In short, if you're a user, it doesn't make sense to use stable. Use testing or unstable and you're system will be as up to date, if not more, as any distro. If you're running a server, just use testing, unless security is a big issue. Then use stable. Or use testing and keep a watch on the linux security pages, and manually apply the newest patches when they come out. IMHO, there is a level for any use inside the various debian trees. The biggest problem from a PR standpoint for debian is in the names. Feel free to disagree with any point I made, 'cause I'm not as good as I sound. On 2/2/02 at 6:39 AM Jason Lim wrote: On 2/1/02 at 4:25 PM Tim Quinlan wrote: kernel, etc... and as we all know, jumping from stable to unstable is problem-prone and doesn't worth flawlessly every time. Why jump all the way to unstable, why not use testing? Testing is usually stable enough for most applications plus the various software packages are pretty up to date. In my experience unstable is pretty damn stable as well. I upgraded a couple of boxen from stable to unstable a little over a year ago and haven't been bit by any of the big bugs. I just check the mailing lists and debian planet to see if anything big has popped up before doing an apt-get update apt-get upgrade. Obviously these aren't servers. In my experience as well. As I said in a previous post, i've heard that testing is the last to get security updates, which is not acceptable if you're running servers. I think the only problem with debian is the naming. Changing nothing but the name from unstable to cutting edge or something and there wouldn't be close to the outcry about how 'behind' debian is. IMHO. Well, there more or less needs to be more frequent stable releases... something along the lines of Redhat's quick releases. Okay... Redhat again.. i know i know... but you've got to admit they've got the release aspect of their distro pretty good. They are business people over there, and they know how frequent business users like to have updates, and when critical updates should be released. I'm just wondering if it is even POSSIBLE to follow the frequent release schedule that Redhat follows, or if it is not possible because most/all of the developers for Debian are volunteers and won't work to such a tight schedule. If we can find and identify the problems not allowing up-to-date releases, perhaps a solution can be found? -- Lang Is uniformity attainable? Millions of innocent men, women, and children, since the introduction of Christianity, have been burnt, tortured, fined, imprisoned; yet we have not advanced one inch towards uniformity. What has been the effect of coercion? To make one half of the world fools, and the other half hypocrites. -- Thomas Jefferson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unstable is unstable; stable is outdated
On Fri, Feb 01, 2002 at 04:03:40PM -0800, Jeremy C. Reed wrote: On 1 Feb 2002, Jeff S Wheeler wrote: On Fri, 2002-02-01 at 01:42, Jason Lim wrote: We have production boxes running unstable with no problem. Needed to run unstable because only unstable had some new software, unavailable in stable. Its a pity stable gets so outdated all the time as compared to other distros like Redhat and Caldera (stable still on 2.2 kernel), but thats a topic for a separate discussion. This is really a shame. It's my biggest complaint with Debian by far. The tools work very well, but the release cycle is such that you can't use a stable revision of the distribution and have modern packages available. Some up-to-date packages are located in the testing distribution. This probably has been (and currently) discussed elsewhere. I think the problems are that there are too many packages and too many dependencies. Yep, the old exponential dependancy problem... Maybe a solution would be to have a fourth collection (beside stable, testing and unstable): mini. It would not have thousands of packages. For example, it would only have about 150 to 300 packages. Only new packages are added if a vote approves. This sounds a little bit like what I think is needed; Debian needs to be partitioned into sub-distro's with their own independant release schedules. What do you think of having a mini distribution that limits the number of packages allowed? Why not just call it debian-core. Then you can have debian-gnome, debian-kde, debian-xfree etc. Each of these can be implemented as seperate distro's with their own releases, using Packages files pointing into the pool. This paritions the dependancies, making it all easier to manage, speeding the release cycle and potentialy allowing people to mix-n-match stable-core with unstable-gnome if they wish. -- -- ABO: finger [EMAIL PROTECTED] for more info, including pgp key -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unstable is unstable; stable is outdated
On Sat, 2 Feb 2002, Donovan Baarda wrote: This probably has been (and currently) discussed elsewhere. I think the problems are that there are too many packages and too many dependencies. Yep, the old exponential dependancy problem... I see the problems with unstable page is over 500 pages (448KB) long. Maybe a solution would be to have a fourth collection (beside stable, testing and unstable): mini. It would not have thousands of packages. For example, it would only have about 150 to 300 packages. Only new packages are added if a vote approves. This sounds a little bit like what I think is needed; Debian needs to be partitioned into sub-distro's with their own independant release schedules. What do you think of having a mini distribution that limits the number of packages allowed? Why not just call it debian-core. Then you can have debian-gnome, debian-kde, debian-xfree etc. Each of these can be implemented as seperate distro's with their own releases, using Packages files pointing into the pool. This paritions the dependancies, making it all easier to manage, speeding the release cycle and potentialy allowing people to mix-n-match stable-core with unstable-gnome if they wish. So do you mean that these sub-distros don't have any dependencies on any packages within the other sub-distros? Jeremy C. Reed echo '9,J8HD,fDGG8B@?:536FC5=8@I;C5?@H5B0D@5GBIELD54DL@8L?:5GDEJ8LDG1' |\ sed ss,s50EBsg | tr 0-M 'p.wBt SgiIlxmLhan:o,erDsduv/cyP' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
*****SPAM***** Re: unstable is unstable; stable is outdated]
Hi, Thank you for telling me. Unfortunately, Spews and OSIRUS (they use Spews' list, so essentially the same applies) have listed many ISPs in Hong Kong and around Asia, meaning many of us over here are blocked from sending emails to the USA if a company uses Spews. That is why we suggest that businesses use ORDB (http://www.ordb.com) as it blocks most spam, but ONLY blocks spam and very rarely legitimate emails (we use this list for our personal emails too). Spews is supposedly early warning, hence if the owner of Spews thinks there may be spam coming from a certain place, they block if off first, whether or not spam will really come through there or not. ORDB, on the other hand, uses automated testing to block mail servers, rather than rely on the decision of one or two unaccountable people with their own ideas. Telstra in Australia, PCCW (Pacific Century Cyberworks/ Hong Kong Telecom), Singtel, and others in Asia have many netblocks listed in Spews. Sprint is also has large chunks of netblocks blocked. We used it before and had too much legitimate business email blocked. So, again, thanks for telling me, but there is little I can do to unblock Asian ISPs. Spews is unaccountable to anyone and no one can contact them (which they say on their website). They have banged heads with many ISPs in Asia... maybe the owner of Spews is overly patriotic to the USA to the point of being racist (but I'll leave that discussion there). Sincerely, Jason - Original Message - From: Oliver Andrich [EMAIL PROTECTED] To: Jason Lim [EMAIL PROTECTED] Sent: Saturday, February 02, 2002 8:52 AM Subject: [[EMAIL PROTECTED]: *SPAM* Re: unstable is unstable; stable is outdated] Hi, may be it is of interest to you, that the mailservers of your provider are in a anti-spam list. If not, just delete this mail. Discovered it, when my spamassassin caugth your email. Best regards, Oliver -- -- --- Oliver Andrich | Tel.: 0261-5009075 IT Projektmanagement,| Mobil: 0172-6538591 Systemprogrammierung und -design | Fax: 069-13305990076 | Email: [EMAIL PROTECTED] -- --- Fingerpring: 2AB5 B998 8BD2 AC3A E12A 3A8A 171E 5B1B EC4B 3C2B -- --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unstable is unstable; stable is outdated
This paritions the dependancies, making it all easier to manage, speeding the release cycle and potentialy allowing people to mix-n-match stable-core with unstable-gnome if they wish. So do you mean that these sub-distros don't have any dependencies on any packages within the other sub-distros? I think that is what he means... that you could throw a hybrid system together. For example... most ISPs would probably want the most up to date apache and proftpd (or whatever your combination is). They don't really care to have the most up to date compilers or libraries or anything else... only what is required to get the latest apache and proftpd. I can see a problem in this idea though, as many packages have cross depedancies. EG. apache needs library A version 2, while proftpd needs library A version 3. How would that be handled? Upgrading to libarary A version 3 might break apache... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
unstable is unstable; stable is outdated
On Fri, 2002-02-01 at 01:42, Jason Lim wrote: We have production boxes running unstable with no problem. Needed to run unstable because only unstable had some new software, unavailable in stable. Its a pity stable gets so outdated all the time as compared to other distros like Redhat and Caldera (stable still on 2.2 kernel), but thats a topic for a separate discussion. This is really a shame. It's my biggest complaint with Debian by far. The tools work very well, but the release cycle is such that you can't use a stable revision of the distribution and have modern packages available. I can't imagine this issue is being ignored, but is it discussed on a policy list, probably? It seems like FreeBSD's -RELEASE, -STABLE, -CURRENT scheme works much better than what Debian has. I've never seen big political arguments on this mailing list, but I always hear that Debian as an organization is often too burdened with internal bickering and politics to move forward with big changes. Is that the case here? Just curious, not trying to start a flame war. -- Jeff S Wheeler [EMAIL PROTECTED] Software DevelopmentFive Elements, Inc http://www.five-elements.com/~jsw/
Re: unstable is unstable; stable is outdated
On Fri, 2002-02-01 at 01:42, Jason Lim wrote: We have production boxes running unstable with no problem. Needed to run unstable because only unstable had some new software, unavailable in stable. Its a pity stable gets so outdated all the time as compared to other distros like Redhat and Caldera (stable still on 2.2 kernel), but thats a topic for a separate discussion. This is really a shame. It's my biggest complaint with Debian by far. The tools work very well, but the release cycle is such that you can't use a stable revision of the distribution and have modern packages available. I agree. What I would like to know is how other Linux distros like Redhat (only mentioning Redhat because that is what many of our cusomters request, and nearly everyone knows it) can have pretty new stable releases? No release is going to be totally bug-free, and I think just about everyone (business and personal) know and accept this. Perhaps people are willing to trade in a few more bugs to have a far more up-to-date system? I know Debian likes to have stable REALLY VERY stable... but perhaps it is SO stable that is too outdated to be used in a production environment. I mean, I think Debian is the only Linux distro still shipping with a 2.2 kernel; everyone else has gone ahead with 2.4 for quite a long time now. I pretty much work with Linux exclusively in a business environment... so from a business of view (and I hate to say this... but...) I like Redhat more than Debian, in that a default install of Redhat comes with a 2.4 kernel, ext3, and lots of up-to-date tools, whereas with Debian I have to recompile a new kernel, download the various new tools to support the new kernel, etc... and as we all know, jumping from stable to unstable is problem-prone and doesn't worth flawlessly every time. I can't imagine this issue is being ignored, but is it discussed on a policy list, probably? It seems like FreeBSD's -RELEASE, -STABLE, -CURRENT scheme works much better than what Debian has. I've never seen big political arguments on this mailing list, but I always hear that Debian as an organization is often too burdened with internal bickering and politics to move forward with big changes. Is that the case here? Just curious, not trying to start a flame war. I also do not believe in flame wars, which are not at all constructive. I'd be very willing to engage in some constructive discussion with anyone, with ideas that are doable rather than ideals. I think Debian MAY be too weighed down in ideals, rather than focusing on getting a good opensource linux distro out there. Of course, there are probably many factors affecting Debian and making it slow to move, but surely something can be done to improve the situation? I know that as a company, we could donate a bit of money (with the economy as it is, not much though), but from what I can see, money isn't really where the problem lies... it is somewhere else. I don't know what I can personally do to help policy changes or anything like that, but I'd be willing to give my perspective and ideas on the matter, if that helps at all. Perhaps other business users out there would also like to give Debian a bit more input, so Debian becomes a viable business distro that isn't so out-of-date?
Re: unstable is unstable; stable is outdated
kernel, etc... and as we all know, jumping from stable to unstable is problem-prone and doesn't worth flawlessly every time. Why jump all the way to unstable, why not use testing? Testing is usually stable enough for most applications plus the various software packages are pretty up to date.
Re: unstable is unstable; stable is outdated
*** REPLY SEPARATOR *** On 2/1/02 at 4:25 PM Tim Quinlan wrote: kernel, etc... and as we all know, jumping from stable to unstable is problem-prone and doesn't worth flawlessly every time. Why jump all the way to unstable, why not use testing? Testing is usually stable enough for most applications plus the various software packages are pretty up to date. In my experience unstable is pretty damn stable as well. I upgraded a couple of boxen from stable to unstable a little over a year ago and haven't been bit by any of the big bugs. I just check the mailing lists and debian planet to see if anything big has popped up before doing an apt-get update apt-get upgrade. Obviously these aren't servers. I think the only problem with debian is the naming. Changing nothing but the name from unstable to cutting edge or something and there wouldn't be close to the outcry about how 'behind' debian is. IMHO. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- Lang Is uniformity attainable? Millions of innocent men, women, and children, since the introduction of Christianity, have been burnt, tortured, fined, imprisoned; yet we have not advanced one inch towards uniformity. What has been the effect of coercion? To make one half of the world fools, and the other half hypocrites. -- Thomas Jefferson
Re: unstable is unstable; stable is outdated
kernel, etc... and as we all know, jumping from stable to unstable is problem-prone and doesn't worth flawlessly every time. Why jump all the way to unstable, why not use testing? Testing is usually stable enough for most applications plus the various software packages are pretty up to date. I remember reading somewhere that security updates go to unstable first, then into security, then testing... meaning that testing was the last to get security updates. Is this wrong?
Re: unstable is unstable; stable is outdated
On 2/1/02 at 4:25 PM Tim Quinlan wrote: kernel, etc... and as we all know, jumping from stable to unstable is problem-prone and doesn't worth flawlessly every time. Why jump all the way to unstable, why not use testing? Testing is usually stable enough for most applications plus the various software packages are pretty up to date. In my experience unstable is pretty damn stable as well. I upgraded a couple of boxen from stable to unstable a little over a year ago and haven't been bit by any of the big bugs. I just check the mailing lists and debian planet to see if anything big has popped up before doing an apt-get update apt-get upgrade. Obviously these aren't servers. In my experience as well. As I said in a previous post, i've heard that testing is the last to get security updates, which is not acceptable if you're running servers. I think the only problem with debian is the naming. Changing nothing but the name from unstable to cutting edge or something and there wouldn't be close to the outcry about how 'behind' debian is. IMHO. Well, there more or less needs to be more frequent stable releases... something along the lines of Redhat's quick releases. Okay... Redhat again.. i know i know... but you've got to admit they've got the release aspect of their distro pretty good. They are business people over there, and they know how frequent business users like to have updates, and when critical updates should be released. I'm just wondering if it is even POSSIBLE to follow the frequent release schedule that Redhat follows, or if it is not possible because most/all of the developers for Debian are volunteers and won't work to such a tight schedule. If we can find and identify the problems not allowing up-to-date releases, perhaps a solution can be found?
Re: unstable is unstable; stable is outdated
I thinking the problem here, as I mentioned before, is one of semantics as opposed to a real problem. Options are: 1) unstable pros: Very up to date, cons: Occasion big bug that can do damage user: Someone who knows there way around Linux pretty well and likes to say,I use unstable 'cause I'm so cool! 2) testing pros: Pretty up to date, very stable cons: May have the latest-greatest version of an app a week or two after your buddy using unstable. Last to get security upgrades. user: Someone who actually uses their computer to get work done and is less worried about being the latest greatest cool guy. Someone who laughs at their co-working trying to figure out why init keeps bombing after his last unstable upgrade. 3) stable pros: Rock stable, quicker security updates than testing. cons: old user: critical server. Most of these characterization are user standpoint. If I had a server that was super critical, I'd use stable (or *BSD). The two servers I have don't have a huge load and it's not a big deal if they go down (not to sound like a huge power user, 'cause I'm talking about a home network and a minor server at work). I have testing on them. In short, if you're a user, it doesn't make sense to use stable. Use testing or unstable and you're system will be as up to date, if not more, as any distro. If you're running a server, just use testing, unless security is a big issue. Then use stable. Or use testing and keep a watch on the linux security pages, and manually apply the newest patches when they come out. IMHO, there is a level for any use inside the various debian trees. The biggest problem from a PR standpoint for debian is in the names. Feel free to disagree with any point I made, 'cause I'm not as good as I sound. On 2/2/02 at 6:39 AM Jason Lim wrote: On 2/1/02 at 4:25 PM Tim Quinlan wrote: kernel, etc... and as we all know, jumping from stable to unstable is problem-prone and doesn't worth flawlessly every time. Why jump all the way to unstable, why not use testing? Testing is usually stable enough for most applications plus the various software packages are pretty up to date. In my experience unstable is pretty damn stable as well. I upgraded a couple of boxen from stable to unstable a little over a year ago and haven't been bit by any of the big bugs. I just check the mailing lists and debian planet to see if anything big has popped up before doing an apt-get update apt-get upgrade. Obviously these aren't servers. In my experience as well. As I said in a previous post, i've heard that testing is the last to get security updates, which is not acceptable if you're running servers. I think the only problem with debian is the naming. Changing nothing but the name from unstable to cutting edge or something and there wouldn't be close to the outcry about how 'behind' debian is. IMHO. Well, there more or less needs to be more frequent stable releases... something along the lines of Redhat's quick releases. Okay... Redhat again.. i know i know... but you've got to admit they've got the release aspect of their distro pretty good. They are business people over there, and they know how frequent business users like to have updates, and when critical updates should be released. I'm just wondering if it is even POSSIBLE to follow the frequent release schedule that Redhat follows, or if it is not possible because most/all of the developers for Debian are volunteers and won't work to such a tight schedule. If we can find and identify the problems not allowing up-to-date releases, perhaps a solution can be found? -- Lang Is uniformity attainable? Millions of innocent men, women, and children, since the introduction of Christianity, have been burnt, tortured, fined, imprisoned; yet we have not advanced one inch towards uniformity. What has been the effect of coercion? To make one half of the world fools, and the other half hypocrites. -- Thomas Jefferson
Re: unstable is unstable; stable is outdated
Feel free to disagree with any point I made, 'cause I'm not as good as I sound. I'll throw my $.02 here. I think there is a more fundamental problem here. That is somehow incorporating the latest apache into stable will somehow make stable break. What needs to get done is to build a distro which isolates applications to a sufficient degree that they don't break each other. If you are able to build a distro like that then all you have to worry about is the application itself. If postgres 7.2 is deemed stable then you add it to your stable distro. Apple has done very interesting things with their bundle system if anyone cares to look, encap also looks pretty interesting. Ideally a distribution should act like this. Applications should not overly interfere with each other. It should be possible to install multiple versions of the same application. The distribution should be able to incorporate manually installed applications (make install) It should be possible to reconstruct the package database from the disk drive. all that and apt goodness too of course. feel free to add your own to the list. :wq Tim Uckun US Investigations Services/Due Diligence http://www.diligence.com/
Re: unstable is unstable; stable is outdated
On 1 Feb 2002, Jeff S Wheeler wrote: On Fri, 2002-02-01 at 01:42, Jason Lim wrote: We have production boxes running unstable with no problem. Needed to run unstable because only unstable had some new software, unavailable in stable. Its a pity stable gets so outdated all the time as compared to other distros like Redhat and Caldera (stable still on 2.2 kernel), but thats a topic for a separate discussion. This is really a shame. It's my biggest complaint with Debian by far. The tools work very well, but the release cycle is such that you can't use a stable revision of the distribution and have modern packages available. Some up-to-date packages are located in the testing distribution. This probably has been (and currently) discussed elsewhere. I think the problems are that there are too many packages and too many dependencies. Maybe a solution would be to have a fourth collection (beside stable, testing and unstable): mini. It would not have thousands of packages. For example, it would only have about 150 to 300 packages. Only new packages are added if a vote approves. The mini collection can be done similar to the testing distribution: The mini distribution can be automatically-generated from the unstable distribution by a set of scripts which attempt to move over packages which lack important bugs and don't have dependency conflicts. Look here for ideas: http://people.debian.org/~jules/testingfaq.html What do you think of having a mini distribution that limits the number of packages allowed? I can't imagine this issue is being ignored, but is it discussed on a policy list, probably? It seems like FreeBSD's -RELEASE, -STABLE, -CURRENT scheme works much better than what Debian has. I've never seen One difference is that FreeBSD's ports collection is different than their base collection. The base (or main) collection has the -stable and -current development branches. But the ports collection is only developed in one: -current. (FreeBSD builds packages for -current and recent releases, but they only use one, the current, ports collection. Because of this, some consider the -current ports collection to be like unstable.) Jeremy C. Reed p.s. I am writing an article about the BSD ports collections, in regards to *stable* ports collections. If you are interested in reviewing a rough draft, let me know off-list.
Re: unstable is unstable; stable is outdated
If ONLY there was some way to make testing get security updates faster... then I am almost sure testing would become the choice for many people running servers and such. It almost sounds like Redhat 7.2 (compared side to side). Options are: 1) unstable pros: Very up to date, cons: Occasion big bug that can do damage user: Someone who knows there way around Linux pretty well and likes to say,I use unstable 'cause I'm so cool! 2) testing pros: Pretty up to date, very stable cons: May have the latest-greatest version of an app a week or two after your buddy using unstable. Last to get security upgrades. user: Someone who actually uses their computer to get work done and is less worried about being the latest greatest cool guy. Someone who laughs at their co-working trying to figure out why init keeps bombing after his last unstable upgrade. 3) stable pros: Rock stable, quicker security updates than testing. cons: old user: critical server. Most of these characterization are user standpoint. If I had a server that was super critical, I'd use stable (or *BSD). The two servers I have don't have a huge load and it's not a big deal if they go down (not to sound like a huge power user, 'cause I'm talking about a home network and a minor server at work). I have testing on them. In short, if you're a user, it doesn't make sense to use stable. Use testing or unstable and you're system will be as up to date, if not more, as any distro. If you're running a server, just use testing, unless security is a big issue. Then use stable. Or use testing and keep a watch on the linux security pages, and manually apply the newest patches when they come out. IMHO, there is a level for any use inside the various debian trees. The biggest problem from a PR standpoint for debian is in the names. Feel free to disagree with any point I made, 'cause I'm not as good as I sound. On 2/2/02 at 6:39 AM Jason Lim wrote: On 2/1/02 at 4:25 PM Tim Quinlan wrote: kernel, etc... and as we all know, jumping from stable to unstable is problem-prone and doesn't worth flawlessly every time. Why jump all the way to unstable, why not use testing? Testing is usually stable enough for most applications plus the various software packages are pretty up to date. In my experience unstable is pretty damn stable as well. I upgraded a couple of boxen from stable to unstable a little over a year ago and haven't been bit by any of the big bugs. I just check the mailing lists and debian planet to see if anything big has popped up before doing an apt-get update apt-get upgrade. Obviously these aren't servers. In my experience as well. As I said in a previous post, i've heard that testing is the last to get security updates, which is not acceptable if you're running servers. I think the only problem with debian is the naming. Changing nothing but the name from unstable to cutting edge or something and there wouldn't be close to the outcry about how 'behind' debian is. IMHO. Well, there more or less needs to be more frequent stable releases... something along the lines of Redhat's quick releases. Okay... Redhat again.. i know i know... but you've got to admit they've got the release aspect of their distro pretty good. They are business people over there, and they know how frequent business users like to have updates, and when critical updates should be released. I'm just wondering if it is even POSSIBLE to follow the frequent release schedule that Redhat follows, or if it is not possible because most/all of the developers for Debian are volunteers and won't work to such a tight schedule. If we can find and identify the problems not allowing up-to-date releases, perhaps a solution can be found? -- Lang Is uniformity attainable? Millions of innocent men, women, and children, since the introduction of Christianity, have been burnt, tortured, fined, imprisoned; yet we have not advanced one inch towards uniformity. What has been the effect of coercion? To make one half of the world fools, and the other half hypocrites. -- Thomas Jefferson
Re: unstable is unstable; stable is outdated
On Fri, Feb 01, 2002 at 04:03:40PM -0800, Jeremy C. Reed wrote: On 1 Feb 2002, Jeff S Wheeler wrote: On Fri, 2002-02-01 at 01:42, Jason Lim wrote: We have production boxes running unstable with no problem. Needed to run unstable because only unstable had some new software, unavailable in stable. Its a pity stable gets so outdated all the time as compared to other distros like Redhat and Caldera (stable still on 2.2 kernel), but thats a topic for a separate discussion. This is really a shame. It's my biggest complaint with Debian by far. The tools work very well, but the release cycle is such that you can't use a stable revision of the distribution and have modern packages available. Some up-to-date packages are located in the testing distribution. This probably has been (and currently) discussed elsewhere. I think the problems are that there are too many packages and too many dependencies. Yep, the old exponential dependancy problem... Maybe a solution would be to have a fourth collection (beside stable, testing and unstable): mini. It would not have thousands of packages. For example, it would only have about 150 to 300 packages. Only new packages are added if a vote approves. This sounds a little bit like what I think is needed; Debian needs to be partitioned into sub-distro's with their own independant release schedules. What do you think of having a mini distribution that limits the number of packages allowed? Why not just call it debian-core. Then you can have debian-gnome, debian-kde, debian-xfree etc. Each of these can be implemented as seperate distro's with their own releases, using Packages files pointing into the pool. This paritions the dependancies, making it all easier to manage, speeding the release cycle and potentialy allowing people to mix-n-match stable-core with unstable-gnome if they wish. -- -- ABO: finger [EMAIL PROTECTED] for more info, including pgp key --
Re: unstable is unstable; stable is outdated
On Sat, 2 Feb 2002, Donovan Baarda wrote: This probably has been (and currently) discussed elsewhere. I think the problems are that there are too many packages and too many dependencies. Yep, the old exponential dependancy problem... I see the problems with unstable page is over 500 pages (448KB) long. Maybe a solution would be to have a fourth collection (beside stable, testing and unstable): mini. It would not have thousands of packages. For example, it would only have about 150 to 300 packages. Only new packages are added if a vote approves. This sounds a little bit like what I think is needed; Debian needs to be partitioned into sub-distro's with their own independant release schedules. What do you think of having a mini distribution that limits the number of packages allowed? Why not just call it debian-core. Then you can have debian-gnome, debian-kde, debian-xfree etc. Each of these can be implemented as seperate distro's with their own releases, using Packages files pointing into the pool. This paritions the dependancies, making it all easier to manage, speeding the release cycle and potentialy allowing people to mix-n-match stable-core with unstable-gnome if they wish. So do you mean that these sub-distros don't have any dependencies on any packages within the other sub-distros? Jeremy C. Reed echo '9,J8HD,[EMAIL PROTECTED]:[EMAIL PROTECTED];[EMAIL PROTECTED]@5GBIELD54DL@8L?:5GDEJ8LDG1' |\ sed ss,s50EBsg | tr 0-M 'p.wBt SgiIlxmLhan:o,erDsduv/cyP'
