He can certainly ask the FSF their opinion out of a desire to be a "good citizen", but remember, the only legally relevent interpreters of the GPL are the courts. With no GPL trial record available, a lawyer is unlikley to provide much insight either.
I'm suspicious that the real reason Apple took the course they did was to provide cover for bailing out Job's Next company. A company that also flushed a lot of money down the toilet and never produced anything the market found desirable. By having Apple buy it, Job's created the illusion that there was something of value there.
The real irony is that Jobs zealots (as opposed to old fashioned Apple product zealots) would swallow the idea that Apple's future depended on adopting an OS based on a quarter-century-old command-line technology (wrapped in a GUI not withstanding).
You keep using this word "real-time". I don't think it means what you think it means. Did data transfers rates over the Internet reach infinity and I didn't notice?
I think any writer who takes predictions from Larry Ellison seriously has zero credibility. What happened to the network computers we were all supposed to be using the last 7 years?
Karnaugh maps were traditionaly used by hardware logic designers to minimize the number of gates required to implement a logical function at the bit level.
If the system uses a single byte that means you have 256 possible states. If you have two bytes it's 65,536 states and so on. I don't think you want to draw a Karnaugh map for something like Emacs, you won't live long enough.
That's what I mean by fine-grained state, a single state of the system is defined by the state of all the bits in the system.
A course-grained state implies a higher level of abstraction. Like in a communications protocol when they say waiting for an Ack is a state.
Well, a lot depends on the granularity of the "states" you're talking about. It's generally impractical to design a fine-grained state machine for anything but the simplest system because of state explosion.
Even if the result can be thought of as a state machine, it's often better not to model it as one.
"Closed source was to a great extent an invention of Microsoft."
Well, I guess when you add the phrase "to a great extent" just about anything could be true. The fact is that MS was not the first company to keep it's source code private and consequently did not invent closed source. Perhaps you work for the US patent office and therefore have no sense of prior art.
In your alternate universe, if Win32 was destroyed tomorrow, then there must not be very many programmers using it today. So it wouldn't affect many people. Of course, it's your universe, it doesn't have to follow the logic of ours.
In looking at MS's design guidelines, I'm struck by how big the learning curve appears to be.
One of the main ideas behind guidelines is supposed to be that consistency will result in more programmer productivity because the programmer will recognize new aspects more quickly.
The question is: Does the time it takes to learn the guidelines so they are second nature exceed the time saved by avoiding a lookup of a function or having to come up with your own name?
Guidelines are an engineering product just as much as code, and as such, they should be subject to the same cost/benefit tradeoff as anything else. I wonder how often in practice this analysis is actually done.
Well, running on a server is a different scenario. If the UI is a web browser, and the server app doesn't need to run under different OS's, it doesn't really matter what language is used to implement the app as long as it can deliver html to the clients (at least from a cross-platform point of view).
Of course, a web browser UI is a compromise in itself. As you say, sometimes there are good reasons not to adjust to every platform, but you always lose something in the trade-off.
"Questions on the survey suggest Sun is considering moving away from a crossplatform look and feel (eg, Metal) towards native looks by default."
Of course, a true cross-platform application should have the same look and feel on every platform.
That's the problem with all these cross-platform technologies like Java, you always end up with an non-optimal solution. If an application can't take advantage of platform-specific features, why bother having multiple platforms?
Based on your definitions, I think most companies want 95% code-monkeys, because independent thinking on the part of rank and file programmers is not considered desirable.
If the companies design systems made of both hardware and software the percentage rises to 100%. In those companies, only hardware designers are allowed to perform system level design even if that design indirectly dictates a software architecture.
"No, I don't think it would be an easy question to hedge on, and I think most people would respond honestly"
And you base this conclusion on...?
"Also, just because someone was recently doing primarily Windows development, doesn't mean they don't have five to ten years of UNIX before that."
But that's my point. People in the situation you describe were both Windows developers and Unix developers, so it would be misleading to claim this is exclusively a Windows to Linux switch. It's more like a switch from Unix to Linux with a brief stop at Windows along the way.
But isn't there a vested interest in Linux developers to debunk the "myth" that more Linux developers came from Unix than Windows? Isn't this the sort of question that is pretty easy to hedge on?
Jumping from developing Windows apps to Linux apps without Unix experience is obviously much more difficult than switching from Unix to Linux. Given that fact, I'm going to remain a skeptic until a more scientific study comes to the same conclusion.
All of these process "things" like CMM are really just about having written policies and following them. They have nothing to do with the quality of anything unless you measure quality as conformance to the process (which would be a circular argument).
Getting SEI certification is about paying the right consultants and having at least a plausible story about meeting a particular CMM level.
The biggest problem I have with these things is that there really isn't any proof that a standardized approach is helpful. Once you are certified the assumption is made that you are better across the board. So if the Ford corporation is certified, all of Ford's cars are of high quality because they followed the same process.
I prefer the UL model of quality. Each product has to be individually evaluated for quality no matter what process was used to create it. That is much tougher and more expensive method so it's not popular with companies and the government who are looking for a low cost quality stamp.
Slashdot Mirror
"He's always claimed to be an 'evangelist', not a 'representative'"
From Bruce's post:
"But I speak for a reasonable portion of the Free Software community"
That sounds like a claim of being a representative to me.
Make that "XAML" not "AXML". One down, 99,999 to go.
"Win32 has like 76,000 APIs, and they're taking it down to 8,000 with Longhorn technology"
The question is will they be adding 100,000 new things to learn in AXML in order to replace the 68,000 lost APIs?
All of Larry Ellison's predictions have turned out to be wrong so far, so don't worry.
He can certainly ask the FSF their opinion out of a desire to be a "good citizen", but remember, the only legally relevent interpreters of the GPL are the courts. With no GPL trial record available, a lawyer is unlikley to provide much insight either.
I was referring to the original UI design of Unix, which I believe was exclusively a command line interface (feel free to correct me if I'm wrong).
Having said that, you gave a nice summary of contemporary UI's for Unix.
It's true that OSX isn't based on the original Unix, but irony doesn't require 100% logic.
In other words, the user interface is a command line which is exactly the "problem" that the Mac "solved". Thus the irony.
I didn't say anything about the Next Cube's coolness. I just said the marketplace didn't value it.
If Unix wasn't a command line technology what method did the inventors use to communicate with the kernel. Certainly not a GUI.
I'm suspicious that the real reason Apple took the course they did was to provide cover for bailing out Job's Next company. A company that also flushed a lot of money down the toilet and never produced anything the market found desirable. By having Apple buy it, Job's created the illusion that there was something of value there.
The real irony is that Jobs zealots (as opposed to old fashioned Apple product zealots) would swallow the idea that Apple's future depended on adopting an OS based on a quarter-century-old command-line technology (wrapped in a GUI not withstanding).
You keep using this word "real-time". I don't think it means what you think it means. Did data transfers rates over the Internet reach infinity and I didn't notice?
I think any writer who takes predictions from Larry Ellison seriously has zero credibility. What happened to the network computers we were all supposed to be using the last 7 years?
Karnaugh maps were traditionaly used by hardware logic designers to minimize the number of gates required to implement a logical function at the bit level.
If the system uses a single byte that means you have 256 possible states. If you have two bytes it's 65,536 states and so on. I don't think you want to draw a Karnaugh map for something like Emacs, you won't live long enough.
That's what I mean by fine-grained state, a single state of the system is defined by the state of all the bits in the system.
A course-grained state implies a higher level of abstraction. Like in a communications protocol when they say waiting for an Ack is a state.
So this is what I mean by granularity.
Well, a lot depends on the granularity of the "states" you're talking about. It's generally impractical to design a fine-grained state machine for anything but the simplest system because of state explosion.
Even if the result can be thought of as a state machine, it's often better not to model it as one.
"Closed source was to a great extent an invention of Microsoft."
Well, I guess when you add the phrase "to a great extent" just about anything could be true. The fact is that MS was not the first company to keep it's source code private and consequently did not invent closed source. Perhaps you work for the US patent office and therefore have no sense of prior art.
In your alternate universe, if Win32 was destroyed tomorrow, then there must not be very many programmers using it today. So it wouldn't affect many people. Of course, it's your universe, it doesn't have to follow the logic of ours.
In looking at MS's design guidelines, I'm struck by how big the learning curve appears to be.
One of the main ideas behind guidelines is supposed to be that consistency will result in more programmer productivity because the programmer will recognize new aspects more quickly.
The question is: Does the time it takes to learn the guidelines so they are second nature exceed the time saved by avoiding a lookup of a function or having to come up with your own name?
Guidelines are an engineering product just as much as code, and as such, they should be subject to the same cost/benefit tradeoff as anything else. I wonder how often in practice this analysis is actually done.
Well, running on a server is a different scenario. If the UI is a web browser, and the server app doesn't need to run under different OS's, it doesn't really matter what language is used to implement the app as long as it can deliver html to the clients (at least from a cross-platform point of view).
Of course, a web browser UI is a compromise in itself. As you say, sometimes there are good reasons not to adjust to every platform, but you always lose something in the trade-off.
"Questions on the survey suggest Sun is considering moving away from a crossplatform look and feel (eg, Metal) towards native looks by default."
Of course, a true cross-platform application should have the same look and feel on every platform.
That's the problem with all these cross-platform technologies like Java, you always end up with an non-optimal solution. If an application can't take advantage of platform-specific features, why bother having multiple platforms?
Based on your definitions, I think most companies want 95% code-monkeys, because independent thinking on the part of rank and file programmers is not considered desirable.
If the companies design systems made of both hardware and software the percentage rises to 100%. In those companies, only hardware designers are allowed to perform system level design even if that design indirectly dictates a software architecture.
I am exaggerating a little, but not much.
Thanks for reminding me why I hated it so much. I saw it in the theater long ago and forgot.
I thought Time Bandits sucked. I just don't get Terry Gilliam I guess.
"No, I don't think it would be an easy question to hedge on, and I think most people would respond honestly"
...?
And you base this conclusion on
"Also, just because someone was recently doing primarily Windows development, doesn't mean they don't have five to ten years of UNIX before that."
But that's my point. People in the situation you describe were both Windows developers and Unix developers, so it would be misleading to claim this is exclusively a Windows to Linux switch. It's more like a switch from Unix to Linux with a brief stop at Windows along the way.
But isn't there a vested interest in Linux developers to debunk the "myth" that more Linux developers came from Unix than Windows? Isn't this the sort of question that is pretty easy to hedge on?
Jumping from developing Windows apps to Linux apps without Unix experience is obviously much more difficult than switching from Unix to Linux. Given that fact, I'm going to remain a skeptic until a more scientific study comes to the same conclusion.
All of these process "things" like CMM are really just about having written policies and following them. They have nothing to do with the quality of anything unless you measure quality as conformance to the process (which would be a circular argument).
Getting SEI certification is about paying the right consultants and having at least a plausible story about meeting a particular CMM level.
The biggest problem I have with these things is that there really isn't any proof that a standardized approach is helpful. Once you are certified the assumption is made that you are better across the board. So if the Ford corporation is certified, all of Ford's cars are of high quality because they followed the same process.
I prefer the UL model of quality. Each product has to be individually evaluated for quality no matter what process was used to create it. That is much tougher and more expensive method so it's not popular with companies and the government who are looking for a low cost quality stamp.
I'm just responding to show you that at least one other person knows what you're talking about.