Zeiss Ikon

You're a young feller, aren't you? That came out when MTV was still reasonably fresh. Over the weekend in my stock + Better Burn Time career, Adeny was tapped to take new crew/propulsion modules to Kerbin Station Alpha, after it was discovered that someone forgot to install docking ports on the outer ends of the modules -- rendering it impossible to dock with the station once the modules were attached. On the way up, he docked with one of the (unstabilized) modules that had been left in orbit on an early (failed) attempt to provide Lufrid with some means to change her orbit, and deorbited it. The plan is to do the same with each of the discarded modules that he's replacing, as well, though that plan may be subject to change (depending how much monopropellant he can bum from Lufrid to let him catch the first one -- he'll suck that one dry to be able to dock with the second). This relatively new policy, to avoid leaving junk in orbit so far as possible, was prompted by reports from multiple crews of spotting debris inside 100 km during launch or parking orbits, and reports from Lufrid (backed up with photos) of debris coming within 45 km of her station when she was at "just above [biome]" altitude . Now, LKO insertions are intentionally underburned to ensure the booster reenters, allowing the next stage to finish circularizing; modules that can be captured/docked are deorbited as available dV/monopropellant on other missions permits, and program administrators (in between arguing over who'll buy the next new coffee machine for their tiny offices) are discussing the possibility of ordering research toward a method of capturing discarded stages that lack docking ports so they, too, can be deorbited.

This thread is making me very nervous. ITAR is no joke, at least for Americans. Technology sharing can be a very serious legal problem, even when the recipient is in Canada or UK.

Or are you building a cruise missile?

I'll second that -- I'm running 64-bit KSP in 64-bit Linux, and it seems rock solid. The only time I've had problems is after playing for (literally) five or six hours in a single session. And if I need to, I can use all 16 GB in my recently upgraded desktop machine.

If life worked that way, I'd have won the Powerball or MegaMillions at least a couple times by now. I spent Sunday rebuilding my computer -- new motherboard, AMD FX-8350 (8 cores/8 threads, up to 4.2 GHz turbo), 16 GB RAM -- and then installing a new version of Ubuntu (because my old version had gotten fouled up by what I think was a bad update). Given I'm doing this on vacation (the only time I have enough hours all together to do this kind of work), I'm using a USB wifi dongle for connection, and I'd forgotten that the one I own is, um, a little flaky. As in, after being connected for a while, throughput drops to zero and I have to disconnect and reconnect. Do that a few (dozen) times and I have to restart the router to regain connectivity. Doing this in a rented beach house is annoying in a way it could never be at home (where I use a wired connection on this machine, because of the bad wifi dongle). That said, I've got pretty much everything back up except a couple installations that require a reliable, high-throughput Internet connection (I'll get those done when I get home). Only thing still not working is my email -- same client I've used for the past (are you sitting down?) twenty-four years, and I've set up new after system upgrades/reinstalls/switches at least a dozen times. This time, all settings were preserved, except for having to change the file paths for stored e-mail and the new version of SeaMonkey browser putting all my bookmark toolbar entries down in the bookmark menu with no hints how to get them back where I'm used to seeing them. I also figured out an efficient way to run the same KSP save on two different machines (at least for Linux): install the same version/mods on both machines (the only mod I use in Better Burn Time), and make the "saves" folder a symbolic link to the actual folder, which resides in the local folder for my Dropbox. Dropbox daemon syncs all three folders continuously, so as long as the Dropbox icon shows "up to date" when I point to it, I'm good to go. And yes, KSP does run much better on this machine. Despite all the warnings in my other thread about Intel processors beating AMD for all instances involving single-thread tasks, my old Intel (Core2Quad) was an old enough design that its work-per-clock wasn't much if any better than the AMD I could afford (yes, I'd rather have had a four-core i5 or i7 to get the same 8 threads, and got similar or better KSP performance at 3.5 GHz, but those cost 4-5 times as much). Given my clock is now at least 1.5x what it was, and I'm not getting the thermal throttling I've been seeing on both my Core2Quad and my Core i7m (2 core, 4 thread) laptop, while I haven't banished the yellow clock, I no longer have the freezes where the CPU clock is scaled back to a few hundred megahertz while the core cools down. A smooth game is much more playable -- no longer having the burn clock pause 20-30 m/s from the bottom of an 800 m/s burn makes a huge difference in my ability to make accurate cut-offs. Same goes for when I'm trying to maneuver in a limited time (like turning a long, heavy launcher core to the node before I need to start my circularization burn). So, with the new machine running the same save I've been playing on my laptop, I haven't gotten any screenshots uploaded (see above about connectivity issues), but Val did successfully carry three tourists to Munar orbit, dock with Mun Station Alpha, and collect a rescued engineer who'd been taken in by the station itself (station has considerable maneuvering capability, with four Puff engines, RCS, and a docking port in the cupola) -- then ran short of fuel on the way home; a rescue craft was sent up (also carrying a VIP tourist who only wanted to orbit Kerbin) and arrived with just about enough fuel, combined with what Val still had, to push the two docked craft into a reentry. For safety reasons, the two craft remained together until reaching parachute deployment conditions (game deletes a craft in atmosphere if it gets out of physics range from the one you're flying). Funds gained from those missions and a double rescue in retrograde Mun orbit went to making the final upgrade to the Space Plane Hangar; KSP is now fully upgraded except for the Admin Building (which is still in original condition -- got to keep those bean counters under control). Sufficient margin existed to send up a pair of modules for Kerbin Station Alpha to give it similar propulsion and maneuver capability as Mun Station Alpha -- 12 Oscar B tanks and four Spark engines, plus the same RCS quads and tanks as on the Mun Station Alpha crew modules. Recent rescue Jorlan, after insisting on a redesign of the module lifter (to push both modules rather than stuffing them in between the command pod and transfer stage as was done with the Mun Station modules), successfully docked both modules in the dark -- then realized, when the station/tug combination orbited back into sunlight, that one module was misaligned, so will need to undock and realign so that the Sparks won't spin and tumble the station when used to maneuver.

