[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: What Fedora makes sucking for me - or why I am NOT Fedora



Jeff Spaleta wrote:

If I tell you that "it works" is that enough for you?
If you have identical hardware, an identical set of other packages, and a
similar workload, yes.

How do you know if I do or do not?  Are you saying that the only
information that would help you make a determination as to 'known
broken' or 'is working' as YOU define those concepts is if you have
feedback from people who are doing what you are doing with the
hardware you are using? How much detail do you need about other
people's machines and workloads? How in the hell do you expect to
capture that level of detail from other people?

Those are all good questions. I don't think fedora has a way to answer any of them.

You keep missing the point. I'm going to have to ratchet up the
bluntness factor for you.

I'm trying to make a point so I can hardly miss it. The point is that I need to minimize risk on certain machines and I'm not going to run fedora on them until I see a way to do that. I don't think this is a unique need or that it is impossible for fedora to meet.

You are trying to rely on other people's experiences with updates to
justify whether you should be installing the update on your systems.

Yes, there is safety in numbers - there will always be problems that aren't exposed until a large number of machines run something. But as always, I'm talking about other machines, not necessarily other people. I'd provide my own experience on a test machine to others, given some mechanism to do that usefully.

You haven't described how you would expect to capture that distributed
information from other people in such a way that you can make use of
it before you need to make the decision as to whether or not to
install that update on your very very precious machines.

We are talking about an expectation of risk here. The ideal scenario is to know that the exact package set has been installed on the exact hardware and is currently running the same load. That's the sort of testing you'd do if you had real QA. Lacking that, knowing that a sufficiently large number of other machines have installed the packages in question without reporting problems is a good indication.

You are talking in generalities and what this discussion needs at this
point is implementation specifics.

It all has to start with being able to reproduce package sets. What good does it do to track stability/usability of a configuration you or anyone else can't duplicate, or that after the testing period, aren't even available?

It's not a matter of trust for at least couple of reasons.  One is that your
hardware and installed package set is probably nothing like mine.

How do you know? How do you know that anyone out there is doing
something close enough to what you are doing to be comparable?  If you
are looking to compare systems and workloads you have to trust people
they are reporting the right information.

As long as there are large number of users and any easy reporting mechanism, the simple lack of problem reports would satisfy my expectation of little risk. But by the time this is evident, the configurations they were running successfully can't be created again.

Again, it isn't personal - it has to do with the need to keep certain
machines running.

Stop with the generalities. Talk about YOUR needs and YOUR workloads.

That varies wildly per machine. The largest set would be java based web servers, then an assortment of squid proxies, the usual infrastructure services like DNS, dhcp, snmp monitoring, file, web (e.g. twiki running under mod_perl), email, subversion, backuppc, etc., with a few things running under VMware and and assortment of freenx sessions strategically positioned to be able to manage all the locations.

And what needs to happen is to know that somewhere,
someone has installed the same package set on the same kind of hardware and
has it still working.

How do you expect that information to be collected? How do you expect
that information to be served up?

I'd opt in if there were a mechanism to publish my package set, hardware list, and uptime to some collecting mechanism.

I've used it.
That hardly sounds like a recommendation.

I official recommend that you do whatever it is I've already
suggested.  Does that help?
Does that make the idea sound better to you? Need that in writing?

No, since I think my needs aren't unique, what I am looking for is advice published for fedora users in general - like something on the fedora project page that says that regressions in updates are rare but still expected, and here is the procedure to recover from them.

That sounds like at least an admission that the stock tools and mechanisms
aren't good enough.

Good enough for what? I do not expect the provided tools to meet all
of my needs all the time. As an adminstrator I am accountable for the
integrity of my systems...

OK, but doesn't that imply that you should be able to control your installed package set - or share or match it up with someone else?

not Fedora...

And you don't think it would be helpful if fedora provided a way to install a package set exactly as known to work elsewhere?

> not the mirrors which are
serving fedora packages..and not my ISP who is providing me the
network access to reach those mirrors.  I expect there to be a need
for local administration policy that I control...which mitigates the
dependence on any external entity which puts the integrity of my
systems at risk.  For updates, that means doing several things, one of
which is caching backups locally in case I need to back out
something..even in situations where my ISP has a problem and my
network access goes down.

OK, if fedora users are expected to do all that, shouldn't there be better tools set up for it as part of the distro and step by step procedures published so people know what to expect?

--
   Les Mikesell
    lesmikesell gmail com


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]