Under any decent web server (Well, Apache at the very least), it takes less than two short lines to disallow linking from outside sources, and you can also be selective about who you let link where.
There should be a law against lawsuits that can be solved with technically in a few minutes. Isn't there a "good faith" requirement of some sort that would void lawsuits about any trivially solvable problem such as this one?
A challenge-response or public-key scheme would make a lot of sense; but if they're not using either, well... it's going to go down very quickly when someone builds a speedpass repeater.
but it seems that the nice guys at 34sp.com have amazingly competent service at the reasonable price of ~$17 per YEAR (Yes, that's YEAR, not MONTH). I haven't yet tried to host there, but reading the community boards and collecting info from people who host there, it looks like I'm NOT going to do any home based DSL hosting.
Re:You really should provide more info ....
on
Zope or Cocoon 2?
·
· Score: 1
Actually, I don't assume Cocoon sucks - that's your interpretation. I have used Tomcat 3.2 (I think that was the version), servlets and JSPs, and - at least from my experience, they suck. Or, to be a bit more fair, they fail to deliver on any of the marketing hype Sun is surrounding them with, and - for projects I've been involved with, suck significantly more than Zope or AOLServer.
But Cocoon runs in a Servlet, and I assume (this is the right point to attack me, if you insist) that whatever you do must play well with Servlets, Contexts and other stuff I have experience with in Servlets that I highly dislike.
Once again, I said Servlets and JSPs suck, not that Cocoon sucks - it's even there in the comment you quoted, for christ's sake!
But since we're at it - if you don't use Cocoon hand-in-hand with other J2EE components like EJB (which I don't have experience with, but most everyone I know now thinks it sucks - when most of them were enthusiastic when they started dealing with it), you don't even have a hype basis on which you can claim Cocoon is able to scale. (Which is kind of moot, because Cocoon basically attempts to be a presentation layer - super ultra smart, but nevertheless, a presentation layer - which, unless you do something super ultra stupid, should not be a part of the scalability equation)
You really should provide more info ....
on
Zope or Cocoon 2?
·
· Score: 4, Informative
About the needs for scalability, reliability, hardware costs, software costs, etc.
So long as you are not trying to support tens of thousands of users, it usually matters little what framework you choose (unless one of the options has building blocks that match your application better).
Zope is easier to get started with, but be warned that it has a much longer learning curve than is initially assumed required to reach high level zoping. It's also mature, robust and very well supported. I don't have any experience with Cocoon, but for any project I've been involved with I'd take Zope to JSP/Servlets any day.
That said, Zope doesn't claim to scale as well as Java based solutions claim. I've yet to see any of these claims substantiated, but some people claim Java scales (I'm still awaiting conclusive proof, btw, that it's the J2EE framework that makes scalability easy).
Also, consider AOLserver (through PyWX or Tcl) - it's extremely fast and robust, and it does wonders for simple database applications (and even some complex ones). You might want to download a copy of ArsDigita as reference material, before ArsDigita's site disappears.
And finally, Michael Sweet's HTMLDOC provides super-ultra-professional postscript/pdf output from plain HTML. Take a look at some outputs (the FlTk manual, the HTMLDoc manual, or just take a site and convert it using the available online converter), impress yourself and never settle for less.
When I take something to "evaluate" at a hardware store, I pay (eventually taxed) money, and if I am not satisfied, I get my (therefore de-taxed) money back.
Such an act, if actually enforced (something I think is nearly impossible) will essentially kill off the current practice of downloading evaluation versions and paying later.
Well, I can't tell myself whether you are right or wrong, but it seems that there have been medical Linus Torvaldses in the past.
There's Roy Raymond Rife, there's Ozone Therapy and many others. If you believe these stories, then there have been Linuses all along in medicine, but the AMA was capable enough to make them irrelevant.
I didn't believe any of these conspiracy theories on first reading, but the very idea of the SSSCA and UCITA, and how far both have gone indicates that these stories aren't that far-fetched.
Google's claim to fame is its ability to rank results properly (something no other search engine ever got right). The rank, if I recall correctly, is _mostly_ based on links from other sites.
Now, when you're indexing thousands of doc and pdf files on a company network, how many of those link to each other?
And how many companies have internal newsgroups that can be searched? (No, Exchange shared folders don't count - or can Google index those as well?)
Actually, threads are truely evil and are rarely required for anything. In fact, in MS-Windows, most of the times what you describe happens because one thread is waiting on a semaphore held by another thread or process (Outlook is a fine example of this).
But in general, you're very much right on the money (except perhaps by implicitly assuming that XML is clean since it's cleaned-up SGML; XML is cleaner, but still underspecified and mostly abused).
Unfortunately for IBM and Apple, even though the platforms were immensely successful, it wasn't them who made the real big money - it was distributed among a lot of other players. Sony cares about making money rather than standardizing an open platform.
Some of it is not really their fault. When you study the associated physical phenomena (specifically, Riley's distribution), you see that blind spots cannot be avoided in a narrowband network.
Ultrawideband (and to a certain extent, wideband) communication solves this problem by having a transmission band so wide that even if part of the band has blind spots, some of the signal will still make it through. Commercially, we're not there yet.
Shannon knew this in 1948 and documented it; it took the rest of the world nearly 50 years to follow.
I just hope they don't consider it more credible than paper signatures, because it isn't.
Sure, the math is safe, but the use isn't. When I digitally sign a document, I don't actually do it myself - I ask a device to do that - a device of which, regardless of common beliefs, I have very little control (About as much control as one might have on their employee - you can ask them to do something, and it will usually look as if they did it, but that doesn't imply anything).
I'm using SDF on a regular basis at work, and have been doing so for 3 years or so. Together with the wonderful htmldoc (from easy software products, it can turn any textfile into a beautiful, production quality document in no time.
Whenever I have to send out.doc files, I ask SDF to convert to.html, load it from word and save it as.doc (the default.rtf output sucks).
SDF is great - the input is still 100% readable as a plain textfile, and LaTeX, HTML, PDF and FrameMaker conversions are simply awesome. Unfortunately, it's no longer maintained, and even the download files aern't there anymore. Still, I've been using it for 3 years, and haven't encountered a single bug. The documentation is superb and -- if all else fails -- read the source, luke!
I am considering a switch to Doxygen - the input still remains human readable (although less so than SDF), and it has better support for LaTeX formulas and output formats.
Operating systems have so much material available because there's science involved - there are a few things that can be proved (e.g., shortest job first, lock-free / wait-free synchronziation primitives, Belady's FIFO anomaly) which should be known to everyone starting to practice. There is also a considerable accumulated body of knowledge which, though not based on solid math, has reached a "common knowledge" status.
The same cannot be said about windowing systems. The algorithms are well documented, but there isn't much connection between them and actually building a windowing system. Building a windowing system is an art more than science or engineering - a system that's a masterpiece to one is considered bad practice by another.
That said, if you want to learn from a system IMO exceptionally well balanced between doing things cleanly and making them work, take a look at FLTK (pronounced FullTick) - it revolves around the ridiculous and totally unaccepted idea that the GUI is only an aspect of your program, and that the logic of the program should not be influenced by how the GUI is implemented. How silly. (Yep, I know, SDNWOTN).
From trolltech; The version that comes with qt-2 is Perl and thus as cross platform as you can probably hope for. tmakes are significantly easier to maintain directly than makefiles, configure scripts or any other beast I've looked at.
Slashdot Mirror
Under any decent web server (Well, Apache at the very least), it takes less than two short lines to disallow linking from outside sources, and you can also be selective about who you let link where.
There should be a law against lawsuits that can be solved with technically in a few minutes. Isn't there a "good faith" requirement of some sort that would void lawsuits about any trivially solvable problem such as this one?
A challenge-response or public-key scheme would make a lot of sense; but if they're not using either, well ... it's going to go down very quickly when someone builds a speedpass repeater.
but it seems that the nice guys at 34sp.com have amazingly competent service at the reasonable price of ~$17 per YEAR (Yes, that's YEAR, not MONTH). I haven't yet tried to host there, but reading the community boards and collecting info from people who host there, it looks like I'm NOT going to do any home based DSL hosting.
Actually, I don't assume Cocoon sucks - that's your interpretation. I have used Tomcat 3.2 (I think that was the version), servlets and JSPs, and - at least from my experience, they suck. Or, to be a bit more fair, they fail to deliver on any of the marketing hype Sun is surrounding them with, and - for projects I've been involved with, suck significantly more than Zope or AOLServer.
But Cocoon runs in a Servlet, and I assume (this is the right point to attack me, if you insist) that whatever you do must play well with Servlets, Contexts and other stuff I have experience with in Servlets that I highly dislike.
Once again, I said Servlets and JSPs suck, not that Cocoon sucks - it's even there in the comment you quoted, for christ's sake!
But since we're at it - if you don't use Cocoon hand-in-hand with other J2EE components like EJB (which I don't have experience with, but most everyone I know now thinks it sucks - when most of them were enthusiastic when they started dealing with it), you don't even have a hype basis on which you can claim Cocoon is able to scale. (Which is kind of moot, because Cocoon basically attempts to be a presentation layer - super ultra smart, but nevertheless, a presentation layer - which, unless you do something super ultra stupid, should not be a part of the scalability equation)
About the needs for scalability, reliability, hardware costs, software costs, etc.
So long as you are not trying to support tens of thousands of users, it usually matters little what framework you choose (unless one of the options has building blocks that match your application better).
Zope is easier to get started with, but be warned that it has a much longer learning curve than is initially assumed required to reach high level zoping. It's also mature, robust and very well supported. I don't have any experience with Cocoon, but for any project I've been involved with I'd take Zope to JSP/Servlets any day.
That said, Zope doesn't claim to scale as well as Java based solutions claim. I've yet to see any of these claims substantiated, but some people claim Java scales (I'm still awaiting conclusive proof, btw, that it's the J2EE framework that makes scalability easy).
Also, consider AOLserver (through PyWX or Tcl) - it's extremely fast and robust, and it does wonders for simple database applications (and even some complex ones). You might want to download a copy of ArsDigita as reference material, before ArsDigita's site disappears.
And finally, Michael Sweet's HTMLDOC provides super-ultra-professional postscript/pdf output from plain HTML. Take a look at some outputs (the FlTk manual, the HTMLDoc manual, or just take a site and convert it using the available online converter), impress yourself and never settle for less.
When I take something to "evaluate" at a hardware store, I pay (eventually taxed) money, and if I am not satisfied, I get my (therefore de-taxed) money back.
Such an act, if actually enforced (something I think is nearly impossible) will essentially kill off the current practice of downloading evaluation versions and paying later.
And perhaps that was the original intent.
Well, I can't tell myself whether you are right or wrong, but it seems that there have been medical Linus Torvaldses in the past.
There's Roy Raymond Rife, there's Ozone Therapy and many others. If you believe these stories, then there have been Linuses all along in medicine, but the AMA was capable enough to make them irrelevant.
I didn't believe any of these conspiracy theories on first reading, but the very idea of the SSSCA and UCITA, and how far both have gone indicates that these stories aren't that far-fetched.
Google's claim to fame is its ability to rank results properly (something no other search engine ever got right). The rank, if I recall correctly, is _mostly_ based on links from other sites.
Now, when you're indexing thousands of doc and pdf files on a company network, how many of those link to each other?
And how many companies have internal newsgroups that can be searched? (No, Exchange shared folders don't count - or can Google index those as well?)
Actually, threads are truely evil and are rarely required for anything. In fact, in MS-Windows, most of the times what you describe happens because one thread is waiting on a semaphore held by another thread or process (Outlook is a fine example of this).
But in general, you're very much right on the money (except perhaps by implicitly assuming that XML is clean since it's cleaned-up SGML; XML is cleaner, but still underspecified and mostly abused).
Unfortunately for IBM and Apple, even though the platforms were immensely successful, it wasn't them who made the real big money - it was distributed among a lot of other players. Sony cares about making money rather than standardizing an open platform.
Some of it is not really their fault. When you study the associated physical phenomena (specifically, Riley's distribution), you see that blind spots cannot be avoided in a narrowband network.
Ultrawideband (and to a certain extent, wideband) communication solves this problem by having a transmission band so wide that even if part of the band has blind spots, some of the signal will still make it through. Commercially, we're not there yet.
Shannon knew this in 1948 and documented it; it took the rest of the world nearly 50 years to follow.
I just hope they don't consider it more credible than paper signatures, because it isn't.
Sure, the math is safe, but the use isn't. When I digitally sign a document, I don't actually do it myself - I ask a device to do that - a device of which, regardless of common beliefs, I have very little control (About as much control as one might have on their employee - you can ask them to do something, and it will usually look as if they did it, but that doesn't imply anything).
I'm using SDF on a regular basis at work, and have been doing so for 3 years or so. Together with the wonderful htmldoc (from easy software products, it can turn any textfile into a beautiful, production quality document in no time.
.doc files, I ask SDF to convert to .html, load it from word and save it as .doc (the default .rtf output sucks).
Whenever I have to send out
SDF is great - the input is still 100% readable as a plain textfile, and LaTeX, HTML, PDF and FrameMaker conversions are simply awesome. Unfortunately, it's no longer maintained, and even the download files aern't there anymore. Still, I've been using it for 3 years, and haven't encountered a single bug. The documentation is superb and -- if all else fails -- read the source, luke!
I am considering a switch to Doxygen - the input still remains human readable (although less so than SDF), and it has better support for LaTeX formulas and output formats.
Operating systems have so much material available because there's science involved - there are a few things that can be proved (e.g., shortest job first, lock-free / wait-free synchronziation primitives, Belady's FIFO anomaly) which should be known to everyone starting to practice. There is also a considerable accumulated body of knowledge which, though not based on solid math, has reached a "common knowledge" status.
The same cannot be said about windowing systems. The algorithms are well documented, but there isn't much connection between them and actually building a windowing system. Building a windowing system is an art more than science or engineering - a system that's a masterpiece to one is considered bad practice by another.
That said, if you want to learn from a system IMO exceptionally well balanced between doing things cleanly and making them work, take a look at FLTK (pronounced FullTick) - it revolves around the ridiculous and totally unaccepted idea that the GUI is only an aspect of your program, and that the logic of the program should not be influenced by how the GUI is implemented. How silly. (Yep, I know, SDNWOTN).
From trolltech; The version that comes with qt-2 is Perl and thus as cross platform as you can probably hope for. tmakes are significantly easier to maintain directly than makefiles, configure scripts or any other beast I've looked at.