Re: upstart in rawhide

[Casey Dahlin]

On Thu, Oct 14, 2010 at 11:36:53AM -0700, Adam Williamson wrote:
> On Thu, 2010-10-14 at 17:13 +0200, Petr Lautrbach wrote:
> > Hello,
> > 
> > systemd will be default init system in Fedora 15 and scripts infrastructure 
> > will be adapted to it.
> > There is a plan to leave upstart in Fedora as non-official alternative.
> 
> Why?

Same reason initng is still around: someone's willing to do the work to
maintain it. Specifically Petr (who I'll turn maintainership over to
soon).

--CJD
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Ubuntu moving towards Wayland

[Casey Dahlin]

On Fri, Nov 05, 2010 at 11:12:09AM -0400, Matthias Clasen wrote:
> On Fri, 2010-11-05 at 02:11 +0100, Dennis Jacobfeuerborn wrote:
> > Interesting move: http://www.markshuttleworth.com/archives/551
> > 
> > Has anyone looked into bringing Wayland to Fedora? If not this might be the 
> > right time getting involved in the discussion.
> > 
> > http://wayland.freedesktop.org/
> 
> Until recently, wayland required private branches of quite a few
> dependencies. But it should be possible to build wayland against F15
> packages now, or at least it should be soon. If somebody wants to give
> this a try, I'd be happy to review packages.
> 

Last time I tried the big problem was Cairo-drm wasn't enabled in our cairo
packages. Granted that was a while ago. Also I don't know the status of drivers
other than Intel getting the page-flip ioctl in the kernel, which is the other
major prerequisite.

> Wayland certainly still has a way to go before we can think about
> replacing X altogether, but many pieces of this puzzle have been falling
> into place, and with the increased interest (and hopefully
> contribution), we may see it happen sooner rather than later.
> 

The code definitely needed some more eyes last time I poked it. Its completely
undocumented in most places, duplicates macro declarations across multiple
files, and essentially implements its own version of point-to-point dbus (the
politics there aren't quite so simple, as there may be an argument for Wayland
doing its own IPC, even if it does seem rather too elaborate).

I'd love to see things move this way though.

--CJD
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Ubuntu moving towards Wayland

[Casey Dahlin]

On Sat, Nov 06, 2010 at 10:57:27AM +, Richard W.M. Jones wrote:
> We want to ditch extremely useful, ground-breaking features because of
> "tearing" when scrolling in a browser window? [I do *not* see any of

I actually read it as we want to ditch features that were groundbreaking in
1975 since the limits on technology from back then no longer mandate them and
the advances in technology today are not as easily taken advantage of with
those considerations.

Not saying you're wrong, just offering another viewpoint.

--CJD
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [ACTION REQUIRED] Retiring packages in F-16 (v3)

[Casey Dahlin]

On Thu, Jul 14, 2011 at 03:39:13PM -0400, Bill Nottingham wrote:
*snip*
> Orphan userspace-rcu

I'll take that one.

--CJD
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [ACTION REQUIRED] Retiring packages in F-16 (final warning)

[Casey Dahlin]

> Orphan rubygem-rcov

Oh, missed that one. I'll definitely take that.

--CJD
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [ACTION REQUIRED] Retiring packages in F-16 (final warning)

[Casey Dahlin]

On Wed, Jul 20, 2011 at 03:41:28PM -0400, Casey Dahlin wrote:
> > Orphan rubygem-rcov
> 
> Oh, missed that one. I'll definitely take that.
> 
> --CJD

Never mind. It has been snatched up already.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: General systemd questions in respect to Fedora project.

[Casey Dahlin]

On Thu, Jul 21, 2011 at 12:06:56AM +0400, Lucas wrote:
> On 07/20/2011 09:54 PM, Lennart Poettering wrote:
> 
> >
> >> 2. How can one disable it?
> >
> > If you build systemd you can leave it out of your build. On Fedora it is
> > enabled however.
> 
> >
> > Lennart
> >
> 
> You have just renamed Linux to Window, Fedora Linux is dead. Welcome Fedora 
> Windows.
> 
> If I will use Linux any more in the future, I promise, I will do everything 
> to remove systemd from 
> any available system.
> 
> Hopefully, I will manage to fix FreeBSD for my desktop.

So that your init system, kernel, core utils, C library, etc, can all be
written by and subject to the absolute authority of a small exclusive
set of core developers?

--CJD
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Why EDID is not trustworthy for DPI

[Casey Dahlin]

On Tue, Oct 04, 2011 at 04:17:08PM -0400, Martin Langhoff wrote:
> For fedora users, as others have mentioned, perhaps a UI that lets
> users test a couple of possible dpi values might be useful (for those
> users so inclined). It does have to cross a good chunk of the stack to
> work well, and seems like a lot of work to get right; but the xrandr
> improvements are a start.
> 

Windows used to have a gui that would show a ruler on your monitor and
say "hold a real ruler up to this and slide the slider until its the
same size." Given what's been said about how windows handles DPI I can
only wonder what it did, but it might be a nice thing to have.

--CJD
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [Test-Announce] Fedora 15 Beta RC1 Available Now!

[Casey Dahlin]

On Fri, Apr 08, 2011 at 09:25:31PM +0100, mike cloaked wrote:
> On Fri, Apr 8, 2011 at 9:19 PM, Jesse Keating  wrote:
> > On 4/8/11 12:14 PM, Christopher Aillon wrote:
> >>> Its the way we do it.
> >> F13 is the earliest mention I can find mention of "Beta RC" on
> >> devel-list.  But that doesn't really change the validity of my
> >> statement.  It's confusing, and we should change it.
> >
> > This is fair criticism.  I believe I'm the one that started referring to
> > these composes as "release candidates" more vocally.  We needed a way to
> > reference the succession of attempted composes for a release point, be
> > it Alpha, Beta, or GA.  Calling them release candidates made sense to
> > me, however I can see how they could be confusing.
> >
> > Would it make more sense to refer to these as "Alpha Candidate", "Beta
> > Candidate" and "Release Candidate" ?  ac{1,2,3}, bc{1,2}, rc1  ?
> >
> > It does mean the name will change at each stage, but it should be more
> > descriptive as to what stage we're in.
> 
> How about the sequence:
> Fn-Alpha-Pre.1 Fn-Alpha-Pre.2 . Fn-Alpha
> Fn-Beta-Pre.1 Fn-Beta-Pre.2 Fn-Beta-Pre.3  Fn-Beta
> Fn-RC1 Fn-RC2 Fn-RC3...  Fn (=release)
> 

That is certainly a different color bikeshed from the one Jesse
suggested :)

Its probably best that it be decided for certain /if/ we want to change
before we decide what the new naming convention be. Then we get the
inevitable bikeshedding argument out from under the actual issue that's
been raised here.

--CJD
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: rfc/headsup: graphics driver packaging in F16+

[Casey Dahlin]

On Tue, Apr 12, 2011 at 01:48:19PM -0400, Nathaniel McCallum wrote:
> 
> With this approach, you have lost a critical feature: the ability for
> you to change your hardware (or move the software bits to a different
> computer) and have everything automatically work.
> 
> Nathaniel

You lose it for a couple of strange usecases though:

1) Moving from a card that is up to date in what it supports to an older
card that isn't (rare).

2) Moving from one crappy ancient card to another (plausible, but still
rare).

The vesa driver should mean some workable video support in either case,
and from there, if we were really, truly concerned, we could detect the
need for the driver and prompt to install it. That's starting to sound
like the bad old days of kudzu though, and I'd be surprised if anyone
really felt this was worth that effort.

--CJD
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: rfc/headsup: graphics driver packaging in F16+

[Casey Dahlin]

On Tue, Apr 12, 2011 at 02:01:26PM -0400, Nathaniel McCallum wrote:
> On Tue, 2011-04-12 at 13:57 -0400, Casey Dahlin wrote:
> > On Tue, Apr 12, 2011 at 01:48:19PM -0400, Nathaniel McCallum wrote:
> > > 
> > > With this approach, you have lost a critical feature: the ability for
> > > you to change your hardware (or move the software bits to a different
> > > computer) and have everything automatically work.
> > > 
> > > Nathaniel
> > 
> > You lose it for a couple of strange usecases though:
> > 
> > 1) Moving from a card that is up to date in what it supports to an older
> > card that isn't (rare).
> > 
> > 2) Moving from one crappy ancient card to another (plausible, but still
> > rare).
> > 
> > The vesa driver should mean some workable video support in either case,
> > and from there, if we were really, truly concerned, we could detect the
> > need for the driver and prompt to install it. That's starting to sound
> > like the bad old days of kudzu though, and I'd be surprised if anyone
> > really felt this was worth that effort.
> 
> I think losing it in those cases is probably acceptable.  My thought is
> that the disk space for drivers is minimal, lets just support everything
> (or at least the current stuff) in a single install.  My concern isn't
> moving to and/or between rare old cards.  My concern is moving from
> nouveau to intel or radeon...  The "big" drivers should definitely be
> installed on every system, regardless of its hardware.
> 

