Re: wayland in rawhide

[Steve Clark]

On 11/26/2015 06:32 AM, Ian Malone wrote:

On 25 November 2015 at 22:01, Adam Williamson
 wrote:

On Wed, 2015-11-25 at 15:40 -0500, Przemek Klosowski wrote:

On 11/25/2015 03:25 PM, drago01 wrote:

On Wed, Nov 25, 2015 at 9:17 PM, Adam Williamson
 wrote:

On Fri, 2015-11-20 at 14:34 +, Ian Malone wrote:

[1] Apparently middle mouse buttons are rare. I'm in an office

This seems an odd assertion [...]

Its not odd ... its plain wrong.


I think Ian meant to say that the mice WITHOUT middle button are rare.
The quote above continues on like this:

 I'm in an office surrounded by them and them only computers I've used 
without one for roughly the past decade are my old laptop

Am I right, Ian?

No.


Well, it was what I said. I was going to add that it would be possible
to check in the archives, but I can't actually find my original post
there. Not sure why this thread has woken up again.


The wiki page explaining the GNOME-on-Wayland approach to middle-button
paste - https://wiki.gnome.org/Initiatives/Wayland/PrimarySelection -
makes this claim as one of the reasons why it wasn't initially planned
for inclusion in Wayland:

"Additionally, reasons against keeping it:

 the middle click is a hard-to-discover easter egg
 there are few middle mouse buttons in the world"

Ian was, I think with reason, questioning the second of those. I was
pointing out that those are only a couple of *supplementary* reasons,
so it's not really worth spending much time disputing that assertion,
even though it does seem like an odd one. The primary reasons why
Wayland wasn't initially going to implement a PRIMARY selection
mechanism are given earlier in the page:


I was questioning those and a tone that's become very common:
1. This is obscure, only crusty old dinosaurs know about it and use
it. (I'm fairly sure I'm neither crusty or old.)
2. Not relevant any more because Y.

Throw these in to support any breakage you would like to introduce and
suddenly you're a breath of fresh air blowing all the old cruft away
and anyone who disagrees is stuck in the dark ages. Except in this
case they're trivially demonstrated as untrue (well documented, unlike
documenting all new features in blog posts and leaving them to rot,
hardware support widespread). So this feature is being re-introduced
because "many longterm X users have become reliant on this easter egg"
(still an easter egg) and it is, "to ease the transition for long-term

How can you say it is an "easter-egg"? It is clearly documented in the X Window 
system
documentation.

X users." (Who just can't cope with the modern world, so let's throw
them a bone.) They look like very little consideration was given.


"Among the arguments for eschewing the PRIMARY selection were:

 It makes it easy to unintentionally paste passwords, snippets of
private conversations and other non-public information,
 into online communication.
 security concerns with unexpected data stealing if the mere act of
selecting a text fragment makes it available to all running
applications"


That is a genuine concern, but compare it to having a clipboard of the
past N selections which most users are probably not aware of either.
It looks like they've come up with a scheme to tie it down.


and it goes on to propose that the primary selection should in fact be
implemented.

And turned off by default of course.

Actually, my main comment (snipped) was that the utility of having
separate buffers is not even discussed, and it is not actually clear
that this wont simply be reintroduced as an option to turn on a form
of auto-copy on select. Which the discussion of the signalling
mechanism involved and the "not just text" aspect seem to suggest it
might be.




--
Stephen Clark
*NetWolves Managed Services, LLC.*
Director of Technology
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: wayland in rawhide

[Steve Clark]

On 11/20/2015 09:34 AM, Ian Malone wrote:

On 12 November 2015 at 14:59, Ray Strode  wrote:

Hi,

On Thu, Nov 12, 2015 at 5:51 AM, Jared K. Smith
 wrote:

I've been testing Wayland myself since around the F22 time period, but
"middle click paste" and the occasional odd bug keep annoying me enough to
go back to X.  Can you elaborate on the plans for supporting middle click to
paste, or is it considered a relic of a bygone era and I should try to
unlearn?

Plans for middle-click paste are tracked here:

https://wiki.gnome.org/Initiatives/Wayland/PrimarySelection


This would actually be quite a productivity killer for me, not just
the lack of middle-button paste[1], but also removing a separate
copy-buffer. It is seriously useful to be able to carry around
multiple pieces of text, particularly if you're going to need to
keeping one and change the other (or working on two things at once).

[1] Apparently middle mouse buttons are rare. I'm in an office
surrounded by them and them only computers I've used without one for
roughly the past decade are my old laptop (now moved on, but had
emulated middle click, maybe the wayland developers were unaware of
this too), and other people's mac laptops, which have their own
'easter egg' combinations of one, two, three(?) finger clicks and
drags.


I just did a quick walk around our office of approximately 70 people and every 
mouse had 3 buttons.
As far as the middle button paste being an "easter-egg" it was documented in the "X 
Windows Systems User Guide"
on page 97 way back in 1990.


--
Stephen Clark
*NetWolves Managed Services, LLC.*
Director of Technology
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: dnf even allows to uninstall RPM and systemd without warnings

[Steve Clark]

On 06/23/2014 06:54 PM, Gerald B. Cox wrote:

First of all thank you for your reasoned response.  I simply disagree.

I understand the fact about require bugs, and the tons of dependent packages.  I've seen that also when I've 
tried to remove a package and noticed it had a myriad of dependencies which would also be removed.  However, 
when I see this, I simply respond N when I'm asked if it is OK to proceed.  I also cringe when I 
see the -y or --assumeyes option mentioned.  IMO that is just inviting disaster.  I'm surprised 
no one is demanding that be removed.  It is dangerous.

Regarding your kernel comment, I've been using Fedora since Redhat 6.2 and DNF since it first came 
out and I've never encountered this.  When I update the kernel, it leaves the prior two on my 
system for rollback, so I have no idea what you're talking about.  Yes, if you manually enter 
dnf remove kernel it will come back with a list of all your installed kernels, but 
again, you have to tell it YES to proceed.

That said, my concern is that valuable developer time be devoted to something 
which basically is to assist a small fraction of people who are careless, can't 
be bothered to read or both.


On Mon, Jun 23, 2014 at 12:26 PM, Przemek Klosowski przemek.klosow...@nist.gov 
mailto:przemek.klosow...@nist.gov wrote:

On 06/23/2014 11:51 AM, Gerald B. Cox wrote:

This has got to be the silliest thing I've ever seen, but whatever.  You 
enter the command dnf remove dnf, and guess what?  It removes dnf.  You enter 
the command dnf remove kernel, and guess what, it removes the kernel.  What a 
concept, it does what you tell it to do.

You present it as simple, but it's really trickier than you imply for 
several reasons. We discussed several special cases, which you must have missed 
so let me recall those for your benefit.

First, the dependencies. Updates often involve chains of those, and I've 
seen cases, e.g. caused by a require bugs, where
suddenly some system libraries end up scheduled for removal, dragging along 
tons of dependent packages. Yes, 'yum update' will then ask for confirmation, 
but it just isn't scalable---the equivalent of 'yum -y update' must be reliable 
and recoverable even if things go wobbly.

Second, kernel updates deleting all old kernels can delete the only running kernel. 
You can't just say don't ship broken kernel upgrades because it's a 
per-system problem---new ones work for most people but if you are the unlucky person for 
whom it
doesn't work, you are in a bind:

 - you must upgrade because otherwise you will never get a fix
 - you can't upgrade because it'll delete the only running kernel, and the 
new one might not work

It just makes a lot of sense to identify and protect a subset of packages 
whose removal is potentially irreversible.


Hi Gerald,

We get it. In a perfect world we wouldn't need any kind of validation on input 
because no one would ever make a mistake.

--
Stephen Clark
*NetWolves Managed Services, LLC.*
Director of Technology
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F22 System Wide Change: Replace Yum With DNF

[Steve Clark]

On 06/13/2014 09:03 AM, drago01 wrote:

On Fri, Jun 13, 2014 at 2:58 PM, Reindl Harald h.rei...@thelounge.net wrote:

Am 13.06.2014 14:53, schrieb Jan Zelený:

That being said, the reason for not renaming dnf to yum is that renaming this
project to yum will do nothing else than to confuse its users, as they will
think this is still yum and they should expect from dnf it what they expected
from yum. They should not. And dnf is not yum, I'm really sorry if you think
it is.

the user expects that anyways if you replace something he
did not asked for replace it and what just worked for him

Well there are different levels of works i.e just because something works that
something does not have to be the best possible implementation of
something ...

Horses worked too but at some point we decided that cars work better
and moved on.

Yes but who is this better for? A few developers or the mass of people and 
documentation that
are used to using yum.

With cars it was obviously better for me - dnf not so obvious.

Regards,
Steve

--
Stephen Clark
*NetWolves Managed Services, LLC.*
Director of Technology
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F22 System Wide Change: Replace Yum With DNF

[Steve Clark]

On 06/13/2014 11:01 AM, Reindl Harald wrote:


well, hopefully it does not fit the same way if it needs to drive
offside a nice road in context of software: stability

i am tired hear people talking about milliseconds of boot-performance
and what update tool is slightly faster here and there because i never
met anybody who is booting and upgrading his system 365/24/7




+1

--
Stephen Clark
*NetWolves Managed Services, LLC.*
Director of Technology
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Incorrect order of /usr/bin and /usr/sbin in path

[Steve Clark]

On 05/05/2014 10:43 AM, Lennart Poettering wrote:

On Mon, 05.05.14 10:35, Kaleb S. KEITHLEY (kkeit...@redhat.com) wrote:


On 05/05/2014 10:28 AM, Adam Jackson wrote:

On Sun, 2014-05-04 at 18:59 +0200, Reindl Harald wrote:


however, the semantics of /usr/sbin is to contain superuser
binaries which should not be overriden because a binary
with the same name exists in /usr/bin

My memory is that the s was more for static not superuser.
There's some conceptual overlap, static binaries being there to recover
even if your shared libraries are hosed which is normally a superuser
kind of operation, but.

My recollection is that the s in /sbin and /usr/sbin was more
system level management. Things an admin would need but would not
usually be needed by an ordinary user.

Binaries in /bin and /sbin would have been statically linked to aid
in recovering a system in single-user mode when /usr might not be
mounted, in the days when disks were so small that /usr might often
be a separate disk.

/usr/sbin is an invention of Linux.

It existed in *BSD for as long as I used it.



The traditional SysV meaning is /sbin for static binaries, and /bin for
and /usr/bin for normal dynamic binaries. Linux then redefine sbin as
meaning system binaries, but that's a concept that really doesn't make
much sense, as you can see for example by Fedora always placing both
/usr/bin and /usr/sbin in the $PATH, and shipping a number of binaries
in both places...

We really should get rid of the destinction, and make all of /bin,
/sbin, /usr/sbin a symlink to /usr/bin, and then never bother again
about $PATH orders and namespace collisions...

Lennart




--
Stephen Clark
*NetWolves Managed Services, LLC.*
Director of Technology
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: dnf versus yum

[Steve Clark]

On 01/04/2014 03:09 PM, Adam Williamson wrote:

On Sat, 2014-01-04 at 10:50 +0100, Mattia Verga wrote:

