Re: [01/05] Embedded with systemd: systemd and SIL

[Jeremiah Foster]

On Sun, Nov 16, 2014 at 7:52 PM, Robert  wrote:

> By choosing packages carefully, it is possible to use linux in
> applications that need to meet SIL1 or SIL2 criteria [1].


No. At least this is my understanding of the situation today. SIL, or
System Integrity Level, is something that needs to be certified by a third
party and I don't believe that has ever been done for Debian. It is usually
done for proprietary RTOSes like QNX.


> I personally
> don't have any applications that need to meet SIL2, but it is possible
> to meet SIL1 by taking a normal installation and removing a bunch of
> stuff (initramfs, udev and inetd amongst others) until the system is
> deterministic enough (see the methodology in [2]). /sbin/init functions
> OK with a few static devices in/dev
>

It is not enough. You need to demonstrate that you meet the SIL level you
claim through certification.

>
> Given the tight udev/systemd marriage and the undeterministic nature of
> socket activation, I suspect that systemd will never be suitable for
> SIL applications.
>
> Are there any other debian embedded developers that need to meet SIL
> criteria? How are you planning to manage the fact that there are very
> few non-systemd distros left, or do we have to resign ourselves to a
> life of OpenEmbedded and buildroot?
>

The two issues are orthogonal. Init processes don't really need to meet the
SIL level since they're mostly a part of userland. OpenEmbedded is almost
certainly not used by the current SIL certified OSes out there. There is
however a project at OSADL which is planning to take a kernel and a very
small userland, essentially Debian's net install as defined by
debbootstrap. This work is being done in OSADL with the support of numerous
companies since industries like the automotive industry find the current
crop of SIL certified operating systems too inflexible to do many of the
things they'd like to do on modern silicon. Look at the SIL2LinuxMP project
for more: http://www.osadl.org/SIL2LinuxMP.sil2-linux-project.0.html


Regards,

Jeremiah


>
> [1] http://www.reliableembeddedsystems.com/pdfs/2010_03_04_rt_linux.pdf
> [2] http://www.hse.gov.uk/research/rrpdf/rr011.pdf
>
>
> --
> To UNSUBSCRIBE, email to debian-embedded-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive: https://lists.debian.org/5468f252.50...@gmail.com
>
>


-- 
Jeremiah C. Foster
GENIVI COMMUNITY MANAGER

Pelagicore AB
Ekelundsgatan 4, 6tr, SE-411 18
Gothenburg, Sweden
M: +46 (0)73 093 0506
jeremiah.fos...@pelagicore.com

Re: [04/05] Embedded with systemd: systemd and kernel upgrades

[Darac Marjal]

On Sun, Nov 16, 2014 at 08:52:37PM +0200, Robert wrote:
> This was recently posted on #systemd-devel:
> 
> "To make this clear, we expect that systemd and kernels are updated in
> lockstep. We explicitly do not support really old kernels with really
> new systemd. So far we had the focus to support up to 2y old kernels
> (which means 3.4 right now), but even that should be taken with a grain
> of salt, as we already made clear that soon after kdbus is merged into
> the kernel we'll probably make a hard requirement on it from the systemd
> side."
> 
> This is a very onerous requirement in the embedded world. There are many
> embedded platforms sold today that only have 2.6.X BSPs. While I agree
> that the BSP from vendors should be better (and it is getting better
> thanks to devicetree), it seems that we are doomed to run ancient
> userspace to match our ancient kernels.
> 
> This change will probably hit me the hardest and for me it really cuts
> into what linux means. It used to be that I could run the same userspace
> on my tiny embedded device, my desktop or on the server --- the only
> difference being the kernel.
> 
> It seems like the only solution here is to abandon debian and fall back
> to OpenEmbedded or buildroot.

Not necessarily. If debian supports your embedded architecture, then
you'll get the right thing. Now there's a number of avenues that Debian
could take:
 * Backport the necessary features in the newer kernel to the older
   kernel (the bigger the change, though, the harder this will be as it
   will only be Debian supporting it, rather than the upstream kernel
   team)
 * Disconnect the 'lockstep' connection. I don't know the details, but
   it might be that, in practice, there is some wiggle room and the
   kernel and userspace could be, say, the same minor version but
   different patch levels.
 * Special-case the architecture. At the moment, for example, systemd is
   the default init with a Linux kernel; for the kfreebsd port cgroups
   are unavailable so systemd doesn't work. So kfreebsd is special-cased
   not to include systemd. If necessary, similar could be done for your
   architecture.

> 
> 
> -- 
> To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
> with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
> Archive: https://lists.debian.org/5468f275.5020...@gmail.com
> 


signature.asc
Description: Digital signature

Re: systemd - so much energy wasted in quarreling

[Eduard Bloch]

Hallo,
* st [Tue, Nov 11 2014, 02:01:46AM]:
> Hans wrote:
> 
> >And at the beginning things never work perfect
> 
> That's why they shouldn't make it into Stable as defaults,
> now should they?

We shouldn't and we are not. Because it's not "the beginning", systemd
already has multiple years of history behind.

I am wick of people whining about problems that systemd allegedly has but
that turn out to be a bug in something else when you dig deeper, or are
actually solved long ago. Sometimes this solutions are badly documented,
even so much that it hits my nerve, but apart from that systemd is
mature enough for inclusion as primary init system.

Regards,
Eduard.


signature.asc
Description: Digital signature

Re: Embedded with systemd

[Jeremiah Foster]

> --
> Embedded with systemd: systemd and kernel upgrades
>
> This was recently posted on #systemd-devel:
>
> "To make this clear, we expect that systemd and kernels are updated in
> lockstep. We explicitly do not support really old kernels with really
> new systemd. So far we had the focus to support up to 2y old kernels
> (which means 3.4 right now), but even that should be taken with a grain
> of salt, as we already made clear that soon after kdbus is merged into
> the kernel we'll probably make a hard requirement on it from the systemd
> side."
>
> This is a very onerous requirement in the embedded world. There are many
> embedded platforms sold today that only have 2.6.X BSPs.


But I highly doubt those devices have modern userlands.



> While I agree
> that the BSP from vendors should be better (and it is getting better
> thanks to devicetree), it seems that we are doomed to run ancient
> userspace to match our ancient kernels.
>
> This change will probably hit me the hardest and for me it really cuts
> into what linux means. It used to be that I could run the same userspace
> on my tiny embedded device, my desktop or on the server --- the only
> difference being the kernel.
>

I find it unlikely that you'd be able to run Jessie on your desktop and
Jessie on your device, at least, not without a little bit of work. I think
that work shouldn't be that hard actually, depending on what you've got for
embedded hardware (you haven't been very specific yet.) Things like the
Beagle Board run Debian out-of-the box, so depending on your hardware,
things might be pretty easy.

>
> It seems like the only solution here is to abandon debian and fall back
> to OpenEmbedded or buildroot.
>

OE, yocto, buildroot, etc. are always options. But iwith OE once you've
built your image, you're on your ow, the vendor won't help you without a
support contract and many of the userlands are maintained by large
companies that will ignore you. With debian, you have a large community of
support, including those working in Linaro. The big shadow hanging over
embedded is not OE, but Android, which many embedded developers see as
"winning" against GNU/Linux. This will mean a much more proprietary, or
restricted, userland.

Cheers,

Jeremiah


>
> --
> Embedded with systemd: systemd and realtime
>
> Given the existence of
> (
> http://www.freedesktop.org/wiki/Software/systemd/MyServiceCantGetRealtime/
> ),
> it seems that realtime and systemd is problematic. Has anyone tried the
> workarounds mentioned with a PREEMPT_RT kernel? How did it go?
>
>
> --
> To UNSUBSCRIBE, email to debian-embedded-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive: https://lists.debian.org/5468fd5f.1060...@gmail.com
>
>


-- 
Jeremiah C. Foster
GENIVI COMMUNITY MANAGER

Pelagicore AB
Ekelundsgatan 4, 6tr, SE-411 18
Gothenburg, Sweden
M: +46 (0)73 093 0506
jeremiah.fos...@pelagicore.com

Re: Valuing non-code contributions -- was Re: systemd - so much energy wasted in quarreling

[Chris Bannister]

On Sat, Nov 15, 2014 at 01:13:05PM -0500, Ric Moore wrote:
> On 11/15/2014 08:51 AM, Curt wrote:
> >On 2014-11-15, Renaud OLGIATI  wrote:
> >>>
> >>>Why can't you wrap your lines while you're at it?
> >>
> >>Can't you set your mail client to wrap them for you ?
> >>
> >
> >Sure, and I can killfile the troll, correct the spelling and grammatical
> >errors of the slothful and the ignorant, convert html to text, ignore
> >spam and advertising, translate foreign languages, decipher cryptic
> >codes, tolerate "test" messages and subscription or unsubscription
> >requests, ignore the obscene, abide the rabid, suffer the rant, bear the
> >ad hominem, and blow whatever's left out my ass.
> 
> You'd be left w3ith a period and a semi-colon. :) Ric

Excuse me, but some people think anatomy jokes are distasteful.

-- 
"If you're not careful, the newspapers will have you hating the people
who are being oppressed, and loving the people who are doing the 
oppressing." --- Malcolm X


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141117111012.GE20978@tal

Re: Valuing non-code contributions -- was Re: systemd - so much energy wasted in quarreling

[Tanstaafl]

On 11/17/2014 6:10 AM, Chris Bannister  wrote:
> Excuse me, but some people think anatomy jokes are distasteful.

Some people think sex should only be for procreation...

PC police get sooo tiring...


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5469dcdb.2090...@libertytrek.org

Re: Joey Hess is out?

[Eduard Bloch]

Hallo,
* Slavko [Sat, Nov 08 2014, 04:13:12PM]:
> > Why don't the anti-systemd people do what they've been threatening the
> > whole time and fuck off to another distro or to FreeBSD?
> 
> This is exact example why i stopped all my contribution to Debian, and
> i will not start it again, despite if i stay with Debian in future or
> not! I orphan my packages in near future.
> 
> If the community consider people which have another opinion as bad, it
> is time do not contribute to it more. And whole debate is about one
> idea: If you don't like systemd, you are stupid.

That's not my impression. It's more like: if you don't like systemd,
don't use it. If you don't like it that much that you want to rant
against it, make sure your arguments have some proof/backup.

Since systemd hatters usually fail on the second task, the rhetorical
arsenal is chosen accordingly (ad-hominem, trolling, misquoting, ...).

Regards,
Eduard.


signature.asc
Description: Digital signature

Re: engineering management practices and systemd (Re: Installing an Alternative Init?)

[Chris Bannister]

On Sat, Nov 15, 2014 at 10:14:17PM +0900, Joel Rees wrote:
> On Sat, Nov 15, 2014 at 8:51 PM, Andrei POPESCU
>  wrote:
> > On Vi, 14 nov 14, 22:53:36, Joel Rees wrote:
> >>
> >> If you can't deal with it, snip it?
> >
> > I don't think it brings anything useful to a discussion on -user. That's
> > much more suitable for some -devel list.
> 
> Re-read the wall of text you deleted, then think again about this suggestion.

Or even the off-topic list, if anyone is interested.

-- 
"If you're not careful, the newspapers will have you hating the people
who are being oppressed, and loving the people who are doing the 
oppressing." --- Malcolm X


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141117114428.GF20978@tal

Re: engineering management practices and systemd (Re: Installing an Alternative Init?)

[Chris Bannister]

On Sun, Nov 16, 2014 at 12:00:52PM -0500, Ric Moore wrote:
> On 11/15/2014 08:35 PM, Ludovic Meyer wrote:
> 
> >At the same time, most debian users likely do not really care about 
> >transition
> >plan and systemd. It was widely published everywhere in March and yet, no 
> >one would have cared if this
> >mattered ?
> 
> I installed systemd to Jessie as soon as it was announced. No problems so
> far. I'm happy. :) Ric

Me too. A slight glitch at the start, but easily fixed. Everything
running smooth as!

-- 
"If you're not careful, the newspapers will have you hating the people
who are being oppressed, and loving the people who are doing the 
oppressing." --- Malcolm X


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141117114909.GG20978@tal

Re: Why focus on systemd?

[Chris Bannister]

On Sun, Nov 16, 2014 at 12:29:45PM -0600, John Hasler wrote:
> OdyX writes:
> > ...please stop.  Seriously.
> 
> Please stop ranting about the ranting.  Seriously.  It's just as
> distracting and irritating as the rants themselves.  Just filter the
> rant threads and those who post them.  I'd filter all subjects
> containing the string "[Ss]ystemd" but there may be things about it that
> I need to see. 

Exactly! and there's the trouble. Separating the 'wheat from the chaff' is
the issue we'll probably be facing when Jessie is actually released. :(

A repeat performance is going to get boring very quickly.

-- 
"If you're not careful, the newspapers will have you hating the people
who are being oppressed, and loving the people who are doing the 
oppressing." --- Malcolm X


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141117120657.GH20978@tal

Re: Joey Hess is out?

[Gian Uberto Lauri]

Eduard Bloch writes:

> That's not my impression. It's more like: if you don't like systemd,
 > don't use it.

If I am left free of doing it, there is no problem, Debian does not
force me to use any desktop environment at all, and that pleases me
much, so if I am left free to use an older, tested and reliable init
system there is no problem at all.

 > If you don't like it that much that you want to rant
 > against it, make sure your arguments have some proof/backup.

Systemd is responsible  of too many things, does too  many things, and
this is not a good design choice.

There were other poor design choices, it seems that Debian maintainers
have fixed some of them (i.e. renaming network devices), other seems
to be still there (binary logs...).

But I have no time or will to investigate the subject anymore. When
Debian stable will use systemd in a default installation/dist-upgrade
i will brace for impact and then consider what to do. Quickly, since
my work depends on it :).

 > Since systemd hatters usually fail on the second task, the rhetorical
 > arsenal is chosen accordingly (ad-hominem, trolling, misquoting, ...).

Beware.

Using the second word of the arsenal may make its user elegible of
being the one on the other end of the telephone in this strip:

http://ars.userfriendly.org/cartoons/?id=19990211

-- 
 /\   ___Ubuntu: ancient
/___/\_|_|\_|__|___Gian Uberto Lauri_   African word
  //--\| | \|  |   Integralista GNUslamicomeaning "I can
\/ coltivatore diretto di software   not install
 già sistemista a tempo (altrui) perso...Debian"

Warning: gnome-config-daemon considered more dangerous than GOTO


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/21609.59695.729334.363...@mail.eng.it

Re: init scripts [was: If Not Systemd, then What?]

[Marty]

On 11/17/2014 01:13 AM, Andrei POPESCU wrote:

On Du, 16 nov 14, 13:22:54, Marty wrote:

On 11/16/2014 11:50 AM, Miles Fidelman wrote:

>In the later case, one just has to read:
>http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities/
>to get very, very scared

Each one a bug as per Debian policy (sysvinit support). Looks like we have
our work cut out for us.


Would you please be so kind to point out which bullet point contradicts
which Policy section?

Kind regards,
Andrei


Don't they all by definition? Did I miss something?

I suspect the workaround in all cases is sysvinit-core, but the warning 
still applies to anyone who runs the default configuration.


For the record, since you omitted my smiley, I don't assume these are 
not already well known, or that I am planning to file bug reports. :)







--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Archive: https://lists.debian.org/5469ea0c.3050...@ix.netcom.com

Re: [01/05] Embedded with systemd: systemd and SIL

[Jean-Christian de Rivaz]

Le 16. 11. 14 19:52, Robert a écrit :

By choosing packages carefully, it is possible to use linux in
applications that need to meet SIL1 or SIL2 criteria [1]. I personally
don't have any applications that need to meet SIL2, but it is possible
to meet SIL1 by taking a normal installation and removing a bunch of
stuff (initramfs, udev and inetd amongst others) until the system is
deterministic enough (see the methodology in [2]). /sbin/init functions
OK with a few static devices in/dev

Given the tight udev/systemd marriage and the undeterministic nature of
socket activation, I suspect that systemd will never be suitable for
SIL applications.


Why did you think that localhost sockets activation is not deterministic ?
When local process use localhost sockets, there is no transmission media 
with

risk of packet loss, alteration, random latency, or reordering.

AFAIK, dbus is designed to never loss a message under normal workload. 
Future

kdbus will probably be even better on that matter.

JCdR



--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Archive: https://lists.debian.org/5469e648.1070...@eclis.ch

Re: Joey Hess is out?

[Martin Read]

On 17/11/14 12:25, Gian Uberto Lauri wrote:

There were other poor design choices, it seems that Debian maintainers
have fixed some of them (i.e. renaming network devices), other seems
to be still there (binary logs...).


A default Debian jessie configuration has persistent text logs in 
/var/log written by rsyslog, and *volatile* binary logs in 
/run/log/journal written by systemd-journald. Removing the binary logs 
completely disables functionality of the systemd suite which an 
administrator familiar with systemd would expect to be present by default.


Administrators of systemd-based systems who wish to turn off the binary 
log can, of course, simply add the line


Storage=none

to the [Journal] section of /etc/systemd/journald.conf, at which point 
systemd-journald will simply forward all log entries directly to rsyslog 
without writing them to a binary file.


If installing, or upgrading to, jessie resulted in a configuration with 
*only* binary logs, and this was not the obvious foreseeable result and 
intent of a deliberate administrator action taken during the 
installation/upgrade procedure, then that is probably what we call a 
*bug*, and is the sort of thing that is why Debian has a "testing" branch.



--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Archive: https://lists.debian.org/5469f671.8000...@zen.co.uk

Re: dm-crypt/LUKS performance

[Henrique de Moraes Holschuh]

On Sun, 16 Nov 2014, David Fuchs wrote:
> I am setting up a system with an Intel octo-core Avoton, which has AES-NI
> support. After doing some crude benchmarking tests with dd, I am surprised
> about the huge performance penalty that full-disk encryption apparently has
> on read/write throughput.

