Linux - SoftwareThis forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.
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.
Don't all of the three initializers run under the name, init?
I then tried this:
Code:
prompt$ ps 1
PID TTY STAT TIME COMMAND
1 ? Ss 0:03 /sbin/init
prompt$ ls -l /sbin/init
-rwxr-xr-x 1 root root 265848 Jul 18 2014 /sbin/init
prompt$ file /sbin/init
/sbin/init: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=7a4c688d009fc1f06ffc692f5f42ab09e68582b2, stripped
This is the sort of "how to ask the workstation" info I'm looking for. Thanks. Sadly, I still don't have an answer for: sysvinit vs. upstart vs. systemd.
i think debian (based) systems are in some sort of transition from sysvinit to systemd, which means that both systems are in use, and init scripts simply call systemd units/services. (or something like that. i've seen it on a debian jessie system, but i'm not exactly sure how it works. i'm probably using wrong terms here.)
not sure how that translates into ubuntu, but it's still debian-based, no?
Non of my AntiX Installs run systemd. Example from your guys commands
Code:
$ cat /proc/1/comm
init
$ ps -p 1 -o comm=
init
I guess if you wanna dig deeper. If any systemd resides on your system.
Code:
man systemctl
If it says no manual. No systemd is present. If it spits out tons of info. Suprise, suprise, suprise. As gomer pyle would say.
You are running systemd.
AntiX runs without it so far but certain apps are starting to complain on install/uprade about needing libsystemd0 as a dependency for like cups and such. Like a slow mud slide. Creep is kicking in
Edit: suprised myself. This
Code:
$ cat /etc/issue
Linux Mint 17 Qiana \n \l
Does not run systemd either. Who would have thought?
Since all software has the name init, how is someone supposed to know which package is doing the work?
sysvinit
upstart
systemd
When I try to search online, anything using systemd or upstartd gets a long list of cussing and discussing.
When I try locate systemd and locate upstart it seems that both are present on my workstations.
Is there some way to ask a running workstation which init package is in actual use?
Thanks in advance,
~~~ 0;-Dan
Everything works easy with sysvinit. systemd has a few advantages at the cost of the control of your own system. The online documentation is poor, and the documentation in systemd itself is lacking.
Its a big mess that everyone is embracing.
Hopefully, choice will be offered by most distros in the future.
Everything works easy with sysvinit. systemd has a few advantages at the cost of the control of your own system. The online documentation is poor, and the documentation in systemd itself is lacking.
Its a big mess that everyone is embracing.
Hopefully, choice will be offered by most distros in the future.
Sadly, I don't think that will happen. MOST have simply accepted that SystemD is the way to go and have abandoned offering choices. Of the "major" distro's, I believe Slackware is the only one that hasn't moved to SystemD (even Ubuntu abandoned upstart and have gone systemd).
...
MOST have simply accepted that SystemD is the way to go and have abandoned offering choices.
...
I've created software systems since the late 1960's. Time and again, I've seen software create, features added, fluff & bloat, etc. Eventually, the large, monolithic application gets re-factored for all sorts of reasons.
I expect this will also happen to what we now call 'systemd'.
I've created software systems since the late 1960's. Time and again, I've seen software create, features added, fluff & bloat, etc. Eventually, the large, monolithic application gets re-factored for all sorts of reasons.
I expect this will also happen to what we now call 'systemd'.
~~~ 0;-Dan
Eventually, I don't doubt. But not in the next few years, I imagine.
Distribution: K/Ubuntu 18.04-14.04, Scientific Linux 6.3-6.4, Android-x86, Pretty much all distros at one point...
Posts: 1,802
Rep:
Keep in mind that while many distros are switching to systemd, they are not doing it wholesale at this point. Most are simply including those parts of systemd that they need for dependency reasons with other packages (the Desktop Environments, mostly), and keeping the init that they have been using to date (Upstart, for the most part). The obvious exceptions to that are the latest versions of RHEL, CentOS, Scientific, et al.
Keep in mind that while many distros are switching to systemd, they are not doing it wholesale at this point. Most are simply including those parts of systemd that they need for dependency reasons with other packages (the Desktop Environments, mostly), and keeping the init that they have been using to date (Upstart, for the most part). The obvious exceptions to that are the latest versions of RHEL, CentOS, Scientific, et al.
The thought of that is scary. Thats the kind of bundle and control and uniform system that many GNU/Linux users just don't want. If we wanted a bundle with no choice we would all use Microoft Windows or Apple OS X.
We dont need more dependencies, we need more independent functions which only relies on libraries. We dont need to chain system functions together with desktop functions, or chain all libaries together with functions and system functions.
GNU/Linux is all about choice, and chaining and making dependent everything is a bad idea.
GNU is the core and the drivers and hardware functions are done by Linux. X is the volunteer part of the system which so far hasnt offered any alternative. Wayland is being implemented now. All the various desktops is another part of the system. Bootloaders there are several of.
In theory and actuality, these parts can all be idividually replaced by alternatives. Linux kernel with GNU Hurd or BSD. GNU itself can be replaced as send with busybox and Android. Xorg graphical environnement can be replaced with Wayland and all the desktops can be raplaced by each others.
This is the beauty of GNU/Linux and computer freedom. Aside from it, tons of other compponents exist and all or most have alternatives.
The obvious way forward is that distroes offer various options and that the change is as seamless as changing from X to Wayland or Gnome to KDE.
Or do most people here use "use whole partition" instead of "custom partition setup" when thwy install their system?
Classic Unix/Linux does have one management-problem: "lots and lots of independent config-files, owned by lots and lots of independent processes, all supposed to be 'working together.'" Even though sysadmins have gotten good at this ... even have gotten used to it ... the situation is far from ideal. When you multiply the problem by "hundreds of blade computers in a modern computer center" (I still prefer mainframes, myself ...), it becomes very expensive and risky.
Of course, Microsoft Windows went far too-far the other way, creating (in effect) its own mini-filesystem in the form of "the Registry," which literally controls so much of the operating system's behavior that it serves as a gigantic Achilles Heel.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
