ently comparable,
since presumably you wouldn't have to spend money to keep the existing
32-bit machine in service). If Andrey does, I'd be interested to learn
it.
--
The Wanderer
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the wor
the upgrade to Jessie continue to
work equally well until the user decides to reboot - whether that's
immediately, or six months down the line. Previous releases could
successfully be used that way, after all; I've done it with at least one
of them.
- --
The Wanderer
Secrecy is the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 07/03/2014 11:53 PM, Russ Allbery wrote:
> The Wanderer writes:
>
>> I, for one, would be highly displeased if a routine dist-upgrade to
>> testing required me to reboot to avoid having things break.
>
>> I genera
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 07/04/2014 04:52 AM, Philip Hands wrote:
> The Wanderer writes:
>
>> ... particularly because I use rather fewer things than many other
>> people, and don't use most fancy GUI elements. (For example, I
>> don
mponents are going to
> need such forced reboots on a repeated basis, I don't like where this
> is going.
To be fair, I don't think anyone has suggested that reboots would be
required "on a repeated basis" - only on the initial transition.
- --
The Wanderer
Secrecy is the b
be upgraded from
versions which rely on X to versions which rely on Wayland - then at the
very least a pre-upgrade warning should be provided, with the
opportunity to cancel / postpone the upgrade.
One of the things people have been asking for, when it comes to systemd,
is such a warning in the f
wouldn't this mean that it wouldn't be possible to make local
modifications to a module found there and distribute them by other means
(e.g. even within one's own organization) without either making a false
statement in the license or violating the license?
If it would mean that, then
even I just accept that default sometimes.
Changing that default, without forcing HTTPS in the way which people in
this thread are objecting to, would seem to require changing all of
those clients - a much, much bigger proposition than the administrators
of any one server can practically tackle.
- -
l images almost certainly makes more
sense than using netinst.
- --
The Wanderer
Secrecy is the beginning of tyranny.
A government exists to serve its citizens, not to control them.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQI
the people behind the libav side of the
split seems, IIRC, to have been "no code gets in without having been
reviewed by someone other than the author", this was apparently deemed
an unacceptable condition.
- --
The Wanderer
Secrecy is the beginning of tyranny.
A government
e found in making sure that everything passes
through one central (discussion-enabled) point before landing.
- --
The Wanderer
Secrecy is the beginning of tyranny.
A government exists to serve its citizens, not to control them.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG
ts xz decompression, then surely it doesn't matter
whether some outside source for xz compression / decompression is
available.
Unless debootstrap relies on the outside source to perform that
decompression, of course, but in that case I'm not sure what it would
even mean to say that deboot
s discussion
(and possibly similar ones) understand "default" as meaning in the
context of "default init system for jessie", and possibly clarifying
that more officially on a broader scale for future reference?
- --
The Wanderer
Secrecy is the beginning of tyranny.
A
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 09/05/2014 at 07:26 AM, The Wanderer wrote:
> On 09/05/2014 at 04:57 AM, Josselin Mouette wrote:
>
>> Noel Torres wrote:
>
>>> So we are clearly failing to follow the least surprise (for
>>> the user) path.
>
#x27;, and AFAICT that should get the job
done.
Alternately, it should be possible to pin systemd-sysv to "not
installed", even when no such package as systemd-sysv exists - and then
dist-upgrade should be able to figure out the necessary dependency
resolution.
- --
The Wanderer
Secr
sure at least a large fraction of the remaining disagreements
I've seen under discussion lie in conflicting understandings of that
meaning, and it looked as if the current discussion might be getting
closer to clarifying people's conflicting understandings - which can
only help, even if no offi
which is
essential to the nature of an init system, the only way to avoid this is
to require that no init system implement any feature that something
outside of the init system might legitimately want to depend on - unless
that feature is also implemented equally in a standalone form.
- --
T
nvolved but interested observer, I though this
(switching the shell people use to build and test their packages, and
nothing else) was what you were proposing in the first place.
--
The Wanderer
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world
ffect that my package
preferences don't get counted in this kind of statistics.
--
The Wanderer
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- G
utside the bounds of what constitutes "utterly smooth", and I would
consider any such functionality loss to be a bug - quite possibly an RC
bug. The maintainer in question, at least, does not appear to think
that; he does appear to agree that it would be a bug, but a minor one at
best. T
es that still apply for a package which isn't in testing at all, and
has never been in unstable before?
Because I wouldn't expect so, and I thought that such a package was what
we were talking about here.
--
The Wanderer
The reasonable man adapts himself to the world; the unreasonab
lopers, and is the core reason why blaming
systemd upstream for the problems that result from
> • Software A's upstream decided they wanted to use it, because it made
> their life easier.
is arguably (but IMO often) legitimate.
--
The Wanderer
The reasonable man adapts himself
removed.
(I'm pretty sure I've seen a proposed solution, in a package-upgrade
scenario, which involved "remove package X and everything that depends
on it", as well. But I don't recall any specifics on that one, so it
might be my imagination.)
My core objection to aptitude
On 10/21/2014 at 10:03 AM, Josselin Mouette wrote:
> The Wanderer wrote:
>
>> This is the problem. The init system should not be providing
>> "features" which other software might, post-boot and pre-shutdown,
>> want to make use of. (AFAIK sysvinit never did
see their point,
although I don't know whether I necessarily believe it holds.
> Only because the "Wanderer" is a troll, doesn't mean that everything
> he says is wrong.
I object to being characterized as a troll. I'm not trying to stir
things up or incite a furor o
On 10/21/2014 at 10:35 AM, Matthias Urlichs wrote:
> Hi,
>
> The Wanderer:
>
>>> Can you give an example of people doing that in case of systemd?
>>> Because so far, everything I heard was similar to GNOME, where:
>>> • systemd provided a feature.
>
ld cease entirely to be remotely on-topic
for debian-devel (even to whatever extent this entire thread isn't
already offtopic).
Any suggestions for a place where such discussion would be welcome or
at least acceptable, and where it would reach people who are
experienced with or at least interest
I don't know how common such situations are, but they do seem to occur,
and to be more than a visual glitch.
--
The Wanderer
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unrea
-'.
In any other scenario, the current tools seem entirely capable of
figuring out the correct thing to do without issues. As far as I am
aware, there is not currently any such pair of packages.
Would it be reasonable to write a requirement into some appropriate
document (possibly Policy) forb
wouldn't
> be surprised to find some.
There aren't any in current stable, testing, stable/updates, or
testing/updates, at least. That was the first thing I checked.
--
The Wanderer
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw
signature.asc
Description: OpenPGP digital signature
t the harmful actions of
> some project members and the complicity of others in those actions
> over some significant time now.
Agreed. (Or IHO harmful, at least - I'm not taking a position on that
myself, not least because I probably haven't seen most of the actions in
question.)
ly
interested in trying to address or discuss that disagreement directly...
it only gets covered indirectly, in the midst of flamewars about the
broader topic. Which is far from an effective way to resolve the
question.
--
The Wanderer
The reasonable man adapts himself to the world; the un
On 11/10/2014 at 08:34 AM, Matthias Urlichs wrote:
> Hi,
>
> The Wanderer:
>
>> Unfortunately, as far as I can tell, no one seems to be remotely
>> interested in trying to address or discuss that disagreement
>> directly...
>
> The problem is that, appare
ing is still going on, the issues are in some
important sense still not "settled"; even if/though they are in the
sense that a project decision has been made, that is not the only
possible or necessarily relevant sense of the word.
--
The Wanderer
The reasonable man adapts him
On 11/16/2014 at 05:11 PM, Theodore Ts'o wrote:
> On Sun, Nov 16, 2014 at 09:02:12AM -0500, The Wanderer wrote:
>
>> I would, for example, have classified the discussions / arguments
>> in the "systemd-sysv | systemd-shim" bug which appears to have
>> r
g them a
known-partially-broken configuration based on systemd-shim and
cgmanager.
Again, if that's not correct, I'd be interested to be corrected on that
point.
--
The Wanderer
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adap
inence of a new stable release, what further
requirements and/or deadlines would I need to keep in mind as I work on this,
and what possible further procedures (beyond those in the new-package
documentation) would I need to follow?
--
The Wanderer
Warning: Simply because I argue an issue does n
On 08/28/2012 06:51 AM, Ian Jackson wrote:
The Wanderer writes ("Restoring the removed e16 package"):
I'm not positive whether this properly belongs here; if it would be more
appropriate on another mailing list, just let me know which one.
On this point, I've already b
than my /
that is hosted in a slower RAID1.
Okay, this is where you stopped making sense.
RAID1 is *not* slower than RAID5. On the contrary. Think about it:
I interpreted that statement as meaning that the RAID1 was hosted on slower
hardware, and therefore was slower overall.
--
The
On 05/13/2013 10:22 AM, The Wanderer wrote:
On 05/13/2013 09:46 AM, Wookey wrote:
Hmm. Do the parts of the 64-bit tree that the 32-bit side compiles
against end up installed in a final installation (as libraries?) or
are they really just intermediate 'during build' items?
They
On 05/13/2013 10:31 AM, The Wanderer wrote:
On 05/13/2013 10:22 AM, The Wanderer wrote:
On 05/13/2013 09:46 AM, Wookey wrote:
Hmm. Do the parts of the 64-bit tree that the 32-bit side
compiles against end up installed in a final installation (as
libraries?) or are they really just
On 05/13/2013 11:00 AM, Wookey wrote:
+++ The Wanderer [2013-05-13 10:22 -0400]:
On 05/13/2013 09:46 AM, Wookey wrote:
OK. I'd like to understand some more about this, as it's a
similar issue to other cross-compiler toolchains, and if we can't
solve both the same way the
On 05/14/2013 09:34 AM, Goswin von Brederlow wrote:
On Mon, May 13, 2013 at 07:55:30AM -0400, The Wanderer wrote:
If I'm correctly understanding what's being described here, I would
think that the full-functionality 64+32 Wine would probably be
another exception (unless it f
om) it's not just a
few random bytes.
I'm coming to lean towards the conclusion that further work on this
would probably be better done in the context of the Debian Wine
packaging team, if not (for some parts of it) Wine upstream...
--
The Wanderer
Warning: Simply because I argue an iss
rrant more care.
--
The Wanderer
Warning: Simply because I argue an issue does not mean I agree with any
side of it.
Every time you let somebody set a limit they start moving it.
- LiveJournal user antonia_tiger
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a
to go
back to that ancient point and proceed forward without using any "v2
only" code, the odds of anyone ever bothering (much less of its ever
being tested in court) are exceedingly slim.
--
The Wanderer
Warning: Simply because I argue an issue does not mean I agree with any
side
t does apparently at least pass
the laugh test well enough to be taken seriously. Alan's (and Uoti's)
point seems to have been to warn people about that fact, and thereby
warn them about the potential pitfalls of relying on the legal
interpretation that Linus was using.
--
The Wa
t nowadays with the Mozilla project; I don't need
more of it elsewhere.)
--
The Wanderer
Warning: Simply because I argue an issue does not mean I agree with any
side of it.
Every time you let somebody set a limit they start moving it.
- LiveJournal user antonia_tiger
--
To UNSUBSCRIBE,
On 07/15/2013 09:43 AM, John Paul Adrian Glaubitz wrote:
On 07/15/2013 03:00 PM, The Wanderer wrote:
My personal objections to systemd come down to the fact that I
don't trust its developers / maintainers. Part of that is bleedover
from the fact that I've so far had only poor experi
On 07/17/2013 03:05 AM, Ondřej Surý wrote:
On Wed, Jul 17, 2013 at 6:29 AM, Chris Bannister
wrote:
On Mon, Jul 15, 2013 at 10:44:21AM -0400, The Wanderer wrote:
My most recent experience with PulseAudio came when I noticed
that WoW (run through Wine) was producing crackling, stuttering
ourse. But
you aren't required to use the code the upstream produces, either.
...except when you need its functionality, and there's lock-in
preventing you from (sufficiently easily) switching to some alternative.
Which may be relevant to the case at hand.
--
The Wanderer
Warning: Simply
een anything which even tries to convince me
otherwise.
[0] Meaning approximately "we create our own language and talk it to
ourselves, and anyone else who wants to talk to us has to learn our
language", not intending to imply "undocumented" or "legally restricted"
On 07/21/2013 05:04 PM, Josselin Mouette wrote:
Le samedi 20 juillet 2013 à 19:21 -0400, The Wanderer a écrit :
[I am almost certainly going to regret this.]
I hope so.
Please don't be a jerk.
Making the switch away from the entrenched sysvinit is visibly very
difficult, at least
ative
much bigger than just implementing a new init system; any new
alternative would then have to jump over considerably bigger hurdles
than systemd did.
It will be the same situation as we currently have sith SysV-Init.
So I wouldn't worry about this at all :-)
Isn't the current
much bigger job than just implementing a new
init system.
--
The Wanderer
Warning: Simply because I argue an issue does not mean I agree with any
side of it.
Every time you let somebody set a limit they start moving it.
- LiveJournal user antonia_tiger
--
To UNSUBSCRIBE, email to debian-devel
On 07/22/2013 02:52 AM, Tollef Fog Heen wrote:
]] The Wanderer
If someone implementing a new alternative wanted to retain the
other tools with which systemd integrates, that person would have
to match their interfaces, which might limit the functionality the
new alternative could be able to
On 07/22/2013 08:48 AM, Jeremy Bicha wrote:
On 21 July 2013 20:22, The Wanderer wrote:
I'm saying that it looks to me as if the lock-in to systemd would
be even stronger than the lock-in to sysvinit, and might well
extend to the point of even making it harder to implement anothe
threat (of "contempt of court", AIUI) may have
been not for shutting down the site or for refusing to comply but for
effectively violating a gag order about the whole thing by the way he
explained that - and why - he was shutting down.
--
The Wanderer
Warning: Simply because I argue
such a fallback exists, without preventing root from
manually overriding it.
If the stated goal is to avoid having e.g. /boot fill up with cruft
short of manual intervention, then at a glance, the mechanism which
these files provide does not seem to interfere with that goal.
--
The Wanderer
ect me.
* For reasons I don't properly understand, some people seem to think
a decision is needed to make or not make systemd the default in
Debian.
Have I missed anything or got anything wrong?
With the above modifications, looks about accurate to me, for whatever
that may be worth.
--
igning,
building, and supporting laptops specifically intended to run Linux. I haven't
used one myself, but they look like a good outfit from what I can see, and the
laptops look decent within the somewhat limited selection available.
--
The Wanderer
Warning: Simply because I argue an is
program sit unchanged is automatically a bad
thing, no matter how close to perfect-for-its-purpose the program may already
have been.
Change is not always bad; in fact, it's very often good. But change isn't always
good either, and refusal of change isn't always simple obstinacy or
on-list copy (so that messages from the list in my archive are
consistent), even if I've already received the off-list copy, but in my
experience the Message-IDs of the two variants of the message are very often
identical.
--
The Wanderer
Warning: Simply because I argue an issue does not
here's argument to be made that the actual problem lies in not
changing the Message-ID when modifying a message for mailing-list
retransmission, but that's a long-established practice and there are very likely
reasons for it.
--
The Wanderer
Warning: Simply because I argue an iss
On 11/26/2012 08:22 AM, Andrew Shadura wrote:
Hello,
On Mon, 26 Nov 2012 08:07:03 -0500 The Wanderer wrote:
Gmail does something similar, except not time-limited; it won't even
re-send you a copy of a mail you send to a mailing list. This is apparently
on the grounds that you already
release".
I'm not saying he's right - sarge was assigned version 3.1, for example, and
other non-'x.0' releases have been made in the past - but that seems more like
an argument that someone might actually make.
--
The Wanderer
Warning: Simply because I argue an issue
t a way to
override the block just as conveniently as it was set up in the first place.)
So either I'm not understanding what you mean by this description, or what
you're describing doesn't seem to be happening on my system.
--
The Wanderer
Warning: Simply because I argue an issue
On 01/04/2013 09:15 AM, Thomas Preud'homme wrote:
Le vendredi 4 janvier 2013 05:44:57, The Wanderer a écrit :
That doesn't seem to match my experience.
I most commonly encounter apt-listbugs bug lists via 'apt-get
dist-upgrade'. If I say "no" in response to
probably in many practical cases as well.
--
The Wanderer
Warning: Simply because I argue an issue does not mean I agree with any
side of it.
Every time you let somebody set a limit they start moving it.
- LiveJournal user antonia_tiger
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.d
I haven't noticed? Or "none of the above"?
--
The Wanderer
Warning: Simply because I argue an issue does not mean I agree with any
side of it.
Every time you let somebody set a limit they start moving it.
- LiveJournal user antonia_tiger
--
To UNSUBSCRIBE, email to debian-devel-
On 03/05/2013 10:46 AM, Johannes Schauer wrote:
Hi,
Quoting The Wanderer (2013-03-05 15:35:37)
You can build either one without a matching version of the other, but you
won't get full functionality. In order to get the full functionality of
both, from what I've been able to tell
ou have to
take two. You pay for that convenience by sacrificing the convenience of being
able to close the lid *without* suspending, but which inconvenience is the
greater depends on your usage patterns, and different people may well prefer to
sacrifice different ones.
--
The Wanderer
Warni
titions laid out and
filesystems created by hand.
--
The Wanderer
Warning: Simply because I argue an issue does not mean I agree with any
side of it.
Every time you let somebody set a limit they start moving it.
- LiveJournal user antonia_tiger
--
To UNSUBSCRIBE, email to debian-devel-requ...@lis
#x27;t.
It may or may not be relevant that I have grub-pc held on my desktop at version
1.99-17; I believe this was originally due to the existence of bugs which
claimed that upgrading could/would break the boot, but by now it may be due more
to inertia than to anything else.
--
The Wanderer
I heard mixing and matching between
the two is not encouraged (though I don't know why not), and since dealing with
the limitations of apt-get is far less aggravating for me than dealing with the
attempted cleverness of aptitude, I find the older program by far the more
preferable solution.
-
nd including it on the list of release goals
seems like an appropriate way of raising its profile (and/or its
priority) in pursuit of that.
--
The Wanderer
Warning: Simply because I argue an issue does not mean I agree with any
side of it.
Every time you let somebody set a limit they start m
t only not do it ourselves but push back
against upstream efforts to do it.
If the distinction does not still make sense, then we should explicitly
decide to reject it, and under that scenario moving to merge /usr with /
(in either direction) seems like a very sensible thing to do.
ose -dev packages is installed - and swap back afterwards
for normal compilation of other things.)
--
The Wanderer
Warning: Simply because I argue an issue does not mean I agree with any
side of it.
Every time you let somebody set a limit they start moving it.
- LiveJournal user antonia_
onfiguration at all.
--
The Wanderer
Warning: Simply because I argue an issue does not mean I agree with any
side of it.
Every time you let somebody set a limit they start moving it.
- LiveJournal user antonia_tiger
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
wi
On 05/13/2013 09:46 AM, Wookey wrote:
+++ The Wanderer [2013-05-13 07:55 -0400]:
For the full 64+32 Wine, I don't believe this is possible - or if
it is possible, no way of doing it has yet been documented that I
know of. The official Wine documentation of how to build that
configur
l use MEncoder anyway, because there are things it can do
that FFmpeg can't do yet, but there aren't very many such things
anymore.
In any case, wouldn't this be more work than updating the MPlayer
package(s) to use the current upstream release?
- --
The Wanderer
Secrecy is
package FFmpeg in their place.
At the time, I remember someone saying that there should be no reason
both could not be available (possibly with Conflicts or similar) if
someone did want to do the packaging work for FFmpeg. However, I'm not
sure that statement didn't come from the Ubuntu
However, even aside from
MEncoder being officially deprecated by upstream, it seems likely that
doing that would involve most of the same work as getting MPlayer itself
working again and probably more into the bargain - so if you're going to
do the work anyway, why not retain both?
- --
if the
only available one is tied to a release, then it seems natural and
appropriate for the release team to be the ones to oversee those goals.
If we don't want them doing that (for whatever reason), then we need to
either decide that no enforcement mechanism is needed, or come up with
one t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 12/26/2013 09:35 AM, Adam D. Barratt wrote:
> On Thu, 2013-12-26 at 09:02 -0500, The Wanderer wrote:
>
>> It's seemed intuitively obvious to me that a "release goal" could
>> equally be defined as "a n
iew/20653/intel-320-series-solid-state-drive
The article includes spec-sheet information and detailed benchmark
results. Glancing over them again, I'm not surprised by this described
result from that drive; there are other SSDs that might do much better.
- --
The Wanderer
Secrecy is the be
tion introduce another variable
and likely improve performance, these drives were specifically chosen
because they were top performers in their capacity class at the time -
and with SSDs, higher capacity generally performs better anyway. So this
may not be a particularly valuable datapoint.
- --
ustify the generality of the statement, and in any case that
would be an implementation detail rather than a basic fact of flash
memory.
Is there something I've missed?
- --
The Wanderer
Secrecy is the beginning of tyranny.
A government exists to serve its citizens, not to control them
er trust
that the result of that work will be - or, if it once is, will continue
to be - something *I* would consider good.
As such, advice to "not be distrustful" seems to me to be lacking an
essential foundation.
- --
The Wanderer
Secrecy is the beginning of tyranny.
A governme
tart/stop of each field) of a text file than
it is of a binary one, when working without known-reliable
documentation. (And I'm not willing to assume that I'll always have such
documentation.)
There's a *reason* the vast majority of kernel userspace-interface files
are in plain-text
nk what was meant by the
phrasing was not "If X, then Y", but "Just because X, that does not mean
Y".
- --
The Wanderer
Secrecy is the beginning of tyranny.
A government exists to serve its citizens, not to control them.
-BEGIN PGP SIGNATURE-
Version: GnuPG
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 02/11/2014 12:38 PM, Russ Allbery wrote:
> The Wanderer writes:
>
>> In my case: because I want to be able to read them conveniently at
>> a glance, without requiring the presence of a functioning
>> specialized tool f
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 02/11/2014 10:15 AM, Olav Vitters wrote:
> On Tue, Feb 11, 2014 at 09:05:48AM -0500, The Wanderer wrote:
>> I do not trust the systemd project to not do things I consider bad
>> or even insane, because they've already done s
liking, you will have to deal with other
> people's preferences. It's like that and that's the way it is...
Quite true, which is at least one-third of the reason I didn't speak up
against the switch to libav at the time when it happened. Reinhard
preferred it, and he was the o
separately, from source to
syslog (presumably in the form of rsyslogd), or does it flow from source
to journald to syslog? (Or something else? Or am I missing / making an
assumption that turns this into a stupid question?)
- --
The Wanderer
Secrecy is the beginning of tyranny.
A governme
e binary
nature of the file format.
(And now I wait for someone to point out an obvious specialized format
and/or tool that everyone uses that I've overlooked...)
- --
The Wanderer
Secrecy is the beginning of tyranny.
A government exists to serve its citizens, no
ts.debian.org/debian-devel/2002/07/msg01139.html
- --
The Wanderer
Secrecy is the beginning of tyranny.
A government exists to serve its citizens, not to control them.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBCgAGBQJ
much more than 5, and is still only
counting people who run popcon. (Which I often don't, because it breaks
my reflexive attempts to tab-complete 'popd' when I'm root.)
- --
The Wanderer
Secrecy is the beginning of tyranny.
A government exists to serve its ci
efault
really is - and, barring another project-wide decision, is expected to
indefinitely continue to be - as simple as installing one set of
packages rather than another.
- --
The Wanderer
Secrecy is the beginning of tyranny.
A government exists to serve its citizens, not
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 03/30/2014 10:57 AM, Thomas Goirand wrote:
> On 03/30/2014 08:02 PM, The Wanderer wrote:
>
>> If it's been decided to continue to require package maintainers to
>> provide traditional init scripts as well as systemd u
1 - 100 of 235 matches
Mail list logo
