LinuxQuestions.org
Download your favorite Linux distribution at LQ ISO.
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 06-21-2014, 07:52 PM   #256
astrogeek
Moderator
 
Registered: Oct 2008
Distribution: Slackware [64]-X.{0|1|2|37|-current} ::12<=X<=15, FreeBSD_12{.0|.1}
Posts: 6,301
Blog Entries: 24

Rep: Reputation: 4256Reputation: 4256Reputation: 4256Reputation: 4256Reputation: 4256Reputation: 4256Reputation: 4256Reputation: 4256Reputation: 4256Reputation: 4256Reputation: 4256

Quote:
Originally Posted by skarnet View Post
Define "normal".
A change in state in the system is normal to me. Is it abnormal that you install new binaries ? Remove old ones ? chown and chmod ?
Assuming that we are still in the context of an init system, a game of musical binaries and permissions is not really "normal".

Quote:
Originally Posted by skarnet View Post
Poor users who will get an obnoxious error message for no reason at all when they try to run something at the same time the package manager is updating it. Please, this is the Microsoft way, not the Unix way.
Throw more dust into the air, I think I can still see the point that was being made... (and it is not I who is posting from a Microsoft system!).

Who is talking about sending obnoxious messages to a user anyway? That is quite a leap from the context under discussion.

Quote:
Originally Posted by skarnet View Post
It's not error trapping. It's error checking, and it's a much better programming method than gratuitously introducing race conditions and useless checks. System calls return an error code for a reason, and it's a "normal" case, not an "exceptional" case, whatever that means.
With whatever respect due for your work on the S6 system, I suggest that you rethink use of this as a programming axiom.

It is NOT gratuitous introduction of a race condition, and it is NOT a useless test! It IS a decision point, a control flow inflection point, a boolean test, a conditional statement to determine the course of one or more subsequent operations. Once the decision test has been made there is no race. If subsequent operations fail for any reason, including change of permissions or files, it is an error within the context of THAT decision.

It is the difference between control and simple reaction.

Quote:
Originally Posted by skarnet View Post
I will probably not be able to convince you, so this will be my last post on the subject.
No need to run and hide. And please, chill a little!

There was nothing confrontational intended in my post, just a perspective that I thought important to mention.

Quote:
Originally Posted by skarnet View Post
Upstream is reachable. Talk to me.

People haven't heard of s6 for the simple reason that I'm a busy man and my free time is better spent designing and coding software than advertising it. Time spent bullying distributions into adopting a piece of software is time not spent making said software better. But I'm realizing more and more that distributions are obviously more sensitive to public relations than to technical merit, so I'll definitely do some more PR in the future.
I was trying to talk to you... but I definitely feel alienated at the moment.

Technical merit is in the eye of the beholder, I suppose. One big complaint about systemd is that upstream turns a deaf ear, that is the Poettering method! We don't need another one like it!
 
1 members found this post helpful.
Old 06-21-2014, 09:36 PM   #257
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
Skarnet and Pape both have been reachable which is a vast turn for the better. At least they have been willing to discuss things, and regardless of point of view over methodology, discussion right now is the most important factor here.
 
Old 06-21-2014, 09:38 PM   #258
genss
Member
 
Registered: Nov 2013
Posts: 744

Rep: Reputation: Disabled
there is no need to check if a program is there, executable, if you have permissions etc.
the kernel does all that

the filesystem is for permissions and ID's, not the init system
at least if you ask me

Last edited by genss; 06-21-2014 at 09:52 PM.
 
2 members found this post helpful.
Old 06-21-2014, 10:05 PM   #259
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
I'm glad we have LFS as a distribution to work with outside of Slackware because it allows clean room implementations we can port back to Slackware. I'm excited and nervous to build up another init from scratch again.

Maybe soon we can translate our Runit work to Slackware.
 
