Re: libproxy as external dependency
On Thu, 2008-10-23 at 17:35 +, Benjamin Otte wrote: pros: - current proxy handling in GNOME is a huge mess, we're all lucky we can live without proxies - the API looks extremely sane - there is nothing else that does proxying - Dan (who is going to be the main - or only? - user of it) likes it - active maintainers - no bugs cons: - I'm (luckily) not too knowledgable about proxy handling - not a lot of users - yet another library, slowing applications startup. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: libproxy as external dependency
On Fri, 2008-10-24 at 11:21 +0200, Xavier Bestel wrote: On Thu, 2008-10-23 at 17:35 +, Benjamin Otte wrote: pros: - current proxy handling in GNOME is a huge mess, we're all lucky we can live without proxies - the API looks extremely sane - there is nothing else that does proxying - Dan (who is going to be the main - or only? - user of it) likes it - active maintainers - no bugs cons: - I'm (luckily) not too knowledgable about proxy handling - not a lot of users - yet another library, slowing applications startup. only of those that might require a proxied connection, not every single application, which is fairly obvious. but humour me: where would you put this functionality? and saying libgnome or gtk+ is not going to cut it. ciao, Emmanuele. -- Emmanuele Bassi, W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: libproxy as external dependency
2008-10-24 klockan 11:40 skrev Emmanuele Bassi: but humour me: where would you put this functionality? and saying libgnome or gtk+ is not going to cut it. libsoup perhaps? — Wouter -- :wq mail [EMAIL PROTECTED] web http://uwstopia.nl come on fallen star · i refuse to let you die · so be mine — placebo signature.asc Description: Digital signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: libproxy as external dependency
2008/10/24 Xavier Bestel [EMAIL PROTECTED]: - yet another library, slowing applications startup. Actually, I've been thinking about this problem lately. Why don't people use dlopen() more often? If you use a library in your app which is not intrinsically essential to it (like gtk+ is) why are you linking to it at load time? In general I think GUI apps should be designed to load up as fast as possible, lazily loading and processing as much as possible. In this specific library case, since the API is so simple and you don't know you need it until you somehow check your app's settings it's a no-brainer really. Rui ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: libproxy as external dependency
On Fri, 2008-10-24 at 12:04 +0200, Wouter Bolsterlee wrote: 2008-10-24 klockan 11:40 skrev Emmanuele Bassi: but humour me: where would you put this functionality? and saying libgnome or gtk+ is not going to cut it. libsoup perhaps? er... http://mail.gnome.org/archives/desktop-devel-list/2008-October/msg00041.html libsoup is going to use this library, but not every project is going to be using libsoup to access proxies. e.g. the dictionary might probably use libproxy to try and connect to the DICT servers, and no libsoup would be involved. ciao, Emmanuele. -- Emmanuele Bassi, W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: libproxy as external dependency
On Fri, 2008-10-24 at 11:09 +0100, Rui Tiago Cação Matos wrote: In this specific library case, since the API is so simple and you don't know you need it until you somehow check your app's settings it's a no-brainer really. You could lazy-load the library when you need to access a URL, but the point is that your app shouldn't have to know how to handle proxies or check settings: it just asks the library to handle them. Ross -- Ross Burton mail: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] www: http://burtonini.com signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: libproxy as external dependency
On Fri, 2008-10-24 at 11:09 +0100, Rui Tiago Cação Matos wrote: 2008/10/24 Xavier Bestel [EMAIL PROTECTED]: - yet another library, slowing applications startup. Actually, I've been thinking about this problem lately. Why don't people use dlopen() more often? If you use a library in your app which is not intrinsically essential to it (like gtk+ is) why are you linking to it at load time? In general I think GUI apps should be designed to load up as fast as possible, lazily loading and processing as much as possible. that's already what happens by default: used symbols are only paged in when needed. the default penalty for adding a shared object is 4 kB, and if the library has been written correctly, the amount of dirty RSS memory should be 0. ciao, Emmanuele. -- Emmanuele Bassi, W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: gnome-user-share
On Thu, Oct 23, 2008 at 5:15 PM, Patryk Zawadzki [EMAIL PROTECTED] wrote: On Thu, Oct 23, 2008 at 5:08 PM, Bastien Nocera [EMAIL PROTECTED] wrote: On Thu, 2008-10-23 at 17:02 +0200, Frederic Peters wrote: A point Patryk touched is that generic distributions will provide Apache packages configured to run at startup, so it is not just a matter of binary size. That's exactly the problem. As a data point, Fedora's httpd is disabled by default for exactly this sort of reason (having it installed doesn't mean we want it running by default). I doubt our server guys will get overly happy over the idea of disabling a typical server daemon just so you can integrate it with GNOME. I don't really think I want the server team to hate the GNOME team any more. Also there seem to be lighter alternatives: http://www.perlmonks.org/?node_id=658773 And what about Cherokee? http://www.cherokee-project.com It's small, modular, very light and easy to run as a user in specific port (to avoid bother system web servers, for example) http://www.cherokee-project.com/doc/bundle_cherokee-worker.html -- Juan Jesús Ojeda Croissier Emergya Consultoría / http://www.emergya.es Avda. de la Innovación, 3 (Edif. Hércules), Mód 12-13 E41020 Sevilla Tfno: +34 954 51 75 77 Fax: +34 954 51 64 73 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: gnome-user-share
Juan Jesús Ojeda Croissier wrote: And what about Cherokee? http://www.cherokee-project.com It's small, modular, very light and easy to run as a user in specific port (to avoid bother system web servers, for example) http://www.cherokee-project.com/doc/bundle_cherokee-worker.html Sure, but the point is not about the code size (as Bastien noted Apache is just two or three megabytes) but about distribution policies to start installed services by default. And their policies apply to Cherokee just like to other webservers... Bastien already wrote about Fedora policy, httpd is disabled by default. I know that Debian policy is to consider that the user installing a server wants it to be started. From what I read of Patryk, PLD Linux also starts Apache on installation. What about others ? I guess Red Hat is like Fedora, and Ubuntu is like Debian, but what about SuSE ? Frederic ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: gnome-user-share
Le vendredi 24 octobre 2008, à 14:38 +0200, Frederic Peters a écrit : Bastien already wrote about Fedora policy, httpd is disabled by default. I know that Debian policy is to consider that the user installing a server wants it to be started. From what I read of Patryk, PLD Linux also starts Apache on installation. What about others ? I guess Red Hat is like Fedora, and Ubuntu is like Debian, but what about SuSE ? I guess you meant openSUSE ;-) Based on http://en.opensuse.org/Apache_Quickstart_HOWTO, my guess would be that apache is not running by default when it's installed. Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: gnome-user-share
Vincent Untz wrote: Le vendredi 24 octobre 2008, à 14:38 +0200, Frederic Peters a écrit : Bastien already wrote about Fedora policy, httpd is disabled by default. I know that Debian policy is to consider that the user installing a server wants it to be started. From what I read of Patryk, PLD Linux also starts Apache on installation. What about others ? I guess Red Hat is like Fedora, and Ubuntu is like Debian, but what about SuSE ? I guess you meant openSUSE ;-) Based on http://en.opensuse.org/Apache_Quickstart_HOWTO, my guess would be that apache is not running by default when it's installed. Right, it's not. I know this because I always install apache on my machines because libsoup's regression tests use it (with their own custom httpd.conf.in), which is another example of a scenario where someone installing apache doesn't necessarily want it running by default. Of course, distros that think run-by-default-when-installed is the right behavior could just split the package into apache-software-only (or something) and have apache just be a tiny package that pulled in the software package and added the config files necessary to make it run by default. And then gnome-user-share would depend on the apache-software-only package on those distros. -- Dan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: gnome-user-share
Le jeudi 23 octobre 2008 à 18:22 +0200, Murray Cumming a écrit : Yeah, I have the same problem with Glom's dependency on PostgreSQL. Debian/Ubuntu users get an unused PostgreSQL instance even when Glom isn't running, just because its Debian policy to run any services that are installed, with no apparent way for the package to request anything different. I think it's a bad policy. If it’s really necessary for Glom to have the PostgreSQL binaries around (which seems strange when there are alternatives such as SQLite), we will simply split the postgresql packages in two, one with the binaries and one providing the service. Not a big issue. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: gnome-user-share
On Solaris, apache daemon is disabled by default aswell. Matt Vincent Untz wrote: Le vendredi 24 octobre 2008, à 14:38 +0200, Frederic Peters a écrit : Bastien already wrote about Fedora policy, httpd is disabled by default. I know that Debian policy is to consider that the user installing a server wants it to be started. From what I read of Patryk, PLD Linux also starts Apache on installation. What about others ? I guess Red Hat is like Fedora, and Ubuntu is like Debian, but what about SuSE ? I guess you meant openSUSE ;-) Based on http://en.opensuse.org/Apache_Quickstart_HOWTO, my guess would be that apache is not running by default when it's installed. Vincent ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: gnome-user-share
Le jeudi 23 octobre 2008 à 17:02 +0200, Frederic Peters a écrit : A point Patryk touched is that generic distributions will provide Apache packages configured to run at startup, so it is not just a matter of binary size. What do distributors think? I think we could split the web server package in two. One package would contain the binary, that would be available for things like gnome-user-share. The other would contain the system-wide configuration and the service. I also think that Apache is a bad choice. If you need a good web server with DAV support, please think of lighttpd instead, or - much better - of a libsoup-based implementation. Cheers, -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: gnome-user-share
Le jeudi 23 octobre 2008 à 16:41 +0100, Bastien Nocera a écrit : I doubt our server guys will get overly happy over the idea of disabling a typical server daemon just so you can integrate it with GNOME. I don't really think I want the server team to hate the GNOME team any more. Why is it enabled by default anyway? You would certainly need to configure things for it to work properly anyway. Not necessarily. If you just run apt-get install some-webapp, it will (for those that are correctly packaged) install the webserver and the database server, configure the former, create tables in the latter and be ready for immediate use. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: gnome-user-share
On Fri, 2008-10-24 at 15:11 +0200, Josselin Mouette wrote: Le jeudi 23 octobre 2008 à 18:22 +0200, Murray Cumming a écrit : Yeah, I have the same problem with Glom's dependency on PostgreSQL. Debian/Ubuntu users get an unused PostgreSQL instance even when Glom isn't running, just because its Debian policy to run any services that are installed, with no apparent way for the package to request anything different. I think it's a bad policy. If it’s really necessary for Glom to have the PostgreSQL binaries around (which seems strange when there are alternatives such as SQLite), SQLLite can't do what PostgreSQL can do, which is why PostgresSQL exists. For instance: - Multi-user and the relevant locking. - Access control. - Network access. And I'm quite sure that we'll discover various SQL things that SQLLite can't handle when we try to support SQLLite, which we plan to do for embedded devices. SQL gets complicated quickly, even for seemingly obvious tasks. we will simply split the postgresql packages in two, one with the binaries and one providing the service. Not a big issue. So far that hasn't happened. But I've been dealing with Ubuntu because they are (slightly) more responsive. -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: gnome-user-share
Le vendredi 24 octobre 2008 à 17:58 +0200, Murray Cumming a écrit : SQLLite can't do what PostgreSQL can do, which is why PostgresSQL exists. For instance: - Multi-user and the relevant locking. - Access control. - Network access. As these are not things necessary for a UI generator, I thought glom could rely on SQLite instead. This is not a bad thing to require a better DB engine, but it really has some shortcomings when it comes to packaging. So far that hasn't happened. But I've been dealing with Ubuntu because they are (slightly) more responsive. Whoa? There is no Debian package simply because no one had stepped up so far. Christophe Sauthier is starting to work on it, and I will help him to get the necessary changes in postgresql. Cheers, -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: gnome-user-share
On Fri, 2008-10-24 at 18:07 +0200, Josselin Mouette wrote: Le vendredi 24 octobre 2008 à 17:58 +0200, Murray Cumming a écrit : SQLLite can't do what PostgreSQL can do, which is why PostgresSQL exists. For instance: - Multi-user and the relevant locking. - Access control. - Network access. As these are not things necessary for a UI generator, Even if Glom was just a GUI generator, I guess I would disagree about your idea of what is a good database GUI. I thought glom could rely on SQLite instead. This is not a bad thing to require a better DB engine, but it really has some shortcomings when it comes to packaging. So far that hasn't happened. But I've been dealing with Ubuntu because they are (slightly) more responsive. Whoa? There is no Debian package simply because no one had stepped up so far. Christophe Sauthier is starting to work on it, and I will help him to get the necessary changes in postgresql. Thanks. -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: gnome-user-share
On Fri, 2008-10-24 at 15:16 +0200, Josselin Mouette wrote: I also think that Apache is a bad choice. If you need a good web server with DAV support, please think of lighttpd instead, or - much better - of a libsoup-based implementation. There's also security issues to consider. One good thing about using Apache is the fact that there's a huge dedicated security team in place for both reviewing and dealing with vulnerabilities in highly predictable ways. Also, the distributors of Apache typically provide good response time on integrating these fixes just because Apache is so ubiquitous and people use it for traditional HTTP duties on port 80. Especially on distributions not using something like SELinux this is a problem. Remember that with Mandatory Access Control (which e.g. SELinux provides), you can confine the web server process spawned by g-u-s to only access ~/Public. Without something like this (and too many people, yours truly included, runs SELinux in permissive mode)... if there's a vulnerability in the server used by gnome-user-share... then you're effectively serving all the files that the user has access to (e.g. $HOME including passwords stored in cleartext by Firefox (the default). Result: Game over man! All thismeans that it's very important that we use the most secure web server we can get for gnome-user-share. As I said, it's clear to me that Apache does meet our goals here. If you want to propose something else, the burden is on you to provide evidence that what you propose is not only reasonably secure, but also have good processes in place for dealing with vulnerabilities. (FWIW, I don't mean to belittle libsoup-as-a-server (my understanding is that libsoup is mostly used as a client so that's where the focus is) or the lighttpd teams. To be honest, I haven't looked at their security track record security. I doubt most people in this thread have.) David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: gnome-user-share
On Fri, Oct 24, 2008 at 06:19:54PM +0200, Murray Cumming wrote: Whoa? There is no Debian package simply because no one had stepped up so far. Christophe Sauthier is starting to work on it, and I will help him to get the necessary changes in postgresql. Thanks. BTW, I talked to one of the Debian apache maintainers over dinner last night, and he also agreed it's probably a good idea to split the init scripts off. Probably best to come up with some general scheme here for these kind of things. Michael ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: gnome-user-share
Em Qui, 2008-10-23 às 14:53 +0100, Bastien Nocera escreveu: Heya, I'd be interested in getting gnome-user-share into GNOME 2.26. But one of the main shorter term goals is to get the desktop sharing feature of vino integrated into gnome-user-share. http://bugzilla.gnome.org/show_bug.cgi?id=471366 Hi! I really would love to see all sort of sharing in a central place. I'm just a bit worried on how to merge the current vino capplet into g-u-s. Currently it has many options, results of people complaining about those hidden features - they existed, but were only activated by some gconf editor. Definitely this dialog needs some love. Next week I'll attend the 5º GNOME Forum here in Brazil and will discuss it with some design guys. In short, +1 from me! -- Jonh Wendell http://www.bani.com.br ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: gnome-user-share
On Fri, 24.10.08 20:14, Josselin Mouette ([EMAIL PROTECTED]) wrote: Le vendredi 24 octobre 2008 à 12:53 -0400, David Zeuthen a écrit : As I said, it's clear to me that Apache does meet our goals here. If you want to propose something else, the burden is on you to provide evidence that what you propose is not only reasonably secure, but also have good processes in place for dealing with vulnerabilities. The last times it happened, it seemed to me that lighttpd developers have good processes when it comes to security. One other thing to consider wrt. security is the code size, and apache binaries are about twice as large. There are of course other advantages with using lighttpd, such as less memory footprint, better performance and a much more flexible configuration scheme; it may not be necessary for gnome-user-share, but it’s much less error-prone and that’s another possible cause of bugs. Contrary to what the name suggest, lighttpd is not just a lightweight web server, it is a powerful and complete implementation used by some of the biggest websites. I don't think that this kind of FUD about Apache is very constructive. Just because lighttpd has a light in its name it doesn't mean that Apache is a slow huge beast. That is nonsense. Apache is modular. You can decide what you want to use and what not. It's easy to configure Apache in away that it is perfectly suitable even for embedded use -- and I doubt it would be much slower or more resource-hogging than any other httpd. So, unless you have rational arguments, i.e. real numbers how much faster and lighter and less error-prone lighttpd actually is then all the noise about lighttpd (or Cherokee) is just noise. And even if Apache was a bit slower, you get so much more for it when it comes to functionality and well-tested-ness. Also Apache is available in each distro and well understood. Please, think twice before blindly believing that something is oh such much lighter or oh so much faster just because some people who wrote it like to use the word lightweight. Let's stay rational! There are good reasons to eventually adopt gsoup for this stuff. But there is no benefit at all in adopting Cherokee/lighttpd over Apache. Especially since the Apache support is already there, it is written. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: gnome-user-share
Isn't that what nfs does? Or for that matter, ftp? I don't understand why a web server is needed for sharing files. 2008/10/23, Bastien Nocera [EMAIL PROTECTED]: Heya, I'd be interested in getting gnome-user-share into GNOME 2.26. Currently, gnome-user-share is a simple capplet and daemon combination that, through obex-data-server and apache, provides users with simple file sharing. Currently it supports: - ObexFTP and ObexPush (through obex-data-server) - DAV file sharing (through Apache's httpd) Future plans include: - Sharing optical media drives: http://bugzilla.gnome.org/show_bug.cgi?id=530744 - Sharing selected drives: http://bugzilla.gnome.org/show_bug.cgi?id=355382 We're also looking into integrating Frank Scholz' UPNP sharing work (see http://coherence.beebits.net/wiki/Nautilus). But one of the main shorter term goals is to get the desktop sharing feature of vino integrated into gnome-user-share. http://bugzilla.gnome.org/show_bug.cgi?id=471366 Questions? Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- mvh Björn ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: gnome-user-share
On Fri, 2008-10-24 at 21:11 +0200, BJörn Lindqvist wrote: Isn't that what nfs does? Or for that matter, ftp? I don't understand why a web server is needed for sharing files. WebDAV is supported natively with Bonjour/Zeroconf in MacOS X and Windows, and is very well supported in GVFS and Nautilus. We could just as well have implemented FTP, but it wouldn't have had the same level of integration. NFS requires kernel level help, and the whole protocol is dreadful. Implementing user-space NFS (be it on the server, or the client side[1]) nicely is not easily possible. Adding more protocols would be easy, but unneeded in my opinion. [1]: See the nfs-*.[ch] files at http://svn.gnome.org/viewvc/gnome-vfs/trunk/modules/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: gnome-user-share
Le vendredi 24 octobre 2008 à 20:58 +0200, Lennart Poettering a écrit : I don't think that this kind of FUD about Apache is very constructive. Just because lighttpd has a light in its name it doesn't mean that Apache is a slow huge beast. That is nonsense. And just because Apache is famous doesn’t mean it’s a silver bullet either. Apache is modular. You can decide what you want to use and what not. It's easy to configure Apache in away that it is perfectly suitable even for embedded use -- and I doubt it would be much slower or more resource-hogging than any other httpd. Figures show it. Apache will use at least 4MB of RSS on my systems, where lighttpd uses around 2. As for benchmarks, see for example http://www.cherokee-project.com/benchmarks.html - most other benchmarks you can find will show the same kind of ratio between Apache and lighttpd. So, unless you have rational arguments, i.e. real numbers how much faster and lighter and less error-prone lighttpd actually is then all the noise about lighttpd (or Cherokee) is just noise. Faster and lighter can easily be shown by benchmarks. As for less error-prone, you should just have a look at a typical lighttpd configuration file. Currently I have a complicated setup with many vhosts and I can’t imagine how much work it would take to achieve the same with Apache. And even if Apache was a bit slower, you get so much more for it when it comes to functionality and well-tested-ness. You might be right about well-testedness, but about functionality I beg to disagree; until very recently Apache didn’t even support FastCGI, and for most things they are functionally equivalent. Please, think twice before blindly believing that something is oh such much lighter or oh so much faster just because some people who wrote it like to use the word lightweight. Let's stay rational! It is pretty insulting to assume I’m saying it because of what I’ve read. I’m saying it because I use both of them everyday. And frankly, there’s one of them that I’d like not to see anymore. It’s not that Apache is bad – I’d be pretty happy if all software was bad like that — but it’s not as flexible as other solutions. Now, I don’t think this is the right place to troll about webservers, but you don’t need to climb on your high horse just because someone suggests another technical solution. Especially since the Apache support is already there, it is written. If people are interested, I guess I could do the porting to lighttpd, it doesn’t look too complicated. Maybe seeing it in action would be more convincing. Cheers, -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: gnome-user-share
On Fri, 2008-10-24 at 15:16 +0200, Josselin Mouette wrote: Le jeudi 23 octobre 2008 à 17:02 +0200, Frederic Peters a écrit : A point Patryk touched is that generic distributions will provide Apache packages configured to run at startup, so it is not just a matter of binary size. What do distributors think? I think we could split the web server package in two. One package would contain the binary, that would be available for things like gnome-user-share. The other would contain the system-wide configuration and the service. I also think that Apache is a bad choice. If you need a good web server with DAV support, please think of lighttpd instead, or - much better - of a libsoup-based implementation. Also note that whatever solution is chosen, this needs to be possible: http://bugzilla.gnome.org/show_bug.cgi?id=529852 http://bugzilla.gnome.org/show_bug.cgi?id=519577 Both of those would be possible with httpd, just not currently implemented. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: gnome-user-share
2008/10/24 Bastien Nocera [EMAIL PROTECTED]: On Fri, 2008-10-24 at 21:11 +0200, BJörn Lindqvist wrote: Isn't that what nfs does? Or for that matter, ftp? I don't understand why a web server is needed for sharing files. WebDAV is supported natively with Bonjour/Zeroconf in MacOS X and Windows, and is very well supported in GVFS and Nautilus. What web servers do they run? Adding more protocols would be easy, but unneeded in my opinion. I feel kind of silly for installing Apache (along with the default It works! html page) for sharing files.. but I get your point. I have experimented some with gnome-user-share, and it works very well. But there seem to be some rough edges. Only the ~/Public directory is shared. Unless you already know about it, it is quite impossible to guess what name the directory should have. Why can't it work like nautilus-share? Right click any directory - Sharing options. It is very discoverable. The capplet allows you to configure password less sharing. Allowing that seems like a bad choice to me and a user induced security hole. The description could also be clearer on who will gain access to the shared files. It reads Share filer over the network. I assume it means the local area network and not the internet, but I'm not sure. Then there are some minor bugs. The share name is not translated and always reads public files. Trying to open the share from localhost returns HTTP-error: Cannot connect to destination. Also, I would like to mount the shares like you can with samba and nfs shares. But I assume that is out of scope for g-u-s. -- mvh Björn ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
