This isn't the only one. There are a bunch of those kinds of display technologies in the pipeline: basically, LCD displays, but with small scall structures that increase contrast, viewing angle, and persistence.
It's a good short term solution because switching manufacturing over to those kinds of technologies should be fairly easy.
The disadvantage is that those are still heavy glass sandwidches, with all the problems that brings with it. eInk, OLED, and other new display technologies give far more flexible and lightweight displays, and promise significant weight savings.
Quartz 2D is not, and has never been, "Display PDF." Quartz 2D is a display-list drawing API that uses a drawing model that's very similar to PDF.
PDF is just a serialized version of a "display list" (well, it's a more general object model, but it's a bunch of graphical objects in a hierarchy). Apple describes Quartz as "Display PDF", and that is really basically what it is. I don't see why you get so pushed out of shape over that.
Note that X11 is not initially putting in server-side display lists; there is no pressing need for them. They'll probably make it in as an extension later, and then they'll probably mirror SVG closely.
mo X needs an overhaul, needs to ditch the legacy crap (lose Xaw for example)
X11 is a protocol. Xaw is not part of the protocol. It was "ditched" long ago. People still use it because they still have applications that depend on it, but that doesn't need to bother you.
stop interfacing with video hardware like it's 1980.
I don't know what that is supposed to mean. X11 has numerous server implementations that interface with hardware in all sorts of ways. Many commercial and workstation X11 implementations have had dedicated hardware acceleration for more than a decade. What more do you want?
If you are saying that XFree86's architecture is a bit dusty, well maybe you are right, but XFree86 isn't X11, it's one of many implementations.
X11 on OS X is dog slow compared to running X11 natively. In fact, Quartz itself is dog slow for text rendering. And that's not surprising: contrary to what you are stating, the use Quartz makes of hardware acceleration is still quite limited.
If XGL is fully OpenGL accelerated, it is leapfrogging anything Apple has implemented in Quartz today.
The genie effect on OS X looks cool and is fast because of the hardware compositing going on. But more importantly, it's a quick visual cue to show you that you have just minimized a window, and it travelled down to the second spot on the right of your dock, so you know where it is.
Note that some X11 window managers have had such features long before OS X even existed (and many still do). They didn't warp the window, but they showed the window rectangle itself zooming down to a dock or icon.
It goes beyond animation effects, too. People have commented on OS X's "gumdrop" window controls, which look cute and friendly, but few seem to notice they're arranged like a traffic light, which is intuitive for most people. Red, yellow, and green circles--red closes the window, yellow minimizes, and green zooms.
Not as friendly as "X", "big window", and "little window", which have become pretty much universally recognized for this purpose and whose shape is actually mnemonic.
Note that I use OS X as an example simple because I think it's the undisputed king of GUI visual cues.
All these things have been explored long before Aqua. Overall, I think Aqua is a pretty mixed bag in terms of "visual cues" and usability in general.
They did use OpenGL for [Quartz], but only in a very limited way. Each window is represented as a texture on a surface and fed to the graphics pipeline for compositing.
Let's just remember that, shall we: Quartz uses OpenGL acceleration only in a very limited way, because Apple fanboys always scream bloody murder when people make that statement.
Quartz is amazing. Nothing else in the world comes anywhere close to it,
Display lists as the basis for graphical user interfaces are ancient. DisplayPostscript also basically did the same thing. Tk and Gnome both have had vector-based canvases for a long time, and both use them for creating complex widgets. Zoomable toolkits have offered the same functionality and then some.
There is very little that is new about Quartz-like engines. The reason they haven't been used widely before is because they are memory and CPU intensive (and it shows with Quartz, which is a real resource hog compared to X11). But machines are now fast enough to ship those kinds of display engines for day-to-day applications, so everybody is doing it. Apple, as usual, was a little quicker to market, for the usual reasons: they charge a premium for their machines so they can afford to put expensive features into it, and they don't worry about compatibility with anybody else.
The nice thing about X11 support for these features is that X11 will remain fully backwards compatible.
The alternative would be locking up those people--expensive, and it only makes people crazier. This way, the victim is fairly well protected, the offender can work for a living, and he or she may actually gradually return to a normal life as well.
If that's true, why is enforcement necessary? If this is truly a desirable course of action which will only have a positive effect, why must companies be forced to undertake it? Why aren't they doing it voluntarily, if it's so obviously the best and most profitable thing to do?
Gosh, did you even bother to read the rest of the message? Existing large companies would be forced to make massive investments in new hardware, something that cuts deeply into their profits. The jobs and economic benefits accrue to companies that are currently fairly small but that have the technology. Since the existing large companies have the political clout, their preferences get heard.
This is the same question I ask statists about taxes, which are collected coercively under the same bogus justification.
I'm not sure what you mean by "statists" or "collected coercively" (aren't taxes by their veyr nature coercive?), but, in general, the purpose of taxes is to pay for public goods. Public goods are things that the market will not produce efficiently on its own, things like research, the environment, and national defense.
You may be living in a dream world where public goods don't exist, but their existance and fundamental importance to economic systems is about as much of a fact as gravity or light in physics.
The notion of effectively throwing out a lot of existing hardware and replacing it with new, more energy efficient hardware produced by a diverse group of companies should have economists and politicians licking their fingers.
Instead, they are listening to a tiny number of very powerful lobbies: the car companies, the oil companies, and the power producing companies. For them, of course, the move to energy efficient technology means that they have to make investments, investments that they would rather take as profits (or at least not have to borrow in order to make).
But that's just it: if those investments were made, it would provide a huge economic boon that would help the economy greatly, creating just the kinds of jobs we like: manufacturing, high-tech, design, software. It would also be an opportunity to modernize our aging infrastructure in many industries, as well as provide the necessary pressure to de-subsidize automobiles and support a modern and convenient system of public transit (which yields yet more jobs and other benefits).
So now that we've reached this postmodern understanding that all official corporate communication is, if not a charade, part of a ritualized dance where meaning must be divined between the lines,
In Soviet Russia, people reached that understanding decades ago for all official corporations. Obviously, they were far ahead of their time. Of course, the poor suckers didn't have much of a choice than to figure it out--their lives depended on it every day; for us, most of the time, the consequence of figuring out corporate messages just comes down to whether we buy Coke or Pepsi.
Seriously, this is no coincidence: modern political propaganda was invented during WWI in the US by people like Bernays. After WWI, the now out-of-work folks started writing books and selling their services to the private sector. Their "Torches of Freedom" campaign made smoking instantly acceptable for women (even though Bernays himself already believed that smoking was bad and forbade his daughter to smoke). Goebbels picked up Bernays's methods for the Nazis (from Bernay's published works), and I suspect the communist movement used it as well. After that, this has been pretty much the standard way for any large organization to communicate with rest of us--it is standard textbook stuff.
For better or worse, Star Trek is what it is: something that was vaguely based on Forbidden Planet, became a cult series in the 1960's, and then evolved into some politicially correct somewhat socialist utopia.
We can look at the kinds of series Straczynski has been producing, and that's not it. B5 and Jeremiah are fun series in their own right, but they are rather different, both in outlook and in style.
I'm not sure Star Trek needs to continue at all, after the success and longevity it has had. But if it should, it probably should do so in its own particular way and style, and for that, I think someone else may be better suited.
I imagine it would be in the form of a counterattack. That is, if someone tries to sue you, you check if they're breaking any patents you own and threaten to sue them back.
Yes, that is one use for patents. But once you have that weapon, you can use it for all sorts of other "defensive" purposes as well, like, for example, when someone is competing with you, you don't like it, and so you just threaten them with a patent infringement lawsuit. And companies regularly use their patent portfolios for that.
<sarcasm>Oh my God, I didn't realize that. If it's based on Java, then, obviously, it must be complete junk.</sarcasm>
Seriously, how shallow and inane can you Apple fanboys get? Of course, C# is based on Java. Even Java, with all its flaws, is a fairly well designed programming language, and C# fixes most of its problems. Both C# and Java are fairly dull and conservative languages as far as languages go, but at least they get the basics right: memory management, static typing, reflection, and runtime safety.
Objective C sacrificed all of those in the name of C compatibility. Well, guess what, the tradeoffs Objective C made were questionable even in the 1980's (which is why it was such a dud), and they make no sense whatsoever anymore in 2005.
In fact I'm having a hard time imagining a type of metric that you WOULD consider valid. Care to explain?
The problem is that a "maintainability index" claims to measure something called "maintainability", but how it defines "maintainability" is arbitrary and ad hoc. What it calls "maintainability" has a priori nothing to do with what "maintainability" means to a software practitioner, namely predicting how much effort and money fixing bugs and adding features will take over time.
There are lots of "metrics" (in the SE sense, i.e., things you can measure about code, not in the mathematical sense) that don't suffer from that problem. You can easily define and measure what LOC or man months or cyclomatic complexity mean. Those are metrics where it is perfectly valid to say that "if you find them useful, you use them" because they don't pretend to measure anything other than pretty straightforward code properties. When people use those metrics, they generally calibrate them themselves for their own environments, so the user of those metrics determines how properties like maintainability and cost depend on those measured code properties.
So, you can't just attach arbitrary names to some ad hoc combination of code complexity measures; as this paper shows, if you call something a "maintainability index", people are going to use it as such, and the fault is partly with naming it incorrectly. The term "maintainability index" should be reserved for what the term suggests: a numerical value whose order (but not necessarily magnitude) reflects as closely as possible the amount of money and effort required to maintain a software project.
Very few patent disputes with big companies ever become lawsuits, and it takes a while for lawsuits over patents to be filed (in fact, it can be in the interest of companies to wait a while). Microsoft has only started getting on the patent bandwagon fairly recently and they have already been throwing their weight around with patent-related threats.
Furthermore, the notion of "defensive patents" is nonsense. In order to defend an idea against a patent claim, all you need to do is publish it (you still need the lawyers to actually win in court, but you need those also if you have a patent).
The term "defensive patent" is really a euphemism for becoming a member of a patent cartel: the "giants" that Gates talks about, companies like IBM, Apple, Xerox, etc., have amassed huge patent portfolios that they are cross licensing. As a result, they can operate almost completely free of worries over patent infringement, while small companies that don't have cross licensing agreements are at constant risk of being put out of business by any member of that club. Well, Gates's solution to the problem has been to become a member of the cartel.
Well, our notions of "innovation" obviously differ. You think that if Apple hacks in standard more modern functionality (mostly copied from other systems) and performs some maintenance, that's "innovation"; I'm sorry, but I disagree with that.
The basic fact remains: OS X is fundamentally 1980's technology. While the kernel and the display system are still usable, the worst part of the whole thing is Objective-C, which was a mediocrity even in the 1980's and is thoroughly outdated 20 years later.
But we don't have to argue about it: I think the market will show that OS X has no chance against either Windows or Linux. In fact, much as I dislike Microsoft software,.NET and its development tools are already orders of magnitude better than the junk Apple is shipping for APIs and development tools.
In practice, people use the term "percentage" to mean parts-in-100 OR a fraction
Numerically, it only means one thing: "fraction or ratio with 100 understood as the denominator". If you are using it in any other way, you are using it incorrectly.
The fact that colloquially people confuse the two sometimes is no excuse. Colloquially, people also confuse "power", "strength", and "force", but as an engineer, you better keep them straight; that's part of your job.
Look at the second definition listed in the dictionary. It's a "part of a whole."
Yes, but not as a numerical value.
Nobody ever implied that the number has any statistical validity, it is just a number which happens to do a fairly good job at helping people compare things. If it's useful to you, use it. If not, don't.
So, you agree then: the maintainability index is bullshit because nobody has established that it actually tells us anything about the maintainability of software. It simply is a number that everybody can determine for themselves whether they find useful.
Of course, that means that the paper we are talking about has no significance: since its measure of maintainability has not been validated, we can draw no conclusions about the maintainability of OSS from the MI.
As far as I'm concerned, USENET died when people started making searchable archives of it available. I had been using USENET since the 1980s, and, while it had some problems, it was a discussion forum where people discussed things freely and under their own names. USENET also was mostly a mix of academics, students, and corporate computer geeks. Binary newsgroups and postings were few, but the comp.sources newsgroups were the primary vehicle for the distribution of open source software. People got to know each other personally and even made professional contacts.
Once you had to worry about any hasty post coming back to haunt you a decade later, I stopped using it. And the influx of huge numbers of other users also made it a lot less fun for me.
I'm sure a new generation of USENET users found other uses for USENET, after the community changed and after DejaNews came into existence. But that USENET isn't the USENET I grew up with--it's already something different.
First of all, perCM ranges from 0 to 1, not 0 to 100. Yes, that isn't explicitly stated,
Oh, it is quite explicitly stated: perCM is described as a "percentage" (as in "per hundred"), so it ranges from 0 to 100, not 0 to 1. If you are saying that it ranges from 0 to 1, then the description is wrong; the proper term for that is a "fraction". You would think that software engineers, of all people, would be sensitive to using the right names and units, but apparently not.
What this is saying is that the benefit of comments has a maximum at around 3%. Having more comments than this tends to DECREASE the maintainability (and this is borne out by experience).
Well, what you illustrate again is that the MI is a seat-of-the-pants kind of measure that was thrown together because it looks nice, not because anybody thought about statistical validity.
Using tools such as MI derived for measuring CSS quality, OSS code quality appears to be at least equal and sometimes better than the quality of CSS code implementing the same functionality.
So, apparently, the authors think that OSS is as a general rule better than CSS from a maintainability point of view.
You can find a description of the maintainability index here.
If you look at the desription, you'll see that the equation was mainly "calibrated" based on a bunch of projects at HP. But fitting such an equation to a handful of self-selected projects doesn't give you any idea of how statistically valid it is.
Furthermore, the maintainability index contains measures that you would expect to go up as software systems become bigger; therefore, it isn't even a meaningful comparison of software systems of different size (or a single software system over time): maintaining a 1MLOC project is just a lot harder than maintaining a 100kloc project, but you may be doing equally well on both of them.
Particularly amusing is a term of 50 * sin (sqrt(2.4 * perCM)) in the maintainability index, where perCM is the average percentage of comment lines per module. As perCM ranges from 0 to 100, the argument for the sin(.) function will range from 0 to 15 (ponder for yourself what that means about how much you should comment).
Until someone produces sound maintainability data with hundreds of software projects, the use of MI is just bullshit.
Why not just raise gas taxes to make up for the more fuel efficient fleet? That way, revenues can stay the same, but the incentive to switch to more fuel efficient vehicles remains.
Given what is driving around on California roads, fuel efficient cars can't have made such a big dent yet anyway, so the size of the increase should remain modest.
What DejaNews did to USENET was actually worse than merely not helping it--I think they destroyed it. What used to be an informal discussion forum where people could have frank conversations turned into something where every word you wrote was archived in perpetuity, under your real name. As a result, people went to other media, or at least started using anonymous accounts.
In general, making information easy to get to changes the use people make of that information. Sometimes that's for the better, and sometimes it's for the worse.
Let's start at the beginning: Yes, elements of the Mac OS are based on UNIX. But only stuff like the scheduler and the process model. The kernel itself and fundamental things like interprocess communication are based on Mach, not UNIX. And, of course, none of the user experience has anything to do with UNIX.
Yes, and when do you think Mach was created? In 1985. The BSD APIs that a lot of OS X software actually uses are from the 1970's and early 1980's. The OS X kernel is a combination of a failed OS project from CMU, coupled with a wildly successful open source OS project from Berkeley, both 20 years old.
Mac OS X really has nothing to do with PostScript. The Quartz 2D drawing model was deliberately designed to be very similar to PDF, making it trivial to translate from PDF to Quartz 2D and back, but that's really where it ends. The window-drawing subsystem -- Quartz Compositor, now Quartz Extreme --has nothing to do with either PDF or PostScript.
Quartz is a "PDF engine" (Apple's own words), which replaces DisplayPostscript in NeXTStep. It is an moderate improvement over DisplayPostscript, in that it prohibits arbitrary Postscript programmability, but other than that, it has many of the same problems.
Yes, the Objective-C language dates back quite a ways, but programs written for the Mac have about as little to do with the Objective-C language itself as programs written for Windows have to do with the C language itself.
Programs you write in 2005 for Cocoa look almost identical to the programs you would have written in the 80's for NeXT. GNUStep, which followed the NeXTStep/OpenStep programming model closely, is also very close to Cocoa.
It's not like somebody in Cupertino just decided one day that everything invented since 1988 was crap and that the wave of the future would be retro-innovation. Not at all.
They hired Jobs and whatever software came with him. That happened to be NeXTStep.
So you see, to imply that Mac OS X is based on 80s-era technologies is just plain misleading.
I'm not "implying" that, it's a fact: Mac OS X is basically NeXTStep with a few tweaks and theming. For you to imply that OS X is brand new technology is just ridiculous. The OS X kernel, toolkit, programming model, programming language, and technology are all old stuff.
And the problem with it being retro-technology is that it really has lots of limitations, which Apple is trying to address through clever marketing and naming, rather than technological improvements and innovation.
How is that any different from the fact that a Linux kernel hacker should never look at closed MS WinNT kernel sources (even with permission)
It's different because Microsoft isn't pretending that their NT kernel is open or free; they make you jump through hopps to look at it. But Sun is pretending that their available source is "open". It's Sun's lies and misrepresentations, not their licenses, that is the problem.
and an MS WinNT kernel hacker should never look at GPLed Linux kernel sources?
They can look all they want; the GPL allows this and there is no serious legal risk associated with that, in particular, since GPL'ed code is less likely to be infested with patents. MS may have rules against it, but those rules are overly cautious. What they can't do is cut-and-paste.
Microsoft has similar licenses, by the way: "we own it, but we explicitly allow you to look all you want with no consequences".
At what point does reimplementing an algorithm you saw (in code) somewhere else stop being code theft?
Reimplementing is never "code theft". The only thing you have to worry about is patents. You have to be careful that if it looks too close to the original, people may successfully claim copyright infringement, and the best defense is to be able to say "I have never seen the original code", but that's a precautionary practical measure, not an intended restriction of copyright law.
Slashdot Mirror
This isn't the only one. There are a bunch of those kinds of display technologies in the pipeline: basically, LCD displays, but with small scall structures that increase contrast, viewing angle, and persistence.
It's a good short term solution because switching manufacturing over to those kinds of technologies should be fairly easy.
The disadvantage is that those are still heavy glass sandwidches, with all the problems that brings with it. eInk, OLED, and other new display technologies give far more flexible and lightweight displays, and promise significant weight savings.
Quartz 2D is not, and has never been, "Display PDF." Quartz 2D is a display-list drawing API that uses a drawing model that's very similar to PDF.
PDF is just a serialized version of a "display list" (well, it's a more general object model, but it's a bunch of graphical objects in a hierarchy). Apple describes Quartz as "Display PDF", and that is really basically what it is. I don't see why you get so pushed out of shape over that.
Note that X11 is not initially putting in server-side display lists; there is no pressing need for them. They'll probably make it in as an extension later, and then they'll probably mirror SVG closely.
mo X needs an overhaul, needs to ditch the legacy crap (lose Xaw for example)
X11 is a protocol. Xaw is not part of the protocol. It was "ditched" long ago. People still use it because they still have applications that depend on it, but that doesn't need to bother you.
stop interfacing with video hardware like it's 1980.
I don't know what that is supposed to mean. X11 has numerous server implementations that interface with hardware in all sorts of ways. Many commercial and workstation X11 implementations have had dedicated hardware acceleration for more than a decade. What more do you want?
If you are saying that XFree86's architecture is a bit dusty, well maybe you are right, but XFree86 isn't X11, it's one of many implementations.
X11 on OS X is dog slow compared to running X11 natively. In fact, Quartz itself is dog slow for text rendering. And that's not surprising: contrary to what you are stating, the use Quartz makes of hardware acceleration is still quite limited.
If XGL is fully OpenGL accelerated, it is leapfrogging anything Apple has implemented in Quartz today.
The genie effect on OS X looks cool and is fast because of the hardware compositing going on. But more importantly, it's a quick visual cue to show you that you have just minimized a window, and it travelled down to the second spot on the right of your dock, so you know where it is.
Note that some X11 window managers have had such features long before OS X even existed (and many still do). They didn't warp the window, but they showed the window rectangle itself zooming down to a dock or icon.
It goes beyond animation effects, too. People have commented on OS X's "gumdrop" window controls, which look cute and friendly, but few seem to notice they're arranged like a traffic light, which is intuitive for most people. Red, yellow, and green circles--red closes the window, yellow minimizes, and green zooms.
Not as friendly as "X", "big window", and "little window", which have become pretty much universally recognized for this purpose and whose shape is actually mnemonic.
Note that I use OS X as an example simple because I think it's the undisputed king of GUI visual cues.
All these things have been explored long before Aqua. Overall, I think Aqua is a pretty mixed bag in terms of "visual cues" and usability in general.
They did use OpenGL for [Quartz], but only in a very limited way. Each window is represented as a texture on a surface and fed to the graphics pipeline for compositing.
Let's just remember that, shall we: Quartz uses OpenGL acceleration only in a very limited way, because Apple fanboys always scream bloody murder when people make that statement.
Quartz is amazing. Nothing else in the world comes anywhere close to it,
Display lists as the basis for graphical user interfaces are ancient. DisplayPostscript also basically did the same thing. Tk and Gnome both have had vector-based canvases for a long time, and both use them for creating complex widgets. Zoomable toolkits have offered the same functionality and then some.
There is very little that is new about Quartz-like engines. The reason they haven't been used widely before is because they are memory and CPU intensive (and it shows with Quartz, which is a real resource hog compared to X11). But machines are now fast enough to ship those kinds of display engines for day-to-day applications, so everybody is doing it. Apple, as usual, was a little quicker to market, for the usual reasons: they charge a premium for their machines so they can afford to put expensive features into it, and they don't worry about compatibility with anybody else.
The nice thing about X11 support for these features is that X11 will remain fully backwards compatible.
The alternative would be locking up those people--expensive, and it only makes people crazier. This way, the victim is fairly well protected, the offender can work for a living, and he or she may actually gradually return to a normal life as well.
If that's true, why is enforcement necessary? If this is truly a desirable course of action which will only have a positive effect, why must companies be forced to undertake it? Why aren't they doing it voluntarily, if it's so obviously the best and most profitable thing to do?
Gosh, did you even bother to read the rest of the message? Existing large companies would be forced to make massive investments in new hardware, something that cuts deeply into their profits. The jobs and economic benefits accrue to companies that are currently fairly small but that have the technology. Since the existing large companies have the political clout, their preferences get heard.
This is the same question I ask statists about taxes, which are collected coercively under the same bogus justification.
I'm not sure what you mean by "statists" or "collected coercively" (aren't taxes by their veyr nature coercive?), but, in general, the purpose of taxes is to pay for public goods. Public goods are things that the market will not produce efficiently on its own, things like research, the environment, and national defense.
You may be living in a dream world where public goods don't exist, but their existance and fundamental importance to economic systems is about as much of a fact as gravity or light in physics.
The notion of effectively throwing out a lot of existing hardware and replacing it with new, more energy efficient hardware produced by a diverse group of companies should have economists and politicians licking their fingers.
Instead, they are listening to a tiny number of very powerful lobbies: the car companies, the oil companies, and the power producing companies. For them, of course, the move to energy efficient technology means that they have to make investments, investments that they would rather take as profits (or at least not have to borrow in order to make).
But that's just it: if those investments were made, it would provide a huge economic boon that would help the economy greatly, creating just the kinds of jobs we like: manufacturing, high-tech, design, software. It would also be an opportunity to modernize our aging infrastructure in many industries, as well as provide the necessary pressure to de-subsidize automobiles and support a modern and convenient system of public transit (which yields yet more jobs and other benefits).
So now that we've reached this postmodern understanding that all official corporate communication is, if not a charade, part of a ritualized dance where meaning must be divined between the lines,
In Soviet Russia, people reached that understanding decades ago for all official corporations. Obviously, they were far ahead of their time. Of course, the poor suckers didn't have much of a choice than to figure it out--their lives depended on it every day; for us, most of the time, the consequence of figuring out corporate messages just comes down to whether we buy Coke or Pepsi.
Seriously, this is no coincidence: modern political propaganda was invented during WWI in the US by people like Bernays. After WWI, the now out-of-work folks started writing books and selling their services to the private sector. Their "Torches of Freedom" campaign made smoking instantly acceptable for women (even though Bernays himself already believed that smoking was bad and forbade his daughter to smoke). Goebbels picked up Bernays's methods for the Nazis (from Bernay's published works), and I suspect the communist movement used it as well. After that, this has been pretty much the standard way for any large organization to communicate with rest of us--it is standard textbook stuff.
For better or worse, Star Trek is what it is: something that was vaguely based on Forbidden Planet, became a cult series in the 1960's, and then evolved into some politicially correct somewhat socialist utopia.
We can look at the kinds of series Straczynski has been producing, and that's not it. B5 and Jeremiah are fun series in their own right, but they are rather different, both in outlook and in style.
I'm not sure Star Trek needs to continue at all, after the success and longevity it has had. But if it should, it probably should do so in its own particular way and style, and for that, I think someone else may be better suited.
I imagine it would be in the form of a counterattack. That is, if someone tries to sue you, you check if they're breaking any patents you own and threaten to sue them back.
Yes, that is one use for patents. But once you have that weapon, you can use it for all sorts of other "defensive" purposes as well, like, for example, when someone is competing with you, you don't like it, and so you just threaten them with a patent infringement lawsuit. And companies regularly use their patent portfolios for that.
It's based on Java, for crying out loud.
<sarcasm>Oh my God, I didn't realize that. If it's based on Java, then, obviously, it must be complete junk.</sarcasm>
Seriously, how shallow and inane can you Apple fanboys get? Of course, C# is based on Java. Even Java, with all its flaws, is a fairly well designed programming language, and C# fixes most of its problems. Both C# and Java are fairly dull and conservative languages as far as languages go, but at least they get the basics right: memory management, static typing, reflection, and runtime safety.
Objective C sacrificed all of those in the name of C compatibility. Well, guess what, the tradeoffs Objective C made were questionable even in the 1980's (which is why it was such a dud), and they make no sense whatsoever anymore in 2005.
In fact I'm having a hard time imagining a type of metric that you WOULD consider valid. Care to explain?
The problem is that a "maintainability index" claims to measure something called "maintainability", but how it defines "maintainability" is arbitrary and ad hoc. What it calls "maintainability" has a priori nothing to do with what "maintainability" means to a software practitioner, namely predicting how much effort and money fixing bugs and adding features will take over time.
There are lots of "metrics" (in the SE sense, i.e., things you can measure about code, not in the mathematical sense) that don't suffer from that problem. You can easily define and measure what LOC or man months or cyclomatic complexity mean. Those are metrics where it is perfectly valid to say that "if you find them useful, you use them" because they don't pretend to measure anything other than pretty straightforward code properties. When people use those metrics, they generally calibrate them themselves for their own environments, so the user of those metrics determines how properties like maintainability and cost depend on those measured code properties.
So, you can't just attach arbitrary names to some ad hoc combination of code complexity measures; as this paper shows, if you call something a "maintainability index", people are going to use it as such, and the fault is partly with naming it incorrectly. The term "maintainability index" should be reserved for what the term suggests: a numerical value whose order (but not necessarily magnitude) reflects as closely as possible the amount of money and effort required to maintain a software project.
Very few patent disputes with big companies ever become lawsuits, and it takes a while for lawsuits over patents to be filed (in fact, it can be in the interest of companies to wait a while). Microsoft has only started getting on the patent bandwagon fairly recently and they have already been throwing their weight around with patent-related threats.
Furthermore, the notion of "defensive patents" is nonsense. In order to defend an idea against a patent claim, all you need to do is publish it (you still need the lawyers to actually win in court, but you need those also if you have a patent).
The term "defensive patent" is really a euphemism for becoming a member of a patent cartel: the "giants" that Gates talks about, companies like IBM, Apple, Xerox, etc., have amassed huge patent portfolios that they are cross licensing. As a result, they can operate almost completely free of worries over patent infringement, while small companies that don't have cross licensing agreements are at constant risk of being put out of business by any member of that club. Well, Gates's solution to the problem has been to become a member of the cartel.
Well, our notions of "innovation" obviously differ. You think that if Apple hacks in standard more modern functionality (mostly copied from other systems) and performs some maintenance, that's "innovation"; I'm sorry, but I disagree with that.
.NET and its development tools are already orders of magnitude better than the junk Apple is shipping for APIs and development tools.
The basic fact remains: OS X is fundamentally 1980's technology. While the kernel and the display system are still usable, the worst part of the whole thing is Objective-C, which was a mediocrity even in the 1980's and is thoroughly outdated 20 years later.
But we don't have to argue about it: I think the market will show that OS X has no chance against either Windows or Linux. In fact, much as I dislike Microsoft software,
In practice, people use the term "percentage" to mean parts-in-100 OR a fraction
Numerically, it only means one thing: "fraction or ratio with 100 understood as the denominator". If you are using it in any other way, you are using it incorrectly.
The fact that colloquially people confuse the two sometimes is no excuse. Colloquially, people also confuse "power", "strength", and "force", but as an engineer, you better keep them straight; that's part of your job.
Look at the second definition listed in the dictionary. It's a "part of a whole."
Yes, but not as a numerical value.
Nobody ever implied that the number has any statistical validity, it is just a number which happens to do a fairly good job at helping people compare things. If it's useful to you, use it. If not, don't.
So, you agree then: the maintainability index is bullshit because nobody has established that it actually tells us anything about the maintainability of software. It simply is a number that everybody can determine for themselves whether they find useful.
Of course, that means that the paper we are talking about has no significance: since its measure of maintainability has not been validated, we can draw no conclusions about the maintainability of OSS from the MI.
As far as I'm concerned, USENET died when people started making searchable archives of it available. I had been using USENET since the 1980s, and, while it had some problems, it was a discussion forum where people discussed things freely and under their own names. USENET also was mostly a mix of academics, students, and corporate computer geeks. Binary newsgroups and postings were few, but the comp.sources newsgroups were the primary vehicle for the distribution of open source software. People got to know each other personally and even made professional contacts.
Once you had to worry about any hasty post coming back to haunt you a decade later, I stopped using it. And the influx of huge numbers of other users also made it a lot less fun for me.
I'm sure a new generation of USENET users found other uses for USENET, after the community changed and after DejaNews came into existence. But that USENET isn't the USENET I grew up with--it's already something different.
First of all, perCM ranges from 0 to 1, not 0 to 100. Yes, that isn't explicitly stated,
Oh, it is quite explicitly stated: perCM is described as a "percentage" (as in "per hundred"), so it ranges from 0 to 100, not 0 to 1. If you are saying that it ranges from 0 to 1, then the description is wrong; the proper term for that is a "fraction". You would think that software engineers, of all people, would be sensitive to using the right names and units, but apparently not.
What this is saying is that the benefit of comments has a maximum at around 3%. Having more comments than this tends to DECREASE the maintainability (and this is borne out by experience).
Well, what you illustrate again is that the MI is a seat-of-the-pants kind of measure that was thrown together because it looks nice, not because anybody thought about statistical validity.
From the conclusions:
Using tools such as MI derived for measuring CSS quality, OSS code quality appears to be at least equal and sometimes better than the quality of CSS code implementing the same functionality.
So, apparently, the authors think that OSS is as a general rule better than CSS from a maintainability point of view.
You can find a description of the maintainability index here.
If you look at the desription, you'll see that the equation was mainly "calibrated" based on a bunch of projects at HP. But fitting such an equation to a handful of self-selected projects doesn't give you any idea of how statistically valid it is.
Furthermore, the maintainability index contains measures that you would expect to go up as software systems become bigger; therefore, it isn't even a meaningful comparison of software systems of different size (or a single software system over time): maintaining a 1MLOC project is just a lot harder than maintaining a 100kloc project, but you may be doing equally well on both of them.
Particularly amusing is a term of 50 * sin (sqrt(2.4 * perCM)) in the maintainability index, where perCM is the average percentage of comment lines per module. As perCM ranges from 0 to 100, the argument for the sin(.) function will range from 0 to 15 (ponder for yourself what that means about how much you should comment).
Until someone produces sound maintainability data with hundreds of software projects, the use of MI is just bullshit.
Why not just raise gas taxes to make up for the more fuel efficient fleet? That way, revenues can stay the same, but the incentive to switch to more fuel efficient vehicles remains.
Given what is driving around on California roads, fuel efficient cars can't have made such a big dent yet anyway, so the size of the increase should remain modest.
What DejaNews did to USENET was actually worse than merely not helping it--I think they destroyed it. What used to be an informal discussion forum where people could have frank conversations turned into something where every word you wrote was archived in perpetuity, under your real name. As a result, people went to other media, or at least started using anonymous accounts.
In general, making information easy to get to changes the use people make of that information. Sometimes that's for the better, and sometimes it's for the worse.
Let's start at the beginning: Yes, elements of the Mac OS are based on UNIX. But only stuff like the scheduler and the process model. The kernel itself and fundamental things like interprocess communication are based on Mach, not UNIX. And, of course, none of the user experience has anything to do with UNIX.
Yes, and when do you think Mach was created? In 1985. The BSD APIs that a lot of OS X software actually uses are from the 1970's and early 1980's. The OS X kernel is a combination of a failed OS project from CMU, coupled with a wildly successful open source OS project from Berkeley, both 20 years old.
Mac OS X really has nothing to do with PostScript. The Quartz 2D drawing model was deliberately designed to be very similar to PDF, making it trivial to translate from PDF to Quartz 2D and back, but that's really where it ends. The window-drawing subsystem -- Quartz Compositor, now Quartz Extreme --has nothing to do with either PDF or PostScript.
Quartz is a "PDF engine" (Apple's own words), which replaces DisplayPostscript in NeXTStep. It is an moderate improvement over DisplayPostscript, in that it prohibits arbitrary Postscript programmability, but other than that, it has many of the same problems.
Yes, the Objective-C language dates back quite a ways, but programs written for the Mac have about as little to do with the Objective-C language itself as programs written for Windows have to do with the C language itself.
Programs you write in 2005 for Cocoa look almost identical to the programs you would have written in the 80's for NeXT. GNUStep, which followed the NeXTStep/OpenStep programming model closely, is also very close to Cocoa.
It's not like somebody in Cupertino just decided one day that everything invented since 1988 was crap and that the wave of the future would be retro-innovation. Not at all.
They hired Jobs and whatever software came with him. That happened to be NeXTStep.
So you see, to imply that Mac OS X is based on 80s-era technologies is just plain misleading.
I'm not "implying" that, it's a fact: Mac OS X is basically NeXTStep with a few tweaks and theming. For you to imply that OS X is brand new technology is just ridiculous. The OS X kernel, toolkit, programming model, programming language, and technology are all old stuff.
And the problem with it being retro-technology is that it really has lots of limitations, which Apple is trying to address through clever marketing and naming, rather than technological improvements and innovation.
How is that any different from the fact that a Linux kernel hacker should never look at closed MS WinNT kernel sources (even with permission)
It's different because Microsoft isn't pretending that their NT kernel is open or free; they make you jump through hopps to look at it. But Sun is pretending that their available source is "open". It's Sun's lies and misrepresentations, not their licenses, that is the problem.
and an MS WinNT kernel hacker should never look at GPLed Linux kernel sources?
They can look all they want; the GPL allows this and there is no serious legal risk associated with that, in particular, since GPL'ed code is less likely to be infested with patents. MS may have rules against it, but those rules are overly cautious. What they can't do is cut-and-paste.
Microsoft has similar licenses, by the way: "we own it, but we explicitly allow you to look all you want with no consequences".
At what point does reimplementing an algorithm you saw (in code) somewhere else stop being code theft?
Reimplementing is never "code theft". The only thing you have to worry about is patents. You have to be careful that if it looks too close to the original, people may successfully claim copyright infringement, and the best defense is to be able to say "I have never seen the original code", but that's a precautionary practical measure, not an intended restriction of copyright law.