This is the first time I heard of DNF.
Looking at the page where differences between DNF and yum are
explained (http://akozumpl.github.io/dnf/cli_vs_yum.html) my question
is: do we really need DNF to replace yum?

Maybe I'm wrong, but it seems to me that DNF is no more than yum with
some different standard behavior and a couple of new command line
options. So why replace yum? If those changes are good why simply
don't change standard options in yum or add those new commands to yum?

Because yum's code is a mess. The primary point of the dnf rewrite is
not to alter the user interface, but to clean up the code itself.

That is great but it should support everything yum supported. Even Linux keeps 
old interfaces
around, if they are going to change there is at least a period where they are 
marked as deprecated
and with a caution they may be removed in the future!


--
Stephen Clark
*NetWolves*
Director of Technology
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: dnf versus yum

[Steve Clark]

On 01/02/2014 02:25 PM, Dan Mashal wrote:

On Thu, Jan 2, 2014 at 11:09 AM, Richard Vickery
richard.vicker...@gmail.com wrote:



On Thu, Jan 2, 2014 at 7:28 AM, Reindl Harald h.rei...@thelounge.net
wrote:

look like it starts to happen again: a replacement which is not ready

https://lists.fedoraproject.org/pipermail/users/2014-January/444565.html
https://lists.fedoraproject.org/pipermail/users/2014-January/444563.html

please realize that a drop-in replacement *first* needs to be *really*
drop-in and not somehow like, otherwise all the things you may make
better are worthless

and yes yum remove kernel is a *minimum* to handeled properly

there are people maintaining RHEL5,RHEL6,RHEL7 and Fedora machines
guess how abused they are if they have completly different behavior
because dveleopers tend to call anything they don't like to implement
a border case




Reindl makes a very good case here against the adoption. The last thing we
want is to cause confusion in the community. It may be very wise to wait and
give the community more time to absorb dnf. I confess that it would be a
learning curve for me to use this command: I could imagine the headaches it
would bring others with much more pressing deadlines.

my 2 cents,

I don't understand what the learning curve is? It works exactly the
same as yum. Typing 'dnf' instead of 'yum' is a learning curve?

I'm confused.

Dan

If is a drop in replacement for yum - then why not call it yum, then there is 
no learning curve.

Also at least yum stood for something - Yellowdog Updater, Modified - as 
opposed to being some
nonsensical conglomeration of letters. The only thing I am aware of that dnf means is 
did not finish.

--
Stephen Clark
*NetWolves*
Director of Technology
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Where does loopback short circuit ?

[Steve Clark]

On 08/29/2013 04:28 PM, Neil Horman wrote:

On Thu, Aug 29, 2013 at 01:06:23PM -0700, Les Howell wrote:

On Thu, 2013-08-29 at 18:04 +0100, Richard W.M. Jones wrote:

On Thu, Aug 29, 2013 at 10:02:27AM -0700, John Chludzinski wrote:

I've had a debate with some co-workers about whether or not a message
that's sent to the loopback interface makes it way into the IP layer and
is fragmented before flowing back up the network stack.  Does it?

Can you please not keep creating new top level threads.

Furthermore, this is not an appropriate mailing list to discuss any
general (not even Linux) networking issues that you may have.  It's
more appropriate for a venue such as stackoverflow.

Rich.

I am unsure of the standards for this.  I am also curious about the
Fedora implementation.  I would suspect that the loopback mechanism
would be implementation dependent, and that the method used on a
particular system would provide valuable information.

A usergroup such as stackoverflow would not likely have that
information.  Therefore this would seem to be the most accurate source
for such information IMO.

A short and reasonable answer would be beneficial to the group.


The answer is simple, and as always, contained in the source.  lo is defined in:
drivers/net/loopback.c

It registers an interface using the network driver api, and contains a transmit
routine.  Therefore, all frames that go to the loopback interface go through the
entire routing stack, and get looped at the driver.

honestly, doing anything less tends to get pretty messy anyway, as you start to
have to handle all sorts of special cases.  Consider the possibility that a
packet socket is listening on lo when you transmit a tcp frame out of it.  If
you looped it back higher in the stack, you'd have to be sure to clone the skb
and offer the packet to the packet protocol somewhere in the ip stack.  Multiply
that by every protocol listener available in the kernel and the fan out gets
unmanageable.  Its better to just go down to the driver layer and loop there.

Neil


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Hello,

I believe in later kernels there is the option to bypass the tcp stack on the 
loopback
which will be enabled by default. See this thread.
http://marc.info/?l=linux-netdevm=134456025709318w=3



--
Stephen Clark
*NetWolves*
Director of Technology
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F20 System Wide Change: No Default Sendmail

[Steve Clark]

On 07/21/2013 03:17 AM, drago01 wrote:

On Sun, Jul 21, 2013 at 8:58 AM, Nicolas Mailhot
nicolas.mail...@laposte.net wrote:

Le Sam 20 juillet 2013 21:14, Adam Williamson a écrit :


I asked for evidence, not hypotheses. All you are currently doing is
making an assertion, over and over and over and over again.

Pot, kettle

I'll add another one: desktop people have complained for years just like
you it was a legacy system and surely something better should replace
it. Yet the something better never materialized. When I had a disk go
wrong lately I was notified by the big ugly legacy system. I had *zero*
notification by all the better systems that were given as evidence.

That's good for you but most user wouldn't even have noticed the mail.

Where are your statistics to back up that wild assertion.

--
Stephen Clark
*NetWolves*
Director of Technology
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: No Default Syslog

[Steve Clark]

On 07/19/2013 02:56 PM, Jóhann B. Guðmundsson wrote:

On 07/19/2013 06:45 PM, Billy Crook wrote:

I haven't seen anyone asking to ship two sysloggers.


I perhaps should have been clearer and say two logging systems which
we currently are doing and one of those cannot be disabled or removed so
the logical choice is to remove the one that can and make him as an
option to be install later.

JBG

This might have merit if the one you want to keep could do everything it does
plus what the one you want to remove does.

--
Stephen Clark
*NetWolves*
Director of Technology
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: No Default Syslog

[Steve Clark]

On 07/18/2013 08:09 AM, Lennart Poettering wrote:

On Wed, 17.07.13 22:35, Ding Yi Chen (dc...@redhat.com) wrote:


This should be simpler than forcing those stubborn mind (such as me) to change,
No?

We don't force anyone. You can just install rsyslog and you have
everything as you love it.

Lennart


Or you can de-install rsyslog and have everything as you love it.

--
Stephen Clark
*NetWolves*
Director of Technology
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: No Default Syslog

[Steve Clark]

On 07/17/2013 08:20 AM, Jóhann B. Guðmundsson wrote:

On 07/17/2013 12:05 PM, Richard W.M. Jones wrote:

On Wed, Jul 17, 2013 at 09:21:39AM +, Jóhann B. Guðmundsson wrote:

On 07/17/2013 12:58 AM, Ding Yi Chen wrote:

You still have not addressed the third party programs and scripts
that monitor /var/log/messages

We honestly cant keep progress and cleanup in the distribution back
out of fear of breaking some third party programs.

Irrespective of whether journald is good or bad, this is a dumb
argument.

Dumb I see so you have established a time frame for us how long we
should  hold back progress  in the project and or you have devised an
implementation plan on features and cleanups with a rate that a third
party can keep up with in the distribution, maybe even chosen which
third parties we wait for and which we dont?

You think it's good for the community to be dependent on third party I
dont since think we should first and foremost be thinking about
ourselves and our community not some third party of the interweb or even
a downstream distribution to us like like RHEL.

We as a community need to be able to set the pace for ourselves and the
fact is unless you are closed source the best thing you can do as a
third party is actually participate in the Fedoraproject, packaging you
software or application stack and ship it within the distribution so
that our existing processes will catch any fallout which our features or
cleanups might bring and allow for the community to actually fix it with
your or for you.

JBG

But it seems the community is only the people driving all these changes, what about the 
whole user community,
not just the developer community


--
Stephen Clark
*NetWolves*
Director of Technology
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: No Default Syslog

[Steve Clark]

On 07/17/2013 11:05 AM, Zbigniew Jędrzejewski-Szmek wrote:

On Wed, Jul 17, 2013 at 12:00:05PM +0200, Reindl Harald wrote:


Am 17.07.2013 11:21, schrieb Jóhann B. Guðmundsson:

On 07/17/2013 12:58 AM, Ding Yi Chen wrote:

You still have not addressed the third party programs and scripts
that monitor /var/log/messages

We honestly cant keep progress and cleanup in the distribution back out of fear 
of breaking some third party programs

you could if you want

* only journald is running - write to /var/log/messages and 
/var/log/secure additionally to the journal
   a option in /etc/systemd/journald.conf to disable this

* if a syslog-daemon is running leave /var/log/messages and /var/log/secure
   untouched from journald

so *if* you want you can keep progress without a large impact all the time

Except ... that would still keep duplicated logs on the FS. Removing
the duplication is the primary reason for wanting to not install
rsyslogd by default.

Zbyszek

This seems like such a specious argument. Maybe it made sense when we were 
talking about disk drives
that were megabytes in size, but now we have 500 gigabyte drives usually as a 
minimum.



--
Stephen Clark
*NetWolves*
Director of Technology
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: No Default Syslog

[Steve Clark]

On 07/17/2013 11:21 AM, john.flor...@dart.biz wrote:


 From: scl...@netwolves.com

 This seems like such a specious argument. Maybe it made sense when
 we were talking about disk drives
 that were megabytes in size, but now we have 500 gigabyte drives
 usually as a minimum.

You don't ever work with embedded systems, do you?

--
John Florian




So you run fedora on an embedded system?

--
Stephen Clark
*NetWolves*
Director of Technology
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: No Default Syslog

[Steve Clark]

On 07/15/2013 08:29 PM, Lars Seipel wrote:

On Mon, Jul 15, 2013 at 02:46:27PM -0600, Eric Smith wrote:

I don't actually care whether there's a binary journal or not, but far
more of us have real usecases for /var/log/messages, so we shouldn't
give up that being available by default.

If you use bash or ksh you could just replace /var/log/messages with
(journalctl) in your command line and stuff should just work (when
reading). Other shells can probably do the same. It obviously depends on
journalctl being able to run.

What about scripts that use /usr/bin/logger? Do messages generated by this 
utility
end up in the journal? Or php scripts, or programs using syslog(3).




--
Stephen Clark
*NetWolves*
Director of Technology
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: No Default Syslog

[Steve Clark]

On 07/15/2013 10:55 AM, Dan Fruehauf wrote:

+1 - same here. You're far from being alone.

I'm still trying to get used to the new systemd in Fedora and still trying to 
think why I need it. Altogether for my day to day use I find it as added 
complexity with no real benefit cerca f15.

Unix/Linux for me is the simplicity of text files. If I lose the simplicity of 
text files I just wonder what is left for me? A bunch of vague files in a 
binary format I need complex  tools to decipher? Might as well just install 
win7 and utilize my gfx card.

Same happened to me when I moved from being a big fan of KDE to LXDE. Why is 
that? KDE became just too heavy, too much  I just didn't need. LXDE just 
lets me open a terminal, a web browser, a music player and get my  done 
with.

A change like that is something probably the ubuntu community would like to 
adopt. A change that would just give me yet another reason to not use ubuntu. 
Linux is text files. It's grep, sed, bash, awk and all the other amazing text 
manipulation utilities we have.

A change like that might actually make me move away from Fedora after being 
loyal to it for as long as it existed. And I know I will not be alone.

Lets try to keep things simple. This is why we use Fedora. This is why I use 
Fedora.



On Mon, Jul 15, 2013 at 7:11 PM, Miroslav Suchý msu...@redhat.com 
mailto:msu...@redhat.com wrote:

On 07/15/2013 10:44 AM, Jaroslav Reznik wrote:

= Proposed System Wide Change: No Default Syslog =
https://fedoraproject.org/wiki/Changes/NoDefaultSyslog

Change owner(s): Lennart Poettering lennart at poettering net, Matthew
Miller mattdm at fedoraproject org

No longer install a traditional syslog service by default. 
(Specifically,
remove rsyslog from the @core or @standard groups in comps.)

The systemd journal will be the default logging solution. Rsyslog, 
Syslog-NG,
and even traditional sysklogd will continue to cover use cases outside 
of the
default.


My voice may be one of thousands, but I'm saying: I want to have 
traditional syslog service as default and have journal from systemd as option.

-- 
Miroslav Suchy

Red Hat, Software Engineer
-- 
devel mailing list

devel@lists.fedoraproject.org mailto:devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel





+1 for me too.

--
Stephen Clark
*NetWolves*
Director of Technology
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Improving the Fedora boot experience

[Steve Clark]

On 03/14/2013 06:52 AM, Denys Vlasenko wrote:

On 03/11/2013 08:49 PM, Michael Cronenworth wrote:

On 03/11/2013 02:41 PM, Björn Persson wrote:

Yes, why not display the Grub menu?

Because it's the year 2013. Not 1999.


Whether any text is displayed or not, there still needs to be a long
enough pause that the user has time to press a key. Not displaying any
text at all would make it harder to understand that the time to press
that key is now. Many people won't even understand that they have an
opportunity to press a key.

Does any other computing device you own prompt you for a boot menu? Your
mobile phone? Your TV (which likely has embedded Linux)? Your car?

My computer is not a mobile phone or car.
I much prefer it to *not* become mobile phone-like cripple.


Why is that? Could it be because a boot menu is not necessary for normal
operation? A normal user doesn't need to wonder Hey what kernel do I
need to boot today? every time their system boots.

...until something breaks.
*Then* suddenly you discover that you _do_ need a way to see all
this stuff (and more).


If you are a developing developer and need to boot a different kernel or
change kernel parameters then you know how to get into the boot menu --
on-screen prompts or no on-screen prompts.

There is a time when developers need to distance themselves from
user-interfaces and realize they are not the only user of the
user-interface. This is one of those times.

Intentionally dumbing down the system so that even idiots can use it
will result in *only* idiots using it.

If you don't want to see boot menu, there is a way to switch it off.
This behavior can be made much easier to enable,
if necessary - along the lines of Don't ask me again checkboxes.




+1

--
Stephen Clark
*NetWolves*
Director of Technology
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Improving the Fedora boot experience

[Steve Clark]

On 03/14/2013 07:06 AM, Denys Vlasenko wrote:

On 03/11/2013 10:48 PM, Björn Persson wrote:

Lennart Poettering wrote:

(And on EFI systems that do not initialize USB anymore during POST, you
have to go through the OS to get into the boot loader anyway...)

That's going to be real fun when the OS fails to boot, and I can't fix
the boot because I can't get into the boot loader because the OS fails
to boot.

+1


Yeah Lennart what do you do then?

--
Stephen Clark
*NetWolves*
Director of Technology
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Improving the Fedora boot experience

[Steve Clark]

On 03/12/2013 07:04 AM, drago01 wrote:

On Tue, Mar 12, 2013 at 11:37 AM, Reindl Harald h.rei...@thelounge.net wrote:


Am 12.03.2013 09:55, schrieb drago01:

On Mon, Mar 11, 2013 at 10:22 PM, seth vidal skvi...@fedoraproject.org wrote:

On Mon, 11 Mar 2013 16:18:33 -0500
Michael Cronenworth m...@cchtml.com wrote:


On 03/11/2013 04:13 PM, seth vidal wrote:

I want to encourage kids, teenagers, etc to explore the OS. We need
them to be involved in CREATING and LEARNING. So I don't want to
scare any of them off.

My OLPC does not present any boot menu or prompt.

That's not an argument for why we should not present one. It is an
argument for why they should be.

Sorry but that's nonsense. Pretty much all other operating systems do
not display the boot loader by default and you see this as a reason
for showing it?
What kind of weird logic is that? Or do you really think we can have
we do show a screen that you won't care about most of the time on
every boot as a selling point for fedora?

who cares about OTHER operating systems?

You can't develop an operating system while living under a rock you
have to look at what the competition does.


if i would want their behavior i would install them

Strawman.


are you guys booting the whole day your machines that
save 2 seconds is woth any discussion?

Yes 2 seconds is a LONG time when your system is using an SSD.
Booting should be instant there is no reason why we should have to
wait before being able to use the system. (killing grub delay gets us
closer to that goal).

I'd say booting is a more common task then messing with bootloader
options so lets optimize for the former rather then the later.

How many times do you boot your system each day? 10? Okay thats a whole 20 
additional seconds.



--
Stephen Clark
*NetWolves*
Director of Technology
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Improving the Fedora boot experience

[Steve Clark]

On 03/12/2013 09:33 AM, Lennart Poettering wrote:

On Tue, 12.03.13 09:13, Steve Clark (scl...@netwolves.com) wrote:


How many times do you boot your system each day? 10? Okay thats a
whole 20 additional seconds.

This is way up on my list of most non-sensical arguments about building
OSes, right next to Linux is about choice.

This bullshit about boot times don't matter is just entirely bogus,
and it doesn't get better by constant repitition.

Fast boot times matter on desktops, they matter on embedded, they matter
on mobile, they matter or servers, they matter everywhere.

Fast boot times matter to dual-boot users, they matter to everybdoy who
doesn't run his system 24/7, they matter in container setups, they
matter in HA setups, they matter in the cloud, they matter for people
who update their system, they matter to people with discontiniuous power
supplies, they matter to provide users with a sane user experience.

Fast boot times save you time and energy. They increase reliability, and
applicability.

Fast boot times improve the first impression our OS makes on people.

And yes, I know that some BIOSes suck, and are slower than the OS to
boot. But that's -- for once -- something that *does* not matter, and is
no excuse for having everything else to be slow, too. The Windows 8
certification *requires* fast POST from all machines, and so, it's only
getting better, and we should do our bit about it.

You know: *you* might not need fast boot. *Your* systems you might not
reboot only every other week. *Your* server system might have a very
slow BIOS POST. But we don't do this OS for *you* alone. Fedora has a
certain claim of universality. And that's why fast boot matters to
Fedora.

Lennart


How in the hell does 2 more seconds when booting a Desktop make any difference 
in an 8 to 10 hour
day that the computer is going to be up. Go get a cup a coffee!

You keep touting window 8 - maybe you should just use it an leave Linux alone!

--
Stephen Clark
*NetWolves*
Director of Technology
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Improving the Fedora boot experience

[Steve Clark]

On 03/12/2013 02:23 PM, Reindl Harald wrote:


Am 12.03.2013 19:03, schrieb Chris Murphy:

i learned it many years ago by facing the boot-menu


Well you wouldn't learn it today because of how grub2-mkconfig and grubby 
interact.

ah and because things got worser you would make it more worse



Your first kernel update depends on grubby to write the entry in grub.cfg,
and uses a nomenclature completely different than grub2-mkconfig.

thanks god for that, so i have the same behavior as
all the years before on any machine


And then, most new linux users with Windows or OS X experience,
have no idea what a kernel even is.

so they can learn or use Windows/OSX


If they do, most don't know what the kernel does that system services don't

so they can learn or use Windows/OSX


Next it is never the case that Windows or OS X or mobile devices have
multiple kernel versions. There is only one kernel at one time on such systems

BUT WE HAVE AND IT IS A BLESS


You'd have to learn this

and you learn by FACING things


Even if I were to see a coherent list of kernels in a list by their date,
it's unlikely I as a new user would have made the leap to try another option

with this argumentation you can follow the current attitude
to make linux-systems to the same blackboxes as other
operating systems

but the better option for us all would be if people with
this attitude switch to these operating systems instead
damage slowly what we know as UNIX-LIKE system



Well said Reindl !l



--
Stephen Clark
*NetWolves*
Director of Technology
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Improving the Fedora boot experience

[Steve Clark]

On 03/11/2013 05:04 PM, Lennart Poettering wrote:

On Mon, 11.03.13 21:45, Nicolas Mailhot (nicolas.mail...@laposte.net) wrote:


Le Lun 11 mars 2013 21:16, Lennart Poettering a écrit :

On Mon, 11.03.13 13:08, Chris Murphy (li...@colorremedies.com) wrote:


On Mar 11, 2013, at 11:31 AM, Björn Persson bj...@xn--rombobjrn-67a.se
wrote:

Or nothing at all displayed unless the user happens to know to press

some key at the

right moment?

A multiboot system needs at least a message to inform the user how to
get to the boot manager (the GRUB menu). A Fedora only system probably
should entirely suppress the menu or notice how to get to it.

Somebody who is capable of installing multiple operating systems on one
machine should easily be savvy enough to remember that pressing
shift/esc/space/f2/whatever gets him the boot menu.

If you installed multiple OSes and noticed that the boot menu is gone,
wouldn't pressing these keys be your natural reaction anyway?

My natural reaction would be to curse whoever is making me waste minutes
in press-random-keys-to-see-if-you-can-unlock-boot games to win a few
seconds. I'm pretty sure any poll would find the same result.

My natural reaction to the current grub2 menu that steals my boot is
that I start to hate Fedora and Linux for that we waste our time in ugly
boot menus and bikeshedding about them.

Lennart


How many times do you boot a day? If it is more than once or twice I would 
posit that is not
the normal user. So what is 2 extra seconds?

--
Stephen Clark
*NetWolves*
Director of Technology
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Non responsive state for systemd

[Steve Clark]

On 03/04/2013 07:05 PM, Lennart Poettering wrote:

On Mon, 04.03.13 10:24, David Highley (dhigh...@highley-recommended.com) wrote:


Lennart Poettering wrote:

On Mon, 04.03.13 07:56, David Highley (dhigh...@highley-recommended.com) wrote:


Twice now we have one Fedora 18 system where systemd seems to get into a
non responsive state. We are not able to get the status of any service
and we're not able to do an init 6 to restart the system.

Did notice today that a full process list showed a message about abrt
and something to the effect nobody cared. We also see a number of
defunct processes that seem to never clear. So far the only remedy we
have found is a hard power cycle.

Can you get a stack trace of PID1? sudo pstack 1 should already give a
hint, but even better would be a a bt full via gdb.

We are offsite right now so will dig deeper later. We had checked the
log files and noticed that it complains about rsyncd not being able to
connect to a port and there was another complaint about Gnome. The
rsync one repeats as there are back ups that are not being serviced
which is is what alerted to something being wrong. We are sending and
receiving email from this system. It also has an internal web, mysql,
and other subsystems which seem to work fine. So when this state occurs
it sometimes takes a while to notice.

This is a bug in libselinux:

https://bugzilla.redhat.com/show_bug.cgi?id=901812

This is exact reason you don't make the most important user space program 
dependent on a lot of other stuff!


Lennart




--
Stephen Clark
*NetWolves*
Director of Technology
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Non responsive state for systemd

[Steve Clark]

On 03/06/2013 07:08 AM, Lennart Poettering wrote:

On Wed, 06.03.13 06:55, Steve Clark (scl...@netwolves.com) wrote:


On 03/04/2013 07:05 PM, Lennart Poettering wrote:

On Mon, 04.03.13 10:24, David Highley (dhigh...@highley-recommended.com) wrote:


Lennart Poettering wrote:

On Mon, 04.03.13 07:56, David Highley (dhigh...@highley-recommended.com) wrote:


Twice now we have one Fedora 18 system where systemd seems to get into a
non responsive state. We are not able to get the status of any service
and we're not able to do an init 6 to restart the system.

Did notice today that a full process list showed a message about abrt
and something to the effect nobody cared. We also see a number of
defunct processes that seem to never clear. So far the only remedy we
have found is a hard power cycle.

Can you get a stack trace of PID1? sudo pstack 1 should already give a
hint, but even better would be a a bt full via gdb.

We are offsite right now so will dig deeper later. We had checked the
log files and noticed that it complains about rsyncd not being able to
connect to a port and there was another complaint about Gnome. The
rsync one repeats as there are back ups that are not being serviced
which is is what alerted to something being wrong. We are sending and
receiving email from this system. It also has an internal web, mysql,
and other subsystems which seem to work fine. So when this state occurs
it sometimes takes a while to notice.

This is a bug in libselinux:

https://bugzilla.redhat.com/show_bug.cgi?id=901812

This is exact reason you don't make the most important user space program 
dependent on a lot of other stuff!

True thing. libselinux is a library we really really should avoid
linking against. I mean, it's almost as bad as libc, we really should
avoid linking against that from PID 1 too. Oh man, those systemd guys
are such idiots that they dare to link against libc and
libselinux!

Lennart

Well you can be as sarcastic as you want but I have been using UNIX/Linux since 
1985 and never had init hang or die on me.


--
Stephen Clark
*NetWolves*
Director of Technology
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names

[Steve Clark]

On 01/29/2013 01:13 PM, Andrew McNabb wrote:

On Tue, Jan 29, 2013 at 06:11:19PM +, Matthew Garrett wrote:

Walk /sys/class/net, filter on type, filter out bridges, filter out
wireless if you want to. sysfs should have all the information you need
without name-based heuristics.

You have added confirmation that any attempt to figure out the name of
the interface is an ugly brittle mess. ;)

--
Andrew McNabb
http://www.mcnabbs.org/andrew/
PGP Fingerprint: 8A17 B57C 6879 1863 DE55  8012 AB4D 6098 8826 6868

I agree. I was so happy when we moved from FreeBSD with its em's, vr's, rl's, 
re's, bge's, fxp's, ed's, etc
to Linux with just eth!