I believe (and maybe I've read this thread to quickly) that that will
still be the case. Its only the drivers for old cards with smaller
feature sets that are being moved at alll.

--CJD
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: wireless-tools/net-tools are DEPRECATED

[Casey Dahlin]

On Wed, May 04, 2011 at 02:26:10PM -0500, Dan Williams wrote:
> On Fri, 2011-04-29 at 19:21 -0400, Chuck Anderson wrote:
> > On Fri, Apr 29, 2011 at 12:30:02PM -0500, Dan Williams wrote:
> > > Looking at the code, the 4-second delay is only used when the device is
> > > actually connected to something.  State 3 == DISCONNECTED, state 2 ==
> > > UNAVAILABLE, so it's performing as expected here.  Were there actually
> > > an IP address assigned to 'nf' then the 4-second delay would be used.
> > > Given that nothing really happens to the device when it's DISCONNECTED
> > > anyway, the logs you see are pretty much a NOP for NM.
> > 
> > I would really /love/ it if NM could log the human readable state
> > names and reason codes, rather than the cryptic numbers.
> 
> Done and rolled into the 0.8.999 (0.9-rc2) release:
> 
> http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=c4b922ed2197657dc4091fb6782e9cb8f9644af5
> https://admin.fedoraproject.org/updates/NetworkManager-0.8.999-1.fc15,NetworkManager-openswan-0.8.999-1.fc15,NetworkManager-openconnect-0.8.999-1.fc15,NetworkManager-pptp-0.8.999-1.fc15,NetworkManager-openvpn-0.8.999-1.fc15,NetworkManager-vpnc-0.8.999-1.fc15
> 
> Reason codes too.  Just for you Chuck :)  (that's a lie, it's been
> requested before but I figured since Chuck asked I might as well just do
> it)

By me no less :P thanks for writing it.

--CJD
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Is Rawhide supposed to be useful?

[Casey Dahlin]

On Tue, May 10, 2011 at 01:07:22PM -0400, Adam Jackson wrote:
> X being broken in rawhide was in who knows how many peoples' ways, and 
> even though it's provenpackager+ and even though all it would have taken 
> was a mass driver rebuild, nobody even tried. Where _are_ you people? 
> Why do I bother to open the ACLs on my packages if nobody's going to 
> take advantage of it?
> 

Its a hard problem in human psychology (see diffusion of
responsibility/the bystander effect). It'd be nice if there were some
place we could list all of these tasks and allow people to grab them,
regardless of what they maintain (sounds a bit like bugzilla really) to
at least deter the sense of "what if I do all this work and someone else
fixes it before I commit?"

--CJD
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Is Rawhide supposed to be useful?

[Casey Dahlin]

On Wed, May 11, 2011 at 04:23:00PM +0200, Michael Schwendt wrote:
> That conclusion is based on the assumption that somebody pushes completely
> broken stuff into Rawhide _knowingly_.

Or that they push unproven code into rawhide carelessly.

--CJD
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: UID_MIN & GID_MIN changed

[Casey Dahlin]

On Thu, May 26, 2011 at 08:52:34AM -0400, Simo Sorce wrote:
> On Thu, 2011-05-26 at 07:39 +0200, Alexander Boström wrote:
> > ons 2011-05-25 klockan 12:37 -0500 skrev Dennis Gilmore:
> > 
> > > another issue that i thought of was existing ldap/nis systems that 
> > > allocate 
> > > regular users in the 500-1000 range when installing or upgrading if they 
> > > use 
> > > policies that probit system accounts from logging in will have users 
> > > unable to 
> > > login. 
> > 
> > As someone who admins such an LDAP setup I think the sooner the change
> > is made the better. (If it had been changed long ago then it wouldn't
> > have been a problem now.)
> > 
> > Personally I think UIDs and their relation to user accounts should be
> > treated as host-local. I also want a pony.
> 
> It would be nice, but then there is NFS ...
> 

NFSv4 has UID mapping, and we were all supposed to start using it
yesterday. My pony will have sparkles and rainbows.

--CJD
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Package Reviews Needed

[Casey Dahlin]

On Tue, Jun 07, 2011 at 03:12:19PM +0200, Kevin Kofler wrote:
> Tom Callaway wrote:
> > pyrit:
> > https://bugzilla.redhat.com/show_bug.cgi?id=691894
> 
> Oh great, because a tool to parasite wireless connections which the 
> owners went out of the way to secure with the best available protocol is 
> EXACTLY what we need…
> 
> Use of this tool is probably against the law in most of the world. (Some 
> countries even ban using unencrypted wireless networks without explicit 
> permission.) And I fail to see any legitimate use for this tool.
> 

White hats and black hats require the exact same tools to do their job.
Penetration testing is a huge part of what security researchers do.

--CJD
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: systemd: please stop trying to take over the world :)

[Casey Dahlin]

On Mon, Jun 13, 2011 at 10:33:19AM +0200, Lennart Poettering wrote:
> Uh, and even much healthier than Upstart, which you seem to be a big fan
> of. Ohloh lists 3 patch authors. (But I figure that is out-of-date, it
> cannot be that low)
> 

I'm guessing its just ohloh having as much trouble operating launchpad
as humans do. I know I have quite a large branch somewhere in there, but
it usually takes me a good while to find evidence of it too.

In general, though, someone else would have to understand what Upstart
is supposed to be in order to contribute code. Since that is explicitly
and by choice only documented in Scott's head, its kinda hard to do.

--CJD
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: systemd: please stop trying to take over the world :)

[Casey Dahlin]

On Tue, Jun 14, 2011 at 01:55:08PM +0200, Denys Vlasenko wrote:
> With sufficient amount of nutty hackery it may be possible to figure is
> out, but it will be either racy, or will require labeling (process
> groups? session ids? cgroups?) which, in general, is not reliable:
> processes can escape from that.
> 

Cgroups. And it is reliable. And processes cannot escape it. That's part
of why Cgroups were created, because all of the other options you
mentioned have precisely the flaw you point out. Cgroups does not.

--CJD
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: what key between Ctrl & Alt (was: GNOME3 and au revoir...)

[Casey Dahlin]

On Fri, Jun 17, 2011 at 07:05:59AM -0800, Jeff Spaleta wrote:
> On Fri, Jun 17, 2011 at 6:42 AM, Jared K. Smith
>  wrote:
> > It can be named... it's called the "Super" key.  Well, at least mine
> > is super, as it has a Fedora logo on it :-)
> 
> 
> That's a bad place for the Fedora logo... just like its a bad place
> for the Windows logo.  What is needed is project-neutral label for
> that key so that GNOME and other interfaces can start referencing it
> in the documentation with having to work about vendor branding.
> 
> If only the superman logo were public domain the superman symbol would
> be perfect.

The key was actually around for a bit before there was a windows logo on
it. It had a small diamond on it.

--CJD
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: GNOME3 and au revoir WAS: systemd: please stop trying to take over the world :)

[Casey Dahlin]

On Fri, Jun 17, 2011 at 01:05:08PM -0400, Bernd Stramm wrote:
> 
> I think it fails on #1:
> 
> > Makes it easy for users to focus on their current task and reduces
> > distraction and interruption 
> 
> First, this point assumes that there is *one* current task. That is not
> how I work. I have one main task, and I keep an eye on some other
> things, like whose is in some chats, what comes up in twitter flows,
> etc.
> 

One could rephrase your complaint as "I don't want to focus on my
current task." So GNOME shell just isn't for you.

--CJD
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: GNOME3 and au revoir WAS: systemd: please stop trying to take over the world :)

[Casey Dahlin]

On Fri, Jun 17, 2011 at 02:12:54PM -0400, Bernd Stramm wrote:
> One could do that, but that would be an idiotic thing to do. So one
> doesn't.
> 

Its what you said. You explicitly want to divide your attention between
multiple tasks. GNOME shell is for people who don't want to do that.

--CJD
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: GNOME3 and au revoir WAS: systemd: please stop trying to take over the world :)

[Casey Dahlin]

On Fri, Jun 17, 2011 at 02:32:12PM -0400, Bernd Stramm wrote:
> So Gnome Shell is not for a good many of the people who had been using
> Gnome before that.
> 

YES! I don't know why more people don't realize this: GNOME 2 was a
mediocre interface for a lot of people. It COULD NOT be a good interface
for the same number of people, and there is NOTHING wrong with them
pruning their userbase to a subset which they can adequately serve.

> It is not good to counter a technical point with a personal attack,
> which is what you did.
> 

No I didn't.

> Different workloads require different ways of working. In my case,
> there is not just one task that requires 100% of my attention. There is
> one big, long term task that can tolerate short interruptions, and
> several smaller ones. This is a perfectly normal situation.
> 

That doesn't mean GNOME shell did not meet the goal you quoted. It means
that goal contradicts your own goals. The goal was "let the user focus
on the current task." You want your focus less singularly distributed.
Serving you brings them further from, not closer to, the goal as stated.

