LinuxQuestions.org
Visit Jeremy's Blog.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 05-20-2014, 04:02 PM   #76
TobiSGD
Moderator
 
Registered: Dec 2009
Location: Germany
Distribution: Whatever fits the task best
Posts: 17,148
Blog Entries: 2

Rep: Reputation: 4886Reputation: 4886Reputation: 4886Reputation: 4886Reputation: 4886Reputation: 4886Reputation: 4886Reputation: 4886Reputation: 4886Reputation: 4886Reputation: 4886

Quote:
Originally Posted by jpollard View Post
It is a very old solution... its called "mv".

Nearly all the installation tools use it...
1. install new file as file.new
2. rename current file to file.old
3. rename file.new to file.

Or use a hard link (which is actually faster...)

1. install new file
2. remove link.
3. create link to new file.

In the VERY old days you had to use the first method with shared libraries as well. The reason you had to keep the file.old was that current processes might be using it, and if you deleted it then those processes could get a segfault.

Linux filesystems don't actually care - if a process is using a shared library the in-memory inode carries a reference count, removing the link from a directory doesn't delete the file (which only decrements the in memory link count, and removes the name from the directory). The file isn't deleted until the link count goes to zero...

This solution goes back to SunOS 2.xx days, around 1985.
Sorry, but I can't see how this is related to the part of Arkerless' post that I have quoted:
Quote:
Replacing text files that can be manipulated using very robust and mature tools we have all spent a significant portion of our life mastering and replacing them with a binary file only editable using new, immature tools developed and controlled by a central source, hmmm, where have I seen that before?
 
Old 05-20-2014, 05:52 PM   #77
Arkerless
Member
 
Registered: Mar 2006
Distribution: Give me Slack or give me death.
Posts: 81

Rep: Reputation: 60
Quote:
Originally Posted by TobiSGD View Post
Can you elaborate on that?
I'm not sure exactly what you wanted me to elaborate on. Why text files are good?
 
Old 05-20-2014, 06:38 PM   #78
JWJones
Senior Member
 
Registered: Jun 2009
Posts: 1,444

Rep: Reputation: 709Reputation: 709Reputation: 709Reputation: 709Reputation: 709Reputation: 709Reputation: 709
Quote:
Originally Posted by moisespedro View Post
Does anyone know about a distro Arch-like but with no systemd?
This one, too:

http://www.lsdlinux.org/
 
Old 05-20-2014, 07:55 PM   #79
TobiSGD
Moderator
 
Registered: Dec 2009
Location: Germany
Distribution: Whatever fits the task best
Posts: 17,148
Blog Entries: 2

Rep: Reputation: 4886Reputation: 4886Reputation: 4886Reputation: 4886Reputation: 4886Reputation: 4886Reputation: 4886Reputation: 4886Reputation: 4886Reputation: 4886Reputation: 4886
Quote:
Originally Posted by Arkerless View Post
I'm not sure exactly what you wanted me to elaborate on. Why text files are good?
No, what exactly do you mean with that statement? What do you want to edit and why does that not work anymore?
 
Old 05-21-2014, 02:05 AM   #80
Arkerless
Member
 
Registered: Mar 2006
Distribution: Give me Slack or give me death.
Posts: 81

Rep: Reputation: 60
Quote:
Originally Posted by TobiSGD View Post
No, what exactly do you mean with that statement? What do you want to edit and why does that not work anymore?
Well it's not just editing, it can also be reading, recovering, etc. Text files are mature tech, just about anything you could possibly need to do with a text file there is already a tool to do it. When you are working with a binary file, and it really doesnt matter that much if the format is open or not though of course open is at least theoretically better, but you dont get to choose from all of these tools that have already been built, no, you have to use a special tool just for this one file. If the tool you need has not already been created most of us are out of luck, open format or not.

And it's not me, I just avoid using it. But this guy for instance finds that the log files he needs become unreadable at just the moment he needs them which is just what I would expect from the design as I understand it. A single point of failure combined with a binary log sounds like a recipe for anti-slack to me. Googling the subject turns up a whole lot of similar complaints, bug reports, etc.

And yeah, it sounds very much like the windows registry to me. Both replaced a set of text files with a single binary file. The registry is definitely an improvement in some ways, but it is still probably the biggest single point of failure in the system. The vendor-specific tool has limited functionality and you just cant use standard tools on it. A fragile and non-repairable foundation does not make for a sturdy house.
 
3 members found this post helpful.
Old 05-21-2014, 06:36 AM   #81
TobiSGD
Moderator
 
Registered: Dec 2009
Location: Germany
Distribution: Whatever fits the task best
Posts: 17,148
Blog Entries: 2

Rep: Reputation: 4886Reputation: 4886Reputation: 4886Reputation: 4886Reputation: 4886Reputation: 4886Reputation: 4886Reputation: 4886Reputation: 4886Reputation: 4886Reputation: 4886
Now I get it, you mean the binary log file. Why not just saying that directly? Anyways, to address your points:

