Plone obviously scales well, but is also very easy to use for quickly getting started with small-group content management. Consider this:
Plone is easy to install - get Andy McKay's Win32 installer or Jim Roepcke's Mac OS X installer Get 'em here and you will be up and running in 10 minutes with a Plone site pre-configured by the installer. Also you can get RPM or DEB packages.
Default workflow and content types let you hit the road running: you have documents, news items, events, images, etc.
Customization examples are available - Andy's ZopeZen skin is available in the collective - a good example of doing a weblog-style site in Plone.
Plenty of add ons mean less code you have to write: check out the collective project on sf.net, mentioned above.
Membership and security is built-in - you could do complex stuff like authenticate off of mysql or LDAP, but the default user-folder (and upcoming group support in Plone 2.0) system is capable and easy to work with without the fuss or worry.
Simple workflows can be changed through the web; you want to do a google search for "CMF workflow just publish" - or better yet, just grant your small group publish abilities, and let them choose to do it. If you want to hack the edit script, one line of code would trigger the publish workflow transition, if you want to save some clicks. The point is that this is very customizable, and on the other end of the spectrum, you can do things like email notification in your workflow scripts with a bit of cut and pasting some stock code.
Recipes abound on zopelabs.org under the CMF category
With Plone 2.0, you can seriously customize the UI without changing the templates, just by haing and admin change values ina web form that are plugged into dynamically generated CSS.
One of the most supportive mailing lists and IRC (#plone on irc.freenode.net) channels on the planet.
...of the development process. Projects with vibrant, enthusiastic communities will tend to exceed, both socially, and technically. This is one of Plone and Zope's greatest assets. So, if you think of it this way, it is more than a mere "popularity" contest - it is a measure of dedication, enthusiasm, caring, and a bit of zealotry (not in a bad way) - these are good leading indicators as the the strength of the product via its support mechanism and community.
Make fun of "buzzwords" if you will, but getting open-source into government and private-enterprise that works with government is important, and lack of accessibility is a deal-breaker for those kinds of projects. Standards are important to doing business with technology - that's the process you go through to generate something called money (perhaps you've heard of this, no?).
...that Plone's UI (esp. in 2.0 beta) is modular. It is Section 508 and W3C WAI compliant. It also can be rendered on mobile-phones, large-format, and presentation/print CSS devices without need for ANY changes to the HTML output or multiple sets of templates. From an architecture and extensibility standpoint, Plone's UI is really best-in-class. It also has the largest and most diverse audience and user-base of any open-source CMS, as well as formal standards for process improvement (the PLIP process), which definitely aides in the UI development/refinement process.
1. Open source on the desktop is an important issue, regardless of where you come down on it.
2. Zope's scalability is more transparent than any other app server or CMS product on the market today. With ZEO clustering coming with little/no need to write extra code to make your deployment scale-out, this is a win. Add to that mature caching frameworks and provend interoperability, the above post is definitely uninformed.
3. These projects represent an important open-source future, just as much as they represent the present. Eveyone already knows about the Kernel and Apache. This is an opportunity for these important projects to show their stuff and move open source software "up the stack" to higer levels (don't underestimate how important this is to the future of open-source!).
From a user who uses every piece of software on that list, I have to disagree.
Sure KDE was a winner - but number one in the vote tally was Plone. Why? Becuase Plone has a large, enthusiastic community. Plone is faily new in the grand scheme of things, compared to these other projects. Why Plone got the most votes is that it has a lot of the most "finishing work" of many projects - it will be a good ambassador for open-source products and frameworks.
Sure, the KDE, GIMP, GNOME, and OpenOffice folks have been around for a while, and obviously get in on both quality and recognition, but it's important to see that Zope and Plone also are getting a lot of deserved attention at the same level as these other four well-known open-source projects.
...in the US, we bomb foreign countries for less invsive violations of human rights, such as free speech. Imagine these folks suign the Debian project, for example. I'm more worried day-to-day about the more suttle, under-the-table terrorism enacted against our industry and trade by those willing to exert power through the legal and patent system. The problem here is that enforcing a patent can trace its authority to the end of the barrel of a law-enforcement officer's handgun, or the weapons of economic ruin in court pronouncements. As long as corporations can carry this kind of power protected by the rule-of-law to stifle free speech and free enterprise, how can it not be called fascism? It's not a stretch to call this violence, is it? What kind of sentences should we give to violent criminals (perhaps better use of the court system)?
They would really need to sweeten the pot to make this interesting. They need to be able to have a single appliance software stack that is capable of exporting filesystems over the network as well as block devices. If they added something on the SERVER end like HyperSCSI (or iSCSI, but HyperSCSI is faster/free), it would be more interesting, no?
My company is a large-market daily-US newspaper, and we are building CMS systems in Zope & Plone (using Python). There may be several advantages to using a scripting language, but a shift from Java to a non-OO scripting language like PHP is likely higher risk for you - Zope (and the Zope Content Management Framwork) may offer a better solution given it has a toolset of components to leverage out-of-the box, and a simple, component-oriented way of developing content management applications with a scripting language that is easier to use, but just as scalable as Java-based solutions.
Because it uses an object database for content repositories for digital asset management, you minimize the need to do object-relational serialization and marshalling between an OO system and a relational datastore. However, this isn't as complicated as it sounds; consider something like Archetypes, a schema-driven content type generation system that also has built-in relationship management for composition of media products from related assets.
Shameless plug: I'll be giving a talk on how we are doing much this at the Plone Conference. in October in New Orleans.
Scalability costs with this type of content-management solution will not be in licensing of yor apps, but in commodity hardware (scaling out). These costs would be greater than if you used something much more bare (i.e. PHP has no security model built-in, so pages might require less resources to render, but you get more limited flexibilty or need to implement such a layer anyway for your application, negating the performance difference), but performance and price would likely be on-par or more competitive than Java solutions.
If you are not in the market to build, but to buy the first 80% of your way into a solution, Zope Corporation has built a commercial CMS product on top of these open-source foundations (Zope/CMF, Squid+ESI) - it is called Zope4Media, initially developed for Viacom and Boston.com (one of the largest local media sites out there, which might speak for the performance characteristics of a well-designed Zope application).
I wonder sometimes what Apple doesn't gradually dump AppleScript for Python? Think about it: it would give them a scripting platform as powerful as powerful as Java, but (nearly) as simple as AppleScript (perhaps more readable, and certainly more maintainable). Python 2.3 is going to get bundled with Panther, and is used in some core "essential functionality" in Panther and already has bindings to pretty much everything one would needs to tightly stitch to Apple's platform (ojbc, quartz, Java apps via JPE, etc).
Who cares? Machine cycles are cheap...
on
Does C# Measure Up?
·
· Score: 2, Insightful
Bruce Eckel sums it up best:
"Programmer cycles are expensive, CPU cycles are cheap, and I believe that we should no longer pay for the latter with the former. " from a post by Bruce Eckel on artima.com.
Perhaps people should stop obsessively benchmarking platform VMs, and start benchmarking coding productivity and teamwork, perhaps in Python, with the performance bits in C. For a real-world example, Zope does exactly that: 95% of the code in Zope ends up being done in Python - only the real performance-intensive stuff need be in C... and the stuff done in Python is easy to read, modify, reuse, and tweak (thus, better productivity for both developers that use Zope as and app-server platform well as developers who work on Zope's core).
PHP is popular (as is M$ ASP) becuase it has a gentle slope for web designers to learn programming. I don't think this is a bad thing, but inlining code and presentation is really not the right way to be encouraging new folks to programming to code... PHP teaches programmers bad habits like excessive use of global namespaces, and generally is accomplished with poor editing style becuase it is inlined with HTML, which has different needs for editing/indentation/etc.
A more appropriate introduction for this audience to programming might be python and TAL (template attribute language - the core of Zope's Page Templates, and the only vendor-neutral industry standard, cross-language templating system beside XSLT). I'm not suggesting Zope is appropriate for everyone (though for big apps, it really is best), but perhaps mod_python + page templates would be a better alternative for lightweight web-based scripting than PHP.
PHP does not work well for team programming, and Python does. If you are developing applications in a vacuum, by yourself, this may not matter, but on a team where you need to have coders of many skill levels, business managers, and designers interact, you really need to divide logic from presentation, and use componentized code with explicit namespaces to enable that sort of interaction. Otherwise, it just more <?PHP include("./someunknownquantity.php"; ?> magic.
PHP suffers readability not in syntax, but in archetecure design. With global namespaces for module functions (say, for example, to FTP a file), you do not have the ability to trace the logic between source files and modules in someone else's code. In addition, PHP encourages the inlining of code in presentation, and most PHP code is not modular (some is) - but on top of that the most popular mechanism for code reuse is eval() and include(), which simply pop more crap into the global namespace without being explicit what they do.
All this impacts readability. Python does not have these problems becuase it encourages explicit namespaces for all objects/modules/packages/classes/etc. Python also enforces readabilty by simple (easy) use of whitespace (this is a good thing.
If you buy this logic, Renquist is just a two-bit terrorist with the wonderous decoration of a black robe. Makes the Critical Legal Studies folks seem more right every day.
Class Action - SCOX to 0.02, acquisition?
on
Settling SCOres
·
· Score: 1
My 2 cents is that SCOX stock price should be driven down to 2 cents.
If all Linux kernel copyright holders (or most) do what this German fellow did, but formed a class action (or several, in each country), SCOX stock price would drop like a stone. It would make SCO a more palatable acquisition target for IBM, but not at a price that makes this strategy threats of men with badges and guns enfocing the a worthy exit for stockholders. This would rid the world of SCO, but in a way that would not validate the sue-to-be-bought model, becuase being bought for pennies on the dollar is not maximizing shareholder value, and it would make a fool out of Mr. McBride, who's just a white-collar thug.
PHP4 is problematic archectecture for what you ask. PHP makes profoundly stupid architecutral blunders like lack of namespaces for library functions, which makes it hard for someone else reading your code to determine where function X came from? Inline includes.evals of code are bad, bad, bad too.
You really want a MVC-ish sort of seperation of concerns, I suppose? Zope will do this: XHTML or XML Zope Page Templates, which are valid XML (code via attributes and XML namespaces) using the TAL namespace. Also, ZPTs will allow you to put mockup in your templates and strip out at runtime. In Zope, page templates (view) use simple Python scripts or ZSQL methods for glue logic (controller), and support either content objects developed as low-level Python Products (model) and stored in the object database, or alternately, just have content stored in every RDB you could think of. Best of all, Zope uses Python, which is a much more clean language.
You are going to spend money on an LCD display for a server that sits at a co-lo facility with noone looking at it 99.3% of the time? This is so 1999. I'm not trying to insult you, but question your understanding of the alternatives, which are likely to be more simple.
got Unix? Serial console!!! On Linux, edit lilo.conf, and edit/etc/inittab, put your consoles on/dev/ttyS0 - it only makes sense!
Windoze? A network-capable kvm is likely about the same price as an LCD display, and scales to multiple boxes. But even cheaper is VNC, which can be tunneled over pub key authenticated SSH for remote access.
Co-lo facilities are likely to be charging 15-25 USD per rack unit per month, and a 15" CRT takes up 8 units, so you end up paying at least 120 USD a month to not see a monitor most of the time. What a waste. If you go the VNC or serial console route, even without an expensive Mainboard with remote access to the bios setup, etc, you can still get away with no monitor - and when you do need one, your colo provider should have a monitor on a cart you can use gratis (if not, screw them and go elsewhere - it is a competitive enough business that they can't screw you).
The reason that the LCD in the drive bay thing has gone away is that it is too much of a niche item to survive in a commoditized economy where hardware has low margins (this is also known as reality). Welcome to 2003 - scale down your expectations.
Folio NFO files are too much of a niche format to have already been reverse engineered, so you likely want a text dump of the content. This is not a problem, as Folio software does have export abilities.
You likley want to get your hands on a copy of Folio Views for Windows or Macintosh. First, keep in mind that there are differences between the 3.x and 4.x infobases. You need to find out which version of Folio products produced your infobase. If nothing else, Folio Views 4.x will read the older NFO files. You want to export the infobase from Folio Views to a Folio Flat File (FFF, very simple SGMLish, but not quite SGML text).
You will likely need to buy this from an OEM, since NextPage stopped producing this a long time ago. Here's the history: Folio was the default search engine for Netware many moons ago, and was popular, and then had DOS, then 16-bit windows versions of their "Views" product (2.x and 3.x line). Folio was purchased by Lexis-Nexis, and then sold to OpenMarket, who didn't want it, and eventually sold it back to its original founders, who changed the name of the company to NextPage. During the time it was at OpenMarket, a 4.x version of Views was released, which is win32 (and also MacOS app).
FYI, FFF is very easy to work with. I've written text filters to work with it, and it's as easy as any other decently-marked-up format, even if it is not SGML. I do not know of any way to get an NFO out to FFF without a copy of Views.
Tip: My former employer NewsView Solutions is one of the few OEMs still selling Folio-branded products, and still uses the Folio Views 4.x products alongside with their digital asset management software. They could sell you a copy of Views (I forget about pricing).
Though not mentioned, genetic conditions related to clotting factors might also be a factor (pun intended) in the development of DVT. For example, those most prone to problems on long flights are people with conditions like Factor V Leiden (3-5% of US population has this condition, most don't know about it) are likely to contribute to this. My hunch is that the guy with problems mentioned in the article likely had a clotting factor condition, which predisposed him to trouble, and he (unintentionally) found it working long periods of time at his desk.
Progress is underway for a zope.org community site replacement that will be based on more recent versions of Zope and the Content Management Framework. This should defitely improve things (searchability, news, product listings).
The Zope community, though, is very rich, and the mailing lists generate a lot of traffic; also, #zope and #plone on openprojects (or whatever its called now) are useful resources.
Zope 3X really provides a framework much more focussed on developers creating and leveraging services and applications, and less on the out-of-the-box feel. The main ideas behind Zope3X are to lower the barrier to writing Python product code, and leverage existing Python modules and applications more readily; also, focusing on component-oriented design (favor composition to inheritance and a bunch of mixin classes; where Java forces you through lack of multiple inheritance to do this, Python is more flexible, and with this comes a downside of overuse of inheritance in Python, of which Zope2 is a good example; Zope3 solves this to lower the learning curve and decrease complexity).
Overall, I think Zope 3 will become a convincing alternative to.NET and J2EE people who want to code in a better language;) with a decent framework. In the meantime, Zope2 is still an excellent product for complex applications, and in particular for content-heavy applications that can leverage both built-in transaction support, object-persistence, and good relational database support.
Performance versus VMware, Plex86, User-Mode Linux
on
Bochs 2.0 Released
·
· Score: 1
I'm curious... For virtual servers along the line of something like VMWare's GSX product, how well does bochs perform compared to these 3 alternatives?
Good comparitive examples...
on
PHP5 Coming Soon
·
· Score: 2, Informative
...or why python is better on the backend and the front-end.
Like Java, Python already does assignment by reference, copy is optional. PHP is just figuring this out. PHP's language leaves much to be desired in team programming and code readability. Using 'Design Patterns' is only half the equation. You can do component oriented programming, but some languages are going to be better than others at facilitaing it in a manner that works in reality. PHP5, unfortunately, won't hold a candle to Zope 3, which is really going to compete at the level of J2EE and.NET as well-thought-out enterprise component frameworks.
PHP lacks object persistence, multiple inheritance, full-featured transaction machinery, a built-in security model, an interactive command-line interpreter, and it is too tied to web-scripting only. And becuase it doesn't have a security model that binds operations to roles/permissions, it can't easily put gateway methods with bound roles (like Zope's proxy roles) between web code and SQL code, leading to increased chance of SQL injection vulnerabilities.
On the other hand, Zope has object perisistence, transactional RDBMS integration and connection abstraction, templated, componentized SQL methods, a security framework, and Python, which is a much better language (explicit is better than implicit). And if you need to do any sort of content-management, Zope has a mature component-oriented framwork in the CMF, with a killer-app implementation in Plone. It also has XML-RPC, WebDAV, Caching managers, and all sorts of other goodies you won't find out of the box in PHP.
PHP is fast, and it is easy, but it is by no means scalable. PHP offers a gentle slope learning-curve, and quick easy hacks, but is somewhat like a crack addiction. What PHP as a framework needs to do is not reinvent the wheel in the language department, and use a pre-existing, scalable, enterprise-class OO scripting language, and utilize a templating technology that doesn't promote mixing logic and presentation - but what's the point, since it would look remarkably like Zope?
Slashdot Mirror
Plone obviously scales well, but is also very easy to use for quickly getting started with small-group content management. Consider this:
...of the development process. Projects with vibrant, enthusiastic communities will tend to exceed, both socially, and technically. This is one of Plone and Zope's greatest assets. So, if you think of it this way, it is more than a mere "popularity" contest - it is a measure of dedication, enthusiasm, caring, and a bit of zealotry (not in a bad way) - these are good leading indicators as the the strength of the product via its support mechanism and community.
Make fun of "buzzwords" if you will, but getting open-source into government and private-enterprise that works with government is important, and lack of accessibility is a deal-breaker for those kinds of projects. Standards are important to doing business with technology - that's the process you go through to generate something called money (perhaps you've heard of this, no?).
...that Plone's UI (esp. in 2.0 beta) is modular. It is Section 508 and W3C WAI compliant. It also can be rendered on mobile-phones, large-format, and presentation/print CSS devices without need for ANY changes to the HTML output or multiple sets of templates. From an architecture and extensibility standpoint, Plone's UI is really best-in-class. It also has the largest and most diverse audience and user-base of any open-source CMS, as well as formal standards for process improvement (the PLIP process), which definitely aides in the UI development/refinement process.
1. Open source on the desktop is an important issue, regardless of where you come down on it.
2. Zope's scalability is more transparent than any other app server or CMS product on the market today. With ZEO clustering coming with little/no need to write extra code to make your deployment scale-out, this is a win. Add to that mature caching frameworks and provend interoperability, the above post is definitely uninformed.
3. These projects represent an important open-source future, just as much as they represent the present. Eveyone already knows about the Kernel and Apache. This is an opportunity for these important projects to show their stuff and move open source software "up the stack" to higer levels (don't underestimate how important this is to the future of open-source!).
From a user who uses every piece of software on that list, I have to disagree.
Sure KDE was a winner - but number one in the vote tally was Plone. Why? Becuase Plone has a large, enthusiastic community. Plone is faily new in the grand scheme of things, compared to these other projects. Why Plone got the most votes is that it has a lot of the most "finishing work" of many projects - it will be a good ambassador for open-source products and frameworks.
Sure, the KDE, GIMP, GNOME, and OpenOffice folks have been around for a while, and obviously get in on both quality and recognition, but it's important to see that Zope and Plone also are getting a lot of deserved attention at the same level as these other four well-known open-source projects.
...in the US, we bomb foreign countries for less invsive violations of human rights, such as free speech. Imagine these folks suign the Debian project, for example. I'm more worried day-to-day about the more suttle, under-the-table terrorism enacted against our industry and trade by those willing to exert power through the legal and patent system. The problem here is that enforcing a patent can trace its authority to the end of the barrel of a law-enforcement officer's handgun, or the weapons of economic ruin in court pronouncements. As long as corporations can carry this kind of power protected by the rule-of-law to stifle free speech and free enterprise, how can it not be called fascism? It's not a stretch to call this violence, is it? What kind of sentences should we give to violent criminals (perhaps better use of the court system)?
They would really need to sweeten the pot to make this interesting. They need to be able to have a single appliance software stack that is capable of exporting filesystems over the network as well as block devices. If they added something on the SERVER end like HyperSCSI (or iSCSI, but HyperSCSI is faster/free), it would be more interesting, no?
My company is a large-market daily-US newspaper, and we are building CMS systems in Zope & Plone (using Python). There may be several advantages to using a scripting language, but a shift from Java to a non-OO scripting language like PHP is likely higher risk for you - Zope (and the Zope Content Management Framwork) may offer a better solution given it has a toolset of components to leverage out-of-the box, and a simple, component-oriented way of developing content management applications with a scripting language that is easier to use, but just as scalable as Java-based solutions.
Because it uses an object database for content repositories for digital asset management, you minimize the need to do object-relational serialization and marshalling between an OO system and a relational datastore. However, this isn't as complicated as it sounds; consider something like Archetypes, a schema-driven content type generation system that also has built-in relationship management for composition of media products from related assets.
Shameless plug: I'll be giving a talk on how we are doing much this at the Plone Conference. in October in New Orleans.
Scalability costs with this type of content-management solution will not be in licensing of yor apps, but in commodity hardware (scaling out). These costs would be greater than if you used something much more bare (i.e. PHP has no security model built-in, so pages might require less resources to render, but you get more limited flexibilty or need to implement such a layer anyway for your application, negating the performance difference), but performance and price would likely be on-par or more competitive than Java solutions.
If you are not in the market to build, but to buy the first 80% of your way into a solution, Zope Corporation has built a commercial CMS product on top of these open-source foundations (Zope/CMF, Squid+ESI) - it is called Zope4Media, initially developed for Viacom and Boston.com (one of the largest local media sites out there, which might speak for the performance characteristics of a well-designed Zope application).
I wonder sometimes what Apple doesn't gradually dump AppleScript for Python? Think about it: it would give them a scripting platform as powerful as powerful as Java, but (nearly) as simple as AppleScript (perhaps more readable, and certainly more maintainable). Python 2.3 is going to get bundled with Panther, and is used in some core "essential functionality" in Panther and already has bindings to pretty much everything one would needs to tightly stitch to Apple's platform (ojbc, quartz, Java apps via JPE, etc).
Bruce Eckel sums it up best:
"Programmer cycles are expensive, CPU cycles are cheap, and I believe that we should no longer pay for the latter with the former. " from a post by Bruce Eckel on artima.com.
Perhaps people should stop obsessively benchmarking platform VMs, and start benchmarking coding productivity and teamwork, perhaps in Python, with the performance bits in C. For a real-world example, Zope does exactly that: 95% of the code in Zope ends up being done in Python - only the real performance-intensive stuff need be in C... and the stuff done in Python is easy to read, modify, reuse, and tweak (thus, better productivity for both developers that use Zope as and app-server platform well as developers who work on Zope's core).
PHP is popular (as is M$ ASP) becuase it has a gentle slope for web designers to learn programming. I don't think this is a bad thing, but inlining code and presentation is really not the right way to be encouraging new folks to programming to code... PHP teaches programmers bad habits like excessive use of global namespaces, and generally is accomplished with poor editing style becuase it is inlined with HTML, which has different needs for editing/indentation/etc.
A more appropriate introduction for this audience to programming might be python and TAL (template attribute language - the core of Zope's Page Templates, and the only vendor-neutral industry standard, cross-language templating system beside XSLT). I'm not suggesting Zope is appropriate for everyone (though for big apps, it really is best), but perhaps mod_python + page templates would be a better alternative for lightweight web-based scripting than PHP.
PHP does not work well for team programming, and Python does. If you are developing applications in a vacuum, by yourself, this may not matter, but on a team where you need to have coders of many skill levels, business managers, and designers interact, you really need to divide logic from presentation, and use componentized code with explicit namespaces to enable that sort of interaction. Otherwise, it just more <?PHP include("./someunknownquantity.php"; ?> magic.
PHP suffers readability not in syntax, but in archetecure design. With global namespaces for module functions (say, for example, to FTP a file), you do not have the ability to trace the logic between source files and modules in someone else's code. In addition, PHP encourages the inlining of code in presentation, and most PHP code is not modular (some is) - but on top of that the most popular mechanism for code reuse is eval() and include(), which simply pop more crap into the global namespace without being explicit what they do.
All this impacts readability. Python does not have these problems becuase it encourages explicit namespaces for all objects/modules/packages/classes/etc. Python also enforces readabilty by simple (easy) use of whitespace (this is a good thing.
If you buy this logic, Renquist is just a two-bit terrorist with the wonderous decoration of a black robe. Makes the Critical Legal Studies folks seem more right every day.
My 2 cents is that SCOX stock price should be driven down to 2 cents.
If all Linux kernel copyright holders (or most) do what this German fellow did, but formed a class action (or several, in each country), SCOX stock price would drop like a stone. It would make SCO a more palatable acquisition target for IBM, but not at a price that makes this strategy threats of men with badges and guns enfocing the a worthy exit for stockholders. This would rid the world of SCO, but in a way that would not validate the sue-to-be-bought model, becuase being bought for pennies on the dollar is not maximizing shareholder value, and it would make a fool out of Mr. McBride, who's just a white-collar thug.
...and Python.
PHP4 is problematic archectecture for what you ask. PHP makes profoundly stupid architecutral blunders like lack of namespaces for library functions, which makes it hard for someone else reading your code to determine where function X came from? Inline includes.evals of code are bad, bad, bad too.
You really want a MVC-ish sort of seperation of concerns, I suppose? Zope will do this: XHTML or XML Zope Page Templates, which are valid XML (code via attributes and XML namespaces) using the TAL namespace. Also, ZPTs will allow you to put mockup in your templates and strip out at runtime. In Zope, page templates (view) use simple Python scripts or ZSQL methods for glue logic (controller), and support either content objects developed as low-level Python Products (model) and stored in the object database, or alternately, just have content stored in every RDB you could think of. Best of all, Zope uses Python, which is a much more clean language.
Remember, one thing M$ does well is pay lawyers.
User-mode Linux specifically has honeypot features designed into it. Haven't done this myself, but there is plenty of info.
/ user-mode-linux.sourceforge.net/slides/ists _rt/ists_rt.htm
http://user-mode-linux.sourceforge.net/
http:/
You are going to spend money on an LCD display for a server that sits at a co-lo facility with noone looking at it 99.3% of the time? This is so 1999. I'm not trying to insult you, but question your understanding of the alternatives, which are likely to be more simple.
/etc/inittab, put your consoles on /dev/ttyS0 - it only makes sense!
got Unix? Serial console!!! On Linux, edit lilo.conf, and edit
Windoze? A network-capable kvm is likely about the same price as an LCD display, and scales to multiple boxes. But even cheaper is VNC, which can be tunneled over pub key authenticated SSH for remote access.
Co-lo facilities are likely to be charging 15-25 USD per rack unit per month, and a 15" CRT takes up 8 units, so you end up paying at least 120 USD a month to not see a monitor most of the time. What a waste. If you go the VNC or serial console route, even without an expensive Mainboard with remote access to the bios setup, etc, you can still get away with no monitor - and when you do need one, your colo provider should have a monitor on a cart you can use gratis (if not, screw them and go elsewhere - it is a competitive enough business that they can't screw you).
The reason that the LCD in the drive bay thing has gone away is that it is too much of a niche item to survive in a commoditized economy where hardware has low margins (this is also known as reality). Welcome to 2003 - scale down your expectations.
You likley want to get your hands on a copy of Folio Views for Windows or Macintosh. First, keep in mind that there are differences between the 3.x and 4.x infobases. You need to find out which version of Folio products produced your infobase. If nothing else, Folio Views 4.x will read the older NFO files. You want to export the infobase from Folio Views to a Folio Flat File (FFF, very simple SGMLish, but not quite SGML text).
You will likely need to buy this from an OEM, since NextPage stopped producing this a long time ago. Here's the history: Folio was the default search engine for Netware many moons ago, and was popular, and then had DOS, then 16-bit windows versions of their "Views" product (2.x and 3.x line). Folio was purchased by Lexis-Nexis, and then sold to OpenMarket, who didn't want it, and eventually sold it back to its original founders, who changed the name of the company to NextPage. During the time it was at OpenMarket, a 4.x version of Views was released, which is win32 (and also MacOS app).
FYI, FFF is very easy to work with. I've written text filters to work with it, and it's as easy as any other decently-marked-up format, even if it is not SGML. I do not know of any way to get an NFO out to FFF without a copy of Views.
Tip: My former employer NewsView Solutions is one of the few OEMs still selling Folio-branded products, and still uses the Folio Views 4.x products alongside with their digital asset management software. They could sell you a copy of Views (I forget about pricing).
Though not mentioned, genetic conditions related to clotting factors might also be a factor (pun intended) in the development of DVT. For example, those most prone to problems on long flights are people with conditions like Factor V Leiden (3-5% of US population has this condition, most don't know about it) are likely to contribute to this. My hunch is that the guy with problems mentioned in the article likely had a clotting factor condition, which predisposed him to trouble, and he (unintentionally) found it working long periods of time at his desk.
Composition is association; Layout is just containment of views.
Progress is underway for a zope.org community site replacement that will be based on more recent versions of Zope and the Content Management Framework. This should defitely improve things (searchability, news, product listings).
.NET and J2EE people who want to code in a better language ;) with a decent framework. In the meantime, Zope2 is still an excellent product for complex applications, and in particular for content-heavy applications that can leverage both built-in transaction support, object-persistence, and good relational database support.
The Zope community, though, is very rich, and the mailing lists generate a lot of traffic; also, #zope and #plone on openprojects (or whatever its called now) are useful resources.
Zope 3X really provides a framework much more focussed on developers creating and leveraging services and applications, and less on the out-of-the-box feel. The main ideas behind Zope3X are to lower the barrier to writing Python product code, and leverage existing Python modules and applications more readily; also, focusing on component-oriented design (favor composition to inheritance and a bunch of mixin classes; where Java forces you through lack of multiple inheritance to do this, Python is more flexible, and with this comes a downside of overuse of inheritance in Python, of which Zope2 is a good example; Zope3 solves this to lower the learning curve and decrease complexity).
Overall, I think Zope 3 will become a convincing alternative to
I'm curious... For virtual servers along the line of something like VMWare's GSX product, how well does bochs perform compared to these 3 alternatives?
...or why python is better on the backend and the front-end.
.NET as well-thought-out enterprise component frameworks.
Take namespaces for special-purpose library stuff. Or inline eval (include) of logic code (bad, bad, bad). Good analysis (mine) here, including comparitive code to demonstrate my point.
Like Java, Python already does assignment by reference, copy is optional. PHP is just figuring this out. PHP's language leaves much to be desired in team programming and code readability. Using 'Design Patterns' is only half the equation. You can do component oriented programming, but some languages are going to be better than others at facilitaing it in a manner that works in reality. PHP5, unfortunately, won't hold a candle to Zope 3, which is really going to compete at the level of J2EE and
PHP lacks object persistence, multiple inheritance, full-featured transaction machinery, a built-in security model, an interactive command-line interpreter, and it is too tied to web-scripting only. And becuase it doesn't have a security model that binds operations to roles/permissions, it can't easily put gateway methods with bound roles (like Zope's proxy roles) between web code and SQL code, leading to increased chance of SQL injection vulnerabilities.
On the other hand, Zope has object perisistence, transactional RDBMS integration and connection abstraction, templated, componentized SQL methods, a security framework, and Python, which is a much better language (explicit is better than implicit). And if you need to do any sort of content-management, Zope has a mature component-oriented framwork in the CMF, with a killer-app implementation in Plone. It also has XML-RPC, WebDAV, Caching managers, and all sorts of other goodies you won't find out of the box in PHP.
PHP is fast, and it is easy, but it is by no means scalable. PHP offers a gentle slope learning-curve, and quick easy hacks, but is somewhat like a crack addiction. What PHP as a framework needs to do is not reinvent the wheel in the language department, and use a pre-existing, scalable, enterprise-class OO scripting language, and utilize a templating technology that doesn't promote mixing logic and presentation - but what's the point, since it would look remarkably like Zope?