Re: [arch-general] [OT] What is wrong with DBus anyway?
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 not allowed inside 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/sy
Re: [arch-general] [OT] What is wrong with DBus anyway?
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: (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. ;) [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
Re: [arch-general] [OT] What is wrong with DBus anyway?
Le Fri, 4 Dec 2009 23:26:27 +0100, Xavier 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
Re: [arch-general] [OT] What is wrong with DBus anyway?
Le Sat, 05 Dec 2009 00:34:59 +0100, Jan de Groot 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
Re: [arch-general] [OT] What is wrong with DBus anyway?
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 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. > >
Re: [arch-general] [OT] What is wrong with DBus anyway?
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.
Re: [arch-general] [OT] What is wrong with DBus anyway?
gedit --help shows --new-window. I don't see what issue is Dwight On Fri, Dec 4, 2009 at 5:07 PM, Heiko Baums wrote: > Am Fri, 4 Dec 2009 23:38:02 +0100 > schrieb f...@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 >
Re: [arch-general] [OT] What is wrong with DBus anyway?
Am Fri, 4 Dec 2009 23:38:02 +0100 schrieb f...@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
Re: [arch-general] [OT] What is wrong with DBus anyway?
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 ?
Re: [arch-general] [OT] What is wrong with DBus anyway?
Xavier wrote: On Fri, Dec 4, 2009 at 10:59 PM, David Rosenstrauch 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 Well, at least something came out of this thread...
Re: [arch-general] [OT] What is wrong with DBus anyway?
On Fri, Dec 04, 2009 at 10:55:32PM +0100, Heiko Baums wrote: > Am Fri, 4 Dec 2009 22:11:08 +0100 > schrieb f...@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 ?
Re: [arch-general] [OT] What is wrong with DBus anyway?
On Fri, Dec 4, 2009 at 10:59 PM, David Rosenstrauch 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
Re: [arch-general] [OT] What is wrong with DBus anyway?
On 12/04/2009 04:11 PM, f...@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
Re: [arch-general] [OT] What is wrong with DBus anyway?
Am Fri, 4 Dec 2009 22:11:08 +0100 schrieb f...@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
Re: [arch-general] [OT] What is wrong with DBus anyway?
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 ?
Re: [arch-general] [OT] What is wrong with DBus anyway?
On 12/04/2009 03:50 PM, f...@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
Re: [arch-general] [OT] What is wrong with DBus anyway?
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 ?
Re: [arch-general] [OT] What is wrong with DBus anyway?
On Fri, 04 Dec 2009 20:07:24 +0100 Arvid Picciani 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.
Re: [arch-general] [OT] What is wrong with DBus anyway?
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
Re: [arch-general] [OT] What is wrong with DBus anyway?
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
Re: [arch-general] [OT] What is wrong with DBus anyway?
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 disa
Re: [arch-general] [OT] What is wrong with DBus anyway?
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 th
Re: [arch-general] [OT] What is wrong with DBus anyway?
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 > > (0x7f5df48bb000) > > libdbus-1.so.3 => /usr/lib/libdbus-1.so.3 (0x7f5df467c000) > > > > 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.
Re: [arch-general] [OT] What is wrong with DBus anyway?
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.
Re: [arch-general] [OT] What is wrong with DBus anyway?
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.
Re: [arch-general] [OT] What is wrong with DBus anyway?
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. 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. -- Shridhar
Re: [arch-general] [OT] What is wrong with DBus anyway?
On Fri, Dec 4, 2009 at 2:40 AM, Brendan Long 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 ---
Re: [arch-general] [OT] What is wrong with DBus anyway?
> 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 signature.asc Description: This is a digitally signed message part
Re: [arch-general] [OT] What is wrong with DBus anyway?
On Fri, Dec 4, 2009 at 12:49 AM, Arvid Picciani 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 ---
Re: [arch-general] [OT] What is wrong with DBus anyway?
Denis A. Altoé Falqueto wrote: 2009/12/4 Arvid Picciani : 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
Re: [arch-general] [OT] What is wrong with DBus anyway?
2009/12/4 Arvid Picciani : > 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 ---
Re: [arch-general] [OT] What is wrong with DBus anyway?
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?
Re: [arch-general] [OT] What is wrong with DBus anyway?
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
Re: [arch-general] [OT] What is wrong with DBus anyway?
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." f...@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
Re: [arch-general] [OT] What is wrong with DBus anyway?
On Thu, Dec 3, 2009 at 11:07 PM, 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 ---
Re: [arch-general] [OT] What is wrong with DBus anyway?
On Fri, 4 Dec 2009 00:31:39 + Pierre Chapuis wrote: > Le Fri, 4 Dec 2009 10:33:38 +1030, > Ty John 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 ;)
Re: [arch-general] [OT] What is wrong with DBus anyway?
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
Re: [arch-general] [OT] What is wrong with DBus anyway?
Le Fri, 4 Dec 2009 10:33:38 +1030, Ty John 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
Re: [arch-general] [OT] What is wrong with DBus anyway?
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
Re: [arch-general] [OT] What is wrong with DBus anyway?
On Thu, Dec 3, 2009 at 7:55 PM, 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 ---
Re: [arch-general] [OT] What is wrong with DBus anyway?
On Thu, 3 Dec 2009 22:58:08 + Pierre Chapuis wrote: > Le Thu, 3 Dec 2009 20:41:26 -0200, > Denis A. Altoé Falqueto a écrit : > > > On Thu, Dec 3, 2009 at 4:14 PM, Arvid Picciani 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?
Re: [arch-general] [OT] What is wrong with DBus anyway?
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 > > (0x7f5df48bb000) > > libdbus-1.so.3 => /usr/lib/libdbus-1.so.3 (0x7f5df467c000) > > > > 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?
Re: [arch-general] [OT] What is wrong with DBus anyway?
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 (0x7f5df48bb000) libdbus-1.so.3 => /usr/lib/libdbus-1.so.3 (0x7f5df467c000) 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
Re: [arch-general] [OT] What is wrong with DBus anyway?
Le Thu, 3 Dec 2009 21:58:25 +0100, Xavier a écrit : > On Thu, Dec 3, 2009 at 9:32 PM, Pierre Chapuis 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 (0x7f5df48bb000) libdbus-1.so.3 => /usr/lib/libdbus-1.so.3 (0x7f5df467c000) 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
Re: [arch-general] [OT] What is wrong with DBus anyway?
On Thu, 2009-12-03 at 22:55 +0100, f...@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.
Re: [arch-general] [OT] What is wrong with DBus anyway?
Le Thu, 3 Dec 2009 20:41:26 -0200, Denis A. Altoé Falqueto a écrit : > On Thu, Dec 3, 2009 at 4:14 PM, Arvid Picciani 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
Re: [arch-general] [OT] What is wrong with DBus anyway?
On Thu, Dec 3, 2009 at 4:14 PM, Arvid Picciani 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 ---
Re: [arch-general] [OT] What is wrong with DBus anyway?
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-741455.html On Fri, Dec 4, 2009 at 3:25 AM, 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 >
Re: [arch-general] [OT] What is wrong with DBus anyway?
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
Re: [arch-general] [OT] What is wrong with DBus anyway?
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 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 >
Re: [arch-general] [OT] What is wrong with DBus anyway?
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
Re: [arch-general] [OT] What is wrong with DBus anyway?
On Thu, Dec 3, 2009 at 9:32 PM, Pierre Chapuis 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.
Re: [arch-general] [OT] What is wrong with DBus anyway?
On 12/03/2009 01:19 PM, Nathan Wayde wrote: On 03/12/09 18:14, Arvid Picciani wrote: - most software depending on it, will crash when dbus crashes, or fail to start uncracefully, or behave unexpected. i've honestly never seen dbus crash +1. Ever. DR
Re: [arch-general] [OT] What is wrong with DBus anyway?
On Thu, 3 Dec 2009 20:32:46 + Pierre Chapuis 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
Re: [arch-general] [OT] What is wrong with DBus anyway?
Le Thu, 3 Dec 2009 17:05:18 -0200, Denis A. Altoé Falqueto 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
Re: [arch-general] [OT] What is wrong with DBus anyway?
On Thu, Dec 3, 2009 at 5:14 PM, Denis A. Altoé Falqueto 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 ---
Re: [arch-general] [OT] What is wrong with DBus anyway?
On Thu, Dec 3, 2009 at 5:11 PM, André Ramaciotti da Silva 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 ---
Re: [arch-general] [OT] What is wrong with DBus anyway?
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 > 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. :)
Re: [arch-general] [OT] What is wrong with DBus anyway?
On Thu, Dec 3, 2009 at 4:53 PM, André Ramaciotti da Silva 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 ---
Re: [arch-general] [OT] What is wrong with DBus anyway?
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?
Re: [arch-general] [OT] What is wrong with DBus anyway?
On Thu, Dec 3, 2009 at 4:14 PM, Arvid Picciani 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 ---
Re: [arch-general] [OT] What is wrong with DBus anyway?
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
Re: [arch-general] [OT] What is wrong with DBus anyway?
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
Re: [arch-general] [OT] What is wrong with DBus anyway?
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
Re: [arch-general] [OT] What is wrong with DBus anyway?
On Thu, Dec 3, 2009 at 7:42 PM, Denis A. Altoé Falqueto wrote: > On Thu, Dec 3, 2009 at 3:38 PM, Felipe Tanus 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.
Re: [arch-general] [OT] What is wrong with DBus anyway?
On Thu, Dec 3, 2009 at 3:38 PM, Felipe Tanus 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 ---
Re: [arch-general] [OT] What is wrong with DBus anyway?
2009/12/3 Aaron Griffin : > On Thu, Dec 3, 2009 at 11:06 AM, Denis A. Altoé Falqueto > 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: fota...@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
Re: [arch-general] [OT] What is wrong with DBus anyway?
On Thu, Dec 3, 2009 at 11:06 AM, Denis A. Altoé Falqueto 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.
[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 ---