--CJD
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Orphaning packages

[Casey Dahlin]

On Wed, Jul 06, 2011 at 11:23:06AM -0700, Jesse Keating wrote:
> I no longer have a need/care for these packages, they are up for grabs:
> 
> contacts
> inotail

I'll take inotail.

--CJD
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Orphaning packages

[Casey Dahlin]

On Wed, Jul 06, 2011 at 02:43:43PM -0400, Casey Dahlin wrote:
> On Wed, Jul 06, 2011 at 11:23:06AM -0700, Jesse Keating wrote:
> > I no longer have a need/care for these packages, they are up for grabs:
> > 
> > contacts
> > inotail
> 
> I'll take inotail.
> 
> --CJD

Someone pointed out that this functionality is now available in tailf,
so I don't think this package is necessary at all.

--CJD
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F17 heads up: gnome-shell for everyone!

[Casey Dahlin]

On Sat, Nov 05, 2011 at 09:46:41PM +0100, Kevin Kofler wrote:
> enaut wrote:
> > I am one of them and I went directly from the tilling-WM Xmonad to gnome
> > 3! So you can't say it's only for absolute noobs :).
> 
> The fact that you were using a tiling WM first shows that you are much more 
> willing to adapt to unconventional designs than most other users. I, for 
> one, want my computer to work the way I learned and interiorized a computer 
> works, any "innovative" interface destroys my automatisms and confuses me.
> 

http://zs1.smbc-comics.com/comics/20110814after.gif

--CJD
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Just Patched Kmess 2.0.6.1 :)

[Casey Dahlin]

On Wed, Nov 23, 2011 at 02:52:11PM -0600, Manuel Escudero wrote:
> (Cross Posting both to the Developers and Users List, sent a copy to
> Rex Dieter, who I believe is the maintainer for Kmess in the Fedora
> Community)
> 
> Hi, as you might have noticed in the last few days (if you are a kmess user)
> the kmess client that ships with Fedora 15 and Fedora 16 was affected by a
> bug that won't let the user see it's contact list when connecting into Kmess
> just after starting it's session.
> 
> I was really annoyed by this bug because I use kmess really often, so I've
> looked in the Kmess forums for a patch, downloaded the lastest kmess source
> from fedora's repositories and built new RPM's with the patch applied.
> 

Why not submit the patch in the bugzilla and let it get shipped as a
regular update? You've done almost all the work, but then you've gone
and added confusion by shipping it outside of the distro. I'm sure we'd
have been happy to take it considering you did the hard part for us.

--CJD
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: pyvnc2swf and vnc2flv

[Casey Dahlin]

On Mon, Nov 28, 2011 at 12:18:01PM +0100, Jos Vos wrote:
> Hi,
> 
> I was looking for a tool to record X/VNC session in a movie and found
> pyvnc2swf.  But looking at the project's home page,
> , I see that the
> development has been superseded by its successor, vnc2flv,
> ,
> since 2 years.
> 
> Maybe Fedora should upgrade to this new version for F17.

You should contact the maintainer directly and see if he will package
the new app (or at the very least retire the old one so a new maintainer
can obsolete it).

--CJD
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Ubuntu moving towards Wayland

[Casey Dahlin]

On Tue, Nov 09, 2010 at 01:44:19PM -0500, Brian Wheeler wrote:
> 
> And where does that sit in the architecture? 
> 
> Looking over the architecture page (2nd figure) it looks like the only
> way to get the kind of network transparency that X has under Wayland is
> to put the network between the Wayland client and Wayland Compositor.
> Which would mean that the passing of events has to be networkable from
> the start.  If its put on top it ends up being the VNC model of doing
> things and that sucks in a big way.
> 

Basically you'd run an alternate compositor in your ssh session that
would read out the buffers, compress them, and send them over the
network instead of compositing them into a larger buffer and scanning
them out.

--CJD
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Ubuntu moving towards Wayland

[Casey Dahlin]

On Tue, Nov 09, 2010 at 02:14:32PM -0500, Brian Wheeler wrote:
> On Tue, 2010-11-09 at 14:05 -0500, Casey Dahlin wrote:
> > On Tue, Nov 09, 2010 at 01:44:19PM -0500, Brian Wheeler wrote:
> > > 
> > > And where does that sit in the architecture? 
> > > 
> > > Looking over the architecture page (2nd figure) it looks like the only
> > > way to get the kind of network transparency that X has under Wayland is
> > > to put the network between the Wayland client and Wayland Compositor.
> > > Which would mean that the passing of events has to be networkable from
> > > the start.  If its put on top it ends up being the VNC model of doing
> > > things and that sucks in a big way.
> > > 
> > 
> > Basically you'd run an alternate compositor in your ssh session that
> > would read out the buffers, compress them, and send them over the
> > network instead of compositing them into a larger buffer and scanning
> > them out.
> > 
> > --CJD
> 
> That's an interesting solution.  If I logged into a remote machine would
> I have to run a separate compositor for every application or one per
> remote connection?  I suppose the compositor could be started
> automatically if the wayland libraries looked for an env setting (the
> same way X looks for DISPLAY).

When you did ssh --wayland, the remote ssh session daemon would start
that special compositor and inject its address into the environment so
things you launched under that session would use it. Then your ssh
client would start a proxy wayland client to recieve the compressed
buffers and create windows on your local wayland compositor.

Best part is, if you composited the buffers beforehand and then sent the
result as a giant window, you get VNC functionality, so you only need
one protocol for both.

--CJD
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Ubuntu moving towards Wayland

[Casey Dahlin]

On Tue, Nov 09, 2010 at 02:28:10PM -0500, Brian Wheeler wrote:
> On Tue, 2010-11-09 at 14:24 -0500, Casey Dahlin wrote:
> > On Tue, Nov 09, 2010 at 02:14:32PM -0500, Brian Wheeler wrote:
> > > On Tue, 2010-11-09 at 14:05 -0500, Casey Dahlin wrote:
> > > > On Tue, Nov 09, 2010 at 01:44:19PM -0500, Brian Wheeler wrote:
> > > > > 
> > > > > And where does that sit in the architecture? 
> > > > > 
> > > > > Looking over the architecture page (2nd figure) it looks like the only
> > > > > way to get the kind of network transparency that X has under Wayland 
> > > > > is
> > > > > to put the network between the Wayland client and Wayland Compositor.
> > > > > Which would mean that the passing of events has to be networkable from
> > > > > the start.  If its put on top it ends up being the VNC model of doing
> > > > > things and that sucks in a big way.
> > > > > 
> > > > 
> > > > Basically you'd run an alternate compositor in your ssh session that
> > > > would read out the buffers, compress them, and send them over the
> > > > network instead of compositing them into a larger buffer and scanning
> > > > them out.
> > > > 
> > > > --CJD
> > > 
> > > That's an interesting solution.  If I logged into a remote machine would
> > > I have to run a separate compositor for every application or one per
> > > remote connection?  I suppose the compositor could be started
> > > automatically if the wayland libraries looked for an env setting (the
> > > same way X looks for DISPLAY).
> > 
> > When you did ssh --wayland, the remote ssh session daemon would start
> > that special compositor and inject its address into the environment so
> > things you launched under that session would use it. Then your ssh
> > client would start a proxy wayland client to recieve the compressed
> > buffers and create windows on your local wayland compositor.
> > 
> > Best part is, if you composited the buffers beforehand and then sent the
> > result as a giant window, you get VNC functionality, so you only need
> > one protocol for both.
> > 
> 
> I assume there would be a fallback method for older ssh clients?
> 

It would involve a bit more effort on the user's part (most of which
could be rolled into a script) but you could set up the final scenario
using present-day ssh assuming you had the wayland bits on both ends.

--CJD
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Ubuntu moving towards Wayland

[Casey Dahlin]

On Tue, Nov 09, 2010 at 09:03:38PM +, Richard W.M. Jones wrote:
> On Tue, Nov 09, 2010 at 01:43:06PM -0500, Adam Jackson wrote:
> > - We lose network transparency!  Well, sure, the protocol doesn't have
> > that directly.  You can still do vnc-like things trivially and with a
> > modest amount of additional wayland protocol (or just inter-client
> > conventions) you can do spice-like things.  This is good, not bad,
> > because efficient remoting protocols do not look like X.  Now we get to
> > design a good one, and in the meantime vnc-style remoting sure does go a
> > long way towards being good enough.  (But, we can't switch yet, because
> > we don't even have vnc-style remoting yet; so we're not switching yet.)
> 
> Just so we don't lose the point: VNC-style remoting is *not*
> a suitable alternative.
> 

Ajax is using VNC-style remoting to refer to a pixel-scraping remoting
mechanism which would not necessarily include a root window and would in
most cases function the same way as X forwarding. Seems to be a repeated
confusion in this branch of the thread.

--CJD

> Rich.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: nouveau & gnome-shell (was: Re: Ubuntu moving towards Wayland)

[Casey Dahlin]

