On 19/04/2015 09:19, Didier Kryn wrote:
Hi Laurent. I suspect, from a recent experience that /linuxrc is tried
even before /init.
Yes, but AFAICT, it's only when an initrd is used. (The relevant
piece of code is init/do_mounts_initrd.c)
And initramfs is not considered as an initrd, so
On 02/05/2015 09:43, marc...@welz.org.za wrote:
0700 for root-only binaries would hide them from your shell's
autocompletion.
Which would be lots of stat() system calls.
If a shell doesn't make them, then it doesn't verify that a file is
executable either. (I just checked with zsh: it
On 02/05/2015 10:52, marc...@welz.org.za wrote:
... confusing - it is unclear if he is arguing that departures from the
standard should be entertained or not.
I am arguing that FHS includes good things and bad things, and that
good things should be followed and bad things should not. In other
On 03/05/2015 06:44, Steve Litt wrote:
What is the motivation for a person to join the mailing list
of an anti-systemd, pro-choice distro, and start spouting pro-systemd
stuff? What kind of a use of time is that? Why do several people keep
doing this? What could they possibly gain?
Be fair.
On 30/04/2015 22:35, Joerg Reisenweber wrote:
exactly this PATH issue is what I expect and appreciate here: I do NOT expect
command autocompletion of normal user to get confused by command names that
are not supposed to even be in user's PATH
0700 for root-only binaries would hide them from
On 03/05/2015 10:15, marc...@welz.org.za wrote:
So you have just argued that to hide things from autocompletion,
one should make things 0700. We have also established that
for this scheme to work the shell needs to do a stat() *for* *each*
*candidate* executable. But the my /bin/bash does not do
On 05/05/2015 11:22, Didier Kryn wrote:
I'm not sure what happens if init crashes after other processes have
been started, wether the kernel panics or other processes continue
without init - not a very good situation.
The Linux kernel panics when init dies. It's the dreaded attempted
to kill
On 19/04/2015 01:06, Isaac Dunham wrote:
I'm not sure exactly what the priority is, but the kernel searches
/sbin/init, /init, and /linuxrc at least.
From the kernel source (init/main.c):
if (!try_to_run_init_process(/sbin/init) ||
!try_to_run_init_process(/etc/init) ||
On 09/04/2015 10:37, Jaromil wrote:
a -Dev list is there already, just not public and invite only.
That's really a shame, because I would love to have access to that list -
even read-only. Isn't it possible to open subscriptions while keeping
posts moderated ? (posts from devs would be
For what is worth - and at risk of adding fuel to the fire, but
I am just voicing my impressions and you guys will do what you want
with it:
I have subscribed to this list five days ago, hoping to see technical
discussions about how to design a distribution without systemd. I am
the author of
On 03/06/2015 19:50, Vince Mulhollon wrote:
Just be careful, the assumption is the user is the installer is the
buyer, and frankly most of the machines I've installed in the last 20
years, that has not been the case.
My point exactly, and my apology for entertaining the confusion with a
poor
On 03/06/2015 18:41, hellekin wrote:
*** I must I was almost agreeing until moralistic crap. This is
your opinion, and in my own, an unfounded one. What we're talking
about here is about technology, not moralistic anything.
The technology we're building is one that empowers the user, and it
On 18/06/2015 16:57, Hendrik Boom wrote:
I assume that aptitude has enough algorithmic capacity to do this, but
when things get complicated there may not be enough computational power
to carry out this analysis in available time and space.
My experience is that we have way more
On 15/06/2015 05:57, Isaac Dunham wrote:
(3) Server uses not-a-supervisor:
# write a small C wrapper that forks, execs server in child,
# accepts s6-style notification and exits in parent
fake-sv -d 1 server
client
The main reason why I advocate such a simple notification style is
that this
On 14/06/2015 11:58, KatolaZ wrote:
Sorry for asking a silly question, but what's the problem in having
cups running all the time? And better, if you start/stop cups when
you need it, why should cups notify systemd (or any other init) that
it is ready to do things? Why should init be informed of
[ Didier ]
What happens then? Does the webprinting service crash? Or does it
hang until Cups is ready? Is it able to detect that it is hanging?
The last would probably be the most sensible way to handle the
dependency :-) A professional webprinting service should be able to
do that. And this is
On 14/06/2015 19:17, KatolaZ wrote:
I am sorry but you simply don't get rid of race conditions by
signalling that the daemon is ready. If the daemon dies or hangs for
whatever reason, you will still have a problem, since you thought the
service was up and running while it is not any more
On 14/06/2015 23:45, Jonathan Wilkes wrote:
Is there a way to tell which packages use a particular function like sd_notify
et al?
Authors *should* document readiness notification capabilities of
their daemons. But then again, reality may be different.
sd_notify will be easy to spot: there
On 15/06/2015 00:36, Isaac Dunham wrote:
I think that a program that must run in the background is broken.
Yet *prohibiting* auto-backgrounding imposes an even more heavy toll
on scripts where process 1 requires process 2 to be running and
ready: you *must* run a supervisor, or else run a
On 12/06/2015 22:21, marc...@welz.org.za wrote:
The trick is for the daemon process to only background when
it is ready to service requests (ie its parent process exits
when the child is ready).
You already mentioned it in a reply to me, indeed. I intentionally
did not follow up, and here is
On 12/06/2015 20:09, Tomasz Torcz wrote:
Hey, it's almost exactly what sd_notify() does. Instead of one character,
it writes READY=1 to a socket. Nothing more, no D-Bus, no additional
libraries needed. In basic form it few lines of C code.
Of course
On 12/06/2015 19:46, Steve Litt wrote:
I agree with every single thing you write above, but have one question
for you: What does Devuan do when daemons like cupsd and sshd make
sd_notify calls, and these don't condition the call on sd_notify being
available, and sd_notify cannot be conditionally
On 13/06/2015 11:37, KatolaZ wrote:
AFAIK all this fuss with
daemon-readiness began with the first attempts to have parallel boot
sequences, which is something that is still *useless* in 95% of the
use cases: servers don't get restarted evey other minute and normal
users who don't use suspend
On 12/06/2015 19:01, Steve Litt wrote:
The one thing I *do* know is that we need to provide a sd_notify
interface, even if it does nothing at all and drops passed information
on the floor.
Please don't do this.
The more you bend to the systemd interfaces, the more it gets a foot
in the door.
On 12/06/2015 19:46, Steve Litt wrote:
I agree with every single thing you write above, but have one question
for you: What does Devuan do when daemons like cupsd and sshd make
sd_notify calls, and these don't condition the call on sd_notify being
available, and sd_notify cannot be conditionally
On 31/05/2015 18:35, Didier Kryn wrote:
AFAIU, this thread has turned to be about interfacing whatever app to
a scripting language. I consider this a very usefull feature for all
but basic applications. In particular, I consider that interfacing
init - The init program which is pid 1 - with a
On 27/05/2015 12:12, Hendrik Boom wrote:
I'm in the process of writing (yet) a(nother) editor and output formatter,
and on reading this, I started to wonder -- just how could one separate
a command-line version from the UI? I can see that the output
formatter can be so separated (and very
On 27/05/2015 17:51, Irrwahn wrote:
No intention to lessen your main point, but that last observation
does not come as a surprise. Development systems inherently have
an installation overhead compared to simple runtime environments,
it's always been that way.
Oh, definitely. My router
On 27/05/2015 17:46, Anto wrote:
And I have been using OpenWRT for years
This is exactly akin to using a distribution, even if you
recompile it from source: it hides the real costs such as
software dependencies, because it precisely does all the hard
work for you.
OpenWRT is a great project,
On 28/05/2015 11:43, Didier Kryn wrote:
porting to Musl was not finished yet - still problems
with dynamic linking he says. I prefer Musl to uClibc for several
reasons
I'm using musl too. You can use the Aboriginal toolchains, even if
they're uClibc-based, to compile musl, and then link stuff
On 01/07/2015 20:21, Aldemir Akpinar wrote:
http://linux.slashdot.org/story/15/06/30/0058243/interviews-linus-torvalds-answers-your-question?utm_source=feedly1.0mainlinkanonutm_medium=feed
Yes, it can happen to the best of us: even Linus doesn't know there
are alternatives to handle services
On 16/08/2015 06:53, Steve Litt wrote:
The toughest part is how to store the passwords in a way that isn't a
security problem.
Unfortunately, /etc/wpa_supplicant.conf doesn't have an include feature
(which is strange, because hostapd supports a wpa_psk_file option).
So you have to store the
On 19/08/2015 15:29, Edward Bartolo wrote:
This is the completed C backend with all functions tested to work. Any
suggestions as to modifications are welcome.
OK, someone has to be the bad guy. Let it be me.
First, please note that what I'm saying is not meant to discourage you.
I
On 19/08/2015 19:14, Edward Bartolo wrote:
I am not assuming anything and understand the risks of buffer
overflows. The first step I am taking is to make the code function.
The second step is further debug it until it behaves properly and the
third step is to correct any potential security
Spam detection software, running on the system tupac2,
has identified this incoming email as possible spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content
On 22/08/2015 16:58, Laurent Bercot wrote:
Spam detection software, running on the system tupac2,
has identified this incoming email as possible spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
On 29/07/2015 17:07, tilt! wrote:
I am certain there is a way of solving this automounting
problem (if I may call it that) cleanly, without the use
of either of them. :-)
There is a way to solve (almost) every suid issue cleanly, but
it requires running a small additional daemon for every
On 29/07/2015 16:02, kpb wrote:
That is a really interesting way of looing at things, thanks for the mental
prompt.
It's an elementary design principle: separate the engine from the interface.
I very much hope people who design GUIs keep it in mind.
How would you deal with providing
On 29/07/2015 19:44, Jaromil wrote:
IMHO the bigger barrier to this is not having
a string parsing code (or basic grammar)
that is security oriented, I mean hardened
to run as root and handle corner cases
The tool I linked does no parsing at all. The user gives the end
of the command line she
On 31/07/2015 11:47, Rainer Weikusat wrote:
But that's not a good reason for it being installed and running: A
daemon process should only exist because it provides some important
functionality with a real benefit for users of the system which cannot
(reasonably) be provided in some other way
On 07/08/2015 14:58, Rainer Weikusat wrote:
There's obviously a TOCTOU race here because A is ready now doesn't
mean A is still ready at any later time.
Of course. That's why you need a supervisor to receive death notifications
and publish them to whomever subscribes.
If there's something
I'm not sure how systemd does it, but in my vision, there should be
two different states for the service: the *wanted* state, and the
*current* state.
The wanted state is what is set by the administrator when she runs
a command such as rc thisrunlevel. The command should set all the
services
On 07/08/2015 00:09, Rainer Weikusat wrote:
Since this is maybe/ likely a bit harsh
Not harsh, just unwilling to accept that I'm actually your ally and
not your enemy.
I'm not trying to replace Unix, because Unix is not broken - at least,
not as far as system startup is concerned. There
On 06/08/2015 20:18, Rainer Weikusat wrote:
UNIX(*) and therefore, Linux, provides two system calls named fork and
exec which can be used to create a new process while inheriting certain
parts of the existing environment and to execute a new program in an
existing process, keeping most of the
On 15/08/2015 22:19, Stephanie Daugherty wrote:
They did, but out of all this design by committee, hidden between all
the political bullshit and bikeshedding, they also created the most
brilliant, most comprehensive set of standards for quality control,
package uniformity, license auditing, and
On 06/08/2015 16:00, Rainer Weikusat wrote:
That's all nice and dandy but it all boils down to 'the code executed by
the init script was deficient in some way'.
Yes, just like root exploits boil down to the code executed by the
suid program was deficient in some way.
My point is that you
On 23/07/2015 22:41, Peter Maloney wrote:
What's wrong with these, which Thunderbird handles just fine?
Ah, indeed it does, when the list address is in the To:
It does not when the list address is in the Cc:
So the solution is to make sure to always send To: the list. :)
Thanks for the
On 22/07/2015 22:20, T.J. Duchene wrote:
That said, the reality of the situation is quite different than it is
in theory. As the old saying goes in the American Midwest: The
proof is in the pudding. Until someone provides a systemd
alternative that works better than systemd, yet provides
On 22/07/2015 10:00, Oz Tiram wrote:
One argument I hear often about systemd is that it more adapted to current
hardware needs, [e.g. here][1]
Computers changed so much that they often doesn’t even look like
computers. And their operating systems are very busy : GPS, wireless
networks,
On 23/07/2015 10:36, T.J. Duchene wrote:
I do not understand this animosity toward D-BUS. Could you please
explain why it is such a point of contention? It is a only a
protocol, with many different implementations. It is comfortably
very generic and used on other UNIXs.
Simple: it has a
On 22/07/2015 16:24, Isaac Dunham wrote:
In general, I'd agree with you, but there are some situations where it's
possible to argue for hotplugger/service manager integration:
if you hotplug a scanner or printer, there's reason to think that the
corresponding daemon (sane/cups/lprng/lpr)
On 15/07/2015 06:30, Steve Litt wrote:
Apparently somebody has arbitrarily declared July to be systemd month.
I wonder what *we* can do to celebrate systemd month.
I'm going to happily ignore it and do my own thing, and unless you
want to give more power to systemd by acknowledging that the
On 18/07/2015 09:52, Didier Kryn wrote:
There are two categories of launchers: supervisors and
non-supervisors. Similarly, I think two scripts only are needed for
every daemon: one for launching without supervision, alla sysv-init
and one for launching from a supervisor. Just two, not one per
On 18/07/2015 12:42, Fred DC wrote:
I am not saying that runit is better as s6 - all I want to point out is
that debian runit, until recently, intergrates fairly well with sysv-rc.
The reason why it does is that it compromises on supervision. I don't
know how debian runit is packaged, but I'm
On 19/07/2015 20:07, Didier Kryn wrote:
You say crapware; I've also read bloatware. Everyone complains
about GNU, including me, but I don't forget everyone is or should be
immensely gratefull for the wonderful software they provide to the
world, free and open. Think of gcc, glibc, emacs,
On 09/07/2015 19:36, Steve Litt wrote:
I know what you mean. In the past 9 months I've seen a huge uptick
in ambuification in emails, to the point where many times, you don't
know who said what, and it looks like the person is arguing with
himself, with temporal dislocations thrown in as people
On 28/08/2015 17:00, Michael Bütow wrote:
https://tlhp.cf/lennart-poettering-su/
The thing is, he's not entirely wrong: su *is*, really, a
broken concept.
What he conveniently forgets, of course, is that having a
real root session with a separated environment, which is
what the new feature
On 29/08/2015 14:43, Rainer Weikusat wrote:
'su' is not a concept, it's a program.
grumble Okay, let's clarify.
A program is the implementation of an idea. The idea is often
unwritten or unspoken, or forgotten, and people will only refer
to the implementation; but good design always starts
On 29/08/2015 20:10, KatolaZ wrote:
Well, I wouldn't say that su is a broken concept on its own. In
assessing the quality of ideas and software one should always take
into account the motivations which led to a certain solution.
su appeared in ATT Unix Version 1:
Yes. However, Unix has
On 30/08/2015 04:29, Isaac Dunham wrote:
Correction for this:
Alpine Linux is OpenRC based.
Ah, sorry, I mixed them: it's Void Linux that's runit-based.
--
Laurent
___
Dng mailing list
Dng@lists.dyne.org
On 30/08/2015 20:54, Steve Litt wrote:
http://www.ibuildthecloud.com/blog/2014/12/03/is-docker-fundamentally-flawed
Very nice!
Note that the article is about the containers' *host*.
When people talk about making systemd work with containers,
they're usually meaning running systemd *in* the
On 29/08/2015 23:11, Steve Litt wrote:
in my LUG, the most pro-systemd guys are the mega-metal admins
administering hundreds of boxes with hundreds of Docker containers.
These guys are telling me systemd is necessary to efficiently manage
the Dockers.
They're telling you that because they've
On 30/08/2015 01:13, Simon Hobson wrote:
I don't think anyone has suggested it's for servers only. But, there
is an argument for picking the low hanging fruit - and that means
trying to do the easy bits first. I've not really followed it in
detail, but from what I've read it does seem that the
On 31/08/2015 20:56, Tobias Hunger wrote:
Oh, I am pretty happy with systemd and won't lie about that. I would
still like to see some competition going.
That's pretty much the crux of the problem here. Nothing can compete
with systemd on the same grounds, because systemd covers so much ground
On 01/09/2015 10:29, Jaromil wrote:
if you can confirm the plan of releasing r6-rc within september
I confirm it.
--
Laurent
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
On 01/09/2015 10:04, Tobias Hunger wrote:
Now that is a really depressing outlook.
What can I say: the state of affairs with the systemd madness
*is* depressing.
I am way more positive than about your chances than that. X11 used to
be impossible to replace because of drivers and we are
On 03/09/2015 18:35, Steve Litt wrote:
I'd figure out how to stop those zombies from happening in the first
place. It's pretty hard to create a zombie: I think you have to
doublefork and then terminate.
Nope, a zombie is actually very easy to create:
- have a process parent that spawns a
On 01/09/2015 15:50, shraptor wrote:
I am interested in r6-rc is there any place to read more about it
or perhaps I have to wait for the release?
http://skarnet.org/s6-rc/ but you won't see much there until it's
released.
You can get a preliminary look, which includes some early
On 29/09/2015 17:34, Timo Buhrmester wrote:
It can't respawn
Probably because people don't want this behavior. Auto-respawn only
makes sense when you're "relying" on buggy software you already expect
to blow up, *and* are unwilling to debug it. "Try turning it off
and on again", "A restart
On 24/09/2015 15:31, Rainer Weikusat wrote:
I'd still very much like to see an actual example which really needs
these depenencies which isn't either bogus or a workaround for a bug in
the software being managed.
Your network must be up before you do any network connections.
Your DNS cache
On 24/09/2015 16:40, Rainer Weikusat wrote:
Hence 'failure'
is part of the normal mode of operation and proccesses trying to use TCP
need to deal with that.
Yeah, well, if your favorite startup mode is to start everything at
the same time and say "eh, if it doesn't work, the program is
On 24/09/2015 17:51, Rainer Weikusat wrote:
If it starts working within less than five minutes, users will forget
about it faster than they could complain, especially for a system which
is usually supposed to be running. But that's actually a digression.
Five minutes? And you think it's
On 25/09/2015 11:27, KatolaZ wrote:
I actually had the impression that servers was what Laurent was
referring to... :)
Was I? It's possible.
I usually refer to servers because it's the environment I'm used
to; but what I'm saying about boot times, parallelism and so on
is also true for
On 24/09/2015 21:23, Steve Litt wrote:
What's the benefit of having the shortest run-time code path of any
service manager?
- Speed: a short run-time code path means that less instructions are
executed, so the job is done faster. The point is to do the amount
of necessary work (calling the
On 25/09/2015 17:29, Simon Hobson wrote:
Windows and MacOS both prioritise those tasks needed to get a desktop
picture (or login prompt) on the screen - as that gives the illusion
of fast boot time.
Oh, yes, definitely. (My client machine runs Windows, and I experience
that every day.)
It
if you can confirm the plan of releasing s6-rc within september
I confirm it.
And, lo and behold, I'm on schedule for once.
s6-rc-0.0.1.0 is out.
s6-rc is a service manager for Unix systems, running on top of
a s6 supervision tree. It manages the live state of the machine,
defined by a
On 25/09/2015 09:05, Simon Hobson wrote:
More to the point, I'd rather have reliability over speed any day.
How about you get both?
The dichotomy is a false one. People believe they can't have both
because init systems have never been done right so far, and always
forced them to choose
On 25/09/2015 09:26, Jaromil wrote:
What I'm particularly interested is something to do process monitoring
and respawning for a certain group of daemons
Just supervise the daemons you want to supervise, and don't
supervise the ones you don't want to. But really, there's no
reason *not* to
So I was wondering what the original intent was in having these two
directories directly off the root? Is it so the init and supervision
can proceed even before partition mounts are complete? Is there some
other reason? Can anyone recommend setups that fulfill the reasons for
the
What do we as a community need to do
to get S6 into a "corporate friendly" state?
What can I do to help?
"Corporate-friendly" is not really the problem here. The problem is
more "distro-friendly".
Distributions like integrated systems. Integrated systems make their
lives easier, because
80 matches
Mail list logo