--
Stephen Clark
*NetWolves*
Director of Technology
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: Package Signature Checking During Installation

[Steve Clark]

On 01/08/2013 10:55 AM, Peter Jones wrote:

On Tue, Jan 08, 2013 at 03:52:02PM +, Petr Pisar wrote:

On 2013-01-08, Jaroslav Reznik jrez...@redhat.com wrote:

= Features/PackageSignatureCheckingDuringInstall =
https://fedoraproject.org/wiki/Features/PackageSignatureCheckingDuringInstall

* Detailed description:
One long-standing problem in Fedora is that we don't check package signatures
during installation. This has been a persistent issue since the very beginning
of Fedora (and even in Red Hat Linux before it.) The reason for this has
always been that there's no way to form any root of trust for the signatures
in the repositories, and thus no reason they wouldn't have been modified along
with whatever package would need to be re-signed after tampering.


Reading till here makes me pondering how's possible rpm does not check
package signature.


Following the implementation of Features/SecureBoot, we can extend the Secure
Boot keys as a root of trust provided by the hardware against which we can
verify a signature on our key files, thus guaranteeing that they're from the
same source as the boot media.


Now it's clear it's about insttalling distribution. Not about installing
a package with rpm in general.

Could reponsible person change title and abstract to be clear it's about
_distribution_ installation?

Sure thing.

It's now at
https://fedoraproject.org/wiki/Features/PackageSignatureCheckingDuringOSInstall
, and the title and description have been changed to match that.



What about repins? I want to add my own custom package that is not signed and 
create a new CD with a custom ks.cfg.
How would that work?

Thanks,


--
Stephen Clark
*NetWolves*
Director of Technology
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: pulseaudio maintainership status

[Steve Clark]

On 12/26/2012 11:26 AM, Brendan Jones wrote:

On 12/25/2012 10:50 AM, Julian Sikorski wrote:

Dear list, Dear Lennart,

a week ago I have submitted a pulseaudio bug alongside with the patch
[1]. There was no response so far.
Knowing that Lennart is busy with systemd these days, I proceeded to
check the pkgdb status of pulseaudio. The only other maintainer with
commit access is lkundrak, who has been declared non-responsive a while
ago himself, plus 3 request pending.
To have such a critical subsystem barely maintained does not seem
sustainable. I have already stepped up to co-maintain pavucontrol and
paprefs, but PA proper is a whole other level. I have joined the waiting
list and am willing communicate the issues between Fedora and upstream,
but someone with an ability to fix bugs on their own would be welcome too.
Lennart, could you please look at the pending ACL requests? Thank you.

Merry Christmas everyone,
Julian

[1] https://bugzilla.redhat.com/show_bug.cgi?id=888422


If you look at the build status you can see pulseaudio is hardly
unmaintained.

Rex Dieter has also provided a backport of the latest pulseaudio to use
with early releases. I'm sure he is very amenable to cherry picking
patches from a later release if it fixes a specific issue people may be
having.

http://repos.fedorapeople.org/repos/rdieter/pulseaudio-backport/

Then why is no one fixing the identified bugs?

--
Stephen Clark
*NetWolves*
Director of Technology
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: systemd requires HTTP server and serves QR codes

[Steve Clark]

On 10/09/2012 02:17 PM, Lennart Poettering wrote:

On Tue, 09.10.12 10:31, Matthew Miller (mat...@fedoraproject.org) wrote:


On Tue, Oct 09, 2012 at 04:05:10PM +0200, Lennart Poettering wrote:
? On Tue, 09.10.12 09:49, Matthew Miller (mat...@fedoraproject.org) wrote:

allowing regular users to do so. (Commonly currently accomplished by making
/var/log/messages owned and readable by the wheel group.)

The HTTP thingy is not really how admins should access the logs. They
should just use journalctl.

On a related but tangental note: I notice that journalctl allows access to
members of the admin group by default.

Well, I'd say this differently: we _restrict_ access to adm, in
contrast to the previous logic where everybody was allowed to read
/var/log/messages and only root /var/log/secure.


When was previous - that access to /var/log/messages was allowed?
$ cat /etc/redhat-release
Fedora release 14 (Laughlin)
sclark66:~/Download
$ less /var/log/messages
/var/log/messages: Permission denied


In Fedora for the past few releases
we've followed the tradition of making wheel the admin group -- see
http://docs.fedoraproject.org/en-US/Fedora/17/html/Installation_Guide/sn-firstboot-systemuser.html?
This is also the case in RHEL 6, so changes here have downstream
implications.

The way I see this is that wheel allows you to *do* privileged things,
but adm allows you to *see* privileged things.

Note that adm has been widely used for the log purpose on other Linux
distros, most notably Debian and its descendents. On Debian
/var/log/messages defaulted to being private to adm, and we kinda
wanted to unify things here and though the Debian default is much nicer
than the Fedora default of world-readability of logs, from a security
PoV.


Could we make that a default on Fedora in addition to adm? (I assume this is
polkit but can't see it offhand -- hmmm... looks to be hard-coded in the
source?) I don't really have a strong opinion about whether adm should work
or not, but wheel should.

Well, we could of course add this as ACL, but I wonder if it wouldn't be
nicer to declare that adm is for seeing, and wheel for doing as I
suggested above.


Second, there's a traditional separation between /var/log/secure and
/var/log/messages. Crucially, the secure log may contain
accidentally-typed user passwords and other privacy-sensitive information.
How can we do something similar with the systemd journal and
journalctl?

As mentioned no system messages are user-readable by default in the
journal. We are more secure by default with the journal.


Ideally, the /var/log/messages data would be available to members of the
admin group without extra authentication, but seeing the potentially-privacy
sensitive /var/log/secure should require re-authentication. (As a sysadmin,
I should be able to safely look at message data with a user looking over my
shoulder, so I can help them without possibly exposing private information
about other users on the system.)

Well, honestly the old secure vs. messages split is kinda broken, simply
because old syslog didn't check the originator of messages and hence
unprivileged processes could get have their data spill into the presumed
secure logs. Splitting this of based on the facility field is fake
securety, and we don't do fake security anymore with the journal.

Lennart




--
Stephen Clark
*NetWolves*
Director of Technology
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: *countable infinities only

[Steve Clark]

On 06/15/2012 12:05 PM, Jay Sulzberger wrote:


On Fri, 15 Jun 2012, Mathieu Bridon boche...@fedoraproject.org wrote:


On Thu, 2012-06-14 at 15:46 -0400, Jay Sulzberger wrote:
Please forgive this top posting.

I will not answer now your radical defense of Microsoft, except to
say two things:

1. Your defense would apply also to the decades long fraud of
Microsoft saying in their EULA that, if you do not run the
Microsoft OS installed at point of sale of the hardware, you get
a refund for the OS.  But Microsoft and the hardware vendors
systematically refused refunds.

No they haven't. People get their OS refunded in France. It is a long
and frustrating process, but with each victory it gets easier.

No, even in France, as you state, it is not easy to get a refund.
Even though the practice of tying software to hardware is
illegal.  What this shows is that one must be careful to
correctly estimate the size of various forces in tactical situation.

The relevance to the present case is this:

Some Fedora developers argue that it will still be possible to
install Fedora on x86 hardware which, as shipped, has only the PK
and the PK authorized Microsoft Hardware Key in the UEFI.  But
Microsoft has for over a decade promised to simply give a refund
when requested.  And today nowhere on Earth does Microsoft
actually simply give a refund when requested.  Now Microsoft has
promised to always allow the owner sitting before the machine to
install their own key.  But we know that Microsoft has
systematically broken its promise to give refunds.  Thus we
should not accept Microsoft's promise here.

In the case of ARM devices Microsoft's statement of its position
is different: If the ARM device is shipped with a Microsoft OS,
then Fedora will never be installed on the device.  No putting
one's own key in, no getting a special
Microsoft/Vendor/Certificate-Authority managed key for the whole
Fedora project, no nothing, just gross suppression of Fedora and
all free OSes.


There's even a step-by-step guide (in French) :
http://non.aux.racketiciels.info/guide/index

Thank you for this pointer.

Here is a story from 1999:

http://www.nylug.org/articles/text/article.windowsrefundday.nytimes.shtml

The story is partly inaccurate. In New York City, of all the
vendors whose machines we installed a free OS on, after careful
removal of the Microsoft OS, only Emachines gave us a refund.
Emachines was courteous in their written response to our request,
and prompt in sending us the refund.


And recently:

For the first time in a case related to the sale of hardware/software, a
judge declares explicitly  that the sale of an OS by the OEM when the
customer never asked for it can be considered unfair in any
circumstance given its aggressive characteristic. The argument, more
direct than ever (speaking about forced sale rather than bundled sale),
is usable in all Europe.


(quick translation from me, the inner quote is a translation of the
actual words from the judge)

http://aful.org/communiques/faire-payer-systeme-exploitation-non-demande-deloyal-en

I am glad to see the court's clear statement.


Of course this is wildly off-topic...


--
Mathieu

I hope that France enforces the law against tying of software to
hardware.  France for decades has not.  Of course, neither has
the United States of America, nor the UK, have enforced the laws
and regulations here.  Nor has any large European country
enforced its analogous laws and regulations, as far as I am
aware.

This is not offtopic.  This is the main topic.  Fedora proposes
to support Microsoft in Microsoft's attempt to directly control
every home computer on Earth.  The same arguments that are used
in the present UEFI case to justify truckling to Microsoft could
as well be applied to the Refund Clause question: Why there is
really no problem.  It is just a minor inconvenience that the
hardware ships with an OS you do not want.  See the EULA says you
get a refund, so you just have to carefully remove the Microsoft
OS, careful don't start it up by accident, and then you get a
refund..  But in fact the policy of Microsoft is not to give any
refunds, ever.  And in fact in the UEFI case, no matter what
Microsoft says, the policy of Microsoft is to make it difficult
to install Fedora on x86 hardware, and impossible on ARM
hardware.

oo--JS.

+1

--
Stephen Clark
*NetWolves*
Director of Technology
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: *countable infinities only

[Steve Clark]

On 06/12/2012 08:10 AM, Orcan Ogetbil wrote:

On Sat, Jun 9, 2012 at 10:57 AM, drago01 wrote:

On Sat, Jun 9, 2012 at 4:09 PM, Orcan Ogetbil wrote:

On Sat, Jun 9, 2012 at 3:19 PM, Chris Smart wrote:

On 09/06/12 19:34, drago01 wrote:

If Fedora does not implement some form of Secure Boot support, 100% of
Fedora users will still be able to install Fedora on new machines, after
they disable Secure Boot, if their computer even has it at all (and
personally, I think the majority of Fedora users will simply buy
hardware which does not have Secure Boot). I know I would.

No because some users in don't know what a firmware is and can't/don't
want to fiddle with it.

Except it won't be that hard.

For people like you.


I believe that supporting people who are not in your like you
classification above is loss of time and resources. They should not be
using any electric equipment (e.g. toaster oven, refrigerator, light
bulb) to begin with. Furthermore, reading arguments against this in an
official Fedora mailing list makes me sad.

Sorry for being so harsh. I just don't have much tolerance for
accepting unintelligence.

Not sure I should even reply to such a mail but ... not being computer
literate does not imply being unintelligent .
Just think about that for a bit.

Due to my respect to your request, I thought about it for nearly 72
hours. I still stand behind what I said: People who are incapable of
switching a BIOS setting, which might involve doing a simple web
search beforehand, should better not touch any electric equipment.

Fellow contributors assert that such people are not in Fedora's target
base, as per the statement of the Board. Of course they are right. I
am just claiming the set of BIOS-capable people is not limited to
target Fedora user base, but extends to all electric equipment users.

Best,
Orcan

+1

--
Stephen Clark
*NetWolves*
Director of Technology
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: *countable infinities only

[Steve Clark]

On 06/12/2012 06:15 AM, drago01 wrote:

On Tue, Jun 12, 2012 at 12:11 PM, Nicu Buculeinicu_fed...@nicubunu.ro  wrote:

On 06/12/2012 12:58 PM, drago01 wrote:


On Tue, Jun 12, 2012 at 9:44 AM, Nicu Buculei wrote:


The point is we have a target audience:
http://fedoraproject.org/wiki/User_base

Our desired users ARE contributors.


We do have a mission as well:
http://fedoraproject.org/wiki/Overview#Our_Mission

The Fedora Project consistently seeks to create, improve, and spread
free/libre code and content. 


And Bingo! the mission is all about freedom.

I didn't deny that.


Which you don't do by excluding users ... sure we want to gain new
contributors but that does not mean that we should exclude other
users.


Not if it affects our freedom, is a problem of freedom versus convenience.

No because secure boot does not limit your freedom in *any* way. If
you want to hack on the kernel or other low level stuff flip a switch
in the firmware.
It is reasonable to expect this type of users to be able to do that.


If spreading to some users means losing some freedom, then I think that is
against the mission.

We are not loosing any freedom we are implementing a technology that
makes fedora work out of the box on newer hardware.

This is MS classic ploy against free software embrace and extend. First it will 
be it can be disabled then for
windows 9 if you want to have approved hardware MS will require, like ARM, x86 
secure boot can not be disabled
and they will point to Fedora and say see it is not necessary that we need to 
be able to turn off secure boot, free
software like Fedora works just fine with it enabled.


--
Stephen Clark
*NetWolves*
Director of Technology
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: *countable infinities only

[Steve Clark]

On 06/12/2012 10:58 AM, Jay Sulzberger wrote:


On Tue, 12 Jun 2012, drago01drag...@gmail.com  wrote:


On Tue, Jun 12, 2012 at 12:11 PM, Nicu Buculeinicu_fed...@nicubunu.ro  wrote:
On 06/12/2012 12:58 PM, drago01 wrote:


On Tue, Jun 12, 2012 at 9:44 AM, Nicu Buculei wrote:


The point is we have a target audience:
http://fedoraproject.org/wiki/User_base

Our desired users ARE contributors.


We do have a mission as well:
http://fedoraproject.org/wiki/Overview#Our_Mission

The Fedora Project consistently seeks to create, improve, and spread
free/libre code and content. 


And Bingo! the mission is all about freedom.

I didn't deny that.


Which you don't do by excluding users ... sure we want to gain new
contributors but that does not mean that we should exclude other
users.


Not if it affects our freedom, is a problem of freedom versus convenience.

No because secure boot does not limit your freedom in *any* way. If
you want to hack on the kernel or other low level stuff flip a switch
in the firmware.
It is reasonable to expect this type of users to be able to do that.

Up until now, installing a free OS did not require the extra
moves, which Fedora admits are irksome.  If Microsoft succeeds in
imposing Microsoft Root Control, then it becomes even harder to
install free software, as compared to running a Microsoft OS
which is already loaded on the box at point of sale.  If we let
them, Microsoft will have erected yet another barrier to running
free software.

ad diction: SecureBoot does not mean secure boot in the
situation where a large rich entity hostile to free software
holds the unique key which allows booting on the hardware.  To
continue to call the arrangement under which Microsoft holds the
root key to the hardware SecureBoot is inaccurate.  If any
Fedora developer uses the term without explanation of its real
meaning, that developer suggests to those listening, that the
developer thinks that Microsoft holding the root key is more
secure than Fedora holding the root key, or the owner of the
hardware holding the root key.

It is ridiculous to use a term invented by Microsoft to mislead
people who do not understand that SecureBoot means Root Control
by Microsoft.


If spreading to some users means losing some freedom, then I think that is
against the mission.

We are not loosing any freedom we are implementing a technology that
makes fedora work out of the box on newer hardware.

No, if we have to beg Microsoft for permission to conveniently
install Fedora, we have lost our freedom to conveniently, without
asking permission of Microsoft, install Fedora.  Why should we
beg Microsoft for a power which last month we had, and which
Microsoft has seized to itself?

Of course the actions by Microsoft are against anti-trust law in
the US and in Europe grossly violate the rule against tying of
software and hardware.  And claiming Why you could pirouette and
do a handspring backwards, and if Microsoft agrees, then you can
install Fedora, so there is no extra bar to installation. is
incorrect.  Before now we did not have to do the pirouette and
handspring.  Before the New Microsoft Regime of Booting, we did
not have to beg Microsoft to sign our keys.

No.  Our side must here stand and fight.

oo--JS.

+1

--
Stephen Clark
*NetWolves*
Director of Technology
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: *countable infinities only

[Steve Clark]

On 06/02/2012 11:27 AM, Chris Adams wrote:

Once upon a time, Kevin Koflerkevin.kof...@chello.at  said:

And I don't think having to disable Secure Boot in the firmware is a
hurdle which will make our users simply walk away. I didn't simply walk
away either back in the day where RHL wouldn't boot without disabling the
Plug and Play operating system option in the BIOS.

You are far from an average user though.  There are lots of users that
Fedora would like to target that would flinch (at a minimum) when told
they have to change their firmware settings first.  Even more would be
disturbed when you tell them that to run Fedora you have to disable an
option called Secure Boot (but I want my system to be secure!).

You can try to explain it all you want, but they'll latch on to the
disable Secure Boot and glaze over any explanation.

Developers will not have a big problem; they're used to having to enable
special options and such for some development or testing work.  Fedora
isn't just supposed to be for developers though.

Who are these users? I have been using Linux since 0.99 while working with many 
users of Windows,none of them
expressed an interest in trying linux.

--
Stephen Clark
*NetWolves*
Director of Technology
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: *countable infinities only

[Steve Clark]

On 06/02/2012 05:26 PM, drago01 wrote:

On Sat, Jun 2, 2012 at 11:14 PM, Gregory Maxwellgmaxw...@gmail.com  wrote:


  I think regressing to the installs
being somewhat easier than ten yearsish ago is still a better place to
be than the cryptographic lockdown.

I disagree and once again it is not a lockdown as people who care
enough can disable it, while having it enabled by default makes things
easier for a large set of (potential) users.


Who are these potential users? How many people running windows have you 
convinced to also
load Linux? I have been using Linux since 0.99 and have not been able to 
convince any to use Linux.

And if we have the choice between make it easier to modify every part
of the OS vs. make it easier to instal the OS in the first place
... no one thinking rationally would opt for the former.

