Requirements for RunUO on Linux

[RavonTUS]

Requirements for RunUO on Linux

Greetings,

I am glad to see such a following of people trying to get RunUO to work on Linux. In response to so many questions, here is the "Ravon" version of requirements to get this to work.

Linux - I am a kubuntu 7.04 junky so that's the one I suggest (BSD is not Linux).
Mono v1.2.5 or better
SVN 259 or better (Do not use RC1)
Wine 0.9.46 or better
UO ML v6.0.2 or better (installed on the server)

If you do not have these minimum requirements, it will not work and you will get error messages.

Use two computers. One for the server and one for the UO client.

To run the UO client for testing, the only thing I have found to work is UORice and modifing the logon.cfg file.

-Ravon

 

[panther]

Wine? What would someone need Wine for?

 

[floppydisc]

Probably to install UO. A client can always be useful to have (at least if you need the mul files).
On the other hand, a client shouldn't be on a server ... a server should not even have X running ;-)

 

[RavonTUS]

Wine? What would someone need Wine for?

You need Wine to install UO. You need UO to patch and update the mul files.

-Ravon

 

[Courageous]

You need Wine to install UO. You need UO to patch and update the mul files.

Your alternative, if a LAN is present, is to cross mount the drives from a windows box. On the windows box, you would update the ordinary way, and the linux box would automatically "see" the updates. You could also do the same thing with VMWare and a "real" windows installation.

C//

 

[floppydisc]

Your alternative, if a LAN is present, is to cross mount the drives from a windows box. On the windows box, you would update the ordinary way, and the linux box would automatically "see" the updates. You could also do the same thing with VMWare and a "real" windows installation.

C//

I wouldn't recommend this. RunUO went through hell to implement platform specific (unsafe) read and write operations to speed up file access. That would totally go to waste if it was a network filesystem which is limited by network speed and the overhead of the connection itself. Ofcourse one could still sync the files manually - update the windows box and then copy over the new mul files.

 

[RavonTUS]

Your alternative, if a LAN is present, is to cross mount the drives from a windows box. On the windows box, you would update the ordinary way, and the linux box would automatically "see" the updates. You could also do the same thing with VMWare and a "real" windows installation.

C//

Agh, Windows.

-Ravon

 

[osi_layer8]

I wouldn't recommend this. RunUO went through hell to implement platform specific (unsafe) read and write operations to speed up file access. That would totally go to waste if it was a network filesystem which is limited by network speed and the overhead of the connection itself. Ofcourse one could still sync the files manually - update the windows box and then copy over the new mul files.

I do this on my test shard, but the runuo filesystem is local, I just mount it on my work computer to do edits. In VMware there is some overhead to save times, so I would not recommend this for a production environment. But its fine for a test one.

 

[Courageous]

I wouldn't recommend this. RunUO went through hell to implement platform specific (unsafe) read and write operations to speed up file access. That would totally go to waste if it was a network filesystem which is limited by network speed and the overhead of the connection itself. Ofcourse one could still sync the files manually - update the windows box and then copy over the new mul files.

Ah. A fair point. Rather, one should cross mount the linux drives to windows.

 

[Courageous]

I do this on my test shard, but the runuo filesystem is local, I just mount it on my work computer to do edits. In VMware there is some overhead to save times, so I would not recommend this for a production environment. But its fine for a test one.

Well, sure. Running a runuo server in virtualization wasn't what I was saying though. Rather, the Windows system to do the patching of the UO client files could be virtualized.

In other news, ESX 3.5 is now supporting paravirtualization. This will take virtualization overhead to effectively nil. Not relevant here, of course, unless you have a few grand. But useful if you're into data centers...

C//

 

[RavonTUS]

Greetings,

I am currently using VMware on a Kubuntu box, with both XP & Kubuntu. It allows me to switch back and forth for testing. I do have the client and server on both OS's.

Production Server runs on the XP side and the test server runs on the Linux side.

P4 HT 3.0GHz
2G Ram
60G HD (Kinda small)
Kubuntu 7.4 wtih VMware 1.3

-Ravon