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 th
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 direct-off-root
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 wil
On 28/09/2015 22:05, Rob Owens wrote:
Here is a real-world scenario that has caused me trouble over the years.
I have a system that connects wirelessly to my local network. The system
uses wicd to manage the network connections, and wicd starts at boot.
This system is supposed to mount several N
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 doe
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 client
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 supe
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 betwee
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 scr
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 accept
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 suppos
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 mu
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 s
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 chil
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
documentation
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 pret
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 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 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 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
https://mailinglists.dyne.org/cgi-bin/mailm
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 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 b
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 AT&T Unix Version 1:
Yes. However, Unix has evolv
On 29/08/2015 14:43, Rainer Weikusat wrote:
'su' is not a concept, it's a program.
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 with the
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 do
On 22/08/2015 17:20, Timo Buhrmester wrote:
I wouldn't quite take this personally, and I doubt anyone on the list
is to blame for that, with the possible exception of yourself for not
arranging yourself around the fact that these days, MTAs behind
dynamic IPs are automatically suspicious.
Well
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 question
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 prev
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 issue
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 appreciate
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 p
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 o
On 08/08/2015 03:43, Isaac Dunham wrote:
Which, fortunately, is pretty easy to do: I wrote an environment
sanitizer yesterday, because I was curious how easily solved that is.
Usage is
cautenv [-c DIR] [-u] [-x] COMMAND [COMMAND_ARGS...]
Would you mind linking it ? I'm interested in trying to
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 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 somethi
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 *are
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 env
On 06/08/2015 16:31, Isaac Dunham wrote:
If differences in environment can cause problems, it's a problem with
design. A program that changes what it does just due to differences
between the init environment and a login environment is going to be
hard to debug.
There are tons of those, and you
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 sh
On 06/08/2015 11:45, tilt! wrote:
Thing is, init scripts tend to have problems managing services
that do not offer sufficient commandline interfaces as described
above
There's a simple reason for that: "init scripts" aren't
"managing services". They can more or less start and stop them,
that's
On 02/08/2015 09:14, Steve Litt wrote:
So next time one of the new breed calls you a neckbeard for helping
build a distro with simple protocols and services, show him
http://www.catb.org/esr/halloween/halloween1.html . And try not to
laugh when the whole thing goes right over his head.
Also, s
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
N
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 29/07/2015 18:03, tilt! wrote:
My estimate is that such daemon was not resource hungry:
Actually, I'm talking about a daemon consuming entirely negligible
resources, performing no polling at all, only reacting to an
external command performed either manually or via the hotplug helper.
I k
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 notifi
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 c
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 noti
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 ho
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 conv
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) shou
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 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, late
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 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 eve
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 de
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 t
On 03/07/2015 14:39, Franco Lanza wrote:
SystemdOS will be just another bad thing that many people will have to
use for a period of time, and, just like today microsoft is a little bit
less invasive than some years ago and it's doing a little bit better
with latest windows version, in some years
On 01/07/2015 21:17, Martin Steigerwald wrote:
Linus describes personality issues around how to handle bug reports.
And I think that is one of the main issues I have with some systemd upstream
developers as well. The "we are right, you are wrong", "we wont fix this its
not our bug", "we created
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.0mainlinkanon&utm_medium=feed
Yes, it can happen to the best of us: even Linus doesn't know there
are alternatives to handle services
On 2015-06-20 11:56, k...@aspodata.se wrote:
# grep /boot/init.sysvinit /var/log/all.log
Jun 20 11:33:47 opal kernel: [0.00] Kernel command line: BOOT_IMAGE=312
ro root=901 noinitrd init=/boot/init.sysvinit
Jun 20 11:33:47 opal kernel: [2.332734] Failed to execute
/boot/init.sysvini
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 computation
On 18/06/2015 16:15, Steve Litt wrote:
I was envisioning Devuan people making the defs and runscripts, not the
authors of the init systems. It would be crazy for us to think you, or
someone in your position, would write AND MAINTAIN between 30 and 200
run scripts. That's crazy. What wouldn't be c
On 18/06/2015 15:47, Steve Litt wrote:
I expect the dependency chain should be something like:
depends on: init, -sysv-init | -epoch-init |
-systemd-init | -openrc-init | -upstart-init
Who, too much for me! Too much for most people. Entangled.
Still, it is an accurate representation of
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 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 requires to be running and
ready: you *must* run a supervisor, or else run a lame-not-quite-a-
supervi
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 w
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
W
[ 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 w
On 14/06/2015 15:29, Nikolaus Klepp wrote:
And I thought the historic solution would be to give your web printing service
an id higher than cups, eg.:
/etc/rc*/S04cups
/etc/rc*/S99awsomewebprinter
Together with the nightmare from unix museum (aka fork when ready) it simply
works.
No, it do
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 o
On 13/06/2015 08:40, Didier Kryn wrote:
Yes, daemon writers are good-willing developpers; they want their
software to serve as many users as possible; and users install
distros. This gives power to the distros. But if someone provides
them with a KISS readyness-signaling method, along with a syst
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 suspen
On 13/06/2015 10:43, marc wrote:
It is only bad design if you have your heart set on a supervision
framework like daemontools.
No, it is bad design because
- it lengthens the code path before the service is operational
- it requires software authors to write more code into their
daemon inste
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 w
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
https://github.com/systemd/systemd/b
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 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 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 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 c
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 03/06/2015 13:32, Jaret Cantu wrote:
Freedom of choice, but let them know that their choice makes baby kitten angels
cry.
Give freedom of choice if it's what the distribution is about; or don't
give the option if the distribution is about licensing purity.
But whatever you do, don't pate
On 01/06/2015 11:25, Didier Kryn wrote:
I know the argument that init should be kept small to be rock-solid.
Does it mean that it must be written in C and not in Lua or Ash?
It all depends on what you call "init". This word encompasses at
least three different things. Explanation and details h
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 scr
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 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 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 doesn't
On 27/05/2015 16:49, Didier Kryn wrote:
I am slowly trying to assemble a minimal Linux development
environment and the number of tools you need to just compile a C
program is unbelievable. Clearly, the majority of developpers don't
care about simplicity.
Amen to that.
I built my home router
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 useful
On 24/05/2015 00:17, Steve Litt wrote:
http://troubleshooters.com/linux/politics_of_dependencies.htm
Well written, Steve. I liked the article. :)
I would argue that arrogance isn't so much the problem as carelessness.
It's actually a good idea to stand your ground against external pressure
w
On 14/05/2015 23:16, shraptor shraptor wrote:
I even could try myself, did openssl static with musl a while ago but am not a
100%
with what toolchain means.
I compile everything statically with musl. OpenSSL is doable; the
annoying thing IIRC is the Perl dependency at build-time, and of
cours
On 06/05/2015 19:49, Anto wrote:
When I started this thread, I genuinely asked technical question
related to what I am doing in removing systemd's files from Debian
sources of some packages. I am quite sure that I didn't propose or
demand that to be implemented in Devuan. I am doing that all sole
On 05/05/2015 23:03, marc...@welz.org.za wrote:
Hello
No, sorry. Doing chown root:admin && chmod 2750 does not give anybody
in the admin group (the ones who should be allowed to run it) any
extra rights - they are already running with admin group privileges
Ah, yes, my mistake. The pattern I w
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 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 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. Th
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 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 do
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 yo
On 30/04/2015 20:16, John Morris wrote:
He is correct on this point. One should always obey the rules until you
understand why the rule was made and the consequences of breaking it.
Except that the rule we're talking about just shouldn't be violated.
Once upon a time the rule was that / sh
On 30/04/2015 15:58, Joerg Reisenweber wrote:
I beg to differ on that, to me it seems it has all the sound rationale it
needs, to for example understand why /bin should have commands that are needed
during early boot, before /usr gets mounted.
Thus FHS is not only a summary of current practice b
1 - 100 of 104 matches
Mail list logo
