4 ms·

1998: https://www.linuxjournal.com/article/3012 https://www.linuxjournal.com/article/3012 > The Roxen Challenger HTTP Web Server is a marvel ahead of its time

1998: https://www.linuxjournal.com/article/3012 https://www.linuxjournal.com/article/3012 > The Roxen Challenger HTTP Web Server is a marvel ahead of its time. That's a bold, hard-to-prove statement for a web server when compared to the amazing success of the Apache HTTP Server. Before you stop reading, you should consider that there is nothing wrong with having two subtly different, yet very good tools.

WalterGR 4y ago
> you should consider that there is nothing wrong with having two subtly different, yet very good tools. It's amusing that this needs to be said when writing for a particular audience.
- nazgulsenpai 4y ago
  I don't follow; are you implying Linux users (the particular audience) don't like having multiple tools for specific use cases or that the author's statement goes without saying?
  - cschep 4y ago
    Often when there are two (or more) very good tools for a single task (e.g. editing text) there breaks out a Holy War, rather than people being happy for each other to use their preferred, each excellent in their own way, option. Seems to me this is what the parent comment is nodding to.
    - WalterGR 4y ago
      Precisely. Checking more recent comments, it looks like a Holy War has broken out over whether there should be Holy Wars. Priceless!
- IshKebab 4y ago
  Well it is wrong. There is something wrong with having two subtly (depending on how subtle it is) different tools. There's duplication of effort, community split, interoperability hassles (depending on the something), extra support burden if other people have to support both, etc. I don't think anyone would agree that having 110V, 220V, 50Hz and 60Hz is good. Or subtly different railway gauges. Or Windows and Unix style line endings. There are a couple of upsides too - increased competition, backup in case one project goes in a crazy direction, etc. But it's silly to pretend there's nothing bad about it. Though anyway in this case I think "a marvel ahead of its time" is not a "subtle difference".
  - em-bee 4y ago
    roxen and apache were not two subtly different tools, they were, and still are, miles apart. the way you use them and develop for them is completely different. roxen not only replaces apache but also perl, php or any other language that you develop your websites with. therefore roxen does not even compete with apache, but it also competes with laravel, django or rails. the fact that those later frameworks need apache to serve their content is rather incidental. rails was first released in 2004. django in 2005, laravel in 2011. i used roxen (and it's predecessor spinner) in 1994!! that's literally a decade earlier. i think the only possibly competing tool available at the time was cl-http in lisp[0]. (AIDA/Web for smalltalk was created in 1996, as was WebObjects, Java EE came in 1999. that's all i could find so far) [0]: at the time i was looking for a better alternative to the available ncsa and cern webservers. i remember ordering a student version or something like that of franz lisp so i could try it. and i was put off by having to write lisp code just to serve static files. that was what made me keep looking until i found spinner.
    - IshKebab 4y ago
      > roxen and apache were not two subtly different tools, they were, and still are, miles apart Yeah that's what I suspected (read to the end of my comment).
      - em-bee 4y ago
macintux 4y ago
I wasn’t trying to denigrate it: I was genuinely curious what it’s good or bad at. Every language has a reason to exist, although for many it’s simply because it can.
randallsquared 4y ago
Roxen was definitely far easier to use than Apache, but PHP was a second-class citizen on Roxen, and "Roxen including RXML and Pike" was directly competing with "Apache plus mod_php" (and/or ColdFusion? I never used that, so not sure) though I don't know that the creators understood that at that time. There were a number of contributions to Roxen's oblivion, to include RXML was a very high level XML-based scripting language, but you had to drop to Pike to do some things; PHP was a single language that was clunkier than Pike but didn't seem like two separate languages to learn. Since Roxen started so early, there was some terminological divergence already in 2000 between it and the rest of the webserver world. Roxen created a 2.x of the web server and RXML syntax that was notably nicer and more modern-seeming, but also much slower for some use cases, so some Roxen 1.x users resisted upgrading -- so much so that when the company gave up, the community-maintained Roxen, Caudium, was based on 1.x, not 2.x, even though 2.x had been out for many years. From the outside perspective, Roxen seemed to treat consulting or enterprise sales as its bread and butter, in which the webserver was a sort of force multiplier or secret sauce, which directly conflicted with a goal of growing the Roxen user community.
- em-bee 4y ago
  I don't know that the creators understood that at that time yes, this is right, this was not well understood. part of the problem was that the concept of web development frameworks was not established yet. later it would have been easier to say that roxen competes with frameworks such as django or rails, but at the time roxen was promoted as a webserver, and so people expected a drop-in replacement for apache. in fact, roxen might have done better if it had been using apache as a http protocol frontend. in a sense roxen/pike suffers the same challenge as smalltalk and lisp do today. you can do powerful things in those languages and environments, but they don't fit into the mold of what everyone else was doing. you kind of have to give up your existing ecosystem and start from scratch learning new tools and concepts. RXML was a very high level XML-based scripting language, but you had to drop to Pike to do some things; PHP was a single language that was clunkier than Pike but didn't seem like two separate languages to learn. i wouldn't see it that way. anyone who learned programming could see that html/xml/rxml was not a programming language but sophisticated markup. for some time there were two camps, those that wanted code and markup mixed in one file, and those that wanted to keep it separate. php favored the mixed approach and python went for the latter. roxen with pike also was firmly in the latter camp. however it seems that it took a while before the latter approach became more popular and by that time multiple alternatives such as python and ruby were available. Caudium, was based on 1.x, not 2.x, even though 2.x had been out for many years. i was part of that team. the primary issue was not performance, but compatibility. roxen 2 could not handle some of the more complex rxml people had created with roxen 1. the most notable reaction i remember that per hedbor, the primary developer of roxen, was disappointed that we had forked roxen 1 and not roxen 2. he was understandably and rightfully proud of his work. but unfortunately it took some time before roxen 2 was able to achieve enough compatibility with roxen 1 to make a lot of old rxml work in roxen 2. another notable detail is that the fork was lead by his very brother david. and for the curious, the name caudium came from us looking up the word "fork" in a latin dictionary. we didn't find a nice sounding translation, but there was this reference of a roman town near a river-fork whose name we all liked, so that is what we picked.

WalterGR 4y ago

> you should consider that there is nothing wrong with having two subtly different, yet very good tools. It's amusing that this needs to be said when writing for a particular audience.

nazgulsenpai 4y ago
I don't follow; are you implying Linux users (the particular audience) don't like having multiple tools for specific use cases or that the author's statement goes without saying?
- cschep 4y ago
  Often when there are two (or more) very good tools for a single task (e.g. editing text) there breaks out a Holy War, rather than people being happy for each other to use their preferred, each excellent in their own way, option. Seems to me this is what the parent comment is nodding to.
  - WalterGR 4y ago
    Precisely. Checking more recent comments, it looks like a Holy War has broken out over whether there should be Holy Wars. Priceless!
IshKebab 4y ago
Well it is wrong. There is something wrong with having two subtly (depending on how subtle it is) different tools. There's duplication of effort, community split, interoperability hassles (depending on the something), extra support burden if other people have to support both, etc. I don't think anyone would agree that having 110V, 220V, 50Hz and 60Hz is good. Or subtly different railway gauges. Or Windows and Unix style line endings. There are a couple of upsides too - increased competition, backup in case one project goes in a crazy direction, etc. But it's silly to pretend there's nothing bad about it. Though anyway in this case I think "a marvel ahead of its time" is not a "subtle difference".
- em-bee 4y ago
  roxen and apache were not two subtly different tools, they were, and still are, miles apart. the way you use them and develop for them is completely different. roxen not only replaces apache but also perl, php or any other language that you develop your websites with. therefore roxen does not even compete with apache, but it also competes with laravel, django or rails. the fact that those later frameworks need apache to serve their content is rather incidental. rails was first released in 2004. django in 2005, laravel in 2011. i used roxen (and it's predecessor spinner) in 1994!! that's literally a decade earlier. i think the only possibly competing tool available at the time was cl-http in lisp[0]. (AIDA/Web for smalltalk was created in 1996, as was WebObjects, Java EE came in 1999. that's all i could find so far) [0]: at the time i was looking for a better alternative to the available ncsa and cern webservers. i remember ordering a student version or something like that of franz lisp so i could try it. and i was put off by having to write lisp code just to serve static files. that was what made me keep looking until i found spinner.
  - IshKebab 4y ago
    > roxen and apache were not two subtly different tools, they were, and still are, miles apart Yeah that's what I suspected (read to the end of my comment).
    - em-bee 4y ago

macintux 4y ago

I wasn’t trying to denigrate it: I was genuinely curious what it’s good or bad at. Every language has a reason to exist, although for many it’s simply because it can.

randallsquared 4y ago

Roxen was definitely far easier to use than Apache, but PHP was a second-class citizen on Roxen, and "Roxen including RXML and Pike" was directly competing with "Apache plus mod_php" (and/or ColdFusion? I never used that, so not sure) though I don't know that the creators understood that at that time. There were a number of contributions to Roxen's oblivion, to include RXML was a very high level XML-based scripting language, but you had to drop to Pike to do some things; PHP was a single language that was clunkier than Pike but didn't seem like two separate languages to learn. Since Roxen started so early, there was some terminological divergence already in 2000 between it and the rest of the webserver world. Roxen created a 2.x of the web server and RXML syntax that was notably nicer and more modern-seeming, but also much slower for some use cases, so some Roxen 1.x users resisted upgrading -- so much so that when the company gave up, the community-maintained Roxen, Caudium, was based on 1.x, not 2.x, even though 2.x had been out for many years. From the outside perspective, Roxen seemed to treat consulting or enterprise sales as its bread and butter, in which the webserver was a sort of force multiplier or secret sauce, which directly conflicted with a goal of growing the Roxen user community.

em-bee 4y ago
I don't know that the creators understood that at that time yes, this is right, this was not well understood. part of the problem was that the concept of web development frameworks was not established yet. later it would have been easier to say that roxen competes with frameworks such as django or rails, but at the time roxen was promoted as a webserver, and so people expected a drop-in replacement for apache. in fact, roxen might have done better if it had been using apache as a http protocol frontend. in a sense roxen/pike suffers the same challenge as smalltalk and lisp do today. you can do powerful things in those languages and environments, but they don't fit into the mold of what everyone else was doing. you kind of have to give up your existing ecosystem and start from scratch learning new tools and concepts. RXML was a very high level XML-based scripting language, but you had to drop to Pike to do some things; PHP was a single language that was clunkier than Pike but didn't seem like two separate languages to learn. i wouldn't see it that way. anyone who learned programming could see that html/xml/rxml was not a programming language but sophisticated markup. for some time there were two camps, those that wanted code and markup mixed in one file, and those that wanted to keep it separate. php favored the mixed approach and python went for the latter. roxen with pike also was firmly in the latter camp. however it seems that it took a while before the latter approach became more popular and by that time multiple alternatives such as python and ruby were available. Caudium, was based on 1.x, not 2.x, even though 2.x had been out for many years. i was part of that team. the primary issue was not performance, but compatibility. roxen 2 could not handle some of the more complex rxml people had created with roxen 1. the most notable reaction i remember that per hedbor, the primary developer of roxen, was disappointed that we had forked roxen 1 and not roxen 2. he was understandably and rightfully proud of his work. but unfortunately it took some time before roxen 2 was able to achieve enough compatibility with roxen 1 to make a lot of old rxml work in roxen 2. another notable detail is that the fork was lead by his very brother david. and for the curious, the name caudium came from us looking up the word "fork" in a latin dictionary. we didn't find a nice sounding translation, but there was this reference of a roman town near a river-fork whose name we all liked, so that is what we picked.