begin quoting Todd Walton as of Sun, Mar 13, 2005 at 02:16:37AM -0800: > On Sat, 12 Mar 2005 22:29:16 -0800, Stewart Stremler <[EMAIL PROTECTED]> > wrote: [snip] > > That's the general idea. If a vendor demands that you give _them_ full > > and unrestricted access to *your* machine, you should tell them to take > > a long walk off a short dock. > > Agreed. Literally, and in spirit. As a side note, I once knew a guy > who took a long walk off a short pier. Actually the pier wasn't that > short. He just wasn't paying attention.
Heh. > > The only reason this sort of arrogant "your machine is my machine so > > suck it up" attitude works is that the users cave in and go along. > > "There is no alternative," they mutter, and "those software people > > wouldn't ask me to do something that wasn't NECESSARY." > > There are those of us who like working with machinery. But there are > lots more in this world who don't. I don't think that it is, nor > *should* it be, the average user's responsibility to worry about > trust. Ultimately, it all comes down to the user. They either delegate trust to the vendor, or they delegate it to the government who dictates the policies to the vendor. The Average User should worry about trust in this way: if they don't understand the issue, say "no". Full stop. Don't understand the consequences of executable attachements? Say no, and have the software strip 'em out. Don't understand the consequences of running Network Services? Say no, and don't enable 'em on the system. Don't understand the tradeoffs and risks of Javascript? Disable it. At least, that's the _ideal_ world. > First and foremost, the operating environment should be such > that a malicious intruder doesn't get far, and is easily taken care > of. Malice cannot always be detected. It depends on _intent_, and there's no way of getting that into the system. > Secondly to that, it should be taken as the responsibility of > software people to produce software that does what it's supposed to, > with as few negative side effects as possible. They argue that this is why they need administrative access. They are trying to "minimize negative side effects". So I think we need to phrase things differently. Coming up with that phrasing is proving to be difficult... What we need is an efficient way of sandboxing processes. Because programs can often test their environment to see if they've been given the sort of control that the programmers desire, we need to have the sandbox be *transparent*. User-Mode-Linux is too heavy-weight, and you do want to allow *some* interaction between processes. The fakeroot and chroot commands do a little of this, but they aren't quite there yet. SELinux holds forth some promise, but doesn't appear to be *dynamic* enough. Then again, I haven't tried running it in quite some time, and it's not really solving the problem. > So, to the extent that you're blaming end users for this, I have to > disagree. Users get what they want, or they go elsewhere. Granted, blaming the users is a harsh way to phrase the problem -- it's more of an interaction between the providers of software and the user-base... > But I think that I agree with you, Stewart, more than I > disagree. My two points above only underline what you're saying. Thank you. > That many software developers don't adhere to basic good sense in > their craft is definitely something bad. Yes. There were a few lessons I learned that do not appear to have been taught broadly: 1) Don't hard-code data. Constants aren't. Besides, it's hard to know why the magic value of 6.28 works. Paths to dependent programs may change. You never know when something on the system will be moved, and your program should still work if everything is moved around. 2) Don't spread out your platform-dependent code. Put it all one file. That way you can rewrite just one file for each system, and porting involves selecting the appropriate machine-specific file to link in to the rest of the system. 3) Comment. Explain your intent. "Self-documenting code" is a myth promulgated by the lazy and/or illiterate. It's better to have well-documented but non-working code than to have undocumented but working code -- because then someone else can fix your code instead of having to rewrite it. 80% of the lifetime of a program is spent in maintenance mode. Either that, or they've been rejected out of hand. :-/ > > The very attitudes that caused many of us seek out _alternative_ systems, > > from applications like OpenOffice and operating systems like Linux, has > > come to roost in the open-source community. Once again we see that the > > new boss is the same as the old boss... > > No! There is nothing inevitable about the similarity of bosses. "That, Mr. Anderson, is the sound of Inevitability." "My name is Neo!" > Open > source is not going the way you want it to go. What are you going to > do about it, Stewart "Always Has An Opinion" Stremler? I'm serious. > I'd like to know, now, not just your suggestions on how software > should be written, but how to make it happen that it gets written like > that? I cannot *make* anyone do anything. I can write MY code so that it is as "clean" as possible. Otherwise, I can only argue. Create memes and set them loose. Alas, it seems that my memes aren't terribly infectious. The current meme is that it's my machine, not yours, not theirs, but mine. I should get to decide where things go, how things are arranged, and I should be able to do this whenever. -Stewart "Open to better suggestions." Stremler -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
