[arch-general] [OT] What is wrong with DBus anyway?
Hi, fellow archers. I've created a new email with a new subject, so that who wants to ignore this completely, can do it easily. The recent past discussions about DBus got me thinking about an unanswered question: what is technically wrong with DBus? After some time researching about that, I can't find that answer by myself. DBus is just a way to make applications communicate. It can be used in several languages, namely C, C++, Java, Perl, Python, Ruby, and many more. There are tools for it in bash, although there's some limitations with that, but is very easy to do something fast in python or perl or ruby or... It (DBus) has some interesting mechanisms to activate daemons just when needed. I find this feature very interesting, so that you only spend the resources when you really need. One restriction is that it is not network enabled, so it only works locally. But in the home page, there is a invitation to improve that situation (http://www.freedesktop.org/wiki/Software/DBusRemote). Anyway, I would like to read what others have to say about DBus, but please give techinical reasons. I don't want to know who likes and who dislikes DBus. And I don't have anything against who dislikes DBus. Everyone is entitled to an opinion. Thanks. -- R: Porque prejudica a legibilidade do texto. P: Porque é ruim colocar a resposta de um e-mail antes do texto citado? ------------------------------------------- Denis A. Altoe Falqueto -------------------------------------------
On Thu, Dec 3, 2009 at 11:06 AM, Denis A. Altoé Falqueto <denisfalqueto@gmail.com> wrote:
Hi, fellow archers.
I've created a new email with a new subject, so that who wants to ignore this completely, can do it easily.
The recent past discussions about DBus got me thinking about an unanswered question: what is technically wrong with DBus? After some time researching about that, I can't find that answer by myself.
DBus is just a way to make applications communicate. It can be used in several languages, namely C, C++, Java, Perl, Python, Ruby, and many more. There are tools for it in bash, although there's some limitations with that, but is very easy to do something fast in python or perl or ruby or...
It (DBus) has some interesting mechanisms to activate daemons just when needed. I find this feature very interesting, so that you only spend the resources when you really need.
One restriction is that it is not network enabled, so it only works locally. But in the home page, there is a invitation to improve that situation (http://www.freedesktop.org/wiki/Software/DBusRemote).
Anyway, I would like to read what others have to say about DBus, but please give techinical reasons. I don't want to know who likes and who dislikes DBus. And I don't have anything against who dislikes DBus. Everyone is entitled to an opinion.
Mechanisms have existed for like 20 years before dbus to communicate with other programs. dbus is just another way to do it that has a smell of "architecture astronomy" - as if they all scoffed at the actual ways to do IPC on various Unicies and said "Oh, I can design better". That's why I dislike it.
2009/12/3 Aaron Griffin <aaronmgriffin@gmail.com>:
On Thu, Dec 3, 2009 at 11:06 AM, Denis A. Altoé Falqueto <denisfalqueto@gmail.com> wrote:
Hi, fellow archers.
I've created a new email with a new subject, so that who wants to ignore this completely, can do it easily.
The recent past discussions about DBus got me thinking about an unanswered question: what is technically wrong with DBus? After some time researching about that, I can't find that answer by myself.
DBus is just a way to make applications communicate. It can be used in several languages, namely C, C++, Java, Perl, Python, Ruby, and many more. There are tools for it in bash, although there's some limitations with that, but is very easy to do something fast in python or perl or ruby or...
It (DBus) has some interesting mechanisms to activate daemons just when needed. I find this feature very interesting, so that you only spend the resources when you really need.
One restriction is that it is not network enabled, so it only works locally. But in the home page, there is a invitation to improve that situation (http://www.freedesktop.org/wiki/Software/DBusRemote).
Anyway, I would like to read what others have to say about DBus, but please give techinical reasons. I don't want to know who likes and who dislikes DBus. And I don't have anything against who dislikes DBus. Everyone is entitled to an opinion.
Mechanisms have existed for like 20 years before dbus to communicate with other programs. dbus is just another way to do it that has a smell of "architecture astronomy" - as if they all scoffed at the actual ways to do IPC on various Unicies and said "Oh, I can design better".
That's why I dislike it.
Hi, Aaron didn't give any tech reason in his answear, and i don't think someone will do, except the one you already said at your first e-mail(no network). People who don't like DBus find it just unecessary. I like DBus because I belive it unify the IPC in a way others methods can't. It's more a question of taste than tech. []'s -- Felipe de Oliveira Tanus E-mail: fotanus@gmail.com Blog: http://www.itlife.com.br Site: http://www.inf.ufrgs.br/~fotanus/ ----- "All we have to decide is what to do with the time that is given us." - Gandalf
On Thu, Dec 3, 2009 at 3:38 PM, Felipe Tanus <fotanus@gmail.com> wrote:
Aaron didn't give any tech reason in his answear, and i don't think someone will do, except the one you already said at your first e-mail(no network). People who don't like DBus find it just unecessary. I like DBus because I belive it unify the IPC in a way others methods can't. It's more a question of taste than tech.
That's what I fell too, though is a little early to jump to conclusions. The funny thing is that even who is not using a desktop can take advantage of a global bus for communication. And if it is standardized (even if a de facto standard), is good for everyone. It is sad, isn't it? -- A: Because it obfuscates the reading. Q: Why is top posting so bad? ------------------------------------------- Denis A. Altoe Falqueto -------------------------------------------
On Thu, Dec 3, 2009 at 7:42 PM, Denis A. Altoé Falqueto <denisfalqueto@gmail.com> wrote:
On Thu, Dec 3, 2009 at 3:38 PM, Felipe Tanus <fotanus@gmail.com> wrote:
Aaron didn't give any tech reason in his answear, and i don't think someone will do, except the one you already said at your first e-mail(no network). People who don't like DBus find it just unecessary. I like DBus because I belive it unify the IPC in a way others methods can't. It's more a question of taste than tech.
That's what I fell too, though is a little early to jump to conclusions.
The funny thing is that even who is not using a desktop can take advantage of a global bus for communication. And if it is standardized (even if a de facto standard), is good for everyone.
It is sad, isn't it?
-- A: Because it obfuscates the reading. Q: Why is top posting so bad?
------------------------------------------- Denis A. Altoe Falqueto -------------------------------------------
I don't think the recent flame-war revolves around Dbus beeing "evil" or technically unsuited. I've studied a little bit Dbus, and my opinions can be summarized as: * another way to do IPC, but oriented towards a Object-Oriented interface; (of course with the mandatory complex XML configuration;) * poorly documented; (I refer to libraries and bindings, tutorials, examples, etc.) * and maybe *abused* by almost every single desktop application; * finally adopted by more than a project (mostly Gnome / GTK related projects); (which is the biggest plus); Now I think that the recent rants were against this *abuse* of Dbus, than against the tool itself. By abuse I mean: most applications require (if enabled at compile time) for Dbus to be running (as a hard constraint), and break if it's not running or start the dbus process themselves. Ciprian.
Aaron Griffin wrote:
Mechanisms have existed for like 20 years before dbus to communicate with other programs.
and those don't require a user space daemon.
dbus is just another way to do it that has a smell of "architecture astronomy" - as if they all scoffed at the actual ways to do IPC on various Unicies and said "Oh, I can design better".
"Those who don't understand UNIX are condemned to reinvent it, poorly." – Henry Spencer
That's why I dislike it.
+1 I'll add some additional points: - it's implementation is large broken. - most software depending on it, will crash when dbus crashes, or fail to start uncracefully, or behave unexpected. - some systems are actually not supported by hal while they are by udev and have system-v IPCs. - reinventing the wheel and calling it super-boat-2000 isn't going to help anyone. Instead of fixing problems, people constantly create new ones. - FDO is hierarchic and polical level. Dbus is hierarchic on technical level. FDO wishes to provide a better experience to users by integrating all software nicely into one global truth. The Foss ecosystem is not hierarchic. The Foss ecosystem does not require a single truth to rule them all. The Foss ecosystem does not require to be competitive with OtherOs. -- Arvid Asgaard Technologies
On 03/12/09 18:14, Arvid Picciani wrote: [...]
I'll add some additional points: - it's implementation is large broken. how so? - most software depending on it, will crash when dbus file bug reports and get developers to write proper software. crashes, or fail to start uncracefully, or behave unexpected. i've honestly never seen dbus crash but then again i've experienced almost none of the issues people often complain about with Linux - some systems are actually not supported by hal while they are by udev and have system-v IPCs. got nothing to do with dbus - reinventing the wheel and calling it super-boat-2000 isn't going to help anyone. Instead of fixing problems, people constantly create new ones. lol - FDO is hierarchic and polical level. what Dbus is hierarchic on technical level. FDO wishes to provide a better experience to users by integrating all software nicely into one global truth. The Foss ecosystem is not hierarchic. The Foss ecosystem does not require a single truth to rule them all. The Foss ecosystem does not require to be competitive with OtherOs.
what does any of that have to do with dbus in a technical sense?
--
Arvid Asgaard Technologies
Nathan Wayde wrote:
what does any of that have to do with dbus in a technical sense?
There are multiple incorrect answers to this. I'm going to chicken out of this argument, until someone proofreads my essay on this topic. -- Arvid Asgaard Technologies
On Thursday 03 December 2009 12:19:58 and regarding:
On 03/12/09 18:14, Arvid Picciani wrote: [...]
I'll add some additional points: - it's implementation is large broken. how so? - most software depending on it, will crash when dbus file bug reports and get developers to write proper software. crashes, or fail to start uncracefully, or behave unexpected. i've honestly never seen dbus crash but then again i've experienced almost none of the issues people often complain about with Linux - some systems are actually not supported by hal while they are by udev and have system-v IPCs. got nothing to do with dbus - reinventing the wheel and calling it super-boat-2000 isn't going to help anyone. Instead of fixing problems, people constantly create new ones. lol - FDO is hierarchic and polical level. what Dbus is hierarchic on technical level. FDO wishes to provide a better experience to users by integrating all software nicely into one global truth. The Foss ecosystem is not hierarchic. The Foss ecosystem does not require a single truth to rule them all. The Foss ecosystem does not require to be competitive with OtherOs.
what does any of that have to do with dbus in a technical sense?
--
Arvid Asgaard Technologies
As for dbus or related processes crashing and causing fits, I don't know the precise cause, but I suspect an attempted save via sftp or fish on a dbus based app that sent my server into a tailspin (note, the offending connection was from openSuSE 11.2 not Arch). See the 'Nov 17 03:28:04' entries below: Nov 17 03:08:41 nirvana sshd[22185]: Accepted publickey for david from 192.168.6.102 port 59448 ssh2 Nov 17 03:08:46 nirvana su: (to root) david on /dev/pts/3 Nov 17 03:10:01 nirvana /usr/sbin/cron[23394]: (david) CMD (/home/david/linux/scripts/Learn_as_spam_cron) Nov 17 03:12:01 nirvana /usr/sbin/cron[23414]: (drr) CMD (/usr/local/bin/Learn_as_spam_cron) Nov 17 03:14:01 nirvana /usr/sbin/cron[23430]: (deborah) CMD (/usr/local/bin/Learn_as_spam_cron) Nov 17 03:16:01 nirvana /usr/sbin/cron[23489]: (zachry) CMD (/usr/local/bin/Learn_as_spam_cron) Nov 17 03:18:01 nirvana /usr/sbin/cron[24289]: (sydney) CMD (/usr/local/bin/Learn_as_spam_cron) Nov 17 03:18:29 nirvana dhcpd: Wrote 0 deleted host decls to leases file. Nov 17 03:18:29 nirvana dhcpd: Wrote 0 new dynamic host decls to leases file. Nov 17 03:18:29 nirvana dhcpd: Wrote 38 leases to leases file. Nov 17 03:20:00 nirvana dhcpd: DHCPREQUEST for 192.168.6.120 from 00:25:00:df:fe:2c (iPod-touch-2) via eth0 Nov 17 03:20:00 nirvana dhcpd: DHCPACK on 192.168.6.120 to 00:25:00:df:fe:2c (iPod-touch-2) via eth0 Nov 17 03:21:26 nirvana dhcpd: DHCPREQUEST for 192.168.6.120 from 00:25:00:df:fe:2c (iPod-touch-2) via eth0 Nov 17 03:21:26 nirvana dhcpd: DHCPACK on 192.168.6.120 to 00:25:00:df:fe:2c (iPod-touch-2) via eth0 Nov 17 03:24:11 nirvana dhcpd: DHCPREQUEST for 192.168.6.120 from 00:25:00:df:fe:2c (iPod-touch-2) via eth0 Nov 17 03:24:11 nirvana dhcpd: DHCPACK on 192.168.6.120 to 00:25:00:df:fe:2c (iPod-touch-2) via eth0 Nov 17 03:24:11 nirvana dhcpd: DHCPDISCOVER from 00:25:00:df:fe:2c (iPod-touch-2) via eth0 Nov 17 03:24:12 nirvana dhcpd: DHCPOFFER on 192.168.6.120 to 00:25:00:df:fe:2c (iPod-touch-2) via eth0 Nov 17 03:28:04 nirvana shadow[24998]: group already exists - group=ntadmin, by=0 Nov 17 03:28:04 nirvana dbus-daemon: Unable to reload configuration: Element <standard_system_servicedirs> not allowed inside <busconfig> in configuration file Nov 17 03:28:04 nirvana avahi-daemon[3764]: Disconnected from D-Bus, exiting. Nov 17 03:28:04 nirvana avahi-daemon[3764]: Got SIGQUIT, quitting. Nov 17 03:28:04 nirvana powersaved[4644]: ERROR (filter_function:98) DBus daemon disconnected. Trying to reconnect... Nov 17 03:28:04 nirvana avahi-daemon[3764]: Leaving mDNS multicast group on interface eth0.IPv4 with address 192.168.6.17. Nov 17 03:28:04 nirvana avahi-dnsconfd[3775]: read(): EOF Nov 17 03:28:07 nirvana console-kit-daemon[2480]: WARNING: Couldn't connect to system bus: Failed to connect to socket /var/run/dbus/system_bus_socket: Connection refused Nov 17 03:28:21 nirvana syslog-ng[2458]: last message repeated 4 times Nov 17 03:28:21 nirvana gconfd (david-1390): GConf server is not in use, shutting down. Nov 17 03:28:21 nirvana gconfd (david-1390): Error releasing lockfile: Failed to link '/tmp/gconfd-david/lock/1t1258450101ut827002u1000p1390r552977190k2414831832' to '/tmp/gconfd-david/lock/ior': No such file or directory Nov 17 03:28:21 nirvana gconfd (david-1390): Exiting Nov 17 03:28:22 nirvana console-kit-daemon[2480]: WARNING: Couldn't connect to system bus: Failed to connect to socket /var/run/dbus/system_bus_socket: Connection refused Nov 17 03:29:07 nirvana syslog-ng[2458]: last message repeated 15 times Nov 17 03:29:10 nirvana console-kit-daemon[2480]: WARNING: Couldn't connect to system bus: Failed to connect to socket /var/run/dbus/system_bus_socket: Connection refused Nov 17 03:30:07 nirvana syslog-ng[2458]: last message repeated 18 times Nov 17 03:30:07 nirvana console-kit-daemon[2480]: WARNING: Couldn't connect to system bus: Failed to connect to socket /var/run/dbus/system_bus_socket: Connection refused Nov 17 03:31:07 nirvana syslog-ng[2458]: last message repeated 20 times Nov 17 03:31:10 nirvana console-kit-daemon[2480]: WARNING: Couldn't connect to system bus: Failed to connect to socket /var/run/dbus/system_bus_socket: Connection refused Nov 17 03:32:07 nirvana syslog-ng[2458]: last message repeated 19 times Nov 17 03:32:09 nirvana dhcpd: DHCPREQUEST for 192.168.6.120 from 00:25:00:df:fe:2c (iPod-touch-2) via eth0 Nov 17 03:32:09 nirvana dhcpd: DHCPACK on 192.168.6.120 to 00:25:00:df:fe:2c (iPod-touch-2) via eth0 Nov 17 03:32:10 nirvana console-kit-daemon[2480]: WARNING: Couldn't connect to system bus: Failed to connect to socket /var/run/dbus/system_bus_socket: Connection refused Nov 17 03:33:07 nirvana syslog-ng[2458]: last message repeated 19 times Nov 17 03:33:10 nirvana console-kit-daemon[2480]: WARNING: Couldn't connect to system bus: Failed to connect to socket /var/run/dbus/system_bus_socket: Connection refused Nov 17 03:34:07 nirvana syslog-ng[2458]: last message repeated 19 times Nov 17 03:34:10 nirvana console-kit-daemon[2480]: WARNING: Couldn't connect to system bus: Failed to connect to socket /var/run/dbus/system_bus_socket: Connection refused Nov 17 03:35:07 nirvana syslog-ng[2458]: last message repeated 19 times Nov 17 03:35:10 nirvana console-kit-daemon[2480]: WARNING: Couldn't connect to system bus: Failed to connect to socket /var/run/dbus/system_bus_socket: Connection refused Nov 17 03:36:07 nirvana syslog-ng[2458]: last message repeated 19 times Nov 17 03:36:10 nirvana console-kit-daemon[2480]: WARNING: Couldn't connect to system bus: Failed to connect to socket /var/run/dbus/system_bus_socket: Connection refused Nov 17 03:37:07 nirvana syslog-ng[2458]: last message repeated 19 times Nov 17 03:37:10 nirvana console-kit-daemon[2480]: WARNING: Couldn't connect to system bus: Failed to connect to socket /var/run/dbus/system_bus_socket: Connection refused Nov 17 03:38:07 nirvana syslog-ng[2458]: last message repeated 18 times Nov 17 03:38:07 nirvana console-kit-daemon[2480]: WARNING: Couldn't connect to system bus: Failed to connect to socket /var/run/dbus/system_bus_socket: Connection refused Nov 17 03:39:07 nirvana syslog-ng[2458]: last message repeated 20 times Nov 17 03:39:10 nirvana console-kit-daemon[2480]: WARNING: Couldn't connect to system bus: Failed to connect to socket /var/run/dbus/system_bus_socket: Connection refused Nov 17 03:40:07 nirvana syslog-ng[2458]: last message repeated 19 times Nov 17 03:40:10 nirvana console-kit-daemon[2480]: WARNING: Couldn't connect to system bus: Failed to connect to socket /var/run/dbus/system_bus_socket: Connection refused Nov 17 03:40:57 nirvana syslog-ng[2458]: last message repeated 15 times Nov 17 03:40:57 nirvana named[4151]: client 192.168.6.149#51507: update '3111skyline.com/IN' denied Nov 17 03:40:58 nirvana console-kit-daemon[2480]: WARNING: Couldn't connect to system bus: Failed to connect to socket /var/run/dbus/system_bus_socket: Connection refused -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
On Thu, Dec 3, 2009 at 4:14 PM, Arvid Picciani <aep@exys.org> wrote: [...] Well, let's see: 1. DBus has an user space daemon I _think_ that this eases the transition of messages between the applications and the user space bus. This also happens with Jack Audio Connection Kit. Indeed, clients can't connect to it if the daemon is started by root and the clients are started by normal users. 2. Some applications don't work if DBus is not started. This is a possible bug in the application, is not a failure of DBus. Maybe the developers think that is not feasible to support more than one type of IPC mechanism, so they choose one and go with it. If you can convince them to use DBus optionally, and the features that depend on it can be simply turned off without the application losing too much, fine. I think that indeed that is the case with X server, isn't it? It is only a matter of configuring xorg.conf to disable it (maybe I'm confusing thing here). 4. There are other IPC mechanisms Yes, there are. But I think that each one has some drawbacks too. CORBA, for example, is too heavy for simple use (Gnome developers can tell a good story about that). XMLRPC needs a HTTP server or something like that and the overhead of the communication protocol is not very efficient for local use. Maybe there's another IPC mechanism that is good, but maybe it doesn't have everything that DBus have (for example, activation of daemons on demand). 5. DBus is hierarchical As is your filesystem too. There's a good reason for that. Hierarchy per se is not a bad thing and in DBus it is well used. It separates objects in categories, so that functions with different purposes don't get mixed in a big namespace. Maybe you don't like the Object Oriented nomenclature, but it doesn't need to be called like that. You think in modules, containers, categories, bags, whatever name carries the idea of a collection of related operations. The fact that it is implemented as an object or not is not important for the client and the provider of the service don't need to be an object. Thanks for the people who posted (and keep posting!). The discussion is interesting, even if just for the anthropological point of view. And I'm not yet convinced that DBus should not exist :) -- A: Because it obfuscates the reading. Q: Why is top posting so bad? ------------------------------------------- Denis A. Altoe Falqueto -------------------------------------------
On Thu, Dec 03, 2009 at 04:42:25PM -0200, Denis A. Altoé Falqueto wrote:
(...) 4. There are other IPC mechanisms
Yes, there are. But I think that each one has some drawbacks too. CORBA, for example, is too heavy for simple use (Gnome developers can tell a good story about that). XMLRPC needs a HTTP server or something like that and the overhead of the communication protocol is not very efficient for local use. Maybe there's another IPC mechanism that is good, but maybe it doesn't have everything that DBus have (for example, activation of daemons on demand).
(...)
I believe these aren't the 'other IPC mechanisms' they were talking about. What about FIFOs and sockets?
On Thu, Dec 3, 2009 at 4:53 PM, André Ramaciotti da Silva <andre.ramaciotti@gmail.com> wrote:
I believe these aren't the 'other IPC mechanisms' they were talking about. What about FIFOs and sockets?
In fact, DBus is implemented over Unix sockets. FIFOs and sockets don't define the format that will be used over them, they are just channels of communication. DBus is a wire protocol, as they say in the home page. It defines the format the methods and parameters should be converted to make the communication viable, as well as an event system so that applications can register interest in some activity. -- A: Because it obfuscates the reading. Q: Why is top posting so bad? ------------------------------------------- Denis A. Altoe Falqueto -------------------------------------------
On Thu, Dec 03, 2009 at 05:05:18PM -0200, Denis A. Altoé Falqueto wrote:
On Thu, Dec 3, 2009 at 4:53 PM, André Ramaciotti da Silva <andre.ramaciotti@gmail.com> wrote:
I believe these aren't the 'other IPC mechanisms' they were talking about. What about FIFOs and sockets?
In fact, DBus is implemented over Unix sockets. FIFOs and sockets don't define the format that will be used over them, they are just channels of communication. DBus is a wire protocol, as they say in the home page. It defines the format the methods and parameters should be converted to make the communication viable, as well as an event system so that applications can register interest in some activity.
-- A: Because it obfuscates the reading. Q: Why is top posting so bad?
------------------------------------------- Denis A. Altoe Falqueto -------------------------------------------
I didn't know that. Thanks for clarification. :)
On Thu, Dec 3, 2009 at 5:11 PM, André Ramaciotti da Silva <andre.ramaciotti@gmail.com> wrote:
I didn't know that. Thanks for clarification. :)
Actually, I'm mistaken about DBus using unix sockets. In fact, I'm not sure if it's true. I'm searching about it right now. -- A: Because it obfuscates the reading. Q: Why is top posting so bad? ------------------------------------------- Denis A. Altoe Falqueto -------------------------------------------
On Thu, Dec 3, 2009 at 5:14 PM, Denis A. Altoé Falqueto <denisfalqueto@gmail.com> wrote:
Actually, I'm mistaken about DBus using unix sockets. In fact, I'm not sure if it's true. I'm searching about it right now.
Indeed, I was right [1]. The default transport channel are Unix domain sockets, but there are unencrypted TCP/IP and a testing transport with in-process pipes. [1] http://dbus.freedesktop.org/doc/dbus-specification.html#transports -- A: Because it obfuscates the reading. Q: Why is top posting so bad? ------------------------------------------- Denis A. Altoe Falqueto -------------------------------------------
Le Thu, 3 Dec 2009 17:05:18 -0200, Denis A. Altoé Falqueto <denisfalqueto@gmail.com> a écrit :
In fact, DBus is implemented over Unix sockets. FIFOs and sockets don't define the format that will be used over them, they are just channels of communication. DBus is a wire protocol, as they say in the home page. It defines the format the methods and parameters should be converted to make the communication viable, as well as an event system so that applications can register interest in some activity.
I do not know how D-Bus works on the technical level, but as far as I understand D-Bus means many things and people mix them up. Here is what I understand. There is indeed a D-Bus protocol [1], and I don't see why anybody would be against that, because a protocol is a written document and not a piece of software: it doesn't enforce an implementation. Then, there is a library, libdbus, that implements that protocol. Note that it is not the only one, D-Bus's home page states that the implementations of D-Bus for Java, C# and Ruby do not rely on it. I don't think that's what everybody is targeting either. Finally, there is the D-Bus message bus daemon. The one you see in top, here: 3188 dbus 20 0 10664 1028 724 S 0 0.1 0:00.51 dbus-daemon Actually, there are multiple instances of the daemon running at the same time. Basically, what they do is route the D-Bus messages between the applications. This is what most people target, because it is an extra process running on their system. That being said, I am in favor of simplicity, I am even often called a minimalist, but I kind of like the idea of having a unified way to communicate between Unix applications. I even appreciate the fact that it relies on a daemon and not on an in-kernel thing but I am also fascinated by Minix3, so I have a bias towards putting everything in user space ;) I like D-Bus because it can actually simplify the applications that rely on it and avoid reiventing the wheel. But I do agree that applications that *don't* need to communicate with other applications have no reason to be linked against it! [1] http://dbus.freedesktop.org/doc/dbus-specification.html -- catwell
On Thu, 3 Dec 2009 20:32:46 +0000 Pierre Chapuis <catwell@archlinux.us> wrote:
There is indeed a D-Bus protocol [1], and I don't see why anybody would be against that, because a protocol is a written document and not a piece of software: it doesn't enforce an implementation.
protocols can be bloated and or badly designed. not saying dbus is, i have not enough experience with it. Dieter
On Thu, Dec 3, 2009 at 9:32 PM, Pierre Chapuis <catwell@archlinux.us> wrote:
I like D-Bus because it can actually simplify the applications that rely on it and avoid reiventing the wheel. But I do agree that applications that *don't* need to communicate with other applications have no reason to be linked against it!
Is there any application that actually does that ? Anyway, I don't think this is the most appropriate place to discuss dbus. And what I am going to say is mainly addressed to all the dbus/hal haters out there : If you want to be serious about it, go have a true technical discussion with the REAL developers who know the HOW and WHY of all these softwares. Otherwise you are just ignorant whiners talking to other ignorant people :) I would *LOVE* to see this Arvid genius proving to the dbus developers that their implementation is largely broken.
Le Thu, 3 Dec 2009 21:58:25 +0100, Xavier <shiningxc@gmail.com> a écrit :
On Thu, Dec 3, 2009 at 9:32 PM, Pierre Chapuis <catwell@archlinux.us> wrote:
I like D-Bus because it can actually simplify the applications that rely on it and avoid reiventing the wheel. But I do agree that applications that *don't* need to communicate with other applications have no reason to be linked against it!
Is there any application that actually does that ?
Take gedit for example. It is a text editor, and: [23:44 TA|catwell] ldd $(which gedit) | grep dbus libdbus-glib-1.so.2 => /usr/lib/libdbus-glib-1.so.2 (0x00007f5df48bb000) libdbus-1.so.3 => /usr/lib/libdbus-1.so.3 (0x00007f5df467c000) AFAIK it uses dbus only to communicate with itself (between its instances). There is no iteroperability problem, so D-Bus is not that useful to me. But then again, maybe I don't know how gedit works well enough to judge... -- catwell
Pierre Chapuis wrote:
Take gedit for example. It is a text editor, and:
[23:44 TA|catwell] ldd $(which gedit) | grep dbus libdbus-glib-1.so.2 => /usr/lib/libdbus-glib-1.so.2 (0x00007f5df48bb000) libdbus-1.so.3 => /usr/lib/libdbus-1.so.3 (0x00007f5df467c000)
AFAIK it uses dbus only to communicate with itself (between its instances). There is no iteroperability problem, so D-Bus is not that useful to me. But then again, maybe I don't know how gedit works well enough to judge...
funny thing: gedit is the first time i noticed the problem. then i went emacs, and now emacs depends on dbus. -- Arvid Asgaard Technologies
On Fri, 2009-12-04 at 00:52 +0100, Arvid Picciani wrote:
Pierre Chapuis wrote:
Take gedit for example. It is a text editor, and:
[23:44 TA|catwell] ldd $(which gedit) | grep dbus libdbus-glib-1.so.2 => /usr/lib/libdbus-glib-1.so.2 (0x00007f5df48bb000) libdbus-1.so.3 => /usr/lib/libdbus-1.so.3 (0x00007f5df467c000)
AFAIK it uses dbus only to communicate with itself (between its instances). There is no iteroperability problem, so D-Bus is not that useful to me. But then again, maybe I don't know how gedit works well enough to judge...
funny thing: gedit is the first time i noticed the problem. then i went emacs, and now emacs depends on dbus.
What does upstream have to say about this dependency? Does not seem 'necessary' to me, but depending on the app's structure the choice could be between:- a) some new feature which requires dbus b) not having the feature Which would then lead to the question whether the app's design allows dbus to be loaded only when necessary instead of linked at compile-time. I doubt many apps are designed to allow dbus to be used 'if and only if available' at run-time?
Ng Oon-Ee wrote:
have to say about this dependency?
what i didn't mention, but is apparantly nessesary, is that i was actually deep involved into the whole foodchain of kde and gnome before they started acting like kids and thought they need to copy windows for the greater good. The Gedit author failed to recognise the problem alltogether, even after explaining,... Does not seem
'necessary' to me, but depending on the app's structure the choice could be between:- a) some new feature which requires dbus b) not having the feature
.. that singleton patterns have been around for ages and have in fact nothing to do with dbus, doesnt depend on dbus, and is easier to implement without dbus.
Which would then lead to the question whether the app's design allows dbus to be loaded only when necessary instead of linked at compile-time.
It's a non technical issue. The patch is 4 lines.
I doubt many apps are designed to allow dbus to be used 'if and only if available' at run-time?
Its the general mindset that every each and one of us should be forced to accept the global thruth. -- Arvid Asgaard Technologies
Ng Oon-Ee wrote:
What does upstream have to say about this dependency? Does not seem 'necessary' to me
http://blogs.igalia.com/itoral/2006/03/30/adding-dbus-support-to-gedit/ priceless finding. let me sum up: " - There is feature X which works very well - He discovered it doesn't use dbus. - He starts work on a very complicated patch that makes it use dbus. " -- Arvid Asgaard Technologies
2009/12/4 Arvid Picciani <aep@exys.org>:
http://blogs.igalia.com/itoral/2006/03/30/adding-dbus-support-to-gedit/
priceless finding.
let me sum up: " - There is feature X which works very well - He discovered it doesn't use dbus. - He starts work on a very complicated patch that makes it use dbus.
As I understand it, the complexity was related to the fact that GEdit didn't had DBus support. Of course the first patch will be "complex" and replace a "working functionality", but for now on, GEdit can expose events and functions to _any_ other application through DBus. Just because nobody is using right now, doesn't mean that it will never be useful. -- A: Because it obfuscates the reading. Q: Why is top posting so bad? ------------------------------------------- Denis A. Altoe Falqueto -------------------------------------------
Denis A. Altoé Falqueto wrote:
2009/12/4 Arvid Picciani <aep@exys.org>:
http://blogs.igalia.com/itoral/2006/03/30/adding-dbus-support-to-gedit/
priceless finding.
let me sum up: " - There is feature X which works very well - He discovered it doesn't use dbus. - He starts work on a very complicated patch that makes it use dbus.
As I understand it, the complexity was related to the fact that GEdit didn't had DBus support. Of course the first patch will be "complex" and replace a "working functionality", but for now on, GEdit can expose events and functions to _any_ other application through DBus. Just because nobody is using right now, doesn't mean that it will never be useful.
Correct me if i'm wrong, but i read that as: " - THe argument is valid - but irrelevant because the positive side is some feature no one needs. " -- Arvid Asgaard Technologies
On Fri, Dec 4, 2009 at 12:49 AM, Arvid Picciani <aep@exys.org> wrote:
Correct me if i'm wrong, but i read that as:
" - THe argument is valid - but irrelevant because the positive side is some feature no one needs. "
You're clearly putting words in my mouth. I didn't said your argument was valid, rather the contrary. I showed why I think your argument is _invalid_.. The functionality was not lost and there are advantages now, without any new disadvantage (because DBus is not inefficient). The solution they had before was not standard (every app can have a different one) and the burden to maintain it was on the shoulder of the developer. Now they have the same functionality with a general purpose solution that allows other uses, yet not envisioned, but valid anyway. So why is that so hard to understand? Or you just don't want to. -- A: Because it obfuscates the reading. Q: Why is top posting so bad? ------------------------------------------- Denis A. Altoe Falqueto -------------------------------------------
On Friday 04 December 2009 08:08:03 Arvid Picciani wrote:
Ng Oon-Ee wrote:
What does upstream have to say about this dependency? Does not seem 'necessary' to me
http://blogs.igalia.com/itoral/2006/03/30/adding-dbus-support-to-gedit/
priceless finding.
let me sum up: " - There is feature X which works very well - He discovered it doesn't use dbus. - He starts work on a very complicated patch that makes it use dbus.
<more OT> Why would gedit need to support dbus? AFAIK, KDE supports these things in kdelibs and everybody on top just has everything kdelibs support say new kio slaves. one more reason not to use gnome. for dbus, IMO it just adds a protocol on top of it. Warranted or not aside, XML is not unixy enough anyways. My prediction is world would reinvent CORBA functionally and would refuse to call/recognise it as such. It will be only a decade late. DCOP was invented by KDE because CORBA was too heavy locally(at least thats a technical reason). dbus is succesor of dcop because gnome couldn't use dcop. I hate gnome for the ideas it represents. "Application foo got y pixel spacing between icons" can't be a feature item in relase in 200x. Its just sad design. </more OT> -- Shridhar
On Fri, 2009-12-04 at 03:38 +0100, Arvid Picciani wrote:
Ng Oon-Ee wrote:
What does upstream have to say about this dependency? Does not seem 'necessary' to me
http://blogs.igalia.com/itoral/2006/03/30/adding-dbus-support-to-gedit/
priceless finding.
let me sum up: " - There is feature X which works very well - He discovered it doesn't use dbus. - He starts work on a very complicated patch that makes it use dbus.
Let's sum up: - there's a feature using a deprecated library (bacon uses the bonobo-activation framework) - he discovered the new way to do these things is by replacing it by dbus - he starts work on something that replaces bacon/bonobo and uses dbus Really, you're just having a 100% anti-dbus attitude, but somehow you're fine with Bonobo. Maybe you didn't know, but Bonobo is worse than dbus. It's a complicated slow framework with a lot of design mistakes. The problem with dbus here is that Bonobo was matured, dbus is quite young. Dbus was lacking some features in the beginning, causing nasty regressions. One example was the lack of possibility to pass environment variables to a dbus-launched application. I don't know if this is possible already, but I think they worked around the limitation by not using environment variables for such stuff anymore. Note that a lot of work has been duplicated in applications when they were ported to single-instance applications using dbus. This has been fixed by using the libunique library. At this moment anjuta, brasero, devhelp, gnome-bluetooth, gnome-control-center, gnome-disk-utility, gnome-power-manager, nautilus and totem use this library for their single-instance functionality. Gedit uses its own complicated way and should switch to this library also if possible.
Sounds like either this discussion is worth discussing again. I'll try hard not to trip anyone... Jan de Groot wrote:
Really, you're just having a 100% anti-dbus attitude, but somehow you're fine with Bonobo. Maybe you didn't know, but Bonobo is worse than dbus. It's a complicated slow framework with a lot of design mistakes.
I honestly had no idea what it is. Looks like the ignorance goes both ways.
I think that is because emacs decided to be an operating system instead of a text editor. Seriously, when I read the last release notes, I though: "WTF does a text editor need dns-sd for?"
That' why fellow minimalists use vim, and call me a whiner. heh. Yeah, there is worse people then me... On a related note, i had now contact with lots of people of the OTHER side of the argument, ie the minimalists, off list. Sorry to say, they're even more retarded, in that some even think glibc should be removed ( and replaced with _what_? ) or that they think dbus should be removed but then whine about their gui breaking (dude, whats your point?). Additionaly i researched on some market players behind dbus. Besides the smell of money and taste of blood, there are some professional people behind this, who may have an agenda hostile to some people, but they get stuff done. And whoever gets stuff done, wins in FOSS world. It's that easy, and i have no objection to easy politics.
Note that a lot of work has been duplicated in applications when they were ported to single-instance applications using dbus.
Err. 10 lines of code? I don't even want to know how much code duplication dbus type system implies. But yeah depend on how you argue. - dbus vs some other non unified crap that does basicly the same: clear that dbus wins, since code duplication can't be any useful. - dbus vs system v ipc clear that system v wins, since it worked 20 years ago, still does and is ridiculously simple. Similar some people here have argued that compared to ubuntu, archlinux is pretty unix. Well compared to ubuntu, everything wins. That's not fair :P
This has been fixed by using the libunique library.
Which could use standard mechanics instead of something unrelated like dbus. But i'm glad they abstracted that into a library, so it can be replaced with 10 lines of system v ipc code. I should propably smack some upstream people on that one next fosdem. Everyone doing their own dbus code and then realizing it breaks would have been a serious facepalm, considered that this is exactly what people trip on who remember corba. Seriously guys, can we PLEASE at least avoid doing the same mistakes again? corba sucks, and anyone disagreeing please instantly press the kill button on your MUA, or just shoot yourself. University here is inventing an object rpc for java right now, and its just corba restricted to java. I'm so raging on peoples inability to see past mistakes. At this moment anjuta, brasero,
devhelp, gnome-bluetooth, gnome-control-center, gnome-disk-utility, gnome-power-manager, nautilus and totem use this library for their single-instance functionality.
I'm totally fine with that. I never objected to gnome using d-bus. They have a valid reason to do so. The problem is, they don't have a valid reason to force everyone else to use it.
Gedit uses its own complicated way and should switch to this library also if possible.
I have used gedit, but that's my own damn fault. It's all the upstream who's been stupid.
You're talking crap. Examples of other IPC frameworks are bonobo and dcop. Both launched the daemon on initial usage.
Well here is your part of the ignorance. You're as much qualified to talk about unix, as i am to talk about gnome. This isn't going to lead anywhere unless you do your homework.
Dbus also launches a sesion bus when it's needed, but for the system bus, things are different. You can't run a system bus as normal user, unless you install dbus as setuid root and make some code to launch the system bus on request.
I have to understand the obcurity behind all this. Why can't they use unix sessions? What's a system bus and why can't they use system v for that? But well, here's my part of the ignorance again. I don't even want to know what kind of ugly code they all ran before dbus. I've seen dcop and actually liked it. As long i could just kill it and things still worked (well kde tripped on it i think, but thats irrelevant to me)
xfce terminal has a patch in our svn for it.
I so raged on that. I mean, its a terminal... thankfully there is urxvt.
I don't mind if xfce terminal can't open new tabs or windows when dbus goes down, but please don't kill the ones that are open.
Well even then, how are you supposed to fix the problem when you can't open a terminal? I mean, if you're a kde user, you can't - open a terminal, since the terminal needs dbus - open the menu to open xterm, since the menu needs dbus - kill X because they disabled that, and only us old timers enable it. and if you're really unlucky you get dbus to crash hal to crash your gfx driver, so your only option left is the power button. This is a valid reason why i call people windows users. I can't see anyone capable of staying calm in such a situation unless they were forced to use windows in life, and are just happy linux doesn't spit fire. There were times where we laughed at DOS beeing a cripeled fake copy of an OS. And then they won. for some yet to discover reason. Maybe they invoked godwin. -- Arvid Asgaard Technologies
On 04/12/09 18:49, Arvid Picciani wrote:
Sounds like either this discussion is worth discussing again. I'll try hard not to trip anyone...
Jan de Groot wrote:
Really, you're just having a 100% anti-dbus attitude, but somehow you're fine with Bonobo. Maybe you didn't know, but Bonobo is worse than dbus. It's a complicated slow framework with a lot of design mistakes.
I honestly had no idea what it is. Looks like the ignorance goes both ways.
I think that is because emacs decided to be an operating system instead of a text editor. Seriously, when I read the last release notes, I though: "WTF does a text editor need dns-sd for?"
That' why fellow minimalists use vim, and call me a whiner. heh. Yeah, there is worse people then me... On a related note, i had now contact with lots of people of the OTHER side of the argument, ie the minimalists, off list. Sorry to say, they're even more retarded, in that some even think glibc should be removed ( and replaced with _what_? ) or that they think dbus should be removed but then whine about their gui breaking (dude, whats your point?). Additionaly i researched on some market players behind dbus. Besides the smell of money and taste of blood, there are some professional people behind this, who may have an agenda hostile to some people, but they get stuff done. And whoever gets stuff done, wins in FOSS world. It's that easy, and i have no objection to easy politics.
Note that a lot of work has been duplicated in applications when they were ported to single-instance applications using dbus.
Err. 10 lines of code? I don't even want to know how much code duplication dbus type system implies. But yeah depend on how you argue.
- dbus vs some other non unified crap that does basicly the same: clear that dbus wins, since code duplication can't be any useful.
- dbus vs system v ipc clear that system v wins, since it worked 20 years ago, still does and is ridiculously simple.
Similar some people here have argued that compared to ubuntu, archlinux is pretty unix. Well compared to ubuntu, everything wins. That's not fair :P
This has been fixed by using the libunique library.
Which could use standard mechanics instead of something unrelated like dbus. But i'm glad they abstracted that into a library, so it can be replaced with 10 lines of system v ipc code. I should propably smack some upstream people on that one next fosdem. Everyone doing their own dbus code and then realizing it breaks would have been a serious facepalm, considered that this is exactly what people trip on who remember corba. Seriously guys, can we PLEASE at least avoid doing the same mistakes again? corba sucks, and anyone disagreeing please instantly press the kill button on your MUA, or just shoot yourself. University here is inventing an object rpc for java right now, and its just corba restricted to java. I'm so raging on peoples inability to see past mistakes.
At this moment anjuta, brasero,
devhelp, gnome-bluetooth, gnome-control-center, gnome-disk-utility, gnome-power-manager, nautilus and totem use this library for their single-instance functionality.
I'm totally fine with that. I never objected to gnome using d-bus. They have a valid reason to do so. The problem is, they don't have a valid reason to force everyone else to use it.
Gedit uses its own complicated way and should switch to this library also if possible.
I have used gedit, but that's my own damn fault. It's all the upstream who's been stupid.
You're talking crap. Examples of other IPC frameworks are bonobo and dcop. Both launched the daemon on initial usage.
Well here is your part of the ignorance. You're as much qualified to talk about unix, as i am to talk about gnome. This isn't going to lead anywhere unless you do your homework.
Dbus also launches a sesion bus when it's needed, but for the system bus, things are different. You can't run a system bus as normal user, unless you install dbus as setuid root and make some code to launch the system bus on request.
I have to understand the obcurity behind all this. Why can't they use unix sessions? What's a system bus and why can't they use system v for that? But well, here's my part of the ignorance again. I don't even want to know what kind of ugly code they all ran before dbus. I've seen dcop and actually liked it. As long i could just kill it and things still worked (well kde tripped on it i think, but thats irrelevant to me)
xfce terminal has a patch in our svn for it.
I so raged on that. I mean, its a terminal... thankfully there is urxvt.
I don't mind if xfce terminal can't open new tabs or windows when dbus goes down, but please don't kill the ones that are open.
Well even then, how are you supposed to fix the problem when you can't open a terminal? I mean, if you're a kde user, you can't - open a terminal, since the terminal needs dbus - open the menu to open xterm, since the menu needs dbus - kill X because they disabled that, and only us old timers enable it.
and if you're really unlucky you get dbus to crash hal to crash your gfx driver, so your only option left is the power button. This is a valid reason why i call people windows users. I can't see anyone capable of staying calm in such a situation unless they were forced to use windows in life, and are just happy linux doesn't spit fire. There were times where we laughed at DOS beeing a cripeled fake copy of an OS. And then they won. for some yet to discover reason. Maybe they invoked godwin.
I'm confused. You openly admit you don't know much about dbus or how it works and yet you continue... for the record I'm one of those people that re-enable the ctrl+alt [backspace] X kill functionality and I assure you I'm not pure enough to be a part of your minimalists... In the event that dbus crashes and I can't open a terminal I do what any other non-pretensious Linux user wold do, I ctrl+alt F1..F6 and fix shit that needs fixing. Maybe you just forgot, maybe you were just looking for an argument, maybe you're actually a *nix fanboy who feel that you're too elite poorly Windows users.
Arvid Picciani wrote:
Sounds like either this discussion is worth discussing again.
i forgot to add: "or you're a rare exception, Jan." thanks for at least trying to see the point here, much aprechiated. i hope others follow. -- Arvid Asgaard Technologies
On Fri, 04 Dec 2009 20:07:24 +0100 Arvid Picciani <aep@exys.org> wrote:
Arvid Picciani wrote:
Sounds like either this discussion is worth discussing again.
i forgot to add: "or you're a rare exception, Jan." thanks for at least trying to see the point here, much aprechiated. i hope others follow.
I can't believe this... Look, what do you hope to achieve here? To convince everyone that dbus is evil and should be purged from Arch? What will that accomplished? As Judd have said, Arch Linux is what you make it. You don't like dbus. Fine. We get it. Believe me we really do. Don't use it if you don't want to then. It's _your_ Arch after all, do whatever you like with it and let us do whatever we want to ours. You've already started your own project, that Arch Antidesktop or whatever. Wouldn't it be more productive to spend your time on that instead of here arguing around in circle? Sorry for being OT, won't happen again.
On Fri, 2009-12-04 at 19:49 +0100, Arvid Picciani wrote:
and if you're really unlucky you get dbus to crash hal to crash your gfx driver, so your only option left is the power button.
Please don't post things you haven't looked into. Hal has nothing to do with your gfx driver, as gfx drivers are probed by xorg itself using the libpciaccess library. The only things managed by hal/dbus in xorg are input devices.
Correct me if I am wrong here, but the objective of dbus/ipc is to vastly simplify programming -- suppose you need to write a program which opens document in gedit as one of the steps.... He doesn't need to know about the command line flags of gedit.By having a single interface like dbus, it simplifies his task. Also one more thing, ipc interface like dbus is preserved across versions, whereas the cli flags can change. It is more like interface in object technology where interface remains same but underlying implementation can change(and shouldn't matter to you). I think dbus brings all those OOPs to larger level. I largely think people here are also OOP vs normal procedural (or C vs C++). It is like C++ is slower than C(but there is some advantage also) On Sat, Dec 5, 2009 at 5:04 AM, Jan de Groot <jan@jgc.homeip.net> wrote:
On Fri, 2009-12-04 at 19:49 +0100, Arvid Picciani wrote:
and if you're really unlucky you get dbus to crash hal to crash your gfx driver, so your only option left is the power button.
Please don't post things you haven't looked into. Hal has nothing to do with your gfx driver, as gfx drivers are probed by xorg itself using the libpciaccess library. The only things managed by hal/dbus in xorg are input devices.
Le Sat, 05 Dec 2009 00:34:59 +0100, Jan de Groot <jan@jgc.homeip.net> a écrit :
Please don't post things you haven't looked into. Hal has nothing to do with your gfx driver, as gfx drivers are probed by xorg itself using the libpciaccess library. The only things managed by hal/dbus in xorg are input devices.
By the way, for those who wanted an example of something broken, I'm not sure but I think this might be related: http://bugs.archlinux.org/task/17380 -- catwell
On 12/04/2009 07:24 AM, Jan de Groot wrote:
On Fri, 2009-12-04 at 03:38 +0100, Arvid Picciani wrote:
Ng Oon-Ee wrote:
What does upstream have to say about this dependency? Does not seem 'necessary' to me
http://blogs.igalia.com/itoral/2006/03/30/adding-dbus-support-to-gedit/
priceless finding.
let me sum up: " - There is feature X which works very well - He discovered it doesn't use dbus. - He starts work on a very complicated patch that makes it use dbus.
Let's sum up:
- there's a feature using a deprecated library (bacon uses the bonobo-activation framework) - he discovered the new way to do these things is by replacing it by dbus - he starts work on something that replaces bacon/bonobo and uses dbus
Yup. I was just about to say the same thing. Replacing a non-standard messaging library with dbus - which is effectively now the new standard messaging library, used in numerous apps & daemons - sounds sensible to me. In other words: this isn't a matter of "why does gedit need dbus", but rather "why does gedit need to use a messaging library at all"? The answer to *that* question, as he wrote, is so that "when you start a second Gedit process, it opens a new tab in your current Gedit window instead of creating a new one". Perhaps this feature didn't need to be implemented using a messaging library. But perhaps that did make the most sense for a number of reasons. I really don't know. And frankly, neither do you. As you're not a gedit developer, I really can't put much trust in your opinion on this issue. DR
On Fri, Dec 04, 2009 at 02:09:49PM -0500, David Rosenstrauch wrote:
The answer to *that* question, as he wrote, is so that "when you start a second Gedit process, it opens a new tab in your current Gedit window instead of creating a new one".
And why should that happen at all ? If I wanted a new tab in the current Gedit window then I'd use whatever controls Gedit provides to get one. And to be able to do that Gedit doesn't need any IPC at all. If I start a new process that means I want I new window. Ciao, -- FA Wie der Mond heute Nacht aussieht ! Ist es nicht ein seltsames Bild ?
On 12/04/2009 03:50 PM, fons@kokkinizita.net wrote:
On Fri, Dec 04, 2009 at 02:09:49PM -0500, David Rosenstrauch wrote:
The answer to *that* question, as he wrote, is so that "when you start a second Gedit process, it opens a new tab in your current Gedit window instead of creating a new one".
And why should that happen at all ? If I wanted a new tab in the current Gedit window then I'd use whatever controls Gedit provides to get one. And to be able to do that Gedit doesn't need any IPC at all. If I start a new process that means I want I new window.
Ciao,
Perhaps there's a configuration setting that lets you toggle this? I really don't know. Under KDE some editors have this behavior on by default (Kate) while others don't have it at all (Kedit/Kwrite). But this is besides the point. There's legitimate functionality here that requires the use of dbus (or something similar). Whether you personally *like* that functionality is a separate issue. DR
On Fri, Dec 04, 2009 at 04:02:06PM -0500, David Rosenstrauch wrote:
But this is besides the point. There's legitimate functionality here that requires the use of dbus (or something similar). Whether you personally *like* that functionality is a separate issue.
It is not beside the point. To create a new tab, just provide a 'New Tab' button. Or have tabs from the start and label the next free one '+'. It doesn't require IPC at all. Ciao, -- FA Wie der Mond heute Nacht aussieht ! Ist es nicht ein seltsames Bild ?
Am Fri, 4 Dec 2009 22:11:08 +0100 schrieb fons@kokkinizita.net:
It is not beside the point. To create a new tab, just provide a 'New Tab' button. Or have tabs from the start and label the next free one '+'. It doesn't require IPC at all.
You're not forced to using gedit. If you don't like gedit use mousepad. Oh, you can't do that. It's evil WIMP, it can be used with the mouse. Then just use nano. Ok, not really. Nano depends on glibc, ncurses and texinfo. So it's not enough minimalism. Your ultimate text editor: echo "..." > textfile But this also depends on glibc. So, sorry, I only now such bloated text editors. Heiko
On Fri, Dec 04, 2009 at 10:55:32PM +0100, Heiko Baums wrote:
Am Fri, 4 Dec 2009 22:11:08 +0100 schrieb fons@kokkinizita.net:
It is not beside the point. To create a new tab, just provide a 'New Tab' button. Or have tabs from the start and label the next free one '+'. It doesn't require IPC at all.
You're not forced to using gedit.
THAT is completely irrelevant. I never claimed to be forced to use it. The point is that you can allow a user to have multiple tabs by providing an interface to request a new tab. This still leaves the user the choice not to have new tab by starting a new instance instead of using the new tab option. Providing this does not require IPC. Instead of this, you prefer to limit the user's choice by creating a new tab even if the user starts a new instance. This removes a valuable choice. What is the rationale for doing this ? What is the rationale for forcing a single instance, apart from having a reason to use IPC ? Ciao, -- FA Wie der Mond heute Nacht aussieht ! Ist es nicht ein seltsames Bild ?
Am Fri, 4 Dec 2009 23:38:02 +0100 schrieb fons@kokkinizita.net:
THAT is completely irrelevant. I never claimed to be forced to use it.
THAT is completely relevant. You don't want a text editor which uses IPC so don't use one.
The point is that you can allow a user to have multiple tabs by providing an interface to request a new tab. This still leaves the user the choice not to have new tab by starting a new instance instead of using the new tab option. Providing this does not require IPC.
And what? The gedit devs want to use IPC and they likely have reasons for this. If you don't like this don't use gedit or file a bug report to gedit upstream.
Instead of this, you prefer to limit the user's choice by creating a new tab even if the user starts a new instance. This removes a valuable choice.
This is indeed a valuable choice, choosing between opening a new instance which requires more resources than opening a new tab which requires less resources. I bet you can configure if a text file should be opened in a new instance or in a new tab. Otherwise don't click on the new tab but start a new instance. Other option: Use mousepad. It can only handle one file at a time. Every file is opened in a separate instance. Or use nano, also no multi-file editor. And there's still echo. Which choice is removed by gedit? Heiko
gedit --help shows --new-window. I don't see what issue is.... Dwight On Fri, Dec 4, 2009 at 5:07 PM, Heiko Baums <lists@baums-on-web.de> wrote:
Am Fri, 4 Dec 2009 23:38:02 +0100 schrieb fons@kokkinizita.net:
THAT is completely irrelevant. I never claimed to be forced to use it.
THAT is completely relevant. You don't want a text editor which uses IPC so don't use one.
The point is that you can allow a user to have multiple tabs by providing an interface to request a new tab. This still leaves the user the choice not to have new tab by starting a new instance instead of using the new tab option. Providing this does not require IPC.
And what? The gedit devs want to use IPC and they likely have reasons for this. If you don't like this don't use gedit or file a bug report to gedit upstream.
Instead of this, you prefer to limit the user's choice by creating a new tab even if the user starts a new instance. This removes a valuable choice.
This is indeed a valuable choice, choosing between opening a new instance which requires more resources than opening a new tab which requires less resources. I bet you can configure if a text file should be opened in a new instance or in a new tab. Otherwise don't click on the new tab but start a new instance.
Other option: Use mousepad. It can only handle one file at a time. Every file is opened in a separate instance.
Or use nano, also no multi-file editor. And there's still echo.
Which choice is removed by gedit?
Heiko
On 12/04/2009 04:11 PM, fons@kokkinizita.net wrote:
On Fri, Dec 04, 2009 at 04:02:06PM -0500, David Rosenstrauch wrote:
But this is besides the point. There's legitimate functionality here that requires the use of dbus (or something similar). Whether you personally *like* that functionality is a separate issue.
It is not beside the point. To create a new tab, just provide a 'New Tab' button. Or have tabs from the start and label the next free one '+'. It doesn't require IPC at all.
Ciao,
Here's a common use case (and probably the reason why that feature got added in the first place): You're looking through your file manager at a directory full of text documents, and you double-click on whole a bunch of them to edit them in gedit. It would be nice if they all opened in the same editor instance (i.e., in a new tab), rather than having dozens of separate editor windows open up. (I use this functionality all the time, and find it very helpful.) Having a "New Tab" button doesn't solve this problem at all. The only thing that does solve it is the ability for an existing gedit window be able to get notified about the "open another document" request. And that requires dbus (or similar) to make it happen. So again, there's a legitimate feature here that requires the dbus dependency. If you don't need or want that feature, or don't use a GUI file manager, or feel that gedit is "bloated" because of this, yada yada, then by all means choose a different editor. There's loads of them - as I'm sure you're aware - and I'm sure there's at least one that doesn't have a dbus dependency. But frankly when you wrote that gedit shouldn't "require IPC at all" it seems to me that what you really mean is "gedit isn't minimalist enough for me" since it provides a bunch of features that you don't need/want. DR
On Fri, Dec 4, 2009 at 10:59 PM, David Rosenstrauch <darose@darose.net> wrote:
Here's a common use case (and probably the reason why that feature got added in the first place):
You're looking through your file manager at a directory full of text documents, and you double-click on whole a bunch of them to edit them in gedit. It would be nice if they all opened in the same editor instance (i.e., in a new tab), rather than having dozens of separate editor windows open up. (I use this functionality all the time, and find it very helpful.)
Having a "New Tab" button doesn't solve this problem at all. The only thing that does solve it is the ability for an existing gedit window be able to get notified about the "open another document" request. And that requires dbus (or similar) to make it happen.
Oh, I did not realize that. I have always found that issue to be a big flaw of gui file managers. So that's the whole point of single instance application and libunique [1] that JGC just mentioned. Of course :) But so it actually means that every application that you can potentially launch on multiple files (from a file manager) would benefit from using libunique (which implies dbus)... or the equivalent functionality on top of dbus... or the equivalent functionality without using a standard interface which would be a big mess ? If I got that right, I find it quite funny and ironical that a clueless and endless ranting about dbus ended up making me understand the coolness of dbus. [1] http://live.gnome.org/LibUnique
Xavier wrote:
On Fri, Dec 4, 2009 at 10:59 PM, David Rosenstrauch <darose@darose.net> wrote:
Here's a common use case (and probably the reason why that feature got added in the first place):
You're looking through your file manager at a directory full of text documents, and you double-click on whole a bunch of them to edit them in gedit. It would be nice if they all opened in the same editor instance (i.e., in a new tab), rather than having dozens of separate editor windows open up. (I use this functionality all the time, and find it very helpful.)
Having a "New Tab" button doesn't solve this problem at all. The only thing that does solve it is the ability for an existing gedit window be able to get notified about the "open another document" request. And that requires dbus (or similar) to make it happen.
Oh, I did not realize that. I have always found that issue to be a big flaw of gui file managers. So that's the whole point of single instance application and libunique [1] that JGC just mentioned. Of course :) But so it actually means that every application that you can potentially launch on multiple files (from a file manager) would benefit from using libunique (which implies dbus)... or the equivalent functionality on top of dbus... or the equivalent functionality without using a standard interface which would be a big mess ?
If I got that right, I find it quite funny and ironical that a clueless and endless ranting about dbus ended up making me understand the coolness of dbus.
Well, at least something came out of this thread...
Le Fri, 4 Dec 2009 23:26:27 +0100, Xavier <shiningxc@gmail.com> a écrit :
If I got that right, I find it quite funny and ironical that a clueless and endless ranting about dbus ended up making me understand the coolness of dbus.
I agree, it sounds cool, but then I thought: web browsers have been doing that for years. Then comes Google Chrome, which uses a new process for each tab to increase stability, and most people love it. I say maybe we need design patterns on that issue ;) -- catwell
On Fri, Dec 04, 2009 at 04:59:10PM -0500, David Rosenstrauch wrote:
But frankly when you wrote that gedit shouldn't "require IPC at all" it seems to me that what you really mean is "gedit isn't minimalist enough for me" since it provides a bunch of features that you don't need/want.
What 'seems to you' is a creation of your mind, nothing more. It has no relation at all to what I mean, and therefore it's irrelevant. Ciao, -- FA Wie der Mond heute Nacht aussieht ! Ist es nicht ein seltsames Bild ?
On Fri, 2009-12-04 at 00:52 +0100, Arvid Picciani wrote:
Pierre Chapuis wrote:
Take gedit for example. It is a text editor, and:
[23:44 TA|catwell] ldd $(which gedit) | grep dbus libdbus-glib-1.so.2 => /usr/lib/libdbus-glib-1.so.2 (0x00007f5df48bb000) libdbus-1.so.3 => /usr/lib/libdbus-1.so.3 (0x00007f5df467c000)
AFAIK it uses dbus only to communicate with itself (between its instances). There is no iteroperability problem, so D-Bus is not that useful to me. But then again, maybe I don't know how gedit works well enough to judge...
funny thing: gedit is the first time i noticed the problem. then i went emacs, and now emacs depends on dbus.
I think that is because emacs decided to be an operating system instead of a text editor. Seriously, when I read the last release notes, I though: "WTF does a text editor need dns-sd for?". Seems they implemented that functionality through dbus, which is the only way to communicate with Avahi (actually the avahi client libs do it for you). I always thought GNU was about one tool - one job, but then they violated that by building emacs.
Jan de Groot schreef: [...]
I always thought GNU was about one tool - one job, but then they violated that by building emacs.
Actually, one tool for one job is a Unix statement and dates from (long) before GNU: <quote [1]> (i) Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new features. [...] This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface. </quote> ;) [1] Basics of the Unix Philosophy http://www.faqs.org/docs/artu/ch01s06.html A very nice document by the way, especially for the 'younger' ones among us. mvg, Guus
On Thu, Dec 3, 2009 at 4:14 PM, Arvid Picciani <aep@exys.org> wrote:
Aaron Griffin wrote: "Those who don't understand UNIX are condemned to reinvent it, poorly." – Henry Spencer
"And those who do understand it are doomed to implement it right, that's why there is Plan 9." - Me. :) (For those who don't know, Plan 9 was made by the some of people who created Unix.) Linux is not Unix, it is a clone. We don't need to be eternally tied to historical ideas from the 70's and early 80's. Unix is not a perfect system, there's no such thing, by the way. We should be struggling to evolve it so that we have less work maintaining it, without losing the strong technical foundation that we all love. Our time is way precious to spend in configuration files that could be easily discovered by the system. I agree, though, that should be some way to manual tweaking, if needed so. -- A: Because it obfuscates the reading. Q: Why is top posting so bad? ------------------------------------------- Denis A. Altoe Falqueto -------------------------------------------
Le Thu, 3 Dec 2009 20:41:26 -0200, Denis A. Altoé Falqueto <denisfalqueto@gmail.com> a écrit :
On Thu, Dec 3, 2009 at 4:14 PM, Arvid Picciani <aep@exys.org> wrote:
Aaron Griffin wrote: "Those who don't understand UNIX are condemned to reinvent it, poorly." – Henry Spencer
"And those who do understand it are doomed to implement it right, that's why there is Plan 9." - Me.
:) (For those who don't know, Plan 9 was made by the some of people who created Unix.)
By the way, we could have both: http://www.glendix.org/ -- catwell
On Thu, 3 Dec 2009 22:58:08 +0000 Pierre Chapuis <catwell@archlinux.us> wrote:
Le Thu, 3 Dec 2009 20:41:26 -0200, Denis A. Altoé Falqueto <denisfalqueto@gmail.com> a écrit :
On Thu, Dec 3, 2009 at 4:14 PM, Arvid Picciani <aep@exys.org> wrote:
Aaron Griffin wrote: "Those who don't understand UNIX are condemned to reinvent it, poorly." – Henry Spencer
"And those who do understand it are doomed to implement it right, that's why there is Plan 9." - Me.
:) (For those who don't know, Plan 9 was made by the some of people who created Unix.)
By the way, we could have both: http://www.glendix.org/
I don't really understand what this project does other than being able to execute Plan 9 binaries. What's the point then?
Le Fri, 4 Dec 2009 10:33:38 +1030, Ty John <ty-ml@eye-of-odin.com> a écrit :
I don't really understand what this project does other than being able to execute Plan 9 binaries. What's the point then?
The point is to have a Plan 9 userspace on the Linux kernel (which is maintained and mainstream), instead of the GNU userspace (which is -arguably- not unixy enough). It makes it Linux, but not GNU/Linux (a bit like Android). -- catwell
On Fri, 4 Dec 2009 00:31:39 +0000 Pierre Chapuis <catwell@archlinux.us> wrote:
Le Fri, 4 Dec 2009 10:33:38 +1030, Ty John <ty-ml@eye-of-odin.com> a écrit :
I don't really understand what this project does other than being able to execute Plan 9 binaries. What's the point then?
The point is to have a Plan 9 userspace on the Linux kernel (which is maintained and mainstream), instead of the GNU userspace (which is -arguably- not unixy enough).
It makes it Linux, but not GNU/Linux (a bit like Android).
Oh thanks for that. It has me interested now but I won't send this thread OT ;)
On Thu, 2009-12-03 at 19:14 +0100, Arvid Picciani wrote:
Mechanisms have existed for like 20 years before dbus to communicate with other programs.
and those don't require a user space daemon.
You're talking crap. Examples of other IPC frameworks are bonobo and dcop. Both launched the daemon on initial usage. On a modern GNOME desktop you still have a bonobo-activation-server running because evolution still uses it. Dbus also launches a sesion bus when it's needed, but for the system bus, things are different. You can't run a system bus as normal user, unless you install dbus as setuid root and make some code to launch the system bus on request. One thing I hate about dbus is the fact that a lot of applications crash together with shutdown of dbus. gnome-session and xfce terminal come to mind. I think gnome-session has been fixed for this, xfce terminal has a patch in our svn for it. I don't mind if xfce terminal can't open new tabs or windows when dbus goes down, but please don't kill the ones that are open. This is not actually a bug in dbus, but an issue with applications using it.
On 12/03/2009 12:29 PM, Aaron Griffin wrote:
Mechanisms have existed for like 20 years before dbus to communicate with other programs. dbus is just another way to do it that has a smell of "architecture astronomy" - as if they all scoffed at the actual ways to do IPC on various Unicies and said "Oh, I can design better".
That's why I dislike it.
I'll preface this by right up front saying that my knowledge of dbus is actually pretty limited. So forgive me if I'm off-base in my comments. But frankly, I didn't think the *intent* behind dbus was as a replacement for IPC. As I understood it, dbus was intended to be a system-wide message bus - i.e., a very generic pub/sub type of system that could be used by any component in the system. Some components would publish messages of a particular, and other components would get notified about messages of a type they're interested in and react to them. Makes some sense to me to do things this way, as then you can just have a single, standard system-wide daemon that every app interacts with in the same way, rather than force each app to reinvent the wheel and implement their own solution. DR
I never had dbus crashing anytime.. Regarding communication channels - there are two types in dbus - one is system and other is userland.. So dbus provided something for userland apps which could not use IPC for some reason. Another main reason as pointed above, it is general pub/sub system - which wasn't there before, and it is quite generic in that publishing to an interface works(need not know underlying stuff). Regarding bad experiences with dbus, it is the application's fault. If app is having problem with dbus, then compile that app without dbus. If that doesnt work then ditch that application. (send flame mail to app creator :) if you are over pissed) On Fri, Dec 4, 2009 at 2:45 AM, David Rosenstrauch <darose@darose.net>wrote:
On 12/03/2009 12:29 PM, Aaron Griffin wrote:
Mechanisms have existed for like 20 years before dbus to communicate with other programs. dbus is just another way to do it that has a smell of "architecture astronomy" - as if they all scoffed at the actual ways to do IPC on various Unicies and said "Oh, I can design better".
That's why I dislike it.
I'll preface this by right up front saying that my knowledge of dbus is actually pretty limited. So forgive me if I'm off-base in my comments.
But frankly, I didn't think the *intent* behind dbus was as a replacement for IPC. As I understood it, dbus was intended to be a system-wide message bus - i.e., a very generic pub/sub type of system that could be used by any component in the system. Some components would publish messages of a particular, and other components would get notified about messages of a type they're interested in and react to them.
Makes some sense to me to do things this way, as then you can just have a single, standard system-wide daemon that every app interacts with in the same way, rather than force each app to reinvent the wheel and implement their own solution.
DR
On Thu, Dec 03, 2009 at 11:29:51AM -0600, Aaron Griffin wrote:
Mechanisms have existed for like 20 years before dbus to communicate with other programs. dbus is just another way to do it that has a smell of "architecture astronomy" - as if they all scoffed at the actual ways to do IPC on various Unicies and said "Oh, I can design better".
That's why I dislike it.
I agree, and there is more. - It uses glib types instead of the plain C ones. So it smells GNOME from the start. Why should an app that has nothing to do with GNOME be forced to use its headers ? - It uses XML configuration, no system tool should do that - it's bloated, ugly, and in most cases impossible to read. No system tool should depend on the presence of XML libraries. - It is being abused in major ways. Any app that uses it to 'enhance the user experience' should be able to work without it just doing its core function, but in almost all cases things are not implemented that way. The latter is part of a culture that dictates that everything should be automatic and based on what 'most' users prefer. Could be, but that is no reason to force these things on those who don't want them. And in almost all cases it is impossible to change this behaviour, any attempt at manaul configuration is viewed as an attack on the system. That said, dbus is probably one of the minor evils originating at freedesktop.org. The Kit family is much worse. Ciao, -- FA
Yeah, XML configuration sucks..(reason for me not using Openbox). Regarding 'kit' family, it originated from Fedora.. In new Fedora 12, they have added few more of those kits(like PackageKit)... :)... One of the reasons these things got added by default maybe that majority of RedHat/Fedora/Ubuntu/Mainline developers also work on gnome/kde libraries.So those libraries gradually became fat with 'developer' contributions. One recent development may be that Debian ditched glibc for eglibc.(some glibc dev were too egotistic to make any changes) http://www.h-online.com/open/news/item/Debian-changes-from-GLIBC-to-EGLIBC-7... On Fri, Dec 4, 2009 at 3:25 AM, <fons@kokkinizita.net> wrote:
On Thu, Dec 03, 2009 at 11:29:51AM -0600, Aaron Griffin wrote:
Mechanisms have existed for like 20 years before dbus to communicate with other programs. dbus is just another way to do it that has a smell of "architecture astronomy" - as if they all scoffed at the actual ways to do IPC on various Unicies and said "Oh, I can design better".
That's why I dislike it.
I agree, and there is more.
- It uses glib types instead of the plain C ones. So it smells GNOME from the start. Why should an app that has nothing to do with GNOME be forced to use its headers ? - It uses XML configuration, no system tool should do that - it's bloated, ugly, and in most cases impossible to read. No system tool should depend on the presence of XML libraries. - It is being abused in major ways. Any app that uses it to 'enhance the user experience' should be able to work without it just doing its core function, but in almost all cases things are not implemented that way.
The latter is part of a culture that dictates that everything should be automatic and based on what 'most' users prefer. Could be, but that is no reason to force these things on those who don't want them. And in almost all cases it is impossible to change this behaviour, any attempt at manaul configuration is viewed as an attack on the system.
That said, dbus is probably one of the minor evils originating at freedesktop.org. The Kit family is much worse.
Ciao,
-- FA
On Thu, 2009-12-03 at 22:55 +0100, fons@kokkinizita.net wrote:
On Thu, Dec 03, 2009 at 11:29:51AM -0600, Aaron Griffin wrote:
Mechanisms have existed for like 20 years before dbus to communicate with other programs. dbus is just another way to do it that has a smell of "architecture astronomy" - as if they all scoffed at the actual ways to do IPC on various Unicies and said "Oh, I can design better".
That's why I dislike it.
I agree, and there is more.
Isn't it in the nature of programmers and people in general to have just enough egotism to say "I can do better"? Progress is based on that. In dbus' case it seems (to this ignorant user) that the attempt was to have a single system which everyone could use. Or in other words, world domination. Which is the goal of most software tools, to be so good that noone would use anything else.
- It uses glib types instead of the plain C ones. So it smells GNOME from the start. Why should an app that has nothing to do with GNOME be forced to use its headers ?
Sorry, unable to comment on the programming details. Aren't glib types basically C ones with a bit of added checks though?
- It uses XML configuration, no system tool should do that - it's bloated, ugly, and in most cases impossible to read. No system tool should depend on the presence of XML libraries.
I dislike reading XML, and editing it. It does have some advantages, however (else it wouldn't exists). Chief among them, I think, is the ease of (and availability of tools to) parse automatically. In this case, as with other software, the devs chose a config to run with and did it. End-of, in my opinion.
- It is being abused in major ways. Any app that uses it to 'enhance the user experience' should be able to work without it just doing its core function, but in almost all cases things are not implemented that way.
The latter is part of a culture that dictates that everything should be automatic and based on what 'most' users prefer. Could be, but that is no reason to force these things on those who don't want them. And in almost all cases it is impossible to change this behaviour, any attempt at manaul configuration is viewed as an attack on the system.
I would tend to agree here, but the bigger cultural thing is what is the issue. Apps, like it or not, are dealing with the profusion of choice on Linux by tying themselves to a single base-point. Currently, that base-point happens to be Gnome, sole-ly due to user numbers. From the viewpoint of app designers, they only expect their creations to be used on Gnome, that's all they test for, and everyone else can go patch themselves a new one. Not right, but when you're basically writing apps selfishly for yourselves (as most do in Linux), its the prerogative of the developer. As previously mentioned, the main problem would be that apps which don't have to depend on it do. This should be solved at the individual app level, not by wishing dbus didn't exist. Or lobbying for it to be removed. Agreed that manual configuration should ALWAYS be possible. Am not sure how much configuration is needed for an IPC however, which is not normally (if at all) user-visible.
That said, dbus is probably one of the minor evils originating at freedesktop.org. The Kit family is much worse.
Ciao,
Different discussion =). Now THAT would be interesting.
On Thu, Dec 3, 2009 at 7:55 PM, <fons@kokkinizita.net> wrote:
- It uses glib types instead of the plain C ones. So it smells GNOME from the start. Why should an app that has nothing to do with GNOME be forced to use its headers ?
DBus as a protocol is language independent. It defines the format the types must be converted to be able to pass between applications written in different languages. The DBus library uses GLib for its main loop implementation. There's DBus in Qt, which uses the Qt main loop, I think. (though I remember from Linux Audio Users list that you don't like Qt too :))
- It uses XML configuration, no system tool should do that - it's bloated, ugly, and in most cases impossible to read. No system tool should depend on the presence of XML libraries.
That's a matter of taste. I work with Java, so I'm not the ideal person to talk about XML :) I don't love it too, but it's not the worst thing of the planet. With time, you end up grasping it as you do with normal text.
- It is being abused in major ways. Any app that uses it to 'enhance the user experience' should be able to work without it just doing its core function, but in almost all cases things are not implemented that way.
That's something that should be discussed with the developers. But they probably have good reasons to use it, or they wouldn't do, isn't it?
The latter is part of a culture that dictates that everything should be automatic and based on what 'most' users prefer. Could be, but that is no reason to force these things on those who don't want them. And in almost all cases it is impossible to change this behaviour, any attempt at manaul configuration is viewed as an attack on the system.
That said, dbus is probably one of the minor evils originating at freedesktop.org. The Kit family is much worse.
I must say that I respect your opinion and am a big fan of your programs, namely Aelous. Your technical skills are astounding and your programming experience is way bigger than mine. But I also must say that I disagree strongly with you in these paragraphs. Again, we don't need to be stuck in the past just for the sake of it. The *Kit family maybe could be replaced by a good set of ACLs, but even that can be problematic, as not all the concepts that are configured by PolicyKit or ConsoleKit are files. And the Unix security model of Users/Groups/Others is not very flexible, beyond some simple cases. -- A: Because it obfuscates the reading. Q: Why is top posting so bad? ------------------------------------------- Denis A. Altoe Falqueto -------------------------------------------
On Thu, Dec 03, 2009 at 10:04:16PM -0200, Denis A. Altoé Falqueto wrote:
... (though I remember from Linux Audio Users list that you don't like Qt too :))
It is completely irrelevant if I like it or not. If dbus is intended for 'general use' it should use C types, not those of whatever toolkit. Authors who don't use that toolkit should not be forced to depend on it, in particular not if nothing is gained by doing so.
(about XML) .... With time, you end up grasping it as you do with normal text.
That's no reason to accept it. With time you would adjust to being tortured each day at 6PM as well.
- It is being abused in major ways. Any app that uses it to 'enhance the user experience' should be able to work without it just doing its core function, but in almost all cases things are not implemented that way.
That's something that should be discussed with the developers. But they probably have good reasons to use it, or they wouldn't do, isn't it?
I don't agree. There's lots of blind belief, ignorance, misguided ambitions, tribal dynamics, and plain lazyness.
Again, we don't need to be stuck in the past just for the sake of it.
Not being stuck in the past doesn't imply you have to accept something just because it's new and the current fad.
The *Kit family maybe could be replaced by a good set of ACLs, but even that can be problematic, as not all the concepts that are configured by PolicyKit or ConsoleKit are files. And the Unix security model of Users/Groups/Others is not very flexible, beyond some simple cases.
It's a lot more flexible than you'd imagine. It has been used with success to manage systems with thousands of users. If that is possible, do you really think that a managing a simple personal computer requires anything new ? Ciao, -- FA
On Thu, Dec 3, 2009 at 11:07 PM, <fons@kokkinizita.net> wrote:
(about XML) .... With time, you end up grasping it as you do with normal text.
That's no reason to accept it. With time you would adjust to being tortured each day at 6PM as well.
:)
I don't agree. There's lots of blind belief, ignorance, misguided ambitions, tribal dynamics, and plain lazyness.
Blind belief is a two handed way. As the old saying goes "I'm not stubborn. Stubborn is who argues with me". Lazyness is inherent to any programmer. If we weren't, we would still be patching panels with cords and reading the output in those beautiful little lamps. -- A: Because it obfuscates the reading. Q: Why is top posting so bad? ------------------------------------------- Denis A. Altoe Falqueto -------------------------------------------
On Thu, Dec 03, 2009 at 10:04:16PM -0200, Denis A. Altoé Falqueto wrote:
The *Kit family maybe could be replaced by a good set of ACLs, but even that can be problematic, as not all the concepts that are configured by PolicyKit or ConsoleKit are files. And the Unix security model of Users/Groups/Others is not very flexible, beyond some simple cases.
Let me illustrate the problem here by construction an argument with a similar flaw: "The mouse is inflexible and should be deprecated, as a stylus has the advantage of being cordless. All modern pointing devices should be cordless and i think these mouse users are just from the 60s." fons@kokkinizita.net wrote:
It's a lot more flexible than you'd imagine. It has been used with success to manage systems with thousands of users. If that is possible, do you really think that a managing a simple personal computer requires anything new ?
It all adds up. Been on one of their conferences? A man with my patience can easily go into stabbing mode there. The amount of clueless people clearly outnumbered any available resources to cluebat them. Eternal September is a pattern, not an event. Someone is propably going to whine about me being offensive again, so i added cake: not. -- Arvid Asgaard Technologies
On 04/12/09 02:27, Arvid Picciani wrote: [...]
Let me illustrate the problem here by construction an argument with a similar flaw:
"The mouse is inflexible and should be deprecated, as a stylus has the advantage of being cordless. All modern pointing devices should be cordless and i think these mouse users are just from the 60s." You do realise that your argument makes no sense right?
Let me illustrate the problem here by construction an argument with a similar flaw:
"The mouse is inflexible and should be deprecated, as a stylus has the advantage of being cordless. All modern pointing devices should be cordless and i think these mouse users are just from the 60s."
Furthermore, no application should ever be built with support for styluses because some applications have buggy stylus support and adding support for something I don't need is against the Arch Way(tm). -Brendan Long
On Fri, Dec 4, 2009 at 2:40 AM, Brendan Long <korin43@gmail.com> wrote:
Let me illustrate the problem here by construction an argument with a similar flaw:
"The mouse is inflexible and should be deprecated, as a stylus has the advantage of being cordless. All modern pointing devices should be cordless and i think these mouse users are just from the 60s."
Furthermore, no application should ever be built with support for styluses because some applications have buggy stylus support and adding support for something I don't need is against the Arch Way(tm).
After all these replies I can see that there are very few and questionable technical reasons against DBus. There are just some pet peeves that can be avoided with a little common sense and good will, both things that we always think we have in excess and the others have in shortage. Well, I thanks for the answers and think it was fun, even if just for the wannabe anthropologist in me. Best wishes. -- A: Because it obfuscates the reading. Q: Why is top posting so bad? ------------------------------------------- Denis A. Altoe Falqueto -------------------------------------------
So a while ago I wanted to get a working phc package for Arch and I eventually got it working, but right now it relies on you installing php with the configuration set with ./configure --enable-embed --prefix=/opt [other options] because I don't want to mess up the default php install, and I can't seem to make a package to install just the embed sapi. I'm wondering if anyone has any ideas of how to make this a simple php-embed package that would only install the needed parts. I tried making one of my own, but if you do --enable-cli and --enable-embed, it won't compile :( -Brendan Long
On Thu, Dec 3, 2009 at 11:56 PM, Brendan Long <korin43@gmail.com> wrote:
I'm wondering if anyone has any ideas of how to make this a simple php-embed package that would only install the needed parts.
I became curios how other distros package phc - turns out they don't. There are two packages provided on phc website, one for RPM-based systems, other for FreeBSD. Both packages are outdated and neither tackles custom php build flags. It might be that a custom build of PHP wasn't required in prior versions. Suggestion: create a PHP package built with --enable-embed flag, name it something other than php and make it a dependency for the phc package. Anyone care to comment why this might be a bad idea?
My problem isn't creating a custom php package, the problem is creating one that installs to /usr but doesn't conflict with the official php package. I'd like to be able to install it just like you can install php-mcrypt and php-mysql. On 12/8/2009 7:43 PM, Denis Kobozev wrote:
On Thu, Dec 3, 2009 at 11:56 PM, Brendan Long<korin43@gmail.com> wrote:
I'm wondering if anyone has any ideas of how to make this a simple php-embed package that would only install the needed parts.
I became curios how other distros package phc - turns out they don't. There are two packages provided on phc website, one for RPM-based systems, other for FreeBSD. Both packages are outdated and neither tackles custom php build flags. It might be that a custom build of PHP wasn't required in prior versions.
Suggestion: create a PHP package built with --enable-embed flag, name it something other than php and make it a dependency for the phc package. Anyone care to comment why this might be a bad idea?
On Wed, Dec 9, 2009 at 12:44 AM, Brendan Long <korin43@gmail.com> wrote:
My problem isn't creating a custom php package, the problem is creating one that installs to /usr but doesn't conflict with the official php package. I'd like to be able to install it just like you can install php-mcrypt and php-mysql.
You would have to modify the current php package though. Either you modify it yourself, name it differently, add the official php package to the list of conflicting packages and upload your PKGBUILD to AUR for those who would want to use embed sapi; or email the current php package maintainer and ask him to include --enable-embed=shared to the list of php extensions. Embed would then be compiled as a shared library and could be installed on demand. Or something like that. Denis.
I'm hoping there's a way to package it separately. I want to install to /usr, but depending on how big the embed SAPI is, I don't know if it would be worthwhile for most users to to make everyone have to install it (since the only program I know of that uses it is phc). On Wed, 2009-12-09 at 01:45 -0500, Denis Kobozev wrote:
On Wed, Dec 9, 2009 at 12:44 AM, Brendan Long <korin43@gmail.com> wrote:
My problem isn't creating a custom php package, the problem is creating one that installs to /usr but doesn't conflict with the official php package. I'd like to be able to install it just like you can install php-mcrypt and php-mysql.
You would have to modify the current php package though. Either you modify it yourself, name it differently, add the official php package to the list of conflicting packages and upload your PKGBUILD to AUR for those who would want to use embed sapi; or email the current php package maintainer and ask him to include --enable-embed=shared to the list of php extensions. Embed would then be compiled as a shared library and could be installed on demand.
Or something like that.
Denis.
For a little while I've been confused because pacman -Syu always said that everything was up to date (for a week or more). I talked to a friend at school and he had the same thing happening and I realized something might be wrong and commented out mirrors one at a time until I found one with updates (I think easynews is the one I used). The new update comes with a mirrorlist that doesn't contain the mirror I was using before (gigenet) The problem is that there's no warning that something is wrong with the old mirrors, so I'd like to suggest some sort of test so that if no updates are found for some amount of time, pacman tries a known good mirror (like the main one). To save on bandwidth, it might work best to make it only check the main repo for an updated package list and then tries the normal mirrors until it finds one with a matching package list. I'm not sure how complicated this would be be, or how worthwhile it is (I suppose Arch users are more likely than most to realize that something is wrong when updates stop), but I think it would be helpful to have some sort of test to make sure you're not updating off a seriously out of date mirror. -Brendan Long
On Fri, Dec 11, 2009 at 3:14 PM, Brendan Long <korin43@gmail.com> wrote:
For a little while I've been confused because pacman -Syu always said that everything was up to date (for a week or more). I talked to a friend at school and he had the same thing happening and I realized something might be wrong and commented out mirrors one at a time until I found one with updates (I think easynews is the one I used). The new update comes with a mirrorlist that doesn't contain the mirror I was using before (gigenet)
The problem is that there's no warning that something is wrong with the old mirrors, so I'd like to suggest some sort of test so that if no updates are found for some amount of time, pacman tries a known good mirror (like the main one). To save on bandwidth, it might work best to make it only check the main repo for an updated package list and then tries the normal mirrors until it finds one with a matching package list.
I'm not sure how complicated this would be be, or how worthwhile it is (I suppose Arch users are more likely than most to realize that something is wrong when updates stop), but I think it would be helpful to have some sort of test to make sure you're not updating off a seriously out of date mirror.
Well, technically there's nothing "wrong" with the mirror. No one defined "matching archlinux.org exactly" to be "right". That said, there was some discussion in the past to use one server for DB files and another for packages. That'd cover this case here - get the db files from archlinux.org and use other servers for packages.
Aaron Griffin (2009-12-11 15:38):
On Fri, Dec 11, 2009 at 3:14 PM, Brendan Long <korin43@gmail.com> wrote:
For a little while I've been confused because pacman -Syu always said that everything was up to date (for a week or more). I talked to a friend at school and he had the same thing happening and I realized something might be wrong and commented out mirrors one at a time until I found one with updates (I think easynews is the one I used). The new update comes with a mirrorlist that doesn't contain the mirror I was using before (gigenet)
The problem is that there's no warning that something is wrong with the old mirrors, so I'd like to suggest some sort of test so that if no updates are found for some amount of time, pacman tries a known good mirror (like the main one). To save on bandwidth, it might work best to make it only check the main repo for an updated package list and then tries the normal mirrors until it finds one with a matching package list.
I'm not sure how complicated this would be be, or how worthwhile it is (I suppose Arch users are more likely than most to realize that something is wrong when updates stop), but I think it would be helpful to have some sort of test to make sure you're not updating off a seriously out of date mirror.
Well, technically there's nothing "wrong" with the mirror. No one defined "matching archlinux.org exactly" to be "right".
That said, there was some discussion in the past to use one server for DB files and another for packages. That'd cover this case here - get the db files from archlinux.org and use other servers for packages.
Having DB files in a central place would do much trust wise. Currently, one has to totally trust a mirror, because a mirror has total control over the contents of binary packages and their checksums. But I guess this is what the past discussion was about? -- -- Rogutės Sparnuotos
On Sat, 2009-12-12 at 00:54 +0200, Rogutės Sparnuotos wrote:
Aaron Griffin (2009-12-11 15:38):
On Fri, Dec 11, 2009 at 3:14 PM, Brendan Long <korin43@gmail.com> wrote:
For a little while I've been confused because pacman -Syu always said that everything was up to date (for a week or more). I talked to a friend at school and he had the same thing happening and I realized something might be wrong and commented out mirrors one at a time until I found one with updates (I think easynews is the one I used). The new update comes with a mirrorlist that doesn't contain the mirror I was using before (gigenet)
The problem is that there's no warning that something is wrong with the old mirrors, so I'd like to suggest some sort of test so that if no updates are found for some amount of time, pacman tries a known good mirror (like the main one). To save on bandwidth, it might work best to make it only check the main repo for an updated package list and then tries the normal mirrors until it finds one with a matching package list.
I'm not sure how complicated this would be be, or how worthwhile it is (I suppose Arch users are more likely than most to realize that something is wrong when updates stop), but I think it would be helpful to have some sort of test to make sure you're not updating off a seriously out of date mirror.
Well, technically there's nothing "wrong" with the mirror. No one defined "matching archlinux.org exactly" to be "right".
That said, there was some discussion in the past to use one server for DB files and another for packages. That'd cover this case here - get the db files from archlinux.org and use other servers for packages.
Having DB files in a central place would do much trust wise. Currently, one has to totally trust a mirror, because a mirror has total control over the contents of binary packages and their checksums. But I guess this is what the past discussion was about?
While I'm not as concerned about security as some (most) here, I do think "db files from one site and packages from another" is a good idea. (some) Mirrors will be slow, however, and there will be additional complexity since the db would perhaps be several steps ahead of most mirrors. For example if package foo-1.2 is installed, package foo-1.4 is in the db, and package foo-1.3 is in the mirror, pacman would have to be smart enough to install foo-1.3....
On Sat, Dec 12, 2009 at 12:20 AM, Ng Oon-Ee <ngoonee@gmail.com> wrote:
While I'm not as concerned about security as some (most) here, I do think "db files from one site and packages from another" is a good idea. (some) Mirrors will be slow, however, and there will be additional complexity since the db would perhaps be several steps ahead of most mirrors. For example if package foo-1.2 is installed, package foo-1.4 is in the db, and package foo-1.3 is in the mirror, pacman would have to be smart enough to install foo-1.3....
Why should it do that ? And that would make the security aspect completely irrelevant. You did say you were not concerned about security (and to be honest, me neither), but it's still not a reason to ignore it. By the way, when you use more than one mirror, pacman will just switch to the second one if it doesn't find the file it wants.
On Sat, 2009-12-12 at 00:35 +0100, Xavier wrote:
On Sat, Dec 12, 2009 at 12:20 AM, Ng Oon-Ee <ngoonee@gmail.com> wrote:
While I'm not as concerned about security as some (most) here, I do think "db files from one site and packages from another" is a good idea. (some) Mirrors will be slow, however, and there will be additional complexity since the db would perhaps be several steps ahead of most mirrors. For example if package foo-1.2 is installed, package foo-1.4 is in the db, and package foo-1.3 is in the mirror, pacman would have to be smart enough to install foo-1.3....
Why should it do that ? And that would make the security aspect completely irrelevant.
You did say you were not concerned about security (and to be honest, me neither), but it's still not a reason to ignore it.
By the way, when you use more than one mirror, pacman will just switch to the second one if it doesn't find the file it wants.
Because sometimes all the mirrors listed in mirrorlist will not have the file, if its just been uploaded. Also not everyone stays up-to-the-minute with updates, judging by the "updated after a month" posts we see once in a while. I'm concerned about the last bit, if a package was just uploaded and only exists on one mirror, everyone who updates and has that package in the period between its uploading and its appearance on their local mirrors will 'fall-back' on varying mirrors (lengthening the update process) and all end up on the poor main server (or Tier 1/2 mirrors). Bad for both the mirror bandwidth as well as most probably much slower for the user, who could probably just wait a day or so for the update to come to his (faster, presumably) local mirror.
Am Sat, 12 Dec 2009 08:58:17 +0800 schrieb Ng Oon-Ee <ngoonee@gmail.com>:
Because sometimes all the mirrors listed in mirrorlist will not have the file, if its just been uploaded. Also not everyone stays up-to-the-minute with updates, judging by the "updated after a month" posts we see once in a while.
I'm concerned about the last bit, if a package was just uploaded and only exists on one mirror, everyone who updates and has that package in the period between its uploading and its appearance on their local mirrors will 'fall-back' on varying mirrors (lengthening the update process) and all end up on the poor main server (or Tier 1/2 mirrors). Bad for both the mirror bandwidth as well as most probably much slower for the user, who could probably just wait a day or so for the update to come to his (faster, presumably) local mirror.
Wouldn't it be possible to first upload the packages and update the db files when the packages on the mirrors (at least on several mirrors) are updated? If I have such a "problem" that a package is on no mirrors, which doesn't happen often, I usually abort the system update and wait one day. I think that's the normal and easiest way of solving this issue. Greetings, Heiko
On Sat, 2009-12-12 at 02:13 +0100, Heiko Baums wrote:
Am Sat, 12 Dec 2009 08:58:17 +0800 schrieb Ng Oon-Ee <ngoonee@gmail.com>:
Because sometimes all the mirrors listed in mirrorlist will not have the file, if its just been uploaded. Also not everyone stays up-to-the-minute with updates, judging by the "updated after a month" posts we see once in a while.
I'm concerned about the last bit, if a package was just uploaded and only exists on one mirror, everyone who updates and has that package in the period between its uploading and its appearance on their local mirrors will 'fall-back' on varying mirrors (lengthening the update process) and all end up on the poor main server (or Tier 1/2 mirrors). Bad for both the mirror bandwidth as well as most probably much slower for the user, who could probably just wait a day or so for the update to come to his (faster, presumably) local mirror.
Wouldn't it be possible to first upload the packages and update the db files when the packages on the mirrors (at least on several mirrors) are updated?
If I have such a "problem" that a package is on no mirrors, which doesn't happen often, I usually abort the system update and wait one day. I think that's the normal and easiest way of solving this issue.
Greetings, Heiko
The few mirrors which sync first would have quite much higher bandwidth usage =). The concern then is that in the period of time between uploading of packages and updating of db, the db would point to a package (foo-1.3) while the mirror would only have the new version (foo-1.4), since I don't think many mirrors keep multiple copies of the same package (schlunix I know off, any others?). So that would break updating as well, just in a different direction, and this would not be recoverable from.
2009/12/11 Ng Oon-Ee <ngoonee@gmail.com>:
On Sat, 2009-12-12 at 02:13 +0100, Heiko Baums wrote:
Am Sat, 12 Dec 2009 08:58:17 +0800 schrieb Ng Oon-Ee <ngoonee@gmail.com>:
Because sometimes all the mirrors listed in mirrorlist will not have the file, if its just been uploaded. Also not everyone stays up-to-the-minute with updates, judging by the "updated after a month" posts we see once in a while.
I'm concerned about the last bit, if a package was just uploaded and only exists on one mirror, everyone who updates and has that package in the period between its uploading and its appearance on their local mirrors will 'fall-back' on varying mirrors (lengthening the update process) and all end up on the poor main server (or Tier 1/2 mirrors). Bad for both the mirror bandwidth as well as most probably much slower for the user, who could probably just wait a day or so for the update to come to his (faster, presumably) local mirror.
Wouldn't it be possible to first upload the packages and update the db files when the packages on the mirrors (at least on several mirrors) are updated?
If I have such a "problem" that a package is on no mirrors, which doesn't happen often, I usually abort the system update and wait one day. I think that's the normal and easiest way of solving this issue.
Greetings, Heiko
The few mirrors which sync first would have quite much higher bandwidth usage =).
It may be that natural selection is already producing this result: for instance, I just recently tried a bunch of different mirrors until I found one that was up to date. So people may be doing this already manually. -- Ryan W Sims
2009/12/11 Ng Oon-Ee <ngoonee@gmail.com>
On Sat, 2009-12-12 at 02:13 +0100, Heiko Baums wrote:
Am Sat, 12 Dec 2009 08:58:17 +0800 schrieb Ng Oon-Ee <ngoonee@gmail.com>:
Because sometimes all the mirrors listed in mirrorlist will not have the file, if its just been uploaded. Also not everyone stays up-to-the-minute with updates, judging by the "updated after a month" posts we see once in a while.
I'm concerned about the last bit, if a package was just uploaded and only exists on one mirror, everyone who updates and has that package in the period between its uploading and its appearance on their local mirrors will 'fall-back' on varying mirrors (lengthening the update process) and all end up on the poor main server (or Tier 1/2 mirrors). Bad for both the mirror bandwidth as well as most probably much slower for the user, who could probably just wait a day or so for the update to come to his (faster, presumably) local mirror.
Wouldn't it be possible to first upload the packages and update the db files when the packages on the mirrors (at least on several mirrors) are updated?
If I have such a "problem" that a package is on no mirrors, which doesn't happen often, I usually abort the system update and wait one day. I think that's the normal and easiest way of solving this issue.
Greetings, Heiko
The few mirrors which sync first would have quite much higher bandwidth usage =).
The concern then is that in the period of time between uploading of packages and updating of db, the db would point to a package (foo-1.3) while the mirror would only have the new version (foo-1.4), since I don't think many mirrors keep multiple copies of the same package (schlunix I know off, any others?). So that would break updating as well, just in a different direction, and this would not be recoverable from.
Maybe a better idea would be to make pacman keep track of the last time it got an updated package list, and if it's beyond a certain point, it starts checking other mirrors (maybe optional "No updates have been found in 5 days, would you like to scan other mirrors for updates?").
On Sat, 2009-12-12 at 17:08 -0700, Brendan Long wrote:
2009/12/11 Ng Oon-Ee <ngoonee@gmail.com>
On Sat, 2009-12-12 at 02:13 +0100, Heiko Baums wrote:
Am Sat, 12 Dec 2009 08:58:17 +0800 schrieb Ng Oon-Ee <ngoonee@gmail.com>:
Because sometimes all the mirrors listed in mirrorlist will not have the file, if its just been uploaded. Also not everyone stays up-to-the-minute with updates, judging by the "updated after a month" posts we see once in a while.
I'm concerned about the last bit, if a package was just uploaded and only exists on one mirror, everyone who updates and has that package in the period between its uploading and its appearance on their local mirrors will 'fall-back' on varying mirrors (lengthening the update process) and all end up on the poor main server (or Tier 1/2 mirrors). Bad for both the mirror bandwidth as well as most probably much slower for the user, who could probably just wait a day or so for the update to come to his (faster, presumably) local mirror.
Wouldn't it be possible to first upload the packages and update the db files when the packages on the mirrors (at least on several mirrors) are updated?
If I have such a "problem" that a package is on no mirrors, which doesn't happen often, I usually abort the system update and wait one day. I think that's the normal and easiest way of solving this issue.
Greetings, Heiko
The few mirrors which sync first would have quite much higher bandwidth usage =).
The concern then is that in the period of time between uploading of packages and updating of db, the db would point to a package (foo-1.3) while the mirror would only have the new version (foo-1.4), since I don't think many mirrors keep multiple copies of the same package (schlunix I know off, any others?). So that would break updating as well, just in a different direction, and this would not be recoverable from.
Maybe a better idea would be to make pacman keep track of the last time it got an updated package list, and if it's beyond a certain point, it starts checking other mirrors (maybe optional "No updates have been found in 5 days, would you like to scan other mirrors for updates?").
The difference I would see is that in the current system an out-of-date mirror is still use-able (no mismatch between db and package as we're discussing). Some would manually change mirrors, but others would not, so the net effect of automating fallover would be to increase load above what it currently is. Not everyone needs packages right on the day they're uploaded, or runs pacman everyday (I do, though =p)
On Sun, 2009-12-13 at 11:16 +0800, Ng Oon-Ee wrote:
On Sat, 2009-12-12 at 17:08 -0700, Brendan Long wrote:
2009/12/11 Ng Oon-Ee <ngoonee@gmail.com>
On Sat, 2009-12-12 at 02:13 +0100, Heiko Baums wrote:
Am Sat, 12 Dec 2009 08:58:17 +0800 schrieb Ng Oon-Ee <ngoonee@gmail.com>:
Because sometimes all the mirrors listed in mirrorlist will not have the file, if its just been uploaded. Also not everyone stays up-to-the-minute with updates, judging by the "updated after a month" posts we see once in a while.
I'm concerned about the last bit, if a package was just uploaded and only exists on one mirror, everyone who updates and has that package in the period between its uploading and its appearance on their local mirrors will 'fall-back' on varying mirrors (lengthening the update process) and all end up on the poor main server (or Tier 1/2 mirrors). Bad for both the mirror bandwidth as well as most probably much slower for the user, who could probably just wait a day or so for the update to come to his (faster, presumably) local mirror.
Wouldn't it be possible to first upload the packages and update the db files when the packages on the mirrors (at least on several mirrors) are updated?
If I have such a "problem" that a package is on no mirrors, which doesn't happen often, I usually abort the system update and wait one day. I think that's the normal and easiest way of solving this issue.
Greetings, Heiko
The few mirrors which sync first would have quite much higher bandwidth usage =).
The concern then is that in the period of time between uploading of packages and updating of db, the db would point to a package (foo-1.3) while the mirror would only have the new version (foo-1.4), since I don't think many mirrors keep multiple copies of the same package (schlunix I know off, any others?). So that would break updating as well, just in a different direction, and this would not be recoverable from.
Maybe a better idea would be to make pacman keep track of the last time it got an updated package list, and if it's beyond a certain point, it starts checking other mirrors (maybe optional "No updates have been found in 5 days, would you like to scan other mirrors for updates?").
The difference I would see is that in the current system an out-of-date mirror is still use-able (no mismatch between db and package as we're discussing). Some would manually change mirrors, but others would not, so the net effect of automating fallover would be to increase load above what it currently is.
Not everyone needs packages right on the day they're uploaded, or runs pacman everyday (I do, though =p)
Not everyone runs pacman every day, but when you do, you expect to get up to date packages.
On Sun, Dec 13, 2009 at 2:07 AM, Brendan Long <korin43@gmail.com> wrote:
On Sat, 2009-12-12 at 17:08 -0700, Brendan Long wrote:
2009/12/11 Ng Oon-Ee <ngoonee@gmail.com>
On Sat, 2009-12-12 at 02:13 +0100, Heiko Baums wrote:
Am Sat, 12 Dec 2009 08:58:17 +0800 schrieb Ng Oon-Ee <ngoonee@gmail.com>:
Because sometimes all the mirrors listed in mirrorlist will not have the file, if its just been uploaded. Also not everyone stays up-to-the-minute with updates, judging by the "updated after a month" posts we see once in a while.
I'm concerned about the last bit, if a package was just uploaded and only exists on one mirror, everyone who updates and has that
On Sun, 2009-12-13 at 11:16 +0800, Ng Oon-Ee wrote: package
in the period between its uploading and its appearance on their local mirrors will 'fall-back' on varying mirrors (lengthening the update process) and all end up on the poor main server (or Tier 1/2 mirrors). Bad for both the mirror bandwidth as well as most probably much slower for the user, who could probably just wait a day or so for the update to come to his (faster, presumably) local mirror.
Wouldn't it be possible to first upload the packages and update the db files when the packages on the mirrors (at least on several mirrors) are updated?
If I have such a "problem" that a package is on no mirrors, which doesn't happen often, I usually abort the system update and wait one day. I think that's the normal and easiest way of solving this issue.
Greetings, Heiko
The few mirrors which sync first would have quite much higher bandwidth usage =).
The concern then is that in the period of time between uploading of packages and updating of db, the db would point to a package (foo-1.3) while the mirror would only have the new version (foo-1.4), since I don't think many mirrors keep multiple copies of the same package (schlunix I know off, any others?). So that would break updating as well, just in a different direction, and this would not be recoverable from.
Maybe a better idea would be to make pacman keep track of the last time it got an updated package list, and if it's beyond a certain point, it starts checking other mirrors (maybe optional "No updates have been found in 5 days, would you like to scan other mirrors for updates?").
The difference I would see is that in the current system an out-of-date mirror is still use-able (no mismatch between db and package as we're discussing). Some would manually change mirrors, but others would not, so the net effect of automating fallover would be to increase load above what it currently is.
Not everyone needs packages right on the day they're uploaded, or runs pacman everyday (I do, though =p)
Not everyone runs pacman every day, but when you do, you expect to get up to date packages.
So should it be a function of the program to make sure that happens? Or is a responsibility of the user? Should the functionality be programmed into pacman to make sure that happens, or should we be asking that users be aware of what repos they're using?
On Sun, 2009-12-13 at 03:31 -0500, Qadri wrote:
On Sun, Dec 13, 2009 at 2:07 AM, Brendan Long <korin43@gmail.com> wrote:
On Sat, 2009-12-12 at 17:08 -0700, Brendan Long wrote:
2009/12/11 Ng Oon-Ee <ngoonee@gmail.com>
On Sat, 2009-12-12 at 02:13 +0100, Heiko Baums wrote:
Am Sat, 12 Dec 2009 08:58:17 +0800 schrieb Ng Oon-Ee <ngoonee@gmail.com>:
> Because sometimes all the mirrors listed in mirrorlist will not have > the file, if its just been uploaded. Also not everyone stays > up-to-the-minute with updates, judging by the "updated after a month" > posts we see once in a while. > > I'm concerned about the last bit, if a package was just uploaded and > only exists on one mirror, everyone who updates and has that
On Sun, 2009-12-13 at 11:16 +0800, Ng Oon-Ee wrote: package
> in the period between its uploading and its appearance on their local > mirrors will 'fall-back' on varying mirrors (lengthening the update > process) and all end up on the poor main server (or Tier 1/2 mirrors). > Bad for both the mirror bandwidth as well as most probably much slower > for the user, who could probably just wait a day or so for the update > to come to his (faster, presumably) local mirror.
Wouldn't it be possible to first upload the packages and update the db files when the packages on the mirrors (at least on several mirrors) are updated?
If I have such a "problem" that a package is on no mirrors, which doesn't happen often, I usually abort the system update and wait one day. I think that's the normal and easiest way of solving this issue.
Greetings, Heiko
The few mirrors which sync first would have quite much higher bandwidth usage =).
The concern then is that in the period of time between uploading of packages and updating of db, the db would point to a package (foo-1.3) while the mirror would only have the new version (foo-1.4), since I don't think many mirrors keep multiple copies of the same package (schlunix I know off, any others?). So that would break updating as well, just in a different direction, and this would not be recoverable from.
Maybe a better idea would be to make pacman keep track of the last time it got an updated package list, and if it's beyond a certain point, it starts checking other mirrors (maybe optional "No updates have been found in 5 days, would you like to scan other mirrors for updates?").
The difference I would see is that in the current system an out-of-date mirror is still use-able (no mismatch between db and package as we're discussing). Some would manually change mirrors, but others would not, so the net effect of automating fallover would be to increase load above what it currently is.
Not everyone needs packages right on the day they're uploaded, or runs pacman everyday (I do, though =p)
Not everyone runs pacman every day, but when you do, you expect to get up to date packages.
So should it be a function of the program to make sure that happens? Or is a responsibility of the user? Should the functionality be programmed into pacman to make sure that happens, or should we be asking that users be aware of what repos they're using?
Well said, I agree. I believe that if separate db and package downloads are implemented it should not be so users can be 'up-to-the-minute' in packages, but for greater security. In fact, now that I think about it, having two dbs (one on the mirror with all packages as available on that mirror and one 'master' with a list of authoritative checksums) would make sense, as it fulfils the security aspect well while avoiding the problem of db/package mismatch. The 'master' db would have to have a history of previous checksums as well.
On 13/12/09 08:48, Ng Oon-Ee wrote:
On Sun, 2009-12-13 at 03:31 -0500, Qadri wrote:
So should it be a function of the program to make sure that happens? Or is a responsibility of the user? Should the functionality be programmed into pacman to make sure that happens, or should we be asking that users be aware of what repos they're using?
Well said, I agree. I believe that if separate db and package downloads are implemented it should not be so users can be 'up-to-the-minute' in packages, but for greater security.
In fact, now that I think about it, having two dbs (one on the mirror with all packages as available on that mirror and one 'master' with a list of authoritative checksums) would make sense, as it fulfils the security aspect well while avoiding the problem of db/package mismatch. The 'master' db would have to have a history of previous checksums as well.
One possible alternative to explicitly storing a history of checksums is to checksum the dbfile, and name it as such. instead of core.db.tar.gz, you'd have have core.[checksum].db.tar.gz and these would be stored for some time on the master. In order to make it secure the standard checksums would have to be upgraded to something with less collisions than md5. Of-course this also raises the question of 'what happens when the master goes down?'.
On 12/13/2009 10:02 AM, Nathan Wayde wrote:
On 13/12/09 08:48, Ng Oon-Ee wrote:
On Sun, 2009-12-13 at 03:31 -0500, Qadri wrote:
So should it be a function of the program to make sure that happens? Or is a responsibility of the user? Should the functionality be programmed into pacman to make sure that happens, or should we be asking that users be aware of what repos they're using?
Well said, I agree. I believe that if separate db and package downloads are implemented it should not be so users can be 'up-to-the-minute' in packages, but for greater security.
In fact, now that I think about it, having two dbs (one on the mirror with all packages as available on that mirror and one 'master' with a list of authoritative checksums) would make sense, as it fulfils the security aspect well while avoiding the problem of db/package mismatch. The 'master' db would have to have a history of previous checksums as well.
One possible alternative to explicitly storing a history of checksums is to checksum the dbfile, and name it as such. instead of core.db.tar.gz, you'd have have core.[checksum].db.tar.gz and these would be stored for some time on the master. In order to make it secure the standard checksums would have to be upgraded to something with less collisions than md5. Of-course this also raises the question of 'what happens when the master goes down?'.
I'm following this topic, and I a bit with Qadri. I think it should be/stay the responsibility of the user. My solution to get up-to-the-minute packages is very simple: -put ftp.archlinux.org on top of the mirrorlist -do pacman -Sy -comment ftp.archlinux.org out of the mirrorlist -do pacman -Su And then it goes through the list of servers for the latest packages. Change the way how the mirrors and how updating works is unnecessary IMHO. -- Jeroen Op 't Eynde jeroen@xprsyrslf.be http://xprsyrslf.be How to set up a cheap professional hosting @ XprsYrslf.be See my latest work: www.jhdeput.be
Jeroen Op 't Eynde wrote:
On 12/13/2009 10:02 AM, Nathan Wayde wrote:
On 13/12/09 08:48, Ng Oon-Ee wrote:
On Sun, 2009-12-13 at 03:31 -0500, Qadri wrote:
So should it be a function of the program to make sure that happens? Or is a responsibility of the user? Should the functionality be programmed into pacman to make sure that happens, or should we be asking that users be aware of what repos they're using?
Well said, I agree. I believe that if separate db and package downloads are implemented it should not be so users can be 'up-to-the-minute' in packages, but for greater security.
In fact, now that I think about it, having two dbs (one on the mirror with all packages as available on that mirror and one 'master' with a list of authoritative checksums) would make sense, as it fulfils the security aspect well while avoiding the problem of db/package mismatch. The 'master' db would have to have a history of previous checksums as well.
One possible alternative to explicitly storing a history of checksums is to checksum the dbfile, and name it as such. instead of core.db.tar.gz, you'd have have core.[checksum].db.tar.gz and these would be stored for some time on the master. In order to make it secure the standard checksums would have to be upgraded to something with less collisions than md5. Of-course this also raises the question of 'what happens when the master goes down?'.
I'm following this topic, and I a bit with Qadri. I think it should be/stay the responsibility of the user. My solution to get up-to-the-minute packages is very simple: -put ftp.archlinux.org on top of the mirrorlist -do pacman -Sy -comment ftp.archlinux.org out of the mirrorlist -do pacman -Su And then it goes through the list of servers for the latest packages.
Change the way how the mirrors and how updating works is unnecessary IMHO.
ftp.archlinux.org is technically a mirror and is not even the most up to date mirror most of the time...
On 12/13/2009 12:08 PM, Allan McRae wrote:
Jeroen Op 't Eynde wrote:
On 12/13/2009 10:02 AM, Nathan Wayde wrote:
On 13/12/09 08:48, Ng Oon-Ee wrote:
On Sun, 2009-12-13 at 03:31 -0500, Qadri wrote:
So should it be a function of the program to make sure that happens? Or is a responsibility of the user? Should the functionality be programmed into pacman to make sure that happens, or should we be asking that users be aware of what repos they're using?
Well said, I agree. I believe that if separate db and package downloads are implemented it should not be so users can be 'up-to-the-minute' in packages, but for greater security.
In fact, now that I think about it, having two dbs (one on the mirror with all packages as available on that mirror and one 'master' with a list of authoritative checksums) would make sense, as it fulfils the security aspect well while avoiding the problem of db/package mismatch. The 'master' db would have to have a history of previous checksums as well.
One possible alternative to explicitly storing a history of checksums is to checksum the dbfile, and name it as such. instead of core.db.tar.gz, you'd have have core.[checksum].db.tar.gz and these would be stored for some time on the master. In order to make it secure the standard checksums would have to be upgraded to something with less collisions than md5. Of-course this also raises the question of 'what happens when the master goes down?'.
I'm following this topic, and I a bit with Qadri. I think it should be/stay the responsibility of the user. My solution to get up-to-the-minute packages is very simple: -put ftp.archlinux.org on top of the mirrorlist -do pacman -Sy -comment ftp.archlinux.org out of the mirrorlist -do pacman -Su And then it goes through the list of servers for the latest packages.
Change the way how the mirrors and how updating works is unnecessary IMHO.
ftp.archlinux.org is technically a mirror and is not even the most up to date mirror most of the time...
Ok, good to know that than. Could anyone point me to most up to date mirror maybe, so my solution would be successful? Or is that the problem we're discussing in this topic? The servers below seem to be stay very up-to-date according to https://www.archlinux.de/?page=MirrorStatus ftp://mirror.giantix-server.de/archlinux/$repo/os/x86_64 ftp://mirrors.kernel.org/archlinux/ -- Jeroen Op 't Eynde jeroen@xprsyrslf.be http://xprsyrslf.be How to set up a cheap professional hosting @ XprsYrslf.be See my latest work: www.jhdeput.be
On Sun, 2009-12-13 at 12:07 +0100, Jeroen Op 't Eynde wrote:
On 12/13/2009 10:02 AM, Nathan Wayde wrote:
On 13/12/09 08:48, Ng Oon-Ee wrote:
On Sun, 2009-12-13 at 03:31 -0500, Qadri wrote:
So should it be a function of the program to make sure that happens? Or is a responsibility of the user? Should the functionality be programmed into pacman to make sure that happens, or should we be asking that users be aware of what repos they're using?
Well said, I agree. I believe that if separate db and package downloads are implemented it should not be so users can be 'up-to-the-minute' in packages, but for greater security.
In fact, now that I think about it, having two dbs (one on the mirror with all packages as available on that mirror and one 'master' with a list of authoritative checksums) would make sense, as it fulfils the security aspect well while avoiding the problem of db/package mismatch. The 'master' db would have to have a history of previous checksums as well.
One possible alternative to explicitly storing a history of checksums is to checksum the dbfile, and name it as such. instead of core.db.tar.gz, you'd have have core.[checksum].db.tar.gz and these would be stored for some time on the master. In order to make it secure the standard checksums would have to be upgraded to something with less collisions than md5. Of-course this also raises the question of 'what happens when the master goes down?'.
I'm following this topic, and I a bit with Qadri. I think it should be/stay the responsibility of the user. My solution to get up-to-the-minute packages is very simple: -put ftp.archlinux.org on top of the mirrorlist -do pacman -Sy -comment ftp.archlinux.org out of the mirrorlist -do pacman -Su And then it goes through the list of servers for the latest packages.
Change the way how the mirrors and how updating works is unnecessary IMHO.
Aren't you doing exactly what's being proposed (check the master for the package list, then download from a faster mirror), just manually? If you think that it's the best way to do things, why not make it automatic?
On 12/13/2009 10:33 PM, Brendan Long wrote:
On Sun, 2009-12-13 at 12:07 +0100, Jeroen Op 't Eynde wrote:
On 12/13/2009 10:02 AM, Nathan Wayde wrote:
On 13/12/09 08:48, Ng Oon-Ee wrote:
On Sun, 2009-12-13 at 03:31 -0500, Qadri wrote:
So should it be a function of the program to make sure that happens? Or is a responsibility of the user? Should the functionality be programmed into pacman to make sure that happens, or should we be asking that users be aware of what repos they're using?
Well said, I agree. I believe that if separate db and package downloads are implemented it should not be so users can be 'up-to-the-minute' in packages, but for greater security.
In fact, now that I think about it, having two dbs (one on the mirror with all packages as available on that mirror and one 'master' with a list of authoritative checksums) would make sense, as it fulfils the security aspect well while avoiding the problem of db/package mismatch. The 'master' db would have to have a history of previous checksums as well.
One possible alternative to explicitly storing a history of checksums is to checksum the dbfile, and name it as such. instead of core.db.tar.gz, you'd have have core.[checksum].db.tar.gz and these would be stored for some time on the master. In order to make it secure the standard checksums would have to be upgraded to something with less collisions than md5. Of-course this also raises the question of 'what happens when the master goes down?'.
I'm following this topic, and I a bit with Qadri. I think it should be/stay the responsibility of the user. My solution to get up-to-the-minute packages is very simple: -put ftp.archlinux.org on top of the mirrorlist -do pacman -Sy -comment ftp.archlinux.org out of the mirrorlist -do pacman -Su And then it goes through the list of servers for the latest packages.
Change the way how the mirrors and how updating works is unnecessary IMHO.
Aren't you doing exactly what's being proposed (check the master for the package list, then download from a faster mirror), just manually? If you think that it's the best way to do things, why not make it automatic?
I'm doing basically the same manually, yes. It was in an answer to the question of Qadri. Damn, when I my email again it seems I forgot to type some words, I'm dyslectic, sorry. Well, to respond to your question: I'm not always interested in doing it that way, I just do it when I'm impatient to get a new package or something. Mostly I just update from more local servers, which have a database at an age of few hours or sometimes a 24 hours. -- Jeroen Op 't Eynde jeroen@xprsyrslf.be http://xprsyrslf.be How to set up a cheap professional hosting @ XprsYrslf.be See my latest work: www.jhdeput.be
On Sun, 2009-12-13 at 14:33 -0700, Brendan Long wrote:
On Sun, 2009-12-13 at 12:07 +0100, Jeroen Op 't Eynde wrote:
On 12/13/2009 10:02 AM, Nathan Wayde wrote:
On 13/12/09 08:48, Ng Oon-Ee wrote:
On Sun, 2009-12-13 at 03:31 -0500, Qadri wrote:
So should it be a function of the program to make sure that happens? Or is a responsibility of the user? Should the functionality be programmed into pacman to make sure that happens, or should we be asking that users be aware of what repos they're using?
Well said, I agree. I believe that if separate db and package downloads are implemented it should not be so users can be 'up-to-the-minute' in packages, but for greater security.
In fact, now that I think about it, having two dbs (one on the mirror with all packages as available on that mirror and one 'master' with a list of authoritative checksums) would make sense, as it fulfils the security aspect well while avoiding the problem of db/package mismatch. The 'master' db would have to have a history of previous checksums as well.
One possible alternative to explicitly storing a history of checksums is to checksum the dbfile, and name it as such. instead of core.db.tar.gz, you'd have have core.[checksum].db.tar.gz and these would be stored for some time on the master. In order to make it secure the standard checksums would have to be upgraded to something with less collisions than md5. Of-course this also raises the question of 'what happens when the master goes down?'.
I'm following this topic, and I a bit with Qadri. I think it should be/stay the responsibility of the user. My solution to get up-to-the-minute packages is very simple: -put ftp.archlinux.org on top of the mirrorlist -do pacman -Sy -comment ftp.archlinux.org out of the mirrorlist -do pacman -Su And then it goes through the list of servers for the latest packages.
Change the way how the mirrors and how updating works is unnecessary IMHO.
Aren't you doing exactly what's being proposed (check the master for the package list, then download from a faster mirror), just manually? If you think that it's the best way to do things, why not make it automatic?
Low-level tools for more control over what's going on is in this case preferable to a large automated app, in my opinion.
As far as I've understand the main problem, it's about mirror which are not up-to-date. So could it be possible to make a dummy package of the day ? Every morning, the main server will produce a dummy package containing the today's timestamp. So if the dummy package is 3 days old, this means that the master mirror is down, or that the mirror haven't synced since 3 days. After this, it's easy to ask to pacman to print an error message if the dummy package is 3 or 7 or whatever you have said to pacman days old. -- Cordialement, Coues Ludovic 06 148 743 42 -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments
Am Sun, 13 Dec 2009 09:02:16 +0000 schrieb Nathan Wayde <kumyco@konnichi.com>:
Of-course this also raises the question of 'what happens when the master goes down?'.
Or gets hacked? Greetings, Heiko
On Sun, Dec 13, 2009 at 12:49 PM, Heiko Baums <lists@baums-on-web.de> wrote:
Am Sun, 13 Dec 2009 09:02:16 +0000 schrieb Nathan Wayde <kumyco@konnichi.com>:
Of-course this also raises the question of 'what happens when the master goes down?'.
Or gets hacked?
The changes you talked about don't really make that problem any worse than it already is. If master goes down or gets hacked, all mirrors are syncing from it anyway (directly or indirectly) so you are fucked. If you worry about it going down, then you provide other masters (you can give money or hardware or hosting) If you worry about getting hacked, you use signatures (you can give money or code)
On 13/12/09 12:02, Xavier wrote:
On Sun, Dec 13, 2009 at 12:49 PM, Heiko Baums<lists@baums-on-web.de> wrote:
Am Sun, 13 Dec 2009 09:02:16 +0000 schrieb Nathan Wayde<kumyco@konnichi.com>:
Of-course this also raises the question of 'what happens when the master goes down?'.
Or gets hacked?
The changes you talked about don't really make that problem any worse than it already is. If master goes down or gets hacked, all mirrors are syncing from it anyway (directly or indirectly) so you are fucked.
If you worry about it going down, then you provide other masters (you can give money or hardware or hosting) If you worry about getting hacked, you use signatures (you can give money or code)
Then i propose another spin on it, layer the extra checksums on top of what is there now. Store a copy of the db file as e.g [checksum].db, this goes on a set of master servers, when the user syncs with their mirror a checksum is generated based on the db file that was downloaded, this checksum is then used to get a the [checksum].db from a master server and this new [checksum].db file is used to do the sync update. The issue of a master going down is gone, if you really cannot download from a master then let the user decides what they want to do - you have a copy of a proper .db file so you could use it if the user decides they want to. In the event that that a corresponding [checksum].db does not exist on a master then you know something has gone wrong. I can't imagine a master would be out of date compared to another mirror (remember this is about storage of the db files, not packages the idea is that [checksum].db would be uploaded first) but in case it was then you could just add a timestamp inside the .db (.lastupdate?) for extra verification. That on on top signing sounds almost perfect to me.
participants (30)
-
Aaron Griffin
-
Allan McRae
-
André Ramaciotti da Silva
-
Arvid Picciani
-
Brendan Long
-
Ciprian Dorin, Craciun
-
David C. Rankin
-
David Rosenstrauch
-
Denis A. Altoé Falqueto
-
Denis Kobozev
-
Dieter Plaetinck
-
Dwight Schauer
-
Felipe Tanus
-
fons＠kokkinizita.net
-
Guus Snijders
-
Heiko Baums
-
Jan de Groot
-
Jeroen Op 't Eynde
-
ludovic coues
-
Nathan Wayde
-
Ng Oon-Ee
-
Pierre Chapuis
-
Qadri
-
Raghavendra Prabhu
-
Rogutės Sparnuotos
-
Ryan Sims
-
Shridhar Daithankar
-
Smith Dhumbumroong
-
Ty John
-
Xavier