Besides installation and modification aside it does provide another
additional value ... which is added security which is a welcome
addition in some environments.



--
Stephen Clark
*NetWolves*
Director of Technology
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: *countable infinities only

[Steve Clark]

On 06/02/2012 07:55 PM, Chris Adams wrote:

Once upon a time, Steve Clarkscl...@netwolves.com  said:

Who are these users? I have been using Linux since 0.99 while working with
many users of Windows,none of them
expressed an interest in trying linux.

Well, we obviously have different friends.  I've got lots of technical
friends (and my father) that don't spend all day working on computers,
just using them (telecom engineers, rocket scientists, etc.).  A number
of them have asked me about Linux over the years, and I've helped them
get started and help with occasional problems.

As for since 0.99: I remember when a friend told me about this post he
saw in the Minix newsgroup.  Unfortunately, I didn't have a 386 at the
time. :)


I worked with developers where we were developing for Unix and they wanted to 
uses PC's running Windows and not
FreeBSD or Linux, go figure. I would think your friends would be able to handle 
disabling secure boot to load fedora.

--
Stephen Clark
*NetWolves*
Director of Technology
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: *countable infinities only

[Steve Clark]

On 06/02/2012 08:20 PM, Matthew Garrett wrote:

On Sat, Jun 02, 2012 at 07:51:52PM -0400, Steve Clark wrote:


Who are these potential users? How many people running windows have you 
convinced to also
load Linux? I have been using Linux since 0.99 and have not been able to 
convince any to use Linux.

It's possible that this says more about you or the people you meet than
anything else.


So an ad hominem attack as opposed to facts to answer the question - nice.

--
Stephen Clark
*NetWolves*
Director of Technology
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: *countable infinities only

[Steve Clark]

On 06/02/2012 08:56 PM, Matthew Garrett wrote:

On Sat, Jun 02, 2012 at 08:43:41PM -0400, Steve Clark wrote:

On 06/02/2012 08:20 PM, Matthew Garrett wrote:

On Sat, Jun 02, 2012 at 07:51:52PM -0400, Steve Clark wrote:


Who are these potential users? How many people running windows have you 
convinced to also
load Linux? I have been using Linux since 0.99 and have not been able to 
convince any to use Linux.

It's possible that this says more about you or the people you meet than
anything else.


So an ad hominem attack as opposed to facts to answer the question - nice.

No, I mean that your anecdote tells you nothing about the population,
only about the people involved. Spend time in Bugzilla or on the forums
and you'll find no shortage of people who have come to Linux from
Windows. If you've never met these people then that just means that you
haven't met them, not that they don't exist.


But don't you think that if they are determined enough to go to bugzilla and 
make an entry they
are smart enough to turn off secure boot? I guess my feeling is that people 
that have the where
withall to attempt to load another OS on their Windows box won't be afraid to 
disable secure boot
especially if it is explained to them why they need to.

--
Stephen Clark
*NetWolves*
Director of Technology
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: *countable infinities only

[Steve Clark]

On 05/31/2012 09:14 PM, Kevin Kofler wrote:

Chris Adams wrote:

- Secure boot is required to be able to be disabled on x86 (the only
platform Fedora will support it).

And this is exactly why we should just require our users to disable it!

I don't see any advantage at all from supporting this feature, just
problems:
* extra restrictions added to GRUB and the kernel to comply with the
security (lockout) requirements. Even if they're all conditional on
secure boot being enabled (are they really?), that still means extra code
which can cause extra breakage even when running in normal mode (the one
every Free Software user should be using).
* possible GPL violation. Did Red Hat Legal have a look at the plans
already? Are they sure they're compliant with the GPL, v2 when it comes to
the kernel, v3 when it comes to GRUB 2? (What's sure is that they aren't
compliant with the spirit of the GPL, whatever version!)
* ineffectiveness of the added restrictions: Can't you still bring up a
Blue Pill with a Window$ VM even with only unsigned userspace apps? And if
we don't even allow those, where's the freedom?
* exercising your freedom to change the kernel (or even just to load an out-
of-tree module!) requires you to disable Secure (Restricted) Boot anyway,
so why support the restricted mode? (As much as I hate proprietary drivers,
you can definitely expect a horde of their users showing up at your door
with a pitchfork...)
* implicit endorsement of M$ and their signature racket (including a
monetary payment to their racketing partner Veri$ign -- was that already
made?). It might even lead M$ to drop the requirement to allow disabling
Secure Boot (or even invert it into a prohibition as on ARM!), arguing
that Linux (sic, should be GNU/Linux) supports it too anyway.
* dependence on the racket, which can change its terms at any moment.

Just saying disable 'Secure' Boot in the BIOS is the easiest solution to
the problem. I remember the days where one had to disable PlugPlay
Operating System in the BIOS to get GNU/Linux to boot at all on some
machines, it didn't cause any real problems.

 Kevin Kofler


+100


--
Stephen Clark
*NetWolves*
Director of Technology
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Action required: Rawhide: /tmp is now on tmpfs

[Steve Clark]

On 06/01/2012 10:23 AM, Alexey I. Froloff wrote:

On Fri, Jun 01, 2012 at 09:27:16AM -0400, Brian Wheeler wrote:

my biggest problem was that tmpfs by
default allocates half of physical RAM for partition.  So I just
allocated big enough swap and added a line to /etc/fstab with
appropriate size= option.

And how is a random user supposed to know this?

In Soviet ALT Linux we didn't care about random users ;-)

In perfect world random user must be smart enough to read the
documentation.  However, this implies, that such documentation
exists and easily accessed (which at first sight is true for
Fedora).


So if things start acting up the answer is to add more swap and
mess with fstab?  WTF?

This is up to Release Managers.  Reasonable defaults in
installer, documentation, etc...


So now any software which uses /tmp for *gasp* temporary space
is now potentially broken depending on the size of the
temporary data.

Well, no software should use /tmp directly, IMO.  There's nice
environment variable $TMPDIR.  You can always point it to
$HOME/tmp for example.  And you can always turn it off if you
really need to.


Sorry guys, this feature sucks.

I like this feature, and there should be easy, well documented
way to turn it off.  I personally don't see a reason why it
should be off by default.


Since most user don't know anything about this why not leave it off and the 
sophisticated power
user can turn it on, since It is trivial to do.


--
Stephen Clark
*NetWolves*
Director of Technology
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: *countable infinities only

[Steve Clark]

On 06/01/2012 11:54 AM, drago01 wrote:

On Fri, Jun 1, 2012 at 5:40 PM, Kevin Koflerkevin.kof...@chello.at  wrote:

Cosimo Cecchi wrote:

I don't want to jump in the technicality of this discussion, but I can
only hope any solution that requires users to fiddle with BIOS
settings in order to install Fedora won't be seriously considered as
viable.

Sorry, but it's the ONLY viable solution. Any solution that removes users'
freedom (and that's the case of ANY solution which leaves Secure Boot
enabled) cannot be seriously considered as viable.

Secureboot support does *NOT* limit your freedom as long as it is
optional (the default setting does not matter).

You are either making more complex for everyone or for those that want
do develop kernel development, run out of tree drivers etc.

In case enabled secureboot is the only option (i.e we somehow refuse
to boot with it disabled) then (and only then) you can talk about
removed freedom otherwise this is just FUD.

What about on ARM?

--
Stephen Clark
*NetWolves*
Director of Technology
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: *countable infinities only

[Steve Clark]

On 06/01/2012 12:02 PM, Cosimo Cecchi wrote:

On Fri, 2012-06-01 at 17:54 +0200, drago01 wrote:

On Fri, Jun 1, 2012 at 5:40 PM, Kevin Koflerkevin.kof...@chello.at  wrote:

Cosimo Cecchi wrote:

I don't want to jump in the technicality of this discussion, but I can
only hope any solution that requires users to fiddle with BIOS
settings in order to install Fedora won't be seriously considered as
viable.

Sorry, but it's the ONLY viable solution. Any solution that removes users'
freedom (and that's the case of ANY solution which leaves Secure Boot
enabled) cannot be seriously considered as viable.

Secureboot support does *NOT* limit your freedom as long as it is
optional (the default setting does not matter).

The point I'm trying to make is the default setting might actually be
the most important thing that matters when it comes to new users that
want to install Fedora.

- You need to disable SecureBoot in the BIOS settings in order to
install Fedora
- BIOS settings? What's that? Oh a blueish DOS-like command-line thing?
Freaky. Disable SecureBoot? Why on earth would I want to make my system
less secure? *screw this Linux thing*

Cosimo


How many people that aren't somewhat technical are even going to think about 
installing another OS?
No many I would guess.

--
Stephen Clark
*NetWolves*
Director of Technology
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs

[Steve Clark]

On 06/01/2012 03:00 PM, Alexey I. Froloff wrote:

On Fri, Jun 01, 2012 at 01:50:55PM -0500, Michael Cronenworth wrote:

Not a single person who has claimed a performance or semantic win for
this /tmp move has replied when asked for proof.

$ time dd if=/dev/zero of=/tmp/file bs=1M count=10240
10240+0 records in
10240+0 records out
10737418240 bytes (11 GB) copied, 4.95536 s, 2.2 GB/s
dd if=/dev/zero of=/tmp/file bs=1M count=10240  0.00s user 3.44s system 69% cpu 
4.956 total

No visual shanges in system behavior.


How much memory do you have to be able to write 11GB to /tmp ???

$ time dd if=/dev/zero of=/var/tmp/file bs=1M count=10240
10240+0 records in
10240+0 records out
10737418240 bytes (11 GB) copied, 59.2188 s, 181 MB/s
dd if=/dev/zero of=/var/tmp/file bs=1M count=10240  0.00s user 54.26s system 
91% cpu 59.239 total

SSD disk.  System becomes unresponsive for a couple of tens of seconds.


$ time dd if=/dev/zero of=$HOME/file bs=1M count=10240
10240+0 records in
10240+0 records out
10737418240 bytes (11 GB) copied, 75.1548 s, 143 MB/s
dd if=/dev/zero of=$HOME/file bs=1M count=10240  0.01s user 71.30s system 94% 
cpu 1:15.16 total

SATA disk.  System becomes less responsive for a couple of seconds.


Does that counts as a proof?  ext4 on /var and /home.




--
Stephen Clark
*NetWolves*
Director of Technology
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs

[Steve Clark]

On 05/31/2012 08:57 AM, Roberto Ragusa wrote:

On 05/31/2012 12:55 PM, Ralf Corsepius wrote:

On 05/31/2012 12:45 PM, Pádraig Brady wrote:

Now /var/tmp should be more persistent which we don't need,

Correct, using /var/tmp is wrong and a mistake.

IMO, advising people to modify their code to using /var/tmp instead of /tmp is 
absurd and evidence of ignorance towards traditional use of /tmp and the FHS.


So I'll patch sort to default to /var/tmp rather than /tmp.

This would mean introducing a bug.

As far as I know:

/tmp is for large data with no expectation of reboot persistence
/var/tmp is for large data with expectation of reboot persistence

tmpfs is for *small* data, so not a good choice for /tmp,
it is certainly optimal for /var/run /var/lock and so on.

I suppose that an additional small-tmp (e.g. /tmpram) could
be useful for some programs currently using tmp for very
small files. But these programs should be patched to deviate
from a traditional Unix convention.
As small (and short lived) files are equally fast on tmpfs
or disk based /tmp, the whole effort is probably pointless.

What would be a really good solution is the ability to specify
very long timeouts for the VM write-back of a normal filesystem.
Having /tmp dirty data in memory for 2 hours (and immune to normal sync
commands) is the perfect approach.
Have RAM? Use RAM. RAM pressure? Becomes a normal disk.
(letting tmpfs swap is NOT the actually same thing, and I
doubt you can set tmpfs much bigger than real RAM)

It is quite easy to come up with use-cases where a small /tmp
will be a problem.

- any kind of temporary unpack/copy pattern, such as entering
a tar.gz with mc, unpacking of installation files for (mostly
proprietary) packages, ...

- vmware uses /tmp/ram0 (immediately unlinked) as guest RAM
backstore

- I personally use /tmp for large files (including ISOs of
DVD I want to burn and delete); maybe I'm the only one doing
that...

- I just discovered that my /tmp is currently 3.2GiB. The
majority of the space is for /tmp/kde-myusername/konsole*.tmp
(700MiB+520MiB+364MiB+305MiB+117MiB+), as I run konsole
with unlimited scrollback buffer and some shells have easily
been open for weeks.

If the feature is implemented and activated by default,
I will just turn it off and live happy. It will just be one more
thing in the growing list of defaults that should have never been
changed.
But be prepared to more than one or two future bugs of the
kind Oracle can't be installed, my backup program fails,
the machine slows down to a crawl and only a reboot fixes it, ...

Best regards.

+100

--
Stephen Clark
*NetWolves*
Director of Technology
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

download.fedoraproject.org ??

[Steve Clark]

Hello,

I am trying to access EPEL but download.fedoraproject.org only gives me a blank 
screen or
from yum I get

pel/metalink
 |  265 B 00:00
Could not parse metalink 
https://mirrors.fedoraproject.org/metalink?repo=epel-6arch=i386 error was
No repomd file
Error: File /var/cache/yum/i386/6/epel/metalink.xml does not exist

--
Stephen Clark
*NetWolves*
Director of Technology
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: download.fedoraproject.org ??

[Steve Clark]

On 04/24/2012 11:27 AM, Kevin Fenzi wrote:

On Tue, 24 Apr 2012 11:24:56 -0400
Steve Clarkscl...@netwolves.com  wrote:


Hello,

I am trying to access EPEL but download.fedoraproject.org only gives
me a blank screen or from yum I get

pel/metalink
|  265 B 00:00 Could not parse metalink
https://mirrors.fedoraproject.org/metalink?repo=epel-6arch=i386
error was No repomd file Error:
File /var/cache/yum/i386/6/epel/metalink.xml does not exist

Can you do:

URLGRABBER_DEBUG=1 yum install whatever-youweretryingtoinstall

and paste the last 500 lines or so?

That will usually show the issue.
Often its:

* Your machine time is vastly off so the ssl cert is not showing as
   valid yet.

* You are behind a proxy so you need to configure that.

* Your dns resolution isn't working.

Also, there's a epel-devel list or the fedora users list for end user
queries like this. ;)

kevin

None of the above:
 if I  --disablerepo=epel yum work fine.

http://download.fedoraproject.org/pub/epel/6/i386/repoview/epel-release.html

which is pointed to by http://fedoraproject.org/wiki/EPEL gives me a blank 
screen.


--
Stephen Clark
*NetWolves*
Director of Technology
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: /tmp on tmpfs

[Steve Clark]

On 04/02/2012 05:30 PM, M A Young wrote:

On Mon, 2 Apr 2012, Lennart Poettering wrote:


On Mon, 02.04.12 16:55, Steve Grubb (sgr...@redhat.com) wrote:

What about forensics? Any reboot erases information that might have been needed
to see what happened during a break in.

/tmp is already volatile and cleaned up in regular intervals. The new
clean-up on boot is just one tiny bit of additional clean-up.

there is a big difference however with files in /tmp being around for 30
days, and the files being cleaned on a reboot, which might be necessary to
get the system in a reliable enough state to do any forensics.

This also means a big change in user experience as many will be expecting
things in /tmp to remain there for a while before being deleted even if
the system is restarted or crashes.

Michael Young

I agree why does this have to be forced on everyone. Admins have the ability to 
do this now if they
want to.

--
Stephen Clark
*NetWolves*
Director of Technology
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: /tmp on tmpfs

[Steve Clark]

On 04/03/2012 11:35 AM, Chris Adams wrote:

Once upon a time, Brian Wheelerbdwhe...@indiana.edu  said:

* The competition for space between things in /tmp and VM.  When someone
abuses space in /tmp (on purpose or not) then the system is going to
start swapping and performance is going to suffer and the common
response for fixing it will end up being 'just reboot'.  That's just gross.

First, tmpfs can be swapped.  If you are swapping tmpfs files, how is
that any worse than having /tmp on a disk?  Also, if some user has taken
up lots of space in /tmp, you can LART the user and delete the files;
that's no different than a user filling up a partition by writing to
/tmp (no reboot necessary in either case).

I've been running with /tmp on tmpfs for several years, including on a
number of servers, and I've never had any unusual problem related to it.
I typically provision a little more swap on such systems, so that
there's some room for spill-over.

