Users/Developers Threatening Fork Of Debian GNU/Linux

[bearded_linux_admin]

This one I had to reply to.

1. Depending on how the log is serialised, you can lose one message, the whole log or just part of a message in case it is binary (damaged header groups or metadata). If the log is plaintext, you lose one character.
2. Every and I mean EVERY operating system out there has a text editor. In a fix you can move a file and read it anywhere. Guess what happens if you try that with a binary log.
3. see point 2. if you narrow your view only to linux then ok. but even there you have to meet specific requirements to read the binary logs.
4. well the UNIX principles are proven by decades of a rock solid operating system. have a look at how well windows did and how it does now when it started adopting them.

In a nutshell, you are missing a lot. You have a very narrow field of view.

From my own experience:

I have (still am in some cases) worked with Linux, Tru64, AIX, Windows, HP-UX and some other obscure systems. While binary logs are nice when they work (Windows, Tru64) they are a pain to read and learn. For text logs you need to know the same tools everywhere (grep, cat, awk, sed ...) and learn the log format as you go (this even applies to SAP and Oracle). In case of binary logs, you have to know a different formating/viewing tool for each platform as well as the log format.

I leave it up to you to consider which situation is easier on the sysadmin.

Well said, many thanks.

[gens]

yep, I know. I just don't want the hassle, and I see very little benefit to me. Like I said, it might be great for people with desktops/laptops whatever - I don't see any tangible benefits for my server farms, and I see a lot of risk, as well as a lot of changes to accommodate such a major change. In short, what's in it for me?

i was saying for corrupted text
you explained binary logs and their downside fairly good

[TheBlackCat]

What I suspect the guys thinking of forking Debian are about is choice. What works for you and makes you all happy might not work for me. Why is everybody in here yelling and shouting that this is wrong?

Please quote any supporter of systemd in this thread saying that choice is bad. The problem is that the anti-systemd crowd is only looking at their own choice. They are ignoring the fact that developers also have a choice: a choice what they are going to spend their time on. It is not up to the anti-systemd crowd to tell developers what they must and must not spend their own free time on.

[danwood76]

This one I had to reply to.

1. Depending on how the log is serialised, you can lose one message, the whole log or just part of a message in case it is binary (damaged header groups or metadata). If the log is plaintext, you lose one character.
2. Every and I mean EVERY operating system out there has a text editor. In a fix you can move a file and read it anywhere. Guess what happens if you try that with a binary log.
3. see point 2. if you narrow your view only to linux then ok. but even there you have to meet specific requirements to read the binary logs.
4. well the UNIX principles are proven by decades of a rock solid operating system. have a look at how well windows did and how it does now when it started adopting them.

In a nutshell, you are missing a lot. You have a very narrow field of view.

From my own experience:

I have (still am in some cases) worked with Linux, Tru64, AIX, Windows, HP-UX and some other obscure systems. While binary logs are nice when they work (Windows, Tru64) they are a pain to read and learn. For text logs you need to know the same tools everywhere (grep, cat, awk, sed ...) and learn the log format as you go (this even applies to SAP and Oracle). In case of binary logs, you have to know a different formating/viewing tool for each platform as well as the log format.

I leave it up to you to consider which situation is easier on the sysadmin.

If your log is corrupted then surely this is a hint that your hard disk is failing?
You wouldn't need to go much further?


The times I most often go hunting through logs is looking for issues with a particular software package or hints as to the location of a compromised script on a web server for example.
Journald has sped this process up for me to the point of me wondering how I lived before.

There will always be people that come up with reasons to not want to use journald, but for the majority of situations it is the perfect answer.
The same goes for systemd, for the majority of users it will serve its purpose and they wont even know its there.

[TheBlackCat]

For text logs you need to know the same tools everywhere (grep, cat, awk, sed ...) and learn the log format as you go (this even applies to SAP and Oracle).

I think you mean "log formats", since different applications, libraries, and daemons write differently-formatted logs even to the same log file. So yes, with binary logs you need to know different formats for different platforms, but at least for a single platform the format will be consistent.

[erendorn]

upstart, in contrast, resolves the dependency tree and then just starts the leaves in parallel
so where systemd "starts" a "service" and then starts the things it depends upon
upstart resolves everything then starts everything that has dependencies met at once

id say upstart does it a better way
although the difference is negligible in the end (unless a dependency fails)

