Re: wayland in rawhide
On 11/26/2015 06:32 AM, Ian Malone wrote: On 25 November 2015 at 22:01, Adam Williamsonwrote: 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
On 11/20/2015 09:34 AM, Ian Malone wrote: On 12 November 2015 at 14:59, Ray Strodewrote: 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
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
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
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
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
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
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 ?
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 ??
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 ??
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
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
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
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
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
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?
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?
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
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?
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?
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?
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?
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
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?
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?
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
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
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
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
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
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
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
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
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?
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?
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?
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?
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?
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))
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))
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))
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
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
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.
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.
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
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
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 :)
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
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
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
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
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 :)
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 :)
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
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.
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
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
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
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
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