Kindling

Voted 'other', I use Funtoo. FreeBSD is great, though it should really be counted as Fedora 10 if you use linux_base - otherwise it's whatever distro you installed.

mons00n, that's a known error. Keep track of the missions it's caused on and let the devs know. JayC's pretty much spot on on the fact that you can't simply 'upgrade glibc'. I'd add that the reasoning behind this - aside from required library updates - is likely that this means less work will need to be done when ARMA II: CO approaches EOL. As it was, the linked glibc wouldn't have survived the next few years - you would have been unable to run the server application on current Linux distro installations. It's a good, forward-thinking move that will allow admins to host ARMA II servers well into the future. Not to mention the fact that you should probably upgrade soon anyway, if not for the features then for the new stability and security fixes that are always being introduced. It's entirely possible to use a chroot. I wouldn't suggest using LD_PRELOAD or similar unless you're fairly experienced, as you'd need to build pretty much all of the deps for the server app with a new, seperate glibc ontop of staying up-to-date with security fixes. Bulding libc and libstd++ is generally a task reserved for distro maintainers or source-based distro users who tend to be more experienced with these matters.

Indeed, don't try to host a production server with it - it is, after all, an alpha. Purely for testing.

Hence why it clearly says 'alpha'. It's in no way a production-quality build. Provide your crash dumps so the dev team can fix the issues :) peppe, personally I'd install 64bit/multiarch but if you're just running the ARMA II server there should be no real difference. I'd really also suggest going for Fedora or Debian Wheezy over CentOS for now as several people have claimed that the CentOS glibc builds are out of date and can't run the server application.

The server is 32bit, it requires 32bit libraries (eg. on an amd64 system you must be multiarch, read readme.txt).

Just a heads up - the latest Linux server alpha version requires a new glibc, which may not be included in Debian Stable or CentOS 6.2 and below (?), might be time to upgrade your distros.

Are you sure you were checking the strings in the correct file? Perhaps it's in /usr/glibc or /usr/lib for you? Remember you're checking the 32bit library. Try 'grep GLIBC' instead - you should get a list of versions. Make sure to check strings on libstdc++.so.6, not .so.5. The best way to track the crashes is to run the server under screen - that way you get all the output to the terminal but you can still detach if needed. There are several known issues already with this build, though. It is, of course, rushed at the behest of us Linux admins :) And peppe, may need to yum install libstdc++ or similar. JayC, this is a very common issue at the moment :) pchaxor, you're going to need to update whether you like it or not - it's compiled with a new version of glibc, anything older simply will not work and upgrading glibc and libstdc++ when your userland is linked to the older version is practically server suicide. There are ways to upgrade without rebooting, if that's too much hassle for you - look up installing distros via chroot. Trust me, better the server is updated for new libs now than not having the time to after ARMA 2's release cycle (in the days of ARMA 3) and nobody being able to run a Linux binary server after distros catch up.

Since you guys are who you are, I would quite happily help you with that. I've had fun on 15thmeu servers. Maybe we can work something out that won't require a full disk reinstall - message me with contact info if you're interested.

To find out if you can run it with your current system: Find in /usr/lib32 (on multiarch) or /usr/lib (32bit) the file 'libstdc++.so.6 locate libstdc++.so.6 | grep /usr/lib For an example, let's say we found /usr/lib32/libstdc++.so.6 strings /usr/lib32/libstdc++.so.6 | grep GLIBCXX_3.4.15 | wc -l If the above command returns '1' (or more), your current distro should support it. If not, time to upgrade :)

Wow, that's pretty strange. It looks like the game is missing all the assets, strings, models etc. - my guess is that you're launching a shortcut with an incorrect working directory, or launching the exe with no working directory. Try this: click 'Configure' in PlayOnLinux, choose your prefix from the list and select Miscellaneous tab and 'Open Shell'. Use cd 'Program\ Files\ \(x86\)/Steam/steamapps/common/arma\ 2\ operation\ arrowhead' or similar to navigate to the actual ARMA 2 OA folder and then start the game manually from there using 'wine Expansion/beta/arma2oa.exe' - not sure if it'll start up in full CO mode, but it'll be good just to check if that's the problem. I use a bash script to basically automate these commands to start the beta, renaming the batch script that Steam includes with OA doesn't work for me.

It's actually pretty easy just to run a backup to an external file server, add a new disk or resize a non-core partition to make room for CentOS 6 or a different distro, install via chroot method and point your bootloader to the new kernel. Then you simply resize/delete/move files and partitions around until you have a full CentOS 6 system - you may not even need to do this if you store everything custom in /home and /usr/local partitions as convention holds :) Or you could hire somebody to do it if you're not comfortable with that. By the way, there's no guarantee that CentOS 6 is up to date enough with libc and libstdc++. Additionally, any debian stable users will need to migrate to testing (wheezy). Most recent Ubuntu versions should work just fine (Ubuntu is based on Debian Sid (unstable)) EDIT: Imago, read readme.txt - looks like your folder variables in arma2oaserver script are wrong. :) Make sure you direct it to the correct ARMA 2 OA folder.

And in the mean time, there's a script here to install a headless version of WINE on a Debian, Ubuntu or CentOS dedicated server to run the Windows application.

I'm using Funtoo at the moment. It's very fast and light but requires quite a lot of Linux knowledge and configuration. Debian stable is good for a production server, so is Fedora (a minimum install, anyway) as it's a little more up to date. CentOS is probably the most stable distro, but it's also the most behind with package versions. Ubuntu Server is easy to manage but isn't particularly light. Really it's down to personal preference as I doubt there's a massive speed difference even between binary and source based distros.

I hope that BiS follows Valve and others by looking to migrate to Linux, too :) That said, Ouya and similar systems may not necessarily have the throughput and a suitable architecture to run the ARMA II or III engine - these devices are made for very different workloads. It could be difficult to adapt ARMA II to such devices because of these differences, especially AI and rendering. Another issue is the user interface - it would need a LOT of work to adapt the UI to something comfortable to use on a console, or even a tablet or phone. Technologically, I think it's possible. But is there really such a big milsim market on consoles, phones and tablets? I doubt it. Maybe we should just all look for a Linux Desktop port. This would increase portability to pretty much any x86 system without having to look at adapting to ARM or console.

Sounds good! Though I have to say, if you're wanting the best performance from a VM I'd choose Xen or KVM (or OpenVZ for absolutely highest performance, though it's not true virtualization since it uses the host's kernel and requires a Linux host) over VirtualBox. They've got much better kernel modules for disks as well as the ability to assign different processor architectures and dynamically allocate memory. Xen and KVM (to a lesser extent) can even pass devices through directly to the VM, eg. a NIC or GFX card.

Absolutely! Though I tend to go -O2 & march=native on production servers, perhaps with fstack-protector and similar hardening flags before they were mainlined in most distros. -O3 can cause hell on production servers :) Mobility is not so important, most of the time - if it's for my phone or other embedded systems, I'd generally use -Os and distcc with generic march to save time and space, though. Hope you find the script helpful :) EDIT: Updated script again, it creates a check script that can be used to automatically restart the ARMA II server if it crashes via cron. More info at the end of the script.

Ah, but VirtualBox is emulation - WINE is a library. There's a big performance difference between these two architectures as WINE is more of a translator than an emulator (VirtualBox emulates a whole system, including hardware, WINE simply converts Windows API calls to Linux ones).

Updated the server installation script - added CentOS and lots of failsafe stuff, if it doesn't work it should at least tell you where it failed (in which case you can ask for help here :)). Also removed the old precompiled WINE and added a mini-guide for installing ARMA II through PlayOnLinux - it'd be great if somebody could bash together a POL script to make things easy, but if not I'll probably do so soon.

I use [Gen|Fun]too or Slackware myself for most tasks. :) [Gen|Fun]too's very good for servers when you want maximum speed (everything is compiled into native code for your processor) as well as minimum overhead (default installation is more minimal than Debian or CentOS). You can also set up your own repositories, where you can slipstream patches and tweaks into your system. My favourite part has to be package management, though - you simply state the features you'd like on your system using USE flags (eg. 'perl' will get all the perl bindings, 'gtk' will give you a gtk GUI interface, 'tls' will give you https access or modules) either per-package or system-wide, and your whole system will pretty much grow out of this - grabbing any dependency needed and configuring it to be as minimal as possible as you choose extra packages. And Slackware is great for rapid deployment of a secure, stable and minimal system. Package management is all done manually, but it means you need to plan your systemand choose what core packages you need beforehand - a good habit to get into. Downloading CentOS now. :)

The only way to get the beta running on a Linux dedicated server at the moment is via WINE. It's that or wait for the 1.62 Linux server to be released. :)

Just about to head out, but I should be able to get that done for you tomorrow. :) I'll need to get a CentOS VM up and running - the difficulty will be in getting everything up-to-date, CentOS lags behind other distros quite a bit with package versions.

Sure, I'm speaking only on licensing - Linux (as in the kernel) is GPLv2 and is most often distributed with a GNU (also GPL) userland. That said, many GNU guys do contribute to the kernel code, as do many corporations (including MS as the recent 'B16B00B5' tabloid-style fiasco highlights). It is interesting to see that Stallman is conceding a little more than usual to Valve - 'My guess is that the direct good effect will be bigger than the direct harm'. Pretty interesting, considering Stallman's general hostility towards non-GPL developers and especially DRM - he seems to be suggesting that it's a lesser evil considering the beneficial effect of bringing more people to Linux. The great thing about Linux, and all GPL-, MIT- and BSD-licensed applications, is that the more people use them, the more people will want to develop them. A steady stream of interest is the best thing for all Linux distributions and applications at the moment.

It all depends on the dependencies of the WINE package in that PPA - if it depends on more data, it has a higher footprint. If not, it has a lower footprint. :)

Personally, I'm more of a simplified BSD license guy as it provides the original developers, derivitive developers and the users with the maximum amount of power and freedom but the GNU guys have always been an important counterbalance to corporations and companies such as Microsoft. :) Of course, this isn't an unexpected direction for MS - Bill Gates (and now Microsoft) has always sold software licenses, not the software itself, and has always been criticized for anticompetitive and outright manipulative monopolizing behaviour. Bill Gates is making it up in humanitarian ways, but I doubt that every Director on Microsoft's board is doing the same.

Considering the disturbing directions Microsoft are taking with Windows 8 and the fact that Valve are throwing developers at Linux, finding bugs in the kernel and even Blizzard agreeing with GabeN that it may be time to move to Linux, it's truly a futureproof move. :) All BiS would really need to worry about is migrating from DirectX to Open[GL|AL|CL] (non-library could code likely be ported almost directly). It would be a big task, of course, but it could end with several performance benefits and 2 new markets (Windows and Mac). Looking at the results of Humble Indie Bundle-like 'pay-what-you-want' sales, you can see that Linux users are certainly not cheap by any means - we're not spoiled by free games :). Maybe not something that will happen with ARMA II. But a massive turn for ARMA 3? We can only hope!