3 members found this post helpful.
Old 06-21-2014, 10:10 PM   #260
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 skarnet View Post
Just a technical detail here. I don't know what Slackware and LFS do exactly, but there is a very common mistake that's being made often, and even in the glibc internals: checking that a command is present and executable, then executing it. It is wrong because:
- there is a race condition. The state of the command might change between the state and the actual execution.
- it is redundant. The kernel will refuse to execute a program if it's absent (duh) or the user doesn't have permission to.
The right way to run a command if present and executable is to actually execve() it. If the execve() fails, errno will tell why, and the program can react accordingly.
Not a race condition.

Think about WHEN the script is run during boot - no logins are active, nor can they be. Thus nothing is there to interfere.

The purpose of checking for the existence and modes is not for the purpose of executing it - it is for the purpose of diagnostics. If something is wrong, it gets reported with decent errors.

Depending on an execv doesn't identify WHICH error it is. That still requires checking.

Depending on the execv doesn't make any difference.

Now checking AFTER an execve fails is reasonable, but not due to race conditions (the execve is going to be used anyway).

Checking after the fact allows the procedure to be a bit more efficient though when there are no errors (if there are no errors, the checks are not done).

Last edited by jpollard; 06-21-2014 at 10:12 PM.
 
1 members found this post helpful.
Old 06-21-2014, 10:32 PM   #261
genss
Member
 
Registered: Nov 2013
Posts: 744

Rep: Reputation: Disabled
"Depending on an execv doesn't identify WHICH error it is. That still requires checking"

yes it does...
even errors that can't be found by looking at a file, like EIO
if the error is a generic one, like EACCES, details can be checked after the fact
 
Old 06-21-2014, 10:32 PM   #262
astrogeek
Moderator
 
Registered: Oct 2008
Distribution: Slackware [64]-X.{0|1|2|37|-current} ::12<=X<=15, FreeBSD_12{.0|.1}
Posts: 6,301
Blog Entries: 24

Rep: Reputation: 4256Reputation: 4256Reputation: 4256Reputation: 4256Reputation: 4256Reputation: 4256Reputation: 4256Reputation: 4256Reputation: 4256Reputation: 4256Reputation: 4256
Quote:
Originally Posted by genss View Post
there is no need to check if a program is there, executable, if you have permissions etc.
the kernel does all that

the filesystem is for permissions and ID's, not the init system
at least if you ask me
That is true, as long as the entirety of the execution context is limited exactly to executing the given target. Obviously, if it is either not present, or not executable, it will fail to execute.

But it is incorrect to say that it is a mistake or error to do it otherwise, as with permission and existence tests - the coder may have had other "needs" in mind.

Within the context of an init system, and particularly some specific implementations (I have Slackware in mind), it can lead to logical and even runtime inconsistencies.

For example, in the Slackware init method, and others, setting the executable permission of a script is the very method of configuring what starts at boot time.

So, if we have set a script to NOT be executable, the init scripts test this and SILENTLY ignore those at boot.

Without the test, it would attempt to run the script and the kernel would generate a "Not found" or "Permission denied" message, which might go to /dev/null, or to the dmesg buffer or an error log (maybe other places). But within this context, the script has been configured not to run so the message is redundant at best. When configured NOT to run, there should be no attempt to run it!

My point as before is this: There are many contexts within which scripts can be executed, the one under discussion is init context generally. And within the init context, specifically in the example of Slackware, there is a difference, however trivial it may be considered, in the result.

Also, "absolute efficiency of execution" is not the be-all and end-all criteria. As jpollard noted, generation of meaningful diagnostic messages may be a good reason for testing before execution, and there are others - different constraints, different objectives, different contexts. One size does not fit all - that is the Unix way.

The point is, neither way is a "mistake", the "best" or most appropriate depends on the complete execution context.

Last edited by astrogeek; 06-22-2014 at 01:37 AM. Reason: Forgot to include a few thoughts, typos, etc...
 
1 members found this post helpful.
Old 06-21-2014, 10:58 PM   #263
genss
Member
 
Registered: Nov 2013
Posts: 744

