Mailing List Archive

On Fri, 30 May 2014 02:04:39 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:

>
> FWIW, I'm no-multilib as well, but I guess for a different reason.
>
> I don't do proprietary and in general couldn't even if I wanted to, since
> I cannot and will not agree to the EULAs, so non-free software that
> hasn't been amd64 ported is of no concern to me,
>

It's not just proprietary software that lags behind. I continue
to encounter FOSS packages from time to time that are still 32-bit only.

One example, for audio enthusiasts, is the excellent AudioCutter:
http://www.virtualworlds.de/AudioCutter/

(There are many other examples but at this moment I can't recall any specific
names so you'll just have to trust me).

However, when it comes to the PDF file format it is hard to beat the
proprietary Foxit Reader. With FOSS only evince comes close but evince
lacks a lot of capability and seems to be buggy in places.

AMD64 should be the standard but many projects refuse to update since
reliance on multi-lib is so much simpler. As a consequence we 64-bit
purists are at a disadvantage.

Frank Peters

Frank Peters posted on Thu, 29 May 2014 22:44:05 -0400 as excerpted:

> On Fri, 30 May 2014 02:04:39 +0000 (UTC)
> Duncan <1i5t5.duncan@cox.net> wrote:
>
>> FWIW, I'm no-multilib as well, but I guess for a different reason.
>>
>> I don't do proprietary [...]
>>
> It's not just proprietary software that lags behind. I continue to
> encounter FOSS packages from time to time that are still 32-bit only.
>
> One example, for audio enthusiasts, is the excellent AudioCutter:
> http://www.virtualworlds.de/AudioCutter/

I'm not saying 32-bit-only FLOSS isn't out there, only that by now, and
actually from 2010 or so (to pick the turn of the decade as a convenient
date, one could actually say by 2008 or so), it's increasingly non-
mainstream. There's the occasional exception, but for most people,
either their 32-bit concerns are proprietary only, or there's a more
mainstream 64-bit alternative.

Luckily for me, my interests are mainstream enough...

> (There are many other examples but at this moment I can't recall any
> specific names so you'll just have to trust me).
>
> However, when it comes to the PDF file format it is hard to beat the
> proprietary Foxit Reader. With FOSS only evince comes close but evince
> lacks a lot of capability and seems to be buggy in places.

I should explicitly mention that I'm all for people making their own
decisions regarding proprietary. Because I know if someone had tried to
push me before I was ready, even while I was preparing for my ultimate
switch, the results would have been nothing but negative. So everyone
must move when they are ready, and if that time never comes, well... But
at the same time, that decision is behind me personally, and there's
simply no way I'm going back to the days of proprietary.

As for pdf, I'm running (semantic-desktop-stripped) kde and okular, and
have been reasonably happy with it. Where I've seen people complain
about PDF readability or compatibility and have checked, okular has done
well enough for me, to the point I never saw what they were complaining
about.

Meanwhile, even if I did find some PDF nothing I could run would handle,
that would simply mean I'd not read that pdf, tho if it was worth it I
could envision taking it to the library to read or to a printer to have
them print it out or something. But I wouldn't install anything
proprietary on my own systems to read it. There are too many other
things to do in the world to worry about missing what's in one pdf,
especially if it meant my freedom was on the line.

> AMD64 should be the standard but many projects refuse to update since
> reliance on multi-lib is so much simpler. As a consequence we 64-bit
> purists are at a disadvantage.

True at times. Luckily, those times aren't so frequent these days.

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman

On Thu, May 29, 2014 at 7:04 PM, Duncan <1i5t5.duncan@cox.net> wrote:
<SNIP>
> Meanwhile, Mark's reason for staying on this list, as opposed to the
> general user list, are more or less mine, as well.
<SNIP>
>
> Rather, in my case it is more that I remember the high traffic of the
> user list and kind of like the lower but perhaps higher quality traffic
> here, tho at times it's /too/ low traffic, these days. Probably at some
> point I'll get back to the user list, but if this list were to shut down,
> I'd still miss it, because while there's not a lot of traffic here these
> days, the signal to noise ratio really is about the highest I can imagine.
>
> --
> Duncan - List replies preferred. No HTML msgs.
> "Every nonfree program has a lord, a master --
> and if you use the program, he is your master." Richard Stallman

Hi Duncan,
There is an in progress, higher energy thread on gentoo-user with folks
getting upset (my interpretation) about systemd and support for
suspend/resume features. I only found it being that I ran into an emerge
block and went looking for a solution. (In my case it was -upower as
a new use flag setting.)

Anyway, I prefer it here. If I was reading that thread real-time I know I'd
be responding to a few things even though I don't have anything of much
value to add. It's just my nature in the presence of threads like that! ;-)

Cheers,
Mark

P.S. - BTW - I love your long answers although I seldom have time
to read them when they arrive. Stay true. They are of value.

Mark Knecht posted on Wed, 04 Jun 2014 09:41:30 -0700 as excerpted:

> There is an in progress, higher energy thread on gentoo-user with folks
> getting upset (my interpretation) about systemd and support for
> suspend/resume features. I only found it being that I ran into an emerge
> block and went looking for a solution. (In my case it was -upower as a
> new use flag setting.)

Yeah. I saw the original dev-list thread on the topic, before it all hit
the tree (and continuing now), which is a big part of why I subscribe to
the dev-list, to get heads-up about things like that.

What happened from the dev-list perspective is that after upower dropped
about half the original package as systemd replaced that functionality,
the gentoo maintainers split the package in half, the still included
functionality under the original upower name, with the dropped portion in
a new, basically-gentoo-as-upstream, package, upower-pm-utils.

But to the gentoo maintainer the portage output was sufficient that
between emerge --pretend --tree --unordered-display and eix upower, what
was needed was self-evident, so he didn't judge a news item necessary.
What a lot of other users (including me) AND devs are telling him is that
he's apparently too close to the problem to see that it's not as obvious
as he thinks, and a news item really is necessary.

Compounding the problem for users is that few users actually pulled in
upower on their own and don't really know or care about it -- it's pulled
in due to default desktop-profile use-flags as it's the way most desktops
handle suspend/hibernate. Further, certain desktop dependencies
apparently got default-order reversed on the alternative-deps, so portage
tries to fill the dep with systemd instead of the other package.
Unfortunately that's turning everybody's world upside down, as suddenly
portage wants to pull in systemd *AND* there's all these blockers!

Meanwhile, even tho he didn't originally think it necessary, once pretty
much all gentoo userspace (forums, irc, lists, various blogs...) erupted
in chaos, the gentoo maintainer decided that even tho he didn't quite
understand /why/ a news item was needed, that was the best way to get the
message out as to how to fix things and to calm things back down.

But, policy is that such news items must be posted to the gentoo-dev list
for (ideally) several days of comment before they're committed, and a
good policy it is in general too, because the news items generally turn
out FAR better with multiple people looking over the drafts and making
suggestions, than the single-person first-drafts tend to be!

In cases such as this, however, the comment time is shortened to only a
day or two unless something seriously wrong comes up in the process, and
while I've not synced for a few days, I'd guess that news item has either
hit before I send this, or certainly if not, it'll hit within a matter of
hours.

Once the news item hits, for people that actually read them at least, the
problem should be pretty much eliminated, as there's appropriate
instructions for how to fix the blocker, etc.

So things should really be simmering back down pretty shortly. =:^)
Meanwhile, in the larger perspective of things, it's just a relatively
minor goof that as usual is fixed in a couple days. No big deal, except
that /this/ goof happens to include the uber-lightening-rod-package that
is systemd. Be that as it may, the world isn't ending, and the problem
is indeed still fixed up within a couple days, as usual, with
information, some reliable, some not so reliable, available via the usual
channels for those who don't want to wait.

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman

On Wed, Jun 4, 2014 at 7:00 PM, Duncan <1i5t5.duncan@cox.net> wrote:
> Mark Knecht posted on Wed, 04 Jun 2014 09:41:30 -0700 as excerpted:
>
>> There is an in progress, higher energy thread on gentoo-user with folks
>> getting upset (my interpretation) about systemd and support for
>> suspend/resume features. I only found it being that I ran into an emerge
>> block and went looking for a solution. (In my case it was -upower as a
>> new use flag setting.)
>
> Yeah. I saw the original dev-list thread on the topic, before it all hit
> the tree (and continuing now), which is a big part of why I subscribe to
> the dev-list, to get heads-up about things like that.
>

Maybe all Gentoo users should subscribe! Over time we would likely
all get a bit smarter. ;-) ;-) ;-)