Also, on servers where there are users with shell access, I'll typically
limit the size of /tmp with an option in fstab (the default is RAM/2,
which can be larger than I'd like).  However, reading the feature page,
this would be harder to do, since somebody's irrational fear of
/etc/fstab is extending to /tmp.  I think that's a bad idea, especially
since the proposed feature creates yet another way to mount filesystems
(systemd-auto, /etc/fstab, and now a service for /tmp).  Really?  Two
wasn't enough?


I have been doing this also but limiting how much space can be used in 
/etc/fstab
with the size= option. To do away with being able to control this seems dumb.


--
Stephen Clark
*NetWolves*
Director of Technology
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: /usrmove? - about the future

[Steve Clark]

On 02/16/2012 08:12 AM, Steve Gordon wrote:


- Original Message -

From: Steve Clarkscl...@netwolves.com
To: Development discussions related to Fedoradevel@lists.fedoraproject.org
Sent: Thursday, February 16, 2012 6:47:03 AM
Subject: Re: /usrmove? -  about the future

On 02/15/2012 10:34 PM, Matthew Garrett wrote:

On Wed, Feb 15, 2012 at 07:23:24PM -0500, Steve Clark wrote:

On 02/15/2012 05:19 PM, mike cloaked wrote:

I use bash completion all the time every single day - I guess I
have
become a corner case!


No you haven't. All the developers I have worked with since the
early nineties use it all the
time every day. We would be lost without it.

You may have been working with them since the earliy nineties, but
the
feature was only introduced in 2.04 in 2000. Programmable
completion
is fairly modern compared to the rest of bash...


bash 1.14 used readline which had completions. Circa 1994.
Thank you very much.

And yet still, has nothing at all to do with the bash-completion package being 
discussed here.

Steve

Oops - sorry for my confusion.

--
Stephen Clark
*NetWolves*
Director of Technology
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: /usrmove? - about the future

[Steve Clark]

On 02/15/2012 05:49 AM, Panu Matilainen wrote:

On 02/15/2012 11:55 AM, Reindl Harald wrote:


Am 15.02.2012 10:53, schrieb Brendan Jones:

On 02/15/2012 10:47 AM, Reindl Harald wrote:


Am 14.02.2012 19:16, schrieb Jóhann B. Guðmundsson:

On 02/14/2012 10:23 AM, Alfredo Ferrari wrote:

Do the systemd maintainers ever read bug reports BTW?

Why do you think otherwise?

Not only read them but fix them as well.

To give you some stats

There are currently 96 Open bugs against systemd and 536 that have been closed 
at the time of this writing...

In F15 which should be the most buggied release since it was the initial 
release into the distribution only has 11
bugs

will systemctl restart ever has working autocompletion for RUNNING services?
it is a littl ebit odd the it does show STOPPED services because
restart makes ususally more sense for running ones...





You could edit /etc/bash_completion.d/systemd-bash-completion.sh to do this for 
you.

i could setup also linux from scratch
that is not the point

the question is: do systemd-developers never use TAB and type
all their stuff completly like on a windows box that they
do not recognize this at the first place?

this is a category of bug where i always expect that no
report is needed since every developer using his software
is expected to take notice of this

As you obviously haven't lost your ability to type, and your keyboard
appears to have all the necessary non-tab keys still in place: file a
bug on it if it bothers you so much.

It might be a shocking revelation to you but not everybody uses or
relies their world on bash autocompletion.

- Panu -

What world are you living in?

--
Stephen Clark
*NetWolves*
Director of Technology
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: /usrmove? - about the future

[Steve Clark]

On 02/15/2012 05:19 PM, mike cloaked wrote:

On Wed, Feb 15, 2012 at 8:30 PM, Adam Williamsonawill...@redhat.com  wrote:

On Wed, 2012-02-15 at 18:10 +0100, Reindl Harald wrote:

Am 15.02.2012 17:59, schrieb Rahul Sundaram:

On 02/15/2012 05:06 PM, Steve Clark wrote:

On 02/15/2012 05:49 AM, Panu Matilainen wrote:

It might be a shocking revelation to you but not everybody uses or
relies their world on bash autocompletion.

 - Panu -

What world are you living in?

bash-completion is not a default package.  Obviously only a small
percentage of users are going to use it.  This isn't something you need
to debate about.  If it was used by the majority, it would be there by
default already.

it is used by all professional users using mostly a terminal

yeah...I'm getting paid for this, so I guess I'm a professional user,
and I use terminals an awful lot, but I don't use bash-completion. Every
time I ever tried it I found, like Rahul, that it makes things slow and
tends to get in my way more than it ever does help me.

I use bash completion all the time every single day - I guess I have
become a corner case!


No you haven't. All the developers I have worked with since the early nineties 
use it all the
time every day. We would be lost without it.

--
Stephen Clark
*NetWolves*
Director of Technology
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: /usrmove?

[Steve Clark]

On 02/10/2012 05:28 AM, Olav Vitters wrote:

On Fri, Feb 10, 2012 at 01:11:06AM +0100, Kevin Kofler wrote:

Yes, I'm arguing that the feature is undesirable by design and should not
have been approved, not for Fedora 17, not for Fedora 18, not even for
Fedora 31337.

It has been approved, other distributions are following. It is very

Hmmm...  a google search of linux distributions implementing usrmove
only turned up Fedora related links.


clear you do not want this. But at the same time, it is happening in
Fedora and elsewhere (noticed openSUSE, will propose for Mageia 3). I
don't think additional emails will change anything about either the
feature, or your opinion.

In any case, when painting I like the colour white. Though maybe in
summer (slightly warmer times), I'll change my mind and choose purple. ;)




--
Stephen Clark
*NetWolves*
Director of Technology
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: UsrMove feature breaking yum upgrade upgrades from older releases to F17?

[Steve Clark]

On 01/27/2012 01:43 PM, Jef Spaleta wrote:

On Fri, Jan 27, 2012 at 8:43 AM, Reindl Haraldh.rei...@thelounge.net  wrote:

if you finally want have /bin as symlink forever this whole
change is only wasted time and makes no sense at all

If you haven't read the new summary write-up on the benefits of the
/user feature that I think you would benefit from reading it.
http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge

If you have read it, then I fear you either don't fully understand or
do not value the long term benefits associated with the filesystem
snapshotting nor the utility of having read-only shared vendor
supplied /usr across many guest instances.


If those stated benefits are achievable in practise, I think carrying
around a few symlinks in / till the heat death of the universe is a
reasonable cost to pay to achieve a stateless vendor OS contained in
/usr.

-jef

So this is all for the benefit of the/some Vendor?

--
Stephen Clark
*NetWolves*
Director of Technology
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: how to have yum prefer one dependency over others

[Steve Clark]

On 10/05/2011 01:51 AM, Adam Williamson wrote:

On Sat, 2011-09-17 at 13:20 +0200, Kevin Kofler wrote:


(That said, there definitely needs to be a way to disable it, and maybe it
should even be disabled by default. I personally always uninstall yum-
presto. For me, it's much faster to just download packages than to rebuild
them from deltas. Only users on really slow connections benefit from it.)

My desktop can rebuild deltas at ~3MB/sec. So even my really fast
internet connection is slower than delta rebuild.

This is a meaningless comment to other people unless you provide
information on what the specs of your desktop are or the speed of your internet 
connection.

--
Stephen Clark
*NetWolves*
Sr. Software Engineer III
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: what if native systemd service is slower than old sysvinit script?

[Steve Clark]

On 09/17/2011 01:09 AM, Adam Williamson wrote:

On Fri, 2011-09-16 at 23:22 -0400, Steve Clark wrote:


Oh, I must have misunderstood - Gene's Mailist comment:
.
   Temptinh as it might be, just please keep session management away from

the init daemon and let it do its one important job properly, robustly
and well and not suffer the path to sure death of trying to be all
things  - just coz it can coz its PID 1,2, 3 etc.

Looked like talk about session management to me.

That was the comment I replied to and said 'we're not really talking
about systemd any more'. =)

Hi Adam,

I guess I am confused by your comment based on what is stated at
http://fedoraproject.org/wiki/Features/systemd

Which explicitly states systemd System and Session Manager.
So it appears to me that Session Management is the next thing systemd
wants to do. In fact Lennart has stated that.





--
Stephen Clark
*NetWolves*
Sr. Software Engineer III
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: what if native systemd service is slower than old sysvinit script?

[Steve Clark]

On 09/16/2011 08:08 PM, Adam Williamson wrote:

On Fri, 2011-09-16 at 08:48 -0400, Genes MailLists wrote:

On 09/16/2011 05:01 AM, Olav Vitters wrote:

On Thu, Sep 15, 2011 at 05:17:43PM -0700, Adam Williamson wrote:

True. As far as GNOME goes, though, whenever you suggest 'bulletproof
session management', they say 'that's what suspend is for'...

I'd like to see proper session management. However, the existing
X protocol is terrible (a KDE'er talked about the horrors @ Desktop
Summit), and session management itself is really difficult.


   Temptinh as it might be, just please keep session management away from
the init daemon and let it do its one important job properly, robustly
and well and not suffer the path to sure death of trying to be all
things  - just coz it can coz its PID 1,2, 3 etc.

We aren't really talking about systemd any more, in this branch of the
thread.

Were not? From:
http://fedoraproject.org/wiki/Features/systemd

systemd System and Session Manager


--
Stephen Clark
*NetWolves*
Sr. Software Engineer III
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: what if native systemd service is slower than old sysvinit script?

[Steve Clark]

On 09/16/2011 11:03 PM, Rahul Sundaram wrote:

On 09/17/2011 06:33 AM, Steve Clark wrote:

Were not? From:
http://fedoraproject.org/wiki/Features/systemd

systemd System and Session Manager

That page does answer your question.  systemd can work as a session
manager but it isn't part of Fedora yet and this particular discussion
wasn't about systemd but difficulties in session management in general.

Rahul


Oh, I must have misunderstood - Gene's Mailist comment:

.
  Temptinh as it might be, just please keep session management away from

 the init daemon and let it do its one important job properly, robustly
 and well and not suffer the path to sure death of trying to be all
 things  - just coz it can coz its PID 1,2, 3 etc.


Looked like talk about session management to me.



--
Stephen Clark
*NetWolves*
Sr. Software Engineer III
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: what if native systemd service is slower than old sysvinit script?

[Steve Clark]

On 09/15/2011 02:07 AM, drago01 wrote:

On Thu, Sep 15, 2011 at 7:25 AM, Ralf Corsepiusrc040...@freenet.de  wrote:

On 09/14/2011 06:23 PM, drago01 wrote:

On Wed, Sep 14, 2011 at 5:34 PM, Ralf Corsepiusrc040...@freenet.dewrote:



snip

Anyway, some more figures: On the same machine, bootup times when
booting from a (slow) external (IDE) USB2 HD:
- Fedora 15/i386: ca. 135 secs.
- Ubuntu 11.04/i386: ca. 70 secs.

[Here bootup time: Wirst watch measured time from grub prompt to
login screen]

It shows the effect of slow disks (60secs w/ internal HD vs. 2.15
minutes w/ USB HD), but raises questions on why Ubuntu appears to be so
much faster in this configuration.

Do they both start the same services? Unless you tweaked your fedora
installation where we start a bunch of stuff that pretty much nobody
would use in a typical desktop system that is to be expected.

Is there a reason Fedora starts a bunch of stuff that pretty much nobody
would use in a typical desktop system ?

Fedora is certainly not targeted at the server/enterprise target, being on the 
bleeding edge and all.


--
Stephen Clark
*NetWolves*
Sr. Software Engineer III
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: grub / grub2 conflicts

[Steve Clark]

On 09/15/2011 12:01 PM, Matthew Garrett wrote:

On Thu, Sep 15, 2011 at 04:56:43PM +0100, Richard W.M. Jones wrote:


For grub1 guests, it has turned out not to matter which specific
version of grub [as long as it was grub1] was used, as apparently
grub-install updates all files needed in /boot/grub as appropriate.
Or at least we haven't come across a guest where this hasn't worked
(yet -- we could be in for a surprise).

The most obvious case where it can fail involves grub being effectively
unmaintained, and so various vendors have extended it in different ways.
You may end up with valid configuration files for one distribution that
can't be parsed by the grub for another. The assumption you're making is
fragile. It's even worse for grub2, since it has a built-in module
loader. Modules built for one version of grub aren't guaranteed (or even
really expected) to work when loaded into another.


Hmm... there isn't a version check to prevent this Seems sort of fragile.

I'm very interested in how to reinstall bootloaders *without* invoking
guest code.  Also in how to not break the bootloader when moving or
aligning the boot partition, which sometimes happens for reasons we
don't understand (but not on all grub1 guests, only on RHEL 5 era
grub1).

You're asking for the impossible. The only supportable bootloader for a
specific guest is the bootloader that matches the installed OS. If you
want to support grub2 on Ubuntu, for instance, you'll need Ubuntu's
grub2 - not Fedora's. The binary interface may have changed between
them.




--
Stephen Clark
*NetWolves*
Sr. Software Engineer III
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: what if native systemd service is slower than old sysvinit script?

[Steve Clark]

On 09/14/2011 04:35 AM, Jóhann B. Guðmundsson wrote:

On 09/13/2011 11:03 PM, Micha? Piotrowski wrote:

Hi

2011/9/13 Tom Lanet...@redhat.com:

(This isn't new with 9.1, btw --- the last version or so of 9.0
for F16 was the same, since we switched over to native systemd
files.)

I used this service file on F15 and it starts slower
4214ms postgresql.service

if we compare with an old SysVinit script
2469ms postgresql.service


First of all you cant reliably measure startup performance between
legacy sysv init script and a native systemd unit since either one of
those might be doing less/more.


So I wonder if it makes sense to convert in such case?

Yes systemd is bringing more to the table then just startup speed
which by the way is completely irrelevant in server environment.

I personally look at the boot decrease as an side effect not an feature.

We are still a long way from actually deliver that degreased boot time
out of the box into the hands of the desktop end users or perhaps I
should rather say there is room for plenty of improvements in that regard.

Once we have done that it willl highlight other issues such as the log
into the desktop time which currently is taking longer time for me (
Gnome it might be faster on other *DE ) than it takes to booting the
operating system.

JBG

Thats right!  Just wave your hands and say it is all ok that systemd is slower 
now but it is doing
so much more and we will make it better in the future...!

This was a simple test to start postgresql - what else needs to be done!



--
Stephen Clark
*NetWolves*
Sr. Software Engineer III
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: what if native systemd service is slower than old sysvinit script?

[Steve Clark]

On 09/14/2011 11:28 AM, Tom Lane wrote:

=?ISO-8859-2?Q?Miloslav_Trma=E8?=m...@volny.cz  writes:

2011/9/14 Jóhann B. Guðmundssonjohan...@gmail.com:

An simple test to measure this reliably is to strip down the legacy sysv
init script to the start up command only and have a strip down unit file to
the startup command only.

Then time the startup of either.

Why?  The current numbers show that the service file is _slower_ even
when the old init script is supposedly doing much more work in shell.
If anything, stripping the unessential parts should make the service
file _even slower_ in relative terms.

Yes.  The unit file is already stripped down: it does nothing except
pg_ctl start.  The init script had accumulated a whole lot of
perhaps-unnecessary sanity-checking, which frankly I'd rather have kept
but the systemd mantra seems to be no shell scripting so I didn't.

Michal's numbers look pretty damning, and I find it remarkable that the
systemd advocates seem to have managed not to read them, let alone admit

Don't confuse we with facts! I've already made up my mind! ;-)

that they suggest something's seriously wrong.

regards, tom lane



--
Stephen Clark
*NetWolves*
Sr. Software Engineer III
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: PostgreSQL 9.1 and Lucene Core for F16

[Steve Clark]

On 09/12/2011 10:55 PM, Tom Lane wrote:

Bruno Wolff IIIbr...@wolff.to  writes:

On Mon, Sep 12, 2011 at 03:16:47 -0400,
   Tom Lanet...@redhat.com  wrote:

OK, it's built and filed at
https://admin.fedoraproject.org/updates/postgresql-9.1.0-1.fc16

One thing I noticed is that service postgresql initdb and
service postgresql help no longer work. I was hoping they'd redirect
to the systemd equivalents of the old function.

I would have liked that too, but systemd is completely unfriendly to

Ahh... but this is progress !? :-(

custom actions of that sort.  The new dispensation is that you have
to do postgresql-setup initdb or postgresql-setup upgrade.
This is documented in
/usr/share/doc/postgresql-*/README.rpm-dist
and in the F16 release notes at
https://fedoraproject.org/wiki/Docs/Beats/DatabaseServers
I'm willing to document it somewhere else if you have a better idea.

(This isn't new with 9.1, btw --- the last version or so of 9.0
for F16 was the same, since we switched over to native systemd
files.)

regards, tom lane



--
Stephen Clark
*NetWolves*
Sr. Software Engineer III
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

[Steve Clark]

On 08/23/2011 01:48 PM, JB wrote:

JBjb.1234abcdat  gmail.com  writes:


...

Here are some more detailed thoughts.

Sys init.
-
Sys init as a process #1 should be beyond approach by design, and delegate
all work to other process(es), whether in a permanent or an ad-hoc manner,
that can be operated by sysadmin if needed (e.g. restarted, initialized,
configured, fixed, etc).
We want it to be minimal in its size, minimal in its functions, simple,
stable, secure (no attack venues, direct or indirect) - yes,
beyond approach.

Sockets activation and on-demand services.
--
Here is a description of how it works:
http://0pointer.de/blog/projects/socket-activation.html

The essense begins here:
Socket activation makes it possible to start all (...) services completely
simultaneously, without any kind of ordering.
...
That means the scheduling of our services is entirely done by the kernel: ,,,

Then it continues:
But it's not just about parallelization. It offers a number of other
benefits:
   ...
   We no longer need to configure dependencies explicitly. Since the sockets
   are initialized before all services they are simply available ...

   If a service dies its listening socket stays around, not losing a single
   message. After a restart of the crashed service it can continue right where
   it left off.
   ...

Well, it looks like a wunderwaffe :-)

Systemd and security - an example # 2 of an attack venue.
-
The above is dangerous as a design idea to achieve parallelization of
services.
Let's assume that service A is a dependency for service B (and others).
After A's on-demand socket has been put on hold (blocking), the A may die
or lock up for any reason, that is never to come up again by itself as
an active service.
That means there is a system lock-up possibility here while B (and others) are
on hold too (waiting for A to be unblocked), and wait ..., and wait ...

Systemd and security - an example # 1 of an attack venue.
-
Here is a possible known example:
http://www.securiteam.com/unixfocus/6U00P1PEVQ.html

We know that systemd owns the service socket-in-waiting (with its buffer).
In case of an attack on socket buffer availability via kernel the systemd is
grounded as well.
This should not be allowed to happen to process #1, the Mother of All
Processes.
One more reason to redesign the systemd to be minimal and beyond approach,
and instead have other restartable child process(es) take over the function
of on-demand socket handling.

Can you comment on that ?

JB

http://news.icanhascheezburger.com/2010/06/22/political-pictures-make-a-windows-that-doesnt-crash/




JB - do you mean beyond reproach ?

Idiom:
beyond reproach
So good as to preclude any possibility of criticism.


--
Stephen Clark
*NetWolves*
Sr. Software Engineer III
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

[Steve Clark]

On 08/22/2011 12:03 PM, JB wrote:

Steve Grubbsgrubbat  redhat.com  writes:


...
You're not seeing the hundreds - no thousands of emails about systemd?
You are not seeing that all the expected facilities of init are not covered?
There is well founded rebellion here.
...

Yes, you are right. And the people (e-mails, posts) you refer to are too.

Your concerns and those of others point to a questionable (non-UNIX) systemd
design.
Once again I refer everybody to Denys Vlasenko's thread, where this is very
visible; go over it again and you will know why:
http://lists.fedoraproject.org/pipermail/devel/2011-June/152323.html

