Dude, I know about realtime priority. I've been in the realtime business for most of my working life.
I have been in OS design and implementation for 2 decades, but really, that is no argument, nor is you having been into realtime stuff for whatever time.
Then, realtime class != realtime priority. Priority of realtime class processes in handled differently, but is not exactly higher.
I've used UNIX systems with realtime priority. It doesn't make a difference to interactive response time. It's a great way to lock up the system when a realtime process goes into an infinite loop and becomes a compute-bound process, though.
And it still will allow decent interactive use on an OS/2 system.
I can EASILY believe that OS/2 is doing a better job of handling I/O. That's been a problem with the traditional UNIX monolithic kernel as long as I've used it, but that's got nothing to do with how many CPU-bound processes are sitting there competing with the interactive one.
OS/2 has a monolithic kernel as well, that has nothign to do with this whatsoever.
The thing that has everything to do with this is deciding which of the processes that is runnable at a given moment gets time. As said before, a realtime class (not priority!!) process can go into an infinite loop and still not prevent an interactive process from being responsive.
As long as 30ms latency is acceptable, OS/2 is uable for realtime purposes, it GUARANTEES that latency, Unix does not give any such guarantee (tho modern implementations have gotten a lot better at it)
At one point around 1990 I was 2 of the top 3 posters on Usenet. My first posts date back to the early '80s. I'm real familiar with ">"-quoting, and if we were using trn with an 80x24 screen with all the lines wrapped on input, that would work nicely. But ">"-quoting doesn't work worth a damn in an environment where you're NOT using a TTY type display.
Well, I have no problem with it in a browser either, but since you are the one having to read what I type and have trouble with it, I'll do as you suggest.
You do know of course that bash forks and execs for each external command (like ls) and internal commands frequently involve disk I/O as well. In addition, CD burning... particularly on older burners... is a real-time process and good burning software is going to run at an elevated priority... it's more important than the user interface. So you're mixing up CPU, disk, and a high priority background task. Separating the impact of the scheduler out of that is going to be a big problem.
Bash has internal commands as well of course. Also, OS/2 does not suffer from similar inresponsiveness in similar conditions.
OS/2 puts things requiring realtime priority in a seperate priority class, they are not 'higher' in priority but they are treated differently to ensure they get their timeslices when needed still.
Basicly, OS/2 has 4 priority classes, each with a number of priority levels (32 if I remember correctly, but this is some time ago).
How dynamic priority works out depends on the class you are in.
What sort of serial port, what was the UART? 8250, 16540, 16550? Was the Solaris driver smart enough to use the 16-byte queue in the latter case, or was it taking an intterupt for every character? Again, you're combining all kinds of things that have nothing to do with scheduling.
16550AFN, 16byte fifo,
Using a 8250 just makes the problem more prominent.
And no, I am not mixing up things here. How the system handles interupts, realtime tasks, user tasks, and gives all of them timeslices at the moment they need it has all to do with priority management and your scheduler. That a 8250 generates a lot more interupts then a 16550 is true of course but it applies to both systems (unless of course a system doesn't support the fifo)
You can do a similar experiment with for example formatting a floppy in the background.
You are right that there are a lot of aspects to this, but in the end, it is still a matter of how the system distributes time over the processes that are running (or threads in case of OS/2) which is still the task of priority management and the scheduler, and giving the guarantee of a context switch and rescheduling of tasks within a given time (30ms in case of OS/2 with a default configuration, this is tunable by the user)
Resource congestion? sre, that is the problem we are talkign about, just that the CPU is yet another congested resource.
> Could you, like, indent or italicise the stuff you're quoting?
I use the decades old quoting convention from usenet, email etc before there were things like html. Any line starting with a > is quoted text.
> I've seen interactive character mode applications become unresponsive in those circumstances, but I can't see how that could possibly have anything to do with the scheduler.
Well, the contested resource was of course the CPU, no swapping/paging.
Example, bash accepting user input, becomming slgightly sluggish because of cd writing software running in the 'background'. The CD writing software did try claiming 100% cpu time, and most likely also used some other resources. I could also go back ot the 486 that I used to run OS/2 on and still run Solaris on. OS/2 had no problem with keeping a serial link at 57600bps running reliably without any noticable impact on a foreground shell, SOlaris on the same hardware doesn't, anything above 19k2 for the comms app becomes noticable for the foreground app.
> So in OS/2 if your foreground program opened a file and that blocked for half a second because it was on a network file share and competing with the porn traffic, then the GUI as a whole was also blocked until that application responded to a message? What if the app was blocked for a minute? Did the whole thing lock up for a minute?
You got it. FOr a nice example of this, try Lotus 123g for OS/2.
> I find this hard to believe. Did you test this on the same hardware? What version of UNIX were you using? Because I have been using UNIX for a quarter of a century and I can not recall ever finding myself in a situation where a character based interactive application that wasn't blocked on other I/O was effected by any number of background CPU-intensive apps. Ever. Even when the load average is up in the double digits, when there are dozens of programs competing for the run queue, interactive applications autmatically and invisibly get priority.
Hrm, I saw this fail on Sun 68k, sparc and hypersparc hardware, and on x86 hardware, Irix on R3000, R4000, R5000, FreeBSD, NetBSD and Linux on a huge variety of x86 hardware (from 386dx to p4 xeon), AIX on a whole variety of RS/6000 machines, HPUX on HPPA and some more. My experience with Unix like systems is some 5 years shorter then yours, but I doubt it is less extensive.
I only ever ran OS/2 on 386, 486 and classic Pentium machines, and I only ran Solaris (upto 2.6), Linux (upto 2.4) and FreeBSD (upto 4.2) on the same hardware, so direct comparison I can only make between those systems.
> Actually, a single event queue feeding a single event loop is a very common technique used in real-time control systems, because as long as you can control the latency for each operation you have complete control of the latency for the system as a whole. Having a single queue that imposes virtually no latency of its own is still going to give you a more responsive user interface than multiple queues that deliberately impose latency to increase throughput.
Of course, and for a very well controlled realtime system this works really well. For a general purpose GUI you cannot control the latency of whatever application the user decides to run, so there it really does not work too well.
> And what exactly are you saying about OS/2 in CHARACTER MODE and UNIX in CHARACTER MODE? I want to be certain here, because way back in this thread I said that the differences between OS/2 scheduler and the UNIX scheduler weren't fundamentally important for graphical user interfaces, and both were doing about the same thing, and you just accused me of saying the UNIX scheduler did better than OS/2. Which isn't something I've said, or attempted to imply... and if I inadvertently confused you, I apologise.
What I am trying to point out here is that the difference in responsiveness between the 2 stays even when you eliminate the GUI completely. The very simple conclusion is that the GUI may contribute but is not the sole, and not even the primary reason for this difference.
>> that mouse pointer is almost completely handled in hardware, and you do still get interupts > The mouse pointer isn't controlled from an interrupt, it's crontrolled by Intuition, from an ordinary Amiga Exec task.
I somehow recall this running during vertical retrace, but I may confuse this with the code that handled the pointer in Geos. Regardless, movimng around a hardware mouse pointer is so extremely simple and non intensive for the cpu that any OS that provides some form of preemptive multitasking should be able to handle it without much of a problem, esp. when you can get away by only updating the position between 12.5 and 15 times/sec.
> And with a modern accelerated video card, the mouse is almost completely handled in hardware too.
Yes, and on such a card I have yet to see a mouse pointer become jumpy as a response to high system load, Windows, X11, OS/2 PM make little difference there as long as they do indeed support the hardware pointer also.
> So if the fine details of the scheduler was that important to maintaining the GUI's responsive behaviour, the simplistic scheduler on the Amiga should have been a major drawback. Right?
No, wrong. try to actually click on something while your Amiga is heavily loaded and see if you get a response.
While smooth movement of a software generated mouse pointer gives an indication, movement of a hardware mouse pointer gives very little indication of how responsive a system stays under load.
My original claim was that the OS/2 scheduler and priority management do a better job at keeping the system responsive then a typical Unix scheduler and priority management. This is very clear when using a GUI, and many people (including you) seem to attribte this to the GUI.
A GUI that employs a single, synchronous message queue for events between the GUI and applications is really not a good way to achieve responsiveness at all, and it is definitely not the reason for OS/2s responsiveness, if anything, it is a problem.
> Well, yeh, of course they did. They have to tell you that all their design decisions are great and why they made them. Every major piece of software has lots of very smart people writing lots of copy about why they did the things they did. They're not always right.
Of course they are not always right, I never said so. I just pointed you at the fact that many things have been said about why exactkly the scheduler and priority management of OS/2 was better, you can ignore that and just keep pushing your own little love for Unix.
You can disagree with what people say, fine, give soem reason, provide some argument, maybe point at an argument already made by someone else. Just dismissing what is being said with 'people say so much' is not going to help being convincing here.
> You do see the same thing on UNIX for non-GUI applications. Interactive applications are responsive no matter what the CPU load is, so long as the memory load doesn't get so high they're deferred by swapping or excessive paging. Unless you're talking about like that, or you're seeing the behaviour of the GUI around the character mode application (you know, right, that when you run a character application inside an X-term the user interface is still handled by the X11 GUI), you're just plain wrong there. The responsiveness of UNIX character-based applications under excessive CPU loading is phenomenally good. Legendary, even.
You just go try running anything interactively (and I mean something character based, running in a full screebn console in native character mode, so no X11, no graphics mode WHATSOEVER) on a machine with a load of 20 and without overcommiting memory. I have had that situation on Linux, FreeBSD, Solaris, AIX, HPUX, IRIX, ULTRIX, and ALL of them perform a lot worse under such conditions then OS/2 does with similar load and a VIO app in the foreground. If you don't believe it, please go try it.
So X11 may add to the problem, but without any trace whatsoever of X11, the problem is still there.
Unix does a lot better in this then any Windows version, sure, but it did not, and still doesn't do better then OS/2 in this.
Just to make sure, I am comparing OS/2 in CHARACTER mode, NO GUI running whatsoever, with Unix in CHARACTER mode, so again, NO GUI whatsoever. Please make an argument that does in no way involve X11 can you?
As a small sidenote, I actually have seen large parts of the code of presentation manager from OS/2 as it was in 1.2, 1.3 and 2.0 (I am a former OS/2 developer), adn I can assure you that it is in no way responsible for the high responsiveness, rather, it was one of the major obstacles to achieving responsiveness.
So even while your claim about X11 and inefficiency may be true, its not relevant.
Then, with regards to the Amiga, it is extremely easy to slow it down ot crawling speed and yet have a smooth mouse pointer.. easy becaus that mouse pointer is almost completely handled in hardware, and you do still get interupts. All it takes from there is changing 2 registers.
> When I started using UNIX back around '78 it had already been doing that kind of priority juggling for so long that you just assumed it was there.
When IBM and MS introduced OS/2 in the late 80s, they also filled quite a few pages about why the OS/2 scheduler does really a much better job at those things. They did a much better job at explaining it then I can do, but I have seen enough of both to see that even when it may look like trivial differences, they are in fact a very relevant.
> No, really, it's not the scheduler. Juggling priorities so that interactive tasks get priority over compute bound ones is precambrian. It's not what makes OS/2 and other operating systems that provide good interactive response what they are. Do you want to know what it is? It's the whole GUI design. It's recognising that a GUI is a real-time environment, one in which the time a result is generated is part of whether the result is correct or not. It's taking advantage of the fact that the display is computationally close to the user. It's all kinds of things.
Yeah sure, that is why you see the exact thing for non GUI (ie, character based) applications.
> THAT is why now that you have a 2 GHz 64-bit processor and a graphics card that by itself has more CPU power than the whole of Project Athena at MIT did... that is why you can have all that and when things get busy it gets delayed. The differences between the design of X11 and OS/2 are so profound that they utterly swamp trivia like a slightly different scheduling algorithm.
Its by far not the only thing that matters, putting some limits on how long a task can spend in the kernel while blocking the rest of the system helps as well for example.
OS/2s GUI is definitely not a well designed one, especially its single message queue is a problemn both for responsiveness and stability. X actually does a much better job there.
As mentioned before, the same kind of difference can be seen when you eliminate the GUI on both Unix and OS/2, so sorry, your story about how this is all the gui is simply not true.
> I doubt that what you're seeing has anything to do with process priorities or scheduler design. The unfortunate design decisions that have produced the kinds of glitches you see in the current X-based desktop environment are buried much deeper and are harder to fix than simply tweaking the scheduler.
Its not simply tweaking the scheduler and priorities, its a different design of scheduler and priority management, and indeed one that does a better job at giving the user a nice smooth experience.
2 factors in this were dynamic priority boosting (a runnable task that had been 'starved' for too long would get its priority boosted untill it became high enough for it to get a timeslice) and the notion of foreground/interactive tasks versus background/non interactive tasks. The interactiveness was not just about the 'nature' of the application, it was more about if it was the one currently having the user focus.
Together with a rather short context switching time, this helped provide a good starting point for a nice responsive system.
Go get yourself a C64 technical reference from e-bay or such, it contains a complete (assembler) source listing with comments of its kernal (yeah, thats how Commodore called it) and at elast part of the basic interpreter;)
> So from the perspective of IBM there would be the advantage of getting somebody outside look into the code and fix bugs.
Is this really an advantage to them?
They decided somewhere in the last decade that service was their thing, fixing bugs for a product tat is beyond its official end of life is not always easy, but it is well payed for service, which for quite some time has been IBM's main business.
As long as enough customers exist that pay them for maintaining it, there is no business sense whatsoever in opensourcing it.
> Actually, no. IBM really did all they could do. But until the late 90s, they had to pay $86 to MS for every copy of OS/2 sold (part of the licensing agreement for HPFS).
Ah yes, thats why we (was working at IBM, doing OS/2 support and some development) got told that marketing effords aimed at the consumer were to be stopped inmediately, the day before WIndows 95 became generally available..
No, they didn't try as hard as they could, they gave up before even having tried.
> OS/2 V1.0 was a MS product, infact 1.1 may have been MS also.
Both 1.0 and 1.1 were made and sold by MS and IBM. Microsofts involvement declined after that, but they did also at least release 1.2. I am not sure about 1.3, tho I am very shure they could have released it at the time with the agreements as they were.
A part of OS/2's code, and quite a bit of its design can be found back in NT, and earlier NT versions had enoufh OS/2 in them to be able to run many character based (VIO) OS/2 applications.
How do I know? I was part of IBM's OS/2 development efford from 1989 till 1996.
> It was not until 1.2 that it was IBM only. MS and IBM had a falling out and they each took the existing code from 1.1 and went their own merry way. MS wanted to keep "Windows" alive, so IBM got the OS/2 name. Although I never saw this, I have been told that the early releases of Windows NT actually had OS/2 in the error messages.
> And FreeBSD is lacking in Systrace support which is by far a better option than just jailing processes.
Systrace is way cool, and an extremely usefull tool. It provides granularity way beyond what a FreeBSD jail does (tho with MAC you get quite a bit closer, but following a different idea)
Systreace has one big disadvantage, it is so flexible that it requires quite a bit of thought to configure it correctly, and it requires indeth knowledge of both the application and the operating system.
Better for specific situations? definitely. Better as a general purpose security measure? I doubt it is for the average administrator, it requires too much configuration and knowledge for this.
When having a choice between slightly more complexity in code, or more complexity in configuration, I prefer the first. Code is written once by supposedly knowledgable people, it can be fixed if needed. Configurations are in the end made by humans, many different ones for that. The chances of mistakes there are a lot bigger, and are in the end more difficult to find and are managed by less knowledgale people.
> This is pretty nonsensical. You make it sound like a chroot is something you can just break-out of. Once a program has chrooted itself, and dropped privlidges, it's locked there. No attacker is going to be breaking-out of the cheroot and getting access to the rest of your system. Jail doesn't provide any extra security there.
That depends a lot on what is in your chroot and how much you can trust it.
> Besides, as I said above, OpenBSD comes with systrace, which FreeBSD does not. Systrace is far better than even jailing your processes.
And requires way more work on the administrator side to be done correctly, introducing a bigger chance on mistakes, not to mention the cost in te form of time.
> Not to mention that OpenBSD has propolice, W^X, and the other protections that make your system even more secure, that FreeBSD is lacking.
propolice and W^X are usefull, no doubt.
What made me write my original post, and now reply to yours, is the notion among certain people that OpenBSD cares about security and noone else does. That OpenBSD is the only one to have usefull features for this. Well, when looking purely from a coding point of view, OpenBSD has a very good featureset. When looking from a more practical point of view, building a functional system that is secure and maintainable, then it is not always the best choice, and in practise it often is not in my experience.
Just so you know, I run Open, Net and FreeBSD (and some Linux variations), and I will use OpenBSD when appropriate, but I don't find it appropriate for quite a few situations.
> No problem, in fact Apache ran in chroot by default, as of OpenBSD 3.2, Nov 1st 2002. named chroot by default, as of OpenBSD 2.4, Dec 1st 1998 and smtpd was default chroot at least in 2000.
Systems like FreeBSD and SOlaris (at least on specific hardware) allow for going quite a bit beyond a chroot. Please look into it soemtime, the differences go beyond what I can explain in a single post, and the ways you can use it to make somewhat more complex configurations work with a high level of security is something you can fill a few books with.
Just to be clear, what I am talking about is NOT just a chroot. The lack of this more then anything makes me often chose something else then OpenBSD.
You can just keep ignoring this and point at all good OpenBSD features, well, we agreed quite a few posts ago about their attitude and featureset.
> OpenBSD is an excellent choice as long as it at least can be configured to meet all needs. Obviously if it can't currently support a need then it must be overlooked.
Maybe it is just me, but I end up very often eneding things (one thing in particular, see above) that OpenBSD does not supply.
More recently I have found myself ending up using more and more SMP hardware, and while OpenBSD has become a valid option now on that in some cases, it is far from what I end up needing most often, for exactly that thing, an internet facing machine running some mix of services.
> But this is a far cry from overlooking it just if the default configuration does not meet the needs. It's not like the default install is as functional as it gets. We all know that OpenBSD is quite the opposite.
Yes, and this is why I do use it, and also consider it a very good system for learning about this and for building single purpose dedicated machines for example (ie, appliances)
I somewhere promised to come back on a patent relating to using xor for displaying a cursor, this concerns patent #4,197,590, its from Cadtrak and not from Microsoft as I thought. Google for it and you will find more discussions about why it should or should not have been issued, enough has been said about it I think.
What it comes down to is that a general purpose computer is just that, an aperatus that can perform any function within its physical limitations, based on instructions provided to it in a form it can read.
The creation of the sequence of instructions is where the actual investment takes place, and this is already 'protected' by copyright. Algorithms in this function in a way very similar to mathematics and should be treated as such, they are the basic building blocks for software and are usually discovered and not so much invented. What is invented at times is new systems that make algorithms possible that were previously only theoretical, and I think those can be subject to patents.
At any rate, when someone tries the effect of the typical working of some tool (using a general purpose programmable device to run a program) to solve a new problem, when there is a likelyhood that the tool will affect the problem, and where it is possible to test many variations for outcome without much efford (a consequence of the general purpose nature of a general purpose programmable device) then that should be enough motivation already to try and as a result make for obviousness (given that the way the tool (computer) is used in itself was known beforehand, pssibly without use of the specific tool (general purpose programmable device))
The crux here is that the aperatus is the general purpose programmable device, and not so much a combination of that and a program. The general purpose programmable device makes it possible to go from blueprint (well, something written in some formalized lamguage to be exact) to the final result virtually without efford, and eliminates the need for building a specific device, this was invented with the invention of the general purpose programmable device, and has been known fact ever since.
That someone could have initially patented the running of a program on a programmable device as a means of solving problems without having to build a specific machine for each problem is another matter, and probably someone did (I recall a limited version of this happening in France somewhere in the late 1700s or early 1800s with regards to machines used for weaving paterns and the use of punch cards)
Ok, then my understanding seems to be right (tho I probably lack detail).
I find it somewhat interesting still that proving obviousness more or less comes down to proving prior art. I can understand why 'easy to understand' can't work because many things are easy to udnerstand with hindsight, yet untill someone thinks of it, they were not easy to come up with, hence non obvious. If something is mere replication of a known technique on a new medium, then I believe that a patent should very well describe why it is non obvious because it most likely is obvious to someone skilled in the art.
If obvious does not have a meaning that is anywhere related to obvious as I just described, then the 'skilled in the art' part really makes little sense. I would argue that what was intended by the law is closer to what I describe here then what for as far as I understand the current legal definition is.
Then an entirely different question regarding the validity of software patents (and actually, patents in general)
According to my understanding, the constitution granted congress the right to make laws that allow for patents to encourage usefull inventions.
There seems to also be a notion that economic monopolies are something to be carefull with, and should not be encouraged unless they serve a purpose. For what I know they are not illegal as long as not abused.
I believe that over time courts have roughly enforced what I wrote there about monopolies.
A laymen would reason that as a result, patents should only be granted when they do indeed have a very high likelyness of encouraging usefull inventions.
What is more, I would claim that that is the exact intention of what is written in the constitution as well as patent law.
How can it have happened that this got changed into patents getting granted unless they are very obviously (dictionary definition) invalid or someone with enough money to do so fights the less obviously invalid ones in court? This result seems to contradict at least a laymans reading of the constitution and law.
(It should be noted that software developed for most of the time without enforcable patents, and you will have a very difficult time finding people who will say it developed slowly during that time, rather, it developed as fast as hardware and human understanding did allow, so making an argument that patents are needed to encourage invemntion here seem to rather be disqualified by the real world)
I realize above is quite simplified, and may lack detail, but I assume the line of thought is clear.
> By those general duties, I am refering to the usual suspects: DNS, FTP, HTTP, POP3, SMTP, etc. W^X, Propolice and Stackghost tackle some pretty generic security problems which can plague these services and are responsible for a large percentage of successful attacks. However these are not the only services that OpenBSD supports and the active security mechanisms work regardless of the application being protected.
Absolutely, and those features are extremely usefull to tackle specific classes of attacks.
Quite a few security breaches result from simple misconfigurations, and none of the mentioned mechanisms does much to prevent those while of course they do help prevent exploitation of a whole bunch of possible bugs that can result in privilege escalation, so there is a level of containment there.
For services like a public dns, smtp and in many cases http, I prefer being able to seperate those from the host environment so that even in case of a local root compromise, the effect is still contained within an environment specifically built for that one service.
This takes more efford and isn't entirely out of the box, so no argument about that.
For many a situation I found having to put in quite a bit of efford to make things secure and functionally what is desired (I have yet to find the customer who only needs a basic apache and smtp server), so a little extra efford while setting things up is not too much of a problem, esp. when it saves efford for maintenance later on.
Ideally, you'd have all the openbsd security mechanisms together with what I just described and something like mandatory access control (having acl support makes live a lot easier and safer when running samba on an internal server for example)
As long as we can't have that, I'll have to make a choice, and I believe that choice is not as straightforward untill most peope only actually need a default install.
> Please ask the Sinclair people, and then get back to me. Media Matters is bringing these issues, which otherwise few people would know about, to a public forum.
A long time ago someone said soemthing along the lines of 'I may not agree with your point of view, but I will defend your right to state it with my life'. Where did those days go?
What you wree just doing is following the following simplistic reasoning:
"They are wrong so I can be wrong."
Well, 2 wrongs don't make a right, and the ONLY valid defense against such propaganda is uncovering and publishing the truth (which is incidentely what MM seems to eb trying to do).
You are of course entitled to your own opinion, but I really suggest you go look at countries like France or Germany to get a bit of a clue what the consequences of your rather misguided ideas are when applied to political speach.
> The spectrum is limited. The spectrum belongs to the people. The spectrum is licensed temporarily to broadcasters for use in the public interest. Anyone acting outside the public interest is subject to having their license revoked.
I doubt there is much disagreement about that aspect.
What you seem to have a lot of trouble understanding is that the broadcasting of opposing views, and even the broadcasting of provocative lies is in the public interest. It provokes thought and discussion, and that gets you a better informed public in the end.
As soon as you start deciding what should be broadcasted based on if you like the point of view (or just whatever is beign said/shown) then you are no longer serving the public interest, you are only serving your own political point of view and those who happen to agree with it.
Living in a democracy is difficult because choice is difficult and having to accept that not everyone agrees is difficult. If you forgo the later 2, you can forget about the first one.
> It takes more code to conditionally load drivers. It takes more effort to debug different kernel images.
Removingdrivers and features that you do not need does not require any code to conditionally load drivers, it requires removing them in your kernel configuration and not building and linking them.
You are jumping to the conclusion that I was talking about dynamically loading drivers, I was NOT.
> Extra drivers that aren't executed aren't a source of vulnerabilities.
The potential to call code in those drivers exists so yes, they can be a potential source of vulnerabilities.
> But it seems to have the highest strength for general internet facing duties and is beyond taking another BSD and just adding a little extra effort to security.
And this is exactly where we seem to disagree.
In my opinion, that is only true if what you need happens to fall within the focus of the OpenBSD team. They do a lot of good work, and if what I need happens to be within their area of focus, I will often use their work, but there are many more situations where OpenBSD simply does not offer the functrionality that I need for an internet facing machine.
In other words, they are limited in what they offer, but when they offer something they do it well.
On another note, I find it interesting how you (tho in a friendly way) get somewhat defensive as soon as someone suggests there may be other and even better solutions then OpenBSD while at the same time agreeing that it is not perfect. I don't think there is any reason for this defensiveness, noone is saying it is bad or was attacking it in any way.
> This is a single example application out of many, using a single example security mechanism out of many, which has been developed (the code, not the concept) on and primarily for OpenBSD by OpenBSD developers.
And they did a good job there as I said already. However, there are also other platforms which implement security mechanisms, and at times ones that OpenBSD does not have. Often those are Kernel level mechanisms that go beyond the basic Unix concept.
At any rate, as I have said elsewhere already, if I were to build a router or small webserver, OpenBSD would definitely be one of my first choices, and idem for a shell server that is used for remote maintenance for example.
If it were to include smtp support (not unthinkable on a home/small office router/gateway) or something like an smb or nfs server (not very likely on a router), I may find I have a need for things like mandatory access control and the ability to seperate the environment a service runs in beyond what a chroot can do.
> My previous statement, "Yes but priv sep requires code changes for each privilege seperated application. Some apps are particularly difficult to do this with, like ssh.", does not refute that.
I never said that it was easy or that anyone else did this or anything that intended to refute that this was difficult or whatever. I pointed out that you will find openssh with privilege seperation on virtually any modern unix and at least freebsd and many a linux distribution. Thanks to Theo and his people? definitely. Kudos to them. Exclusive to OpenBSD? Not at all, and that was my only point there.
> My original point, is that they roll out many security mechanisms and this is just one of them.
Which I never even tried to refute, I just pointed out that most of those mechanisms are not exclusive to OpenBSD (tho they may get them first)and that there are also security mechanisms out there that OpenBSD does not implement. That does in no way mean that I deny their focus on security, but it means that that is not something they are alone in.
In short, while very secure, OpenBSD is by far not the only OS allowing you to build a very secure system, at times it may be the better choice, at other times it may not.
Slashdot Mirror
Dude, I know about realtime priority. I've been in the realtime business for most of my working life.
I have been in OS design and implementation for 2 decades, but really, that is no argument, nor is you having been into realtime stuff for whatever time.
Then, realtime class != realtime priority. Priority of realtime class processes in handled differently, but is not exactly higher.
I've used UNIX systems with realtime priority. It doesn't make a difference to interactive response time. It's a great way to lock up the system when a realtime process goes into an infinite loop and becomes a compute-bound process, though.
And it still will allow decent interactive use on an OS/2 system.
I can EASILY believe that OS/2 is doing a better job of handling I/O. That's been a problem with the traditional UNIX monolithic kernel as long as I've used it, but that's got nothing to do with how many CPU-bound processes are sitting there competing with the interactive one.
OS/2 has a monolithic kernel as well, that has nothign to do with this whatsoever.
The thing that has everything to do with this is deciding which of the processes that is runnable at a given moment gets time. As said before, a realtime class (not priority!!) process can go into an infinite loop and still not prevent an interactive process from being responsive.
As long as 30ms latency is acceptable, OS/2 is uable for realtime purposes, it GUARANTEES that latency, Unix does not give any such guarantee (tho modern implementations have gotten a lot better at it)
At one point around 1990 I was 2 of the top 3 posters on Usenet. My first posts date back to the early '80s. I'm real familiar with ">"-quoting, and if we were using trn with an 80x24 screen with all the lines wrapped on input, that would work nicely. But ">"-quoting doesn't work worth a damn in an environment where you're NOT using a TTY type display.
Well, I have no problem with it in a browser either, but since you are the one having to read what I type and have trouble with it, I'll do as you suggest.
You do know of course that bash forks and execs for each external command (like ls) and internal commands frequently involve disk I/O as well. In addition, CD burning... particularly on older burners... is a real-time process and good burning software is going to run at an elevated priority... it's more important than the user interface. So you're mixing up CPU, disk, and a high priority background task. Separating the impact of the scheduler out of that is going to be a big problem.
Bash has internal commands as well of course. Also, OS/2 does not suffer from similar inresponsiveness in similar conditions.
OS/2 puts things requiring realtime priority in a seperate priority class, they are not 'higher' in priority but they are treated differently to ensure they get their timeslices when needed still.
Basicly, OS/2 has 4 priority classes, each with a number of priority levels (32 if I remember correctly, but this is some time ago).
How dynamic priority works out depends on the class you are in.
What sort of serial port, what was the UART? 8250, 16540, 16550? Was the Solaris driver smart enough to use the 16-byte queue in the latter case, or was it taking an intterupt for every character? Again, you're combining all kinds of things that have nothing to do with scheduling.
16550AFN, 16byte fifo,
Using a 8250 just makes the problem more prominent.
And no, I am not mixing up things here. How the system handles interupts, realtime tasks, user tasks, and gives all of them timeslices at the moment they need it has all to do with priority management and your scheduler. That a 8250 generates a lot more interupts then a 16550 is true of course but it applies to both systems (unless of course a system doesn't support the fifo)
You can do a similar experiment with for example formatting a floppy in the background.
You are right that there are a lot of aspects to this, but in the end, it is still a matter of how the system distributes time over the processes that are running (or threads in case of OS/2) which is still the task of priority management and the scheduler, and giving the guarantee of a context switch and rescheduling of tasks within a given time (30ms in case of OS/2 with a default configuration, this is tunable by the user)
Resource congestion? sre, that is the problem we are talkign about, just that the CPU is yet another congested resource.
> Could you, like, indent or italicise the stuff you're quoting?
I use the decades old quoting convention from usenet, email etc before there were things like html. Any line starting with a > is quoted text.
> I've seen interactive character mode applications become unresponsive in those circumstances, but I can't see how that could possibly have anything to do with the scheduler.
Well, the contested resource was of course the CPU, no swapping/paging.
Example, bash accepting user input, becomming slgightly sluggish because of cd writing software running in the 'background'. The CD writing software did try claiming 100% cpu time, and most likely also used some other resources. I could also go back ot the 486 that I used to run OS/2 on and still run Solaris on. OS/2 had no problem with keeping a serial link at 57600bps running reliably without any noticable impact on a foreground shell, SOlaris on the same hardware doesn't, anything above 19k2 for the comms app becomes noticable for the foreground app.
> So in OS/2 if your foreground program opened a file and that blocked for half a second because it was on a network file share and competing with the porn traffic, then the GUI as a whole was also blocked until that application responded to a message? What if the app was blocked for a minute? Did the whole thing lock up for a minute?
You got it. FOr a nice example of this, try Lotus 123g for OS/2.
> I find this hard to believe. Did you test this on the same hardware? What version of UNIX were you using? Because I have been using UNIX for a quarter of a century and I can not recall ever finding myself in a situation where a character based interactive application that wasn't blocked on other I/O was effected by any number of background CPU-intensive apps. Ever. Even when the load average is up in the double digits, when there are dozens of programs competing for the run queue, interactive applications autmatically and invisibly get priority.
Hrm, I saw this fail on Sun 68k, sparc and hypersparc hardware, and on x86 hardware, Irix on R3000, R4000, R5000, FreeBSD, NetBSD and Linux on a huge variety of x86 hardware (from 386dx to p4 xeon), AIX on a whole variety of RS/6000 machines, HPUX on HPPA and some more. My experience with Unix like systems is some 5 years shorter then yours, but I doubt it is less extensive.
I only ever ran OS/2 on 386, 486 and classic Pentium machines, and I only ran Solaris (upto 2.6), Linux (upto 2.4) and FreeBSD (upto 4.2) on the same hardware, so direct comparison I can only make between those systems.
> Actually, a single event queue feeding a single event loop is a very common technique used in real-time control systems, because as long as you can control the latency for each operation you have complete control of the latency for the system as a whole. Having a single queue that imposes virtually no latency of its own is still going to give you a more responsive user interface than multiple queues that deliberately impose latency to increase throughput.
Of course, and for a very well controlled realtime system this works really well. For a general purpose GUI you cannot control the latency of whatever application the user decides to run, so there it really does not work too well.
> And what exactly are you saying about OS/2 in CHARACTER MODE and UNIX in CHARACTER MODE? I want to be certain here, because way back in this thread I said that the differences between OS/2 scheduler and the UNIX scheduler weren't fundamentally important for graphical user interfaces, and both were doing about the same thing, and you just accused me of saying the UNIX scheduler did better than OS/2. Which isn't something I've said, or attempted to imply... and if I inadvertently confused you, I apologise.
What I am trying to point out here is that the difference in responsiveness between the 2 stays even when you eliminate the GUI completely. The very simple conclusion is that the GUI may contribute but is not the sole, and not even the primary reason for this difference.
>> that mouse pointer is almost completely handled in hardware, and you do still get interupts
> The mouse pointer isn't controlled from an interrupt, it's crontrolled by Intuition, from an ordinary Amiga Exec task.
I somehow recall this running during vertical retrace, but I may confuse this with the code that handled the pointer in Geos. Regardless, movimng around a hardware mouse pointer is so extremely simple and non intensive for the cpu that any OS that provides some form of preemptive multitasking should be able to handle it without much of a problem, esp. when you can get away by only updating the position between 12.5 and 15 times/sec.
> And with a modern accelerated video card, the mouse is almost completely handled in hardware too.
Yes, and on such a card I have yet to see a mouse pointer become jumpy as a response to high system load, Windows, X11, OS/2 PM make little difference there as long as they do indeed support the hardware pointer also.
> So if the fine details of the scheduler was that important to maintaining the GUI's responsive behaviour, the simplistic scheduler on the Amiga should have been a major drawback. Right?
No, wrong. try to actually click on something while your Amiga is heavily loaded and see if you get a response.
While smooth movement of a software generated mouse pointer gives an indication, movement of a hardware mouse pointer gives very little indication of how responsive a system stays under load.
My original claim was that the OS/2 scheduler and priority management do a better job at keeping the system responsive then a typical Unix scheduler and priority management. This is very clear when using a GUI, and many people (including you) seem to attribte this to the GUI.
A GUI that employs a single, synchronous message queue for events between the GUI and applications is really not a good way to achieve responsiveness at all, and it is definitely not the reason for OS/2s responsiveness, if anything, it is a problem.
> Well, yeh, of course they did. They have to tell you that all their design decisions are great and why they made them. Every major piece of software has lots of very smart people writing lots of copy about why they did the things they did. They're not always right.
Of course they are not always right, I never said so. I just pointed you at the fact that many things have been said about why exactkly the scheduler and priority management of OS/2 was better, you can ignore that and just keep pushing your own little love for Unix.
You can disagree with what people say, fine, give soem reason, provide some argument, maybe point at an argument already made by someone else. Just dismissing what is being said with 'people say so much' is not going to help being convincing here.
> You do see the same thing on UNIX for non-GUI applications. Interactive applications are responsive no matter what the CPU load is, so long as the memory load doesn't get so high they're deferred by swapping or excessive paging. Unless you're talking about like that, or you're seeing the behaviour of the GUI around the character mode application (you know, right, that when you run a character application inside an X-term the user interface is still handled by the X11 GUI), you're just plain wrong there. The responsiveness of UNIX character-based applications under excessive CPU loading is phenomenally good. Legendary, even.
You just go try running anything interactively (and I mean something character based, running in a full screebn console in native character mode, so no X11, no graphics mode WHATSOEVER) on a machine with a load of 20 and without overcommiting memory. I have had that situation on Linux, FreeBSD, Solaris, AIX, HPUX, IRIX, ULTRIX, and ALL of them perform a lot worse under such conditions then OS/2 does with similar load and a VIO app in the foreground. If you don't believe it, please go try it.
So X11 may add to the problem, but without any trace whatsoever of X11, the problem is still there.
Unix does a lot better in this then any Windows version, sure, but it did not, and still doesn't do better then OS/2 in this.
Just to make sure, I am comparing OS/2 in CHARACTER mode, NO GUI running whatsoever, with Unix in CHARACTER mode, so again, NO GUI whatsoever. Please make an argument that does in no way involve X11 can you?
As a small sidenote, I actually have seen large parts of the code of presentation manager from OS/2 as it was in 1.2, 1.3 and 2.0 (I am a former OS/2 developer), adn I can assure you that it is in no way responsible for the high responsiveness, rather, it was one of the major obstacles to achieving responsiveness.
So even while your claim about X11 and inefficiency may be true, its not relevant.
Then, with regards to the Amiga, it is extremely easy to slow it down ot crawling speed and yet have a smooth mouse pointer.. easy becaus that mouse pointer is almost completely handled in hardware, and you do still get interupts. All it takes from there is changing 2 registers.
> When I started using UNIX back around '78 it had already been doing that kind of priority juggling for so long that you just assumed it was there.
When IBM and MS introduced OS/2 in the late 80s, they also filled quite a few pages about why the OS/2 scheduler does really a much better job at those things. They did a much better job at explaining it then I can do, but I have seen enough of both to see that even when it may look like trivial differences, they are in fact a very relevant.
> No, really, it's not the scheduler. Juggling priorities so that interactive tasks get priority over compute bound ones is precambrian. It's not what makes OS/2 and other operating systems that provide good interactive response what they are. Do you want to know what it is? It's the whole GUI design. It's recognising that a GUI is a real-time environment, one in which the time a result is generated is part of whether the result is correct or not. It's taking advantage of the fact that the display is computationally close to the user. It's all kinds of things.
Yeah sure, that is why you see the exact thing for non GUI (ie, character based) applications.
> THAT is why now that you have a 2 GHz 64-bit processor and a graphics card that by itself has more CPU power than the whole of Project Athena at MIT did... that is why you can have all that and when things get busy it gets delayed.
The differences between the design of X11 and OS/2 are so profound that they utterly swamp trivia like a slightly different scheduling algorithm.
Its by far not the only thing that matters, putting some limits on how long a task can spend in the kernel while blocking the rest of the system helps as well for example.
OS/2s GUI is definitely not a well designed one, especially its single message queue is a problemn both for responsiveness and stability. X actually does a much better job there.
As mentioned before, the same kind of difference can be seen when you eliminate the GUI on both Unix and OS/2, so sorry, your story about how this is all the gui is simply not true.
> I doubt that what you're seeing has anything to do with process priorities or scheduler design. The unfortunate design decisions that have produced the kinds of glitches you see in the current X-based desktop environment are buried much deeper and are harder to fix than simply tweaking the scheduler.
Its not simply tweaking the scheduler and priorities, its a different design of scheduler and priority management, and indeed one that does a better job at giving the user a nice smooth experience.
2 factors in this were dynamic priority boosting (a runnable task that had been 'starved' for too long would get its priority boosted untill it became high enough for it to get a timeslice) and the notion of foreground/interactive tasks versus background/non interactive tasks. The interactiveness was not just about the 'nature' of the application, it was more about if it was the one currently having the user focus.
Together with a rather short context switching time, this helped provide a good starting point for a nice responsive system.
Go get yourself a C64 technical reference from e-bay or such, it contains a complete (assembler) source listing with comments of its kernal (yeah, thats how Commodore called it) and at elast part of the basic interpreter ;)
> So from the perspective of IBM there would be the advantage of getting somebody outside look into the code and fix bugs.
Is this really an advantage to them?
They decided somewhere in the last decade that service was their thing, fixing bugs for a product tat is beyond its official end of life is not always easy, but it is well payed for service, which for quite some time has been IBM's main business.
As long as enough customers exist that pay them for maintaining it, there is no business sense whatsoever in opensourcing it.
> Actually, no. IBM really did all they could do. But until the late 90s, they had to pay $86 to MS for every copy of OS/2 sold (part of the licensing agreement for HPFS).
Ah yes, thats why we (was working at IBM, doing OS/2 support and some development) got told that marketing effords aimed at the consumer were to be stopped inmediately, the day before WIndows 95 became generally available..
No, they didn't try as hard as they could, they gave up before even having tried.
> OS/2 V1.0 was a MS product, infact 1.1 may have been MS also.
Both 1.0 and 1.1 were made and sold by MS and IBM. Microsofts involvement declined after that, but they did also at least release 1.2. I am not sure about 1.3, tho I am very shure they could have released it at the time with the agreements as they were.
A part of OS/2's code, and quite a bit of its design can be found back in NT, and earlier NT versions had enoufh OS/2 in them to be able to run many character based (VIO) OS/2 applications.
How do I know? I was part of IBM's OS/2 development efford from 1989 till 1996.
> It was not until 1.2 that it was IBM only. MS and IBM had a falling out and they each took the existing code from 1.1 and went their own merry way. MS wanted to keep "Windows" alive, so IBM got the OS/2 name. Although I never saw this, I have been told that the early releases of Windows NT actually had OS/2 in the error messages.
Microsoft did distribute OS/2 commercially upto version 1.2 or 1.3. Both as a standalone product, and together with MS Lan Manager.
They never commercially sold a 32bit version however.
> And FreeBSD is lacking in Systrace support which is by far a better option than just jailing processes.
Systrace is way cool, and an extremely usefull tool.
It provides granularity way beyond what a FreeBSD jail does (tho with MAC you get quite a bit closer, but following a different idea)
Systreace has one big disadvantage, it is so flexible that it requires quite a bit of thought to configure it correctly, and it requires indeth knowledge of both the application and the operating system.
Better for specific situations? definitely. Better as a general purpose security measure? I doubt it is for the average administrator, it requires too much configuration and knowledge for this.
When having a choice between slightly more complexity in code, or more complexity in configuration, I prefer the first. Code is written once by supposedly knowledgable people, it can be fixed if needed. Configurations are in the end made by humans, many different ones for that. The chances of mistakes there are a lot bigger, and are in the end more difficult to find and are managed by less knowledgale people.
> This is pretty nonsensical. You make it sound like a chroot is something you can just break-out of. Once a program has chrooted itself, and dropped privlidges, it's locked there. No attacker is going to be breaking-out of the cheroot and getting access to the rest of your system. Jail doesn't provide any extra security there.
That depends a lot on what is in your chroot and how much you can trust it.
> Besides, as I said above, OpenBSD comes with systrace, which FreeBSD does not. Systrace is far better than even jailing your processes.
And requires way more work on the administrator side to be done correctly, introducing a bigger chance on mistakes, not to mention the cost in te form of time.
> Not to mention that OpenBSD has propolice, W^X, and the other protections that make your system even more secure, that FreeBSD is lacking.
propolice and W^X are usefull, no doubt.
What made me write my original post, and now reply to yours, is the notion among certain people that OpenBSD cares about security and noone else does. That OpenBSD is the only one to have usefull features for this. Well, when looking purely from a coding point of view, OpenBSD has a very good featureset. When looking from a more practical point of view, building a functional system that is secure and maintainable, then it is not always the best choice, and in practise it often is not in my experience.
Just so you know, I run Open, Net and FreeBSD (and some Linux variations), and I will use OpenBSD when appropriate, but I don't find it appropriate for quite a few situations.
> No problem, in fact Apache ran in chroot by default, as of OpenBSD 3.2, Nov 1st 2002. named chroot by default, as of OpenBSD 2.4, Dec 1st 1998 and smtpd was default chroot at least in 2000.
Systems like FreeBSD and SOlaris (at least on specific hardware) allow for going quite a bit beyond a chroot. Please look into it soemtime, the differences go beyond what I can explain in a single post, and the ways you can use it to make somewhat more complex configurations work with a high level of security is something you can fill a few books with.
Just to be clear, what I am talking about is NOT just a chroot. The lack of this more then anything makes me often chose something else then OpenBSD.
You can just keep ignoring this and point at all good OpenBSD features, well, we agreed quite a few posts ago about their attitude and featureset.
>
OpenBSD is an excellent choice as long as it at least can be configured to meet all needs. Obviously if it can't currently support a need then it must be overlooked.
Maybe it is just me, but I end up very often eneding things (one thing in particular, see above) that OpenBSD does not supply.
More recently I have found myself ending up using more and more SMP hardware, and while OpenBSD has become a valid option now on that in some cases, it is far from what I end up needing most often, for exactly that thing, an internet facing machine running some mix of services.
> But this is a far cry from overlooking it just if the default configuration does not meet the needs. It's not like the default install is as functional as it gets. We all know that OpenBSD is quite the opposite.
Yes, and this is why I do use it, and also consider it a very good system for learning about this and for building single purpose dedicated machines for example (ie, appliances)
I somewhere promised to come back on a patent relating to using xor for displaying a cursor, this concerns patent #4,197,590, its from Cadtrak and not from Microsoft as I thought. Google for it and you will find more discussions about why it should or should not have been issued, enough has been said about it I think.
Then, for your reference, I have tried to write up a bit on why the whole concept of patents when applied to software feels seems rather alien for someone involved in software development.
What it comes down to is that a general purpose computer is just that, an aperatus that can perform any function within its physical limitations, based on instructions provided to it in a form it can read.
The creation of the sequence of instructions is where the actual investment takes place, and this is already 'protected' by copyright. Algorithms in this function in a way very similar to mathematics and should be treated as such, they are the basic building blocks for software and are usually discovered and not so much invented. What is invented at times is new systems that make algorithms possible that were previously only theoretical, and I think those can be subject to patents.
At any rate, when someone tries the effect of the typical working of some tool (using a general purpose programmable device to run a program) to solve a new problem, when there is a likelyhood that the tool will affect the problem, and where it is possible to test many variations for outcome without much efford (a consequence of the general purpose nature of a general purpose programmable device) then that should be enough motivation already to try and as a result make for obviousness (given that the way the tool (computer) is used in itself was known beforehand, pssibly without use of the specific tool (general purpose programmable device))
The crux here is that the aperatus is the general purpose programmable device, and not so much a combination of that and a program. The general purpose programmable device makes it possible to go from blueprint (well, something written in some formalized lamguage to be exact) to the final result virtually without efford, and eliminates the need for building a specific device, this was invented with the invention of the general purpose programmable device, and has been known fact ever since.
That someone could have initially patented the running of a program on a programmable device as a means of solving problems without having to build a specific machine for each problem is another matter, and probably someone did (I recall a limited version of this happening in France somewhere in the late 1700s or early 1800s with regards to machines used for weaving paterns and the use of punch cards)
Ok, then my understanding seems to be right (tho I probably lack detail).
I find it somewhat interesting still that proving obviousness more or less comes down to proving prior art. I can understand why 'easy to understand' can't work because many things are easy to udnerstand with hindsight, yet untill someone thinks of it, they were not easy to come up with, hence non obvious. If something is mere replication of a known technique on a new medium, then I believe that a patent should very well describe why it is non obvious because it most likely is obvious to someone skilled in the art.
If obvious does not have a meaning that is anywhere related to obvious as I just described, then the 'skilled in the art' part really makes little sense. I would argue that what was intended by the law is closer to what I describe here then what for as far as I understand the current legal definition is.
Then an entirely different question regarding the validity of software patents (and actually, patents in general)
According to my understanding, the constitution granted congress the right to make laws that allow for patents to encourage usefull inventions.
There seems to also be a notion that economic monopolies are something to be carefull with, and should not be encouraged unless they serve a purpose. For what I know they are not illegal as long as not abused.
I believe that over time courts have roughly enforced what I wrote there about monopolies.
A laymen would reason that as a result, patents should only be granted when they do indeed have a very high likelyness of encouraging usefull inventions.
What is more, I would claim that that is the exact intention of what is written in the constitution as well as patent law.
How can it have happened that this got changed into patents getting granted unless they are very obviously (dictionary definition) invalid or someone with enough money to do so fights the less obviously invalid ones in court? This result seems to contradict at least a laymans reading of the constitution and law.
(It should be noted that software developed for most of the time without enforcable patents, and you will have a very difficult time finding people who will say it developed slowly during that time, rather, it developed as fast as hardware and human understanding did allow, so making an argument that patents are needed to encourage invemntion here seem to rather be disqualified by the real world)
I realize above is quite simplified, and may lack detail, but I assume the line of thought is clear.
> By those general duties, I am refering to the usual suspects: DNS, FTP, HTTP, POP3, SMTP, etc. W^X, Propolice and Stackghost tackle some pretty generic security problems which can plague these services and are responsible for a large percentage of successful attacks. However these are not the only services that OpenBSD supports and the active security mechanisms work regardless of the application being protected.
Absolutely, and those features are extremely usefull to tackle specific classes of attacks.
Quite a few security breaches result from simple misconfigurations, and none of the mentioned mechanisms does much to prevent those while of course they do help prevent exploitation of a whole bunch of possible bugs that can result in privilege escalation, so there is a level of containment there.
For services like a public dns, smtp and in many cases http, I prefer being able to seperate those from the host environment so that even in case of a local root compromise, the effect is still contained within an environment specifically built for that one service.
This takes more efford and isn't entirely out of the box, so no argument about that.
For many a situation I found having to put in quite a bit of efford to make things secure and functionally what is desired (I have yet to find the customer who only needs a basic apache and smtp server), so a little extra efford while setting things up is not too much of a problem, esp. when it saves efford for maintenance later on.
Ideally, you'd have all the openbsd security mechanisms together with what I just described and something like mandatory access control (having acl support makes live a lot easier and safer when running samba on an internal server for example)
As long as we can't have that, I'll have to make a choice, and I believe that choice is not as straightforward untill most peope only actually need a default install.
> Please ask the Sinclair people, and then get back to me. Media Matters is bringing these issues, which otherwise few people would know about, to a public forum.
A long time ago someone said soemthing along the lines of 'I may not agree with your point of view, but I will defend your right to state it with my life'. Where did those days go?
What you wree just doing is following the following simplistic reasoning:
"They are wrong so I can be wrong."
Well, 2 wrongs don't make a right, and the ONLY valid defense against such propaganda is uncovering and publishing the truth (which is incidentely what MM seems to eb trying to do).
You are of course entitled to your own opinion, but I really suggest you go look at countries like France or Germany to get a bit of a clue what the consequences of your rather misguided ideas are when applied to political speach.
> The spectrum is limited. The spectrum belongs to the people. The spectrum is licensed temporarily to broadcasters for use in the public interest. Anyone acting outside the public interest is subject to having their license revoked.
I doubt there is much disagreement about that aspect.
What you seem to have a lot of trouble understanding is that the broadcasting of opposing views, and even the broadcasting of provocative lies is in the public interest. It provokes thought and discussion, and that gets you a better informed public in the end.
As soon as you start deciding what should be broadcasted based on if you like the point of view (or just whatever is beign said/shown) then you are no longer serving the public interest, you are only serving your own political point of view and those who happen to agree with it.
Living in a democracy is difficult because choice is difficult and having to accept that not everyone agrees is difficult. If you forgo the later 2, you can forget about the first one.
> Predictable, will the next point release break our stuff or not?
Which is still better then 'Will the next fix to the current version break our stuff or not?' (XP SP2 comes to mind)
> OS X is no more BSD than Windows 98 was MS-DOS.
Hahahhaa hahaha
I wonder if you realize how true that one is.. it refutes the remainder of your post tho.
> It takes more code to conditionally load drivers. It takes more effort to debug different kernel images.
Removingdrivers and features that you do not need does not require any code to conditionally load drivers, it requires removing them in your kernel configuration and not building and linking them.
You are jumping to the conclusion that I was talking about dynamically loading drivers, I was NOT.
> Extra drivers that aren't executed aren't a source of vulnerabilities.
The potential to call code in those drivers exists so yes, they can be a potential source of vulnerabilities.
> But it seems to have the highest strength for general internet facing duties and is beyond taking another BSD and just adding a little extra effort to security.
And this is exactly where we seem to disagree.
In my opinion, that is only true if what you need happens to fall within the focus of the OpenBSD team. They do a lot of good work, and if what I need happens to be within their area of focus, I will often use their work, but there are many more situations where OpenBSD simply does not offer the functrionality that I need for an internet facing machine.
In other words, they are limited in what they offer, but when they offer something they do it well.
On another note, I find it interesting how you (tho in a friendly way) get somewhat defensive as soon as someone suggests there may be other and even better solutions then OpenBSD while at the same time agreeing that it is not perfect. I don't think there is any reason for this defensiveness, noone is saying it is bad or was attacking it in any way.
> This is a single example application out of many, using a single example security mechanism out of many, which has been developed (the code, not the concept) on and primarily for OpenBSD by OpenBSD developers.
And they did a good job there as I said already. However, there are also other platforms which implement security mechanisms, and at times ones that OpenBSD does not have. Often those are Kernel level mechanisms that go beyond the basic Unix concept.
At any rate, as I have said elsewhere already, if I were to build a router or small webserver, OpenBSD would definitely be one of my first choices, and idem for a shell server that is used for remote maintenance for example.
If it were to include smtp support (not unthinkable on a home/small office router/gateway) or something like an smb or nfs server (not very likely on a router), I may find I have a need for things like mandatory access control and the ability to seperate the environment a service runs in beyond what a chroot can do.
> My previous statement, "Yes but priv sep requires code changes for each privilege seperated application. Some apps are particularly difficult to do this with, like ssh.", does not refute that.
I never said that it was easy or that anyone else did this or anything that intended to refute that this was difficult or whatever. I pointed out that you will find openssh with privilege seperation on virtually any modern unix and at least freebsd and many a linux distribution. Thanks to Theo and his people? definitely. Kudos to them. Exclusive to OpenBSD? Not at all, and that was my only point there.
> My original point, is that they roll out many security mechanisms and this is just one of them.
Which I never even tried to refute, I just pointed out that most of those mechanisms are not exclusive to OpenBSD (tho they may get them first)and that there are also security mechanisms out there that OpenBSD does not implement. That does in no way mean that I deny their focus on security, but it means that that is not something they are alone in.
In short, while very secure, OpenBSD is by far not the only OS allowing you to build a very secure system, at times it may be the better choice, at other times it may not.