5 ms·

footnote: because the maintainer (Lennart Poettering) is religiously anti-portability. This is a shame, because it makes for brittle software, even when target

footnote: because the maintainer (Lennart Poettering) is religiously anti-portability. This is a shame, because it makes for brittle software, even when targeting the same platform where APIs do shift and improve over time. To quote: > In fact, the way I see things the Linux API has been taking the role of the POSIX API and Linux is the focal point of all Free Software development. Due to that I can only recommend developers to try to hack with only Linux in mind and experience the freedom and the opportunities this offers you. So, get yourself a copy of The Linux Programming Interface, ignore everything it says about POSIX compatibility and hack away your amazing Linux software. It's quite relieving! I find this to be extremely cringe-worthy; I can only hope that a Linux monoculture isn't the future of open source development.

mseepgood 13y ago
> This is a shame, because it makes for brittle software The opposite is true: Abundant use of #ifdefs makes for unmaintainable and brittle software.
- anonyfuss 13y ago
  > The opposite is true: Abundant use of #ifdefs makes for unmaintainable and brittle software. False dichotomy; simply don't make abundant use of #ifdefs. Most large, portable projects don't use #ifdefs across the codebase. They abstract the core concepts out into interfaces that can be implemented atop different APIs, and then maintain distinct implementations where necessary. The advantage is that this also insulates you from changes to the underlying system APIs, creates testable code, and provides clean well-defined points of interaction between subsystems.
  - mseepgood 13y ago
    > They abstract the core concepts out into interfaces that can be implemented atop different APIs This is exactly what systemd's D-Bus API is for.
    - anonyfuss 13y ago
      D-bus isn't a software architecture and doesn't somehow magically make systemd more maintainable.
  - bkor 13y ago
    Another layer of abstraction just results in more complicated code, more bugs, more difficulty testing the different code paths. Might be fine for a lot of projects, but this is just something to boot up your system.
    - anonyfuss 13y ago
      > Another layer of abstraction just results in more complicated code, more bugs, more difficulty testing the different code paths. No. A proper approach to abstraction: - Reduces complexity by reducing interdependency between subsystems. - Facilitates testing by reducing interdependency between subsystems, and reduces bugs by facilitating testing. - Allows for iterating components of the code base independently, and more easily adapting to changes to underlying components and subsystems, whether in the software themselves, or part of the system(s) the software relies on. > Might be fine for a lot of projects, but this is just something to boot up your system. Actually, this isn't just something to boot up your system (and if it was, it would be even easier to keep portable). Instead, systemd a kitchen-sink-replace-everything-daemon that introduces massive cross-system/cross-module dependencies.
- msbarnett 13y ago
  The choice between 'portability' and 'ifdefs' is a false dichotomy. There are far cleaner ways to achieve portability, and ifdefs are almost always a sign of 'doing it wrong'. See, for example, Kernighan and Pike talking about portability in The Practice of Programming.
  - bkor 13y ago
    BSD doesn't support a bunch of stuff. How would you deal with that concretely. How would you ensure that all those different code paths are tested?
    - anonyfuss 13y ago
      > BSD doesn't support a bunch of stuff. How would you deal with that concretely. How would you ensure that all those different code paths are tested? You could start by explaining "a bunch of stuff" -- and why it's necessary -- concretely.
    - npsimons 13y ago
      Code coverage tools are available. Porting software to other platforms is just one crude, but very effective way of testing different code paths, some you can't even see (unless you are in the habit of stopping at each compile stage and checking things such as the compiler's assembler output . . . ).
npsimons 13y ago
I hate with a passion having to work on just about any platform besides Debian/Linux. Call it what you will, I'm just very comfortable and satisfied with how Debian/Linux works. That being said, to be anti-portability is just plain unprofessional. Just having a second non-gcc compiler to test against for, say C++, is a blessing in that it's bound to make you rethink how you code and to catch problems well before they happen. The more platforms you can test against, the better your code will be. And much as I love Linux, I would hate to see it stagnate and become the only OSS option. I think Poettering has had an attitude problem for quite some time, and unfortunately he doesn't seem to be getting any better.
- bkor 13y ago
  Do you really think BSD would replace their init system with something not BSD licensed? Seems like a pointless exercise to slow down progress just for theoretical usecase.
  - npsimons 13y ago
    Which is part of my point; although BSD is not my personal license of choice, I really think it would be a bad idea to have Linux distros (or apps higher in the stack) be incompatible with the BSDs, eg by requiring something Linux specific (eg, systemd). I'm not a big fan of systemd; I really think is too wide in scope, and making the logs binary doesn't make sense to me. It might be more acceptable to me if they dual licensed it (GPLv3 and BSD) so that it could be ported to and used in the BSDs (among other systems); that would also give the bonus of improving the code (which making it portable almost always does). Alas, none of these concerns are likely to be addressed satisfactorily. PS - So-called "theoretical" use cases have probably been the number one source of bugs (especially security holes) in the history of software. "Oh, don't worry about checking array bounds, nobody would be stupid enough to write too much data!"

mseepgood 13y ago

> This is a shame, because it makes for brittle software The opposite is true: Abundant use of #ifdefs makes for unmaintainable and brittle software.

anonyfuss 13y ago
> The opposite is true: Abundant use of #ifdefs makes for unmaintainable and brittle software. False dichotomy; simply don't make abundant use of #ifdefs. Most large, portable projects don't use #ifdefs across the codebase. They abstract the core concepts out into interfaces that can be implemented atop different APIs, and then maintain distinct implementations where necessary. The advantage is that this also insulates you from changes to the underlying system APIs, creates testable code, and provides clean well-defined points of interaction between subsystems.
- mseepgood 13y ago
  > They abstract the core concepts out into interfaces that can be implemented atop different APIs This is exactly what systemd's D-Bus API is for.
  - anonyfuss 13y ago
    D-bus isn't a software architecture and doesn't somehow magically make systemd more maintainable.
- bkor 13y ago
  Another layer of abstraction just results in more complicated code, more bugs, more difficulty testing the different code paths. Might be fine for a lot of projects, but this is just something to boot up your system.
  - anonyfuss 13y ago
    > Another layer of abstraction just results in more complicated code, more bugs, more difficulty testing the different code paths. No. A proper approach to abstraction: - Reduces complexity by reducing interdependency between subsystems. - Facilitates testing by reducing interdependency between subsystems, and reduces bugs by facilitating testing. - Allows for iterating components of the code base independently, and more easily adapting to changes to underlying components and subsystems, whether in the software themselves, or part of the system(s) the software relies on. > Might be fine for a lot of projects, but this is just something to boot up your system. Actually, this isn't just something to boot up your system (and if it was, it would be even easier to keep portable). Instead, systemd a kitchen-sink-replace-everything-daemon that introduces massive cross-system/cross-module dependencies.
msbarnett 13y ago
The choice between 'portability' and 'ifdefs' is a false dichotomy. There are far cleaner ways to achieve portability, and ifdefs are almost always a sign of 'doing it wrong'. See, for example, Kernighan and Pike talking about portability in The Practice of Programming.
- bkor 13y ago
  BSD doesn't support a bunch of stuff. How would you deal with that concretely. How would you ensure that all those different code paths are tested?
  - anonyfuss 13y ago
    > BSD doesn't support a bunch of stuff. How would you deal with that concretely. How would you ensure that all those different code paths are tested? You could start by explaining "a bunch of stuff" -- and why it's necessary -- concretely.
  - npsimons 13y ago
    Code coverage tools are available. Porting software to other platforms is just one crude, but very effective way of testing different code paths, some you can't even see (unless you are in the habit of stopping at each compile stage and checking things such as the compiler's assembler output . . . ).

npsimons 13y ago

I hate with a passion having to work on just about any platform besides Debian/Linux. Call it what you will, I'm just very comfortable and satisfied with how Debian/Linux works. That being said, to be anti-portability is just plain unprofessional. Just having a second non-gcc compiler to test against for, say C++, is a blessing in that it's bound to make you rethink how you code and to catch problems well before they happen. The more platforms you can test against, the better your code will be. And much as I love Linux, I would hate to see it stagnate and become the only OSS option. I think Poettering has had an attitude problem for quite some time, and unfortunately he doesn't seem to be getting any better.

bkor 13y ago
Do you really think BSD would replace their init system with something not BSD licensed? Seems like a pointless exercise to slow down progress just for theoretical usecase.
- npsimons 13y ago
  Which is part of my point; although BSD is not my personal license of choice, I really think it would be a bad idea to have Linux distros (or apps higher in the stack) be incompatible with the BSDs, eg by requiring something Linux specific (eg, systemd). I'm not a big fan of systemd; I really think is too wide in scope, and making the logs binary doesn't make sense to me. It might be more acceptable to me if they dual licensed it (GPLv3 and BSD) so that it could be ported to and used in the BSDs (among other systems); that would also give the bonus of improving the code (which making it portable almost always does). Alas, none of these concerns are likely to be addressed satisfactorily. PS - So-called "theoretical" use cases have probably been the number one source of bugs (especially security holes) in the history of software. "Oh, don't worry about checking array bounds, nobody would be stupid enough to write too much data!"