Let me preface this with the fact that I'm an intellectual property specialist. I bill $450/hour, and still have lots of time to work on my startup without having to take venture capital.

I thought about some educational answers for your questions, but the insult at the start of your comment rubs me wrong and I decided I don't owe you anything. So, I'll save them.

The first symptom of a new but incomplete understanding of patents is gold fever. That is when you have an idea that what you are holding is extremely valuable and that you must protect it from others at all costs. People tend to get irrational about it.

So here is some reality: The fact that you have even published your video (which is "use in commerce" under patent law) invalidates future patents that you might file on that same art. Then there is the prior art (including art you are not aware of), and the recent court finding in Alice v. CLS Bank that invalidates most process and method patents which describe software. These all work against the potential that your thesis is going to make you rich through patent licensing.

You can get a patent awarded, perhaps, that you can use to hoodwink an investor, but forcing an automotive company to pay you? Much less likely and it will cost $10 Million in attorney fees to get there.

Probably your school wants 51% of the revenue and your grant funding sources (and those of your college department) may have their own policies on patents.

Yes, this is definitely a "WTF?" moment in the history of Slashdot. I suggest that you all just move on to the next story and refuse to feed the troll by asking him questions.

Slashdot, obviously, has to innovate in order to stay current. Thus, they are now taking the next step after "Anonymous Cowards". The new "Identified Troll" feature will include interviews of people who have prostituted their personal credibility to some company's calculated disinformation campaign.

1. Doing away with journald requires a replacement, because it is functionality needed by systemd. No suitable replacement exists. Therefore, it can't be replaced. Why is this so hard to understand? It has nothing to do with being modular or not. Just because syslogd is a logging daemon and journald is a logging daemon doesn't mean the two are interchangeable. If that was a requirement for modularity, we would never be able to develop new interfaces. The syslog API was developed in the 1980s. At some point, the systemd developers decided they couldn't do everything they needed through the syslog API alone, so they developed a new API and journald to go with it. So yes, it is modular, but no you can't replace it because no suitable alternative exists. If you need further elaboration, consider the Unix userspace before multiple syslogd daemons were available. There was the syslog API, but only one syslogd daemon. Since you can't run a functional system without logging, this effectively required you to use syslogd. Does that mean syslog/syslogd was not a modular system until rsyslog and syslog-ng came out? No, of course not.

2. I see you make no effort to elaborate your argument beyond saying "no, you are wrong." The reason for lack of alternatives is that nobody has developed them. I stand by that statement. However, there is starting to be some movement on that front, with efforts by the BSD folks, for example, to port the logind functionality over to BSD so that software that depends on it can use it. Likewise, if you wanted to write a logging daemon that provides the functionality that systemd needs without, for example, using a binary file format, you could do that and I am sure you would have no problem replacing journald with it.

The original point of this thread was that the 69+ individual binaries that systemd builds was an example of being monolithic, with claims by various people that you are forced to use all of them and none of them can be replaced. That is false, and that is the origin of my statement above. Journald cannot be disabled with a compile-time switch, unlike the others. Strictly speaking, this does not mean it is monolithic. Journald communicates with the rest of systemd via well-defined, albeit some in a state of flux, APIs (that is the definition of modular, in case you were wondering). The reason why the developers have not made journald optional is because no currently available syslog variant can replace the functionality of journald, so why bother? Since systemd needs something like journald to function, and journald is currently the only available option, make it a hard dependency. Maintaining backwards compatibility with syslog is not a requirement for modularity.

Glad to hear it.

Why does it matter? Journald cannot be separated from systemd because it draws on many features to gather the information it needs, such as to verify timestamp and authenticity, for example. Systemd is dependent on journald because it needs a logging facility that provides information (indexed and organized by process) in a way that no other logging facility currently does. So yes, this is monolithic because they can't be separated. One might ask if they could in principle be separated. Maybe. It depends at least somewhat on the rational for doing so.

With respect to syslogd, journald communicates all logging information to any external logging daemon via a socket and a well-defined interface. It also gathers logging information from userspace processes via the syslog API. So by definition, journald is modular in this sense (it communicates with other processes via well-defined interfaces). The fact that journald must relay logging information to syslogd is a consequence of listening directly to /dev/log, which prohibits syslogd from doing so. Is this bad? It depends on your perspective.

You don't lose that ability. Why do you think that? The bug report that you linked to is about a different issue.

I understand that monolithic is a moving target of criticism for people who don't like systemd.

The journal is part of the core of systemd, so as such it cannot be removed. Why? Well, in short, syslog does not provide the functionality systemd needs for certain things. So yeah, you can call that monolithic if you want...if you also want to say that you can't remove the shell and still have sysvinit work, therefore it is monolithic. That said, the reason why the journal must pass messages on to syslogd is because only one service is allowed to listen on /dev/log, so nothing like your emacs example. Most of the rest of systemd is entirely optional.

They are not all required at the same time. Where are you getting your information?

Yes...you...can! That is the whole f$@%@#$ing point of having multiple binaries! Where do people come up with this crap?

What you might ask instead is, why do no suitable replacements exist? Because nobody has written them....

I last tried a Debian install around the time of Dayton Hamvention, so a few months ago. I don't have a bug #, I tried to debug GDM for a while but didn't have enough time. I can try another install sometime soon.

Well, a Core i5 tablet with two parallel screen digitizers is an odd enough bird that you can't expect it to run on the somewhat aged Debian stable. And indeed the older GNOME there handles the touchscreen incorrectly.

Because it has a touchscreen and a separate pen digitizer on the same screen. And now with the keyboard, it also has a Cirque touchpad, for a total of three digitizers.

The Toughpad has a touchscreen and a pen (with a separate digitizer!) and the touchscreen doesn't work properly in the older GNOME in stable.