Like a lot of people, my first exposure was on YouTube. I'd seen videos come up in suggestions for a couple years (game's been "accessible" for almost five years now), probably because I watch SpaceX and aircraft-related videos. Eventually, I clicked through on one, thought it was kind of neat, and went back to the rabbit trails I'd been chasing. It wasn't until I found Scott Manley's videos, realized that this wasn't just about launching rockets, it involved actual orbital mechanics, interplanetary missions, that I decided to try the game. I found it on special at the main web site (which was good, because I never bother to search Steam for games -- very few of their offerings have Linux-native versions), bought it, downloaded it -- that was September 2016.

@invision Not yet -- vacation is next week, I'll build it Sunday or Monday. Mine is a Franken-PC, too -- I've continuously upgraded from my Laser 286, purchased in 1990. Been through 286, 386, 486SX, 486DX, a forgotten string of Pentium generations, AMD a couple times. Seen Windows 3, 3.1, 95, 98, XP, and then jumped to Linux (MEPIS 11, then Kubuntu 14.04). Still got the original 1.44 MB 3.5" and 1.2 MB 5 1/4" floppy drives, though they aren't hooked up (last motherboard didn't have a floppy connector) and I doubt they'd work if I could find a diskette to put in them (too full of dust).

Today, I finished up my last open rescue contract -- Adeny went to retrograde Munar orbit and collected Monie from her stranded Mk. 1 Command Pod (previously, he'd rescued Lufrid from LKO, and collected Samcal from a prograde Munar orbit). Females now outnumber males on the pilot list by four to two. After returning her home, I launched the second module for the new Munar Station Alpha. Jeb insisted on being allowed to fly this one -- he hasn't been back to the Mun in quite a while. This new crew module has a little bit of a quirk -- once the transfer stage is jettisoned, it has only RCS, with two roundified tanks plus the 10 units in the Mk. 1 Command Pod. It had seemed this ought to be plenty for matching orbits 200+ km above the Mun, but I'd forgotten the thirteen degree inclination of Mun Station Alpha -- after dumping the transfer stage on an impact trajectory and circularizing, there was enough RCS to make the plane change, and almost rendezvous. Fortunately, the station core has a 1.25 m RCS tank (and a set of four Puff engines, though they weren't necessary for this situation). Samcal managed to maneuver the station to dock with Jeb using only a tiny fraction of the monopropellant aboard -- and in the process, achieved a "World's First" docking at the Mun, as well as closing a contract to do the same. Still one more module to dock to complete the "build a station in Munar orbit" contract -- Jeb's staying over while Val flies the second crew module up (and you may rest assured she won't repeat Jeb's mistake); after docking the second stick of two Mk. 1 Crew Cabins to the single Hitchhiker, the station's permanent capacity will be 13, plus two command pods makes 15 -- and with all three pilots aboard, that contract will close. Once that's done, Jeb and Val will return to Kerbin (Mk. 1 Command Pod with two Round 8 tanks and a Spark behind the heat shield, and only the internal batteries after decoupling -- should be plenty of EC for the trip, as long as they remember to turn off SAS after each maneuver). Samcal will remain in command, for now. Rescuing is a lot cheaper way to recruit than hiring from the Astronaut Complex, but I'd probably have hired, if I could -- but when I went to the complex, there were engineers and scientists standing around, but not a single pilot in sight. They must have been snatched up by those other agencies (and some of them wound up needing a ride home). I did get one ugly little surprise as Samcal was preparing to go meet Jeb "Dry Tanks" Kerman; when the station core decoupled from its transfer/insertion stage (which I had left attached, hoping to refuel it and keep it with the station), what should have been its fourth Clamp-o-Tron Jr. remained attached to the fairing truss instead of the station core. Apparently, when you put a docking clamp on a bottom surface with an upward view, it stays in its "docking side up" position, despite appearing to surface mount just as it would in a radial position. Now I know; I'll invert the vessel to attach bottom clamps in the future. Fortunately, that clamp wasn't critical. I had intended to use it mainly for fuel transfer, secondarily for boosting with a tug (yet to be constructed) -- but I can still do both with the clamp mounted in the center of the cupola's "forward" window (hurrah for structural glass!).

