The problem comes when the school administrators micromanage said specifications in a political way that interferes with education.

I was under the impression that fork() was still broken outside Cygwin.

It's like Twitter, only backward, in the same sense that BASIC string variables are like shell, Perl, or PHP variables, only backward.

So which hosting company do you recommend that offers SSH over VPN? Shared hosts that I've seen offer only a web-based administration panel and a shell account. With VPS or dedicated, you'd have to rent two servers: one to act as the "hardened node in a heavily firewalled DMZ" and one to actually be the server administered through SSH. And even then, how would you administer the "hardened node in a heavily firewalled DMZ"?

Say I need to administer a server from home, from the home of a relative that I visit every other weekend, occasionally from public Wi-Fi in a restaurant or library, and rarely from public Wi-Fi in a hotel in another state. Other than opening the server's SSH or HTTPS administration port to the Internet, what other method would you recommend for me to log in and do work from all of those places?

Windows without Cygwin still lacked unistd.h last time I checked.

Unless the vendor that doesn't cross compile sues one that does for patent infringement or nonliteral copyright infringement. Or unless the vendor that doesn't cross compile benefits from a strong network effect among its users.

TLS library maintainers not caring about speed is part of what leads web site operators to use HTTPS for login and payment pages and redirect all other hits to HTTP.<cough>Slashdot</cough> This leaves the session cookie wide open for anyone to clone with tools like Firesheep.

Rsync your CherryTree file, or sync with whatever cloud storage solution you use, Google Drive, Microsoft NSAAS, whatever.

It's a bit limited for complex things, but it worked for some students I know tracking the majority of their note-keeping needs. Stopped using 3rd party solutions since I eat my own dogfood, and now have notes integrated into my distributed versioned whiteboard / issue tracker / build & deploy & test product. I have issue/note/image annotation plugins for coding with Netbeans, Eclipse, Visual Studio, Emacs and Vim -- Which reminds me of a Vim plugin I just saw that you might find useful... if you can run a (home) server (and port forward around NAT), then install Wordpress on a LAMP stack (in a VM, because PHP exploits) -- I'm pretty sure Emacs has all that built in by default now: C-x M-c M-microblog.

I jest, it's just Org mode. Save your .org to your Git repo, and away you go.

That's one hell of a strawman you've got there. I'm not an anarchist myself, but I'm not sure you've ever actually met many anarchists before if that's what you think of them. Sounds like you've conflated anarchy with chaos -- that's just silly. There are many native peoples that live quite happily in anarchy. Self defense is an important aspect of anarchy. Note: The USA supreme court has ruled that it is not the duty of the police to protect anyone. They can't help you or your loved ones until they have already been victimized. The founding fathers of the USA also believed in a well armed militia. It is your duty to protect yourself, your loved ones, and your property -- Just like it is under anarchy... So, really, making weaponry more available is a good thing. Accidental shootings are rare, far more kids die in bathtubs or crossing the road than from accidental shootings, to say nothing of riding in cars themselves. Folks are OK with people building custom bathrooms and cars... right? Criminals don't care about gun control laws anyway.

I use a custom 3D printing rig for my robotics projects, and this gun project is AMAZING. Who doesn't want sturdier robots? Now, here's something interesting: How many technological advances can you think of that were not quickly militarized? Electricity? Nope. Uhm, radio? Nope. Cars? No -- hell, even horses were militarized. Computers? Nope, code makers and breakers. Telescopes? Immediately found their way to the battle field. Even our beloved RC cars, model airplanes and robots are becoming military drones. Did you know the US government reserves the right to option any patent for their exclusive secret (military) use? That's why patent applications are still secret even though first to file exists.

Making guns is human nature. We've been crafting weapons with unlikely materials for millions of years. Break this rock, and tie it to that stick and you can make a spear! However, this 3D printed gun is more of a proof of concept, and it's important because guns involve coping with extreme heat and pressure. It's sort of the same way that other than for boring entertainment or a very expensive hobby race cars are mostly pointless, except that many expensive impractical innovations from race cars do eventually make it into street cars for better safety, efficiency, speed, etc. I can hardly think of a better Olympics of 3D printing than gun making.

Also, "bits of plastic"... I can 3D print with metals using a simple welding rig. The resolution is shit, and requires lots of polishing afterwards, but the results are OK considering it's make-shift adaptation to a reprap, and they will only get better. If we can improve the durability of 3D printing, then you might order things at your computer and pick them up from the local hardware store in the "printware" section. Perhaps they'd have some thing-of-the week demo units of things to try out, printed while you wait, or delivered with your next pizza. Then we could drastically reduce our shipping infrastructure by producing products right in the stores, only shipping the raw materials to feed the printers. Other things like cars which you'd want certified MFGs to assemble could even be customized on demand -- Select a bigger cargo area, or narrower for tight spaces, get your logo crafted into the design.

Hell, we could even work our way up to custom designed 3D printed space craft, you'd have to bake the ceramic shields though. I've even made my own super capacitors by layering the ceramic clay and aluminum foil and baking it in the kiln (vertically, with the edges folded closed, only the lower 1/3rd retained its metal and became a huge capacitor. My welding rods deposit too thickly, but better metal and ceramic 3D printing could yield things with built in instant-charge inductive cells too one day. It's a ways off, esp. with entrenched market forces, but that's what refining 3D printing material science by making guns can lead us to.

If you're opposed to 3D printed guns, I would encourage you to NEVER drive a car. In fact, stay indoors at all times, and only eat health food, heart disease is one of the most dangerous things on the planet.... But fortunately we're working on 3D printed replacement hearts.

I agree, but you don't even need a machine shop, lathe, etc. to build a gun. You can build a pretty sturdy zip gun with some pipe and fittings from your local hardware store. They even sell 22 caliber rounds for driving in nails so you can build the whole gun, projectiles and all, right there in the store. Get some real bullets at Walmart later. Look, we're all "nerds" here, home made guns should be part of any contingency scenario for your zombie plan; Help a geek out.

Makeshift "zip" guns are even studier than a 3D printed gun is right now. Eventually 3D printed materials will be even better than subtraction technologies, since we can influence fine structural detail. But right now, 3D printed guns are WAY down the list on essential zombie preparedness kit items (it's like a hurricane or earthquake kit, but with more shotguns).

If you're in the US, today is a great day for a zombie attack. There are folks gathering away from their homes in large quantities, and running around collecting and eating food off the ground. Even if you don't get visited by the Easter Zombunny, today is a great opportunity to teach kids foraging skills. Remember, in the event of an outbreak: Always hunt responsibly, steer clear of tasty traffic bottlenecks, and she is not your mother-in-law anymore.

Uh, no. No one could have even discovered the dark side of the moon until the early 70's. There wasn't any video either, but there have been several attempts to reconstruct what it might have been like on a stage.

Haha. Oh man. Java is a VM. Do you check for "dangerous constructs" like Just In Time compiling of data into machine code at Runtime and marking data executable then running it by the Java VM? Because that's how it operates. Even just having that capability makes Java less secure, don't even have to get exploit data marked code and executed, just have to get it in memory then jump to the location of the VM code that does it for me with my registers set right. Do any of your Java code checking tools run against the entire API kitchen sink of that massive attack surface you bring with every Java program called the JRE? Do they prevent users from having tens of old deprecated Java runtimes installed at 100MB a pop, since the upgrade feature just left them there and thus are still able to be targeted explicitly by malicious code? No? Didn't think so.

Don't get me wrong, I get what you're saying, Java code can be secure, but you have to run tests against the VM and API code you'll be using too. Java based checking tools produce programs that are just as vulnerable as C code, and actually demonstrably more so when you factor in their exploit area of their operating environment. Put it this way: The C tools (valgrind) already told us that the memory manager was doing weird shit -- It was expected weird shit. No dangerous construct warning would have caught heartbleed, it's a range check error coupled with the fact that they were using custom memory management. The mem-check warnings are there, but they have been explicitly ignored. It would be like the check engine light coming on, but you know the oil pressure is fine, just the sensor is bad... so no matter how bright of a big red warning light you install it can't help you anymore, it's meaningless. Actually, it's a bit worse than that, it would be like someone knew your check engine lights were on because of some kludge they added for SPEED, and so they knew they could get away with pouring gasoline in your radiator because you wouldn't notice anything wrong until it overheated and blew up -- AND you asked them about the check engine light a few times over the past two years, but they just shrugged and said, "Don't worry about it, I haven't looked under the hood lately, but here's a bit of electrical tape if the light annoys you."

I write provably secure code all the time in C, ASM (drivers mostly), even my own languages. CPUs are a finite state machines, and program functions have finite state as well. It's fully possible to write and test code for security that performs as it should for every possible input. For bigger wordsize CPUs, Instead of testing every input, one just needs to test a sufficiently large number of them to exercise all the bit ranges and edge cases. As you've noted, automation is key. If you want to write secure code you have to think like a cracker. My build scripts automatically generate missing unit test and fuzz testing stubs based on the function signatures. Input fuzzing tests are what a security researching hacker or bug exploiting cracker will use first off on any piece of code to test for potential weakness, so if you're not using these tests your code shouldn't touch crypto or security products, it's simply not been tested. Using a bit of doc-comments to add a additional semantics I can auto generate the tests for ranges, and I don't commit code to the shared repos that doesn't have 100% test coverage in my profiler. If OpenSSL was using even just a basic code coverage tool to ensure each branch of #ifdef was compilable they'd have caught this heartbleed bug. I recompiled OpenSSL without the heartbeat option as soon as my news crawler AI caught wind of it.

Code review, chode review. These dumbasses aren't using basic ESSENTIAL testing methodology you'd use for ANY product even mildly secure: Code Coverage + memory checking is the bare minimum for anything that has to do with "credentials". They apparently also have no fucking idea how OS memory managers operate (they do memory re-use, that's why we even need Valgrind, because some accesses to freed memory won't SEGFAULT since your program is reusing recently deallocated memory on the next malloc). That's why I find the whole "optimization on by default for SPEED" suspicious since it was only needed on few platforms; Especially suspicious considering they hadn't tested the other side of the #ifdef for years, AND claimed they couldn't disable the custom memory management expressly because compiling against equivalent standard mem manager code hadn't been tested in years? No, that's NOT acceptable! If your mem-manager code hasn't been tested versus the default stdlib's malloc then it just plain shouldn't be in use publicly -- especially not in an industry standard security related product. How the fuck else do you compare code branches to test your memory manager?! How the fuck else do you even know it's better than malloc() and free()?! The fact of the matter is that the OpenSSL codebase has so many commits now because it is trash. That's what happens when you set out to make a big-int math lib and it evolves into a security product. No one should expect that shit to be even slightly secure unless it was re-engineered with proper dev toolchain and unit test / input fuzzing generation framework.

Honestly, if I were trying to break OpenSSL I might accept a patch on new years when no one else was really paying attention that exposed the huge memory reuse vulnerability red-flag I've been waiving people away from testing for years... Sounds like a bunch of "plausible deniability" to me. Just like when OpenSSL's entropy was REMOVED from its random number generator back in '08. Yes the OpenSSL maintainers went dark and silently moved to another issue tracking... a huge problem for an open source security product (getting a sense of their typical dumbassery now?), but the Debian maintainers that allowed that patch to their OpenSSL without at least running it past upstream should have been sent out to pasture too. You DO NOT FUCK WITH a security product's RNG on a whim! That shit is hard to get secure even if you're not being evil. However, if the OpenSSL devs had a simple entropy test in their RNG test harness no one would have been able to make the mistake that made all the SSL keys bogus last time.

Sorry. OpenSSL is dead to me now. I'm a rationalist. I don't have to think in binary terms. I can entertain several possibilities weighted at different degrees of certainty. I'm not 100% certain of anything, but what I do know to a high degree of certainty (enough that it's not worth risking use of it) is that OpenSSL and everything else is being targeted for anti-sec by all the world's 3 letter agencies, and the fuckers that screwed up HUGE, TWICE are going to stay in charge? These maintainers should step the fuck down. I wouldn't even trust them to keep backdoors out of a minesweeper clone. It's a good thing the OpenBSD devs are ripping out the bullshit, but without a complete rewrite and change of guards I'm not going to risk it. It's a waste of time, IMO. Just use something else or start from scratch -- That'll take the same time as stripping it down to the core components, test the hell out of them, and refactor everything with proper tests any security product should have. The scary thing is that OpenSSL is in a better state than most of the proprietary SSL code I've seen in the wild.

If you want something done right: Do it yourself. You can't trust the court jester with the keys to your kingdom. These bigint math, hashing, and cipher algorithms ARE NOT HARD to implement. For the things I need secure I just use my own implementations (and ciphers). Heartbleed didn't mean shit to me. And for the rest of you folks pretending you give a damn about security, Stop complaining! You look like idiots. I don't really know what all the fuss is about. Oooh! All the keys are exposed. So fucking what? Any security researcher worth their salt knows that the CA / PKI for TLS is completely and utterly broken anyway. It's a giant security theater. It's like you're flipping out because someone's shoes didn't get checked in line at the airport meanwhile some unknown unchecked kid is stowing away in the wheel well of your airplane, and freezing to death -- Good thing he wasn't a terrorist!

Any CA can create a cert for ANY domain, and if you go view certs ( FF -> preference -> Advanced -> Certificates -> View ), then you'll see known bad actors explicitly trusted as roots right now in your fucking browser! You have The Hong Kong Post office as a trusted root and you give a fuck about heartbleed?! Russia, China, Iran, etc. countries yours is probably at cyber-war with right now are also trusted? ANY ONE OF THEM compromises ANY server between the endpoints and they can MITM the SSL connection, you'll get a big green secure bar and everything. You could use the CA system with 100% self signed certs for Intranet security, but for anything else it's fucked: No one checks the cert chain manually, and if they did how do you know your email provider didn't switch CA's? YOU DON'T, and any attempt to find out is susceptible to the same MITM.

With national security letters and gag orders flying around no one can trust any CA in the world, and you have to trust ALL of them to not be compromised for SSL infrastructure to be secure -- The likelihood of the CA system being uncompromised is actually below 0%, we have governments admitting to wholesale spying all over the world and boasting about their buildings full of people who's job it is to make sure the CA system, OpenSSL, etc. are not secure. In my estimate I'd put the CA system at -9001% secure, since any competent security researcher would have NEVER built the system such: It's a collection of single points of failure that is so fragile even one failure could compromise everything. Remember diginotar? This CA system shit was built to be insecure by design. It was broken before it was even implemented, IMO. It's not like PGP trust graphs don't exist. It's not like we never revised the system either, so that's no excuse. Too bad convergence breaks every other build of FF. Heartbleed is overblown because ALL YOUR SSL KEYS are bogus the moment you created them, and so are your new ones.

Heartbleed doesn't affect me at all. I operate with the understanding that everything online, even data in an SSL connection, is equivalent to writing it on the back of a post card. Look, HTTP-Auth exists, Modify it slightly so that it pops up a box on secure connection attempt BEFORE DISPLAYING ANY PAGE (typing a password in on a web form is already game over, fools). Server sends nonce-0 and server GUID (or just use the domain), Client sends nonce-1, UserID, and negotiates stream cipher to use. Use HMAC to derive proof of knowledge: HMAC ( passphrase, User ID + Server ID + nonce-0 + nonce-1 ) = proof of knowledge. DONE Do not exchange the proof. Just key your chosen stream cipher with it at both ends of the connection and begin communicating over an encrypted tunnel that no MITM can get. I use the HMAC with a key-stretching hash of the inputs to make brute forcing take a bit longer, the ends can specify min and max iterations and even thousands of iterations is faster than TLS key exchange. If the user has a password saved then don't let an unsecured connection happen, simple. This protocol is what my custom VPN uses. We have logins at the places we need security anyway. Yes, someone could intercept account creation, but at least with the pre-shared key method that's a small window -- The only time you need PKI is to exchange the passphrase (or HASH( APP_salt + master_password + serverID ) in my case). Fail to capture account creation and no more MITM. You don't even need a CA system since the window is so small. At least with pre-shared secrets you have the CHANCE to exchange the secret out of band: Go to your bank physically, hand the PW to someone in person. The CA system ensures that every connection can be MITM'd regardless of how you exchange the password. Any security researcher who EVER thought that the PKI hierarchy offered any security should not be trusted. Think about it: It just inserts a CA trust as a potential MITM for every mother fucking connection!

Heartbleed woes are ridiculous. It's like you're sitting there on the side of the road with your car broken down -- Transmission stripped, engine thrown a rod, on fire; You're OK with that, but then a passing truck dings your windshield and you flip right out. That pebble you're losing your shit over is heartbleed.

US student loans have various humiliating processes you can use to get some deferments, but if you never actually start making money with or without your degree you still have to pay them back eventually and they never go away and if you have outstanding student loans you can't close escrow on a home, or do some other important things.

Luckily Audi has a lot of experience dealing with corrosion, having produced an all-aluminum car in 1994 with the A8. Lots of warnings in all the service documentation about not using the wrong fasteners, about only using tin-plated ring terminals, etc. Unintentional grounding is a problem anyway... but only if you're not intentionally grounded, through a compatible terminal.