or they represent a bug, in which case, a workaround in ssh-agent isn't going to be good enough.
I used to be you.
20 years ago when I first ran into programs that started a new shell session and didn't run their shell as a login shell I'd get good and mad. They were wrong, they needed to change.
I was completely right that they were wrng, but what I eventually realised is that it doesn't matter if I was right. I wasn't going to be able to force anyone to change, the original model I wanted to use was better than the model that some people were actually using, but it didn't matter... because the right way only worked if everyone did things the right way. As soon as one person did things the wrong way and you had to work around it, you were in the "wrong way" world, and you could never go back... because the workaround is what made the wrong way wrong.
So, I gave up trying to change it, I grumbled and held my nose and did the new right thing. Life is full of workarounds for bugs like this. Civilization is made out of them. Live with it, because it was too late to fix it when I noticed it happening 20 years ago.
It's been at least 20 years since you could depend on programs that start your first shell of a session to correctly figure out whether they should start a login shell or not. And I've had them fail both ways. The only thing I've found that's at all workable is to have an environment variable that's got the PID of my login shell in it, and use that to figure out which kind of startup I should do.
It seems to me that you're arguing that there's some kind of magic shield of protection around open source software that prevents you from learning and expanding your skills when you work on it.
I don't know if you've ever considered the revenue generated from having the desktop operating system monopoly being developed in the US, but perhaps you should...
Great point, and everyone reading this should absolutely be aware that Microsoft has considered it, and the US government has considered it, and they all know about it, and it's a filter that they listen to everything you say to them about Microsoft and Open Source through.
There's a very real "he's a son-of-a-bitch, but he's OUR son-of-a-bitch" effect.
When I opened this article I was thinking "yeah, right, who's going to make Microsoft use this?" The "who's going to make Microsoft use this argument has been something that I have seen as an absolute barrier to real open document formats for at least ten years.
But you're absolutely right, we'll get a huge win from just having a better open and widely used document format than HTML. Right now the open source office suites aren't really all that open other than being open-source. I'm not saying that's not huge, because it is, but you can be open-source and still lock people in [1], and we already know how easily a document format can lock you in to a single application. On top of that, if you think of the file format as an interface as well as a format, having a standard file format opens up the ability of people to write applications that operate on documents from all programs. Right now, in fact, one of the common reasons for exporting a document to HTML is not to display it in a web browser, but to get it into a format that's easier for another application to deal with, because there are an enormous number of applications already written that do interesting things with HTML.
[1] For example, GCC is open-source, but porting code written for GCC to other compilers can be soul-killing, because the language accepted by GCC is not an open standard... it's "the language accepted by GCC". Oh, it also accepts standard code, but it takes a deliberate and conscious commitment to write code that is both standards-conforming and portable to be "writing code with GCC" instead of "writing code for GCC". Every open source project that accepts a complex language - whether it's C or XML - has to face the same problem, and very few have faced the challenge of really supporting standards at all well.
Note however that the TCP/IP work was done under a DARPA grant, paid for by the US government, so it is not only legal, but even moral right for Microsoft to use this code.
Not only that but whenever I've been present when someone has asked the people who wrote the code if it's OK for Microsoft to use it, they didn't say "we can't stop them", they said "we want them to use it".
I don't see how you can possibly come up with a more ethical or moral justification for it than that.
Yep, I'm a total Microsoft shill, I've never said one bad word about the Pocket PC, anything you find online that suggests I'm completely turned off by the design is a forgery, I never said it. If you run into the places I seem to have pointed out how much better a job PalmOS does at everything that a PDA is for, and that you can't rely on the Pocket PC to give you a secure place to store your most important data... hey, I was drunk, stoned, AND using a cellphone while driving.
I don't know what happened, maybe Microsoft the company had an almost un-heard of breakthrough and let some of the people who worked there show their total commitment to keeping their word, but they did. Writing bad stuff about the Pocket PCdidn't get you taken off their list, which was really smart of them because it meant they got feedback on PPC 2002 from people who actively disliked PPC 2000...
And the site least like Amazon for me is mwave.com, where the cart seems to be maintained in the browser and if you hit "back" you lose it piece by piece... and if you close your browser window it's gone, right then and there.
Going back to say a 386 or 486 based machine may allow you to observe lag under heavy load on a CLI.
Going back to a 286 and a PDP-11 I can't recall having ever observed lag under heavy CPU load in a command line application under UNIX. I have observed lag caused by other things but I've observed that same lag when the CPU was mostly idle.
For example "insane numbers of processes" doesn't mean "the problem is heavy CPU load", it can mean "the problem is thrashing".
On SMP systems and/or when running a huge number of processes, the difference may be easier to observe.
A traditional monolithic kernel requires a lot of work to get it to do SMP adequately, let alone well, because unless you have kernel threads or SMP you can just duck in and out of a single giant lock. So, they do.
Going back and making the kernel more re-entrant with finer-grained locks is an ongoing process.
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.
Not quite, try this one:
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 regard them as English-speaking countries.
Do you see the difference that removing the word "just" and replacing "similar" with "English-speaking" makes? And try this one on:
since English is widely spoken in the UK, USA, France, and Mexico, we should regard them as English-speaking countries.
You wouldn't call Mexico an "English-speaking country", even though you may not need to deal with that as long as you stay in the "English-speaking environment" of the hotel.
I don't want to drag this metaphor out too far, but thanks for providing an analogy that helped me understand what my point looked like from your side of the screen.
You're talking about things that are extremely common on traditional UNIX systems. But they're not universal even there (see what happens if someone deletes a file you've opened over NFS), and they've never been even common in UNIX-like environments on non-UNIX-like systems.
I'm talking about things that a UNIX-like environment has to have to be a UNIX-like environment. Things that have to be emulated to create an environment where the "Software Tools" approach can be used. They're things that are fairly easy to emulate, in some cases, but they have to be there.
So, when I'm talking about a UNIX-like system, I'm talking about a system where all the things you need for a UNIX-like environment are already there in the native environment. That native programs are already naturally expecting.
Forty years ago, there was no system that provided more than one or two, at the most. Most didn't provide any, and many of these characteristics didn't exist in any system.
Thirty years ago, there was only one system that provided them all, and when you put them together the result was an environment that was so profoundly different from every other environment that it wasn't just like a new language for people to use when they interacted with computers, it was like a new kind of language.
The GUI was the same kind of profound change, but the GUI was a new kind of language that a computer had to be born to run. This one wasn't just new, but you could have it on the computer and operating system you already had. People implemented UNIX-like environments on top of every operating system that could conceivably support one, and that turned out to be just about every operating system you could sit down at a keyboard and use.
Let's say that I was an Esperanto enthusiast. Let's say I learned Esperanto 30 years ago. Let's say that I was talking to someone who was so used to the fact that everyone spoke Esperanto that the idea that "native Esperanto speaker" was a useful concept not only passed him by... but it kind of pissed him off that I was using the word "Esperanto" when I described a native Esperanto speaker. He'd say things like "Yes, he's an Esperanto speaker, but he's also a physicist" and I wouldn't even understand why that was part ofthe discussion.
That's only a metaphor, yes, but that's the same kind of experience as the one I'm having right now.
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
If you do that you'll have created a system in which the role of the scheduler is much more important than it is in a traditional UNIX kernel. If you just do that, in fact, you are almost certain to end up with a system that is less able to handle resource contention than the current kernel, because you'll have a system where a process can be competing with its own device drivers instead of a system where the device drivers are running as software interrupts in that same process.
It's like switching to a microkernel design. If you build a system with a microkernel design and pay anywhere near as little attention to queue management and scheduling as you can get away with in a traditional UNIX kernel, you'll end up with a system that has incredible problems with bottlenecks. Like, say, MINIX.
In fact, a scheduler that acts like the UNIX scheduler is actually worse than a naive scheduler in those environments. It's almost guaranteed to create a problem with priority inversion as a driver in OS/2 or a server in a microkernel gradually gets "niced" down below the priority of the process that it's starving.
Next...
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.
Measure, or observe?
If I have to measure something to notice it, then that's proof for me that it's not something that matters.
If it's a big enough difference that I can get it just using the system with a compute-bound job in the background, then that might be worth actually firing up my test box for.
If it's something that's going to make a big difference, then that's actually exciting, because I've used UNIX systems with other schedulers before and I've never seen that.
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.
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?
Like, one assumes, one would pray for a sick friend?
What is now considered the traditional file system API is not well designed for databases, but there have been other ones that might be better used in the past: an API that does for databases what the UNIX API (after all, virtually all file system APIs these days are based on it) did for files is needed.
This is something that's really sunk in, recently. I spent years doing free technical support above and beyond the call of my job, and that got me moved into the support group, which was great for a while... but I kept ALSO being the guy who can fix things, and spent huge amounts of time fixing things for people that I wasn't actually being paid to fix, and that sucked up home time and work time and all my "fun" coding time. Lots of people think I'm a great guy, but I'm not being anywhere near as effective as I could be at anything but being that great guy.
Today I haven't done anything except on my own schedule. I let someone else find they had their computer plugged into the wrong port, instead of tracking it down for them, and they sounded perfecly happy about that. I feel great.
The site that I see showing up in/. over and over again that's just copies of press releases elsewhere on the net is PhysOrg. How much are they getting from/. eyeballs? How many slashleeches are there?
It strikes me that this is the way any good engineer would want to go about things.
Absolutely. Eating your own dogfood isn't enough. Eating your own dogfood is going to help you sell dogfood, but it's not going to help you when your customers are cats, when you're already selling all the dogfood there is to sell and you can't break into the cat market at all. What they did with us was fed their dogfood to people who preferred catfood, and watched us eat it, and asked us about it. And they came up with a product that cats like better.
Eh, it's still dogfood, but it's good enough dogfood that in some areas it actually tastes better to a cat than catfood does.
As an aside I think that's one of open source's biggest draws.
Oh, yeh, that's right. You don't have to wait for the dogfood company to notice that you're not a damned dog. You can cook up your own catfood if that's what it takes.
Man, I'm totally sorry. I thought I was in "stop ignoring that" mode when I said Now we've talked about the drivers, I'll say that things like the GUI design and the driver architecture have a bigger impact blah blah blah blah.
I dropped the ball there.
So let me say that between your posts and my subsequent googling you have totally expanded my understanding of the OS/2 scheduler, it's way better than I thought. And also, I totally get that you've got solid examples of related problems that don't have anything to do with the GUI.
So, yes, you're absolutely right. It's not just the GUI. There's lots of other ways the OS/2 architecture is designed to provide way more responsiveness than the traditional UNIX kernel.
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.
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.
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.
I absolutely got that. That's why I used an example of a dinosaur that really, truly is described as a "dog like animal". It's a dinosaur! It's different from a dog in so many ways that it makes NT and Xenix look like cousins. If a dinosaur (instead of a big cat or even a marsupial) can be dog-like, then it seems that using the "whatever-like" term to describe something that's only "whatever-like" in some particular area is no big deal.
And it absolutely isn't.
I'm saying that NT, OS/2, and UNIX are all members of a group of operating systems that can be used in the biggest "ecological niche", if you will, that UNIX created and that UNIX usually occupies. This isn't the same as the "it's got a POSIX interface" niche, VMS has had a POSIX interface so long I've forgotten when it showed up. IBM's MVS has a POSIX interface, for Watson's sake.
The difference is this: if you go poking around in the system doing UNIX type things on a non-UNIX-like system with a POSIX interface you'll end up either finding yourself locked out of lots and lots of files all over the place, or you'll accidentally trash files so that native applications can't make head nor tail of them. If you do that in a UNIX-like system, well, you can pull stuff out of the native environment, do UNIXy things to it, toss it back out again right on top of the original native file, and it's totally OK to do that because it won't break anything.
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.
The really really amazing thing, then, is that this kind of interface has become so common and so universal that you're saying things like it just happens to share some functionality and implements certain things in a similar way.
You're absolutely right. That's exactly what it means. And it's so amazingly amazing that I've completely forgotten where my towel is, because thirty years ago people were willing to spend weeks typing in FORTRAN and RATFOR code from "Software Tools" because that was the only way in the entire world to get a system that happened to share that functionality and implement things in that certain way.
Really.
I did it. And it gave me a system that was so much better than the one I was using that when I showed one of my co-workers how I could call a program from the editor command line and pull the results back into the editor buffer he was completely blown away.
Completely.
If UNIX hadn't existed, nobody would be doing that. Oh, eventually, in a GUI, yes, but not from the command line. UNIX gave you about as much of teh same kind of power that a good GUI gives you, and it gave you that power on the command line, in any program you wanted, including the shell.
Having that in the shell, HAVING a shell instead of a monitor, all the other stuff I listed? That's the stuff that MADE UNIX into this totally awesome environment, and having that awesome environment in EVERY OS is just so insanely cool that... I guess if you haven't had to struggle with what we had before it maybe you'll never see it.
I guess that's why when I get "it's totally amazing that every major OS out there is UNIX-like" you get "he's just talking about every OS out there. Why does that make them UNIX like?".
Disconnect them and have them pay YOU for a support visit to get decontaminated and reconnected for enough that it's worth YOUR time to do it. Present that to whoever you've volunteered your time to as the only workable solution... and either walk when they say no, or watch the problem fix itself as the word gets around.
I was part of one of Microsoft's attempts at getting people who were active on the Internet involved. At the Pocket PC, Wireless, and Beyond shindig in 2000 Microsoft invited 35 people - mainly Palm users - who were active online to Redmond, gave them each a couple of Pocket PCs (and mailed them a couple more over the years), and asked for feedback.
There was no NDA.
There was no attempt to encourage people to be pro-Microsoft or even actively promote the product. I certainly wasn't, I was more than ready to highlight the shortcomings of the products, and they still kept me on their list and sent me units to try on.
And most of all, they didn't just talk... they listened as well.
Three things struck me:
First, all the Palm users immediately got together and beamed all their contact info to each other. The Pocket PC users mostly didn't know how to do it, beaming was difficult and the handhelds were generally larger and less comfortable to use and even the Microsoft people on the handheld team didn't tend to have theirs with them.
Second, getting the mail set up on the LAN they were demoing on was really hard. By the second try people were saying things like "this isn't supposed to be rocket science, and besides, we're all supposed to be rocket scientists".
Third, the handwriting recognition was clumsy. It required a lot more strokes and a lot more tries to reliably recognise text, compared to Graffiti.
The really amazing thing, the thing that made me a total fan of Beth Goza and Derek Brown was thet the next version of the Pocket PC software actually fixed all these problems. Not all the changes were improvements, and not all the problems we pointed out were fixed, but so many of them were I was stunned. In fact, since Palm replaced Graffiti with Jot the Pocket PC does a better job of implementing Graffiti than Palm OS does.
Unfortunately, while they made many changes the Pocket PC still has all the deeper flaws that I wrote about back then. Oh well, this isn't about the Pocket PC. This is about Microsoft.
What was key with the PPCWB shindig is that Microsoft set up a two-way discussion with us, and didn't try and control what we said in it or to other people. This wan't an "Astroturf" campaign, it was a real engagement with the community, and they got a huge win out of NOT creating a conduit for synthetic adulation.
Hrm, you seem to have started out by claiming it is NOT the scheduler and/or priority management but a different GUI design.
I said that the GUI design had a much much bigger impact on the responsiveness of the user interface than the scheduler. Now we've talked about the drivers, I'll say that things like the GUI design and the driver architecture have a bigger impact on the responsiveness of the user interface than the scheduler. It's not exactly the same conversation, but it's a parallel point (pardon the geometrically inexact metaphor there).
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.
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.
That doesn't mean that the scheduler doesn't make it possible to do things on OS/2 that you can't do on traditional UNIX, it just means that the problems you observed can't be fixed just by improving the scheduler on the systems where you observed them.
It is like claiming reptiles are dog like animals since they happen to have 4 legs, a tail, brains and such.
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.
Some reptiles were dog-like animals because they share characteristics with dogs, as a result of fitting into the same ecological niche, that they can usefully be described as dog-like animals to distinguish them from reptiles that doen't share those characteristics. For a specific example, one dinosaur has the name "cynodont" or "dog-jaw" because its jaw resembles a dog's jaw as much as a dinosaur's jaw can be expected to. It's described as a "dog-like dinosaur".
Now this doesn't say there's any genetic relationship between these dinosaurs and dogs that's not shared by other mammals. It's just a useful distinction.
So when I say a system is "UNIX-like", that doesn't mean it's genetically related to UNIX, or that that's the only what to describe it, it just means that it's useful to describe it as "UNIX-like".
There are operating systems that are not "UNIX-like". VMS isn't "UNIX-like". If you open a file in VMS, read it as a stream of bytes, and write it out again, you can't expect that the new file to actually be the same as the old file. That's because a VMS file is a set of records, not a stream of bytes. In NT, you expect that will work. You can construct scenarios where it won't work, but you can do that on UNIX too (for example, what if the file is an executable... the copy won't have the execute bit set)... but in general that's the way files work in NT. That's a UNIX-like characteristic.
File name is an unstructured string? UNIX-like. I can't think of a single operating system before UNIX where the only restriction on the characters in the unqualified name of a file is that they can't conflict with other parts of the fully qualified file name.
File system is a directed graph? UNIX-like. This actually originated in Multics, but why is Multics as well known as it is? Because UNIX borrowed ideas from it.
The shell is just another program? UNIX-like. Back when UNIX was developed, this wasn't even seen as a good idea, let alone common.
Put enough features like these together and you have an operating system that you can deal with as if it was UNIX and you'll mostly get away with it, even if you're dealing with files created by programs that don't use the UNIX-like features of the OS.
Another way to think of it is to consider Kernighan and Plauger's book "Software Tools". The operating systems that share the characteristics I'm talking about can be treated as a native "Software Tools" platform. Not only can you run "Software Tools" programs on a UNIX-like system, but you can usually ignore the fact that there's other ways to interact with the system. You'll miss out on a lot of the features of the system, but you rarely forced to deal with them.
And the whole point of "Software Tools"? Creating a UNIX-like environment on a non-UNIX-like system. So if the native environment of the system is that kind of UNIX-like environment, what does it tell you?
Why, that it's useful to talk about it as a UNIX-like system.
That's not the only way to describe it, of course. And it limits you. But it's still a useful distinction.
We can argue about that, too, but I think you can play the rest of the discussion out in your head, no?
Linus has been quoted as saying that once hd had the file system, cheduler, and device drivers he had the core of a UNIX system.
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.
Slashdot Mirror
or they represent a bug, in which case, a workaround in ssh-agent isn't going to be good enough.
I used to be you.
20 years ago when I first ran into programs that started a new shell session and didn't run their shell as a login shell I'd get good and mad. They were wrong, they needed to change.
I was completely right that they were wrng, but what I eventually realised is that it doesn't matter if I was right. I wasn't going to be able to force anyone to change, the original model I wanted to use was better than the model that some people were actually using, but it didn't matter... because the right way only worked if everyone did things the right way. As soon as one person did things the wrong way and you had to work around it, you were in the "wrong way" world, and you could never go back... because the workaround is what made the wrong way wrong.
So, I gave up trying to change it, I grumbled and held my nose and did the new right thing. Life is full of workarounds for bugs like this. Civilization is made out of them. Live with it, because it was too late to fix it when I noticed it happening 20 years ago.
Apparently Siracusa hasn't advanced beyond .bashrc or .cshrc; someone tell him about .login or .profile.
It's been at least 20 years since you could depend on programs that start your first shell of a session to correctly figure out whether they should start a login shell or not. And I've had them fail both ways. The only thing I've found that's at all workable is to have an environment variable that's got the PID of my login shell in it, and use that to figure out which kind of startup I should do.
It seems to me that you're arguing that there's some kind of magic shield of protection around open source software that prevents you from learning and expanding your skills when you work on it.
Man, I think there's a huge opportunity for a joint venture between the Indian Government and Google. "Google Earth".
[black helicopters] (Search Web) (Search Space Imagery) (I'm feel nosey)
I don't know if you've ever considered the revenue generated from having the desktop operating system monopoly being developed in the US, but perhaps you should...
Great point, and everyone reading this should absolutely be aware that Microsoft has considered it, and the US government has considered it, and they all know about it, and it's a filter that they listen to everything you say to them about Microsoft and Open Source through.
There's a very real "he's a son-of-a-bitch, but he's OUR son-of-a-bitch" effect.
When I opened this article I was thinking "yeah, right, who's going to make Microsoft use this?" The "who's going to make Microsoft use this argument has been something that I have seen as an absolute barrier to real open document formats for at least ten years.
But you're absolutely right, we'll get a huge win from just having a better open and widely used document format than HTML. Right now the open source office suites aren't really all that open other than being open-source. I'm not saying that's not huge, because it is, but you can be open-source and still lock people in [1], and we already know how easily a document format can lock you in to a single application. On top of that, if you think of the file format as an interface as well as a format, having a standard file format opens up the ability of people to write applications that operate on documents from all programs. Right now, in fact, one of the common reasons for exporting a document to HTML is not to display it in a web browser, but to get it into a format that's easier for another application to deal with, because there are an enormous number of applications already written that do interesting things with HTML.
[1] For example, GCC is open-source, but porting code written for GCC to other compilers can be soul-killing, because the language accepted by GCC is not an open standard... it's "the language accepted by GCC". Oh, it also accepts standard code, but it takes a deliberate and conscious commitment to write code that is both standards-conforming and portable to be "writing code with GCC" instead of "writing code for GCC". Every open source project that accepts a complex language - whether it's C or XML - has to face the same problem, and very few have faced the challenge of really supporting standards at all well.
Note however that the TCP/IP work was done under a DARPA grant, paid for by the US government, so it is not only legal, but even moral right for Microsoft to use this code.
Not only that but whenever I've been present when someone has asked the people who wrote the code if it's OK for Microsoft to use it, they didn't say "we can't stop them", they said "we want them to use it".
I don't see how you can possibly come up with a more ethical or moral justification for it than that.
Yep, I'm a total Microsoft shill, I've never said one bad word about the Pocket PC, anything you find online that suggests I'm completely turned off by the design is a forgery, I never said it. If you run into the places I seem to have pointed out how much better a job PalmOS does at everything that a PDA is for, and that you can't rely on the Pocket PC to give you a secure place to store your most important data... hey, I was drunk, stoned, AND using a cellphone while driving.
:)
I don't know what happened, maybe Microsoft the company had an almost un-heard of breakthrough and let some of the people who worked there show their total commitment to keeping their word, but they did. Writing bad stuff about the Pocket PCdidn't get you taken off their list, which was really smart of them because it meant they got feedback on PPC 2002 from people who actively disliked PPC 2000...
Pity about that reliability problem.
And the site least like Amazon for me is mwave.com, where the cart seems to be maintained in the browser and if you hit "back" you lose it piece by piece... and if you close your browser window it's gone, right then and there.
Going back to say a 386 or 486 based machine may allow you to observe lag under heavy load on a CLI.
Going back to a 286 and a PDP-11 I can't recall having ever observed lag under heavy CPU load in a command line application under UNIX. I have observed lag caused by other things but I've observed that same lag when the CPU was mostly idle.
For example "insane numbers of processes" doesn't mean "the problem is heavy CPU load", it can mean "the problem is thrashing".
On SMP systems and/or when running a huge number of processes, the difference may be easier to observe.
A traditional monolithic kernel requires a lot of work to get it to do SMP adequately, let alone well, because unless you have kernel threads or SMP you can just duck in and out of a single giant lock. So, they do.
Going back and making the kernel more re-entrant with finer-grained locks is an ongoing process.
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.
Not quite, try this one:
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 regard them as English-speaking countries.
Do you see the difference that removing the word "just" and replacing "similar" with "English-speaking" makes? And try this one on:
since English is widely spoken in the UK, USA, France, and Mexico, we should regard them as English-speaking countries.
You wouldn't call Mexico an "English-speaking country", even though you may not need to deal with that as long as you stay in the "English-speaking environment" of the hotel.
I don't want to drag this metaphor out too far, but thanks for providing an analogy that helped me understand what my point looked like from your side of the screen.
You're talking about things that are extremely common on traditional UNIX systems. But they're not universal even there (see what happens if someone deletes a file you've opened over NFS), and they've never been even common in UNIX-like environments on non-UNIX-like systems.
I'm talking about things that a UNIX-like environment has to have to be a UNIX-like environment. Things that have to be emulated to create an environment where the "Software Tools" approach can be used. They're things that are fairly easy to emulate, in some cases, but they have to be there.
So, when I'm talking about a UNIX-like system, I'm talking about a system where all the things you need for a UNIX-like environment are already there in the native environment. That native programs are already naturally expecting.
Forty years ago, there was no system that provided more than one or two, at the most. Most didn't provide any, and many of these characteristics didn't exist in any system.
Thirty years ago, there was only one system that provided them all, and when you put them together the result was an environment that was so profoundly different from every other environment that it wasn't just like a new language for people to use when they interacted with computers, it was like a new kind of language.
The GUI was the same kind of profound change, but the GUI was a new kind of language that a computer had to be born to run. This one wasn't just new, but you could have it on the computer and operating system you already had. People implemented UNIX-like environments on top of every operating system that could conceivably support one, and that turned out to be just about every operating system you could sit down at a keyboard and use.
Let's say that I was an Esperanto enthusiast. Let's say I learned Esperanto 30 years ago. Let's say that I was talking to someone who was so used to the fact that everyone spoke Esperanto that the idea that "native Esperanto speaker" was a useful concept not only passed him by... but it kind of pissed him off that I was using the word "Esperanto" when I described a native Esperanto speaker. He'd say things like "Yes, he's an Esperanto speaker, but he's also a physicist" and I wouldn't even understand why that was part ofthe discussion.
That's only a metaphor, yes, but that's the same kind of experience as the one I'm having right now.
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
If you do that you'll have created a system in which the role of the scheduler is much more important than it is in a traditional UNIX kernel. If you just do that, in fact, you are almost certain to end up with a system that is less able to handle resource contention than the current kernel, because you'll have a system where a process can be competing with its own device drivers instead of a system where the device drivers are running as software interrupts in that same process.
It's like switching to a microkernel design. If you build a system with a microkernel design and pay anywhere near as little attention to queue management and scheduling as you can get away with in a traditional UNIX kernel, you'll end up with a system that has incredible problems with bottlenecks. Like, say, MINIX.
In fact, a scheduler that acts like the UNIX scheduler is actually worse than a naive scheduler in those environments. It's almost guaranteed to create a problem with priority inversion as a driver in OS/2 or a server in a microkernel gradually gets "niced" down below the priority of the process that it's starving.
Next...
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.
Measure, or observe?
If I have to measure something to notice it, then that's proof for me that it's not something that matters.
If it's a big enough difference that I can get it just using the system with a compute-bound job in the background, then that might be worth actually firing up my test box for.
If it's something that's going to make a big difference, then that's actually exciting, because I've used UNIX systems with other schedulers before and I've never seen that.
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.
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?
Pray for WinFS.
Like, one assumes, one would pray for a sick friend?
What is now considered the traditional file system API is not well designed for databases, but there have been other ones that might be better used in the past: an API that does for databases what the UNIX API (after all, virtually all file system APIs these days are based on it) did for files is needed.
Kind of undoes the original premise that he is doing this on an unpaid, volunteer basis now doesn't it?
Right. You're absolutely right. Do you get that that's the problem?
Changing the rules in the middle of the game.
That's because the game they're playing with him is "Calvinball".
This is something that's really sunk in, recently. I spent years doing free technical support above and beyond the call of my job, and that got me moved into the support group, which was great for a while... but I kept ALSO being the guy who can fix things, and spent huge amounts of time fixing things for people that I wasn't actually being paid to fix, and that sucked up home time and work time and all my "fun" coding time. Lots of people think I'm a great guy, but I'm not being anywhere near as effective as I could be at anything but being that great guy.
Today I haven't done anything except on my own schedule. I let someone else find they had their computer plugged into the wrong port, instead of tracking it down for them, and they sounded perfecly happy about that. I feel great.
The site that I see showing up in /. over and over again that's just copies of press releases elsewhere on the net is PhysOrg. How much are they getting from /. eyeballs? How many slashleeches are there?
It strikes me that this is the way any good engineer would want to go about things.
Absolutely. Eating your own dogfood isn't enough. Eating your own dogfood is going to help you sell dogfood, but it's not going to help you when your customers are cats, when you're already selling all the dogfood there is to sell and you can't break into the cat market at all. What they did with us was fed their dogfood to people who preferred catfood, and watched us eat it, and asked us about it. And they came up with a product that cats like better.
Eh, it's still dogfood, but it's good enough dogfood that in some areas it actually tastes better to a cat than catfood does.
As an aside I think that's one of open source's biggest draws.
Oh, yeh, that's right. You don't have to wait for the dogfood company to notice that you're not a damned dog. You can cook up your own catfood if that's what it takes.
Would you please stop ignoring that?
Man, I'm totally sorry. I thought I was in "stop ignoring that" mode when I said Now we've talked about the drivers, I'll say that things like the GUI design and the driver architecture have a bigger impact blah blah blah blah.
I dropped the ball there.
So let me say that between your posts and my subsequent googling you have totally expanded my understanding of the OS/2 scheduler, it's way better than I thought. And also, I totally get that you've got solid examples of related problems that don't have anything to do with the GUI.
So, yes, you're absolutely right. It's not just the GUI. There's lots of other ways the OS/2 architecture is designed to provide way more responsiveness than the traditional UNIX kernel.
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.
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.
That cool?
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.
I absolutely got that. That's why I used an example of a dinosaur that really, truly is described as a "dog like animal". It's a dinosaur! It's different from a dog in so many ways that it makes NT and Xenix look like cousins. If a dinosaur (instead of a big cat or even a marsupial) can be dog-like, then it seems that using the "whatever-like" term to describe something that's only "whatever-like" in some particular area is no big deal.
And it absolutely isn't.
I'm saying that NT, OS/2, and UNIX are all members of a group of operating systems that can be used in the biggest "ecological niche", if you will, that UNIX created and that UNIX usually occupies. This isn't the same as the "it's got a POSIX interface" niche, VMS has had a POSIX interface so long I've forgotten when it showed up. IBM's MVS has a POSIX interface, for Watson's sake.
The difference is this: if you go poking around in the system doing UNIX type things on a non-UNIX-like system with a POSIX interface you'll end up either finding yourself locked out of lots and lots of files all over the place, or you'll accidentally trash files so that native applications can't make head nor tail of them. If you do that in a UNIX-like system, well, you can pull stuff out of the native environment, do UNIXy things to it, toss it back out again right on top of the original native file, and it's totally OK to do that because it won't break anything.
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.
The really really amazing thing, then, is that this kind of interface has become so common and so universal that you're saying things like it just happens to share some functionality and implements certain things in a similar way.
You're absolutely right. That's exactly what it means. And it's so amazingly amazing that I've completely forgotten where my towel is, because thirty years ago people were willing to spend weeks typing in FORTRAN and RATFOR code from "Software Tools" because that was the only way in the entire world to get a system that happened to share that functionality and implement things in that certain way.
Really.
I did it. And it gave me a system that was so much better than the one I was using that when I showed one of my co-workers how I could call a program from the editor command line and pull the results back into the editor buffer he was completely blown away.
Completely.
If UNIX hadn't existed, nobody would be doing that. Oh, eventually, in a GUI, yes, but not from the command line. UNIX gave you about as much of teh same kind of power that a good GUI gives you, and it gave you that power on the command line, in any program you wanted, including the shell.
Having that in the shell, HAVING a shell instead of a monitor, all the other stuff I listed? That's the stuff that MADE UNIX into this totally awesome environment, and having that awesome environment in EVERY OS is just so insanely cool that... I guess if you haven't had to struggle with what we had before it maybe you'll never see it.
I guess that's why when I get "it's totally amazing that every major OS out there is UNIX-like" you get "he's just talking about every OS out there. Why does that make them UNIX like?".
And the fact that contrast exists.
Zowie.
Disconnect them and have them pay YOU for a support visit to get decontaminated and reconnected for enough that it's worth YOUR time to do it. Present that to whoever you've volunteered your time to as the only workable solution... and either walk when they say no, or watch the problem fix itself as the word gets around.
I was part of one of Microsoft's attempts at getting people who were active on the Internet involved. At the Pocket PC, Wireless, and Beyond shindig in 2000 Microsoft invited 35 people - mainly Palm users - who were active online to Redmond, gave them each a couple of Pocket PCs (and mailed them a couple more over the years), and asked for feedback.
There was no NDA.
There was no attempt to encourage people to be pro-Microsoft or even actively promote the product. I certainly wasn't, I was more than ready to highlight the shortcomings of the products, and they still kept me on their list and sent me units to try on.
And most of all, they didn't just talk... they listened as well.
Three things struck me:
First, all the Palm users immediately got together and beamed all their contact info to each other. The Pocket PC users mostly didn't know how to do it, beaming was difficult and the handhelds were generally larger and less comfortable to use and even the Microsoft people on the handheld team didn't tend to have theirs with them.
Second, getting the mail set up on the LAN they were demoing on was really hard. By the second try people were saying things like "this isn't supposed to be rocket science, and besides, we're all supposed to be rocket scientists".
Third, the handwriting recognition was clumsy. It required a lot more strokes and a lot more tries to reliably recognise text, compared to Graffiti.
The really amazing thing, the thing that made me a total fan of Beth Goza and Derek Brown was thet the next version of the Pocket PC software actually fixed all these problems. Not all the changes were improvements, and not all the problems we pointed out were fixed, but so many of them were I was stunned. In fact, since Palm replaced Graffiti with Jot the Pocket PC does a better job of implementing Graffiti than Palm OS does.
Unfortunately, while they made many changes the Pocket PC still has all the deeper flaws that I wrote about back then. Oh well, this isn't about the Pocket PC. This is about Microsoft.
What was key with the PPCWB shindig is that Microsoft set up a two-way discussion with us, and didn't try and control what we said in it or to other people. This wan't an "Astroturf" campaign, it was a real engagement with the community, and they got a huge win out of NOT creating a conduit for synthetic adulation.
Microsoft's done it once. Can they do it again?
Hrm, you seem to have started out by claiming it is NOT the scheduler and/or priority management but a different GUI design.
I said that the GUI design had a much much bigger impact on the responsiveness of the user interface than the scheduler. Now we've talked about the drivers, I'll say that things like the GUI design and the driver architecture have a bigger impact on the responsiveness of the user interface than the scheduler. It's not exactly the same conversation, but it's a parallel point (pardon the geometrically inexact metaphor there).
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.
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.
That doesn't mean that the scheduler doesn't make it possible to do things on OS/2 that you can't do on traditional UNIX, it just means that the problems you observed can't be fixed just by improving the scheduler on the systems where you observed them.
Does putting it that way help?
It is like claiming reptiles are dog like animals since they happen to have 4 legs, a tail, brains and such.
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.
Some reptiles were dog-like animals because they share characteristics with dogs, as a result of fitting into the same ecological niche, that they can usefully be described as dog-like animals to distinguish them from reptiles that doen't share those characteristics. For a specific example, one dinosaur has the name "cynodont" or "dog-jaw" because its jaw resembles a dog's jaw as much as a dinosaur's jaw can be expected to. It's described as a "dog-like dinosaur".
Now this doesn't say there's any genetic relationship between these dinosaurs and dogs that's not shared by other mammals. It's just a useful distinction.
So when I say a system is "UNIX-like", that doesn't mean it's genetically related to UNIX, or that that's the only what to describe it, it just means that it's useful to describe it as "UNIX-like".
There are operating systems that are not "UNIX-like". VMS isn't "UNIX-like". If you open a file in VMS, read it as a stream of bytes, and write it out again, you can't expect that the new file to actually be the same as the old file. That's because a VMS file is a set of records, not a stream of bytes. In NT, you expect that will work. You can construct scenarios where it won't work, but you can do that on UNIX too (for example, what if the file is an executable... the copy won't have the execute bit set)... but in general that's the way files work in NT. That's a UNIX-like characteristic.
File name is an unstructured string? UNIX-like. I can't think of a single operating system before UNIX where the only restriction on the characters in the unqualified name of a file is that they can't conflict with other parts of the fully qualified file name.
File system is a directed graph? UNIX-like. This actually originated in Multics, but why is Multics as well known as it is? Because UNIX borrowed ideas from it.
The shell is just another program? UNIX-like. Back when UNIX was developed, this wasn't even seen as a good idea, let alone common.
Put enough features like these together and you have an operating system that you can deal with as if it was UNIX and you'll mostly get away with it, even if you're dealing with files created by programs that don't use the UNIX-like features of the OS.
Another way to think of it is to consider Kernighan and Plauger's book "Software Tools". The operating systems that share the characteristics I'm talking about can be treated as a native "Software Tools" platform. Not only can you run "Software Tools" programs on a UNIX-like system, but you can usually ignore the fact that there's other ways to interact with the system. You'll miss out on a lot of the features of the system, but you rarely forced to deal with them.
And the whole point of "Software Tools"? Creating a UNIX-like environment on a non-UNIX-like system. So if the native environment of the system is that kind of UNIX-like environment, what does it tell you?
Why, that it's useful to talk about it as a UNIX-like system.
That's not the only way to describe it, of course. And it limits you. But it's still a useful distinction.
We can argue about that, too, but I think you can play the rest of the discussion out in your head, no?
Linus has been quoted as saying that once hd had the file system, cheduler, and device drivers he had the core of a UNIX system.
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.