The Python WSGI spec (PEP 333) is trying to address exactly this issue. And I agree it's an issue -- I maintain quite a lot of Python applications (not in CherryPy, but same basic setup) and it can be really annoying. CherryPy supports WSGI, though its WSGI support isn't perfect (but they're aware and working on it).
Relatedly I just released Paste Deploy, which is also intended to address these issues. It's just a small piece that will only be useful given more infrastructure support, but I'm optimistic. In the end I think it will mean some specific setup to support Python applications on a server, but once the basic support is configured adding an application should be a one-line affair.
Python frameworks are now catching up to things like ASP and PHP
While Python web programming has some issues, "catching up" isn't really how I'd describe it. Even in the most basic of Python frameworks you get more expressive power than in ASP and PHP. You also get equivalent performance to PHP (I can't say much about ASP -- but Python is fast enough which is all that matters). In terms of expressiveness Python beats the pants off PHP, Visual Basic, C#, and Java. There's no "catching up" there at all, they were long since passed.
But I'd certainly agree the single process thing is a red herring; it's not what makes CherryPy interesting.
You are being really dense. If an employee is going to study legal statues, then they'll know what their rights are, regardless of the handbook. No one in this case contested what rights employees had. This case about whether the employer is misrepresenting the employees' rights in the handbook, creating a rule that was unenforceable. The employer is not going to put a copy of the ruling in the handbook; the ruling is not any kind of clarification. The ruling did demand that some things in the handbook be clarified; the ruling specifically did not make the employer clarify this part of the handbook at all.
To repeat: when the case is about the clarity of the handbook, the ruling itself is not a clarification. That wouldn't make sense.
Anyway, I don't see the big deal, since the rule has now been clarified anyway. Or do you think the company is going to turn around and fire someone for trying to organize a union, and actually get away with it?
It hasn't been clarified, because the handbook isn't being changed at all. All the ruling was about was whether they would have to clarify this in the handbook.
The issue here isn't whether someone would be fired for trying to organize a union -- though that happens very frequently -- but whether this rule would have a chilling effect on any organizing (formal or otherwise) among employees.
I read the ruling you link to, and I have no idea where you got your interpretation. The rule they quote is:
While on duty you must NOT... [ellipses theirs] fraternize on duty or off duty, date or become overly friendly with the client's employees or with co-employees.
This has nothing to do with uniforms! Nothing! You apparently didn't read any better than the original poster (who also misrepresents this ruling).
This ruling does NOT mean your employer can ban socializing with coworkers. The original article, confirmed by the document you link to, complains that the board did not strike down language in the handbook that APPEARED to bad such socializing.
The NLBR argued that this rule would not be interpreted by employees as forbidding off-duty association. Reading the rule, that is clearly total bullshit, it clearly WOULD be interpreted to ban such association. Their claim that it only would be interpreted as being related to dating and entanglements is bull, since the rule mentions dating, and "fraternization" isn't a qualification of "dating" but an extension of the rule to ban protected behavior.
Of course, this does not actually change employee rights in any way whatsoever. If the employer did fire or discipline an employee for associating with coworkers, that would be just as illegal as before. This is a question of whether the employer can threaten employees with discipline implicitly through confusing and easily misinterpreted rules. That's what the original article talks about and what the ruling confirms.
A bubble sort in assembler of 1 million items might be slower than a quicksort of the same million items in python.
I'd go even further -- it's almost certain to be faster in Python, because you'll be using a highly optimized sort algorithm that someone else wrote in C (99.9% of the time you should use the built-in sorting methods in Python). Unless the assembly programmer is really obsessing over their sort implementation, in which case that programmer should really find Real Work To Do and stop messing around. Did the programmer even check if that sort is a bottleneck?
There are people in this thread who are saying you should carefully understand all your algorithms and know how the big O complexity of sorts and all that; these people are being rather dense. While web application programming does use the occassional "algorithm", the bulk of programming isn't about algorithms at all. It's about designing good abstractions, refactoring, careful error handling, etc. Algorithm design is, for most cases, a solved problem that is only a distraction.
In a high-level language like Python, almost all good algorithm design is figuring out how to map your problem onto the powerful data structures and algorithms already built into the language.
Modern computer science for application developers is about design and methodology, not mathematical algorithms.
Java is high-level compared to C, but compared to any modern programming language it is distinctly low-level. This includes even C++. Java has almost no metaprogramming abilities. Instead it needed Aspect Oriented Programming to accomplish what real high level languages have built in. AOP is about as elegant as doing high-level programming using C macros -- it has to resort to brutally low-level transformations (on the source and bytecode level) because Java doesn't support syntactic or even good object-level abstractions.
Here's a good rule for what a HLL is in 2005:
In a high level language you will not need to automatically generate source code to express your programs in a concise way.
As a specific example, what Hibernate does with source code generation and tons of XML configuration files, other programming languages can do purely with programmer-written source code.
When using a Java 1.5 compiler, all this [autoboxing] is perfectly legal. How, you ask?
Why, no, I wouldn't ask that. In high level languages this isn't and has never been an issue. Java is working hard to get caught up with Smalltalk-80. Shiny new features like generics just look like arcane cludges to those of us who do use HLLs.
I never saw a 'huge' commercial project done in Python, Ruby, Moo or Euphoria, in the last 10 years...
Several 'huge' web companies use Python extensively. Specifically Google and Yahoo both use Python a great deal. Google does all their frontend stuff in C++ and Python (C++ for the speed, obviously). Yahoo is much more eclectic, but they've used Python a great deal in their products for a long time now. Python isn't used a great deal by code monkeys, nor in institutional environments where Java and.NET is popular, but Python has been used in some very large projects.
Of course there's lots of options for Python besides Zope. Some say too many options, but there's a standard for smoothing out those differences, and there's been a lot of progress on that front in the last six months or so. Coming into Python this won't mean much, except that you won't find yourself in a dead end if you choose wrong from the available options.
You don't understand one of the most important necessary preconditions for a larger web app in corporations - someone to approve it.
J2EE and ASP.NET have rich organizations that they can loan you to take key decision makers (CFOs) out to lunch to help approve expensive J2EE projects.
This is one of the good aspects of things like Rails -- because large organizations have disfunctional decision making processes, it gives small more independent developers and shops a leg up. Damn, from that perspective it almost seems like a feature that Rails doesn't appeal to CFOs or compete head-to-head with J2EE.
There's something kind of karmic about this, really. Those big organizations get exactly what they want, and exactly what they deserve: a big smelly heap of J2EE. Why should we try to convince them of the technical superiority of our techniques, unless we actually care about the success of the institutions themselves? We have nothing to win -- if we're wrong, then we lose credibility; if we're right, then they get to take our good ideas.
Re:Ruby on Rails as a threat to PHP?
on
Ajax On Rails
·
· Score: 1
Incidentally Google doesn't use PHP at all as far as I know; they use Python, C++, and Java. I can't say why they don't use PHP; but I think because Python fills that niche well for them, and because they have a small number of very good programmers, and PHP is limiting for that kind of programmer. Oh, and of course they use Python for a lot of their internal tools, and PHP is wholely inappropriate for that.
But, with respect to the parent post, I very much doubt their lack of PHP has anything to do with scalability, and certainly nothing to do with commercial tools.
Zope targets a very different space than Rails. It's always been a bit of a struggle for a programmer -- it tries to make certain things easy, and in the process makes other things very hard, or introduces very difficult magic. You can't get your head around Acquisition, no matter how you try it'll kick your ass periodically.
If you are comparing Rails and Zope, you probably aren't comparing things properly. Doing a CMS? Then Zope has a lot of infrastructure, and Rails has none. Doing a small databased-backed web application? Then Zope will be rather painful.
If you want to compare a Python option to Rails and Ruby, you should look at something like Paste/Webware, CherryPy, Subway, Aquarium, or others. There's a lot of choices, but there's very active work to bring together these web platforms, so won't be trapped by your initial choice.
Perhaps it's because x86 is much easier to code morph than a RISC architecture, because you have more to work with.
Re:Why isn't this already out?
on
Next Generation X11
·
· Score: 2, Informative
If there's no X process, then what handles windows? GGI, at least from what I can see on its website is simply an API that provides access to low level functions, pretty much like SDL.
GGI isn't a replacement for X, but is an example of that architecture applied to a subset of what X does. GGI has multiple backends. The GGI API is translated to the backend differently depending on the nature of the backend. For instance, some hardware implements some high-level rendering in the hardware. For other hardware some of that rendering may have to be done in software. A network backend, for instance, would turn those API calls into some form of communication and send it over the net.
Under GGI that would be, at best, a VNC style of network transparency, and you'd get a rectangle on the other end of the connection. But GGI isn't a replacement for X; if you were to implement X this way then you'd have multiple xlib implementations which forms a higher level API than GGI, with concepts of windows and whatnot.
If you want a thin layer that lets you draw stuff on the screen you can have it already: The framebuffer.
Funny you should mention it. The problem with the framebuffer is that the API is bound to the implementation. It's a framebuffer; but that implementation doesn't fully describe the hardware available. GGI has a higher level API, and so the GGI API can be translated into commands to the graphics card that take better advantage of the card's ability. Again, this isn't an X replacement, but an example of an architectural style (which I'm asserting is superior to X's client/server style).
Though you were right when you said that X is moving in the direction of an API. Something like the Render extension is the style I'm talking about (at least from my understanding of how such extensions work). It's primarily an API, not a protocol. It can be implemented in terms of the stable X protocol, but to be efficient that is usually shortcutted, using some protocol I know nothing about and probably isn't standard. (Yes, it does it with shared memory or somesuch -- but shared memory isn't a "protocol"; you need to define what you put in that shared memory, not just where it is, and AFAIK these extensions to not try to define that what in any formal way.)
There is a standard API, the X library. It's not like its interface changes every week or something. I don't know of any applications that talk the X network protocol directly.
Exactly, which is why this can be resolved in a backward-compatible way (for clients, not servers of course). Which is exactly what I said in my original reply. Keep the xlib library, turn the X protocol into an incidental implementation detail which can be replaced. If you have an X server, then some protocol will be present. I don't believe the presence of an X server process is absolutely required.
Nothing at all oddball about it.
I said, very specifically, that a client/server display is an oddball architecture. Not that the way it implements client/server is odd.
I know how this stuff works, but I'm talking about architecture, not the implementation details you are focusing on. The architecture I'm talking about exists right now, it is mainstream (outside of X), and can be backward compatible with most X applications. GGI (using an API-based architecture) was a great idea, and I don't know why no one ever paid it much attention. I'm not arguing for Y, or Berlin, or any of those other things. I am arguing that network transparency should be implemented on top of this architecture, not as part of it, and X inappropriately mixes the two (and mixes all sorts of other things in there too, most of which it does poorly).
Maybe the X architecture isn't really to blame, but the traditional monolithic X development process. Maybe this architecture is only appealing because it makes it easier to route around that process. But there's a benefit in that too.
By standardizing on only an API, the protocol becomes ad hoc. That is, it could be a kernel call, or IPC, or send data over the network, or do the work in process, or whatever. There are real and valid reasons for all of those options, even if each might not be reasonable in all cases. For instance, using the same API for printing is reasonable, and should probably be done in process. There's no reason to have a standard protocol, because there aren't multiple viable implementations of that protocol (at least on the client side, and I believe the protocol provides a difficult abstraction barrier for efficient servers).
If it's best to put the display code in the kernel, then this opens up that possibility, but does not require it. It opens up a wide variety of possibilities, where a protocol is limited to a client/server architecture. X's client/server architecture is the oddball in the world of display architectures, while a standard API is the norm.
I believe this is the way the GGI project is architected, so it's not a crazy idea at all.
Re:Why isn't this already out?
on
Next Generation X11
·
· Score: 2, Insightful
There has to be some way for an application to talk to X. So, you remove the network protocol, how do you want to talk it to X then, magic? In order for two different programs to talk to each other there has to be some kind of protocol, no way around it.
Sure there's a way around it: an API. X has an API (xlib, the C library). But it also has a protocol, the means by which xlib communicates with the X server. In theory the protocol could be removed now without effecting most client programs, though I assume that would effect the implementation dramatically.
In a kind of parrallel situation, the GNUStep people were trying to figure out what to do with Display Postscript -- they didn't have a good or fast implementation, and DPS was supposed to be central to the NEXTSTEP design they were copying. Then someone hacked together something that implemented the Objective C bindings that generated Postscript, and made them call the xlib libraries directly, because the whole DPS thing was taking too long. It was meant as an intermediate step... but it worked. Last time I looked (which was a long time ago) they had given up on DPS as a pointless abstraction. If they want to implement accurate printing later, they can do so by creating another, entirely separate Postscript-generating layer (but without having to worry about performance or interactivity or other non-print related things).
The same possibility exists for X. Give up on the client/server and network transparency. If it matters so much, you can easily implemented it on top of a non-transparent system (as long as you have a defined API with no back doors). If it matters so much there's probably multiple ways of implementing transparency with different tradeoffs. Various hardware would have different implementations of the xlib C API -- those implementations could share code, but only if they wanted to. All the other policy, like fonts and security and whatnot, would be implemented separately, which is already happening anyway.
We have a layered system. And that's fine (and even if it wasn't it can't be changed). But X got some of the layers wrong, I think it actually did too much. That can be fixed.
Packages made for sid don't even work on sarge all the time without pulling in extra packages from sid. That's the same thing that happens with packages meant for Ubuntu.
My impression was that the experiences are quite different. On Debian you can install a consistent set of packages, or you can't. The integrity of your system is not dependent on keeping your packages consistent across a major release. The releases mark a set of packages that go well together, in that upgrading within your release won't cause a cascade of new dependencies that is out of control. But that's about all it does.
With Ubuntu you get the possibility that you can install a.deb package and get an inconsistent system. That's essentially a new problem -- I guess it could have happened with other Debian forks, but they never got that far for it to be an issue.
That doesn't even make sense, if you understand the process behind Debian and Ubuntu. The majority of work towards Ubuntu has been from Debian developers -- if they were starting from scratch they'd have nothing. And the majority of work will continue to be done by Debian developers, who still outnumber Ubuntu developers by very large numbers, and Debian has a process to support that kind of size. There might be issues with that process, but that doesn't invalidate the size and skill of the community behind Debian, nor does Ubuntu offer a comparable experience for developers.
And it doesn't have to -- Ubuntu isn't out to beat Debian. At all. They are using different release methodologies, and are essentially forking Debian Policy where they see fit. But in their effort for short-term usability improvements, there's the danger that they'll create a difficult to maintain system -- and Debian's fundamental maintenance abilities are probably its best feature. And probably why Ubuntu is based on Debian.
This is the big difference between a religious attitude towards OSS and a laid back engineering style attitude.
Use the best tool for the job and do not let religion get in the way of that decision!
This is fine if you are willing to ignore the dynamics of the community. Which, frankly, is a dumb managerial attitude, and poor judgement on Linus's part. You can't change the Linux community to stop caring about OSS values -- and asking them to stop caring is just crazy on all sorts of levels. When taking a more wholistic view of the SCM decision, Linus's decision simply didn't make pragmatic sense given the real constraints and requirements of the community.
SCM is all about issues of cooperation, workflow, management and review structures, and as such is intimately tied to the nature of the community. BitKeeper in some ways addressed that well, with a distributed style of development. However, licensing is real, and the BitKeeper license was antithetical to philosophies that were important to many developers, and to the larger environment of software which supports Linux and which Linux supports. Licensing has real and dramatic effects on architecture and process, and paying attention to that isn't religion. Maybe ignoring that is a layed-back engineering attitude, but that's "engineering" as a perjorative -- the kind of single-minded stupidity sometimes seen in over-specialized engineers who lose sight of the goal and focus on only the implementation.
We already are seeing lots and lots of projects moving to Subversion, so the CVS shift is already happening. I think this opinion piece is good reasoning on why Subversion is a good model for most open source projects -- maybe not including the kernel, but including the bulk of projects. I'm seeing an increasing number of Subversion repositories which resolve the access issue by just giving nearly anyone access -- it's all versioned, so it's no big deal. This is a kind of collectivist trend that really requires community cooperation, and builds the social foundations of a developer community (through transparency and continuous integration) in addition to the technical merits of version control.
That isn't to say a distributed system wouldn't also be able to accomplish some of this stuff, but rather that Subversion is very usable Right Now (already much better than CVS), and its flaws compared to distributed systems are minor. Maybe the nature of cooperative development will change in the future -- that is very possible! -- but Subversion is a good tool for Right Now.
Python has excellent Unicode support, and I'd say that its general i10n/i18n support (which is really a vague category of support, but common in Python apps) is a big part of why it's caught on well in Europe. Also, there is some auto-completion available in Python IDEs, and in quite a few interactive interpreters (rlcompleter2) is a neat implementation of this). It isn't the same as in a Java or C# IDE -- that's just infeasible in a dynamic language -- but there's some help available there.
Anyway, you don't need Java to handle these issues.
But UTF-8 isn't Unicode. It's an 8-bit encoded version of Unicode.
Everytime I learn something new about Unicode, I recognize a New Hard Aspect of it. It's true, in many ways UTF-8 is a workable way to handle Unicode without real Unicode objects (and I know nothing about Ruby's Unicode support), but there are subtle aspects where a standard encoding is not the same as real support.
Huh, highish rated posting with no replies, I guess other people are also curious. I know about Zope 3, but I haven't used it at all seriously.
Zope 3 is really targetted at J2EE-like functionality. Rails is based on a You-Ain't-Gonna-Need-It philosophy -- it provides significant base functionality and a set of conventions, but the framework is not all-encompassing or intended to match J2EE feature-for-feature, nor as a framework does it really mean much outside of the web. This is by design.
Zope 3 is really a whole design philosophy, kind of like J2EE. It makes heavy use of interfaces and adapters, which are intended to bring an increased level of formality to the development process. But it's not just an attempt to put static typing on top of a dynamic language; the techniques they use are fundamentally dynamic, and an attempt to utilitilize those formalisms as basic programming constructs. This is embodied in the idea of "adaptation", where instead of requiring an interface, you ask for a version of an object that implements the interface, and then you provide wrappers ("adapters") to translate interfaces.
There's other ideas in there too, generally built upon these basic programming ideas. It's a framework of frameworks. It's also heavy on the idea of modeling, and of an applications that provide a window into your models. The entire scale and concept is very different from Rails. It's actually a little foreign to the Python community too. A lot of Zope 2's ideas were also foreign to the Python community, but the problem is that they were also uncomfortable and put people off -- I don't think people are uncomfortable with Zope 3 as much as unfamiliar.
(Also, Zope 3 is a complete rewrite of Zope 2 and is very different, so most of people's experience of Zope 2 -- good or bad -- can't really be applied to Zope 3)
Slashdot Mirror
Relatedly I just released Paste Deploy, which is also intended to address these issues. It's just a small piece that will only be useful given more infrastructure support, but I'm optimistic. In the end I think it will mean some specific setup to support Python applications on a server, but once the basic support is configured adding an application should be a one-line affair.
But I'd certainly agree the single process thing is a red herring; it's not what makes CherryPy interesting.
To repeat: when the case is about the clarity of the handbook, the ruling itself is not a clarification. That wouldn't make sense.
The issue here isn't whether someone would be fired for trying to organize a union -- though that happens very frequently -- but whether this rule would have a chilling effect on any organizing (formal or otherwise) among employees.
This ruling does NOT mean your employer can ban socializing with coworkers. The original article, confirmed by the document you link to, complains that the board did not strike down language in the handbook that APPEARED to bad such socializing.
The NLBR argued that this rule would not be interpreted by employees as forbidding off-duty association. Reading the rule, that is clearly total bullshit, it clearly WOULD be interpreted to ban such association. Their claim that it only would be interpreted as being related to dating and entanglements is bull, since the rule mentions dating, and "fraternization" isn't a qualification of "dating" but an extension of the rule to ban protected behavior.
Of course, this does not actually change employee rights in any way whatsoever. If the employer did fire or discipline an employee for associating with coworkers, that would be just as illegal as before. This is a question of whether the employer can threaten employees with discipline implicitly through confusing and easily misinterpreted rules. That's what the original article talks about and what the ruling confirms.
There are people in this thread who are saying you should carefully understand all your algorithms and know how the big O complexity of sorts and all that; these people are being rather dense. While web application programming does use the occassional "algorithm", the bulk of programming isn't about algorithms at all. It's about designing good abstractions, refactoring, careful error handling, etc. Algorithm design is, for most cases, a solved problem that is only a distraction.
In a high-level language like Python, almost all good algorithm design is figuring out how to map your problem onto the powerful data structures and algorithms already built into the language.
Modern computer science for application developers is about design and methodology, not mathematical algorithms.
Here's a good rule for what a HLL is in 2005: In a high level language you will not need to automatically generate source code to express your programs in a concise way.
As a specific example, what Hibernate does with source code generation and tons of XML configuration files, other programming languages can do purely with programmer-written source code.
When using a Java 1.5 compiler, all this [autoboxing] is perfectly legal. How, you ask?
Why, no, I wouldn't ask that. In high level languages this isn't and has never been an issue. Java is working hard to get caught up with Smalltalk-80. Shiny new features like generics just look like arcane cludges to those of us who do use HLLs.
Besides the Wiki page, this is a subjective but amusing review of the options.
There's something kind of karmic about this, really. Those big organizations get exactly what they want, and exactly what they deserve: a big smelly heap of J2EE. Why should we try to convince them of the technical superiority of our techniques, unless we actually care about the success of the institutions themselves? We have nothing to win -- if we're wrong, then we lose credibility; if we're right, then they get to take our good ideas.
But, with respect to the parent post, I very much doubt their lack of PHP has anything to do with scalability, and certainly nothing to do with commercial tools.
If you are comparing Rails and Zope, you probably aren't comparing things properly. Doing a CMS? Then Zope has a lot of infrastructure, and Rails has none. Doing a small databased-backed web application? Then Zope will be rather painful.
If you want to compare a Python option to Rails and Ruby, you should look at something like Paste/Webware, CherryPy, Subway, Aquarium, or others. There's a lot of choices, but there's very active work to bring together these web platforms, so won't be trapped by your initial choice.
Perhaps it's because x86 is much easier to code morph than a RISC architecture, because you have more to work with.
Under GGI that would be, at best, a VNC style of network transparency, and you'd get a rectangle on the other end of the connection. But GGI isn't a replacement for X; if you were to implement X this way then you'd have multiple xlib implementations which forms a higher level API than GGI, with concepts of windows and whatnot.
Funny you should mention it. The problem with the framebuffer is that the API is bound to the implementation. It's a framebuffer; but that implementation doesn't fully describe the hardware available. GGI has a higher level API, and so the GGI API can be translated into commands to the graphics card that take better advantage of the card's ability. Again, this isn't an X replacement, but an example of an architectural style (which I'm asserting is superior to X's client/server style).Though you were right when you said that X is moving in the direction of an API. Something like the Render extension is the style I'm talking about (at least from my understanding of how such extensions work). It's primarily an API, not a protocol. It can be implemented in terms of the stable X protocol, but to be efficient that is usually shortcutted, using some protocol I know nothing about and probably isn't standard. (Yes, it does it with shared memory or somesuch -- but shared memory isn't a "protocol"; you need to define what you put in that shared memory, not just where it is, and AFAIK these extensions to not try to define that what in any formal way.)
I know how this stuff works, but I'm talking about architecture, not the implementation details you are focusing on. The architecture I'm talking about exists right now, it is mainstream (outside of X), and can be backward compatible with most X applications. GGI (using an API-based architecture) was a great idea, and I don't know why no one ever paid it much attention. I'm not arguing for Y, or Berlin, or any of those other things. I am arguing that network transparency should be implemented on top of this architecture, not as part of it, and X inappropriately mixes the two (and mixes all sorts of other things in there too, most of which it does poorly).
Maybe the X architecture isn't really to blame, but the traditional monolithic X development process. Maybe this architecture is only appealing because it makes it easier to route around that process. But there's a benefit in that too.
If it's best to put the display code in the kernel, then this opens up that possibility, but does not require it. It opens up a wide variety of possibilities, where a protocol is limited to a client/server architecture. X's client/server architecture is the oddball in the world of display architectures, while a standard API is the norm.
I believe this is the way the GGI project is architected, so it's not a crazy idea at all.
In a kind of parrallel situation, the GNUStep people were trying to figure out what to do with Display Postscript -- they didn't have a good or fast implementation, and DPS was supposed to be central to the NEXTSTEP design they were copying. Then someone hacked together something that implemented the Objective C bindings that generated Postscript, and made them call the xlib libraries directly, because the whole DPS thing was taking too long. It was meant as an intermediate step... but it worked. Last time I looked (which was a long time ago) they had given up on DPS as a pointless abstraction. If they want to implement accurate printing later, they can do so by creating another, entirely separate Postscript-generating layer (but without having to worry about performance or interactivity or other non-print related things).
The same possibility exists for X. Give up on the client/server and network transparency. If it matters so much, you can easily implemented it on top of a non-transparent system (as long as you have a defined API with no back doors). If it matters so much there's probably multiple ways of implementing transparency with different tradeoffs. Various hardware would have different implementations of the xlib C API -- those implementations could share code, but only if they wanted to. All the other policy, like fonts and security and whatnot, would be implemented separately, which is already happening anyway.
We have a layered system. And that's fine (and even if it wasn't it can't be changed). But X got some of the layers wrong, I think it actually did too much. That can be fixed.
With Ubuntu you get the possibility that you can install a .deb package and get an inconsistent system. That's essentially a new problem -- I guess it could have happened with other Debian forks, but they never got that far for it to be an issue.
And it doesn't have to -- Ubuntu isn't out to beat Debian. At all. They are using different release methodologies, and are essentially forking Debian Policy where they see fit. But in their effort for short-term usability improvements, there's the danger that they'll create a difficult to maintain system -- and Debian's fundamental maintenance abilities are probably its best feature. And probably why Ubuntu is based on Debian.
SCM is all about issues of cooperation, workflow, management and review structures, and as such is intimately tied to the nature of the community. BitKeeper in some ways addressed that well, with a distributed style of development. However, licensing is real, and the BitKeeper license was antithetical to philosophies that were important to many developers, and to the larger environment of software which supports Linux and which Linux supports. Licensing has real and dramatic effects on architecture and process, and paying attention to that isn't religion. Maybe ignoring that is a layed-back engineering attitude, but that's "engineering" as a perjorative -- the kind of single-minded stupidity sometimes seen in over-specialized engineers who lose sight of the goal and focus on only the implementation.
That isn't to say a distributed system wouldn't also be able to accomplish some of this stuff, but rather that Subversion is very usable Right Now (already much better than CVS), and its flaws compared to distributed systems are minor. Maybe the nature of cooperative development will change in the future -- that is very possible! -- but Subversion is a good tool for Right Now.
Anyway, you don't need Java to handle these issues.
Everytime I learn something new about Unicode, I recognize a New Hard Aspect of it. It's true, in many ways UTF-8 is a workable way to handle Unicode without real Unicode objects (and I know nothing about Ruby's Unicode support), but there are subtle aspects where a standard encoding is not the same as real support.
Zope 3 is really targetted at J2EE-like functionality. Rails is based on a You-Ain't-Gonna-Need-It philosophy -- it provides significant base functionality and a set of conventions, but the framework is not all-encompassing or intended to match J2EE feature-for-feature, nor as a framework does it really mean much outside of the web. This is by design.
Zope 3 is really a whole design philosophy, kind of like J2EE. It makes heavy use of interfaces and adapters, which are intended to bring an increased level of formality to the development process. But it's not just an attempt to put static typing on top of a dynamic language; the techniques they use are fundamentally dynamic, and an attempt to utilitilize those formalisms as basic programming constructs. This is embodied in the idea of "adaptation", where instead of requiring an interface, you ask for a version of an object that implements the interface, and then you provide wrappers ("adapters") to translate interfaces.
There's other ideas in there too, generally built upon these basic programming ideas. It's a framework of frameworks. It's also heavy on the idea of modeling, and of an applications that provide a window into your models. The entire scale and concept is very different from Rails. It's actually a little foreign to the Python community too. A lot of Zope 2's ideas were also foreign to the Python community, but the problem is that they were also uncomfortable and put people off -- I don't think people are uncomfortable with Zope 3 as much as unfamiliar.
(Also, Zope 3 is a complete rewrite of Zope 2 and is very different, so most of people's experience of Zope 2 -- good or bad -- can't really be applied to Zope 3)