Solved What happen if I don't enable dbus service?

  • Thread starter Deleted member 63539
  • Start date
D

Deleted member 63539

Guest
As usual, I would add these lines to /etc/rc.conf and reboot to my new desktop:
Code:
dbus_enable="YES"
hald_enable="YES"
This time I tried to comment them out and to my surprise, my desktop worked without any problems!

But I found on dmesg there is something regarding the system dbus service being not start.

I don't know if running with these two lines commented out could have negative affect my system or not.

Please let me know. Thanks.
 
Last edited by a moderator:
The only time dbus is needed is the first time you start your new desktop.
polkit requires a machine-id. This is generated by dbus.
So if you don't want dbus then all you have to do is run dbus once on first time starting desktop.
service dbus onestart will do the trick.
/var/lib/dbus/machine-id

You will find that some things don't work without dbus enabled.
 
The only time dbus is needed is the first time you start your new desktop.
polkit requires a machine-id. This is generated by dbus.
So if you don't want dbus then all you have to do is run dbus once on first time starting desktop.
service dbus onestart will do the trick.
/var/lib/dbus/machine-id

You will find that some things don't work without dbus enabled.
Hi. It seemed mate started dbus automatically. It's run with my account's privilege, though, not root.

When I run ps aux | grep dbus I found this:

/usr/local/bin/dbus-daemon --syslog --fork --print-pid 5 --print-address 7 --session
/usr/local/bin/dbus-daemon --config-file=/usr/local/share/defaults/at-spi2/accessibility.conf --n
dbus-launch --exit-with-session mate-session
 
I've had dbus disabled for years and not noticed any untoward side-effects. Note that I still use twm as my Window Manager.
After I studied the dmesg I think I would rather enable dbus system wide. All of the error messages disappear. If you use a desktop environment such as MATE like me, you could let hald disabled but dbus must be enabled. So the answer of this thread is, you should enable dbus, if you don't, it still runs but could malfunction.
 
hald and d-bus are linux-isms for making hardware detection/plug and play easier
imo they suck, bsd has alternatives to these. or hald at least
 
hald and d-bus are linux-isms for making hardware detection/plug and play easier
imo they suck, bsd has alternatives to these. or hald at least
Yes, but the maintainers already have too much hazzle to cope w/ all the other linuxisms in GUIs. For shure in principle it should be possible to substitute usage of hald(8) with devd(8), but do not underestimate all those f*g details...
 
There are generally two instances of dbus. A system-wide one and a user one.

The system-wide one is that dbus_enable in rc.conf

The user one is either started by Linux desktop environments or you should do it manually in your .xsession / .xinitrc via dbus-launch.

The system-wide one is important to be able to do things like shutdown, eject devices, change network from the desktop. However FOSS desktops are so broken that this rarely works anyway.

The user one is for app-specific ones like telling file managers to refresh is a file gets moved, or to ensure that there is only one instance of an application running and things like that. Software usually has workarounds rendering it not very necessary.
 
There are generally two instances of dbus. A system-wide one and a user one.

The system-wide one is that dbus_enable in rc.conf

The user one is either started by Linux desktop environments or you should do it manually in your .xsession / .xinitrc via dbus-launch.

The system-wide one is important to be able to do things like shutdown, eject devices, change network from the desktop. However FOSS desktops are so broken that this rarely works anyway.

The use one is for app-specific ones like telling file managers to refresh is a file gets moved, or to ensure that there is only one instance of an application running and things like that. Software usually has workarounds rendering it not very necessary.

if you stated that truth in a linux forum you would be flogged
you are so right though
too bad broken garbage like kde seems to be the only way to get a file picker/uploader on firefox that can display scaled thumbnais right now..
 
You will find that some things don't work without dbus enabled.

I wonder how these things managed to work over the last thirty years without dbus.

Plug out & in your USB keyboard. Plug in a USB stick or printer, MP3-player etc.pp. Then you'll notice different behaviour of your GUI.

Should the GUI change their behaviour when something is plugged?

I think it depends - maybe you want a gadget that focuses on just providing a display for whatever might happen (but then there are probably more appropriate software-suites to run such a thing). Or otherwise, maybe you consider the display just one hardware/software component among many that are operated on a system - and then that should probably function as configured, and not change their behaviour in irreproducible fashions at their own discretion.
 
