Linux - GeneralThis Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then this is the place.
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.
View Poll Results: Are you for or against systemd?
are you serous
the code looks like an endless loop to me
I don't code in C but it looks to me that all your example dose is open window after
after window after window after window until the power switch is turned off
I will give more infos about the code above so that it helps to experimentally study the output.
Most X11 or Motif applications (on simple -lX11, -lXm,...) are today outdated, nonsense,... for most of linux community.
Reason is shinning applications, like Windows or Mac does. It takes however resources on your system.
Ok, so far are you with me?
So, let's go further. The above example is a simple demo for making a GTK window of "Hello World". Very simple. If you may try to place this above code into a file and to compile it with gcc.
You will notice that you will need all those dependencies, many have no points to be installed, right?
Free Software Foundations is very clear on this matter. You try to focus on non proprietary software, i.e. open source (...) and to avoid to use libraries that will bound you in some matters.
On most debian-based systems, one can run apt-get to get to necessary libs to compile. apt-get to compile the above will results in the above packages, which is actually not according to the philosophy.
But, I think, that no one care at all about this problem....
Some people, I think, are very receptive to change. But others appear to think that, "if it was good enough for a PDP-7 at Bell Labs in the 1970's, it's still good enough today!"
Well, "like it or not, that's just not true."
Today, "the use case has fundamentally changed." Computer systems are no longer isolated. In fact, they might be virtual. And in any case, there might be many hundreds of them ... or, yes(!),thousands.
Features of systemd that are of no use whatsoever to "an individual Linux machine on the desk in your second bedroom" suddenly become very important when you are tasked with simultaneously managing hundreds or thousands of them, and when all of them are in "far-away places."
Face it: the "1970's metaphors" very-simply couldn't be carried forward. It wasn't an option anymore.
If "1970's metaphors" are still just fine with you, then ... "this is open source." There's nothing stopping you from implementing what you decide is best for you. And that's the beauty of it.
Last edited by sundialsvcs; 04-19-2017 at 06:15 PM.
On most debian-based systems, one can run apt-get to get to necessary libs to compile. apt-get to compile the above will results in the above packages, which is actually not according to the philosophy.
But, I think, that no one care at all about this problem....
ok thats the dependence list for that source code got it now
in slack the packages are much larger we do the whole gttk libes in one package it's one way of getting around of not having dependence checking in the package
Some people, I think, are very receptive to change. But others appear to think that, "if it was good enough for a PDP-7 at Bell Labs in the 1970's, it's still good enough today!"
Well, "like it or not, that's just not true."
Today, "the use case has fundamentally changed." Computer systems are no longer isolated. In fact, they might be virtual. And in any case, there might be many hundreds of them ... or, yes(!),thousands.
Features of systemd that are of no use whatsoever to "an individual Linux machine on the desk in your second bedroom" suddenly become very important when you are tasked with simultaneously managing hundreds or thousands of them, and when all of them are in "far-away places."
Face it: the "1970's metaphors" very-simply couldn't be carried forward. It wasn't an option anymore.
If "1970's metaphors" are still just fine with you, then ... "this is open source." There's nothing stopping you from implementing what you decide is best for you. And that's the beauty of it.
is this what you mean computers working together https://en.wikipedia.org/wiki/Beowulf_cluster
or do you mean like can be done with a simple wifi router and a little set up with out systemd
when the work of the system is split up up into smaller parts
it is posable to find where something goes wrong and fix it
with 595 issues (bugs) it doesn't look like YOUR ( as in I don't want it you can keep it ) new way is working very well at getting problems fixed
Some people, I think, are very receptive to change. But others appear to think that, "if it was good enough for a PDP-7 at Bell Labs in the 1970's, it's still good enough today!"
Well, "like it or not, that's just not true."
Today, "the use case has fundamentally changed." Computer systems are no longer isolated. In fact, they might be virtual. And in any case, there might be many hundreds of them ... or, yes(!),thousands.
Features of systemd that are of no use whatsoever to "an individual Linux machine on the desk in your second bedroom" suddenly become very important when you are tasked with simultaneously managing hundreds or thousands of them, and when all of them are in "far-away places."
Face it: the "1970's metaphors" very-simply couldn't be carried forward. It wasn't an option anymore.
If "1970's metaphors" are still just fine with you, then ... "this is open source." There's nothing stopping you from implementing what you decide is best for you. And that's the beauty of it.
I am not so sure about this.
You can still make your own operating system in assembler with almost nothing. You can still run a small system, which can evolve. (here)
Basically the system remains quite similar. Basics are still there.
However the big part, indeed huge complexity, is this hardware and kernel that will work not only on a single machine, but many millions. Big diversity of hardware: cpu, wifi, mem, .... good luck. And the best, it works actually.
Some people, I think, are very receptive to change.
Normally I agree with your writing, but in this instance I must disagree strongly and call out the use of the logical fallacy Appeal to Novelty, which is one of systemd's main promotional tactics. It's usually accompanied with some level of Ad Hominem and, lately, Appeal to Popularity, if not also other fallacies, but I hope they will continue to remain unused in the thread.
Newer is not better. Different is not better. Only better is better. Being a mass of undebuggable race conditions does not facilitate starting masses of servers. Nor do non-ACID compliant, binary logs, to pick at two old sores.
Them lying about it being an init system helped them spread it quite far, because for most people an init system is not interesting or relevant. So if it were only about replacing an init system, there would be little problem or complaint. However, it is nearly seven years since systemd stopped being an init system due to one of the worst cases of creeping featurism ever seen.
Quote:
Originally Posted by sundialsvcs
...
There's nothing stopping you from implementing what you decide is best for you. And that's the beauty of it.
Actually there is.
Again, if it were only about an init system, there would be no problem. Same if systemd were in any way modular. But it is neither and how it has metastasized to all kinds of unrelated packages makes it all but impossible for even a skilled group of people, with a lot of effort, to implement what is best instead. Just try installing without systemd. You can't, unless you change distros. There are only a few distros both willing and able to expend the great effort needed to clean up. Even with larger teams, it means occasionally cutting losses and dropping some packages completely, such as GNOME.
That leads to an observation about the open source assertion. An interesting comment I saw elsewhere addresses the complexity of the systemd code. It's so complex, non-modular, and interconnected that although it can be argued that it might fulfill the letter of the concept of OSS, it fails the spirit of the concept. For something to be OSS, the code must be made available. In the case of systemd, it is not possible for someone of either meager C skills or without the possibility and, more importantly, a willingness to invest an unreasonably enormous amount of time to get going at changing the code. So in practice the code is not available.
"Red Hat's model works because of the complexity of the technology we work with. An operating platform has a lot of moving parts, and customers are willing to pay to be insulated from that complexity. I don't think you can take one finite element—like Apache—and make a business out of it [using our model]. You need product complexity."
Distribution: Currently: OpenMandriva. Previously: openSUSE, PCLinuxOS, CentOS, among others over the years.
Posts: 3,881
Original Poster
Rep:
Quote:
Originally Posted by sundialsvcs
Some people, I think, are very receptive to change.
Can you expand on this, for example, who would you mean by "some people"? Do you think if most distro's developers dropped systemd in favor of something else, these people would still be receptive of change?
Quite incredible. If you read the article, you see that Red Hat's success is in unravelling complexity (hence the title of the article you linked to: "Red Hat's open source success story built on killing complexity in IT"), but you argue that this shows that Red Hat's model is in creating complexity.
That complexity already exists with the myriad of technological IT solutions that exist in the real world, there is no need to create any more. It's like arguing that the model of doctors is based upon making us ill and of the police force in creating crime to solve.
Here's one thing that I do know: systemd is not going away. No distro is going to go back to "good ol' init" out of sentimentality or otherwise. The bugs will continue to be found and fixed. And, if you're determined to think that a large and complex system must contain secret back-doors meant to spy on you, you're free to think that, too.
If you think that inittab and crontab and passwd cannot be improved upon, feel free. But, I've looked at a console screen that was controlling five hundred Linux machines, all of them remote, all at the same time. The "glue" that made this possible was systemd. That's very much the use-case that it was designed for ... not a single hobbyist running a Linux box in his den.
If you're not faced with this use-case, you might not see why any change is necessary – because, in your case, perhaps it isn't. But if you are running massively distributed workloads in a "cloud" of individual computers, you need what this software layer provides. And there are a lot of commercial users of Linux who are doing these things today. What they are doing would be very unmanageable without it.
Linux is the latecomer to this ball game. Both Windows and OS/X have been doing this for many years. It has been a barrier to the widespread adoption of Linux that it was so difficult to control en masse and that there was no way to coordinate activities across system boundaries. The systemd project was specifically designed to address such issues.
Last edited by sundialsvcs; 04-20-2017 at 08:13 AM.
Could I ask you to expand on the "execution" part of your reply?
binary journal makes it much harder to troubleshoot when there are issues
slower to start because of all the bugs
slower to stop because of all the bugs
huge security holes
Will never use any distro with systemd. Will stick with Slackware until the bitter end then will move on to either one of the BSDs or some other experimental OS but will never accept systemd.
Will never use any distro with systemd. Will stick with Slackware until the bitter end then will move on to either one of the BSDs or some other experimental OS but will never accept systemd.
What do you think? You believe that Slackware will not move on like other distros.
There is also a big business behind Slackware.
No, the best is to move to BSD. BSD is much cleaner than Linux. Linux is today in the hands of gnome.
Just because of gnome you got your systemd.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.