POL and Linux

[ncrsn]

I know there are some pollers on penguin already, so tell me, and others interested...

What there is to think about before trying to run POL on Linux? How possible it really is?

First of all, I'm thinking, what distribution should be used - Gentoo is well supported, I quess, but does that mean using another one, like popular Ubuntu or Red Hat, is a path to failure? What are you using, and what it took to get it to work?

Second issue is, should something be noted if someone is moving scriptbase from Windows platform? Are there OS specific things which may cause problems, and how to overcome them? Is e.g. case sensitivity a thing to think about scriptwise, maybe by using ReadConfigFile("itemdesc") instead of ":PACKAGE:ITEMDESC"?

And what about core bugs and features: anything specific that affects only one OS (note, this could of course work for the benefit of Linux, although I happen to think things could only be worse)?

Last question from my side for now, if you have tried using POL on Linux, what are you overall feelings, was it worth it?

Of course, free discussion is allowed concerning this matter, I just threw some very first questions to think about. And don't you worry, even if no-one answers or supports the Linux and POL combo, I'm going to try it out. Only sooner and more succesfully if supported.

[Pierce]

With the exception of case sensitivity there is normally no difference between Linux and Windows core.
Our live Pol 97 shard runs under debian linux (Etch (4.0)) and I personally run the same server scripts - which means the same Pol 97 test core with the same script base - under windows for development. I even compile these scripts under windows and upload the windows compiled .ecl files to the linux server for security reasons.
My experience is simple: If your script base follows the unix/linux case sensitivity rules you'll have no problems

There are only small things you perhaps have to change, like e.g. Multithread=1 in pol.cfg, which is for linux only.

So the main thing you should take care off is that e.g. "include "include/YesNo";" leads to an include file named YesNo.inc and not yesno.inc

[AxelDominatoR]

I always ran POL under linux in about 5 years or more and it's rock solid.
I find it easier to run it if resident in a remote server ( the StartHere.sh script can be run from a screen terminal ).

Oh, I'm updating the StartHere.sh to accomodate more and more functions ( it will have the same functionality as the POL Launcher Austin is coding ), so it should be trivial to start up a linux server.

[Austin]

Yeah we're trying to make POL easier than an East-County, San Diego girl!

I always ran POL under linux in about 5 years or more and it's rock solid.
I find it easier to run it if resident in a remote server ( the StartHere.sh script can be run from a screen terminal ).

Oh, I'm updating the StartHere.sh to accomodate more and more functions ( it will have the same functionality as the POL Launcher Austin is coding ), so it should be trivial to start up a linux server.

[phao]

On High Loads (and the definition of high load will depend on the hardware of the machine), a linux server will acts better than a windows one.

Filenames on linux are case-sensitive

IMO, compiling scripts is better on linux (I'm talking about the way you do it, typing commands, etc). As it's common doing everything from the command line on Linux, it was not a problem to use Ecompile there, there is a better feelling on an unix command line than on a windows command line (command prompt). On Windows I do not use command line, I've added a item on the context menu, so I can compile without going to the command line.

I don't use linux here right now, I'm on windows, and I do that because I don't want to emulate UO on wine.

There is another point. I was emulating UO on linux sometime ago (Slackware 11) and running POL. It seems to be faster than it is on Windows. I remember not getting my UO slowing down because of POL (as It happens on windows).

Well, I preffer the .bat starthere than the .sh one.

[AxelDominatoR]

StartHere.sh just updated Try the new version.

Oh, and if you prefer the .bat version, could you please point up why? Any suggestion is always appreciated

[phao]

I don't like prompting on linux (it's a way of use issue)

On windows it's just normal, but not on linux (I think).

I'd like something like this.

./starthere -d # start pol
./starthere -bd # ecompile all to ecompile.log
./starthere -ad # build all config file, from realmgen
./starthere -aeb # build brit UOML realm

I mean, i'm just accostumed doing stuff like this on linux.

It's enough having just the shell as interactive. I don't like much prompting.

But it's a way of use issue, on windows I don't see a problem on prompting hehe.

If you're going to implement something like this, I recommend using a more intuitive option names, like -o to open poll, -c to compile scripts, like:

./starthere -c all

Also, output everything to stdout.. let people redirect if they want

./starthere -c all >~/compile.log 2>&1

That is up to you, I just think when you're developing things for linux, just try to think "which way of using suits better here?" and try to pickup something based on the more simpler(in the unix way of simple)/practical ones.

There is a situation where I "like" prompting. And it's while configuring something, for example, you may write a configurator for ecompile.cfg, doing that without prompting wouldn't be that great IMO. I think prompting is a good Idead while writing configurators.

That happens, because configuration files are text files. Writing in the configurator is better than writing directly into the file (you may commit some mistakes writing by hand).

That doesn't happen when "performing an action".

You could do configurators (that prompts) for pol.cfg, servers.cfg, ecompile.cfg, etc, using prompt, but to starthere, which is mainly a "executer", prompting is not a good idea.

That is all my opinions on that.

[Eros]

Taking the matter POL and LINUX, the archives .ecl of POL are binaries?

If so, my server on Linux, I could convert on my PC and play in the WIN .ecl for LIN?

[Luth]

Someone can correct me if I'm wrong, but I always interpreted ECL to stand for eScript's Compiled Language, a server-parsable binary file that is not platform dependent. An ECL compiled on Windows works fine on Linux.

[AxelDominatoR]

Hi all, just back from a four-day vacation!

I don't like prompting on linux (it's a way of use issue)

I half-agree with you.

I love *nix tools because of the simplicity and the capability ( like being used in a script or their output being piped ), but having a sort of control panel where you can watch the status of the server ( latest linux starthere will have different colors on menu items if there's something wrong or all is good and nice ) can be really useful, too.

There is a situation where I "like" prompting. And it's while configuring something, for example, you may write a configurator for ecompile.cfg, doing that without prompting wouldn't be that great IMO. I think prompting is a good Idead while writing configurators.

Ok, now my proposal. I can split the script in two frontends, the functions being absolutely the same and included in a separate file. A frontend is the interface I'm actually trying to develop, with interactive configurators and such. The other is a command-line wrapper that will simply call the function, like: "./polcontrol -a".

What do you think? I can make this type of script in no time, the functions being shared with the other.

[ncrsn]

Thank you all for your tips.

I got it working with almost no problem at all. It will still take a while to ensure every important letter's case is correct, but, I'm sure it'll work out. It's nice to have a support for GNU/Linux on POL, keep it up.

--

AxelDominatoR: I am still to really try the tool you made, since I already had an old filebase to build on and didn't need it yet, but when it comes to using it, I somewhat agree with Phao: if possible, it would be useful to have also a "./polcontrol -abc" support. Newcomers, I'm sure, will appreciate if they don't have to read manual to get to use the tool, so better support both methods, eh?

[phao]

Hi all, just back from a four-day vacation!

I don't like prompting on linux (it's a way of use issue)

I half-agree with you.

I love *nix tools because of the simplicity and the capability ( like being used in a script or their output being piped ), but having a sort of control panel where you can watch the status of the server ( latest linux starthere will have different colors on menu items if there's something wrong or all is good and nice ) can be really useful, too.

There is a situation where I "like" prompting. And it's while configuring something, for example, you may write a configurator for ecompile.cfg, doing that without prompting wouldn't be that great IMO. I think prompting is a good Idead while writing configurators.

Ok, now my proposal. I can split the script in two frontends, the functions being absolutely the same and included in a separate file. A frontend is the interface I'm actually trying to develop, with interactive configurators and such. The other is a command-line wrapper that will simply call the function, like: "./polcontrol -a".

What do you think? I can make this type of script in no time, the functions being shared with the other.

Well, hehe, do it then.

The good of what i've understood you're going to do is that you can just use the basic command line tools to make whatever you want to do.

So for example you have a set of tools to configure POL, then you can make a script that prompts for information and just call those commands, and you can do the same using a GUI.

That is.. Doing that you can just re-use the command line tools you've made.

In windows, austim re-made the software, he couldn't re-use what he have done, and surely this wont happen with you.

[Yukiko]

Someone can correct me if I'm wrong, but I always interpreted ECL to stand for eScript's Compiled Language, a server-parsable binary file that is not platform dependent. An ECL compiled on Windows works fine on Linux.

Yep.

They are platform independent and should run under POL on Linux and Windows.

Not sure about the meaning of ECL although I think you are right there too or maybe it stands for "Eric's Cool Language".
*grins*