More FUD for everyone: Computers Are Dangerous! (Users are devs, after all.)
There are some people who are trying to squelch conversations on this
list with cries of FUD! FUD!
To you I offer one more thing to cry Fear! Uncertainty! Doubt! about.
[begin-sarcasm]
Can you do binary math in your head? Boolean logic?
Can you process a chain of inferences without a computer to help you?
How about ternary math? Arbitrary base math?
Can you calculate a table of results and reduce it?
Do you have any idea what a mathematical grammar is? How such grammars
map to ideal programming languages? How they fail to map to real
languages -- both programming and human languages?
Do you understand the reason it's supposed to be hard to figure out a
private key from a public key and a long piece of encoded text, even
when you have the plaintext to work from?
Do you understand how easy it is to tap into an ethernet cable or hang
an antenna in the air and tap into a wireless data exchange?
The list goes on, but if YOU don't understand these things, YOU
shouldn't be using a computer!
Is that enough FUD for you, Chris?
[end-sarcasm]
Now, obviously I'm being sarcastic. At least I hope I made it obvious
enough. Okay, I guess I'll go back and put the tags into place ....
Still, ...
Microsoft, Apple, Google, etc., all have test departments. Red Hat has
a test department but relies heavily on the Fedora community for the
final part of the Quality Assurance function.
Debian doesn't really have a test department. The devs do a lot of
automated testing and some additional initial testing that is still
hard to automate, but there is no explicitly named test department.
(No surprise. It's not a corporation, it's a community.) That means,
we, the users, even if we also use other OSses, etc., are a very
significant part of the quality control / quality assurance function.
(Maybe the debian community should add a class of participants called
official testers, but I'm into classless society myself, so I'm not
gong to advocate that.)
That means we have the responsibility to file bugs.
Of course, we should file meaningful bug reports, according to our
understanding levels and time constraints.
Time is something we all have limits on, and it's hard to tell each
other that a bug report is more important than a PTA meeting for a
child.
Understanding, however, is something we all have a responsibility to
improve, both the practical side and the theoretical.
And we all need to be a little more willing to believe that other
people may understand things we don't.
Now, from the end-sarcasm tag to this point is stuff that I sincerely
hope no one is going to argue with. I'd leave it like this, but then
some would complain that it's off-topic.
Some will complain that it's off-topic anyway, but I'll tie it into
some of the current conversations which some people are tired of
hearing about. And I know that will invite argument. I'm not going to
speculate as to the reasons it will invite argument, but according to
pattern, I'm sure it will.
Before you argue, think carefully about what I'm trying to say.
I'll start with an example of what I'm trying to talk about, one that
is relevant to the comments Chris made that lit the fire under me.
It's going to sound a little rude, perhaps, but there are those who
seem to be unable to understand how to use unix permissions in debian
to set up a private group to share files with. (I'm not pointing at
you, Chris. Nor am I pointing to Ansgar, if he is reading the list
today.)
The original post which Ansgar replied to was a bit of maybe excessive
rhetoric I had posted about the interplay of very complex systems with
permissions.
Questions very regularly come up which display either a lack of
understanding of unix permissions or a desire to avoid playing by the
rules which I consider the best rules for dealing with them. Further
explanation of those rules belongs, I suppose, in a how-to.
I want to do a how-to about it, but I also wanted to write a set of
utilities for it, and I ran out of time. I'll try to write up a
limited how-to sometime in the near future and post it to my blog. If
there's enough interest, I can probably refine it and post it to an
appropriate debian wiki, even later.
Given that I haven't written the how-to yet, I'm going to briefly
explain why I don't care for ACLs or SELinux:
If you need to share files safely and securely, you can try to use
ACLs, but I don't recommend it. It's easy to punch holes in your
security model while you're trying to make the ACLs work, and I'd
recommend figuring out unix permissions first, instead.
And if you understand the unix model of file permissions, as it is
implemented in debian, and if you have admin privileges, it's going to
be quicker to just create a private group for sharing and make the
appropriate users members of that private group. (This is what I do at
home.) There are some bumpy spots in this approach, but the bumps
aren't really cleared when using ACLs.
One ACL approach would be for the admin to set up a public folder for
each user, either within the users' home directories or in a separate
sharing directory, and allow each user to store the files to be shared
there and set the ACL for each file to restrict the file to the users
that need to see it.
Setting up that public folder requires understanding the permissions
model. Even using it, if you don't understand the model, you're going
to be wondering why you can't do certain things.
(There have been distributions of unix and Linux that don't follow the
correct model for various reasons. Most of them have earned their
Darwin awards by now. If you want to discuss what the correct model
is, start a different thread, please. It has been the subject of flame
wars in the past.)
SELinux is overkill for this sort of thing, and might, in fact, get in
the way enough to cause people to deliberately open holes in their
security.
I have some epithets for both SELinux and ACLs, which I will refrain
from here, but with three different functions trying to control access
to files, it's really easy for even an experienced user to intend to
set one set of permissions and end up with another.
I may be wrong about this. I'll admit that up front. But according to
what I read in the systemd docs and cgroups docs, between systemd and
cgroups, you end up with another, more-or-less hidden path to change
the effective permissions on a file or directory.
(I'll try to remember to go back and check later this week, since
Chris is insistent, although I have other priorities that should be
higher, including one that involves providing means for doing some of
the things systemd does wrong the right way.)
So, with that example in place, I'm hoping that everyone who bothers
to read this will at least agree that, one, users should be regularly
spending a little time to learn a little more about the systems they
use. Users should be willing to discuss what they understand, even at
the risk of being wrong sometimes, even when the subject involves
something as inflammatory as systemd is turning out to be.
To you who say, "Leave it to the devs!" -- well, sure, Don't try to
break into the source code and rip systemd out of the repositories. If
you support what they are doing, file bug reports instead of beefing
here. Even if you don't start with the bug reports.
If we had an ombudsman or something, we could take serious problems
that don't get resolved there, but setting up an ombudsman function is
really hard to get right, and if you don't get it right just generally
makes things much worse after a short time of seeming to be just what
the doctor ordered.
Setting up an echo chamber where no one is listening only serves to
prevent necessary conversations from taking place.
At the present time, this is the only real forum we have for
discussing issues that are serious, that we think are not being dealt
with properly by the developers.
Remember that developers are human, too, and sometimes suffer bouts of
excessive hubris, and maybe even have down days when any little
disagreement at all feels like a personal attack. Even in the best of
worlds.
I'm far from convinced that preventing such conversations from
occurring here would ever be correct, even if we had other paths for
problem resolution. The possibility that the criticisms might go too
far is a price we have to pay to keep the channel open.
(I personally don't think they have gone too far here, except once or
twice when blatant physical threats were posted. Even in the ironic
mode, the possibility that a jest could turn real is not small enough
for those kinds of jests to be allowed, and to those who helped shut
down those physical threats, I think we all thank you. But we should
also consider that such threats may well have come from a concern that
systemd will end up failing in a way that will cost people real money,
and real jobs.)
If you want to say that the problems are only minor quibbles, sure, say that.
But if you say that, because you say so, everyone else should shut up
and leave it to the developers, you are basically asking for one of
the important QC/QA functions to be shut off so you can compute in
peace. And that means you are not taking your responsibilities as a
user seriously.
And if things go your way, you'll get what you deserve -- a system
full of bugs, because no one dares disagree with the developers.
--
Joel Rees
Be careful where you see conspiracy.
Look first in your own heart,
and ask yourself if you are not your own worst enemy.
Reply to: