soulsource

Exactly. If you are new to playing KSP on Linux, you might also want to have a look at the Linux Thread before you launch KSP for the first time. Especially, neglecting the localization issues of the Unity engine will likely lead to a messed up configuration file if your locale is using another character than the period as decimal separator.

You can try the landing legs in the VAB - they can be deployed using the right click menu. By this you can check if they reach down below the engines. About the lander being to long: Tanks can be surface-attached, so you can build your lander more wide than high. Also, the gravity of the Mün is rather low (acceleration of 1.63 m/s^2). Just multiply this number by the mass of your lander to get the gravitational force and compare it to the sum of the vacuum thrust of all engines of the lander. I'd aim for at least a thrust/weight ratio (TWR) of at least 1.2, but as long as you don't add a significant amount of mass by switching to bigger engines, a higher TWR never hurts (or in other words: the higher the TWR, the more fuel efficient your burns against gravity become). While I'm a huge fan of doing the math manually, I can also recommend the VOID mod. It offers a nice table in the VAB, listing details for the various stages, including TWR information for the celestial one selects. My personal landing strategy, which is definitely not the most fuel efficient, is to first go to a low orbit (for the Mün about 10 km), kill all horizontal velocity (switch the navball to "surface" and burn towards the horizon below the retrograde marker, until retrograde shows directly upwards), and then let the craft fall more or less freely (although I tend to decelerate if it goes faster than 100 m/s - just because I tend to be too afraid...), and to make sure that it doesn't move much faster than 60 m/s when the IVA radar altimeter shows less than 3 km. Below 1 km I tend to decelerate even further - around 10 m/s. Of course I always try to keep the retrograde marker pointing directly upwards. Below 300 m radar altitude I usually go below 8 m/s velocity, and meanwhile I even try to get below 2 m/s when landing.

For landing, you can also switch to IVA view. There's a radar altimeter in all command capsules. This will give you the current altitude above ground, not above the (arbitrary) zero level of a body. Now to your original question: The calculation of the phase angle. Let's assume our ship is in a circular low Kerbin orbit, with no significant inclination with respect to the Mün. Wemb has already described how to adjust inclination in comment #4. The question we'd like to answer is: "What is the angle traveled by the Mün during the time a Hohmann transfer takes from low Kerbin orbit to the orbit of the Mün?" I noticed that sometimes my browser doesn't display the formulas in this post correctly. If you see an obviously misplaced or duplicated formula, please reload, or right click and "view image". Let's first get the time the transfer takes. For this, we'll use Kepler's third law, which can be formulated as: "All orbits with the same semi-major axis have the same orbital period." This allows us to calculate the orbital period of the Hohmann transfer orbit by using a circular orbit which has a radius (we'll call this r) equal to the semi-major axis of the Hohmann transfer. The semi-major axis is simply given by the arithmetic average of the periapsis and apoapsis. For a circular orbit, we know that the angular velocity (omega) is constant, and that the centripetal force needed to stabilize the orbit is given by . As in our case the orbit is stabilized by gravity, this has to be equal to (where GM is the standard gravitational parameter of the parent body - here of Kerbin). This gives us an angular frequency of: The angular velocity is related to the orbital period by: Keep in mind, that a Hohmann transfer just takes half of this time, as we only fly from periapsis to apoapsis, and not back. Now, finding out the angle the Mün is travelling during this time, all we need is to multiply the Mün's angular velocity (which we get by the same formula as above, just this time setting r equal to the Mün's semi-major axis) by T/2. Done. But now, let's input some numbers: The Mün has a circular orbit with a radius of 12000000 m, the standard gravitational parameter of Kerbin is 3.5316e12 m^3/s^2. Let's assume we depart from a circular orbit, 100 km above the sea level of Kerbin (which is 600 km from the center of Kerbin). This means, that the semi-major axis of our Hohmann transfer is given by: The angular velocity of our equivalent circular orbit would therefore be: Now, the time our transfer takes is: The angular velocity of the Mün is given by: The angle we want to know is now given by the product: This result tells us, that the ideal moment for a burn would be when the Mün is about 110 degrees ahead of our ship. Nevertheless, this is for a transfer to the center of the Mün, something we probably want to avoid, so I'd either add or subtract a little bit to the apoapsis of the transfer. Or, just play with the maneuver node a little bit, until you get your desired orbit. Edit 1: The problem with the formulas should now be fixed. I switched from sciweavers to codecogs. Edit 2: It just hit me: The standard gravitational parameter cancels out. One doesn't need it at all. The phase angle is simply given by:

I'd say KSP is a pretty difficult game. Of course it gets easy if one uses the walkthrough (dV maps from the Wiki/Forum, data readout mods, transfer window planners,...) or autopilot mods, but if one wants the full KSP experience, one should imho calculate this stuff by hand instead of looking it up. So, yes, I'm a hardcore gamer, as I play KSP (and Dwarf Fortress). I'm also playing a lot of other games (including several AAA titles), but none of them make me think of myself as a hardcore gamer (despite the several hundreds of hours spent playing Skyrim for instance...), as they very seldom pose an as big challenge as the calculations required for KSP do. Regarding the "dumbing down" of the game, I think it's justified. The developers want to focus on things they consider fun, and therefore simplify things they consider tedious. After playing Realism Overhaul for some time, I must say, that stock missions feel more dynamic than RO-missions, simply because one doesn't need to keep as many things in mind while building a craft and therefore doesn't need to spend as much time in the VAB. Also, in RO it's already very tough to do a manned return from Mars, and I wouldn't even think about manned return missions to Venus, Mercury or the satellites of the gas giants... The Kerbolar system on the other hand is small enough to allow return missions to every rocky planet or satellite, what in my opinion contributes a lot to the game experience. The only thing about the simplifications: What the developers consider fun/tedious isn't necessary the same as what players consider fun/tedious. But for that there are mods. ;-)

If you're going to play with many mods, go for the 64bit Linux version. On Windows I'd rather try to get the 32bit version running within the memory limits, as many mods will disable themselves when being run with the 64bit Windows version. (If you really want to, you can of course edit the mod source code, remove the check, and use your self-compiled mod version, but as there have been some heated discussions, please do not publish such edited mods, and don't expect mod authors to help you.). So, my personal (edit: non-sorted) top list of mods for career: Stock Bugfix Modules: Fixes some issues that are still present in KSP Kerbal Alarm Clock: Stops time-warp for you - no more missed maneuver nodes. Also includes a simple transfer window prediction. Ferram Aerospace Research: The stock aerodynamics model is good, Ferram's is in my opinion better. Also, this mod includes some tools for the VAB that help you design crafts that are aerodynamically stable without resorting to trial and error. Important if you play without reverting. Real Chute: Allows you to tweak the size of parachutes. Also, Ferram Aerospace comes with RealChute Lite, and adding the full RealChute one gives access to more tweakables. Vessel Orbital Information Display: An excellent data display mod with a nice customizable layout. The code to calculate dV is the same as used by Kerbal Engineer Redux. Procedural Fairings: With this it's easier to get a fairing suited for transonic velocities. Waypoint Manager: Ever decided to quickly EVA to a certain waypoint, and missed a way to find it without the Navball? This places a visible marker. Addon Version Checker: Alerts you when a mod update is available. Kerbal Inventory System: A mod that allows your engineers to modify craft in flight. For instance this allows you to add new experiments to landers. Chatterer: Purely for the mood. This adds radio communication sounds to your crewed vessels, and beeps to probes. If you're going to install a huge amount of mods, you'll likely want to use ckan, but as it broke several mod installations for me (for instance chatterer after the new voice for Valentina was added...), I personally do not use it, and rely on the addon version checker instead. If you like eyecandy and you have a fast GPU, you can install Astronomer's Visual Pack. This nevertheless is easiest to do using ckan. Edit: Descriptions

I'd distinguish between using MechJeb for data readout, maneuver planning, or as an autopilot. For me an autopilot is something that takes away a lot of fun, as I enjoy the thrill of flying crafts manually (think: adrenaline rush when docking large station parts). If I'm using RemoteTech signal delay, which makes an autopilot mandatory for unmanned crafts, I still prefer kOS to MechJeb, as with it I'm still the one in charge, as it's my code running on the kOS interpreter, and not the code of the geniuses who write MechJeb. To plan maneuvers, I personally use a spreadsheet. For me it's way more fun to calculate stuff myself, instead of just using the results of MechJeb. And last, but not least, data readout. This is the one function of MechJeb I'd actually consider using, if there wouldn't be VOID, which does basically the same thing, but in a visual representation that better suits my taste. With 0.90 I've been playing without data readout mods, as I wanted the "stock experience", but after building dozens of crafts and always checking wet and dry mass by manually emptying the tanks, it got boring. For this reason I installed VOID again when starting a new save for 1.0.X. (In 0.23.5 I did an Eve return mission without data readout mods. There was no mass readout in the VAB, so I added up part masses in a spreadsheet manually. Those were the times...) On the question, if MechJeb is cheating: It's a single player game, you can make (and break) your own rules. If you don't like piloting, go install an autopilot (or write one yourself either using the modding API, kOS, or kRPC). If you don't like fiddling with maneuver nodes, install a maneuver planner mod. If you got fed up with manually checking the dry mass of your craft, install a data readout mod. It's all up to you.

Just to toss in the word: Oberth Effect. This effect is the reason why it's more efficient to burn directly from low orbit into the transfer. Shameless self-quote:

Distant Object Enhancement. The old thread has more screenshots.

True, but a small note: While for nVidia the open source driver is indeed 3rd party, as nVidia didn't care much about them up to recently, the AMD open source drivers are to a huge extant written by AMD employees, what also explains why they work very well, even better than the closed source drivers (which are actually ported over from their Windows drivers, which aren't that great either...). You're right! Sorry for giving outdated information. This variable has actually been removed in Mesa 10.3. As I haven't been using it recently, I didn't notice. On exotic hardware installation can be difficult. Quite often there are firmware bugs that don't affect Windows (as manufacturers of course test Windows) but cause other operating systems to fail to boot. A typical example would be a faulty ACPI table, but there can be severely worse firmware bugs as well. While the Linux developers tend to include so called quirks to work around those bugs, of course they first need to know about the issues, and it might take some time to figure how to deal with a certain problem. What might help to diagnose your issue would be if you booted up with a custom kernel command line (the thing where the nomodeset option would go), without the "quiet" and "spash" options. This way you'll hopefully see some text output of what the system is doing, and where it stops. If even that doesn't work, try the nomodeset option in addition (don't worry too much about it, proprietary GPU drivers don't support kernel mode setting anyhow, and if you're using an nVidia card, you'll definitely want to install the proprietary drivers.). Another option you could try would be "noacpi", but beware that this disables most power saving features and should only be a temporary workaround until you find a proper fix for your issue. Well, Gentoo is one of the two distributions I recommend for advanced users, the other one being Arch. Gentoo is rolling release as well, but it's by far not bleeding edge, as long as one stays within the stable branch. Nevertheless, as Arch it requires some knowledge about how a Linux system works, therefore it's definitely not suitable for beginners.

