But in the market for powerful "smart" phones, Linux won't have an easy time duking it out with earlier arrivals from Microsoft, Palmsource and the Symbian consortium, a group that includes Motorola, IDC analyst Alex Slawsby said.
Technically, this should be a no-brainer. PalmOS is effectively a 16bit platform dedicated to organizer functions, with other uses as an afterthought; and Palm is currently in transition between PalmOS4 and PalmOS6 anyway, two very different architectures. Microsoft's phone platform is the usual bloated, buggy, messy stuff we have come to expect from them. Only Symbian is pretty decent, but it is proprietary. The Linux APIs (i.e., UNIX/POSIX) have a three decade history. They are mature and scalable to small devices, and Linux itself is as well. And huge numbers of programmers know the Linux APIs.
By 2006, IDC believes Symbian will have increased its market share in powerful phones to 53 percent from its current 46 percent. Microsoft will have about 27 percent of the market, with Palm at 10 percent. IDC predicts that Linux could take as much as 4.2 percent.
I see: the reason why Linux will have a hard time is because we say so.
"It's more efficient to work with (Linux) because there are more modules we won't have to develop ourselves." [...] "By using Linux instead of Symbian or Windows, they are in control of their own upgrade cycle,"
Seems like Motorola really has their act together. Good to see. If they deliver on their promises, my next phone is likely going to be from Motorola.
I'm not thinking of any system with even 2^64 units of stored data- rather that I can see an argument for massive address spaces in order to better organise data while retaining a persistent model. One possibility this would open is the mapping of 'transformed data' which could be computed on demand as the pages containing it are accessed - if this technique were applied recursively it is easy to see why very large address spaces may prove useful in future.
Yes: that is called "pointer swizzling". However, imagine I have a 16Gbyte persistent array and I have 32Gbytes of memory. With a 64bit machine, I can map and access every byte of that array directly, from memory, through a pointer; once it's in memory, there is no OS overhead. That case can't be handled at all with pointer swizzling. How can it be done? With x86-style segment registers in hardware or with operating system calls to move data to/from memory. The former is a complete mess, as the experience with the 8086 and 80286 have shown, and the latter is unnecessarily slow.
I would be intrigued to hear why you assert "32 bit floating point values are a complicated and dangerous compromise."
With 64bit floating point values, many more numerical algorithms "just work" for normal parameter ranges and numerical requirements, without complicated mechanisms for dealing with error. With 32bit floating point values, many algorithms require much more careful design, but most implementors neither are qualified nor take the time to do it.
Another use for 64bit floating point quantities is for 32bit interval computations, something hardware should really have support for.
Maybe we need to agree to disagree - I doubt I'll see an architecture as I envisage any time soon!
This isn't a new problem. The architectures you envision have been tried before: pointer swizzling, segment registers, and explicit I/O calls. All of them have turned out to be too costly and/or too complex compared to just making the word size uniformly bigger. Software is complex enough as it is; that's not a hassle we need or can afford. Uniform word sizes clearly have a cost for many applications, in that many bits aren't used most of the time, but the cost just has turned out to be lower than the alternatives.
I think there are two problems here. One is that hardware has become vastly more complex, just like software, so that it is virtually impossible to test for every possible bug.
I don't see the problem. Nothing is entirely bug free, but there is a traditional level of reliability we have had for hardware. I have never needed to upgrade my stereo before. If hardware becomes more complex then it requires more testing to achieve the same level of quality. What you seem to imply is that vendors make their hardware more complex, do the same amount of testing, and then let the users find the bugs. That's exactly what I am annoyed by. Hardware vendors should do testing commensurate with the complexity of the hardware they release.
And the second is the rapid development and change of standards. Are you happy buying a new toy everytime something new (like a new, better movie format) comes out? Why not zap your old player with hardware support for the new format?
Standards are usually not developed rapidly. MPEG4 took, what, two decades after MPEG2 to be released? What is being developed rapidly is a barrage of new, proprietary formats, formats that vendors release quickly in an effort to grab market share with minor advantages. That should be discouraged.
Here is my rule of thumb: programmability is fine if I can program it to do what I want it to do. Then, I don't have to rely on the vendor to dictate to me how and when to upgrade. But when programmability only goes as far as the vendor sending me binary-only field upgrades, then programmability is merely a means for the vendor to avoid sufficient testing the hardware before sending it out.
There is nothing "wrong" with any correctly designed piece of hardware. I mean, unless you step on it, an FPGA by itself isn't going to hurt you.
What is wrong, IMO, is using FPGAs to build consumer products that are upgradable by the end user because that allows companies to release hardware with less testing and just have the users find and fix the bugs. Like Microsoft does with software.
The most common way of programming an FPGA is from a PROM chip on board. FPGAs are used as much in applications where ASICs
Obviously, I have no problems with FPGAs whose programs are loaded from ROM. One would think you would be able to figure that out from what I wrote since I explained very explicitly what I don't like about field upgradability.
If your digital camera manufacturer expects that you load an FPGA bitstream from your PC everytime you switch it on then, well, you should have read some reviews before you parted with your cash.
A lot of hardware used to do this and still does this. Reviewers don't generally notice it because they just review stuff on one particular version of Windows. When the next version of Windows comes out and the vendor doesn't release a new driver, such hardware usually becomes a useless chunk of metal and plastic.
As for you digital camera example, come on, that's a deliberately stupid example. You can figure out for yourself while even the worst company is not going to release a digital camera that requires downloads from a PC every time it is switched on. Firmware upgrades for digital cameras are still a huge problem, waste of time, and dangerous practice (if you interrupt it, the camera may break and won't get fixed under warranty). For example, I have a Nikon camera that was released with serious bugs; but the ugprade program doesn't run under Windows XP (it starts the download but never finishes the firmware download), and Nikon won't fix the camera for me. Ditto with a Palm firmware upgrade. Reviewers don't get to see such hassles.
Hardware is generally as reliable as it is, because most firms are very good at hardware test and qualification,
Yes, and if hardware firms can just release bug fixes like Microsoft does, that will get worse because they will invest less effort in "test and qualification". That is my point. This is what has happened in software over the last decade or two, and it looks like it is going to happen in hardware now that hardware is "field upgradable" and "field programmable".
In fact hardware implemented in an FPGA is no different from the users point of view from hardware implemented any other way, or from embedded software running on a micro-controller for that matter.
Ummm--no. The "FP" in "FPGA" stands for "field-programmable", and it is field programmability that I'm arguing against. Field programmability usually means that I, the user, need to do something to the device.
As a user, I don't want to have to "field upgrade" my stereo, television, camera, portable music player, car, or other device, I want them to work exactly as advertised; if they don't work as advertised, it should be the vendor's responsibility to fix them, at his cost. Making me download and install drivers, hot fixes, updates, or other stuff is an attempt to cut corners on testing and to off-load maintenance and repair costs onto me.
And if that kind of corner cutting takes hold, soon no vendor will be able to compete anymore with high-quality products and decent service. It's the same thing we have seen in software: Microsoft has initiated a race to the bottom in terms of software quality, immature releases, and testing and driven pretty much all other vendors out of the market through corner cutting. Hardware is trying to repeat the same thing, by letting companies avoid proper testing and allowing them to fix immature products after the fact.
The choice of using FPGAs for an emerging standard is good engineering, because if the standard changes before maturing the hardware does not then become instantly obsolete.
That's the attitude I'm arguing against. There shouldn't be "emerging standards". Define standards correctly and so that they stand the test of time, then implement them correctly. Don't ship products before the standard is defined. 802.11g is an example of this kind of bad behavior.
Of course, for some custom equipment, field upgradability makes sense. But that's already covered. My point is: expansion of field programmability into computers, peripherals, appliances, and comsumer electronics is undesirable as far as I'm concerned.
I'm sorry, but I'm getting tired of FPGAs. Many early USB peripherals had FPGAs in them. The result? You need some weird driver CDs, and the hardware becomes useless when the special drivers don't install anymore.
For hardware developers to imitate the mistakes of software development is a mistake. Hardware should conform to well-defined interfaces, it should be carefully designed, debugged, and tested, and then it should not require "upgrades" or "installation" later on, it should just work. If it hooks up to computers, it should only require generic drivers.
Nope, I'm simply reading your posts less selectively than you are.
In different words, you are hallucinating.
You have a record of generally promoting C Sharp and the CLR over Java,
Between Java and C#, C# is still the lesser of two evils. With Java, we already know that it is closed and proprietary and that Sun is litigious. With ECMA C#, there is at least a chance that it is open.
and, intentionally or not, leading people up the Dotnet garden path.
Nonsense. Even if you read my posts as a ringing endorsement of C#, I have always warned people about using the.NET APIs.
Now that the patent issue has come home to roost,
Nothing "has come home to roost". Microsoft has filed a patent application on a collection of.NET APIs. That probably has no relevance for ECMA C# or the CLR. In contrast, Sun has patents on core aspects of the Java runtime.
I trust we can look forward to 'guidance' that's less biased than the following?
"I don't want security features in my day-to-day language: they are complex and costly." Obviously your requirements are somewhat different from typical corporate IT systems. That's perfectly OK, we will keep this in mind when evaluating any future recommendations.
No, you simply fail to understand the difference between runtime safety, sandboxing, and application security. To build secure applications, you need runtime safety, you do not need Java-style sandboxing or anything like the Java security manager. Security APIs are needed for certain special-purpose applications, not for making general applications secure. Sorry if the dual use of the term "security" confuses you.
Regarding static and dynamic typing, it is a mistake to assume that the use of both models must or should imply separate languages.
You have trouble understanding the difference between "no more than two" and "exactly two"? I said we don't need multi-language support, you only need two languages: one for static, one for dynamic typing. Of course, you can make do with one: there are plenty of examples that predate Strongtalk.
My view is that the history of LISP is highly relevant to modern language design.
Of course it is.
For your reference, the original intent that LISP be an intermediate language is described here [uni-erlangen.de].
I think that paper must be going way over your head if you think that it has anything to do with CLR/JVM-style intermediate languages.
I take it that you don't use SQL or XML?
Like about so many things, you are wrong in this regard, too.
And so to the collaborative development of a new programming language, which appears to have got off to a rather rocky start:
Well, good, you go right ahead. I won't be holding my breath, though, for the results. I think we already have plenty of well-designed open languages and open source implementations. My, you might even use Lisp itself.
Actually, now that there are two implementation of Python (CPython and Jython), I think that I would have to disagree with you about the single implementation problem.
I didn't say that there was only one implementation (there are actually at least three: there is also the CLR Python implementation, unusable as that may be). But the language is still defined by the CPython implementation. When it stops being defined by the CPython implementation, we will have multiple Python-derived languages.
Standardization certainly didn't help Lisp, and standardization has actually delayed adoption of important parts of C++ (as folks waited for them to become standard).
Lisp didn't die because of standardization. If anything, it died because standardization was too little, too late. Even with the ANSI CL standard, it was basically impossible to write complex applications that ran on multiple implementations.
C++ standardization is what makes C++ usable. The C++ standard has really been a great boon for C++.
As long as the language in question has a good (and portable) Free Software implementation why should I care about what some wacky standards body says?
Because those "wacky standards bodies" are generally composed of dozens of people with lots of experience. Standardization is tedious and long-winded, and it doesn't always result in a quality product, but more often than not it helps. And standards bodies also do a lot of negotiations about patents and other intellectual property.
I'm sorry, but I get really offended when people put words in my moth. Or are you simply reading-impaired? This is what I wrote:
Maybe the open source C#/CLR efforts won't work out. Maybe Microsoft has some devious master plan and a bunch of aces up their sleeve. But whatever the situation with C#/CLR, I'm convinced that Java is not the answer. If you don't trust the open source C#/CLR efforts, my recommendation would be to stick with C/C++ for the time being, or use one of the many other open source languages.
Does that sound like I'm recommending that people "embrace C#"?
My advice is and remains: forget about Java: Sun apparently can't handle the technical stewardship, and they have demonstrated their intent to keep it proprietary. If you want a Java-like language, with Java-like simplicity (and as simplistic, too), consider using ECMA C# (not.NET), but remain wary of Microsoft's legal and business strategy for.NET and be aware that C#/CLR has lots of technical limitations, too.
Your best bet is to pick something different, IMO. There are plenty of excellent languages out there. For rapid applications development, consider Python, Lua, Ruby, Smalltalk, or Perl. If you need speed, C++ is a mature and open language now. Eiffel is no more flawed than Java and has open source implementations. And if you want a language for the 21st century, consider OCAML.
Re:64bit matters, for Google, too
on
Forget Moore's Law?
·
· Score: 2, Interesting
I donï½t, at present, see applications which would significantly benefit from register values of these sizes ï½
You can't even memory map files anymore reliably because many of them are bigger than 4G, which means that pretty much no program that deals with I/O can rely on memory mapping. Shared memory, too, needs to be shoe-horned into 32bit. 32bit addressing has a profoundly negative effect on software and hardware architecturs. We are back to PDP-11 style computing.
Why limit ourselves to 64 bit addresses ï½ I can foresee valid applications for 128,256 and 512 bit (and larger) address schemes (consider, for example, distributed grid computing.)
Sorry, I can't. 64bit addressing is driven by the fact that we can have easily more storage on a single machine than can be addressed with 32 bits. With 64bit computing, we can have a global unified address space for every single computer in the world for some time to come. There will probably be one more round of upgrades to 128bit addressing at one point, but that's it.
The distinction Iï½d like to make is one of diminishing returns for typical applications of increasing the ï½default word lengthï½.
First of all, for floating point software, it makes sense to go to 64bit anyway: 32bit floating point values are a complicated and dangerous compromise.
But in general, you are right: 32bit numerical quantities are good enough for a lot of applications. But, as I was saying, we tried making machines that are mostly n-bits and have provisions for addressing >n-bits, and the software becomes a mess. Going to uniform 64bit architectures is driven by the fact that some software needs 64bits, and once some software does, the cost of only partial support is too high.
AMD has a good compromise: they give you blazing 32bit performance and decent 64bit performance, with very similar instruction sets. That way, you can keep running existing 32bit software in 32bit mode.
The point is that a bunch of slower 32-bit processors running Google will more than likely be better than one large 64-bit processor.
My point is: there is a crossover. When memory and 64bit processors become cheap enough, you are better off with fewer 64bit processors. After all, the other stuff that comes with 32bit processors (boxes, disk drives, networking, etc.) isn't free.
And in some applications, you just don't have a choice. Some applications that require more than 4G of RAM can be nearly impossible to port to a network of 32bit machines.
If this is the case, I see no valid reason to want to manipulate 64 bit quantities atomically within the processor - wouldn't simply extending the 32bit MMU architecture (with appropriate compiler optimisations) prove more cost effective for the foreseeable future?
That's what the 8086 originally tried to do with 8/16 bit registers and larger address spaces. Other systems tried as well. It becomes a big mess.
What has turned out to be better is to go to a uniform 32bit model by default, but offer instructions operating on smaller data types, as well as MMX, for those few places where it is critical to manipulate smaller quantities efficiently. And an analogous approach can be taken with 64bit processors.
Well, there are two competing constraints: the ability to address 64 bits and bang-for-the-buck. Until recently, if you needed more than 4G, the memory alone was so expensive that it didn't matter much how much the system cost.
These days, however, memory has become cheap enough that the price of the rest of the system matters. And non-x86 systems (including Itanium) don't usually give you good bang for the buck. So, if you can work around the 4G address space limit for a bit longer, until 64bit hardware from any vendor becomes cheaper, you can save a lot of money. And that's what Google is doing.
There those that claim that.NET is open to re-implementation, but until Microsoft make a simliar public legal declaration to Sun's JSPA, any.NET reimplementation represents a pending legal mindfield.
A vague public declaration is not a legal commitment. If Sun were serious about making Java open and non-proprietary, they would dedicate their patents on Java to the public domain and go through with a standardization process.
In addition, parts of the core Java platform, like Swing, are not sufficiently well specified to permit useful independent reimplementation.
Basically, what Sun has been saying is that they don't claim ownership to APIs they didn't develop by themselves. Gee, what a big concession to make.
In comparison, Sun has granted the Apache and all open source developers FULL access to the specs, test kits and granted the full rights to develop competing products under the JSPA
What this really means is that Sun apparently can and does restrict the ability of people to create commercial third party implementations. And that shows that (1) Sun must own strong intellectual property on Java (in fact, we know they at least own patents), and (2) they are using it deliberately to restrict who can build implementations. That means that Java is not an open language standard.
Altogether, the situation both on the Java and on the C# side is bleak. Java is certainly not an open alternative to C#--they are both proprietary languages on which Sun and Microsoft, respectively, hold lots of patents.
The real question is why the whole industry is so enthralled by 30 year old technology. I mean, when Sun promised to make Java a language standard and make it completely free and open, there was some interest in it as a real-world compromise--the most modern language that an industry firmly stuck in the 1960's could live with--but few if any of Sun's promises have come through.
64bit matters, for Google, too
on
Forget Moore's Law?
·
· Score: 4, Insightful
Assume, for a moment, that we had processors with 16bit address spaces. Would it be cost-effective to replace our desktop workstations with tens of thousands of such processors, each with 64k of memory? I don't think so.
Well, it's not much different with 32bit address spaces. It's easy in tasks like speech recognition or video processing to use more than 4Gbytes of memory in a single process. Trying to squeeze that into a 32bit address space is a major hassle. And it's also soon going to be more expensive than getting a 64bit processor.
The Itanium and Opteron are way overpriced in my opinion. But 64bit is going to arrive--it has to.
Doesn't Mono's existence constitute prior art, anyway?
Microsoft started filing this patent in July 2001. I think that predates most of the Mono effort.
And what about having opened the specs up in the form of an ECMA standard, doesn't that make it a bit harder?
The patent looks like it applies to.NET, not ECMA C#.
In any case, Microsoft's patent is probably legally completely useless anyway. What it tells us, though, is their intent and wishes. And why battle with Microsoft over this? C# isn't worth it (Java isn't either).
Sorry, but I have to disagree. Python is a nice, useful, simple scripting language, but that's all it is. And Python isn't covered by any standard either: Python is what the Python implementation does. It shares that problem with Java, in fact.
Good, glad to see that our thinking on this has, er, converged [slashdot.org]. Not that you're quite with us Java fans yet,
I think you misunderstood. I used to be a "Java fan" and am responsible for its adoption by several companies. But Sun has demonstrated bad faith and incompetence when it comes to Java over the last half dozen years: not only has Sun patented key aspects of Java, they have also pulled out of several standardization efforts, and they have failed to deliver essential technologies and enhancements that they promised.
I trust you've seen NZHeretic's post [slashdot.org]?
NZHeretic is wrong: it is unclear whether Java is open to reimplementation; Sun still holds key patents, for example, and those have not been dedicated to the public domain. But that question is academic anyway because key APIs (like Swing) are not suficiently documented, so you couldn't reimplement them without reading Sun's sources if you wanted to, and if you do read Sun's sources, you are bound by their source license.
Java is not the answer for open source development--Sun has demonstrated that amply since 1996. There is still some hope for C#: the Mono project is actually increasingly relying on non-.NET APIs. Unless the Microsoft patent also covers ECMA C# (which seems really unlikely), ECMA C# with Gnome libraries may still be a perfectly good and viable choice, whith fewer technical warts than Java and fewer legal problems than Java.
Now, if we are going to develop "the next" programming language or platform, let's look at your points:
1. A language with source / "bytecode" equivalence. Code is distributed in a form that it can be manipulated and further developed in. This eliminates the use/development barrier, smooths the development tool chain and helps foster open source practices. Eclipse, for example, would like to treat Java like this but it can't quite get there.
Java-style byte codes are an awful representation for manipulating programs. Trust me, I have written that kind of code in Java and other languages. The best way to deal with that in Java is to reconstruct a tree-structured representation.
2. Persistent data. Programs can manipulate persistent data directly rather than mapping it to and from storage systems.
Well, not in Java, and not in anything with a Java runtime. I'm also not convinced that I want this deep down in my system.
3. Global processes. Processes and threads become shareable and potentially persistent, merging workflow capabilities into the basic language. (Workflow systems are everywhere, if not workflow packages).
Commercial workflow has nothing to do with operating system processes or threads. And trying to make arbitrary processes or threads persistent is a can of worms. I don't want that overhead or complexity in a language I use day-to-day.
4. Multilanguage support can be added, but without conflicting with (1). There must still be one universal, intermediate language - an extended every which way Scheme, say - but more convenient user languages resembling SQL, Java, VB etc. can be used to map to this. Actually this was the original intent of LISP circa 1963...
I have no idea whose "original intent" for LISP that is supposed to have been. In any case, I think multi-language support is vastly overrated. I do think a platform should support mixing high-performance statically typed code and convenient dynamically typed code, but for that, you only need two languages (java/bsh, C/Tcl, C++/Python, etc.).
5. Secure by design (TM) of course. And not just by stopping buffer overruns. Java now has a good set of controls, but features from J2EE such as isCallerInRole() need to be made intrinsic to the system.
To stop buffer overruns (a security problem), you don't need security features in the language, like Java has, you merely need runtime safety. I don't want security features in my day-to-day language: they are complex and costly.
Java is not a particularly well-engineered platform because many of its tradeoffs were driven by one environment (platform-independent, untrusted client software) and make no sense for a general-purpose language. And C# has copied most of those bad tradeoffs. Perhaps it's good that both Java and C# are removing themselves from the space of open, free languages: it might be best to start over with a simpler, better engineered system anyway.
This patent seems legally irrelevant, and it seems highly doubtful that Microsoft could legally get the Mono project or other third party ECMA C# or.NET for infringing it.
However, this patent shows bad faith by Microsoft. If Microsoft wanted C# to be perceived as an open language and core set of libraries, this is the last thing they would want.
Where does this leave us? We have two companies, Sun and Microsoft, that are engaged in some bizarre battle to try and control the software industry. Both have attempted to get patents that allow them to use the patent system to control who implements the language and how (yes, Sun has patents on key aspects of Java). Both are trying to keep control of the software, APIs, and future language evolution. And what is particularly ironic is that all this battle is about decades old technology.
What does this mean? Both open source and commercial users should say "no thanks" to both Java and C#. We need to get back to a model where programming languages and libraries are standardized through open standards processes and where the core language and APIs and are not covered by patents. C, C++, Smalltalk, Ada, and many other languages have shown that this is possible. In fact, had Sun not derailed and preempted the adoption of those other languages with promises of a bright Java future (on which they have failed to deliver), we might well be using some language now that is technically superior to both Java and C# and is covered by a truly open standard.
Without a license, you cannot use copyrighted material.
That's nonsense. Copyright restricts copying, not use. What companies attempt to do with software licenses is to get you to agree to certain conditions in exchange for being permitted to obtain the software. But the restrictions arise from the license, not copyright. Furthermore, the ability of publishers to impose such licenses has traditionally been rather limited: publishers may force you to agree to a license saying that you can't resell a book, but you can resell it anyway no matter what the license says and there is nothing they can do about it.
And the GPL is at risk, in multiple ways. A court might say that there is no "valuable consideration" involved in the GPL licensing, and hence no contract exists for someone receiving GPL'ed software. As a result, the recipient can either not redistribute the software at all, or the court may decide that GPL'ed software is, for practical purposes, in the public domain. Either of those outcomes would not be very good for the GPL.
I'm not saying that I agree with that reasoning, I'm just saying that there are plenty of ways in which a court (in particular, a court biased in favor of Microsoft and commercialism) could draw a line between the GPL and commercial licenses and do grave harm to open source software. So, don't become complacent.
Ideally, we would get a legislative clarification of copyright law that explicitly provides for open source and free software licenses.
We have a glut of office space and a lack of housing, but Lucasfilm needs to build a "new campus". Why don't they just lease some dot-bomb office space in Redwood City? Oh, I forgot, that wouldn't be cool enough for a "creative company".
For applications like 3D renderers or P2P systems that need to find multiple instances of themselves on a local network, you don't need Rendezvous--they have been able to do this via broadcast and multicast for a long time. Nor, for that matter, are server-less IP configuration or service discovery really new--Windows, for example, already has them, and for pretty much the same reason that Macintosh does: Microsoft wanted the same kind of plug-and-go convenience they had with their non-TCP/IP systems for TCP/IP (well, even if it was plug-and-crash in the case of Microsoft).
Don't get me wrong: Rendezvous looks like a decent and simple standard, and if it gets widely supported, that would be great. It's also great that all the fanfare surrounding Rendezvous gets people thinking about how to make their applications configure themselves with less user intervention. But the existence of Rendezvous isn't a problem for Microsoft, and it isn't something groundbreakingly new either.
Slashdot Mirror
Technically, this should be a no-brainer. PalmOS is effectively a 16bit platform dedicated to organizer functions, with other uses as an afterthought; and Palm is currently in transition between PalmOS4 and PalmOS6 anyway, two very different architectures. Microsoft's phone platform is the usual bloated, buggy, messy stuff we have come to expect from them. Only Symbian is pretty decent, but it is proprietary. The Linux APIs (i.e., UNIX/POSIX) have a three decade history. They are mature and scalable to small devices, and Linux itself is as well. And huge numbers of programmers know the Linux APIs.
By 2006, IDC believes Symbian will have increased its market share in powerful phones to 53 percent from its current 46 percent. Microsoft will have about 27 percent of the market, with Palm at 10 percent. IDC predicts that Linux could take as much as 4.2 percent.
I see: the reason why Linux will have a hard time is because we say so.
"It's more efficient to work with (Linux) because there are more modules we won't have to develop ourselves." [...] "By using Linux instead of Symbian or Windows, they are in control of their own upgrade cycle,"
Seems like Motorola really has their act together. Good to see. If they deliver on their promises, my next phone is likely going to be from Motorola.
Yes: that is called "pointer swizzling". However, imagine I have a 16Gbyte persistent array and I have 32Gbytes of memory. With a 64bit machine, I can map and access every byte of that array directly, from memory, through a pointer; once it's in memory, there is no OS overhead. That case can't be handled at all with pointer swizzling. How can it be done? With x86-style segment registers in hardware or with operating system calls to move data to/from memory. The former is a complete mess, as the experience with the 8086 and 80286 have shown, and the latter is unnecessarily slow.
I would be intrigued to hear why you assert "32 bit floating point values are a complicated and dangerous compromise."
With 64bit floating point values, many more numerical algorithms "just work" for normal parameter ranges and numerical requirements, without complicated mechanisms for dealing with error. With 32bit floating point values, many algorithms require much more careful design, but most implementors neither are qualified nor take the time to do it.
Another use for 64bit floating point quantities is for 32bit interval computations, something hardware should really have support for.
Maybe we need to agree to disagree - I doubt I'll see an architecture as I envisage any time soon!
This isn't a new problem. The architectures you envision have been tried before: pointer swizzling, segment registers, and explicit I/O calls. All of them have turned out to be too costly and/or too complex compared to just making the word size uniformly bigger. Software is complex enough as it is; that's not a hassle we need or can afford. Uniform word sizes clearly have a cost for many applications, in that many bits aren't used most of the time, but the cost just has turned out to be lower than the alternatives.
I don't see the problem. Nothing is entirely bug free, but there is a traditional level of reliability we have had for hardware. I have never needed to upgrade my stereo before. If hardware becomes more complex then it requires more testing to achieve the same level of quality. What you seem to imply is that vendors make their hardware more complex, do the same amount of testing, and then let the users find the bugs. That's exactly what I am annoyed by. Hardware vendors should do testing commensurate with the complexity of the hardware they release.
And the second is the rapid development and change of standards. Are you happy buying a new toy everytime something new (like a new, better movie format) comes out? Why not zap your old player with hardware support for the new format?
Standards are usually not developed rapidly. MPEG4 took, what, two decades after MPEG2 to be released? What is being developed rapidly is a barrage of new, proprietary formats, formats that vendors release quickly in an effort to grab market share with minor advantages. That should be discouraged.
Here is my rule of thumb: programmability is fine if I can program it to do what I want it to do. Then, I don't have to rely on the vendor to dictate to me how and when to upgrade. But when programmability only goes as far as the vendor sending me binary-only field upgrades, then programmability is merely a means for the vendor to avoid sufficient testing the hardware before sending it out.
There is nothing "wrong" with any correctly designed piece of hardware. I mean, unless you step on it, an FPGA by itself isn't going to hurt you.
What is wrong, IMO, is using FPGAs to build consumer products that are upgradable by the end user because that allows companies to release hardware with less testing and just have the users find and fix the bugs. Like Microsoft does with software.
Obviously, I have no problems with FPGAs whose programs are loaded from ROM. One would think you would be able to figure that out from what I wrote since I explained very explicitly what I don't like about field upgradability.
If your digital camera manufacturer expects that you load an FPGA bitstream from your PC everytime you switch it on then, well, you should have read some reviews before you parted with your cash.
A lot of hardware used to do this and still does this. Reviewers don't generally notice it because they just review stuff on one particular version of Windows. When the next version of Windows comes out and the vendor doesn't release a new driver, such hardware usually becomes a useless chunk of metal and plastic.
As for you digital camera example, come on, that's a deliberately stupid example. You can figure out for yourself while even the worst company is not going to release a digital camera that requires downloads from a PC every time it is switched on. Firmware upgrades for digital cameras are still a huge problem, waste of time, and dangerous practice (if you interrupt it, the camera may break and won't get fixed under warranty). For example, I have a Nikon camera that was released with serious bugs; but the ugprade program doesn't run under Windows XP (it starts the download but never finishes the firmware download), and Nikon won't fix the camera for me. Ditto with a Palm firmware upgrade. Reviewers don't get to see such hassles.
Hardware is generally as reliable as it is, because most firms are very good at hardware test and qualification,
Yes, and if hardware firms can just release bug fixes like Microsoft does, that will get worse because they will invest less effort in "test and qualification". That is my point. This is what has happened in software over the last decade or two, and it looks like it is going to happen in hardware now that hardware is "field upgradable" and "field programmable".
With Bush's revival of Star Wars, that may soon be literally true.
Ummm--no. The "FP" in "FPGA" stands for "field-programmable", and it is field programmability that I'm arguing against. Field programmability usually means that I, the user, need to do something to the device.
As a user, I don't want to have to "field upgrade" my stereo, television, camera, portable music player, car, or other device, I want them to work exactly as advertised; if they don't work as advertised, it should be the vendor's responsibility to fix them, at his cost. Making me download and install drivers, hot fixes, updates, or other stuff is an attempt to cut corners on testing and to off-load maintenance and repair costs onto me.
And if that kind of corner cutting takes hold, soon no vendor will be able to compete anymore with high-quality products and decent service. It's the same thing we have seen in software: Microsoft has initiated a race to the bottom in terms of software quality, immature releases, and testing and driven pretty much all other vendors out of the market through corner cutting. Hardware is trying to repeat the same thing, by letting companies avoid proper testing and allowing them to fix immature products after the fact.
The choice of using FPGAs for an emerging standard is good engineering, because if the standard changes before maturing the hardware does not then become instantly obsolete.
That's the attitude I'm arguing against. There shouldn't be "emerging standards". Define standards correctly and so that they stand the test of time, then implement them correctly. Don't ship products before the standard is defined. 802.11g is an example of this kind of bad behavior.
Of course, for some custom equipment, field upgradability makes sense. But that's already covered. My point is: expansion of field programmability into computers, peripherals, appliances, and comsumer electronics is undesirable as far as I'm concerned.
For hardware developers to imitate the mistakes of software development is a mistake. Hardware should conform to well-defined interfaces, it should be carefully designed, debugged, and tested, and then it should not require "upgrades" or "installation" later on, it should just work. If it hooks up to computers, it should only require generic drivers.
In different words, you are hallucinating.
You have a record of generally promoting C Sharp and the CLR over Java,
Between Java and C#, C# is still the lesser of two evils. With Java, we already know that it is closed and proprietary and that Sun is litigious. With ECMA C#, there is at least a chance that it is open.
and, intentionally or not, leading people up the Dotnet garden path.
Nonsense. Even if you read my posts as a ringing endorsement of C#, I have always warned people about using the .NET APIs.
Now that the patent issue has come home to roost,
Nothing "has come home to roost". Microsoft has filed a patent application on a collection of .NET APIs. That probably has no relevance for ECMA C# or the CLR. In contrast, Sun has patents on core aspects of the Java runtime.
I trust we can look forward to 'guidance' that's less biased than the following?
The statement I made is still true.
No, you simply fail to understand the difference between runtime safety, sandboxing, and application security. To build secure applications, you need runtime safety, you do not need Java-style sandboxing or anything like the Java security manager. Security APIs are needed for certain special-purpose applications, not for making general applications secure. Sorry if the dual use of the term "security" confuses you.
Regarding static and dynamic typing, it is a mistake to assume that the use of both models must or should imply separate languages.
You have trouble understanding the difference between "no more than two" and "exactly two"? I said we don't need multi-language support, you only need two languages: one for static, one for dynamic typing. Of course, you can make do with one: there are plenty of examples that predate Strongtalk.
My view is that the history of LISP is highly relevant to modern language design.
Of course it is.
For your reference, the original intent that LISP be an intermediate language is described here [uni-erlangen.de].
I think that paper must be going way over your head if you think that it has anything to do with CLR/JVM-style intermediate languages.
I take it that you don't use SQL or XML?
Like about so many things, you are wrong in this regard, too.
And so to the collaborative development of a new programming language, which appears to have got off to a rather rocky start:
Well, good, you go right ahead. I won't be holding my breath, though, for the results. I think we already have plenty of well-designed open languages and open source implementations. My, you might even use Lisp itself.
I didn't say that there was only one implementation (there are actually at least three: there is also the CLR Python implementation, unusable as that may be). But the language is still defined by the CPython implementation. When it stops being defined by the CPython implementation, we will have multiple Python-derived languages.
Standardization certainly didn't help Lisp, and standardization has actually delayed adoption of important parts of C++ (as folks waited for them to become standard).
Lisp didn't die because of standardization. If anything, it died because standardization was too little, too late. Even with the ANSI CL standard, it was basically impossible to write complex applications that ran on multiple implementations.
C++ standardization is what makes C++ usable. The C++ standard has really been a great boon for C++.
As long as the language in question has a good (and portable) Free Software implementation why should I care about what some wacky standards body says?
Because those "wacky standards bodies" are generally composed of dozens of people with lots of experience. Standardization is tedious and long-winded, and it doesn't always result in a quality product, but more often than not it helps. And standards bodies also do a lot of negotiations about patents and other intellectual property.
My advice is and remains: forget about Java: Sun apparently can't handle the technical stewardship, and they have demonstrated their intent to keep it proprietary. If you want a Java-like language, with Java-like simplicity (and as simplistic, too), consider using ECMA C# (not .NET), but remain wary of Microsoft's legal and business strategy for .NET and be aware that C#/CLR has lots of technical limitations, too.
Your best bet is to pick something different, IMO. There are plenty of excellent languages out there. For rapid applications development, consider Python, Lua, Ruby, Smalltalk, or Perl. If you need speed, C++ is a mature and open language now. Eiffel is no more flawed than Java and has open source implementations. And if you want a language for the 21st century, consider OCAML.
You can't even memory map files anymore reliably because many of them are bigger than 4G, which means that pretty much no program that deals with I/O can rely on memory mapping. Shared memory, too, needs to be shoe-horned into 32bit. 32bit addressing has a profoundly negative effect on software and hardware architecturs. We are back to PDP-11 style computing.
Why limit ourselves to 64 bit addresses ï½ I can foresee valid applications for 128,256 and 512 bit (and larger) address schemes (consider, for example, distributed grid computing.)
Sorry, I can't. 64bit addressing is driven by the fact that we can have easily more storage on a single machine than can be addressed with 32 bits. With 64bit computing, we can have a global unified address space for every single computer in the world for some time to come. There will probably be one more round of upgrades to 128bit addressing at one point, but that's it.
The distinction Iï½d like to make is one of diminishing returns for typical applications of increasing the ï½default word lengthï½.
First of all, for floating point software, it makes sense to go to 64bit anyway: 32bit floating point values are a complicated and dangerous compromise.
But in general, you are right: 32bit numerical quantities are good enough for a lot of applications. But, as I was saying, we tried making machines that are mostly n-bits and have provisions for addressing >n-bits, and the software becomes a mess. Going to uniform 64bit architectures is driven by the fact that some software needs 64bits, and once some software does, the cost of only partial support is too high.
AMD has a good compromise: they give you blazing 32bit performance and decent 64bit performance, with very similar instruction sets. That way, you can keep running existing 32bit software in 32bit mode.
My point is: there is a crossover. When memory and 64bit processors become cheap enough, you are better off with fewer 64bit processors. After all, the other stuff that comes with 32bit processors (boxes, disk drives, networking, etc.) isn't free.
And in some applications, you just don't have a choice. Some applications that require more than 4G of RAM can be nearly impossible to port to a network of 32bit machines.
That's what the 8086 originally tried to do with 8/16 bit registers and larger address spaces. Other systems tried as well. It becomes a big mess.
What has turned out to be better is to go to a uniform 32bit model by default, but offer instructions operating on smaller data types, as well as MMX, for those few places where it is critical to manipulate smaller quantities efficiently. And an analogous approach can be taken with 64bit processors.
These days, however, memory has become cheap enough that the price of the rest of the system matters. And non-x86 systems (including Itanium) don't usually give you good bang for the buck. So, if you can work around the 4G address space limit for a bit longer, until 64bit hardware from any vendor becomes cheaper, you can save a lot of money. And that's what Google is doing.
A vague public declaration is not a legal commitment. If Sun were serious about making Java open and non-proprietary, they would dedicate their patents on Java to the public domain and go through with a standardization process. In addition, parts of the core Java platform, like Swing, are not sufficiently well specified to permit useful independent reimplementation. Basically, what Sun has been saying is that they don't claim ownership to APIs they didn't develop by themselves. Gee, what a big concession to make.
In comparison, Sun has granted the Apache and all open source developers FULL access to the specs, test kits and granted the full rights to develop competing products under the JSPA
What this really means is that Sun apparently can and does restrict the ability of people to create commercial third party implementations. And that shows that (1) Sun must own strong intellectual property on Java (in fact, we know they at least own patents), and (2) they are using it deliberately to restrict who can build implementations. That means that Java is not an open language standard.
Altogether, the situation both on the Java and on the C# side is bleak. Java is certainly not an open alternative to C#--they are both proprietary languages on which Sun and Microsoft, respectively, hold lots of patents.
The real question is why the whole industry is so enthralled by 30 year old technology. I mean, when Sun promised to make Java a language standard and make it completely free and open, there was some interest in it as a real-world compromise--the most modern language that an industry firmly stuck in the 1960's could live with--but few if any of Sun's promises have come through.
Well, it's not much different with 32bit address spaces. It's easy in tasks like speech recognition or video processing to use more than 4Gbytes of memory in a single process. Trying to squeeze that into a 32bit address space is a major hassle. And it's also soon going to be more expensive than getting a 64bit processor.
The Itanium and Opteron are way overpriced in my opinion. But 64bit is going to arrive--it has to.
Microsoft started filing this patent in July 2001. I think that predates most of the Mono effort.
And what about having opened the specs up in the form of an ECMA standard, doesn't that make it a bit harder?
The patent looks like it applies to .NET, not ECMA C#.
In any case, Microsoft's patent is probably legally completely useless anyway. What it tells us, though, is their intent and wishes. And why battle with Microsoft over this? C# isn't worth it (Java isn't either).
Sorry, but I have to disagree. Python is a nice, useful, simple scripting language, but that's all it is. And Python isn't covered by any standard either: Python is what the Python implementation does. It shares that problem with Java, in fact.
I think you misunderstood. I used to be a "Java fan" and am responsible for its adoption by several companies. But Sun has demonstrated bad faith and incompetence when it comes to Java over the last half dozen years: not only has Sun patented key aspects of Java, they have also pulled out of several standardization efforts, and they have failed to deliver essential technologies and enhancements that they promised.
I trust you've seen NZHeretic's post [slashdot.org]?
NZHeretic is wrong: it is unclear whether Java is open to reimplementation; Sun still holds key patents, for example, and those have not been dedicated to the public domain. But that question is academic anyway because key APIs (like Swing) are not suficiently documented, so you couldn't reimplement them without reading Sun's sources if you wanted to, and if you do read Sun's sources, you are bound by their source license.
Java is not the answer for open source development--Sun has demonstrated that amply since 1996. There is still some hope for C#: the Mono project is actually increasingly relying on non-.NET APIs. Unless the Microsoft patent also covers ECMA C# (which seems really unlikely), ECMA C# with Gnome libraries may still be a perfectly good and viable choice, whith fewer technical warts than Java and fewer legal problems than Java.
Now, if we are going to develop "the next" programming language or platform, let's look at your points:
Java is not a particularly well-engineered platform because many of its tradeoffs were driven by one environment (platform-independent, untrusted client software) and make no sense for a general-purpose language. And C# has copied most of those bad tradeoffs. Perhaps it's good that both Java and C# are removing themselves from the space of open, free languages: it might be best to start over with a simpler, better engineered system anyway.
However, this patent shows bad faith by Microsoft. If Microsoft wanted C# to be perceived as an open language and core set of libraries, this is the last thing they would want.
Where does this leave us? We have two companies, Sun and Microsoft, that are engaged in some bizarre battle to try and control the software industry. Both have attempted to get patents that allow them to use the patent system to control who implements the language and how (yes, Sun has patents on key aspects of Java). Both are trying to keep control of the software, APIs, and future language evolution. And what is particularly ironic is that all this battle is about decades old technology.
What does this mean? Both open source and commercial users should say "no thanks" to both Java and C#. We need to get back to a model where programming languages and libraries are standardized through open standards processes and where the core language and APIs and are not covered by patents. C, C++, Smalltalk, Ada, and many other languages have shown that this is possible. In fact, had Sun not derailed and preempted the adoption of those other languages with promises of a bright Java future (on which they have failed to deliver), we might well be using some language now that is technically superior to both Java and C# and is covered by a truly open standard.
That's nonsense. Copyright restricts copying, not use. What companies attempt to do with software licenses is to get you to agree to certain conditions in exchange for being permitted to obtain the software. But the restrictions arise from the license, not copyright. Furthermore, the ability of publishers to impose such licenses has traditionally been rather limited: publishers may force you to agree to a license saying that you can't resell a book, but you can resell it anyway no matter what the license says and there is nothing they can do about it.
And the GPL is at risk, in multiple ways. A court might say that there is no "valuable consideration" involved in the GPL licensing, and hence no contract exists for someone receiving GPL'ed software. As a result, the recipient can either not redistribute the software at all, or the court may decide that GPL'ed software is, for practical purposes, in the public domain. Either of those outcomes would not be very good for the GPL.
I'm not saying that I agree with that reasoning, I'm just saying that there are plenty of ways in which a court (in particular, a court biased in favor of Microsoft and commercialism) could draw a line between the GPL and commercial licenses and do grave harm to open source software. So, don't become complacent.
Ideally, we would get a legislative clarification of copyright law that explicitly provides for open source and free software licenses.
We have a glut of office space and a lack of housing, but Lucasfilm needs to build a "new campus". Why don't they just lease some dot-bomb office space in Redwood City? Oh, I forgot, that wouldn't be cool enough for a "creative company".
Don't get me wrong: Rendezvous looks like a decent and simple standard, and if it gets widely supported, that would be great. It's also great that all the fanfare surrounding Rendezvous gets people thinking about how to make their applications configure themselves with less user intervention. But the existence of Rendezvous isn't a problem for Microsoft, and it isn't something groundbreakingly new either.