I wish..some applications remove the gtk2 support and change to gtk3, me too, I hate gtk3Is there some flag I can set to get programs to build with gtk2 instead in my make.conf?
Another service I want gone from mysystem anyways.
[Mod: Watch your language]
Nahhh, not transmission-remote. I think the qt/gtk gui ports need it (I don't use them) but transmission-remote uses its own rpc
Seriously, I don't understand why people keep introducing bloat into programs, usually upstream. Like they have a cluttered state of mind.
make install cleanthen from that point on I let it build everything. If it deems it necessary to pull a dependency in I go with what it thinks need pulled in during the build. I enable both in /etc/rc.conf early on so when they are installed they're ready to go when needed.
43402 root 1 52 0 14M 1104K select 2 0:00 0.00% dbus-launch 59551 jitte 1 22 0 14M 1104K select 1 0:00 0.00% dbus-launch 60081 jitte 1 20 0 12M 1632K select 0 0:01 0.00% dbus-daemon 98510 messagebus 1 20 0 13M 1648K select 2 0:00 0.00% dbus-daemon
topshows this load on a AMD Phenom II x 3 N830 Triple Core @ 2.1GHz with 4GB RAM:
Security?Respectfully, I have never understood why people make such a big deal of it or hal.
Imagine, you were the boss of some shop with a couple of employees. Would you like it to have an employee hanging around where you don't know why he was engaged, what would be his specific tasks and what he were actually doing?
That's about the same with a machine you are running, and a couple of daemons engaged to work on that machine.
suto become root, which some see as bad practice but all I have ever used and am comfortable working as. When I work as root it is only work done needed as root and then I log out back into my usr account.
On my system they don't.
devel/dbus-glib devel/qt5-dbus multimedia/audacious-plugins net/glib-networking security/gcr www/qt5-webengine x11-toolkits/qt5-gui accessibility/at-spi2-atk accessibility/at-spi2-core
And sometimes it is.Sometimes worrying about it isn't worth the time.
Reading TFA helps.This is not a dbus security flaw, which is why it's labeled polkit.
Why does killing the dbus-send command cause an authentication bypass? The vulnerability is in step four of the sequence of events listed above. What happens if polkit asks dbus-daemon for the UID of connection :1.96, but connection :1.96 no longer exists? dbus-daemon handles that situation correctly and returns an error. But it turns out that polkit does not handle that error correctly. In fact, polkit mishandles the error in a particularly unfortunate way: rather than rejecting the request, it treats the request as though it came from a process with UID 0. In other words, it immediately authorizes the request because it thinks the request has come from a root process.
I'm not entirely certain what I'm supposed to glean from that article, but here are some gems from a quick scan.
The accidental IPC! I really wanna use it now.While D-Bus does offer 1-to-1 and 1-to-many IPC, it’s more of a byproduct of its original purpose than a mean of efficient process to process data transfer — it isn’t meant to be fast.
How very enterprise! I wonder if it has AbstractFactoryFactories.Its design is heavily influenced by Service Oriented Architectures (SOA), Enterprise Service Buses (ESB), and microkernel architectures.
A bus permits abstracting communication between software, replacing all direct contact, and only allowing them to happen on the bus instead.
Additionally, the SOA allows software to expose objects that have methods that can be called remotely, and also allows other software to subscribe/publish events happening in remote objects residing in other software.
Moreover, D-Bus provides an easy plug-and-play, a loose coupling, where any software could detach itself from the bus and allow another process to be plugged, containing objects that implement the same features the previous process implemented.
Interfaces can be described as standard, and for documentation, in D-Bus XML configuration files so that other programmers can use the reference to implement them properly. These files can also be used to auto-generate classes from the XML, making it quicker to implement and less error-prone.
USE_QT = dbusoption in some qt pkg Makefile.
I'm sorry for that, and I'll take your advice, thanksWhy do people choose 112th anniversary of Chicago's massacre (google that yourselves, I'm not posting links for this one) to post to the forums?
Anyway, DBUS is an implementation of IPC (as pointed out earlier in this thread. So, CanvisMe , I would discourage disabling dbus. It takes a lot of expertise to know about alternative solutions that actually work, and can be used as a drop-in replacement. IPC is vitally important to proper functioning of desktops in FreeBSD. If you don't like DBUS, you'd need to be comfortable with getting down and dirty with the source code of the desktops themselves.
Look upthread:So how can I entirely disable dbus. While I'm using ports to build qt related pkgs, there's
USE_QT = dbusoption in some qt pkg Makefile.