> What happened from the dev-list perspective is that after upower dropped
> about half the original package as systemd replaced that functionality,
> the gentoo maintainers split the package in half, the still included
> functionality under the original upower name, with the dropped portion in
> a new, basically-gentoo-as-upstream, package, upower-pm-utils.
>

I certainly have no issue with the basics of what they did, but more
in a second.

> But to the gentoo maintainer the portage output was sufficient that
> between emerge --pretend --tree --unordered-display and eix upower, what
> was needed was self-evident, so he didn't judge a news item necessary.
> What a lot of other users (including me) AND devs are telling him is that
> he's apparently too close to the problem to see that it's not as obvious
> as he thinks, and a news item really is necessary.
>

Yeah, this was likely the issue. One comment in the -user thread on this
subject was that at least one -dev-type thinks users should be reading
change logs to figure this stuff out. I no longer remember how long I've
run Gentoo but it's well beyond a decade at this point. Daniel Robbins
was certainly participating. I was working at a company from mid-1999
to 2004 when I started. I can only say that I've never read a change log
in that whole time.

> Compounding the problem for users is that few users actually pulled in
> upower on their own and don't really know or care about it -- it's pulled
> in due to default desktop-profile use-flags as it's the way most desktops
> handle suspend/hibernate.

As is the case for me using kde-meta. However while I figured out I could
set -upower on kdelibs and not have any build or boot issues pretty quickly
I soon discovered that flag goes beyond my simplistic view of
suspend/resume which I have never used. It also covers _everything_ in
the Power Management section of systemsettings which means I lost
my ability in KDE to control what I suspect is DPMI time settings on
my monitors. I'll either have to learn how to do that outside of KDE or
reinstall the newer upower-pm-utils package.

> Further, certain desktop dependencies
> apparently got default-order reversed on the alternative-deps, so portage
> tries to fill the dep with systemd instead of the other package.
> Unfortunately that's turning everybody's world upside down, as suddenly
> portage wants to pull in systemd *AND* there's all these blockers!
>

Yeah, that's what got me to look at gentoo-user and find the problem. Lots
of blocks involving systemd.

<SNIP>
> So things should really be simmering back down pretty shortly. =:^)
> Meanwhile, in the larger perspective of things, it's just a relatively
> minor goof that as usual is fixed in a couple days. No big deal, except
> that /this/ goof happens to include the uber-lightening-rod-package that
> is systemd. Be that as it may, the world isn't ending, and the problem
> is indeed still fixed up within a couple days, as usual, with
> information, some reliable, some not so reliable, available via the usual
> channels for those who don't want to wait.
>

This stuff does happen once in awhile. I'm surprised it doesn't happen
more often actually so for the most part the release process is pretty
good.

WRT to systemd, my real problem with this latest issue is the systemd
profile issue, and beyond that there doesn't seem to be a systemd
oriented new machine install document. In my study getting ready to
build a new RAID (probably will be 2-drive 3TB RAID1) I wondered
of I should give in to this portage pressure and go systemd. When
I start looking there all I find are documents that seem to assume
a pretty high understanding of systemd which doesn't represent
my current education or abilities. Seems to me if the gentoo-devs
interested in seeing systemd gain traction were serious this would be
a high priority job. All we get today is

http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?full=1#book_part1_chap12

which to me says it's not what Gentoo developers want Gentoo users to
use. Of course, that's just me.

Take care,
Mark

Mark Knecht posted on Thu, 05 Jun 2014 11:59:23 -0700 as excerpted:

> Yeah, this was likely the issue. One comment in the -user thread on this
> subject was that at least one -dev-type thinks users should be reading
> change logs to figure this stuff out. I no longer remember how long I've
> run Gentoo but it's well beyond a decade at this point. Daniel Robbins
> was certainly participating. I was working at a company from mid-1999 to
> 2004 when I started. I can only say that I've never read a change log in
> that whole time.

Wow. I read 'em routinely. There are actually four different types of
"changelogs" I read, more or less often and closely, depending on the
package and how closely I'm following it.

1) The gentoo package changelogs (as found in the gentoo tree) don't
normally contain a lot of information about the upstream package or
changes between versions, so I don't read them all the time, but I *DO*
read the gentoo package changelog much of the time when I see a -rX bump
for something I already have installed at the same upstream version
number, because in that case I normally want to know what the gentoo
package maintainer considered important enough for a revision bump and
the resulting rebuild trigger for users with that same upstream version
already installed, instead of simply fixing it in the ebuild without a
revision bump. These can be security bumps, for instance, and if so I
want to know how bad it was and what my risk was before the update.
Another common reason is config changes or patches that might affect me
in other ways, that as an admin responsible for the wellbeing of my gentoo
system (a responsibility I take very seriously), I want to know about.

Additionally, the gentoo package changelogs contain dates for version
introduction into the tree as well as stabilization on the various archs,
and eventually, for removal from the tree. Most of the time when I'm
checking on these, it's to help someone on some other list figure out a
dependency on their non-gentoo distro, or figure out how far behind my
~amd64 installation their version is and how outdated, etc. Other times
it can be basically the same stuff, but for another gentooer on stable
instead of my ~amd64 plus selected live-packages system.

At least back when Zac was portage dev lead, because gentoo /is/ upstream
for portage and because portage changes are critical to a gentoo system's
wellbeing, the portage package changelog was far more detailed than most
others, including bug report numbers and mentioning big feature changes.
I followed the portage changelog very closely and looked up every bug
number mentioned to see what sort of changes were being made and why.

2) While not technically "changelog" files, git logs are in fact
generally much more detailed changelogs, and for stuff like kde, where I
run live-git-branch packages from the gentoo/kde project overlay, every
time I do a sync (of both the main gentoo tree and the few overlays I
run), I FAITHFULLY run git log on the overlay trees to see what updated
since I last synced, and how. For the overlays, I follow *EVERY*
*SINGLE* *CHANGE*, at minimum reading the git-log entry which lists the
files involved as well, and if there's patches introduced that interest
me, I'll use git show to pull up the full git diffs and see what actually
changed, line by line in the source code.

3) Similarly, for various upstream packages I follow upstream's changelog
or news files as well, not /too/ closely for most packages, but for a lot
of packages, closely enough to at least be aware of major feature
updates, both so I can make use of those features, and because they might
affect config files that I'll be etc-updating in short order, after the
package upgrade.

4) For a lot of packages that I run the live-git version of, I'll use the
smart-live-rebuild output to get the upstream git commit IDs, and will
then do a git log with those IDs to see what changed there, as well. For
a few packages, I have a different script that I run that does an
individual git pull for the package, and I git log it if there are
changes, before I even run smart-live-rebuild to catch the others at all.

Until I recently switched to systemd, I was one of the few non-dev users
actually running openrc-9999, precisely so I COULD follow individual git
commit updates, and I found and filed a number of bugs that then got
fixed before a release version ever made them generally available even to
~arch users. Similarly, I've been involved with upstream pan (the news
client I follow this list with, among other things) for over a decade
now, helping out on its mailing list and now filling the local
application historian role as well, tho I'm not a dev, and I follow its
git logs *VERY* closely. Lately I've been active both as a btrfs user
and on the btrfs list, and follow the btrfs-progs git commit log closely
as well.

