Hi,
there is a very interesting discussion on Fedora devel list:
systemd: please stop trying to take over the world :) Denys Vlasenko http://lists.fedoraproject.org/pipermail/devel/2011-June/152323.html
The poster, Denys Vlasenko, showed an inquiring mind and justified it by asking very relevant UNIX fundamental and technical questions, thus showing he is a very knowledgeable person.
I share his concerns about systemd: - going beyond system init replacement - not adhering to UNIX principles (modularity, etc) - interference with sysadmin duties/decisions to set up the system (e.g. loading modules on its own and e.g. enabling sys capabilities and protocols)
To Denys: Drill, baby, drill :-)
There are people on test and user lists who are afraid to even touch F15 ... and the reasons are systemd, GNOME 3, etc. Things called "progress" ...
I follow the discussion with great interest and so should you all.
JB
On 06/15/2011 03:39 PM, JB wrote:
Hi,
there is a very interesting discussion on Fedora devel list:
systemd: please stop trying to take over the world :) Denys Vlasenko http://lists.fedoraproject.org/pipermail/devel/2011-June/152323.html
The poster, Denys Vlasenko, showed an inquiring mind and justified it by asking very relevant UNIX fundamental and technical questions, thus showing he is a very knowledgeable person.
I share his concerns about systemd:
- going beyond system init replacement
- not adhering to UNIX principles (modularity, etc)
- interference with sysadmin duties/decisions to set up the system (e.g. loading modules on its own and e.g. enabling sys capabilities and protocols)
To Denys: Drill, baby, drill :-)
There are people on test and user lists who are afraid to even touch F15 ... and the reasons are systemd, GNOME 3, etc. Things called "progress" ...
I follow the discussion with great interest and so should you all.
JB
Both systemd and gnome 3 have caused me no end of trouble that I have had a lot of fun in managing to overcome (just like dracut did back when). In doing so, I have learned a lot more about the kernel, boot processes, various startup processes, gnome and workflow.
Reminds of my card walloping days and the transition to computers. Some made the transition to computer programming easily, some tried to wallop cards on computers and became frustrated and quit and some just quit without trying.
All this said, I am beginning to believe Fedora is more and more an experiment in social engineering.
I am having a lot of fun.
Clyde E. Kunkel <clydekunkel7734 <at> cox.net> writes:
... All this said, I am beginning to believe Fedora is more and more an experiment in social engineering. ...
That's a well-chosen remark :-) "Social engineering is the art of manipulating people into performing actions...".
I think it also applies to open source domain activities. I have had an impression over the years that users, but also ad hoc developers, are used very instrumentally ("guinea pigs" ?) as users, testers, and devs, in the process of furthering goals of open source projects or companies.
I see a dichotomy between e.g. open source companies' interests and those of larger community, be it other open source organizations or even a mass of individuals.
I am also surprised (have been for long time) by seeing Linux projects violating UNIX principles of software development. In this particular context, I am disappointed that they, apparently, lack oversight by management, starting with the design phase.
Thanks god there are still those old timers all over the places, who are vigilant and capable of spotting brewing trouble, unfortunately almost after the fact.
JB
Sorry, JB, I usually avoid posting (hence the trash email address), but not today because this hit home.
On Wed, 2011-06-15 at 22:06 +0000, JB wrote:
Clyde E. Kunkel <clydekunkel7734 <at> cox.net> writes:
... All this said, I am beginning to believe Fedora is more and more an experiment in social engineering. ...
That's a well-chosen remark :-) "Social engineering is the art of manipulating people into performing actions...".
Sometimes this does seem the case, but on the other hand considering the size of the open source community these days (as opposed to say, 1994, before there was a real label for it) there is no way to make a decision that everyone will agree with. There are too many people to please and no possible way everyone can communicate everything to each other and discuss prior to making a decision on something. Of course, these days blogging has trained people to be more self-important *and* noisier than ever. Another way of saying this is perhaps that the self-important used to do more and say less, and by simply doing they were de facto in charge. Argument from irrelevant people clogs lists more than it used to -- or perhaps I am getting old and nostalgic.
Of course the "quietly doing" part above is, and forever will be, the secret to having things your way in open source -- or actually in any tech. Working implementations of ideas carry far more weight than any argument in a mailing list.
I am also surprised (have been for long time) by seeing Linux projects violating UNIX principles of software development. In this particular context, I am disappointed that they, apparently, lack oversight by management, starting with the design phase.
This does not surprise me in the least. As open source has become more high profile it has attracted the attention of and absorbed the vanity developers who used to write their pet apps in Pascal, QBASIC or Java on Windows (or OS/2 if they were l33+), and now play with whatever vanity language is popular this week from within the confines of whatever open source project they think will make them famous(ish). This sort of developer often can't tell you who Fred Brooks, Eric Raymond, Donald Knuth, Ken Thompson, or anyone similar are and haven't read anything they've written for our benefit about design or the Unixy way to solve problems.
Chicken lipstick is in high demand, automated text processing through intelligent use of shell scripts is down, overly complex solutions are up, overweight software is up, the number of people who have ever learned to configure their system starting with a minimal install (not even touching the number of users who can't build their own system from source) is way down, etc.
These are simply signs that the community has changed because the people who remember what the Unixy way of doing things was has become a much smaller percentage of the population as we've absorbed a million haX0r d00dz from the Windows world. That expansion is not bad and the new guys certainly mean well, but we've definitely not done enough to familiarize newcomers with the history of Unix, who the original old guys were, what they were thinking, and the depth of thought that went into a project before the first line of code was written back in the day.
It doesn't help that C and Lisp are considered "too hard" to teach in allegedly credible CS undergrad courses these days. Specific discussion in class about what happens within a compiler and how processors actually process things has been replaced with rather vague generalities (those are "deep subjects that you don't need to worry about") and freed the instructors to focus on teaching elementary problem solving in Java and Python as if it is deep CS skill. In other words, elementary problem solving logic and problem deconstruction theory is now masquerading as deep computer science -- the technicals are scary so they are to be avoided (what if my students aren't smart enough to pass?!? I might look like a bad instructor -- best avoid pointer math and recursion this go-around...).
Without achieving that critical mass of fundamental knowledge it is very difficult for newcomers to the community to identify exactly why the Unix way is better than the Windows way. Their choice to join the open source community is therefore based largely on emotional and social factors -- this is counter-cultural, it's against The Man/M$/Whoever, "I think I have better security (but I don't know what that means on a deep level)", its cheaper, etc. -- not on technical grounds. Any reason is adequate in my view, but without a firmly set social more that guides newcomers to familiarize themselves with the roots of Unix and do their basic homework we cannot realistically expect Linux to remain Unixy forever.
Just my $2.00.
-Iwao
On 06/15/2011 04:19 PM, 夜神 岩男 wrote:
Sorry, JB, I usually avoid posting (hence the trash email address), but not today because this hit home.
On Wed, 2011-06-15 at 22:06 +0000, JB wrote:
Clyde E. Kunkel<clydekunkel7734<at> cox.net> writes:
... All this said, I am beginning to believe Fedora is more and more an experiment in social engineering. ...
That's a well-chosen remark :-) "Social engineering is the art of manipulating people into performing actions...".
Sometimes this does seem the case, but on the other hand considering the size of the open source community these days (as opposed to say, 1994, before there was a real label for it) there is no way to make a decision that everyone will agree with. There are too many people to please and no possible way everyone can communicate everything to each other and discuss prior to making a decision on something. Of course, these days blogging has trained people to be more self-important *and* noisier than ever. Another way of saying this is perhaps that the self-important used to do more and say less, and by simply doing they were de facto in charge. Argument from irrelevant people clogs lists more than it used to -- or perhaps I am getting old and nostalgic.
Of course the "quietly doing" part above is, and forever will be, the secret to having things your way in open source -- or actually in any tech. Working implementations of ideas carry far more weight than any argument in a mailing list.
I am also surprised (have been for long time) by seeing Linux projects violating UNIX principles of software development. In this particular context, I am disappointed that they, apparently, lack oversight by management, starting with the design phase.
This does not surprise me in the least. As open source has become more high profile it has attracted the attention of and absorbed the vanity developers who used to write their pet apps in Pascal, QBASIC or Java on Windows (or OS/2 if they were l33+), and now play with whatever vanity language is popular this week from within the confines of whatever open source project they think will make them famous(ish). This sort of developer often can't tell you who Fred Brooks, Eric Raymond, Donald Knuth, Ken Thompson, or anyone similar are and haven't read anything they've written for our benefit about design or the Unixy way to solve problems.
Chicken lipstick is in high demand, automated text processing through intelligent use of shell scripts is down, overly complex solutions are up, overweight software is up, the number of people who have ever learned to configure their system starting with a minimal install (not even touching the number of users who can't build their own system from source) is way down, etc.
These are simply signs that the community has changed because the people who remember what the Unixy way of doing things was has become a much smaller percentage of the population as we've absorbed a million haX0r d00dz from the Windows world. That expansion is not bad and the new guys certainly mean well, but we've definitely not done enough to familiarize newcomers with the history of Unix, who the original old guys were, what they were thinking, and the depth of thought that went into a project before the first line of code was written back in the day.
It doesn't help that C and Lisp are considered "too hard" to teach in allegedly credible CS undergrad courses these days. Specific discussion in class about what happens within a compiler and how processors actually process things has been replaced with rather vague generalities (those are "deep subjects that you don't need to worry about") and freed the instructors to focus on teaching elementary problem solving in Java and Python as if it is deep CS skill. In other words, elementary problem solving logic and problem deconstruction theory is now masquerading as deep computer science -- the technicals are scary so they are to be avoided (what if my students aren't smart enough to pass?!? I might look like a bad instructor -- best avoid pointer math and recursion this go-around...).
Without achieving that critical mass of fundamental knowledge it is very difficult for newcomers to the community to identify exactly why the Unix way is better than the Windows way. Their choice to join the open source community is therefore based largely on emotional and social factors -- this is counter-cultural, it's against The Man/M$/Whoever, "I think I have better security (but I don't know what that means on a deep level)", its cheaper, etc. -- not on technical grounds. Any reason is adequate in my view, but without a firmly set social more that guides newcomers to familiarize themselves with the roots of Unix and do their basic homework we cannot realistically expect Linux to remain Unixy forever.
Just my $2.00.
-Iwao
+1 Very elegantly written. I could not with you more.
If anybody would like an authoritative treatise I recommend the Unix "Blue Book" from Bell Labs (my memory fails me but I think it was also Ritchie).
夜神 岩男 <supergiantpotato <at> yahoo.co.jp> writes:
Sorry, JB, I usually avoid posting (hence the trash email address), but not today because this hit home.
Well, we are happy we woke you up :-)
... There are too many people to please and no possible way everyone can communicate everything to each other and discuss prior to making a decision on something.
I think many users/testers on this list are experienced and have a good sense of what is important. If they are not sure about it, the exchange of opinions here clears up their mind.
Fedora is, according to : http://distrowatch.com/table.php?distribution=fedora
"The Fedora Project is an openly-developed project designed by Red Hat, open for general participation, led by a meritocracy, following a set of project objectives. The goal of The Fedora Project is to work with the Linux community to build a complete, general purpose operating system exclusively from open source software. Development will be done in a public forum."
Now, I think that Fedora (thru its Red Hat sponsorship) is acting "by ambush" - that is, there is very little consideration for opinion expressed by users *prior* to schedule of new major features (projects) to be implemented in next release. It is assumed that what Red Hat thinks is good for them, Fedora, and by simple extrapolation it must be for everybody associated with Fedora (formally or not). That's why I said the users and testers are treated instrumentally.
The systemd is an example of a hard push and twisting of facts about others' participation in adopting it that backfired. The warnings were coming in advance from users community here. They were ignored as noice. Now they are coming even from within Red Hat itself, heavy guns judging by quality of arguments presented (fundamental and technical). Clearly, there is something wrong about the process of Fedora development.
Also, Red Hat and Fedora thru their systemd developer Lennart Poettering, and GNOME 3 devs, together tried to ambush Linux community at large, when they "proposed" a mutual dependency plan, exclusive to Linux and "screw other UNIX and Linux distros", in which the role of systemd went far beyond its original purpose to be a replacement of system init. That alienated many people from different corners of Linux *and* UNIX domains, as could be seen in tech magazines and various discussion forums.
I think all these mishaps and encountered resistance are examples of bad PR for Red Hat and Fedora.
I think there is a need to think about it. Please take the users and your own people more seriously if you want a viable community, Fedora distro, and later collect fruits of your past actions.
JB
On Thu, 2011-06-16 at 01:00 +0000, JB wrote:
Now, I think that Fedora (thru its Red Hat sponsorship) is acting "by ambush" - that is, there is very little consideration for opinion expressed by users *prior* to schedule of new major features (projects) to be implemented in next release. It is assumed that what Red Hat thinks is good for them, Fedora, and by simple extrapolation it must be for everybody associated with Fedora (formally or not). That's why I said the users and testers are treated instrumentally.
It's clear that we (on this user-list) are users, beta testers, and guinea pigs. And we have little function beyond finding and reporting bugs, and explaining what we've found out to others asking questions about how to do things.
On the developer lists are people with more input into how things will be done, with more potential to influence changes.
But how individual projects are managed is external, and upstream. i.e. How we get Gnome, KDE, Apache, OpenOffice, et cetera, implemented are handled by those individual project groups.
As ever, the advice is, "if you don't like it, get involved in the appropriate groups, or use something different." Which means, join the developers (some projects will be programmers only, others may have a conglomeration of designers and programmers). And can either mean switching from Gnome to something else, or from Fedora to something else. It's always been that way; use what's pre-built, or make your own.
And, as ever, some projects go off on tangents so wild that they're unacceptable to people. And projects will live and die by that. If they piss off their users that they abandon it in droves, it'll die off, and something else becomes the new fad (e.g. we've gone from Netscape to Firefox, as the main browser; and sound has gone from OSS to ALSA to PulseAudio). Or it may change direction again, and people might like the new change.
I'm one of those who're not keen on the incredible change in system requirements with the recent changes to KDE and Gnome. It's almost Windows-like in having computer staggering under the burden of a behemoth desktop, when I bought hardware I expect to be used by the applications, with the support system meant to be quietly in the background.
On 06/15/2011 04:19 PM, 夜神 岩男 wrote:
This sort of developer often can't tell you who Fred Brooks, Eric Raymond, Donald Knuth, Ken Thompson, or anyone similar are
And let's not forget the sane genius, Daniel J. Alderson. JPL is still using his programs to navigate space probes 25 years after his death, but except for a few SF fans, nobody's ever heard of him. We've all heard about people who could write FORTRAN in any language, but Dan was the only person I ever knew who could write PL/1 programs in FORTRAN. He also knew how to turn off array bounds checking and do pointer arithmetic in FORTRAN by addressing an array out of bounds. I know; I helped him do it back in the early '80s.
On Wed, 2011-06-15 at 20:15 -0700, Joe Zeff wrote:
On 06/15/2011 04:19 PM, 夜神 岩男 wrote:
This sort of developer often can't tell you who Fred Brooks, Eric Raymond, Donald Knuth, Ken Thompson, or anyone similar are
And let's not forget the sane genius, Daniel J. Alderson. JPL is still using his programs to navigate space probes 25 years after his death, but except for a few SF fans, nobody's ever heard of him. We've all heard about people who could write FORTRAN in any language, but Dan was the only person I ever knew who could write PL/1 programs in FORTRAN. He also knew how to turn off array bounds checking and do pointer arithmetic in FORTRAN by addressing an array out of bounds. I know; I helped him do it back in the early '80s.
OK, you got me with the pointer arithmetic in FORTRAN trick. That is precisely the sort of thing that the word "hack" was originally intended to indicate and the sort of wizardry only available to those who have a complete understanding of what is going on in the code, compiler and hardware.
Which brings me to a point I haven't spelled out but hinted around that Tim-of-the-famously-ignored-mailbox hit on "... not keen on... having [the] computer staggering under the burden of a behemoth desktop." If you take a look at the actual functionality inherent in the new desktop, there is no solid reason for it to be so heavy, other than the choice of implementation platform. Scripting some functionality in a high-ish language (JavaScript, if I'm not mistaken) saves development time, but it is a burden to all forever once developed. I would move that with something as basic as the desktop this may be a good initial protoyping model, but moving the desktop code closer to the metal would be a sound solution.
But the discipline (and it is a discipline) of refactoring is lost on many these days. On the other hand, consider the success Gnote had over Tomboy. One required Mono and C#, the other was a faithful refactoring in C++ that turned into a smashing success, blowing away the original (tomboy was just orphaned, I believe). Despite the supposed benefits of C#/Mono portability (or rather, "supposed portability of C#/Mono"), standards-compliant C/C++ code can be recompiled to run (nearly) anywhere. But doing it right (e.g. standards compliant and with as much correct use of standard libraries as practical) is hard. And people don't like that. In any case, by the end tomboy acted as a prototype for what became the more mainstream app, Gnote. (Please note that I am not a fan of overoptimization in code -- much evil lies down that tricky path.)
We could probably lighten the system considerably if we backed down a bit from the en vogue languages and spent some time refactoring the good-but-heavy ideas and injected a bit more of the Unix philosophy into those refactoring projects.
Another way of saying the above is that scripting used to be utilized primarily for one-shot tasks, personal functions and prototyping, while things like C and Lisp tended to wind up in production code. Scripting provides great glue -- its awesome glue -- and it gives a developer of a custom project a way to show the customer/world/himself in a jiffy "This is what the thing will do/look like -- and if you like it we'll refactor this in a real language and have it industrial strength in a few months". Today, however, entire desktop managers and ERP systems are written on interpreted language platforms in pure script (and I don't mean bash). This is not, I think, what was originally intended when higher languages were invented. All those layers introduce a lot of overhead that I find a little awkward (and mystifying sometimes, to uncover where a problem is occurring -- is it the interpreter, the kernel, the virtualization layer, the script itself; what stack where is host to a bug?).
And anyway, there are so many highly individualized vanity languages/platforms now that you have to learn a whole new API just to get under the skin of any new project now -- because the guy who had a good idea for a new mail client learned Python in school but the guy who had a good idea for a new MTA learned Ruby On Rails and the guy who wrote the latest SPA you want to use on your new experimental mail machine did it in Eiffel -- or whatever. This is not that odd of a situation. I love languages, but this proliferation is getting a bit ridiculous. One of the benefits Unix used to enjoy was its fairly standardized (not so much in comittee, just de facto standardized) set of development features and the omni-presence of bash and C. Once that became bash, C and, sat, GTK we were really in business... but its just gotten out of hand now, and that is not where Unix was originally meant to go in my opinion.
But it certainly allows a single author to re-write ten versions of the same book which all amount to "Basic problem solving and deconstruction in [Some language]". If that author teaches at a community college he looks like a genius too, and might land a real book deal eventually with O'Reilly if he blogs enough and annoys the right folks at a convention or two... but I digress.
Blah blah. The whole post was digression. I'm going to crawl back in my hole of email silence and write something terribly complicated. In ed. I feel that I need to get back in touch with my roots -- one character change at a time.
And now I resume my mailing list coma for another 10 years.
-Iwao
On 06/15/2011 11:21 PM, 夜神 岩男 wrote:
OK, you got me with the pointer arithmetic in FORTRAN trick. That is precisely the sort of thing that the word "hack" was originally intended to indicate and the sort of wizardry only available to those who have a complete understanding of what is going on in the code, compiler and hardware.
I assure you, Dan didn't do that sort of thing just because he could. He did it because it was the only way to get the job done in FORTRAN, and he couldn't use a language with pointers because the whole project was to create a set of subroutines *for* FORTRAN. If anybody really wants to know about this, email me off-list because there's no way in the world I'm going to bore and/or confuse the rest of you.
On 06/15/2011 06:06 PM, JB wrote:
I am also surprised (have been for long time) by seeing Linux projects violating UNIX principles of software development.
Linux isn't Unix. It sounds like you'd be happier running, er, Unix - or a BSD - rather than a Linux distro that is considered to be the most cutting-edge one available.
In this particular context, I am disappointed that they, apparently, lack oversight by management, starting with the design phase.
Management? Who's that? FOSS "management" mostly falls to the developers, since they're doing the work.
But regardless who you choose to identify as management, you'll probably find that they've been very supportive of systemd, mostly because it solves lots of real-world problems in an elegant way. Sure, there have been glitches (and squabbles about timing - systemd punted from F14), but again, this is a running-with-scissors distro.
Personally, I'm hugely impressed with the sped-up boot and shutdown times, and the detailed reporting (did something fail?) provided by systemctl.
Fedora is lucky to have flame-proof developers like LP who aren't afraid to try something new...
- Mike
On Thu, 2011-06-16 at 07:59 -0400, Dr. Michael J. Chudobiak wrote:
On 06/15/2011 06:06 PM, JB wrote:
I am also surprised (have been for long time) by seeing Linux projects violating UNIX principles of software development.
Linux isn't Unix. It sounds like you'd be happier running, er, Unix - or a BSD - rather than a Linux distro that is considered to be the most cutting-edge one available.
In this particular context, I am disappointed that they, apparently, lack oversight by management, starting with the design phase.
Management? Who's that? FOSS "management" mostly falls to the developers, since they're doing the work.
But regardless who you choose to identify as management, you'll probably find that they've been very supportive of systemd, mostly because it solves lots of real-world problems in an elegant way. Sure, there have been glitches (and squabbles about timing - systemd punted from F14), but again, this is a running-with-scissors distro.
Personally, I'm hugely impressed with the sped-up boot and shutdown times, and the detailed reporting (did something fail?) provided by systemctl.
Fedora is lucky to have flame-proof developers like LP who aren't afraid to try something new...
- Mike
+1
John
I am also surprised (have been for long time) by seeing Linux projects violating UNIX principles of software development. In this particular context, I am disappointed that they, apparently, lack oversight by management, starting with the design phase.
That is hardly a Unix principle given Unix itself was a hack on an old box to run spacewar as much as anything else.
Unix principles seem to have worked well - policy is in user space, initialisation is handled by user space, the kernel doesn't have to embody this.
Now systemd may be a pretty lousy attempt to replace init at this point but it is also show the basic flexibility of keeping such stuff in user space.
It may also do good things just as the fact NetworkManager was a complete pile of crap inspired various people to write conman (which in turn seems to have given the NetworkManager people the needed incentive 8))
Alan
On Wed, 15 Jun 2011 19:39:38 +0000 (UTC) JB wrote:
There are people on test and user lists who are afraid to even touch F15 ... and the reasons are systemd, GNOME 3, etc. Things called "progress" ...
I rather like systemd, not because I feel like I'll ever be able to understand it ("mind numbing complexity" is a phrase that comes to mind :-), but because it really and truly does indeed boot the system much much faster. Not small percentage benchmark faster, but big human perceptible speed increases.
Of course, at the moment, some of that speed may be because it isn't actually doing everything (like getting NFS filesystems mounted).
Tom Horsley <horsley1953 <at> gmail.com> writes:
...
I am going easy about systemd. I am not sure it is going to survive as is ...
Just a small example. # yum info avahi ... Description : Avahi is a system which facilitates service discovery on : a local network -- this means that you can plug your laptop or : computer into a network and instantly be able to view other : people who you can chat with, find printers to print to or find : files being shared. This kind of technology is already found in : MacOS X (branded 'Rendezvous', 'Bonjour' and sometimes : 'ZeroConf') and is very convenient. ...
I used to remove avahi package from my systems prior to F15 - no need for "zeroconf" here. And I could do it, if I remember it.
With F15, try it: # yum remove avahi ... =============================================================================== Package Arch Version Repository Size =============================================================================== Removing: avahi i686 0.6.30-3.fc15 @koji-override-1/$releasever 997 k Removing for dependencies: avahi-compat-libdns_sd i686 0.6.30-3.fc15 @koji-override-1/$releasever 30 k avahi-glib i686 0.6.30-3.fc15 @koji-override-1/$releasever 10 k gigolo i686 0.4.1-2.fc15 @koji-override-0/$releasever 546 k gnome-vfs2 i686 2.24.4-5.fc15 @koji-override-0/$releasever 3.3 M gnomebaker i686 0.6.4-10.fc15 @koji-override-0/$releasever 2.0 M gvfs i686 1.8.2-1.fc15 @updates 5.1 M libbonoboui i686 2.24.5-1.fc15 @koji-override-0/$releasever 1.2 M libfm-gtk i686 0.1.15-5.D20110427gita1f63c3114.fc15 @koji-override-0/$releasever 331 k libgnome i686 2.32.1-2.fc15 @koji-override-0/$releasever 2.9 M libgnomeui i686 2.24.5-2.fc15 @koji-override-0/$releasever 3.5 M libpurple i686 2.7.11-2.fc15 @koji-override-0/$releasever 27 M lxde-common noarch 0.5.5-0.2.20110328git87c368d7.fc15 @koji-override-0/$releasever 919 k lxmusic i686 0.4.4-4.fc15 @koji-override-0/$releasever 384 k pcmanfm i686 0.9.9-5.D20110422git3f899d14eb.fc15 @koji-override-0/$releasever 665 k pidgin i686 2.7.11-2.fc15 @koji-override-0/$releasever 2.9 M xmms2 i686 0.7-8.fc15 @koji-override-0/$releasever 2.5 M
Transaction Summary =============================================================================== Remove 17 Package(s)
Installed size: 54 M Is this ok [y/N]: n
Why ? May I add that avahi is a brain child of the same dev Lennart Poettering. http://en.wikipedia.org/wiki/Avahi_(software)
JB
JB <jb.1234abcd <at> gmail.com> writes:
... # yum remove avahi ...
See previous post.
Why is avahi dependent on (I have a LXDE desktop): gnomebaker - CD/DVD burner lxde-common - configuration files for LXDE lxmusic - music client pcmanfm - PCMan File Manager pidgin - instant messaging client etc.
Can anybody help ?
JB
On 06/16/2011 05:09 AM, JB wrote:
JB <jb.1234abcd <at> gmail.com> writes: See previous post.
Why is avahi dependent on (I have a LXDE desktop): gnomebaker - CD/DVD burner lxde-common - configuration files for LXDE lxmusic - music client pcmanfm - PCMan File Manager pidgin - instant messaging client etc.
Can anybody help ?
Avahi is not dependent on those things. Those things are dependent on Avahi. Further, the part you snipped in the original post shows the path that yum took to get to each program.
Avahi is required by the GNOME VFS layer (probably to find network file systems), which is in turn used by GnomeBaker and pcmanfm. Pidgin probably supports local network messaging, which is based on Zeroconf and therefore uses Avahi. xmms evidently also requires Avahi (network audio source detection? DAAP music sharing?), and lxmusic requires xmms.
This is further forced by the fact that RPM does not support optional dependencies, unlike Debian's package system. Therefore, the only way for a package to say "you should really have this" is to depend on it (assuming that VFS can even function without avahi).
But the bottom line is: Avahi is used by some core libraries like the VFS layer, which in turn are used by your applications. Taking it off requires them to go as well. You could try disabling Avahi (look at Lennart's blog posts for how to force systemd not to enable certain services) to avoid the run-time overhead if you really want.
- Michael
Michael Ekstrand <michael <at> elehack.net> writes:
On 06/16/2011 05:09 AM, JB wrote:
JB <jb.1234abcd <at> gmail.com> writes: See previous post.
Why is avahi dependent on (I have a LXDE desktop): gnomebaker - CD/DVD burner lxde-common - configuration files for LXDE lxmusic - music client pcmanfm - PCMan File Manager pidgin - instant messaging client etc.
Can anybody help ?
Avahi is not dependent on those things. Those things are dependent on Avahi. Further, the part you snipped in the original post shows the path that yum took to get to each program.
Avahi is required by the GNOME VFS layer (probably to find network file systems), which is in turn used by GnomeBaker and pcmanfm. Pidgin probably supports local network messaging, which is based on Zeroconf and therefore uses Avahi. xmms evidently also requires Avahi (network audio source detection? DAAP music sharing?), and lxmusic requires xmms.
This is further forced by the fact that RPM does not support optional dependencies, unlike Debian's package system. Therefore, the only way for a package to say "you should really have this" is to depend on it (assuming that VFS can even function without avahi).
But the bottom line is: Avahi is used by some core libraries like the VFS layer, which in turn are used by your applications. Taking it off requires them to go as well. You could try disabling Avahi (look at Lennart's blog posts for how to force systemd not to enable certain services) to avoid the run-time overhead if you really want.
- Michael
# yum remove avahi Loaded plugins: fastestmirror, langpacks, presto, priorities, refresh- : packagekit Setting up Remove Process Resolving Dependencies --> Running transaction check ---> Package avahi.i686 0:0.6.30-3.fc15 will be erased --> Processing Dependency: avahi = 0.6.30-3.fc15 for package: avahi-compat-libdns_sd-0.6.30-3.fc15.i686 --> Processing Dependency: avahi = 0.6.30-3.fc15 for package: avahi-glib-0.6.30-3.fc15.i686 --> Running transaction check ---> Package avahi-compat-libdns_sd.i686 0:0.6.30-3.fc15 will be erased --> Processing Dependency: libdns_sd.so.1 for package: xmms2-0.7-8.fc15.i686 ---> Package avahi-glib.i686 0:0.6.30-3.fc15 will be erased --> Processing Dependency: libavahi-glib.so.1 for package: gnome-vfs2-2.24.4-5.fc15.i686 --> Processing Dependency: libavahi-glib.so.1 for package: libpurple-2.7.11-2.fc15.i686 --> Processing Dependency: libavahi-glib.so.1 for package: gvfs-1.8.2-1.fc15.i686 --> Running transaction check ---> Package gnome-vfs2.i686 0:2.24.4-5.fc15 will be erased --> Processing Dependency: libgnomevfs-2.so.0 for package: libgnome-2.32.1-2.fc15.i686 --> Processing Dependency: libgnomevfs-2.so.0 for package: gnomebaker-0.6.4-10.fc15.i686 --> Processing Dependency: libgnomevfs-2.so.0 for package: libgnomeui-2.24.5-2.fc15.i686 ---> Package gvfs.i686 0:1.8.2-1.fc15 will be erased --> Processing Dependency: gvfs for package: libfm-gtk-0.1.15-5.D20110427gita1f63c3114.fc15.i686 ---> Package libpurple.i686 0:2.7.11-2.fc15 will be erased --> Processing Dependency: libpurple.so.0 for package: pidgin-2.7.11-2.fc15.i686 --> Processing Dependency: libpurple(x86-32) = 2.7.11-2.fc15 for package: pidgin-2.7.11-2.fc15.i686 ---> Package xmms2.i686 0:0.7-8.fc15 will be erased --> Processing Dependency: libxmmsclient-glib.so.1 for package: lxmusic-0.4.4-4.fc15.i686 --> Processing Dependency: libxmmsclient.so.6 for package: lxmusic- 0.4.4-4.fc15.i686 --> Processing Dependency: xmms2 >= 0.7 for package: lxmusic-0.4.4-4.fc15.i686 --> Running transaction check ---> Package gnomebaker.i686 0:0.6.4-10.fc15 will be erased ---> Package libfm-gtk.i686 0:0.1.15-5.D20110427gita1f63c3114.fc15 will be erased --> Processing Dependency: libfm-gtk.so.0 for package: pcmanfm-0.9.9-5.D20110422git3f899d14eb.fc15.i686 ---> Package libgnome.i686 0:2.32.1-2.fc15 will be erased --> Processing Dependency: libgnome-2.so.0 for package: libbonoboui-2.24.5-1.fc15.i686 ---> Package libgnomeui.i686 0:2.24.5-2.fc15 will be erased ---> Package lxmusic.i686 0:0.4.4-4.fc15 will be erased ---> Package pidgin.i686 0:2.7.11-2.fc15 will be erased --> Running transaction check ---> Package libbonoboui.i686 0:2.24.5-1.fc15 will be erased ---> Package pcmanfm.i686 0:0.9.9-5.D20110422git3f899d14eb.fc15 will be erased --> Processing Dependency: pcmanfm for package: lxde-common-0.5.5-0.2.20110328git87c368d7.fc15.noarch --> Running transaction check ---> Package lxde-common.noarch 0:0.5.5-0.2.20110328git87c368d7.fc15 will be erased --> Processing Dependency: /usr/bin/gvfs-open for package: gigolo- 0.4.1-2.fc15.i686 --> Restarting Dependency Resolution with new changes. --> Running transaction check ---> Package gigolo.i686 0:0.4.1-2.fc15 will be erased --> Finished Dependency Resolution adobe-linux-i386 | 951 B 00:00 updates/metalink | 27 kB 00:00
Dependencies Resolved
============================================================================== Package Arch Version Repository Size ============================================================================== Removing: avahi i686 0.6.30-3.fc15 @koji-override-1/$releasever 997 k Removing for dependencies: avahi-compat-libdns_sd i686 0.6.30-3.fc15 @koji-override-1/$releasever 30 k avahi-glib i686 0.6.30-3.fc15 @koji-override-1/$releasever 10 k gigolo i686 0.4.1-2.fc15 @koji-override-0/$releasever 546 k gnome-vfs2 i686 2.24.4-5.fc15 @koji-override-0/$releasever 3.3 M gnomebaker i686 0.6.4-10.fc15 @koji-override-0/$releasever 2.0 M gvfs i686 1.8.2-1.fc15 @updates 5.1 M libbonoboui i686 2.24.5-1.fc15 @koji-override-0/$releasever 1.2 M libfm-gtk i686 0.1.15-5.D20110427gita1f63c3114.fc15 @koji-override-0/$releasever 331 k libgnome i686 2.32.1-2.fc15 @koji-override-0/$releasever 2.9 M libgnomeui i686 2.24.5-2.fc15 @koji-override-0/$releasever 3.5 M libpurple i686 2.7.11-2.fc15 @koji-override-0/$releasever 27 M lxde-common noarch 0.5.5-0.2.20110328git87c368d7.fc15 @koji-override-0/$releasever 919 k lxmusic i686 0.4.4-4.fc15 @koji-override-0/$releasever 384 k pcmanfm i686 0.9.9-5.D20110422git3f899d14eb.fc15 @koji-override-0/$releasever 665 k pidgin i686 2.7.11-2.fc15 @koji-override-0/$releasever 2.9 M xmms2 i686 0.7-8.fc15 @koji-override-0/$releasever 2.5 M
Transaction Summary ============================================================================== Remove 17 Package(s)
Installed size: 54 M Is this ok [y/N]:
I included the full output this time, for documentation. Yes, indeed, e.g. avahi <- avahi-glib <- gnome-vfs2 <- gnomebaker
Thanks for the explanation, Michael.
JB
On 06/16/2011 12:13 AM, Tom Horsley wrote:
On Wed, 15 Jun 2011 19:39:38 +0000 (UTC) JB wrote:
There are people on test and user lists who are afraid to even touch F15 ... and the reasons are systemd, GNOME 3, etc. Things called "progress" ...
Well, I am "sufficiently impressed" by F15 for not using it :)
I rather like systemd, not because I feel like I'll ever be able to understand it ("mind numbing complexity" is a phrase that comes to mind :-),
So far, I am having problems to find reasons to like it :=)
It certainly solves a couple of problems sysvinit/upstart had, but is introducing new ones and without any doubt has integration issues.
but because it really and truly does indeed boot the system much much faster. Not small percentage benchmark faster, but big human perceptible speed increases.
Really? I measure almost identical times for cold-booting F14 rsp. F15.
From grub-prompt into gdm: both ca. 60s (wrist watch measured; Identical machine, similar configurations, parallel installation into different partitions of the same disk).
Ralf
On Wed, 2011-06-15 at 18:13 -0400, Tom Horsley wrote:
Of course, at the moment, some of that speed may be because it isn't actually doing everything (like getting NFS filesystems mounted).
But it does. Even with traditional network setup, just add comment=systemd.automount to the mount options in fstab. Ok, it will delay setup quite a bit as it will still have to wait for the network to become available this is what "systemd-analyze blame" says on my system (trimmed to just the first few lines):
bash-4.2$ systemd-analyze blame 47844ms netfs.service 47419ms home-home1.mount 47416ms ntpdate.service 41649ms sendmail.service 6765ms udev-settle.service 2773ms cups.service 2644ms network.service 1682ms lvm2-monitor.service 977ms fedora-storage-init.service 678ms fedora-storage-init-late.service
It apparently takes > 45 seconds to establish network connections (on my 3Com switch with VLANs) So in total my system takes 78 seconds to boot, including mounting of NFS4 file systems. With the systemd automount stanza, I see the first mount fail, but then it gets retried later. I have been too lazy to try to improve boot times. I am glad the system starts correctly Louis
JB wrote:
- going beyond system init replacement
- not adhering to UNIX principles (modularity, etc)
- interference with sysadmin duties/decisions to set up the system (e.g. loading modules on its own and e.g. enabling sys capabilities and protocols)
It would be nice if there were more integration with system-config-services or a better, more modern replacement.
I never needed all of those run levels, It was just confusing and useless complexity. And 2-3 of them were always unused anyway, so getting rid of them was sensible.
Why shouldn't it load modules on its own? If the system can take care of running itself, then all the less for me to worry about. I don't want to have to configure every little thing; I want the system to run itself. But, I do like to be able to configure those things that interest me. I think that Fedora 15, as it is now, allows me this.
There are people on test and user lists who are afraid to even touch F15 ... and the reasons are systemd, GNOME 3, etc. Things called "progress"
That's their problem. My computers are running as I want them to and I have no complaints. Love progress, even when it means I have to unlearn some old stuff and adapt to improvements.
If you don't like gnome 3 or kde 4, then there are lots of other window managers in the fedora repos, or you can go all cli by logging in to vt-2 to vt6.
Petrus de Calguarium <pgueckel@...> writes:
... Why shouldn't it load modules on its own? If the system can take care of running itself, then all the less for me to worry about. I don't want to have to configure every little thing; I want the system to run itself. But, I do like to be able to configure those things that interest me. I think that Fedora 15, as it is now, allows me this.
Here is the answer - you should be more sceptical about systemd's "helpfulness":
http://lists.fedoraproject.org/pipermail/devel/2011-June/152596.html
... If you don't like gnome 3 or kde 4, then there are lots of other window managers in the fedora repos, or you can go all cli by logging in to vt-2 to vt6.
Yes, indeed - LXDE is my new desktop. I love classics :-)
JB
On 06/16/2011 04:53 AM, JB wrote:
Here is the answer - you should be more sceptical about systemd's "helpfulness":
http://lists.fedoraproject.org/pipermail/devel/2011-June/152596.html
The mail you are referring to is wrong on several details. IPV6 is entirely optional in systemd for instance. I would advise anyone reading that mail to read the entire thread including the replies
Rahul
On Wed, 2011-06-15 at 16:56 -0600, Petrus de Calguarium wrote:
I never needed all of those run levels, It was just confusing and useless complexity. And 2-3 of them were always unused anyway, so getting rid of them was sensible.
Most of the time, we don't. But then it can be handy for some boxes to have different run-levels.
e.g. A server that's usually left alone on the shelf, occasionally remote managed by command line. Even less occasionally, you might plug a keyboard and monitor into it, and want a full graphical environment while you work on it. It's handy to be able to start-up/shut-off all the unnecessary user-interfaces in one go.
e.g. Fixing up a machine that's just gone out of whack. It's handy to be able to easily start up in a mode where nearly all services are not started up. So you can do repairs, or reset the list of what will start-up, and get a computer to actually finish booting when something it used to demand existed no-longer does (like NFS-mounted resources when you unplug a machine to use in another location).
I'm yet to read how this important functionality, to a large number of people will be handled, with the move away from the old system.
On 06/16/2011 08:28 AM, Tim wrote:
Most of the time, we don't. But then it can be handy for some boxes to have different run-levels.
e.g. A server that's usually left alone on the shelf, occasionally remote managed by command line. Even less occasionally, you might plug a keyboard and monitor into it, and want a full graphical environment while you work on it. It's handy to be able to start-up/shut-off all the unnecessary user-interfaces in one go.
e.g. Fixing up a machine that's just gone out of whack. It's handy to be able to easily start up in a mode where nearly all services are not started up. So you can do repairs, or reset the list of what will start-up, and get a computer to actually finish booting when something it used to demand existed no-longer does (like NFS-mounted resources when you unplug a machine to use in another location).
I'm yet to read how this important functionality, to a large number of people will be handled, with the move away from the old system.
http://fedoraproject.org/wiki/How_to_debug_Systemd_problems#Boot_into_rescue...
Rahul
-
Alan Cox -
Clyde E. Kunkel -
Dr J Austin -
Dr. Michael J. Chudobiak -
JB -
Joe Zeff -
Louis Lagendijk -
Michael Ekstrand -
Mike Wright -
Peter G. -
Rahul Sundaram -
Ralf Corsepius -
Tim -
Tom Horsley -
夜神 岩男