Sys init was, and should be (as it was expected to be in systemd):
- simple, limited-in-functions, stable, and thus secure in design
- no sys init *and* services manager roles (the last one should be done by
   another (child) process and inetd-like server)
- no networking exposure due to security concerns
- no pseudo-roles like handling user sessions, login's, etc
- etc

It is not by chance that people think about a Windows-like approach in concept
and design of systemd, and even Lennart admitted to it:
I like to see it as a modular platform to build an OS from.
It comes thru, he wants systemd, with its implied world domination attitude,
to be a base for some OS-to-be; he even expects it to be some kind of
a standard every distro would adopt.

I can only say I hope not !
I would suggest that Fedora will be first to reject it as it is now.
Fedora is a BETA distro by choice, so it should be easy, prudent, and proper
to stop here and redesign systemd, with community, users and testers input.

A propos, I have here a few links to sources on UNIX philosophy.
I would suggest to everybody to not just read them (skip over them quickly),
but also think for a few minutes about each principle.
It helps clear up one's mind.

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

Eric Steven Raymond
The Art of Unix Programming
http://www.catb.org/esr/writings/taoup/
http://www.catb.org/esr/writings/taoup/html/

The Unix Philosophy
http://www.linuxjournal.com/article/2877

Enjoy it.
JB

Vivaldi - Da due venti il mar turbato - Angela Gheorghiu - 1987 (Very Rare!)
http://www.youtube.com/watch?gl=USv=8_MtYYCuFjk




+1000

--
Stephen Clark
*NetWolves*
Sr. Software Engineer III
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

[Steve Clark]

On 08/20/2011 03:31 PM, Steve Grubb wrote:

On Saturday, August 20, 2011 02:17:04 PM Lennart Poettering wrote:

On Sat, 20.08.11 09:41, Steve Grubb (sgr...@redhat.com) wrote:

On Friday, August 19, 2011 10:50:01 PM Kevin Kofler wrote:

Tim Waugh wrote:

Oh, I just noticed this:

https://fedoraproject.org/wiki/Packaging:Guidelines:Systemd#Socket_ac
tiva tion Since Fedora currently doesn't want any services to do
on-demand loading, all socket activated services must autostart.

What the heck?! We're disabling systemd's main feature there, aren't
we? Wasn't the main design concept behind systemd the observation that
everything can be parallelized most effectively by on-demand
activation?

Why is bootup speed so important that init now has become network aware?
Process 1 gets special protection from the kernel. You cannot kill it.
If there is any mistake in its code, then you have an unkillable all
powerful process that might do rogue things. It almost sounds like this
is reinventing Xinetd - except its not as feature rich as xinetd.

systemd never reads a single packet from any of the network sockets it
listens on on behalf of services. It just passes these sockets off to
the services as soon as traffic is seen on them (i.e. when POLLIN is
triggered we pass off the socket, we don't call read() on it.)

And therein lies one of the big problems that xinetd has. If its listening and 
passes
the descriptor to a child to accept and the child crashes or aborts before 
accepting
the socket, the whole mess spins in a circle where the listen descriptor is 
readable,
but nothing is accepting the connection.

But still, why is speed so important that xinetd capabilities are the answer? 
Why not
leave init not network aware and let xinetd do the on demand startup? This has 
the
advantage of being able to kill xinetd whereas init cannot be killed.



Then lets look at the accept option. If systemd accepts a connection and
passes it to a child process, do you now support tcp_wrappers so that
you deny the connection before starting the child?

We do tcpwrap checks for incoming connections. I do wonder though
whether it might be time to deprecate tcpwrap distribution-wide. I am
pretty sure firewalls are the better approach, more widely supported,
more widely understood and more widely used.

Do you remember the hole in netfilter a while back?
CVE-2001-1572
CVE-2006-4572
Its happened before and it will happen again. I'm sure this list is not 
complete.

Then some tools that help setup the firewall might accidentally leave you open:
CVE-2003-0080

Belt and suspenders! Must have both.



That would mean any flaw in tcp_wrappers now is part of process 1
which has special protection from the kernel.

We are very careful with what we execute in PID 1. For example we make
sure not to do any NSS lookups or use other code that might pull in
arbitrary libraries into PID 1. And following this logic I carefully
made sure that tcpwrap checks are not done in PID 1, but in the forked
off process shortly before we execute the process binary.

And anyway, I wouldn't overestimate the risk here. tcpwrap does not read
from the socket, it just executes syscalls like getsockname() and
getpeername() and suchlike, but does not parse potentially dangerous
network traffic.

I wrote lots of patches for tcp_wrappers, mostly to give it ipv6 capabilities. 
But
there were bugs fixed. For example, it provides many functions with names that 
are in
glibc. Which means you might get tcp_wrapper's implementation rather than 
glibc's. My
version was called socket_wrappers and it fixed a whole lot of the problems in
tcp_wrapper. So, even if you fork with the intention of not using its code in 
process
1, you might accidentally be using it.

readelf -s /lib64/libwrap.so.0.7.6 | grep FUNC | grep -v UND

Looks like someone has been doing some cleanining up, but maybe not that way on 
other
distros.

But anyways, tcp_wrapper does reverse DNS lookups to compare the forward and 
reverse
paths in case anyone has tampered with the remote DNS to make it look like the
incoming connection is legit. So, may it does not read much off the socket, its 
does a
recvfrom peek, but it does talk with remote DNS servers to make a decision. Not 
all
DNS servers are legit and can be malicious. One incoming packet can cause a 
cascade of
outgoing DNS querries.



I personally think systemd's configure should have an
--enable-networking. I think this should be turned off. A network aware
init could be internet worm material since you cannot kill process 1.

Please read up on socket activation before making such broad comments.

I feel very comfortable in saying that if you increase the attack surface of an
unkillable and all powerful process, someone will notice this and find the hole 
one day
and it might not even be in your code. You may do everything perfect and there 
is one
hole in a library that is the undoing of the system. The difference is an IPS 
system
can reach out and 

Re: Default services enabled

[Steve Clark]

On 08/20/2011 08:09 AM, Lars Seipel wrote:

On Sat, 2011-08-20 at 00:13 +0200, Reindl Harald wrote:

if you can give a warning you can also stop the socket
this is what the user expects and if your software-design
is not able to act logically it is broken

Stopping the service but leaving the possibility for later socket
activation is a valid use case. Warning about that because it also could
be a mistake is a nice service and sufficient.


How can you say that? I stopped the serivce! I don't expect it to magically 
start backup!!!
You are just plain wrong. Any system should be about doing things with the least 
surprise to the user!


service restart htt

you can type TAb the whole day and will get no auto-completion

Of course not. This is wrong syntax.

systemctl restart htttab

should do what you're trying to accomplish. If you insist on using the
service wrapper script, the appropriate syntax would be:

service htttab  restart

It does fine in both cases.


yes it is a improvent to get htis after the boot but if you restart a server
you nromally watch the boot and have no reason to login as long you see
nothing red - this was broken by the usability-pifall how systemd boots

I'm pretty certain that failures are colored red. Are you sure you got
your facts right?

Lars




--
Stephen Clark
*NetWolves*
Sr. Software Engineer III
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 15 and mount points

[Steve Clark]

On 08/12/2011 11:03 AM, Reindl Harald wrote:


Am 12.08.2011 17:00, schrieb Tomasz Torcz:

On Fri, Aug 12, 2011 at 10:46:27AM +0200, Reindl Harald wrote:

I thought that their outputs, especially that of findmnt, would've
clarified the output of mount, except for the three sandbox bind
mounts.

Suggestions for replacing mount in your scripts:
findmnt -lnu -o SOURCE,TARGET,FSTYPE,OPTIONS
findmnt -lnsu -o SOURCE,TARGET,FSTYPE,OPTIONS
findmnt -o SOURCE,TARGET,FSTYPE,OPTIONS -S /dev/sda1
findmnt -o SOURCE,TARGET,FSTYPE,OPTIONS -T /
findmnt -n -o SOURCE,TARGET,FSTYPE,OPTIONS -S /dev/sda1
findmnt -n -o SOURCE,TARGET,FSTYPE,OPTIONS -T /

this does not solve the problem with thousands of applications
like df, mlocate and mount: if a change forces a lot of programs
and scripts to be changed anybody who made it is a little naive
to believe the world is turning around him and should hurry
up fixing all this apllications he broke or revert his change!

   One of Fedora's core values is first.  We do introduce new things
and instead of reverting them, we fix broken apps.  If lot of programs
have to be changed -- life is hard

who is the we fixing df and when will this happen?


Yeah and all those broken apps weren't broken til you introduced your new better 
thing.

--
Stephen Clark
*NetWolves*
Sr. Software Engineer III
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: thanks for F15 mdadm systemd unit

[Steve Clark]

On 07/22/2011 01:16 PM, drago01 wrote:

On Fri, Jul 22, 2011 at 4:53 PM, Reindl Haraldh.rei...@thelounge.net  wrote:

Am 22.07.2011 16:33, schrieb drago01:

On Thu, Jul 21, 2011 at 1:38 PM, Reindl Haraldh.rei...@thelounge.net  wrote:


Am 21.07.2011 13:14, schrieb Bryn M. Reeves:

On 07/20/2011 11:05 PM, Reindl Harald wrote:

hopefully systemd will aslo live for 40 years as sysvinit
did or the next replacement will be finished BEFORE release
including the correspondending parts of the distribution

Just to be clear as this has been mentioned several times in recent threads:
System V style initialisation is _not_ 40 years old. SysV was only released in
1983 (and even after that time there were alternatives - the BSDs never adopted
this approach to system initialisation).

so let it be 28 years now

Still way too old ... technology has advanced a lot in the past 28 years

this is poor argumentation which too many peopole follow unreflected

Its not any poorer then it has been like that for 28 years so don't
dare to change it.
Where the sole reason for this kind of arguments seem to be I
can't/don't want to learn anything new ... which is really tiresome.
Working with technology like this requires change and / or learning
something new at some point. You cant just get used to one thing and
think you can stick to that for the rest of your life.

I don't think there would be so much push back if it was painless to people and 
didn't break things.

I know it is very frustrating to me when stuff that worked now all of sudden 
doesn't because somebody decided
that we have better, faster, newer way of doing things so lets do it!

Sound in fedora a few years ago under went this exact scenario and it took a 
couple of releases for me before it became
somewhat stable again.

--
Stephen Clark
*NetWolves*
Sr. Software Engineer III
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: thanks for F15 mdadm systemd unit

[Steve Clark]

On 07/21/2011 07:38 AM, Reindl Harald wrote:


Am 21.07.2011 13:14, schrieb Bryn M. Reeves:

On 07/20/2011 11:05 PM, Reindl Harald wrote:

hopefully systemd will aslo live for 40 years as sysvinit
did or the next replacement will be finished BEFORE release
including the correspondending parts of the distribution

Just to be clear as this has been mentioned several times in recent threads:
System V style initialisation is _not_ 40 years old. SysV was only released in
1983 (and even after that time there were alternatives - the BSDs never adopted
this approach to system initialisation).

so let it be 28 years now

the last ten years subsystems are coming and going every
incarnation/replacment is hyped as so much better, has
a lot of bugs which are fixed over some years and if most
of them are fixed the next guy thinks he has a better
replacement

in the past there were real developers which was able to
maintain and optimize code over a long time without
permanently break backward-compatible, these days people
start to throw away and begin from scratch in the hope
they will not make old mistakes and suboptimal software-design
again what is true, they all make a lot of new/other mistakes
and as d said - as soon as they fixed it is called outdated
and will be replaced again






+100

--
Stephen Clark
*NetWolves*
Sr. Software Engineer III
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: systemd: Is it wrong?

[Steve Clark]

On 07/10/2011 05:46 AM, Jon Masters wrote:

On Sat, 2011-07-09 at 23:32 -0400, Steve Dickson wrote:

On 07/08/2011 10:57 AM, Lennart Poettering wrote:

Or in other words: configuration via command line arguments or
environment variables sucks.

I disagree. It doesn't suck. It's the way UNIX and Linux have done this
for dozens of years, and it's the way countless sysadmins know and love.
Sucks might be true from the point of view of hey look at this great
thing I just designed, but it's very much not true from the point of
view of the sysadmin working on the weekend who's just thinking gee,
what the heck is going on, why won't this just work how it has done for
the past twenty years?. In other words suck depends on viewpoint.

Jon.

This is so true - every admin knows the shell - now we have to learn another 
new bunch of
stuff - and for what benefits?





--
Stephen Clark
*NetWolves*
Sr. Software Engineer III
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: systemd: Is it wrong?

[Steve Clark]

On 07/10/2011 11:32 AM, Matthew Garrett wrote:

On Sun, Jul 10, 2011 at 05:46:18AM -0400, Jon Masters wrote:


I disagree. It doesn't suck. It's the way UNIX and Linux have done this
for dozens of years, and it's the way countless sysadmins know and love.
Sucks might be true from the point of view of hey look at this great
thing I just designed, but it's very much not true from the point of
view of the sysadmin working on the weekend who's just thinking gee,
what the heck is going on, why won't this just work how it has done for
the past twenty years?. In other words suck depends on viewpoint.

The big kernel lock doesn't suck. It's the way SMP UNIX did things for
dozens of years, and it's the way countless kernel hackers know and
love. Sucks might be true from the point of view of hey look at this
great fine-grained locking I just designed, but it's very much not true
from the poit of the driver author working on the weekend who's just
thinking gee, what the heck is going on, why won't this just work how
it has done for the past twenty years?. In other words suck depends
on viewpoint.

Improvement means change, and change will inevitably upset some people
who would prefer to do things in exactly the same way that they always
have done. If we assert that all viewpoints are equally valid then every
single thing we've done in Fedora sucks. In this case there are sound
technical arguments against configuration by command line argument or
environment variable (just like there are against the BKL), and while we
should obviously attempt to make any transition as painless as possible
for administrators, that doesn't serve as a counter to those technical
arguments. They suck. Unarguably.


What are the benefits of systemd - other than it is the new fantastic, 
wonderful latest gizmo!

--
Stephen Clark
*NetWolves*
Sr. Software Engineer III
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: systemd: Is it wrong?

[Steve Clark]

On 07/10/2011 01:49 PM, Matthew Garrett wrote:

On Sun, Jul 10, 2011 at 11:49:19AM -0500, Chris Adams wrote:


Command line arguments and/or environment variables allow script-based
startup to adapt to current conditions without having to edit a
configuration file.  Now maybe you could argue that every program should
figure out relevant things for itself, but here in the real world, that
will never be the case.

The suggestion isn't that having the options is wrong, it's that having
them as the primary means of configuration is poor design. If your
entire configuration takes the form of a shell script that constructs a
set of command line options then you've increased fragility for no
benefit. Having a proper configuration file and allowing admins to
override specific aspects of that from the command line isn't a problem.


This is just your opinion - where in the else it this mantra preached.

--
Stephen Clark
*NetWolves*
Sr. Software Engineer III
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: systemd: Is it wrong?

[Steve Clark]

On 07/10/2011 04:20 PM, Matthew Garrett wrote:

On Sun, Jul 10, 2011 at 03:15:33PM -0400, Jon Masters wrote:

On Sun, 2011-07-10 at 16:32 +0100, Matthew Garrett wrote:

On Sun, Jul 10, 2011 at 05:46:18AM -0400, Jon Masters wrote:
The big kernel lock doesn't suck. It's the way SMP UNIX did things for
dozens of years, and it's the way countless kernel hackers know and
love. Sucks might be true from the point of view of hey look at this
great fine-grained locking I just designed, but it's very much not true
from the poit of the driver author working on the weekend who's just
thinking gee, what the heck is going on, why won't this just work how
it has done for the past twenty years?. In other words suck depends
on viewpoint.

I get your analogy, and your point. But there's a key difference. In the
kernel community (which is relatively much smaller), there are
established well documented means by which people find out about things
like BKL removal and act upon it. There is LWN, there is LKML, there is
an expectation that those working on the kernel read these things.

We have documentation and we have release notes. There's an expectation
that admins pay attention to these things.


There should not be, and there is not, an expectation that Linux users
and admins in the wider world follow distribution mailing lists, wiki
pages, and IRC obsessively. Or read blogs. That isn't how it's done.
It's done through slow, gradual change picked up over time, unless you
want the kind of pain that I believe is coming further down the line.

The systemd transition hasn't been rapid, and what we're talking about
here is a change in best practices rather than a change in what's
possible. Your systemd service file can launch a shell script that execs
the daemon. You can stick with a SysV init file instead. But both
approaches change nothing regarding the intrinsic fragility of sourcing
a freeform shell script as application configuration.


Again you say best practices - where is this written, only in the minds of 
people pushing systemd.


--
Stephen Clark
*NetWolves*
Sr. Software Engineer III
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: systemd: Is it wrong?

[Steve Clark]

On 07/10/2011 05:35 PM, Matthew Garrett wrote:

On Sun, Jul 10, 2011 at 03:56:25PM -0500, Chris Adams wrote:

Once upon a time, Matthew Garrettmj...@srcf.ucam.org  said:

The suggestion isn't that having the options is wrong

Well, that's what you said before (conveniently snipped from your
reply).  You compared CLI args/env vars to the BKL as something to be
eliminated; specifically, you said (and I quoted):


In this case there are sound
technical arguments against configuration by command line argument or
environment variable

You have still failed to enumerate even one of the sound technical
arguments.

Configuration by, not overriding configuration. It's a mistake to have

Says you. It has seemed to work OK for the last 25+ years. I don't ever 
remember having a problem
in my 25+ years of working with UNIX/LINUX with the existing initscripts. Where 
are the BZ reports
that we are fixing with systemd?

your daemon's configuration be handled by a shell script that's sourced
into existing environment. It's reasonable for an admin to override
configuration on an as-needed basis.


it's that having
them as the primary means of configuration is poor design. If your
entire configuration takes the form of a shell script that constructs a
set of command line options then you've increased fragility for no
benefit. Having a proper configuration file and allowing admins to
override specific aspects of that from the command line isn't a problem.

You are moving the target (to a worst-case example) and still not
winning your argument.

The discussion was about having significant quantities of configuration
in /etc/sysconf in the form of shell fragments.


