According to my bps over the past month according to mrtg:
RX: 20GB
TX: 1.5GB
Now, that sounds like quite a lot, and sure, it's probably a fair bit above average. Except, I doubt more than a couple of those GB's ever made it outside my provider's network, because most if it is from usenet.
Should I be charged more for using a local news service and my providers internal bandwidth? More importantly, should I be charged the same as some guy who spends those 20G's on Gnutella, 90% of which is jumping off to random nodes around the world and eating the bandwidth they actually pay for?
> When you think about it, aren't pop-unders better than pop-overs?
Not when you tend to open a lot of windows in the background and those f*cking window.focus() calls screw up your window ordering; the end result is even *bigger* windows get popped to the front; requested ones, yes, but when you open a window in the background only to have it force itself to the front, it's very irritating.
I'd rather have the fairly well defined behavior of popup's than have my window stack ordering screwed up as well.
What's not so cool about this is it breaks opening *any* JS windows.
While not a problem on sites that do it properly (<a href="foo.html" onclick="openwindow('foo.html');return false;">foo</a>), it's annoying on sites that use the javascript: pseudo-protocol (<a href="javascript:openwindow('foo.html')">foo< ; / >) and which misuse onclick (<a href="#" onclick="openwindow('foo.html')">foo</a>).
> But Opera can identify itself as other browsers.
More importantly, Opera by default identifies itself as another browser.
One of the first things I did when I configured it was to set it to identify itself as Opera rather than MSIE. I can't say I've ever felt the need to revert.
I guess I must have somewhat atypical browsing habits, since I can't say I've seen many problems with layout or JS - the worst I can think of from the past month or so was perhaps an offset CSS/Edge style background image on some site, and that's still rendered better than MSIE.
Certainly as a web developer I find I hit problems with MSIE more often than I do with Opera. I guess that's because I'm not a DHTML weenie:)
Not only is it more up-to-date, more easily upgraded, and able to get as bloated as Perl demands, it also includes the excellent BSDPAN.
BSDPAN allows you to install CPAN modules and manage them like any other package (pkg_info, pkg_delete, etc), and for weenies like me who set LOCALBASE to/usr/pkg, makes them LOCALBASE clean, \o/
/usr/ports/lang/perl5 is not just there for completeness. Even if you have Perl installed from base, chances are anyone even remotely interested in Perl will want to replace it with the port anyway.
Now, if only we can convince core to remove sendmail...
> > The best answer, ofcourse, is "we simply don't know".
> No, the best answer is: Because the writers didn't really think it through very well.
No, the best answer is: because a film where horses are hooked into a big fusion reactor and put into a fake reality where horses run around plains all day isn't going to make for a very interesting movie. The same goes for if they'd gone for custom designed brainless lumps of organic matter.
>Why do the agents bother to broadcast their presence to the rebels by morphing into "Men In Black" whenever they take a body over
Because they are trying to make it look "cool". They weren't out to make an entirely self-consistant universe, they were trying to make a movie they thought was cool and would impress people.
Sure, you could make a film that was self consistant and made sense, but most people in the industry simply aren't good enough to be able to come up with one and be able to pull it off. And those that can aren't necessarily going to be the ones to get in a position in which to make a film like The Matrix.
Just look at Spielberg; do you think the films he makes are particularly thought inspiring, imaginative, or self-consistant? No; nobody would look twice if he was a writer.
> Perl is really good about this. The Test::Harness > and Test::More modules make it very easy to write > test suites, so CPAN modules have lots of > automated tests.
Ruby also has a number of unit test frameworks which are used by a surprising (or not, depending on your PoV) amount of software written in it.
ruby <name_of_library.rb>, and fairly often you'll see it run some unit tests that were wrapped in an if ARGV[0] == __FILE__ block.
On the other hand, if inflation (that is, the universe expanding faster than the speed of light) has had as a significant effect on the size of the Universe as some would have us believe, the visible Universe is likely to just be a small bubble in a much larger physical Universe, since the light in it simply hasn't had time to travel all the way across it.
As for the Universe wrapping around, well, yeah; what else is it going to do? Ok, maybe it'll just reverse you when you cross the "boundary", and you end up going in the other direction with your left/right reversed (like what would happen if you were to flip through the 5th dimension) or something. Bah, how should I know;)
> By simply adding &threshold=-1 to the end of that, I can see all the replies [slashdot.org] at -1 easily and painlessly.
The argument wasn't "query strings are bad, m'kay"; look at the URI and see what information's in there. Does.pl serve any purpose? Does sid=3188 gain anything, aside from make the page very difficult to serve statically? Does tid=95 and pid=3436807 tell you anything?
The URI's would work just as well using something like http://slashdot.org/stories/31884/comments/3436807 / 5/?mode=nested&threshold=-1; even if/stories/31884 were a static file, the URI would still work and point roughly to the right place. And it's not exposing the internals of how the comments system works, and it's keeping the more readily tunable query strings clear, without making the exact resource you're pointing to difficult to find.
> Do you know how to make k5's comments nested instead of threaded purely using the URI?
No. Actually, I wasn't really pointing out k5 as being the perfect example; Scoop actually tends to really suck in this respect (like setting the URI to '/' when you change comment modes). However, I might be tempted to ask you which URI is likely to live the longest, certainly back when SlashDot used to archive articles after a couple of weeks.
> The point is, wether or not it takes the optimum number of bytes isn't always the priority
I never once said the size of the URI was important. I said it contained a lot of extranious information that changed a lot while meaning little (i.e. the URI's changed from the dynamic query string to an.shtml file when a story was archived).
> in the case of/., its designed to be easy to use for the (savvy) user, not easy on the server
What's easier for the "savvy" user? A URI that will work for the rest of SlashDot's life, or one that'll last until the story is archived, or the underlying architecture changes, and which contains a lot of randomly ordered and mostly meaningless information?
A well designed URI scheme will actually give the savvy user a lot more control; say, you include the date of an article, ala http://slashdot.org/stories/2002/05/30/; you can imagine going to such a URI and getting all of the stories on that day, month or year, and instantly being able to identify how old a linked to article is. You can also imagine an archived URI and a live, dynamic URI both using the same schema.
You can also imagine giving a URI of an interesting article to a friend without first having to decode the query string; just strip off anything after/comments and they get the story.
Note: This applies to any site, those particular SlashDot and k5 URI's were just examples.
> You can't mod_rewrite a domain name that you have lost control over.
Nope, that's too bad. You can mod_rewrite a domain name you do have control over, though. You can also see if you can get the new owners to redirect to your new domain.
If, say, all your URI's start with a date, you ask the new owners to redirect any URI containing '/yyyy/mm/dd' less than the date you lost the domain to your new site. You may not get it all or even most of the time, but the option is still there.
Alas, this is one of those cases URN's would come in handy.
My little (unreleased) intro to Ruby
on
Ruby Developer's Guide
·
· Score: 4, Interesting
The key to making links that don't rot is to design a URI schema that's both independent of any redesigns of your site and independent of any particular way of doing things.
Well, for a start, that.pl is a bad idea. What happens in 4 years time when SlashDot is running on PHP, or Java, or Perl 7, or a Perl Server Page, or ASP? Then there's the difficult-to-decode query string that tells you nothing about the link other than "this is the information the server needs to locate your page at the moment", and doesn't give you much faith in it living forever.
For a start, you can't tell what application or script is serving you the page, and you can't see what type of file it's linking to; both these things can and will change over time.
Second, there's a date embedded in there; you can see the developers, if they ever decide to change the meaning of '/comments', using that date as a reference; if the URI is before the change, they can map it onto the new schema or pass it onto legacy code.
Having the date in the URI is good because it allows you to determine when the link was issued, and map it onto any changes or pass it off to a legacy system as required.
Now let's take an apparantly good link on my now horribly out of date site, aagh.net.
Certainly, hiding the fact that I'm using PHP to serve this document is good, and shortening the URI to remove the useless querystring is good (you can't see one? Good, that's the point), however, this URI may well stop working in a few weeks; I'm planning a redesign and the old schema may well not fit in well with it.
A short yyyymm in there could have made all the difference; a simple if check on the URI's issue date would keep it working.
The moral of the story: Think about your URI's when you're designing a site. Try to remove as much data as you can without painting yourself into a corner.
Well, assuming we run out of data to process and methods to process it (yeah, right), or you get bored, or decide it's pointless, there are plenty of other projects to go to.
Folding@Home and Genome@Home are two related projects with open results and which will probably have client source available sometime.
> why couldn't the author try out the code without having the game installed?
Like Quake, Doom, etc, the data files were not released, only the code for the engine/exe.
> I'm wondering if it is still available for sale somewhere
Yes. I bought the Virgin Interactive "White Label" edition, which includes FreeSpace 1 and 2 for under £10 a few months ago. You should be able to pick up a copy. £10's damn good concidering that's 6 CD's worth of game:)
> From the screenshots, Freespace 2 appears to be similar to Homeworld [sierra.com] and Terminus [vvisions.com].
Not quite. FreeSpace 2 is more like a space flight sim; you get to fly about in a fighter craft, often around big-ass capital ships you either get to protect, destroy, or run away from. Sometimes in quite yummy nebula's (quite a sight when you see the shadow of an enemy superdestroyer come into view, filling half the sky before melting one of the destroyers you're escorting in one shot:)
The beam weapons are lovely and substantial; get hit by an anti-fighter beam and you get knocked about like a tin can while you desperately try to get out of it's way.
There are a few very good quality mods too. I can personally recommend the truely excellent Derelict; VolitionWatch is down at the moment though.
Although I can see the argument for having all the compiled-in extensions loaded all the time, having absolutely everything in the same namespace makes writing procedural code a little dangerous, not to mention leaving a nasty taste in your mouth if you're trying to code in an OO fasion.
The answer is, of course, to put your functions in a seperate namespace (a class in Zend 1, a proper namespace in Zend 2), or to use a naming scheme that's less likely to conflict (personally I use WordCaps (or camelCase) instead of under_scores, but since PHP doesn't stick to under_score style all the time and isn't case sensitive, this isn't a wonderful solution).
Coding in an OO fasion's less an issue for namespace conflicts, and more an issue for getting procedural code thrown in everywhere unless you load performance draining wrappers. PHP's weak object model doesn't help here. After using Ruby I find myself running into PHP's limits a lot harder. *grumble*
I hope that they will move extensions to make use of namespaces sometime (PHP 5, or 6 maybe); i.e. MySQL::connect(), PgSQL::connect(), etc. If nothing else this will help make the language cleaner.
BTW, as for CPAN, some of the PHP bods are trying to produce something like it; PEAR, which includes a passable database abstraction layer, among other things.
Personally, I'd be using Ruby if it had better webserver embeddability (mod_ruby doesn't yet support Apache 2, and the Apache 1 support feels a bit immature) and a nicer CGI API. Running it as a daemon might be an interesting solution, but finding hosts who will allow that might be a bit of a pain. Maybe I should try it out while I can:)
> Don't Perl scripts get compiled every time they are run?
Yes, but it's compiled into an internal bytecode format, not an executable binary.
In this sense it's more like Java -> Bytecode -> JVM (hence Perl -> Bytecode -> PVM) than, say, C -> Object code -> Native Binary. Not quite, but near enough.
Python has the same property, as do many otherwise interpreted languages. Parrot (the engine Perl 6 will use) is also bytecode based, and probably has more in common with a Java VM, in that it impliments a sort of dynamic-language CPU with registers and instructions, rather than just a tree of tokens the interpreter can easily walk along.
Can you please repost in a form that isn't just one long 25 line paragraph?
> We understand the processes, they don't work that way.
Says you. Maybe also says some scientists, but I'd still rather believe our knowledge and understanding is incomplete and our insight too shallow than give up and introduce something even more difficult to explain.
You see, if you want to rely on a Godlike being, eventually we're going to have to explain that. Exchanging one apparantly impossible thing with another just doesn't seem like good science to me:)
> I'm just a bit tired of the cultish "don't like it? build your own" thread that seems to permeate much of the open source community
That is the way it works. The fact of the matter is that most people with the skills to actually develop such an interface don't have that particular itch to scratch.
> I'm also disappointed by the lack of original ideas, as reflected in the EMACS vs VI and Apache vs IIS wars
Ah, well, original ideas are few and far between everywhere in computing, not just open source. And a lot of those new ideas are in techy stuff most people couldn't care less about, and even most of THOSE aren't particularly new, just nobody bothered implimenting them:)
Apache used to have a pure prefork scheme for handling requests. Now it's a mix and match with various schemes, including one that allows seperate Apache processes to run as the user id of whoever owns a particular virtual host ([sound of 100,000 PHP weenies wetting their pants]). Does that count as an original idea? Probably not, but that's the sort of level that impresses most Apache users.
> Surely, it is possible that someone, someday, might build a better editor that either EMACS or vi
Sure. JEdit, NEdit, etc. I still prefer vim, but for a lot of people they would count, no?
Anyway, Emacs isn't an editor, it's a LISP interpreter with a bundled editor:)
> and surely it is possible that neither Apache or IIS represent the ultimate in web server technology.
There are plenty of alternatives (Roxen, thttpd, Jigsaw, Webrick, etc), and IIS and Apache are obviously still making big advances in their own scheme of things.
> Why can't the open source community generate sone truly innovative, easy to use, ideas
You might ask the same of any development community (websites, architecture, car design, commercial software vendors, etc). Finding one or the other may be fairly easy, finding both (aside from being doubly subjective) may prove more difficult. And finding one that's truely new will probably cut that down even more:)
> instead of rewriting the same old stuff
This is what humans are about. Get an idea, mix it about with other ideas, occasionally come up with a new idea. Repeat.
It just happens that the open source side of things tends to be from the perspective of a programmer, so..
> and castigating as "not terribly bright outsiders" those with the temerity to suggest that Computers Are Supposed To Be East To Use??
What's easy to use for you may not be easy to use for a programmer. What's easy for a sysadmin may not be easy for you either. Well, that's where most open source is targetted; if you dislike it, find something that is aimed at you, alter other software (or pay someone to do it) to make it more like what you want, or try commercial software which by and large is aimed at you.
Certainly, getting upset over the interface for various open source stuff not meeting your expectations won't get you very far unless you can make suggestions on how to change them in a way everyone can live with.
> Gonzalez writes: "The fact that the Sun's location is fine-tuned to permit the possibility of life [...] powerfully suggests divine design."
I can't resist pointing out that if the Sun wasn't in such a state, we wouldn't be here to talk about it.
On the other hand, if the Sun wasn't so tuned, and we WERE here and not all dieing of mass cancers or being frozen/boiled, I'd be much more inclined to believe that maybe there is some divine intervention there.
> This kind of troglodytic ignorance of the value of a good interface is all too typical.
Since when is "write one and submit it" classed as ignoance? I understand the problem domain, I know how a good interface can improve matters. it just so happens the text file + vim + docs is a pretty optimal solution for me.
> Why shouldn't this stuff be easy to use?
Apache's config is very user friendly for it's target demographic. Concidering how flexible and complex Apache is, it's remarkably simple to set up.
> Why should soneone need to know how to construct regular expressions in order to run a web server?
They don't. If they want to do pattern matching to transform URI's or whatever, though, regexp is the only way to go. If you can think of a more user friendly way of matching arbitary strings, then quick! patent it!
> Why maintain the quarter-century old text-based UNIX interface as some kind of rite of passage that the Chosen Ones use to ward off the Heathen?
I'll be impressed if you can come up with a non-cluttered, stable, secure, lightweight config tool that can match even the standard Apache config, never mind the power of being able to bring any text processing language to bear on any problem.
> If open source is really about giving people choices, then give them more than one option.
Your choices:
Write your own. If you know so much about interface design, put it to use, even if you just come up with an interface design paper.
Find one of the many currently available interfaces; a quick freshmeat search finds Comanche, Mohawk and TkApache.
Lucky for you Apache comes with a KLIK install system. There's no particular reason they couldn't extend that to provide a bit more flexibility over the installed config.
Nor is there any particular reason the PHP team couldn't write an MSI that supported Apache. No need for yet another set of tools that don't really fit in with the Windows way of doing things (although I suppose apt works quite like Windows when dependencies get screwed up or the "registry" gets damaged *grin*).
> So why not put this argument to bed and just offer both as built-in support with apache?
Go write one suitable for production use, give it to the Apache Software Foundation, and I'm sure they'll be more than happy to bundle it, or at least provide it as a seperate subproject.
Slashdot Mirror
I came up with mboxdir. It was actually a preliminary specification for a Win32 client.
RX: 20GB
TX: 1.5GB
Now, that sounds like quite a lot, and sure, it's probably a fair bit above average. Except, I doubt more than a couple of those GB's ever made it outside my provider's network, because most if it is from usenet.
Should I be charged more for using a local news service and my providers internal bandwidth? More importantly, should I be charged the same as some guy who spends those 20G's on Gnutella, 90% of which is jumping off to random nodes around the world and eating the bandwidth they actually pay for?
> When you think about it, aren't pop-unders better than pop-overs?
Not when you tend to open a lot of windows in the background and those f*cking window.focus() calls screw up your window ordering; the end result is even *bigger* windows get popped to the front; requested ones, yes, but when you open a window in the background only to have it force itself to the front, it's very irritating.
I'd rather have the fairly well defined behavior of popup's than have my window stack ordering screwed up as well.
What's not so cool about this is it breaks opening *any* JS windows.
.
While not a problem on sites that do it properly (<a href="foo.html" onclick="openwindow('foo.html');return false;">foo</a>), it's annoying on sites that use the javascript: pseudo-protocol (<a href="javascript:openwindow('foo.html')">foo< ; / >) and which misuse onclick (<a href="#" onclick="openwindow('foo.html')">foo</a>)
*grumble*
> Does buying it make these stupid ads go away?
:)
Yes.
Putting this in your user css file and setting it up in Opera/Mozilla makes most of the stupid ads on websites go away too:
http://freak.aagh.net/code/user.css
Just in case you need a reason to dump MSIE
> But Opera can identify itself as other browsers.
:)
More importantly, Opera by default identifies itself as another browser.
One of the first things I did when I configured it was to set it to identify itself as Opera rather than MSIE. I can't say I've ever felt the need to revert.
I guess I must have somewhat atypical browsing habits, since I can't say I've seen many problems with layout or JS - the worst I can think of from the past month or so was perhaps an offset CSS/Edge style background image on some site, and that's still rendered better than MSIE.
Certainly as a web developer I find I hit problems with MSIE more often than I do with Opera. I guess that's because I'm not a DHTML weenie
Not only is it more up-to-date, more easily upgraded, and able to get as bloated as Perl demands, it also includes the excellent BSDPAN.
/usr/pkg, makes them LOCALBASE clean, \o/
BSDPAN allows you to install CPAN modules and manage them like any other package (pkg_info, pkg_delete, etc), and for weenies like me who set LOCALBASE to
/usr/ports/lang/perl5 is not just there for completeness. Even if you have Perl installed from base, chances are anyone even remotely interested in Perl will want to replace it with the port anyway.
Now, if only we can convince core to remove sendmail...
No, the best answer is: because a film where horses are hooked into a big fusion reactor and put into a fake reality where horses run around plains all day isn't going to make for a very interesting movie. The same goes for if they'd gone for custom designed brainless lumps of organic matter.
Because they are trying to make it look "cool". They weren't out to make an entirely self-consistant universe, they were trying to make a movie they thought was cool and would impress people.
Sure, you could make a film that was self consistant and made sense, but most people in the industry simply aren't good enough to be able to come up with one and be able to pull it off. And those that can aren't necessarily going to be the ones to get in a position in which to make a film like The Matrix.
Just look at Spielberg; do you think the films he makes are particularly thought inspiring, imaginative, or self-consistant? No; nobody would look twice if he was a writer.
> Perl is really good about this. The Test::Harness
> and Test::More modules make it very easy to write
> test suites, so CPAN modules have lots of
> automated tests.
Ruby also has a number of unit test frameworks which are used by a surprising (or not, depending on your PoV) amount of software written in it.
ruby <name_of_library.rb>, and fairly often you'll see it run some unit tests that were wrapped in an if ARGV[0] == __FILE__ block.
On the other hand, if inflation (that is, the universe expanding faster than the speed of light) has had as a significant effect on the size of the Universe as some would have us believe, the visible Universe is likely to just be a small bubble in a much larger physical Universe, since the light in it simply hasn't had time to travel all the way across it.
;)
As for the Universe wrapping around, well, yeah; what else is it going to do? Ok, maybe it'll just reverse you when you cross the "boundary", and you end up going in the other direction with your left/right reversed (like what would happen if you were to flip through the 5th dimension) or something. Bah, how should I know
> By simply adding &threshold=-1 to the end of that, I can see all the replies [slashdot.org] at -1 easily and painlessly.
.pl serve any purpose? Does sid=3188 gain anything, aside from make the page very difficult to serve statically? Does tid=95 and pid=3436807 tell you anything?
7 / 5/?mode=nested&threshold=-1; even if /stories/31884 were a static file, the URI would still work and point roughly to the right place. And it's not exposing the internals of how the comments system works, and it's keeping the more readily tunable query strings clear, without making the exact resource you're pointing to difficult to find.
.shtml file when a story was archived).
/., its designed to be easy to use for the (savvy) user, not easy on the server
/comments and they get the story.
The argument wasn't "query strings are bad, m'kay"; look at the URI and see what information's in there. Does
The URI's would work just as well using something like http://slashdot.org/stories/31884/comments/343680
> Do you know how to make k5's comments nested instead of threaded purely using the URI?
No. Actually, I wasn't really pointing out k5 as being the perfect example; Scoop actually tends to really suck in this respect (like setting the URI to '/' when you change comment modes). However, I might be tempted to ask you which URI is likely to live the longest, certainly back when SlashDot used to archive articles after a couple of weeks.
> The point is, wether or not it takes the optimum number of bytes isn't always the priority
I never once said the size of the URI was important. I said it contained a lot of extranious information that changed a lot while meaning little (i.e. the URI's changed from the dynamic query string to an
> in the case of
What's easier for the "savvy" user? A URI that will work for the rest of SlashDot's life, or one that'll last until the story is archived, or the underlying architecture changes, and which contains a lot of randomly ordered and mostly meaningless information?
A well designed URI scheme will actually give the savvy user a lot more control; say, you include the date of an article, ala http://slashdot.org/stories/2002/05/30/; you can imagine going to such a URI and getting all of the stories on that day, month or year, and instantly being able to identify how old a linked to article is. You can also imagine an archived URI and a live, dynamic URI both using the same schema.
You can also imagine giving a URI of an interesting article to a friend without first having to decode the query string; just strip off anything after
Note: This applies to any site, those particular SlashDot and k5 URI's were just examples.
> You can't mod_rewrite a domain name that you have lost control over.
Nope, that's too bad. You can mod_rewrite a domain name you do have control over, though. You can also see if you can get the new owners to redirect to your new domain.
If, say, all your URI's start with a date, you ask the new owners to redirect any URI containing '/yyyy/mm/dd' less than the date you lost the domain to your new site. You may not get it all or even most of the time, but the option is still there.
Alas, this is one of those cases URN's would come in handy.
http://freak.aagh.net/ruby/intro/
It's only a first draft, but it should give a reasonable overview to the curious.
The key to making links that don't rot is to design a URI schema that's both independent of any redesigns of your site and independent of any particular way of doing things.
y &threshold=3&commentsort=3&tid=95&mode=nested&pid= 3434535 - what is it telling you that it doesn't need to?
.pl is a bad idea. What happens in 4 years time when SlashDot is running on PHP, or Java, or Perl 7, or a Perl Server Page, or ASP? Then there's the difficult-to-decode query string that tells you nothing about the link other than "this is the information the server needs to locate your page at the moment", and doesn't give you much faith in it living forever.
6 511/51/post#here is a URI to reply to a random comment on k5.
Let's look at a few examples.
The URI to this page is http://slashdot.org/comments.pl?sid=31884&op=Repl
Well, for a start, that
Now let's look at an equivilent Kuro5hin URI.
http://www.kuro5hin.org/comments/2002/4/29/22137/
For a start, you can't tell what application or script is serving you the page, and you can't see what type of file it's linking to; both these things can and will change over time.
Second, there's a date embedded in there; you can see the developers, if they ever decide to change the meaning of '/comments', using that date as a reference; if the URI is before the change, they can map it onto the new schema or pass it onto legacy code.
Having the date in the URI is good because it allows you to determine when the link was issued, and map it onto any changes or pass it off to a legacy system as required.
Now let's take an apparantly good link on my now horribly out of date site, aagh.net.
http://www.aagh.net/php/style/ links to an article on PHP coding style.
Certainly, hiding the fact that I'm using PHP to serve this document is good, and shortening the URI to remove the useless querystring is good (you can't see one? Good, that's the point), however, this URI may well stop working in a few weeks; I'm planning a redesign and the old schema may well not fit in well with it.
A short yyyymm in there could have made all the difference; a simple if check on the URI's issue date would keep it working.
The moral of the story: Think about your URI's when you're designing a site. Try to remove as much data as you can without painting yourself into a corner.
> what next?
Well, assuming we run out of data to process and methods to process it (yeah, right), or you get bored, or decide it's pointless, there are plenty of other projects to go to.
Folding@Home and Genome@Home are two related projects with open results and which will probably have client source available sometime.
Check a list of distributed projects. There's plenty of choice.
> why couldn't the author try out the code without having the game installed?
:)
:)
Like Quake, Doom, etc, the data files were not released, only the code for the engine/exe.
> I'm wondering if it is still available for sale somewhere
Yes. I bought the Virgin Interactive "White Label" edition, which includes FreeSpace 1 and 2 for under £10 a few months ago. You should be able to pick up a copy. £10's damn good concidering that's 6 CD's worth of game
> From the screenshots, Freespace 2 appears to be similar to Homeworld [sierra.com] and Terminus [vvisions.com].
Not quite. FreeSpace 2 is more like a space flight sim; you get to fly about in a fighter craft, often around big-ass capital ships you either get to protect, destroy, or run away from. Sometimes in quite yummy nebula's (quite a sight when you see the shadow of an enemy superdestroyer come into view, filling half the sky before melting one of the destroyers you're escorting in one shot
The beam weapons are lovely and substantial; get hit by an anti-fighter beam and you get knocked about like a tin can while you desperately try to get out of it's way.
There are a few very good quality mods too. I can personally recommend the truely excellent Derelict; VolitionWatch is down at the moment though.
Yeah, it's a bit ugly having a flat namespace of, let's see;
:)
-<freaky@voi:~/src/phpdoc/en/functions>-
-% grep '<refentry id="function\.' *.xml |wc -l
2579
2579 functions.
Although I can see the argument for having all the compiled-in extensions loaded all the time, having absolutely everything in the same namespace makes writing procedural code a little dangerous, not to mention leaving a nasty taste in your mouth if you're trying to code in an OO fasion.
The answer is, of course, to put your functions in a seperate namespace (a class in Zend 1, a proper namespace in Zend 2), or to use a naming scheme that's less likely to conflict (personally I use WordCaps (or camelCase) instead of under_scores, but since PHP doesn't stick to under_score style all the time and isn't case sensitive, this isn't a wonderful solution).
Coding in an OO fasion's less an issue for namespace conflicts, and more an issue for getting procedural code thrown in everywhere unless you load performance draining wrappers. PHP's weak object model doesn't help here. After using Ruby I find myself running into PHP's limits a lot harder. *grumble*
I hope that they will move extensions to make use of namespaces sometime (PHP 5, or 6 maybe); i.e. MySQL::connect(), PgSQL::connect(), etc. If nothing else this will help make the language cleaner.
BTW, as for CPAN, some of the PHP bods are trying to produce something like it; PEAR, which includes a passable database abstraction layer, among other things.
Personally, I'd be using Ruby if it had better webserver embeddability (mod_ruby doesn't yet support Apache 2, and the Apache 1 support feels a bit immature) and a nicer CGI API. Running it as a daemon might be an interesting solution, but finding hosts who will allow that might be a bit of a pain. Maybe I should try it out while I can
> That must explain why SMP, the TCP stack, and the VM are light-years ahead of LINUX on BSD.
:)
FreeBSD's SMP is actually pretty smelly. It certainly doesn't scale very far.
OpenBSD's SMP is non-existant.
So, presumably, NetBSD's SMP rules?
And yes, FreeBSD 5's SMP will rule too, but "light-years ahead" is pushing it
> Don't Perl scripts get compiled every time they are run?
Yes, but it's compiled into an internal bytecode format, not an executable binary.
In this sense it's more like Java -> Bytecode -> JVM (hence Perl -> Bytecode -> PVM) than, say, C -> Object code -> Native Binary. Not quite, but near enough.
Python has the same property, as do many otherwise interpreted languages. Parrot (the engine Perl 6 will use) is also bytecode based, and probably has more in common with a Java VM, in that it impliments a sort of dynamic-language CPU with registers and instructions, rather than just a tree of tokens the interpreter can easily walk along.
Can you please repost in a form that isn't just one long 25 line paragraph?
:)
> We understand the processes, they don't work that way.
Says you. Maybe also says some scientists, but I'd still rather believe our knowledge and understanding is incomplete and our insight too shallow than give up and introduce something even more difficult to explain.
You see, if you want to rely on a Godlike being, eventually we're going to have to explain that. Exchanging one apparantly impossible thing with another just doesn't seem like good science to me
> I'm just a bit tired of the cultish "don't like it? build your own" thread that seems to permeate much of the open source community
:)
:)
:)
That is the way it works. The fact of the matter is that most people with the skills to actually develop such an interface don't have that particular itch to scratch.
> I'm also disappointed by the lack of original ideas, as reflected in the EMACS vs VI and Apache vs IIS wars
Ah, well, original ideas are few and far between everywhere in computing, not just open source. And a lot of those new ideas are in techy stuff most people couldn't care less about, and even most of THOSE aren't particularly new, just nobody bothered implimenting them
Apache used to have a pure prefork scheme for handling requests. Now it's a mix and match with various schemes, including one that allows seperate Apache processes to run as the user id of whoever owns a particular virtual host ([sound of 100,000 PHP weenies wetting their pants]). Does that count as an original idea? Probably not, but that's the sort of level that impresses most Apache users.
> Surely, it is possible that someone, someday, might build a better editor that either EMACS or vi
Sure. JEdit, NEdit, etc. I still prefer vim, but for a lot of people they would count, no?
Anyway, Emacs isn't an editor, it's a LISP interpreter with a bundled editor
> and surely it is possible that neither Apache or IIS represent the ultimate in web server technology.
There are plenty of alternatives (Roxen, thttpd, Jigsaw, Webrick, etc), and IIS and Apache are obviously still making big advances in their own scheme of things.
> Why can't the open source community generate sone truly innovative, easy to use, ideas
You might ask the same of any development community (websites, architecture, car design, commercial software vendors, etc). Finding one or the other may be fairly easy, finding both (aside from being doubly subjective) may prove more difficult. And finding one that's truely new will probably cut that down even more
> instead of rewriting the same old stuff
This is what humans are about. Get an idea, mix it about with other ideas, occasionally come up with a new idea. Repeat.
It just happens that the open source side of things tends to be from the perspective of a programmer, so..
> and castigating as "not terribly bright outsiders" those with the temerity to suggest that Computers Are Supposed To Be East To Use??
What's easy to use for you may not be easy to use for a programmer. What's easy for a sysadmin may not be easy for you either. Well, that's where most open source is targetted; if you dislike it, find something that is aimed at you, alter other software (or pay someone to do it) to make it more like what you want, or try commercial software which by and large is aimed at you.
Certainly, getting upset over the interface for various open source stuff not meeting your expectations won't get you very far unless you can make suggestions on how to change them in a way everyone can live with.
> Gonzalez writes: "The fact that the Sun's location is fine-tuned to permit the possibility of life [...] powerfully suggests divine design."
I can't resist pointing out that if the Sun wasn't in such a state, we wouldn't be here to talk about it.
On the other hand, if the Sun wasn't so tuned, and we WERE here and not all dieing of mass cancers or being frozen/boiled, I'd be much more inclined to believe that maybe there is some divine intervention there.
Since when is "write one and submit it" classed as ignoance? I understand the problem domain, I know how a good interface can improve matters. it just so happens the text file + vim + docs is a pretty optimal solution for me.
> Why shouldn't this stuff be easy to use?
Apache's config is very user friendly for it's target demographic. Concidering how flexible and complex Apache is, it's remarkably simple to set up.
> Why should soneone need to know how to construct regular expressions in order to run a web server?
They don't. If they want to do pattern matching to transform URI's or whatever, though, regexp is the only way to go. If you can think of a more user friendly way of matching arbitary strings, then quick! patent it!
> Why maintain the quarter-century old text-based UNIX interface as some kind of rite of passage that the Chosen Ones use to ward off the Heathen?
I'll be impressed if you can come up with a non-cluttered, stable, secure, lightweight config tool that can match even the standard Apache config, never mind the power of being able to bring any text processing language to bear on any problem.
> If open source is really about giving people choices, then give them more than one option.
Your choices:
I think that's plenty of choice, personally.
Lucky for you Apache comes with a KLIK install system. There's no particular reason they couldn't extend that to provide a bit more flexibility over the installed config.
Nor is there any particular reason the PHP team couldn't write an MSI that supported Apache. No need for yet another set of tools that don't really fit in with the Windows way of doing things (although I suppose apt works quite like Windows when dependencies get screwed up or the "registry" gets damaged *grin*).
> So why not put this argument to bed and just offer both as built-in support with apache?
Go write one suitable for production use, give it to the Apache Software Foundation, and I'm sure they'll be more than happy to bundle it, or at least provide it as a seperate subproject.