Depends on the driver you're using. With the craprietary drivers I have no idea, as they are so buggy, I wouldn't touch them wearing a hazmat suit. The open source drivers have an environment variable: GALLIUM_MSAA, which you can set to the desired MSAA-Level.

What you're suggesting, CaptainApollo, is ignoring Oberth effect and therefore wasting quite a bit of fuel. Here's what I'd do for a one-way Duna mission, step by step: When building the probe/lander, plan ahead if you want to do a powered landing, or if you want to rely on parachutes. I'd do the latter, as they'll help you keep your craft oriented, but you'll either need about five times the number of chutes you'd use for the same mass on Kerbin, or the RealChute mod. It's of course also possible to do a combination of parachute and powered landing, relying on chutes to eat away most of the velocity and to keep your craft stable, but to kill the last bit of speed by doing a short burn right before touchdown. I don't know about 1.0.4, but in 1.0.2 heatshields were optional on Duna when landing from a low orbit, as atmospheric entry happens at relatively low velocity. Calculate (of course with taking Oberth effect into account - see below) or look up the required change in velocity (Delta-v, or dV), and build your craft to have enough fuel for this using the rocket equation or a mod that displays available dV (I recommend VOID). Beware that most dV charts already take into account Oberth effect, so if you first go to escape velocity, and do a second burn in kerbolar orbit, you'll probably run out of fuel. Also, for transfers to planets with inclined orbits (luckily Duna has negligible inclination) you should also take into account the dV needed for the inclination change. Calculate or look up the phase angle for a transfer between Kerbin and Duna, or just install either Transfer Window Planner or Kerbal Alarm Clock. For a transfer to Duna usually circular approximation is good enough. Calculation is rather easy, as the phase angle is just the angle traveled by Duna during the time the transfer takes (minus half a circle). First, we'll need the time our transfer orbit takes. The orbital period is given by T=2*pi*sqrt(a^3/GM), where GM is the standard gravitational parameter (in this case of Kerbol, so it's 1.1723328e18 m^3/s^2), and a is the semi-major axis of the orbit. This formula can be derived by setting centripetal force (m*omega^2) equal to gravity (GM/r^2). As for the transfer the periapsis is at the orbit of Kerbin, and the apoapsis at the orbit of Duna, a is given by the average between the semi-major axis of Kerbin and the semi-major axis of Duna, yielding 1.7163e10 m. With these numbers, our orbital period for the transfer orbit is 1.3048e7 s, or 151 earth days, or 604 Kerbin days. This is the orbital period, the transfer from periapsis (Kerbin) to apoapsis (Duna) takes half the time. Now we'll need the angular frequency of Duna. Here the same argument regarding forces can be used, the formula is then omega=sqrt(GM/a^3). Here we input the semi-major axis of Duna's orbit and of course again GM of Kerbol, yielding omega=3.6285143e-7 rad/s, or omega=2.078986e-5 degree/s. Multiplying the angular frequency of Duna with the time the transfer takes yields an angle of 135.6°. Subtracting a half-circle (180°) gives the phase angle of -44.4°. This tells you that the ideal moment for the transfer is reached, when Duna is 44.4° ahead of Kerbin. So, in order to hit the right spot, either get one of the mods I mentioned above, or look at the Kerbol system from above/below, center your view at Kerbol, and time-warp until the angle between imaginary lines Kerbol->Kerbin and Kerbol->Duna is about 44.4°. At the correct phase angle it's time to launch your ship. After bringing it to low Kerbin orbit, place a maneuver node and plan a prograde burn with the dV of the first burn needed for the transfer, maybe slightly more. If you're using a dV map, that's the sum of the numbers between Low Kerbin Orbit and Duna Intercept. Now move the maneuver node around your orbit, until the planned trajectory gets tangential to the orbit of Kerbin around Kerbol. Of course you could also calculate this ejection angle, but I've found that it's a waste of time, as dragging the node around works just as well. After having the node placed in such a way, look if you're already lucky and have an intercept. If not, the two markers "target position at intersect" and "closest approach" will be your best friends, as an intercept happens when these two markers are close enough. Check if there's are node-lines visible, and how big the inclination of your plotted course is with respect to Duna's orbit. If the inclination is large (I'd say above 0.2°) try placing a maneuver node at the nodeline and to correct the inclination. If that gives you an intercept: bingo. If not, I'd play slightly with the first maneuver node (the one placed on LKO), by slightly increasing or decreasing the dV number. If you cannot get an intercept, check the phase angle again. If it's too early, wait a few in-game days and try again. If it's too late, you'll probably need more dV for the initial burn. Once your ship is on the way, check its trajectory regularly. I'd have a look after about half the transfer, and if necessary do slight corrections. Apart from maybe inclination changes, these correction burns should usually just take a few m/s. You should also consider to fine-tune the target-orbit around Duna already quite some time before entering Duna SOI. Early course corrections are more difficult, but if carried out correctly usually take less dV. After entering Duna's SOI, make last course corrections if needed. I wouldn't aerobrake in 1.0, but rather first enter an orbit around Duna. I'd aim for a rather low orbit, maybe 10 km above the edge of Duna's atmosphere. For landing with parachutes, I'd do a deceleration burn to bring periapsis to about 30 km or so, maybe even lower (I haven't been to Duna with stock atmosphere in 1.0, only with FAR, so this is an educated guess based on the pressure data given on the Wiki) and try to keep the heatshield (if present) pointing front. I wouldn't fire the parachutes until the probe/lander has slowed down to about 300 m/s, except if the ground comes dangerously close. Below 10 km you should get serious deceleration due to atmospheric drag, so there should be plenty of time to open the chutes. If you don't use chutes, I'd first test the lander on Kerbin. Of course unmanned, as Kerbin has a higher gravity and you'd need a higher TWR for a successful landing. The reason is, that you'll need to make sure that your lander either is aerodynamically stable during descent and has the engines pointing forward, or that you'll have at least enough torque to orient the lander this way when needed. If you can control your lander at 10 km above sea level on Kerbin, it'll probably also stay under control everywhere on Duna. Edit: On the Oberth Effect. I just found that the Wikipedia article on Oberth effect is not very descriptive, and I think that adding an example will help to illustrate. For this, let's start from a circular low orbit around Kerbin. Our orbit has a certain radius r, and our ship has a certain velocity v0. We already used the formulas on the Wikipedia article on Hohmann transfers to calculate the dV needed to enter the Hohmann orbit to Duna (let's call it dVh), but that number applies only if we are already free of Kerbin's gravity. Naively one might now think, that one could simply add the dV needed to escape Kerbin to the dVh needed to go into the Hohmann transfer, but the situation isn't that easy. Thing is, there's the principle of conservation of energy, and energy is the quantity we can add here. Let's assume we burn and add to our current velocity v0 an additional velocity dV0. The kinetic energy of our ship after the burn will then be m*(v0+dV0)^2/2. In addition, we sit in Kerbin's gravity well, adding a (negative) energy of -GM*m/r, where GM is the standard gravitational parameter of Kerbin. After we leave Kerbin's gravity well, we would still like to have enough kinetic energy to enter the Hohmann transfer, so we'll need a kinetic energy of m*dVh^2/2. This gives us the energy balance: m*(v0+dV0)^2/2-GM*m/r=m*dVh^2/2 The required dV for a burn using Oberth effect can now be found by solving this equation for dV0. (I'm not sure if this is really correct. Please notify me if there's a mistake, I'll fix it asap.)

Scott Manley, one of the more famous KSP youtubers, made a nice . Beware, it's really, really long, and to be honest I haven't watched it, but from what I've seen of his works, they should be very extensive and include some actual science.

I disagree for AMD cards. My experience is that the proprietary AMD drivers are a *beep* of *beep*. Of course, if you're OK with micro-stuttering, tearing during video playback, graphics glitches, regular crashes, the complete lack of desktop integration (ok, switching resolution works, but try disabling a monitor without X-server restart), no support for VAAPI or EGL (= no up to date Gnome 3 desktop) and ugly font rendering in exchange for maybe a 50% increase in fps, then go ahead and install them. When using an up to date open source radeonsi driver stack with an R9 or one of the faster R7 cards KSP is purely CPU limited, unless one uses visual enhancement mods. But back to topic: I'm running 64bit KSP on Linux, simply because when I bought KSP it was much easier to get 64bit software working flawlessly on my distribution of choice (Gentoo). Although this is no longer an issue (Gentoo got full multilib support meanwhile), I never really spent a second thought about trying to run the 32bit version.

I'd say: Worry not. I've been using a gamepad to fly my craft since I don't remember, and that's way superior to keyboard. But, to be honest, an additional keyboard doesn't hurt, for action groups and such. But again, to be fair, I've seldom used more than 4 action groups, and those could for instance be bound to the d-pad. I'm using the Wiimote Classic controller, but I've also tried to play with a DS4 and the game plays excellent with both. For building craft, there's a very well working touchpad on the DS4. The CPU power of the PS4 isn't that bad. Each single bulldozer module may be slow due to the low clock rate (1.6 GHz base clock, but under load it clocks to a higher frequency, which we actually can only guess, as Sony afaik never revealed the maximum turbo core clock rate - speculations are it's 2.75 GHz), but it has 4 of them (or 8 cores, if you prefer AMD marketspeech). I'm absolutely certain, that SQUAD wouldn't think about a PS4 port, if they wouldn't already have multithreaded physics up their sleeve. What this means is obvious: An incredible performance boost on the PC! And also, very likely acceptable performance on the PS4, probably comparable to what you get on "high end" AMD hardware on the PC right now (depends on how well the calculations scale with number of threads, but Newtonian physics usually scales very well). If one doesn't like DS4, one can always plug a keyboard and a mouse. You know, the USB ports on the PS4 aren't decoration. The only thing needed to get mouse+keyboard working is support in the game, and I would be very negatively surprised if the standard input on PC would be disabled on the console for no reason. Nevertheless, I do have two negative points: Mods. I feel kind of sorry for people going to play KSP on the PS4, as they will, if at all, only have a very limited number of mods available, and I guess all of those mods will have to go through an inspection by Sony before they can be released. Probably not many mod authors will want to waste their time with this process. Fonts. The UI is currently optimized for sitting close to the screen. There are several threads here where people complain that text in KSP is hard to read when playing on a TV screen. I'm curious how the port will display stuff, as there is significantly less space on the screen available when a bigger font size is used. For us PC users I think not much will change, apart from performance improvements. For instance I don't see how adding additional keybindings for a DS4 would negatively impact our keyboard bindings. Also, I don't expect the UI on the PC version to change, at best those of us who play on TV will get an additional option for a bigger UI (if code of the company doing the PS4 port flows back upstream...). Edit: There's another thing that troubles me more: I don't think that the fraction of console users interested in a game like KSP is as large as the fraction of PC users. Is there a market for it?!? Edit 2: Regarding the company contracted for the port: They will likely "just" have to adjust UI and input. Platform specific bugs should be rather minor, given that the PS4 OS is based on BSD. On the other hand, their current product lineup is less than convincing...

Today I failed my first crewed Eve mission with realistic aerodynamics (FAR). Although I thought my ship would be stable in both directions, it wasn't. At about 65 km altitude it started to turn, and my reaction wheels didn't supply enough torque to counteract, so it was in the end ripped apart by aerodynamics forces. While I would have given the mission a chance of success of about 1/3, I honestly would have expected to loose the ship due to non-level ground, and not due to aero forces... RIP Matrix Kerman... On the brighter side, my Gilly mission is still running perfectly, with plenty of spare fuel I think I can still do a few "landings" before heading back home to Kerbin, and the non-crewed Eve probe lander, as well as the SCANsat probes are getting tons of science.

Well, I found that there are sometimes "stars" visible that move, and that much faster than any natural planet/moon. Yesterday I tried to "track" one by zooming out and in, but no matter what I did, it stayed just a pixel big or disappeared altogether. It could of course be an asteroid on a very elliptic orbit (they're called aster-oid, as they look like a star when viewed through a telescope, as they stay point-like, no matter how big the magnification), but I was in the orbit of Gilly when I saw it in a southern direction, and afaik there are no asteroids near the Eve system. My theory is that it's either a bug with the skybox, with distant object enhancement (no, it doesn't show a name on mouseover) or Texture Replacer. Non-Player ships would be the last think of as explanation..

There's one thing that bothers me slightly. Not that I'm afraid police will show up and arrest all Linux 64bit users, but in order to make KSP capable of addressing textures in memory above 4GB (think: modded installs), Linux 64bit users need to manually edit the Unity Player executable (see the Linux Thread) using a hex-editor... As far as I understand the EULA (which luckily is null and void where I live), this is actually forbidden, right?

If one doesn't care about the sciency aspect of sending various engines to Eve to test them under "real" conditions, the stage information window of the VOID mod can display sea level performance data for any planet (dV, TWR,...) in the VAB, so figuring the I_sp for engines on Eve should be a trivial task with this mod (as dV is proportional to I_sp -> build a small rocket, take vacuum I_sp, divide by vacuum dV, multiply by Eve sea level dV, profit). As I neither have aerospikes, nor the NASA engines unlocked, my choice for the bottom stage is the Mainsail. I haven't tested my lander design yet, it's still on its way to Eve...

To be more precise, Debian per default installs only open source software, but it does ship closed source software as well. That's especially important for users of AMD graphics cards and broadcom network cards, as the open source radeon and broadcom drivers requires non-free firmware. So, to get the open source radeon driver to work with 3D accelleration, one needs first to enable the contrib and non-free repositories in sources.list, update the list of packages (there's a refresh button in synaptic, or on the command line run "apt-get update" as root), and install the firmware-linux-nonfree package ("apt-get install firmware-linux-nonfree", again as root). (As said, if you have a Southern Islands card, forget the open source radeon driver on Debian 8 until this bug gets fixed, as it will crash regularly.) Enabling the contrib and non-free repos will give you extremely easy ways to install the proprietary drivers as well. For AMD you'll then have packages named fglrx-driver and fglrx-control available, and for nvidia there's nvidia-driver (or some nvidia-legacy-*** packages for older drivers for older cards). For AMD cards it might be necessary to run "aticonfig --initial" as root after installing the proprietary drivers. A word of warning: On all distributions that have their own package managers, it's in nearly all cases the best to install software from the repositories, even if it's older than software found on the vender website. The reason is, that if you install software from the repositories, there's usually a way to cleanly uninstall it again, as it uses the native package format of the distribution. If you download an installer from somewhere on the web (ok, let's be clear here: I'm talking about the AMD or nVidia graphics driver installers) there might be (for the graphics drivers: there is) no clean way to uninstall the software again. This might (for the graphics drivers: will definitely) cause issues when upgrading the distribution to a newer release.

Regarding proprietary drivers, the situation as far as I see it from my experience: Intel only has open source drivers, and sadly they aren't on par with their proprietary Windows drivers... nVidia open source drivers aren't really usable, as nVidia isn't involved in their development. So, if you have an nVidia card, the proprietary drivers are the way to go. They are about as fast as their Windows drivers, from what I've read (can't judge, don't have nVidia or Windows) AMD is the main developer of the open source radeon drivers. The reason they are not as fast as the closed source AMD drivers have something to do with third party intellectual property that AMD mustn't disclose, so they had to write around some things they could use directly in their proprietary drivers. On the other hand, the current proprietary AMD drivers, as fast as they might be compared to the open source drivers, are like an anthill: full of bugs. So, if your GPU is fast enough, for AMD the open source drivers are way better regarding stability and desktop integration. With one exception: The open source AMD drivers are currently broken on Debian 8, at least with Southern Islands cards. Here's the bug report. So, on Debian 8, if you're using an AMD Southern Island card, you'll have to use the proprietary drivers, or install a fixed mesa package manually, but that's a thing I wouldn't recommend a new user to do. So, to install the proprietary AMD drivers on Debian 8 (they don't work with Gnome 3 btw), check the Debian Wiki. Edit: Emacs

Regarding installation: You should be able to install Linux to a USB drive just the same way as installing it to a HDD. For Linux both are just block devices, and modern BIOS (but not EFI) treats them just as HDDs. So, I'd take two USB drives (or one DVD and one USB drive), where one of them will be made into an installation medium, and the other will be the target of the installation. There are several things to look out for though. If your computer is new enough to use EFI firmware, you have to be careful about which firmware mode you're using, EFI or BIOS. For a bootable USB drive I'd use BIOS mode. The reason is, that for booting in BIOS mode the firmware always reads the drives boot sector and if there is bootable code there, it will allow you to boot from it, while for EFI there exists a list of bootable entries within the firmware's own storage in addition. While I don't think that an additional boot entry in EFI would really create troubles, using BIOS mode is the safer solution, as this way the computer's EFI configuration remains untouched. Otherwise a boot entry for Linux would be added to the EFI configuration, and I'm not certain how well that'd work if your USB drive isn't plugged. For most Linux installers it depends on the way the installation medium is booted, whether or not it'll use EFI mode. So, to be on the safe side boot the installer in BIOS/legacy/(anything that isn't EFI) mode. If your computer no longer supports BIOS mode, you might have to tell the Linux installer to use the main HDD's EFI partition, but I'm honestly not sure about this. You'll want full control over partitioning and bootloader installation. There's nothing worse than accidentally messing up your main HDD because the Ubuntu an oversimplified installer thinks it's smarter than you. If there still were something as an Alternate installer for Ubuntu I'd advice to use that, but sadly support for it was dropped in 2012, so you're either stuck with using a distribution not based on Ubuntu, or be very careful to select the manual partitioning option ("something else") on this screen, and to select the USB drive for bootloader installation on the partitioning screen (which will likely NOT be sda if you haven't unplugged your HDD - on Linux hard drives are nowadays named /dev/sd[letter][number], where [letter] denotes the drive, and [number] denotes partitions.). While partitioning create the required partitions on the USB drive. For a simple setup it's probably enough to just make one big partition with "/" as mount point (that's no way optimal, but read on). I wouldn't create a swap partition on the USB drive, but rather later place a swap file somewhere on the HDD. If you want to learn about partitioning for Linux, I can recommend Appendix C of the Debian installation guide. (Or Appendix C of the Ubuntu installation guide, which is obviously exactly the same, except that they replaced the word "Debian" by "Ubuntu". Don't waste time on reading the rest of the Ubuntu installation guide, it's horribly outdated. For instance the debian-installer has been replaced by ubiquity in 2006 or so...) Before writing your partitions to disk, make sure that they are going to be on the USB drive, and that the bootloader is going to end up in the MBR of the disk containing the /boot partition. So, if your /boot partition is /dev/sdb1, the bootloader should go to the MBR of /dev/sdb. If your /boot partition is going to be /dev/sdc4, then the bootloader should go to /dev/sdc. If you haven't made a separate /boot partition, but just a / partition which for instance could be named /dev/sdb1, the the bootloader goes to /dev/sdb. So, here is what I'd do, step by step. Don't blame me if anything goes wrong, this is just how I think it's done, but I haven't tried this myself. First: Backup all your important data, or do the installation to USB at a computer that doesn't have anything important on it. Second: Seriously, create backups. While of course there will be no data lost if the installation is done correctly, it's always possible that one hits the wrong button and accidentally formats the wrong drive. Make sure you have a Windows installation medium around. If you accidentally overwrite the bootsector of your HDD or mess up the EFI config it will help you make windows bootable again (although I'll not be able to help you with this, as I'm no expert on Windows). Next, get an installation image of the distribution you want to use. Xubuntu is a good compromise between speed and usability and it's easy to install, so let's get that one. With *buntu it's nearly always the best to use LTS versions, as versions in between just get 9 months of support and are usually less stable, so I'd download Xubuntu 14.04 LTS 64bit. Burn it to a DVD, if your PC has an optical drive. It's still the easiest way to use it. If not, create a bootable installer USB drive. Consider unplugging your HDD. If it isn't plugged, it can't be accidentally formated. Boot from the just created installation medium. If your computer supports EFI and legacy/BIOS mode isn't disabled in the EFI config (if it is, enable it...) it should show you two boot entries: One with EFI (or UEFI, or similar), and one without, or one with BIOS, legacy, or similar, and one without anything. In the first case, select the entry that isn't EFI, in the second, select the BIOS/legacy entry. Boot to the desktop ("Try Xubuntu without installing"). Now let's find out the device node for the USB drive. Open a terminal window (there are other ways, but that is probably the most simple) Plug the target USB drive to a free USB port. Run "dmesg | tail". This command will show you the last few lines (tail) of the kernel output (dmesg), the | character means: take output of left command as input for right command. It should show a line like "[12345.67890] sd 11:0:0:0: [sdb] Attached SCSI removable disk". You'll care only about the part where in my example it sais "sdb". That's the device node our just plugged USB drive got. We'll try to only edit this one drive. Of course in your case it can be any other sd* name, depending on how many drives are currently connected. (As said, sda is the first HDD, sdb the second, and so on, while sda1 is the first primary partition on sda, sda2 the second primary, sda5 the first logical and so on.) Now, start the installer (there's an icon on the desktop). On the screen that asks about partitioning, select "Something Else". You'll now see a list of all connected drives (which should include usb drives). Only edit partitions on the drive determined in step 11. You can also open the dropdown menu for bootloader installation, which will show you the drive names, just to be sure that you're editing the right drive. I'd delete all partitions on the USB (there should only be one, or none at all) by selecting them and pressing the minus button. If there are no partitions on it, select the drive and click "New Partition Table". If it asks you if you wang GPT or MBR stop. You're using EFI, not BIOS mode, if this question pops up. Back to step 7. Or continue, and hope that EFI is smart enough not to break when you remove the USB (it very likely is smart enough, I'm just paranoid.) Now you should see the drive name, with "free space" below it. Select the free space. Partitioning depends, whether or not you're installing to a USB pendrive, or a USB HDD. On a USB HDD it might make sense to create a swap partition. Think of it as a warranty: If the RAM gets full, this space can be used to remove unneeded data from RAM and store it until it is needed again. As on HDDs the innermost part is the fastest, and swap should be fast, let's first create a swap partition by pressing the small plus button. At the "use as" drop down, choos swap space. Choose to put it at the beginning of the free space. Ask five Linux users for optimal swap partition size, and you'll get five different answers, but in my opinion twice the size of your RAM is a good number. Still, if that's too much for your taste, half your RAM should be fine as well. Pendrives are painfully slow. Putting a swap partition on them will likely have a negative impact on performance. Nevertheless this means that if RAM gets full, programs will be force-closed. For this step by step guide we'll create just one data partition. As written above, appendix C of the Debian manual explains partitioning for Linux in more details, but as this is a single purpose KSP stick, separate partitions make little sense. We'll use all available memory. Create a primary partition in the free space, beginning or end doesn't matter. As mountpoint select "/" from the dropdown menu. File system is a good question. Ext2 is faster on USB, but Ext4 gives better data integrity. I'd use Ext4. [*]Check the drop down menu for bootloader installation. You'll want it in the MBR of the USB drive. So, if it said "sdb" in step 11, and the dropdown list also sais that sdb is the USB drive, choose "sdb". Choose the USB drive itself, not the partition just created. [*]When pressing the Install Now button, the installer will complain about the lack of swap space if you didn't create a swap partition. Let's ignore this for now. You can still create a Swap file on your HDD later if you want to. [*]The system will now be installed to the USB drive. This will take some time (or, on pendrives a long time, as most pendrives are rather slow when writing). [*]While installing, the installer will ask you to choose the default keyboard layout, your timezone, and will allow you to create a user. [*]When the installation is finished, just reboot. You should now be able to tell your computer to boot off the USB. Regarding the installation of KSP on Linux, please see the Linux thread. An even safer way to install Linux to a USB drive is to use a virtual machine, as this will not expose your EFI and HDD. I'm currently installing Xubuntu to a USB drive this way, just for fun and to see if it works. For this of course one has to pass through access to the USB device the system should be installed to, and then boot the VM from the installation .iso. As I don't know how to use any Windows VM software, I sadly cannot give a step by step guide here, but I'm sure you get my point. I'll report once that's finished if it worked. Edit: It indeed works to install Xubuntu to a real USB drive from within a virtual machine, by passing through direct access to the USB device.

I've one casualty caused by a "forget that, I'm sure it will fly" attempt to build an ultra-lightweight plane, one Kerbal died because of reentry heat in 1.0.0, and three Kerbals that exploded together with my 150000 funds Eve ship when due to aero forces and too high thrust an engine decided to break loose and shoot directly through the hitchhiker container... I try to keep Kerbals alive as much as I can, and usually perform missions with probe cores instead. But there are things a probe core can't do. Manned landings for instance ;-)

I sent my GPU for warranty repair, as one of the fans started to make strange scratching noises. Now I'm stuck with a borrowed R7 250X, and as I have grown a profound hatred toward the proprietary AMD drivers, I'm currently running this anyhow not so powerful GPU with the open source Linux drivers. To little surprise Environment Visual Enhancements is a bit too heavy for it, but after uninstalling this and the related mods, I've got KSP running more or less smooth again at otherwise maximum graphics settings. Ingame, I did two sat contracts for polar orbits of Kerbin, with about 160° inclination change in between. Good that my standard contract sat has more than 4k dV... I also rescued a Kerbal from LKO, and did the inclination change course correction for all ships currently on their way to Eve. Apart from the SCANsat for Gilly, they are all on their final trajectory, the next burn will then bring them to their desired orbits. Then the fun things will start...

Let's see, what Scott Manley has to say about the LV-Ns in 1.x...

For me: The stock 0.23.5 Eve return mission, that would, in principle have been able to launch from sea level. It was a 3 kiloton monster of a ship, far from optimal, and it lost several tanks and engines upon landing (who needs landing legs if you have perfectly fine engines?!?), but still made it back to orbit. It was a multi-ship mission, including a crew vehicle that brought Kerbals to Eve orbit and back, the "lander", and a rover that doubled as a short range boat, in order to get science readings from both, land and sea. The mission furthermore included several refueling missions in low and high Kerbin orbit, and in low Eve orbit as well. I did use quicksaves on that mission though, and landing took several reloads...