And I skype people... I do not have MSN and I never had a reason to change that since none of the people I want to keep contact with over the net uses it anyway.
Google I do use a few times a day.
Point is that google made it into dictionaries by now, and afaik MSN did not. That should say a lot more about how much it is used and how long that has been the case already then the experience of a single user (being it you or me).
Sorry the place M$ made its money was in the Corporate BoardRoom -- Talking the C*O's into to drinking the koolaid. Google will have a hard time getting the consistent flow of revenue without corporate accounts. Cash Flow improves revenue projections, which improves valuation, which encourages re-investment -- which keeps the cool stuff coming.
I see you did pickup something about running a business, but it also seems you did not understand a thing about the text you just reproduced, nor do you seem to understand much about Microsoft and their market, for that matter, you don't seem to understand much about this concept called market, so lets start there:
When you are trying to make some money by selling some product, you will have to find potential customers and turn them into actual customers.
The whole group of potential customers are your 'market' and you'll hav eto find and address themone way or another in order for them to know about you and your product.
Now, if your market consists of large corporations, then the boardrooms you were talking about might be the right place to be.
If your market is the general public, then those boardrooms are not likely to get you any customers (they may get you other things like alliances with other companies maybe)
Microsoft did a very good job, using its former alliance with IBM, in getting one of its products in almost every large corporation. This was not achieved in the boardrooms of those corporations however, it was achieved by a strategic alliance wiht one big corporation.
A huge factor in this is also that since many people got an IBM PC (clone, but still called IBM PC at the time by many), a company that was about to make a choice for some kind of computer system could save itself quite a bit on training by picking a system that many people knew already.
Only after those things were in place, boardroom talk was needed to maintain the status quo, and with each incarnation of the MS system, they managed to make it more expensive for corporations to change to another system so that the insentive to change is only there with people who have to look further into the future then just the next 1 or 2 years (only those people will get to see the real cost of this choice)
I just wonder, how much experience do you have with systems like viavoice and dragon dictate and the like?
Notable about his wrongness wasn't the "missed" prediction, in my opinion, it was how off-the-mark his vision was -- a vision easily and with little intuition would have predicted no PC/speech interaction, even if the technology completely stepped up to it (it didn't).
Hrm, I have been using a speech interface for some of my computers for almost 15 years now. About a decade ago, such speech interfaces still required special hardware, but had become very usable for things like controlling the system and dictating mail and other text.
Around that same time, the first systems started appearing that could do those things without special hardware, and within a few years (talking 1996-98), the requirement for special hardware had dissapeared completely.
What did stay was the need for training the system in order to reliably dictate text (usually not needed for system control since it uses a much much smaller vocabulary)
So, in 1999 BG has this keynote speech, and while his prediction was not very realistic for many reasons, it was quite feasable technically back then, and is even more feasable today. You will find it is being deployed very succesfully )and has been for the last decade) for medics and lawyers and some other groups of users, all of which happen to have somewhat specific use paterns, and have a need to keep their hands free and/or a need to produce text faster then their typing skills would allow. Dictating to a voice recorder and having a typist type it out is a viable alternative at times, but not always.
If Microsoft wins the search engine market, our search engines will be cluttered with ad upon ad and suck up amazing amounts of bandwidth.
And will favor IIS servers over Apache, and will support IE better then anything else (if it supports another browser at all) and requires activeX and requires a seperate desktop application )yeah, nonsense, but if thats what it takes to exclude others...)
A bit over the top_ I bet. But the above (and parent post) do contain more then a bit of truth wrt what MS would do.
Given that internet search/indexing is a commodity Google will have a hard time sustaining any profitability in the long term.
Spidering and indexing might be considered comodities, catagorizing is not, at least judging from the difference in qualitz of results between the different engines.
Also, I do not remember Google (or any other search engine) asking me for money in order to get search results, so I somehow suspect Google doesn't earn its money from just being a search engine. Search technology is extremely important for them of course, and is the backbone of their enterprise, but its services on top of searching that is what the game is about.
Seems that a country that mandated such things (and had this lets feed the people first before we get into this TV for everyone thing) is doing pretty well economically at least.
What I meant is that it opens up the possibility of licensing, where it did not exist before. That means that it reduces the "reinventing the wheel" problem.
Patents also prevents you from using what you invented independently when someone else happens to have invented the same thing just before you.
Obviously, licensing is not always the most profitable option, but it would never be without IP.
No, it wouldn't be an option indeed, but 'reverse engineering' and using the 'invention' would be, while right now it is not.
You should really look a bit more at both sides of this patent issue.
If it ever happens, yes... but so far it's just a message on a bulletin board. Implementing the JVM itself is no trivial task,
it is indeed far from trivial, tho it does not need to be as complex as SUN made it.
and would take years to reach the performance and stability of Sun's JVM even with huge resources.
There are 2 issues here:
You don't have to achieve that level of 'quality' on the short term, it has to be 'good enough'. There are many examles where 'good enough' software is extremely succesfull despite there being equivalent software that has a much higher level of quality.
This same assumption was held by people developing operating systems. They have been proven wrong repeatedly. A tiny group of individuals with the right mindset and enough of a clue about what they are doing, can develop usable versions of such a system in an amazingly short time.
They have chosen their own unique architecture so I don't think code reuse is in their plan.
Luckily not.. Sun's JVM may be stable, but it is also overly complex and a serious resource hog in many cases.
IBM may or may not do development on their own on the product as well, but very importantly service contracts are paid up front - they get the money whether their own engineers do the fix or if their own engineers just take a fix that was done in Open Source by somebody else, run it through QA and then put it in an IBM servicepack.
Well, I do not know the exact terms and conditions for current OS/2 service contracts, but I do know what is usually in there for a product that is past its end of life, like it is the case with OS/2.
In general, it means you will get the service packs if/when they are made and get conditions for getting your own specific problems fixed. The later is not payed upfront. (if this product was not yet past its 'end of life', then such fixes are on IBM's expense, but in this case they are not)
I understand perfecly well what you are saying, but I am trying to tell you that in this specific case, your reasoning does not work because the customer does pay a price for each specific fix that they need and that is not there yet. Making the fix generates direct income in this case.
It is not a difference of understanding between us 2 about what a service contract is, it is you not taking into account what it is to have a service contract with IBM on a product that is past its end of life.
> That depends on what the release schedules are for these things.
I don't think you understood what I am saying. IBM gas serv8ice contracts with those customers, and gets payed for doign this development. Leaving it to others means less income for them.
I don't believe I'll see it for a purely CLI environment, because there's not enough latency even under massive load for me to notice in a purely CLI environment even on machines a hundred times slower than what I'm using today.
Not having an idea what you are using now, but its hard to make a relatively modern machine running a UNIX with for example a 4BSD scheduler lag due to the scheduler under heavy load, other then by having an insane number of processes.
Going back to say a 386 or 486 based machine may allow you to observe lag under heavy load on a CLI.
Huge number of processes makes schedulers like the 4BSD one very inefficient, and it is for example not very good at making good use of multiple (possibly virtual) CPUs. (ULE is better but far from perfect at the later for now)
But under X11? I can't say I'm sure enough to rule it out. I haven't seen it before, but I could be wrong. Tell me, is this huge, or is it something I have to measure?
The difference under most conditions on a modern desktop are not huge for what I can tell, and may not even be observable depending on what kind of machine you have. 'Fixing' latency with raw power is a kinda well known approach, but doesn't even start to address the underlying differences between implementations, let alone answer which one is more effective.
On SMP systems and/or when running a huge number of processes, the difference may be easier to observe.
That's only a metaphor, yes, but that's the same kind of experience as the one I'm having right now.
Well, it is an interesting one, and I can see your point of view.
To make a counter metaphor, to me it feels like you are arguing that since English (with a bit of variation here and there) is spoken in the UK, USA, Australia and many other places over the world, we should just regard them as similar countries.
And that's a really cool thing to be able to do, and you need a UNIX-like operating system to do it. Trust me, do that anywhere you please on VMS and you're going to end up in a world of hurt eventually. I've done that.
And I have seen the same kind of problems on OS/2 and NT, where you get this nice thing of applications being made aware of changes to files without the need of something like FAM, and where using a file (read or write) locks it and prevents other processes from changing it while you work with it (something that can be done on UNIX like systems, but is not automatic there).
Lets not forget that in UNIX a file is in fact not represented by a name, that name is merely an index pointing to the file. It is represented usually by an inode. OS/2 nor NT have this concept.
Try removing a file that is being used, and see how UNIX like systems keep the inode (ror similar in case of say XFS filesystems) around untill you stop using it, whereas OS/2 and NT will refuse removing the file and give an error.
There are many assumptions that you can make about the behavior of a 'UNIX like' system that will simply break on both OS/2 and NT and those are not far fetched things, they are extremely common things
Are they more like UNIX then VMS is? probably, alltho people have made a very strong argument for NT being a VMS like system.
So, let me say this, without any intent to ignore the value of OS/2, or OS/2's scheduler, or your experience. And that is... you could go into Linux or Solaris or whatever traditional UNIX kernel you're talking about and completely fix everything that's wrong about the scheduler, give it a real-time scheduler, or the OS/2 scheduler, or a magic scheduler that ALWAYS picks the process to run next that will provide the absolutely most responsive user interface while never deferring any other critical processes... and every single one of the shortcomings in the behaviour of interactive tasks would still be there.
Definitely, simply because it is not the only problem.
That's what I mean when I say the scheduler doesn't matter, that the UNIX scheduler is pretty close to good enough, it's because the scheduler just isn't responsible for enough of the system in a traditional UNIX kernel for it to be responsible for the problems.
And that is where we disagree. You can fix all the other problems in a traditional UNIX kernel, and still have a system that is not being responsive when ignoring the scheduler and priority management (note that I have from the start been talking about those 2, and also pointed at that they are not the only problem, but are a substantial part of the problem)
If you really want some proof of how much it matters, I suggest you install a FreeBSD -current snapshot, and then build 2 kernels, one with the 4BSD scheduler and one with the ULE scheduler, and just go measure the difference in responsiveness yourself.
A synchronous event loop causes other problems, but it doesn't add latency that doesn't exist in the underlying programs. A message queue that deliberately buffers and defers operations so it can bundle them to improve throughput does.
It makes responsiveness depend on well behavedness of applications, but you are right that as long as applications are well behaved, this indeed causes lower latency (this has always been IBM's argument against implementing multiple message queues)
And adding latency to a user interface, even if it's just a little, makes it feel less responsive. Even if your traditional UNIX and OS/2 systems had the same scheduler, the OS/2 GUI would feel more responsive than the X11 one.
As I have pointed out quite a few times in this discussion, the responsiveness differences remain even when eliminating the GUI completely on both systems. Would you please stop ignoring that?
I haven't explained the distinction I'm making well enough, because if I had you wouldn't have drawn such a broad analogy. I apologise for that. Still, there's the beginnings of a useful analogy there... so let me run with it.
I think my point was that when you only (or mostly) look at similarities, you can see things as being alike, while they do have differences that are so relevant that when looking at the bigger picture and take into account the differences, they are not alike.
NT, OS/2, UNIX and quite a few other systems are similar, and more similar to eachother then they are to say OS/390, VMS and such.
Yet, NT as well as OS/2 behave more like DOS then UNIX in many aspects. I would not call them DOS like operating systems hwever because the differences between them and DOS are more relevant then the similarities.
Calling OS/2 an NT like system? I can see the point of that.
Saying that OS/2, NT and UNIX are all part of a group of similar operating systems? I can see the point of that.
Calling OS/2 and NT UNIX like? well, in case of NT you can make an argument since it at least officially is supposed to be posix complient, OS/2 is not, and as a result doesn't even try to implement a similar interface, it just happens to share some functionality and implements certain things in a similar way.
I made the overly broad analogy exactly because I consider you calling them UNIX like system to be overly broad.
Computer games where you interact with the game via a screen and a joystick is not what I would consider VR. I would consider VR to be something that totally immerses all of the senses of touch, sight and sound into an artificial world, including some kind of feedback technology to produce touch sensations, so it seems you really are inside of that world, not just watching it on a screen.
Hrm, flight simulator with 3d projection (using 3d glasses), force feedback joystick and suround sound... that seems to match quite what you are asking for.
Racing game using a force feedback steering wheel and again 3d projection and suround sound is just another example.
Its not like this is anywhere new, have been playing games with such features (and the appropriate hardware, which is available at reasonable prices) for half a decade at least.
With today's GFX accelerators, you'd think they could take all that old hardware (data gloves, dual-screen headsets) and pump all the latest graphics through in 'true' 3D.
Hmm..
Quite a bit of the 'consumer' hardware from NVIDIA (and most likely others, but no experience with that) support stereo vision and dual screen 3d projection, and support the same type of '3d glasses' as my SGI workstation does, so that one is there.
USB has a definition for human interface devices, and other then price, there is very little reason why oen could not make and use a dataglove that way I'd think. To me it seems this is more a matter of what consumers want to pay for then anything else.
UNIX is anything that can be treated like a UNIX system. That's a functional definition of UNIX, and it's a useful definition. "Trademark UNIX" versus "genetic UNIX" versus "Linux" isn't useful because there have been systems that are "Trademark UNIX" that are less capable of being treated like a UNIX system than any version of Linux. "Trademark UNIX" and "genetic UNIX" ceased to be a useful definition of UNIX by the early '80s, because you could buy systems that were more compatible with System III (the first real AT&T commercial Trademark UNIX) than real Version 6 or Version 7 UNIX was.
Well, that way of looking at it works of course. Claiming however that systems like OS/2 or NT are 'UNIX like systems' is not. It is like claiming reptiles are dog like animals since they happen to have 4 legs, a tail, brains and such. 'X like' is defined as much by similarities as by differences, and those systems have too substantial differences when compared to UNIX to call them UNIX like. They do of course share a bunch of things with UNIX, and are more similar to it then say VMS.
Calling Linux a UNIX? hmm, we can argue about that, but I can see the argument for that claim.
Hrm, you seem to have started out by claiming it is NOT the scheduler and/or priority management but a different GUI design. I never claimed it is exclusively the scheduler or priority management, but that they play an important role in this.
I'll just say one thing about what UNIX is. UNIX is not Thompson and Ritchie's source tree, UNIX is a family of operating systems that provide a common core set of system calls as their native API. FreeBSD is UNIX. Linux is UNIX. OS/9 and QNX and Regulus are or were UNIX. Interix is a hosted UNIX.
I don't think I ever claimed Unix to be the T&R source tree. That I do not call FreeBSD a UNIX has a lot to do with what can officially be called UNIX. It is however genetically spoken a UNIX of course. Linux is a UNIX like system because it implements virtually the same API, however, it is not UNIX (both according to its maker and to those who actually can certify it as being UNIX)
OS/2 is a UNIX-like OS, so are NT and BeOS and AmigaOS and, well, you have to go back to VMS or look in an IBM dinosaur pen for something that isn't.
Your definition of UNIX and UNIX like seem to be rather loose ones, and entirely different from how those words are used by virtually everyone in the field.
Just to recapitulate:
Solaris, AIX, HPUX, IRIX and quite a few others are 'trademark' UNIX, they have passed the appropriate tests, and can officially be called UNIX.
FreeBSD, OpenBSD, NetBSD and a few others can be called 'genetic UNIX' because they derive directly from the original UNIX 'family tree'.
Linux on the other hand is a UNIX like system, it does not share a common origin with any of the above mentioned systems, but it implements a very similar set of interfaces and shares many design aspects.
While I'd agree about AmigaOS, and don't know about BeOS, I do not regard OS/2, NT and for example DOS as Unix like systems. You are right that they do share some things with Unix, but they are quite different with regards to their design and behavior for a programmer, systems administrator and an end-user. Specifically, the 'everything is a file' idea does not apply to those, redirection works entirely differently, the programming interfaces are different etc.
Similar in specific aspects? sure. UNIX like? I don't think so unless you have a very broad definition of what UNIX like means.
Wasn't a large part of that not trying due to infighting among divisions? Despite IBM's blunders in marketing, OS/2 had a hard-core fan base, and had they spun off OS/2 as a separate corp, it probably would have succeeded.
At the time (1995-96) OS/2 was marketed by a more or less independent IBM software company. IBM's PC company (doing the PC hardware) was not very cooperative indeed, but had no say about this.
> OS/2's kernel is not really similar to the traditional UNIX monolithic kernel. The original design had no kernel threads at all, let alone any way for a driver to schedule any, and virtually all traditional UNIXes (including Linux) use the same model today.
Of course they are different but both are monolithic (which has very little to do with this really). You are right of course that they are different in design in many ways, and one major difference is indeed in the area of threads. In OS/2, threads are the only things that can be scheduled. Processes own resources, but strictly spoken, they can't be executed, they have one or more threds of execution. SO in case of OS/2 it would indeed be threads competing for cpu time.
> We're not talking about processes competing against processes, we're talking about processes competing against device drivers. UNIX device drivers are not processes, tasks, or threads, and they are not scheduled, they are not handled or managed by the scheduler. The interrupt handler (lower half) triggers what's effectively a "software interrupt" that handles the longer term operations in the kernel context but doesn't normally involve a switch to a different process context. The scheduler doesn't "see" the driver at all.
Yep, but this is quite a chicken/egg problem. If your scheduler cannot handle threads (as in, use threads as the basic unit of execution, regardless of what context it is executing in) then handling interupts in a different way is not that easy. On OS/2, threads are the only unit of execution, if something runs it must be in a thread, even if that is an interupt thread. Actually, there is a Unix like system which does this in a very similar way nowadays, take a peek at FreeBSD 5.x and its interupt threads.
At any rate, you are of course right that there is more to it then just a scheduler and priority management.
Slashdot Mirror
I MSN people more than I google things.
And I skype people... I do not have MSN and I never had a reason to change that since none of the people I want to keep contact with over the net uses it anyway.
Google I do use a few times a day.
Point is that google made it into dictionaries by now, and afaik MSN did not. That should say a lot more about how much it is used and how long that has been the case already then the experience of a single user (being it you or me).
Sorry the place M$ made its money was in the Corporate BoardRoom -- Talking the C*O's into to drinking the koolaid. Google will have a hard time getting the consistent flow of revenue without corporate accounts. Cash Flow improves revenue projections, which improves valuation, which encourages re-investment -- which keeps the cool stuff coming.
I see you did pickup something about running a business, but it also seems you did not understand a thing about the text you just reproduced, nor do you seem to understand much about Microsoft and their market, for that matter, you don't seem to understand much about this concept called market, so lets start there:
When you are trying to make some money by selling some product, you will have to find potential customers and turn them into actual customers.
The whole group of potential customers are your 'market' and you'll hav eto find and address themone way or another in order for them to know about you and your product.
Now, if your market consists of large corporations, then the boardrooms you were talking about might be the right place to be.
If your market is the general public, then those boardrooms are not likely to get you any customers (they may get you other things like alliances with other companies maybe)
Microsoft did a very good job, using its former alliance with IBM, in getting one of its products in almost every large corporation. This was not achieved in the boardrooms of those corporations however, it was achieved by a strategic alliance wiht one big corporation.
A huge factor in this is also that since many people got an IBM PC (clone, but still called IBM PC at the time by many), a company that was about to make a choice for some kind of computer system could save itself quite a bit on training by picking a system that many people knew already.
Only after those things were in place, boardroom talk was needed to maintain the status quo, and with each incarnation of the MS system, they managed to make it more expensive for corporations to change to another system so that the insentive to change is only there with people who have to look further into the future then just the next 1 or 2 years (only those people will get to see the real cost of this choice)
I just wonder, how much experience do you have with systems like viavoice and dragon dictate and the like?
Notable about his wrongness wasn't the "missed" prediction, in my opinion, it was how off-the-mark his vision was -- a vision easily and with little intuition would have predicted no PC/speech interaction, even if the technology completely stepped up to it (it didn't).
Hrm, I have been using a speech interface for some of my computers for almost 15 years now. About a decade ago, such speech interfaces still required special hardware, but had become very usable for things like controlling the system and dictating mail and other text.
Around that same time, the first systems started appearing that could do those things without special hardware, and within a few years (talking 1996-98), the requirement for special hardware had dissapeared completely.
What did stay was the need for training the system in order to reliably dictate text (usually not needed for system control since it uses a much much smaller vocabulary)
So, in 1999 BG has this keynote speech, and while his prediction was not very realistic for many reasons, it was quite feasable technically back then, and is even more feasable today. You will find it is being deployed very succesfully )and has been for the last decade) for medics and lawyers and some other groups of users, all of which happen to have somewhat specific use paterns, and have a need to keep their hands free and/or a need to produce text faster then their typing skills would allow. Dictating to a voice recorder and having a typist type it out is a viable alternative at times, but not always.
If Microsoft wins the search engine market, our search engines will be cluttered with ad upon ad and suck up amazing amounts of bandwidth.
And will favor IIS servers over Apache, and will support IE better then anything else (if it supports another browser at all) and requires activeX and requires a seperate desktop application )yeah, nonsense, but if thats what it takes to exclude others...)
A bit over the top_ I bet. But the above (and parent post) do contain more then a bit of truth wrt what MS would do.
Given that internet search/indexing is a commodity Google will have a hard time sustaining any profitability in the long term.
Spidering and indexing might be considered comodities, catagorizing is not, at least judging from the difference in qualitz of results between the different engines.
Also, I do not remember Google (or any other search engine) asking me for money in order to get search results, so I somehow suspect Google doesn't earn its money from just being a search engine. Search technology is extremely important for them of course, and is the backbone of their enterprise, but its services on top of searching that is what the game is about.
Seems that a country that mandated such things (and had this lets feed the people first before we get into this TV for everyone thing) is doing pretty well economically at least.
What I meant is that it opens up the possibility of licensing, where it did not exist before. That means that it reduces the "reinventing the wheel" problem.
Patents also prevents you from using what you invented independently when someone else happens to have invented the same thing just before you.
Obviously, licensing is not always the most profitable option, but it would never be without IP.
No, it wouldn't be an option indeed, but 'reverse engineering' and using the 'invention' would be, while right now it is not.
You should really look a bit more at both sides of this patent issue.
although I think the Sun Implementation is a perfect example of this "good enough" quality and far from perfect.
Hehe, I think I have to agree there.
it is indeed far from trivial, tho it does not need to be as complex as SUN made it.
and would take years to reach the performance and stability of Sun's JVM even with huge resources.There are 2 issues here:
- You don't have to achieve that level of 'quality' on the short term, it has to be 'good enough'. There are many examles where 'good enough' software is extremely succesfull despite there being equivalent software that has a much higher level of quality.
- This same assumption was held by people developing operating systems. They have been proven wrong repeatedly. A tiny group of individuals with the right mindset and enough of a clue about what they are doing, can develop usable versions of such a system in an amazingly short time.
They have chosen their own unique architecture so I don't think code reuse is in their plan.Luckily not.. Sun's JVM may be stable, but it is also overly complex and a serious resource hog in many cases.
IBM may or may not do development on their own on the product as well, but very importantly service contracts are paid up front - they get the money whether their own engineers do the fix or if their own engineers just take a fix that was done in Open Source by somebody else, run it through QA and then put it in an IBM servicepack.
Well, I do not know the exact terms and conditions for current OS/2 service contracts, but I do know what is usually in there for a product that is past its end of life, like it is the case with OS/2.
In general, it means you will get the service packs if/when they are made and get conditions for getting your own specific problems fixed. The later is not payed upfront. (if this product was not yet past its 'end of life', then such fixes are on IBM's expense, but in this case they are not)
I understand perfecly well what you are saying, but I am trying to tell you that in this specific case, your reasoning does not work because the customer does pay a price for each specific fix that they need and that is not there yet. Making the fix generates direct income in this case.
It is not a difference of understanding between us 2 about what a service contract is, it is you not taking into account what it is to have a service contract with IBM on a product that is past its end of life.
> That depends on what the release schedules are for these things.
I don't think you understood what I am saying. IBM gas serv8ice contracts with those customers, and gets payed for doign this development. Leaving it to others means less income for them.
> The advantage would be having smaller developers to look into the code and submit possible fixes
For now, IBM earns money from looking into such things. I doubt they want to enable others to do that for free really.
Yep, looks like you completely understand why I was having difficulty with the point you were making.
Was nice discussing with you, good to see that while we disagree maybe, we can still get to understanding eachothers point of view.
I don't believe I'll see it for a purely CLI environment, because there's not enough latency even under massive load for me to notice in a purely CLI environment even on machines a hundred times slower than what I'm using today.
Not having an idea what you are using now, but its hard to make a relatively modern machine running a UNIX with for example a 4BSD scheduler lag due to the scheduler under heavy load, other then by having an insane number of processes.
Going back to say a 386 or 486 based machine may allow you to observe lag under heavy load on a CLI.
Huge number of processes makes schedulers like the 4BSD one very inefficient, and it is for example not very good at making good use of multiple (possibly virtual) CPUs. (ULE is better but far from perfect at the later for now)
But under X11? I can't say I'm sure enough to rule it out. I haven't seen it before, but I could be wrong. Tell me, is this huge, or is it something I have to measure?
The difference under most conditions on a modern desktop are not huge for what I can tell, and may not even be observable depending on what kind of machine you have. 'Fixing' latency with raw power is a kinda well known approach, but doesn't even start to address the underlying differences between implementations, let alone answer which one is more effective.
On SMP systems and/or when running a huge number of processes, the difference may be easier to observe.
That's only a metaphor, yes, but that's the same kind of experience as the one I'm having right now.
Well, it is an interesting one, and I can see your point of view.
To make a counter metaphor, to me it feels like you are arguing that since English (with a bit of variation here and there) is spoken in the UK, USA, Australia and many other places over the world, we should just regard them as similar countries.
And that's a really cool thing to be able to do, and you need a UNIX-like operating system to do it. Trust me, do that anywhere you please on VMS and you're going to end up in a world of hurt eventually. I've done that.
.
And I have seen the same kind of problems on OS/2 and NT, where you get this nice thing of applications being made aware of changes to files without the need of something like FAM, and where using a file (read or write) locks it and prevents other processes from changing it while you work with it (something that can be done on UNIX like systems, but is not automatic there).
Lets not forget that in UNIX a file is in fact not represented by a name, that name is merely an index pointing to the file. It is represented usually by an inode. OS/2 nor NT have this concept
Try removing a file that is being used, and see how UNIX like systems keep the inode (ror similar in case of say XFS filesystems) around untill you stop using it, whereas OS/2 and NT will refuse removing the file and give an error.
There are many assumptions that you can make about the behavior of a 'UNIX like' system that will simply break on both OS/2 and NT and those are not far fetched things, they are extremely common things
Are they more like UNIX then VMS is? probably, alltho people have made a very strong argument for NT being a VMS like system.
So, let me say this, without any intent to ignore the value of OS/2, or OS/2's scheduler, or your experience. And that is... you could go into Linux or Solaris or whatever traditional UNIX kernel you're talking about and completely fix everything that's wrong about the scheduler, give it a real-time scheduler, or the OS/2 scheduler, or a magic scheduler that ALWAYS picks the process to run next that will provide the absolutely most responsive user interface while never deferring any other critical processes... and every single one of the shortcomings in the behaviour of interactive tasks would still be there.
Definitely, simply because it is not the only problem.
That's what I mean when I say the scheduler doesn't matter, that the UNIX scheduler is pretty close to good enough, it's because the scheduler just isn't responsible for enough of the system in a traditional UNIX kernel for it to be responsible for the problems.
And that is where we disagree. You can fix all the other problems in a traditional UNIX kernel, and still have a system that is not being responsive when ignoring the scheduler and priority management (note that I have from the start been talking about those 2, and also pointed at that they are not the only problem, but are a substantial part of the problem)
If you really want some proof of how much it matters, I suggest you install a FreeBSD -current snapshot, and then build 2 kernels, one with the 4BSD scheduler and one with the ULE scheduler, and just go measure the difference in responsiveness yourself.
A synchronous event loop causes other problems, but it doesn't add latency that doesn't exist in the underlying programs. A message queue that deliberately buffers and defers operations so it can bundle them to improve throughput does.
It makes responsiveness depend on well behavedness of applications, but you are right that as long as applications are well behaved, this indeed causes lower latency (this has always been IBM's argument against implementing multiple message queues)
And adding latency to a user interface, even if it's just a little, makes it feel less responsive. Even if your traditional UNIX and OS/2 systems had the same scheduler, the OS/2 GUI would feel more responsive than the X11 one.
As I have pointed out quite a few times in this discussion, the responsiveness differences remain even when eliminating the GUI completely on both systems. Would you please stop ignoring that?
I haven't explained the distinction I'm making well enough, because if I had you wouldn't have drawn such a broad analogy. I apologise for that. Still, there's the beginnings of a useful analogy there... so let me run with it.
I think my point was that when you only (or mostly) look at similarities, you can see things as being alike, while they do have differences that are so relevant that when looking at the bigger picture and take into account the differences, they are not alike.
NT, OS/2, UNIX and quite a few other systems are similar, and more similar to eachother then they are to say OS/390, VMS and such.
Yet, NT as well as OS/2 behave more like DOS then UNIX in many aspects. I would not call them DOS like operating systems hwever because the differences between them and DOS are more relevant then the similarities.
Calling OS/2 an NT like system? I can see the point of that.
Saying that OS/2, NT and UNIX are all part of a group of similar operating systems? I can see the point of that.
Calling OS/2 and NT UNIX like? well, in case of NT you can make an argument since it at least officially is supposed to be posix complient, OS/2 is not, and as a result doesn't even try to implement a similar interface, it just happens to share some functionality and implements certain things in a similar way.
I made the overly broad analogy exactly because I consider you calling them UNIX like system to be overly broad.
Computer games where you interact with the game via a screen and a joystick is not what I would consider VR. I would consider VR to be something that totally immerses all of the senses of touch, sight and sound into an artificial world, including some kind of feedback technology to produce touch sensations, so it seems you really are inside of that world, not just watching it on a screen.
Hrm, flight simulator with 3d projection (using 3d glasses), force feedback joystick and suround sound... that seems to match quite what you are asking for.
Racing game using a force feedback steering wheel and again 3d projection and suround sound is just another example.
Its not like this is anywhere new, have been playing games with such features (and the appropriate hardware, which is available at reasonable prices) for half a decade at least.
With today's GFX accelerators, you'd think they could take all that old hardware (data gloves, dual-screen headsets) and pump all the latest graphics through in 'true' 3D.
Hmm..
Quite a bit of the 'consumer' hardware from NVIDIA (and most likely others, but no experience with that) support stereo vision and dual screen 3d projection, and support the same type of '3d glasses' as my SGI workstation does, so that one is there.
USB has a definition for human interface devices, and other then price, there is very little reason why oen could not make and use a dataglove that way I'd think. To me it seems this is more a matter of what consumers want to pay for then anything else.
UNIX is anything that can be treated like a UNIX system. That's a functional definition of UNIX, and it's a useful definition. "Trademark UNIX" versus "genetic UNIX" versus "Linux" isn't useful because there have been systems that are "Trademark UNIX" that are less capable of being treated like a UNIX system than any version of Linux. "Trademark UNIX" and "genetic UNIX" ceased to be a useful definition of UNIX by the early '80s, because you could buy systems that were more compatible with System III (the first real AT&T commercial Trademark UNIX) than real Version 6 or Version 7 UNIX was.
Well, that way of looking at it works of course. Claiming however that systems like OS/2 or NT are 'UNIX like systems' is not. It is like claiming reptiles are dog like animals since they happen to have 4 legs, a tail, brains and such. 'X like' is defined as much by similarities as by differences, and those systems have too substantial differences when compared to UNIX to call them UNIX like. They do of course share a bunch of things with UNIX, and are more similar to it then say VMS.
Calling Linux a UNIX? hmm, we can argue about that, but I can see the argument for that claim.
Which I think is where I boarded this train...
Hrm, you seem to have started out by claiming it is NOT the scheduler and/or priority management but a different GUI design. I never claimed it is exclusively the scheduler or priority management, but that they play an important role in this.
I'll just say one thing about what UNIX is. UNIX is not Thompson and Ritchie's source tree, UNIX is a family of operating systems that provide a common core set of system calls as their native API. FreeBSD is UNIX. Linux is UNIX. OS/9 and QNX and Regulus are or were UNIX. Interix is a hosted UNIX.
I don't think I ever claimed Unix to be the T&R source tree. That I do not call FreeBSD a UNIX has a lot to do with what can officially be called UNIX. It is however genetically spoken a UNIX of course. Linux is a UNIX like system because it implements virtually the same API, however, it is not UNIX (both according to its maker and to those who actually can certify it as being UNIX)
OS/2 is a UNIX-like OS, so are NT and BeOS and AmigaOS and, well, you have to go back to VMS or look in an IBM dinosaur pen for something that isn't.
Your definition of UNIX and UNIX like seem to be rather loose ones, and entirely different from how those words are used by virtually everyone in the field.
Just to recapitulate:
Solaris, AIX, HPUX, IRIX and quite a few others are 'trademark' UNIX, they have passed the appropriate tests, and can officially be called UNIX.
FreeBSD, OpenBSD, NetBSD and a few others can be called 'genetic UNIX' because they derive directly from the original UNIX 'family tree'.
Linux on the other hand is a UNIX like system, it does not share a common origin with any of the above mentioned systems, but it implements a very similar set of interfaces and shares many design aspects.
While I'd agree about AmigaOS, and don't know about BeOS, I do not regard OS/2, NT and for example DOS as Unix like systems. You are right that they do share some things with Unix, but they are quite different with regards to their design and behavior for a programmer, systems administrator and an end-user. Specifically, the 'everything is a file' idea does not apply to those, redirection works entirely differently, the programming interfaces are different etc.
Similar in specific aspects? sure. UNIX like? I don't think so unless you have a very broad definition of what UNIX like means.
Wasn't a large part of that not trying due to infighting among divisions? Despite IBM's blunders in marketing, OS/2 had a hard-core fan base, and had they spun off OS/2 as a separate corp, it probably would have succeeded.
At the time (1995-96) OS/2 was marketed by a more or less independent IBM software company. IBM's PC company (doing the PC hardware) was not very cooperative indeed, but had no say about this.
> OS/2's kernel is not really similar to the traditional UNIX monolithic kernel. The original design had no kernel threads at all, let alone any way for a driver to schedule any, and virtually all traditional UNIXes (including Linux) use the same model today.
Of course they are different but both are monolithic (which has very little to do with this really). You are right of course that they are different in design in many ways, and one major difference is indeed in the area of threads. In OS/2, threads are the only things that can be scheduled. Processes own resources, but strictly spoken, they can't be executed, they have one or more threds of execution. SO in case of OS/2 it would indeed be threads competing for cpu time.
> We're not talking about processes competing against processes, we're talking about processes competing against device drivers. UNIX device drivers are not processes, tasks, or threads, and they are not scheduled, they are not handled or managed by the scheduler. The interrupt handler (lower half) triggers what's effectively a "software interrupt" that handles the longer term operations in the kernel context but doesn't normally involve a switch to a different process context. The scheduler doesn't "see" the driver at all.
Yep, but this is quite a chicken/egg problem. If your scheduler cannot handle threads (as in, use threads as the basic unit of execution, regardless of what context it is executing in) then handling interupts in a different way is not that easy. On OS/2, threads are the only unit of execution, if something runs it must be in a thread, even if that is an interupt thread. Actually, there is a Unix like system which does this in a very similar way nowadays, take a peek at FreeBSD 5.x and its interupt threads.
At any rate, you are of course right that there is more to it then just a scheduler and priority management.