steve_v

Is your executable marked as executable? - do 'ls -l KSP.x86_64' to find out - look for 'x' in the permissions grouping at the start of the line. 'chmod +x KSP.x86_64' to make it so. *NIX uses permissions, rather than a filename extension (.exe) to denote files that can / should be executed. Also worth mentioning, you may want to set some environment variables and/or create a launcher script - see The Linux Thread for details. Hmm, I'm fairly used to partitioning I guess. Partitions are really all the same whatever OS you're installing, the Windows installer just doesn't give you any options. I *guess* that makes it less confusing. That said, anything that mucks with the partition table has the potential to nuke your stuff - The 'install alongside Windows' process actually involves moving _all_ your data around to make some space for the new partitions, so 'not going to change anything on this part of the disk' doesn't really make sense anyway. Proceed with caution, and a backup of anything really important I still prefer to do this stuff manually, from a live disk - just so I know *exactly* what's going on

Most modern GNU/Linux installers will do this stuff for you You'll get a GRUB (GRand Unified Bootloader) menu at startup & your windows install should appear as an option, along with any Linux distros you have installed. Once upon a time all this was done manually - shrinking partitions, installing GRUB (or LILO), chainloading the windows bootloader etc. It still can be, but IIRC the *buntu installer will hold your hand pretty well these days.

How about http://linuxnewbieguide.org/ it's one of many. One thing I just have to say, learn to use the command prompt (shell). It'll serve you well, and it's packed full of handy tools. If you haven't a launcher in your menu (varies with desktop environment & install method), open a terminal in your KSP install directory - usually in the right click menu of your GUI file manager, or just open a terminal from the main menu and 'cd /path_to_KSP/'. <-- replacing 'path_to_KSP' withthe folder you installed it in Then execute KSP.x86_64 like: './KSP.x86_64' To make a shortcut in the KDE menu, right click the 'K' menu button and hit 'edit applications' -> right click the folder you want it in -> new item. fill in the name etc & put the above /path_to_KSP/KSP.x86_64 in the 'command' box, then save.

All CMOS batteries are replaceable... if you have a soldering iron As for the main battery, that age it's probably a) dead as a doornail and a NiCd, which means you can probably re-pack it with cheap cells

The driver situation is actually pretty darn good these days, unless you, ya know, happen to have a fancy Graphics card... in which case you're at the mercy of the hardware vendors. The open source GPU drivers are coming along nicely though. I haven't actually found anything that doesn't have a working driver in years, and being a monolithic kernel means far less farting around downloading drivers than a new Windows setup... most of the time.

Debian here too stable for 'fire & forget' servers / workstations, sid for my gaming desktop. I started out a slacker though - zipslack 3.5 on a 486 to be precise. I lost a bit of faith in gnome when they started persuing the 'less is more' mentality - somewhere just after 1.6 IIRC. Nothing wrong with it I guess, just too much bling and not enough exposed knobs for my taste

Anything in your system logs? i.e. dmesg or /var/log/messages?

Hodo, that last pic you posted appears to feature some kind of runway lighting or approach guidance - may I inquire as where you got it? If it's what I think it is... I've been wanting that forever.

'A reasonable engine for rough economic times" pretty much sums up my use for the poodle - disposable 2.5m upper stages. Not sure I agree on the 909 though, it's pretty handy - especialy early in a career game.

Cinnamon is nice, though I personally prefer KDE for its configurability. GNOME3 is um... yeah, let's not go there.

Depends on your definition of 'similar' Similar under the hood, hell no. But you can make the desktop look and behave pretty much however you want I'm pleasantly surprised there are so many GNU/Linux fans here - this is a *game* forum after all. Suspect the KSP Win64 debacle may have something to do with it though IMHO the best thing about Linux, aside from the all-important 'freedom' thing, is it's flexibility - where Windows really only runs on a couple of architectures in a limited set of roles Linux runs on almost anything and can *be* anything from a micro router in <50MB to a full-blown desktop to an OS for a room-filling supercomputer And the GNU userland is just nice, really nice. Once you get used to a *NIX environment using Windows feels like dancing in a bodycast. Next mission: Get KSP to run on a 'real' UNIX... AKA BSD. Oh how I miss you not, you half-arsed 'multi tasking' shell... Look out, your DOS is showing. I'm pretty sure pre 2k Windows was some kind of nasty prank

Um, 'cause it's as difficult as falling off a log? Not mine, but here ya go.

Welcome to the Dark Side May your stay be a pleasant one.

Alt-click clone also works for replacing a wing sub-assembly when this happens. Hopefully it goes away when the shiny toys arrive with the next version of FAR On an aside, my experimental VTOL trainer just pulled ~27G in a mach2 vertical loop The crew did not survive. These tweakable wing strengths are neat, if possibly a little OP at the default setting.