On Wed, Nov 10, 2010 at 09:03:25AM -0500, Darryl L. Pierce wrote:
> On Tue, Nov 09, 2010 at 01:22:02PM -0800, Adam Williamson wrote:
> > On Tue, 2010-11-09 at 21:05 +, Camilo Mesias wrote:
> > > I'm using the experimental 3d now with gnome shell. After a few days,
> > > it seems like it performs OK although it locks up for a few seconds
> > > now and then. It seems to recover and I can't see any obvious log
> > > messages around the time of the freeze. It does survive
> > > suspend/resume, which is great. My impression is that it runs slightly
> > > hotter than the nvidia driver but I could be imagining this (I don't
> > > have any figures).
> > 
> > You're probably not. nouveau basically has no power management at
> > present (it's under heavy development upstream, but I don't think ben's
> > pulled any of it downstream yet).
> 
> Does it support multiple monitor configurations? IOW, when I go to work
> I dock and use two external monitors. When I'm home I use either my
> laptop display or, when I'm in my home office, I attach a video dongle
> to connect to a widescreen monitor.
> 
> Right now I use the nVidia config tool to select my monitor config on
> the fly and change to that. What would I use with the mesa driver?
> 

xrandr / system-config-display. I use nouveau with two monitors all the time.

--CJD
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Passing ownership of mingetty

[Casey Dahlin]

On Thu, Nov 11, 2010 at 08:53:47PM +0100, Lennart Poettering wrote:
> On Wed, 10.11.10 21:33, Bernie Innocenti (ber...@codewiz.org) wrote:
> 
> > Hello Petr,
> > 
> > I ended up being the owner of mingetty by chance, because I used to
> > maintain it in the OLPC collection and the previous maintainer released
> > the package.
> 
> Do we really want to keep mingetty around?
> 

Your argument is sound, but this is still a bit off topic for this
thread. Even if mingetty is retired it still needs a maintainer for
another year until we retire F14 (unless we want to take a risk and try
to swap it out in the public releases). I assume OLPC would have a
similar issue.

--CJD
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 15, new and exciting plans

[Casey Dahlin]

On Mon, Nov 15, 2010 at 06:26:27PM -0500, Matthew Miller wrote:
> On Mon, Nov 15, 2010 at 11:15:38PM +, "Jóhann B. Guðmundsson" wrote:
> > Well if you don't consider what Lennart mentioned [1] as a con against 
> > usage of lvm by default what pros do you see for having lvm by default 
> > for the novice end user?
> 
> When the novice end user realizes that they made some poor storage decisions
> initially, they can, with a little learning, fix it without much hassle.
> 
> I have a system which, for silly reasons, I did not use LVM, and then ended
> up having change a separately-mounted /usr, and now (in a sort of irony,
> considering this thread) can't shut down cleanly under systemd. Awesome.
> 
> I'm not particularly attached to LVM as a specific technology, but we need
> something with equivalent functionality before we ditch it.
> 

