Markus Wernig wrote: > Theo de Raadt wrote: > >>>1) With the above install lots of software came onto my disk that I do >>>not want nor need (named, httpd, inetd ...). How can I get rid of those >>>in a consistent way, since they don't show in pkg_info? >> >> You don't get rid of it. Is it hurting you? It is not even denting >> your disk. > > Well, not actually hurting (except for the test boxes that are really > low on disk space). It's probably more a question of mindset. Up to now > I was used to controlling which software went on my system and which didn't.
Relax. YOU installed everything that is there. Nothing was snuck onto your system. You can look at the startup scripts and the install scripts. You can see what is invoked and how. Which would you rather have? 1) A completely "modular" system which works in some combination, but has never been tested for for others? 2) A complete *system* which has been extensively tested as a *system*? Hey, puzzles are fun, but sometimes, you gotta get work done. Keep in mind, if you have ten "knobs" with only two options per knob, that's over 1000 variations that need to be tested...and yes, they all interact in ways that most people don't fully appreciate....and sometimes, they interact in ways that no one appreciated, until ... OpenBSD is about getting work done. If you wish to turn it into a puzzle, you can...but forgive us for not assisting in that, we got better things to do. >>>2) I assume that the answer to the following question is "yes", but I'd >>>like to double-check: Is there really no way to upgrade a single >>>package/program to a recent version in a consistent way? >> >> No. There is no particular need. > Hmm. I just trust you, then? Given your and the team's reputation, this > doesn't seem too hard. Yet, again, it might just be a question of my not > being used to relinquishing control. > [...] This is an operating SYSTEM, not bits and pieces bolted together. COULD you pick and chose different versions of component pieces? Sure, it's open source, free license, you can do anything you want, assuming sufficient skill on your part. Do we support mixing and matching? No. Will we beat on you if you try and fail and ask for help? Yes, we will. :) Again, relax. You are not relinquising control, you are in COMPLETE control of this system. Just a lot of the controls are pre-set for you in the safest, most tested way. None of the control are hidden. All of them are labeled and documented. We don't have any cute cartoons over the controls to "help" you do what the cartoon's artist thought you might find "important"...it's all there for you. We do expect you to sit down with the owners manual (man pages) and the quick start guide (FAQ), rather than have the cartoon ask you strange questions, but I suspect you will find it worth while. Until you understand, leave the controls you absolutely don't need to fiddle with in their default position, and you will be in pretty good shape. Once you know what is going on, there they are...you can point 'em at the sky, crash it into the ground, whatever. But don't whine to us that you broke things by..uh..breaking things. Things are different here. Don't try to make OpenBSD fit into your previous models before you understand WHY things are the way they are. >> The basic summary is that we try to fix the bugs before we ship the >> software. > In the original release, that is? > So the base line is that you review every piece of code in the base > release and try to fix all errors, even those that have not yet been > "publicly" spotted. If one still slips through and is later discovered > to be severe, a source patch is released, else it's fixed in the next > release. Does that sum it up? Sorry for the nitpick, I'm just trying to > understand. The goal is to make every release as close to perfect as possible. The goal is not to shove something out the door and "fix it later". The point isn't to fix "security holes", the point is to fix everything that is wrong. IF they later prove to be security holes, fine, whatever. Effort is not spent trying to determine the security implications of something that is clearly wrong...if it is wrong, it should be fixed. The developers don't hide the stuff they fix, it's all there...every line. They don't wait for other people to find the problems, though. Just fix it because it is wrong. If that fixes a rare crash, great. If it fixes nothing obvious at all, fine. If that "nothing obvious" later turns out to be a serious security hole, whatever, it's fixed, who cares? (unless you run an OS where people want to see PROOF that there is a security issue before fixing problems, of course). The existance of the -stable branch indicates we aren't quite perfect, but the -release of OpenBSD is more secure, safer and more stable for many people than the patched-up version of most other OSs. MOST people won't see a difference in the operation of -release and -stable. That's the point. >> Yes, I know... that's a radical departure from the way that most of >> the operating system vendors operate. > A radicality that, if my above assumptions are correct, would well fit > any responsible vendor. you say that as if it is a common thing... Nick.
