Re: Bits from the release team: the plans for etch
Andreas Barth wrote: * Javier Fernández-Sanguino Peña ([EMAIL PROTECTED]) [051026 18:09]: We can provide a sensible default for system users' removals that copes with most situations and leave a door open (through debconf) to sysadmins that want to fiddle with system users. I really want to warn to try to be too smart by half. Reserving the name/uid-space by not removing the accounts works reasonable well, and having at maximum 5-10 unnecessary accounts is also not the end of the world either. Problem being, if daemons don't remove their (supposedly exclusive-use) accounts, you can end in two years with 100 unnecessary accounts in a workstation. -- HTH, Massa
Re: Bits from the release team: the plans for etch
Andreas Barth wrote: * Humberto Massa ([EMAIL PROTECTED]) [051026 18:28]: Andreas Barth wrote: * Javier Fernández-Sanguino Peña ([EMAIL PROTECTED]) [051026 18:09]: We can provide a sensible default for system users' removals that copes with most situations and leave a door open (through debconf) to sysadmins that want to fiddle with system users. I really want to warn to try to be too smart by half. Reserving the name/uid-space by not removing the accounts works reasonable well, and having at maximum 5-10 unnecessary accounts is also not the end of the world either. Problem being, if daemons don't remove their (supposedly exclusive-use) accounts, you can end in two years with 100 unnecessary accounts in a workstation. How many daemon packages do you install in two years? I even doubt that we have 100 packages that add accounts at all in debian. count them and you'll see. Remember sarge has 17000 packages, how many of those do you think can add a user? in my workstation I try out a new package (for scientfic computing, a game for Lucas, a new development package) at least once each two days, and a lot of times they come with their libs and their daemons -- and their users. So I see them, and think oh, no, this is not what I thought it would be, and --purge them. And the daemons' users pile up in /etc/passwd. -- HTH Massa
Re: Bits from the release team: the plans for etch
Andreas Barth wrote: * Humberto Massa ([EMAIL PROTECTED]) [051026 18:34]: in my workstation I try out a new package (for scientfic computing, a game for Lucas, a new development package) at least once each two days, and a lot of times they come with their libs and their daemons -- and their users. So I see them, and think oh, no, this is not what I thought it would be, and --purge them. And the daemons' users pile up in /etc/passwd. well, perhaps take it as administrators job to clean up /etc/passwd from time to time if you install that many packages (because you as administrator know which users were co-used with someone else, and which not). But this is definitly not the most common scenario. It seems that you still did not get my point. My point is, in a SoHo workstation, this is exactly the most common scenario nowadays (example: hmm. let me try this new dvd-player... I open synaptic, install it, ... nah, it does not work as I expected [but it installed gstreamer, jackd, etc in the process] let me try the next one in the list...) -- HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the release team: the plans for etch
Stephen Frost wrote: * Andreas Barth ([EMAIL PROTECTED]) wrote: * Stephen Frost ([EMAIL PROTECTED]) [051026 20:13]: This is just patently false, as has been pointed out elsewhere. What security hole, exactly, is created by orphaning a file? Well, if some process (maybe within the package) creates a private log file that contains sensitive information, and this log file can later on be read by a process with much less privileges, this is usually considered as security relevant issue. Except log files are supposed to be removed and I don't know of any actual case of this happening anyway. Additionally, this is *not* a problem with the orphaning of the file, it's a problem with the reuse of a previously-used uid. I could see adding a system to track previously-used uids and not reusing them. I don't believe using passwd for that (and keeping unused accounts in passwd/shadow/group/gshadow/etc) is appropriate. It would seem enough to me, at least, to keep an ever-increasing counter where the current value is the next available uid. This could be reset if it reaches the max, or an error presented to the user about it or some such. I'm not convinced that's necessary but I could see it being something reasonable to do. Just leaving around unused accounts isn't reasonable. one (more interesting, maybe) approach could be using some automated method to see what are _every_ _single_ user-id created by our packages (not very difficult) and collecting them in a single package, with UNIQUE uids (so www-data will be , no matter what): this way we can purge users at --purge time. -- HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: init.d script for iptables ruleset
@ 21/09/2005 02:25 : wrote Matthew Palmer : On Wed, Sep 21, 2005 at 01:12:38AM -, Samuel Jean wrote: Here it goes. I wondered about a clever way to load my iptables ruleset via init.d's script. Surprisingly, I didn't find any with Debian. I didn't search that much though. Have a look at Shorewall -- it does similar things to what you're proposing, and is already written. There's probably also a lot of other firewall maintenance systems with similar methods. - Matt I, personally, use FireHOL and I'm more satisfied with it (=simpler) than I was with Shorewall. YMMV. -- HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Easy third-party package installer for debian-based distributions
@ 18/09/2005 17:55 : wrote Josselin Mouette : This is complete overkill. The only thing currently missing in your scenario is support in apt-get and synaptic for grabbing dependencies for a single binary package. E.g. apt-get install foo.deb or synaptic foo.deb. There was some patch to apt that allowed this, but people seemed not to like it for some reason... Personally, I think that apt-get install --from http://someserver.com/debian,main,etch packagename_version_arch.deb or apt-get install --from http://someserver.com/debian,main,etch packagename should do the same as: 1. editing sources.list and putting deb http://...; there; 2. apt-get update ONLY FROM the line inserted in (1) 3. editing apt.conf and giving a BIG priority to the line 4. apt-get -f install packagename[=version] 5. UNDO STEPS 3, 2, 1 with the twist that the default --from would be file:/$PWD,., and that the file: protocol would read the directory in absence of Packages file. -- HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: CDDL, OpenSolaris, Choice-of-venue and the star package ...
I doubt that people who do not wish to become legally bound to appear at the the author's home court whenever he files a frivolous lawsuit can be meaningfully described as a group of persons that can be discriminated against. If everybody belongs to the group, is it meaningfull to discriminate against it? Try people who do not have enough money to travel to $VENUE to defend themselves from a frivolous lawsuit -- one that they will lose by defaulting their court appearance. I think Debian agrees that poor people in general is a group that is protected by DFSG#5. -- HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: CDDL, OpenSolaris, Choice-of-venue and the star package ...
Whereas the alternative may be that licensors are unable to afford the enforcement of their license. Would you prefer to discriminate against them? YES. Please. The DFSG #5 says you should not discriminate the licensee; the licensor is OK. Debian does, in an active basis, discriminate against licensors: if they refuse to release source code; if they license their documentation under the GDFL, MPL (?), old QPL, etc, etc, etc. Free Software is about the licensors (copyright owners) relinquishing some of their rights to assure the rights of the commons. The legal system discriminates in favour of rich people. That's true regardless of license conditions. That's exactly why we (should) discriminate in favour of poor people. -- HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: CDDL, OpenSolaris, Choice-of-venue and the star package ...
The DFSG are not holy writ, but how about if I phrase it as discrimination against licensors without money? DFSG #5: No Discrimination Against Persons or Groups The license must not discriminate against any person or group of persons. This implies, at least to me, that the _licensor_ is not allowed to discriminate against a person or group, because he/she is the one who chooses the license. -- HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: a desperate request for licence metadata (was Re: migrating w iki content from twiki (w.d.net) to moinmoin (w.d.org))
I might be slow, but can you explain why we need a license for this? I do not need to license my books, but I do need to license my software. Why should the wiki documents be treated more like software than a book? Yes, you do need a license to the content of your books. Only thing is, when you buy a book you are buying the right to read it. NOT the right to copy it. NOT the right to modify it. NOT the right to redistribute (modified or not) copies. The wiki content is useful for other people, not only for them to read, but also for them to copy, modify and redistribute. And for them to do just that they need an explicit license. -- HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: a desperate request for licence metadata (was Re: migrating w iki content from twiki (w.d.net) to moinmoin (w.d.org))
Actually, I stand partially corrected as of: Actually, in Norway, I got a limited right to copy it, a given right to modify it, a limited right to distribute it, and a limited right to distribute copies. Down here (Brasil) -- and I suspect in the USofA too -- NO (or, better saying, extremely limited) rights to modifying copyrighted works (IOW the _creation_ of derivative works is an exclusive right of the copyright holder modulus some fair use things) And I find that these rights are sufficient for my use of the books. The wiki content is useful for other people, not only for them to read, but also for them to copy, modify and redistribute. And for them to do just that they need an explicit license. Which I fail to understand, as the limited rights provided to me by law should be sufficient for the wiki content in most cases. Is it not like this where you are? Not really. Remember that this is Debian, and we like our stuff Free. The limited rights do not permit a wiki reader to modify an article and publish (in a magazine for instance) the modified article -- and we would like to have such rights (as we do have for all our software). Other thing is that there is no _real_ difference between software and documentation. What if I publish a bash/perl/python script on the wiki and it gets modified and then used as part of another, bigger piece of software -- exactly because it's useful? Got it? -- HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#326578: ITP: bashpodder -- Easy to use RSS aggregator bas h script
* Hamish Moffatt :: I just packaged podracer last week, which is a derivative of bashpodder. Is there any benefit to having both? The podracer license is MIT/BSD-style, so if the bashpodder license is GPL, something's not quite right! Does a 14-line bash script (*) contains enough creative work to be copyrightable? Anyway, podracer does not seem a derivative work, having a big piece of python included. (*) bashpodder in all its glory, sans comments: cd $(dirname $0) datadir=$(date +%Y-%m-%d) test -d $datadir || mkdir $datadir || exit 1 rm -f temp.log while read podcast; do file=$(wget -q $podcast -O - | xsltproc parse_enclosure.xsl - 2 /dev/null) || file=$(wget -q $podcast -O - | tr '\r' '\n' | tr \' \ | sed -n 's/.*url=\([^]*\).*/\1/p') for url in $file; do grep -q $url podcast.log || wget -q -P $datadir $url echo $url temp.log done done bp.conf cat podcast.log temp.log sort temp.log | uniq podcast.log rm temp.log ls $datadir | grep -v m3u $datadir/podcast.m3u -- HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: better init.d/* : who carres ?
** Peter Palfrader ::
mysqld_get_param () {
/usr/sbin/mysqld --print-defaults |
sed -ne s/^.*--$1=\\([^ ]\\+\\).*\$/\\1/p
}
And harder to read. Making scripts more complex and harder to
read for some dubious efficiency is not a good idea in my opinion.
I respectfully disagree, especially in the example case, in the
following counts:
1. In the example case, we have four pipes (five concurrent
processes), and here we have only one, which I think settles the
performance gain in the non-dubious zone.
2. In the example case, one regexp in the sed command-line explains
quite clearly what you want to extract from the output of
print-defaults, which I think settles the case for the making
scripts more complex and harder to read. I was still in doubt of
what the script extracted from the output of print-defaults until I
saw the regexp.
If I was the DD in charge, I would apply the patch.
--
HTH,
Massa
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: More pbuilder use!
** Joe Smith :: Actually perhaps software should be built outside of clean chroots. Why? Because if there is a possibility that a dirty chroot will cause the package to fail, there is a bug in some peice of software. It could prevent a user from recompiling on his own system, which thusly defeats the point of having the source in the first place. If a package Fails To Build From Source on a end-user system it is an RC bug. By bug definitions i would say a minimum of 'serious', but 'critical' would be better. Why? Simple: If users can make the changes they want, than Debian is NOT free. If it is not free, it has failed. I vehemently disagree. I think exactly the opposite: debbuild and/or dpkg-buildpackage should *always* build a package inside a clean and minimal chroot jail. This way, (1) every package will predictably build from (unchanged) source and (2) every variation that the user *wants* in his package becomes documented in the debian/* files. -- HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: More pbuilder use!
** Bastian Blank :: You have a linux kernel ready, which allows chroot as normal user? Please share it with us. It's called QEMU :-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: Bug#322534: ITP: mpfi -- multiple precision floating-point in terval computation
* Package name: mpfi Version : 1.3.3 Upstream Authors: Nathalie Revol, Fabrice Rouillier (email ommited) * URL : http://perso.ens-lyon.fr/nathalie.revol/software.html * License : LGPL 2.1 or later Description : multiple precision floating-point interval computation The basic principle of interval arithmetic consists in enclosing every number by an interval containing it and being representable by machine numbers: for instance it can be stored as its lower and upper endpoints and these bounds are machine numbers, or as a centre and a radius which are machine numbers. . The arithmetic operations are extended for interval operands in such a way that the exact result of the operation belongs to the computed interval. . The purpose of an arbitrary precision interval arithmetic is on the one hand to get guaranteed results, thanks to interval computation, and on the other hand to obtain accurate results, thanks to multiple precision arithmetic. The MPFI library is built upon MPFR in order to benefit from the correct roundings provided by MPFR. Further advantages of using MPFR are its portability and compliance with the IEEE 754 standard for floating-point arithmetic. Yeah, but what does it *DO*? If it is a library, it oughta be called libmpfi ... and it should be stated. If it is an utility program, the what is arbitrary precision foo is secondary WRT what the program actually does. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: status of jackd? (bug #318098)
I would _NEVER_ recommend someone install Debian Unstable as a
desktop... Testing, yes, Stable even more so.
In my experience, sid breaks less than testing when used as a desktop.
OTOH, I avoid doing apt{-get,itude} upgrade... I generally enter the
interactive aptitude screen, press U, and upgrade only what does not
break... (and I usually regret when I /do/ apt-get upgrade)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bruce Perens hosts party at OSCON Wednesday night
** Andreas Barth :: * Thomas Bushnell BSG ([EMAIL PROTECTED]) [050804 18:48]: Andreas Barth [EMAIL PROTECTED] writes: * Miles Bader ([EMAIL PROTECTED]) [050804 13:54]: Andreas Barth [EMAIL PROTECTED] writes: Which is wholy irrelevant, because Debian's mailing list policy prohibits UBE, not UCE. See: In that case, the description needs to be fixed. Why? Because the intent is obviously to forbid any sort of spam. Well, while the message was certainly UCE, that doesn't mean I thought it was inappropriate. Perhaps the policy is just fine as it is, allowing Debian developers to post suitably targeted messages. I think we can leave that call to the listmasters (at least, I'll do that). IMHO this is a profound disrespect for the great work done in Debian by Bruce. Furthermore, it's just stupid. And to boot, an e-mail calling for curriculae for a recruiting party is on-topic to a DEVELOPERS list, and not Unsolicited by those of us (like myself) that could use a new, better, job and for those of us that could use ANY job at all. Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: Bug#317892: ITP: bum -- tool to manage boot scripts
On Tue, 12 Jul 2005 11:15:42 +0200, Federico Di Gregorio wrote: Boot-Up Manager is a graphical tool to allow easy configuration of init services in user and system runlevels, as far as changing Start/Stop services priority. Consulting the documentation... 1. Activate a de-activated script. BUM will create a standard S20scriptname symlink in directories related to runlevel 2,3,4 and 5 and will remove any Kxxscriptname symlink in the same directories. Further it creates K20scriptname in runlevel 0,1 and 6 directories. It also checks that the script executable and, if needed, will change it so that it is. 2. Deactivate an activated script. BUM will remove any Sxxscriptname symlink. Very nice program, but the behavior described here is incorrect. In order to deactivate the service, bum should install a Kxxscriptname symlink. Testing confirms that bum fails to do this. Without a K symlink in the directory for the current runlevel, when the service's package is upgraded, the service will be started in the postinst even though it is configured to be deactivated. This issue has been discussed before and I believe that there is a good consensus about it now. Bum's current behavior leaves deactivated services in a floating state and Debian does not at present correctly support services left in the floating state. (See #243159.) You will need to choose an appropriate sequence number for the K symlink. I suggest: If there is a K symlink in another directory then use its sequence number; otherwise use an old K sequence number stored in database; otherwise use 100 minus the S sequence number. You may want to look at the source code of sysv-rc-conf too. Among the runlevel editors currently in Debian it sucks the least. I am a fan of vi + file-rc myself, but... anyway, the packager should conflict this package with file-rc or depend on sysv-rc, whatever is better... HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dummy packages and Replaces: field
** Eric Cooper :: On Fri, Jun 24, 2005 at 09:52:34AM -0300, Margarita Manterola wrote: So, if we had a new header to indicate that this is the drop-in replacement of the old program, it could work, right? [...] Which should this new header be? Substitutes:, Supersedes:, Takes-Over:, Drop-In Replaces:, Follows: ? Since there should be a unique replacement that old and new package maintainer(s) agree on, I think the old package (the one being replaced) should have the header. (Perhaps Replaced-By: ?) I disagree. This is not economic in terms of # of uploads... forces you to give a new (last) upload for the old package, which would be even larger than the dummy package upload. -- HTH Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Ongoing Firefox (and Thunderbird) Trademark problems
** Anthony DeRobertis :: Humberto Massa Guimarães wrote: Well said. IMHO, no. DFSG #8 -- witch is part of the SC, IIRC -- forbids us to have rights that our users don't have. No, it doesn't. It says: The rights attached to the program must not depend on the program's being part of a Debian system. If the program is extracted from Debian and used or distributed without Debian but otherwise within the terms of the program's license, all parties to whom the program is redistributed should have the same rights as those that are granted in conjunction with the Debian system. This is exactly what I was talking about: if you consider their trademark policy (for everybody else) combined with their license for Debian to use their trademark, you do have rights attached to the program (the presence of MF's trademarks, most visibly in the caption of the main window and in the names of both the package and the main executable AFAIK (*)) that depend on the program's being part of Debian. And that's it. The only copies of Firefox that do not infringe on this particular DFSG clause are those which are absolutely clean of MF's trademarks. Very clearly, DFSG 8 states that you can not have a different set of rights in regard to FireFox when it is distributed as part of Debian vs. when it is not distributed as part of Debian. That's all. And this is my problem with the inclusion of MF's trademark usage in our package: the right to include such trademark *is* attached to the program (after all, it's the original name of the program (**)); it's a right that *must* *not* *depend* on the program's being part of a Debian system. One *must* be capable of extracting the program from Debian and use it, or distribute it, without debian, but otherwise within the terms of the program's license -- which obviously (at least IMHO) includes the license to the trademarks originally included in the program. It does /not/ prohibit Debian the organization from having rights that other people don't. It is unreasonable to read it that way, because Debian will *always* have additional rights in some works, for example those which it is author or copyright holder of. You are 100% right. But this is irrelevant, because you ignored the context of my phrase. The relevant (contextualized) meaning of my phrase above is: premise 1 = DFSG #8 classifies as non-free software that has *any* rights attached to it that depends on the software be distributed in Debian. premise 2 = Mozilla Foundation Firefox trademark, which is present to be displayed in the usage of the firefox browser as it comes originally, has a restrictive license that either (a) forbids it to be used by Debian or (b) allows it to be used by Debian and Debian only, according to our acceptance or not of their offer of exclusive trademark licensing. conclusion = non-rebranded Firefox is not Free Software as per the DFSG. This is a fairly simple conclusion, and no historically the DFSG was made thinking about copyrights only argument contradicts what is precisely stated there. Even taking the DFSG #4 concession, what is being asked from the MF is not a rename of the program (in which case the version in Debian could be called firefox-debianized or somesuch), but a complete purge of the trademark from the visible part of the program (including menu items, etc), which goes IMHO clearly beyond the DFSG #4 exception. (*) I don't even know if US trademark law allows them to go that far; I could NOT find in Brazilian trademark law any references to anything as deep as that. Basically, the only references that I found in BR case law were to *advertising* and *misrepresenting* something as being from the wrong origin. Anyway, the situation that we have here is: we are modifying Civics and putting different accessories and tuning the engine. We are not obliged to sell our Civics under any other name (maybe in the interest of full disclosure we should state to the next buyer that the car is modified and tuned, IRT the original Civics, and our Consumer Defense Act even makes us give some warranty on the services we made on the vehicle). The Civic is a Civic and any non-forking, non-backdooring, derivative of Firefox is still Firefox, without any trademark being violated IMHO. IANAL, TINLA, and I am not quite familiarized with the Brazilian Industrial Property Act (which regulates trademarks and patents, and gives some instructions about trade/industrial secrets), as opposed to Brazilian copyright statutes and case law, which I am quite familiar with, having worked in some cases while I was a paralegal in a DA's office, criminally prosecuting alledged copyright infringers. (**) as opposed to other trademarks that also cannot be used in the program. An example: I cannot take a modified firefox and call it The Coca-Cola Browser, as I cannot take modified k3b and re-brand it The Coca-Cola CD Burner. Does this fact make those programs non-free? NO. Because the Coca
Mozilla Foundation Trademarks
What trademarks are you referring to? Already the Debian packages don't use any of the trademarked images and logos? If we don't use any trademarked images, logos, or phrases, what exactly are we talking about here? As I think this is a very nice question, could Eric or any other person identify which Mozilla Foundation trademarks are used in our packages (and where)? -- Thanks, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Ongoing Firefox (and Thunderbird) Trademark problems
Not really, because the DFSG is not supposed to apply to trademarks. This is the center of Wouter's and Marco's argument, IMHO. But I don't see anything in the DFSG restricting it to copyrights or excluding trademarks or patents. So, it is my Humble Opinion that DFSG#8 applies broadly. -- HTH, Respectfully, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Ongoing Firefox (and Thunderbird) Trademark problems
* Thijs :: On Tue, June 14, 2005 08:00, Eric Dorland wrote: Now, the Mozilla Foundation is willing to give us permission to use the marks, but only to Debian specifically. To me, this feels like a violation (at least in spirit) of DFSG #8. However, in #4, an explicit exception is made for program names and version numbers. They are not considered fundamental enough to software to require them to be as absolutely free as source code. So if we accept this exception for software coming in, why can't we accept this same exception for software derived from our distribution? I think you are 100% correct. The right choice IMHO is #3: to strip all trademarks from the mozilla products (automagically(*) if possible) and move on with our lives. (*) meaning that instead of a patch, a script is put under debian/ to strip and change all the trademarks before the build -- so others can benefit from the script, too. We don't want to limit the freedoms of those deriving from our distribution, but we accept that limiting the freedom of some trademarks is acceptable. We accept that we can use the Mozilla trademarks, but we also accept that this might not be applicable to downstreams that make huge modifications. It might be beneficial though to have an agreement with MoFo that allows for downstreams of Debian to also use the name, as long as they only modify the package in ways similar to Debian. If you have a downstream that just copies, or copies-and-fixes-bugs, this would surely be just as acceptable to MoFo, right? No. This is not what free software is about (only modifiying the package in ways similar to Debian). We should do the hard work (strip the trademarks) so the community can benefit from our already-stripped mozillas and do whatever it wants with them. This seems to be more like the Debian Way to me. -- HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Ongoing Firefox (and Thunderbird) Trademark problems
* Julien BLACHE :: Matthew Garrett [EMAIL PROTECTED] wrote: The Debian Way (tm) would be to drop mozilla, firefox and thunderbird from Debian -- there's no reason what works with the FSF can't work with the MoFo. The downside to this approach is that the Mozilla Foundation have no good reason to /care/. They're a group that produces free software, but they're not campaigning for freedom. In any case, we can make their software DFSG-free by removing any references to the trademarks. Dropping it entirely wouldn't really help anyone. It seems to me that what the MoFo really cares about is market share, and producing /free/ software comes after that on their list of priorities. I don't even think the restriction to rebrand their software is *really* compatible with the You may not impose any further restrictions on the recipients GPL#6 clause. Do *every* source file in the mozilla trees belong to the Mozilla Foundation? We drop their products from Debian, they lose market share. We drop their trademarks, and *we* lose market share: eh, wtf, Debian hasn't got firefox? mozilla? thunderbird? sunbird? omgwtf $DISTRO has them! Maybe my market perception is *very*, *very* different from yours, but IMHO the would be quite the opposite. If we drop their products, the market sees: Debian is without the main FOSS internet suite! and says $DISTRO it is then, ie *we* lose market share. If OTOH we drop their trademarks, our (prospective) users won't even notice, because: (1) if they install or use a live-cd, they will see the browser icon and Iceweasel Web Browser caption, and won't notice, and (2) if they read about Debian before they install/use a live-cd, they will stumble somewhere in the info Debian uses a rebranded version of Firefox called Iceweasel to protect its users (that may want to modify and redistribute the software) from any trademark liability. Their trademark policy is something that should not exist in a free software context. They don't care about free software. They don't care about distributors/vendors. I agree, to a point. They have reason to protect their assets from evil versions of mozilla, but their current policy is too hard. -- HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Ongoing Firefox (and Thunderbird) Trademark problems
* Marco :: On Jun 14, Julien BLACHE [EMAIL PROTECTED] wrote: We drop their products from Debian, they lose market share. We drop Really? Do you actually believe that debian users would switch to Konqueror just because we stopped distributing Firefox in Debian? Agreed. Their trademark policy is something that should not exist in a free software context. Why not? Trademarks are not software, and the mozilla trademark policy is not depriving anybody of freedoms about their code. I don't think I agree with that; it *does* restrict the creation of derivative works in a way that would be most reasonable. (It would be unreasonable to expect that you could patch Firefox to present itself as Microsoft (R) Internet Explorer (tm), as opposed to Mozilla (R) Firefox (tm)) They don't care about free software. They don't care about distributors/vendors. This looks like a bold statement, and should be argumented a bit more if you want people to believe you. -- HTH, Always, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Ongoing Firefox (and Thunderbird) Trademark problems
* Towns :: Eric Dorland wrote: Now, the Mozilla Foundation is willing to give us permission to use the marks, but only to Debian specifically. To me, this feels like a violation (at least in spirit) of DFSG #8. Our priorities are our users and free software Does having the package actually be called firefox or thunderbird make life easier and better for users? I think so. I don't think so. Does the opposite make it worse? I think so. IMHO it makes no difference at all. The normal, regular, I-dont-read-debian-mailing-lists folk install the Gnome Desktop or the KDE Desktop tasks, see the Web Browser icon, double-click it and voila. As long as it works (and as long as they can install the Macromedia plugins), they don't care. The rest of the world knows Debian renamed Firefox as Iceweasel to escape Mozilla Foundation's arcane trademark license. Does calling it firefox or thunderbird hurt free software? At first, no. But it *does* hurt our users. Why? Because they are confident that getting something from the Debian mirror, modifying it and re-distributing under the same terms is allowed. And they can be burned after some time. And they *will* blame it on Debian. Someone told me there was a maxima if you get a new client, you got *one* new client, if you lose an old client you lost eleven clients (old and prospective)... It would hurt Debian, and as I think Debian is one *big* power in favor of Free Sotware, it hurts Free Software, too. It doesn't hurt us -- we're already doing it, it doesn't hurt upstream -- they're happy for us to do it, it doesn't hurt our They are happy for Debian to do it, but they are *not* happy enough to allow Debian users to do it too. users as above. Does it hurt Debian derivatives? Depends on the permission -- it seems hard to give Debian permission but not give random people permission to redistribute Debian's deb, which is all most distributors do. No, a lot of derivatives will make additional changes in the .deb and not just pass it along. Does changing the name hurt free software? It hurts us, by taking away time from other things, it hurts upstream by Agreed. decreasing their name recognition and providing a bunch of FAQs of the form what's wrong with firefox that Debian doesn't distribute it?. Depending on how much time it takes us to do it right, it Agreed, but this is *their* problem and not ours. might hurt our derivatives even more, by introducing new RC bugs and destabilising the release, and providing a base system that users are less happy with (Why doesn't it come with firefox?). I don't think this question will *ever* happen. YMMV, of course. Yeah. -- HTH, Always, Respectfully, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Ongoing Firefox (and Thunderbird) Trademark problems
* Julien BLACHE :: Humberto Massa Guimarães [EMAIL PROTECTED] wrote: We drop their products from Debian, they lose market share. We drop their trademarks, and *we* lose market share: eh, wtf, Debian hasn't got firefox? mozilla? thunderbird? sunbird? omgwtf $DISTRO has them! Maybe my market perception is *very*, *very* different from yours, but IMHO the would be quite the opposite. Not necessarily. We *will* have to agree on disagreeing, then. If we drop their products, the market sees: Debian is without the main FOSS internet suite! and says $DISTRO it is then, ie *we* lose market share. If we drop their products, we issue a PR explaining why we dropped them. Just like we're about to do with the GFDL'ed docs. And *then* Debian will be left without a mozilla-compatible web browser, not without Mozilla itself. If OTOH we drop their trademarks, our (prospective) users won't even notice, because: (1) if they install or use a live-cd, they will see the browser icon and Iceweasel Web Browser caption, and won't notice, and The icon won't be the firefox or mozilla icon. The name won't be firefox or mozilla. The user will notice. The firefox and the mozilla icons (and and even their brands) are not so-well-known as you are assuming IMHO. My experience (6 years) as a final-user-supporter: they see the thing that looks like a globe, a planet, or has web browser or internet as its caption, web browser interface (forward, back, url, topping the browser panel) appears, they are happy. (2) if they read about Debian before they install/use a live-cd, they will stumble somewhere in the info Debian uses a rebranded version of Firefox called Iceweasel to protect its users (that may want to modify and redistribute the software) from any trademark liability. Don't count on it too much :) In the drop case, they would probably start looking for a firefox/mozilla package for Debian and would eventually end up on a d.o page explaining why the packages were dropped, thanks to the Google Magic (tm). QED. In the rebrand case, they will look for said package and Google will take them to a page saying Firefox is called Iceweasel under debian to protect you from trademark lawsuits, they think oh, good, this Debian fellow is a nice guy helping protect me. -- HTH, Respectfully, Massa
Re: Ongoing Firefox (and Thunderbird) Trademark problems
* Cesar Martinez Izquierdo :: El Martes 14 Junio 2005 16:50, Marco d'Itri escribió: They don't care about free software. They don't care about distributors/vendors. This looks like a bold statement, and should be argumented a bit more if you want people to believe you. Moreover, it doesn't matter whether they care about free software or not. The *fact* is that they produce free software. Debian is You couldn't be more right. But is it free software after all? not here to be a moral judge of upstreams, the aim is to produce a distribution. Firefox is free software, and DFSG-compliant: The license may require derived works to carry a different name or version number from the original software. (Even if it is a compromise). But is non-rebranded Firefox *really* distributable by us under GPL#6, no further restrictions? It seems to me that if our users can't customize and compile and distribute Firefox under the terms of the GPL, we are passing along another restriction over those in the GPL. Obviously, I'm assuming that we are redistributing Firefox under the terms of the GPL because IIRC the MPL is not DFSG-free. I think everything is clear enough. And I think it is quite reasonable that an upstream author asks for a name change for a modified version. Even for security fixes. There is lots of modified versions of programs out there and the upstreams authors are always suffering bug reports that doesn't concern the original version. So, in this paragraph you are basically stating that we *should* rename firefox to save them from such burden. And if you finally plan to rename Firefox, you should start renaming PHP, unless I missed something... If the same restriction applies to PHP, I'm all for it. -- HTH, Massa
Re: splitting package on arch-dependant and arch-independant part s
* Bartosz Fenski aka fEnIo :: On Tue, Jun 14, 2005 at 09:39:09PM +0600, Sergey Fedoseev wrote: There's only one rule. Architecture dependent files go to binary package, and architecture independent to data package. I consider some common procedures should exist anyway. For example ones move manpage to binary package and others move it to data package. Who is right? Who moved binary (_architecture_ dependent binary) to -data package? Basically you don't have to split package if there are Since when are manpages architecture dependent binaries? no architecture dependent data in it (or such data is very small). Maybe you should tell us what program are you going to package. That would be a good idea. -- HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Better brand recognition for new Debian (etch)
* Wiktor Wandachowicz :: Hello all Debian folks! First of all I would like to congratulate all Debian developers and maintainers for releasing sarge. Good job! (and a big relief for all of you, I guess) Having a Debian installed on 10 Sun Blade boxes and helping a bit on debian-boot with debian-installer I can safely say that I am also concerned with the future of Debian. Lately I have spotted an interesting entry in Ian Murdock's Weblog (http://ianmurdock.com/?p=239), where he points out that in order to get a better user recognition and vendor support some _naming_ changes may be required. After reading the post I can say that indeed there are some ideas worth to be at least considered. What I am referring to is that not only stable / testing / sid repositories are enough. Maybe just after a little bit of tweaking Debian could get some more profiles called server / desktop also? What this means for developers, is to link (or understand) such profiles as server == stable, and desktop == testing. On the other hand, maybe some more profiles would be required, such as: stable-server, stable-desktop, testing-server and testing-desktop? IMHO, there is a series of (serious) problems in such a plan, such as: * testing and unstable are not installable by non-tech-folk, all the time, really. There can be times where they are, but there are some times they are not. They break. * we should not really multiply (space, time, bandwidth) needed for our mirrors; right now, some archs are endangered because of such hefty requirements. * we *do* have, after all, tasks to install desktops and (some, specialized?) servers, without having to resort to creating another 30G of repositories. * finally, the infrastructure necessary to do what you ask for is really a job better done by specialized derived distros (such as LinEx, Ubuntu, even Ian's own Progeny) -- HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: splitting package on arch-dependant and arch-independant part s
Sergey Fedoseev [EMAIL PROTECTED] no architecture dependent data in it (or such data is very small). Maybe you should tell us what program are you going to package. That would be a good idea. I'm not going to package program...yet. There are many packages already splitted. And I believe binary part of most of them can be reduced (and it can be reduced not only by moving manpages). And to not file a bug to every package I want this to be discussed there. For example ones move manpage to binary package and others move it to data package. Who is right? So who is right? The praxis is, IIRC, only separate -bin and -data if there is a good reason. For instance, if -data is *very* big AND is a good portion of the original package AND is arch-indep, then you have good reason to split the package. I think the policy does NOT allow for the manpages to go in a separate package from the binary, because the general rule is that if you can execute something, you can access the manpage. -- HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Ongoing Firefox (and Thunderbird) Trademark problems
* Matthew Garrett :: Humberto Massa Guimarães [EMAIL PROTECTED] wrote: Obviously, I'm assuming that we are redistributing Firefox under the terms of the GPL because IIRC the MPL is not DFSG-free. This is, uh, debated. Is it? I seemed to recall that the MPL contained a choice-of-venue clause, and that -legal deemed choice-of-venue as non-free, because imposes a burden on the licensee in case of litigation. -- Massa
Re: Ongoing Firefox (and Thunderbird) Trademark problems
** Cesar Martinez Izquierdo :: No, I think we should NOT rename Firefox to save our *direct* users from such burden. A lot of people would get greatly confused with a different name for Firefox, even if you don't think so. *Indirect* users such as derived distributions should check the licenses and other trademark or patent issues before start distributing anything. It's their task to check it. We can help them if we create Debian packages which are easy to rename, but we shouldn't confuse the rest of the users just to make this task easier to derived distributions. The problem I see with your two paragraphs above is that there is not, and there should not be, real difference between direct and indirect users of free software. Free software is supposed to be distributed freely for anyone without discrimination of field of endeavour, and IMHO this includes making a derived distro. And, to top it, Our priorities are Free Software and our users, not ... and our *direct* users. And if you finally plan to rename Firefox, you should start renaming PHP, unless I missed something... If the same restriction applies to PHP, I'm all for it. Oh yes, it would be funny. I've programmed a webpage in PZP but it doesn't render correctly in Littlefox. When should we start the project Debian-rest of the world branding reference? Whenever upstream asks us to do it or permits our downstreams not to do it. At least IMHO. -- HTH, most Respectfully, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
Maybe I can shed some light on this ** Manoj Srivastava :: That common is common enough? Not really. There is nothing to indicate that how you fashioned your run levels would make sense for, say, me. People whoi really want tailored run-levels often have very definite ideas about how these run-levels would be tailored; it is unlikely that a predefined solution designed by committee in Debian would suit their needs, and they would have to roll their own, anyway, and a predefined solution would just get in their way. _Why_ did you not create you own run level schema, BTW, if you have indeed needed them so often? (I haven't felt that itch yet, or I would have; creating differentiated run levels is not exactly rocket science). I think this all evades the real questions, that are: (1) LSB -- which Debian's policy vows to follow -- mandates the default differentiated runlevels. Why are not doing it? (2) The differentiated runlevels by default *do* have practical, and in many cases important, utilizations (the X-freezing is a good example). Why not? (3) Substituting diferentiated runlevels by the old, 3-runlevel scheme is relatively easy, as it is to create otherwise customized runlevels, independently of where one comes from. So, why not? (4) It *does* generate an unnecessary difference between Debian and *all* *other* distros, with no reasonable motive at all. IE, IMHO, Debian should adopt the 6-runlevel scheme dictated by the LSB (0=off, 1=single, 2=multi,no-net, 3=multi, 4=5=multi+DM, 6=reboot) because (1) it's praxis to the other distros, (2) it's in the LSB and (3) there is no good reason not to. -- HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: Ongoing Firefox (and Thunderbird) Trademark problems
** Sebastian Ley :: Am Dienstag, 14. Juni 2005 16:20 schrieb Humberto Massa Guimarães: Does calling it firefox or thunderbird hurt free software? At first, no. But it *does* hurt our users. Why? Because they are confident that getting something from the Debian mirror, modifying it and re-distributing under the same terms is allowed. And they can be burned after some time. And they *will* blame it on Debian. Modifying and redistributing stuff from the Debian archive does not release you from checking redistribution licenses. Just make sure /usr/share/doc/$MOZILLA-PRODUCT/copyright clarifies the trademark issue, and let's justify the inclusion with §4 of the DFSG. As I said before, IMHO our priorities are Free Software and our users and not ... and our *direct* users... -- HTH, Massa
Re: splitting package on arch-dependant and arch-independant part s
I didn't say anything about manpages, did I? Your phrase was directly after Sergey's question of where should he put the manpages. Apropos, Sergey, your argument about manpages going in -data is sound, provided -bin REALLY Depends: on -data. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Better brand recognition for new Debian (etch)
** Otavio Salvador :: humberto == Humberto Massa Guimaraes [EMAIL PROTECTED] writes: humberto IMHO, there is a series of (serious) problems in such a humberto plan, such as: humberto * testing and unstable are not installable by humberto non-tech-folk, all the time, really. There can be times humberto where they are, but there are some times they are humberto not. They break. unstable really break sometimes but testing exist to be a always working version. This is why sometimes things have a so long delay to enters testing while it has something broken or with RC issues. Not really. I explain: when a bug goes from unstable to testing (and they do) and renders stuff uninstallable on testing, there is a longer delay where things *will* be broken there, until the corrected version goes there from unstable. humberto * we should not really multiply (space, time, bandwidth) humberto needed for our mirrors; right now, some archs are humberto endangered because of such hefty requirements. we currently have support for partial mirroring using a lot of packaged tools like debmirror, rsync, mirror and debpartial-mirror. humberto * we *do* have, after all, tasks to install desktops humberto and (some, specialized?) servers, without having to humberto resort to creating another 30G of repositories. I didn't understand what you mean here. Please explain. The problem with Wiktor's proposal is not only mirroring, but storing, building, and transferring (HD, CPU, bandwidth) *separately* what he calls desktop-testing, desktop-stable, etc etc. humberto * finally, the infrastructure necessary to do what you humberto ask for is really a job better done by specialized humberto derived distros (such as LinEx, Ubuntu, even Ian's own humberto Progeny) Well yes and no. If we had a place to move the improvements we need on derivative distributions could be better since we have the possibility to merge more code and more effort and start to have more cooperation. Debian have all needed structure done. DAK support it very well and what is really need is only decide what is the rules for packages migrate to that releases from unstable. No, after you decide that packages can migrate there is a lot of things you should provide: more storage for the now-frozen package, CPU to rebuild that specific version with the specific dependencies in a point in time, bandwidth to transfer it back and forth and to the mirrors. All this without giving anything more than desktop-task. I'm not sure if this is good or bad for Debian but is possible to have it working without so much effort. We will have to agree in disagreeing. -- HTH, Respectfully, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Ongoing Firefox (and Thunderbird) Trademark problems
Yes, it's not nice, it's crap, but it's still entirely possible within the (pseudo-)legal framewark Debian gives itself. Isn't Debian point to be less crap? Yeah, I even agree it's possible within Debian's laws, but should it be done? I don't think so. -- HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Ongoing Firefox (and Thunderbird) Trademark problems
Yes. Copyright and trademark are completely orthogonal. Sorry John, but this is BS. The text of the GPL#6 says: You may not impose *any* further restrictions on the recipients' exercise of the rights granted herein. This *does* include trademark restrictions. But this is a moot point for the time being, because I'm told that Debian distributes mozilla under the MPL (and I don't have the MPL text in hand), even if the MPL contains a choice-of-venue clause (and *I*, personally, consider a choice-of-venue clause non-free, and I seemed to recall that such consensus was reached in d-l, but I was told that I am wrong about this.). So, at least until I have more info, I withdraw from this line of reasoning. -- Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: And now for something completely different... etch!
** Manoj Srivastava :: (4) It *does* generate an unnecessary difference between Debian and *all* *other* distros, with no reasonable motive at all. We differ on what we considered reasonable. But not *one* reasonable motive for differing was cited in this whole thread. So, right, we differ on what we consider reasonable, but why is differing in this point considered reasonable? IE, IMHO, Debian should adopt the 6-runlevel scheme dictated by the LSB (0=off, 1=single, 2=multi,no-net, 3=multi, 4=5=multi+DM, 6=reboot) because (1) it's praxis to the other distros, (2) it's in the LSB and (3) there is no good reason not to. Shrug. Talk to the people whoi do the work, then, or those responsible for these packages. I assumed they would be on-list... -- Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Ongoing Firefox (and Thunderbird) Trademark problems
Our users have permission to modify it and further redistribute it *as long as they change the name*. That's a limitation we're willing to accept for ourselves - why should it not be free enough for our users? If we are willing to accept it for ourselves, then we should accept it for ourselves and do the renaming, IMHO. The problem is quite the opposite: if we are *not* willing to accept it for ourselves, why should we push the limitation to our users? -- Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Ongoing Firefox (and Thunderbird) Trademark problems
** Matthew Garrett :: Humberto Massa Guimarães [EMAIL PROTECTED] wrote: Is it? I seemed to recall that the MPL contained a choice-of-venue clause, and that -legal deemed choice-of-venue as non-free, because imposes a burden on the licensee in case of litigation. -legal decided is not a terribly meaningful phrase. Lack of You are really putting words in my mouth (hand?). I have written -legal deemed, which I think means -legal seemed to reach the consensus that... choice of venue imposes a burden on the licensor in case of litigation - I see no reason why one is obviously free and the other non-free. Imagine the following: by your reasoning, there is *no* free software, because writing the software to start with is a burden on the licensor. -- HTH, Massa
Re: Ongoing Firefox (and Thunderbird) Trademark problems
With this reasoning, firefox must go to non-free -- because everything in main is guaranteed to be freely distributable by anyone, anywhere. With modifications, inclusive. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: C++ ABI change -- freezing unstable for new C++ library packa ges
I maintain a package (hdf5) which contains a pure C library and a C++ interface. However, I'm pretty sure the C++ library isn't used by packages depending on it. In this case, is it necessary for the library to be renamed? What about third-party software that is not part of Debian and depends on your C++ interface to work? Is it fair game to break it? Even if the ISV neatly packaged it for Debian? -- Respectfully, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Ongoing Firefox (and Thunderbird) Trademark problems
Let's say we call it mozilla-firefox (assuming we are allowed to in the first place) and downstream (making some modifications) is not allowed to call it mozilla-firefox. If we call it debian-firefox then downstream is still not allowed (under the same conditions) to call it mozilla-firefox. The difference is not You seem to be wrong about the Mozilla Foundation's trademark policy. They say no one (ok, they excepted Debian especially, but *I*, personally, do not think this flies because of DFSG#8) can use the words Mozilla or Firefox (or Thunderbird etc) in their browser. So, if we rename the browser, we must call it (for instance) IceWeasel, and yes, any person downstream from us can call it anything but Firefox or Mozilla or Mozilla Firefox. that huge to me. (but naming the package just firefox seems to me like a good idea in the first place) I think it's named mozilla-firefox nowadays because of the firebird snafu (it had to be named mozilla-firebird to differentiate it from the firebird database manager). -- HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Structured (XML-like) input/output for shell apps?
* Gabor :: Hi, On Sat, Jun 11, 2005 at 07:40:10PM +0200, Olaf van der Spek wrote: Many shell apps/scripts output data in tables, for example ls -l, ps aux, top, netstat, etc. At the moment, most of these apps use fixed-width columns with a variable-width last-column. This results in (unnecessary) truncation, for example: Debian- 11918 0.0 0.1 4428 1464 ?Ss Jun05 0:00 /usr/sbin/exim4 -bd -q30m tcp 0 0 TC218-187-80-45.2:35589 bananensaft.inline.:www ESTABLISHEDproxy 153239 Also, because the output isn't structured (in way easily readable by machines), using the data in a script isn't (very) easy and is likely to break due to strict dependency on the syntax. Are there already any plans to solve these issues? Yes. The commands you mention were designed for _human_ consumption. Do not use them in scripts without good reasons. There are a lot of commands to get well-formatted output without truncation. For example, ls has a -n option for exactly this reason; stat(1) can be used instead of ls -l to avoid clipping; ps has a _lot_ of formatting options itself and all the data can be found under /proc in an easily parseable format etc. You just have to select the right tool for the job (that also includes using more powerful scripting languages if the task is complicated). I was thinking, using structured output (and maybe input) in an XML-like way would solve these and allow neat post-processing. XML is just _terrible_ for human input/output. What Olaf *really* seems to want is a resource like the new (vapor?) Monad shell from MS. Which can be a good thing, if done right, but is generally a waste of CPU and memory, if you ask me. As you said, there is not a lot of difference between ls *.ab | fields name, size | table in Monad and printf %-50.50s %d\n, $_, -s $_ for *.ab in Perl. The domain is necessary anyway, ie, you have to know Monad to understand the first, you have to know perl to grok the second. * Olaf :: XML is just _terrible_ for human input/output. It's not meant for human IO, it's meant for IO to the next chain. The final chain would then process it to normal text output. Even so; imagine a long (6 links) chain of things. Each of them would have to unserialize the input and serialize the output (XML no less! big overhead!), besides trying to know if its input is xml or not, if its output should be xml or not. In the Monad case, it *seems* that what is passed around are (DCOM?) objects, lowering the overhead a litlle bit, but there is a lot of overhead nonetheless. And it's still easier to use a tool (like Perl, Python or Ruby for instance) that can do the job you want (look my example above) IOW, I don't think Monad is such a hot idea. -- HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Structured (XML-like) input/output for shell apps?
* Olaf :: On 6/13/05, Humberto Massa Guimarães [EMAIL PROTECTED] wrote: snikt printf %-50.50s %d\n, $_, -s $_ for *.ab in Perl. The domain is necessary anyway, ie, you have to know Monad to understand the first, you have to know perl to grok the second. Except that in Perl you have hard-coded the size of the name field and hard-coded sizes are almost never optimal (either too large or too small in most of the cases). Not necessarily. Just as you have tableout as an external command (built-in or not) in Monad, you can have a Perl module to print things in a tabular manner, expanding the column sizes as needed (based on HTML::Format::Table or somesuch) XML is just _terrible_ for human input/output. It's not meant for human IO, it's meant for IO to the next chain. The final chain would then process it to normal text output. Even so; imagine a long (6 links) chain of things. Each of them would have to unserialize the input and serialize the output (XML no less! big overhead!), besides trying to know if its input is xml or Note that I said structured (XML-like) IO. I didn't say XML. I'm sure an implementation without big overhead is possible. Yes, and I withdraw :-) what I said about XML. But *any* serialization / deserialization necessary for this scheme to work would add (unnecessary) overhead. This and the fact that you would create incompatibilities with other Unices ... Those are indications that this won't be done. Obviously, some Monad clone can be done with its entire toolchain (monad-ls, monad-tableout) ... -- HTH, Massa
Re: Structured (XML-like) input/output for shell apps?
* Olaf :: On 6/13/05, Humberto Massa Guimarães [EMAIL PROTECTED] wrote: Yes, and I withdraw :-) what I said about XML. But *any* serialization / deserialization necessary for this scheme to work would add (unnecessary) overhead. This and the fact that you would Well, if you can do it with Perl without overhead, you can of course also do it without Perl without overhead. In that case the 'structured' support would be included Not exactly. Don't get me wrong, object component technology is a great thing, standing just next to sliced bread in the list of great things, but (just like sliced bread) it does not cure cancer. When I do my example inside of Perl, I am supposing whatever objects or handles the Perl interpreter has stay inside the interpreter's process; when you do a pipe like monad-ls *.ab | monad-fields name, size | monad-tableout you are implying the existence of 3 processes, two of them making serialization of their (internal) objects for output, two or them making de-serialization of their inputs to (internal) objects, all of them analyzing (or receiving a hint from the shell, that had to analyze for them all) to see if their input came from an object pipe and if their output goes to an object pipe. At least two of those process have to read all of their input to memory before spitting any output (ls -- because it sorts the filenames -- and tableout -- because it dimensions the columns beautifully). This is a *lot* of overhead -- normal overhead, contention overhead (ls blocks the other two processes until it starts spitting its output), and synch overhead (any object read in the input must be perfectly synchronized to be a valid IPC object), and it's a lot of overhead independently of the IPC mechanism utilized. In the case of my Perl example, verbosely made to use a hypotetical text::table: use Text::Table; $t=new Text::Table; $t-addline($_, -s $_) for *.ab; print $t-as_text You still have some contention inherent to the operation you want to convey (sorting *.ab, determining optimal column width), but none of the (really expensive) freeze-serialize/deserialize-thaw cycles the monad version has, nor the (expensive, complex, and even with security implications(*)) input-format, input-synch, etc issues. (*) security implications because when you make a pipe component like monad-fields that can receive an arbitrary object as its input, you have to have in mind that said object can have security bugs in its methods, either on purpose or not. Imagine a malicious-ls that spits objects whose get-name method (property getter) copies the .ssh directory of the current user to another, publically-readable locale. This can be installed in someplace in the net and you can convince people that your ls is better and 0wn the poor bastards... This *will* certainly happen in an environment like this because, well, there will be a point in time where it will be too much trouble to check all those distributed objects... Not unlike a lot of websites install spyware via ActiveX in the poor IE-using folk. -- HTH, Massa
Re: Structured (XML-like) input/output for shell apps?
On 6/13/05, Humberto Massa Guimarães [EMAIL PROTECTED] wrote: Not necessarily. Just as you have tableout as an external command (built-in or not) in Monad, you can have a Perl module to print things in a tabular manner, expanding the column sizes as needed (based on HTML::Format::Table or somesuch) But I doubt that'd be as simple as things are now. As I said in my other answer, things will *never* be simpler as they are right now. Any other stuff will tend to complicate instead of simplify things. Yes, and I withdraw :-) what I said about XML. But *any* serialization / deserialization necessary for this scheme to work would add (unnecessary) overhead. This and the fact that you would create incompatibilities with other Unices ... Those are indications that this won't be done. What kind of incompatibilities? There are a lot of scripts today in production use that use the output of ls, ps, in a text-way. If you want to put another command, or another switch to ls, ok, but the fact that you *can* do it does not mean that you *should* do it. (see below) Obviously, some Monad clone can be done with its entire toolchain (monad-ls, monad-tableout) ... Why not ls --monad? If you want to fork and maintain forever util-linux, I have nothing to say about that. But I *will* leave you (I'm going home from work now) with Occam's razor: Entia non sunt multiplicanda praeter necessitem. (Things shouldn't be multiplied without necessity) IOW: if it's not broken, don't fix it. -- HTH, Massa
Re: And now for something completely different... etch!
Matt wrote: On Thu, Jun 09, 2005 at 01:13:16AM +0200, Javier Fernández-Sanguino Peña wrote: to find their own (sometimes flawed) solution to a very common problem. Years using Linux: 10. Idem here Times I've absolutely needed an X-less boot when an XDM was installed: 0. Mine: 30 or more. How common was that problem you were trying to solve, again? It depends on how great is the hardware you have access to. In Brasil, we have a lot of crappy SiS mb-integrated video, and stuff like it, that would easily freeze the machine if X configuration is not *milimetrically* well-adjusted. -- HTH, Massa
RES: /usr/lib vs /usr/libexec
Josselin: Le jeudi 12 mai 2005 à 18:32 -0700, Thomas Bushnell BSG a écrit : You said it: there is a cache. After the first access, the directory will be in the cache. Making all of this a purely imaginary problem. The whole directory is in the cache? I don't think so. Remember, that in between each lookup, a library gets searched, which probably flushes the entire cache. Currently, on my 256 MB machine, the kernel is using 60 MB for the cache. I think this is enough to include a few directory blocks, especially some as frequently used as /usr/lib. You said it yourself. Even if your 256MB machine were typical (it's not), the less cache memory you use to cache dentries of /usr/lib, the better (more memory for your apps, or to cache other, more useful stuff).
Re: /usr/lib vs /usr/libexec
Thomas Bushnell BSG wrote: Humberto Massa [EMAIL PROTECTED] writes: with the possible exception of FAT and Minix. Q: are they used by a default? A: Last time I installed Debian (15 days ago), it asked me if I wanted my partition ext3, xfs, or reiserfs IIRC; I chose reiserfs, and I am pretty sure finding a file in a directory in reiserfs is O(log n) in the worse case. (Actually, I think that except for HUGE directories [far larger than /usr/lib] it accesses two or three blocks of disk in every case, hence being O(1)). How many directory entries do you think fit in a block? Is this a trick question? see... the average lib*.so.x.y in my disk is 12 characters long, a block has 8192 bytes, with an overhead of two dwords per dentry we have an average 409.6 directory entries in a block. YMMV. ls /usr/lib | wc -l brings me 9000, so it's very different to the disk thrice and twenty times just to give a ENOENT (ten times in the average to give success in load one lib) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr/lib vs /usr/libexec
Thomas Bushnell BSG wrote: Christoph Hellwig [EMAIL PROTECTED] writes: On Tue, May 10, 2005 at 04:40:11PM -0700, Thomas Bushnell BSG wrote: What does the default Debian install do? Debian seems to use ext3 without directory indexing by default. Which is a sane choice as directory indexing on ext3 still seems to be not fully mature. And as mentioned in another thread it's not available on ext2 at all. So that means that, in fact, directory lookups on Debian are O(n), and we are, in fact, subject to problems from huge directories. As I said before, as far as I recall, the Debian installer suggested me only filesystems that have O(1) [O(log n) worst case] directory lookup. I chose reiserfs, but the installer IIRC suggested ext3 and xfs as alternatives. I will probably re-install my laptop this weekend, and then I can give you more accurate info. HTH -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr/lib vs /usr/libexec
Will Newton wrote: On Wednesday 11 May 2005 17:21, Thomas Bushnell BSG wrote: BUt according to Christoph Hellwig, the ext3 which is the default is used without directory indexing, which returns you to O(n). You have yet to present any numbers which show there is a problem here. Can we please discuss real world problems? This is not an imaginary problem, after all, in principle. Let's see, as I wrote before, my installation has *thousands* of files in /usr/lib and, in some filesystems, this can add up to a very large time (and ab-use of dentry cache memory) to link, say, Konqueror (which links to *hundreds* of shared objects). Imagine that, to load Konqui, you have to go 200 times to the disk (ok, cache, but...), each of them reading the 1 entries I have in /usr/lib, some of them twice or three times, to follow the symlinks. This is a real inefficiency. So, if you ask me for MHO, ext3 should be used by default *with* directory indexing. And maybe FHS should be pressed to provide something like /usr/libexec. -- HTH Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr/lib vs /usr/libexec
Peter Samuelson wrote: (...) HOWEVER This is a very silly thing to argue about without benchmarks. Those who care about this - yes, Thomas, I mean you - should get numbers. Here's how: (steps 1-6) You are 100% right and I stand corrected. -- HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPL and linking
Raul Miller wrote: On 5/9/05, Humberto Massa [EMAIL PROTECTED] wrote: You can't re-state something saying a different thing. GPL#0 says that a work based on the Program is a derivative work under copyright law, and then says that is to say, a work containing..., which is NOT a re-statement of a derivative work under copyright law. That's another re-statement of what a work based on the Program means. The GPL just equated the two, before the colon! It states, clearly, that the a work based on the program is a derivative work under copyright law, and then, using a colon and the introductory phrase that is to say, it states that a work based on the program is a work containing My point is that the second statement is not stating the same thing, so it can NOT be a re-statement. It must be something else. Yes and no. The GPL is the authoritative document on whatever it wants to define and whatever it CAN define (the GPL CANNOT define what is a derivative work under copyright law, for instance)... but IF AND ONLY IF it defines it without ambiguity. The GPL is not defining what a derivative work under copyright law means. It's defining what a work based on the Program means. It had equated the two of them in the first part of the phrase. What the GPL actually does is defining a cat this way: '' a cat is the animal on the page 3 of the Domestic Pets Handbook, that is to say, an animal with four legs and whiskers. ''. Does this defines all animals with four legs and whiskers as being cats? Not actually. Cats are outside the scope of copyright law. But cats are not outside the scope of the Domestic Pets Handboook. If you were not trying to win the argument at all costs, you would see that my paragraph in quotes, above, has EXACTLY the same grammatical structure as GPL#0. And the interpretation you are giving to this disposition of the GPL#0 is exactly the same I am giving for cats. You *are* saying that every work that contains the Program or a portion of it is a work based on the Program, as per the GPL. But it's not! Now, every derivative work under copyright law is a work based on the Program... nothing more, nothing less... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr/lib vs /usr/libexec
Thomas Bushnell BSG wrote: Martin Dickopp [EMAIL PROTECTED] writes: Thomas Bushnell BSG [EMAIL PROTECTED] writes: If there is a reason to separate /usr from / (which so many people think there is, though I don't understand why, since it has no semantic significance at all), why separate /lib from /etc? I don't see a semantic difference between /bin and /usr/bin (or /lib and /usr/lib). IMHO, the only reason for /bin and /lib is that some programs and libraries need to be available before is /usr is mounted. That doesn't make sense. If you get rid of the /usr vs / distinction, then there is no before /usr is mounted. Have you considered that for some (eg embedded) applications, the block device containing / does not have enough space to contain everything that is under /usr? And that, as a result, it would have to mount it as a network drive, for instance? That wasn't my argument. My argument is that I don't consider shared libraries and internal executables different kinds of things. They are both binaries loaded and executed by a program. Sure, and documentation and libraries are both files opened by programs. The difference is that libraries are also generic things that are shared by many programs, and searched by the linker, whereas executables are not. In fact, a library is loaded and executed by only two programs (ld and ld.so) in the normal scheme of things. The difference between /usr/lib and /usr/shared is more clear: what is under /usr/lib depends on the arch; what is under /usr/share doess not. So, /usr/lib can be mounted in a network drive, shared by a lot of machines of the same arch in a network. And /usr/shared can be (hmpf)... shared... between all machines in a network, independently of arch. Thomas HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr/lib vs /usr/libexec
Thomas Bushnell BSG wrote: Goswin von Brederlow [EMAIL PROTECTED] writes: That doesn't make sense. If you get rid of the /usr vs / distinction, then there is no before /usr is mounted. But then you have a minimum 1-5GB /. That sucks. Why, exactly? I know people think it's obvious, but the lack of stated reasons worries me. I know the *original* reasons why / needed to be small, but they don't apply anymore. So I'll buy the it's obvious if you can state the original reasons and explain why you think they still apply. If not, then what is the current reason? Thomas What do you think are the original reasons / needed to be small? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr/lib vs /usr/libexec
Thomas Bushnell BSG wrote: Andrew Suffield [EMAIL PROTECTED] writes: We do not have that bug, so it's not important to us. Still, nobody has said. What filesystems available on Debian have a better than linear search time for open, and are they used by a default Debian install? These are two questions: Q: What filesystems... ? A: Every one of them with the possible exception of FAT and Minix. Q: are they used by a default? A: Last time I installed Debian (15 days ago), it asked me if I wanted my partition ext3, xfs, or reiserfs IIRC; I chose reiserfs, and I am pretty sure finding a file in a directory in reiserfs is O(log n) in the worse case. (Actually, I think that except for HUGE directories [far larger than /usr/lib] it accesses two or three blocks of disk in every case, hence being O(1)). HTH -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr/lib vs /usr/libexec
Thomas Bushnell BSG wrote: You've missed the point. Split / and /boot, that makes sense if it's necessary. Splitting / and /usr does not make sense. Sure it does. Especially if you want / to be in a Flash disk and /usr to be somewhere else in the network. HTH Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr/lib vs /usr/libexec
Christoph Hellwig wrote: On Tue, May 10, 2005 at 02:03:01PM -0300, Humberto Massa wrote: These are two questions: Q: What filesystems... ? A: Every one of them with the possible exception of FAT and Minix. ext2 doesn't. With dir_index, yes it does. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPL and linking
Raul Miller wrote: On 5/6/05, Humberto Massa [EMAIL PROTECTED] wrote: ??? Let's try again: '' The GPL tries to define work based on the Program in terms of derivative work under copyright law, and then, after this definition and a colon, it tries to explain what is a derivative work under copyright law, but gives a wrong explanation, which would remain wrong even if only USC 17 was considered as a global copyright law. '' See? The GPL says, in its section 0, caput, with [] braces mine: Except what you're calling a paraphrase of the derivative work concept is a restatement of the work based on the Program concept. You can't re-state something saying a different thing. GPL#0 says that a work based on the Program is a derivative work under copyright law, and then says that is to say, a work containing..., which is NOT a re-statement of a derivative work under copyright law. It would be a re-statement if it said: '' a work based on the Program is a derivative work under copyright law, that is to say, in most jurisdictions, any intellectually-novel work that results from a transformation made on the Program, like a translation to another language etc. etc. etc. '' THIS is a re-statement. I say one thing, then I say the SAME thing with other words. Then again, other things you say, such as 'The GPL tries to define' shows that you're not really interested in talking about what the GPL is or what it's saying. The GPL does define work based on the Program. There is no element of try here. The GPL -- not your email -- is the authoritative document about what the GPL does and does not define. Yes and no. The GPL is the authoritative document on whatever it wants to define and whatever it CAN define (the GPL CANNOT define what is a derivative work under copyright law, for instance)... but IF AND ONLY IF it defines it without ambiguity. What the GPL actually does is defining a cat this way: '' a cat is the animal on the page 3 of the Domestic Pets Handbook, that is to say, an animal with four legs and whiskers. ''. Does this defines all animals with four legs and whiskers as being cats? This is not a definition, because of the ambiguity of the terms. When you study the GPL deeply, and start digging on hermeneutics books, you'll see that the that is to say part is only an explanation or example, and NOT part of an authoritative definition. Especially *because* any ambiguity is construed against the offerer, the only possible *legal* reading of the GPL is that a work based on the Program is exactly defined as a derivative work under (your local) copyright law. Finally, I want to say that I am NOT against the GPL. Only I disagree with its interpretation given in the FSF GPL FAQ and I think that, in the courtroom, (I am pretty sure as far as Brazilian courts are involved, really) considering any collective works as works based on the Program would NOT stick. HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPL and linking
Batist Paklons wrote: This however doesn't really change a lot about our discussion about the GPL. It is my belief that the GPL is horribly drafted. One should either choose the simplistic beauty of a BSD style license, or choose a carefully drafted legalese text, such as the IBM Public License. I grew up in a french culture, which chooses for the former, on the belief that it is impossible to predict everything, so it is better to leave out the details and set forth only general principles. The GPL just fails short on both sides. Another concern is that subsequent versions of the GPL cannot improve the language that easily, in spite of the any later version clause. I cannot believe that any jurisdiction would reasonably allow a I offer you this on these conditions, but a third party may change these conditions at will clause. There is simply no consensus on those future conditions. It is effectively a license change, thus a change of contract, with every possible consequence of notice and so on. Batist, I think you are mistaken about the meaning of the any later version copyright license... the terms are precisely '' This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. '' and they mean that said program is dually-triply-etc licensed under the GPLv2 or v3 or v4 or any other upcoming FSF-GPL, at the licensee's discretion. I am a defender of the GPLv2. I am not a defender of the GPLv3 because I don't know its terms yet... :-) I don't know why would anyone license their work under yet-undisclosed terms, but... HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPL and linking
Raul Miller wrote: Actually, it tries to define work based on the Program in terms of derivative work under copyright law, and then incorrectly paraphrases that definition. It's probably worth noting that derivative work and work based on the Program are spelled differently. What's not clear, to me, is whether the word that refers to the d phrase or the w phrase. Careful study sheds no insight into this burning issue. ??? Let's try again: '' The GPL tries to define work based on the Program in terms of derivative work under copyright law, and then, after this definition and a colon, it tries to explain what is a derivative work under copyright law, but gives a wrong explanation, which would remain wrong even if only USC 17 was considered as a global copyright law. '' See? The GPL says, in its section 0, caput, with [] braces mine: ''a work based on the Program means either the Program or any derivative work under copyright law [definition #1]: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language [explanation, #2].'' I don't know if the meaning of paraphrase is the same in English as its Portuguese cognate, so maybe the misuse of this word is the only error in his analysis... [If I read the GPL, I can't find where it paraphrases the d phrase. On the other hand I can't figure out how someone could claim that the GPL incorrectly paraphrases the w phrase.] There has been so much silliness written about this topic ... Agreed. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Woody - Sarge upgrade report
Roberto C. Sanchez wrote: things about his woody-to-sarge transition I have made this transition a lot lately, too, and I would like to offer some insight about the following process: 2. The standard yes, no, diff, shell approach could probably use some tweaking. What I mean is that with so many config files being updated, there should be an option to manually merge now. This can be done in one of a couple of ways. A text editor could be opened with both the current and proposed config loaded (e.g., vim and emacs), or a single file could be presented with the diff'd In my experience, I almost always hit D (show differences), select the configfile name, :!vimdiff configfile(pasted from clipboard) configfile(idem).dpkg-new, do the merging, :diffupdate, :wq, hit D again, repeat if not satisfied, and then hit N (keep mine). In a woody-to-sarge dist-upgrade, this *really* hurts my wrists. What I would like is an option A (automerge) that did a 3-way merge of configfile and configfile.dpkg-new, open an editor in the conflict markers, let you edit the conflicts out, and when you save/exit, showed you the differences between your new configfile and configfile.dpkg-new, and asked again. portions inserted and marked in the complete file (e.g., editors that only support one open file). I think that this can be done by shelling out (with the Z option), but I am never really sure if my changes will stick. The option says shell to examine the situation, or something to that effect. There is no indication that if I change the config, the change will stick. Yeah, I feel unsafe, altough I *know* whatever I save in the configfile will stick. Also, some packages should adopt the policy of including a local snippet. What I mean is, for example, with the dhcpd package, or any package that requires a change to the config immediately after installation. Simply put, a dhcpd config will always need to be modified to tell which net, subnet mask, hostnames, MACs, and so on, it needs to handle. It is annoying when the messages throughout the file change and cause the admin to have to intervene in the process by choosing what to do. Some packages (e.g., horde2) have a config in /etc/pkg-name with a standard pkg-name.conf and then somewhere in the .conf file they source or include a snippet with the local changes. I encourage the maintainers of such packages (dhcpd and ntp, come to mind immediately) to consider this approach. I really agree with this. more stuff HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Urgently need GPL compatible libsnmp5-dev replacement :-(
Andrew Suffield wrote: [This part of the thread belongs on -legal] So, there it goes. On Wed, May 04, 2005 at 11:51:51PM -0500, Peter Samuelson wrote: [Paul TBBle Hampson] This of course assumes the phrase derived work is legalese for code dependancy or something. I'm sure the GPL actually defines what _they_ mean by it... The GPL simply defers to copyright law to define derivative work. (most jurisdictions') copyright law defines derivative work as a work that, being a novel intellectual creation by itself, results in a transformation of another (original) work, the key word being transformation. This is a part of copyright law originally thought for controlling instrument re-arranging of musical works, translations of a work from a language to another, and sequels and prequels re-using characters from a literary/theatrical work. Anyway, this is a very foggy issue, because the GPL uses thoughout the license text the expression work based on the Program (as opposed to the [legally-defined] expression derivative work), which it defines in the following (contradictory) phrase of section 0, caput: ''a work based on the Program means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language.'' Notice that before the colon, it gives one definition; after the colon, it gives another definition (a wrong one, considering that the that is to say introduces an explanatory part of the phrase, and that the explanation differs from the copyright law definition, and that copyright laws vary with jurisdictions, etc). This can be contrasted with the infamous mere aggregation clause, section 2, paragraph 3: ''In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License.'', and with the other occurences of the (legally-defined) expression derivative work in the GPL, after section 0: The first one in section 2, paragraph 2: ''the intent [of this section of the GPL, section 2] is to exercise the right to control the distribution of derivative or collective works based on the Program'' [braces mine]; The second one in section 5: ''You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivative works.''; this one, combined with the mere aggregation clause, can be construed as an authorization to distribute collective works containing the GPL'd work; And the last one in section 10: ''Our decision [on licensing any FSF-owned software under different terms] will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally'' [braces mine]; again, without mentioning the collective works, this can be combined with the mere aggregation clause as a confirmation of the authorization to distribute collective works containing the GPL'd work. And yes, I noticed that the first one kind of contradicts the other two, too. I might add that claiming a program that uses a library's published API is a derived work is a bit shaky from the get-go. If you actually cut and paste code from the library into your program, it's a lot more clear-cut. Yes, in the former case there was no transformation of the library's source code; in the latter, there was. We talk about APIs on forums like -legal to save time, because everybody (supposedly) knows what we're talking about there. They aren't directly relevant, it's just that certain aspects of program design will normally have certain legal implications because that's how those things are normally implemented. Changing static linking to dynamic, or replacing a linker call with a dlopen() call, *always* has precisely *zero* effect on whether something is a derivative work or not. A work is created derivative, or not, at the time of inception. For source code, this is the time Yes! I could not agree more. when the code is written. The way in which it is compiled is irrelevant. For a binary, this is the time when the binary is built and linked. A statically linked binary is a derivative work of I disagree here: there is no novel intellectual work involved in building/linking a binary. A binary can be, at most, a collective (anthology) work, and this makes a difference in some point in time. Especially if the GPL is involved. everything it links because it contains verbatim copies of those things. Every binary, static, dynamic, or other, is a derivative of everything that any part of its source was derived from. Nope. Collective. No intellectually-novel transformation was applied, other than (maybe)
Re: Publicly available mbox archives of debian mailing lists + Bug#161440
Josh Metzler wrote: How would you know which subscriber was harvesting e-mail addresses? Josh If the need ever comes, you can put a fake and distinct CC: address on each outgoing mail, that will point to a single subscriber. I would receive the same mail with CC:[EMAIL PROTECTED] and you, with CC:[EMAIL PROTECTED] If joshua.abcde gets spammed, it's my fault. if joshua.abcdf gets spammed, it's your fault. Obviously, this would need to be better elaborated, but it could work. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: definition of use
James William Pye wrote:
Greetings(Please be sure to CC me!),
First, my apologies for not joining the conversation around the time
that it transpired, but it was not until recently that I had noticed it.
Second, my apologies to Mr. Welch for suffering from the controversy
created by the license that I wrote.
That's right, it's me, random Joe off the street as Mr. Palmer put it.
And, yes, IANAL(Of course IANAL. Lawyers would not consider brevity to
be a value in an instrument, and for good reason, I know(Despite the
lack of any indication of such knowledge). ;).
Before I get into any details, this discussion is about the definition
of the word 'use' in the context of copyright law (U.S.C. Title 17[1]),
and perhaps whatever extra insights the connotations of the fair license
might provide within its single, compound sentence.
This license hangs on the idea that the definition of the word 'use' in
the context of copyright law is as follows:
6: (law) the exercise of the legal right to enjoy the benefits
of owning property; we were given the use of his boat
[syn: {enjoyment}]
(From WordNet 2.0)
(dict.org, dict use, also google'ing will reveal it in other areasof the
net)
This definition does not match the definition of usar (=to use) in
Brazilian Law, which is based on possession, not ownership.
lots of stuff here
While the length of my response might not indicate it, I am not married
to this license. I wrote it in an attempt to create a *very* concise
authorization of I.P. use. BSD and MIT licenses satisfy my needs, save
brevity and generality. For instance, BSD and MIT refer to 'source
code', 'software', and 'documentation', which I would gather refer to
computer programs, but how do images and other kinds of works fall
into those terms(I guess SVG might fall into source code ;)? What if I
wanted to open source other kinds of works? I thought it would be more
fitting to have a license that actually uses the terminology of the laws
that specify the restrictions of the granted exclusive rights. It really
is a shame that 'use' is not defined in Title 17.
The only useful conclusion that I have been able to directly draw from
these discussions is that it is not *self evident* that 'use'
constitutes the exercising/enjoyment of the bundle of rights given to
the owner of copyrighted works by U.S.C. Title 17 Chapter 1[2].
So, what is the definition of the word 'use'? Does it *only* mean to
execute a program? Or to *only* read a book? Or to *only* listen to that
music?
In Brazilian computer programs law, what we *do* have is that using a
program is defined by its use license contract terms, meaning the
execution of the program under those terms -- limited by our fair use
clauses (art. 6º Computer Programs Law [L.9609/98]: one backup copy;
citation with source in context of education; similarity by
functionality; integration on/to other systems) and by our (very heavy)
consumer-protection law.
In the case of non-computer-programs-stuff, what we do have is a statute
limitation clause (art. 46 Author's Rights Act [L.9610/98]: lots of
stuff, among them musical execution in your home or in schools).
So, yes, one can suppose safely that the word use in the case of a
computer program license means executing such program; in the case of a
music, means listening to it in a private/familiar environment or in a
school; and in the case of a computer library, the execution of its API
by other programs.
Anyways, I'm getting too tired to think; perhaps when I hear back, I
will have more positions and points. That is, if you or someone else
doesn't provide something fatal.
[1]http://uscode.house.gov/download/title_17.php
[2]http://uscode.house.gov/download/pls/17C1.txt
IANAL, TINLA, this is just MHO.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#304266: ITP: sdate -- never ending september date
Ben Pfaff wrote: Ross Burton [EMAIL PROTECTED] writes: Games serve a purpose: they entertain the user. What is the purpose of sdate? The same. If you are not entertained by sdate, then you do not need to install it. That said, the following script is probably just as amusing, and undoubtedly simpler: Could you enlighten me as of the reason that September 93 never ended? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Detecting the installed MTA
Nico Golde wrote: I think there is no other way expect to specify this in a config file. Or it should be documentated that in this case the user has do dpkg-reconfigure the package. Regards Nico Isn't there a way to write a trigger to be... hmmm... triggered in case some specific package (/in/ /casu/ one of the MUAs) get installed/uninstalled/reconfigured? Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: init.d script dependencies for etch?
martin f krafft wrote: also sprach Bastian Blank [EMAIL PROTECTED] [2005.04.01.2104 +0200]: Uh, this looks like a pull type of thing in which ever init.d script starts its dependencies. I don't think this is a good idea. No, it is not. The dependencies are cached. Cached? As in queried beforehand? As in two-pass algorithm, once iterating init.d with 'depends' as option, then with 'start' ? Yeah, that sounds nice. My sarcasm detector went off with this one, so I'll try to intervene. AFAIK the Gentoo /etc/rc does the following: 1. for all init.d scripts, read it, call depend(), determine its dependencies, store its start() function somewhere; 2. for all dependency-ordered determined, call the start() functions paralelizing when possible And, yes, it's very nice. HTH Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Emulated buildds (for SCC architectures)?
Steve Langasek wrote: Hi Gunnar, On Fri, Mar 18, 2005 at 08:06:47PM -0600, Gunnar Wolf wrote: And I am sure we can find more examples like these - I have not really checked, but I would be surprised if architectures as popular as Sparc, Alpha or ARM wouldn't have an emulator (although probably not currently as reliable as those two). Now, if we face dropping one or more of our architectures (i.e. m68k) because new hardware can not be found anymore (the Vancouver proposal mentions that the release architecture must be publicly available to buy new in order to keep it as a fully supported architecture - I know, SCC != fully supported, but anyway, a buildd can die and create huge problems to a port), why shouldn't we start accepting buildds running under emulated machines? I quite agree with Anthony that if we have to emulate the machine, there's not much sense in supporting it. This makes no sense to me. There is a lot of embedded machines out there that can, for instance, run a web browser (graphical links, w3m or even mini-mo) but are not capable of running g++ (to give an example, and hence they are not capable of /building/ mini-mo). So, if you can emulate this machine in an amd64 1000x faster and with 100x more RAM, you can build an entire Debian system, and permit the installation of a base system with the needed features for the embedded application. I do know, from first-hand experience trying to get ssh running on a Cobalt, that compilation speed is not always correlated with the usefulness of a system; so I'm not completely opposed to using distcc (in moderation!) for release architectures, but I would still first like to see some serious discussion about why it's useful to build all the software we do for all the architectures before agreeing that such a distcc network is warranted. Other question I have is: why the (in moderation!) comment? I think distcc and ccache should be used thoroughly (sorry if this is the wrong spelling) in the buildd process, and I have not seen any moderate, rational and good argument in contrary. Regards, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Documentation is/is not software [was: NEW ...]
Matthew Palmer wrote: On Tue, Mar 22, 2005 at 12:32:30PM +, Matthew Wilcox wrote: On Tue, Mar 22, 2005 at 09:06:19AM -0300, Humberto Massa wrote: And I believe that the Vancouver proposal, if implemented as intended up to now, will not only affect what Debian really *is*, but in some ways will *destroy* what Debian is. Debian has already decided to destroy what it is by giving in to the crackpots who insist that everything is software. Way to set the tone for a productive debate. Yeah, we are seeing a lot of this lately. At any rate, the problem with trying to treat different types of bitstreams differently is to classify them, and identify a different set of freedoms which are appropriate -- and, more pretinently, why those different set of freedoms is important. The crackpots won more or less by default, because nobody was able to come up with either of these two pre-requisites. This suggests to me that either (a) it can't actually be done, in which case the crackpots are, after all, right; or (b) Debian is so filled with crackpots that there is nobody who actually wants to see documentation treated differently to executable programs. IMHO the problem is that there is not a clear distinction. Period. Why? Because source code *is* documentation. The set of freedoms we want to Free Software (AFAICT) is: freedom to study, modify... for all this we need access to the documentation, part of which is the source code. I used to sit in the documentation requires different freedoms camp, but eventually just couldn't support my feelings with logical argument. But there are significantly more powerful minds than mine out there; I look forward to hearing their arguments in favour of different freedoms for documentation. The problem with hearing arguments in favour of different freedoms for documentation is that people will have to define what is -- and what is not -- documentation. And I don't really think this is possible. One example: are Debian-changelogs documentation? They contain instructions on what version of a package is to be built, and which debbugs should be closed... If someone can come up with a bright-line test for differentiating executable materials and documentation, or executable materials and say firmware, and can produce a DFDocumentationG or DFFirmwareG with effective reasoning, I will be most impressed, and will most likely support their position. Until then, however, I am firmly in the all things we ship are software, and the DFSG applies to all of that camp. - Matt crackpot and proud Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: NEW handling: About rejects, and kernels (Was: Re: NEW handling ...)
Sven Luther wrote: Still i believe i have made some constructive proposals, and even if my first posts may have been a bit too aggressive, for which i apologize, or too many, i think it is also a prove of the passion which lies on this issue. Something which has the potential to affect many of what we believe debian is, and which is handled by utter contempt, at least in the initial posting. I give my support to Sven. And I think there is many more people in this list who should apologize, too. And I believe that the Vancouver proposal, if implemented as intended up to now, will not only affect what Debian really *is*, but in some ways will *destroy* what Debian is. Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Do not make gratuitous source uploads just to provoke the bui ldds!
David Schmitt wrote: 1) people realize that $arch won't be REGULAR for etch because the people working on a release don't want to handhold it through testing and autobuilding is too slow to properly keep up. Even not considering the problem I see with the Vancouver proposal regarding Debian identity and quality, I think *this* is one of the greatest problems: how much is this a problem with autobuilding being slow? Autobuilding being slow is a problem that has a number of interesting, _techinical_ solutions as, eg, incremental building, ccache, distcc, etc. And I had not a good answer on why such an important item (KDE taking 12 days to compile on m68k???) was not addressed. A non-clean ccache, keeping .o files between successive would give a lot of boost on this. HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
Matthias Urlichs wrote: With a decent toolset, doing a security package for 10 architectures should be a nearly-constant amount of work, no matter which base the number 10 is written in. Speaking of which, can anyone here explain to me why does a two-line security fix on, say, KDE, makes things need to be recompiled for 12 days long? (!!!) One could think that there are more incremental ways of dealing with recompilation of enourmous packages. Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
Sven Luther wrote: On Mon, Mar 14, 2005 at 03:52:54PM -0300, Humberto Massa wrote: Sven Luther wrote: Speaking of which, can anyone here explain to me why does a two-line security fix on, say, KDE, makes things need to be recompiled for 12 days long? (!!!) One could think that there are more incremental ways of dealing with recompilation of enourmous packages. Not currently supported, and not really considered as a technical solution. Friendly, Sven Luther Your answer was not really considered an answer to my question either :-) My original question began with the word why...?. So I repeat, why does small things need days of recompilation? Moreover, why isn't They do not really, provided you keep about all the intermediate .o files of the preceding build, depending on the security fix naturally. My points are: (1) this is feasible/viable and (2) this would put times for tier-[23] arch builds in the same league (or at least compatible) with tier-1 arch builds. incremental building supported? And finally, why isn't it considered a technical solution? Because it is not needed for the fast tier1 arches ? This is a chicken-and-egg thing, isn't it? And it should be considered a *technical* solution, even if not a *political* one. Friendly, Sven Luther Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