You need to use a recent kernel that can run dm-crypt in parallel (and it
needs to be compiled with that option enabled as well.  I don't know if
Debian's 3.16 is compiled like that).  That information is missing from your
report.

> The system will be used as a home file server, and the results with drive
> encryption are still acceptable - but I'm still curious if they are to be
> expected, or if there is an obvious culprit for the performance hit. Is it
> possible that I'm not using the hardware AES?

Check in /proc/crypto whether aes-asm is listed, and whether it has a higher
priority than aes-generic.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141117132415.gc14...@khazad-dum.debian.net

Re: Embedded with systemd

[Paul H]

On 17/11/14 21:14, Jeremiah Foster wrote:
>> This is a very onerous requirement in the embedded world. There are many
>> embedded platforms sold today that only have 2.6.X BSPs.
> But I highly doubt those devices have modern userlands.

Which is why we (emdebian users) have ditched the job of maintaining the 
hardware vendor's half-hearted OpenEmbedded build and switched to simply using 
Debian multistrap & friends in the first place, right? :-)

>> This change will probably hit me the hardest and for me it really cuts
>> into what linux means. It used to be that I could run the same userspace
>> on my tiny embedded device, my desktop or on the server --- the only
>> difference being the kernel.

I too posted on this topic recently. A lot of boards, from not-so-obscure 
vendors, not to mention silicon for that matter is still being sold and 
included into new systems today which can barely run kernel 3.4 let alone 3.7.

I (also) don't think systemd is a wrong choice for Debian, so please don't 
misread any perceived frustrations of mine as being "anti-systemd". I think the 
reality is that those of us stuck supporting systems trapped on old kernels are 
going to suffer for a number of years until these devices are (very slowly!) 
retired and replaced with solutions containing SoCs from vendors who have 
finally figured out a sustainable business model that somehow includes proper 
ongoing kernel support.

My plan is that if I find myself depending on packages which no longer work 
under sysvinit-core, I'll rebuild those packages for myself as needed (and 
share the results, if that's helpful): I have to do this already now anyway, 
for example to use build options which make more sense for a given target, or 
to make my own -nox (headless) versions of stuff that would otherwise drag in 
200MiB+ of GTK/Qt dependencies.

> I find it unlikely that you'd be able to run Jessie on your desktop and
> Jessie on your device, at least, not without a little bit of work. I think

That's exactly what I do (and I assume other emdebian users too). Even if it 
took me a week or two to get my build scripts going, and a bit
more to tie it all into my CI and release management infrastructure it's still 
far more enjoyable, less error-prone and a lot less effort than
pushing a pile of rotting bitbake recipes uphill. xapt and dpkg-cross tools are 
truly fantastic (not to mention the rest of debian, like
debhelper). Especially for those of us maintaining packages which need to run 
in a bunch of different environments (not just embedded).

>> --
>> Embedded with systemd: systemd and realtime
>>
>> Given the existence of
>> (
>> http://www.freedesktop.org/wiki/Software/systemd/MyServiceCantGetRealtime/
>> ),
>> it seems that realtime and systemd is problematic. Has anyone tried the
>> workarounds mentioned with a PREEMPT_RT kernel? How did it go?

It is my intention to make the |ControlGroup=cpu:/| approach work; I have been 
maintaining a systemd rootfs for one of my targets but haven't quite found the 
time to investigate this fully.

Cheers

--
Paul


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1416230073.34519.yahoomailba...@web162606.mail.bf1.yahoo.com

Re: Joey Hess is out?

[Nate Bargmann]

* On 2014 17 Nov 06:01 -0600, Eduard Bloch wrote:
> Since systemd hatters usually fail on the second task, the rhetorical
> arsenal is chosen accordingly (ad-hominem, trolling, misquoting, ...).

Here is the crux of the problem in these discussions and that is the use
of "haters" as an ad hominem as part of the shaming language directed at
those with concerns.  It matters not who started it, but when one of the
primary developers of systemd also engages in using this language to
describe those who do have legitimate concerns, the discussion descends
quickly into a non-productive direction especially when others follow
his lead as being somehow acceptable.

Personally, I do not "hate" systemd.  While I have some concerns, I have
been monitoring these threads for any technical tidbits and I've been
using it to gain familiarity with what it offers and how to work with
it.  Unlike others, I do not have systems that are in an enterprise
situation as mine are simply home desktops so my paycheck will not be
impacted by the adoption of it.  Despite that, I will not minimize or
dismiss the concerns of others.

- Nate

-- 

"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."

Ham radio, Linux, bikes, and more: http://www.n0nb.us


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141117134648.ga22...@n0nb.us

Web site conformance and various browsers

[songbird]

  sometimes i have issues with a website and i cannot
tell if it is a problem with the browser or a problem
with the website.  obviously i am not a website 
developer so this sort of issue isn't clear where i
need to poke at things more...

  are there any tools available which help sort that