Hum, not clear to me. I knew systemd managed dependencies slightly differently from upstart, but to be honest I don't know the actual difference.
Is that linked to socket activation? (when talking to a service, input is queued until service ready, service is started, service talks to dependency service 2, repeat for service 2)?

[jrch2k8]

i asked you, not some websites
and i asked how systemd determines what the next process it starts will be
nothing else

you didn't answer that simple question

and no, systemd is in a galaxy far away from KISS
from wikipedia: "The KISS principle states that most systems work best if they are kept simple rather than made complicated; therefore simplicity should be a key goal in design and unnecessary complexity should be avoided."
systemd, for one example, needs dbus to even work...

and continued on the "Worse is better" page also from wikipedia: "The idea is that quality does not necessarily increase with functionality."

Keep It Simple, Stupid
not Make It Unnecessarily Complicated For No Good Reason, Intelligent Person

well the links provide all the basic infrastructure to make a mental map for the process, i won't waste time giving you a dissertation of why does why it does when somebody just took its time to pretty much put all the basic information you need in a wiki but well if you wanna stick to it to prove whatever trolling point you have, thats fine is all the same to me

second the KISS principle is not about dependencies/code/language specific complexity is about algorithmic complexity and was devised in an age where most software was build in massive monolithic do everything executable(on the first iterations of C and fortran this was the easy way of doing things, compiler were very stupid) as you may imagine stability wasn't all that great, so the UNIX(packard bell days) guys though it made more sense stupid isolated algorithm focused on 1 task alone that could interact with each other to achieve the same result of the massive monolithic executable but with more stability(because of this UNIX reigned in server all the way to the mid 90's). So yes systemd is KISS because every member dependency or process focus in 1 simple task and they interact with each other(btw KISS not require you to make generic use all software on earth interfaces like some think). that wikipedia articles is not wrong about the acronym but is to simple an explanation to make any real sense out of it. If you feel like code is what it refer as simple then be happy stick to that interpretation of the article but be aware not software written after the 70's is KISS compliant that way because the moment you add a syscall(reardless the kernel) 90% of amateur developers will not be able to make sense of it.

about your later response about event procs that is totally unrelated to the job cgroups does(its just a happy consequence of it) and is not a replacement, read the articles i posted again including the one about namespaces and google linux abstract sockets(it helps to understand some concepts of virtual tables vs non virtual tables allocation and tracking)

[Tentacle]

In a nutshell, you are missing a lot. You have a very narrow field of view.

I'm not missing anything, my servers are all systemd-less. I'm just trying to get some real technical objections to binlogging. You gave a few such objections. Personally I find them objections to (in)convenience in reading a binlog. But okay.

[jrch2k8]

This one I had to reply to.

1. Depending on how the log is serialised, you can lose one message, the whole log or just part of a message in case it is binary (damaged header groups or metadata). If the log is plaintext, you lose one character.
2. Every and I mean EVERY operating system out there has a text editor. In a fix you can move a file and read it anywhere. Guess what happens if you try that with a binary log.
3. see point 2. if you narrow your view only to linux then ok. but even there you have to meet specific requirements to read the binary logs.
4. well the UNIX principles are proven by decades of a rock solid operating system. have a look at how well windows did and how it does now when it started adopting them.

In a nutshell, you are missing a lot. You have a very narrow field of view.

From my own experience:

I have (still am in some cases) worked with Linux, Tru64, AIX, Windows, HP-UX and some other obscure systems. While binary logs are nice when they work (Windows, Tru64) they are a pain to read and learn. For text logs you need to know the same tools everywhere (grep, cat, awk, sed ...) and learn the log format as you go (this even applies to SAP and Oracle). In case of binary logs, you have to know a different formating/viewing tool for each platform as well as the log format.

I leave it up to you to consider which situation is easier on the sysadmin.

1.) yes is true but in text depend how the backend fails it can make corrupt the entire file too and in binary depending the backend you can only lose 1 byte or the whole file, so is pretty much to the implementation of it not an absolute consequence of the type per se.
2.) well this is true but systemd already include the tool to read the logs(journalctl) so it alleviates this scenario a bit and journald forward the data to r/ng/syslog if you enable that service and you can work like before because no version of syslog ever started at early boot, so you loose nothing compared to the old days
3.) see 2, you are been a bit narrow too because you haven't investigated enough and started assuming things but as explained you just enable syslog service and you can have both ways even the creator of syslog explained it on his site (systemctl enable/start r/ng/syslog and voila)
4.) KISS is about simple algorithms and modularity not code, if you worked with anything older than unix you should remember the previous ways of sequential monolithic super do all executables and why KISS was an important swap in concepts and stability, in this regard systemd is KISS at algorithm level and is extremely modular but of course 40 years later the kernel code is waaaaaaay more complex and efficient, so any software using kernel code is going to be hard to read for anyone not used to develop that close to the metal.

for the sysadmin is irrelevant as long as you enable your favorite syslog and in fact will make your life easier with the extra features, go and see the administrators guide in systemd site to get a better idea. with so many trolls here sending all kind of wrong informations is hard to solve doubts so is better to go straight to the source

[ceage]

My favourite part about this entire discussion is a few things.

1. The argument that systemd essentially pisses all over the UNIX legacy blah blah blah. By using Linux, you're using an operating system that does so with a major system component: the kernel itself. In the many years that it's been under development do you not have the slightest clue at how massive it's become? If you're so concerned about UNIX's legacy -- use MINIX or straight up UNIX.

The ironic part of this conflict is that those gentlemen who like to present themselves as legitimate followers of the `School of True Unix Paradigms & Ideas' are in fact actively contributing to bringing discredit to functioning, still up-to-date Unix design practices. Their heads are brimming with catchy one-liners about system design and that's pretty much the only excuse they need to stop using said body part. As soon as they get in danger of leaving their superficial manner of thinking about software, they resort to parroting some other gentleman, who, once upon a time on IRC or Usenet, inaugurated them into the ways of good software design by reciting the holy words:

``Programs should do one thing well. Now be on your way, Son. Spread the word, so that humankind may henceforth live in harmony with one another.''

It has to be one of the most abused phrases in the history of computing. If I were the sentimental type, I'd have developed an aversion against it by now, despite the fact that I consider it to be useful, simply because some people will never grow tired of rattling it out again and again and again, without even making the slightest effort to fill it with meaning.

I'm claiming that anybody can make each and every single software system in existence simultaneously comply with and violate that requirement in the blink of an eye without even touching a single line of code. Provided they first pull their heads out of whichever opinion leader's rear end it might be sticking in. Apart from that, nothing more than a mere mental hack is needed. After all, Unix is, according to its designers, one big development environment and hacking is what Unix people do, right? Right. The hack works like this:

Step 1: Come up with a definition of ``one thing''.

... and that's it. Now, I've applied this hack to my systemd's /sbin/init just recently and guess what: it worked! All of a sudden systemd's /sbin/init managed the run time state of my system. There you have it. It's doing only one thing and it's doing it pretty damn well, I consider. Halle-friggin-lujah! This hack even works when applied to the whole Microsoft Windows operating system. It's only a matter of definition. Damn. Now, don't y'all dare get ideas and cheat on poor Misses Linux now, fellas!

Wait a second. Let's not be quite so hasty. Let's rather take a moment and remind ourselves of what the actual definition of a computer program is: ``A program is a sequence of individual steps.'' Wait, what? A sequence? As in ``More than one thing''? There's an oddity. Is that supposed to mean, by any chance, that the phrase ``Programs should do one thing well'' is, strictly speaking, a contradiction in terms? Bingo! A contradiction is exactly what this is. So, how could the original Unix designers, smart as they are, not have realized that? Well, I believe they did. Indeed, it should be pretty safe to assume those guys knew exactly that a simplifying catch phrase summarizing a whole OS design for the purpose of communication is not meant to be taken quite so literally. Maybe the intent was to convey a certain approach to tackling problems. Yes, now that I've come to think about it, I'm quite certain that I once read something along those lines in a book called `The Unix Programming Environment' by Brian Kernighan and Rob Pike. Maybe, and I might be taking a leap here, *maybe* the real difficulty is not in writing programs that do one thing. Maybe it's in coming up with a definition of what the heck ``one thing'' is supposed to mean in practical terms: what is a logical, manageable unit of functionality that has to be implemented to solve a given problem? Is my description of the problem even meaningful? *Maybe* the answers to those questions vary depending on the context I work in, and maybe the context itself keeps changing slowly but steadily since even before the 1970s.

Yes, Unix philosophy can be helpful in guiding a designer onto the right path when devising a new system. What systemd opponents fail to acknowledge is that those guidelines don't compensate for a lack of careful interpretation, adaptation and good thinking in general. However, those gentlemen are most likely not interested in solving problems in the first place. Their biggest worry, it seems, is their emotional attachment to their habits. Habits which necessitate maintaining a simplistic view of computing out of pure self-interest. If at least they were sincere enough to admit that.