I have an old IBM machine with similar specs (33mhz CPU / 8MB RAM / 80MB HDD) running as a router/firewall (FreeSCO) right now... It _is_ actually a bit OP for that task - the bottleneck is the 10Mbit NIC. It's the last of my prehistoric machines - the next oldest is a blazing fast PIII 800 - that I bought for $5 I used to have an old DEC Alpha workstation tower, I forget the exact specs but you could have the option of: A 486DX4, A DEC Alpha (64 bit!!) or a dual Pentium pro CPU/RAM board. With up to 64MB of FP ram - I had the Alpha, with an early UNIX OS (I forget the exact variety). Dunno why I got rid of it TBH, probably space... DEC made some damn fine machines, that beast was more structuraly sound than most modern cars. Where I work, there's a _room_ full of ancient laptops, some are 386 era. Nobody seems to know how to back things up properly, so they have been keeping entire machines just for the data on the disks Might have to go exploring one day soon.

It's not a solution, it's an experiment. As far as I can tell, it multithreads part of the garbage collector. At least that's what it does in stock mono. My experiences are entirely subjective, and only on GNU/Linux. It may well just be placebo The idiots guide would be: Check out https://github.com/Unity-Technologies/mono. Modify external/buildscripts/build_runtime_linux.pl to reverse the --disable-parallel-mark configure flag. 'perl external/buildscripts/build_runtime_linux.pl'. (with -build64=1 if you want 64bit) Copy eg. 'builds/embedruntimes/linux64/libmono.so' to <KSP_INSTALL_DIR>/KSP_Data/Mono/x86_64/. See if you can see a difference - probaby not unless you run a lot of mods that create a lot of garbage. There are a few other things that can be messed with here, for example using __thread rather than libpthreads which may also be slightly faster - see the README. Unfortunately the changes Unity made to this mono fork means most of the GC related options no longer compile, eg. using sgen or system boehm. Messing with mono may not do anything usefull at all, or it may eat your kitten. 'at own risk' applies here, but I'd be interested to know if it really does make a difference.

0.25 works just as well as 0.24.2 for me - with the NVIDIA driver. I'm also running Debian sid but I haven't tried nouveau since (historically at any rate) it causes boot failures with KMS on this machine. Desktop system with a _slightly_ beefier GPU though I tempted to say that GPU doesn't have a lot of VRAM - maybe the requirement for 0.25 is higher & you're not able to load all the textures? But I'd expect something in the logs if that were the case...

Where I am, they're called "Surge supressors" "Transient Voltage Suppressors" and the like - any half decent UPS will have one built in & many powerboards do too. That said, unless you have _really_ nasty power, the SMPS in your PC should be pretty much immune anyway. I'd say overheating or _maybe_ a dodgy PSU. I'd run a stress test - prime95 for the CPU, Furmark for the GPU and check your temperatures don't get out of control. Maybe worth running eg. memtest86+ to check your RAM, though dodgy ram is more liable to cause BSODs etc. than a random shutdown.

What I'm dying to know is: when do we get a Unity built with a non-ancient version of mono? the boeheim GC overhead is awfull (and I can't get Unity's mono fork to compile the 'experimental' sgen). Mainstream mono has had multithreaded generational GC for some time now... On an aside, recompiling mono with '--enable-parallel-mark' (disabled as "causes crashes" in Unity's buildscripts) significantly reduces the "stopping the world" GC hitches for me... no crashes so far Of course the real elephant in the room, as usual, is the single threaded physx...

Unless you have explicitly disabled logging with the -nolog switch, there is a log file. Directly accusing one of the most respected mod authors here of writing crappy code, while providing no evidence whatsoever (i.e. logs) to back up your claim? That's not going to work. Nobody is under any obligation to help you, so if you want people to _volunteer_ time to solve this I suggest you ask nicely and make some effort of your own to provide the requested information. Now, upload a log file and someone may be inclined to take a look. Posting said logs in the KAC thread may even expedite the process On a side note, ~/.config is a really super dumb place to put a log... er, you listening Unity?

Looks like you're running nouveau / Gallium, have you tried the NVIDIA binary drivers? Also maybe worth mentioning, reports from Arch linux that running the 32bit build on a 64bit OS with multilib can cause graphical issues - you are running 64bit KSP right?

Just a quick 'me too' Occurs pretty much instantly (AFAIK) when exiting timewarp on the pad, KJR also installed.

My bet's on garbage collection TBH, it's awfull regular & about the right intervals (yes, I've been playing with GCMonitor). Now, If I can just get the profiler set up for 64bit I might be able to see which of the _other_ mods I'm running on my main install are contributing... The more mods installed (AKA lower framerate in general) the worse this gets but MJ is the only one that has a noticeable impact alone, and certainly appears to be the biggest culprit overall.

If you just want an FPS indicator, grab fps.dll from here. There is also voglperf, but the hud is not so pretty. It can do logging though.

OK, so I have a trace, and I have emveepee opening it okay too (had to pass --runtime=v4.0 to mono to get emveepee to run) But, as I suspected, It doesn't mean much to me. Actually, there doesn't appear to be much information in it at all, but you may see different. Or I may be missing something . Do I need to build MJ with debug symbols (or the C# equivalent) to get usefull data?