Re: Debian's Linux kernel continues to regress on freedom
On Wed, 12 Sep 2007 00:39:05 -0400, Nathanael Nerode [EMAIL PROTECTED] wrote: Non-free material is being included in main for the benefit of *precisely zero* users. There's no two ways about this: this is a Social Contract violation. I guess the Social Contract really is a joke. I don't know why new applicants are supposed to agree to it. Old members apparently violate it at will for years with no consequences. It doesn't make me respect Debian very much. Developers you have, are better than developers you don't have. The ones you have, make Debian what it is. If reality doesn't match the theory, change the theory, not the reality. An obsession with freedom that insists on removing RFCs from source tarballs, is absurd. Why not change the contract. -- Internet service http://www.isp2dial.com/
Re: Debian's Linux kernel continues to regress on freedom
On Wed, 12 Sep 2007 09:56:20 +0200, Miriam Ruiz [EMAIL PROTECTED] wrote: 2007/9/12, Raphael Hertzog [EMAIL PROTECTED]: On Wed, 12 Sep 2007, Miriam Ruiz wrote: 2007/9/12, John Kelly [EMAIL PROTECTED]: An obsession with freedom that insists on removing RFCs from source tarballs, is absurd. Why not change the contract. You're not talking seriously, are you? Why not? Is it difficult to acknowledge that not all people think the same? Have you noticed that none of the GR end up with 100% on one side and 0% on the other? So, what exact change in the social contract are you proposing? From a random RFC: http://www.ietf.org/rfc/rfc2060.txt Distribution of this memo is unlimited. With RFCs available to anyone with a web browser, it's absurd to say they're non-free, and a waste of time removing them from Debian. If people need that spelled out in a contract, then spell it out in a way that can't be misconstrued. -- Internet service http://www.isp2dial.com/
Re: Debian's Linux kernel continues to regress on freedom
On Wed, 12 Sep 2007 08:00:34 -0500, Ron Johnson [EMAIL PROTECTED] wrote: Only you are talking about willy-nilly changes... besides we as Debian only want our users the freedom to be able to if they wanted it, to willy-nilly modify the RFC text. I'm shaking my head in stunned disbelief. He says We as Debian, but I wonder if a majority truly agree. IMO, only wackos would willy-nilly modify RFC text. -- Internet service http://www.isp2dial.com/
Re: Debian's Linux kernel continues to regress on freedom
On Wed, 12 Sep 2007 18:13:53 +0200, Pierre Habouzit [EMAIL PROTECTED] wrote: Only you are talking about willy-nilly changes... besides we as Debian only want our users the freedom to be able to if they wanted it, to willy-nilly modify the RFC text. I'm shaking my head in stunned disbelief. He says We as Debian, but I wonder if a majority truly agree. IMO, only wackos would willy-nilly modify RFC text. Damn, now I'm a wacko. So I dare say you're an insulting moron. If Debian is the distro for wackos, so be it. But I have to wonder if your loud clique could muster a majority in a vote over whether RFCs should be removed from Debian. -- Internet service http://www.isp2dial.com/
Re: Debian's Linux kernel continues to regress on freedom
On Wed, 12 Sep 2007 18:35:18 +0200, Pierre Habouzit [EMAIL PROTECTED] wrote: there is little point in shipping rfc's that are mirrored everywhere on the interwebs, and rfc's are clearly non-free Your sentence is self contradictory. For all practical intents and purposes, mirrored everywhere equals free. I said I'm a wacko Got it. -- Internet service http://www.isp2dial.com/
Re: Debian's Linux kernel continues to regress on freedom
On Wed, 12 Sep 2007 10:20:44 -0700, Russ Allbery [EMAIL PROTECTED] wrote: We previously had a vote on whether the DFSG should extend to the entire contents of the archive or only to software, and the vote outcome was that it extended to the entire contents of the archive. Recently, or some time ago? -- Internet service http://www.isp2dial.com/
Re: Debian's Linux kernel continues to regress on freedom
On Wed, 12 Sep 2007 19:28:53 +0200, Sven Luther [EMAIL PROTECTED] wrote: IF you close your eyes while people get attacked beside you for trying to do what you are calling for, then you have nothing to complain when things not happen like you want. Especially when those people who involve themselves get the kind of suffering and abuse i got because of my implication in the non-free firmware discussion. Note, i have since been expulsed, banned, humiliated, punished, kicked out of the kernel team, and in general am considered as a sub-human of the most evil kind, while everyone congratulated themselves to get ride of me. Debian is no different from any other clique. The crowd follows those who appear strong, and devour any who appear weak. If Debian's highly esteemed social contract is for the benefit of users, then why not let users vote. The outcome may be different if another vote was taken, with language specifically exempting RFCs from the DFSG. -- Internet service http://www.isp2dial.com/
Re: Debian's Linux kernel continues to regress on freedom
On Wed, 12 Sep 2007 20:27:41 +0200, Miriam Ruiz [EMAIL PROTECTED] wrote: 2007/9/12, John Kelly [EMAIL PROTECTED]: If Debian's highly esteemed social contract is for the benefit of users, then why not let users vote. The outcome may be different if another vote was taken, with language specifically exempting RFCs from the DFSG. This is pure demagogy [1] and adds nothing productive to the debate apart from trying to be a provocation. Again, if Debian's highly esteemed social contract is for the benefit of users, then why not let users vote? Or are you just a crowd of hypocrites? -- Internet service http://www.isp2dial.com/
Re: Debian's Linux kernel continues to regress on freedom
On Wed, 12 Sep 2007 20:45:07 +0200, Roland Mas [EMAIL PROTECTED] wrote: John Kelly, 2007-09-12 18:33:12 + : Again, if Debian's highly esteemed social contract is for the benefit of users, then why not let users vote? We do, actually. Those users who do show interest in influencing the course of Debian by concrete actions rather than by mailing-list trolling are entitled to vote. Others aren't. How do we know the difference? The criterion is known as the NM process. It's open to all. If only maintainers qualify as users then your social contract is a farce. -- Internet service http://www.isp2dial.com/
Re: Debian's Linux kernel continues to regress on freedom
On Wed, 12 Sep 2007 20:45:13 +0200, Pierre Habouzit [EMAIL PROTECTED] wrote: We don't see the point to bend our ideals for obnoxious or invalid reasons (having RFCs in the source package is completely useless to the user in the first place). If you truly believe that users will never see them anyway, then stop wasting time removing them. So can you now stop, or at least bring valid arguments ? If you stop removing RFCs from Debian, you'll still be a crowd of wackos, but at least it won't be so immediately obvious to the casual passerby. -- Internet service http://www.isp2dial.com/
Re: RFC: changes to default password strength checks in pam_unix
On Tue, 4 Sep 2007 07:53:08 + (UTC), Oleg Verych [EMAIL PROTECTED] wrote: What about having more secure Debian's sshd_config by default? PermitRootLogin no DenyUsers * Doing remote ssh installations without any console access will make you unhappy with that default. -- Internet service http://www.isp2dial.com/
Re: RFC: changes to default password strength checks in pam_unix
On Tue, 04 Sep 2007 12:31:15 +0300, Lars Wirzenius [EMAIL PROTECTED] wrote: I stop brute force attacks by sending auth log messages to a FIFO which I read with a perl script. After 10 login failures, your IP is firewalled for 24 hours. I'm sure it does work great. Can you work on making sure it is the default in lenny if openssh-server is installed? It's the type of thing an admin can do locally: set up syslog.conf so that it copies auth log data to a FIFO: auth.info -/var/log/auth auth.=notice-/var/log/auth.notice auth.=notice|/var/tmp/hostaccess.sshd And then read it with a program or script which makes local decisions on how to handle it. If someone wants to take that idea and distribute it with debian, go for it. Personally, I don't have time to fight the political battle that would ensue. -- Internet service http://www.isp2dial.com/
Re: RFC: changes to default password strength checks in pam_unix
On Tue, 4 Sep 2007 14:50:25 -0600, Dwayne C. Litzenberger [EMAIL PROTECTED] wrote: On most of my boxes, passwords are useless for anything except local authentication, and even for that, they aren't used much. How about a Debian policy that enumerates the specific cases where passwords are allowed to be used for authentication, and states that password authentication must be disabled by default for everything else? IMO, it's better to leave that policy at a local level, determined by local admins. Excessive legislation at a federal level is undesirable to me. -- Internet service http://www.isp2dial.com/
Re: RFC: changes to default password strength checks in pam_unix
On Sep 3, Lars Wirzenius wrote: ti, 2007-09-04 kello 10:17 +0900, Miles Bader kirjoitti: If the system is excessively anal about what passwords it will let you use, people will just start writing them down... That is arguably better than having passwords which can be guessed by doing brute-force attackes over ssh. I stop brute force attacks by sending auth log messages to a FIFO which I read with a perl script. After 10 login failures, your IP is firewalled for 24 hours. Works great. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: flock() and sendmail
On Fri, 17 Nov 2006 11:14:21 +, Roger Leigh [EMAIL PROTECTED] wrote: It's almost always a bad idea to use flock() instead of fcntl(). fnctl() locking is effectively deprecating flock() I heard it was the other way around. Please explain ... If you look at SUSv3/POSIX, you'll see that fcntl()/lockf() locking is the only standardised form of locking. flock() isn't included in the standard. I have no reason to limit my choices to standards.
Re: flock() and sendmail
On Fri, 17 Nov 2006 15:42:21 +0100, Michael Banck [EMAIL PROTECTED] wrote: On Fri, Nov 17, 2006 at 01:02:15PM +, John Kelly wrote: On Fri, 17 Nov 2006 11:14:21 +, Roger Leigh [EMAIL PROTECTED] wrote: It's almost always a bad idea to use flock() instead of fcntl(). fnctl() locking is effectively deprecating flock() I heard it was the other way around. Please explain ... This list is not for discussing different Un*x locking implementations, please find advise on which you prefer elsewhere. Why are you telling me? Roger raised that issue. I'm discussing flock() with the debain sendmail package and the linux 2.6 kernel. Or does that annoy you too?
Re: flock() and sendmail
On Fri, 17 Nov 2006 18:33:10 +0100, Michael Banck [EMAIL PROTECTED] wrote: On Fri, Nov 17, 2006 at 03:37:56PM +, John Kelly wrote: I'm discussing flock() with the debain sendmail package and the linux 2.6 kernel. Or does that annoy you too? To be honest, I don't see why this should concern all other Debian developers, yes. I didn't know all other Debian developers had appointed you as the topic Gestapo. Heil Hitler!
Re: flock() and sendmail
On Fri, 17 Nov 2006 19:09:33 +0100, Kurt Roeckx [EMAIL PROTECTED] wrote: Anyway, from the linux/Documentation/locks.txt file: 1.2.1 Typical Problems - Sendmail - Because sendmail was unable to use the old flock() emulation I believe flock() *emulation* is no longer used in 2.6 kernels. installations use fcntl() instead of flock(). This is true of Slackware 3.0 for example. This gave rise to some other subtle problems if sendmail was configured to rebuild the alias file. Sendmail tried to lock the aliases.dir file with fcntl() at the same time as the GDBM routines tried to lock this file with flock(). With pre 1.3.96 kernels this could result in deadlocks that, over time, or under a very heavy mail load, would eventually cause the kernel to lock solid with deadlocked processes. Then I have to wonder why sendmail is still configured to use fcntl() when running on linux. Sounds like the modern kernel implementation of flock() would be better.
Re: flock() and sendmail
On Fri, 17 Nov 2006 19:54:13 +0100, Kurt Roeckx [EMAIL PROTECTED] wrote: I actually see no good reason to want to use flock() over fcntl(). Maybe because the fcntl() interface follows the completely stupid semantics of System V and IEEE Std 1003.1-1988 (``POSIX.1'') that require that all locks associated with a file for a given process are removed when any file descriptor for that file is closed by that process. This semantic means that applica- tions must be aware of any files that a subroutine library may access. For example if an application for updating the password file locks the password file database while making the update, and then calls getpwnam(3) to retrieve a record, the lock will be lost because getpwnam(3) opens, reads, and closes the password database. The database close will release all locks that the process has associated with the database, even if the library routine never requested a lock on the data- base. Another minor semantic problem with this interface is that locks are not inherited by a child process created using the fork(2) function. The flock(2) interface has much more rational last close semantics and allows locks to be inherited by child processes. Flock(2) is recommended for applications that want to ensure the integrity of their locks when using library routines or wish to pass locks to their children. http://leaf.dragonflybsd.org/cgi/web-man?command=fcntlsection=2
Re: flock() and sendmail
On Fri, 17 Nov 2006 20:09:54 +0100, Michael Banck [EMAIL PROTECTED] wrote: On Fri, Nov 17, 2006 at 06:12:44PM +, John Kelly wrote: Heil Hitler! QED. Godwin's law only applies when the comparison is unfair.
Re: flock() and sendmail
On Thu, 16 Nov 2006 11:24:34 -0800 (PST), Richard A Nelson [EMAIL PROTECTED] wrote: ** NOTE: Override HASFLOCK as you will but, as of 1.99.6, mixed-style ** file locking is no longer allowed. In particular, make sure ** your DBM library and sendmail are both using either flock(2) ** *or* fcntl(2) file locking, but not both. This, indeed, is the important part ! DB has changed alot, and now has its own locking system, and whatever it uses to lock the entire DB is what should be used by its callers. Has DB changed from fcntl to flock ? I don't know. Are you trying to access the sendmail databases from another program that has differing locking conventions ? Not yet. You fail to provide any hints as to on why fcntl which is used instead of flock is causing you grief. No grief yet. So far, I'm only studying your package to see what the possibilities are. I need to make some local customizations, and it seemed like a good idea, while I'm in there, to use flock() instead of fcntl(), if there are no conflicts. DBM is obsoleted by Berkeley DB if I understand correctly, so maybe the note about DBM won't matter to me. But there is still the question of how Berkeley DB locking interacts with sendmail's use of flock(), if at all.
flock() and sendmail
sendmail defines HASFLOCK=0, apparently because, as configure says: # flock() doens't work over NFS and there's a rumour of b0rkedness in # Linux 2.4.x kernels ;( and include/sm/conf.h says: ** NOTE: Override HASFLOCK as you will but, as of 1.99.6, mixed-style ** file locking is no longer allowed. In particular, make sure ** your DBM library and sendmail are both using either flock(2) ** *or* fcntl(2) file locking, but not both. I don't need NFS with sendmail. Surely flock() is not *still* broken in 2.6 kernels? Any advice?
Re: RFC: ITP: prayer -- fast IMAP-based web mail system with few dependencies
On Thu, 9 Nov 2006 01:58:19 +0100, Magnus Holmgren [EMAIL PROTECTED] wrote: Prayer is geared towards large-scale, perhaps even *very* large-scale installations. It offers speed and low resource usage That's attractive to me. Changing the appearance is rather hard Like the doctor said: if it hurts, don't do that. the purpose of Prayer was to fit on top of UW-based mail systems which really weren't designed to run Webmail. The new mix format mailbox improves UW performance. But in any case, a stateful webmail like prayer will always perform better, no matter what the imap server. Now, after 5 years, they don't need it anymore. No more releases are planned. What will they do, then? Comments are welcome (It's not that I want to give up, but it's a bit silly to maintain a package nobody uses.) I've tried many webmail systems, and prayer is my last hope. :-) Why not package it up the way it is, with minimal changes? Maybe a few of us can hack some improvements in, over time.
