Hi Blues,
Well done Michael for giving a very considered & professional
response.
Zeffie, when you leave school you will find the real world is mostly
full of quite reasonable people, and throwing a hissy fit does not
exactly encourage anyone to ever consider your services.
Anyway, thats my 2 zlotys worth.
Keith Reynolds
Date sent: Wed, 19 Dec 2007 06:59:13 +0100
From: Michael Stauber <bq (at mark) solarspeed.net>
Send reply to: coba-e (at mark) bluequartz.org
Subject: [coba-e:11551] Re: What really happeded to the mail
To: coba-e (at mark) bluequartz.org
[ Double-click this line for list subscription options ]
Zeffie,
> "Are you Serious right now?
>
> Do you have a point or are you just being rude?
> Now... What have you done that makes you think that you can speak to me
> like this?
This is the second and final reply I'm going to post on this list in direct
response to what you have written:
When you move into a new community neighbourhood you're not making friends by
shouting out loud how stupid everyone else is that's been living there for
years, doing things a certain way for valid reasons that obviously are
escaping you. If you do what you did, then it is not surprising that you're
greeted with curious looks at best, suspicious reservation and perhaps even
openly displayed criticism. Regardless if the points you try to make are
valid or not. If those points are fully or partially invalid, then it may even
make you look silly.
The way you introduced yourself to the list makes clear that you're not here
to make friends. So what is it then - purely business? Then that's the wrong
place for that as I and others have already pointed out.
You ask me if I'm being rude to you? Actually when I posted my first reply to
you I was quite relaxed and still coordially friendly - despite your dramatic
entry here and after you've ignored CentOS + BlueQuartz (and its users) for
years.
Personally I do not like your manners and I think that both the fact *that*
and the way *how* you are telling us how we *have* to do things is so
preposterous that it borders on audacity. I've read your replies on the list
so far and that you resort to personal attacks when you're meeting resistance
or criticism isn't exactly helpful either, as it just leads to further
escalation and dissent.
This list is usually a quite civil and relaxed place and the BlueQuartz
community is like a big family. Sometimes there is some dissent or there are
some mild dissagreements - that's fine and happens in the best families. But
the way you already started bashing people left and right (both users and
BlueQuartz team members) is another audacity that collides with the values of
this community. That this is not only my own personal opinion should be clear
from what others have written.
> Can you tell me how this relates to a incorrectly patched procmail?
> This has nothing to do with the issue.
>
> But since you brought it up... the procmail of the RaQ4 is just about the
> same as what your using now!
> rpm -q procmail --changelog
Check the Procmail for the RaQ550 and see what I mean. That was buggered up
beyond believe thanks to a patch that Cobalt had put in. It would segfault
and also hang on quota issues instead of returning the propper signal to the
calling application. Which then may have hang around waiting on Procmail to
make a callback.
> And Since you Brought it up. Yes, I have been building updates since the
> RaQ2. I have even built things for the Raq but I don't like to talk about
> that to much... they used to make good hidden snort boxes though... :)
>
> I've built hundreds of updates and upgrades for...
> [SNIP]
Yes, a lot of massively intrusive updates. That term ("massively intrusive")
sounds worse than it is and it may have a negative touch attached. That's not
my intention. But the fact remains: They massively interfere with the system
in a way that can lead to undesired results. I've done my share of them as
well back in the days of the RaQ3 (Apache 1.3.6 to 1.3.20 and 1.3.22 for
example) and got hit smack over the head when Sun finally did release an
updated Apache. Once the Cobalt's got EOL'ed and patch support was
discontinued it wasn't a bad idea, though - no doubt about that. It certainly
helped to keep the RaQs secure long after Sun had abandoned the RaQs.
BUT: Both CentOS and BlueQuartz ARE actively maintained. Ripping out essential
services and replacing them with custom versions *will* cause conflicts down
the road when the next official update comes around. Maybe not the first time
around, certainly not every time, but it'll happen eventually. At that point
the question must be: And then what?
The only way to protect users against that is to "filter" patches. Means:
Feeding ALL patches (CentOS, BlueQuartz as well as your own patches) off your
own repository. Even excluding certain RPMs from YUM in yum.conf or
CentOS-Base.conf won't keep you safe, as the YUM config files sometimes gets
upgraded as well - especially when the base OS is upgraded to the next
release.
Once you serve it all out of your own repository you have essentially forked
your build and can do with it whatever you want. In total disregard of how
CentOS or BlueQuartz are used to do things.
But no matter if you fork or just keep massively intrusive updates in an extra
repository: Everyone that is using it has exactly two choices: Swallow the
worm with the hook and keep using *your* repository (and/or your fork), or do
an CMU-export, OS restore and CMU-import and start over fresh with something
that's more in line with the "official" CentOS + BlueQuartz distribution.
Like Brian pointed out already in regards to Apache: PCI compliance is not
just reached by just running the latest version of Apache - it takes more
than that. The httpd-2.0.52-38.ent.centos4 that comes with CentOS-4.6 is what
people are currently running (if they have YUM updated recently). Just
because it's 2.0.52 doesn't mean that all advisories for 2.0.52 still apply,
as this is the 38th release of that RPM with tons of fixes (doesn't cover
everything, but according to CentOS it's good enough). So you not only make
an advertising on this list in which you point to your commercial offerings,
but this advertising is also misleading at best or factually wrong at the
worst. Plus it creates long term problems in regards to future "official"
patches, which may leave users between a rock and a hard place. Especially
with the release of 5200 (Ellis) in mind. Hence I am concerned about users
who install those patches and pointed that out in my first reply. Nothing
more, nothing less.
> ahhh.. I've seen your spamfilter with a /etc/procmailrc...
> so, you wanted this there as a base for your mail filter... ok, got
> ya...
That was ages ago and on CentOS I use a miltered and fully daemonized approach
for best efficiency, relieability and speed. I've seen yours for the RaQ4 as
well, but won't comment publically on it as I'd consider something like that
bad business conduct.
> Try READING!
>
> usupported!
> My Work is Supported! I know you could try supporting your work a little
> more.
It's neither supported by CentOS nor by BlueQuartz and therefore unsupported
by them. Official upgrades will disregard and/or collide with such
modifications as indicated in my first reply and also in more detail above in
this reply. As far as that goes my own software is of course also not
officially supported by either CentOS or BlueQuartz. But by mself instead,
same as you support your own.
> All You've built is your security and spam filter in /home/whatever How
> Messy! This actually makes working on your custom build very hard btw...
> I have to troubleshoot your stuff all the time and your putting things in
> strange places makes my work harder... 9 out of 10 times though the
> customer is happy to just remove your stuff and use mine... which they
> always say "works much better."
You accuse me of being rude, but right here you waltz in and openly discredit
my work based on knowing next to nothing about it. So let me put this
straight:
I also have uninstalled a lot of your software for clients and was asked to
replace it with my own software. Funnily enough the feedback from the clients
afterwards was also that my software "works much better". Well, if the client
is happy, so am I. Regardless what software he uses.
As for installing software in /home/solarspeed/: To not interfere with system
files and to keep my software out of the way and install it in its own
directory wherever and whenever possible. This makes both maintenance and
updates easier and avoids conflicts. That is a lesson I learned from my own
(almost - but not quite) 10 years of experience with Cobalt RaQs and my
experience with BlueQuartz since it came out. Now IF an update breaks my
software, it's usually the matter of fixing a config file which got replaced
during an update and at the worst you may need to restart a service
afterwards - but that's it. I find that quite beneficial and that's why I do
it that way.
There may be perfectly legit reasons for doing things "your way", but you have
no right to say that doing it "my way" is wrong or even messy <shrug>.
> What do you think this place is?
> Your own personal usergroup for your products and os only?
Regardless if it's a Linux crack or just someone that wants to try out CentOS
+ BlueQuartz (or Linux for that matter) for the first time around: I see all
members of this community as part of a family where all members are equal and
deserve to be treated with respect.
If *you* can do that as well, you will fit in nicely here.
Surprise us and try to fit in. Do what Brian, I and others did: Don't
advertise your own products here and work WITH the team and WITH the users -
and not against them.
If you have anything else to say to me directly, take it off list. You know
how to find me.
--
With best regards,
Michael Stauber