On Thu, Sep 8, 2011 at 10:51 AM, Canek Peláez Valdés <can...@gmail.com> wrote: > On Wed, Sep 7, 2011 at 11:39 PM, Dale <rdalek1...@gmail.com> wrote: >> Canek Peláez Valdés wrote: >>> >>> Then don't update. Wanna keep up with upstream? Then accept that sometimes >>> you will need to change your setup, and change how you do stuff. Regards. >> >> This is so like something I have told folks about windoze. Awesome ! To >> think I stayed away from windoze because of the freedom Linux gives a user >> just to find out now, its not as different as I thought. :-( > > But the freedom is still there. The freedom to either keep your system > as it is (don't upgrade), or to modify the source code to suit your > own needs.
Please don't ever, ever, ever recommend not upgrading as a reasonable long-term strategy. I don't like to think about how many security problems exist in systems I'm familiar with because "not upgrading" was the more convenient route. The other side of what you're saying, "show me the code," is reasonable. And if there's only one upstream maintainer who's got what feels like the entire Linux community over a barrel on this, that seems like a really good idea in principle. > Just don't expect from upstream to maintain code for each and every > possible configuration. It gets really complex really really really > fast. See also: LibreOffice requiring CUPS discussion earlier this week. No surprises there, and it's understandable. Still, I think I understand the complexity of what we're talking about, yet it feels like the developer has a serious case of "my use cases are the most valid ones, and I want to simplify udev's problem space in favor of that." As long as (and only as long as) udev isn't required for a server to well and correctly, that's almost reasonable. That almost puts it in the same class as DBus. (See the discussion from *last* week.) Perhaps udev's problem is that it's too complex, as a result of having too large a problem scope. > Upstream (either Gentoo, or the kernel, or udev, or all of them) will > decide to support only a subset of all possible configurations and it > will mark them as supported. Don't aprove of that? Then maintain it > yourself (which you have the freedom to do), or keep up with the > change. > > Freedom doesn't equals to "give me everything I want, and the way I > want it". The freedom we have is "here is this set of programs, and we > support this set of configurations; if you don't like it, here is also > the source code". Which is light years better than in Windows or MacOS Code or GTFO. Classic FL/OSS fare. (Admittedly the best solution we've found so far) ... I remember devfs, and that it was rejected in favor of udev because some things belong in userspace. udev, as far as I understand, udev listens to hotplug events and performs actions in response. Perhaps an alternate implementation is in order. -- :wq