Quote:
Originally Posted by Arkerless View Post
Well it's not just editing, it can also be reading, recovering, etc. Text files are mature tech, just about anything you could possibly need to do with a text file there is already a tool to do it. When you are working with a binary file, and it really doesnt matter that much if the format is open or not though of course open is at least theoretically better, but you dont get to choose from all of these tools that have already been built, no, you have to use a special tool just for this one file. If the tool you need has not already been created most of us are out of luck, open format or not.

And it's not me, I just avoid using it. But this guy for instance finds that the log files he needs become unreadable at just the moment he needs them which is just what I would expect from the design as I understand it. A single point of failure combined with a binary log sounds like a recipe for anti-slack to me. Googling the subject turns up a whole lot of similar complaints, bug reports, etc.
At first, any init system is and will always be a single point of failure, regardless if it is systemd, sysvinit, bsdinit, ... .
If binary logs bother you (and they definitely bother me) then simply don't use them. Install a classic syslog, it will even benefit from the extended logging capabilities of journald, since journald will pass through all the messages, even those that syslog doesn't catch normally.
Quote:
And yeah, it sounds very much like the windows registry to me. Both replaced a set of text files with a single binary file. The registry is definitely an improvement in some ways, but it is still probably the biggest single point of failure in the system. The vendor-specific tool has limited functionality and you just cant use standard tools on it. A fragile and non-repairable foundation does not make for a sturdy house.
The registry is for configuration, not for logging. systemd is still configured by text files, so the comparison with the registry is simply wrong. Even if you would compare the registry to logging, you cant just add text files to the registry, which can easily be done with systemd logging.
 
Old 05-21-2014, 10:07 AM   #82
Arkerless
Member
 
Registered: Mar 2006
Distribution: Give me Slack or give me death.
Posts: 81

Rep: Reputation: 60
Quote:
Originally Posted by TobiSGD View Post
At first, any init system is and will always be a single point of failure, regardless if it is systemd, sysvinit, bsdinit, ... .
This is true in a sense but you are dodging the point. Normal init systems are not single points of failure for *logging* because a normal init system does not try to be a unified logging system as well.

Quote:
If binary logs bother you (and they definitely bother me) then simply don't use them. Install a classic syslog, it will even benefit from the extended logging capabilities of journald, since journald will pass through all the messages, even those that syslog doesn't catch normally.
If I understand that system correctly, you still have journald doing the same thing but exporting the datastream at the end, this does not sound more robust.

Quote:
The registry is for configuration, not for logging.
Obviously.

Quote:
systemd is still configured by text files, so the comparison with the registry is simply wrong.
No it's not. They are both unified binaries that replaced a collection of text files. The comparison is apt and specific.


Quote:
Even if you would compare the registry to logging, you cant just add text files to the registry, which can easily be done with systemd logging.
Actually you can. You can export the registry to a text file, and you can import entries from text files. Very useful capabilities but they still fail to ameliorate the basic fragility of the structure.
 
2 members found this post helpful.
Old 05-21-2014, 10:24 AM   #83
ReaperX7
LQ Guru
 
Registered: Jul 2011
Location: California
Distribution: Slackware64-15.0 Multilib
Posts: 6,564
Blog Entries: 15

