systemd discussion: agree to disagree

[steveL]

Textbook example how to deal with a troll is not to deal with a troll. I've had great success doing just that. Trolls go elsewhere when not fed.

In general, that's the best approach.
It doesn't work when the person in question is stuck on auto-repeat ("and I have another post in me" is a good indicator that's happening.)
In this, forums are no different to IRC.

Where they differ is that the trolling is preserved, unless reported and moderators see fit to delete it.

As such, they are useful to the Stalinists who want that "uniform pattern of public utterances" I mentioned.
In the context of the systemdbust propaganda campaign (or "gentle Putsch"), it doesn't matter so much that no-one here believes a word of axl's nonsense; what matters is that any newbies who haven't been infected yet, are kept susceptible, and thus when they cast around the web for alternative opinions, what they see is a wall of text with half-truths and rhetoric that has been fed from "upstream".

Since that is what's going on, it's important to nip it in the bud, and between us keep on insisting that:
No; shit is still shit, however much you talk delusional nonsense about it, and irrespective of how many webpages you can find which insist it is in fact shinola.
==

The true object of propaganda is neither to convince nor even to persuade; but to produce a uniform pattern of public utterances in which the first trace of unorthodox thought reveals itself as a jarring dissonance.

Now consider that "cognitive dissonance" is a term coined by the "Advertising industry" to describe what they do, and it is a neologism for "lazy thinking".
Consider also that "Advertising" used to be known as the Propaganda industry, in the years after the "second World War", when the Ministry of Propaganda was well regarded.

edit: spacing

[berferd]

Emacsd anyone? :twisted:

We have a winner.

EDIT: No irony implied. Roki942 has summed up systemd in two words.

[steveL]

I can see why you favor TIPC. It is already what kdbus (that has nothing to do with D-Bus, btw.) never achieved, it is included in the kernel.
But TIPC is meant for clusters. If D-Bus is overkill... well... I'd favor it anytime anyway over D-Bus. But how do you advertise using Cluster oriented messaging mechanisms on single-machine systems?

Eh? Local node is always the first thing to deal with, when it comes to networked data.
But see that last link I gave, for technical detail. Note that the assumptions at the end actually work in our favour. (That's why they're made wrt clustering, and apply even more so, or are not relevant, for localnode.)

See also the next two posts (and the main post's breakdown of the signal flow.)

Yes, that would still be the (much) better variant to D-Bus. Unfortunately I can't see this happening anytime soon.

Why not? All it takes is a few coders who are fed up of working against crappy amateur-hour interfaces to an idiot-box implementation. (I do not work in this area, so it's not in my ballpark.)
There isn't actually any work needed to implement "kdbus" since it already exists. One just has to use it, and establish a basic ABI with a control channel. (And stick to it.)
As you said yourself:

someone thought it would be a great idea to kill DCOP and switch to D-Bus.., no matter how often and hard we bang our head onto the table. (I did, when I saw that move. I was outraged that a perfectly fine system was replaced by ... that...)

Do you really believe that no other coders working in the desktop/session arena do not feel the same? Including on BSDs.

You clearly have at least some time, and interest, as well as sufficient skill, to work in this area. You know that there are thousands of other admins, bug-wranglers and programmers who want the clean, useful approach.

I find it amazing that you feel so constrained by what one single group of people, out of so many billions, does; it seems to me like conditioning, completely at odds with the supposedly sociable "modern" Linux community. I thought reaching out to other coders, and not having to deal with people you don't want to, was the whole attraction of FLOSS.
That and the freedom to do things correctly and think longer-term than commercial pressures usually allow.

As stated, the "irreversible" argument is completely bogus when it comes to software.

So lose that misconception: it's only sociopolitical pressure attempting to promulgate a technical fallacy. ("we've got all the toys, and if you don't like it you can get out of the sandcastle.")

Lul, it's only software, people. It can be removed and supplanted at will; that is the point of it.
Some idiot's power-domain is irrelevant to what my computer does.

[eohrnberger]

systemd discussion: agree to disagree:

systemd, I'm not in favor.

The initv system seems to be built on the very UNIX philosophy of small and specific. Each script in /etc/init.d is it's own little thing, and easily understandable and tailored to the need.

systemd seems not to built on this philosophy, providing a larger, more complex, harder to understand system to replace initv.

One of the reasons that I stick with Gentoo is that initv has been supplanted by systemd by many of the other LiuLinux distributions. At least with Gentoo you still have a choice if you want systemd or not, but how long that's going to remain be the case?

Just my two cents worth, I guess.

[Yamakuzure]

I can see why you favor TIPC. It is already what kdbus (that has nothing to do with D-Bus, btw.) never achieved, it is included in the kernel.
But TIPC is meant for clusters. If D-Bus is overkill... well... I'd favor it anytime anyway over D-Bus. But how do you advertise using Cluster oriented messaging mechanisms on single-machine systems?

Eh? Local node is always the first thing to deal with, when it comes to networked data.

of course! And it is the default anyway.

About the switch to dbus:

Do you really believe that no other coders working in the desktop/session arena do not feel the same? Including on BSDs.

Of course not. I fail to see where I gave that impression, and am sorry that I sounded like that.

You clearly have at least some time, and interest, as well as sufficient skill, to work in this area. You know that there are thousands of other admins, bug-wranglers and programmers who want the clean, useful approach.

I find it amazing that you feel so constrained by what one single group of people, out of so many billions, does; it seems to me like conditioning, completely at odds with the supposedly sociable "modern" Linux community. I thought reaching out to other coders, and not having to deal with people you don't want to, was the whole attraction of FLOSS.

On the contrary, my time is very limited.

I doubt I'll have any time to play around with TIPC soon. Further I doubt that TIPC can automatically start services once they are needed. It seems like TIPC can only support what has been started beforehand. But I didn't really dig into TIPC that deep to be sure of that.

[CasperVector]

Speaking of the message bus issue, I am looking forward to the first formal release of skabus.
I am really unfamiliar with system programming, but I personally feel curious about how you people would think about ZeroMQ.

[berferd]

...I personally feel curious about how you people would think about ZeroMQ.

http://250bpm.com/blog:4

I think I understand exceptions better than he does. Then again, maybe I'm missing something.

[geki]

...I personally feel curious about how you people would think about ZeroMQ.

http://250bpm.com/blog:4

I think I understand exceptions better than he does. Then again, maybe I'm missing something.

There is nanomsg as a bus(or such) from the ZeroMQ developer, referenced in the blog post. Looks interesting and development seems to be active.

[berferd]

A new project, nng, is underway as reimplementation of these same protocols. nng is wire compatible with nanomsg, and offers a number of additional advanced capabilities. Although nng itself is still in pre-release state, we are encouraging people using or considering using nanomsg to look at nng.

[Yamakuzure]

...I personally feel curious about how you people would think about ZeroMQ.

http://250bpm.com/blog:4

I think I understand exceptions better than he does. Then again, maybe I'm missing something.

Well, the blog post is a nice read, but it is the comment section I find very interesting. It is fascinating how people think about the "C versus C++" problem.
My take on that: Choosing C over C++ is shooting yourself in the foot with a nail gun. C is the Core of C++, so you can do everything in C++, that you can do in C. Plus having a type safe compiler. C compilers are type unsafe.
The misunderstanding of literally everyone who has ever tried to tell me that C is a better choice than C++ was, that they where convinced that they had to use higher C++ structures when choosing C++. That's simply not true. If your C program does not compile with a C++ compiler, then your code is just broken and only works with your C compiler by accident.
(And that comes, but that is my personal and very subjective opinion, from too many wannabe C++ "Codaz" who throw tank size class constructs at every tiny x+y problem. Because C++)

A new project, nng, is underway as reimplementation of these same protocols. nng is wire compatible with nanomsg, and offers a number of additional advanced capabilities. Although nng itself is still in pre-release state, we are encouraging people using or considering using nanomsg to look at nng.

That looks promising!

Maybe there is still light at the end of the tunnel!

[Naib]

...I personally feel curious about how you people would think about ZeroMQ.

http://250bpm.com/blog:4

I think I understand exceptions better than he does. Then again, maybe I'm missing something.

There is nanomsg as a bus(or such) from the ZeroMQ developer, referenced in the blog post. Looks interesting and development seems to be active.

The problem with such things is usurping what is present. It might be picked up by little known project that don't want to use dbus either because too heavy or for political reasons. This does nothing for the large amount of use cases that are deployed ... Inertia

There needs to be a collective will to replace dbus and that doesn't exist. So either a valid usecases breaks dbus so that need requires another IPC to compliment dbus (to then replace), or it is slowly pushed out.

Remember qt has dbus bindings making it "easier" for those that use that toolkit to use dbus transparently.

[CasperVector]

If your C program does not compile with a C++ compiler, then your code is just broken and only works with your C compiler by accident.

I recently found that the use of `void' in `int main (void)', while being advisable in C, might be considered as not standard-conformant in C++

[proteusx]

The problem with such things is upsuring what is present.

What is the meaning of this?

[Naib]

The problem with such things is upsuring what is present.

What is the meaning of this?

auto-correct thought it knew best.. usurping

[NeddySeagoon]

proteusx,

Overcoming the inertia so that the new thing will replace the old thing.

New does not mean better, usually, it just means different.
e.g. udev persistent device names just swapped one set of corner cases for another set of corner cases.

[Naib]

proteusx,

Overcoming the inertia so that the new thing will replace the old thing.

New does not mean better, usually, it just means different.
e.g. udev persistent device names just swapped one set of corner cases for another set of corner cases.

well the initial query was based upon a typo. But yes... usurping , to overthrow, to replace.
New doesn't necessarily mean better but i think we can agree that dbus isn't great and it wouldn't take much to be better. BUT being better isn't enough, the use-case inertia can easily kill off replacement, likewise never underestimate "good enough " (see betamax vs VHS)

also obligatory XKCD https://imgs.xkcd.com/comics/standards.png

[CasperVector]

The problem with such things is upsuring what is present.

What is the meaning of this?

I think it should have been "usurping" (so not "upsurping" either ;).

[proteusx]

Naib

I always read your posts with interest.
My question was not meant to be a dig at the spelling. I looked up the word in vain, and the sentence made no sense.
I am not a native speaker of English.

[Tony0945]

The misunderstanding of literally everyone who has ever tried to tell me that C is a better choice than C++ was, that they where convinced that they had to use higher C++ structures when choosing C++. T

Exactly! A common complaint is huge memory requirements and disk space. That's because textbooks (and presumably lectures) talk of nonsense things like Dog is a subclass of mammal which is a subclass of Animal. As a result when writing a program to schedule feeding your dog the coder implements a huge structure of complete classes that is not needed and you get a program with cat dietary requirements as well.
It's a pet peeve (pun not intended) of mine. Teach a class as what it is: an extension of a C structure that includes pointers and references to functions.

(And that comes, but that is my personal and very subjective opinion, from too many wannabe C++ "Codaz" who throw tank size class constructs at every tiny x+y problem. Because C++)

That's how they were taught. And way to many "software Engineers" are trained monkeys with no feel for what they are doing.

Maybe there is still light at the end of the tunnel!

I fear it's another train.

Re "(int)main(void)" Because it's wrong. The OS always calls main(int argc,char **argv) where argc >= 0
If you don't care about the arguments you can avoid stupid compiler warnings you cheat. Coding for Windows I sometimes use "void main(void)" because of compiler settings to treat all warnings as errors and I don't care to create meaningless exit codes that will never be used.

A C++ class doesn't have to have absolutely every conceivable class member either which also escapes professors.

[Naib]

The problem with such things is upsuring what is present.

What is the meaning of this?

I think it should have been "usurping" (so not "upsurping" either .

d'oh... thats the one... got my engineering head firmly on at the moment

Naib

I always read your posts with interest.
My question was not meant to be a dig at the spelling. I looked up the word in vain, and the sentence made no sense.
I am not a native speaker of English.

Oh I didn't read it as a dig, was more trying to get thing right...

[NeddySeagoon]

Naib,

I didn't even spot the typo, I read it as "usurping". :(

[mrsteven]

If your C program does not compile with a C++ compiler, then your code is just broken and only works with your C compiler by accident.

I recently found that the use of `void' in `int main (void)', while being advisable in C, might be considered as not standard-conformant in C++

Huh?! There never was anything wrong with that. Your link does not even state otherwise. Following forms are equivalent and explicitly permitted by the C++ 99 standard (and AFAIK nothing changed later on):

Code: Select all

int main() { /* ... */ }
int main(void) { /* ... */ }

Generally, in C++ f(void) has the same meaning as f(). In C, f() tells the compiler not to check the parameters, while f(void) explicitly states that f does not take any parameters.

Of course, void main() is just plain wrong (in C and in C++) and you should feel ashamed by just thinking about writing it in a real world program.

[Tony0945]

Of course, void main() is just plain wrong (in C and in C++) and you should feel ashamed by just thinking about writing it in a real world program.

How about this:

Code: Select all

sqrt[]=" comma separated list of hex codes";

....
v = r * sqrt(P); /*sic */

The array is initialized with an assembly language function that uses the PowerPC SQRT function.

[CasperVector]

Huh?! There never was anything wrong with that. Your link does not even state otherwise. Following forms are equivalent and explicitly permitted by the C++ 99 standard (and AFAIK nothing changed later on): [...]

Sorry then, I just spotted this sentence, which might have been itself a result from misunderstanding of the wording:

In C++, the names are to be taken literally, and the "void" in the parameter list is to be omitted, if strict conformance is desired.

[mv]

One can certainly find some subtle syntax corner cases in which C and the C-core of C++ differ (BTW, there are K&R C, Ansi C, ... as well as C++98, C++11, C++14, ...).
But I think this is irrelevant to the C/C++ discussion since these corner cases certainly don't make a compelling feature of one of the languages (unless one speaks about adapting a huge existing code base). (BTW, even here the features are IMHO on the side of C++ since it is usually stricter and thus helps to avoid accidental errors.)