1 |
Beso <givemesugarr@×××××.com> posted |
2 |
d257c3560811251519w7f8a0734jc27c23e2bf06404e@××××××××××.com, excerpted |
3 |
below, on Tue, 25 Nov 2008 23:19:40 +0000: |
4 |
|
5 |
> it has been written in a hurry at work, while speaking at the phone with |
6 |
> an italian customer... |
7 |
> so i've spit out a rather difficult to understand sentence. |
8 |
|
9 |
Yeah, that could do it. Not a problem... except that it wasn't until I |
10 |
actually started trying to deconstruct it as part of my reply that I |
11 |
actually made sense out of it. Before that, I thought it internally |
12 |
conflicted with itself and figured I knew where you were trying to go |
13 |
with it, but wasn't quite sure. Even afterward I wasn't sure I had it |
14 |
right, thus bringing it up to ensure I did. |
15 |
|
16 |
... And while I don't understand more than a few words in any language |
17 |
other than English, I'm /usually/ pretty good at groking strange word |
18 |
ordering and etc, because I've been exposed to quite a variety of |
19 |
multiple cultures of /some/ sort or another (plus now archaic English) |
20 |
most of my life. So I'm unaccustomed to not being able to make sense out |
21 |
of things, even if the word order is /not/ customary English. But this |
22 |
one I really did get wrong at first. It was a stumper! |
23 |
|
24 |
> this works for packages in gentoo. the problem is when the same package |
25 |
> is provided in other overlays. I tend to use quite a big number of |
26 |
> overlays and in that case the package mask is mandatory when you want to |
27 |
> mask a specific version and overlay. sometimes when the version is the |
28 |
> same this is proving difficult with portage. |
29 |
|
30 |
Yes. I've only had that happen a relatively few times, because I only |
31 |
use a relatively few overlays. And when it did happen here, it just |
32 |
seemed to work the way I needed it to anyway, so I didn't trouble myself |
33 |
with it. But certainly, once someone's running more than a small handful |
34 |
of overlays, it can get "interesting". |
35 |
|
36 |
> this is one of the reasons that i've switched to paludis |
37 |
|
38 |
That's one thing the paludis devs have gotten right. It was designed |
39 |
pretty much from the beginning to handle multiple overlays and make |
40 |
configuring which one gets used for which packages relatively easy. |
41 |
|
42 |
> this also applies when i want to mask/unmask stuff from my personal |
43 |
> testing overlay (mainly patches against some build that fails). also |
44 |
> when using masked ebuilds, like the live ones, the use of package.unmask |
45 |
> and sometimes package.mask is quite useful. |
46 |
|
47 |
I used to do a lot of personal overlay stuff. Now, I use Ed Catmur's |
48 |
portage-patches scripts, which hook into portage and allow one to apply |
49 |
one's own set of patches to a specified package. It works for patching |
50 |
with an /etc/portage/patches tree much like the /etc/portage/env/ tree |
51 |
that the last few versions of portage have worked with for setting stuff |
52 |
like CFLAGS in a package-specific way. (I only recently realized Ed |
53 |
Catmur is the author of udept, which I had merged previously, so he / |
54 |
should/ be relatively familiar with portage tricks.) |
55 |
|
56 |
Since I installed those scripts and now use package.keywords to set ~x86 |
57 |
or whatever for some packages instead of putting them in the overlay and |
58 |
adding ~amd64, my personal overlay has remained almost empty. I had a |
59 |
"live" pan ebuild, but eva@gentoo encouraged me to forward it when I |
60 |
mentioned it in a bug and it's now in the tree. I have a copy of the |
61 |
amarok-1.4.9999 live ebuild that I needed to modify to install slotted |
62 |
and not conflict with the amarok-2/kde4 version, but that's about it. If |
63 |
the patch is to the sources, I use portage-patches and use the existing |
64 |
ebuild without changes. Only if the ebuild itself (or eclass, but that |
65 |
hasn't happened in awhile) needs patching, and it can't be handled by say |
66 |
setting EXTRA_ECONF in the /etc/portage/env tree either, does it end up |
67 |
in my overlay. And that doesn't happen so often. Usually it's a sources |
68 |
patch, and that can go in the /etc/portage/patches tree, thanks to Ed's |
69 |
portage-patches. |
70 |
|
71 |
> my problem is that my bugs are ignored due to --as-needed. now that |
72 |
> diego has started to massively test the --as-needed flag as default |
73 |
|
74 |
Hmm... I've been using --as-needed (in LDFLAGS but not forced in spec |
75 |
files) for awhile myself, but haven't seen my bugs ignored with it. |
76 |
Maybe it's the type of bugs I file, or the type of packages I end up |
77 |
finding bugs in and the devs that maintain them, or the fact that if |
78 |
I think my custom LDFLAGS (or CFLAGS or still masked gcc version or ...) |
79 |
are causing problems, I set them to accepted Gentoo defaults for that |
80 |
package using a file in the /etc/portage/env tree, and specifically |
81 |
mention in my bug whether that changed the result or not. |
82 |
|
83 |
One thing's for sure, I've certainly developed a much thicker skin over |
84 |
the years, since one of my originally filed bugs got marked INVALID for |
85 |
some stupid reason. I don't just tuck my tail between my legs and go |
86 |
home like I used to, tho I've not had occasion to get into a real bug- |
87 |
status war since that changed. But my bugs don't generally seem to be |
88 |
ignored, either. Some don't get action for awhile, but it's not ignoring, |
89 |
it's the "real life" of the assigned dev, and the fact that some of my |
90 |
bugs are rather esoteric, so not /that/ system life threatening to |
91 |
anything. |
92 |
|
93 |
But Flameeyes' campaigning on the --as-needed thing is certainly needed. |
94 |
I'm very glad he's doing it, as it's something few would have the skills |
95 |
to tackle, but at the same time, something he can let his new machine do |
96 |
much of the work on, so maybe he doesn't overwork himself so much. |
97 |
|
98 |
Gentoo's lucky to have someone that talented around, and he doesn't have |
99 |
the enormous ego problems a lot of the similarly talented devs seem to |
100 |
have. Unfortunately, like my dad and sister, he seems to be a |
101 |
workaholic. They do great and wonderful things, certainly, but they they |
102 |
burn the candle at both ends doing it, and their health suffers as a |
103 |
result. Having that problem in my own family, I recognize it in |
104 |
Flameeyes as well, and his frequent hospital trips at such a relatively |
105 |
young age concern me. He's an asset not only to Gentoo, but to the FLOSS |
106 |
community in general, and I fear we're going to lose him if he can't |
107 |
learn to pace himself. Fortunately, he seems to have realized that |
108 |
himself, now, and has cut back substantially from what he /was/ trying to |
109 |
do. |
110 |
|
111 |
> O_O i didn't know that there was a package named emerge... |
112 |
|
113 |
I didn't either... until then. But I learned! =:^) |
114 |
|
115 |
> well, this also applies to the stable branch. then there are also the |
116 |
> keyworded packages. i know that when gentoo came out this distinction |
117 |
> (as it is still now) it has been a really good one, but still, nowadays |
118 |
> when the unstable branch is as stable as the stable branch, with a big |
119 |
> lack of devs, maybe it's better to think of dropping one of the 2. |
120 |
|
121 |
Maybe the next time someone brings up the Enterprise Gentoo idea on the |
122 |
dev list, I should counter with the dropping stable idea... AFAIK the |
123 |
last time it came up was early this year, so it should be time for it to |
124 |
come up again sometime between this spring and next fall... |
125 |
|
126 |
But they've already dropped stable keyworks on IIRC mips (but don't quote |
127 |
me on that, it may have been a different arch, and I'm too lazy to go |
128 |
check my devlist archives ATM), because it just wasn't happening, and |
129 |
maintainers were getting seriously annoyed due to having to keep outdated |
130 |
and broken packages in the tree as the only stable on that arch. |
131 |
|
132 |
> it's simple in my opinion. rhel offers a big stability with a lot of |
133 |
> security features and so on. but it has a downside: it's built on |
134 |
> classic and not optimized flags and the packages that are built are |
135 |
> fully built, and not only with the stuff you |
136 |
> really need. having a branch that has similar features, but it's |
137 |
> optimized for a specific machine and takes full potential from that |
138 |
> machine would be a boost. don't you think so?! |
139 |
|
140 |
Yes. But the problem tends to be that these Enterprise users need |
141 |
support, and for that to be economical, there has to be a reasonably |
142 |
large size group on the same packages built with the same set of options |
143 |
and CFLAGS. |
144 |
|
145 |
They can get their support and run their proprietary packages, but to do |
146 |
it, the tradeoff is that they gotta accept being a clone, |
147 |
one-size-fits-all. The hard economics of the situation are that as soon |
148 |
as you optimize for the hardware you're actually running, and build for |
149 |
the dependencies you actually need, you're in a niche that's small enough |
150 |
it's simply not economical to support you... at the level of commercial |
151 |
support that RHEL's customers demand anyway, or they'd be elsewhere. |
152 |
|
153 |
Practically speaking, you and I know that in many, perhaps most cases, |
154 |
the benefit of such "support" is highly questionable anyway, because |
155 |
practically speaking, posting to the relevant list/newsgroup/forum gets |
156 |
an answer way faster than paid support is likely to. And in the cases |
157 |
where it doesn't, paid support may fail as well. And... being open |
158 |
source, for the few cases where that paid support does actually mean a |
159 |
benefit, it's quite possible a single-shot consultant or developer job |
160 |
could be funded to address that specific issue, customized solution, for |
161 |
roughly the same money but in less time than than the paid support. |
162 |
|
163 |
But regardless, that doesn't provide someone else to point the finger at |
164 |
and save someone's a**, and... practically speaking, RHEL DOES pay a lot |
165 |
of paychecks for full-time FLOSS developers, that would at best be part |
166 |
time if it weren't for /someone/ deciding they needed that sort of |
167 |
support enough to pay the big bucks for it. |
168 |
|
169 |
> then we're back to the point when the distinction between stable and |
170 |
> unstable is still a little useless nowadays. the release time between |
171 |
> one version and the following is going to decrease as time goes. an |
172 |
> example is xorg. just think of how many xorg-server versions have been |
173 |
> released recently, and from what i've read the project would be pushed |
174 |
> farther form intel that wants a fully featured and working environment |
175 |
> for professional use. which has been the latest stable xorg ebuild?! |
176 |
|
177 |
xorg is an interesting problem, not in the least because it has a very |
178 |
clear yet politically unpalatable solution, simply ignore users who chose |
179 |
hardware vendors whose only real competitive features are only enabled by |
180 |
proprietaryware drivers. nVidia, and to a lessor extent ATI but that |
181 |
one's being solved as we speak, are, simply put, holding xorg development |
182 |
hostage to the rate at which they develop their proprietary drivers to |
183 |
match. The logical thing to do would be to let xorg development and |
184 |
those user who have hardware with freedomware drivers continue their |
185 |
progress apace, and let the nVidia users be stuck on the two-years- |
186 |
outdated or whatever proprietary development model they've chosen to |
187 |
support with their buying dollars. |
188 |
|
189 |
Actually, if you look at it, that's gotta be one of the reasons Intel is |
190 |
pushing xorg development so hard. It has a competitive advantage in that |
191 |
it's hardware, while not as full featured hardware-wise, has native |
192 |
driver support for the latest whiz-bang xorg features right off the |
193 |
blocks, leaving the proprietaryware folks sucking dust, and it's not |
194 |
above trying to exploit it. AMD, who needs the Linux users far more than |
195 |
Intel does, was facing the very real prospect of being practically locked |
196 |
out of the Linux market due to Intel's Linux cooperation, and had no |
197 |
choice but to respond, first by buying a graphics maker so it wasn't |
198 |
locked out due to the proprietaryware actions of third parties, and then |
199 |
by opening up ATI's graphics to the same extent, or actually even |
200 |
further, pushing Intel. |
201 |
|
202 |
But the gamers and their preferred nVidia proprietaryware are continuing |
203 |
to hold things back, at least as far as stable support, and not just for |
204 |
Gentoo. All of the big distributions are facing the problem, as are |
205 |
Dell, Acer, Asus, and other OEMs now shipping Linux kit in some volume. |
206 |
No major distro can afford to cut off the nVidia user market share, so |
207 |
none of them can afford to ship a new xorg no matter how far behind their |
208 |
current version is, until nVidia deigns to support a newer xorg with |
209 |
their proprietary driver. And $deity have pity on the poor distrib that |
210 |
has the luck of having nVidia release a driver just after they've frozen |
211 |
the repository to all bug bug fixes in preparation for a new release, |
212 |
because now they'll be shipping with an outdated nVidia driver AND xorg, |
213 |
and can't really upgrade either one except as options, without delaying |
214 |
release another month or two to test the new xorg with everything. And |
215 |
if the major distros can't ship it, then the OEMs basing their own |
216 |
distribs on them can't ship it, even if they're using Intel hardware that |
217 |
could really benefit from the newer xorg. |
218 |
|
219 |
Fortunately with the AMD purchase of ATI and its subsequent switch back |
220 |
away from the dark side, 2009 seems likely to resolve this. The |
221 |
distributions and hardware OEMs both are getting increasingly impatient |
222 |
with nVidia, and with Intel support right there and AMD/ATI/Radeon |
223 |
support coming on fast, 2009 looks likely to be the year nVidia either |
224 |
reverses itself as well, or regardless, starts losing its ability to hold |
225 |
things back. |
226 |
|
227 |
Bringing that all back around to our discussion at hand, for other |
228 |
distributions, that'll probably mean shipping a more modern xorg, with an |
229 |
optional stale xorg just to support nVidia users, and a * on their |
230 |
feature list with an "nVidia users" small-print disclaimer. KDE's not a |
231 |
distribution, but it has already taken that tact by choosing not to |
232 |
support nVidia proprietary driver users at full feature strength some of |
233 |
the time. |
234 |
|
235 |
Gentoo... will probably either end up taking a similar position with |
236 |
stable, telling nVidia users to mask the newest stable until nVidia gets |
237 |
off their a**, or will continue to let stable xorg molder, updating it |
238 |
only when nVidia deigns to allow it by updating their proprietaryware, |
239 |
meanwhile forcing more and more users who want decently current features |
240 |
to either highly package.keyworded systems, or to fully ~arch systems. |
241 |
|
242 |
Hopefully either nVidia or their proprietaryware driver users get a clue, |
243 |
but I'm not holding my breath... |
244 |
|
245 |
> for kde 3.5.7 and superior serie. the time in which it went stable has |
246 |
> been very high. and the same reduction in time between releases is |
247 |
> happening for other projects as well. i really think that this |
248 |
> stable/unstable division should really be revised, especially when |
249 |
> there's a problem with the lack of testing devs. |
250 |
|
251 |
KDE... has been a problem for Gentoo of late. Well, KDE4 has been a |
252 |
problem for everyone, not just Gentoo, but Gentoo had problems before |
253 |
that, as you mentioned, from 3.5.x. |
254 |
|
255 |
The real problem for Gentoo has been the size of KDE... and the devs on |
256 |
the project. Losing developers, and before their loss, loss of |
257 |
cooperation with the rest of Gentoo, due to an inability to work well |
258 |
with others... hurts any project. There are certainly two sides to the |
259 |
story and I'm not close enough to it nor do I have any desire to pick |
260 |
sides, so I won't, but the fact is, whoever was to blame or whether it |
261 |
was just the way things had to be, that loss /hurt/. We're lucky a bunch |
262 |
of users got involved in the overlay work, or Gentoo basically wouldn't |
263 |
/have/ a modern KDE, either 3.5 or 4.x series, at this point. |
264 |
|
265 |
Hopefully that's all behind us and KDE can become a thriving healthy |
266 |
project once again. As I said, I'm a bit far from the action, but that |
267 |
influx of new blood, as well as some developers from other areas putting |
268 |
on another hat, has seemed to help, and the major teething problems with |
269 |
the switch to the 4.x series seem to be over, so I'm optimistic. |
270 |
|
271 |
Otherwise, much as I hate to since Gentoo otherwise seems about the ideal |
272 |
fit for me personally, I may end up having to ultimately switch to |
273 |
something else (assuming KDE4.2 finally gets the kde4 act together |
274 |
upstream, as they've been promising, or maybe kde will be what I end up |
275 |
dropping), or perhaps more likely, simply switch to kde upstream directly |
276 |
for KDE stuff. |
277 |
|
278 |
But none of the other really big projects seem quite as bad as Gentoo/kde |
279 |
and Gentoo/xorg. In particular, toolchain seems to still be quite |
280 |
functional, and the PM side is strong enough it's supporting three |
281 |
thriving PM! What about GNOME and XFCE? I've not /read/ of anything so |
282 |
majorly wrong with those projects and from outside, they've seemed much |
283 |
smoother, but unless GNOME reverses course with gnome3, it's not for me, |
284 |
and xfce... well, I guess I've never seriously looked at it, but I've |
285 |
always thought of it as not as full featured as I like... and my hardware |
286 |
certainly isn't the issue it seems to be for a lot of xfce users. |
287 |
|
288 |
For everything else, at least for desktop use, it doesn't seem to me that |
289 |
stable lagging a bit should be a serious problem. If someone needs codec |
290 |
support only in a new media-* package, unlike xorg or toolchain or the |
291 |
desktop environment, they can package.keyword it without threatening the |
292 |
stability of either the computer itself or at least their entire desktop. |
293 |
|
294 |
>> While we're at it, the same applies to the usual KDE/GNOME/XFCE/etc |
295 |
>> wars, and the VIM/EMACS wars, and ... and ... I've come to realize |
296 |
>> that the approaches are just different, neither one "better", altho |
297 |
>> certainly individuals will find one or the other "better" for their |
298 |
>> individual needs. |
299 |
|
300 |
> well, it' s better to have a choice and a battle between them than |
301 |
> having one solution that doesn't progress, or that progresses in a bad |
302 |
> way, as happens on windoze for example. |
303 |
|
304 |
Exactly. Especially when "progress" as defined by some is "regression" |
305 |
as defined by others. When that's the case, as it is for example with |
306 |
the proliferation of user accessible controls on KDE as compared to |
307 |
forced conformance to the "One True Way" (tm) on GNOME, it's /better/ to |
308 |
have separate projects, and far from hurting each other, they keep the |
309 |
devs who might otherwise cause problems and needless infighting on the |
310 |
other alternative, working on their preferred alternative instead. Where |
311 |
it's possible and convenient, they can always cooperate, and |
312 |
freedesktop.org has been very good at bringing that with its various |
313 |
hosted projects, while letting the desktop projects otherwise pull in |
314 |
their opposing directions without hurting anyone, and in particular, |
315 |
without hurting the interests of the wider FLOSS community. Why so few |
316 |
see it and calls for "One True Desktop" (tm) are so common, I don't know, |
317 |
except that those folks must still be thinking the "One True MS Way" (tm). |
318 |
|
319 |
> as a little example, i have a friend that is fully convinced that linux |
320 |
> is not capable of doing what windoze svista would do. i just showed him |
321 |
> kde4 with compiz enabled, put on wow on codeweavers (thanks to the free |
322 |
> giveaway offer from some time ago) and installed the native enemy |
323 |
> territory and he remained stupified. he didn't believe |
324 |
> that he could do the same things that he could do on windoze in a better |
325 |
> way and more intuively on linux. now he's still staying with his windoze |
326 |
> but he doesn't pretends anymore that linux is bad and not working. |
327 |
|
328 |
Some people like the security and comfort "Big Brother" (tm) provides... |
329 |
|
330 |
I could go off on a US political tangent here, or for that matter, on a |
331 |
big bad MS tangent, but I won't... The big bad nVidia bit above is |
332 |
enough for this post. =:^) |
333 |
|
334 |
> the same could apply for gnome when speaking of innovative features, |
335 |
> or to kde when speaking about eye candy or too much innovation all |
336 |
> together. everyone should sustain their ideas and show them to the |
337 |
> other part so that the other one could learn something from it. and i |
338 |
> think that when this happens everyone gets stronger than before. |
339 |
|
340 |
That's what's nice about choice and the FLOSS community way of developing |
341 |
a bunch of competing solutions in parallel. That cross-pollination is |
342 |
not just allowed, but actively encouraged! =:^) |
343 |
|
344 |
> the same discussion might apply for microsoft-novell agreement that is |
345 |
> has bought a very high compatibility with office |
346 |
> documents to openoffice 3, so that everyone might continue to use |
347 |
> whatever he likes without really worrying that the others could or |
348 |
> couldn't understand them. |
349 |
|
350 |
Of course, the Boycott-Novell folks have a very different view of things |
351 |
there. But fortunately for me, I've been far enough away from that I've |
352 |
had no need to develop an informed opinion on it. I very seldom have to |
353 |
deal with Office formatted docs of any kind (save for the usual .pps cute/ |
354 |
funny mail stuff making the rounds, and I just ignore that), I don't use |
355 |
Gnome for other reasons and haven't had to deal with mono, and Gentoo's |
356 |
sufficient for me so I've little interest in Novell/SuSE as a |
357 |
distribution. So I've sufficiently few dealings with them or their |
358 |
controversial products that a boycott really isn't something that would |
359 |
affect either them or me. The work of Greg KH (Novell employee, AFAIK) |
360 |
on the kernel is about as close as it gets, here, and evidently his |
361 |
integrity is sufficient I've seen nothing calling that into question. |
362 |
|
363 |
-- |
364 |
Duncan - List replies preferred. No HTML msgs. |
365 |
"Every nonfree program has a lord, a master -- |
366 |
and if you use the program, he is your master." Richard Stallman |