It also takes a decision out of the mix when a user buys a new drive. They can
just dump it in the volume group rather than having to learn how to place it at
a mountpoint and migrate data (the actual commands are no big deal. Learning to
weigh the costs and benefits of applying your new 1TB disk to /usr vs /home
isn't).

Its a usecase that matters to an interesting class of user: the petty power
user. They help Aunt Tillie with her computer. They built their own computer.
They think of themselves as quite tech-savvy. They are also liable to say
things like "If linux is so great why can't it even run normal programs?"

LVM is nice in that it accomodates this generally unpleasent sort of person
(who is much improved by education and has the potential to become a great
contributor once humbled and made willing to learn) though it does this by
offering a temporary crutch.

--CJD
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 15, new and exciting plans

[Casey Dahlin]

On Mon, Nov 15, 2010 at 10:49:24PM +, Matthew Garrett wrote:
> On Mon, Nov 15, 2010 at 11:28:33PM +0100, Karel Klic wrote:
> > Dne 15.11.2010 22:31, Matthew Garrett napsal(a):
> > > Further, what's the licensing situation here? If I have an application
> > > that (at runtime) is a mixture of GPLed and GPL-incompatible code, does
> > > sending this coredump to a remote service count as distribution?
> > 
> > Interesting point. I do not know.
> > 
> > What is the scope of this question? Can GPLed and GPL-incompatible code 
> > end up in the same coredump in Fedora installation without 3rd party 
> > software installed?
> 
> It was reasonably likely in X until Synaptics got relicensed. I think 
> we're fairly safe from a stock install point of view.
> 

We should probably detect when things we don't ship are linked in and put some
measures in place to keep the user from inadvertently breaking copyright law
(or worse, putting copyrighted material on our BZ so /we/ end up inadvertently
breaking copyright law).

--CJD
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fixing the glibc adobe flash incompatibility

[Casey Dahlin]

On Wed, Nov 17, 2010 at 08:08:00PM -0500, Fulko Hew wrote:
> On Wed, Nov 17, 2010 at 4:26 PM, Jeff Spaleta  wrote:
> 
> > On Wed, Nov 17, 2010 at 8:16 PM, Jon Masters 
> > wrote:
> > > Did anyone upstream look into a compatibility environment variable that
> > > could be exported to change the direction of the memcpy? Yes, it's a
> > > hack, but it would allow affected users to have an option.
> >
> > Could we make use of that sort of environment variable feature more
> > generally as a way to build environments that test for bad memcpy
> > usage similar to this by flipflopping back and forth, even while we
> > are writing code?
> >
> 
> Its been a few decades since I last had to write a memcpy, but the last time
> I did,
> I made sure it worked with overlapping regions and just 'did the right
> thing'
> and made it as optimized as possible (for the CPUs available).
> 
> I know the definition for memcpy (on Linux) says don't use overlapping
> regions but thats really a poor excuse for knowingly misbehaving when
> it could certainly prevented.  Sorry, but using 'optimization' as a defense
> is just plain poor engineering practices.
> 
> Its certainly easier to provide a single well-behaved memcpy than it is to
> ensure that ALL programmers in the world write software that prevents
> overlapping regions.
> 
> It may just be me, but wouldn't it be 'common sense'?

Do all of your screwdrivers have big bulky ends so you can hammer nails in with
them? memcpy was given a specific purpose so it could be optimized for it. It
was a design choice in the spec itself, made when it was given its name. That's
why there's memmove. A program that uses functions outside of spec is still
broken, even if it happens to work, just like it is if it reads an
uninitialized variable but still works because the uninitialized space happens
to contain zero whenever the function is called.

This is why I gave up on Objective C. The two features of the language I wanted
(better memory management and exceptions) were ruined by silly gotchas in the
documentation. The memory management documentation essentially forbade you
directly from trying to understand memory management conceptually ("Don't think
of it as refcounting. Think of it as us telling you where to put these little
bits of code and you doing it and then your memory management works.")[1] and
the exceptions just came with a big warning label that said "try not to
actually use these if you can help it." I know for a fact both of these things
would have worked fine for me in the practical implementation, but they were
specified wrong so I left the language alone. Common sense is malleable, the
only thing anyone's held accountable for is the documentation and that's how it
has to be.

--CJD

[1] C itself is in a similar situation with its specification of pointers. We
all think of memory as an array of bytes and of pointers as an integer index
into that array, but if you think of C pointers that way and try to actually
read the bits in them you will break the spec, even though your program will
likely work. Its a good example here since if this were 1975 I could actually
find the compiler and CPU architecture that would, due to absolute necessity,
break your program. Hell if they're function pointers I just need a PPC box.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fixing the glibc adobe flash incompatibility

[Casey Dahlin]

On Thu, Nov 18, 2010 at 04:27:48AM +, Matthew Garrett wrote:
> On Wed, Nov 17, 2010 at 11:26:31PM -0500, Benjamin Kreuter wrote:
> > On Wednesday 17 November 2010 22:59:54 Matthew Garrett wrote:
> > > Pretty sure it doesn't point them out. It just breaks them.
> > 
> > Using memcpy on overlapping ranges is undefined behavior; a crash is a 
> > pretty 
> > good way of pointing that out.  Other undefined behavior causes a crash  
> > (last 
> > I checked):
> 
> Flash isn't crashing. It just sounds like it's trapped in a flooded 
> submarine.
> 

/me suddenly realizes that the Flash bug he's been encountering is the one
being discussed in this thread.

--CJD
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

pdftk requires tomcat5?

[Casey Dahlin]

Sizewise this didn't end up being an awful cost for me, but why on earth would
this happen?

Installing:
 pdftk   x86_64 1.41-27.fc14   fedora  76 k
Installing for dependencies:
 bouncycastlex86_64 1.45-1.fc13fedora 3.3 M
 bouncycastle-mail   x86_64 1.45-1.fc13fedora 517 k
 bouncycastle-tspx86_64 1.45-1.fc13fedora 105 k
 itext   x86_64 2.1.7-6.fc13   fedora 3.0 M
 javamailx86_64 1.4.3-2.fc13   fedora 925 k
 tomcat5-jsp-2.0-api noarch 5.5.27-7.4.fc12fedora  73 k
 tomcat5-servlet-2.4-api noarch 5.5.27-7.4.fc12fedora 114 k

--CJD
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: pdftk requires tomcat5?

[Casey Dahlin]

On Mon, Nov 22, 2010 at 03:19:35PM -0500, Orcan Ogetbil wrote:
> On Mon, Nov 22, 2010 at 3:11 PM, Casey Dahlin wrote:
> > Sizewise this didn't end up being an awful cost for me, but why on earth 
> > would
> > this happen?
> >
> > Installing:
> >  pdftk                       x86_64     1.41-27.fc14           fedora      
> > 76 k
> > Installing for dependencies:
> >  bouncycastle                x86_64     1.45-1.fc13            fedora     
> > 3.3 M
> >  bouncycastle-mail           x86_64     1.45-1.fc13            fedora     
> > 517 k
> >  bouncycastle-tsp            x86_64     1.45-1.fc13            fedora     
> > 105 k
> >  itext                       x86_64     2.1.7-6.fc13           fedora     
> > 3.0 M
> >  javamail                    x86_64     1.4.3-2.fc13           fedora     
> > 925 k
> >  tomcat5-jsp-2.0-api         noarch     5.5.27-7.4.fc12        fedora      
> > 73 k
> >  tomcat5-servlet-2.4-api     noarch     5.5.27-7.4.fc12        fedora     
> > 114 k
> >
> > --CJD
> >
> 
> A little bugzilla  search might help
> https://bugzilla.redhat.com/show_bug.cgi?id=650390
> 
> I just typed "pdftk" in the quick search box on bugzilla and hit enter.
> 

Somehow didn't think to check BZ for this sort of problem. Thanks for pointing
that out though.

--CJD
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: noexec on /dev/shm

[Casey Dahlin]

On Thu, Dec 16, 2010 at 12:27:34PM +, Richard W.M. Jones wrote:
> On Wed, Dec 15, 2010 at 07:21:25AM +0100, Lennart Poettering wrote:
> > Jeez. Tha's just FUD. Of course we have discussed this openly with
> > various folks. We haven't discussed this with you, Rich, personally, but
> > well, I'll make a note now tht I'll DoS you now with every single
> > choice we make, to get your blessing.
> 
> What you don't understand is that you are throwing away the experience
> and knowledge of thousands of Unix system administrators.  Almost of
> all of them do not even read this mailing list.
> 
> Rich.

I hate this argument.

The "experience and knowledge" claim applies to everything we could possibly
change.

Change.
Is.
Going.
To.
Happen.

This is technology. Good technical professionals learn new things quickly. So
to all those thousands of Unix system administrators I suggest making a
purchase here:

http://www.saferacer.com/auto-racing-helmets/?cat=52

--CJD
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: noexec on /dev/shm

[Casey Dahlin]

On Thu, Dec 16, 2010 at 08:16:53PM +0100, Miloslav Trmač wrote:
> Casey Dahlin píše v Čt 16. 12. 2010 v 11:19 -0500:
> > On Thu, Dec 16, 2010 at 12:27:34PM +, Richard W.M. Jones wrote:
> > > What you don't understand is that you are throwing away the experience
> > > and knowledge of thousands of Unix system administrators.  Almost of
> > > all of them do not even read this mailing list.
> > > 
> > > Rich.
> > 
> > I hate this argument.
> > 
> > The "experience and knowledge" claim applies to everything we could possibly
> > change.
> > 
> > Change.\nIs.\nGoing.\nTo.\nHappen.
> 
> That's a too black-and-white view.  Of course there is and will be
> change - what would we all be doing here if there were nothing to
> change, after all?  The thing that needs to be appreciate is that every
> change has _costs_ on the user-base.
> 

I think the view I was presented with was too black-and-white. Richard began
with essentially "change is bad." I responded. You've really wholly replaced
the argument I was reacting to. Which is a good thing. The conversation should
have begun here.

> I can't quickly find out good numbers on the number of server users of
> Fedora and Fedora-derived distributions; based on
> http://www.centos.org/modules/newbb/viewtopic.php?topic_id=18728&forum=14 ,
> let's stipulate that there are 1,000,000 installations (which is almost
> certainly a huge understatement), with 10 servers per administrator on
> average, so 100,000 Linux system administrators.  Better numbers would be
> welcome.
> 

http://fedoraproject.org/wiki/Statistics

That's the best we have.

> Especially minor changes that don't bring any measurable benefit
> (perhaps making the system "cleaner" or making programmer's life more
> convenient) but require time from each user to adapt are better
> abandoned than implemented.
>   Mirek

Measurable != significant. Great programmers and architects have an instinct
for something called "defect avoidance." You can't measure it, since the unit
would be "number of bugs/bug-related outages and problems which never
happened." Depending on your instincts on what that value might be, "cleaner"
could be the single most important thing to improve in the entire distro. You
can guess my own instincts on the subject.

This sort of immeasurability is everywhere in computing. Its what causes most
major corporate security breaches ("well, we haven't had a security breach in
awhile, I guess we don't need to spend so much on a security team.") Its what
spawned the desperate rationalization "all software has bugs," which is an
excuse to not have to measure how well you avoid putting bugs in the code. For
my part, I believe in trying to write software that can't break, even if I'm
not always successful. Part of that effort is ripping off anything that's
loose. If its purpose is questionable, or its exposed in a semantically iffy
way, it needs to be ripped out.

--CJD
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: noexec on /dev/shm

[Casey Dahlin]

On Mon, Dec 20, 2010 at 07:16:21PM -0800, Fernando Lopez-Lezcano wrote:
> This is from Paul Davis, the main architect of Jack (I forwarded him 
> your post):
> 
> 
> this isn't exactly correct.
> 
> in /dev/shm on linux we have:
> 
> (a) unix-domain sockets for non-RT communication with the server

Perhaps these could become abstract domain sockets.

--CJD
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: noexec on /dev/shm

[Casey Dahlin]

On Thu, Dec 23, 2010 at 09:11:46AM -0800, Fernando Lopez-Lezcano wrote:
> On 12/22/2010 12:56 PM, Casey Dahlin wrote:
> >On Mon, Dec 20, 2010 at 07:16:21PM -0800, Fernando Lopez-Lezcano wrote:
> >>This is from Paul Davis, the main architect of Jack (I forwarded him
> >>your post):
> >>
> >>
> >>this isn't exactly correct.
> >>
> >>in /dev/shm on linux we have:
> >>
> >> (a) unix-domain sockets for non-RT communication with the server
> >Perhaps these could become abstract domain sockets.
> 
> Could you explain a bit perhaps? I'm not familiar with them... (or
> maybe you have a url I could surf to?)
> 
Basically, you put a \0 in front of the path when you bind the socket. So, for
example, bind to "\0/jack/socket". Yes, that looks weird, but it works. The
socket will not appear anywhere in the filesystem, but can still be opened by
using that wonky path from anywhere. When no longer referenced the socket will
simply disappear.

Here's a link, though it takes awhile to get to the point:
http://blog.eduardofleury.com/archives/2007/09/13/

--CJD
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: firewalld - A firewall daemon with D-BUS interface providing a dynamic firewall (test version)

[Casey Dahlin]

On Mon, Dec 27, 2010 at 08:06:05PM +0100, nodata wrote:
> 
> Hi,
> 
> First of all thanks for making this work on the command line first and 
> gui second.
> 
> Can I ask a stupid question? Does dbus have the kind of performance 
> necessary to support this type of application?
> 

What kind of performance do you think is necessary? Its just a
configuration interface, its not like its pushing all your packets
through dbus or asking the bus every time it needs to make a routing
decision (or did I miss something? I'd certainly hope not).

--CJD
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Plans for BTRFS in Fedora

[Casey Dahlin]

On Wed, Feb 23, 2011 at 11:54:58AM -0600, Eric Sandeen wrote:
> On 2/23/11 11:42 AM, Jesse Keating wrote:
> > On 2/23/11 5:00 AM, Josef Bacik wrote:
> >> This would be a great thing in general since the default ext* image is
> >> shrunk down to be installed which creates a bad fs layout which has
> >> performance implications.
> > 
> > Can you expand upon this more?  The filesystem is shrunk down when the 
> > live image is built, but then once it is installed the fs is resized to 
> > fill out the physical disk / partition it is being installed to.
> 
> Shrinking down the filesystem tends to scramble it a bit.  All the allocator
> decisions that were made based on fs size at the time of install go out the
> window as resize2fs fills in every hole it can find to maximally compress the
> fs.
> 

Is there some sort of "sparsifying defrag" we could do after copying the image
over? The dd-based install is so fast that we could actually afford another
pass if we needed it IMHO.

--CJD
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Services that can start by default policy feedback

[Casey Dahlin]

On Thu, Feb 24, 2011 at 03:51:37PM -0500, Genes MailLists wrote:
> On 02/24/2011 01:32 PM, Matthew Garrett wrote:
> 
> > There are no essential services, which means any proposal that contains 
> > the phrase "non-essential services" is already unimplementable.
> > 
> 
>   HID services (keyboard/mouse) might be nice  ... :-) :-)