This is more than theoretical to me; a small package I maintain is one
example of a command-line configured daemon.  The shmpps daemon is a
tiny little daemon that reads a timing pulse-per-second and updates a
shared memory segment.  It uses a few command line arguments to set the
source port/type and shared memory segment destination; right now, that
is done for the init script by a file in /etc/sysconfig.

And that's a bad thing to do. You're sourcing your configuration in an
unsanitised environment. There's a huge number of ways that this can go
wrong depending on the admin's local configuration, which is clearly
undesirable.


This is a small, light-weight daemon, and doesn't need a configuration
file parser.  This is a valid way that Unix daemons have run for
decades, and you are saying that should be removed.  I guess every small
daemon now needs to include its own config file parser, replacing the
already-existing getopt() call?  How is this better?

Nobody's said it should be removed. Lennart's said that it sucks, and I
agree. But all of this would still be better with a simple config parser
that's shared between any daemons that want it.




--
Stephen Clark
*NetWolves*
Sr. Software Engineer III
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: glibc 2.14-4 eats my data (Re: F15 ext3, eCryptfs + samba = data corruption (Re: F15 Error mounting eCryptfs: [-5] Input/output error on different disks))

[Steve Clark]

On 07/08/2011 12:32 PM, Michał Piotrowski wrote:

W dniu 8 lipca 2011 18:21 użytkownik Michał Piotrowski
mkkp...@gmail.com  napisał:

Hi,

2011/7/8 Andreas Schwabsch...@redhat.com:

Use valgrind.

I attach valgrind output.

==1312== 1 errors in context 1 of 116:
==1312== Source and destination overlap in memcpy(0xaef1590, 0xaef1593, 76)
==1312==at 0x4C283B6: memcpy@@GLIBC_2.14 (mc_replace_strmem.c:653)
==1312==by 0x401835: ??? (in /sbin/mount.ecryptfs)
==1312==by 0x5E3039C: (below main) (in /lib64/libc-2.14.so)

I installed ecryptfs-utils-debuginfo package and now it's more readable

==1815== 1 errors in context 1 of 116:
==1815== Source and destination overlap in memcpy(0xaef1590, 0xaef1593, 76)
==1815==at 0x4C283B6: memcpy@@GLIBC_2.14 (mc_replace_strmem.c:653)
==1815==by 0x401835: main (string3.h:52)



So it does appear to be related to the memcpy change in libc.

Could this be related to
  - Fix static linking with checking x86/x86-64 memcpy (BZ#12653)
or is it an eCryptfs problem?


Andreas.

--
Andreas Schwab, sch...@redhat.com
GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84  5EC7 45C6 250E 6F00 984E
And now for something completely different.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel



--
Stephen Clark
*NetWolves*
Sr. Software Engineer III
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: glibc 2.14-4 eats my data (Re: F15 ext3, eCryptfs + samba = data corruption (Re: F15 Error mounting eCryptfs: [-5] Input/output error on different disks))

[Steve Clark]

On 07/08/2011 01:19 PM, Michał Piotrowski wrote:

2011/7/8 Jakub Jelinekja...@redhat.com:

On Fri, Jul 08, 2011 at 01:12:04PM -0400, Steve Clark wrote:

So it does appear to be related to the memcpy change in libc.

So eCryptfs is buggy, just fix it.
The compatibility stuff that has been added to glibc to workaround
buggy old programs was just for programs linked against old glibc.
If you compile it again and you want it still working, fix it.
It isn't that hard.

I'll try tomorrow, I hope it is obvious bug.


memove should be used if areas overlap that are being copied.

Jakub
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel







--
Stephen Clark
*NetWolves*
Sr. Software Engineer III
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: glibc 2.14-4 eats my data (Re: F15 ext3, eCryptfs + samba = data corruption (Re: F15 Error mounting eCryptfs: [-5] Input/output error on different disks))

[Steve Clark]

On 07/07/2011 01:13 PM, Michał Piotrowski wrote:

Hi,

When I did a glibc downgrade to 2.13.90-9 eCryptfs mount problem no
longer appears, also there is no data corruption problem. Glibc
changes somehow breaks eCryptfs and probably also samba.

W dniu 5 lipca 2011 21:25 użytkownik Michał Piotrowski
mkkp...@gmail.com  napisał:

W dniu 5 lipca 2011 21:13 użytkownik nodatal...@nodata.co.uk  napisał:

On 05/07/11 21:11, Michał Piotrowski wrote:

Hi,

W dniu 16 czerwca 2011 21:37 użytkownik Michał Piotrowski
mkkp...@gmail.comnapisał:

Hi,

Do anyone noticed any problems with mounting eCryptfs recently on F15?
It seems to me unlikely that I have an I/O errors on few disks.
Especially if only eCryptfs reports them.


I've got two dirs

/home/s1 - ext3
/home/s2 - ext3 + eCryptfs

If I copy a file from my laptop to /home/s1 it has md5 sum
c7da3acc8e85f64661b49b9788771bf6
when I copy this file from shell to /home/s2 it has the same md5 sum
c7da3acc8e85f64661b49b9788771bf6

If I copy the same file from my laptop to /home/s2 I get a strange error
in Total commander please remove the write protection - TC's progress bar
doesn't show any progress - after copying file has correct size, but
it's totally
broken - md5 sum
f26767c3aed2f6e639ddb9ad6601daaf

Does anyone have any idea what could be wrong? I guess that data corruption
problem is related to this strange Error mounting eCryptfs: [-5]
Input/output error
message.



Check dmesg,

nothing here


your the logs

Some samba problem

Jul  5 21:21:21 ozzy smbd[6939]: [2011/07/05 21:21:21.750117,  0]
lib/util_sock.c:1514(matchname)
Jul  5 21:21:21 ozzy smbd[6939]:   matchname: host name/address
mismatch: :::192.168.101.100 != dio
Jul  5 21:21:21 ozzy smbd[6939]: [2011/07/05 21:21:21.751328,  0]
lib/util_sock.c:1635(get_peer_name)
Jul  5 21:21:21 ozzy smbd[6939]:   Matchname failed on dio
:::192.168.101.100
Jul  5 21:21:30 ozzy smbd[4815]: [2011/07/05 21:21:30.603368,  0]
lib/util_sock.c:680(write_data)
Jul  5 21:21:30 ozzy smbd[4815]: [2011/07/05 21:21:30.604101,  0]
lib/util_sock.c:1441(get_peer_addr_internal)
Jul  5 21:21:30 ozzy smbd[4815]:   getpeername failed. Error was Drugi
koniec nie jest połączony
Jul  5 21:21:30 ozzy smbd[4815]:   write_data: write failure in
writing to client 0.0.0.0. Error Przerwany potok
Jul  5 21:21:30 ozzy smbd[4815]: [2011/07/05 21:21:30.607351,  0]
smbd/process.c:79(srv_send_smb)
Jul  5 21:21:30 ozzy smbd[4815]:   Error writing 62 bytes to client.
-1. (Drugi koniec nie jest połączony)
Jul  5 21:21:30 ozzy smbd[4815]: [2011/07/05 21:21:30.608346,  0]
lib/util_sock.c:680(write_data)
Jul  5 21:21:30 ozzy smbd[4815]: [2011/07/05 21:21:30.608883,  0]
lib/util_sock.c:1441(get_peer_addr_internal)
Jul  5 21:21:30 ozzy smbd[4815]:   getpeername failed. Error was Drugi
koniec nie jest połączony
Jul  5 21:21:30 ozzy smbd[4815]:   write_data: write failure in
writing to client 0.0.0.0. Error Przerwany potok
Jul  5 21:21:30 ozzy smbd[4815]: [2011/07/05 21:21:30.610048,  0]
smbd/process.c:79(srv_send_smb)
Jul  5 21:21:30 ozzy smbd[4815]:   Error writing 55 bytes to client.
-1. (Drugi koniec nie jest połączony)
Jul  5 21:21:30 ozzy smbd[4815]: [2011/07/05 21:21:30.612862,  0]
lib/util_sock.c:680(write_data)
Jul  5 21:21:30 ozzy smbd[4815]: [2011/07/05 21:21:30.613797,  0]
lib/util_sock.c:1441(get_peer_addr_internal)
Jul  5 21:21:30 ozzy smbd[4815]:   getpeername failed. Error was Drugi
koniec nie jest połączony
Jul  5 21:21:30 ozzy smbd[4815]:   write_data: write failure in
writing to client 0.0.0.0. Error Przerwany potok
Jul  5 21:21:30 ozzy smbd[4815]: [2011/07/05 21:21:30.615032,  0]
smbd/process.c:79(srv_send_smb)
Jul  5 21:21:30 ozzy smbd[4815]:   Error writing 53 bytes to client.
-1. (Drugi koniec nie jest połączony)
Jul  5 21:21:30 ozzy smbd[4815]: [2011/07/05 21:21:30.616071,  0]
lib/util_sock.c:680(write_data)
Jul  5 21:21:30 ozzy smbd[4815]: [2011/07/05 21:21:30.616580,  0]
lib/util_sock.c:1441(get_peer_addr_internal)
Jul  5 21:21:30 ozzy smbd[4815]:   getpeername failed. Error was Drugi
koniec nie jest połączony
Jul  5 21:21:30 ozzy smbd[4815]:   write_data: write failure in
writing to client 0.0.0.0. Error Przerwany potok
Jul  5 21:21:30 ozzy smbd[4815]: [2011/07/05 21:21:30.617768,  0]
smbd/process.c:79(srv_send_smb)
Jul  5 21:21:30 ozzy smbd[4815]:   Error writing 75 bytes to client.
-1. (Drugi koniec nie jest połączony)
Jul  5 21:21:30 ozzy smbd[4815]: [2011/07/05 21:21:30.619713,  0]
lib/util_sock.c:680(write_data)
Jul  5 21:21:30 ozzy smbd[4815]: [2011/07/05 21:21:30.620268,  0]
lib/util_sock.c:1441(get_peer_addr_internal)
Jul  5 21:21:30 ozzy smbd[4815]:   getpeername failed. Error was Drugi
koniec nie jest połączony
Jul  5 21:21:30 ozzy smbd[4815]:   write_data: write failure in
writing to client 0.0.0.0. Error Przerwany potok
Jul  5 21:21:30 ozzy smbd[4815]: [2011/07/05 21:21:30.621454,  0]
smbd/process.c:79(srv_send_smb)
Jul  5 21:21:30 ozzy smbd[4815]:   Error writing 75 bytes to client.
-1. (Drugi koniec nie jest 

Re: SYSTEMD: Give us a option for upstart

[Steve Clark]

On 06/23/2011 03:29 AM, Benny Amorsen wrote:

Steve Clarkscl...@netwolves.com  writes:


If your are concerned with boot times suspend to disk!

Suspend to disk is dead slow even with an SSD. That really is no
alternative.

Suspend to RAM is nice when it works which is about 4 times out of 5 on
this laptop. (A great improvement over a few years ago, by the way).


/Benny

Suspend to disk on my 2gb 5 year old laptop takes about 15 seconds. I don't 
think that is slow.

--
Stephen Clark
*NetWolves*
Sr. Software Engineer III
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: SYSTEMD: Give us a option for upstart

[Steve Clark]

On 06/23/2011 08:49 AM, Reindl Harald wrote:


Am 23.06.2011 14:10, schrieb Steve Clark:

On 06/23/2011 03:29 AM, Benny Amorsen wrote:

Steve Clarkscl...@netwolves.com  writes:


If your are concerned with boot times suspend to disk!

Suspend to disk is dead slow even with an SSD. That really is no
alternative.

Suspend to RAM is nice when it works which is about 4 times out of 5 on
this laptop. (A great improvement over a few years ago, by the way).


/Benny

Suspend to disk on my 2gb 5 year old laptop takes about 15 seconds.
I don't think that is slow

and you think while booting the system needs to read 2 GB from disk as after
suspend? try this with moden hardware with 8 or 16 GB RAM:-)


Hi Reindl,

I don't think you understand me. I think that justification for using systemd 
because it lead to faster boot ups
is not a valid justification.


--
Stephen Clark
*NetWolves*
Sr. Software Engineer III
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: The behaviour of systemctl.

[Steve Clark]

On 06/19/2011 10:25 PM, Matthew Garrett wrote:

On Sun, Jun 19, 2011 at 07:09:14PM -0400, Steve Clark wrote:


Aaron, haven't you figured it out yet? As far as Lennart is concerned it
is his way or the highway!

My $.02 after following all the threads about sysemd/ctl.

Steve,

This is a technical mailing list and this kind of response is
unproductive. If you have significant technical issues with the design
of systemd then take them up in the appropriate way. Belittling
contributors because of perceived notions of their behaviour is
inappropriate.

(For what it's worth, I've never had any trouble getting a useful
response from Lennart when I've raised a technical issue with him)


That is the issue. In every discussion I have seen Lennart and all his 
supporters say well if you don't like it
use something else. Show me on example where it has been otherwise in the last 
month on this mailing list.



--
Stephen Clark
*NetWolves*
Sr. Software Engineer III
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: The behaviour of systemctl.

[Steve Clark]

On 06/19/2011 06:54 AM, Aaron Sowry wrote:

On Sun, Jun 19, 2011 at 10:03:05AM +0100, Martin Dengler wrote:

Your point about column headers is taken (explicitly, in my mail) and
bears no more repeating since there's a bug about it.

I didn't realise there was a bug for this, which is it?


Your point about paging continues to be that you don't like it for the
purist reason that unix-y tools shouldn't format their output.

This is not just purism for purism's sake, I think the point is being lost here
somewhere. To clarify, coding applications in this way results in:

- Additional code to deal with output logic in different situations, which like
all code, is potentially buggy. This is especially true when there is
distribution-specific logic in the code.

- Additional flags and corresponding documentation to modify behaviour which has
been imposed on you by the author (--no-pager, adding/removing column headers,
enabling/disabling --full output)

- Output format from a command being non-obvious unless you are intimately 
familiar
with the specific output logic of the command.

- Additional dependencies and potential non-portability to other systems which
may not satisfy these dependencies.

- Increased learning curve, since behaviour differs from most other commonly
used applications.

The list goes on. If you want to call it purism then fine, just don't pretend
there are no valid reasons for it.


I'm happy this is the default.  If you're not, why
not file a bug?  It's more effective than complaining on a downstream
mailing list.

I already did, bug 713567. It was CLOSED WONTFIX within 45 minutes.

/Aaron

Aaron, haven't you figured it out yet? As far as Lennart is concerned it is his 
way or the highway!

My $.02 after following all the threads about sysemd/ctl.

--
Stephen Clark
*NetWolves*
Sr. Software Engineer III
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: what key between Ctrl Alt

[Steve Clark]

On 06/17/2011 09:05 AM, Felix Miata wrote:

On 2011/06/17 08:53 (GMT-0300) Domingo Becker composed:


The shortest way is by using keyboard, as Rahul says:
1. Press the key between Ctrl and Alt.

What key between Ctrl  Alt? The last good[1] keyboards made (AFAIK) predate
keyboards with windows keys, so none of the keyboards I use routinely have them.

[1]good requires:
1-function keys grouped on left so that only fingers of one child's (small)
hand are required to use any combination of function key simultaneously with
any combination of shift key(s); readily usable purely by touch of an
experience user
2-standard inverted-T cursor keys with blank above up key and two blanks
above left and right keys
3-oversize Enter key
4-double width backspace key.

+100

--
Stephen Clark
*NetWolves*
Sr. Software Engineer III
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: what key between Ctrl Alt

[Steve Clark]

On 06/17/2011 09:43 AM, Tomas Mraz wrote:

On Fri, 2011-06-17 at 09:05 -0400, Felix Miata wrote:

On 2011/06/17 08:53 (GMT-0300) Domingo Becker composed:


The shortest way is by using keyboard, as Rahul says:
1. Press the key between Ctrl and Alt.

What key between Ctrl  Alt? The last good[1] keyboards made (AFAIK) predate
keyboards with windows keys, so none of the keyboards I use routinely have them.

[1]good requires:
1-function keys grouped on left so that only fingers of one child's (small)
hand are required to use any combination of function key simultaneously with
any combination of shift key(s); readily usable purely by touch of an
experience user
2-standard inverted-T cursor keys with blank above up key and two blanks
above left and right keys
3-oversize Enter key
4-double width backspace key.

The conditions 2, 3, 4 are still fairly commonly met although it seems
to be harder to get such keyboard recently - at least here.

However I thought that the condition 1 was abandoned when the original
IBM AT keyboards stopped shipping :). But then a short search revealed
this one:
Avant Stellar Keyboard
http://benchmarkreviews.com/index.php?option=com_contenttask=viewid=376Itemid=65limit=1limitstart=4


Good collapsible spring keyboards are still available from Unicomp.
http://pckeyboards.stores.yahoo.net/linux101.html


--
Stephen Clark
*NetWolves*
Sr. Software Engineer III
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: systemd: please stop trying to take over the world :)

[Steve Clark]

On 06/14/2011 04:06 AM, Lennart Poettering wrote:

On Mon, 13.06.11 19:02, Denys Vlasenko (dvlas...@redhat.com) wrote:


On Mon, 2011-06-13 at 12:37 -0400, Simo Sorce wrote:

On Mon, 2011-06-13 at 18:01 +0200, Denys Vlasenko wrote:

We invoke sethostname() from inside systemd since that is one of the
most trivial system calls known to men and doing this with a

separate

binary is just absurd. This way we also can ensure that the hostname

is

always initialised which is very useful for early boot logging and

other

stuff. On systemd you get the guarantee that the hostname is always

set

up if you run in userspace,

You can't possibly know what kind of (possibly dynamic) hostname
admin might want to assign to his machine. The static hostname
may be as useless as default (none) which is set by kernel.
Anyway, logging with default hostname is not a catastrophe.

Why do you set up stuff no one asked you to?

Changing a machine hostname at random times is just asking for trouble.

I just tried it. So far flames don't shoot out of my notebook.

Wow, that's convincing proof.

Lennart


One question - does systemd run /etc/rc.local script?
If not where do I put my own little things I want to happen at boot up.
--
Stephen Clark
*NetWolves*
Sr. Software Engineer III
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [Fed-Devel] Re: SYSTEMD: Give us a option for upstart

[Steve Clark]

