Partnership with AddonFox
Hello, We found your Linux distro and would like to offer you a cooperation that you can benefit from. Our addon, AddonFox, lets users install the best Firefox addons all at once. The users choose which addons they want by choosing the categories that interest them and the addons they want using checkboxes. AddonFox then installs them all at once. It can give great value for your users, if you included AddonFox in Firefox in your distro and you would get 50% revenue from the addons in the AddonFox list that pay us per install. The AddonFox list was created from us going over hundreds of addons and choosing the best ones. We then also added some paying addons. This generates great revenue and gets great feedback from users. You can install AddonFox from http://www.addonfox.com/ Looking forward for your response. Best wishes, Yotam -- Yotam Elal | Business Development | Linkular LLC Email: yo...@linkular.com Phone: +972-54-5665548 -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d6ba5b9.4090...@linkular.com
Reminder: DebConf12 bid discussion meeting: 1 March, 20 UTC
Reminder: There will be a meeting to discuss the DebConf12 bids at 20 UTC on 1 March, on #debconf-team on irc.debian.org. Everyone interested in where DebConf will happen in 2012 is encouraged to read through the competing bids' documents and attend the meeting. Agenda: - Questions from bid teams about the bid process - Question from bid teams about what others suggest they try to do on any uncertain aspects or potential problems - Questions to bid teams A more formal meeting will be held later (probably on 15 March) to lead to a decision on the DebConf12 venue. Information about the bids can be found at: http://wiki.debconf.org/wiki/DebConf12/Bids/Managua http://wiki.debconf.org/wiki/DebConf12/Bids/Brazil/BeloHorizonte You can also ask the bid teams questions on the debconf-team mailing list, outside the meeting, and this is preferable for more complicated questions, or ones which might require research to answer. -- Moray -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktindutcvzcwt8k57zky4va5oiktgsmqlccy4f...@mail.gmail.com
[DEP9] inet-superserver configuration by maintainer scripts
[M-F-T set to -devel and my email] Hi, I claim DEP-9 for a proposal on inetd.conf updates by maintainer scripts. This proposal is the evolution of one I've made over a year ago, and takes into account the criticism and suggestions made at the time. FWIW I've contacted privately those that were against the old proposal, a while ago, to give them the opportunity to voice their opinion on this new version, and the only reply I've received was rather positive, so here it is for further discussion. Appended below the DEP itself -- please follow up to -devel. Cheers, Serafeim Title: inet-superserver configuration by maintainer scripts DEP: 9 State: DRAFT Date: 2011-02-28 Drivers: Serafeim Zanikolas s...@debian.org URL: http://dep.debian.net/deps/dep8 License: http://www.jclark.com/xml/copying.txt Abstract: Motivation, requirements and functional overview of a successor configuration tool for inetd superservers. [[!toc ]] # Introduction The inet-superserver facility (typically provided by the openbsd-inetd package) listens to certain sockets and invokes the right server upon the arrival of an incoming request. Servers that are meant to be invoked by inetd must add a service entry to /etc/inetd.conf upon package installation (and remove the entry upon package purge). Maintainer scripts that modify inetd.conf must currently do so using a utility called update-inetd, as per Policy 11.2. However, update-inetd has a problematic interface that leads to several kinds of bugs, including cross-package ones. Fixing update-inetd is largely a matter of fixing its interface, which would break backwards-compatibility. With that cost as a given (ie. the cost of revising all maintainer scripts of update-inetd's reverse-depends), one might as well create a successor tool with a cleaner interface. This DEP proposes such a successor inetd configuration tool, hereafter called reconf-inetd. reconf-inetd, in addition to providing the existing functionality, must meet the following requirements: * the standard configuration files of inetd and xinetd must remain the authoritative files; * the solution must not change the way system administrators configure inetd, and must have no impact on maintainers of Provides: inet-superserver packages; * reconf-inetd must be capable of co-existing with update-inetd, so as to allow a gradual transition. Note that the first requirement above implies that inetd.conf entries that have been (i) added by reconf-inetd and (ii) were subsequently modified by the user, shall not be removed even on package purge. # Motivation The main problem of update-inetd is that the service entry to be enabled, disabled or removed, is selected in terms of a service name, such as ftp. This limitation typically leads to cross-package bugs because of the difficulty to distinguish between independent implementations (eg. ftpd-ssl versus proftpd), or an ipv4 versus an ipv6 implementation of the same kind of service. As an example, in #168847, ftpd-ssl's invocation of update-inetd enables the service entry of (the previously uninstalled) proftpd because both packages' entries have an ftp service name. As of now, one can try to avoid the above problem as follows. A maintainer script may (i) further specify the acted-upon service entry in terms of a regular expression (which is matched against the whole service entry, instead of just the service name); (ii) override the default comment-prefix (#lt;offgt;# ), to distinguish service entries of different packages that provide the same kind of service (eg. #lt;off-ftpd-ssl-ipv4gt;# vs #lt;off-proftpd-ipv4gt;# ). These features work when used correctly, but at the cost of fragile logic in maintainer scripts. To summarise, the interface of update-inetd is inadequate in that it does not require that the following three elements are specified to select an entry: service name, protocol type, and path to server program. A secondary issue, but nevertheless one that would be nice to solve, is support for configuration updates of xinetd (#8927). xinetd has a relatively low popcon but one could argue that that may be the case because it is not well integrated in Debian. # Outline of reconf-inetd operation reconf-inetd will operate similarly to update-inetd, ie. add, remove, enable and disable service entries in /etc/inetd.conf. The main difference is that where update-inetd uses command-line arguments, reconf-inetd will use xinetd.conf(5) configuration fragments under /usr/share/reconf-inetd (hereafter called reconf-inetd fragments, for brevity). Moreover, reconf-inetd will be invoked via a dpkg trigger, as opposed to from maintainer scripts. With reconf-inetd, inet-superserver configuration will occur as follows: * reconf-inetd will provide the directory /usr/share/reconf-inetd, and declare a dpkg trigger for that directory * server packages that can use inetd, will depend on reconf-inetd and install a
No good user experience of Debian (Was: Packaging r-bioc-simpleaffy)
Hi Tony, I would like to discuss this topic in a separate thread on debian-project where it might belong to. On Mon, Feb 28, 2011 at 12:55:58AM +, Tony Travis wrote: it would not be a good user experience at all running it under Debian with Iceweasel instead of Firefox, for example, and lots of non-free things missing. These things do matter, even though we all know that the two Linux platforms are almost identical underneath the GUI... The vast majority of biologists use M$ Windows on their desktop, and don't care about the server. However, to encourage biologists to use Linux on the desktop as, presumably Debian-Med wants to, the user experience needs to be at least as good as M$ Windows and preferably better. I've just tried Debian 6 - It really is NOT better than M$. Could you please be a bit more verbose on this. The only hard facts I can make out from your mail are these: - Iceweasel instead of Firefox Debian does not rename Firefox just for the fun of it. We just had a longish discussion about it with lawyers involved and they came to the conclusion that we have no other chance than renaming Firefox. Please do not blame Debian for other projects unusual licenses. - lots of non-free things missing Can you please be a bit more verbose what exactly you are missing (in general and specifically for your work as biologist). I think I remember your unhappyness about Gnash. Anything else? I personally admit that I simply have to trust your opinion that Debian is not better than M$ because I do not know any M$ operating system well enough to make a knowledgeable decision. My frustration when I touched such systems were most probably based on my beginner status I have on these but I would really like to hear some points which make me understand your statement. (This is really an honest question.) This thread is a total turn-off for me about Debian-Med. Even though you were joking about me going back to Debian, I can tell you that I never will because in trying to win hearts and minds of ordinary users Debian has already lost the fight. This sort of internecine conflict between two very similar Linux distributions is pointless. I personally do not see a conflict between Debian and Ubuntu neither is there any sign of a internecine one. I take your comment really seriosely but to fully understand what you would expect (except Mozilla changing its license and some better replacements of non-free tools). For my perception criticism is the best way to progress and I really hope that we will be able to meet your user experience in the future better than in the past. It is what Debian and Ubuntu have in common that attracted me to Debian-Med. The people here have been very helpful indeed, but the Debian politics I've witnessed recently are a wake-up call to me. What is the big deal about the fact that we set up two Bioconductor repo's? I think this was clarified and that there is no politics involved here. Debian packages are simply handcrafted. There are people out there who explain Debian as: Ubuntu but tested. I do not want to overstress this polemic argument but there is some truth in it and hopefully makes you understand that this has nothing at all to do with politics but rather with quality and technical perfectness. [I think your other questions are answered on the Debian Med mailing list. I simply wanted to share some negative user experience in contrast to several good critics on debian-project list. For the readers here: I highly regard Tony's opinion. Please do not start a flamewar about his opinion.] Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110228225908.ga5...@an3as.eu
Re: No good user experience of Debian (Was: Packaging r-bioc-simpleaffy)
On 28/02/11 22:59, Andreas Tille wrote: Hi Tony, I would like to discuss this topic in a separate thread on debian-project where it might belong to. Hi, Andreas. OK, the topic is now closed on Debian-Med. [...] I simply wanted to share some negative user experience in contrast to several good critics on debian-project list. For the readers here: I highly regard Tony's opinion. Please do not start a flamewar about his opinion.] I don't want to start an advocacy debate about Debian vs. Ubuntu, because that has been done to death elsewhere. My objective is to win the hearts and minds of biologists using M$ Windows to run Bio-Linux, the current version of which is based on 64-bit Ubuntu 10.04 LTS. Together with my colleagues, I arranged a biologist's 'power' user workshop in Florence during which we spent one of the three days in a University computer lab set up entirely with Debian Etch workstations running Iceweasel, to connect as NX clients to NuGO-Linux servers. http://nbx.nugo.org It was not my idea to use Debian clients. It was a facility offered to us by the University of Florence and I was happy to accept the offer. I did not anticipate the problems that we encountered doing something as simple as running an NX client. The session was a complete disaster until we rapidly installed the non-free Sun Java and browser plugin. First off, our NuGO servers use the NX 'helper' applet that did not work with gcj and IcedTea, to load a native NX client. Then as part of the excercise we wanted to run Adobe reader. These things are trivial to do under M$ Windows and I found myself unable to convince anyone that it was a good idea to run Linux on the client-side. Needless to say, this all worked perfectly from my Bio-Linux (Ubuntu) laptop. I used Debian on SPARC and x86/x86_64 on workstations and servers long before Ubuntu was released, and I'm well aware that Ubuntu is nothing without Debian. However, my own experience of non-expert users being introduced to Debian for the first time is a lot less satisfactory than when they are introduced to Ubuntu. I'm not in any way detracting from the huge achievements of Debian. I'm just saying that I found it easier to convince sceptical M$ Windows users to run an NX client on their own machine to access an Ubuntu server, or run Ubuntu on their own machine than I did to convince them to use Debian for any purpose. As Andreas said, this is not flame-bait - It's just my opinion, and I've posted a message here on debian-project because he asked me to. Bye, Tony. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d6c3fc3.6090...@minke.ukfsn.org
