Try "help('postscript')", "help('png')", and "help('jpeg')".
Output to different graphics devices has been in S, Splus, and R for as long as I can remember (and that's a long time). Maybe you should try having a look at the copious documentation for R; the documentation, like the system itself, is free.
There must be a better way of showing a sane number of options while still allowing power users to access the more esoteric ones.
Why does everybody try to be one-size-fits-all? Maybe infinite customizability is possible, allowing in a single code-base to be used by both novices and experts, but that may be a bad engineering tradeoff.
There is room on Linux for different desktop environments for novices, experts, Windows refugees, Macintosh refugees, Motif refugees, keyboard fanatics, disabled users, kids, gamers, computer labs, and many others.
I think XFCE and Gnome are a good example of two desktop environments that share a lot of code but are targeted at different user communities.
I use both Gnome and KDE. Gnome strikes me as a more "UNIXy" kind of desktop environment, but KDE's strength could be that it feels more comfortable to people coming from Windows or Macintosh. Maybe that's the user community KDE should target more aggressively, rather than trying to be all things to all people. That would mean removing some customizability from KDE, making its interface more Windows/Mac-like, and simplifying the UI.
I've already asserted that I'm only concerned about whether the design of ANDF would have prevented them from being implemented.
You asserted that ANDF would have been a suitable replacement for.NET or Java. It is not because it fails to define many crucially important runtime facilities. ANDF is about as much a replacement for Java or.NET as a pile of blank pages is a replacement for a Ph.D. dissertation.
None of which provide the functionality and performance of Berlin or Aqua, except the ones that bypass X11.
First of all, Aqua is the GUI, Cocoa is the toolkit, and Quartz is the graphics engine.
Now, you have failed to provide any examples of functionality that X11 lacks that Berlin or Aqua have. Furthermore, you don't provide any evidence for your performance claims. In my own experience, the Mac graphics engine sucks in terms of performance; the only thing it seems to do pretty well is move windows opaquely.
Aqua runs on top of OpenGL,
Whatever gave you that idea?
don't use anything that is non-open on a system. Is what you are left with competitive and useful? [...] Yes. At least as much as SunOS without NeWS was.
I agree with that: the non-proprietary part of Mac OS X in 2004 is comparable in features and functionality to the open part of SunOS. Of course, compared to systems that are completely free and open source, that is pitiful.
The fact that Cocoa is outdated and people are trying to use alternatives whenever they can [...] And here we have the same trick again. This is not a fact. This is an assertion. One that you seem to have pulled out of thin air and tried to present as something I said. If you can't support it, you're not going to get any points for repeating it.
Cocoa being "outdated" is a judgement, albeit a fairly straightforward one: the toolkit is based on an unsafe C derivative without garbage collection.
As for people looking for alternatives, neither of us has statistics. But the majority of applications I use on my Mac are not Cocoa applications.
Calling it a "more recent" API is a heck of a rewriting of history.
OpenGL is not "recent". What Macintosh and Windows popularized is grafting something like OpenGL (or Direct3D) onto the side of an existing window system; X11 is just doing the same thing those systems are doing.
but it's going to take X11 a while to catch up with OpenGL-based window systems... if it ever does.
There are no usable "OpenGL-based window systems".
TenDRA and ANDF could have, if they continued, been used to implement anything in.NET or Java. Is THAT precise enough for your automated mind?
It's precise but wrong. ANDF simply lacks definitions for a host of facilities that the JVM and the CLR provide. It's not a question of whether those can be implemented in ANDF, it's a question of whether they are defined and standardized, and they are not.
Limitations of X11? Well, let's see, they've just gotten around to translucency, in three or four years there may be enough non-experimental implementations for real apps to actually use it. Angled text is still iffy. The shape extension seems to be pretty universally available, though.
In different words, you are saying, X11 does not have any limitations anymore.
General 3d support still seems to be dependent on mapping a window into some other API's space and surrounding it with X11 decorations.
X11 offers several 3D APIs. The ones that are "dependent on mapping a window into some other API's space" are the more recent ones, mostly because Macintosh and Windows made that sort of "design" popular.
So you're saying that SunOS wasn't an open system until Sun abandoned NeWS?
I'm saying, use the following test: don't use anything that is non-open on a system. Is what you are left with competitive and useful?
SunOS was competitive and useful without NeWS or any of the other crap Sun had added. gcc is competitive and useful when you run it in strict ANSI mode.
OS X is not competitive when you don't use Apple's proprietary stuff; when you use OS X, you end up having to incorporate proprietary software into your work practices and you have to rely on proprietary features for a host of day-to-day functions.
Finally: you can't have it both ways: if the Mac OS X native GUI is doomed because Cocoa is being replaced by other toolkits, then how does this doomed API keep it from being an open system?
I fail to see the contradiction. The fact that Cocoa is outdated and people are trying to use alternatives whenever they can doesn't contradict the statement that Cocoa is, for now, still an essential component of OS X. In the long run, Apple can either switch to another GUI and toolkit (whether open or proprietary remains to be seen), or Cocoa may end up killing the entire Macintosh platform.
Also, why are you trying to confuse yourself (and future maintainers) with operator overloading in C++? It's just a Bad Idea (TM). Don't do it.
And this from a guy who recommends Matlab? Matlab is all about "operator overloading".
And do you really think that "x.times(q.over(s.times(s)+Math.PI))" is easier to read and maintain than "x * q/(s*s+pi)"?
Go get Matlab (or Mathematica or Mathcad/Maple). Matlab has a powerful scripting language that does exactly what you need, and you can download thousands of functions written for it.
Matlab and those other packages are expensive. And Matlab is not the kinds of system you want to write production or end-user code in. It's also kind of flaky when you try to do anything other than numerical computing in it.
In addition to the lack of operator overloading, there are other problems with Java for numerical computing. For example, it doesn't have "complex" and similar data types, and it has no means by which you can define them yourself efficiently either. Also, Java does not have true multidimensional arrays.
The C# language is considerably better for numerical computing than Java. However, C# implementations are still a bit behind Java implementations (although they seem to be catching up fast).
I would recommend sticking with C++ for now and waiting another year to switch to something else. C# will probably mature to the point where it is a reasonable choice.
You're mixing up all kinds of different issues here. I started out talking about alternatives to GCC, and in that context I suggested tcc as an alternative. Then you argued that ANDF didn't provide type-safety.
Come on, get your arguments straight. You wrote:
TenDRA (tcc), in particular, could have done everything Java and.NET does
That is and remains wrong. Whatever combination of tools or subset of tools you pick out of the TenDRA/ANDF/tcc toolbox, it is not a replacement for Java,.NET, C#, or the CLR because it doesn't even offer a fraction of the functionality. The Java and CLR runtimes (not the libraries, but the runtimes themselves) have extensive support for dynamic language features, such as type safety, fault isolation, sandboxing, garbage collection, method dispatch, and reflection. On the JVM or CLR, I am guaranteed a lot about the behavior of code written in arbitrary languages, compiled with arbitrary compilers. TenDRA/ANDF/tcc don't offer anything close, and you cannot simply implement them at the level of the language or compiler.
An intermediate code that requires a type-safe language is more limited than one that doesn't.
Well, good then that the CLR instruction set can express unsafe operations.
Virtually every API in a bare Linux or BSD install, without X, is there in Mac OS X.
As I was saying: the kernel and command line APIs are in OS X and those parts of OS X are open. The rest (i.e., the bulk of it) isn't.
You anticipate Apple abandoning Cocoa? [...] On top of that, you have a choice of toolkits and GUIs.
I think you gave the answer yourself: people are porting lots of other toolkits to OS X because they don't want to bother with Cocoa. That trend will continue. Objective C and Display PDF will still continue to live deep within the bowels of OS X, and a few die-hard Mac developers will develop to them, but technically, they are obsolete, and they will become less and less relevant.
Finally, you seem to be a lone voice crying out in the wilderness when it comes to GNUstep and intellectual property problems. I can't find any references to this online.
In order to be an "open system", the API needs to be explicitly declared as open and freely implementable, and there needs to be a well-defined standard. NeXTStep/OSX is an ill-defined, moving target, there is no standard, no commitment to standardization, and no explicit declaration that the APIs are freely implementable. In the absence of those, nobody knows whether there are any legal problems.
On the other hand, [X11] got other limitations that make me wish whatever they're calling Berlin these days would gel into something usable.
I challenge you to name some "limitations" of X11 relative to Berlin or Cocoa.
The only evidence I'd recommend you look for would be its sheer popularity:
Well, I guess that settles it: by your reasoning, Windows must be much more efficient and must have a much better UI than Macintosh because it is 20x more efficient.
On that level, I'd say it's a very efficient user interface element.
I was explicitly not asking about "that level". I'm asking about the standard usability and efficiency metrics, the kind of stuff Apple and the article claimed this thing had, the kind Apple engineers like to keep talking about they use to design their products, but that we don't get any evidence for.
Since you care so much, get some different players together and do the tests.
I didn't claim that the scroll wheel was a superior interface; the article did.
BTW, Do you currently own a player of any description?
Yes, several.
If so which one?
A couple of Archos players, a Creative Zen, and a bunch of flash players.
And have you tried the iPod?
Both the big one and the mini. And, no, I didn't buy either.
But whether I like it or not has little to do with my question. I was just asking whether there is any actual evidence that the wheel is a good UI element.
I wasn't asking whether it was a superior product, I was asking whether there is any evidence that the scroll wheel on the iPod is an efficient user interface element. The article claimed so. I am just asking whether there is some evidence for that claim. Apparently not.
I guess the fact that a simple question about whether the iPod scroll wheel actually works more efficiently than other controllers got moderated down shows us once again: Apple's user base just isn't interested in facts, they just like to believe that Apple does everything better. Great going, guys.
The **idea** is that with an ipod you go around in a circle, which is a continuous motion.. while with other players like the zen you have to go back up to the top once you have done a round. it means a long break.
As I was saying, I would like to see some **evidence** that this **idea** actually works in practice. Not that people like it, or that it sells well (a lot of crap sells really well), or that it looks nice, but that it actually works well.
its like using a touch pad, if you move round slowly from corner to corner you go about 20 pixels on the thing, but if you go across really fast you can get from corner to corner of your screen.
Yes, and whether touch pads are efficient pointing devices is another question.
Its the same for the iPods, you can scroll down to "z" by spinning it around **really** fast 3 times, a lot better than having to spin a dial around 10 or so, at least.
Yes, but is it better than, say, a pressure sensitive switch that scrolls fast when you press it hard and slowly when you press it gently?
Sorry, but usability and efficiency is not something that can be judged merely by trying something out; it requires measurement.
Using an iPod scroll wheel for the first time will make you grin from ear to ear.
Apple clearly made the right choice from a marketing point of view: lots of people like the interface. But that's not the same as saying that it's a good or an efficient interface.
Ah. You're mixing up the language and the implementation.
No, I'm not. The JVM and.NET implement safety at the runtime and assembly level, while ANDF does not. At the language level, Java and C# give you runtime safety, while the Tendra C/C++ compilers (which you gave as an alternative) do not.
If the language you are compiling to ANDF does not enforce safe operations, then you can't compile that language to an intermediate code that enforces safe options unless you restrict yourself to a subset of that language.
It's not that simple. First of all, ANDF fails to define a runtime that allows safe code to interoperate safely. Second, ANDF fails to mark unsafe code explicitly, so I get no guarantees about a piece of ANDF code.
In contrast, all JVM code is safe and the JVM defines an entire safe runtime.
And the CLR gets the best of both worlds: it defines a safe runtime infrastructure, but it also lets you execute unsafe code, but that code is marked explicitly even in the binary.
Sorry, but ANDF just is not even close to being a replacement for the JVM or the CLR, and the JVM isn't a substitute for the CLR either.
You're treating "open systems" and "open source" too much as synonyms.
No, I don't. The vast majority of OS X APIs are neither open systems nor open source.
I would say that the interfaces and protocols in the OS X window system are better documented and more stable than either of the X11 based systems,
X11 is an open, well-specified protocol that has remained stable for nearly 20 years and stood the test of time. As for Gnome and KDE, they are just two of many interoperable toolkits and frameworks that run on top of X11. I think neither is particularly good, but both are clearly open and extensively documented.
The API is based on NeXTstep and minutely documented, and there's an open source implementation of NeXTstep that runs on UNIX.
Oh? Please point to an open specification of those APIs, i.e., a specification that comes with legal guarantees that anybody can implement it without fear of lawsuits from NeXT or Apple.
Furthermore, GNUStep is far from a usable implementation of NeXTStep. Even if it were, the question of whether the NeXTStep APIs are open or not is academic: they just don't have a future, not even on Macintosh.
No. But you have a writing problem. Now you say you are political, but before you wrote this:
See, there's a lot of Open Source software that's not playing the FSF's GNU game. You don't hear as much about it, because it's not controversial, and it's widely used by all the big players. [...] Don't buy in to Microsoft's game, or Richard Stallman's. They thrive on opposition and obstruction for different reasons. The rest of us just want the best tools we can get for our money...
The fact is that you and the BSD crowd in general are as political as Stallman and the GPL crowd, you have your own firm views, and you assert them. And you thrive as much on "opposition and obstruction" as Stallman.
Your problem, however, is that you believe so much that you are right that you talk about the BSD license as just another license along a possible spectrum, you try to tar Stallman as some kind of political monster while you just want to use software. And that's what makes you considerably worse than Stallman.
Online mail services, banks, etc. should really all offer the option of using one-time passwords from strike lists.
The idea is simple: when you log in, you can either use your regular password, or you can use a one-time password from a printed list of passwords (you strike it out so you don't accidentally reuse it). You would use the one-time password when you log in in a public environment, when people might be looking over your shoulder, video taping the keyboard, have a key-logger installed, etc.
One-time passwords like that don't require any kind of special hardware, just a web page that lets you print a new list whenever you want to.
Almost all web-based services should offer this, in particular, web-based mail services like Yahoo!, AOL, etc.
I'd like to see some independent evidence that the iPod scroll wheel is actually superior in terms of usability to other kinds of navigational devices for use on MP3 players.
The main attraction to designers of touch sensitive devices like Synaptics produces seems to be that they are comparatively cheap, fairly intuitive to novice users, take up little space, and don't gum up. But while those are clearly lots of positive traits, they are not the same as saying that those devices are good from a usability or efficiency point of view.
Stallman has an interesting approach, but it's not nearly as simple as you imply, and he does engage in an awful lot of entirely unnecessary breast-beating.
I consider his "breast beating" entirely necessary.
Remember his original attitude towards Linux? If it were up to him we'd still be waiting for Hurd.
You say that as if it had been established that the current course was the better one. Nothing could be further from the truth. The Linux kernel is probably the biggest single headache for people who create Linux installers and distributions. There is a good chance that if people had invested the thousands of man-years that were spent on beating the Linux kernel into shape into developing the Hurd, we'd have a much better (and more future-proof) overall OSS platform.
Your reasoning amounts to saying that because the Linux kernel won, it must be better. Gee, if you believe that, why don't you use Windows?
If I didn't give a damn about licenses and politics Stallman's shenanigans wouldn't piss me off as much.
Well, and the kind of licensing shenanigans and political posturing people like you engage in piss of other people because they perceive people like you as a serious threat to OSS. So, stop being "holier than thou" and get used to it: it's politics. Stallman is pretty good at it, it's part of the deal, and if you think that you can create software without being political, you are a fool.
Fair enough, you couldn't use ANDF for web applets. so, TenDRA could have done everything other than web applets that Java is used for, and everything that I would actually trust.NET for. Neither the JVM nor.NET are inherently safe designs.
You are confusing runtime safety and sandboxing. Runtime safety prevents type-correct programming from making type errors. Sandboxing prevents hostile programs from doing damage. The two are two independent properties of runtime systems. In fact, it's easy to have sandboxing without runtime safety.
Java and.NET both offer runtime safety; ANDF does not offer runtime safety. Java and.NET also happen to offer sandboxing, but as you observe, sandboxing is a pretty special purpose application.
And the startup overhead that sandbox imposes is unacceptably high. Java applets run quickly once they have been checked and started, but the number of applications where that 30-second-to-a-minute startup overhead is worth it is a tiny fraction of the ones where it's used.
Hey, what can I say: the Java platform specification and its implementations both suck. But that's a specific problem with Java (and its clone,.NET), not with safety or sandboxing.
Linux gives people a choice. [..] I think you misspelled "Open Systems give people a choice".
I didn't say "Linux is the only system that gives people a choice", I said "Linux gives people a choice".
My open systems of choice are FreeBSD, Mac OS X, and Tru64.
I think you are a bit confused on the notion of "open systems" if you call Mac OS X an "open system". The Darwin kernel and command line environment may be considered "open systems", but a lot of Mac OS X components are highly proprietary and conform to no standard, open or otherwise.
However, there are several circumstance that must be in place before a photographer owns the copyright to something they shoot.
No. The photographer owns the copyright, period.
Why do you think people have to waive that rights when they hire a photographer.
Those aren't copyright releases, they are model releases. They are different kinds of rights.
In any case, when you find someone else's photos, you neither have copyright in them nor do you have model releases, so if you publish those photos, you violate the rights of both the photographer and the models.
In mathematical terms, on the innovation = f(t) scale, the curves are about to cross.
I think the curves crossed long ago: X11, BSD, Mach, X toolkits, Tcl/Tk, etc. came out long before equivalent Windows technologies. However, because Microsoft set the de-facto standards for appearance and behavior, open source has had to spend a lot of time backfitting its own innovation into a framework that the mainstream user, who is used to Microsoft software, understands.
TenDRA (tcc), in particular, could have done everything Java and.NET does
No, it couldn't. Java and C# are safe languages. ANDF was a way of encoding unsafe binary code.
But let me hasten to add that this isn't a proof that open source inhibits innovation. It's proof that letting ANY software dominate a market inhibits innovation.
TendraCC and ANDF had nothing to do with innovation. Neither do Java or.NET. All of them represented old technology even when they came out, and all of them were just engineering tradeoffs that you had to grin and bear.
There was a lovely GDI-X11 termote terminal system called NTerprise that gave as good response time to networked Windows applications as to networked X11 apps, but because Microsoft went with Citrix' "screen-scraper" technology it died out.
So what? We have X11. We have RDP. We have VNC. We have DisplayPostscript. Linux gives people a choice. The only restrictions here originate with Microsoft: Microsoft chooses one technology for Windows and that's it. Well, that's not a problem with OSS, or a piece of software becoming dominant by itself, it's a problem with Microsoft and their ownership of the OS.
Don't buy in to Microsoft's game, or Richard Stallman's. They thrive on opposition and obstruction for different reasons.
Stallman's goal is to make it possible for you to create and use free software in the future.
Maybe you disagree with him that the GPL and the political efforts he supports are necessary to do that. But to accuse him of "thriving on opposition and obstruction" is insulting and uncalled for.
The rest of us just want the best tools we can get for our money...
And chances are that if the whole OSS community took the "I don't give a damn" attitude about licenses and politics that you do, then "the best tools we can get for our money" will soon become "whatever Microsoft ships".
If you have no rights to any of the code you write, then there is no way you can sell it and you go bankrupt. [...] For OSS to really excel, there simply has to be a mechanism that allows people to get paid for their contributions to innovation.
There is: you get hired to work on a piece of software and you get paid for your work. It works like a charm.
What companies like Microsoft have gotten used to is that they do a tiny bit of non-innovative work and then have their users by the balls. That is, they want to be able to charge disproportionately for the same work, over and over again. They like to be in a high-margin business. Well, doesn't everyone. But the real world doesn't work that way.
The idea that people only get paid for installation and not development and that sysadmins will live a dual life installing software during the day for pay and writing code at night is really not tenable.
I suspect most OSS developers these days are hired and paid as OSS developers by companies. Most of the ones that aren't are paid for by government grants.
If OSS came with a strong system of structured property rights, then OSS developers would make more money and it would be more exceptible to business types.
OSS has a strong system of "structured property rights": everybody who writes OSS owns the software. They voluntarily give other people liberal licenses because they believe it is in their own interest to do so.
If OSS came with a strong system of structured property rights, then OSS developers would make more money and it would be more exceptible to business types.
OSS gives more rights to the customers, and you can bet that that is "more acceptable" to those business types.
From the software vendor's point of view, OSS is the equivalent of low-cost, high-quality competition. Of course they don't like it, just like they don't like any other competitor. But it doesn't matter whether vendors of high-cost, proprietary software like or don't like competition. That's the beauty of a free market.
Slashdot Mirror
Try "help('postscript')", "help('png')", and "help('jpeg')".
Output to different graphics devices has been in S, Splus, and R for as long as I can remember (and that's a long time). Maybe you should try having a look at the copious documentation for R; the documentation, like the system itself, is free.
There must be a better way of showing a sane number of options while still allowing power users to access the more esoteric ones.
Why does everybody try to be one-size-fits-all? Maybe infinite customizability is possible, allowing in a single code-base to be used by both novices and experts, but that may be a bad engineering tradeoff.
There is room on Linux for different desktop environments for novices, experts, Windows refugees, Macintosh refugees, Motif refugees, keyboard fanatics, disabled users, kids, gamers, computer labs, and many others.
I think XFCE and Gnome are a good example of two desktop environments that share a lot of code but are targeted at different user communities.
I use both Gnome and KDE. Gnome strikes me as a more "UNIXy" kind of desktop environment, but KDE's strength could be that it feels more comfortable to people coming from Windows or Macintosh. Maybe that's the user community KDE should target more aggressively, rather than trying to be all things to all people. That would mean removing some customizability from KDE, making its interface more Windows/Mac-like, and simplifying the UI.
I've already asserted that I'm only concerned about whether the design of ANDF would have prevented them from being implemented.
.NET or Java. It is not because it fails to define many crucially important runtime facilities. ANDF is about as much a replacement for Java or .NET as a pile of blank pages is a replacement for a Ph.D. dissertation.
You asserted that ANDF would have been a suitable replacement for
None of which provide the functionality and performance of Berlin or Aqua, except the ones that bypass X11.
First of all, Aqua is the GUI, Cocoa is the toolkit, and Quartz is the graphics engine.
Now, you have failed to provide any examples of functionality that X11 lacks that Berlin or Aqua have. Furthermore, you don't provide any evidence for your performance claims. In my own experience, the Mac graphics engine sucks in terms of performance; the only thing it seems to do pretty well is move windows opaquely.
Aqua runs on top of OpenGL,
Whatever gave you that idea?
don't use anything that is non-open on a system. Is what you are left with competitive and useful? [...] Yes. At least as much as SunOS without NeWS was.
I agree with that: the non-proprietary part of Mac OS X in 2004 is comparable in features and functionality to the open part of SunOS. Of course, compared to systems that are completely free and open source, that is pitiful.
The fact that Cocoa is outdated and people are trying to use alternatives whenever they can [...]
And here we have the same trick again. This is not a fact. This is an assertion. One that you seem to have pulled out of thin air and tried to present as something I said. If you can't support it, you're not going to get any points for repeating it.
Cocoa being "outdated" is a judgement, albeit a fairly straightforward one: the toolkit is based on an unsafe C derivative without garbage collection.
As for people looking for alternatives, neither of us has statistics. But the majority of applications I use on my Mac are not Cocoa applications.
Time will tell who is right.
Calling it a "more recent" API is a heck of a rewriting of history.
OpenGL is not "recent". What Macintosh and Windows popularized is grafting something like OpenGL (or Direct3D) onto the side of an existing window system; X11 is just doing the same thing those systems are doing.
but it's going to take X11 a while to catch up with OpenGL-based window systems... if it ever does.
There are no usable "OpenGL-based window systems".
TenDRA and ANDF could have, if they continued, been used to implement anything in .NET or Java. Is THAT precise enough for your automated mind?
It's precise but wrong. ANDF simply lacks definitions for a host of facilities that the JVM and the CLR provide. It's not a question of whether those can be implemented in ANDF, it's a question of whether they are defined and standardized, and they are not.
Limitations of X11? Well, let's see, they've just gotten around to translucency, in three or four years there may be enough non-experimental implementations for real apps to actually use it. Angled text is still iffy. The shape extension seems to be pretty universally available, though.
In different words, you are saying, X11 does not have any limitations anymore.
General 3d support still seems to be dependent on mapping a window into some other API's space and surrounding it with X11 decorations.
X11 offers several 3D APIs. The ones that are "dependent on mapping a window into some other API's space" are the more recent ones, mostly because Macintosh and Windows made that sort of "design" popular.
So you're saying that SunOS wasn't an open system until Sun abandoned NeWS?
I'm saying, use the following test: don't use anything that is non-open on a system. Is what you are left with competitive and useful?
SunOS was competitive and useful without NeWS or any of the other crap Sun had added. gcc is competitive and useful when you run it in strict ANSI mode.
OS X is not competitive when you don't use Apple's proprietary stuff; when you use OS X, you end up having to incorporate proprietary software into your work practices and you have to rely on proprietary features for a host of day-to-day functions.
Finally: you can't have it both ways: if the Mac OS X native GUI is doomed because Cocoa is being replaced by other toolkits, then how does this doomed API keep it from being an open system?
I fail to see the contradiction. The fact that Cocoa is outdated and people are trying to use alternatives whenever they can doesn't contradict the statement that Cocoa is, for now, still an essential component of OS X. In the long run, Apple can either switch to another GUI and toolkit (whether open or proprietary remains to be seen), or Cocoa may end up killing the entire Macintosh platform.
Also, why are you trying to confuse yourself (and future maintainers) with operator overloading in C++? It's just a Bad Idea (TM). Don't do it.
And this from a guy who recommends Matlab? Matlab is all about "operator overloading".
And do you really think that "x.times(q.over(s.times(s)+Math.PI))" is easier to read and maintain than "x * q/(s*s+pi)"?
Go get Matlab (or Mathematica or Mathcad/Maple). Matlab has a powerful scripting language that does exactly what you need, and you can download thousands of functions written for it.
Matlab and those other packages are expensive. And Matlab is not the kinds of system you want to write production or end-user code in. It's also kind of flaky when you try to do anything other than numerical computing in it.
In addition to the lack of operator overloading, there are other problems with Java for numerical computing. For example, it doesn't have "complex" and similar data types, and it has no means by which you can define them yourself efficiently either. Also, Java does not have true multidimensional arrays.
The C# language is considerably better for numerical computing than Java. However, C# implementations are still a bit behind Java implementations (although they seem to be catching up fast).
I would recommend sticking with C++ for now and waiting another year to switch to something else. C# will probably mature to the point where it is a reasonable choice.
Come on, get your arguments straight. You wrote: That is and remains wrong. Whatever combination of tools or subset of tools you pick out of the TenDRA/ANDF/tcc toolbox, it is not a replacement for Java,
An intermediate code that requires a type-safe language is more limited than one that doesn't.
Well, good then that the CLR instruction set can express unsafe operations.
Virtually every API in a bare Linux or BSD install, without X, is there in Mac OS X.
As I was saying: the kernel and command line APIs are in OS X and those parts of OS X are open. The rest (i.e., the bulk of it) isn't.
You anticipate Apple abandoning Cocoa? [...] On top of that, you have a choice of toolkits and GUIs.
I think you gave the answer yourself: people are porting lots of other toolkits to OS X because they don't want to bother with Cocoa. That trend will continue. Objective C and Display PDF will still continue to live deep within the bowels of OS X, and a few die-hard Mac developers will develop to them, but technically, they are obsolete, and they will become less and less relevant.
Finally, you seem to be a lone voice crying out in the wilderness when it comes to GNUstep and intellectual property problems. I can't find any references to this online.
In order to be an "open system", the API needs to be explicitly declared as open and freely implementable, and there needs to be a well-defined standard. NeXTStep/OSX is an ill-defined, moving target, there is no standard, no commitment to standardization, and no explicit declaration that the APIs are freely implementable. In the absence of those, nobody knows whether there are any legal problems.
On the other hand, [X11] got other limitations that make me wish whatever they're calling Berlin these days would gel into something usable.
I challenge you to name some "limitations" of X11 relative to Berlin or Cocoa.
The only evidence I'd recommend you look for would be its sheer popularity:
Well, I guess that settles it: by your reasoning, Windows must be much more efficient and must have a much better UI than Macintosh because it is 20x more efficient.
On that level, I'd say it's a very efficient user interface element.
I was explicitly not asking about "that level". I'm asking about the standard usability and efficiency metrics, the kind of stuff Apple and the article claimed this thing had, the kind Apple engineers like to keep talking about they use to design their products, but that we don't get any evidence for.
Since you care so much, get some different players together and do the tests.
I didn't claim that the scroll wheel was a superior interface; the article did.
BTW, Do you currently own a player of any description?
Yes, several.
If so which one?
A couple of Archos players, a Creative Zen, and a bunch of flash players.
And have you tried the iPod?
Both the big one and the mini. And, no, I didn't buy either.
But whether I like it or not has little to do with my question. I was just asking whether there is any actual evidence that the wheel is a good UI element.
I wasn't asking whether it was a superior product, I was asking whether there is any evidence that the scroll wheel on the iPod is an efficient user interface element. The article claimed so. I am just asking whether there is some evidence for that claim. Apparently not.
I guess the fact that a simple question about whether the iPod scroll wheel actually works more efficiently than other controllers got moderated down shows us once again: Apple's user base just isn't interested in facts, they just like to believe that Apple does everything better. Great going, guys.
The **idea** is that with an ipod you go around in a circle, which is a continuous motion.. while with other players like the zen you have to go back up to the top once you have done a round. it means a long break.
As I was saying, I would like to see some **evidence** that this **idea** actually works in practice. Not that people like it, or that it sells well (a lot of crap sells really well), or that it looks nice, but that it actually works well.
its like using a touch pad, if you move round slowly from corner to corner you go about 20 pixels on the thing, but if you go across really fast you can get from corner to corner of your screen.
Yes, and whether touch pads are efficient pointing devices is another question.
Its the same for the iPods, you can scroll down to "z" by spinning it around **really** fast 3 times, a lot better than having to spin a dial around 10 or so, at least.
Yes, but is it better than, say, a pressure sensitive switch that scrolls fast when you press it hard and slowly when you press it gently?
try them out
Sorry, but usability and efficiency is not something that can be judged merely by trying something out; it requires measurement.
Using an iPod scroll wheel for the first time will make you grin from ear to ear.
Apple clearly made the right choice from a marketing point of view: lots of people like the interface. But that's not the same as saying that it's a good or an efficient interface.
Ah. You're mixing up the language and the implementation.
.NET implement safety at the runtime and assembly level, while ANDF does not. At the language level, Java and C# give you runtime safety, while the Tendra C/C++ compilers (which you gave as an alternative) do not.
No, I'm not. The JVM and
If the language you are compiling to ANDF does not enforce safe operations, then you can't compile that language to an intermediate code that enforces safe options unless you restrict yourself to a subset of that language.
It's not that simple. First of all, ANDF fails to define a runtime that allows safe code to interoperate safely. Second, ANDF fails to mark unsafe code explicitly, so I get no guarantees about a piece of ANDF code.
In contrast, all JVM code is safe and the JVM defines an entire safe runtime.
And the CLR gets the best of both worlds: it defines a safe runtime infrastructure, but it also lets you execute unsafe code, but that code is marked explicitly even in the binary.
Sorry, but ANDF just is not even close to being a replacement for the JVM or the CLR, and the JVM isn't a substitute for the CLR either.
You're treating "open systems" and "open source" too much as synonyms.
No, I don't. The vast majority of OS X APIs are neither open systems nor open source.
I would say that the interfaces and protocols in the OS X window system are better documented and more stable than either of the X11 based systems,
X11 is an open, well-specified protocol that has remained stable for nearly 20 years and stood the test of time. As for Gnome and KDE, they are just two of many interoperable toolkits and frameworks that run on top of X11. I think neither is particularly good, but both are clearly open and extensively documented.
The API is based on NeXTstep and minutely documented, and there's an open source implementation of NeXTstep that runs on UNIX.
Oh? Please point to an open specification of those APIs, i.e., a specification that comes with legal guarantees that anybody can implement it without fear of lawsuits from NeXT or Apple.
Furthermore, GNUStep is far from a usable implementation of NeXTStep. Even if it were, the question of whether the NeXTStep APIs are open or not is academic: they just don't have a future, not even on Macintosh.
No. But you have a writing problem. Now you say you are political, but before you wrote this:
The fact is that you and the BSD crowd in general are as political as Stallman and the GPL crowd, you have your own firm views, and you assert them. And you thrive as much on "opposition and obstruction" as Stallman.
Your problem, however, is that you believe so much that you are right that you talk about the BSD license as just another license along a possible spectrum, you try to tar Stallman as some kind of political monster while you just want to use software. And that's what makes you considerably worse than Stallman.
Online mail services, banks, etc. should really all offer the option of using one-time passwords from strike lists.
The idea is simple: when you log in, you can either use your regular password, or you can use a one-time password from a printed list of passwords (you strike it out so you don't accidentally reuse it). You would use the one-time password when you log in in a public environment, when people might be looking over your shoulder, video taping the keyboard, have a key-logger installed, etc.
One-time passwords like that don't require any kind of special hardware, just a web page that lets you print a new list whenever you want to.
Almost all web-based services should offer this, in particular, web-based mail services like Yahoo!, AOL, etc.
I'd like to see some independent evidence that the iPod scroll wheel is actually superior in terms of usability to other kinds of navigational devices for use on MP3 players.
The main attraction to designers of touch sensitive devices like Synaptics produces seems to be that they are comparatively cheap, fairly intuitive to novice users, take up little space, and don't gum up. But while those are clearly lots of positive traits, they are not the same as saying that those devices are good from a usability or efficiency point of view.
Stallman has an interesting approach, but it's not nearly as simple as you imply, and he does engage in an awful lot of entirely unnecessary breast-beating.
I consider his "breast beating" entirely necessary.
Remember his original attitude towards Linux? If it were up to him we'd still be waiting for Hurd.
You say that as if it had been established that the current course was the better one. Nothing could be further from the truth. The Linux kernel is probably the biggest single headache for people who create Linux installers and distributions. There is a good chance that if people had invested the thousands of man-years that were spent on beating the Linux kernel into shape into developing the Hurd, we'd have a much better (and more future-proof) overall OSS platform.
Your reasoning amounts to saying that because the Linux kernel won, it must be better. Gee, if you believe that, why don't you use Windows?
If I didn't give a damn about licenses and politics Stallman's shenanigans wouldn't piss me off as much.
Well, and the kind of licensing shenanigans and political posturing people like you engage in piss of other people because they perceive people like you as a serious threat to OSS. So, stop being "holier than thou" and get used to it: it's politics. Stallman is pretty good at it, it's part of the deal, and if you think that you can create software without being political, you are a fool.
Fair enough, you couldn't use ANDF for web applets. so, TenDRA could have done everything other than web applets that Java is used for, and everything that I would actually trust .NET for. Neither the JVM nor .NET are inherently safe designs.
.NET both offer runtime safety; ANDF does not offer runtime safety. Java and .NET also happen to offer sandboxing, but as you observe, sandboxing is a pretty special purpose application.
.NET), not with safety or sandboxing.
You are confusing runtime safety and sandboxing. Runtime safety prevents type-correct programming from making type errors. Sandboxing prevents hostile programs from doing damage. The two are two independent properties of runtime systems. In fact, it's easy to have sandboxing without runtime safety.
Java and
And the startup overhead that sandbox imposes is unacceptably high. Java applets run quickly once they have been checked and started, but the number of applications where that 30-second-to-a-minute startup overhead is worth it is a tiny fraction of the ones where it's used.
Hey, what can I say: the Java platform specification and its implementations both suck. But that's a specific problem with Java (and its clone,
Linux gives people a choice. [..] I think you misspelled "Open Systems give people a choice".
I didn't say "Linux is the only system that gives people a choice", I said "Linux gives people a choice".
My open systems of choice are FreeBSD, Mac OS X, and Tru64.
I think you are a bit confused on the notion of "open systems" if you call Mac OS X an "open system". The Darwin kernel and command line environment may be considered "open systems", but a lot of Mac OS X components are highly proprietary and conform to no standard, open or otherwise.
However, there are several circumstance that must be in place before a photographer owns the copyright to something they shoot.
No. The photographer owns the copyright, period.
Why do you think people have to waive that rights when they hire a photographer.
Those aren't copyright releases, they are model releases. They are different kinds of rights.
In any case, when you find someone else's photos, you neither have copyright in them nor do you have model releases, so if you publish those photos, you violate the rights of both the photographer and the models.
In mathematical terms, on the innovation = f(t) scale, the curves are about to cross.
I think the curves crossed long ago: X11, BSD, Mach, X toolkits, Tcl/Tk, etc. came out long before equivalent Windows technologies. However, because Microsoft set the de-facto standards for appearance and behavior, open source has had to spend a lot of time backfitting its own innovation into a framework that the mainstream user, who is used to Microsoft software, understands.
TenDRA (tcc), in particular, could have done everything Java and .NET does
.NET. All of them represented old technology even when they came out, and all of them were just engineering tradeoffs that you had to grin and bear.
No, it couldn't. Java and C# are safe languages. ANDF was a way of encoding unsafe binary code.
But let me hasten to add that this isn't a proof that open source inhibits innovation. It's proof that letting ANY software dominate a market inhibits innovation.
TendraCC and ANDF had nothing to do with innovation. Neither do Java or
There was a lovely GDI-X11 termote terminal system called NTerprise that gave as good response time to networked Windows applications as to networked X11 apps, but because Microsoft went with Citrix' "screen-scraper" technology it died out.
So what? We have X11. We have RDP. We have VNC. We have DisplayPostscript. Linux gives people a choice. The only restrictions here originate with Microsoft: Microsoft chooses one technology for Windows and that's it. Well, that's not a problem with OSS, or a piece of software becoming dominant by itself, it's a problem with Microsoft and their ownership of the OS.
Don't buy in to Microsoft's game, or Richard Stallman's. They thrive on opposition and obstruction for different reasons.
Stallman's goal is to make it possible for you to create and use free software in the future.
Maybe you disagree with him that the GPL and the political efforts he supports are necessary to do that. But to accuse him of "thriving on opposition and obstruction" is insulting and uncalled for.
The rest of us just want the best tools we can get for our money...
And chances are that if the whole OSS community took the "I don't give a damn" attitude about licenses and politics that you do, then "the best tools we can get for our money" will soon become "whatever Microsoft ships".
If you have no rights to any of the code you write, then there is no way you can sell it and you go bankrupt. [...] For OSS to really excel, there simply has to be a mechanism that allows people to get paid for their contributions to innovation.
There is: you get hired to work on a piece of software and you get paid for your work. It works like a charm.
What companies like Microsoft have gotten used to is that they do a tiny bit of non-innovative work and then have their users by the balls. That is, they want to be able to charge disproportionately for the same work, over and over again. They like to be in a high-margin business. Well, doesn't everyone. But the real world doesn't work that way.
The idea that people only get paid for installation and not development and that sysadmins will live a dual life installing software during the day for pay and writing code at night is really not tenable.
I suspect most OSS developers these days are hired and paid as OSS developers by companies. Most of the ones that aren't are paid for by government grants.
If OSS came with a strong system of structured property rights, then OSS developers would make more money and it would be more exceptible to business types.
OSS has a strong system of "structured property rights": everybody who writes OSS owns the software. They voluntarily give other people liberal licenses because they believe it is in their own interest to do so.
If OSS came with a strong system of structured property rights, then OSS developers would make more money and it would be more exceptible to business types.
OSS gives more rights to the customers, and you can bet that that is "more acceptable" to those business types.
From the software vendor's point of view, OSS is the equivalent of low-cost, high-quality competition. Of course they don't like it, just like they don't like any other competitor. But it doesn't matter whether vendors of high-cost, proprietary software like or don't like competition. That's the beauty of a free market.