steve_v

Pretty please?

If you're running FAR, it's calculated for you in the flight data window

Spot on, thanks muchly I hear ya on the fragile contracts system, it's not the first time it's gone belly up on me for trivial part changes.

IIRC it's more a play on 'free cisco'. It's pretty cool. I used to have a real beast of a 486 (120MHZ!) running this, lived in the basement doing ADSL routing / firewall duties plus some custom mods of my own to take voice messages with the fallback dialup modem, compress them to mp3 (SLOW) and send them out by email Encoding time wasn't important, but with a heavily optimised mpg123 build it was _just_ fast enough for realtime playback - with ~85% CPU usage. Finding software to deal with the voice functions of the modem & convert its unusual recording format was... interesting. Much digging through ancient FTP sites The DXL4 CPU was also the first I encountered that had a fan, one day it fell off... and nothing happened

Technically, all Linux kernels are 'monolithic' though the definition blurs a bit when you take into account loadable modules.For a really lightweight system, nothing beats a hand-compiled kernel though. I'm not sure what the minimum space requirement for a modern kernel is, but back in the 2.0.X days you could get a cli OS on a single 1.44MB floppy It did involve rabbits though, and hats. This, for example, is a fully functional router distro. I did a bit of hacking on it long ago, surprised it's still around TBH.

NullReferenceException: Object reference not set to an instance of an object at (wrapper stelemref) object:stelemref (object,intptr,object) at PartLoader.ParsePart (.UrlConfig urlConfig, .ConfigNode node) [0x00000] in <filename unknown>:0 at PartLoader+.MoveNext () [0x00000] in <filename unknown>:0 Ahh, this. I have seen it too, but I really have no idea what causes it - it doesn't happen all the time or always on the same part. It does seem to trigger at a certain threshold number of part mods though. I'm not sure this is actually attributable to any specific mod, the error looks to be coming from Squads part loader...

Player.log is better, location: ~/.config/unity3d/Squad/Kerbal Space Program/Player.log

As much as I hate to be the bearer of bad news, It appears that the latest version breaks the FAR flight GUI. With 0.1.5a installed, the FAR gui won't open, no matter how many times you click the clicky thing Linux x64, only FAR, MJ and this lot installed. I get this at vessel load: ArgumentOutOfRangeException: startIndex + length > this.length Parameter name: length at System.String.Substring (Int32 startIndex, Int32 length) [0x00000] in <filename unknown>:0 at ClawKSP.KerbalDebrisFix.OffRails (.Vessel VesselToFix) [0x00000] in <filename unknown>:0 at EventData`1[Vessel].Fire (.Vessel data) [0x00000] in <filename unknown>:0 at Vessel.GoOffRails () [0x00000] in <filename unknown>:0 at OrbitPhysicsManager.LateUpdate () [0x00000] in <filename unknown>:0 Complete log.

Ahh, seems I've stirred the anthill some . *Maybe* relevant data point: I recompiled mono with --enable-parallel-mark, the slowdown is still there (going by the game clock) but it doesn't seem to 'stop the world' nearly as much (subjective, as always). On the other hand, it also appears to introduce a massive memory leak... I didn't notice this untill the framerate tanked, ohh look KSP is using 12GB of RAM - that'd explain it. Suspect I broke the garbage collector Does anyone know of a way to log the physics rate? It'd be real handy...

It would seem AMDs Linux drivers are *still* a steaming pile - hence why I don't have an AMD card.

In that case, I'd say it's almost certainly GPU or GPU drivers - sounds like it's the only thing that's actually dying & it's probably left in a state where X can't re-initialise it. You *might* be able to unload and re-load the driver over SSH to get your screen back, but that won't stop it happening again. As to what to do about it... dunno TBH. I don't have an AMD card to play with, but others appear to be having similar problems - all with AMDs binary driver... I'd say blame AMD, but that doesn't really help much either. I take it you've played with all the options in CCC? There may also be more (i.e. disabling features) in xorg.conf - see the docs for your driver. Try the open source radeon driver - performance will probably suffer a bit though. About the only other thing I can suggest is trying different versions of the AMD driver (or maybe Xorg, but that gets a mite complicated) - it may be a regression, stranger things have happened. If nobody with a similar card has any ideas, it might be worth taking it to either the Mint or AMD support forums.

Is it ah, expected behaviour that this update wipes out most of my contracts, along with all the archives? I grok the bit about removing it, but nothing is mentioned of an update... No big deal as I have backups, but I'd kinda like to try out the new toys on my career save - without loosing the all important 'explore body' contracts already accepted.

You know you can fix Xorg issues from the console, right? Boot /= GUI. Unlike Windows, the GUI is just another layer & the system is quite useable for most tasks without it. In fact, you can have a graphical web-browser (wit a mouse even!), video playback, full multi-tasking etc. without even starting Xorg.