Rep: Reputation: Disabled
Quote:
Originally Posted by astrogeek View Post
For example, in the Slackware init method, and others, setting the executable permission of a script is the very method of configuring what starts at boot time.

So, if we have set a script to NOT be executable, the init scripts test this and SILENTLY ignore those at boot.
"
EACCES

Execute permission is denied for the file or a script or ELF interpreter.
"

it does not go anywhere else

EACCES can actually mean 3 other things

Search permission is denied on a component of the path prefix of filename or the name of a script interpreter. (See also path_resolution(7).)

The file or a script interpreter is not a regular file.

The file system is mounted noexec.


first one is our/admins fault (i think)
second is, well, self explanatory and should be checked
third is... it's easy to check but an init system should know that already (unless the "mount" binary is used to mount)

so only conclusion left is it's either not executable or not a valid executable
hmmm
validating that... possible but...
tomorow as i turned off my computer and this craptop can't handle 3 pages open
 
2 members found this post helpful.
Old 06-22-2014, 07:48 AM   #264
genss
Member
 
Registered: Nov 2013
Posts: 744

Rep: Reputation: Disabled
Quote:
Originally Posted by genss View Post
so only conclusion left is it's either not executable or not a valid executable
correction
execve returns ENOEXEC if the file is not a valid executable, and EACCES if it the executable bit is not set

also checked if it's how bash does things, and yes it does try execve then stat() when that fails
so it's already default on all stock slackware systems
 
1 members found this post helpful.
Old 06-23-2014, 02:26 AM   #265
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
Yes and that scripting style used by Slackware does allow for execution of instance rather than just execution by scripting. Using "if" commented instance scripts allows a far reaching level of flexibility for daemon loading and execution, but it's useful only in the one shot instance of execution phase of stage 1 system core daemon loading. At stage 2 you don't need it and can manage daemons by allowing for symlink existences in the /service execution directory.

Right now the work we've done with Runit exposes this level of flexibility, and I'm hopeful we can utilize this same level of flexibility in s6. The best thing we can do right now is assist in getting projects off the ground, do research, and get alternatives available to the general public.
 
1 members found this post helpful.
Old 09-22-2014, 05:02 PM   #266
metaschima
Senior Member
 
Registered: Dec 2013
Distribution: Slackware
Posts: 1,982

Rep: Reputation: 492Reputation: 492Reputation: 492Reputation: 492Reputation: 492
Quote:
Originally Posted by ReaperX7 View Post
I trust you've watched this video:

http://www.youtube.com/watch?v=_2aa34Uzr3c

While I don't see it consuming glibc, gcc, or some of the various libraries and some utilities like gawk and others (how the hell could systemd even have it's own libc and compiler is actually intangible), systemd, however, is aiming to be the Core OS of the system or more or less a shell-less sealed off hypervisor running a Linux kernel to which all programs and applications run in their own userspace using cgroups as execution containers with limited permissions across the system using virtual filesystems per application installation.

We even have an OS distribution based on that concept called Core OS.

https://coreos.com/

And another called Android OS.

While for the moment all aspects of systemd are able to be optional, what would happen if that right to opting out of a service vanished? We used to be able to extract udev, now we can't hardly do that because of all the mess of software it creates, and if we want separated udev we have to use eudev. We can't opt out of journald, so what makes you think eventually we won't be able to opt out of networkd, or logind, or whatever else? And yes, Tobi it is a conglomerate project, but the goal of that project is not the goal of the sum of it's parts.
This is one of the most informative posts on systemd that I have read. This sums up systemd, what it is, what it stands for, and what is planned for the future.

In one phrase it is the Androidization of Linux, a power grab by Pottering and the corporations that inserted him in his current place for this sole purpose. I'm just taken aback by how quickly systemd was adopted without question and without a fight, not even from my personal hero Linus Torvalds. Well, he did put up some fight, but not enough.

For a while I thought that it would be possible to use other init systems, but udev is under systemd now, and eudev would be the only alternative. With only 3 distros left that haven't adopted systemd, the outlook is grim. Resistance is futile ...