I think it depends - maybe you want a gadget that focuses on just providing a display for whatever might happen (but then there are probably more appropriate software-suites to run such a thing). Or otherwise, maybe you consider the display just one hardware/software component among many that are operated on a system - and then that should probably function as configured, and not change their behaviour in irreproducible fashions at their own discretion.

You point is? Are you also against tray icons?
 
Trash bin? That exists on MacOS X. On unix we have rm(), and rm does not need a trash bin, because the stuff is gone afterwards.

BTW, on X a trash bin would be difficult to design, because X is a network application: the machine that has the screen attached could be different from the one that runs the display manager and again different from those running the applications. So what is expected to go into a "trash bin", and from which machine??

This is all just windows mind-poisoning. They got stuck at the minicomputers, that is: load an application from the floppy and then show the user what has been loaded. They never ever understood what an OS is supposed to do, and even less what distributed computing would mean.
 
Ahem, the tray is a certain desktop UI thing introduced with Windows 95. You might have seen one.

Never got there. Switched to Unix in 1990, from MSDOS 3.2.
Reason was: MSDOS couldn't handle two simultanous uplinks while letting me work on the system at the same time. Unix could, because unix is an OS. (Windows would not do well on that either. It would just provide some eye-candy while being as broken as before.)
 
Trash bin? That exists on MacOS X. On unix we have rm(), and rm does not need a trash bin, because the stuff is gone afterwards.

BTW, on X a trash bin would be difficult to design, because X is a network application: the machine that has the screen attached could be different from the one that runs the display manager and again different from those running the applications. So what is expected to go into a "trash bin", and from which machine??

This is all just windows mind-poisoning. They got stuck at the minicomputers, that is: load an application from the floppy and then show the user what has been loaded. They never ever understood what an OS is supposed to do, and even less what distributed computing would mean.

The trash is located at /home/{user}/.local.share.Trash it is activated by gio trash (I think part of the gvfs package?) which I believe is dependent on dbus. I personally do not use dbus but set up commands using mv and rm.
 
The trash is located at /home/{user}/.local.share.Trash it is activated by gio trash (I think part of the gvfs package?)

Okay. The difficulty with these things is (say, even if you run a machine in workstation mode, i.e., working mostly on the local system as the login-user with locally installed applications), all your applications have to play nice with these features, and use all the same tools.

Once upon a time, I gave it a try with those fancy "window managers". My conclusion then was, no matter which one, we could spend months or years trying to fix and integrate all the missing pieces, to get it all to work in a smooth and consistent fashion. So I gave up on that, because I think it's better to have a limited functionality that can be relied upon, than to have ample features that happen to work only sometimes. So, for more than 15 years I am now using x11-wm/icewm, and no problems.

The remaining issue is those programs that are trying to work with some toolkit. This is mostly noticeable when they spam the homedir with dubious and unintellegible file trees, or, worse, when they try to talk to dubious and unintellegibe system services (like that dbus - which is just none of their business). I usually have quite some work getting as much as possible of these switched off via the port's config options.

Now considering that trash bin: so you need dbus to make it work sometimes - namely, for those programs that would support it. Concluding, without dbus it does always not work, and with dbus it may or may not work depending on the application. Now which one is better?
I for my part think that somthing reliably not working is still better than something where we do not know if or when it works. Specifically if that is about safety: if we throw something away and do not know if we can get it back or not, then that is no different to just not being able to get it back.

So, I for my part have a backup solution instead of a trash bin. And backup is run every 10 minutes.
(Thats because I was envious of the VAX VMS: they can do versioning on the filesystem files. I can't do that, neither on UFS nor ZFS. But I can run incremental backup frequently enough that it will protect me from erroneously reverted edits, accidentially deleted work, and the like.)
 
Trash bin? That exists on MacOS X. On unix we have rm(), and rm does not need a trash bin, because the stuff is gone afterwards.

BTW, on X a trash bin would be difficult to design, because X is a network application: the machine that has the screen attached could be different from the one that runs the display manager and again different from those running the applications. So what is expected to go into a "trash bin", and from which machine??

This is all just windows mind-poisoning. They got stuck at the minicomputers, that is: load an application from the floppy and then show the user what has been loaded. They never ever understood what an OS is supposed to do, and even less what distributed computing would mean.

This is off topic but I am curious about your OS time line
what variant of unix did you use? do you use the *BSD variants now?
I was unfortunate enough for my first taste of nix to be trash like linux
 
This is off topic but I am curious about your OS time line
what variant of unix did you use? do you use the *BSD variants now?

you're welcome. Originally, I was into electronics, as a hobby, first. I had production equipment for PCB (2-sided). etc. - that all went somehow astray over the decades.
Then, around 1985, I understood that one can build a computer as well (the usual 8-bit "homecomputer" type). But then I didn't need to, because some spare piece came along that was originally designed as a kind of office computer, equipped with a 650X processor. So I figured how that would work, and learned assembler.

Then I got into some people who did buy PC/XT clones from Taiwan to sell them again. Those would run with DOS. And in 1987 I got into some people who knew about the Internet, and I decided that I want that. And that was quite difficult at that time.

So, I had two wires. One was used to dial out and fetch some news. The other was for people to dial in -onto the same machine- and read these news. And meanwhile I intended to read and answer my mails - on the same machine.
DOS cannot do that - if you dial out, the whole computer will be busy with dialing-out, and nothing else can be done meanwhile. But I knew how the computer is built, and that the computer itself whould have no problem in doing all these things at the same time. Only you cannot do it with DOS. You still could not do it with Windows 3. You might have been able to do it with Windows 95, but that would appear only 8 years later, would then require a 32bit machine, and would still be quite hard to get it properly configured - and then you would need to cater for all the useless graphical overhead crap which would not go thru a serial line anyway.

Thats when I learned about unix, and that unix will instantly do all that I wanted, with no overhead at all. That one only needs to connect modems to the serial interfaces, and then getty(8) will already know how to handle these. And that unix can run on 16bit (because the original PDP-11 was nothing else).
Around 1990 that had worked out more or less into something that actually worked and did the things as intended - on an 80286. (Obviousely the unix had also come somehow from Taiwan and I doubt that it was legal.)

1993 I figured out about Linux, and that, being a full release including kernel sources, appeared a lot more promising. But then I started to recognize the downsides; yes, there were sources - but it wasn't clear who would have written which part of them or who would be responsible for any version - if there were intellegible versions at all. It was all just a heap of chaos, or -as others had termed it- an oriental bazaar.
And that was when a friend (and I am very thankful) brought me this CD for chrismas:
Code:
# dir /cdrom
total 176
drwxr-xr-x   9 tty   tty     2048 Dec 22  1995 .
drwxr-xr-x  26 root  wheel    512 Jul 21 09:17 ..
-rw-r--r--   1 tty   tty        0 Dec 19  1995 FreeBSD-2.1.0-RELEASE
-rw-r--r--   1 tty   tty    18782 Dec 18  1995 HARDWARE.TXT
-rw-r--r--   1 tty   tty    26256 Dec 18  1995 INSTALL.TXT
-rw-r--r--   1 tty   tty     5732 Dec 18  1995 MIRROR.SITES
-rw-r--r--   1 tty   tty     5372 Dec 18  1995 README.TXT
-rw-r--r--   1 tty   tty    14797 Dec 18  1995 RELNOTES.TXT
drwxr-xr-x   7 tty   tty    61440 Dec 19  1995 distfiles
drwxr-xr-x  16 tty   tty     2048 Dec 22  1995 dists
drwxr-xr-x   2 tty   tty     2048 Dec 19  1995 docs
drwxr-xr-x   2 tty   tty    28672 Dec 19  1995 incoming
drwxr-xr-x  31 tty   tty     4096 Dec 19  1995 packages
drwxr-xr-x  27 tty   tty     4096 Dec 19  1995 ports
drwxr-xr-x   4 tty   tty     2048 Dec 19  1995 tools

I was looking at that disk (it contains not only the base system, but most of the ports also), and I was thinking: how many man-hours of development have gone into that little thing?
And that basically was it. For a while I was still using FreeBSD and NetBSD in parallel and trying to figure out which would suit me better. But nothing else any more since then.
 
Back
Top