Yeah, there is (with NVIDIA too, so it's not the GPU driver). I'm not sure what's causing it either - best guess so far is monos garbage collector. There's a better one in place in the current mainstream mono, but Unitys fork is a wee bit behind. Enabling multithreading for the builtin GC improves matters, but it also introduces memory leaks If anybody has other ideas I'm all ears, 'tis fairly annoying. AMD needs some serious poking regarding the driver bugs though, this has been going on far too long.

Another one of those things I often forget to mention, as I've been setting up fstab by hand for as long as I can remember. I actually use 'noatime' on drives I'm never going to want to audit.

What GPU and driver do you have? Taking down X is usually graphics card driver related... Retrieving the system logs via SSH after a crash may shed some light.

So prior to that you were running the open-source raedon driver? and it worked? This is smelling more and more like a bug in AMDs drivers... again. It's been a rock & hard-place scenario with AMD/ATI for damn near forever - lower than expected performance with the open-source drivers - you can't really blame the devs though, they've had to reverse engineer much of this. Never-ending compatibility issues & bugs with AMDs binary blob. Unfortunately I don't have an AMD card to play with... and I won't buy one until the Linux driver support improves. If it's taking down X, its almost certainly a driver issue. Unless someone with an AMD card has some tips, or changing settings in CCC fixes it this might be a 'go whinge at AMD for the crappy driver' type scenario

Bugger. I don't see anything suspicious in there, assuming KSP crashed in the timeframe this log covers. It's about as usefull as the Player.log Doesn't necessarily rule out hardware / driver / ram etc. issues but it's not as illuminating as I'd hoped. I'd still be tempted to point the finger at the GPU drivers, if only because AMD has a long history of shoddy drivers for Linux.... So... got the latest AMD driver?

I've been keeping an eye on ReactOS for years now, I'm not overly optimistic TBH. It doesn't appear to have come very far in that time - not surprising considering everything must be reverse engineered without help from MS. Re-inventing a square wheel doesn't make much sense to me anyhow.

All true, IIRC the Ubuntu installer gives the first user you create ALL:ALL in /etc/sudoers. Anyone in the sudoers group also has ALL:ALL. The problem in this case, however, was that it was on a partition mounted noexec. - something I always forget about.

Have a look in /etc/fstab, remove the offending mount option. Like most configuration on Linux, it's a fairly readable text file, but if your disks are mounted by uuid you will need to get the uuid to find the right line. Once again, you can get this with 'mount' (or 'blkid' on the partition in /dev - eg. blkid /dev/sda1 for disk 1, partiton 1) Also, there is a manual for pretty much everything 'man fstab', 'man mount' etc. 'man' is possibly the most usefull command on the system.

Of course, most of the system is outside the home directory. The noexec mount option just tells the kernel not to try to automatically execute files on that mountpoint using the 'magic number' (or the shebang, in the case of a script) to figure out the correct interpreter. It's a feature of the automounter, or the installer put the option in /etc/fstab. Either way, it's silly since it doesn't actually prevent you from executing the file - you just need to call an interpreter (in this case /lib64/ld-linux-x86-64.so.2 for an x64 binary) directly. It doesn't really help security either, except in a casual first-glance kind of way, and it's *really* annoying. Note that calling ld-linux directly is a dirty, dirty, hack and may have been fixed by now

It's usually something simple like that Does indicate that there's something funny about the disk you had it on to begin with though. Is it by chance mounted with the noexec option, or read-only? 'mount' will tell you If it's an external drive and Ubuntu helpfully automounted it for you, I would not be at all surprised if it's mounted noexec... More Ubuntu 'features'

'chmod 0755 ./KSP.x86_64' (shorthand for chmod u+rwx,g+rx,o+rx) as your normal user, no sudo. Then check 'ls -l ./KSP.x86_64' and see if the e(x)ecute bits are set. Your KSP install's not on a read-only filesystem or something is it? can you write to your KSP install directory as your normal user? As long as everything is in your home directory and you have _not_ used 'sudo' to put it there, you shouldn't need root priveliges at all. Ubuntu's fetish for sudo has always perplexed me somewhat - the first thing I do on a new install is 'sudo passwd root', set a root password & disable remote root logins if they aren't already. Then I can 'su' to become root, and _stay_ root untill I am done doing 'administrative' things. IMO it's actually more secure than the Ubuntu setup as an attacker would need to know both a user password _and_ the root password to run anything as root - provided you set a good password for root of course.

Administrator? is this a *user* account, or are you logged in as root? Ubuntu does funny things to be more like windows, hence the copying of *that* feature... Who owns your KSP files, and who are you? Mine says: $ ls -l KSP.x86_64 -rwxr-xr-x 1 steve users 20207816 Oct 8 05:36 KSP.x86_64 And I am: $ whoami steve You shouldn't need to provide a password (I'm assuming you're using sudo from a normal user account) to change permissions on something owned by your user account, you shouldn't need to use sudo either, for that matter.