I won't give up the fight tho, or I'll run to BSD if I have to. This whole thing sticks to high heaven. Everything about it is wrong and suspicious. Nothing anyone has said that might be a positive for systemd would make me want to touch it with a barge pole.

I'm still hoping that it all goes horribly wrong for systemd and they toss it out of the kernel like the drunken scoundrel that it is. I'm hoping even more that Linux survives as something that resembles its former self and not Android. If not, RIP Linux, hello BSD.
 
6 members found this post helpful.
Old 09-22-2014, 05:28 PM   #267
Didier Spaier
LQ Addict
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slint64-15.0
Posts: 11,211

Rep: Reputation: Disabled
Well, this pretty much sums up to: you can offer or use the distribution you want, provided it assembles systemd's building blocks, linked with systemd's glue.
http://www.phoronix.com/scan.php?pag...tem&px=MTczNDk
http://0pointer.net/blog/revisiting-...x-systems.html

Last edited by Didier Spaier; 09-22-2014 at 05:37 PM.
 
2 members found this post helpful.
Old 09-22-2014, 05:50 PM   #268
Nh3xus
Member
 
Registered: Jan 2013
Location: France
Distribution: Slackware 14.1 32 bits
Posts: 211

Rep: Reputation: 57
Quote:
In one phrase it is the Androidization of Linux, a power grab by Pottering and the corporations that inserted him in his current place for this sole purpose.
You are close to the conclusion of many people who remains silent on that very subject.

I don't know if the link below will be a repost, but I highly suggest that you read this article (It's long, but worth it, IMHO) :

http://igurublog.wordpress.com/2014/...ainst-systemd/

It might help you to understand how the Linux kernel and its ecosystem was never really driven by people like you and me,but rather by the folks from RedHat.

Hence why PulseAudio, and systemd are a thing.

---

Quote:
Well, [Linus] did put up some fight, but not enough.
You're a bit confused on that one.

Linus has nothing against systemd itself. He just can't stand Lennart's behavior.
 
3 members found this post helpful.
Old 09-22-2014, 06:41 PM   #269
metaschima
Senior Member
 
Registered: Dec 2013
Distribution: Slackware
Posts: 1,982

Rep: Reputation: 492Reputation: 492Reputation: 492Reputation: 492Reputation: 492
Quote:
Originally Posted by Nh3xus View Post
You're a bit confused on that one.

Linus has nothing against systemd itself. He just can't stand Lennart's behavior.
Yeah, I read his recent comments and he is not against systemd, but he was against Pottering and Sievers and their arrogance and refusal to fix bugs. Either way, I am disappointed.

That is a great article you linked to BTW. The links for there are good too.

This is the article with Linus' POV:
https://www.linuxquestions.org/quest...md-4175518759/
http://www.itwire.com/business-it-ne...ons-on-systemd

I think Linus may be underestimating the situation.

Last edited by metaschima; 09-22-2014 at 06:48 PM.
 
1 members found this post helpful.
Old 09-22-2014, 08:39 PM   #270
perbh
Member
 
Registered: May 2008
Location: Republic of Texas
Posts: 393

Rep: Reputation: 81
In one of LP's musings/ramblings (and sorry, I can't remember the url nor did I bookmark it), he said (quote and unquote):
Code:
We are trying to make an OS here.
So there you are guys - straight from the horse's mouth!!
 
  


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: Shuttleworth says Ubuntu will switch to systemd LXer Syndicated Linux News 0 02-16-2014 09:33 AM
Debian To Replace SysVinit, Switch To Systemd Or Upstart jeremy Linux - News 0 10-28-2013 03:03 PM
LXer: Michael Geist’s website went dark to protest U.S. restrictions on Internet LXer Syndicated Linux News 0 01-20-2012 08:20 AM
LXer: Canonical Tells Mac OS X, Windows Users: "Switch to Ubuntu" LXer Syndicated Linux News 0 07-31-2009 07:41 AM

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

All times are GMT -5. The time now is 02:35 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