Not if you have a headless server. Also I don't think its absolutely
necessary to have a service running to use the keyboard.

There's no real usecases that want _no_ services running, and there's
probably very few within Fedora proper that don't want things like udev
(and then they're probably doing so much to the base install anyway that
a bit of service reconfiguration is nothing), but technically Matthew is
correct.

--CJD
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: s/redhat/system in package names

[Casey Dahlin]

On Sat, May 08, 2010 at 01:10:18AM +0200, Xose Vazquez Perez wrote:
> hi,
> 
> Long time ago, all *redhat* packages were renamed to "system*".
> But three of them are still alive: redhat-lsb, redhat-menus and 
> redhat-rpm-config
> 
> Should they switch to "system-" ?
> 
> -thanks-
> 

I think s/redhat/fedora/ is the better choice for these particular
instances.

--CJD

> -- 
> «Allá muevan feroz guerra, ciegos reyes por un palmo más de tierra;
> que yo aquí tengo por mío cuanto abarca el mar bravío, a quien nadie
> impuso leyes. Y no hay playa, sea cualquiera, ni bandera de esplendor,
> que no sienta mi derecho y dé pecho a mi valor.»
> -- 
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: systemd (Was Re: tmpfs for strategic directories)

[Casey Dahlin]

On Mon, May 24, 2010 at 09:05:31AM -0400, Tom spot Callaway wrote:
> On 05/23/2010 04:19 AM, Kevin Kofler wrote:
> > Lennart Poettering wrote:
> >> So far response from the community has been very positive, but we didn't
> >> have a fedora-devel discussion about this yet, so we'll have to see
> >> whether we can somehow make the broader community as enthusiastic about
> >> the whole idea as I am. ;-)
> > 
> > I, for one, think systemd should be the default ASAP.
> 
> Perhaps the first time I can recall that we have agreed. ;)
> 
> ~spot

Any particular reason on either of your parts?

Just about everything in systemd is either set to be in upstart (simpler
dependency syntax, xinetd-style service activation) or was discarded by it
years ago (cgroups are a dead end).

The assumption that just because its new means its more advanced is in this
case a bit misguided.

--CJD

> -- 
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: systemd (Was Re: tmpfs for strategic directories)

[Casey Dahlin]

On Tue, May 25, 2010 at 05:45:07PM +0200, Lennart Poettering wrote:
> On Tue, 25.05.10 10:21, Casey Dahlin (cdah...@redhat.com) wrote:
> 
> > 
> > On Mon, May 24, 2010 at 09:05:31AM -0400, Tom spot Callaway wrote:
> > > On 05/23/2010 04:19 AM, Kevin Kofler wrote:
> > > > Lennart Poettering wrote:
> > > >> So far response from the community has been very positive, but we 
> > > >> didn't
> > > >> have a fedora-devel discussion about this yet, so we'll have to see
> > > >> whether we can somehow make the broader community as enthusiastic about
> > > >> the whole idea as I am. ;-)
> > > > 
> > > > I, for one, think systemd should be the default ASAP.
> > > 
> > > Perhaps the first time I can recall that we have agreed. ;)
> > > 
> > > ~spot
> > 
> > Any particular reason on either of your parts?
> > 
> > Just about everything in systemd is either set to be in upstart (simpler
> > dependency syntax, xinetd-style service activation) or was discarded by it
> > years ago (cgroups are a dead end).
> 
> Oh, is that so? 
> 
> Have you actually read the blog story I put together? 
> 

Yes, but I'm going to go read it again just to be sure.

> Why do you say "cgroups are a dead end"? Sure, Scott claims that, but
> uh, it's not the only place where he is simply wrong and his claims
> baseless. In fact it works really well, and is one of the strong points
> in systemd. I simply see no alternative for it. The points Scott raised
> kinda showed that he never really played around with them.
> 
> Please read up on cgroups, before you just dismiss technology like that
> as "dead end".
> 

I did. When upstart was about to use them. 2 years ago. We chucked them by the
following LPC.

The problem we've found is that cgroups are too aggressive. They don't have a
notion of sessions and count too much as being part of your service, so you end
up with your screen session being counted as part of gdm.

This is why setsid was added to the netlink connector.

> > The assumption that just because its new means its more advanced is in this
> > case a bit misguided.
> 
> Well, please read the blog story. I know it's long, but it should be an
> interesting read. The whole point of the blog story is to make clear the
> reason systemd exists is purely technical, and that we think our design
> is simply the better one.
> 

So you have:

1) Socket activation. Part of Upstart's roadmap. Would happen sooner if you
cared to submit the patch. We don't think its good enough by itself, hence the
rest of Upstart, but a socket activation subsystem that could reach as far as
systemd and even work standalone in settings where systemd can work is
perfectly within Upstart's scope. I'd be happy to firm up the design details
with you if you wanted to contribute patches.

2) Bus activation. Missed opportunity here to actually become the launchpoint
for activated services. I won't criticize that too much though, as its
usefulness is largely dependent on kernelspace DBus, which I've been trying to
bludgeon Marcel Holtmann into turning over to the public for a year now.

3) Cutting down on the forking by replacing some of the shell scripts... cool
   3a) With C code... really?

4) Process environment control. No complaints, and also nothing Upstart doesn't
want to do.

> We did systemd because we thought that technically Upstart is
> fundamentally flawed and misses out on so many opportunities.
> 

And we think the same of systemd.

> And if you cannot see that then I can only beg you to read the blog
> story, because it goes into much detail about all the technical
> features.
> 
> Please, judge systemd on technical grounds, don't judge it on political,
> or emotional grounds.
> 

Not to be specifically political, but did you ever consider submitting systemd
itself as a patch? Literally:

diff -pruN ~lennart/coding/upstart ~lennart/coding/systemd

And mail it to upstart-devel-list. I'm being a bit hyperbolic, but actually not
much. That would have been a valid move.

You should really come work with us. We're fun guys.

--CJD
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: systemd (Was Re: tmpfs for strategic directories)

[Casey Dahlin]

On Wed, May 26, 2010 at 02:01:35PM +0200, Tomasz Torcz wrote:
> On Wed, May 26, 2010 at 01:26:48PM +0200, Lennart Poettering wrote:
> > > The problem we've found is that cgroups are too aggressive. They don't 
> > > have a
> > > notion of sessions and count too much as being part of your service, so 
> > > you end
> > > up with your screen session being counted as part of gdm.
> > 
> > 
> > The per-user cgroups are controlled via a PAM module. That way there's
> > finally a nice way how we can reliably clean up behind a user when he logs 
> > out:
> > we just kill his complete cgroup and he's gone.
> 
>   You are avoiding the question: what about screen sessions? Whole
> point of screen is to stay after logout, and by killing cgroup you
> nullify it.
>  

Precisely my point.

--CJD
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: systemd (Was Re: tmpfs for strategic directories)

[Casey Dahlin]

On Wed, May 26, 2010 at 01:26:48PM +0200, Lennart Poettering wrote:
> On Tue, 25.05.10 23:02, Casey Dahlin (cdah...@redhat.com) wrote:
> 
> > > Why do you say "cgroups are a dead end"? Sure, Scott claims that, but
> > > uh, it's not the only place where he is simply wrong and his claims
> > > baseless. In fact it works really well, and is one of the strong points
> > > in systemd. I simply see no alternative for it. The points Scott raised
> > > kinda showed that he never really played around with them.
> > > 
> > > Please read up on cgroups, before you just dismiss technology like that
> > > as "dead end".
> > > 
> > 
> > I did. When upstart was about to use them. 2 years ago. We chucked them by 
> > the
> > following LPC.
> 
> Who is "we"?
> 

Upstart has about 1.7 developers. The 1 is Scott, myself and Johann Kiviniemi
fight over the .7.

> > The problem we've found is that cgroups are too aggressive. They don't have 
> > a
> > notion of sessions and count too much as being part of your service, so you 
> > end
> > up with your screen session being counted as part of gdm.
> 
> Well, how exactly you set up the groups is up to you, but the way we do
> it in systemd is stick every service in a seperate cgroup, plus every
> user in a seperate one, too. Some examples:

> 
> And so on.
> 

Someone else already pointed out the issues here.

> And the nice thing is that these cgroups are shown when you do "ps -eo
> cgroup,...". You can always figure out from "ps" to which service a
> process belongs, even if if it fork()ed a gazillions of times. And all
> the keeping track is done by the kernel, basically for free. No
> involvement from userspace.
> 
> > This is why setsid was added to the netlink connector.
> 
> Well, this is just flawed, on so many levels, that it

> enforcement for your services, since you simply have no cgroups. And no
> nice interfacing with the other libcgroup tools either.
> 

