13 ms·

Am I the only one who's disgusted with this bloated, convoluted, dbus-dependent pile of crap? I mean, c'mon, binary log files? I'll pass, thanks. It replaces wa

Am I the only one who's disgusted with this bloated, convoluted, dbus-dependent pile of crap? I mean, c'mon, binary log files? I'll pass, thanks. It replaces way more than it needed to. I prefer the BSD-style philosophy, nice, simple rc.conf, used to run Arch till it got infected with this garbage too. It slowly progressed away from it's BSD-style roots. So recently, I just gave up and moved to FreeBSD. Not a single regret so far.

AceJohnny2 12y ago
> dbus-dependent pile of crap? This seems to come up frequently. I'm curious: how alternatively would a local process communicate with the Init daemon?
- drdaeman 12y ago
  What's wrong with old good Unix pipes?
  - audidude 12y ago
    The don't solve race conditions in peers trying to locate each other (surprisingly difficult). They don't solve a standardized marshaling format. They don't come with an implementation to integrate with main loops for event polling. They don't handle authentication (well, sort of). They have an inherent vulnerability in FD passing where you can cause the peer to lock up. You can get into deadlock situations in your messaging code if you aren't really careful about message sizes and when you order poll in/poll out. They aren't introspect-able to see what the peer supports. They make it super easy to not maintain ABI. I could go on.
    - nisa 12y ago
      > They have an inherent vulnerability in FD passing where you can cause the peer to lock up. (It's kind of unfair but I could not resist): Just like dbus today? http://www.ubuntu.com/usn/usn-2352-1/ http://www.ubuntu.com/usn/usn-2352-1/
    - audidude 12y ago
      Exactly (since userspace DBus has to use sockets, kdbus uses memfd). Imagine if you had to fix that in every program that ever wanted to do IPC instead of just one place. Sounds like a security and maintenance nightmare.
    - agwa 12y ago
      > The don't solve race conditions in peers trying to locate each other (surprisingly difficult). There's only one PID 1 - it would not be hard to locate its UNIX domain socket. > They don't solve a standardized marshaling format. Fair point. > They don't come with an implementation to integrate with main loops for event polling. They're file descriptors so they work with select, poll, etc. > They have an inherent vulnerability in FD passing where you can cause the peer to lock up. Please elaborate. There's nothing inherently vulnerable with FD passing. In fact, dbus relies on it so if you can't make FD passing secure then you can't make dbus secure either. > You can get into deadlock situations in your messaging code if you aren't really careful about message sizes and when you order poll in/poll out. I think you're overstating the difficulty of doing this correctly. > They aren't introspect-able to see what the peer supports. I for one am OK with PID 1 not being introspectable. > They make it super easy to not maintain ABI. It's quite possible to maintain ABI compatibility, but still, how much of a moving target should PID 1's ABI be anyways? dbus is a great solution for normal applications, but PID 1 is special. The generality provided by dbus is unnecessary. PID 1 should not be servicing requests from ordinary users, so any security concerns with using UNIX domain sockets directly are moot. If there are certain actions, such as shutdown, that need to be triggered from non-root users, then there should be a separate, unprivileged, process that listens on dbus, implements authorization logic, and then relays the command to PID 1 over a UNIX domain socket using a very simple and easily-audited interface. That's good security and reliability engineering.
    - jude- 12y ago
      You seem to want pipes to bend over backwards to solve each and every one of your applications' problems. > The don't solve race conditions in peers trying to locate each other (surprisingly difficult). Not even sure what you mean here. Are you talking about peer discovery? Because DBus won't help you there either--peers have to be aware of each other's DBus object paths before they can rendezvous. Similarly, two peers need to know where the common pipe is to rendezvous. > They don't solve a standardized marshaling format. Nor should they. There are a ton of ways to skin this cat in userspace, depending on what your application needs. Protobufs come to mind, for example, but there are others. Why do you want the pipe to enforce a particular marshaling format? Does the pipe know what's best for every single application that will ever use it? > They don't come with an implementation to integrate with main loops for event polling. It's not the kernel's responsibility to implement the application's main loop. That's what libevent and friends are for today, if you need them. > They have an inherent vulnerability in FD passing where you can cause the peer to lock up. Last I checked, you pass file descriptors via UNIX sockets, not pipes. > They don't handle authentication (well, sort of). Depends on your application's threat model. The kernel provides some basic primitives that can be used to address common security-related problems (capabilities, permission bits, users, groups, and ACLs). If they're not enough, you're free to perform whatever authentication you need in userspace to secure your application against your threat model's adversaries. It is unreasonable to expect the pipe to be aware of every single threat model an applications expects, especially since they change over time. > You can get into deadlock situations in your messaging code if you aren't really careful about message sizes and when you order poll in/poll out. It's not the pipe's fault if you don't use it correctly. > They aren't introspect-able to see what the peer supports. Peer A could use the pipe to ask peer B what it can do for peer A. Why do you want the pipe to do peer B's job? > They make it super easy to not maintain ABI. Nor does DBus. Nothing stops an application from willy-nilly changing the data it serves back.
      - cbsmith 12y ago
        > Not even sure what you mean here. Are you talking about peer discovery? Because DBus won't help you there either--peers have to be aware of each other's DBus object paths before they can rendezvous. Similarly, two peers need to know where the common pipe is to rendezvous. I suspect he was referring to socket activation and how that simplifies these kinds of messes. > Nor should they. There are a ton of ways to skin this cat in userspace, depending on what your application needs. Protobufs come to mind, for example, but there are others. Right... so that's exactly what systemd did. It used Dbus, which provides that standard serialization format. Not my favourite format, but very well established and tested and focused on systemd's problem domain. The point is, in order to have loose coupling between components, something like unix pipes is just a starting point. > Does the pipe know what's best for every single application that will ever use it? Ah, now I understand the problem with systemd. I never realized it was trying to take over every application's communications protocol! ; -) Seriously, I think it is perfectly reasonable (and necessary) to define a standard protocol for system even notifications... I say this because it has already been done... by the standard compoents like udev & dbus that systemd is building on top of... > Last I checked, you pass file descriptors via UNIX sockets, not pipes. Correct. People have a tendency to mess up their semantics though. If the original poster wasn't referring to unix domain sockets, than it is an even sillier question. > It is unreasonable to expect the pipe to be aware of every single threat model an applications expects, especially since they change over time. Yes, but you do need something more sophisticated than a pipe to manage secure communications between your systems components. > Nor does DBus. Nothing stops an application from willy-nilly changing the data it serves back. ? D-Bus will drop you like a hot potato the moment you fire off invalid messages. You could send valid messages with fraudlent/misleading data payloads I guess, but at least a whole host of problems are addressed by tightening that up.
  - cbsmith 12y ago
    Arguably dbus is basically built is unix domain sockets with a pub/sub routing mechanism (and a ton better security).
- Sanddancer 12y ago
  named pipes, posix ipc, signals, etc. There are quite a few existing communications methods that can be used for this purpose.
  - AceJohnny2 12y ago
    OK, and how do you format the data you send across, or find out which functions the daemon supports and trigger them?
    - ultramancool 12y ago
      Classic sysvinit or BSD-style init doesn't rely upon this sort of functionality at all. Just some simple scripts. No need to complicate it any further. A few signals are all that are needed.
      - mmagin 12y ago
        Simple scripts? Have you looked at the shit in /etc/init.d in a modern linux distribution? $ wc -l * | sort -n | tail 274 exim4 286 apache2 290 dnsmasq 298 nfs-common 350 clamav-freshclam 364 udev 386 checkroot.sh 420 clamav-daemon 465 clamav-milter 9893 total If you look into these, you'll find tons of near-duplicate code between scripts, and frequently every script reinvents the wheel in one way or another.
        mmagin 12y ago
        And on my Debian testing system with systemd, the longest service definition is 46 lines! (/lib/systemd/system/getty@.service)
        jsmthrowaway 12y ago
        The comment makes more sense if you substitute "familiar" for "simple," a tactic I use a lot while reading arguments like these.
        deleted 12y ago
- codemac 12y ago
  I'm curious: Why is the init daemon what a local process should communicate with? A daemon that managaes other daemons doesn't need to be PID 1, even to reap zombies. Secondly, daemons shouldn't care what process is managing them, a principled approach to communication between the daemon manager and a daemon would probably include handing off sockets/ports/fds, but probably not much else.
  - thwarted 12y ago
    >A daemon that managaes other daemons doesn't need to be PID 1, even to reap zombies. And get this, prctl(PR_SET_CHILD_SUBREAPER) has existed since May 2012, the original patch was created and submitted by Poettering, and yet we're still told that service management needs to run as pid1 in order to see all double-forked detached daemonized processes.
  - rodgerd 12y ago
    > Why is the init daemon what a local process should communicate with? Because there could, and I know this is a crazy thought, be some benefit in having more meaningful information flow between the master of processes and the processes it manages?
- JdeBP 12y ago
  > how alternatively [to dbus] would a local process communicate with the Init daemon? The answer to that is easy: It's still signals, like it has been for decades, and systemd doesn't change that any more than anything else does. systemd defines some more signals, but that's about it. Notice that you said init daemon. The errors here are in thinking that (a) dbus is the communications system, even in systemd, for the part of the system that does overall system state management and the stuff that the kernel requires of process #1; and (b) the part of the system that supervises daemons is in all packages run in process #1, the "init daemon". systemd, the package, uses dbus in a number of places between a number of components, most notably logind, hostnamed, timedated, machined, and localed. But don't get that confused with systemd the program that runs as process #1, which is as constrained by the kernel (and others) into using the same signals as always, just as any other system manager is. There's an AF_LOCAL socket (/run/systemd/private) for systemctl to talk to PID #1 using a private undocumented protocol, and a public documented D-Bus API for units, but those are for the service management part of systemd the program. The system manager and service manager in the nosh package are in the same boat. The system manager's API is that same set of signals again (augmented with some of the extra systemd-defined signals that fit the model). There's no other API because the system manager is not what the world talks to about service management. The control/status API for individual services is the filesystem, the service manager (that is not in PID 1) presenting the same suite of pipes and files as daemontools-encore. And there's an AF_LOCAL socket for system-control (and indeed anything else, such as service-dt-scanner a.k.a. svscan) to talk to the service manager for loading and unloading service bundles in the first place, and plumbing them together.
TallGuyShort 12y ago
There are a lot of people who agree with you. I feel a bit torn on some of the issues myself, but I'm in a position where I'll be dealing with the enterprise Linux distributions that are adopting systemd quite a lot, so regardless of what I run on my laptop (another BSD fan here), I appreciate the people who are building good resources for getting up to speed on systemd.
drdaeman 12y ago
I think I'm mostly fine with journald (as a concept). At least I can explain reasoning for it to myself. A switch from non-structured to structured data provides a significant advantage, and indexes are useful. At least I had too many times grepping a multi-gigabyte log file. Sure, relatively modern (RFC5424) syslog protocol has structured data too, but in my experience most software had never bothered to use it. So, forcing a switch through introducing another protocol that has structured data baked-in isn't a too terrible idea. My only issue with journald's binary log files is that they're of homebrewn custom format, that's not accessible by any standard means. Plain text files aren't directly readable by humans, too, but we have cat, less or alike tools to pass such data to terminal (sometimes an iconv is required, say, if log entries contain filenames that has characters outside of ASCII range), and those tools are available on every modern OS out there. Personally, I think, a compromise that'd satisfy me (YMMV) would be either an industry-standard log format (like, maybe, sqlite - it's fairly simple, universal and omnipresent nowadays) or, even better, storing data in text files, but having accompanying binary index and metadata ones that store non-human-readable stuff (like hash chain - bet, no sane human would ever check cryptographic log integrity by hand) and provide additional information for faster machine access. But the heck journald is a tightly-coupled part of into systemd instead of being a separate project is beyond me. I can't reject that systemd has some good things about it too, but it's too terribly monolithic and unhackable compared to mostly-scripted init systems. And such negative points easily outweigh the positive ones.
- Sanddancer 12y ago
  The biggest problem with dropping the syslog protocol altogether is that there's a huge amount of other stuff that speaks syslog. Things like networking gear use it for the same purposes as a normal *nix box, and getting them to switch is going to be like pulling teeth. With your particular case, I'd say you should look at rsyslog and/or syslog-ng. Both of them have backends that talk with actual databases, so you can have all your tools readily available, and can additionally dump to plain text and/or email messages at the same time. As to the why for journald, it seems very much like the rest of Poettering's MO of NIH. He doesn't seem too capable of working with other project makers to get his goals handled, so just does everything himself, to the detriment of the overall community.
jqm 12y ago
Viewing the comments, no it appears you are not the only one disgusted. I'm just glad for Slackware at this point.
pjmlp 12y ago
> So recently, I just gave up and moved to FreeBSD. Not a single regret so far. It all depends on the use cases. For me, FreeBSD is a no go given my desktop usage requirements.
- bigbugbag 12y ago
  what about the desktop oriented BSD such as dragonfly or pc-bsd ?
  - pjmlp 12y ago
    Also not, since I require access to specific 3D programming software SDKs (vendor specific), modeling, video editing tools and .NET (work). This currently makes me a Windows/Mac OS X guy in what concerns desktop usage.

AceJohnny2 12y ago

> dbus-dependent pile of crap? This seems to come up frequently. I'm curious: how alternatively would a local process communicate with the Init daemon?

drdaeman 12y ago
What's wrong with old good Unix pipes?
- audidude 12y ago
  The don't solve race conditions in peers trying to locate each other (surprisingly difficult). They don't solve a standardized marshaling format. They don't come with an implementation to integrate with main loops for event polling. They don't handle authentication (well, sort of). They have an inherent vulnerability in FD passing where you can cause the peer to lock up. You can get into deadlock situations in your messaging code if you aren't really careful about message sizes and when you order poll in/poll out. They aren't introspect-able to see what the peer supports. They make it super easy to not maintain ABI. I could go on.
  - nisa 12y ago
    > They have an inherent vulnerability in FD passing where you can cause the peer to lock up. (It's kind of unfair but I could not resist): Just like dbus today? http://www.ubuntu.com/usn/usn-2352-1/ http://www.ubuntu.com/usn/usn-2352-1/
  - audidude 12y ago
    Exactly (since userspace DBus has to use sockets, kdbus uses memfd). Imagine if you had to fix that in every program that ever wanted to do IPC instead of just one place. Sounds like a security and maintenance nightmare.
  - agwa 12y ago
    > The don't solve race conditions in peers trying to locate each other (surprisingly difficult). There's only one PID 1 - it would not be hard to locate its UNIX domain socket. > They don't solve a standardized marshaling format. Fair point. > They don't come with an implementation to integrate with main loops for event polling. They're file descriptors so they work with select, poll, etc. > They have an inherent vulnerability in FD passing where you can cause the peer to lock up. Please elaborate. There's nothing inherently vulnerable with FD passing. In fact, dbus relies on it so if you can't make FD passing secure then you can't make dbus secure either. > You can get into deadlock situations in your messaging code if you aren't really careful about message sizes and when you order poll in/poll out. I think you're overstating the difficulty of doing this correctly. > They aren't introspect-able to see what the peer supports. I for one am OK with PID 1 not being introspectable. > They make it super easy to not maintain ABI. It's quite possible to maintain ABI compatibility, but still, how much of a moving target should PID 1's ABI be anyways? dbus is a great solution for normal applications, but PID 1 is special. The generality provided by dbus is unnecessary. PID 1 should not be servicing requests from ordinary users, so any security concerns with using UNIX domain sockets directly are moot. If there are certain actions, such as shutdown, that need to be triggered from non-root users, then there should be a separate, unprivileged, process that listens on dbus, implements authorization logic, and then relays the command to PID 1 over a UNIX domain socket using a very simple and easily-audited interface. That's good security and reliability engineering.
  - jude- 12y ago
    You seem to want pipes to bend over backwards to solve each and every one of your applications' problems. > The don't solve race conditions in peers trying to locate each other (surprisingly difficult). Not even sure what you mean here. Are you talking about peer discovery? Because DBus won't help you there either--peers have to be aware of each other's DBus object paths before they can rendezvous. Similarly, two peers need to know where the common pipe is to rendezvous. > They don't solve a standardized marshaling format. Nor should they. There are a ton of ways to skin this cat in userspace, depending on what your application needs. Protobufs come to mind, for example, but there are others. Why do you want the pipe to enforce a particular marshaling format? Does the pipe know what's best for every single application that will ever use it? > They don't come with an implementation to integrate with main loops for event polling. It's not the kernel's responsibility to implement the application's main loop. That's what libevent and friends are for today, if you need them. > They have an inherent vulnerability in FD passing where you can cause the peer to lock up. Last I checked, you pass file descriptors via UNIX sockets, not pipes. > They don't handle authentication (well, sort of). Depends on your application's threat model. The kernel provides some basic primitives that can be used to address common security-related problems (capabilities, permission bits, users, groups, and ACLs). If they're not enough, you're free to perform whatever authentication you need in userspace to secure your application against your threat model's adversaries. It is unreasonable to expect the pipe to be aware of every single threat model an applications expects, especially since they change over time. > You can get into deadlock situations in your messaging code if you aren't really careful about message sizes and when you order poll in/poll out. It's not the pipe's fault if you don't use it correctly. > They aren't introspect-able to see what the peer supports. Peer A could use the pipe to ask peer B what it can do for peer A. Why do you want the pipe to do peer B's job? > They make it super easy to not maintain ABI. Nor does DBus. Nothing stops an application from willy-nilly changing the data it serves back.
    - cbsmith 12y ago
      > Not even sure what you mean here. Are you talking about peer discovery? Because DBus won't help you there either--peers have to be aware of each other's DBus object paths before they can rendezvous. Similarly, two peers need to know where the common pipe is to rendezvous. I suspect he was referring to socket activation and how that simplifies these kinds of messes. > Nor should they. There are a ton of ways to skin this cat in userspace, depending on what your application needs. Protobufs come to mind, for example, but there are others. Right... so that's exactly what systemd did. It used Dbus, which provides that standard serialization format. Not my favourite format, but very well established and tested and focused on systemd's problem domain. The point is, in order to have loose coupling between components, something like unix pipes is just a starting point. > Does the pipe know what's best for every single application that will ever use it? Ah, now I understand the problem with systemd. I never realized it was trying to take over every application's communications protocol! ; -) Seriously, I think it is perfectly reasonable (and necessary) to define a standard protocol for system even notifications... I say this because it has already been done... by the standard compoents like udev & dbus that systemd is building on top of... > Last I checked, you pass file descriptors via UNIX sockets, not pipes. Correct. People have a tendency to mess up their semantics though. If the original poster wasn't referring to unix domain sockets, than it is an even sillier question. > It is unreasonable to expect the pipe to be aware of every single threat model an applications expects, especially since they change over time. Yes, but you do need something more sophisticated than a pipe to manage secure communications between your systems components. > Nor does DBus. Nothing stops an application from willy-nilly changing the data it serves back. ? D-Bus will drop you like a hot potato the moment you fire off invalid messages. You could send valid messages with fraudlent/misleading data payloads I guess, but at least a whole host of problems are addressed by tightening that up.
- cbsmith 12y ago
  Arguably dbus is basically built is unix domain sockets with a pub/sub routing mechanism (and a ton better security).
Sanddancer 12y ago
named pipes, posix ipc, signals, etc. There are quite a few existing communications methods that can be used for this purpose.
- AceJohnny2 12y ago
  OK, and how do you format the data you send across, or find out which functions the daemon supports and trigger them?
  - ultramancool 12y ago
    Classic sysvinit or BSD-style init doesn't rely upon this sort of functionality at all. Just some simple scripts. No need to complicate it any further. A few signals are all that are needed.
    - mmagin 12y ago
      Simple scripts? Have you looked at the shit in /etc/init.d in a modern linux distribution? $ wc -l * | sort -n | tail 274 exim4 286 apache2 290 dnsmasq 298 nfs-common 350 clamav-freshclam 364 udev 386 checkroot.sh 420 clamav-daemon 465 clamav-milter 9893 total If you look into these, you'll find tons of near-duplicate code between scripts, and frequently every script reinvents the wheel in one way or another.
      - mmagin 12y ago
        And on my Debian testing system with systemd, the longest service definition is 46 lines! (/lib/systemd/system/getty@.service)
      - jsmthrowaway 12y ago
        The comment makes more sense if you substitute "familiar" for "simple," a tactic I use a lot while reading arguments like these.
        deleted 12y ago
codemac 12y ago
I'm curious: Why is the init daemon what a local process should communicate with? A daemon that managaes other daemons doesn't need to be PID 1, even to reap zombies. Secondly, daemons shouldn't care what process is managing them, a principled approach to communication between the daemon manager and a daemon would probably include handing off sockets/ports/fds, but probably not much else.
- thwarted 12y ago
  >A daemon that managaes other daemons doesn't need to be PID 1, even to reap zombies. And get this, prctl(PR_SET_CHILD_SUBREAPER) has existed since May 2012, the original patch was created and submitted by Poettering, and yet we're still told that service management needs to run as pid1 in order to see all double-forked detached daemonized processes.
- rodgerd 12y ago
  > Why is the init daemon what a local process should communicate with? Because there could, and I know this is a crazy thought, be some benefit in having more meaningful information flow between the master of processes and the processes it manages?