On 06/14/2011 07:08 AM, Rahul Sundaram wrote:

On 06/14/2011 04:36 PM, Rudolf Kastl wrote:

I never proposed having alternatives for each of the core systems
either... There is already a viable alternative that works. inittab
contains atm exactly one line... the one with the default runlevel...
and /etc/fstab can be parsed differently if there are changes.

systemd doesn't use /etc/inittab and upstart uses it.  So you have to
account for the differences and test them.


Also i do not understand the Argument with the unit files... they are
systemd related. upstart isnt affected. Since upstart isnt installed
by default anyways it also doesent matter for critical path. Got a
hard time to follow your argumentation there. SystemV init scripts are
already present and work quite well aswell.

You miss the point.  Packages are already dropping init scripts and
converting to using systemd unit files.  To maintain upstart
compatibility you have to continue to maintain sys init scripts in
addition to systemd unit files and again make sure they don't diverge
and they both work equivalently.   Who is volunteering for that?

Rahul

You already are maintaining multiple UI systems which seem to me to be much 
more complex than
two different init systems.


--
Stephen Clark
*NetWolves*
Sr. Software Engineer III
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 14 and Sandy Bridge graphics

[Steve Clark]

On 06/12/2011 12:55 PM, Reindl Harald wrote:


Am 12.06.2011 18:53, schrieb drago01:

On Sun, Jun 12, 2011 at 6:45 PM, Reindl Haraldh.rei...@thelounge.net  wrote:
upstart is still maintained and shipped, you should be able to install
and use it.

and why in the world is systemd forced after a upgrade via yum where
upstart was in use before - upgrades should left core configurations
in peace!


+1

--
Stephen Clark
*NetWolves*
Sr. Software Engineer III
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: SYSTEMD: Give us a option for upstart

[Steve Clark]

On 06/12/2011 05:39 PM, Reindl Harald wrote:


Am 12.06.2011 23:35, schrieb Josh Boyer:

On Sun, Jun 12, 2011 at 5:23 PM, Reindl Haraldh.rei...@thelounge.net  wrote:

PLEASE give us a option for systems upgraded with yum
NOT USING systemd and force upstart as before

* the system is running since years
* every dist-upgrade via yum was no problem
* now see screenshot
* WTF is there to relabel if started with selinux=0-kernel-param

WHY IN THE WORLD ARE USERS FORCED TO USE SYSTEMD ONLY BECAUSE
THEY UPGRAD TO F15? DO THIS FOR NEW INSTALLATIONS BUT NEVER
ON UPDATES

I DO NOT NEED SYSTEMD ON 20 SERVERS HERE BECAUSE THEY ARE STARTING
FAST ENOUGH AND I NEED NO MAGIC WHICH THINKS KNOWS WHAT TO START
IN WHICH ORDER SINCE I KNOW WHAT IS RUNNING ON MY SYSTEMS

BULL***, I CAN'T HEAR YOU!  SOUND OFF LIKE YOU GOT A PAIR!

there is nothing bullshit

why are users of running systems are forced to change their
init-system to systemd? upstart is in the repos but ignored

WTF every three years a new pig is forced to run through the city
and if any subsystem is runnign well and debugged some idiot
comes out of his hole and try replace and force everybody
to use it


sarcasmdon't you know you will save 15-30 seconds each time you boot 
up/sarcasm

--
Stephen Clark
*NetWolves*
Sr. Software Engineer III
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: SYSTEMD: Give us a option for upstart

[Steve Clark]

On 06/12/2011 06:18 PM, Reindl Harald wrote:


Am 13.06.2011 00:13, schrieb Steve Clark:


WTF every three years a new pig is forced to run through the city
and if any subsystem is runnign well and debugged some idiot
comes out of his hole and try replace and force everybody
to use it


sarcasmdon't you know you will save 15-30 seconds each time you boot 
up/sarcasm

someone come out there and show me how will a 20 second-reboot on the
vmware-guest production servers will get 20 seconds faster

everybody out there is crying about boot / start times
have the peopole nothing to do as reboot their machines?

normally i start a computer and then it runs for a day, some weeks
or even some months, the same with open programs


I agree - saying a main feature of systemd is improved boot times is idiotic.  
I you boot your system in the morning and shut it down
at night what does 30 seconds mean out of 8*60*60 seconds? Nothing. If your are 
concerned with boot times suspend to disk!


--
Stephen Clark
*NetWolves*
Sr. Software Engineer III
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: systemd: please stop trying to take over the world :)

[Steve Clark]

On 06/10/2011 09:36 AM, Michal Schmidt wrote:

On 06/10/2011 03:07 PM, Denys Vlasenko wrote:

I understand your desire to replace everything by systemd.
I really do. syslogd, klogd, mount, fsck, and a dozen other things
I forget or don't know.

You're exaggerating.


Why does systemd link against libpam?
systemd does logins now, not /bin/login or gdm or ...?

to implement PAMName= (man systemd.exec)


libattr? Does it mean it requires filesystem which implements
extended attributes? If not, why does it use libattr then?

systemd uses libcap. libcap depends on libattr.


libwrap? systemd is a network application now too?

to implement TCPWrapName= (man systemd.exec)


libaudit? What systemd has in common with audit?

Start and stop of a service is an auditable event.
http://lists.fedoraproject.org/pipermail/devel/2010-August/141543.html


To be honest, I doubt the wisdom of implementing service manager
as an init process. There is no inherent reason why it has to be init -
you can run it as *a child of init*, and keep init very simple.
Then, if service manager would crash, at least it doesn't
take system down with it...

systemd does not take the system down when it crashes. It catches the
signal, dumps core and freezes, but does not exit.
^^^

So you just end up with a froze system instead of a crashed system

Michal



--
Stephen Clark
*NetWolves*
Sr. Software Engineer III
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: systemd: please stop trying to take over the world :)

[Steve Clark]

On 06/10/2011 09:07 AM, Denys Vlasenko wrote:

Hi Lennart,

systemd is eating a lot more memory than any other init process
I ever played with.

Granted, systemd does a bit more that typical init, but I think
using *eleven plus megabytes* of malloced space is a bit much.

systemctl --all shows 258 units total on my machine,
thus systemd uses ~40 *KILO*bytes of state per unit?

I understand your desire to replace everything by systemd.
I really do. syslogd, klogd, mount, fsck, and a dozen other things
I forget or don't know. It's called featuritis.
Now I hear about plans to incorporate ConsoleKit into it
(hearsay, so maybe it's not true).

Look where it is now:

Top:

Mem total:2035840 anon:431208 map:78924 free:419084
  slab:91624 buf:108040 cache:942336 dirty:196 write:0
Swap total:4095996 free:4095996
   PID   VSZ VSZRW   RSS (SHR)*DIRTY (SHR) STACK COMMAND
  1818  624m  365m  185m 13472  155m64   224 /usr/lib/firefox-4/firefox
  1816  433m  189m  166m 17248  142m 0   204 evolution
  1257 53672 40400 22664  6004 18336  4176   132 /usr/bin/Xorg
 1 15384 11856 13664  1340 11752 0   132 /sbin/init
^ ^ 11.7 megs of malloc space

  1839  275m 40224 24208 10572 11020 0   132 /usr/bin/gnome-terminal
  1713  202m 45284 20308  9736  9604   576   132 
/usr/libexec/xfce4/panel-plugins/xfce4-mixer-plugin
  1843  171m  9448 20264 10012  8440   344   204 xchat
  1770  152m 55672 19412 10972  6108 0   132 nautilus

It's the *fourth* largest process on my system!


# ldd `which systemd`
linux-gate.so.1 =   (0x00a6b000)
libselinux.so.1 =  /lib/libselinux.so.1 (0x414f6000)
libdbus-1.so.3 =  /lib/libdbus-1.so.3 (0x41bc1000)
libpthread.so.0 =  /lib/libpthread.so.0 (0x0019a000)
libudev.so.0 =  /lib/libudev.so.0 (0x422c9000)
libwrap.so.0 =  /lib/libwrap.so.0 (0x420fa000)
libpam.so.0 =  /lib/libpam.so.0 (0x420e6000)
libaudit.so.1 =  /lib/libaudit.so.1 (0x420cc000)
libcap.so.2 =  /lib/libcap.so.2 (0x4152f000)
librt.so.1 =  /lib/librt.so.1 (0x00be8000)
libc.so.6 =  /lib/libc.so.6 (0x00295000)
/lib/ld-linux.so.2 (0x00276000)
libdl.so.2 =  /lib/libdl.so.2 (0x00af6000)
libgcc_s.so.1 =  /lib/libgcc_s.so.1 (0x00f68000)
libnsl.so.1 =  /lib/libnsl.so.1 (0x0095c000)
libattr.so.1 =  /lib/libattr.so.1 (0x420c5000)

Why does systemd link against libpam?
systemd does logins now, not /bin/login or gdm or ...?

libattr? Does it mean it requires filesystem which implements
extended attributes? If not, why does it use libattr then?

libwrap? systemd is a network application now too?

libaudit? What systemd has in common with audit?

libdbus?... this is a lost battle I guess...

I propose to stop for a second and optimize systemd down
instead of trying to add even more bells and whistles to it.
Or else you'll soon end up linking against every /lib/lib*.so*

At the very least, I would like to see its memory consumption
to go down substantially.

It is an *init replacement*, not the replacement for everything.
One of init's goal is to be *simple* and *stable*.
Every new feature you add and library you link against
works against that goal.

To be honest, I doubt the wisdom of implementing service manager
as an init process. There is no inherent reason why it has to be init -
you can run it as *a child of init*, and keep init very simple.
Then, if service manager would crash, at least it doesn't
take system down with it...


Yes, whatever happened to the *NIX philosophy of simple non-complex programs 
that did
their job well. It has seemed to serve well since the 70's.

--
Stephen Clark
*NetWolves*
Sr. Software Engineer III
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: systemd questions

[Steve Clark]

On 05/20/2011 12:00 AM, Chuck Ebbert wrote:

On Thu, 19 May 2011 14:59:57 +0200
Lennart Poetteringmzerq...@0pointer.de  wrote:


I am sorry that reality bothers you so much, but it is the hard old real
world ...

See, I am so young, I still have the idealism that we can fix what is
broken.

And you're going to go about it by removing something that people have
been using for many years, replacing it with a vague promise of a
better solution.

Why are you so dead set against leaving what is there now so that people
can continue to run their systems? What are they supposed to use?

+1

--
Stephen Clark
*NetWolves*
Sr. Software Engineer III
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: ipv6 tools + ipv4 tools fusion.

[Steve Clark]

On 04/27/2011 11:57 PM, Paul Wouters wrote:

On Wed, 27 Apr 2011, Chuck Anderson wrote:


On Thu, Apr 28, 2011 at 02:59:09AM +0200, Reindl Harald wrote:

because the same hostname can have A and AAA records
and the people commonly use ping (sysadmins) must be
able to decide what they will test?

Use -4 -or -6 parameters if you care to force one vs. the other.

+1

It's really annoying, because ping takes a long time to fail
when you try it on an  name.


+1+1

--
Stephen Clark
*NetWolves*
Sr. Software Engineer III
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [thunderbird] Default browser is no longer read from prefs

[Steve Clark]

On 04/13/2011 03:26 AM, Christopher Aillon wrote:
 On 04/12/2011 06:40 PM, Rahul Sundaram wrote:
 On 04/13/2011 06:47 AM, Christopher Aillon wrote:
 commit 7986a8567a9dbb2a6f8187b91a021d5ad350f96f
 Author: Christopher Ailloncail...@redhat.com
 Date:   Tue Apr 12 18:15:07 2011 -0700

   Default browser is no longer read from prefs

   It's read from the system.  Too bad that means GConf for now...

   This means the open browser script isn't used either, so kill that.

 This should go into the desktop beat for the release notes along with
 the gconf key needed.

 No.  This has been the case since Fedora 11, actually.  It just didn't
 matter since gconf was where the defaults were kept anyway, and
 gnome-default-application-preferences set the gconf keys, and it never
 got cleaned out.

 Now, we're setting _gsettings_ keys in control center, so those gconf
 keys aren't getting updated when the user toggles that.  But it doesn't
 matter.  I pushed an update to the default gconf values to launch
 gvfs-open as the default browser which will read the values out of
 gsettings.

 This should all be transparent to the user, no need to document stuff
 that just works.
I think that is the wrong attitude! Because at some point it is going to break
and the poor enduser is going to have no idea why. This is the Microsoft 
attitude.


-- 
Stephen Clark
*NetWolves*
Sr. Software Engineer III
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F15: NIS, NFS mounts and systemd

[Steve Clark]

On 04/05/2011 04:08 PM, Severin Gehwolf wrote:

On Tue, 2011-04-05 at 22:03 +0200, Micha? Piotrowski wrote:

W dniu 5 kwietnia 2011 21:49 uz.ytkownik Micha? Piotrowski
mkkp...@gmail.com  napisa?:

W dniu 5 kwietnia 2011 21:48 uz.ytkownik Micha? Piotrowski
mkkp...@gmail.com  napisa?:

Try to add some informations about ordering to ypbind script

### BEGIN INIT INFO
# Provides: ypbind
# Required-Start: $local_fs $remote_fs $network
# Required-Stop: $local_fs $remote_fs $network
# Short-Description: Starts the ypbind daemon
# Description: The Apache HTTP Server is an extensible server

Without apache part :)


### END INIT INFO

or better - rewrite this POS
http://notendur.hi.is/~johannbg/systemd/etc/rc.d/init.d/ypbind to
native systemd service

I am afraid that none of these scripts
http://notendur.hi.is/~johannbg/systemd/etc/rc.d/init.d/ypbind
http://notendur.hi.is/~johannbg/systemd/etc/rc.d/init.d/yppasswdd
http://notendur.hi.is/~johannbg/systemd/etc/rc.d/init.d/ypserv
http://notendur.hi.is/~johannbg/systemd/etc/rc.d/init.d/ypxfrd
does have the correct ordering information.

I can help with rewriting to native sysetmd services, but I need a
tester - I do not use this service, so I'm not sure if I can correctly
configure and test.

Is there documentation somewhere as to how to write a native systemd
service? Thanks!

--Severin


I thought that was the GREAT thing about systemd - it would work with all the 
existing init scripts!

Sounds like it falls short.


--
Stephen Clark
*NetWolves*
Sr. Software Engineer III
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: preupgrade f13 to f14 hangs on reboot

[Steve Clark]

On 04/04/2011 10:55 AM, Przemek Klosowski wrote:

On 04/03/2011 06:04 PM, Steve Clark wrote:

I am trying to use preupgrade a fedora 13 system to fedora 14. When I
reboot the system just
hangs.

The hardware is a Jetway MB with an intel D510 cpu and 2 GB of memory
sata drive.

All I see on reboot is a blinking cursor in the upper left corner of the
screen.
I have to ctl-alt-del to get out of the hang.

It looks like it stopped booting, so either your boot environment got
damaged or the F14 kernel fails on your machine.  Does the Fedora 14
Live CD boot successfully for you? Do you have enough space in the /boot
partition? Can you boot the Live CD, spacebar into the grub menu and try
booting off the local hard disk?

Haven't tried live cd - don't have a dvd/cd drive on the box. Plenty of room in 
the /boot
partition.
/dev/sda1 485M  246M  214M  54% /boot

Grub comes up of the hard disk just fine. If I select thetitle Upgrade to 
Fedora 14 (Laughlin)
kernel /boot/upgrade/vmlinuz preupgrade 
repo=hd::/var/cache/yum/preupgrade ks=hd:/dev/sda1/upgrade/ks.cfg 
stage2=hd:/dev/sda1/upgrade/install.img
initrd /boot/upgrade/initrd.img

I just get a flashing cursor in the top left corner of the screen. I can then 
ctl-alt-del and select the f13 kernel from grub and the
system will boot back into f13.

lspci
00:00.0 Host bridge: Intel Corporation N10 Family DMI Bridge (rev 02)
00:02.0 VGA compatible controller: Intel Corporation N10 Family Integrated 
Graphics Controller (rev 02)
00:02.1 Display controller: Intel Corporation N10 Family Integrated Graphics 
Controller (rev 02)
00:1b.0 Audio device: Intel Corporation N10/ICH 7 Family High Definition Audio 
Controller (rev 02)
00:1c.0 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 1 (rev 
02)
00:1c.1 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 2 (rev 
02)
00:1c.2 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 3 (rev 
02)
00:1d.0 USB Controller: Intel Corporation N10/ICH7 Family USB UHCI Controller 
#1 (rev 02)
00:1d.1 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller 
#2 (rev 02)
00:1d.2 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller 
#3 (rev 02)
00:1d.3 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller 
#4 (rev 02)
00:1d.7 USB Controller: Intel Corporation N10/ICH 7 Family USB2 EHCI Controller 
(rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2)
00:1f.0 ISA bridge: Intel Corporation NM10 Family LPC Controller (rev 02)
00:1f.2 SATA controller: Intel Corporation N10/ICH7 Family SATA AHCI Controller 
(rev 02)
00:1f.3 SMBus: Intel Corporation N10/ICH 7 Family SMBus Controller (rev 02)
01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI 
Express Gigabit Ethernet controller (rev 03)
02:00.0 SATA controller: JMicron Technology Corp. JMB362/JMB363 Serial ATA 
Controller (rev 02)
02:00.1 IDE interface: JMicron Technology Corp. JMB362/JMB363 Serial ATA 
Controller (rev 02)
03:00.0 Network controller: Atheros Communications Inc. AR9285 Wireless Network 
Adapter (PCI-Express) (rev 01)

I was hoping maybe there were some options I could add to the kernel line to 
make it boot.



--
Stephen Clark
*NetWolves*
Sr. Software Engineer III
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

preupgrade f13 to f14 hangs on reboot

[Steve Clark]

I am trying to use preupgrade a fedora 13 system to fedora 14. When I reboot 
the system just
hangs.

The hardware is a Jetway MB with an intel D510 cpu and 2 GB of memory sata 
drive.

All I see on reboot is a blinking cursor in the upper left corner of the screen.
I have to ctl-alt-del to get out of the hang.

Any suggestions?

--
Stephen Clark
*NetWolves*
Sr. Software Engineer III
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel