[gentoo-user] Re: systemd and kernel developers cooperating to turn it into a global cgroup manager?
Daniel Campbell wrote: Do you know the design consequences of opt-in versus opt-out? I'll keep this short: When evolving a codebase, new behavior for core parts of the system should not be pushed or forced on users. If you must, keep the old behavior around as a default and allow users to try the new thing by explicitly opting in. The new naming in whichever udev started the mess did it the exact opposite (and wrong) way. Good luck with that argument; you have to bear in mind Gentoo devs are mostly fresh out of Uni (or still in it.) They're not very experienced iow, as a rule, apart from in Gentoo ebuilds and making the tree work together, which is all we ask of them. Oh and usually Java from Uni; they typically have a snobbery about shell as well (and doesn't it show) which is quite amusing when one considers their implementation language. (No this is not to the topic per se: it's a wider point that I had to repeat to someone recently, who apparently found the insight very useful. So I put it out there for other users, or those to come. I have zero interest in arguing the toss with anyone: you're welcome to your opinion, that's mine. You ain't gonna change it, so don't bother trying. Feel free to rant amongst yourselves. ;) The point is that this is actually why Gentoo is a very good place for a developer to cut hir teeth: they learn from the other users when they install, and usually come up through the forums, where if you've ever been to OTW, the difference between a personal attack and criticism of someone's work is blatantly obvious. Further they have to run any major design ideas past that same experienced user-base, who had the rough edges knocked off ages ago, and simply want it to work for everyone. They don't always see it like that, ofc, but I for one remember thinking much dumber things. [1] The way the new behavior was introduced may have led users of single-NIC systems to believe that the old way was broken, when as demonstrated through past use, works *just fine* for single-NIC machines. It was *multi-NIC* use that wasn't as predictive and needed the fix, not *single*. It's basically using poor design/defaults decisions to smear existing technology dishonestly. Technical propaganda, so to speak. Even more amusing when you consider that the original race that was so terrible it justified breaking the machines of those it was supposedly in aid of, as well as those of people who had zero use for it, yet were apparently the target market, was in fact implemented by the same set of early userspace experts who put themselves forward as such 5 years previously. I personally have no words to describe such a situation beyond idiocy. Getting back to the original topic, cgroups sound like a pretty neat idea that other init systems could benefit from. If the systemd guys are willing to work on that subsystem for themselves, are they also interested in seeing what other init systems would want from cgroups? This is actually what I posted about: I know qnikst already implemented a large chunk of functionality in openrc and was concerned about the proposed changes mainly because as usual it was a grand statement of intent, with little in the way of coherent content. But we're spitting in the wind: you can't expect amateurs who've backed themselves into a corner, full of ego-attachment to their work, to ever admit it's crap, or that they fscked-up. Certainly not based on the record of this team. Certainly there's more room for development and/or standardization on an API instead of a single project having all the influence. I think their presence and activity with cgroups could be beneficial if policed by another init system project that's not trying to infect every Linux distro. Yes one would think before embarking on such a venture they'd at least take a look at other things that also run on Linux in the same domain, such as s6, runit or openrc. But no, systemd is allowed to take them over, but no consideration can be given to those use-cases, because this is only about cgroups. It's orthogonal, maan. You're not alone; careful though as you just get labelled a hater even when you've tried your damndest to collaborate with the other side (who are the only ones even interested in sides) only to come up against groupthink, double-speak, and monkeys flinging poo. You're not with us so you *must* be against us! No. We just do not care. Ah you is haterz. Bye then; enjoy the kool-aid. [1] http://www.iusedtobelieve.com/ -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
[gentoo-user] Re: Re: Flexibility and robustness in the Linux organisim
On Mon, Sep 30, 2013 at 12:04:38AM +0200, Alan McKinnon wrote: On 29/09/2013 23:41, Dale wrote: Alan McKinnon wrote: On 29/09/2013 18:33, Dale wrote: that gnome is very hostile when it comes to KDE or choice is not news. And their dependency on systemd is just the usual madness. But they are not to blame for seperate /usr and the breakage it causes. If not, then what was it? You seem to know what it was that started it so why not share? He already said it. Someone added a hard disk to a PDP-9 (or was it an 11?) Literally. It all traces back to that. In those days there was no such thing as volume management or raid. If you added a (seriously expensive) disk the only feasible way to get it's storage in the system was to mount it as a separate volume. From that one single action this entire mess of separate /usr arose as folks discovered more and more reasons to consider it good and keep it around Yes you elide over that part, but it's central: there were more and more reasons to consider it good, and to use it. You said it. They haven't gone away just because some prat's had a brainwave and needs a lie-down, not encouragement. In fact most of them are touted as USPs in the propaganda we get told is a reasoned argument for ditching all our collective experience. That wasn't the question tho. My question wasn't about many years ago but who made the change that broke support for a seperate /usr with no init thingy. The change that happened in the past few years. I think I got my answer already tho. Seems William Hubbs answered it but I plan to read his message again. Different thread tho. Nobody broke it. It's the general idea that you can leave /usr unmounted until some random arb time later in the startup sequence and just expect things to work out fine that is broken. It just happened to work OK for years because nothing happened to use the code in /usr at that point in the sequence. Actually because people put *thinking* into what things were needed in early boot and what were not. In fact *exactly the same* thinking that goes into sorting out an initramfs. Only you don't need to keep syncing it, and you don't need to worry about missing stuff. Or you never used to, given a reasonably competent distro. Which was half the point in using one. Thankfully software like agetty deliberately has tight linkage, and it's simple enough to move the two or three things that need it to rootfs; it's even officially fine as far as portage is concerned (though I do get an _anticipated_ warning on glibc upgrades.) More and more we are seeing that this is no longer the case. So no-one broke it with a specific commit. True enough. Cumulative lack of discipline is to blame, although personally I blame gmake's insane rewriting of lib deps before the linker even sees them, that makes $+ a lot less useful than it should be, and imo led to a general desire not to deal with linkage in the early days of Linux, that never went away. It has always been broken by design becuase it's a damn stupid idea that just happened to work by fluke. *cough* bullsh1t. IT and computing is rife with this kind of error. Indeed: and even more rife with a history of One True Way. So much so that it's a cliche. Somehow it's now seen as hip to be crap at your craft, unable to recognise an ABI, and cool to subscribe to N + 1 True Way, as that's an innovation on the old form of garbage. And yet GIGO will still apply, traditional as it may be. Peace and hugs ;) steveL -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
[gentoo-user] Re: Re: Flexibility and robustness in the Linux organisim
On Mon, Sep 30, 2013 at 11:37:53PM +0100, Neil Bothwick wrote: On Mon, 30 Sep 2013 17:05:39 -0400, Walter Dnes wrote: If *something1* at boot time requires access to *something2* at boot time that isn't available then I would say that *something1* is broken by design not the *something2*. What about the case where *something2* *USED TO BE AVAILABLE, BUT HAS BEEN MOVED TO /USR* ? What about the case where something1 wasn't required at boot time but changed circumstances mean it now is? What about it? Honestly it's like you lot don't know the basics of scripting or something. $PATH ffs. (And don't start on at me about badly-coded apps: fix the apps, or the ebuilds not the OS: it's not broken, and certainly does not need to worked-around.) So I would argue that devs relying on /usr always being there have broken the system. So I would argue that unnecessarily moving stuff into /usr is deliberate sabotage, designed to break *something1*. Define unnecessarily in that context? You can't, not for all use cases. There are many files that clearly need to be available early on, and many more that clearly do not. Between them is a huge grey area, files that some need and some don't, that may be needed now or at some indeterminate point in the future. If you put everything that may conceivably be needed at early boot into /, you shift a large chunk of /usr/*bin/ and /usr/lib* into /, effectively negating the point of a small, lean /. That puts us right back where we started, try to define a point of separation that cannot be defined. Funny, sounds a lot like deciding what to put in an initramfs. And frankly it's untrue[2]. Most of the core system utilities have long been intended to run people's systems. All you need to do is stop pretending nu-skool rubbish is as good as the stuff that's survived decades of use. By definition the latter is a much smaller pool of much higher-quality than the mountains of new unproven and untested stuff, that keeps falling over in real life. Exactly the same happened back then: we just don't see the admittedly smaller mountains of crap that fell by the wayside after a year or five. initramfs is the new /, for varying values of new since most distros have been doing it that way for well over a decade. Only it's not, since you're responsible for keeping it in sync with the main system. And for making sure it has everything you need. And hoping they don't change incompatibly between root and initramfs. The point is the burden has shifted, and made the distribution less of a distribution and more of a DIY, and tough sh1t if it don't work, you get to pick up the pieces we broke irrespective of how many scripts you provide to do work that was never needed before, and technically is not needed now[1] It will break. Everything does at some point or another. So I for one don't need the extra hassle from a totally unnecessary extra point of failure. Good luck to you if that's how you roll; just don't tell me what choices I should make, thanks. Regards, steveL. [1] http://forums.gentoo.org/viewtopic-t-901206.html [2] http://forums.gentoo.org/viewtopic-t-901206-start-75.html ..shows how few things you actually need to move. Note portage is fine with the directory symlinks from /usr to / (I checked with zmedico before I wrote it up.) Also the bug in lvm initscript got fixed, but I still much prefer my machine to have the few extra MB in rootfs, and be able to chuckle at all the eleventy-eleven FUD about those 2 directories. -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
[gentoo-user] Re: Re: Flexibility and robustness in the Linux organisim
On Tue, Oct 01, 2013 at 06:35:58PM +0200, Volker Armin Hemmann wrote: wrong analogy and it goes down from here. Really. Ohh, but they are inspired on YOUR analogy, so guess how wrong yours was. your trolling is weak. And since I never saw anything worth reading posted by you, you are very close to plonk territory right now. If his analogies are weak, that's deliberate: to show that your analogy is just as weak. Irrespective of why /usr was first added, or that it was in fact what /home now is, it's proven useful in many contexts. That you don't accept that, won't convince anyone who's lived that truth. All you'll do is argue in circles about irrelevance. The setup of a separate /usr on a networked system was used in amongst other places a few swedish universities. seperate /usr on network has been used in a lot of places. So what? Does that prove anything? Nope, it doesn't. Er quite obviously it proves that a separate /usr can be useful. In fact so much so that all the benefits of the above setup are claimed by that god-awful why split usr is broken because we are dumbasses who got kicked out of the kernel and think that userspace doesn't need stability post, as if they never existed before, and could not exist without a rootfs/usr merge. Seriously, /var is a good candidate for a seperate partition. /usr is not. They both are. Not very convincing is it? Seriously, if you don't see the need for one, good for you. Just stop telling us what to think, will you? too bad POSIX is much older than LSB or FHS. Too bad separate /usr is much older than initramfs. too bad that initramfs and initrd are pretty good solutions to the problem of hidden breakage caused by seperate /usr. If you are smart enough to setup an nfs server, I suppose you are smart enough to run dracut/genkernelco. If you are smart enough to run dracut/genkernelco I suppose you are smart enough to see the wrongness of your initial statement too bad POSIX is much older than LSB or FHS. too bad I am right and you are and idiot. Originally, the name POSIX referred to IEEE Std 1003.1-1988, released in 1988. The family of POSIX standards is formally designated as IEEE 1003 and the international standard name is ISO/IEC 9945. The standards, formerly known as IEEE-IX, emerged from a project that began circa 1985. Richard Stallman suggested the name POSIX to the IEEE. The committee found it more easily pronounceable and memorable, so it adopted it That is from wikipedia. 1985/1988. When were LSB/FHS created again? FHS in 1994. Hm You really are obtuse. You should try to consider what *point* the other person is trying to make before you mouth off with superior knowledge that completely misses it. *plonk* ditto. AFAIC you're the one who pulled insults out, when in fact you were *completely* missing the point. Bravo. -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
[gentoo-user] Re: separate / and /usr to require initramfs 2013-11-01
On Sat, Sep 28, 2013 at 09:17:02PM +0100, Neil Bothwick wrote: On Sat, 28 Sep 2013 19:04:41 +, Alan Mackenzie wrote: I suppose that what I am about to say isn't really relevant, but it is unfortunate over the past year that people blamed udev specifically for this. It is true that it does things that don't work if /usr isn't mounted, but eudev does as well, since it is basically the same code. Who else is there to blame? We are continually being told that a separate /usr is broken, as though this were some unfortunate act of insert your deity here, much like an earthquake. This gets patronising really quickly. (Please note, I'm NOT blaming you here. I appreciate that you're as much victim as Dale or me or anyone else round here.) It's evolution. Linux has for years been moving in this direction, now it has reached the point where the Gentoo devs can no longer devote the increasing time needed to support what has now become an dge case. Yeah and that's just vague crap without content ;) No, this breaking of separate /usr was done by some specific project, some specific person, even, in a supreme display of incompetence, malice, or arrogance. How come this project and this person have managed to maintain such a low profile? There seems to have been some sort of conspiracy to do this breakage in secret, each member of the coven pushing the plot until the damage was irrevocable. Who was it? So which was it, one specific person or a coven of conspirators? This is open source, secret conspiracies don't really work well. If this really was such a bad move, do you really think the likes of Greg K-H would not have stepped in? Or is he a conspirator too? No he's just a bit naive: he wants to believe the best of people and did not realise quite how sneaky Poettering is. No doubt he still doesn't. But I'm sure he never foresaw some of their shenanighans, such as claiming their newly inserted breakage was the fault of device-drivers and everyone should switch to their funky new way of loading modules. No-one seemed to think what Torvalds said was incorrect, even if they disagreed with his tone. And yet that's exactly the same crap they pull in user-space, only they seem to think the kernel mentality of userspace is crazy is a howto methodology. -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
[gentoo-user] Re: Re: Re: Flexibility and robustness in the Linux organisim
On Fri, Oct 11, 2013 at 09:50:05AM +0200, Alan McKinnon wrote: On 11/10/2013 09:54, Steven J. Long wrote: On Mon, Sep 30, 2013 at 12:04:38AM +0200, Alan McKinnon wrote: On 29/09/2013 23:41, Dale wrote: Alan McKinnon wrote: From that one single action this entire mess of separate /usr arose as folks discovered more and more reasons to consider it good and keep it around Yes you elide over that part, but it's central: there were more and more reasons to consider it good, and to use it. You said it. snip It has always been broken by design becuase it's a damn stupid idea that just happened to work by fluke. *cough* bullsh1t. IT and computing is rife with this kind of error. Indeed: and even more rife with a history of One True Way. So much so that it's a cliche. Somehow it's now seen as hip to be crap at your craft, unable to recognise an ABI, and cool to subscribe to N + 1 True Way, as that's an innovation on the old form of garbage. And yet GIGO will still apply, traditional as it may be. I have no idea what you are trying to communicate or accomplish with this. Oh my bad, I thought this was an informal discussion. On a formal level, I was correcting your assumption, presented as a fact, that the only reason root and /usr split has worked in the past is some sort of fluke. Further your conflation of basic errors in software design with a solution to anything at all: the same problems still go on wrt initramfs, only now the effort is fractured into polarised camps. All I see in all your responses is that you are railing against why things are no longer the way they used to be. That's just casting aspersions, so I'll treat it as beneath you. It's certainly beneath me. -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
[gentoo-user] Re: Re: separate / and /usr to require initramfs 2013-11-01
On Fri, Oct 11, 2013 at 09:42:33AM +0100, Neil Bothwick wrote: On Fri, 11 Oct 2013 09:36:02 +0100, Steven J. Long wrote: It's evolution. Linux has for years been moving in this direction, now it has reached the point where the Gentoo devs can no longer devote the increasing time needed to support what has now become an dge case. Yeah and that's just vague crap without content ;) I bow to your superior expertise in that field :) Yup I have to filter out crap all day every day, usually crap I wrote. So which was it, one specific person or a coven of conspirators? This is open source, secret conspiracies don't really work well. If this really was such a bad move, do you really think the likes of Greg K-H would not have stepped in? Or is he a conspirator too? No he's just a bit naive: he wants to believe the best of people and did not realise quite how sneaky Poettering is. No doubt he still doesn't. But I'm sure he never foresaw some of their shenanighans, such as claiming their newly inserted breakage was the fault of device-drivers and everyone should switch to their funky new way of loading modules. No-one seemed to think what Torvalds said was incorrect, even if they disagreed with his tone. I don't understand why people keep banging on about Poettering in this, previously finished, thread. You brought up the background, wrt Greg K-H. Regardless of how you feel, I'm not alone in considering Poettering's (and Seivers') behaviour underhanded. And all this stuff about the situation just arose is only true, if you accept Poettering's propaganda^W arguments as given. So yes, he's very relevant. Sorry for not keeping current with the threads; I'll not post any more to respect the deadline.. -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
[gentoo-user] Re: Gentoo is so AWESOME
Nicolas Sebrecht wrote: Steven J. Long wrote: Again you're wilfully misinterpreting what I've said, and answering a completely different point. You didn't know the basics of how to go about approaching Gentoo. While I (and others BTW) My point is simply this: there is a world of difference between someone who simply sends two emails to the wrong place, a busy list that often has a lot of controversy on it, and someone who actively helps out other users, files bugs, patches and new or updated ebuilds and knows enough to be of use in #gentoo-dev-help. FTR, I do not count myself amongst that latter group. I just know them when I see them; but they're always known to gentoo folks already. was trying to provide an external POV with points to make outside contributions and rectruitement more efficient, You've sold your tirades under that banner, yes. I'm not buying; as is prob'y clear. you guys @gentoo.org turned this thread into plain bullshits. As has been pointed out, I am not @gentoo.org. Sorry for use of 'we' in that context: I was perhaps reacting emotionally as well. Frankly I'd taken care to spell out exactly what I was saying, and you just ignored the content, and reacted to the perceived insult. Starting with a statement like Please note I'm not discussing any technical ability you may or may not have. does not allow you to make the exact opposite Again: I was not discussing technical ability. Knowing the basics of how Gentoo operates is not a technical challenge. So you're wrong: I never disparaged your technical ability as a developer. Perhaps you should just take what people type at face value: it saves a lot of confusion. Especially given the differences in language that occur; that was why I spelt it out. and being insulting or border-line in the rest of your mails. I was being sarcastic in my last mail. Prior to that I was truly simply trying to explain, where you'd gone wrong. Further, I spoke informally (wtf did you expect?) since I assumed you were comfortable with the informality that is pretty much par for the course on most mailing-list and web-forums. And I stand by that: if you don't do the groundwork, I have zero sympathy for you. Of much more concern, and where the cultural shift needs to take place, are the people who do the groundwork, and are proven useful to the community and the project, but never acknowledged. Many of them have a decade or two of experience at least in Computing, and they'd be valuable and productive members of the dev-team, as well as bringing some longer-term perspective. But I actually think this whole thread is a change in that direction: developers are reaching out and asking for people to get involved, and engaging with those who have already been doing that, as well as providing the basic info to those who haven't. So in terms of Gentoo and the project we care about, things are getting better. IMO. BTW everything I say is my opinion. I don't usually bother to qualify it, as it's obvious imo. I don't remember I ever faced to such direct and personal judgments in the open source world. Blimey, you have led a sheltered life. You'll grow a thicker-skin: you'd better if you intend to do much in FLOSS. But feel free to hate me: you won't be alone, and I have grown a thicker skin over the last few years, so I'll cope. Oh, I know you pretend it's not. No, I just think you take yourself too seriously. And you still haven't really sat down and considered the points I made in my first mail, which you prefer to have restated in order to ignore again, afaic. So, I'm on my way, dear, in order to: - learn how to approach a community (stuff that practically every user knows); And yet you didn't, nor did you bother to do much looking around on the websites. More importantly, if you are intending to collaborate with a wider community, that believe me can be an awful lot nastier than me, you *really* cannot handle that being pointed out. You might want to work on that. - learn where to find the doc and read it; - learn all the basics; Hallelujah. I look forward to your contributions on bugzilla, the forums, IRC and sunrise. - not magnify myself. Thank you for all the smart feedbacks. Obvisously, it was all about me. You did make it all about you, yeah. And then took everything personally as an attack on you, when two minutes' reflection (or a re-read) would have shown you that the basics were nothing at all to do with coding, and everything to do with Gentoo processes. F**k I want to believe you don't embody the dominant POV of the Gentoo maintainers about the original topic. / I don't embody any official position on anything. However, from my experience, I think most people would expect you, or anyone else, to have at least done some basic research about the organisation they claim to want to join. I'm going serioulsy tired of this thread. Me too. Repeating myself
[gentoo-user] Re: Gentoo is so AWESOME
Nicolas Sebrecht wrote: hasufell wrote: You can use the command line too. www-client/pybugz I know this tool. I did try it. At that time it was buggy and did not work for me. Though, this would still be a busy process as this is just another interface og the bugzilla thing. It's another command to run, just like git. As others have pointed out, the use of a bug-tracker is important in terms of managing the process. That still stands. Git workflow has been on the todo list for a long time, as well as review systems such as gerrit. It is non trivial to implement Other than the git repository size requiring a huge initial clone, it's very easy to do. And yes, I've read all the headaches on the Gentoo mailing lists about the git migration. Using git and accepting patches on a mailing-list wouldn't change the process you discuss: it would just make everything harder to manage, and require more work on the part of maintainers. And there are no people working full-time on Gentoo ebuilds, in contrast to Linux kernel development. So aiming for that as a model, is simply a bad idea: the circumstances and the time available are radically different. As is the product. Also, Gentoo organization has two heads making ambitious dicisions hard to take. And AFAIKS, to decision process in Gentoo is not helping at all. We are far from how it worked at the genesis/beginning of Gentoo. I don't agree: Gentoo is much stronger now. But more importantly I don't see this as relevant in the slightest. You appear to be whinging basically, that you weren't welcomed with open arms on the strength of your email to the list, so you emailed again and no-one cared. And going from there to drawing wider conclusions on a the whole setup, as if that's the reason you were snubbed *sniffle*. Total non- sequitur imo. It is non trivial to implement and none of it is an excuse for not contributing IMO ;) Those are enhancements and we are already working on it. Get your hands dirty. Oh, yes. Pass the recruitement process to enhance the recruitement process, workflow and decision process (not possible to change, IMO). Funny! :-) No: just contribute. Again, I proposed myself to the dev list two times in the past. Nobody cared and I had no answers. Because that has never been the process: anyone can post to the mailing-list, it doesn't mean anything. While I agree it would have been good if recruiters had followed it up with you, if you're so new to Gentoo that you think the ML is how to start, then I can see why people might feel you needed to learn more, perhaps by reviewing the documentation. And if that's too much to ask, then perhaps you're not cut out to be a Gentoo developer: ime you need to be more of a self-starter just to use the distro. Please don't get me wrong: I think the recruitment process could be improved, in particular by having more developers working on it. And that does take a cultural shift, in terms of seeing recruitment as important, and a desirable thing to work on, as well as in terms of being more proactive and welcoming to newcomers, and to external perspectives. Neither of those change the fact that you don't join a team just by sending them an email. Like it or not, there are social factors involved, or it wouldn't be a team of people, however loosely associated. And if you cba to review the basics, stuff most users know, or can find out easily, what makes you think you're cut out to be a developer? Please note I'm not discussing any technical ability you may or may not have with bash, ebuilds or upstream sources. Just your ability to find out the basics, which is much less difficult than installing Gentoo in the first place. If you want/ed to be a developer, my advice would always be: show you're useful, not that you need hand-holding and ego-stroking from the get-go. -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
[gentoo-user] Re: Moving from old udev to eudev
Samuli Suominen wrote: Futhermore predictable network interface names work as designed, Unfortunately the design is crap. -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
[gentoo-user] Re: Moving from old udev to eudev
Samuli Suominen wrote: FUD again. The backwards compability is still all there and udev can be built standalone and ran standalone. Sorry I'm going to call bullshit on this one. You know damn well upstream moved udev into systemd, promising everyone it would be possible to continue to build just udev, and then changed that with weasel words into build everything and extract udev. So you cannot build udev standalone any more, as you state. You have to build systemd and then extract the udev stuff you actually want. You don't like other projects bundling dependencies, but somehow it's ok for systemd. Utter tripe. And on the contrary, there was no need for sys-fs/eudev to remove support for sys-fs/systemd when it could have supported both sys-apps/systemd and sys-apps/openrc like sys-fs/udev does without issues. Huh? WTF would be the point, when systemd bundles udev? We already have loads of people on the forums having issues with conflicts between sys-apps/systemd and sys-fs/udev, so again your point is total nonsense. None of which detracts from for your sterling work on Gentoo, and the support you provide to users on various media. -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
[gentoo-user] Re: Gentoo is so AWESOME
Nicolas Sebrecht wrote: Steven J. Long wrote: Again, I proposed myself to the dev list two times in the past. Nobody cared and I had no answers. Because that has never been the process: anyone can post to the mailing-list, it doesn't mean anything. While I agree it would have been good if recruiters had followed it up with you.. .. Neither of those change the fact that you don't join a team just by sending them an email. Like it or not, there are social factors involved, or it wouldn't be a team of people, however loosely associated. If social factours is important, it is not just that FMPOV. I never said it was though, did I? However you cannot just ignore those social factors, however much you might prefer to. You must know that from work, so why is this so hard to accept? Anyway, you seems to think the way Gentoo shares code and knowledge is good enough as-is to have contributors and new developers. Another strawman, after I've just stated: Please don't get me wrong: I think the recruitment process could be improved.. that does take a cultural shift. Again you appear to be reacting emotionally. Feel free to have a hissy-fit: that's the kind of thing that turns people off you. Not sure what you mean about sharing code: it's all mirrored across the world multiple times so I don't really recognise your point about a deficit of sharing. Fine. I don't think so and the other contributions to this thread confort me in my opinion. Yes well, somehow I think you're more interested in comfort for your opinions, most especially of yourself, than actually moving anything forward for everyone. Please, take the critism the constructive way. The topic is not about me. The same goes for you: and it was about you, since all you wanted to discuss were how your two emails (the effort!) were ignored, and then draw wide-ranging conclusions that were non-sequitur. I did try to discuss what actually happens, and where you went wrong. You haven't considered what I've said, only used it as reason for spurious argument. Pointing out my hand-holding, ego-stroking or whatever looks pointless. I wasn't: I was pointing out your apparent need for those, which seems to have continued into this email. You've turned it into about what a great developer you are, and how much we're missing by not having your contribution. Even though I specifically stated: Please note I'm not discussing any technical ability you may or may not have. I know the basics. Again you're wilfully misinterpreting what I've said, and answering a completely different point. You didn't know the basics of how to go about approaching Gentoo. Stuff that practically every user knows, or can find out *very* easily: much more easily than the documentation they end up searching to do an install and maintain their machine/s. Again, if you cba to do that basic groundwork, wtf do you expect? Oh yes, us all to fall over ourselves and fete you with discussion about how wonderful you are, and how lucky we'd be if you only deigned to contribute some of your wisdom to us mere mortals. So much so that we ignore all the usual metrics, and take your email as gospel truth, that overrides whether you are actually a good fit for Gentoo, or even whether you can lookup docs on a website, let alone have actually contributed as part of the community. Good luck with that approach, and your current projects. -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
[gentoo-user] Reinventing the wheel
Alan McKinnon wrote: Steven J. Long wrote: POSIX 4: Programming for the Real World (Gallmeister, 1995) UNIX Network Programming vol 2: Interprocess Communications (Stevens, 1999) More here: https://foss.aueb.gr/posix/ I'll look into those, but do take note those books are 14 and 18 years old Yes I am aware of that ;) The age is not the point. The content and its relevance are. Further, you want Lewine 1994, first published 1991, if you're at all concerned about portability, so make it 20 years; and that doesn't get you the deep insight that really matters: read the books on the site in order if you want that, doing the exercises if you want to actually implement stuff. And ask in #friendly-coders for some more books ;) - that's eternity in our world. It's only really an eternity in compute-time, afaic. Calling something innovation doesn't make it innovative. And it certainly doesn't make it an invention. Nor is the speed with which fads and modern capitalism can move, any indication of progress. Sure a lot's happened. But not much has changed. One True Way is still around, it's just mutated into N+1 True Way, as we read something about Plan to throw one away, you will anyway and we've innovated that to Throw every version away as we don't know what an ABI promise means, and it's soo easy just to push a binary update, when you don't have to deal with the consequent service failure. Basics never change, details do. Some features are here for the long haul and I doubt anything will really change them: pipes, named pipes, unix sockets and things of that ilk. Which is why a 14-year old book describing them is still valid. There's actually a decade of other books by Stevens before that, and APUE (on the site) was updated in 2005 by Rago (who was writing about SysV networking at the same time as the first UNP and APUE.) Stevens himself died unfortunately: a _great_ loss. If you look on the site, you'll see vol 1 of UNP was also updated. And that's where the eternity of changes have really taken place: in remote networking, not in local IPC, which is a solved problem. If you know the background. And a programmer always should (or get another job, if learning it is too much.) There are newer versions of both APUE and UNP vol 1, but I hear they're not as good. So I'll get them when they're a bit cheaper, and I have some idle time. The real bugbear with IPC is people reinventing the wheel over and over and over to do simple messaging - Which is exactly why it pays to know about the existing mechanisms instead of trying to reinvent them. What you're saying here is exactly my point. writing little daemons that do very little except listen for a small number of messages from localhost and react to them. Use a generic message bus for that! There's no need. Most apps have a select/poll routine (or the equivalent) in any case, especially the ones that respond to events, including pretty much all desktop apps. So either you respond to the IPC channel in the main event routine, or you do some in a thread. There's several mechanisms, and several methods to do different things. POSIX gives you the standardised components: it's up to you to put them together. wrt a generic message bus that's called a message queue. And a programmer who finds them too difficult to use is basically a nub. I've read people say that because it's not an fd, it's not worth using. Which is completely amateur afaic: that's an awfully small comfort-zone. By all means push for an eventfd in POSIX: but in the meantime, be capable of more than one thing. AF_UNIX datagram sockets are fine too, and are in fact what dbus uses. As I said, I never actually criticised dbus itself: I'm fine with a desktop-session bus, to multiplex and broadcast the various events of user interest, and I quite liked the protocol when I first read up on it. To use that as basic plumbing for other things, is a bad idea imo. All you're doing is implementing a central point of failure, that has the additional borkage of being involved with user desktop events. A complete encapsulation nightmare imo. But I don't really care what other people do with their boxes: it doesn't affect me, so why should I? As others have pointed out, dbus is certainly not required for a production server, and I sincerely doubt it ever will be. There's too many experienced admins and coders who quietly earn a living off clean systems, without ever getting involved in mailing-list debates. It fits nicely in the grand Unix tradition of do one job and do it well, See below wrt filesystems. and few apps have passing messages around as their core function. Hand it off to the system, that's what it's there for. Exactly: the operating-system. It's such a common problem, and it has wider implications to do with scheduling and priority that come up around synchronisation, that it's all been provided several times already
[gentoo-user] Re: Re: Fresh install and problem with net.* init.d script
Neil Bothwick wrote: Steven J. Long wrote: Alan McKinnon wrote: You might as well ask why do you need or want any other form of IPC you already have, as that is what dbus is. It's a very small, light daemon, can run system-wide or per-session and has the potential to many of the IPC implementations you already have. You might as well just use the existing IPC mechanisms too, Yes, lets have lots of IPC mechanisms instead of one daemon that handles IPC for everything. It's called an operating system. While we're at it, let's get rid of syslog and add file logging code to every program that needs it. cron and at seem a bit of a waste of space too. Strawmen burn so well, don't they? I know, let's do all process-scheduling in user-space, I mean who needs preemptive multi-tasking when we have such experts in the early userspace at our disposal. User-land threading works really well too: so long as we worship at the altar of the great God Lennart, blocking and synchronisation can be handled via prayer and the sacrifice of a small, modular utility every sunrise. -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
[gentoo-user] Re: Re: Fresh install and problem with net.* init.d script
Alan McKinnon wrote: you forgot that shared library nonsense. Every app should just bundle static copies of everything it needs and leave it up to the dev to deal with bugs and security issues And you forgot: -lc prob'y because it's not required. -lrt comes into play too. I'd recommend a book or two, but I have the feeling you're not a coder, and your only response has been derogatory, so I don't think you'd get very far with them. Shame really, you and Neil were two of the people I most respected on this list. -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
[gentoo-user] Re: Re: Re: Fresh install and problem with net.* init.d script
Alan McKinnon wrote: Peace and hugz OK? Definitely :-) POSIX 4: Programming for the Real World (Gallmeister, 1995) UNIX Network Programming vol 2: Interprocess Communications (Stevens, 1999) iirc the first is on safari-online; you can download code from the second here: http://www.kohala.com/start/unpv22e/unpv22e.html More here: https://foss.aueb.gr/posix/ If you've not had the pleasure of W Richard Stevens' writing, you have a treat in-store. I'd guess you guys have at least read some of the TCP/Illustrated series, though. Regards, steveL. -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
[gentoo-user] Re: Fresh install and problem with net.* init.d script
Alan McKinnon wrote: dbus is NOT a desktop daemon. This is very important, and that single misunderstanding is probably behind all the fud you read about it. dbus implements a message bus - an amazingly useful thing to have. Why do you need or want a message bus? You might as well ask why do you need or want any other form of IPC you already have, as that is what dbus is. It's a very small, light daemon, can run system-wide or per-session and has the potential to many of the IPC implementations you already have. Those are the ones that don't happen to show up in ps so you hear very little whinging about them. You might as well just use the existing IPC mechanisms too, especially on a server. Oh wait, that would take experience and the humility borne of it. That desktop systems are the main user of dbus at this point in time doesn't change one bit what dbus is designed to do and it's usefulness. Actually it was designed to be a desktop bus. That its mission has crept, or arguably the developer has made a land-grab, doesn't change that. Note I am not saying anything at all about the technical merits of dbus itself. I actually quite like the base protocol, just not all the crap on top of it. Kinda how I feel about the Java VM, fwtw. Regards, steveL -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
[gentoo-user] Re: mutt configuration advice
Mick wrote: I would be grateful if some kind soul guided my hand on configuring mutt to behave like ... errm ... kmail! O_o Funnily enough I did just that, for the same reasons (You want what?! a full-blown MySQL production server just to notify me about email? YDIW.) and wrote it up here: http://forums.gentoo.org/viewtopic-t-945868.html I don't use gmail, but I'd take a look at using it via IMAP if I were you. I understand mutt is excellent for that. Feel free to let us know how you get on in the forum post, too, as it would be good to have various setups written-up, and the problems encountered along the way outlined for others. HTH, steveL -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
[gentoo-user] Re: Logitech MX620 mouse
On Sat, May 18, 2013 at 10:57:40AM +0200, Stefan G. Weichinger wrote: Am 18.05.2013 00:57, schrieb John Campbell: Take a look at imwheel. It's a little unmaintained but it still works. I've used it on an old MX1000 and my current PreformanceMX. You can set mouse buttons on a per window/program basis to have different effects for whichever window has focus. Thus search for Firefox and paste for Thunderbird. You also might need lomoco to turn on the button. I remember with my MX1000, I had to enable the two scroll wheels as buttons. Otherwise they were used by the mouse to scroll fast which I found pretty useless. thanks for the suggestions! We were successful with btnx yesterday ... and now we don't touch it anymore (as long as it still works). Just for posterity's sake, would you mind posting how you configured it, for anyone searching for help on the same thing? I don't have an MX620, but I do love Logitech trackballs, and am interested in configuration settings for this stuff. I was looking at the Kensington one with a turn-wheel, but settled on my old faithful Trackman Marble for recent replacement. I really just want something like that with a wheel, but the ones I saw didn't do it for me. In any case, at some point i'm going to have to deal with a more complex device, so I'd like to see what kind of thing you needed to configure (never heard of btnx.) Thanks, steveL -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
[gentoo-user] Re: Problems with aclocal
Andre Lucas Falco wrote: It's possible to use the package.env, described here: http://wiki.gentoo.org/wiki//etc/portage/env. I use this for 2 packages (ghostscript-gpl and orbit), runs flawlessly. 2013/5/2 Neil Bothwick n...@digimed.co.uk You could, but then you need to remove the settings when automake or the ebuilds are fixed. Since a fixed ebuild won't necessarily have a version bump, you'd continue using the old version after you don't have to. Ok, but for me, it's a perspective stuff, the bug ( https://bugs.gentoo.org/show_bug.cgi?id=451744) has 4 months, and the packages those i need to compile won't solved. The linked url[1] states that the issue is automake-1.13.1 (and .0). For the fix mentioned, i imagine it's the deprecation warning with -Werror, as the feature is not removed til automake-1.14, which isn't in-tree. I think 1.13.1 should be hard-masked, since it's clearly buggy, and 1.13.2 should be here soon. In any event masking 1.13.1 yourself should be sufficient, for others if not you, as you only have 2 packages failing. Then again, that's what you get for running ~arch ;p Still it's only compilation errors, not broken installs. Not sure what the brouhaha is about: Gentoo users tend to react to compile problems like other distro users react to broken libs, which gives the wrong impression to others (who thus think Gentoo is really unstable in their terms, when the true issue is that some software won't build.) Still, we're only human. Regards, steveL [1] http://www.flameeyes.eu/autotools-mythbuster/forwardporting/automake.html -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
[gentoo-user] Re: Removing pulseaudio
On Fri, Apr 26, 2013 at 04:50:43PM +0800, Mark David Dumlao wrote: On Fri, Apr 26, 2013 at 3:55 AM, Alan McKinnon alan.mckin...@gmail.com wrote: And you are vastly overstating the desirability of having pulseaudio enforced on users without very good cause How much barefaced lying can you do in one sentence? 1) it's not enforced _on you_. USE=-pulse Not enforced on Gentoo, no, which is why many of us use it. But we're discussing pulseaudio in the wider ecosystem (you certainly are) which does affect us too. 2) bluetooth headset goes in, audio goes out is good cause. Yeah and if you need it all power to you: look you can install it real simply or it comes by default on some distros. What about the rest of us who either don't give a damn about audio beyond the speakers on our computer, with hifi TV et al separate, or are actually into quality audio, and use jack? See: you cannot predict the use-cases. By definition, you will not be present when the software is run by the end-user. So you have to learn humility, and let the user decide. Hence what was said before about software not imposing itself, especially when not in even use. One True Way inturgrated idiot-box crap doesn't allow that. It's the antithesis of Unix. And if you can't deal with the fact that Linux is a *nix, use something else instead of imposing layers of crap on the rest of us. Especially your dud spangly new ideas that are turds you want the rest of us to polish while you sell your enterprise distro based on everyone else's work. It's poisoning the software ecosystem. and seem to have underestimated how deep that rabbit hole goes. No I haven't. I have no idea how deep the complexity of pulseaudio is because I don't know how to use it. I don't know how to use it because it just works. snip But if I compare how well I learned to use grub vs pulseaudio, two things that I use everyday, it's clear that one of them was more successful in hiding the complexity from me before I used it successfully. HINT: it wasn't grub. Funny, I spent even less time learning to use the KDE artsd and it worked too. I never had any problems with it at all, yet I've heard of a lot of issues with pa, more worryingly to do with the mentality the developer imposes as a condition of working with him. I still got rid of it, and am much happier with my current, Lennartware-free, setup thanks. Must be something about what programs actually do, rather than just misleading analogies and invalid comparisons. If you actually talk like it matters what the programs do, rather than just making airy abstractions on what some ideal fetishized system should be like, you'll understand things better. It does no harm and might be useful for some is simply not a valid reason to enforce a package on all users, especially when said package is the latest johnny-come-lately from a wunderkind with a proven reputation for writing invasive code[1] Oh dear. I should've realized what this was really about. There aren't really any technical reasons behind this, are there? Just some good old fashioned Lennart hate boners. I have a perfect halloween campfire story for this group. The one where a malicious udev update gives a backdoor for He Who Must Not Be Named to install his LennartWare onto yor systems... Newsflash: it's called systemd and you can't get udev without it. Nor can you build udev separately, you must install all the requirements and build the full systemd package: they deliberately broke that. Even though systemd has nothing to do with udev: it's a complete layering violation. They have nfc about what not breaking userspace means. They tried to push binary logfiles in the kernel; they broke module-loading and blamed it on everyone else; and they designed a system with a race builtin, despite claiming loud and wide that they are the experts in the dynamic early userspace domain. Oh and let's not forget the wonderful decision to use XML in system space, plus the current nonsense about hw bus-ids being stable. But sure, these amateurs are just who we want writing system-critical code.. Smart businesses won't be so dumb. Nor will smart users. Good luck to the rest of you, you have my sympathy: I see your pain on IRC every day. -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
[gentoo-user] Re: Removing pulseaudio
On Thu, Apr 25, 2013 at 09:31:43PM +0400, Yuri K. Shatroff wrote: On 25.04.2013 19:48, Mark David Dumlao wrote: On Sat, Apr 20, 2013 at 5:34 PM, Walter Dnes waltd...@waltdnes.org wrote: I think you've hit the nail on the head. Complex setups require complex software... deal with it. An analogy is that an 18-wheeler semi-tractor trailer with a 17-speed manual transmission (plus air brakes that require months of training to manage/use) is much more powerful than a Chevy Sonic hatchback when it comes to hauling huge loads. But for someoneone who merely wants to zip out to the supermarket and buy a week's groceries, the hatchback is much more appropriate. Similarly, PulseAudio may be better at handling complex situations like you describe. The yelling and screaming you're hearing are from the 99% of people whose setups are not complex enough to justify PulseAudio. Making 100% of setups more complex in order to handle the 1% of edge cases is simply wrong. Exactly. If you think you have to make 100% of cases more complex just to handle an edge 1%, YDIW. No ifs nor buts about it. The complexity overhead of pulseaudio is vaaastly overstated here. Yes, as a general principle, adding unneeded complexity is bad. But that takes into account general ideas on the relative tradeoffs of having it there or not. But listen to the happy PA users here who don't feel any problem with their setup. The complexity doesn't bite them. As for the complexity of PA, one must distinguish the PA architecture complexity, its installation complexity and the complexity of managing this stuff for the user (not mentioning usage complexity which is probably negligible). I wouldn't care for the architecture complexity (although I assume it to be too complex) but what I do care about is its bad manageability. If it were to install just a package, or just remove one package, then everyone would be satisfied, including those who need the functionality. But apparently it isn't so; either all audio software is to use PA, or none at all. Analogy: 99% of people aren't going to need a11y. But the whole point of installing it by default on most desktop systems is that you can't predict who will need it, and _it does not harm_ (or very little harm) to the people who don't. So your tradeoffs are: A) no a11y unless elected by user: - for the 1%: a11y is a pain to install because the user might not even be able to see the screen (very big pain) - for the 99% use a few megabytes less on their disk. (very small gain) B) a11y for everyone unless elected removed: - for the 1%: they can use the system properly (no pain) - for the 99%: use a few megabytes more on their disk (very small pain) Obviously (B) is a better default choice. Ditto pulseaudio. That's assuming it were simply a case of a few megabytes of disk space. But as pointed out, it's also a case of upstream wanting everyone to change the way they do things across the board, in the name of convenience. It doesn't seem like these convenience layers really make anyone's life easier in the longer-term. Instead of working behind the scenes so that existing methods function more capably, everyone has to change their code to a new API, whose developers wouldn't know an ABI-promise if it smacked them on the head, and all users have to change their setups. Hardly making everyone's life easier, and breaking userspace as if it were lucrative. Further, they appear to have a tendency to break when you want to do something unusual, or as most people think of it, use your machine as you see fit. That's a problem common to all idiot-box software, when they try to guess and don't listen. If I wanted that, I wouldn't have fled Windows development over a decade ago. Well if PA is that great then why really not do like you suggest? Probably, the problem is not a few megabytes more on their disk but that PA is just not a good alternative? And eventually is there a real big unsolvable problem for one to *install* PA when he needs? Does one really end up with black screen or another kinda PITA without PA? If not, then it's not a good analogy? Precisely. But as I feel it, the talk is about choice, not PA nor complexity. I just *don't want* it. I probably don't see any harm with various akonadis and nepomuks in KDE (actually, I did see much harm, but that's another story) but I simply don't want'em. As a result (of all those useless-for-me pieces of great code removed) I have Gentoo running KDE times faster than e.g. OpenSUSE, but even without that, it's my choice and if I don't perceive or measure these times faster I believe in them. I'm with you there: after I removed semantic-craptop, my KDE came back to me :-) I went a bit further and removed the nubkit stuff, and things actually work a lot better. It was hard giving up kmail[1] but once I'd overcome that barrier, losing nubkit was a
[gentoo-user] Re: Portage screwup
On Thu, Apr 18, 2013 at 02:34:42PM -0600, Joseph wrote: On 04/18/13 22:10, Michael Hampicke wrote: Am 18.04.2013 15:33, schrieb Joseph: What is going on with portage? All the older packages are being removed and and some of them are not even made stable. I've masked current one app-text/poppler-0.22.2-r2 but looking at the web-page this is not even stable poppler-0.22.3 is masked all across the previous version are all removed. All the packages that I recently try to roll back are gone, in most cases only one is available so there is no option to roll back. Am I missing something? If you want the option to rollback, you should use FEATURES=buildpkg[1] in general, and qpkg to make a binpkg from current system. qpkg is part of portage-utils, which is highly recommended. man q after you install it, and follow the instructions in einfo to get it to sync when portage does. The version of poppler that you have masked ( 0.22.2-r2 ) is stable. So it's not a portage screw up, the problem is more that you are trying to install outdated software. I'm not getting any were with this; looking blindly trying to install older versions hoping it might help.. Maybe it is time for me to move to another distro. Why do you want an older version? I don't understand why you have 0.22.2-r2 masked at all; it's in stable which means it's been tested by quite a few people already, and it is recommended that you upgrade. Just be sure to do a revdep-rebuild after you emerge -uD --changed-use world and depclean. As to attic stuff, as Neal said you need to copy ebuild and any needed files from the files subdir into a local overlay. You can read about how to do that at [2] but as I said, I don't think you should have stable poppler masked in the first place. Regards, steveL. [1] http://forums.gentoo.org/viewtopic-p-7165614.html#7165614 [2] http://forums.gentoo.org/viewtopic-p-4547366.html#4547366 -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
[gentoo-user] Re: System maintenance procedure?
On Tue, Dec 04, 2012 at 04:30:33PM -0800, Grant wrote: And then attended like this: emerge -DuN world revdep-rebuild etc-update elogv emerge --depclean eclean distfiles eclean packages Am I missing any good stuff? I've recently modified update[1] to use --changed-use by default, instead of -N: Unlike --newuse, the --changed-use option does not trigger reinstallation when flags that the user has not enabled are added or removed. This is great: it does the same thing as skipUseless (a setting we've had for a couple of years) but means we don't have to show the user what we're skipping, since portage isn't trying to rebuild it in the first place. Also, update does depclean before revdep-rebuild, in case the depclean breaks anything. (It also picks up on preserved-rebuild, though I switched back to stable portage a while ago.) Both after glsa-check of course, which I don't see in your list. (Not that it's actually warned me about anything in the last few years. ;) After the whole thing, it'll run your configUpdater if needed. If not set, it tries etc-proposals cfg-update dispatch-conf and etc-update in that order. I use dispatch-conf nowadays, but used to love etc-proposals popping up in X to tell me when it was done. replace-unmodified, replace-wscomments and ignore-previously-merged are all really useful (not sure which of those are default any more, but I definitely had to set a couple to yes when I installed: pretty sure replace-cvs defaults to yes.) With regards to syncing, update -s does the sync first, calling eix-sync as well if it's installed. We recommend people let eix-sync also update their overlays with: echo '*' /etc/eix-sync.conf (I hope that's still correct) or if they're not using eix, to set postSync to 'layman -S'. The sync is nice, as it wraps it to only use one line in the console. I'd be interested if there's stuff we should add. I've always been wary of eclean, and in fact still have all the distfiles and binpkgs this machine has ever downloaded or installed. Same on my laptop (though it shares distfiles.) Disk space isn't really an issue any more. But if it's useful to others, it should be added. I really wanted something that keeps the last N versions of binpkgs (sometimes things start to break, and you get a revbump that doesn't make things better, and just having the last version isn't enough.) From the manpage, --package-names --time-limit=6m might be a reasonable compromise. Hmm think I'll look into adding some sort of hook, though I might not use it personally: it can just take a set of parameters configured by the admin. [1] http://forums.gentoo.org/viewtopic-t-546828.html -- #friendly-coders -- Where everybody knows your nick ;-)
[gentoo-user] Re: udev with separate /usr and no initramfs
Some fool wrote: Following the debates over the summer, about plans to require an initramfs for udev, I put together a slightly different approach using the dependency tracking in openrc. It's outlined (in Unsupported Software) at: http://forums.gentoo.org/viewtopic-p-6866484.html Just wondering if anyone else besides the one user who's reported a succesful result has tried this. I realise people are experimenting with mdev and static devices; the latter in particular would be of interest on that forum thread, but I'd also like to know if anyone has got any feedback on udev without initramfs, especially on unstable. I'm not knocking the mdev option, and would love to see a forum thread on how to set that up: the more options the better AFAIC. Just that udev is the official upstream kernel thing, AFAIK, and might be more suited for the general desktop end-user, especially with devices that only have udev helper scripts (eg I've heard about wifi and bluetooth.) Regards, steveL. -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
[gentoo-user] Re: Progress on s/udev/mdev/
Pandu Poluan wrote: Great! BTW, if the ebuild goes into overlay, it could use a newer EAPI, couldn't it? Sure. -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
[gentoo-user] Re: GCC with multiple targets
David W Noon wrote: On Fri, 18 Nov 2011 17:49:04 +0100, Kamil Domański wrote: I've been trying to figure out a way to emerge GCC with multiple target architectures. Try using the crossdev package. Yeah crossdev _rocks_. #gentoo-embedded is a good place to get help, as well as the gentoo-embedded list James mentioned in his reply to Erico's post. (both are mentioned in the project pages - communication channels.) -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
[gentoo-user] Re: The LIGHTEST web server (just for serving files)?
Michael Mol wrote: Isn't there a kernelland HTTP server? ISTR seeing the option. I don't know anything about it, though. Yeah there was; as I recall it got removed a while back. Google got me: http://en.wikipedia.org/wiki/TUX_web_server and khttpd at: http://www.fenrus.demon.nl/ ..both of which appear dead. I couldn't find any mention of http in my kernel config either. We use lighttpd for our dev stuff; I guess it's that, nginx or thttpd, last of which doesn't do fastCGI, so might be the best for this purpose. http://en.wikipedia.org/wiki/Comparison_of_web_server_software ..might prove helpful. -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
[gentoo-user] Re: [OT] Binary install distro
Dale wrote: Of course, if I find something better, I can backup the /home directory and install something else then restore the /home and carry on with something new. I strongly recommend keeping a separate partition for /home; it makes things a lot easier if and when you switch. It also makes backing up the whole partition with dd very easy. This is the beauty of Linux. Heh indeed; you can even keep an lvm setup across distros. I used to have `gentoo' and `debian' volume groups and it's easy to mount logical volumes in either direction (/home was on a separate large physical partition.) -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
[gentoo-user] Re: The SIMPLEST web server to config (this time - just for serving video files) ?
Mick wrote: File /usr/lib64/python2.7/SocketServer.py, line 694, in finish self.wfile.flush() File /usr/lib64/python2.7/socket.py, line 303, in flush self._sock.sendall(view[write_offset:write_offset+buffer_size]) error: [Errno 32] Broken pipe I'm pretty much clueless in python so can't interpret the messages - hopefully someone more knowledgeable will chime in. 'Broken pipe' just means the remote closed the connection. It's a pretty standard error in this context, which the server should handle. A process normally gets a SIGPIPE which will by default terminate it, which is what you want if you have a pipeline'd command whose output is no longer required. An example would be checking there is at least one matching file somewhere in a directory hierarchy with: read -d '' f (find /base/dir -type f -name 'foo*' -print0) [[ $f ]] || echo 'no foo* files' -- find will terminate after the first filename has been read. In this case, signal(SIGPIPE, SIG_IGN) or the equivalent has been called, which gives EPIPE instead; a process ignoring the signal is supposed to deal with the error. So I'd say it's a bug. -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
[gentoo-user] Re: Handbook as epub
Michael Mol wrote: I'd like to have the Handbook in a format convenient for reading in ebook readers. Now, I know I could take the existing HTML files and convert them, but I think it'd be nicer if I could get the handbook maintenance scripts to automate a conversion process, and then I could download the epub. Who would I talk to get something like that in the works? You'd talk to the Documentation project: http://www.gentoo.org/proj/en/gdp/index.xml aiui most of the people listed there aren't that active outside their own area; for ages nightmorph had been under a load of pressure, until swift rejoined the project. See the bottom of the page for contact details; you'll most likely want to join their mailing list. There's also a link to understanding the pretty simple GuideXML used. (I have to say it's one of the few applications of XML I really like.) (I've also got an idea about autogenerating, e.g. Android apps, so that I could get up-to-date versions of the handbook on my phone and tablet at all times. But I'd need to learn a bit more before I knew how to autogenerate that.) Sounds good :-) If you need help with scripting there's the Portage Programming forum, the gentoo-devhelp ML, #gentoo-dev-help (yes they're hyphenated differently) #bash and #awk, and ofc #friendly-coders on irc server: chat.freenode.net. IRC really is worth getting on to if you're not already online as it's _really_ easy to get expert help quickly (so long as you bear in mind it's all voluntary and shelter from the beasts in a friendly channel;) and practically all the devs are there in various places. -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
[gentoo-user] udev with separate /usr and no initramfs
Hi, Following the debates over the summer, about plans to require an initramfs for udev, I put together a slightly different approach using the dependency tracking in openrc. It's outlined (in Unsupported Software) at: http://forums.gentoo.org/viewtopic-p-6866484.html and consists of a couple of simple patches to the initscripts for udev and udev-mount, supporting a new initramfs option (defaults to yes) in udev.conf. I've been using it on my desktop at home for a couple of months now and it works like a charm here. As ever, YMMV. As I state in the post: This is only for people who know they have all the modules built-in the kernel to mount local filesystems, have a separate /usr and/or /var, and are happy with their current setups, apart from possible future issues with udev starting before localmount, and find the requirement for an initramfs sufficiently annoying to tweak their setups, *and* are willing to deal with keeping the lines in the initscripts during etc-updates. This is on stable udev (164-r2.) I'm not running unstable, so be careful if you are, and let us know if there are any changes needed. You can get in touch on IRC, or via the forum post. HTH, igli. -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
[gentoo-user] Re: udev with separate /usr and no initramfs
This is on stable udev (164-r2.) I'm not running unstable, so be careful if you are, and let us know if there are any changes needed. You can get in touch on IRC, or via the forum post. -- or ofc this list. Michael Schreckenbauer wrote: I am running ~amd64 and I'll try this, when I have some spare time. I'll let you know, how it works for me. Great, thanks :) Regards, Steve. -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
