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