out (like one that says "This page conforms to 
standards X and Y, but violates a for this part") etc.?

  most the time i use Iceweasel (most current versions
available in testing, sid or experimental) or Midori.
Midori seems to do better and I'm not sure why as i
thought that it used the same basic infrastructure as
Iceweasel.

  any web developers who struggle with this and if I'm
missing something obvious (like use a different browser
like Opera or ...)?

  thanks!


  songbird


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/apapjb-o62@id-306963.user.uni-berlin.de

Re: Joey Hess is out?

[Gian Uberto Lauri]

Martin Read writes:
 > Administrators of systemd-based systems who wish to turn off the binary 
 > log can, of course, simply add the line
 > 
 >  Storage=none

Happy to hear that Debian configuration is now sane.

-- 
 /\   ___Ubuntu: ancient
/___/\_|_|\_|__|___Gian Uberto Lauri_   African word
  //--\| | \|  |   Integralista GNUslamicomeaning "I can
\/ coltivatore diretto di software   not install
 già sistemista a tempo (altrui) perso...Debian"

Warning: gnome-config-daemon considered more dangerous than GOTO


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/21609.64996.528596.864...@mail.eng.it

Strange problem with samba share, maybe dns related

[Cyril Alberts]

Hello,

today I realized a strange bug (maybe there is a reason for it but I 
dont know):


All our employees have a directory/folder at our (wheezy-lts) server, 
which is for interchange. Everybody gets a folder with his name where 
anybody can put things in. It is connected to Windows Clients by the 
letter "Z:\". I generated a huge sum of pdfs which I want to share at 
the server. As I looked for them from a windows-client, I could hardly 
see anything in this folder despite I know that there are many folders 
with pdfs in its subdirectories. They are all recursive chmodded 777 and 
owner is me as samba user (me:me). Now there are people able to see, 
browse and use this documents, but not me as a windows user.
The strangest thing: If I take the IP instead of the NAME of the server 
- it works!


How is it possible, that a folder called via name is empty and via ip it 
is not?


Z:\pdf-> empty folder

\\SERVER\fileserver\Mitarbeiter\me\pdf\-> empty folder

\\192.168.178.123\\fileserver\Mitarbeiter\me\pdf\   -> 2308 Elements

ls -l gives drwxrwxrwx per subfolder and owner is me:me



Is this a DNS-based problem or whats going on here?

I cant explain it, please help!




Greetings

Cyril
--
AfU Agentur für Unternehmensnachrichten GmbH
Albacher Weg 11
35463 Fernwald
Deutschland

Telefon: 06404 66 18 56
Telefax: 06404 37 50
E-Mail: redakt...@afu.de
Internet: www.afu.de


Geschäftsführung:
Norbert Paulsen

Handelsregisternummer:
HRB Gießen 3160

Umsatzsteuer-Identifikationsnummer:
DE 194786071


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Archive: https://lists.debian.org/546a02fd.5060...@afu.de

systemd for administrators, printable version.

[Erwan David]

Is there a printable/epub/pdf version of systemd for administrators ?

20+ HTML pages is very difficult to read, just becaus it requires mouse 
movement.

Even one only HTML page would be better.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141117142921.gb19...@rail.eu.org

Re: Joey Hess is out?

[The Wanderer]

On 11/17/2014 at 08:21 AM, Martin Read wrote:

> On 17/11/14 12:25, Gian Uberto Lauri wrote:
> 
>> There were other poor design choices, it seems that Debian
>> maintainers have fixed some of them (i.e. renaming network
>> devices), other seems to be still there (binary logs...).
> 
> A default Debian jessie configuration has persistent text logs in
> /var/log written by rsyslog, and *volatile* binary logs in
> /run/log/journal written by systemd-journald. Removing the binary
> logs completely disables functionality of the systemd suite which an
> administrator familiar with systemd would expect to be present by
> default.

This is news to me, and mildly disturbing.

I recall having previously seen it stated, repeatedly, that Debian by
default does not store binary logs at all even when running under
systemd - that they exist only in memory, and that the actual log data
is stored only in text-log-file format via forwarding to rsyslog.

(Even this is still mildly concerning to some people, on the grounds
that it still places journald and its binary formats in a place between
"source of data being logged" and "text-format log file" where
previously there was nothing, but it's still probably a reasonable
compromise for most purposes.)

> Administrators of systemd-based systems who wish to turn off the
> binary log can, of course, simply add the line
> 
>   Storage=none
> 
> to the [Journal] section of /etc/systemd/journald.conf, at which
> point systemd-journald will simply forward all log entries directly
> to rsyslog without writing them to a binary file.

This appears to be exactly what I recall seeing stated - repeatedly,
including by trustworthy Debian developers - as how Debian already
behaves in its default systemd configuration. If that is not the case,
then there is even less reason for people who object to binary logs to
be comfortable with the new situation, even mitigated by being able to
turn this behavior on with the option you describe.

-- 
   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

Re: Joey Hess is out?

[Ansgar Burchardt]

On 11/17/2014 03:54 PM, The Wanderer wrote:
> On 11/17/2014 at 08:21 AM, Martin Read wrote:
>> A default Debian jessie configuration has persistent text logs in
>> /var/log written by rsyslog, and *volatile* binary logs in
>> /run/log/journal written by systemd-journald. Removing the binary
>> logs completely disables functionality of the systemd suite which an
>> administrator familiar with systemd would expect to be present by
>> default.
> 
> This is news to me, and mildly disturbing.
> 
> I recall having previously seen it stated, repeatedly, that Debian by
> default does not store binary logs at all even when running under
> systemd - that they exist only in memory, and that the actual log data
> is stored only in text-log-file format via forwarding to rsyslog.

That's exactly what the word volatile means: /run is a in-memory
filesystem, thus all files there only exist in memory.

For the default configuration in Debian this means that all log messages
are stored persistently in /var/log by rsyslog, and some recent log
messages are *also* kept in a volatile in-memory file by journald.

Ansgar


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/546a0e65.5070...@debian.org

Re: Joey Hess is out?

[Christian Seiler]

Am 2014-11-17 15:54, schrieb The Wanderer:

On 11/17/2014 at 08:21 AM, Martin Read wrote:


On 17/11/14 12:25, Gian Uberto Lauri wrote:


There were other poor design choices, it seems that Debian
maintainers have fixed some of them (i.e. renaming network
devices), other seems to be still there (binary logs...).


A default Debian jessie configuration has persistent text logs in
/var/log written by rsyslog, and *volatile* binary logs in
/run/log/journal written by systemd-journald. Removing the binary
logs completely disables functionality of the systemd suite which an
administrator familiar with systemd would expect to be present by
default.


This is news to me, and mildly disturbing.

I recall having previously seen it stated, repeatedly, that Debian by
default does not store binary logs at all even when running under
systemd - that they exist only in memory, and that the actual log 
data

is stored only in text-log-file format via forwarding to rsyslog.


Note: /run is a tmpfs, i.e. it's stored in memory.


Administrators of systemd-based systems who wish to turn off the
binary log can, of course, simply add the line

Storage=none

to the [Journal] section of /etc/systemd/journald.conf, at which
point systemd-journald will simply forward all log entries directly
to rsyslog without writing them to a binary file.


This appears to be exactly what I recall seeing stated - repeatedly,
including by trustworthy Debian developers - as how Debian already
behaves in its default systemd configuration. If that is not the 
case,
then there is even less reason for people who object to binary logs 
to
be comfortable with the new situation, even mitigated by being able 
to

turn this behavior on with the option you describe.


Note that 'systemctl status' won't include the last log lines of a 
given

service if journal has Storage=none set. That is an very, very useful
feature to have, which is why I guess the maintainers of systemd have 
it

activated by default.

What does not happen is that any binary logfile is stored on your hard
drive (well, maybe in swap space, but not in your filesystem), and on
next boot they will be completely reset again.

The only real difference between the default (use /run as storage) and
Storage=none is that you save a bit of RAM. Btw. you can configure how
much the journal will take, see journald.conf(5).

Christian


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Archive: https://lists.debian.org/24ba807a36bc11e67e6aa15147707...@iwakd.de

Re: Joey Hess is out?

[The Wanderer]

On 11/17/2014 at 10:06 AM, Christian Seiler wrote:

> Am 2014-11-17 15:54, schrieb The Wanderer:
> 
>> On 11/17/2014 at 08:21 AM, Martin Read wrote:

>>> A default Debian jessie configuration has persistent text logs
>>> in /var/log written by rsyslog, and *volatile* binary logs in 
>>> /run/log/journal written by systemd-journald. Removing the
>>> binary logs completely disables functionality of the systemd
>>> suite which an administrator familiar with systemd would expect
>>> to be present by default.
>> 
>> This is news to me, and mildly disturbing.
>> 
>> I recall having previously seen it stated, repeatedly, that Debian
>> by default does not store binary logs at all even when running
>> under systemd - that they exist only in memory, and that the actual
>> log data is stored only in text-log-file format via forwarding to
>> rsyslog.
> 
> Note: /run is a tmpfs, i.e. it's stored in memory.

That probably explains the seeming conflict between the statements, but
there's still a difference between data being "kept in memory" and
"written to a file which is stored in memory".

Part of what I found reassuring about the statements that Debian's
default systemd configuration stores the journal's binary logs only in
memory was the idea that it would not be (needing to) write the log data
separately to the binary format, or possibly even do some of the related
processing; it could just use the binary format in-memory (i.e. in its
own process space), and output only in the traditional text form.

If it actually does write the binary format to file, even in a tmpfs or
the like, then that eliminates a lot of what I found reassuring about
those reassurances.

-- 
   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

Re: Installing an Alternative Init?

[Reco]

 Hi.

On Sun, Nov 16, 2014 at 03:48:34PM +0100, Ludovic Meyer wrote:
> On Sat, Nov 15, 2014 at 09:41:23PM -0500, Miles Fidelman wrote:
> > As much as I dislike systemd, I'm not sure that it's a vendor
> > conspiracy to "control the Linux ecosystem."  Yes, redhat pays
> > Lennart Poettering's salary (among others).  But... I'm hard pressed
> > to see how turning a collection of free distros into functional
> > equivalent's of redhat, or increasing the resources applied to free
> > distros, is really to their benefit.  If anything, it would seem to
> > dilute the competitive advantage of paid RHEL.
> > 
> > Personally, I think it's more a matter of one, prima donna
> > developer, who has the advantage of a salary, who has a vision and
> > design philosophy that he's promoting in a very aggressive and
> > single minded way.  And he's very overt about it.  (Somebody posted
> > an email from Poettering last week saying, roughly, 'first we're
> > going to get kdbus into the kernel, then we're going to make udev
> > depend on it, and then everyone will have to eat systemd to get
> > udev.'  As I recall, the message closed with 'gentoo, be warned.')
> > 
> > I figure this is more a case of redhat management not wanting to
> > tick off valued prima donna, and maybe seeing what he's doing as a
> > contribution to the open source community (to date, redhat has been
> > pretty good about contributing to the community in lots of different
> > ways).  Still,  if I were in their shoes, I'd be trying to reign the
> > guys in. 
> 
> Why would the management of a external company care about what 
> happen in Debian ? 

Because Debian is upstream for several critical RHEL parts, such as
shadow (passwd, useradd and friends). And, curiously enough, systemd's
goal is to replace those parts (see "Revisiting How We Put Together Linux
Systems" at http://0pointer.net/blog ).
Apparently, management doesn't like to be left out of control :)

And of course, another distribution = testing a product for free.


> People keep wanting the project to be free of corporate influence, but 
> it seems that some wouldn't be against having a bit of corporate influence if 
> the
> influence was in the way they want..
> 
> > Given that RHEL's main selling points are enterprise
> > capabilities, quality control, and (for the government market)
> > security accreditation and lots of support, I'd much rather see
> > diversity and weak code spread across competing distributions.
> 
> Canonical was criticized for keeping their code for their ( mir, unity ),
> and Redhat would be criticized for not keeping the code only for them. 

No. RedHat is criticized for pushing their code to everyone and their
dog. And it started way before systemd (dbus, hal and pulseaudio to
name a few). At least Canonical keeps their 'innovations' to themselves
last time.


> I guess there is no good way for a company to make free software that
> change something in the core of existing ecosystem.

Take a look at IBM, Oracle and Novell, you may reconsider your statement.


Reco


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141117152923.GA15905@x101h

Re: Joey Hess is out?

[Christian Seiler]

Am 2014-11-17 16:15, schrieb The Wanderer:

Part of what I found reassuring about the statements that Debian's
default systemd configuration stores the journal's binary logs only 
in
memory was the idea that it would not be (needing to) write the log 
data
separately to the binary format, or possibly even do some of the 
related
processing; it could just use the binary format in-memory (i.e. in 
its

own process space), and output only in the traditional text form.


There is one reason to actually keep them in memory: so that consumers
(like 'systemctl status') can access the most recent log messages and 
do

some processing with that. Otherwise, there is no need to store this
data and you can just set Storage=none anyway.

Accessing the current journal works by reading in journal files in /run
(and /var if it exists) and processing them (there is a shared library
for doing so).

If journald only keeps stuff in its own process space, for other
processes to access them there would need to be some kind of IPC
mechanism for other processes to ask journald to get some logs, that
would involve quite a bit of complexity, a large additional codepath in
both journald and all the clients and thus a large surface for 
potential

bugs. With storing them in the same type of files in /run, the codepath
is the same, there is more testing for that codepath and the interface
is a lot easier: access control is just file permissions, scheduling is
done by the kernel, etc.

The alternative you propose is the thing that would be worrisome to me,
i.e. having a completely different, probably less-tested, way of
accessing this stuff, where journald itself (which forwards ALL 
messages

to syslog when using systemd) takes on an additional burden. That seems
to be a far worse idea to me, complexity-wise.

And if you say you don't want the features that access the stored logs,
then you can set Storage=none, because then you simply don't need it at 
all.


Christian


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Archive: https://lists.debian.org/7bfbd9899b4ea6da5254988dac3cb...@iwakd.de

udev memory problem when trying to plug a disk with corrupted partition table

[berenger . morel]

Hello.

I think most of my problem's description is in title, but here are some 
more informations.


I have a hard disk on which I tried a... quite unusual... procedure to 
install another OS. My try in this procedure [1] did not went well at 
all, but it's not the subject of this mail.
Now, fact is that the hard-disk partition table is no longer correct, 
and when I plug it (it is an USB HD) into a Debian system, it makes udev 
eating all my memory, and more.
The only way for me to have a chance to work with that drive plugged is 
to disable swap, because when the system swaps, all CPU is used to 
access hard-drive, and also to do:
_ echo 80 > /proc/sys/vm/overcommit_ratio #honestly, I'm a newbie in 
kernel stuff, but I think I should use 95% here, that would be more 
effective, considering that I think I'll use such configuration on all 
my systems, since most of my tools does not need more than few hundred 
MiB.
_ echo 2 > /proc/sys/vm/overcommit_memory #so, softwares which tries to 
take too much ram will know it or crash. Udev is crashing, I guess.


I think that udev crashes, instead of simply acknowledging that it 
can't handle the partitions of the device, because if I then try other 
operations involving it, they does not work.
Also, I have noticed on more recent systems (testing and backported 
kernel) that I can't even access the device with fdisk after all udev 
processes died. On current stable kernel, I can (which gave me the hope 
to be able to use that disk anew, someday).


The symptoms I were able to see, through various means, like reading 
what is printed on TTY1 when I plug it, or using fdisk on the computer 
which did not made the hardware disappear when udev crashed, is that a 
very huge list of partitions is detected, I suspect an infinite loop.



So, does anyone know how to make udev stopping gracefully to detect the 
full list of partitions, and restrict itself to real hardware? Also, I 
should probably report that bug, but how could I find more informations 
to provide, since I strongly doubt that it can be reproduced, and so 
fixed, without the "correct" partition table?



Fun facts:
_ my BIOS... erm, no, not a BIOS, just a crappy UEFI, is not able to 
boot when that disk is plugged. I never felt good with that UEFI things, 
now I think I have some interesting reason. I'll try that on a old 
computer, just to see if real BIOSes are able to handle damaged logic, 
but *correct hardware*.
_ windows XP is simply not able to see the disk, but it does not dies 
or eat all RAM. Well, that's a pretty damaged installation of XP anyway, 
so not really relevant. And this OS is obsolete anyway.


1: for the curious ones, here is what I tried:
create a virtualbox machine
add it a vmdk which were linked to /dev/sdb (yes, sdb, not sdb1, or 
sdb2: the whole extern disk)

booting the VM on a netBSD's iso
having a very bad feeling when seeing that the extended partition was 
recognized as unknown filesystem

feeling lucky and continuing
seeing that, finally, I was not lucky :)


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Archive: 
https://lists.debian.org/2221850cae78d8b6eab1bbcf02ae3...@neutralite.org

Re: Web site conformance and various browsers

[Diogene Laerce]

Hi,

On 11/17/2014 02:45 PM, songbird wrote:
>   sometimes i have issues with a website and i cannot
> tell if it is a problem with the browser or a problem
> with the website.  obviously i am not a website 
> developer so this sort of issue isn't clear where i
> need to poke at things more...
>
>   are there any tools available which help sort that
> out (like one that says "This page conforms to 
> standards X and Y, but violates a for this part") etc.?
>
>   most the time i use Iceweasel (most current versions
> available in testing, sid or experimental) or Midori.
> Midori seems to do better and I'm not sure why as i
> thought that it used the same basic infrastructure as
> Iceweasel.
>
>   any web developers who struggle with this and if I'm
> missing something obvious (like use a different browser
> like Opera or ...)?

I think you're looking for this :

http://validator.w3.org/

or this for more inquiries:

http://www.softwareqatest.com/qatweb1.html

Best regards,

-- 
“One original thought is worth a thousand mindless quotings.”
“Le vrai n'est pas plus sûr que le probable.”

  Diogene Laerce




signature.asc
Description: OpenPGP digital signature

Re: Web site conformance and various browsers

[golinux]

On Mon, 11/17/14, songbird  wrote:

 Subject: Web site conformance and various browsers
 To: debian-user@lists.debian.org
 Date: Monday, November 17, 2014, 7:45 AM

  sometimes i have issues with a website and i cannot
tell if it is a problem with the browser or a problem
with the website.  obviously i am not a website
developer so this sort of issue isn't clear where i
need to poke at things more...

  are there any tools available which help sort that
out (like one that says "This page conforms to
standards X and Y, but violates a for this part") etc.?

  most the time i use Iceweasel (most current versions
available in testing, sid or experimental) or Midori.
Midori seems to do better and I'm not sure why as i
thought that it used the same basic infrastructure as
Iceweasel.

  any web developers who struggle with this and if I'm
missing something obvious (like use a different browser
like Opera or ...)?

  thanks!

  songbird

 

If the page is compliant with http://validator.w3.org/ standards there 
shouldn't be a problem with proper display.  Could also be an addon or 
about:config setting set by you causing problems.



--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Archive: https://lists.debian.org/a538394b85173ad46036dbb3e2ace...@riseup.net

apt-get update GPG error: Internal error: Good signature, but could not determine key fingerprint?!

[iain]

Hello all

  I am seeing a rather strange error. I have a wheezy VM which I am 
trying to update, but I get the above error on the main source and also 
on security source:


W: GPG error: http://security.debian.org wheezy/updates Release: 
Internal error: Good signature, but could not determine key 
fingerprint?!
W: GPG error: http://mirror.ox.ac.uk wheezy Release: Internal error: 
Good signature, but could not determine key fingerprint?!


Attempting to re-install gnupg and also debian-archive-keyring make no 
difference. Trying a new mirror also makes no difference. Same error.


Anyone seen this before, or perhaps knows more about GPG than me to help 
me in the right direction?


Other VM's update no questions asked

Cheers

Iain


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Archive: 
https://lists.debian.org/ccd1df5b979f2c87ec6d1c7b3ba4e...@thargoid.co.uk

Re: Web site conformance and various browsers

[berenger . morel]

Le 17.11.2014 14:45, songbird a écrit :

sometimes i have issues with a website and i cannot
tell if it is a problem with the browser or a problem
with the website.  obviously i am not a website
developer so this sort of issue isn't clear where i
need to poke at things more...

  are there any tools available which help sort that
out (like one that says "This page conforms to
standards X and Y, but violates a for this part") etc.?

  most the time i use Iceweasel (most current versions
available in testing, sid or experimental) or Midori.
Midori seems to do better and I'm not sure why as i
thought that it used the same basic infrastructure as
Iceweasel.

  any web developers who struggle with this and if I'm
missing something obvious (like use a different browser
like Opera or ...)?

  thanks!


  songbird


The problem with website compatibility can come from lot of problems:
_ I'm not sure that HTML5 is fully supported by all upstream engines 
(see below)
_ it will depends on a browser's configuration, especially about 
JavaScript (JS) because a huge quantity of websites are... hum... just 
bloated with that kind of crap. So, plug-ins like adware, or 
configuration which disables JS can avoid having the same behavior.  You 
can have the same kind of problems with cookies (accepting only a site's 
cookies avoid things like hotmail to work, and I've seen other ones).
_ sites will often voluntarily try to behave differently depending on 
the browser, in a good start intent, but hell is made of such good 
intents...

_ sites will sometimes employ specific things of a browser.

About the last point, if it is made correctly, it might not be detected 
by stuff like w3c's validator.


Otherwise, just for your information:

The problem is not the browser, but the rendering engine behind it.
Firefox/iceweasel is based on gecko (and AFAIK it's the only gecko 
user), while midori, chrome, and a ton of other ones are based on webkit 
(to be really more accurate, chrome is based on blink, a fork of webkit. 
Hopefully this fork might help to not see a new kind of IE era, but I'm 
pessimistic on that, without real reasons).
Even recent opera (starting to version >= 13) versions are based on 
webkit, so we can currently see more or less 3 major competitors:

_ IE
_ webkit/blink (I have no idea about how much blink differs from 
webkit, but seriously, if there is only safari using webkit, webkit will 
just die)

_ gecko

PS: when I think about how crappy all of this is, and that I remember 
that many people said me that websites runs in the same way everywhere, 
I just laugh. I try to remember it everyday, since there is a rumor 
which says that laughing 5min per day is good for health, hehe



--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/704af6d0494f50cbf285eb235d565...@neutralite.org

Re: qemu-kvm problem - libvirtd won't start

[Gary Dale]

On 16/11/14 09:31 PM, Joel Roth wrote:

On Sun, Nov 16, 2014 at 08:52:30PM -0500, Gary Dale wrote:

On 16/11/14 06:39 PM, Joel Roth wrote:

Did you try starting the VMs directly using the qemu command?

Don't have qemu installed. virsh reports:

Maybe there is some connection (c.f. Subject:)
qemu isn't listed as a dependency of qemu-kvm and isn't installed when 
qemu-kvm is installed. I understand that qemu 1.3 supersedes qemu-kvm 
but Wheezy only has 1.1.2, so qemu-kvm is still preferred.


I've got it running now, but still have a problem. Virt-manager is not 
seeing my .xml files when it connects to the server. I 
can create new virtual machines importing the existing images but then 
windows thinks it's on different hardware and wants to revalidate. I 
tried copying the existing .xml file over the new one but that didn't 
fix the problem.


Any ideas?


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Archive: https://lists.debian.org/546a2829.9090...@torfree.net

Re: systemd for administrators, printable version.

[Brian]

On Mon 17 Nov 2014 at 15:29:21 +0100, Erwan David wrote:

> Is there a printable/epub/pdf version of systemd for administrators ?
> 
> 20+ HTML pages is very difficult to read, just becaus it requires mouse 
> movement.
> 
> Even one only HTML page would be better.

DIY. Save the pages to file, 1.pdf, 2.pdf etc, from the browser. Then

   gs -dBATCH -dNOPAUSE -q -sDEVICE=pdfwrite -sOutputFile=SFA.pdf 1.pdf 2.pdf 



-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/17112014163542.3805c1365...@desktop.copernicus.demon.co.uk

Re: apt-get update GPG error: Internal error: Good signature, but could not determine key fingerprint?!

[Ansgar Burchardt]

Hi,

On 11/17/2014 05:26 PM, i...@thargoid.co.uk wrote:
>   I am seeing a rather strange error. I have a wheezy VM which I am
> trying to update, but I get the above error on the main source and also
> on security source:
> 
> W: GPG error: http://security.debian.org wheezy/updates Release:
> Internal error: Good signature, but could not determine key fingerprint?!
> W: GPG error: http://mirror.ox.ac.uk wheezy Release: Internal error:
> Good signature, but could not determine key fingerprint?!

What does

  apt-get -o Debug::Acquire::gpgv=1 update

say?

Ansgar


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/546a2a1b.8050...@debian.org

Re: apt-get update GPG error: Internal error: Good signature, but could not determine key fingerprint?!

[iain]

On 2014-11-17 17:02, Ansgar Burchardt wrote:

Hi,

On 11/17/2014 05:26 PM, i...@thargoid.co.uk wrote:

  I am seeing a rather strange error. I have a wheezy VM which I am
trying to update, but I get the above error on the main source and 
also

on security source:

W: GPG error: http://security.debian.org wheezy/updates Release:
Internal error: Good signature, but could not determine key 
fingerprint?!

W: GPG error: http://mirror.ox.ac.uk wheezy Release: Internal error:
Good signature, but could not determine key fingerprint?!


What does

  apt-get -o Debug::Acquire::gpgv=1 update

say?


Hey:

Get:1 http://mirror.ox.ac.uk wheezy Release.gpg [1,655 B]
Hit http://mirror.ox.ac.uk wheezy Release
100% [Release gpgv 168 kB] [Waiting for headers]inside VerifyGetSigners
gpgv path: /usr/bin/gpgv
Keyring file: /etc/apt/trusted.gpg
Keyring path: /etc/apt/trusted.gpg.d/
Preparing to exec: /usr/bin/gpgv /usr/bin/gpgv --ignore-time-conflict 
--status-fd 3 --keyring 
/etc/apt/trusted.gpg.d/debian-archive-squeeze-stable.gpg --keyring 
/etc/apt/trusted.gpg.d/debian-archive-wheezy-stable.gpg --keyring 
/etc/apt/trusted.gpg.d/debian-archive-wheezy-automatic.gpg --keyring 
/etc/apt/trusted.gpg.d/debian-archive-jessie-stable.gpg --keyring 
/etc/apt/trusted.gpg.d/debian-archive-squeeze-automatic.gpg --keyring 
/etc/apt/trusted.gpg 
/var/lib/apt/lists/partial/mirror.ox.ac.uk_debian_dists_wheezy_Release.gpg 
/var/lib/apt/lists/mirror.ox.ac.uk_debian_dists_wheezy_Release

gpgv exited
Ign http://mirror.ox.ac.uk wheezy Release
Ign http://mirror.ox.ac.uk wheezy/main Sources/DiffIndex
Get:2 http://security.debian.org wheezy/updates Release.gpg [836 B]
Ign http://mirror.ox.ac.uk wheezy/non-free Sources/DiffIndex
Hit http://security.debian.org wheezy/updates Release
99% [Waiting for headers]inside VerifyGetSigners
Ign http://mirror.ox.ac.uk wheezy/contrib Sources/DiffIndex
99% [Release gpgv 102 kB] [Waiting for headers]gpgv path: /usr/bin/gpgv
Keyring file: /etc/apt/trusted.gpg
Keyring path: /etc/apt/trusted.gpg.d/
Preparing to exec: /usr/bin/gpgv /usr/bin/gpgv --ignore-time-conflict 
--status-fd 3 --keyring 
/etc/apt/trusted.gpg.d/debian-archive-squeeze-stable.gpg --keyring 
/etc/apt/trusted.gpg.d/debian-archive-wheezy-stable.gpg --keyring 
/etc/apt/trusted.gpg.d/debian-archive-wheezy-automatic.gpg --keyring 
/etc/apt/trusted.gpg.d/debian-archive-jessie-stable.gpg --keyring 
/etc/apt/trusted.gpg.d/debian-archive-squeeze-automatic.gpg --keyring 
/etc/apt/trusted.gpg 
/var/lib/apt/lists/partial/security.debian.org_dists_wheezy_updates_Release.gpg 
/var/lib/apt/lists/security.debian.org_dists_wheezy_updates_Release

gpgv exited
Ign http://security.debian.org wheezy/updates Release
Ign http://mirror.ox.ac.uk wheezy/main i386 Packages/DiffIndex
Ign http://mirror.ox.ac.uk wheezy/non-free i386 Packages/DiffIndex
Ign http://security.debian.org wheezy/updates/main Sources/DiffIndex
Ign http://mirror.ox.ac.uk wheezy/contrib i386 Packages/DiffIndex
Ign http://security.debian.org wheezy/updates/contrib Sources/DiffIndex
Hit http://mirror.ox.ac.uk wheezy/contrib Translation-en
Ign http://security.debian.org wheezy/updates/non-free Sources/DiffIndex
Hit http://mirror.ox.ac.uk wheezy/main Translation-en
Ign http://security.debian.org wheezy/updates/main i386 
Packages/DiffIndex

Hit http://mirror.ox.ac.uk wheezy/non-free Translation-en
Hit http://mirror.ox.ac.uk wheezy/main Sources
Ign http://security.debian.org wheezy/updates/contrib i386 
Packages/DiffIndex

Hit http://mirror.ox.ac.uk wheezy/non-free Sources
Ign http://security.debian.org wheezy/updates/non-free i386 
Packages/DiffIndex

Hit http://mirror.ox.ac.uk wheezy/contrib Sources
Hit http://mirror.ox.ac.uk wheezy/main i386 Packages
Hit http://mirror.ox.ac.uk wheezy/non-free i386 Packages
Hit http://security.debian.org wheezy/updates/contrib Translation-en
Hit http://mirror.ox.ac.uk wheezy/contrib i386 Packages
Hit http://security.debian.org wheezy/updates/main Translation-en
Hit http://security.debian.org wheezy/updates/non-free Translation-en
Hit http://security.debian.org wheezy/updates/main Sources
Ign http://mirror.ox.ac.uk wheezy/contrib Translation-en_GB
Hit http://security.debian.org wheezy/updates/contrib Sources
Ign http://mirror.ox.ac.uk wheezy/main Translation-en_GB
Ign http://mirror.ox.ac.uk wheezy/non-free Translation-en_GB
Hit http://security.debian.org wheezy/updates/non-free Sources
Hit http://security.debian.org wheezy/updates/main i386 Packages
Hit http://security.debian.org wheezy/updates/contrib i386 Packages
Hit http://security.debian.org wheezy/updates/non-free i386 Packages
Ign http://security.debian.org wheezy/updates/contrib Translation-en_GB
Ign http://security.debian.org wheezy/updates/main Translation-en_GB
Ign http://security.debian.org wheezy/updates/non-free Translation-en_GB
Fetched 2,491 B in 4s (539 B/s)
Reading package lists... Done
W: GPG error: http://mirror.ox.ac.uk wheezy Release: Internal error: 
Good signature, but could not determine key fingerpr

Re: udev memory problem when trying to plug a disk with corrupted partition table

[Henrique de Moraes Holschuh]

On Mon, 17 Nov 2014, berenger.mo...@neutralite.org wrote:
> Now, fact is that the hard-disk partition table is no longer
> correct, and when I plug it (it is an USB HD) into a Debian system,
> it makes udev eating all my memory, and more.

Please image the partition table so that someone can reproduce the issue and
fix it... looks like an useful test case :-)

> I think that udev crashes, instead of simply acknowledging that it

It is likely triggering a bug somewhere in the load of stuff we run when a
disk is hotplugged to create the links in /dev/by-uuid, etc.

I.e. maybe the bug is not in udev itself.

> So, does anyone know how to make udev stopping gracefully to detect
> the full list of partitions, and restrict itself to real hardware?

The kernel itself parses the partition table.  Did it output any error
messages?

> Also, I should probably report that bug, but how could I find more
> informations to provide, since I strongly doubt that it can be
> reproduced, and so fixed, without the "correct" partition table?

Indeed.  Either preserve enough of that partition table to be able to
reproduce the bug, or give up on it ever being found at the moment you
decide to clean up the disk to be able to use it :-(

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141117165515.gb24...@khazad-dum.debian.net

Re: dm-crypt/LUKS performance

[Tixy]

On Sun, 2014-11-16 at 18:56 -0800, David Christensen wrote:
> That SSD appears to have hardware encryption.  So, why dm-crypt?

So you can copy/backup/move disks and partitions without worrying about
whether you can get access to the result in the future? Because you
don't want to trust or rely on whatever black box lives inside the disk?

I'm not the OP, but that's the reason I use Linux software encryption
rather than that built into the SSD.

-- 
Tixy


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1416244765.1352.1.ca...@yxit.co.uk

Re: apt-get update GPG error: Internal error: Good signature, but could not determine key fingerprint?!

[iain]

On 2014-11-17 17:05, i...@thargoid.co.uk wrote:

On 2014-11-17 17:02, Ansgar Burchardt wrote:

Hi,

On 11/17/2014 05:26 PM, i...@thargoid.co.uk wrote:

  I am seeing a rather strange error. I have a wheezy VM which I am
trying to update, but I get the above error on the main source and 
also

on security source:

W: GPG error: http://security.debian.org wheezy/updates Release:
Internal error: Good signature, but could not determine key 
fingerprint?!

W: GPG error: http://mirror.ox.ac.uk wheezy Release: Internal error:
Good signature, but could not determine key fingerprint?!



 Digging further into the logs, it seems that gnupg was segfaulting:
Thanks for your help. Reboot (of the VM) has solved this issue.

Cheers

Iain



--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Archive: 
https://lists.debian.org/25ddcc4583ca17fcebf9796ecccb5...@thargoid.co.uk

Re: udev memory problem when trying to plug a disk with corrupted partition table

[berenger . morel]

Le 17.11.2014 17:55, Henrique de Moraes Holschuh a écrit :

On Mon, 17 Nov 2014, berenger.mo...@neutralite.org wrote:

Now, fact is that the hard-disk partition table is no longer
correct, and when I plug it (it is an USB HD) into a Debian system,
it makes udev eating all my memory, and more.


Please image the partition table so that someone can reproduce the 
issue and

fix it... looks like an useful test case :-)


I think that udev crashes, instead of simply acknowledging that it


It is likely triggering a bug somewhere in the load of stuff we run 
when a

disk is hotplugged to create the links in /dev/by-uuid, etc.

I.e. maybe the bug is not in udev itself.


So, does anyone know how to make udev stopping gracefully to detect
the full list of partitions, and restrict itself to real hardware?


The kernel itself parses the partition table.  Did it output any 
error

messages?


Also, I should probably report that bug, but how could I find more
informations to provide, since I strongly doubt that it can be
reproduced, and so fixed, without the "correct" partition table?


Indeed.  Either preserve enough of that partition table to be able to
reproduce the bug, or give up on it ever being found at the moment 
you

decide to clean up the disk to be able to use it :-(


I've already built an image of the disk, but it's a 500GB disk. I doubt 
you'll want to download it hehe.
So, what part of that disk should I extract, which could be usable and 
sharable? Partition table, of course, which is probably at disk's 
beginning, but how long might it be?



--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/d997408f450877b3ee228348b0ed9...@neutralite.org

Re: Web site conformance and various browsers

[songbird]

berenger.mo...@neutralite.org wrote:
...
> PS: when I think about how crappy all of this is, and that I remember 
> that many people said me that websites runs in the same way everywhere, 
> I just laugh. I try to remember it everyday, since there is a rumor 
> which says that laughing 5min per day is good for health, hehe

  :)  thanks!  and thanks to everyone else too.

  uhg!

  i've avoided this question for a while so far,
for good reasons and i can see they still apply.

  i'll send a note to the problem website support
desk and see if any thing will happen.  since i
do have free time here or there i'll also volunteer 
to help them test newer versions.


  songbird


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/6vopjb-fmd@id-306963.user.uni-berlin.de

Re: Installing an Alternative Init?

[Ludovic Meyer]

On Mon, Nov 17, 2014 at 06:29:24PM +0300, Reco wrote:
>  Hi.
> 
> On Sun, Nov 16, 2014 at 03:48:34PM +0100, Ludovic Meyer wrote:
> > On Sat, Nov 15, 2014 at 09:41:23PM -0500, Miles Fidelman wrote:
> > > As much as I dislike systemd, I'm not sure that it's a vendor
> > > conspiracy to "control the Linux ecosystem."  Yes, redhat pays
> > > Lennart Poettering's salary (among others).  But... I'm hard pressed
> > > to see how turning a collection of free distros into functional
> > > equivalent's of redhat, or increasing the resources applied to free
> > > distros, is really to their benefit.  If anything, it would seem to
> > > dilute the competitive advantage of paid RHEL.
> > > 
> > > Personally, I think it's more a matter of one, prima donna
> > > developer, who has the advantage of a salary, who has a vision and
> > > design philosophy that he's promoting in a very aggressive and
> > > single minded way.  And he's very overt about it.  (Somebody posted
> > > an email from Poettering last week saying, roughly, 'first we're
> > > going to get kdbus into the kernel, then we're going to make udev
> > > depend on it, and then everyone will have to eat systemd to get
> > > udev.'  As I recall, the message closed with 'gentoo, be warned.')
> > > 
> > > I figure this is more a case of redhat management not wanting to
> > > tick off valued prima donna, and maybe seeing what he's doing as a
> > > contribution to the open source community (to date, redhat has been
> > > pretty good about contributing to the community in lots of different
> > > ways).  Still,  if I were in their shoes, I'd be trying to reign the
> > > guys in. 
> > 
> > Why would the management of a external company care about what 
> > happen in Debian ? 
> 
> Because Debian is upstream for several critical RHEL parts, such as
> shadow (passwd, useradd and friends).

1 ( ie shadow-utils ) is not "several".
And by having a critical look at your affirmation, RH is paying a lot 
of upstreams contributors for several critical Debian part :
- glibc
- gcc
- util-linux-ng
- kernel
- udevd

to name a few. I could name a few non critical stuff, from gnome, openjdk.
So I am not sure that your point is valid. Given the size of Redhat, 
I also suspect that having someone working on shadow-utils wouldn't be a 
problem. Judging by 
SEC fillings, public information, there is around 6900 people. 1 more coder is
not a stretch at all.

> And, curiously enough, systemd's
> goal is to replace those parts (see "Revisiting How We Put Together Linux
> Systems" at http://0pointer.net/blog ).
> Apparently, management doesn't like to be left out of control :)

This is free software, there is no way to be left out of control.

That's the whole point of the movement, provided you can code of course.
A lot of people seems to totally forget that point.

> And of course, another distribution = testing a product for free.

I wonder how, since Debian is lagging so much behind that even 
RHEL 7 is released with systemd. I wonder even why they
still have jobs posting for QA people if all is needed is to have users of
others distributions.


> > People keep wanting the project to be free of corporate influence, but 
> > it seems that some wouldn't be against having a bit of corporate influence 
> > if the
> > influence was in the way they want..
> > 
> > > Given that RHEL's main selling points are enterprise
> > > capabilities, quality control, and (for the government market)
> > > security accreditation and lots of support, I'd much rather see
> > > diversity and weak code spread across competing distributions.
> > 
> > Canonical was criticized for keeping their code for their ( mir, unity ),
> > and Redhat would be criticized for not keeping the code only for them. 
> 
> No. RedHat is criticized for pushing their code to everyone and their
> dog.

People keep saying that, but none show no conclusive proof. Just stating
it doesn't make it true. And it doesn't resist simple inquiry such as:

"if they wanted to push it everywhere, why would it be non portable to 
BSD ?" 

We go back to criticize everything that happen, that's getting old.
And kinda poisonous, looking at the people leaving TC or Debian or 
maintainership.

> And it started way before systemd (dbus, hal and pulseaudio to
> name a few). At least Canonical keeps their 'innovations' to themselves
> last time.

So you agree with me. 
If you share, you are criticized, if you don't, you are criticized.
 
> 
> > I guess there is no good way for a company to make free software that
> > change something in the core of existing ecosystem.
> 
> Take a look at IBM, Oracle and Novell, you may reconsider your statement.

I fail to see what did they tried to change in the core ecosystem exactly.

Oracle is attacked by everyone for the stewardship leading to forks on mysql
and openoffice, among others. They even alienated their own community on 
solaris.

Novell was criticized for providing Mono, and providing software written in mono
f

no C-h i m emacs ??

[Harry Putnam]

[NOTE: Originally miss-posted on ... emacs.help]

,
| From: Harry Putnam 
| Subject: no C-h i m emacs ??
| Newsgroups: gmane.emacs.help
| To: help-gnu-em...@gnu.org
| Date: Mon, 17 Nov 2014 13:29:46 -0500 (2 minutes, 9 seconds ago)
| Message-ID: <87egt14r51@reader.local.lan>
`

With emacs24-lucid installed, I can find no info files for emacs-24

/usr/share/info   IXNEY for emacs

/usr/local/share/ IXNEY for info

So with all this installed:

aps emacs|grep ^i   
i   emacs-goodies-el- Miscellaneous add-ons for Emacs   
i A emacs24-bin-common  - GNU Emacs editor's shared, architecture de
i A emacs24-common  - GNU Emacs editor's shared, architecture in
i   emacs24-el  - GNU Emacs LISP (.el) files
i   emacs24-lucid   - GNU Emacs editor (with Lucid GUI support) 
i A emacsen-common  - Common facilities for all emacsen  

I still have no emacs-info files.

Checking them all with dpkg -L shows no main info/emacs installed.

/usr/share/info/dir has no entry for emacs other than:

* Emacs FAQ: (emacs-24/efaq).   Frequently Asked Questions about Emacs.
* Emacs-Goodies-el: (emacs-goodies-el).
* Emacs FAQ: (emacs-24/efaq).   Frequently Asked Questions about Emacs.
* Emacs-w3m: (emacs-w3m).   An Emacs interface to w3m
* Emacs-w3m-ja: (emacs-w3m-ja). An Emacs interface to w3m (Japanese)

So apparently I'm missing something here.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/871tp14qsw@reader.local.lan

Re: udev memory problem when trying to plug a disk with corrupted partition table

[Henrique de Moraes Holschuh]

On Mon, 17 Nov 2014, berenger.mo...@neutralite.org wrote:
> So, what part of that disk should I extract, which could be usable
> and sharable? Partition table, of course, which is probably at
> disk's beginning, but how long might it be?

That depends.  What kind of partition table?

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141117183207.ge24...@khazad-dum.debian.net

Re: Joey Hess is out?

[Eduard Bloch]

Hallo,
* Nate Bargmann [Mon, Nov 17 2014, 07:46:48AM]:
> > Since systemd hatters usually fail on the second task, the rhetorical
> > arsenal is chosen accordingly (ad-hominem, trolling, misquoting, ...).
> Here is the crux of the problem in these discussions and that is the use
> of "haters" as an ad hominem as part of the shaming language directed at
> those with concerns.  It matters not who started it, but when one of the

There is no offensive of discriminatory meaning implied; you have read
my definition and that's how I apply it. Not more, not less.

> primary developers of systemd also engages in using this language to
> describe those who do have legitimate concerns, the discussion descends
> quickly into a non-productive direction especially when others follow
> his lead as being somehow acceptable.

If the final outcome is simply pidgeonholing into "those with us" vs.
"those against us" then I agree. But for somebody not participating in
this stupid holly wars about systemd this argument sounds somehow
far-fetched.

Regards,
Eduard.

-- 
 alpha welche distro hast du eigentlich???
-- gefragt im Channel #debian.de


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20141117185804.ga9...@rotes76.wohnheim.uni-kl.de

Re: engineering management practices and systemd (Re: Installing an Alternative Init?)

[Ludovic Meyer]

On Sun, Nov 16, 2014 at 08:29:28PM -0500, Marty wrote:
> On 11/16/2014 03:32 PM, Ludovic Meyer wrote:
> >On Sun, Nov 16, 2014 at 01:05:08PM -0500, Marty wrote:
> 
> >>My point is that in a modular design nothing should be so entrenched
> >>as to be irreplaceable. Absence of an alternate should not normally
> >>indicate impossibility of an alternate, but some discussions I've
> >>read about logind, udev and dbus are enough to raise serious
> >>concerns.
> >
> >The problem is that, without any action, the difference between "nothing
> >can be replaced" and "it can be replaced" is purely theorical.
> 
> The problem is very real, but there seems to be no agreement about
> solutions, which by itself is evidence of a problem.

There is not even anyone keeping a list of the solution or even the 
problem. Even the basis are not done.

If you truly want to iterate on a solution, you should
start doing it and document it.

>   Now you
> >can discuss for years in theory,
> 
> In fact, people have been discussing this problem for years.

And how did it change anything ? It didn't. So what make you think that 
yet another year is gonna result in something ?

I do not want to be too critical, but that's the exact problem that the troll
in the Hobbit face, by discussing endless on how to cook the dwarfs, they 
get petrified.

And maybe the time to test and get something wrong, as itcan hardly be slower 
than discussing. The whole agile methodology.
 
>   if this doesn't result in any practical
> >outcome, you have just stresstested the mailling lists software.
> 
> Until there's a rough consensus and a clear way forward, I don't
> think many people will commit to specific solutions. There are also
> unknowns like kdbus, to further complicate the matter.

"Talk is cheap", as Linus said.
You seems to be in favor of design by comitee, but this doesn't seems to work
for now.

> >>People who just say, "write your own, it's all FOSS" are missing the
> >>point, I think. Debian is not one guy working in his mom's basement.
> >>It's one of the world's largest software projects. When Debian is
> >>stumped, because its best developers and upstreams are caught in the
> >>entanglement hairball, and see no clear way out, the it's clear case
> >>of *Houston we have a problem.*
> >
> >That's a interesting point, because with all those brillant minds,
> >a vast majority do not even seems to care about this
> >"entanglement hairball". Maybe it is time to admit you do not
> >know the whole details and accept that if developpers do not care,
> >then they are maybe right in doing so ?
> >
> >Especially since you have been unable to give any technical reasons
> >to why you do not want it, and how you would proceed.
> 
> For you, I would start by explaining the Unix Philosophy and how it
> is a critical aspect of Debian's design:
> 
> http://en.wikipedia.org/wiki/Unix_philosophy

That's not a technical reason.

> Then I would proceed to explain how various aspects of systemd
> conflict with this, causing said hairball. Finally, I would explain
> (to the best of my ability) how the entanglement issue precludes a
> quick resolution, and the delay does not indicate lack of interest.

And how would that be a technical reason ? If you disagree with the philosophy,
that's not a technical problem. That's just a opinion. Show a real technical 
issue,
not "here is the design decided 20 years ago and that was ignored by several 
others 
components". heck, even in 1989, people wrote "the unix hater handbook" to
explain how the philosophy is wrong. For example, the example of cat not being
following this design anymore. No one throw a fuse over it, despites being
here, documented and visible by all since more than 20 years.
 
And I know Debian has popularized the idea of "release when it is ready", but 
that's 
also the exact definition of vaporware. And people do not even have a estimation
of the work. Not knowing what solution to choose do not preclude from saying 
the time one of them would take. In fact, it would even help to choose.
 
> >In fact, a quick google check would even give you the required
> >knowledge of why it is better to link :
> >http://spootnik.org/entries/2014/11/09_pid-tracking-in-modern-init-systems.html
> >
> >You can compare the code with "link to systemd library" vs "cut and
> >paste in every source code". As a exercise, you can
> >surely add "use dlopen()" and see which one is simpler and easier to maintain
> >in the long term.
> >
> >Then it will be your turn to explain why it is better to cut and paste or
> >link statically the library, or why it is better to have to patch every 
> >upstream
> >to use dlopen().
> 
> Not sure how we went from entanglement issues to PID tracking, but
> granting your point, it still doesn't explain how we arrive at kdb,
> console and qcodes in PID 1. :)

Because the blog post say how and why stuff requires to be linked with systemd. 
As you didn't
explain what you mean by hairballs ( ie, what re

Re: systemd for administrators, printable version.

[Erwan David]

Le 17/11/2014 17:39, Brian a écrit :
> On Mon 17 Nov 2014 at 15:29:21 +0100, Erwan David wrote:
>
>> Is there a printable/epub/pdf version of systemd for administrators ?
>>
>> 20+ HTML pages is very difficult to read, just becaus it requires mouse 
>> movement.
>>
>> Even one only HTML page would be better.
> DIY. Save the pages to file, 1.pdf, 2.pdf etc, from the browser. Then
>
>gs -dBATCH -dNOPAUSE -q -sDEVICE=pdfwrite -sOutputFile=SFA.pdf 1.pdf 2.pdf 
> 
>
>

Which would (in addition to being tedious) do an ugly job because of web
pages decorations and the fact that a webpage does not map well on a pdf
page.

And no need to be so contemptuous, I know such a "solution" exists, with
a very poor result.

It is strage how any question about systemd documentation inevitably
leads to such despise.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/546a4478.3050...@rail.eu.org

Re: no C-h i m emacs ??

[Don Armstrong]

On Mon, 17 Nov 2014, Harry Putnam wrote:
> With emacs24-lucid installed, I can find no info files for emacs-24

They're in the emacs24-common-non-dfsg package, which is in non-free.

-- 
Don Armstrong  http://www.donarmstrong.com

Maybe I did steal your heart
and I am such a perfect criminal
that you never noticed
 -- a softer world #481
http://www.asofterworld.com/index.php?id=481


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141117191732.gm4...@rzlab.ucr.edu

Re: systemd for administrators, printable version.

[Curt]

On 2014-11-17, Erwan David  wrote:
>
> Which would (in addition to being tedious) do an ugly job because of web
> pages decorations and the fact that a webpage does not map well on a pdf
> page.
>

In iceweasal printing to file turns out a nice-looking pdf in my
opinion.  


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/slrnm6kiih.2kj.cu...@einstein.electron.org

Re: Joey Hess is out?

[Miles Fidelman]

Eduard Bloch wrote:

Hallo,
* Nate Bargmann [Mon, Nov 17 2014, 07:46:48AM]:

Since systemd hatters usually fail on the second task, the rhetorical
arsenal is chosen accordingly (ad-hominem, trolling, misquoting, ...).

Here is the crux of the problem in these discussions and that is the use
of "haters" as an ad hominem as part of the shaming language directed at
those with concerns.  It matters not who started it, but when one of the

There is no offensive of discriminatory meaning implied; you have read
my definition and that's how I apply it. Not more, not less.


Well, ok, but then I've been known to refer to systemd proponents as 
"fanboys."


Miles Fidelman

--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Archive: https://lists.debian.org/546a4e25.8050...@meetinghouse.net

Re: init scripts [was: If Not Systemd, then What?]

[Andrei POPESCU]

On Lu, 17 nov 14, 07:29:00, Marty wrote:
> On 11/17/2014 01:13 AM, Andrei POPESCU wrote:
> >On Du, 16 nov 14, 13:22:54, Marty wrote:
> >>On 11/16/2014 11:50 AM, Miles Fidelman wrote:
> >>
> >>>In the later case, one just has to read:
> >>>http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities/
> >>>to get very, very scared
> >>
> >>Each one a bug as per Debian policy (sysvinit support). Looks like we have
> >>our work cut out for us.
> >
> >Would you please be so kind to point out which bullet point contradicts
> >which Policy section?
> 
> Don't they all by definition? Did I miss something?

Others have addressed those bullets one by one, explaining why they are 
not relevant to Debian. If you disagree you might want to reply to one 
of those posts with specific concerns.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
http://nuvreauspam.ro/gpg-transition.txt


signature.asc
Description: Digital signature

Re: systemd for administrators, printable version.

[Brian]

On Mon 17 Nov 2014 at 19:54:48 +0100, Erwan David wrote:

> Le 17/11/2014 17:39, Brian a écrit :
> > On Mon 17 Nov 2014 at 15:29:21 +0100, Erwan David wrote:
> >
> >> Is there a printable/epub/pdf version of systemd for administrators ?
> >>
> >> 20+ HTML pages is very difficult to read, just becaus it requires mouse 
> >> movement.
> >>
> >> Even one only HTML page would be better.
> > DIY. Save the pages to file, 1.pdf, 2.pdf etc, from the browser. Then
> >
> >gs -dBATCH -dNOPAUSE -q -sDEVICE=pdfwrite -sOutputFile=SFA.pdf 1.pdf 
> > 2.pdf 
> >
> >
> 
> Which would (in addition to being tedious) do an ugly job because of web
> pages decorations and the fact that a webpage does not map well on a pdf
> page.
> 
> And no need to be so contemptuous, I know such a "solution" exists, with
> a very poor result.
> 
> It is strage how any question about systemd documentation inevitably
> leads to such despise.

You were given a brilliant technical solution to a problem you had, one
that was slaved on all this afternoon and that many people would have
given their eye teeth for. :)

By all means don't employ it, but please try not to lace your reaction
with rhetoric because I, for one, am not interested in it.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/17112014193128.97efc7ba4...@desktop.copernicus.demon.co.uk

Re: init scripts [was: If Not Systemd, then What?]

[Miles Fidelman]

Given all the talk about not being able to influence upstream, it 
occurred to me to actually take a look at which of the major 
applications I rely on actually come with native systemd service 
scripts. I just went through the documentation, and in some cases, the 
source trees, for the following:

bind9
apache
sympa
mailman
mysql
mariadb
postgres
postfix
spamassassin
amavisd
clamav

Most come with sysvinit scripts, several come with their own startup 
scripts (e.g., apachectl) that get dropped into rc.local. Not a one 
comes with a native systemd service file (even though, when you search 
through the mysql documentation it tells you that oracle linux has 
switched to systemd).

So... with systemd, one has to:
- rely on packagers to generate systemd service files, and/or,
- rely on systemd's support for sysvinit scripts, which

In the later case, one just has to read:
http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities/
to get very, very scared

Among the implications of this, the old standby of installing software 
from upstream (bypassing packaging), has just gotten a lot riskier. 


Interesting, since I posted this, a bunch of people have jumped on my 
comment that relying on packagers and systemd to support sysvinit 
scripts seems increasingly risky, but...


Not a single person has commented on the observation that upstream 
developers, at least of core server applications, are thoroughly 
ignoring systemd.  So tell me again about all the great features that 
are in such demand, that systemd is a solution for?  Where's the 
demand?  Maybe upstream knows something that seems to elude systemd 
proponents?


Miles Fidelman





--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Archive: https://lists.debian.org/546a52e4.4050...@meetinghouse.net

Re: Re: dm-crypt/LUKS performance

[David Fuchs]

> Which Debian release? Kernel? Motherboard make/ model? CPU model? RAM
module(s)
> make/ model? SSD exact model? Defaults? Customizations?
My initial post was indeed a little light on details, so here's more info:
I'm dealing with a pristine installation of Wheezy. It is running on a
Supermicro A1SAi-2750F with 16GB of Kingston SODIMM RAM and a Intel c2750
Avoton octo-core. The drive I was referring to in my tests is a Samsung 840
PRO with 128 GB.
There's no load on the system what-so-ever other than the tests I'm running.

I measured read/write speeds by a) writing/reading directly to/from the
partition, b) cyrptsetup luksFormat + cryptsetup luksOpen and then writing
to the corresponging /dev/mapper/ device. No LVM or other
indirections involved as someone else suggested might have been the case.

> That SSD appears to have hardware encryption.  So, why dm-crypt?
Basically, what someone else already said - "hardware encryption" on SSDs
is not really useful or trustworthy.

> I assume those are non-default option values. Predicting and measuring
how each of those are
> affected by AES-NI would be a non-trivial task. You might want to try
some benchmarks using the
> defaults first, and then go from there.
I've tried a few options, mostly different key sizes, with similarly bad
performance penalties.

> Did you do a secure erase on the SSD prior to the write tests? SSD's can
write to fresh blocks faster
> than they can reclaim old blocks, erase them, and then write.
I didn't erase/trim anything from the drive. However, it is a brand new
drive that hasn't had more than a few GB written to it in its lifetime, so
I wouldn't think this is an issue. Also, I'd expect degrading SSD
performance to affect both encrypted and non-encrypted writes (and it
really shouldn't affect any of the reads).

> Your first write test is 256 MB, but all the other tests are 512 MB. Why
the unequal size?
As you point out, my tests were certainly not very systematic or scientific
and might even be completely non-representative of any real-world workload.
If I have the time, I will grab another spare drive, and run some more
thorough tests. As crude as my tests were, though, I'm still baffled by the
results.

Thanks,
- Dave.

mdadm Problem

[pascal]

 

Hello, 

Im experiencing a problem with my Software Raid. It has always running
without problems. Since this morning Im seeing this line in the
/var/log/syslog: 

DeviceDisappeared event detected on md device /dev/md0 

 ls -l /dev/md0
ls: cannot access /dev/md0: No such file or directory 

the /etc/mdadm/mdadm.conf: 

ARRAY /dev/md0 metadata=1.2 name=server:0
UUID=b9618cfa:bb8d5746:d9c0e036:c9b5e9ef 

cat /proc/mdstat is empty :-( 

The Strange is as following: 

 mdadm -Es
ARRAY /dev/md/0 metadata=1.2 UUID=b9618cfa:bb8d5746:d9c0e036:c9b5e9ef
name=server:0
ARRAY /dev/md/0 metadata=1.2 UUID=9b19060d:8e418739:fb555db6:8aa82b6c
name=server:0 

Its an RAID 1 with 2 disks /dev/sdc and /dev/sdd 

mdadm --examine /dev/sdd 

/dev/sdd:
 Magic : a92b4efc
 Version : 1.2
 Feature Map : 0x0
 Array UUID : b9618cfa:bb8d5746:d9c0e036:c9b5e9ef
 Name : server:0 (local to host server)
 Creation Time : Mon Feb 24 18:47:54 2014
 Raid Level : raid1
 Raid Devices : 2

 Avail Dev Size : 7813775024 (3725.90 GiB 4000.65 GB)
 Array Size : 3906887360 (3725.90 GiB 4000.65 GB)
 Used Dev Size : 7813774720 (3725.90 GiB 4000.65 GB)
 Data Offset : 262144 sectors
 Super Offset : 8 sectors
 State : clean
 Device UUID : afa9d760:f35c3b77:0d9c890c:e8c99faa

 Update Time : Sun Nov 16 19:27:35 2014
 Checksum : 9176e92f - correct
 Events : 198

 Device Role : Active device 1
 Array State : AA ('A' == active, '.' == missing)

madm --examine /dev/sdc 

mdadm --examine /dev/sdc
/dev/sdc:
 Magic : a92b4efc
 Version : 1.2
 Feature Map : 0x0
 Array UUID : b9618cfa:bb8d5746:d9c0e036:c9b5e9ef
 Name : server:0 (local to host server)
 Creation Time : Mon Feb 24 18:47:54 2014
 Raid Level : raid1
 Raid Devices : 2

 Avail Dev Size : 7813775024 (3725.90 GiB 4000.65 GB)
 Array Size : 3906887360 (3725.90 GiB 4000.65 GB)
 Used Dev Size : 7813774720 (3725.90 GiB 4000.65 GB)
 Data Offset : 262144 sectors
 Super Offset : 8 sectors
 State : clean
 Device UUID : 014728f4:c6f041aa:bbec4955:63af2212

 Update Time : Sun Nov 16 19:27:35 2014
 Checksum : 811507d - correct
 Events : 198

 Device Role : Active device 0
 Array State : AA ('A' == active, '.' == missing)

It seem like its somehow working, but the device /dev/mdo is gone..Can
someone tell me how I can reactivate the SW Raid ?? 

uname -a
Linux server 3.2.0-4-amd64 #1 SMP Debian 3.2.63-2+deb7u1 x86_64
GNU/Linux

cat /etc/debian_version 
7.7

Cheers, 

- Pascal 
 

Re: engineering management practices and systemd (Re: Installing an Alternative Init?)

[Erwan David]

Le 16/11/2014 02:13, Ludovic Meyer a écrit :
> On Sat, Nov 15, 2014 at 10:05:49PM +0100, Erwan David wrote:
>> Le 15/11/2014 20:24, Brian a écrit :
>>> On Sat 15 Nov 2014 at 11:37:14 -0500, Miles Fidelman wrote:
>>>
 Brian wrote:
> On Sat 15 Nov 2014 at 13:49:18 +0200, Andrei POPESCU wrote:
>
>> On Vi, 14 nov 14, 08:04:00, Marty wrote:
>>> By the same token systemd is a major waste with no real gain. It 
>>> duplicates
>>> equivalent modular alternatives, and also requires unnecessary effort to
>>> repair damage from excessive coupling.
>> I challenge you to come up with a configuration that duplicates
>> systemd's features with a combination of other software.
 That assumes that one needs or wants systemd's features.
>>> I rather think Andrei might not regard this as answering his challenge.
>>> (You also didn't say whether the link's picture made you chuckle :) ).
>>>
 For some (many?) of us, systemd represents no gain, and significant
 operational impact (time required to deal with changes).
>>> Fair enough, but working within the realities of a situation is also
>>> part of the deal. The deal for Jessie is systemd. This is not on a take
>>> it or leave basis; quite a lot of work has been put into ensuring the
>>> alternatives you want are there.
>>
>> It isq : when you have bugs like
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762623
>> Once said "oh it works with systemd", then no more activity on the bug,
>> nothing.
> I would suggest to read the url you post. There was a message from the
> maintainer saying "sorry, i tought I answered, I already reported it to
> udev, please give more information on the bug".
>
> Then indeed, you didn't followed up.
>  

Sorry, I was not asked more precision since 2 days ago, and could not
answer right away.
>> That means that practically, systemd is de facto compulsory. Not the
>> default, the only way allowed.
>>
>> So it is take or leave.
> I think this conclusion is likely wrong and hasty, given the lack of 
> activity is a result on waiting on more information from the reporter. 
>
Reporter cannot give info if not asked to...

Moreover even when systemd is not pid 1, it must be used through logind,
pam, etc...

I cannot help more since I do not find any doc on debugging systemd
components, for people not knowng systemd internals.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/546a5df3.40...@rail.eu.org

Re: engineering management practices and systemd (Re: Installing an Alternative Init?)

[Ludovic Meyer]

On Sun, Nov 16, 2014 at 04:09:52PM -0500, The Wanderer wrote:
> On 11/16/2014 at 02:51 PM, Ludovic Meyer wrote:
> 
> > On Sun, Nov 16, 2014 at 01:28:35PM -0500, The Wanderer wrote:
> 
> [about the Linux kernel developers]
> 
> >> They do, however, maintain their external interfaces - rigidly so,
> >> sometimes to what others might call the point of insanity. An 
> >> intentionally user-visible API from the Linux kernel will
> >> essentially never change, and if an exception to that is ever made,
> >> it will be announced *years* in advance. That is one reason why
> >> they try to be *VERY* careful to get the user-facing interface
> >> "right", at least on some basic level, before ever pulling it into
> >> a released kernel.
> >> 
> >> The kernel interfaces which kernel modules need to use are 
> >> kernel-internal interfaces.
> >> 
> >> The systemd interfaces described on the page you link to appear to
> >> be systemd-external interfaces.
> > 
> > I know the difference, and I know this is just some tradeoff, there
> > is advantages and disadvantages on doing that, and if I was cynical,
> > I would postulate that companies like redhat do push for that model
> > of internal/external interfaces in the kernel, because this give a
> > reason to take entreprise distributions. ( ie, SLES, RHEL do have a
> > stable promise API for each release like Windows do, because
> > customers do pay also for that )
> > 
> > My point is not that kernel or systemd devs are right or wrong. But
> > the point is that people who complain that systemd do not have a
> > internal interface yet forget that kernel do not have one since the
> > start and will not have in a near future.
> 
> Er... were people complaining that systemd does not have a stable
> internal interface?
>
> I thought (given the context of that linked-to page) that the complaint
> was that systemd does not have a stable *external* interface.

I think it does. The real question is
- is this interface sufficient
- is the boundary the one we agree on
 
> With possible room for dispute about what constitutes an "interface",
> what qualifies as "stable", and maybe even what counts as "internal" vs.
> "external"... but I didn't see anything that I recognized as being a
> complaint about systemd's internal interfaces.

Let's take the one about logind. What people complain is that
logind requires systemd as pid1, and the reason about this is because
logind requires the internal and non stable interface of systemd, otherwise,
someone would be able to run it with another init, provided it implement the 
stable
interface (this particular interface that do not exist).

Or people do complain they cannot replace or remove journald. Again, because 
there is no separation between the 2, because there is no documented
separation ie a external interface. I hope this clarify my point, but we seems 
to 
agree on this, if I read well what you said just after.
 
> No one is even trying to implement something outside of the systemd
> project that talks to systemd's internal interfaces directly, AFAIK -
> unless systemd-shim does, but I didn't think systemd-shim talked to
> systemd itself at all, just to other tools provided by the systemd
> project.
> 
> And if the interfaces which those tools use to talk to
> systemd-the-init-system are considered "internal" interfaces, which is a
> position for which an argument could be made, then that would simply
> bring up the argument that since those are separate tools the interfaces
> between them should be considered external to each tool. Whether or not
> that's a reasonable argument, and the extent to which it might be
> possible to treat those interfaces that way, could be a discussion worth
> having - but having it would require *getting* to that point first.
> 
> -- 
>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

-- 
l.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141117205859.gc31...@gmail.com

Re: Installing an Alternative Init?

[Reco]

On Mon, Nov 17, 2014 at 07:15:38PM +0100, Ludovic Meyer wrote:
> On Mon, Nov 17, 2014 at 06:29:24PM +0300, Reco wrote:
> >  Hi.
> > 
> > On Sun, Nov 16, 2014 at 03:48:34PM +0100, Ludovic Meyer wrote:
> > > On Sat, Nov 15, 2014 at 09:41:23PM -0500, Miles Fidelman wrote:
> > > > As much as I dislike systemd, I'm not sure that it's a vendor
> > > > conspiracy to "control the Linux ecosystem."  Yes, redhat pays
> > > > Lennart Poettering's salary (among others).  But... I'm hard pressed
> > > > to see how turning a collection of free distros into functional
> > > > equivalent's of redhat, or increasing the resources applied to free
> > > > distros, is really to their benefit.  If anything, it would seem to
> > > > dilute the competitive advantage of paid RHEL.
> > > > 
> > > > Personally, I think it's more a matter of one, prima donna
> > > > developer, who has the advantage of a salary, who has a vision and
> > > > design philosophy that he's promoting in a very aggressive and
> > > > single minded way.  And he's very overt about it.  (Somebody posted
> > > > an email from Poettering last week saying, roughly, 'first we're
> > > > going to get kdbus into the kernel, then we're going to make udev
> > > > depend on it, and then everyone will have to eat systemd to get
> > > > udev.'  As I recall, the message closed with 'gentoo, be warned.')
> > > > 
> > > > I figure this is more a case of redhat management not wanting to
> > > > tick off valued prima donna, and maybe seeing what he's doing as a
> > > > contribution to the open source community (to date, redhat has been
> > > > pretty good about contributing to the community in lots of different
> > > > ways).  Still,  if I were in their shoes, I'd be trying to reign the
> > > > guys in. 
> > > 
> > > Why would the management of a external company care about what 
> > > happen in Debian ? 
> > 
> > Because Debian is upstream for several critical RHEL parts, such as
> > shadow (passwd, useradd and friends).
> 
> 1 ( ie shadow-utils ) is not "several".

Google is your friend. Sorry, could not resist.


> And by having a critical look at your affirmation, RH is paying a lot 
> of upstreams contributors for several critical Debian part :
> - glibc

Not as of Wheezy. Wheezy uses eglibc.
And, while we're on topic of glibc - RedHat isn't writing new 'Modern'
libc to replace an old one. Yet.

Next few years we may see systemd-libc if things go as they're going
now.


> - gcc

A GNU project. Not a RedHat pet.


> - util-linux-ng

A kernel.org project. Not a RedHat pet again.


> - kernel

A joint project, controlled by Torvalds & co. RedHat is one of the few
who's playing a major role there, true. But that role was not enough to
push the most controversial features (kdbus, for example) into the
mainline.


> - udevd

Yup. You nailed that one if we consider latest udev development. It took
a merging into systemd to became that way.

Keep shooting, and you may score a couple of more hits ;)


> to name a few. I could name a few non critical stuff, from gnome, openjdk.

GNOME is can be considered to be controlled by RedHat indeed.
OpenJDK - please. Java is Oracle's turf, not a RedHat one. RedHat
invented their own Ceylon language just because of that fact.


> So I am not sure that your point is valid. Given the size of Redhat, 
> I also suspect that having someone working on shadow-utils wouldn't be a 
> problem. Judging by 
> SEC fillings, public information, there is around 6900 people.
> 1 more coder is not a stretch at all.

No doubt this number includes a small army of corporate drones, janitors
and security guys.
Do you have any estimate on a number of real developers in Red Hat?


> > And, curiously enough, systemd's
> > goal is to replace those parts (see "Revisiting How We Put Together Linux
> > Systems" at http://0pointer.net/blog ).
> > Apparently, management doesn't like to be left out of control :)
> 
> This is free software, there is no way to be left out of control.

For a fellow developer - sure, there's no way to be out of loop as long
as said developer plays by upstream rules.


> That's the whole point of the movement, provided you can code of course.
> A lot of people seems to totally forget that point.

But for a typical management drone - it seems we're both agree that
there's such a way. All it takes is inability to code.

So my point is simple. You mix a few really good developers and an army
of managers. That's a modern RedHat.

> 
> > And of course, another distribution = testing a product for free.
> 
> I wonder how, since Debian is lagging so much behind that even 
> RHEL 7 is released with systemd.

By reading users' bug reports. RHEL has a limited choice of prebuilt
software, therefore a limited number of usecases.

Besides, RHEL7 is supported until 2024 (IIRC). There's plenty room for
small improvements.


> I wonder even why they
> still have jobs posting for QA people if all is needed is to have users of
> others distributions.

I haven't 

Re: [03/05] Embedded with systemd: systemd and weird triggers

[Robert]

On 17/11/2014 08:42, Andrei POPESCU wrote:
>> with systemd I have to have
>>
>> waitforgps.sh
>> waitforgps.service (Exec=waitforgps.sh)
>> service.service (After=waitforgps.service)
>>
>> Is this really the best way?
> 
> Maybe ExecStartPre= would help? See systemd.service(5).

Oh yes, this is much better. I am a bit embarrassed that I missed this
the first time around.



-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/546a6781.50...@gmail.com

Re: mdadm Problem

[Gary Dale]

On 17/11/14 03:43 PM, pas...@denbekker.de wrote:


Hello,

Im experiencing a problem with my Software Raid. It has always running 
without problems. Since this morning Im seeing this line in the 
/var/log/syslog:


DeviceDisappeared event detected on md device /dev/md0

 ls -l /dev/md0
ls: cannot access /dev/md0: No such file or directory

the /etc/mdadm/mdadm.conf:

ARRAY /dev/md0 metadata=1.2 name=server:0 
UUID=b9618cfa:bb8d5746:d9c0e036:c9b5e9ef



cat /proc/mdstat is empty :-(

The Strange is as following:

 mdadm -Es
ARRAY /dev/md/0 metadata=1.2 UUID=b9618cfa:bb8d5746:d9c0e036:c9b5e9ef 
name=server:0
ARRAY /dev/md/0 metadata=1.2 UUID=9b19060d:8e418739:fb555db6:8aa82b6c 
name=server:0


Its an RAID 1 with 2 disks /dev/sdc and /dev/sdd

mdadm --examine /dev/sdd

/dev/sdd:
  Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
 Array UUID : b9618cfa:bb8d5746:d9c0e036:c9b5e9ef
   Name : server:0  (local to host server)
  Creation Time : Mon Feb 24 18:47:54 2014
 Raid Level : raid1
   Raid Devices : 2

 Avail Dev Size : 7813775024 (3725.90 GiB 4000.65 GB)
 Array Size : 3906887360 (3725.90 GiB 4000.65 GB)
  Used Dev Size : 7813774720 (3725.90 GiB 4000.65 GB)
Data Offset : 262144 sectors
   Super Offset : 8 sectors
  State : clean
Device UUID : afa9d760:f35c3b77:0d9c890c:e8c99faa

Update Time : Sun Nov 16 19:27:35 2014
   Checksum : 9176e92f - correct
 Events : 198


   Device Role : Active device 1
   Array State : AA ('A' == active, '.' == missing)

madm --examine /dev/sdc

mdadm --examine /dev/sdc
/dev/sdc:
  Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
 Array UUID : b9618cfa:bb8d5746:d9c0e036:c9b5e9ef
   Name : server:0  (local to host server)
  Creation Time : Mon Feb 24 18:47:54 2014
 Raid Level : raid1
   Raid Devices : 2

 Avail Dev Size : 7813775024 (3725.90 GiB 4000.65 GB)
 Array Size : 3906887360 (3725.90 GiB 4000.65 GB)
  Used Dev Size : 7813774720 (3725.90 GiB 4000.65 GB)
Data Offset : 262144 sectors
   Super Offset : 8 sectors
  State : clean
Device UUID : 014728f4:c6f041aa:bbec4955:63af2212

Update Time : Sun Nov 16 19:27:35 2014
   Checksum : 811507d - correct
 Events : 198


   Device Role : Active device 0
   Array State : AA ('A' == active, '.' == missing)

It seem like its somehow working, but the device /dev/mdo is gone..Can 
someone tell me how I can reactivate the SW Raid ??


uname -a
Linux server 3.2.0-4-amd64 #1 SMP Debian 3.2.63-2+deb7u1 x86_64 GNU/Linux

cat /etc/debian_version
7.7

Cheers,

- Pascal

Try to assemble the array with just one disk (list the other one as 
missing). If it comes up, then shut it down and assemble it with the 
other disk. If both seem to work, then assemble it with both disks.



--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Archive: https://lists.debian.org/546a6ccf.5060...@torfree.net

Re: engineering management practices and systemd (Re: Installing an Alternative Init?)

[Ludovic Meyer]

On Mon, Nov 17, 2014 at 08:44:06AM +0900, Joel Rees wrote:
> One thing at a time.
> 
> On Mon, Nov 17, 2014 at 1:23 AM, Ludovic Meyer  wrote:
> > [...]
> > Your definition of mainstream is strange.
> 
> What's strange about it? Do I need to provide a link to the dictionary
> for you for that? I assume not.
> 
> Given a community, there is a mainstream within that community.

Well, the point is "what is the community" exactly. Not the community in general
but the community you are refering.

As it could be "debian users", "all regular linux distro users" ( by
regular, I mean desktop/server ), or all linux users ( ie counting embedded 
appliance ? ), or do we count android as well ?

if we go just by the number, do we count users or
systems, especially in the light of amazon/yahoo/google/facebook 
server, who likely have combined more server than there is desktop users
of linux ( see a estimation in 2009 
http://www.datacenterknowledge.com/archives/2009/05/14/whos-got-the-most-web-servers/
 )
  
> We have a community of users of Linux-kernel OSses that provide,
> without excessive effort, command-line shells, full C compiler suites,
> administrator access to the device owner, etc.

So your definition is the community of people who are root on a linux system.
No problem, but that's not exactly clear. 
 
> (Sure, Android has No-root Debian and Terminal-IDE, but those are
> third-party apps and don't give true administrator access. The sdk is
> not something mainstream Android users can figure out without a lot of
> effort, and takes a separate machine. Thus, Android is outside the
> domain of discussion, and I shouldn't have had to explain why. Unless
> you think that Linux OSses should start limiting the device owner from
> doing things like adding users and changing the unit infrastructure,
> in which case, the reason we can't communicate is clear.)
> 
> Now, you note that Fedora claims in the range of a million users. Even
> if their estimates are an order of magnitude high, that's hundreds of
> thousands.
> 
> How can that not be mainstream?

Sure, so then Debian waited 3 years after the systemd hit the mainstream,
if you consider Fedora to be mainstream.

Therefore, your request of waiting was fullfilled. 

> Or are you under the misapprehension that there is only one
> mainstream? Fedora and Debian are the mainstreams of what most of us
> consider the Linux community. (Ubuntu being part of the greater Debian
> community and Cent being part of the greater Fedora community.)

You have been using the word as singular, so I was wondering which one you 
have been using. So based on the definition everybody will understand, Linux
itself not being mainstream
 
> Now, before you throw up any more quibbles, what I am talking about
> when I say mainstream users is those users who have not specifically
> chosen to be part of an experiment who are being dragged into an
> experiment.

The whole free software movement is mostly experiments. 
Experiment in the governance at the internet age, in term of software 
methodology, in term of research. There is people trying
new things. The kernel itself is always evolving, 
getting new features, etc.

> Except you'll now point out that Fedora is the "cutting edge" of Red
> Hat's stuff, which is ignoring the issue. And Fedora has rawhide, and
> Debian has sid, which is ignoring the issue.
> 
> sid is locked into the future of stable, just like Rawhide is locked
> into the future of Fedora. The release schedule does not allow for
> major changes to be unrolled easily. Anything that gets accepted into
> sid and passes into testing gets into stable, unless a lot of people
> get excited during the testing phase.
> 
> Now, is systemd a major change or isn't it?
> 
> If you ask Poettering when he wants to sell systemd, it's a MAJOR
> improvement. If you ask systemd proponents when they are sandbagging,
> NO! NO! It's NOT a major change. (Sorry about the shouting, I'm just
> describing how it looks to me. It does look like you guys are being
> emphatic.)

It depend on how you measure it. Number of impacted packages ? Number
of impacted users ? Change of the name of the software, versionning ?
Debian did switch to parralel init, was it a major change ( as it
required to fix all initscript for lsb )

Gnome 3, kde 4, grub2, was it major change ?
Xfree to xorg ? Glibc to eglibc ?
Linux 2.0 to 2.2 to 2.4 ?

Why none of this had a alternative ? 

There is lots of major change anytime and since the start of Debian.
And again, you keep using word as if it was ginving any meaning to what you 
propose
but there is no actionable items at all.

> If it's a major change, it needs more time, and, I'm asserting, the
> special handling of a temporary parallel fork.

You mean like it was the case in the previous stable, where systemd was
present but not as default ?

And you say "more time", how much more time ?
If that's not time based, what are the criteria, what are the bug that 
should be solved

What backport of gnuplot should I use in Jessie?

[Paul E Condon]

I'm currently using Jessie on my personal, home computer,
i.e. the one I use to ask for help on this list. I hope
to keep it running with only brief intervals of outage.

I also track some daily stock prices using gnuplot. I
want to keep that going, generating a new plot every
time I download new data. Of the several backports,
I think one is intended to be the survivor when Jessie
is actually released. Which one is that? Or is there
a dark horse that might be a better choise?

Also, a few words of reasons for your answer would be
helpful in assessing its value to me.

TIA

-- 
Paul E Condon   
pecon...@mesanetworks.net


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141117215436.ga28...@big.lan.gnu

Re: What backport of gnuplot should I use in Jessie?

[Jochen Spieker]

Paul E Condon:
> 
> I also track some daily stock prices using gnuplot. I
> want to keep that going, generating a new plot every
> time I download new data. Of the several backports,
> I think one is intended to be the survivor when Jessie
> is actually released. Which one is that? Or is there
> a dark horse that might be a better choise?

I have the impression you don't really know what a backport is in the
context of Debian.

A backport is a package of a recent software version built for a stable
Debian release. This is done because some people want or need recent
versions of some packages in Debian stable while Debian stable only
usually only receives minor upgrades.

Regarding your question: gnuplot is the same version in both testing
(jessie) and unstable (sid) so there isn't really much choice which
version to use on jessie:

$ apt-cache policy gnuplot
gnuplot:
  Installed: (none)
  Candidate: 4.6.6-1
  Version table:
 4.6.6-1 0
500 http://ftp2.de.debian.org/debian/ testing/main amd64 Packages
500 http://ftp2.de.debian.org/debian/ testing/main i386 Packages
500 http://ftp2.de.debian.org/debian/ sid/main amd64 Packages
500 http://ftp2.de.debian.org/debian/ sid/main i386 Packages

Since jessie is already frozen and this version does not have any
release-critical bugs I am quite confident that this is exactly the same
version that is going to be included when jessie becomes stable.

J.
-- 
When I get home from the supermarket I don't know what to do with all the
plastic.
[Agree]   [Disagree]
 


signature.asc
Description: Digital signature

Re: init scripts [was: If Not Systemd, then What?]

[Ludovic Meyer]

On Mon, Nov 17, 2014 at 02:56:20PM -0500, Miles Fidelman wrote:
> >Given all the talk about not being able to influence upstream, it
> >occurred to me to actually take a look at which of the major
> >applications I rely on actually come with native systemd service
> >scripts. I just went through the documentation, and in some cases,
> >the source trees, for the following:
> >bind9
> >apache
> >sympa
> >mailman
> >mysql
> >mariadb
> >postgres
> >postfix
> >spamassassin
> >amavisd
> >clamav
> >
> >Most come with sysvinit scripts, several come with their own
> >startup scripts (e.g., apachectl) that get dropped into rc.local.
> >Not a one comes with a native systemd service file (even though,
> >when you search through the mysql documentation it tells you that
> >oracle linux has switched to systemd).
> >So... with systemd, one has to:
> >- rely on packagers to generate systemd service files, and/or,
> >- rely on systemd's support for sysvinit scripts, which
> >
> >In the later case, one just has to read:
> >http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities/
> >to get very, very scared
> >
> >Among the implications of this, the old standby of installing
> >software from upstream (bypassing packaging), has just gotten a
> >lot riskier.
> 
> Interesting, since I posted this, a bunch of people have jumped on
> my comment that relying on packagers and systemd to support sysvinit
> scripts seems increasingly risky, but...
> 
> Not a single person has commented on the observation that upstream
> developers, at least of core server applications, are thoroughly
> ignoring systemd. 

No one commented because that's false. 
I also guess that you will use anyone response to later justify
"see, it try to force its way by forcing people to 
integrate with systemd". Either way, that's gonna be used
as a way to criticize.

> So tell me again about all the great features
> that are in such demand, that systemd is a solution for?

Most of the features do not requires anything upstream.
For example :
- being able to autorestart when crashed. Done on the distribution
side, and usually, that's a policy left to the admin, not upstream

- limiting the service with cgroups. Again, dependent on the 
installation, so left to the admin.

- limiting the access with namespaces. Again, depend on the setup,
so left for the admin.

- starting on demand, that can be achieved with either
xinetd protocol ( ie, reading stdin, writing stdout instead 
of a socket ), so no need here. 

- clean environment, that's not a feature that requires any
patch upstream

- journald integration, again, most software do use syslog, so no
special need to have something that work. 

There is a few feature that requires any upstream patches.
1) socket activation using the systemd way ( ie, not xinetd ) 
2) using journald to have more metadata that regular syslog
3) notifcation protocol and automated restart

>  Where's
> the demand?  Maybe upstream knows something that seems to elude
> systemd proponents?


Apache has support as a module in trunk :
https://httpd.apache.org/docs/trunk/mod/mod_systemd.html
There is support for journal too, see mod_journal.

And also see 
https://github.com/apache/httpd/commit/9e6638622be042eb00af5234a48049f7b5487a15#diff-92a02cae0d4feb2dfea5d1532ba1b977
for support directly in apache.


HAProxy do have some support for integration 
https://github.com/jvehent/haproxy/blob/master/src/haproxy-systemd-wrapper.c

Php-fpm does too :
http://thanatos.be/2014/04/12/php-fpm-ondemand.html

Nodejs has a module for nodejs application:
https://savanne.be/articles/deploying-node-js-with-systemd/

Docker has support for it in various place ( socket activation,
support in libcontainer ), and I could surely find lots of
core stuff and newer code that do have native support.

Dovecot have support for it, there is a service
file :
http://hg.dovecot.org/dovecot-2.2/file/8973329d1ceb/dovecot.service.in
There is support for it :
http://hg.dovecot.org/dovecot-2.2/file/8973329d1ceb/src/master/service-listen.c

There is the upstream of mdadm who even wrote 2 articles
on how to do it for nfs :
http://lwn.net/Articles/584175/
http://lwn.net/Articles/584176/

Older software are just integrated with xinetd do not need anything.
So for example, openssh already support socket 
activation like it does for xinetd.

Had you done your homework and spent 5 minutes double checking 
your affirmation, you would surely have found the same links 
as me. just search for HAVE_SYSTEMD on github, bitbucket, etc.

And to show there is demand, you can even look on modern configuration
tools and you can see they all support to configure systemd :
To give the 4 most spoken of at the moment :

- ansible 
https://github.com/ansible/ansible-modules-core/blob/devel/system/service.py#L396

- chef
http://www.rubydoc.info/github/opscode/chef/Chef/Provider/Service/Systemd

- puppet
https://github.com/puppetlabs/puppet/blob/master/lib/puppet/provider/service/systemd.rb

-

Re: [01/05] Embedded with systemd: systemd and SIL

[Robert]

On 17/11/2014 14:12, Jean-Christian de Rivaz wrote:
> Why did you think that localhost sockets activation is not
> deterministic ? When local process use localhost sockets, there is no
> transmission media with risk of packet loss, alteration, random
> latency, or reordering.

I was thinking more in the case where a service starts slow because a
packet on the network causes something else to start at the same time.

As you say, this shouldn't be a problem on localhost, and it seems
trivial to bind .socket units to localhost only. It also seems trivial
to disable socket activation entirely, so it looks like my fears were
unfounded.

Regards,


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/546a7ec9.2080...@gmail.com

Re: Embedded with systemd

[Robert]

On 17/11/2014 15:14, Paul H wrote:
> My plan is that if I find myself depending on packages which no
> longer work under sysvinit-core, I'll rebuild those packages for
> myself as needed (and share the results, if that's helpful): I have
> to do this already now anyway, for example to use build options which
> make more sense for a given target, or to make my own -nox (headless)
> versions of stuff that would otherwise drag in 200MiB+ of GTK/Qt
> dependencies.

I like this approach, and I think it is a good way to go. I guess the
only downside is that you end with a bunch of debuild recipes that are
functionally equivalent to a folder of full of .bb files :)

I think that in practice the amount of packages that will actually
depend on systemd being PID1 will stay relatively small. I have no
illogical problem with pulling in libsystemd and its friends.

>>> it seems that realtime and systemd is problematic. Has anyone
>>> tried the workarounds mentioned with a PREEMPT_RT kernel? How did
>>> it go?
> 
> It is my intention to make the |ControlGroup=cpu:/| approach work; I
> have been maintaining a systemd rootfs for one of my targets but
> haven't quite found the time to investigate this fully.

Let us know what you find.

Thanks,

Robert


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/546a824f.5000...@gmail.com

Re: init scripts [was: If Not Systemd, then What?]

[Miles Fidelman]

Ludovic Meyer wrote:

On Mon, Nov 17, 2014 at 02:56:20PM -0500, Miles Fidelman wrote:

Given all the talk about not being able to influence upstream, it
occurred to me to actually take a look at which of the major
applications I rely on actually come with native systemd service
scripts. I just went through the documentation, and in some cases,
the source trees, for the following:
bind9
apache
sympa
mailman
mysql
mariadb
postgres
postfix
spamassassin
amavisd
clamav

Most come with sysvinit scripts, several come with their own
startup scripts (e.g., apachectl) that get dropped into rc.local.
Not a one comes with a native systemd service file (even though,
when you search through the mysql documentation it tells you that
oracle linux has switched to systemd).
So... with systemd, one has to:
- rely on packagers to generate systemd service files, and/or,
- rely on systemd's support for sysvinit scripts, which

In the later case, one just has to read:
http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities/
to get very, very scared

Among the implications of this, the old standby of installing
software from upstream (bypassing packaging), has just gotten a
lot riskier.

Interesting, since I posted this, a bunch of people have jumped on
my comment that relying on packagers and systemd to support sysvinit
scripts seems increasingly risky, but...

Not a single person has commented on the observation that upstream
developers, at least of core server applications, are thoroughly
ignoring systemd.

No one commented because that's false.
I also guess that you will use anyone response to later justify
"see, it try to force its way by forcing people to
integrate with systemd". Either way, that's gonna be used
as a way to criticize.


False, how?  I went through the release notes, install instructions, 
support wikis, source trees, and did some googling for good measure, and 
all that I found re. systemd scripts for pretty much the most popular 
server-side programs were a few emails in the Arch users list about how 
to get these things working w/ systemd.





--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Archive: https://lists.debian.org/546a8617.8070...@meetinghouse.net

Re: Installing an Alternative Init?

[Ludovic Meyer]

On Tue, Nov 18, 2014 at 12:41:14AM +0300, Reco wrote:
> On Mon, Nov 17, 2014 at 07:15:38PM +0100, Ludovic Meyer wrote:
> > On Mon, Nov 17, 2014 at 06:29:24PM +0300, Reco wrote:
> > >  Hi.
> > > 
> > > On Sun, Nov 16, 2014 at 03:48:34PM +0100, Ludovic Meyer wrote:
> > > > On Sat, Nov 15, 2014 at 09:41:23PM -0500, Miles Fidelman wrote:
> > > > > As much as I dislike systemd, I'm not sure that it's a vendor
> > > > > conspiracy to "control the Linux ecosystem."  Yes, redhat pays
> > > > > Lennart Poettering's salary (among others).  But... I'm hard pressed
> > > > > to see how turning a collection of free distros into functional
> > > > > equivalent's of redhat, or increasing the resources applied to free
> > > > > distros, is really to their benefit.  If anything, it would seem to
> > > > > dilute the competitive advantage of paid RHEL.
> > > > > 
> > > > > Personally, I think it's more a matter of one, prima donna
> > > > > developer, who has the advantage of a salary, who has a vision and
> > > > > design philosophy that he's promoting in a very aggressive and
> > > > > single minded way.  And he's very overt about it.  (Somebody posted
> > > > > an email from Poettering last week saying, roughly, 'first we're
> > > > > going to get kdbus into the kernel, then we're going to make udev
> > > > > depend on it, and then everyone will have to eat systemd to get
> > > > > udev.'  As I recall, the message closed with 'gentoo, be warned.')
> > > > > 
> > > > > I figure this is more a case of redhat management not wanting to
> > > > > tick off valued prima donna, and maybe seeing what he's doing as a
> > > > > contribution to the open source community (to date, redhat has been
> > > > > pretty good about contributing to the community in lots of different
> > > > > ways).  Still,  if I were in their shoes, I'd be trying to reign the
> > > > > guys in. 
> > > > 
> > > > Why would the management of a external company care about what 
> > > > happen in Debian ? 
> > > 
> > > Because Debian is upstream for several critical RHEL parts, such as
> > > shadow (passwd, useradd and friends).
> > 
> > 1 ( ie shadow-utils ) is not "several".
> 
> Google is your friend. Sorry, could not resist.

I spend time to give concrete response. It would be polite to do the same.
 
> 
> > And by having a critical look at your affirmation, RH is paying a lot 
> > of upstreams contributors for several critical Debian part :
> > - glibc
> 
> Not as of Wheezy. Wheezy uses eglibc.
> And, while we're on topic of glibc - RedHat isn't writing new 'Modern'
> libc to replace an old one. Yet.

That doesn't change the fact that before, this was glibc, with the
infamous Ulrich Drepper, and that eglibc is now merged in glibc.
 
> Next few years we may see systemd-libc if things go as they're going
> now.
> 
> 
> > - gcc
> 
> A GNU project. Not a RedHat pet.

Read again :
"RH is paying a lot of upstreams contributors"
GCC was pushed historically by cygnus, and cygnus got 
acquired by RH.
If you look at the committers, you would see lots of
people from the company.
 
> 
> > - util-linux-ng
> 
> A kernel.org project. Not a RedHat pet again.

https://git.kernel.org/cgit/utils/util-linux/util-linux.git
Look who make release, look where he work. 

In fact, by that same reasoning, we can say that systemd is 
a freedesktop.org project, whic is not more 
controlled by RH than stuff hosted on kernel.org.

> 
> > - kernel
> 
> A joint project, controlled by Torvalds & co. RedHat is one of the few
> who's playing a major role there, true. But that role was not enough to
> push the most controversial features (kdbus, for example) into the
> mainline.

Kdbus is pushed by Greg Kroah-Hartman, who is employed by the Linux Foundation.
Before, he was working at Novell, and has no link with RH afaik. 


> > - udevd
> 
> Yup. You nailed that one if we consider latest udev development. It took
> a merging into systemd to became that way.

Mhh no.
http://blog.bofh.it/debian/id_442

Looking at the graph made by the debian maintener, we can see that 
more than 95% of the system have it installed since 2008.
 
> Keep shooting, and you may score a couple of more hits ;)

That's not a constest, I am not keeping score.

> 
> > to name a few. I could name a few non critical stuff, from gnome, openjdk.
> 
> GNOME is can be considered to be controlled by RedHat indeed.
> OpenJDK - please. Java is Oracle's turf, not a RedHat one. RedHat
> invented their own Ceylon language just because of that fact.

Indeed, I wanted to say icedtea. 
 
> 
> > So I am not sure that your point is valid. Given the size of Redhat, 
> > I also suspect that having someone working on shadow-utils wouldn't be a 
> > problem. Judging by 
> > SEC fillings, public information, there is around 6900 people.
> > 1 more coder is not a stretch at all.
> 
> No doubt this number includes a small army of corporate drones, janitors
> and security guys.
> Do you have any estimate on a number of real developers in Red Hat?

Re: init scripts [was: If Not Systemd, then What?]

[Ludovic Meyer]

On Mon, Nov 17, 2014 at 06:34:47PM -0500, Miles Fidelman wrote:
> Ludovic Meyer wrote:
> >On Mon, Nov 17, 2014 at 02:56:20PM -0500, Miles Fidelman wrote:
> >>>Given all the talk about not being able to influence upstream, it
> >>>occurred to me to actually take a look at which of the major
> >>>applications I rely on actually come with native systemd service
> >>>scripts. I just went through the documentation, and in some cases,
> >>>the source trees, for the following:
> >>>bind9
> >>>apache
> >>>sympa
> >>>mailman
> >>>mysql
> >>>mariadb
> >>>postgres
> >>>postfix
> >>>spamassassin
> >>>amavisd
> >>>clamav
> >>>
> >>>Most come with sysvinit scripts, several come with their own
> >>>startup scripts (e.g., apachectl) that get dropped into rc.local.
> >>>Not a one comes with a native systemd service file (even though,
> >>>when you search through the mysql documentation it tells you that
> >>>oracle linux has switched to systemd).
> >>>So... with systemd, one has to:
> >>>- rely on packagers to generate systemd service files, and/or,
> >>>- rely on systemd's support for sysvinit scripts, which
> >>>
> >>>In the later case, one just has to read:
> >>>http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities/
> >>>to get very, very scared
> >>>
> >>>Among the implications of this, the old standby of installing
> >>>software from upstream (bypassing packaging), has just gotten a
> >>>lot riskier.
> >>Interesting, since I posted this, a bunch of people have jumped on
> >>my comment that relying on packagers and systemd to support sysvinit
> >>scripts seems increasingly risky, but...
> >>
> >>Not a single person has commented on the observation that upstream
> >>developers, at least of core server applications, are thoroughly
> >>ignoring systemd.
> >No one commented because that's false.
> >I also guess that you will use anyone response to later justify
> >"see, it try to force its way by forcing people to
> >integrate with systemd". Either way, that's gonna be used
> >as a way to criticize.
> 
> False, how?

the whole part that you erased showed there is a few upstreams 
that care about integration with systemd at the source code level.

Ie, using features of systemd ( journald, socket activation ), 
rather than just providing a .service file.


> I went through the release notes, install instructions,
> support wikis, source trees, and did some googling for good measure,
> and all that I found re. systemd scripts for pretty much the most
> popular server-side programs were a few emails in the Arch users
> list about how to get these things working w/ systemd.

Now, if you really want to see how much do ship
a unit file, i suggest using proper tools, like :
http://code.openhub.net/

Look for ExecStart= 

Now, the problem is that the search engine do give 
around 16 millions of matches, because it also include
the result of various distribution, and I guess duplicate
and fork, so you would surely have to filter. But looking at the
200 seconds first results, this doesn't seems to be full 
of completely wrong results.

--
l.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141118001418.ga16...@gmail.com

Ati Radeon HD 7850 Problem on Debian 7 Stable

[João Luís Correia de Medeiros]

Dear sir or madam,
 
I have an Ati Radeon 7850, and have tried using in Debian Stable.
 
However, I am constantly greeted by X.org issues (in this case, it being unable 
to start, I'm guessing because of the kernel mod not being properly installed 
because I'm using an outdated kernel?)
 
So, in sum, I'm asking what way you recommend me installing or adding support 
for this card, as I'm unable to.
 
I've tried various sources and blogs explaining how to do it, but more often 
than not, I end up with a corrupted installation following their suggestions / 
explanations.
 
Same thing goes for my wireless card (I was unfortunate enough to get a realtek 
chip, it's an RTL8192 ), I install firmware-realtek from Debian ( And 
firmware-Linux-nonfree ) hoping it's all I need to get it up and running, but 
doing so, makes my ETH0 not respond to DHCP at all (I'm guessing it also needs 
a firmware blob to work, and is somehow being given the wrong one? )

Any help is appreciated! 
 
Thank you
 
Best Regards
 
JM
 
 
  

Re: init scripts [was: If Not Systemd, then What?]

[Miles Fidelman]

Ludovic Meyer wrote:

On Mon, Nov 17, 2014 at 06:34:47PM -0500, Miles Fidelman wrote:

Ludovic Meyer wrote:

On Mon, Nov 17, 2014 at 02:56:20PM -0500, Miles Fidelman wrote:

Given all the talk about not being able to influence upstream, it
occurred to me to actually take a look at which of the major
applications I rely on actually come with native systemd service
scripts. I just went through the documentation, and in some cases,
the source trees, for the following:
bind9
apache
sympa
mailman
mysql
mariadb
postgres
postfix
spamassassin
amavisd
clamav

Most come with sysvinit scripts, several come with their own
startup scripts (e.g., apachectl) that get dropped into rc.local.
Not a one comes with a native systemd service file (even though,
when you search through the mysql documentation it tells you that
oracle linux has switched to systemd).
So... with systemd, one has to:
- rely on packagers to generate systemd service files, and/or,
- rely on systemd's support for sysvinit scripts, which

In the later case, one just has to read:
http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities/
to get very, very scared

Among the implications of this, the old standby of installing
software from upstream (bypassing packaging), has just gotten a
lot riskier.

Interesting, since I posted this, a bunch of people have jumped on
my comment that relying on packagers and systemd to support sysvinit
scripts seems increasingly risky, but...

Not a single person has commented on the observation that upstream
developers, at least of core server applications, are thoroughly
ignoring systemd.

No one commented because that's false.
I also guess that you will use anyone response to later justify
"see, it try to force its way by forcing people to
integrate with systemd". Either way, that's gonna be used
as a way to criticize.

False, how?

the whole part that you erased showed there is a few upstreams
that care about integration with systemd at the source code level.

Ie, using features of systemd ( journald, socket activation ),
rather than just providing a .service file.


No... my point is that NONE of the major upstream projects that I use on 
our servers, bother to produce systemd service files, but all of them 
produce sysvinit files.


And I'll note that those are precisely some of the most used, most 
mature packages, that you'll find on practically every production server 
in the world (well, ok, I left out sendmail, but I just checked, and 
guess what, no systemd service file in upstream).


What do they know?

Miles Fidelman


--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Archive: https://lists.debian.org/546aa6c8.8030...@meetinghouse.net

Re: Valuing non-code contributions -- was Re: systemd - so much energy wasted in quarreling

[Chris Bannister]

On Mon, Nov 17, 2014 at 06:32:43AM -0500, Tanstaafl wrote:
> Some people think sex should only be for procreation...

Are you procreation or against it?

-- 
"If you're not careful, the newspapers will have you hating the people
who are being oppressed, and loving the people who are doing the 
oppressing." --- Malcolm X


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141118032039.GC7745@tal

Re: Ati Radeon HD 7850 Problem on Debian 7 Stable

[Joel Roth]

On Mon, Nov 17, 2014 at 07:49:51PM -0500, João Luís Correia de Medeiros wrote:
> Dear sir or madam,
> Same thing goes for my wireless card (I was unfortunate enough to get a 
> realtek chip, it's an RTL8192 ), I install firmware-realtek from Debian ( And 
> firmware-Linux-nonfree ) hoping it's all I need to get it up and running, but 
> doing so, makes my ETH0 not respond to DHCP at all (I'm guessing it also 
> needs a firmware blob to work, and is somehow being given the wrong one? )

Dear JM,

According to lspci, I have RTL8191SEvB Wireless LAN
Controller.  I've been using the rtlwifi and rtl8192se
drivers for years, with firmware-realtek.  The drivers are
not the greatest, but they don't interfere with eth0. 

I think the DHCP issue you have may be a different problem.

Regards,
 
> Any help is appreciated! 
>  
> Thank you
>  
> Best Regards
>  
> JM
>  
>  
> 

-- 
Joel Roth
  


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141118033817.GA3059@sprite

Re: engineering management practices and systemd (Re: Installing an Alternative Init?)

[Marty]

On 11/17/2014 01:54 PM, Ludovic Meyer wrote:

On Sun, Nov 16, 2014 at 08:29:28PM -0500, Marty wrote:

On 11/16/2014 03:32 PM, Ludovic Meyer wrote:
>On Sun, Nov 16, 2014 at 01:05:08PM -0500, Marty wrote:

>>My point is that in a modular design nothing should be so entrenched
>>as to be irreplaceable. Absence of an alternate should not normally
>>indicate impossibility of an alternate, but some discussions I've
>>read about logind, udev and dbus are enough to raise serious
>>concerns.
>
>The problem is that, without any action, the difference between "nothing
>can be replaced" and "it can be replaced" is purely theorical.

The problem is very real, but there seems to be no agreement about
solutions, which by itself is evidence of a problem.


There is not even anyone keeping a list of the solution or even the
problem. Even the basis are not done.

If you truly want to iterate on a solution, you should
start doing it and document it.


There *are* people doing it, e.g. systemd-shim, uselessd, nosh and 
eudev, the refracta team, and others. There are so many projects, it's 
hard to know where to join in, but I'm willing to help if I can.



  Now you
>can discuss for years in theory,

In fact, people have been discussing this problem for years.


And how did it change anything ? It didn't. So what make you think that
yet another year is gonna result in something ?


Right now Jessie is seems to have acceptable sysvinit support. The main 
concerns seem to be about Stretch, but that's 3-4 years away, so I think 
there's time to work on solutions.



I do not want to be too critical, but that's the exact problem that the troll
in the Hobbit face, by discussing endless on how to cook the dwarfs, they
get petrified.

And maybe the time to test and get something wrong, as itcan hardly be slower
than discussing. The whole agile methodology.


Keep in mind this is a mostly volunteer project, with a lot of people 
working in their spare time.



  if this doesn't result in any practical
>outcome, you have just stresstested the mailling lists software.

Until there's a rough consensus and a clear way forward, I don't
think many people will commit to specific solutions. There are also
unknowns like kdbus, to further complicate the matter.


"Talk is cheap", as Linus said.
You seems to be in favor of design by comitee, but this doesn't seems to work
for now.


I think small teams are the way to go in FOSS.


>>People who just say, "write your own, it's all FOSS" are missing the
>>point, I think. Debian is not one guy working in his mom's basement.
>>It's one of the world's largest software projects. When Debian is
>>stumped, because its best developers and upstreams are caught in the
>>entanglement hairball, and see no clear way out, the it's clear case
>>of *Houston we have a problem.*
>
>That's a interesting point, because with all those brillant minds,
>a vast majority do not even seems to care about this
>"entanglement hairball". Maybe it is time to admit you do not
>know the whole details and accept that if developpers do not care,
>then they are maybe right in doing so ?
>
>Especially since you have been unable to give any technical reasons
>to why you do not want it, and how you would proceed.

For you, I would start by explaining the Unix Philosophy and how it
is a critical aspect of Debian's design:

http://en.wikipedia.org/wiki/Unix_philosophy


That's not a technical reason.


It's a philosophy, and not even the dominant one in the software 
industry, but it is about technology and engineering, and part of the 
culture and design of Debian. I recognize that it also clashes with the 
"universal operating system" moniker, because the whole world is not 
Unix, so I see a place in Debian for monolithic OSs like systemd and 
Android clones, but I would have been more conservative about 
introducing it.



Then I would proceed to explain how various aspects of systemd
conflict with this, causing said hairball. Finally, I would explain
(to the best of my ability) how the entanglement issue precludes a
quick resolution, and the delay does not indicate lack of interest.


And how would that be a technical reason ? If you disagree with the philosophy,
that's not a technical problem. That's just a opinion. Show a real technical 
issue,
not "here is the design decided 20 years ago and that was ignored by several 
others
components".


Design philosophies have major technical implications. If Debian had 
started with Windows 3.1, I don't think the project would be where it is 
today. Loose package coupling works well with volunteer projects. For 
systemd to work in Debian it has to work within the existing modular 
framework, and I think it can be done, with difficulty.


 heck, even in 1989, people wrote "the unix hater handbook" to

explain how the philosophy is wrong. For example, the example of cat not being
following this design anymore. No one throw a fuse over it, despites being
here, documented and visible by all s

Re: init scripts [was: If Not Systemd, then What?]

[Scott Ferguson]

On 18/11/14 12:54, Miles Fidelman wrote:
>  I left out sendmail, but I just checked, and
> guess what, no systemd service file in upstream).

xy?

Did you try Google?

https://www.google.com/search?q=systemd+%2B%22sendmail.service%22&ie=utf-8&oe=utf-8&aq=t&&channel=sb

> 
> What do they know?
> 
> Miles Fidelman
> 
> 

e.g. sendmail.service:-
[Unit]
Description=Sendmail Mail Transport Agent
After=syslog.target network.target
[Service]
Environment=QUEUE=1h
EnvironmentFile=/etc/sysconfig/sendmail
Type=forking
ExecStart=/usr/sbin/sendmail -bd -q $QUEUE $SENDMAIL_OPTARG
[Install]
WantedBy=multi-user.target


Useful Refs:-
https://wiki.archlinux.org/index.php/sendmail#Start_on_boot
https://wiki.archlinux.org/index.php/Systemd/Timers
http://0pointer.de/blog/projects/systemd-for-admins-2.html
https://www.lisenet.com/2014/create-a-systemd-service-to-send-automatic-emails-when-arch-linux-restarts/


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/546ac051.5050...@gmail.com

Re: init scripts [was: If Not Systemd, then What?]

[Miles Fidelman]

Ummm those are NOT systemd scripts shipped by the upstream sendmail 
developers.  They ship sysvinit scripts, period.  Which is my point.  
Major upstream application developers do not seem to be jumping on 
systemd.  If anything, what I'm seeing are "oh sh&t, I guess we should 
develop systemd service units at some point."


Miles Fidelman

Scott Ferguson wrote:

On 18/11/14 12:54, Miles Fidelman wrote:

 I left out sendmail, but I just checked, and
guess what, no systemd service file in upstream).

xy?

Did you try Google?

https://www.google.com/search?q=systemd+%2B%22sendmail.service%22&ie=utf-8&oe=utf-8&aq=t&&channel=sb


What do they know?

Miles Fidelman



e.g. sendmail.service:-
[Unit]
Description=Sendmail Mail Transport Agent
After=syslog.target network.target
[Service]
Environment=QUEUE=1h
EnvironmentFile=/etc/sysconfig/sendmail
Type=forking
ExecStart=/usr/sbin/sendmail -bd -q $QUEUE $SENDMAIL_OPTARG
[Install]
WantedBy=multi-user.target


Useful Refs:-
https://wiki.archlinux.org/index.php/sendmail#Start_on_boot
https://wiki.archlinux.org/index.php/Systemd/Timers
http://0pointer.de/blog/projects/systemd-for-admins-2.html
https://www.lisenet.com/2014/create-a-systemd-service-to-send-automatic-emails-when-arch-linux-restarts/





--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Archive: https://lists.debian.org/546ac5c7.9010...@meetinghouse.net

Re: iceweasel does not execute perl scripts

[David Christensen]

On 11/16/2014 10:01 PM, kamaraju kusumanchi wrote:

Thanks for pointing out that Apache requires additional configuration.
I initially looked at
http://perl.apache.org/docs/2.0/user/intro/start_fast.html before
posting to the list. But it was difficult to follow since the website
tries to configure it differently than what seems to be Debian's way
of configuring things.
For example, it asks to add the following to httpd.conf
   LoadModule perl_module modules/mod_perl.so
But there is no httpd.conf in Debian. Instead I found this in Debian
root@hogwarts:/etc/apache2/mods-enabled# cat perl.load
LoadModule perl_module /usr/lib/apache2/modules/mod_perl.so
It talks about "Registry Scripts" without first telling what is
actually meant by a registry script. So it was all confusing to me.


Yes, there are differences between stock Apache and Debian Apache.  Take 
a look at 'apropos apache', a2enmod(8), a2dismod(8), and the 
/etc/apache2 tree.




I finally got it working through some trial and error. Here is my
configuration file
root@hogwarts:/etc/apache2/mods-enabled# cat perl.conf

 Alias /perl/ /home/rajulocal/public_html/perl/
 
 SetHandler perl-script
 PerlResponseHandler ModPerl::Registry
 PerlOptions +ParseHeaders
 Options +ExecCGI
 Order allow,deny
 Allow from all
 



My "That is not a valid mod_perl program" statement was based upon the 
traditional mod_perl handler registration/ callback approach discussed 
in the Eagle book:


http://shop.oreilly.com/product/9781565925670.do


I'd forgotten that mod_perl has a backwards compatibility/ forward 
migration feature which allows mod_perl to run Perl CGI scripts.  That's 
what you found.  Beware that in the past, there was the risk of bugs due 
to variable initialization assumptions common in CGI scripts.  Read your 
Apache documentation carefully if you're going to deploy this.




But no where in the docs
http://perl.apache.org/docs/2.0/user/config/config.html , this
directive is explained. Instead one is expected to refer to the docs
of old version ( http://perl.apache.org/docs/1.0/guide/config.html )
where these things are explained.
In the hindsight, all this looks pretty obvious. But it took me a long
time to figure it all out.


Congratulations on your determination and new-found knowledge! :-)



Ultimately, what I want to do is a very simple thing. May be I am
using the wrong tools here and making it more complicated than it
actually should be. Please point me in the right direction if this is
the case.
I have a perl script that takes a bunch of input parameters and spits
some output. I wanted to write a web interface for it where I get the
input from the user via "HTML forms" and pass it to the perl script,
then run it and show the output. Should I use javascript for this sort
of thing? If so, where does it fit in? Any pointers to good
documentation are appreciated.


Choosing a computer programming language is difficult.  If you're up to 
it, read "Structure and Interpretation of Computer Programs" and work as 
many exercises as you can stand:


http://mitpress.mit.edu/sicp/full-text/book/book.html

SICP is not for the faint of heart -- the difficulty ranges from hard to 
extreme.  But your programming language world-view and coding skills 
will be transformed.



Another consideration is how to deliver your program.  Web browser based 
applications, by design, have limited access to client-side data. 
Basically, the user has to manually enter, save, upload, download, etc., 
everything.  But, if they are standards-compliant, they can run in most 
any modern browser.  Native applications, including clients for client/ 
server applications, have far more capabilities (and risks).  But, you 
have to write one for each and every platform.  Thus, the appeal of 
Java/ JVM.



If you're going to let other people run programs on your computer, you 
need to deal with security -- especially if the computer is on the 
Internet.  This adds system and network design and administration.



David


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Archive: https://lists.debian.org/546ad07a.8020...@holgerdanske.com

What systemD lock-in leads to: An eventual lament. Please don't let it happen.

[SystemBlues]

Eventual lament (nylon string guitar):

I was recording one evening and at some point wandered into a lament.

http://youtu.be/PCJ-CWYoY9s 

I though many would feel the same, once comes in full lennart's reign.
Please don't let it happen.

(C) Gnu GPL v2


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1416286644.149611.192268673.59ddc...@webmail.messagingengine.com

Systemd Blues

[SystemBlues]

Blues song about systemd.

A friend of mine and I, we sat down one afternoon,
and there was something bothering us. I for one
couldn't get it out of my head. It was a feeling,
and it wasn't good.

It was the feeling of getting dicked down
by SystemD.

We put this feeling, the feeling we've never
felt before as proud white males in the greatest country
God every felt to allow to exist on this planet,
previously with nary a care in the world,
we put this new feeling to song.

That feeling was subjugation.

SystemD Blues:
http://youtu.be/y0aTqsl-vfU


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1416286791.150064.192269077.3dd81...@webmail.messagingengine.com

Empires only fall to an enemy within.

[SystemBlues]

Free software worked great for a time, it was a movement
on the upswing. Then it was noticed. Feminists appeared
and lobbied to have those of unclean mind excluded from 
the free/opensource movement, only those who believed
the correct thing were allowed to stay. Code nor contribution
mattered anymore. Believing in social justice for women,
self-mutilated men/women, and gays was what was now important.

No longer is it enough that a man has the ability and the will
to code and contribute. His balls must be in a purse.

Now SystemD has appeared aswell, and is tearing down what
once were stable, time tested, edifices. Its proponents
strangely also are of the pro-feminist / social justice warrior
camp.

Dissent is crushed.

Empires only fall to an enemy within.

http://youtu.be/y0aTqsl-vfU
-- 
  SystemBlues
  sdbl...@fastmail.com


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1416286851.150357.192269297.1c31b...@webmail.messagingengine.com

Re: What backport of gnuplot should I use in Jessie?

[kamaraju kusumanchi]

On Mon, Nov 17, 2014 at 4:56 PM, Paul E Condon
 wrote:
> I also track some daily stock prices using gnuplot. I
> want to keep that going, generating a new plot every
> time I download new data.

Jochen already answered your question about backports. But I am
curious about something. How are you pulling the stock prices? Keep in
mind that you have to account for corporate actions (ex:- dividends,
stock splits, ticker changes etc.,). Just wondering if you have any
experiences that you could share.

> Also, a few words of reasons for your answer would be
> helpful in assessing its value to me.

Even though gnuplot can produce beautiful plots it does not help much
in analyzing the data. You might be better off using a high level
language such as R, octave or Matlab to do the analysis. All these
programs come with good plotting capabilities.

Just my 2 cents...

thanks
raju
-- 
Kamaraju S Kusumanchi
http://malayamaarutham.blogspot.com/


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CABpbYad9g3Fs1coyW2L1GP+7DkHM4zbPO=oz9ngejtcenfd...@mail.gmail.com

Qt version of gnuplot strange message

[Paul E Condon]

The newer version of gnuplot is issuing a warning that I have never
seen before:

Qt: Session management error: Authentication Rejected, reason :
None of the authentication protocols specified are supported and
host-based authentication failed

Apparently Qt believes it has to 'authenticate' the data which I
am feeding to gnuplot. I had always thought that the authenticity
of the data was the responsibility of me, the human user, and not
something that a could possibly be done by an artificial intelligence.
Where can I read about this crazy new feature? and how I can disable
and silence it?

TIA
-- 
Paul E Condon   
pecon...@mesanetworks.net


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141118060341.ga30...@big.lan.gnu

Not this again

[golinux]

UGH!  Looks like Gregory Smith has returned with a new handle - 
SystemBlues. Does anybody read his swill?



--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Archive: https://lists.debian.org/b4e40d99450897148912c230f1fc8...@riseup.net

Re: systemd for administrators, printable version.

[Joerg Desch]

Am Mon, 17 Nov 2014 15:29:21 +0100 schrieb Erwan David:

> Is there a printable/epub/pdf version of systemd for administrators ?

http://www.bandwidthco.com/whitepapers/os/linux/systemd/systemd%20for%
20Administrators.pdf

Google leads me to this link... ;-)

I don't know the state of this document, but it seems to be the file you 
are looking for.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/m4ep45$eju$1...@ger.gmane.org

Re: Strange problem with samba share, maybe dns related

[Marko Randjelovic]

On Mon, 17 Nov 2014 15:15:25 +0100
Cyril Alberts  wrote:

> Hello,
> 
> today I realized a strange bug (maybe there is a reason for it but I 
> dont know):
> 
> All our employees have a directory/folder at our (wheezy-lts) server, 
> which is for interchange. Everybody gets a folder with his name where 
> anybody can put things in. It is connected to Windows Clients by the 
> letter "Z:\". I generated a huge sum of pdfs which I want to share at 
> the server. As I looked for them from a windows-client, I could hardly 
> see anything in this folder despite I know that there are many folders 
> with pdfs in its subdirectories. They are all recursive chmodded 777 and 
> owner is me as samba user (me:me). Now there are people able to see, 
> browse and use this documents, but not me as a windows user.
> The strangest thing: If I take the IP instead of the NAME of the server 
> - it works!
> 
> How is it possible, that a folder called via name is empty and via ip it 
> is not?
> 
> Z:\pdf-> empty folder
> 
> \\SERVER\fileserver\Mitarbeiter\me\pdf\-> empty folder
> 
> \\192.168.178.123\\fileserver\Mitarbeiter\me\pdf\   -> 2308 Elements
> 
> ls -l gives drwxrwxrwx per subfolder and owner is me:me
> 
> 
> 
> Is this a DNS-based problem or whats going on here?
> 
> I cant explain it, please help!

Hello Cyril

These options in smb.conf could make your problems:

dns proxy = no
name resolv order = 

Kind regards

-- 
http://markorandjelovic.hopto.org

One should not be afraid of humans.
Well, I am not afraid of humans, but of what is inhuman in them.
Ivo Andric, "Signs near the travel-road"


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141118075013.225e6...@eunet.rs

Картридер Realtek device 5287

[retaw]

Здравствуйте!

Модель ноутбука Acer Aspire v5-572g-73538g50akk. Какой модуль подойдет 
для картридера? Искал рецепты в гугле, но так и не понял какой лучше 
всего поставить: rts_bpp или с сайта realtek rts5229 (или еще один 
вариант rts_pstor тоже с сайта realtek). Может кто сталкивался?


lspci:

04:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. Device 
5287 (rev 01)


Заранее благодарю.


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Archive: https://lists.debian.org/7203d70f64c8a9a62025ccd0400f7...@ufamts.ru

Re: systemd for administrators, printable version.

[Erwan David]

On Tue, Nov 18, 2014 at 07:31:33AM CET, Joerg Desch  said:
> Am Mon, 17 Nov 2014 15:29:21 +0100 schrieb Erwan David:
> 
> > Is there a printable/epub/pdf version of systemd for administrators ?
> 
> http://www.bandwidthco.com/whitepapers/os/linux/systemd/systemd%20for%
> 20Administrators.pdf
> 
> Google leads me to this link... ;-)
> 
> I don't know the state of this document, but it seems to be the file you 
> are looking for.

Tanks, I download it.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141118070459.gc19...@rail.eu.org