There's no reason Upstart couldn't offer cgroups for resource limits, its
just passed them up as a process supervision mechanism. And they are broken for
the screen case, though perhaps that could be fixed in the kernel.

> Meh, and this lists gets on like this.
> 
> People should not use cn_proc. It's evil. And if you are using for
> anything except logging you are doomed. And even for logging it isnt
> really useful.
> 
> > 1) Socket activation. Part of Upstart's roadmap. Would happen sooner if you
> > cared to submit the patch. We don't think its good enough by itself, hence 
> > the
> > rest of Upstart, but a socket activation subsystem that could reach as far 
> > as
> > systemd and even work standalone in settings where systemd can work is
> > perfectly within Upstart's scope. I'd be happy to firm up the design details
> > with you if you wanted to contribute patches.
> 
> Well, for once, it would be nice to judge things due to actually
> existign features, not of big plans nobody is working on as you
> apparently admit outright.
> 

You worked on it, and finished it. You just didn't do it within Upstart. The
manpower was there it was just misapplied.

> And then, the socket activtion is nice for various reasons, and
> lazy-loading is just one of them. The bigger advantage is that it does
> automatic dependency handling -- which of course is nothign that really
> fits into upstart's design, since that is based on "events" not
> dependencies -- events are just broken, as I might note. And adding
> dependency would turn around upstart's design, making it a completely
> different beast.
> 

Event-driven in Upstart's case just talks about the internal operation of
Upstart. Its rather exposed in current iterations but its just a design
philosophy. You can implement "dependencies" within it, though in the past
Upstart has been hesitant with the term because it tends to imply a
dependency-solving algorithm, where as Upstart provides its dependencies
reactively, in response to change.

> I mean, you called socket activation "xinetd-style activation" in the
> earlier mail of yours -- that is just completely besides the point,
> because this all is not so much about doing on-demand starting of
> internet services. systemd-style activation is about parallelizing
> startup of (mostly) local services and making fully written dependencies
> obsolete. And that's what is so magic about it. And an init systemd
> should be designed around this at its core! And systemd is.
> 

Yes. I get it.

> > 2) Bus activation. Missed opportunity he

Re: systemd (Was Re: tmpfs for strategic directories)

[Casey Dahlin]

On Thu, May 27, 2010 at 10:13:16AM -0500, Chris Adams wrote:
> Once upon a time, Kevin Kofler  said:
> > Editing the code is the wrong way to make "simple local changes".
> 
> That is only true if you can anticipate every task every system admin
> will ever need to do with your tools.
> 
> I've edited init scripts for multiple reasons.  For example, I have
> multiple instances of some daemons running, so I'll make multiple copies
> of the init script and edit as needed for config/PID file locations,
> etc.
> 

Playing devils advocate a more robust init system might accomodate that use
case in particular differently.

--CJD

> -- 
> Chris Adams 
> Systems and Network Administrator - HiWAAY Internet Services
> I don't speak for anybody but myself - that's enough trouble.
> -- 
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: init script behaviour

[Casey Dahlin]

On Tue, Jun 15, 2010 at 03:30:05PM +0300, Manuel Wolfshant wrote:
> On 06/15/2010 03:08 PM, Joe Orton wrote:
*snip*
> > Thoughts?
> Well, I'd say it depends on how we define the "start" part. "fire and 
> forget",  "start and make sure it was started" or "start and make sure 
> it is running".
> 

I'd say fire and forget or something close for most sysv initscripts. If
you want to do better you need a modern tool like systemd/upstart/etc.
Trying to do it better in bash just makes for piles of ugly, and the
weird failure modes and corner cases will usually end up being worse
than the problem.

--CJD
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: init script behaviour

[Casey Dahlin]

On Tue, Jun 15, 2010 at 01:40:43PM -0500, Chris Adams wrote:
> Once upon a time, Casey Dahlin  said:
> > I'd say fire and forget or something close for most sysv initscripts. If
> > you want to do better you need a modern tool like systemd/upstart/etc.
> > Trying to do it better in bash just makes for piles of ugly, and the
> > weird failure modes and corner cases will usually end up being worse
> > than the problem.
> 
> A well-behaved daemon should be doing all the checking possible before
> forking to go into the background.  The init scripts do check the exit
> code, so configuration errors, failure to bind to sockets, etc. should
> be (and in most cases are) caught that way.
> 

Oh if only they were all well-behaved :) Yes, reading and acting on the
information the daemon itself hands to you is obviously a good thing.

--CJD
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [HEADS-UP] systemd is now the default init system in rawhide

[Casey Dahlin]

On Fri, Jul 23, 2010 at 08:04:48PM -0700, darrell pfeifer wrote:
> On Fri, Jul 23, 2010 at 18:26, Lennart Poettering wrote:
> 
> > Heya,
> >
> > I have just uploaded a new systemd and a new upstart package which make
> > systemd the default init system for Rawhide. The scheme I followed makes
> > sure that in case systemd actually breaks systems there is an easy path
> > back to upstart. And here's how it works:
> >
> > - "upstart" and "systemd" are now parallel installable. When you upgrade
> >  rawhide you will get both installed. (we'll drop upstart eventually,
> >  but during the testing phase i made sure to explicitly install both,
> >  so that there is a safe backup init system)
> >
> >
> >
> Just gave it a try with the koji of moments ago.
> 
> ---> Package systemd-sysvinit.x86_64 0:4-3.fc14 set to be installed
> --> Processing Dependency: systemd = 4-3.fc14 for package:
> systemd-sysvinit-4-3.fc14.x86_64
> --> Processing Dependency: upstart >= 0.6.5-6.fc14 for package:
> systemd-sysvinit-4-3.fc14.x86_64

What?!

> ---> Package systemd-units.x86_64 0:4-3.fc14 set to be updated
> --> Running transaction check
> ---> Package systemd.x86_64 0:4-3.fc14 set to be installed
> ---> Package upstart.x86_64 0:0.6.5-7.fc14 set to be updated
> --> Processing Dependency: sysvinit-userspace for package:

Aand this is the other half of the problem. Change I made before Lennart was
around to make a complementary change in the systemd package unfortunately. It
shouldn't have caused a big issue except for the really bizzare dependency
mentioned above.

> upstart-0.6.5-7.fc14.x86_64
> --> Running transaction check
> ---> Package upstart-sysvinit.x86_64 0:0.6.5-7.fc14 set to be installed
> --> Processing Conflict: systemd-sysvinit-4-3.fc14.x86_64 conflicts
> upstart-sysvinit
> --> Processing Conflict: upstart-sysvinit-0.6.5-7.fc14.x86_64 conflicts
> systemd-sysvinit
> --> Finished Dependency Resolution
> Error: systemd-sysvinit conflicts with upstart-sysvinit
> Error: upstart-sysvinit conflicts with systemd-sysvinit
>  You could try using --skip-broken to work around the problem
>  You could try running: rpm -Va --nofiles --nodigest
> 
> 
> darrell

> -- 
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [HEADS-UP] systemd is now the default init system in rawhide

[Casey Dahlin]

On Fri, Jul 23, 2010 at 10:54:50PM -0500, Garrett Holmstrom wrote:
> On 7/23/2010 20:26, Lennart Poettering wrote:
> > - You can boot into either of them by setting the "init=" kernel cmdline
> >option according to your wishes. If you pass "init=/bin/systemd" you
> >will boot into systemd, if you pass "init=/sbin/upstart" you will boot
> >into upstart (note the /sbin vs. /bin!)
> 
> Why is the systemd executable in /bin instead of /sbin?

Without looking too closely I believe systemd eventually seeks to replace
things like gnome-session daemon. It has session management in mind as well as
system.

--CJD

> -- 
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: How to proceed with MiniDebugInfo

[Casey Dahlin]

On Thu, May 24, 2012 at 09:28:16AM +0200, Alexander Larsson wrote:
> I'm at a loss to how to proceed with the MiniDebugInfo work. I have
> patches to rpmbuild that creates the compressed minidebuginfo putting
> them in the main binaries, and I have patches to gdb that reads the
> compressed debuginfo on demand. 
> 
> However, the whole thing is useless unless we agree that we want to
> enable this by default. It seems some people like the idea, whereas
> others disagree that its worth the increased binary size. It doesn't
> look like either side is gonna be able to convince the other side, so
> how do we get to a decision here?
> 

Just go do it. See who actually shows up to stop you.

--CJD
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: How to proceed with MiniDebugInfo

[Casey Dahlin]

On Thu, May 24, 2012 at 07:27:03PM +0200, Jan Kratochvil wrote:
> On Thu, 24 May 2012 19:20:15 +0200, Casey Dahlin wrote:
> > Just go do it. See who actually shows up to stop you.
> 
> I am sure this is significant enough distro change to require FESCo decision.

Still cuts his workload down from convincing an open mailing list to
convincing 7 people.

--CJD
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [RFC] plans for initscripts in F22

[Casey Dahlin]

