SELinux last straw

[Les Mikesell]

Mikkel L. Ellertson wrote:

> Granted, the tools for SELinux are not as mature as the firewall
> tools, but does that mean we throw out SELinux instead of improving
> the tools?

No one is arguing that it should necessarily be thrown out. But, should 
people be using it without understanding it?

> I have seen the same kind of arguments about just about every major
> change. I remember people complaining about udev, and what was wrong
> with using the standard /dev setup. I heard it about the change to
> IPTables. I have heard it about HAL. Way too many of them boil down
> to I know how the old system works, so why should I learn about this
> new way of doing things.

It's not just a matter of learning new things, and even if it were, that 
would boil down to large sums of money in any business context.  Think 
about upgrading a large farm of servers that have multiple network 
connections and the upgrade OS version detects the eth? devices in a 
different order (real example, by the way...).  Now you need the staff 
at each location to either relocate the cables to match or edit a vast 
number if ifcfg-eth? files after they somehow figure out what's 
connected where.

 > I am happy with the way things are working
> now. Don't change things and make me learn a new method. I don't
> care if this new method has advantages over the one I know.

Try it this way: there's been 30 years of work aggregating and improving 
with the old assumptions. That's why we like unix-like systems.  Do you 
want to throw that out on the chance that an untested new idea might be 
better?

> Now, some of the new things are not going to work out, or in trying
> to implement them, a better way may present itself. But if nobody is
> willing to try the new methods, and work out the bugs that are
> always going to crop up when trying something new, then there will
> not be any progress.

Research is always a good idea but most people want the testing to be 
done before the new thing goes into production.

-- 
   Les Mikesell
    lesmikesell at gmail.com