JdeBP 12y ago
> how alternatively [to dbus] would a local process communicate with the Init daemon? The answer to that is easy: It's still signals, like it has been for decades, and systemd doesn't change that any more than anything else does. systemd defines some more signals, but that's about it. Notice that you said init daemon. The errors here are in thinking that (a) dbus is the communications system, even in systemd, for the part of the system that does overall system state management and the stuff that the kernel requires of process #1; and (b) the part of the system that supervises daemons is in all packages run in process #1, the "init daemon". systemd, the package, uses dbus in a number of places between a number of components, most notably logind, hostnamed, timedated, machined, and localed. But don't get that confused with systemd the program that runs as process #1, which is as constrained by the kernel (and others) into using the same signals as always, just as any other system manager is. There's an AF_LOCAL socket (/run/systemd/private) for systemctl to talk to PID #1 using a private undocumented protocol, and a public documented D-Bus API for units, but those are for the service management part of systemd the program. The system manager and service manager in the nosh package are in the same boat. The system manager's API is that same set of signals again (augmented with some of the extra systemd-defined signals that fit the model). There's no other API because the system manager is not what the world talks to about service management. The control/status API for individual services is the filesystem, the service manager (that is not in PID 1) presenting the same suite of pipes and files as daemontools-encore. And there's an AF_LOCAL socket for system-control (and indeed anything else, such as service-dt-scanner a.k.a. svscan) to talk to the service manager for loading and unloading service bundles in the first place, and plumbing them together.

TallGuyShort 12y ago

There are a lot of people who agree with you. I feel a bit torn on some of the issues myself, but I'm in a position where I'll be dealing with the enterprise Linux distributions that are adopting systemd quite a lot, so regardless of what I run on my laptop (another BSD fan here), I appreciate the people who are building good resources for getting up to speed on systemd.

drdaeman 12y ago

I think I'm mostly fine with journald (as a concept). At least I can explain reasoning for it to myself. A switch from non-structured to structured data provides a significant advantage, and indexes are useful. At least I had too many times grepping a multi-gigabyte log file. Sure, relatively modern (RFC5424) syslog protocol has structured data too, but in my experience most software had never bothered to use it. So, forcing a switch through introducing another protocol that has structured data baked-in isn't a too terrible idea. My only issue with journald's binary log files is that they're of homebrewn custom format, that's not accessible by any standard means. Plain text files aren't directly readable by humans, too, but we have cat, less or alike tools to pass such data to terminal (sometimes an iconv is required, say, if log entries contain filenames that has characters outside of ASCII range), and those tools are available on every modern OS out there. Personally, I think, a compromise that'd satisfy me (YMMV) would be either an industry-standard log format (like, maybe, sqlite - it's fairly simple, universal and omnipresent nowadays) or, even better, storing data in text files, but having accompanying binary index and metadata ones that store non-human-readable stuff (like hash chain - bet, no sane human would ever check cryptographic log integrity by hand) and provide additional information for faster machine access. But the heck journald is a tightly-coupled part of into systemd instead of being a separate project is beyond me. I can't reject that systemd has some good things about it too, but it's too terribly monolithic and unhackable compared to mostly-scripted init systems. And such negative points easily outweigh the positive ones.

Sanddancer 12y ago
The biggest problem with dropping the syslog protocol altogether is that there's a huge amount of other stuff that speaks syslog. Things like networking gear use it for the same purposes as a normal *nix box, and getting them to switch is going to be like pulling teeth. With your particular case, I'd say you should look at rsyslog and/or syslog-ng. Both of them have backends that talk with actual databases, so you can have all your tools readily available, and can additionally dump to plain text and/or email messages at the same time. As to the why for journald, it seems very much like the rest of Poettering's MO of NIH. He doesn't seem too capable of working with other project makers to get his goals handled, so just does everything himself, to the detriment of the overall community.

jqm 12y ago

Viewing the comments, no it appears you are not the only one disgusted. I'm just glad for Slackware at this point.

pjmlp 12y ago

> So recently, I just gave up and moved to FreeBSD. Not a single regret so far. It all depends on the use cases. For me, FreeBSD is a no go given my desktop usage requirements.

bigbugbag 12y ago
what about the desktop oriented BSD such as dragonfly or pc-bsd ?
- pjmlp 12y ago
  Also not, since I require access to specific 3D programming software SDKs (vendor specific), modeling, video editing tools and .NET (work). This currently makes me a Windows/Mac OS X guy in what concerns desktop usage.