On Thu, Apr 24, 2014 at 05:55:29PM +0200, Miloslav Trmač wrote:
> Hello,
> 2014-04-24 16:38 GMT+02:00 Lukáš Nykrýn :
> 
> > We must keep initscripts support, but I can imagine a setup where every
> > service uses a systemd unit, so this part does not have to be installed by
> > default, but could be pulled in as a dependency.
> >
> 
> Are you sure?  If you take an existing RPM that ships a sysv file, that's
> alone an indication that it probably hasn't been significantly reworked, so
> noone is likely to have added an explicit requires: on "this part".  For
> extra credit, make sure that this works correctly with LSB-compliant RPMs
> that do nothing not required by LSB.
> 

I may be wrong but I believe we could update our dependency-detection scripts
to note when a package ships an init script and add the requirement
automatically. As long as there's a mass rebuild between now and shipping that
should take care of everyone.

--CJD


pgp0GQ_7Ia4Dx.pgp
Description: PGP signature
-- 
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: Deprecate setjmp/longjmp? [was Re: Maybe it's time to get rid of tcpwrappers/tcpd?]

[Casey Dahlin]

On Mon, Apr 28, 2014 at 08:57:27AM -0400, Adam Jackson wrote:
> On Sun, 2014-04-27 at 23:02 +0100, Andrew Price wrote:
> > On 24/04/14 15:13, Lennart Poettering wrote:
> > > We probably should make setjmp()-freeness a requirement for
> > > all code included in Fedora.
> > 
> > Would it be worth the effort, and how feasible is it anyway?
> 
> I don't think it'd be worth the effort, and I think the burden of
> computing feasibility should rest with those who think it _is_ worth the
> effort.
> 

Well, we could consider banning it from new packages and just let attrition
take care of the rest.

--CJD


pgpVidXejQmkv.pgp
Description: PGP signature
-- 
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: F21 System Wide Change: Wayland

[Casey Dahlin]

On Tue, Apr 29, 2014 at 02:04:56PM +0200, Jaroslav Reznik wrote:
> This change is targeted at F21. For F20, we aim for having an experimental 
> GNOME shell Wayland compositor available, without necessarily having all the 
> surrounding desktop infrastructure ported. To avoid destabilizing the X 
> compositor, mutter will ship two separate libraries, and gnome-shell will 
> ship 
> two binaries that will link against them. Concretely, we plan to have a 
> separate mutter-wayland package.

Looks like this hasn't been updated since F20. Should probably give a status
report of how these F20 changes went off. Last I looked, gnome-wayland was
there, but not terribly functional.

--CJD


pgpJvzcuap0I0.pgp
Description: PGP signature
-- 
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 are we going? (Not a rant)

[Casey Dahlin]

On Mon, Dec 10, 2012 at 04:20:34PM -0500, Przemek Klosowski wrote:
> are not worth paying support for.  I suggested to RedHat that they
> provide a graceful switch-over to CENTOS in such case: it's possible
> manually anyway, so it would be a nice gesture to do it
> automatically for customers who let the support expire. As is in our
> case, this doesn't even decrease the amount of support we
> purchase---it just gives us the flexibility to deploy new systems
> all the time.

If CentOS were to take up that effort themselves (largely feasible for them to
do technically) I'm sure Red Hat sales would wink in that direction in cases
when they felt it was in the interest of Red Hat. Enough of that winking and
eventually engineers at Red Hat's end would probably have an incentive to keep
it working.

--CJD
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: Yum Groups as Objects

[Casey Dahlin]

On Mon, Jan 28, 2013 at 10:26:01AM -0600, Bruno Wolff III wrote:
> On Mon, Jan 28, 2013 at 16:52:18 +0100,
>   Kamil Dudka  wrote:
> >
> >I have been always wondering why yum needs a special set of commands to
> >manipulate groups of packages.  What would be the downside of using just
> >packages that install no files (a.k.a. meta-packages) instead of groups?
> 
> Removing meta packages doesn't remove the dependencies. So you more
> or less have the same problem. It is easy to install groups, but
> tricky to remove them.

I thought we'd been shipping remove-with-leaves by default for awhile now.

--CJD
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: Cinnamon as Default Desktop

[Casey Dahlin]

On Mon, Jan 28, 2013 at 07:49:59PM +0100, Maros Zatko wrote:
> I've used gnome 2.x, when 3.x came out I had no other option
> than to (finally) switch to tiling since my beloved DE was gone
> and not going back.

If you're the sort of person that wants a tiling window manager, then I think
it's fair to ask you to install it yourself, thereby freeing up the default to
serve a different audience.

--CJD
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: Cinnamon as Default Desktop

[Casey Dahlin]

On Sat, Feb 09, 2013 at 11:34:34AM +, Ian Malone wrote:
> Gnome 2 slowly returned to the old behaviour in many ways. Gnome 3 is
> starting to do this.
> 

As someone who, I presume, does not like Gnome 3, and as someone who, I will
wildly guess, shares the notion that GNOME devs are doing whatever they want
and not listening to your use cases...

...are you certain...

...absolutely certain...

...that you'd like to be on record setting the precedent that GNOME 3 is
admitting failure by compromising to your standards?

--CJD
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Improving the Fedora boot experience

[Casey Dahlin]

On Tue, Mar 12, 2013 at 08:01:54AM -0400, Nico Kadel-Garcia wrote:
> And the main lesson her is "don't clutter the user interface with
> useless graphical eye candy". It makes the boot process require
> unnecessary system resources. The new Fedora installation setup is
> currently a *nightmare*. It works very poorly through low bandwidth
> remote connections, the graphics are poorly labeled and very
> confusing, and the "spoke and hub" model is a bit of big vision
> coneptual weirdness that is actively preventing people from wanting to
> touch Fedora. It's an *installer*, keeping it as lightweight and
> simple as possible with minimal graphics means that it will display
> better on small virtual system or remote KVM displays. But this has
> been discarded in favor or an overly bulky and complex system that is
> showing off what are quite fragile graphical features rather than
> simply doing the *job*.

Citation needed. Anaconda has been graphical for ages, and has probably gotten
lighter after the rewrite if anything.

--CJD
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Improving the Fedora boot experience

[Casey Dahlin]

On Tue, Mar 12, 2013 at 11:52:40PM +0100, Nicolas Mailhot wrote:
> rescue system. (that's why safety jackets use flashy unfashionable colors)

So we should make the boot loader use flashy unfashionable colors because it
makes it more reliable?

Ok that's silly, but it's also silly for safety jackets.

--CJD
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Is there a reason we do not turn on the file system hardlink/symlink protection in Rawhide?

[Casey Dahlin]

On Thu, Mar 14, 2013 at 09:08:48AM -0400, Daniel J Walsh wrote:
> Well I believe Ubunto has been using this feature for years and maybe we
> should consider turning it on via systemd or a unit file.  The breakage of AFD
> is not a legitimate reason for Fedora to turn it off.

Why not add an LSM call, security_follow_restricted_link()? Then you could ship
this protection with SELinux policy, and even turn it off per-label if specific
applications need the old behavior.

--CJD
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Is there a reason we do not turn on the file system hardlink/symlink protection in Rawhide?

[Casey Dahlin]

binKWT8x6c21S.bin
Description: application/pgp-encrypted


msg.asc
Description: Binary data
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Is there a reason we do not turn on the file system hardlink/symlink protection in Rawhide?

[Casey Dahlin]

Ok, apparently Mutt is a bit stupider than I thought. Let's try this again.

On Thu, Mar 14, 2013 at 02:20:04PM -0400, Daniel J Walsh wrote:
> We already do,

Good.

> but this protection does protect unconfined_t and for those who

Maybe we're ready to except a confined user by default. Something very, very
loose.

> would dare to disable SELinux.

To hell with 'em. :)

--CJD


pgp0irRYb1paA.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: dnf installs cron.hourly

[Casey Dahlin]

On Fri, Mar 15, 2013 at 07:14:39PM +0100, Miloslav Trmač wrote:
> 1) Changing the mechanism would not resolve any of the questions discussed 
> here.

Systemd is a bit cleaner to admin, and turning the service off wouldn't make an
oddity show up in rpm -qaV like moving a cron job aside would.

> 
> 2) http://lists.fedoraproject.org/pipermail/devel/2013-February/178220.html:
>   * AGREED: Feature is approved. No packages should convert to using
> this feature yet. (7, 0, 0)  (nirik, 20:26:31)

Not sure if that applies in this case. It'd be dnf using a systemd feature, not
systemd using a dnf feature.

--CJD


pgpVo2MZBpUXU.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: dnf installs cron.hourly

[Casey Dahlin]

On Fri, Mar 15, 2013 at 07:44:58PM +0100, Tomasz Torcz wrote:
>   There was a decision of not _migrating_ cronjobs to timer units yet. But I
> think we should ban _introducing_ new cronjobs.  Instead, new periodic jobs
> should be introduced as timer units.

That's assuming all cron jobs should become systemd timer units (Lennart
himself has stated systemd timer units don't fully replace cron).

--CJD


pgpbtQ5fOwcrS.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel