steve_v

That's not the worst example, the profanity filter appears to be both extremely conservative and rather stupid.

As awesome as Claw is with such things, this is another one of those long-standing stock bugs... in which case it's properly Squads problem to fix.

Well, the only reason it's Americans specifically is because it was an American survey. The disturbing thing is that I expect the same would be true of many other populations as well... if certain people I know are anything to go by. Once upon a time I assumed that basic facts like this were common knowledge, easily obtained by anyone who received even basic schooling... with age comes the realisation that ignorance is everywhere. I don't think it's stupidity either, some people just don't seem to care.

Mkay, running it now. Water drag feels about right to me, but I am noticing that fins are now being ripped off my rockets @~10Km/mach 1.5/1°AoA (where they weren't before), I take it this is an intentional result of the drag changes? They are admittedly set rather weak (0.4) and it's a monster SRB stage, so somewhat brutal. But hey, it worked before. Ed: I think it's SAS roll oscillation causing this, but still, aero stress failures where there were none before.

I don't see why - there's a periodic autosave implemented already, just grab the current system time and append it to the save name. You might need to clean up after a certain number of saves, but this isn't exactly rocket science either. Ideally, I'd say: "No worries, I'll just load the previous autosave"... but as it stands, it's more likely to be: "Why the **** is there only one autosave?" Cool, awesome. Totally useless if you forgot to make a named save to load from. This whole problem doesn't happen in other games, because there are multiple autosave slots, or regular level/area transitions that trigger saves. No amount or PEBKAC short of intentionally deleting those save points will loose you more than a small amount of progress. As we don't have easily defined save points in KSP, what's the problem with simply making a bunch of autosaves at intervals? Save files are small and disk is cheap. The problem could, as you say, just as easily be a save that is too recent rather than too old. So give us more saves to choose from, and try not to penalise those that forget to make them manually. My current play style involves (named)saving before I do anything. Partially because of bugs - e.g. I never know when my craft will fail to undock or a base will randomly leap into the sky and explode - and partially because the autosave system is utterly brain-dead - it's quite likely to save just as said base explodes and there's no fallback unless you create one manually.

It didn't get the nickname "destroyer of disks" for nothing (and no, that's not what it actually stands for. As with many things unix, the original naming rationale is probably lost to the sands of time) Agreed, and yeah, it does work. Caveats I know of: You'll need to shrink the filesystem/partition first if the destination disk is smaller - as is often the case moving to an SSD. The windows bootloader gets liquidy this profanity filter is ridiculous upset if you move the start sector of the "System reserved" or Windows (C:) partition. For live progress, you could also pipe through pv, e.g. 'dd if=/dev/source | pv | dd of=/dev/destination' Or dispense with dd altogether and just redirect the data, using pv in place of 'cat' like: pv /dev/source > /dev/destination Added bonus of this method: You'll get a progress bar, speed and an ETA, since it knows the total size to transfer, whereas dd does not. pv /dev/sda > /dev/null 40MiB 0:00:02 [ 125MiB/s] [> ] 0% ETA 0:39:34 You really only need to use dd if you want to to skip/seek/truncate/convert the data stream in the process, for a straight up copy it can be rather slow as it uses silly small block sizes. You will probably find a dd disk copy is a fair bit quicker if you also set 'bs=4M' or so, or just use pv or cat, as they'll use a more sensible block size by default.

Ahh, the tyranny of the rocket equation. There's no escaping it. The only ways around this: decrease your payload mass, decrease overall non-fuel mass, increase engine efficiency, or stage more. Or just add moar boosters, moar fuel and end up with a monster. And no, mass is not quite the same as weight. Mass x gravitational acceleration = weight. On earth, they're often used interchangeably, but in space (microgravity) you mass the same, but weigh less.

It would, but it just turns "quickload" into another "load" - the whole point of quickload is that it's quick. I wouldn't be opposed to the idea, so long as the confirmation a: does something useful, like shows the date of the file to load, and b: can be dismissed instantly with a single keypress (not a clicky button requiring the mouse). Maybe something like: first press of f9 opens dialog with last quicksave date (and ideally screenshot), esc cancels, second press of f9 loads. Well yes, AFAIK. The quicksave system in any game I can think of is nothing more than another save slot/file, bound to quick keys. Most don't even have the "hold f9" safeguard. I do vaguely recall seeing a "warning, your last quicksave was X hours ago, are you sure" type message, but I can't recall where. This generally isn't a problem though, as most other games create permanent autosaves on a regular basis - important game events, area transitions etc. Even if you do quickload by mistake, there are plenty of recent saves to fall back on and progress lost is minimal. To my mind, a better solution than departing from this pseudo-standard would be to improve the autosave system - make a number of autosaves at intervals (and possibly events, eg pre-launch, leaving/entering atmo, soi transition, docking etc.), and allow the player to go back and load one if they accidentally hit f9. The problem isn't so much that quickload allows you to load a really old save, but that it also overwrites the single autosave slot seconds after you do so. There's a mod for this, but something in the stock game would be nice. Also: This is intended behaviour, and therefore by definition not a bug.

True, but that really controls how the chipset / BIOS presents the drive to the OS. AHCI can expose new ATA features to the host, so you may miss out on e.g. NCQ if running in "legacy" / emulation mode, but this is true whether the disk is spinning rust or nand. If the chipset supports AHCI, you should use it anyway - depending on what the hardware supports, it might even perform better. If a particular chipset driver is slow, it's probably going to be slow for newer spinning disks as well - you just won't notice. I guess a reinstall could be an excuse to fix this, but as your link demonstrates, you can also switch drivers without re-installing. Aside, all modern drives are IDE - the acronym is Integrated Drive Electronics, meaning that the drive controller is on the drive, as opposed to say, MFM, where a separate controller board does all the donkey work, like positioning the heads. ATA drives, whether using the old parallel or newer serial transfer architecture still use the same ATA command set, plus any AHCI extensions, if available. Yeah, ok. It's been so long since I used a filesystem that needs regular defragmentation I had forgotten all about that "service". Even back when I still used FAT/NTFS I just defragged as needed, when needed. But surely this also falls into the category of "can be fixed at any time, without reinstalling".

Doubt is fine, but the logs will tell you for sure.

There's a mod working towards something like this - Giving Aircraft a Purpose. It's not quite done yet, but what is ready looks very shiny. For extra bases and cargo runs, there's KerbinSide and the KerbinSide-Jobs contract pack... though neither of those are 1.0.5 ready, AFAIK. I agree, something like this would be a nice addition to the stock game - but it'd have to be done carefully so as not to detract from the original direction of the game - building rockets. Personally I find aircraft just as much fun, add too many aircraft contracts and I may never leave Kerbin again.

Or that, on Windows Putting a "Quit to Desktop" button on the in-game "ESC" pause menu would be nice though.

Yeah, this is pretty irritating, and it's something present in many other games too. In X, I just use xkill (Ctrl-Alt-Esc, click) -> poof.

I can no longer repro this, in the same save or otherwise, with CC 1.9.1 / GAP 0.3.

Again, ATA drives (including SSDS) require no special drivers, that's kinda the point of having all the controller logic on the drive and presenting a standard interface. The motherboard/HBA chipset is a different story, but in this case that isn't changing. Modes? The only "modes" any of my SSDs have are "plugged in" and "not plugged in". They don't even have 'feature' jumpers to muck with any more. Using the wrong (512 vs 4k) sector alignment on partition boundaries can cause performance issues, but all modern drives do translation in the firmware (and many lie about it) - at most you'll take a ~10% performance hit on random I/O. Not nice, but hardly "crippling". Not enabling TRIM/DISCARD may interfere with wear-levelling features, but that's a filesystem option that can, AFAIK, be set at any time. Perhaps Windows does some other mystery magic at "various stages of installation and use", if so I'd love to know exactly what that is.

Well, yes and no. As far as what's on the disk platters, a "bunch of bits" is exactly what it is. The OS doesn't need to interact with anything below the filesystem layer, except at boot time. ATA disks need no drivers (assuming it's the only thing changed), and while partition table alignment or filesystem blocksize could conceivably cause performance issues, the former is easily detected/corrected, and the latter extremely unlikely unless you've fiddled with it - is there even a knob for this on windows?. "Corruption (due to increased disk sizes)"? I'm really not grokking that one, how is this going to happen? Never intended it to be, more an "I can do it this easy way in OS A, why not something similar with OS B?" I don't know of a way to get windows to boot after simply copying the disk contents - but it should be possible, as it is for other operating systems. Is there a way to update the windows bootloader and disk layouts to a new disk ID without a reinstall? The 'bitwise' exact copy method should work as it preserves the disk/partition UUIDs, but it would be more elegant to just update Windows with the new ones, no? You could do this in XP by killing the "MountedDevices" registry key, and updating BOOT.INI, but it's all changed somewhat since I last tried that... not that I ever had a >50% success rate with this anyway - IIRC there was a nasty hexediting the partition table bit involved too. Also, this: Would drive me insane, and quickly. On the car analogy: an old, well maintained vehicle with parts replaced as they wear is not inherently less reliable than a new one. And software is not a car: it has no wearing parts, so age does not factor into it's reliability - unless you're talking bit-rot, in which case you should probably be looking for a better filesystem or less-flaky storage media.

Arghhh, damn you for mentioning that accursed website. Every time I go near the thing, it becomes a multi-hour dive down the proverbial rabbit hole... amusing reading indeed, perhaps too amusing.

Eh? It's all just bits on a storage medium, I don't see how moving it to a new drive makes any difference. Unless of course you are implying that Windows becomes more broken as time installed increases... This I do remember from Win9x. OTOH, I have 2 Debian installs that are at least 7 years old without a reinstall, only dist-upgrades. One has moved disk at least 4 times, including a move from a single drive to RAID, as well as a switch from ext3 to reiserfs, then to ext4. SOP: Partition/format, rsync data, update fstab & bootloader, boot new disk. No issues to report. I find this to be considerably less time-consuming than the standard bitwise copy + partition resize, and far less hassle than a reinstall. Yet to see a way to do it with Widows though.

Mod+L, IIRC.

Yeah, and I should probably add: You should disable "Secure Boot" in the BIOS (if it's enabled) during this process, otherwise: .

Windows is a right pig about moving installations around, but if the only change is the primary disk, it usualy goes something like: Defrag Windows drive. Make disk image backup, this will likely go wrong. Resize partition / filesystem to fit on new disk with e.g. gparted. Make sure windows still boots. Exact copy disk -> disk, with anything that can e.g. dd Fix / resize partitions / FS (again gparted). Cross fingers, run Windows boot recovery tool, e.g. Install disk "Repair" option, bootmgr from recovery console or Boot Repar LiveCD. Initial defrag/resize may be omitted if destination disk is larger than source.

I generally use 7-zip. Free, GPL, opens pretty much anything.

Operative word: Supposedly. In practice, you may note that almost all my posts say "edited". Why? Because annoying editor and no preview. Whoever is in charge of this mess, please reinstate a non-WYSI(S)WYG, plain-text + BBCode editor with a preview function. The old system had one, if the new one cannot do this then it is simply an inferior solution. Less is not more, and simpler is not better.

If I'm to be pedantic, Solaris and BSD aren't exactly 'distros' of Unix any more... I recon they've diverged far enough in the last 20 odd years to be classed as separate OSs. And they're certainly not binary-compatible, so any malware would have to be targeted at and compiled for the platform.

I guess this depends on your definition of "unwanted behaviour" - to me this means obnoxious "hunt for the free DL link amongst the ads" websites, "upgrade" nag screens, crippleware free versions, added toolbars, "you can't have the source code" licensing, DRM, ads of any kind etc... Ok, so I'm probably just used to everything being free. Having to deal with malware-infested Windows machines in a semi-professional capacity, I see plenty - but perhaps the users I deal with are of a slightly different calibre. I have yet to see a GNU/Linux box with any malware at all. OSX I simply ignore. Well... I think "any OS" might be stretching the point a little, I've yet to see a native virus for NetBSD or Solaris, for example. (not to be confused with attacks targeting specific software, e.g. webservers), or even a virus scanner to update, unless you count those designed to detect Windows malware on email servers. That said, running any internet-exposed services without some form of intrusion detection is not overly wise. I don't have any traditional "virus scanner" on any of my non-windows machines, but I do have periodic OS file checksum reporting and alerts for new open ports / unusual processes / logins etc. Then again, I don't plug random flash drives or download executables from suspect websites either - all installed software tends to be signed by teams I have a reasonable faith in.