Thanks, Snark. I'll try that next time I have the game open. BTW, Lufrid is a she -- in fact, all three of the Kerbals I've rescued recently (Samcal and Monie from opposite direction Munar orbits, as well as Lufrid in LKO) are female. I hope that doesn't say anything about their ability (on paper, same as Val, Jeb, and Adeny, one star), as two of them (Lufrid and Samcal) have been given command of the new stations in LKO and Munar orbit.

Edit:

Okay, so my first station was in orbit about 85 km above Kerbin. Kerbin Station Alpha is pretty basic -- two Hitchhikers and a cupola, with a pair of Clamp-o-tron Jr., some batteries, and solar panels to charge the batteries. On a whim, the commander went EVA and took an EVA report, which produced some useful science (because it was "above Kerbin's shores" or some such -- in other words, I was low enough for biomes on Kerbin to matter, which is a science realm I haven't touched). I'd love to get this science, since it'll be nearly free (just add some instruments to modules already planned for addition to this station -- barometers, thermometers, goo cannisters, etc., cheap and easy). However, there arises an issue, and will arise another: initially, how do I get the data Lufrid generated down to Kerbin so R&D can do something with it? The station has a high-gain antenna on one of the Hitchhiker modules, but it's not the one with the working hatch (the cupola and other Hitchhiker hatches are blocked by solar panels and docking port, respectively), and when I tried to immediately transmit the EVA report I was informed there was "no antenna within reach" or something of the sort -- and when Lufrid had re-boarded the station core and transferred to the module with the antenna, I couldn't find the EVA report to transmit. Longer term, once I can reliably transmit my science from Kerbin Station Alpha, have instruments, and have a scientist aboard, will that scientist be able to reset experiments from inside the station, or will he/she have to EVA (presumably within a certain distance of the experiment) to do so?

I'm perfectly able to "fly" debris -- either by switching with the bracket keys ([ or ]) when flying another vessel nearby, or by selecting in the Tracking Station and clicking the green "rocket" button below the object list. Obviously, debris that lacks a probe core can't be controlled in any way, but I can "watch" it (for instance, to make it burn up in an atmosphere pass that it would just fly through if outside physics range). However, if the object type has been set to something that's filtered out in the Tracking Station or map screen, you won't be able to see it on those screens (hence, not switch to it), but only visually from another vessel close enough to give an object marker against the sky.

I presume your concern is that you want your Pe to be in a particular orientation. You can't orient it relative to ground features on Kerbin, of course, because Kerbin rotates under the orbit ever six hours. You also can't orient to the sun (for any term longer than a few days), because Kerbin goes around the sun (hence, direction to the sun changes by 360 degrees) every 427 (6-hour) days. So, first, you have to define what you want to orient to (the fixed skybox? An ascending or descending node relative to some other body?). Once you've done that, you can set your new Pe by making a prograde burn centered on that location, burning until your Pe moves to your burn point -- or burn retrograde until your Ap runs around to your burn point -- then adjust your apses to the required heights with apoapsis and periapsis burns as appropriate.

@stibbonsI'll have to look at OwnCloud/NextCloud -- if it'll coexist with an in-use GUI, that may be the solution (especially after I get my desktop machine rebuilt, I'll have more RAM and more cores to spare the processing power). @RizzoTheRat No, no NAS. I do, however, have an old computer and will have reasonably functional (Core2Quad) hardware to install in it; hard disks are cheap(ish), so I might consider building that into a NAS. Loading the game from a NAS directly wouldn't be prohibitive; 150 Mb/s wifi is faster than original CD-ROM, and ought to load a couple GB of game data in, what, not much over two minutes. That still leaves an issue with remote access, though (even with sync, if the laptop isn't updated when I suspend it to leave home, I'd need to be able to load the game remotely), but OwnCloud/NextCloud may solve that problem. BTW, I'm plenty old enough (got my first computer in 1986, first DOS machine in 1987), just didn't have a need for Dropbox until the last couple years. I really think hubiC will do the job for me, though, once I get through the man page another couple times and get it configured.

Been playing for about four sixteen months (downloaded the demo in September '17, '16 -- time flies! -- bought the game in, well, September '17 '16), and I'm firmly at level 4. Haven't sent missions to Dres, Jool, or Moho yet, but I can visit Eve/Gilly or Duna/Ike any time, even with fairly low tech if needed. Rendezvous, docking, Mun landing/return, all routine, and I can judge remaining fuel well enough that I rarely strand a Kerbal (only one in the current career due to making one try too many to dock in a too-low LKO -- kept hitting atmosphere while trying to rendezvous).

I'm on my first career, still unlocking the 160 nodes in the tech tree (a couple more to go). At present, I have two flights active -- probably not coincidence they're my first two stations, both commanded by rescued pilots: one in LKO (pretty basic, doesn't even have maneuvering other than reaction wheel) and the other, still under construction, in Munar orbit. The contract for the Munar station will close when it has accommodation for 14 kerbals and three pilots aboard -- which will occur when the two crew modules are docked and their pilots still present. Munar Station Alpha also has significant monopropellant capacity, RCS, and a set of Puff engines for orbital adjustments (Kerbin Station Alpha is planned to gain maneuvering capability when it gets its own pair of crew modules, albeit with much more modest thrust from just the RCS quads on the crew modules). So far, I haven't done much with probes (other than using a Stayputnik to control the first orbital passenger flight, which used a Mk. 1 Command Pod to carry the tourist). That may change when I need to get science from further afield than Minmus -- though that'll be a while yet.

You do still get 500 MB of additional space for each referral who joins -- but I (literally) don't know anyone who uses a computer regularly who doesn't already have Dropbox. And I'd need at least two more referrals just to have the minimum space to put my 1.3.0 save up there. I may have solved the problem -- I found a cloud provider called hubiC (for hub-in-Cloud) who give 20 GB free. The bad news is, their Linux client doesn't have a GUI (Mac, Windows, Android, and iOS versions do), but the good news is, it background syncs like Dropbox -- I just have to read the man page enough times to figure out how to get it to auto-start (easy), sync the correct folder (seems reasonably clear), and do it often enough not to cause confusion (also seems clear-ish) -- all from the command line, in a bash script that I can set to run on startup. Down side is it's a French company, I see complaints on their international forum about getting notification emails in French (which I neither speak nor read, though I can eventually make some sense of the written form) -- and if I ever decide to pay for additional space, they take Euro, which will incur exchange fees on my debit card. An alternative would be if I could find a software solution to sync folders between the two machines when the laptop is on my home wifi -- but it needs to be a background sync, because otherwise I'll forget it at the worst possible time and seriously screw something up (like, say, erase a successful Duna landing). So far, AskUbuntu.com hasn't come up with any suggestions other than to spend $30 on software to do that. I'm a little shocked that it doesn't seem to exist in free form.

Google Drive probably works fine if you're on Windows, maybe even on a Mac (for those OS, there's an app that makes it work like Dropbox with their app, doing background 2-way sync in real time). For Linux, it appears, Google Drive is a problem, because there doesn't seem to be a way to set up bidirectional continuous auto-sync for an arbitrary folder, even though it's fairly easy to set up the Google Drive to look like a local folder. @RizzoTheRat You must have an older Dropbox, or something -- my free Dropbox account has a 2 GB limit. Even a stock install won't quite fit (and I've got half a GB of other stuff already in there).

Free flight models need to be stable "hands off" at all times -- yet those are the ones most likely to have been originally designed with lifting tail surfaces. Yes, they can be tricky to trim -- COM location is critical -- but it's done for performance reasons. Those performance considerations generally don't apply to our spaceplane designs (or even our atmospheric-only aircraft); we're better off with longitudinal stability, with a pitch-up moment from the surfaces offsetting a pitch-down moment from the COM (slightly) ahead of the static COL.

This is a common misconception. If you look at the designs for a lot of free-flight model aircraft, they're set up so the tailplane produces lift, and all canards are (it's common for a canard craft to have the COM foward of the leading edge of the wing, where with conventional layouts it's usually 30-50% of the way from the leading to trailing edge, not counting sweep). The critical point, for both canards and conventional layouts, is that the forward wing must fly at a higher coefficient of lift than the rear. This produces a tendency to pitch up as speed increases, or pitch down as speed decreases; this gives what's known as longitudinal stability. Now, the easiest way to do this is with decalage -- a little difference in incidence between the front and rear wings (whether that's canard pitched up relative to the wing, or tailplane pitched down). However, with high performance free flight (which spend most of their time aloft gliding, so L/D is very important, as well as minimum sink) it has often been the case that different airfoils would be used, so that with zero decalage the tailplane would develop less lift, relative to speed, than the wing -- not no lift, certainly not negative lift (because that requires the wing to generate more lift, which increases drag), just less lift. This way, the nose will rise and fall as needed with small changes in speed, but the tailplane is helping hold the tail up, rather than pushing it down. If you're mainly flying straight and level, a canard is actually easier to make stable than a conventional -- put your COM just ahead of the leading edge of the wing, then adjust the canard incidence to get a stable glide and use pitch trim to set level flight speed. Unlike a conventional, the COM location isn't very critical at all, and the canard will always be in a lifting mode (unlike conventional with decalage). For high-G maneuvering, a three-surface is a very good choice, if the surfaces are sized correctly relative to each other -- the COM can be exactly on the COL, and with both canard and tailplane contributing, the craft can maneuver like, well, a jet fighter. Stability, however, is likely to depend on a computer doing the actual flying, while the pilot just tells the computer where to go.

Dropbox does have a Linux native app that handles auto-sync. Don't know One Drive, but this solution (Unison plus google-drive-ocamlfuse to make my Google Drive look like a local folder) should work. Have to use an environment variable to give a stable host name, since the laptop gets used regularly on three different wifi connections (and very occasionally on a couple others) -- probably need one for the desktop machine, too, since it has a DHCP assigned IP address, so can change without warning.

With my two computers having (at present) very similar performance, I needn't worry about wanting to have more mods or higher settings on one than the other (that may change when I get the desktop machine updated, but it's the case at present). I'm not a big mod fan, anyway, though at some point I'd like to be able to play RSS/RP-0 with Scatterer/E.V.E./etc. eye candy, just to see it look like the real world and act like real rockets (I doubt I'll ever be able to afford a computer that can handle all of that, unless I keep a 2018 version and set of mod files for five years or so, and hope it still works with whatever version of Ubuntu I wind up with in 2023) -- playing old software on a current machine is the cheapest way to have the machine that can play with high settings). Also, I'd have to automate the two sync steps for every play session, else I'd forget to sync one way or the other. Using sync software would eliminate the overwriting in either case -- only files that have changed get copied -- but then I'd have to wait for the sync to finish after connecting the thumb drive, and again after closing KSP before disconnecting the thumb drive. Since I seldom spend time with my laptop in any location where I don't have wifi available, internet dependency isn't a big deal for me -- and because of the auto-sync, I'll have a complete local copy on both machines anyway, so I can still play on either machine in a dead spot, when my cable/wifi is down, etc., with problems only occurring if I want to play on the other machine before internet service is regained. @RizzoTheRat I had originally planned to use Dropbox, but my free Dropbox isn't big enough (2 GB, already stuff in it, and my install is closer to 3 GB than 2 GB in size); to get more space, I have to pay $10/mo (albeit for 1 TB, but that's many times what I need) vs. $2/mo for Google Drive to get plenty of space for my needs.

Jeb loses target on leaving his pod because the rescue ship is too far away. If he can't see it, he can't target it. A Kerbal on EVA can target a vessel, but they have to be close together (I've generally done it at distances of a fraction of a km). So, you need to get a closer rendezvous (less separation, less relative velocity) before Jeb makes his jump.

More generally, it's "mod"+F12. Which key is the mod key depends on your OS. As noted, that's Alt for Windows, right-shift for Linux, and I believe on Mac it's the Apple key (can't say for certain -- I have access to a Mac belonging to my partner, but I've never used it, much less installed KSP on it).

I'm in process of setting up to be able to play KSP from the same save game/install on both my laptop (where this 1.3.0 version install and save originated) and my desktop (previously hosting a 1.2.2 install, which will likely remain intact). I'm doing this in part to be able to directly compare performance between the laptop (Core i7-3520M, dual core 2.9 GHz with 3.5 GHz max turbo, 8 GB RAM, Intel graphics) and the desktop (Core2Quad 2.7 GHz, 8 GB RAM, nVidia GTx750, soon to be upgraded to AMD FX8350, 8 cores, 4.0 GHz w/ overclock capability, 16 GB RAM, same graphics), both before and after the upgrade -- and in part just to be able to play the same save comfortably, at home, on my big monitor, but still be able to play it on my laptop when I'm out. There are probably multiple ways to do this, but the one I've chosen is to use my Google Drive, already set up at the 200 GB size to accommodate automatic backups for my laptop as the shared storage. Windows users could use the Google Drive app, which automatically maintains a local copy of the cloud drive and synchronizes both ways, but Google Drive for Linux doesn't exist in a usable form. I already have both machines set up with google-drive-ocamlfuse, which makes the remote storage look and act like a local folder, but doesn't synchronize the data, instead doing all loads and saves through the network, treating the cloud storage as a network drive (NAS or similar). This, however, seems likely to be very slow starting up KSP -- the 2+ GB for my save (with Better Burn Time as the only mod) must be loaded into RAM on every program start, and doing this through a 150 Mb/s wifi connection (likely further throttled by Starbucks when I'm there) seems likely to significantly protract the "loading hints" stage of startup. Fortunately, there are several choices available to allow a Linux system to maintain two-way sync between two folders, local or remote. For my setup, guided by a handy answer on askubuntu.com, I've chosen Unity, a mature and maintained free utility that, after a simple setup, will continuously sync my local KSP_Linux folder with a matching folder on the Google Drive cloud, and thence to the other machine (I routinely leave both machines running 24/7 because they also run BOINC @Home distributed computing tasks). Unity has an easy GUI setup and controls, automatically handles empty (newly created) folders at one end of the link (meaning I needn't manually propagate the save), and is available from the same repositories used by a default Ubuntu (or other Debian) distro, so may be assumed to be safe and reasonably reliable. I've chosen to mirror the entire install -- there's a remote possibility of this causing issues if I set screen resolution on one machine outside the capabilities of the display or graphics system on the other, but I normally play in a window at modest resolution, so don't anticipate this being a problem. The up side is, if I choose to install a mod (say, RSS or RP-0, which I've considered) it will automatically be present on both machines. If I create a sub-folder so as to have saves both with and without certain mods, they'll take up extra space on the Google Drive, but my backups are currently using only 4 GB of the 200 GB I'm paying for ($2/mo as of Jan. 2018), and a base install of KSP takes up between 2 and 3 GB, so I have room for a fair amount of this if I choose, and I can use different launchers on my desktop or menu to select the different installs. This also ensures I have matching versions of KSP itself and any installed mods -- no downloading a mod on one machine to find it's incompatible with the one installed two days before on the other, because of an update. Sure. over the course of a year or so, a thumb drive would be cheaper, and likely would sync faster (even a low-cost thumb drive has a higher data rate than 801-N wifi, though slower than my 1 Gb/s ethernet and comparable to the 300 Mb/s of my internet service), but this solution avoids the potential of a lost or corrupted thumb drive (and Ubuntu is notorious for marking thumb drives as read-only for no apparent reason, which costs time to correct even if it's as easy as logging out of Ubuntu and back in) -- and doesn't require me to remember to bring the thumb drive with me, even if it's not actually lost.