Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

kinda funny though.. as you end up with a system that is developed more like systemd is.


No. This is _bullshit_, and people should really stop saying this.

A lot of components (OpenSSL? GCC? LLVM?) are in that repository merely for convenience but ARE NOT developed on internally (except for patches to make them work, eventually).

This IS NOT the same of "everything developed internally here, from syslog to dhcpcd" mentality of systemd.


Could you elaborate on that?


One single repository containing many different components of the OS, which are not designed to be interchangeable. Basically the biggest complaint most systemd critics have ('monolithic!').


That is not what monolithic means. Monolithic is opposed to modular. Just being in the same repository does not make components tightly coupled etc.


Monolithic is _not_ opposed to modular.

Here's a list of systems that are both monolithic and modular:

* Linux

* the FreeBSD kernel

* the Solaris kernel

* Apache HTTPD

* Postfix

* OpenJDK

* XOrg

* EMACS

* LibreOffice

A modular, non-monolithic alternative to the kernels would be MINIX or HURD.


Monolithic may have a specific technical meaning in the context of kernels which is not opposed to modularity, but in general the two can be considered opposites. Monolithic is simply "of one piece", while modular means something has separate, changeable pieces. If you disagree it would be more enlightening to tell me your definition instead of a list of exceptions, because right now I don't see why they are.


But they are in the same repo because they are tightly coupled. Some of the code is shared between kernel and userspace for example, and stuff is versioned to match, as the BSDs do not have the strict userspace compatibility guarantees that Linux does, so things do change (though there are compat shims).


On the other hand, with the BSDs, you can swap out nearly any userland component for an alternative and it keeps working. While various things share code, it's very rare that one feature depends on an entirely unrelated feature, which is extremely unlike systemd.


True, and you can look in the Makefile to see what the dependencies are.


OpenBSD (newbie alert, I'm no expert): when following -stable or -current branch in OpenBSD, the documents advise you to keep the source tree for the kernel, the src and the X system in step with each other and to only take ports or binary packages from the appropriate repository. You are also advised to compile the updated kernel first, reboot into the new kernel and then recompile the src and xenocara(X system) trees. So although the individual programs are all separate, they are intended to work together as a whole with common configuration settings &c and the source is kept in a single cvs tree.

You can't mix and match (say) an Xorg taken from somewhere else and your own special cat program.

My understanding of the systemd project - especially later versions with kdbus in the kernel and udev integrated in along with networking and the console - is that you may need to 'lockstep' your choice of kernel, systemd packages and possibly the DE if using Gnome in order to have a functioning system. I can see advantages in this but it does represent a considerable cultural change in the Linux world which has previously been a little bit like a Lego set.

If I have this wrong, please advise and correct.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: