The Other Linux Thread

[skeevy]

The first thing you need to do is go and read the first page of the Unmodded Linux Thread. And I mean the entire first page of that thread. It contains a lot of good general information for KSP on Linux.

One thing the Unmodded Thread doesn't go into very well is your choice of disto, kernels, desktop environments, Steam quirks, and more. There are literally hundreds and hundreds of different Linux distors to choose from*; all with different window managers, desktop environments, ease-of-use for noobs, style of update, rolling or non-rolling release, and more.

*though in reality, there's only about 20 or 30 worth a crap ones; the rest are just clones, respins, or for very specific tasks; think email server, forensics, hacking, compiling code, media servers, HTPC, etc

So which distro is best for KSP?

Honestly, that's a hard question to answer. IMHO, the choice varies by your graphics hardware. If you have an Nvidia GPU, you can pretty much install whatever distro you're comfortable with because you'll have to use the Nvidia proprietary driver. If you have an Intel GPU, you need to be running a bleeding edge distro so you'll be able to use the updated software and drivers. If you have an AMD GPU, you actually have some choices -- you can pick whatever and go with the Catalyst Proprietary drivers or go bleeding-edge and use the Radeon Open Source driver. It should be noted that AMD plans to use the Radeon driver (renamed to amdgpu) as the base for both the free and Catalyst drivers within the next year.

Another thing to consider when picking your distro is if it's a rolling release or not. If you don't know, a rolling release distro is install once and as long as you keep is updated, you're always up-to-date. Non-rolling releases distros, like Ubuntu and Debain, will require you to either install a new version every so often** or for you to do a risky upgrade process that might potentially break the system (especially risky if you tweak a lot of stuff). Both styles have their respective pros and cons. For Rolling, the pros are always being up-to-date while the cons are one of those updates might break something. For Non-Rolling, the pros are you know you're running a stable system while the cons are you'll soon be out of date and you'll eventually have to reinstall or do an upgrade.

**every 6 months in Ubuntu's case; up to years for Debian (Debian Stable, while stable, is usually really out of date...you really don't want Debian Stable as a gamer's OS, IMHO)

Whatever Distros -- Ubuntu 14.04 (LTS), Mint 17, Debian Stable, SUSE, Fedora (all non-rolling)

More Up-To-Date -- Ubuntu 14.10, Debian Testing, Manjaro***, Debian Sid, Siduction (all rolling except Ubuntu)

Bleeding Edge -- Arch, Gentoo, Funtoo, Sabayon (all rolling)

***that's the distro I use

I recommend Manjaro. While it might not be the most noob friendly, it's just as easy to install as Ubuntu, and once configured, just as easy to maintain. With the way Manjaro is setup, it's really easy to change between the free and proprietary drivers (hint, hint AMD GPU users). Manjaro is also a hybrid rolling/non-rolling release. What Manjaro does is they snapshot the Arch Linux repos and call that Unstable, do some fixes called Testing****, do any other fixes and call that Stable. Manjaro gives you the bleeding edge of Arch Linux with scrutiny and fixes. If you've ever ran Arch, did a "pacman -Syu", and broke your system, you'll understand and appreciate that. You also have access to Arch's AUR (to an extent...do not use the graphics drivers or the kernels with proprietary drivers) which is access to almost every piece of Linux software available. Manjaro isn't all fun and games. It does require some terminal fixes from time to time (just check the Manjaro forums, you'll find the fix usually). On my first boot, my system was semi-broke and I had to do a bit of searching to fix it; all I had to run was "pacman -Syyuu" and reboot, but if ya didn't know what to search for or weren't used to Linux, something like that can really discourage further use and scare a new user off.

After Manjaro, my recommendations would be Debian Testing, Fedora, or Ubuntu 14.10 with the Xorg-Edgers PPA...actually, all Ubuntu users, regardless of version, that are primarily running Linux just to play KSP should be using the Xorg-Edgers PPA, especially Intel, Nvidia Proprietary, Radeon driver users...not as much if you use AMD's Catalyst driver. Siduction (a distro based on Debian Sid) is also a decent choice to use, but like Manjaro, might require the terminal from time to time.

Out of all the rest I listed above, they're good distros, but they come with steep learning curves and aren't recommended for new users to start with. Once some experience is gained and you have some free time, give Arch or one of the Too's a shot. You'll learn a lot starting with a terminal-only minimal system, configuring everything by hand, and building your system from the ground up.

To Steam or Not to Steam? That is the Question.

By that, I simply mean to launch KSP from within Steam, to run KSP from a script, or directly ran from the executable. For most of ya'll, you're going to want to run KSP with a script. Why? Because Steam uses old Ubuntu 12 libraries and KSP likes up-to-date libraries. Those old libraries are why so many Linux Steam KSPers post help questions. One exception to this is with Manjaro & Arch Linux's Steam-Native package that replaces the Ubuntu libraries with symlinks to your system libraries; which allows you to run KSP with Steam using your native system libraries versus using the old Ubuntu libs. Skip to the end of the post for my personal launch script.

Kernels

Just like the distro and KSP, this also depends on your GPU. Intel and Radeon users really want the most up-to-date kernel their distro supports so you'll be using the most up-to-date graphics driver for your respective GPU. Nvidia users, like stated above, you're locked into using the proprietary driver and therefore your choice of kernel isn't as much of a factor, still, newer shouldn't hurt. Regardless of your GPU, don't pick a low latency kernel. They're not the best for gaming and you might even lose some FPS if you pick one.

Desktop Environment

This is one of those "you should pick this yourself" things. But for gaming, you're going to want a DE like XFCE, LXQT, LXDE, & Enlightenment. With any of those, you'll be using less resources for the base system which means more resources for KSP and your games to use. Of the four, my personal favorites are XFCE and Enlightenment. There are even lighter options, but frankly, unless you pick a distro like Manjaro Openbox Edition or Arch Bang, you'll be in for a steep learning curve and you'll have to set up almost everything by hand. There are other popular desktops like KDE, Gnome, and Unity, but desktops like that use a lot of resources that you'd rather have for KSP. If you have a quad core or better CPU and 8GB or more of ram, you can pick whatever you want. If you have less that that, you'll be screwing yourself unless you pick a lightweight option. I have a quad-core with 8GB of ram, I run XFCE and Enlightenment (I swap between the two every few boots for a change of scenery).

With all the choices there are, a basic intro to Linux with a focus on KSP should be helpful to a newcomer. I just hope this gives a new user an idea of what to look for in a distro and why you might want to use a respin like LxUbuntu over Ubuntu or something more up-to-date like Manjaro, Arch, or Sid.

Start-up Scripts

For Quad Core PC's

#!/bin/sh

export LC_ALL=C 
export LD_PRELOAD="libpthread.so.0 libGL.so.1"
export __GL_THREADED_OPTIMIZATIONS=1
exec taskset -c 2-3 ./KSP.x86_64

For Single Core PC's

#!/bin/sh

export LC_ALL=C 
export LD_PRELOAD="libpthread.so.0 libGL.so.1"
export __GL_THREADED_OPTIMIZATIONS=1
./KSP.x86_64

To use these, create a blank document in your KSP directory named "ksp.sh" (don't use the quotation marks " " dammit). Copy and Paste the above into it and save. Next, mark it as executable, either by ticking the right tick-box in the right click properties menu or by opening a terminal to your KSP directory and using this command "chmod +x ./ksp.sh" (again, don't use the quotation marks). Now all ya have to do us just double click that script to play KSP.

If you notice, the only difference between those is "exec taskset -c 2-3". What that little snip does is tell KSP to use the 3rd and 4th CPU cores (0=1, 1=2, so on and so forth). If you have an 8 core, you could use "-c 6-7" to use cores 7 through 8 or "-c 3-7" to use cores 4 through 8. Run "man taskset" for more information. Currently, KSP only benefits when forced down to two cores. The script above uses those two cores because they run the lightest when nothing else is going on on my PC. Your results may vary, but any two cores other than the main/1st core is better than not doing anything at all.

Note for Intel users. I don't have an Intel GPU to test the LD_PRELOAD and export __GL_ commands. Those are helpful for Nvidia users and they've never given me negative performance with either the Radeon or Catalyst drivers with my AMD R7 260x. If you have issues, remove those two lines. If those issues still persist, you need an actual GPU or start praying that Intel makes you a decent driver (that's a wish in one hand, poo in the other situation).

Post here if you need some Linux specific help and you run a modded KSP.

I'll be updating posts 2 & 3 as more questions come in and fixes are found.

Edited November 4, 2014 by skeevy

[skeevy]

[Reserved for skeevy by sal-vager]

Edited October 28, 2014 by sal_vager

[skeevy]

[Reserved for skeevy by sal_vager]

Edited October 28, 2014 by sal_vager

[John FX]

Cool. Just posting to bump and say that I have decided to bite the bullet and make a USB flash drive to boot from that will boot up into Linux just to play KSP 64 on. I`ve downloaded UBUNTU and it seems fairly basic to set up the flash drive and install Linux onto it.

I`ve never used Linux so I expect a harsh learning curve...

EDIT : Downloaded Ununtu, not debian like I originally said in error...

Edited November 2, 2014 by John FX

[micha]

... I`ve downloaded Debian and it seems fairly basic to set up the flash drive and install Linux onto it.

I`ve never used Linux so I expect a harsh learning curve...

Debian is not the easiest distro to get started with, but IMHO balances configurability (you can start with a very tiny core) with reasonable usability quite well. It's the distro I use for my servers as well as desktops. The main annoyance is that the default repositories do NOT include any "non-free" (ie, closed source, commercial, or otherwise restricted by license) applications, so it's not as complete "out-of-the-box" as various others are, but there's comprehensive HOWTO's for pretty much everything (eg, search for "Debian HOWTO nvidia driver").

I would also strongly suggest you select one of the tiny Desktops (LXDE, XFCE, etc) instead of a full-blown one (Gnome/KDE) if this is mainly for KSP - you'll get -heaps- of extra memory and speed out of your machine, as well as saving some space on your USB stick. Personally I like WindowMaker, but that's not a very familiar interface to one coming from Windows.

One major adjustment if coming from another platform is that 99.9% of all programs are not installed by going to a website, downloading, and running an installer, but rather through the package management system. There's GUI tools as well, but you'll likely want to have a play with "apt" and "aptitude" on the command line - the latter gives you a rudimentary text-based GUI if run without any arguments.

Most of all: Have fun!

[skeevy]

Cool. Just posting to bump and say that I have decided to bite the bullet and make a USB flash drive to boot from that will boot up into Linux just to play KSP 64 on. I`ve downloaded Debian and it seems fairly basic to set up the flash drive and install Linux onto it.

I`ve never used Linux so I expect a harsh learning curve...

I just updated the OP with nothing but distro specific information geared towards playing KSP. As a long time Debian user (over 12 years on and off), I do not recommend Debian Stable as a platform to play games on. Debian has a tendency to become really out of date, and with games, you want to be as up-to-date as you're comfortable with or as possible (there is a difference). If you really want to use Debian, use Debian Testing or Siduction. If you run either of those and you see a lot of stuff needing to be updated when you do an "apt-get update && apt-get upgrade", stop what you're doing, go to the forums, and check to see if anybody else is having update issues, else you might reboot into a terminal and have to figure out what broke by checking logs or searching for the fix with a smartphone....and it sucks having to transfer commands from a phone over to a terminal (ssh and copy/paste are your friends).

My recommendation and current OS is Manjaro (XFCE, Openbox, or Enlightenment editions if you have a dual-core or less cpu and/or under 8GB of ram). IMHO, it's the best there is for a middle ground between stability, bleeding-edge, ease-of-use, and gaming. Plenty of other distros do 1 of those 4 better, not many can pull off all 4 decently.

[Fail-Man 3D]

When managing lots of mods, unionfs-fuse* is your friend.

Example unionfs-fuse mount script for 0.24.2

The above-linked script works with the following directory structure, but can be easily modified to work with whatever structure you want.

(Note that you can't have unionfs-fuse write to its mountpoint, attempting to do so will get the FS stuck in an infinite loop)

KSP prefix (the directory where everything lives)
	ââ€Å“ââ€â‚¬ app-templates # KSP as extracted from the zip file, renamed from KSP_linux to KSP_linux_VersionNumber
	ââ€â€š	ââ€Å“ââ€â‚¬ KSP_linux_0.24.2 # contents not listed
	ââ€â€š	ââ€â€Ã¢â€â‚¬ KSP_linux_0.25.0 # contents not listed
	ââ€Å“ââ€â‚¬ local-overlays # locally-authored overrides
	ââ€â€š	ââ€Å“ââ€â‚¬ shsls-flags # my personal flags
	ââ€â€š	ââ€â€š	ââ€â€Ã¢â€â‚¬ GameData
	ââ€â€š	ââ€â€š		ââ€â€Ã¢â€â‚¬ _local-shsls
	ââ€â€š	ââ€â€š			ââ€â€Ã¢â€â‚¬ Flags
	ââ€â€š	ââ€Å“ââ€â‚¬ binpatch-025_0
	ââ€â€š	ââ€â€š	ââ€Å“ââ€â‚¬ KSP.x86_64 # locally hexedit'ed to work around the pointer-truncation bug that Unity3D inherited from libpng
	ââ€â€š	ââ€â€š	ââ€â€Ã¢â€â‚¬ settings.cfg # locally modified - defaults to 1920x1080 fullscreen
	ââ€â€š	ââ€â€Ã¢â€â‚¬ binpatch-024_2 # same as for previous entry, but based on 0.24.2
	ââ€Å“ââ€â‚¬ mount-points # contains unionfs mount points, which are auto-mkdir'd by the mount scripts
	ââ€â€š	ââ€Å“ââ€â‚¬ modupdate_2014-10-06_16.42
	ââ€â€š	ââ€â€Ã¢â€â‚¬ 025update
	ââ€Å“ââ€â‚¬ overlay-mods
	ââ€â€š	ââ€â€Ã¢â€â‚¬ SomeThirdPartyMod_version-number
	ââ€â€š		 ââ€â€Ã¢â€â‚¬ GameData
	ââ€â€š			  ââ€â€Ã¢â€â‚¬ SomeThirdPartyMod
	ââ€Å“ââ€â‚¬ scripts # where the mount scripts live, you need one mount script for each combination of ( KSP version + mod mix ).
	ââ€â€š	ââ€Å“ââ€â‚¬ modupdate_2014-10-06_16.42.sh # heavily modded 0.24.2
	ââ€â€š	ââ€â€Ã¢â€â‚¬ 025update.sh # 0.25.0, still waiting for more mods to update before making this my primary
	ââ€â€Ã¢â€â‚¬ unionfs-storage # where unionfs diverts writes to; subdirectories are automagically mkdir'd by the mount scripts and by unionfs
		ââ€Å“ââ€â‚¬ modupdate_2014-10-06_16.42
		ââ€â€Ã¢â€â‚¬ 025update

* Or aufs, if you don't mind patching your kernel

Edited November 1, 2014 by Fail-Man 3D
Added directory layout

[skeevy]

snip

* Or aufs, if you don't mind patching your kernel

That's awesome. It's like Skyrim Mod Organizer, only for KSP Linux in the form of a script and A LOT more manual. Nice.

Anyone want another +1 for Manjaro? Nope? Well, too bad, you're getting it anyways -- Their stock kernels come with AUFS support (and ZFS support if that interests anybody). No patching required (at least on my 3.17 stock Manjaro kernel). They also come with some CK patches and BFS stock.

Unrelated to that, just something I've been thinking about lately

Now we just need a universal image conversion script for DDSLoader. I've been looking into it, but unless someone explicitly lays out what coverts to what, what needs to be skipped, what images need to be flipped, etc, I'd just be pissing into the wind. There's a lot of information on the KSP image formats spread throughout the DDSLoader thread and it's a lot to take in all at once.

@Todacious has a basic Linux script and @Shaw has an img2dds program for Linux.

[John FX]

Oops, it seems I have Ubuntu, not debian.

I think it will take me a while to be able to just `install Linux, Install drivers, Install KSP, Play KSP`

I am generally confused by Linux. It seems that either you know or you do not and finding basic info is hard.

Even the most basic instructions seem to involve patching your kernal, loading a few programs with names that are acronyms, running a boatload of unknown shell commands (also acronyms), setting parameters on quite a few files then running some form of script.

Is there no equivalent to `install windows, boot windows, install drivers that came with your hardware, unzip KSP, double click KSP.exe`?

For example, what is AUFS and what is ZFS or CK or BFS? Why are they needed?

I`ll have a look about for Manjaro if it is advised. I`m reading the linux thread first page currently.

Edited November 2, 2014 by John FX

[skeevy]

Oops, it seems I have Ubuntu, not debian.

I think it will take me a while to be able to just `install Linux, Install drivers, Install KSP, Play KSP`

I am generally confused by Linux. It seems that either you know or you do not and finding basic info is hard.

Even the most basic instructions seem to involve patching your kernal, loading a few programs with names that are acronyms, running a boatload of unknown shell commands (also acronyms), setting parameters on quite a few files then running some form of script.

Is there no equivalent to `install windows, boot windows, install drivers that came with your hardware, unzip KSP, double click KSP.exe`?

For example, what is AUFS and what is ZFS or CK or BFS? Why are they needed?

I`ll have a look about for Manjaro if it is advised. I`m reading the linux thread first page currently.

AUFS and ZFS are different file systems like FAT32 or NTFS, only much more advanced. CK are kernel patches made by Con Kolivas. BFS stands for brain f*ck scheduler and is an alternate IO scheduler to use instead of CFS (completely fair scheduler). Traditionally, Linux stuff is programmed for server use, but CK patches and BFS are more for desktops/workstations. For a new user, none of this is anything you should be concerned with (unless that script above gets tweaked to use AUFS....which is a possibility because I dislike dealing with dumbass r/rw errors and some mods do need to write to their directories (like ATM or Parts Catalog)).

To install Linux and just play KSP....the easiest way is install Manjaro (or any distro really) to it's own hdd (one OS to a hdd is my philosophy; post if you need help), boot up, run as root "pacman -Syyuu", reboot, run as root "pacman -S steam-native", launch Steam, download KSP, Play. If you don't use Steam, after the first reboot, go to KSP's download page, download, extract, then play it. To put that in Windows terms: install it, boot up, update the system, reboot, install Steam or Downoad KSP...Except for graphics drivers, you hardly ever install any driver on Linux; I will note that WiFi cards are an exception to that.

As far as Manjaro and Ubuntu installers are concerned, they're click, click, set up partitions, click, click, fill out user info/hostname/etc, click, click, done. Everything is WYSIWYG and real straight forward. It took me under 20 minutes to install Manjaro to its own hdd, maybe another 20 minutes to configure it, install Steam, and start playing KSP.

If you're gonna install Linux to a HDD containing Windows, it isn't as easy but it is possible (though not really recommended). Instructions are different depending on Linux distro, version of Windows, BIOS or UEFI, etc.

I don't know what basic instructions you've been reading, but patching kernels usually isn't necessary except for things like CK, AUFS, BFQ, and other things that most new users just don't need to be doing or aren't part of the mainline Linux kernel.

Those shell commands....that's just basic system maintenance. A lot of that stuff can be done with a GUI app, but what you gain in convenience is a loss for fine control over what you're doing.

For modern Linux setups, about the only thing you might have to configure is xorg.conf if you have some odd ass setup in regards to your GPU.

If you want, link to what guide you're using and we'll try to simplify it for ya.

I advise Manjaro, but only because, for new users, it has a lot of advanced functionality and features that actually require things like kernel patches and whatnot; it has that steam-native package that makes Steam use system libraries (the cause of a lot Steam Linux KSP issues is using the Steam libs); and it's really up-to-date -- there are only a handful of distros more up-to-date than Manjaro, and that handful of other distros come with a steep learning curve -- see here for an example of a steep learning curve.

EDIT: just checked the BFS link....the forum cuss filter changed the F word to .... so replace the .... in the link with the F word.

EDIT2: Have 4 more episodes of Star Trek TNG left. Kinda in a marathon of them so I may not be back for a few hours or tomorrow.

Edited November 2, 2014 by skeevy

[steve_v]

Ya know, 'waaah linux is too hard' doesn't really achieve very much - If you have a question, go ahead and ask it.

I just installed Xubuntu on a spare drive - mostly to see how the other side looks

Installed GPU drivers and updated the system, I didn't see a command line once.

~20 minutes in and I'm 'unziping ksp' and 'double clicking' KSP.x86_64. (actually, I'm launching it in a shell, but I *could* have worn out my mouse button if I wanted to.)

GNU/Linux has really come a long way in terms of 'newb friendliness', I was surprised.

Then I wiped it to give the latest PC-BSD a spin

Used to run Arch, but got lazy re. constant updates. Might have to give Manjaro a go, it sounds like a good comprimise - Debian stable can be a bit *too* 'stable' if you know what i mean.

On a less ornery note, ZFS is pure awesome

[Unit327]

KSP with a lot of mods often hangs forever during part loading for me, does anyone else get this? Sometimes it takes me 5 goes to get into the game, but once there it runs fine.

I'm on mint/ubuntu, 64bit, using LC_ALL=C. I'd post the log but I've watched it with tail -f and it's not very informative (always stops on a different part, no obvious exceptions or errors logged). Still have around 500MB of ram free after loading the game.

[steve_v]

FWIW, I too have seen this.

Only occurs occasionaly for me & my logs are squeaky clean.

I've only ever seen it with Karbonite parts, but that may well be a coincidence.

99% of the time all is well on the second go.

Debian Sid / x86_64, I'd test on x32, but ~6.5GB RAM usage and all...

I'm not too sure where to go with tracking it down, strace just shows an (open) on the texture in question then nada - so I guess it's inside KSP, where I can't get at it.

Ideas anyone? do we have another bug in the texture loader?

Edited November 3, 2014 by steve_v

[ormaaj]

Note the scripts on page 1 won't work as intended unless LC_ALL and LD_PRELOAD are already exported by the parent process (unlikely, more likely LANG will be exported, LC_ALL and LD_PRELOAD will be unset). You should export everything you want in the environment in the script prior to calling exec.

I'd also be wary about setting LC_ALL=C because of its effects on LC_CTYPE. I don't know why it's being set here but I'd guess it's to get sane collation order. If you really need it, and have a distro that supports the non-standard C.UTF-8 locale, that would be preferable. Otherwise you probably just want to set LC_COLLATE, LC_NUMERIC, and maybe LC_TIME.

[steve_v]

IIRC, it's being set because the use of ',' as opposed to '.' as a decimal seperator in certain non-english locales causes some truly wierd behaviour in KSP - including silent save file corruption.

As such, LC_NUMERIC would probably suffice no?

[John FX]

I advise Manjaro, but only because, for new users, it has a lot of advanced functionality and features that actually require things like kernel patches and whatnot; it has that steam-native package that makes Steam use system libraries (the cause of a lot Steam Linux KSP issues is using the Steam libs); and it's really up-to-date -- there are only a handful of distros more up-to-date than Manjaro, and that handful of other distros come with a steep learning curve -- see here for an example of a steep learning curve.

Yup, that is the sort of documentation I`m talking about. It`s really hard to find an actually basic guide. I`ve downloaded Manjaro (hadn`t heard of it before this thread) and I`ve got a spare drive to put it onto. I`ll post if I have any problems.

[ormaaj]

IIRC, it's being set because the use of ',' as opposed to '.' as a decimal seperator in certain non-english locales causes some truly wierd behaviour in KSP - including silent save file corruption.

As such, LC_NUMERIC would probably suffice no?

Maybe. LC_MONETARY affects strfmon() similarly, and LC_TIME affects strftime() in ways that could cause problems depending on how the game saves things (I'm new).

However it looks like it takes some special effort for Unix locales to even influence mono (e.g. generating + setting French locales has no impact on separators without using their Unix libraries):

~ $ LC_MONETARY=fr_FR.UTF-8@euro LC_NUMERIC=fr_FR.UTF-8@euro csharp -pkg:dotnet -e 'Console.WriteLine("{0:c} {1:n}", 123456789.01, 123456789.01);'
$123,456,789.01 123,456,789.01

http://www.mono-project.com/archived/internationalization/

[skeevy]

snip.

snip

snip

snip in a code box

Only reason LC_ALL=C is being set is because that's the recommended fix in the unmodded Linux thread.

Did a bit of searching and LC_COLLATE and LC_NUMERIC have been used to fix the period and comma issue for different things. Arch Linux used to set LC_COLLATE=C system wide to act as a hacky fix for similar multi-language and sorting issues. One or both of those would probably be a better fix than LC_ALL=C system wide.

Another option would be to determine what LC options the current system is using (run "locale"), stash those aside, set LC_ALL=C while KSP is being played, set system's original LC_* settings when KSP is quit.

Thinking out loud here, but @Fail-Man 3D's script combined with my 2nd idea (locale backup/restore) and an automated git solution for backing up save games and settings would be nice to have -- think about it -- mods and mod ships (like with FAR) won't be polluting the game's directories so the KSP directories themselves would always be stock, LC_ALL=C while playing and original locale(s) restored upon exit, and backups of every save, autosave, and settings when they're changed or created. Thoughts or ideas? And yes, I can see issues arising if KSP crashes and the script doesn't catch that to restore the LC settings.

Can't believe I forgot to add two "export"s in those scripts....red for syntax highlighting goodness

(before this thread, had everything in two lines; made it a bit more human readable and screwed it up....thanks for catching that; had to color export red because the syntax highlighting is why I screwed it up...saw those lines had correct colors and completely brain farted that export was missing)

[ormaaj]

Did a bit of searching and LC_COLLATE and LC_NUMERIC have been used to fix the period and comma issue for different things. Arch Linux used to set LC_COLLATE=C system wide to act as a hacky fix for similar multi-language and sorting issues. One or both of those would probably be a better fix than LC_ALL=C system wide.

Another option would be to determine what LC options the current system is using (run "locale"), stash those aside, set LC_ALL=C while KSP is being played, set system's original LC_* settings when KSP is quit.

Nothing is being set system-wide so there's no need to save and restore anything. Environment variables are per-process (you can't really make a system-wide locale change without rebooting).

[skeevy]

Nothing is being set system-wide so there's no need to save and restore anything. Environment variables are per-process (you can't really make a system-wide locale change without rebooting).

Most of my experience is setting them system wide or user wide, like in bash_rc or /etc/locale, /ect/env...places like that. KSP is the first time I've actually exported an LC command on a per-app basis, and honestly, I never bothered checking to see if it was being set system wide or not afterwards (a case of if it works, don't fix it anymore). I should know better than that...

[Fail-Man 3D]

ZFS is pure awesome

ZFS is pure awesome, assuming that the following are all true:

1. You don't hate the license (CDDL is GPL-incompatible, the ZFS kmod taints the kernel when loaded)
   
2. You keep the Solaris Porting Layer kernel module exactly in sync with the ZFS kernel module
   
3. If you fail to do point #3, you have your system set up to halt mid-boot when the ZFS mounts fail
   
4. If you fail to do #4, you at least check to see if the mount succeeded before letting PostgreSQL scribble all over the mount point (ask how I know…)
   
5. If booting from ZFS, you don't mind using (specially-patched) GRUB and/or an initrd
   

Other filesystem-related notes:

• My current implementation redirects all writes to disk. Possible improvement: redirect everything except screenshots, settings.cfg, and saves to tmpfs?
  
• When using unionfs-fuse, you may need to increase the maximum number of files that a regular user can open. The easiest way to do this involves creating a new group, adding yourself to the group, and then changing the file-descriptor limit for the group.
  
• The script I provided may, as written, run into limits on environment variable length and argument length. I don't quite know how to work around this (I haven't run into any problems yet, and the unionfs-fuse documentation is clear as mud on this subject).
  
• JFS is pure evil when used for the rootfs. It needs an initrd with jfs_fsck in it in order to avoid massive corruption. Defragmenting involves "tar -a", a scratch disk, and "mkfs".
  
• XFS is nice, but you need to remember to kick off xfs_fsr from cron every few weeks
  
• XFS and JFS both seem to prefer the deadline scheduler over the CFQ scheduler (I haven't tested BFS yet).
  

@Unit327, @steve_b:

I've had that happen to me before, it can usually be traced back to one of the following:

1. The OS swapping unused chunks of RAM out to disk cache (even better when swapspace and / share The World's Slowest 7200RPM Laptop Hard Disk)
   
2. Buggy part config files
   
3. Ancient models
   
4. Prehistoric plugins
   

[Unit327]

@Unit327, @steve_b:

I've had that happen to me before, it can usually be traced back to one of the following:

1. The OS swapping unused chunks of RAM out to disk cache (even better when swapspace and / share The World's Slowest 7200RPM Laptop Hard Disk)
   
2. Buggy part config files
   
3. Ancient models
   
4. Prehistoric plugins
   

1. no swapspace configured, 1.5G free after loading ksp
   
2. possibly due to one of the mods, but why only does it only hang every 3/4 goes?
   
3. fresh install of ksp
   
4. re-downloded all mods
   

Steve_b mentioned mks/oks mod as well, I do have that one installed.

[Gfurst]

Hey just wanted to share my specs for my fellow penguins..

OS: Linux 3.16-2-amd64 Debian testing 64bit
CPU: AMD FX(tm)-6300 Six-Core Processor (6)
RAM: 7902
GPU: Gallium 0.4 on AMD BONAIRE (264MB)
SM: 30 (OpenGL 3.0 [3.0 Mesa 10.2.6])
RT Formats: ARGB32, Depth, ARGBHalf, RGB565, ARGB4444, ARGB1555, Default, DefaultHDR, ARGBFloat, RGFloat, RGHalf, RFloat, RHalf, R8

Pretty good stuff han? Actually the GPU is a Radeon R7 260X 2gb, don't know why but always shows up like that.

Anyway, just want to point out: open-source drivers, lately they're getting pretty good, performing better than the proprietary, not to mention the advantages of being fully Xorg compatible.

I used Active-texture management on the previous version, but on this one it didn't quite work than I noticed it actually works and looks a lot better without it. Still there don't seem to be a huge memory consumption.

Game is constantly lagging, I'm aware it uses a lot of cpu time, but I don't think is fully using mine; so KSP doesn't take advantage of hexcore?

Checked a FPS addon out of curiosity and found out I'm always stuck at a 25fps, how is that even possible?

[steve_v]

so KSP doesn't take advantage of hexcore?

Correct

[skeevy]

snip

License and upkeep aside, ZFS is pretty good.

BTRFS with BFS is pure suck. Haven't tried it with deadline, noop, or CFS yet.

I used to run XFS exclusively until a random power outage corrupted my drives and I lost around 1.5TB of music, movies, games, and backups. XFS does not like losing power, especially during massive file operations.

Haven't played KSP since my last post here. Been busy IRL and haven't had the time. I did pick up the game Verdun from Steam and managed to get a few hours in it. Just wanted an FPS and figured I'd support another up-and-comer as well as wanting a WWI game. WWII and Modern games get old after a while. I'd love a good FPS set between the 50's and 80's....1900's and 1800's btw...not that many good Cowboy, Civil War, Korea, or Vietnam games.

Verdun's not bad, but it's obvious that it's a WIP. Needs more North American players (hint, hint). Bolt action deathmatch is a blast if there are a lot of players on the server.

Hey just wanted to share my specs for my fellow penguins..

OS: Linux 3.16-2-amd64 Debian testing 64bit
CPU: AMD FX(tm)-6300 Six-Core Processor (6)
RAM: 7902
GPU: Gallium 0.4 on AMD BONAIRE (264MB)
SM: 30 (OpenGL 3.0 [3.0 Mesa 10.2.6])
RT Formats: ARGB32, Depth, ARGBHalf, RGB565, ARGB4444, ARGB1555, Default, DefaultHDR, ARGBFloat, RGFloat, RGHalf, RFloat, RHalf, R8

Same GPU that I have. The 25fps could be from V-Sync being enabled in combination with physics calculations. I had that issue too and those were the causes of it. Sadly, I could either get 25fps constant like that and stay in the Yellow no matter what or disable V-Sync and lower my physics calculations a bit and jump between normal and yellow with the framerate jumping between 9fps and 45fps depending on where I'm looking, where I'm currently at (orbit, Mun, launchpad, etc) or if my trajectory leaves the planet or not -- not sure why, but the second my trajectory exits the atmosphere I gain a massive FPS boost regardless of what's going on.

If you can, run a 3.17 kernel and update Mesa to 10.3. You'll get a decent increase in performance. If the AMD Radeon development keeps on like it is, we should have some awesome drivers around the 3.19 or 3.20 kernel releases. It looks like AMD missed the deadline to get the AMDGPU driver added to the 3.19 kernel. Hopefully Mesa 10.4 and Kernel 3.18 will be released soon and we'll be able to use those (Mesa 10.4 due in December IIRC; Kerenl 3.18 was RC3 the last time I checked).

Bonaire is the codename of the R7 260x. Thought I'd let ya know.

I'm gonna be a bit pissed off if AMDGPU (the upcoming new opensource radeon driver) doesn't support our card since they're doing in-house testing with GCN 1.1 cards like ours. Rumor is that AMDGPU will only support GCN 1.2 and up (R9 285x is the only GCN 1.2 card at the moment).

EDIT:

@sal_vager

Like the new OS tags and colors on the support pages

Edited November 9, 2014 by skeevy