Rep: Reputation: 2117Reputation: 2117Reputation: 2117Reputation: 2117Reputation: 2117Reputation: 2117Reputation: 2117Reputation: 2117Reputation: 2117Reputation: 2117Reputation: 2117
If you want an alternative to systemd, our work in the LFS section on Runit is published and available. Translate it for Slackware (shouldn't be too hard) and you have a new init system.

It's standard UNIX scripting compliant, small, completely modular, fast, and very customizable. This isn't the only alternative so either get off your duffs and do some work to import Slackware a new init system that isn't systemd and can use either classic udev or eudev, or don't complain.

We worked hard to bring this forward on LFS. Do the work for Slackware, and you'll have your solution if you so choose.
 
2 members found this post helpful.
Old 05-21-2014, 10:46 AM   #84
Nh3xus
Member
 
Registered: Jan 2013
Location: France
Distribution: Slackware 14.1 32 bits
Posts: 211

Rep: Reputation: 57
Making <foo>init like Runit work on Slackware is doable. Sure.

Making the DE's provided by Pat compatible with it is another task on its own.
 
Old 05-21-2014, 01:40 PM   #85
ReaperX7
LQ Guru
 
Registered: Jul 2011
Location: California
Distribution: Slackware64-15.0 Multilib
Posts: 6,564
Blog Entries: 15

Rep: Reputation: 2117Reputation: 2117Reputation: 2117Reputation: 2117Reputation: 2117Reputation: 2117Reputation: 2117Reputation: 2117Reputation: 2117Reputation: 2117Reputation: 2117
Actually the DEs aren't an issue. You're referring to things like XDM, KDM, and GDM by chance?

All you have to with those is draft a run file to start the service, link it to the the runsv assigned desktop runlevel directory and make script executable.

Otherwise startx works all the same.
 
Old 05-21-2014, 03:01 PM   #86
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,908

Rep: Reputation: 1513Reputation: 1513Reputation: 1513Reputation: 1513Reputation: 1513Reputation: 1513Reputation: 1513Reputation: 1513Reputation: 1513Reputation: 1513Reputation: 1513
Quote:
Originally Posted by ReaperX7 View Post
Actually the DEs aren't an issue. You're referring to things like XDM, KDM, and GDM by chance?

All you have to with those is draft a run file to start the service, link it to the the runsv assigned desktop runlevel directory and make script executable.

Otherwise startx works all the same.
Well... gdm has dependencies on systemd - at least the current version does. gdm depends on logind which depends on systemd. gdm also depends on systemd for performing the cleanup that gdm should have been doing.

https://blogs.gnome.org/ovitters/201...temd-thoughts/
 
Old 05-21-2014, 06:04 PM   #87
Arkerless
Member
 
Registered: Mar 2006
Distribution: Give me Slack or give me death.
Posts: 81

Rep: Reputation: 60
Quote:
Originally Posted by jpollard View Post
Well... gdm has dependencies on systemd - at least the current version does. gdm depends on logind which depends on systemd. gdm also depends on systemd for performing the cleanup that gdm should have been doing.

https://blogs.gnome.org/ovitters/201...temd-thoughts/
GDM does not depend on systemd. It only depends on having something in place which behaves exactly like systemd.

Seems a hair to split but it's not meaningless. IF GDM were important enough someone would just figure out precisely what functionality it relies on and implement that functionality in a sane standalone. With all the Gnome developers using systemd their requirements could easily change without notice or knowledge so someone would have to be pretty motivated to take that on and keep it up to date. Seems easier to me to just continue living without anything GNOME-related but YMMV.
 
Old 05-21-2014, 09:28 PM   #88
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,908

Rep: Reputation: 1513Reputation: 1513Reputation: 1513Reputation: 1513Reputation: 1513Reputation: 1513Reputation: 1513Reputation: 1513Reputation: 1513Reputation: 1513Reputation: 1513
Quote:
Originally Posted by Arkerless View Post
GDM does not depend on systemd. It only depends on having something in place which behaves exactly like systemd.
I believe that is the definition of "dependency".
Quote:
Seems a hair to split but it's not meaningless. IF GDM were important enough someone would just figure out precisely what functionality it relies on and implement that functionality in a sane standalone. With all the Gnome developers using systemd their requirements could easily change without notice or knowledge so someone would have to be pretty motivated to take that on and keep it up to date. Seems easier to me to just continue living without anything GNOME-related but YMMV.
That is why it depends on systemd. The lack of documentation of what it "depends on".

Personally, I blew off gnome starting with gnome 3.

The PROBLEM that remains is that the gnome developers are forcing other desktops to adopt the dependencies too.
 
1 members found this post helpful.
Old 05-21-2014, 10:02 PM   #89
hitest
Guru
 
Registered: Mar 2004
Location: Canada
Distribution: Slackware (desktops), Void (thinkpad)
Posts: 7,432

Rep: Reputation: 3848Reputation: 3848Reputation: 3848Reputation: 3848Reputation: 3848Reputation: 3848Reputation: 3848Reputation: 3848Reputation: 3848Reputation: 3848Reputation: 3848
Quote:
Originally Posted by jpollard View Post
Personally, I blew off gnome starting with gnome 3.
I stopped using Gnome in Slackware when PV dropped it from -current.
 
Old 05-21-2014, 10:11 PM   #90
ReaperX7
LQ Guru
 
Registered: Jul 2011
Location: California
Distribution: Slackware64-15.0 Multilib
Posts: 6,564
Blog Entries: 15

Rep: Reputation: 2117Reputation: 2117Reputation: 2117Reputation: 2117Reputation: 2117Reputation: 2117Reputation: 2117Reputation: 2117Reputation: 2117Reputation: 2117Reputation: 2117
Not only that, but KDM and XDM are included by default with Slackware, so truthfully, why bother with a DM that uses software that's unwanted or only a duplication? KDM can be used to launch Xfce, IceWM, Mate, KDE, OpenBox, FluxBox, etc. That makes GDM... USELESS!

Also, GDM's older version, as promoted on SlackBuilds.org, does not require systemd.

Your argument on that holds about as much water as a pot with no bottom.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
LXer: Systemd Is The Future Of Debian LXer Syndicated Linux News 1 02-11-2014 04:09 PM
It seems that in future Linux kernel itself will force the use of systemd blancamolinos Slackware 25 11-07-2013 03:38 PM
[SOLVED] systemd and Slackware's future kikinovak Slackware 95 07-14-2012 12:40 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 03:30 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration