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?
Actually, would the term 'freedestop components' be more expressive, instead of referring just to systemd? Distributions are still, sometimes, distinguished based on the package managers they use by default. So, are they going to be, or should be, distinguished by something along this line?
It could defuse a lot of controversy, when people start looking at distributions as such. Eventually, it should be understood that X, Y and Z distributions are 'freedestop components-based', and others are not, and complaining about the fact is pointless.
Out of interest, what do you mean by "freedesktop components-based"?
The term "Linux proprietary", I used in this thread has nothing whatsoever to do with proprietary, closed source, software. It simply means "Linux owned". It's probably a term we use more in *BSD circles. It means software which is generally consider to have no or poor portability to other *nix (or other OS).
Quote:
Originally Posted by alabit
Thanks folks, this weekend I am going to try and switch a minimal Debian 8 from the default to sysvinit.
As always. Md5sum check at least iso downloads for file integrity. There are other safe gaurd links to check iso's also for the tin foil hat folks also.
After install, You can look at
Code:
harry@biker:~
$ cd /etc/apt
harry@biker:/etc/apt
$ ls
apt.conf preferences.d trustdb.gpg trusted.gpg~
apt.conf.d sources.list.d trusted.gpg trusted.gpg.d
harry@biker:/etc/apt
$ cd preferences.d
harry@biker:/etc/apt/preferences.d
$ ls
00systemd
harry@biker:/etc/apt/preferences.d
$ cat 00systemd
Package: *systemd*
Pin: origin ""
Pin-Priority: -1
harry@biker:/etc/apt/preferences.d
Not sure which is easier for you. Since you said switch. Since I don't know what you have invested in your Debian 8 install. Just posting info on a alternative route that might be useful to you. Disregard if I am off base.
This may be a bit naive, but I don't see why systemd had to be such a colossus. If it were truly modular, I think people would have much fewer problems with it.
For example, systemd itself could have been purely an init system based on the excellent idea of opening all daemon sockets in advance and then simultaneously launching the daemons to take them over, thus speeding up the boot. Subsequently the program would act as a babysitter for the daemons, launching additional ones when a socket or spool queue was accessed and relaunching those that crashed.
Quite separately, there could have been a binary journal program for those who wanted more selective journal displays than are available from text loggers like syslog. Those who didn't want a binary journal (and that means most of us) would not have needed to install this.
The configuration programs could have been alternatives to individual init scripts for those sysadmins who found configuration easier using a .ini-type service file than trying to edit a complex script. So for instance you could install timed/timectl or logind/loginctl if you wanted them and not otherwise.
If it had been done this way, applications would have been much less likely to become systemd-dependent and people would not have had this feeling of being railroaded into using it, which is responsible for most of the bad feeling.
Not sure which is easier for you. Since you said switch. Since I don't know what you have invested in your Debian 8 install. Just posting info on a alternative route that might be useful to you. Disregard if I am off base.
THANKS!
You read my mind. I was wondering where to start, what to try first.
I am going to read the virtualization forum next because I need to change my habits of using heavy VirtualBox images for everything and find alternatives.. for the first time in years I need to rethink a lot about the way I do things. Read you there, hopefully.
Thanks folks, this weekend I am going to try and switch a minimal Debian 8 from the default to sysvinit.
You should certainly NOT do this like this. try to play around with debootstrap a bit, in order to look around what are critical part to be removed for a clean installation, and try to make a list of debs without systemd. The rest you compile it yourself carefully on Sysvinit.
some people mentioned apple's launchd and the fact that systemd didn't start out from nothing, that there were "progenitors" - i'd like to hear more about that!
i guess they don't have a common codebase?
so where exactly did systemd come from?
some people mentioned apple's launchd and the fact that systemd didn't start out from nothing, that there were "progenitors" - i'd like to hear more about that!
[JOKE]
Hey guys, I am a new Poettering, I will replace X11 with WIN11, and put pulseaudio instead of ALSA into your kernel! It shall be more complex and it will handle automatically everything. Trust your system. I want also to have instead of the directory /bin/ a directory /system32/ and remove cp and replace it by xcopy. mv will be move. Soon, Debian/Ubuntu and most other distros will implement it since it is a cool innovative idea.
[/JOKE]
That's modern world, things have to change and look a bit more like Windows. Maybe, Windows pays guys to make Linux more like a Windows Spying Platform, like Win10
Jsbjsb001 LQ should have just said they don't do homework...
Fundamentally we're talking Linux which is compiled (ie binary) is it not?
Quote:
The message data is generally not authenticated, every local process can claim to be Apache under PID 4711, and syslog will believe that and store it on disk.
The data logged is very free-form. Automated log-analyzers need to parse human language strings to a) identify message types, and b) parse parameters from them. This results in regex horrors, and a steady need to play catch-up with upstream developers who might tweak the human language log strings in new versions of their software. Effectively, in a away, in order not to break user-applied regular expressions all log messages become ABI of the software generating them, which is usually not intended by the developer.
The timestamps generally do not carry timezone information, even though some newer specifications define support for it.
Syslog is only one of many log systems on local machines. Separate logs are kept for utmp/wtmp, lastlog, audit, kernel logs, firmware logs, and a multitude of application-specific log formats. This is not only unnecessarily complex, but also hides the relation between the log entries in the various subsystems.
Reading log files is simple but very inefficient. Many key log operations have a complexity of O(n). Indexing is generally not available.
The syslog network protocol is very simple, but also very limited. Since it generally supports only a push transfer model, and does not employ store-and-forward, problems such as Thundering Herd or packet loss severely hamper its use.
Log files are easily manipulable by attackers, providing easy ways to hide attack information from the administrator
Access control is non-existent. Unless manually scripted by the administrator a user either gets full access to the log files, or no access at all.
The meta data stored for log entries is limited, and lacking key bits of information, such as service name, audit session or monotonic timestamps.
Automatic rotation of log files is available, but less than ideal in most implementations: instead of watching disk usage continuously to enforce disk usage limits rotation is only attempted in fixed time intervals, thus leaving the door open to many DoS attacks.
Rate limiting is available in some implementations, however, generally does not take the disk usage or service assignment into account, which is highly advisable.
Compression in the log structure on disk is generally available but usually only as effect of rotation and has a negative effect on the already bad complexity behaviour of many key log operations.
Classic Syslog traditionally is not useful to handle early boot or late shutdown logging, even though recent improvements (for example in systemd) made this work.
Binary data cannot be logged, which in some cases is essential (Examples: ATA SMART blobs or SCSI sense data, firmware dumps)
Quote:
Simplicity: little code with few dependencies and minimal waste through abstraction.
Zero Maintenance: logging is crucial functionality to debug and monitor systems, as such it should not be a problem source of its own, and work as well as it can even in dire circumstances. For example, that means the system needs to react gracefully to problems such as limited disk space or /var not being available, and avoid triggering disk space problems on its own (e.g. by implementing journal file rotation right in the daemon at the time a journal file is extended).
Robustness: data files generated by the journal should be directly accessible to administrators and be useful when copied to different hosts with tools like “scp” or “rsync”. Incomplete copies should be processed gracefully. Journal file browsing clients should work without the journal daemon being around.
Portable: journal files should be usable across the full range of Linux systems, regardless which CPU or endianess is used. Journal files generated on an embedded ARM system should be viewable on an x86 desktop, as if it had been generated locally.
Performance: journal operations for appending and browsing should be fast in terms of complexity. O(log n) or better is highly advisable, in order to provide for organization-wide log monitoring with good performance
Integration: the journal should be closely integrated with the rest of the system, so that logging is so basic for a service, that it would need to opt-out of it in order to avoid it. Logging is a core responsibility for a service manager, and it should be integrated with it reflecting that.
Minimal Footprint: journal data files should be small in disk size, especially in the light that the amount of data generated might be substantially bigger than on classic syslog.
General Purpose Event Storage: the journal should be useful to store any kind of journal entry, regardless of its format, its meta data or size.
Unification: the numerous different logging technologies should be unified so that all loggable events end up in the same data store, so that global context of the journal entries is stored and available later. e.g. a firmware entry is often followed by a kernel entry, and ultimately a userspace entry. It is key that the relation between the three is not lost when stored on disk.
Base for Higher Level Tools: the journal should provide a generally useful API which can be used by health monitors, recovery tools, crash report generators and other higher level tools to access the logged journal data.
Scalability: the same way as Linux scales from embedded machines to super computers and clusters, the journal should scale, too. Logging is key when developing embedded devices, and also essential at the other end of the spectrum, for maintaining clusters. The journal needs to focus on generalizing the common use patterns while catering for the specific differences, and staying minimal in footprint.
Universality: as a basic building block of the OS the journal should be universal enough and extensible to cater for application-specific needs. The format needs to be extensible, and APIs need to be available.
Clustering & Network: Today computers seldom work in isolation. It is crucial that logging caters for that and journal files and utilities are from the ground on developed to support big multi-host installations.
Security: Journal files should be authenticated to make undetected manipulation impossible
Code:
_SERVICE=systemd-logind.service
MESSAGE=User harald logged in
MESSAGE_ID=422bc3d271414bc8bc9570f222f24a9
_EXE=/lib/systemd/systemd-logind
_COMM=systemd-logind
_CMDLINE=/lib/systemd/systemd-logind
_PID=4711
_UID=0
_GID=0
_SYSTEMD_CGROUP=/system/systemd-logind.service
_CGROUPS=cpu:/system/systemd-logind.service
PRIORITY=6
_BOOT_ID=422bc3d271414bc8bc95870f222f24a9
_MACHINE_ID=c686f3b205dd48e0b43ceb6eda479721
_HOSTNAME=waldi
LOGIN_USER=500
A netinst is a good start to do away with Systemed just disconnect... (kinda wanted to leave that statement as is (disconnected) but must say stretch/sid is much more)
"you should to0!" —Un1x I get what you're saying (like me sometimes ) eg (for me) "unstable" is always better and lately never "unstable" and I love minimal in many circumstances for example (ie eg) if I have my laptop out and want to scrimp on power: CLI, Randomplay, Links2,,, but, I like how someone explained once (not verbatim:) if you don't like the GUI* and it's a deal breaker for you don't piss on the upcoming graphic artists.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
Jsbjsb001 LQ should have just said they don't do homework...
Off topic-ish:
is always better and lately never "unstable" and I love minimal in many circumstances for example (ie eg) if I have my laptop out and want to scrimp on power: CLI, Randomplay, Links2,,, but, I like how someone explained once (not verbatim:) if you don't like the GUI* and it's a deal breaker for you don't piss on the upcoming graphic artists. 