For kde, where I'm on the kde4 development branch, I don't follow the git
logs /quite/ that closely, but I do keep an eye on them, particularly for
kdelibs, kde-baseapps and kde-workspace.

I have my own scripts that I use for updating the kernel so I don't use
gentoo's kernel packages at all, but there too I run (mainline Linus)
kernel git, and while I don't follow individual commits especially during
the merge window, I often follow the mainline merge-commits, and follow
things more closely as commits slow down later in the cycle. As with
openrc, I've bisected, filed and gotten fixed a number of bugs in pre-
releases over the years before they hit full releases.

So I must confess it's a bit hard to imagine someone who hasn't read a
single changelog in at least the decade I've been on gentoo, particularly
since following them to at least /some/ extent is IMO part of the
responsibility of being a good sysadmin, responsible for at least their
own system if no others, is all about. While I certainly don't expect
people to follow changes as closely as I do, not viewing even /one/
changelog over the course of at least a decade... let's put it this way,
it's not something /I'd/ be proud to admit in public.

OTOH, that you've gone this long without it and are still here discussing
and running gentoo definitely *IS* a testament to how good the gentoo
devs (and tester-users like me filing bugs to be fixed before things hit
stable, and sometimes before they hit a release or the ~arch tree at all)
actually are in general at keeping things actually working for people, a
bit of hiccup now and again for a few days, but basically nothing that's
not fixed in a few days, and nothing that tends to actually eat systems
to the point that you're not here, a decade later.

That's SAYING something! =:^)

> This stuff does happen once in awhile. I'm surprised it doesn't happen
> more often actually so for the most part the release process is pretty
> good.

=:^)

> WRT to systemd, my real problem with this latest issue is the systemd
> profile issue, and beyond that there doesn't seem to be a systemd
> oriented new machine install document. In my study getting ready to
> build a new RAID (probably will be 2-drive 3TB RAID1) I wondered of I
> should give in to this portage pressure and go systemd. When I start
> looking there all I find are documents that seem to assume a pretty high
> understanding of systemd which doesn't represent my current education or
> abilities. Seems to me if the gentoo-devs interested in seeing systemd
> gain traction were serious this would be a high priority job. All we get
> today is
>
> http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?
full=1#book_part1_chap12
>
> which to me says it's not what Gentoo developers want Gentoo users to
> use.
> Of course, that's just me.

You're actually correct. Mainline gentoo remains openrc, and that's
likely to remain the case for some time. Systemd is certainly available
as an option, and more and more people are switching to it, but even
after it's well documented in the handbook, openrc will continue to be an
option for the foreseeable future, with several devs having stated quite
specifically that they use gentoo and depend on openrc in their jobs, so
whatever /else/ may happen to gentoo, openrc is *NOT* about to become
unsupported, as I said for the foreseeable future (which in practice
means at LEAST two years out as it'd take that long to switch over --
remember how long it took to stabilize baselayout-2, and more likely at
least five years, even if they voted that as a goal right now!).

OTOH, individual packages and specific desktop projects can change
dependencies based on what upstream supports, and gentoo/gnome is only
supporting systemd for some elements now.

Luckily for gentoo/kdeers, upstream kde has committed to maintaining more
systemd independence than has gnome, including with kde 5 frameworks.
And the modularization of kde-frameworks should make that much easier
too, over time, altho individual kde packages may eventually require
systemd. OTOH, gentooers have it better than most in that they have more
choice about actually installing individual packages, as well as keeping
upstream-optional dependencies actually optional.

We did almost lose the ability to opt-out of semantic-desktop, but
fortunately saner heads prevailed, and had they not done so in gentoo/kde,
a number of us users were making plans for a user-supported overlay
similar to the user-supported kde-sunset for kde3 users, to maintain
semantic-desktop-less kde4 at least until kde5/frameworks, at which point
we hoped upstream policies would bring back the option due to its
modularity. But while I actually had to maintain the semantic-desktop-
less ebuild patches locally for awhile in ordered to continue following
kde-live-branch, and I guess ~arch users faced the problem for a shorter
time, the policy thankfully reverted before stable users had to make that
painful choice.

But various devs have made it VERY clear, gentoo as a whole isn't going
to get anywhere /close/ to losing the openrc option, as I said, for the
foreseeable future.

And well before that were to happen, or even if gentoo really expected
stable users to switch to systemd in quantity, there'd be MUCH better
documentation, just as that was a prerequisite to the stable-side
baselayout-2, one of the big reasons it took years. Again, that's
exactly the reason users worried about gentoo suddenly switching to
systemd as it /looked/ like it might be doing here, have nothing to worry
about for at **LEAST** two years. A ship as big as gentoo simply doesn't
turn on a dime, nor can it be forced to, and even were the council to
suddenly get a brain transplant and vote that it should be the goal
today, it'd take years to actually implement, including for many gentoo
devs *AND* their employers.

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman

On Thu, 05 Jun 2014 22:48:07 +0100
Martin <m_btrfs@ml1.co.uk> wrote:

> Resend (gmane appears to be losing my email for this list... :-( )

OK, forwarding to the list too (with a bit less snippage than normal,
to keep your message intact as I'm relaying) and replying below.

>
> On 05/06/14 16:35, Martin wrote:
> > On 05/06/14 03:00, Duncan wrote:
> >> So things should really be simmering back down pretty shortly.
> >> =:^)

> > Thanks for the good summary.
> >
> > Yep, I hit all the red "B" blockers... Quickly saw it was upower and
> > some confusion with systemd even though I've not selected systemd
> > anywhere and...
> >
> > I was too rushed to investigate much further and so added into my
> > /etc/portage/package.mask:
> >
> > # Avoid pulling in systemd!
> > =sys-power/upower-0.9.23-r3
> >
> >
> > Thanks for letting me know to await the news item and for the bits
> > to settle...

[.Just forwarding that part and would delete it as I'm not replying to
it, were I not forwarding it for you too. But I'm replying to the
below.]

> > As for systemd... I'm just wondering if the various heated air being
> > generated/wasted is as much rushed arrogance on the part of the
> > implementation as due to the grand ripples of change.
> >
> > The recent kernel DoS debacle due to misusing the long used kernel
> > debug showed a certain 'cavalier' attitude to taking over
> > functionality without a wider concern or caution to keep projects
> > outside of systemd undisturbed... Or at least conscientiously
> > minimise disturbance...

Agreed, and for quite some time I that attitude was why I was delaying
my own switch, tho I expected I'd eventually make it.

But backing up a bit to reveal the larger picture...

Developers in general aren't always exactly known for their ability to
get along with each other or with others or necessarily the wider
community. Certainly there's many examples of this in the FLOSS
community, and from what I've read of the proprietary development
community it's no different, save much of it happens behind closed
doors, with public appearances moderated by the PR folks.

Actually, I've a personal experience that rather changed my own outlook
on things, that I believe explains a lot of the problem here. The
following gets a bit franker and more personally honest than most
discussions and I'm not really comfortable saying it, but it's
important enough not to skip as it illustrates a point I want to make.

I don't ordinarily talk about myself in this way, but the fact is, on
most tests I score well above 90 percentile IQ. Typically, depending
on the test and whether I'm hitting my groove that day or not, I run
95-97 percentile on average in most areas (tho in composition I'm
relatively low for me, 70s). (FWIW, I've always been slightly
frustrated. The MENSA cutoff is supposed to be 98 percentile and I
typically score tantalizingly close, but not quite! It'd be nice...
=:^( ) In technology and computer areas I'd guess I'm a bit higher,
perhaps 98 percentile or so. 95 percentile means about 19 out of 20
people score lower, 98 percentile is 49 out of 50.

But, this level of attainment presents its own set of difficulties,
difficulties I'm intimately familiar with, but obviously not to the
level these /real/ geniuses, the big hero coders of our community, are.

I still remember the day I actually realized what dealing with a
mentally challenged individual actually was, back in about 8th grade or
so. He had come to visit a next door neighbor and we set out to climb
a local butte, me not yet understanding his difficulty -- I knew
there was /something/ different about him, but I didn't know what, I
just accepted it, and him, as basically my equal, as I had been taught
to accept and treat everyone. But climbing this butte didn't simply
involve a hike, as is the case with many hills/buttes. It involved a
bit of relatively minor technical climbing, "chimneying", etc. I
had done it with a group previously, but wanted to try it again, for
the exercise and challenge. But I didn't want to do it alone, and this
guy was agreeable to trying it, so we set out.

Everything went well, considering, but it did take somewhat longer than
I had planned and our ride back got a bit worried and alerted the
authorities. Fortunately, they didn't have to pull us off the mountain
(or scrape us from the bottom of the chimney), but we got in a bit of
trouble.

When I got home, Mom asked me why on earth I'd take a r* guy up a
mountain like that. I was flabbergasted! I didn't know! And to think
I took him on that climb that was slightly challenging for me
(something I'm not sure my Mom knew, and that I didn't tell her!), what
must it have been for him? I was perhaps rather fortunate
something /didn't/ happen, altho now I realize that despite (or even
perhaps because of) his challenge he was remarkably resilient, and may
well have picked himself up and continued better than I would have if
something had gone wrong and either one of us was hurt

That night or perhaps the next day, as I thought about it, I realized
what had happened. I was so used to, as a matter of course, dropping
to whatever level was required to meet people at their own level and
treat them as equal, that I didn't realize I was even doing it. To me
it was just the way one interacted with others. What I had originally
noticed different about him, that I couldn't put into words before as I
simply didn't have the experience or concept, was that I had to drop a
bit more than normal, but I was so used to doing it for pretty much
everyone, that I didn't even realize I was doing it, or know what it
was... until I was forcibly confronted with the fact that this guy was
(to others) noticeably below average. But to me he was simply a bit
more of the normal that I always did, and that I thought was just the
way it was to interact with /anyone/.

Since then I've obviously become a bit wiser in the ways of the world,
but realistically, I really do seldom meet people /really/ my equal in
the real world, and that has really distorted my experience, and to
some extent my attitude and picture of the world.

But that was only experiencing the one side. I consider myself
fortunate to have actually had the opposite experience as well. A bit
over a decade ago I was with a Linux and Unix friendly ISP that had a
lot of real knowledgeable folks as customers, including one guy that was
one of only about a dozen with direct commit privs to one of the BSDs,
and several others that were in the same knowledge class. While I
may well be at the 95-97 percentile range, for the first time in my
life I was well outranked, as several of these guys were at the 99th
percentile or better I'm sure, plus they had likely decades of
experience I didn't (as a newbie fresh from the MS side of the track)
have!

That was a humbling experience indeed! To that point, I had been used
to being at least /equal/ to pretty much anyone I met, and enough above
most that even if I happened to be wrong I knew more about the
situation than pretty much anyone else, that I could out-argue them
even in my wrongness.

Here the situation was exactly reversed, *I* was the know-nothing, the
slow guy that everyone else had to wait for while someone patiently
explained what was going on so I could follow along!

I **VERY** **QUICKLY** learned how to shut up and simply read the
discussion as it happened around me, learning from the masters and
occasionally asking a question or two, and to be *VERY* sure I could
backup any claims I DID make, because if I was wrong, for the first
time in my life I was pretty much guaranteed to be called on it, and
there was no bluffing my way out of that fix with THESE guys!

That had roughly the same level of effect on me as the earlier
experience, but at the opposite end, something I rather badly needed as
I NEEDED a bit of humbling at that point!

Now here's the critical point that I've been so brutally honest to try
to present: What happens to the *REAL* 99 percentilers, the guys who
*NEVER* have that sort of humbling "OOPS, I screwed up and better
shutup! These guys know more than me and if I'm wrong they're not
afraid to demonstrate exactly why and how!" ... experience?

Unfortunately, a lot of them are a**h***s! Why? Because they're at
the top of their class and they know it. Nobody can prove them wrong,
and if somehow someone does, they simply don't know how to react, as
it's an experience they very rarely have. Even on things they know is
simply opinion, they're so used to having absolutely zero peers around
that can actually challenge them on it, that they simply don't
know /how/ to take a real, honest challenge when it comes.

Which BTW is one of the things I find so amazing about Linus Torvalds.
I doubt many would argue that he's at the 99 percentile point, yet
somehow he's a real person, still approachable, and unlike most folks
at his level, actually able to deal with people!

At the other end are people like Hans Reiser. He was and is a
filesystem genius, and reiser4 was years before its time, yet never got
into the kernel despite years of trying, because he was absolutely
horrible at interpersonal relations and nobody anywhere near his
level could work with him, because he simply didn't know how to be
wrong. Unfortunately learning that was literally a fatal experience
for his wife. =:^(

Take it from someone who is in many areas 90 percentile plus, but who
counts that experience sitting at the feet of /real/ masters as perhaps
the single most fortunate and critical experience in his live, because
he learned how to be wrong, that's NOT an easy lesson to learn, but
it's an *EXTREMELY* critical lesson to learn!

Think about that the next time you see something like that kernel
command-line debug thing go down. Poettering and Sievers are extremely
bright men, genius, top of their class. And Poettering in particular
is a gifted speaker as well (researching systemd I watched a number of
videos of presentations he has done on the subject, he really IS an
impressive and gifted speaker!).

But, they don't take being wrong well at all, and they have a sense of
entitlement due to their sense of ultimate rightness.

Never-the-less, however one might dislike and distrust the personality
behind them, both systemd and reiserfs (and later reiser4) were/are top
of their class for their time, unique and ahead of their time in many
ways. There's no arguing that.

I didn't and don't like Hans Reiser, but I used his filesystem
(reiser3), and still use it on my spinning rust drives altho I've
switched to the still not fully mature btrfs on my newer ssds.

Unlike Reiser, I don't know so much about Poettering and Sievers
personal lives and I surely hope they don't end up where Reiser did for
similar reasons. But similar to Reiser, I use their software, systemd,
now. And there's no arguing the fact, it's /good/, even if not exactly
stable, because they continue to "gray goo" anything in their path, and
haven't yet taken the time necessary to truly stabilize the thing.
While I never used it, from what I have read, PulseAudio was much the
same way as long as Poettering was involved -- it never truly
stabilized until he lost interest and left.

Unfortunately I think that's likely to be the case with systemd as
well; it won't really stabilize until Poettering loses interest and
moves on to something else. And for people who depend on stable, I
really doubt I'll be able to recommend it (if you can avoid the
gray goo, I really don't know if that will remain possible if he
doesn't lose interest in another couple years) until then. But it /is/
good, good enough it's taking the Linux world by storm, gray goo and
all. If systemd could just be left alone to stabilize for a year or
so, I think it'd be good, /incredibly/ good, and a lot of hold outs,
like I was until recently, would find little reason not to switch, once
it was allowed to stabilize. But when that's likely to happen
(presumably after Poettering moves on), I really haven't the foggiest.

Meanwhile I'm leading edge enough (I'm running git kde4 and kernel,
after all), and (fortunately) good enough at troubleshooting Linux boot
issues when I have to, that I decided it was time, for me anyway.

So as you can see, while I've succumbed now, I really do still have
mixed feelings on it all.

But meanwhile, try applying the "do they actually know how to be wrong"
theory the next time you see something happening elsewhere, too. It's
surprising just how much of the FLOSS-world feuding it explains!...

Tho this is one area I'd be I'd be /very/ happy if I /was/ wrong about,
and suddenly all these definite top-of-their-field coders started
getting along with each other! Well, we can hope, anyway (and while
we're at hoping, hope the lesson in being wrong isn't data eating code
teaching them how to be wrong, or security code either, as seems to
have been the recent case with openssl!).

--
Duncan - No HTML messages please, as they are filtered as spam.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman