Sure, I agree with you.

1 members found this post helpful.

^^ That ^^ would be the perfect ending for this thread.

1 members found this post helpful.

good example
i would advise to go try to set up anything gnome related by hand, as i have when one of those tools changed my cursor
gtk/gnome do use plain text files behind that, and they are a mess

and no to whoever said that "unix" means only one
UNIX is a standard on how to make an OS similar to Unix
moreover that standard was improved upon over the years in POSIX ("Portable Operating System Interface")
and the standard does not say on HOW to do it, just the interface above it
and no, i am not an UNIX zealot
i could not care less about unix itself, even though slackware aims to be unix like

an OO protocol is not needed
the metadata can be tracked instead of sent with every message, reducing the memory and computation overhead

the linux kernel is more data driven then OO and it is event driven, not asynchronous
just like the computer is an event driven state machine

note also that the reason to put kdbus into the kernel is shared memory (what they keep falsely calling zero-copy)
while the current, user space, dbus is over a netlink socket that supports shared memory

namespaces are currently a mess, you can ask their devs about that
and namespaces, as i said, go against the "everything is a file" philosophy
for example, now you would type something like "cat /proc/sys/net/ipv4/ip_forward" to find out if forwarding is enabled
while with namespaces over dbus you would make a connection then ask an address like, idk, "org.kernel.ipv4.ip_forward"
same with a desktop manager needing upower to find out how much battery is left
that could be just a file /proc/sys/power/battery that when read says.. well.. how much battery is left
and it would be usable from any kind of program, and even a shell script (scripts are programs too)

as for INI, you are just trying to make me look like a "hater" and i find it a cheap blow
i clearly said it doesn't matter much, even though i find plain configs much better then the INI format


so a good os is event driven and exposes everything over virtual filesystems
plan9 is a good OS,
it's just a bit too complicated for your average developer so we have to settle with the next best thing
i'd advise researching about plan9, its /proc interface is relevant to this


edit:
i agree that modern linux is much better then it was just some 8 years ago
but that is more due to moving things into the kernel then adding layers on what was

Au contraire, mon frère.

KDE 4.x is demonstrably worse than KDE 3.x was 10 years ago. After 6 years of development, there are still some fundamental features of KDE 3.x which have not been implemented/replicated in KDE 4.
That's your opinion. IME, Linux has always had good drivers & multimedia support... At least going back as far as kernel version 2.2... In fact, I'd say that nothing has come close to it for at least 15 years.

Document editing? Do you mean word processing/typesetting? If so, then the same applies. There have always been good free options to do both of those tasks.
A week to get something working! :lol: You can't blame the OS for the gaps in your own knowledge.

3 members found this post helpful.

Namespaces can be quite useful in some situations; however, that doesn't mean that the init system needs to manage them if they are chosen to be used, and especially not that their usage should be mandatory. (I consider it to be similar to the situation with 'sudo' utility; a powerful tool for managing user permissions, but not necessarily to serve as a substitute for root.)

If a process (A) is sending a set of data to another process (B), even if B understands the organization of the data, A still has to convert the data to a format that the protocol can handle... and B has to convert it back to its original form. At least I think that would be genss's point (EDIT: not precisely what genss clarified, but along the same lines of inefficiency).

In addition to handling the above scenario inefficiently, DBus handles some situations that aren't needed (network transparent IPC), and doesn't handle some things that are (authentication, at least its not in the specification). For what it's worth, I am in favor of the proposal for KDbus, which seems to address precisely these points.

I don't have a problem if DBus is used for tasks such as finding out the hostname; however, such support should be in addition to, not instead of, the traditional mechanisms of running 'hostname', or calling the library function uname(), or looking at a file in /proc/sys/kernel.

With INI files one is limited to doing only what has been planned for by the designer. If you wish to do something that was not foreseen, you need to patch the program that is reading the INI file. This is not a problem if one uses a Turing-complete scripting language for configuration. You want to activate something based on X and Y being present but not Z, and only if it's a Tuesday in a month whose name ends in "y"? No problem, just write your script to test these conditions.

2 members found this post helpful.

I agree

Rational topics expand into threads with a finite number of posts, and irrational topics have infinite thread expansions. At any rate, we should be able to agree on a finite approximation.

When design choices meet politics

Some examples: 1 2 3.

Nothing unusual, shocking or surprising if you ask me. As far as system engineering is in concern, conflicting requirements coming from different stakeholders[1] is just business as usual, and it's hard that design decisions satisfy everyone then. Especially when the decision process is not designed to make compromises accepted by all. And we all know that le diable est dans les détails. For instance KMS is a good idea, until you get a black screen because of a failed handover.

[1] Even more funny, conflicting requirement sometimes originate from only one stakeholder.

1 members found this post helpful.

Hmmmm in the years I have spent in software design/development I do not believe I have ever seen that happen... no ... wait...

Most of the old various Linux init systems are covered by prior art.

Who is making sure systemd isn't violating any patents?

1 members found this post helpful.

You can check it, it is open source, just like Linux

Interesting point, and one I hadn't considered up until now.

Practically anything you do on a computer these days outside of well known prior-art is likely violating a ridiculously broad patent which should have never been granted, but is now "owned" by someone or other. Can't really blame systemd for this, but it is a good example of why maintaining the ability to have more than one choice is a wise thing to do.

1 members found this post helpful.

Honestly, this way of thinking is exactly what killed SCO.
It's no prior-art either, being derived from linux-only instructions (unless you consider booting/maintaining any service as something illegal).

https://lwn.net/Articles/490438/

This comment really made me chuckle.

Actually, all of the pre-emptive remarks about pitchforks and borging in that thread? All turned out to be totally true.

Really? SCO failed because they thought that "maintaining the ability to have more than once choice" was a good idea? I had no idea!

I always thought SCO failed because they decided that price gouging customers on licensing, and litigation was an easier way to make money than by providing a competitive product and service. Well, OK, I stand corrected.

2 members found this post helpful.