Yes, UNIX lacks a component system that works well for GUI and end-user apps. Yes, at a very high level, it should give people the capabilities of COM on Windows.
But I think neither COM nor CORBA are the answer. COM and CORBA are both rather complex systems because they are trying to patch up deficiencies in the underlying languages, C and C++. In an environment that encourages reuse, you should be able to just serialize and send objects to other components without lots of error-prone declarations. Such systems exist, and have existed for decades. But you simply can't build them reliably on top of C/C++.
Ten years ago, Objective-C was a pragmatic and efficient answer to that problem. Objective-C is simpler than IDL and gives programmers more power. Today, the obvious answer would seem to be Java, although even it is still more complex than it probably ought to be.
While I appreciate the short term utility of Gnome, I think in the long term, the effect of the Gnome project (and KDE, for that matter) is going to be harmful. It continues to encourage people to develop in and for an environment that is fundamentally not well suited to building software components and getting a lot of code reuse.
If people want to do something relevant for end users in an industry-standard environment, I think they should contribute to Java-based desktop application efforts. The Gnome programmers are smart and capable: if even a fraction of the Gnome effort went into open source Java implementation (e.g., kaffe) and Java desktop apps (e.g., JFA), we'd soon have a good environment that would be much easier to extend with new components than a big C/CORBA system.
I see nothing in C# that would make it perform any better than Java. The introduction of objects with value semantics perhaps comes closest, but similar efforts are underway for Java (and can be implemented without any significant changes to the Java language and none to the Java byte codes).
Java has an enormous number of man-years poured into its design, library, bug fixes, and various implementations. Issues like safety, sandboxing, security, and reflection aren't even addressed by C#. A complete set of cross-platform libraries is also not a goal of C#, while Java actually delivers, and delivers pretty well. And people are working hard at adding genericity and features for high performance computing (JavaGrande) to Java.
If Windows programmers switch in droves from C++ to C# that would be great: as far as it's defined, C# is almost indistiguishable from Java, and it would elevate the quality of software on Windows platforms. But, at this point, C# looks like a dud to me: it's late, it's non-standard, has no user community, and it doesn't even promise to offer any compelling advantages over Java.
Linux is probably the main driver for the creation of open source AIM clients. That stuff probably also has formed the basis for many of the third party clients that irk AOL so much on Windows.
Until they release the source code for this thing, I would simply view it as an attempt to reduce the incentive for open source clients to get created.
And I think we are going to see a lot more of that corporate strategy: companies will be releasing "free" binary only or encumbered software for Linux to kill off true open source efforts, which in the long run threaten their business interests.
Yes, it is possible to invest a lot of time and effort in coming up with configuration tools and build tools for C/C++. But I think such an approach is not rational.
Configuration and build tools become a lot easier if you modify the language itself to have a decent module system, and create well-defined module-based interfaces for the different platforms. I would claim that the amount of time and effort to fix C/C++, and the amount of retraining required for programmers is small compared to a solution that doesn't change the language and instead relies on external tools to do half a job with what will end up being a much more complex tool.
Something similar happened with COM/ActiveX: nominally, COM/ActiveX software is written in plain C/C++. But no C/C++ programmer can write COM/ActiveX software; instead, they have to learn what amounts to a whole new language and runtime. There, too, a modification to the language would have been overall more rational.
Yes, for lots of political reasons people like to cling to the illusion that tools and languages are separate, and that they can stay backwards compatible if they don't touch the language. But that really is an illusion, and one that costs the industry dearly in the long run.
In a nutshell, my message to the Software Carpentry would be: we have had enough half-baked solutions like this. Think about how to fix C and add a decent module system and correct cross-module type checking to the language itself. Something like that should be implementable as a simple "xC" to C translator and work across platforms, and it can probably even be backwards compatible in most areas that count.
Parallel computing and medical technology, Java, "patents pending", snazzy web design, expensive PR firm (Ogilvy), micropayments, "veteran entrepreneurs", etc. Lots of buzzwords. Maybe I'm wrong, but it all looks to me like a grab for attention from VC funding, with a quick exit strategy for the founders and angel investors once it goes public. And there may be an intellectual property grab in there as well on some pretty obvious additional sandboxing, encryption, or the concept of paying people for use of their computers off-hours, something that may ultimately get in the way of free and open research uses of Java for distributed scientific computing.
I also have my doubts about the business model itself. Even with the obvious cryptographic techniques for protecting the integrity of the executable code and protecting the communications, companies may still be able to infer things about research efforts by competitors or tamper with other people's results. For most companies, I think it is safer and less hassles just to build their own parallel machine
Altogether, I don't see the purpose or the novelty, and I can't help but have a rather negative reaction to it all. At least, I think the company has a lot more explaining to do.
Obviously, these numbers are strongly biased in favor of Windows: most installations of Linux never show up in them, and many "shipments" of Windows (OEM licenses, site licenses, etc.) never actually get used. IDC's numbers probably also underestimate the Mac user base.
But why worry about it? Companies that make business decisions based on flawed data are likely to fare poorly in the marketplace in the long run. Just think of the relative costs and reliability of a Windows-based web site and a UNIX based equivalent.
"Intellectual property" isn't physical property. In fact, the term "intellectual property" is a fiction created by people who want to exercise undue control over others. The law talks about trademarks, copyrights, patents, and trade secrets, licenses and protections granted by society for very specific purposes and usually only for a limited time.
For the sake of our society, let's hope that it stays that way: societies in which people get to control what other people know, say, or think are not democracies.
People have written bootstrap loaders for all sorts of systems, including Linux systems. You don't need a DOS prompt for that. So, you don't need a DOS mode for that.
But this change will make some important procedures harder (fixing the BIOS, installing old games, etc.). Microsoft may think that most of their customers aren't doing that; but many of their cutsomers hire people to do that sort of thing (or ask friend to do it for them). This makes dealing with Windows machines even more of a pain than it already is. Of course, since CD-ROMs started being inaccessible from DOS mode under standard Windows installations, DOS mode had gotten significantly less useful anyway.
software liability all of a sudden?
on
Hacker Crackdown?
·
· Score: 5
So, if some company sells me a lousy piece of software that causes me to lose money, I can't sue them, because under UCITA they have absolved themselves of all responsibility.
But if I write a piece of software that can be used for file swapping and someone uses it to commit copyright infringement, I may be held responsible for contributory infringement by the RIAA and MPAA?
Even the language and analogy itself is disturbing: creating tools for letting people share information is now on the same level as creating nuclear bombs? Isn't the ability to communicate freely at the heart of a democracy?
I think it's pretty clear what the deciding factor is in who can and cannot be held responsible for the software they create: people with money and political influence are exempted from responsibility. Remember that next time you vote and give the third party candidates a chance. Nader is looking pretty good...
Yes, if bundles are just big executable archive files or directory trees with a known structure, you don't need a database--you can just search through them in a more traditional UNIX shell style. A database approach would be another way, though, of letting both users and packages find the executables they really want (the "owned by..." was just another example--for example, for security reasons, I might not want to execute files owned by anybody else right now).
Your program outputs nothing. But you can demonstrate what I mean in Perl:
sub make_package {
my $library = "hello, world";
my $program = sub { print $library,"\n"; }
};
# create the program/package
$package = make_package();
# change the environment incompatibly
$library = "oops, wrong environment";
# run the program
$package->();
This outputs "hello, world" in Perl. In the real world, it will output the wrong thing.
Maybe, maybe not. Concatenated mounts or similar mechanisms in Plan 9 are one way around the PATH variable. Another is using a file system that is a database; in that case, your "PATH" (i.e., the set of programs you might run by typing their name) would turn into a query "find a file with NAME that is executable, is owned by root or by me, and lives under/usr/executables or/home/myname/executables".
But, yes, fundamentally I agree: doing packaging "right" (in my sense) requires breaking significantly with the way things are done in Linux/UNIX right now. On the other hand, it may be possible to get there without breaking existing functionality. Plan 9 actually has most of the necessary bits and pieces, and it has a usable POSIX system side-by-side with its advanced naming facilities.
For example, one way of getting there might be to start by adopting some kind of "bundle" format for GUI applications (together with a small modification to the kernel to make them executable) and to add an enhanced version of "chroot" (with more control over the environment). I think both of those would be natural, the first for better usability, the second for better security in some applications. Over time, other pieces could fall into place.
I thought it might be useful to present another way of looking at the application packaging problem. Rather than as "object oriented encapsulation" and "communcation through well-defined interfaces", we can also look at it as a kind of lexical closure. In programming languages, lexical closures ensure that a function that was written in one kind of environment behaves predictably even when called in a different environment.
Any program is written and tested in a particular environment (libraries, writable directories, etc.) and makes references to those objects. To function correctly, it should really be shipped with the complete environment it depends on. That's no different from a nested function in Scheme or some other fully lexically scoped programming language (sorry, C/C++ doesn't need to apply).
Of course, requirements on applications are a bit more complicated than functions. When shipping the "closure" of a program over its environment in that way, as an optimization, we may not want to ship every single library with it; many of them may be present in the target execution environment (shipping a secure checksum may be sufficient). Furthermore, for some values in the closure, we may want to allow "substitutions". For example, for some libraries, we may want to allow newer versions to be substituted. And some references, e.g., to a "document directory" are dependent in more complex ways on the environment. Such deviations should probably be identified and declared explicitly as exceptions.
Lexical closures get their power from two properties. First, in modern languages, the "free" references to dependencies in an environment are captured automatically and reliably. Second, once closed over an environment, a function can't go out and start accessing other parts of the environment (at least not without being very explicit about it in most languages).
The alternatives (manual declaration of environmental dependencies, unrestricted access) were tried with programming languages, and they led to unreliable programs, and languages got rid of those approaches pretty quickly. We should probably follow a similar path for packaging applications.
I think the whole notion of exploding a piece of software and spewing the bits and pieces all over the file system is wrong. Applications should be self-contained collections of resources (somewhat like.jar files or the Apple format); let's call them "application bundles" like Apple/NeXT does.
For stuff that isn't packaged with the applications, the package format should contain version information and checksums for any other files it depends on. It should declare those dependencies. The operating system should then be able to identify what is needed, possibly fetch it over the Internet, and give the package access to those files under a symbolic path name.
Such application bundles with dependencies should not (normally) be allowed to access the raw file system for their installation at all. In fact, even most applications should probably not be allowed to reference absolute pathnames. All references should be through symbolic paths. That way, one actually has a prayer of figuring out what the thing depends on, and it would also help with security.
Furthermore, the notion of "install scripts" is broken because it is difficult for anything to figure out what went wrong in the bowels of some script, and because scripts may do things to the system that are difficult to undo. Information about how an application bundles and their needs should be entirely declarative.
Another way of looking at that is that applications and application installation needs to work similar to objects and software components. In the past, programs consisted of functions that looked for, and modified, global variables all over the place. These days, good software components have well defined interfaces, get access to their environment only through those interfaces, and rarely use global variables. That's the kind of change that also has to happen at the level of applications.
The system that is closest to that in many ways is Sun Java: with jar files and the JavaBeans standards, there are well-defined ways for software to get installed and interact with the rest of the system, yet the environment can limit what new software components can do. We need something similar for Linux packages. That would also require additional naming and name translation support for Linux, similar to what Plan 9 offers (however, Plan 9 never adopted a good way of packaging applications based on their naming model--a shame, they were pretty close).
Is there any indication that this is more than vaporware? It's easy to promise a consistent, efficient 2D graphics API with transparency support, anti-aliasing, and hardware acceleration, it's a lot harder to deliver on it.
Re:Dynamic resizing of the X display
on
XFree & Rendering
·
· Score: 2
I think X applications aren't written to handle an event that lets them know that the physical screen size has changed.
However, this shouldn't be a big problem, since, for the most part, only the window manager needs to know. The X server could send an "physical screen size changed" event to the window manager and the window manager would rearrange the windows to fit onto the new screen size. If the X server disables edge scrolling, the effect is the same as on Windows; whether the off screen pixels are still stored or not is not user visible in any important way.
Windows actually has a lot more of those kinds of "legacy" assumptions built in; for example, many Windows applications cannot conceive of resizing or moving their main window while a modal dialog is up or while they are busy computing. I'll take the fixed screen size assumption over that any day...
Re:This has been discussed on /. before
on
XFree & Rendering
·
· Score: 3
Spitzak's points are valid ones, but what he proposes is a major additional effort. Is that effort justified?
For most applications, X11 works OK. If it gets some support for anti-aliasing and compositing, people will be able to do a lot more with it than they can now. Keith's effort seems like a very rational starting point for that: add a small set of server functionalities that addresses the core problems people have.
If X11 additionally got paths, floating point coordinates, and other features in the server, would that significantly expand the application areas for X11? Would it allow existing applications to be speeded up in some important way? If people want those kinds of features, why aren't they using the existing DisplayPostscript extension to X11, already donated by IBM? And is it worth adding a complete 2D rendering API when 3D APIs already provide coordinate transformations, compositing, and all the other features, hardware accelerated, and available on pretty much all platforms, for those applications that really need them?
I can't claim to know the answers; my intuition is that the more minimalist approach Keith is taking is probably the better one for now. But whatever approach might be better in the end, unless significant additional resources materialize, I suspect that is all that realistically can happen. Any volunteers?
Re:This is berlin without the complications?
on
XFree & Rendering
·
· Score: 3
'Widget's for lack of a better term are coded modularly into the server, creating a
single unique interface for all applications to call upon. No more need for Qt/Gtk wars, just pure
simplification.
Win32 has its own, native widget set, and that hasn't stopped people from porting Gtk, Qt, Tcl/Tk, wxWindows, and lots of other toolkits to it. The same will happen with Berlin if the project produces a usable windowing system at all.
It should be noted that Berlin uses a completely different approach to visuals than anything X
ever had. It takes the approach that the application never need know or assume what the visual
will look like.
The purpose of visuals in X isn't to make the programmer's life miserable (even if they do that on occasion) but because there was a technical need for it. There are other tradeoffs you can make: Win32 and NeWS took different approaches, with different advantages and problems. Berlin won't be able to avoid the issue either, since presumably applications will be able to draw raw 2D graphics under it one way or another. If it automates the visual management, that's one choice, good for some applications, bad for others.
Comparatively little development has been done on Netscape over the last few years, so it doesn't seem particularly surprising that bugs like this crop up. Let's hope that Mozilla or some other project will come out with a decent open source browser.
I still prefer Netscape to IE: with IE, the lack of security is designed in from the ground up (ActiveX etc.). Netscape at least is based on technologies that can be made secure.
For the time being, you just have to turn off Java and JavaScript.
It might also be worth looking at other ways of removing privileges from a running Netscape. Linux chroot, capabilities, various group hacks, LD_PRELOAD, and ptrace, could all be used to detect and prevent undesirable behavior.
Given their cash reserves, if few people are willing to write stuff for the Xbox voluntarily, I suppose they can just keep buying game developers and "redirect their efforts". How much effort do you think a Microsoft owned company is going to invest in making PSX2 games in the future?
Incidentally, whether the Xbox "will be the most powerful" remains to be seen. So far, it is still vaporware, and there is a lot that can happen between now and whenever it sees the light of day.
Actually, for the same number of allocations/deallocations, a garbage collector is often faster than malloc/free or new/delete. The reason why garbage collection seems slower is because it does a lot of work all at once (rather than spreading it out) and because it lets people get away with writing sloppier code. But you don't have to get sloppy just because there is a garbage collector.
People have implemented C compilers that have "safe pointers". But, as you observe, it's slow. It also can't work with existing C library interfaces. That's an intrinsic limitation of the C programming language. It's not a necessary limitation in order to achieve any of the features of the C language, it's just a deficiency in C's design.
Mandating the existence of garbage collection in a language doesn't mean that you can't have C-like features. Java happens not to. But Modula-3, Ada, and other languages are as expressive and efficient as C, yet, unlike C, they also have a powerful safe subset.
So, what Hejlsberg promises in the interview is that they will deliver something that is easier to program in than Java, works more efficiently than the best Java implementations, is available across platforms, and allows people to write code that ports even more easily between Windows, UNIX, and Macintosh than Java.
To fulfill those promises, Microsoft not only need to do better than some of the best dynamic language implementors in the world, but they need to do the hard work of producing implementations for their less favorite platforms, just like Sun did with Java.
Given Microsoft's track record, I suspect that is less likely than the proverbial snowball in hell, and I wouldn't exactly plan projects around Microsoft's promises.
But if they deliver, good for them and good for all of us.
Let's hold Hejlsberg to those promises a year from now.
Corporate buyers shouldn't complain to Microsoft about the site-wide license agreements they signed. Those agreements probably are blanket agreements by number of machines or number of users; anything else would be too difficult to audit.
Instead, corporate buyers who have their own ready-made Windows installations should insist on not having Windows preloaded by the manufacturer and receiving a discount on the machine. It's the bundling and tying that's so obnoxious, not the site licensing.
Slashdot Mirror
But I think neither COM nor CORBA are the answer. COM and CORBA are both rather complex systems because they are trying to patch up deficiencies in the underlying languages, C and C++. In an environment that encourages reuse, you should be able to just serialize and send objects to other components without lots of error-prone declarations. Such systems exist, and have existed for decades. But you simply can't build them reliably on top of C/C++.
Ten years ago, Objective-C was a pragmatic and efficient answer to that problem. Objective-C is simpler than IDL and gives programmers more power. Today, the obvious answer would seem to be Java, although even it is still more complex than it probably ought to be.
While I appreciate the short term utility of Gnome, I think in the long term, the effect of the Gnome project (and KDE, for that matter) is going to be harmful. It continues to encourage people to develop in and for an environment that is fundamentally not well suited to building software components and getting a lot of code reuse.
If people want to do something relevant for end users in an industry-standard environment, I think they should contribute to Java-based desktop application efforts. The Gnome programmers are smart and capable: if even a fraction of the Gnome effort went into open source Java implementation (e.g., kaffe) and Java desktop apps (e.g., JFA), we'd soon have a good environment that would be much easier to extend with new components than a big C/CORBA system.
Java has an enormous number of man-years poured into its design, library, bug fixes, and various implementations. Issues like safety, sandboxing, security, and reflection aren't even addressed by C#. A complete set of cross-platform libraries is also not a goal of C#, while Java actually delivers, and delivers pretty well. And people are working hard at adding genericity and features for high performance computing (JavaGrande) to Java.
If Windows programmers switch in droves from C++ to C# that would be great: as far as it's defined, C# is almost indistiguishable from Java, and it would elevate the quality of software on Windows platforms. But, at this point, C# looks like a dud to me: it's late, it's non-standard, has no user community, and it doesn't even promise to offer any compelling advantages over Java.
Until they release the source code for this thing, I would simply view it as an attempt to reduce the incentive for open source clients to get created.
And I think we are going to see a lot more of that corporate strategy: companies will be releasing "free" binary only or encumbered software for Linux to kill off true open source efforts, which in the long run threaten their business interests.
Configuration and build tools become a lot easier if you modify the language itself to have a decent module system, and create well-defined module-based interfaces for the different platforms. I would claim that the amount of time and effort to fix C/C++, and the amount of retraining required for programmers is small compared to a solution that doesn't change the language and instead relies on external tools to do half a job with what will end up being a much more complex tool.
Something similar happened with COM/ActiveX: nominally, COM/ActiveX software is written in plain C/C++. But no C/C++ programmer can write COM/ActiveX software; instead, they have to learn what amounts to a whole new language and runtime. There, too, a modification to the language would have been overall more rational.
Yes, for lots of political reasons people like to cling to the illusion that tools and languages are separate, and that they can stay backwards compatible if they don't touch the language. But that really is an illusion, and one that costs the industry dearly in the long run.
In a nutshell, my message to the Software Carpentry would be: we have had enough half-baked solutions like this. Think about how to fix C and add a decent module system and correct cross-module type checking to the language itself. Something like that should be implementable as a simple "xC" to C translator and work across platforms, and it can probably even be backwards compatible in most areas that count.
I also have my doubts about the business model itself. Even with the obvious cryptographic techniques for protecting the integrity of the executable code and protecting the communications, companies may still be able to infer things about research efforts by competitors or tamper with other people's results. For most companies, I think it is safer and less hassles just to build their own parallel machine
Altogether, I don't see the purpose or the novelty, and I can't help but have a rather negative reaction to it all. At least, I think the company has a lot more explaining to do.
But why worry about it? Companies that make business decisions based on flawed data are likely to fare poorly in the marketplace in the long run. Just think of the relative costs and reliability of a Windows-based web site and a UNIX based equivalent.
For the sake of our society, let's hope that it stays that way: societies in which people get to control what other people know, say, or think are not democracies.
Maybe you should read past the second paragraph?
But this change will make some important procedures harder (fixing the BIOS, installing old games, etc.). Microsoft may think that most of their customers aren't doing that; but many of their cutsomers hire people to do that sort of thing (or ask friend to do it for them). This makes dealing with Windows machines even more of a pain than it already is. Of course, since CD-ROMs started being inaccessible from DOS mode under standard Windows installations, DOS mode had gotten significantly less useful anyway.
But if I write a piece of software that can be used for file swapping and someone uses it to commit copyright infringement, I may be held responsible for contributory infringement by the RIAA and MPAA?
Even the language and analogy itself is disturbing: creating tools for letting people share information is now on the same level as creating nuclear bombs? Isn't the ability to communicate freely at the heart of a democracy?
I think it's pretty clear what the deciding factor is in who can and cannot be held responsible for the software they create: people with money and political influence are exempted from responsibility. Remember that next time you vote and give the third party candidates a chance. Nader is looking pretty good...
Yes, if bundles are just big executable archive files or directory trees with a known structure, you don't need a database--you can just search through them in a more traditional UNIX shell style. A database approach would be another way, though, of letting both users and packages find the executables they really want (the "owned by..." was just another example--for example, for security reasons, I might not want to execute files owned by anybody else right now).
sub make_package {
my $library = "hello, world";
my $program = sub { print $library,"\n"; }
};
# create the program/package
$package = make_package();
# change the environment incompatibly
$library = "oops, wrong environment";
# run the program
$package->();
This outputs "hello, world" in Perl. In the real world, it will output the wrong thing.
But, yes, fundamentally I agree: doing packaging "right" (in my sense) requires breaking significantly with the way things are done in Linux/UNIX right now. On the other hand, it may be possible to get there without breaking existing functionality. Plan 9 actually has most of the necessary bits and pieces, and it has a usable POSIX system side-by-side with its advanced naming facilities.
For example, one way of getting there might be to start by adopting some kind of "bundle" format for GUI applications (together with a small modification to the kernel to make them executable) and to add an enhanced version of "chroot" (with more control over the environment). I think both of those would be natural, the first for better usability, the second for better security in some applications. Over time, other pieces could fall into place.
Any program is written and tested in a particular environment (libraries, writable directories, etc.) and makes references to those objects. To function correctly, it should really be shipped with the complete environment it depends on. That's no different from a nested function in Scheme or some other fully lexically scoped programming language (sorry, C/C++ doesn't need to apply).
Of course, requirements on applications are a bit more complicated than functions. When shipping the "closure" of a program over its environment in that way, as an optimization, we may not want to ship every single library with it; many of them may be present in the target execution environment (shipping a secure checksum may be sufficient). Furthermore, for some values in the closure, we may want to allow "substitutions". For example, for some libraries, we may want to allow newer versions to be substituted. And some references, e.g., to a "document directory" are dependent in more complex ways on the environment. Such deviations should probably be identified and declared explicitly as exceptions.
Lexical closures get their power from two properties. First, in modern languages, the "free" references to dependencies in an environment are captured automatically and reliably. Second, once closed over an environment, a function can't go out and start accessing other parts of the environment (at least not without being very explicit about it in most languages).
The alternatives (manual declaration of environmental dependencies, unrestricted access) were tried with programming languages, and they led to unreliable programs, and languages got rid of those approaches pretty quickly. We should probably follow a similar path for packaging applications.
For stuff that isn't packaged with the applications, the package format should contain version information and checksums for any other files it depends on. It should declare those dependencies. The operating system should then be able to identify what is needed, possibly fetch it over the Internet, and give the package access to those files under a symbolic path name.
Such application bundles with dependencies should not (normally) be allowed to access the raw file system for their installation at all. In fact, even most applications should probably not be allowed to reference absolute pathnames. All references should be through symbolic paths. That way, one actually has a prayer of figuring out what the thing depends on, and it would also help with security.
Furthermore, the notion of "install scripts" is broken because it is difficult for anything to figure out what went wrong in the bowels of some script, and because scripts may do things to the system that are difficult to undo. Information about how an application bundles and their needs should be entirely declarative.
Another way of looking at that is that applications and application installation needs to work similar to objects and software components. In the past, programs consisted of functions that looked for, and modified, global variables all over the place. These days, good software components have well defined interfaces, get access to their environment only through those interfaces, and rarely use global variables. That's the kind of change that also has to happen at the level of applications.
The system that is closest to that in many ways is Sun Java: with jar files and the JavaBeans standards, there are well-defined ways for software to get installed and interact with the rest of the system, yet the environment can limit what new software components can do. We need something similar for Linux packages. That would also require additional naming and name translation support for Linux, similar to what Plan 9 offers (however, Plan 9 never adopted a good way of packaging applications based on their naming model--a shame, they were pretty close).
Is there any indication that this is more than vaporware? It's easy to promise a consistent, efficient 2D graphics API with transparency support, anti-aliasing, and hardware acceleration, it's a lot harder to deliver on it.
However, this shouldn't be a big problem, since, for the most part, only the window manager needs to know. The X server could send an "physical screen size changed" event to the window manager and the window manager would rearrange the windows to fit onto the new screen size. If the X server disables edge scrolling, the effect is the same as on Windows; whether the off screen pixels are still stored or not is not user visible in any important way.
Windows actually has a lot more of those kinds of "legacy" assumptions built in; for example, many Windows applications cannot conceive of resizing or moving their main window while a modal dialog is up or while they are busy computing. I'll take the fixed screen size assumption over that any day...
For most applications, X11 works OK. If it gets some support for anti-aliasing and compositing, people will be able to do a lot more with it than they can now. Keith's effort seems like a very rational starting point for that: add a small set of server functionalities that addresses the core problems people have.
If X11 additionally got paths, floating point coordinates, and other features in the server, would that significantly expand the application areas for X11? Would it allow existing applications to be speeded up in some important way? If people want those kinds of features, why aren't they using the existing DisplayPostscript extension to X11, already donated by IBM? And is it worth adding a complete 2D rendering API when 3D APIs already provide coordinate transformations, compositing, and all the other features, hardware accelerated, and available on pretty much all platforms, for those applications that really need them?
I can't claim to know the answers; my intuition is that the more minimalist approach Keith is taking is probably the better one for now. But whatever approach might be better in the end, unless significant additional resources materialize, I suspect that is all that realistically can happen. Any volunteers?
Win32 has its own, native widget set, and that hasn't stopped people from porting Gtk, Qt, Tcl/Tk, wxWindows, and lots of other toolkits to it. The same will happen with Berlin if the project produces a usable windowing system at all.
It should be noted that Berlin uses a completely different approach to visuals than anything X ever had. It takes the approach that the application never need know or assume what the visual will look like.
The purpose of visuals in X isn't to make the programmer's life miserable (even if they do that on occasion) but because there was a technical need for it. There are other tradeoffs you can make: Win32 and NeWS took different approaches, with different advantages and problems. Berlin won't be able to avoid the issue either, since presumably applications will be able to draw raw 2D graphics under it one way or another. If it automates the visual management, that's one choice, good for some applications, bad for others.
I still prefer Netscape to IE: with IE, the lack of security is designed in from the ground up (ActiveX etc.). Netscape at least is based on technologies that can be made secure.
For the time being, you just have to turn off Java and JavaScript.
It might also be worth looking at other ways of removing privileges from a running Netscape. Linux chroot, capabilities, various group hacks, LD_PRELOAD, and ptrace, could all be used to detect and prevent undesirable behavior.
Incidentally, whether the Xbox "will be the most powerful" remains to be seen. So far, it is still vaporware, and there is a lot that can happen between now and whenever it sees the light of day.
Actually, for the same number of allocations/deallocations, a garbage collector is often faster than malloc/free or new/delete. The reason why garbage collection seems slower is because it does a lot of work all at once (rather than spreading it out) and because it lets people get away with writing sloppier code. But you don't have to get sloppy just because there is a garbage collector.
Mandating the existence of garbage collection in a language doesn't mean that you can't have C-like features. Java happens not to. But Modula-3, Ada, and other languages are as expressive and efficient as C, yet, unlike C, they also have a powerful safe subset.
To fulfill those promises, Microsoft not only need to do better than some of the best dynamic language implementors in the world, but they need to do the hard work of producing implementations for their less favorite platforms, just like Sun did with Java. Given Microsoft's track record, I suspect that is less likely than the proverbial snowball in hell, and I wouldn't exactly plan projects around Microsoft's promises.
But if they deliver, good for them and good for all of us. Let's hold Hejlsberg to those promises a year from now.
Instead, corporate buyers who have their own ready-made Windows installations should insist on not having Windows preloaded by the manufacturer and receiving a discount on the machine. It's the bundling and tying that's so obnoxious, not the site licensing.