SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
GConf: GConf (GNOME configuration library)
GConf:
GConf: GConf is a configuration database system designed for the GNOME project
GConf: and applications based on GTK+. It is conceptually similar to the
GConf: Windows registry.
GConf:
GConf: For information, see: http://projects.gnome.org/gconf/
GConf:
We also have dconf and xfconf doing basically the same thing. And none of them uses plain text files. And the chance is that all the three of them run at the same time. This definitely isn't the "Unix way".
What is exactly the problem with the namespaces and object oriented protocols.
And what is exactly the problem with the plain text human readable INI file.
And what exactly a "good OS" means.
Cheers
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
And the modern software is ten times better than what we had 5 or 10 years ago on Linux.
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.
Quote:
Originally Posted by belka.ew
There are less problems with drivers, less problems with multimedia, document editing and everywhere.
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.
Quote:
Originally Posted by belka.ew
(maybe because I don't need to spend a week anymore to get something working)
A week to get something working! :lol: You can't blame the OS for the gaps in your own knowledge.
What is exactly the problem with the namespaces ...
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.)
Quote:
Originally Posted by ivandi
... and object oriented protocols.
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.
Quote:
Originally Posted by ivandi
And what is exactly the problem with the plain text human readable INI file.
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.
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.
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
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.
Last edited by Didier Spaier; 11-02-2014 at 10:01 PM.
Most of the old various Linux init systems are covered by prior art.
Who is making sure systemd isn't violating any patents?
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.
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.
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).
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.
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).
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.