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. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caar43imumashdol_9z6slew4uo5e7qpattud_zuh_sgfckt...@mail.gmail.com
