The New York Times and Washington Post aren't necessarily on the same network, but as children of the same parent company, nytimes.com and boston.com (and other properties owned by the NYT corp) might be.
What if they are effectively partner sites under the same parent, but their systems don't interact in any way -- would that be a case of infringement?
What if they do share systems or have systems that communicate directoy, but they're the same company? Are they not allowed to do that?
What about a company that has multiple user facing URL namespaces (let's say "www.springfield-times.com" and "www.shelbyville-times.com") served from the same systems and maybe even the same servers, what then?
Then as another person noted you have companies like Gannet offering many sites for many newspapers using the same look & feel for all of them, and these might or might not be running from the same servers or sharing among the same network or networks. What about them?
What is a "network" in this case anyway?
If this patent holds, it could be a thorn in the site of a lot of web sites out there.
I only know him from the print ads and they're plenty annoying but, as far as I've noticed, they don't run a name with the ads.
And I hardly think that a magazine like Billboard is a reasonable comparison -- you read a rag like that for the trashy ads. The Dell ads are running in mainstream sources (major daily newspapers, for example) and so stand out all the more. *shudder*
That is a *wonderful* idea. If Apple is sitting on such a big slush fund as I've heard, surely they could afford to chip in a bit for the free software they're getting to take advantage of...
Substantially the same advice as the one you object to was given out in a posting sent by Adam Foxson to the
perl5-porters@perl.org, macosx@perl.org, and fink-devel@lists.sourceforge.net lists this morning. In this post, Foxson summarizes as follows (snipping drastically -- read the original for details):
The release notes for perl 5.8.0 indicate:
"Perl 5.8 is not binary compatible with any earlier Perl release, XS MODULES WILL HAVE TO BE RECOMPILED!"
Mac OS X users that have fink installed may experience the following error when executing certain perl operations (see 'EXAMPLE').
[snip]
The error is caused by the following sequence of events:
1 - a.bashrc (or other shell rc file) sources/sw/bin/init.[c]sh
2 - init.[c]sh sets PERL5LIB to/sw/lib/perl5
3 -/sw/lib/perl5 contains Storable (the only compiled perl module, included by default, to my knowledge), and possibly other XS modules. Since Storable is a compiled XS module that was compiled with a prior version of perl that is binary incompatible with perl 5.8.0 it will be necessary to recompile Storable (see 'RESOLUTION').
Fink stable currently includes the following six XS modules. If any of these were installed prior to installing 5.8.0 you will likely experience the dyld issue.
- DBD::Mysql
- DBI
- Digest::MD5
- MacOSX::File
- Storable
- Term::ReadKey
You will also experience the dyld issue if any other XS modules are contained within the/sw/lib/perl5 directory. That is, XS modules from fink unstable or another source.
From there, the remedy suggested roughly matches that which Ellem posted earlier, and which you are objecting to now. In his.sig footer, Folson identifies himself as "CPAN Tester for Mac OS X", and the advice he gives sounds credible.
If the advice summarized in these postings is unsound, do you have any counter suggestions that address the issues raised by Foxson's post? Or are those issues themselves phantoms? I didn't realize that Apple had a dedicated Fink developer, but seeing as that seems to be a part of your job description, a clarification of this matter would be very much appreciated -- and you might want to include the mailing lists mentioned above so that the users/developers will know what's going on "from the horse's mouth", so to speak.
% lwp-request -m HEAD http://slashdot.org/ | grep '^X-' X-Fry: I'm never gonna get used to the thirty-first century. Caffeinated bacon? X-Powered-By: Slash 2.003000
% lwp-request -m HEAD http://slashdot.org/ | grep '^X-' X-Bender: Bite my shiny, metal ass! X-Powered-By: Slash 2.003000
% lwp-request -m HEAD http://slashdot.org/ | grep '^X-' X-Bender: Like most of life's problems, this one can be solved with bending. X-Powered-By: Slash 2.003000
% lwp-request -m HEAD http://slashdot.org/ | grep '^X-' X-Bender: There's nothing wrong with murder, just as long as you let Bender whet his beak. X-Powered-By: Slash 2.003000
% lwp-request -m HEAD http://slashdot.org/ | grep '^X-' X-Fry: No, no, I was just picking my nose. X-Powered-By: Slash 2.003000
Is this a Slashdot specific hack, or does the publically available version of it do the same thing?
Not that I disagree with your point that this should have been posted -- you're right, it's newsworthy and merits discussion -- but isn't Helium-3 only useful if you've got a working fusion reactor? Self-sustaining, power generating fusion seems like it's at best decades away from reality.
I'm with Roberty Zubrin on this one: with the technology that Apollo produced, we should be going not to the moon, but to Mars. It would be completely doable, and there's far more interesting & useful things there than fuel for a mythical reactor that no one can even build yet. Just to pick two seemingly trivial examples: air & water. A martian base could cultivate what life support supplies are needed locally; a lunar base would have to import them -- expensively -- from earth. Any profit gained from He3 exploration would surely not be enough to counter those expenses, but a martian expedition could, for the most part live off the land and, once established, go on to more interesting things.
A few weeks ago, some contractors accidentally drilled through the line bringing electricity to our building, thus ending the workday for nearly everyone. At that point the only thing left to do was bring down all the servers & any desktop machines that weren't on a UPS, then crowd around in front of the office display computer -- the one with a UPS, a DVD drive, and a wall-mounted 48" display. We all sat around watching "Office Space" for as long as possible -- managers of other departments sent their employees home, then came over to watch. It was grand...:-)
You're right -- 30 man-months of effort, 18 months of calendar time -- has yet to produce a completed version of Perl6. But you know what? I wasn't along for this part of the ride, but according to Damian, it took maybe two or three years for iterations 2 & 3 of Perl, and four or five years to produce versions 4 & 5. That was all with volunteer effort.
Perl6 is arguably more complex than versions 1-5 combined, and yet it is coming along at a faster clip than any of the earlier iterations did -- largely because, yes, people have donated money so that these three very talented language designers can attack the problem more or less full time. It's foolish to expect this generation of Perl, as complex as it is, to come out in 1/4 the time that the most recent versions took. On the contrary, if it takes "only" 5 years, we can be glad that it arrived as soon as it did thanks to the full-time work these guys have been able to put in.
Also, it's worth noting that Perl has always been one of the first "mainstream" languages to bring features from special purpose academic languages to a wider audience, and Perl6 is a strong continuation of this history. Most people are probably unaware of constructs like regular expressions [version??], closures [Perl5], co-routines, currying functions, and continuations [all Perl6], so why would you expect masses of people to be "begging" for them? And yet once these features get implemented in Perl, they've had a tendency to start being demanded in other languages too -- witness Java recently adopting Perl-esque regexes, even as the Perl6 regex design is evolving away from simple pattern matching engine and into a more sophisticated grammar recognizing parser like Parse::RecDescent, lex, or yacc/bison.
So really, this kind of comment is nothing but trollbait, and I'm falling for it. Perl6, even half-fleshed out, is a tremendous leap forward compared to Perl5, and I for one feel lucky to have these guys focusing on it. In spite of your naked assertion at the end there, the RFC process that kicked off Perl6 development -- with well over 300 well thought out documents that took months for Larry to properly analyze -- well proves that people *were* begging for change, and slowly but surely it is happening. I hope that some magician can produce the funds to keep the Perl6 roadshow on the road, because within a couple of years I want to be able to use this wonderful new version of Perl. If the show ends now, it'll be years longer before Perl6 ever sees the light of day...
I heartily agree -- book ratings, particularly for anything with an animal on the cover, are *way* overrated on Slashdot. This book in particular could have been an interesting case study in whether the situation is getting any better, because the book in question is an update to the previously titled MySQL & mSQL -- and it was absolutely awful. Don't let the review of that book fool you -- it was without question the weakest O'Reilly book I have come across to date. And yet, if all you knew about it was the Slashdot review, you'd have thought it was yet another winner from the fine team at ORA. Wrong.
At the time I read it, I didn't know much about MySQL, but I had finished my battery of database design classes and I knew a little Perl & Python, and it was obvious that the book was riddled with errors, from poor explanations of normalization in early chapters to Perl scripts that, had the reader been so industrious as to type them in verbatim, wouldn't even compile, nevermind produce the intended result if the syntax bugs were ironed out.
To be fair to the generally excellent staff at O'Reilly, I'm sure there were later editions that ironed out many of those flaws, but the fact that not one but two Slashdot reviewers gave the book high marks says a lot more about the quality of the reviewers Slashdot is able to produce than it does about the rare splot on O'Reilly's otherwise fine record.
A year or so ago, the authors of the current rewrite of the book were soliciting peer feedback on the Perl section in particular, because of the bad reputation the original version got . I'm sure they worked very hard to make a better book this time around, but did they succeed? Who knows? This reviewer makes no mention of the original edition, and apparently doesn't realize how awful it was.
I'm interested in the update, but unfortunately will not trust this review in its assessment. I wasted thirty bucks on the last version, regretted it, later found the New Riders book, titled simply MySQL, and was for the most part happy. The Perl sections there are a little odd -- this author's code doesn't feel very idiomatically "native" to me, more like things a long time C hacker would prefer -- but as a reference & manual it is far better than the first edition of the O'Reilly book. I hope that with this edition they're catching up, but as far as I'm concerned the definitive reference manual for MySQL is already out, and like it or not there are no animals on the cover. Even if you wouldn't realize that from the reviews you see on Slashdot....
Yes. At my last job, we used the self-run version of WebTrends. There were good things about it, and there were things that weren't so good.
Personally, as the monkey that had to run it every week, I didn't like it very much -- the version we had could only do log analysis on NT, but all our servers were Linux, so once a week I had to download the weekly reports to my computer (which meant that I wasn't able to run Linux even though all the work I did other than WT had to run on Linux; the download wasn't *that* bad, we were a small site and all the logs would "only" amount to a couple hundred megs -- usually it would finish by the time lunch was over on Mondays...:/), the actual analysis would take quite a long time to complete, and at the end of it I'd have to upload the summary reports back to the web site so that everyone that needed access would be able to see it.
Now to be fair, counter to what I just wrote, the catch is that the copy of Web Trends we had was old when I started the job, and it's even older now -- I'm thinking it's at least three or four years old now. Presumably there are better versions of it now that can run on the same platform as the server OS. Better still, I could have saved a lot of bother by just leaving an NT box at the co-lo facility and automatically access Apache log files by the FTP or SAMBA as needed. But I didn't think of that then, and the product documentation certainly didn't make such a useful suggestion.
I think the earlier poster hit the nail on the head with his comment about quantitative (log based data) vs. qualitative (questionnaire / survey / observation type data). You can whine all you want about how web gathered data is imperfect as a data collection for marketing analysis, but hey, just look at what *every other* form of advertising has to offer: surveys only. Hey, the web can do surveys too, and the web can also gather all this technical information that aren't available to TV, radio, or print ads. The issue isn't that this web data is imperfect -- so what? -- the issue is that you at least have something to work with. As long as you keep the imperfections in the back of your mind when analyzing that data, you can still draw conclusions that are at least as solid as those gatherable by any other form of media.
Also, playing into another point raised by that same poster, I have heard of companies hitting the same problems with internal web data numbers being consistently lower than those obtained by third parties. There are a lot of reasons that this will happen, and not all of them are ones you want to try to defeat -- caching for example allows many people to see your content without running up your bandwidth costs, but the tradeoff is that you never know for sure how many people got to see that content. The best you can hope for is consistency -- to always have numbers that are 1.2x that of the third party counts, or 1.6x, or 3x or if you're lucky 0.75x. Whatever. The point being, getting the numbers to agree is difficult because everyone has a different counting strategy; as long as you can account for the differences & accurately preduct how the third party numbers will agree (or disagree) with yours, that's enough to work with.
Fittingly, when I followed the NYTimes link it showed me an unrequested popup window. This is very interesting to me, as I've got Mozilla set to not allow pages to do that, and this was in fact an article about, well, not wanting to do that. Figures then that this would be the page to poke through my trust in Mozilla's ad armouring features...:-)
I'll second this -- Zope is great stuff. I read a copy of The Zope Book from my friendly neighborhood library (remember those? they're grand...:-) and it's a decent primer on the system for two of the three audience types that'll be using the CMS: those doing presentation (web design, templates, etc), those doing content (source material that gets poured into the templates), and those doing logic (programming and sysadmin stuff). Unfortunately, the original commenter sounds like a programmer, and his is the audience that comes up a bit short in this book. Still, it does a good job of explaining why these jobs should be broken apart and how Zope helps you to bring them back together, and it fleshes out how this is done from several different standpoints.
Still, any shortcomings of the Zope Book detract nothing from the goodness of Zope itself. By default it gives you a nice, featureful web-based management system. "Web-based" can often be a hindrance (complex UI's over the web don't always work very well) but in this case you can get pretty far without having to screw around under the hood, so to speak. One thing to get to terms with is that Zope, written as it is in OO Python, gets to take advantage of a lot of useful, but sometimes confusing, object inheritance trickery. Like for example you can create a user account at a certain level of your site, and inheritance will allow that user's priviliges to cascade down into lower levels of the site but not higher ones. Kind of an obvious feature to want, but the details of how such things get fleshed out are subtle and worth trying to get your head around.
Like the commenter above notes, "it wouldn't hurt to learn a little Python". In many case you can just use Perl, but you may find in the long run that Python feels like a better fit for Zope anyway (seeing as the source code is largely Python in the first place). In any event, the semantic similarities between Python and Perl are much stronger than the semantic *and* syntactic differences you're going to see between Perl and the scripting language offered by most other CMS offerings. And you're actually considering Microsoft CMS? Please....:-)
There are of course other good comments in this discussion, but this is the only one I see endorsing Zope, and I want to second that notion. If the first wave of dynamic web content was CGI, and the second was mod_perl, then the next one along that track seems to be Zope, which really allows you to work at a *much* higher layer of abstraction (which is of course a good thing, and for the same reason that almost nobody writes web stuff in C or assembler). Zope offers a rich high level toolkit -- object persistance (that you might even prefer to standard DBMS storage, though it's there if you want it), templates (some tending towards "HTML with code", others towards "code with HTML"), a mechanism for distributing your content across multiple servers,security controls, etc. It would take *a lot* of work to reproduce all this functionality in-house, and even if you did it would be hard to guarantee that it was as robust as Zope (or, to be fair, many of the other CMS offerings).
Boy, this story gets better every time Slashdotruns it. (I'd swear it ran a third time as well, even longer ago than the last one, but apparently that instance was removed from the database for redundancy.)
TOmorrow I'm gonna submit a story about how Linux kernal 2.0 was finally released...:-)
It can mean different things. In the sense I'm used to it being applied, you split up services in different ways across multiple machines. Making up some terminology that I don't think anyone would object too very strongly, you can split them vertically (an Apache box, a MySQL box, etc) or horizontally (multiple Apache frontends sharing the same content somehow). A very tight definition might mean getting the computers to act as if they are one unit -- I think this may be what your sales guys are talking about -- but it's simpler to just have them working together loosely without having the extra step of pretending to be one homogeneous entity.
Like I say, there are different ways of doing this, and really you ought to browse through a good bookstore or two to get more details. One strategy that's easy to implement might be to split up your content so that plain html is on www.site.com while your images are on img.site.com, your cgi scripts are on cgi.site.com, and your data is housed on db.site.com (which probably shouldn't be web accessible, by the way -- this protects you!). This is a vertical split. Or you can go horizontal by placing everything behind a load balancer that redirects incoming requests to one of several web servers -- each of which can be getting content from a single shared NFS partition. Or you can do a mix of those: maybe all the front end web servers communicate with dedicated database etc boxes behind them (which, again, would not be otherwise internet accessible).
On a Linux or Unix system, NFS is a pretty easy way to mirror content across all your servers. For a Win2k served site, you could probably get away with CIFS Windows shared drives. Or if you want to be really cutting edge, WebDAV might be able to meet similar needs. Less clever -- but debatably easier -- ways to do it might involve rsync'ing content from a master content server to a set of web-facing server "clients". A variation on that idea ends up being more or less identical to content proxy caching, as one big expensive app server in the back gets it's data cached onto a pool of cheap web facing proxies.
But, like I said at the beginning, the devil is in the details and you really ought to pick up a couple of good books if you want to learn more about this. Strategies for e.g. database "clustering" can vary widely depending on the RDBMS being used: I doubt the method would be the same for MySQL as it would for PostgreSQL, Oracle or SQLServer, for example. Some of those might be able to do this work almost transparently, while others would involve more manual planning & setup.
I *think* that if you can prove you buy them for commercial purpose, you can get a refund.
Wait, so if you're buying CD-Rs for personal use you have to pay a tax, but if you're going to -- say -- copy & sell music or software then you can get a tax refund. *That* sounds like an effective restraint on piracy letmetellya:-):-):-)
I was going to reply to the article, but you hit most of the points I was going to...and a lot of them I wasn't thinking of. So to cut down on the redundancy, I'll just reply here & add a couple more points:
To control the timeout problem for slow connections/clients, Apache can be tuned to use very short keepalive times. HTTP/1.1's keepalive header can be useful for clustering a burst of multiple requests (such as an HTML file plus a collection of images for it) but the dormant processes it can generate can be more costly than the TCP connection overhead time you were trying to avoid by enabling HTTP/1.1. Oops. Set the timeout low enough to hit the sweet spot between "too many new TCP connections" and "too many idle Apache children".
Reconsider your resistance to clustering. Yes it can make things more complicated, but it can also make your life a lot easier. Want to ease the Apache or MySQL load? Buy a couple more boxes & have them NFS mount the content or data directories. You can also do clever things like putting all your static content on a server optimized for that purpose (no mod_cgi or mod_include or anything like that) or dedicating hardware to a mod_perl instance, a mod_php instance, etc. Whatever. You gain a lot more flexibility, you compartmentalize things so that (hopefully) you don't have a single point of failure, and it's easier to swap/upgrade/replace components in one area without disrupting things in others.
As another commenter noted, caching can be a big help. Caching proxies can reduce the load on the main server significantly. Not everything can be cached, but it's possible to strike a balance between readily cachable data (home page, section headers, images, stylesheets) and material that really does have to get generated for each request. On a big site, every little bit helps.
mod_gzip is your friend. Processing power is always going to be cheaper than bandwidth, so spend your money on compressing data is cheaper than paying for increased bandwidth. Even if not all clients can take advantage of it, if a significant fraction of them can then you'll quickly come out ahead.
If you have any huge content (audio or video) that places a heavy load on the rest of your systems, you might consider outsourcing it to a company like Akamai that specializes in delivering such content quickly. Services like this are probably expensive, but if you need it then you need it, and going with an Akamai is surely cheaper than setting up & maintaining your own data centers all over the country & world.
As the above poster notes, consider Apache 2.0. Among the many neat-o features it offers is a choice in execution model: in addition to the fork/exec multiprocess model that 1.3.x used, you can also try threaded modes (which should be a big boost to Win32 servers if you need to go in that direction for anything), and I think maybe some more exotic execution methods. Depending on you setup, you might be able to find a big speedup by switching to threads. (Note though that, as of now, Apache2 and PHP4 don't play nicely together, and the same is probably true for a lot of Apache extensions (mod_perl, others) so make sure that whatever modules you need to use are going to work. Test test test!
Just to be sure, can someone -- preferably from or at least in France -- confirm this story? I'm just suspicious because this sounds a lot like a permutation of the urban legend that makes the rounds every now and then. You know the one -- the hysterical, shrieking paranoid email chain forward claiming...
{ $agency } is planning to put a tax on { rand qw/emails bandwidth memory discs CPU/ }, because the growth of the internet has prevented { $agency } from earning the same revenues that they used to get from { rand qw/postage phones tarriffs whatever/ }, so you all have to contact { $local_goverment_official } letting them know that this will bring an end to modern society as we've all come to love it.
So, like, I'm willing to accept that this time it might be real, but considering how many times this hoax has made the rounds, I want to hear it from a reliable source rather than some web site I -- as an American that doesn't typically prowl the contemporary French tech/political web sites -- am reluctant to trust without at least getting a second opinion.
Why I'm asking for a trustworthy second opinion on Slashdot, well, let's just dance around that one eh?:-) (And while you're at it, pardon the pseudo-code, I'm just trying to get the idea across...:-)
Good idea. While you're at it, you might want to do the same to nigrep (try a 'nigrep passw') and, for that matter, the other NetInfo commands in/usr/bin...
Interestingly, I listened to a good long interview with Stan Lee on the radio last weekend, and he made a similar point about when he was getting started with comic books. His characters, as all Marvel fans probably know, were different from older super heroes in that, in spite of the special powers, they were basically ordinary people with basically ordinary problems. They just happened to be saving the world from super villians in between doing their homework, paying their bills, and taking care of their elderly relatives.
Apparently, when Stan first wrote the Fantastic Four, he took this even a step further by having them look & dress like normal people. None of this spandex crap -- if Stan's heroes are going to act like regular folks, then they should dress the part too.
The fan reaction was awful. "Stan, we love the story, the characters are great, but why don't they have uniforms? if you don't fix that we're not gonna buy another issue..."
And so, being a practical man, he "fixed" the problem. For decades now, he has continued to put his soap opera stories -- "soap opera" being his term from the radio interview, not mine -- in their spandex jumpsuits, even if it looks silly. He's never been able to explain why, but any attempt to buck the convention has always been a dismal failure. Go figure.
Like Stan Lee, George Lucas also has to pay the bills. Granted, I don't think he's about to default on his mortgage or anything, but like you say, it's all about giving the audience what they want to see. Is it a distraction from how the story "should" be told? Possibly, but this is a highly commercial artform, and the minute it stops playing to the audience the show draws to a close.
Speaking of tinkering with the audience's expectations, I can't wait until the next James Bond movie:-):-):-)
FYI, it seems like your iTools mail account can be accessed from any IMAP reader on any platform. I regularly check my Mac mail using Pine, Mozilla-mail, and Mail.app on OSX, Linux, & Solaris boxes, and I've had no problems doing so. In a different window I've got Mozilla/Linux checking my mac.com mail through the web interface right now.
The other iTools services -- file sharing, etc -- are restricted to Macs only, but the mail component should be accessible anywhere, either through the web browser or with an IMAP client.
What a coincidence, I was just looking over this stuff this morning. Does anyone know how close we are to being able to run PHP with Apache2.0, preferably (but not necessarily) on Solaris? Looking over PHP4.2.1 notes this morning, it looked like Apache2 support still wasn't there yet, and some people seemed to be having problems building the language on Solaris. Does PHP4.3.0 address those problems? Should I take "Alpha" to be the warning that it sounds like it is, or would it be safe to try it out now? Would it make more sense to stick with PHP4.3.1 and Apache 1.3.x for now? I'm sure those should build okay....
You're dutifully ignoring the point. Seeing as the original article provided so little information or context, I have no idea if I'm an interested party. I can't tell from that if it can be ignored or if it should be studied further. I have a clearer idea now, based on people's comments, but the article itself is completely un-enlightening. That is what I'm griping about...
Slashdot Mirror
What is a "network" in this case anyway?
If this patent holds, it could be a thorn in the site of a lot of web sites out there.
yeah -- i got it :)
And I hardly think that a magazine like Billboard is a reasonable comparison -- you read a rag like that for the trashy ads. The Dell ads are running in mainstream sources (major daily newspapers, for example) and so stand out all the more. *shudder*
That is a *wonderful* idea. If Apple is sitting on such a big slush fund as I've heard, surely they could afford to chip in a bit for the free software they're getting to take advantage of...
From there, the remedy suggested roughly matches that which Ellem posted earlier, and which you are objecting to now. In his .sig footer, Folson identifies himself as "CPAN Tester for Mac OS X", and the advice he gives sounds credible.
If the advice summarized in these postings is unsound, do you have any counter suggestions that address the issues raised by Foxson's post? Or are those issues themselves phantoms? I didn't realize that Apple had a dedicated Fink developer, but seeing as that seems to be a part of your job description, a clarification of this matter would be very much appreciated -- and you might want to include the mailing lists mentioned above so that the users/developers will know what's going on "from the horse's mouth", so to speak.
Thanks a lot.
X-Fry: I'm never gonna get used to the thirty-first century. Caffeinated bacon?
X-Powered-By: Slash 2.003000
% lwp-request -m HEAD http://slashdot.org/ | grep '^X-'
X-Bender: Bite my shiny, metal ass!
X-Powered-By: Slash 2.003000
% lwp-request -m HEAD http://slashdot.org/ | grep '^X-'
X-Bender: Like most of life's problems, this one can be solved with bending.
X-Powered-By: Slash 2.003000
% lwp-request -m HEAD http://slashdot.org/ | grep '^X-'
X-Bender: There's nothing wrong with murder, just as long as you let Bender whet his beak.
X-Powered-By: Slash 2.003000
% lwp-request -m HEAD http://slashdot.org/ | grep '^X-'
X-Fry: No, no, I was just picking my nose.
X-Powered-By: Slash 2.003000
Is this a Slashdot specific hack, or does the publically available version of it do the same thing?
doh! well, you know what i meant... :)
I'm with Roberty Zubrin on this one: with the technology that Apollo produced, we should be going not to the moon, but to Mars. It would be completely doable, and there's far more interesting & useful things there than fuel for a mythical reactor that no one can even build yet. Just to pick two seemingly trivial examples: air & water. A martian base could cultivate what life support supplies are needed locally; a lunar base would have to import them -- expensively -- from earth. Any profit gained from He3 exploration would surely not be enough to counter those expenses, but a martian expedition could, for the most part live off the land and, once established, go on to more interesting things.
A few weeks ago, some contractors accidentally drilled through the line bringing electricity to our building, thus ending the workday for nearly everyone. At that point the only thing left to do was bring down all the servers & any desktop machines that weren't on a UPS, then crowd around in front of the office display computer -- the one with a UPS, a DVD drive, and a wall-mounted 48" display. We all sat around watching "Office Space" for as long as possible -- managers of other departments sent their employees home, then came over to watch. It was grand... :-)
Perl6 is arguably more complex than versions 1-5 combined, and yet it is coming along at a faster clip than any of the earlier iterations did -- largely because, yes, people have donated money so that these three very talented language designers can attack the problem more or less full time. It's foolish to expect this generation of Perl, as complex as it is, to come out in 1/4 the time that the most recent versions took. On the contrary, if it takes "only" 5 years, we can be glad that it arrived as soon as it did thanks to the full-time work these guys have been able to put in.
Also, it's worth noting that Perl has always been one of the first "mainstream" languages to bring features from special purpose academic languages to a wider audience, and Perl6 is a strong continuation of this history. Most people are probably unaware of constructs like regular expressions [version??], closures [Perl5], co-routines, currying functions, and continuations [all Perl6], so why would you expect masses of people to be "begging" for them? And yet once these features get implemented in Perl, they've had a tendency to start being demanded in other languages too -- witness Java recently adopting Perl-esque regexes, even as the Perl6 regex design is evolving away from simple pattern matching engine and into a more sophisticated grammar recognizing parser like Parse::RecDescent, lex, or yacc/bison.
So really, this kind of comment is nothing but trollbait, and I'm falling for it. Perl6, even half-fleshed out, is a tremendous leap forward compared to Perl5, and I for one feel lucky to have these guys focusing on it. In spite of your naked assertion at the end there, the RFC process that kicked off Perl6 development -- with well over 300 well thought out documents that took months for Larry to properly analyze -- well proves that people *were* begging for change, and slowly but surely it is happening. I hope that some magician can produce the funds to keep the Perl6 roadshow on the road, because within a couple of years I want to be able to use this wonderful new version of Perl. If the show ends now, it'll be years longer before Perl6 ever sees the light of day...
At the time I read it, I didn't know much about MySQL, but I had finished my battery of database design classes and I knew a little Perl & Python, and it was obvious that the book was riddled with errors, from poor explanations of normalization in early chapters to Perl scripts that, had the reader been so industrious as to type them in verbatim, wouldn't even compile, nevermind produce the intended result if the syntax bugs were ironed out.
To be fair to the generally excellent staff at O'Reilly, I'm sure there were later editions that ironed out many of those flaws, but the fact that not one but two Slashdot reviewers gave the book high marks says a lot more about the quality of the reviewers Slashdot is able to produce than it does about the rare splot on O'Reilly's otherwise fine record.
A year or so ago, the authors of the current rewrite of the book were soliciting peer feedback on the Perl section in particular, because of the bad reputation the original version got . I'm sure they worked very hard to make a better book this time around, but did they succeed? Who knows? This reviewer makes no mention of the original edition, and apparently doesn't realize how awful it was.
I'm interested in the update, but unfortunately will not trust this review in its assessment. I wasted thirty bucks on the last version, regretted it, later found the New Riders book, titled simply MySQL, and was for the most part happy. The Perl sections there are a little odd -- this author's code doesn't feel very idiomatically "native" to me, more like things a long time C hacker would prefer -- but as a reference & manual it is far better than the first edition of the O'Reilly book. I hope that with this edition they're catching up, but as far as I'm concerned the definitive reference manual for MySQL is already out, and like it or not there are no animals on the cover. Even if you wouldn't realize that from the reviews you see on Slashdot....
Personally, as the monkey that had to run it every week, I didn't like it very much -- the version we had could only do log analysis on NT, but all our servers were Linux, so once a week I had to download the weekly reports to my computer (which meant that I wasn't able to run Linux even though all the work I did other than WT had to run on Linux; the download wasn't *that* bad, we were a small site and all the logs would "only" amount to a couple hundred megs -- usually it would finish by the time lunch was over on Mondays... :/), the actual analysis would take quite a long time to complete, and at the end of it I'd have to upload the summary reports back to the web site so that everyone that needed access would be able to see it.
Now to be fair, counter to what I just wrote, the catch is that the copy of Web Trends we had was old when I started the job, and it's even older now -- I'm thinking it's at least three or four years old now. Presumably there are better versions of it now that can run on the same platform as the server OS. Better still, I could have saved a lot of bother by just leaving an NT box at the co-lo facility and automatically access Apache log files by the FTP or SAMBA as needed. But I didn't think of that then, and the product documentation certainly didn't make such a useful suggestion.
I think the earlier poster hit the nail on the head with his comment about quantitative (log based data) vs. qualitative (questionnaire / survey / observation type data). You can whine all you want about how web gathered data is imperfect as a data collection for marketing analysis, but hey, just look at what *every other* form of advertising has to offer: surveys only. Hey, the web can do surveys too, and the web can also gather all this technical information that aren't available to TV, radio, or print ads. The issue isn't that this web data is imperfect -- so what? -- the issue is that you at least have something to work with. As long as you keep the imperfections in the back of your mind when analyzing that data, you can still draw conclusions that are at least as solid as those gatherable by any other form of media.
Also, playing into another point raised by that same poster, I have heard of companies hitting the same problems with internal web data numbers being consistently lower than those obtained by third parties. There are a lot of reasons that this will happen, and not all of them are ones you want to try to defeat -- caching for example allows many people to see your content without running up your bandwidth costs, but the tradeoff is that you never know for sure how many people got to see that content. The best you can hope for is consistency -- to always have numbers that are 1.2x that of the third party counts, or 1.6x, or 3x or if you're lucky 0.75x. Whatever. The point being, getting the numbers to agree is difficult because everyone has a different counting strategy; as long as you can account for the differences & accurately preduct how the third party numbers will agree (or disagree) with yours, that's enough to work with.
Fittingly, when I followed the NYTimes link it showed me an unrequested popup window. This is very interesting to me, as I've got Mozilla set to not allow pages to do that, and this was in fact an article about, well, not wanting to do that. Figures then that this would be the page to poke through my trust in Mozilla's ad armouring features... :-)
Still, any shortcomings of the Zope Book detract nothing from the goodness of Zope itself. By default it gives you a nice, featureful web-based management system. "Web-based" can often be a hindrance (complex UI's over the web don't always work very well) but in this case you can get pretty far without having to screw around under the hood, so to speak. One thing to get to terms with is that Zope, written as it is in OO Python, gets to take advantage of a lot of useful, but sometimes confusing, object inheritance trickery. Like for example you can create a user account at a certain level of your site, and inheritance will allow that user's priviliges to cascade down into lower levels of the site but not higher ones. Kind of an obvious feature to want, but the details of how such things get fleshed out are subtle and worth trying to get your head around.
Like the commenter above notes, "it wouldn't hurt to learn a little Python". In many case you can just use Perl, but you may find in the long run that Python feels like a better fit for Zope anyway (seeing as the source code is largely Python in the first place). In any event, the semantic similarities between Python and Perl are much stronger than the semantic *and* syntactic differences you're going to see between Perl and the scripting language offered by most other CMS offerings. And you're actually considering Microsoft CMS? Please.... :-)
There are of course other good comments in this discussion, but this is the only one I see endorsing Zope, and I want to second that notion. If the first wave of dynamic web content was CGI, and the second was mod_perl, then the next one along that track seems to be Zope, which really allows you to work at a *much* higher layer of abstraction (which is of course a good thing, and for the same reason that almost nobody writes web stuff in C or assembler). Zope offers a rich high level toolkit -- object persistance (that you might even prefer to standard DBMS storage, though it's there if you want it), templates (some tending towards "HTML with code", others towards "code with HTML"), a mechanism for distributing your content across multiple servers,security controls, etc. It would take *a lot* of work to reproduce all this functionality in-house, and even if you did it would be hard to guarantee that it was as robust as Zope (or, to be fair, many of the other CMS offerings).
TOmorrow I'm gonna submit a story about how Linux kernal 2.0 was finally released... :-)
Like I say, there are different ways of doing this, and really you ought to browse through a good bookstore or two to get more details. One strategy that's easy to implement might be to split up your content so that plain html is on www.site.com while your images are on img.site.com, your cgi scripts are on cgi.site.com, and your data is housed on db.site.com (which probably shouldn't be web accessible, by the way -- this protects you!). This is a vertical split. Or you can go horizontal by placing everything behind a load balancer that redirects incoming requests to one of several web servers -- each of which can be getting content from a single shared NFS partition. Or you can do a mix of those: maybe all the front end web servers communicate with dedicated database etc boxes behind them (which, again, would not be otherwise internet accessible).
On a Linux or Unix system, NFS is a pretty easy way to mirror content across all your servers. For a Win2k served site, you could probably get away with CIFS Windows shared drives. Or if you want to be really cutting edge, WebDAV might be able to meet similar needs. Less clever -- but debatably easier -- ways to do it might involve rsync'ing content from a master content server to a set of web-facing server "clients". A variation on that idea ends up being more or less identical to content proxy caching, as one big expensive app server in the back gets it's data cached onto a pool of cheap web facing proxies.
But, like I said at the beginning, the devil is in the details and you really ought to pick up a couple of good books if you want to learn more about this. Strategies for e.g. database "clustering" can vary widely depending on the RDBMS being used: I doubt the method would be the same for MySQL as it would for PostgreSQL, Oracle or SQLServer, for example. Some of those might be able to do this work almost transparently, while others would involve more manual planning & setup.
Wait, so if you're buying CD-Rs for personal use you have to pay a tax, but if you're going to -- say -- copy & sell music or software then you can get a tax refund. *That* sounds like an effective restraint on piracy letmetellya :-) :-) :-)
So, like, I'm willing to accept that this time it might be real, but considering how many times this hoax has made the rounds, I want to hear it from a reliable source rather than some web site I -- as an American that doesn't typically prowl the contemporary French tech/political web sites -- am reluctant to trust without at least getting a second opinion.
Why I'm asking for a trustworthy second opinion on Slashdot, well, let's just dance around that one eh? :-) :-)
(And while you're at it, pardon the pseudo-code, I'm just trying to get the idea across...
heh :-)
Good idea. While you're at it, you might want to do the same to nigrep (try a 'nigrep passw') and, for that matter, the other NetInfo commands in /usr/bin...
Apparently, when Stan first wrote the Fantastic Four, he took this even a step further by having them look & dress like normal people. None of this spandex crap -- if Stan's heroes are going to act like regular folks, then they should dress the part too.
The fan reaction was awful. "Stan, we love the story, the characters are great, but why don't they have uniforms? if you don't fix that we're not gonna buy another issue..."
And so, being a practical man, he "fixed" the problem. For decades now, he has continued to put his soap opera stories -- "soap opera" being his term from the radio interview, not mine -- in their spandex jumpsuits, even if it looks silly. He's never been able to explain why, but any attempt to buck the convention has always been a dismal failure. Go figure.
Like Stan Lee, George Lucas also has to pay the bills. Granted, I don't think he's about to default on his mortgage or anything, but like you say, it's all about giving the audience what they want to see. Is it a distraction from how the story "should" be told? Possibly, but this is a highly commercial artform, and the minute it stops playing to the audience the show draws to a close.
Speaking of tinkering with the audience's expectations, I can't wait until the next James Bond movie :-) :-) :-)
The other iTools services -- file sharing, etc -- are restricted to Macs only, but the mail component should be accessible anywhere, either through the web browser or with an IMAP client.
What a coincidence, I was just looking over this stuff this morning. Does anyone know how close we are to being able to run PHP with Apache2.0, preferably (but not necessarily) on Solaris? Looking over PHP4.2.1 notes this morning, it looked like Apache2 support still wasn't there yet, and some people seemed to be having problems building the language on Solaris. Does PHP4.3.0 address those problems? Should I take "Alpha" to be the warning that it sounds like it is, or would it be safe to try it out now? Would it make more sense to stick with PHP4.3.1 and Apache 1.3.x for now? I'm sure those should build okay....
You're dutifully ignoring the point. Seeing as the original article provided so little information or context, I have no idea if I'm an interested party. I can't tell from that if it can be ignored or if it should be studied further. I have a clearer idea now, based on people's comments, but the article itself is completely un-enlightening. That is what I'm griping about...