Oh boy, there is so much wrong here... Where to start?

First of all, OpenSSL problems are not ''getting fixed''. Part of the problem is that funding for OpenSSL was primarily based on company XYZ sponsoring function ABC. This gave incentives to the OpenSSL devs to add more functionalities on top of the cruft, the horrible mess that was the code base. More funding equals more developpers equals more eyeballs, but we haven't seen the progress so far.

Second of all, OpenBSD has given a HUGE amount of (BSD licensed) code to the rest of the world, Linux included. Try typing "ssh -V" on any Linux machine and I can guarantee you will get OpenSSH. And if you are like me, this is something you use EVERY. FREAKING. DAY. So please stop the trolling about OpenBSD, mmmmkay?

Third, the amount of code that has been cleaned up, improved, deleted and just plain scrubbed is simply amazing. You can say whatever you want about OpenBSD cranky devs, they know their stuff and they know their way around C code.

Fourth, OpenSSL is BSD/Apache licensed, and not GPL, so stop spouting off about supporting GPL software - not everything has to be blessed by Stallmann to be acceptable. And, yes, the Linux Foundation recognizes this - while you don't.

There is not just ''cruft'' in the code base: if I remember correctly, they removed thousands upon thousands of lines of code from OpenSSL - think VMS, Borland C, Windows 3.x, MS Visual C++ (etc) support.

And they tested the whole thing on the OpenBSD ports - so far, nothing has been broken.

Oh and FIPS support? Not gonna happen. Bob Beck has been very very clear on that subject. OpenBSD does not care too much about US government standard.

That was the goal from the vey beginning: make the code less horrible to get people involved and correct as much as possible.

So, yes, they will find more problems. They expect that.

Acetaminophen is illegal now??!! Please say it ain't so!!

X86 went away fifteen years ago. Every "x86" COU built since the last 1990s runs an x86 layer, but underneath is a very different bear.

At the time, the closest the DOS world had to multitasking was TSRs. Beside my first PC was my CoCo 3 with OS/9 level 2 with 512k of RAM with a true preemptive multitasking kernel running on an 8 but 6809 CPU. Microsoft's dominance at the time meant in many ways the most common 16 bit opposing system in the world was only marginally better than a CPM machine from 1980.

Structure, from the sound of it, although mostly this is people committing various fallacies of reification and making false claims of "natural kinds".

Everything is a continuum. Humans divide the continuum up using acts of selective attention. The only infinitely sharp edge is the edge of our attention (because we scale the edge to match the scale we are attending to, so whatever scale we are attending to seems to have a sharp division between the things we are selecting out.)

"Species" do not have particularly crisp boundaries in the general case: they fade into each other, and we draw edges around them in more-or-less arbitrary ways. When we find new varieties we can either create new categories (by drawing new edges) or lump them into old categories (by moving old edges). Which move is to be preferred depends on the purposes of the knowing subject.

Minix was really the first of its kind; a Unix-like OS that you could run on cheap (relatively speaking at the time) commodity hardware and that you could get the source code for. A lot of the computing we take for granted now comes from Tanenbaum's work.

My first Minix install was on a 386-SX with a whopping 4mb of RAM I borrowed from work back in the early 1990s. I quickly abandoned Minix for Linux once it came out, but for several years I had Minix running on an old 386 laptop just for fun.

I really miss the good old days when technical debates were over the merits and faults of such simple things as different kinds of kernels, and not about whether or not every single thing you do online is being stacked into half a dozen nation's permanent data storage facilities.

The Linus vs. Tanenbaum dustup is from a simpler, more positive age.

He said ice sheet. So we're supposed to ignore what he actually said and assume he meant something completely different? Um, no.

"I am not well read in this department" - wait a minute, you can give exact cites for research papers on sea ice, but don't even have a *general* conception of what percentage of the Antarctic ice sheet is gaining versus what is losing? Something tells me you're just grabbing cites you've never even read from denier websites.

Let me help you out with ice sheet. Pretty much all of the East Antarctic ice sheet is gaining, while pretty much the only area losing is the Antarctic peninsula and surrounding areas in West Antarctica. Now, they're losing *mass* a lot faster per unit area than the east is gaining mass, but in terms of area, the overwhelming majority of Antarctica is gaining ice. Because it almost never gets above freezing there, even in a warming world.

The 2010 paper was evaluating the failed CMIP5 predictions

If you'd actually read the paper, which you clearly haven't, you'd know that they themselves did the CMIP5 runs, it's not CMIP5 runs that had been done earlier. Do you even have a clue what CMIP5 stands for? Coupled Model Intercomparison Project Phase 5. As in, "there were four freaking phases that came before this one". CMIP5 is comprised of all of the latest models from all over the world. They didn't even start planning CMIP5 unitl September 2008. Your notion that this is some sort of review of old climate predictions just shows how terrible your understanding is of what you're talking about and how you don't actually read the papers that you cite, that you're just simply grabbing them from whatever denialist trash websites you read.

First, that's a paper from 2010. How was a paper from 2010 supposed to be "predicting" anything about what scientists in the past thought?

Secondly, and more importantly, I had been responding to Archangel Michael, who was talking about the thickness of the Antarctic ice sheet, not Antarctic sea ice. So your link about pack ice is totally irrelevant.

But hey, let's switch topics totally and talk about sea ice, since you seem to want to. Here's how the IPCC sums up all papers on the modelling of antarctic sea ice, including this one:

Whereas sea ice extent in the Arctic has decreased, sea ice extent in the Antarctic has very likely increased. Sea ice extent across the Southern Hemisphere over the year as a whole increased by 1.3– 1.67% per decade from 1979–2012 with the largest increase in the Ross Sea during the autumn, while sea ice extent decreased in the Amundsen-Bellingshausen Sea. The observed upward trend in Antarctic sea ice extent is found to be inconsistent with internal variability based on the residuals from a linear trend fitted to the observations, though this approach could underestimate multi-decadal variability. The CMIP5 simulations on average simulate a decrease in Antarctic sea ice extent , though Turner et al. (2013) find that approximately 10% of CMIP5 simulations exhibit an increasing trend in Antarctic sea ice extent larger than observed over the 1979-2005 period. However, Antarctic sea ice extent variability appears on average to be too large in the CMIP5 models . Overall, the shortness of the observed record and differences in simulated and observed variability preclude an assessment of whether or not the observed increase in Antarctic sea ice extent is inconsistent with internal variability. Based on Figure 10.16b and (Meehl et al., 2007b), the trend of Antarctic sea ice loss in simulations due to changes in forcing is weak (relative to the Arctic) and the internal variability is high, and thus the time necessary for detection is longer than in the Arctic.

Weak trend, short observed record, and high internal variability in the simulations. Which shouldn't be surprising, sea ice is a lot harder to model than ice sheet thickness, which really only has three main parameters - snowfall, melt/sublimation, and outflow, and the short observed record is due to how few people historically have navigated antarctic waters vs. arctic.

But again, to reiterate the primary point: the conversation you jumped into was about ice sheet thickness, not sea ice.

I'm sorry, I just read through that paper, and nowhere in it does it say that a decline in Antarctic ice is a forecast of AGW. That's one of the worst examples of "proof by ghost reference" I've ever seen. Not to mention that the paper is mainly focused on the Antarctic Peninsula, the one place that actually gets melt on more than super-rare occasions and juts into a different climate zone.

How does one embed "JavaScript URLs" in CSS?

Very easily, and because so few people know it is possible, it's a rather nasty vector for cross-site scripting attacks.

Also you seem to have no idea about where the web is headed or have heard about responsive design and SPA.

I'm well aware of responsive design. I think it's an abomination, because all it does is make it take two page loads to view your site instead of one, by ensuring that I have to first load your broken mobile site, then click the "full version" link. Every single freaking time I end up on a "responsive" mobile version of a website, I find myself locked out of features that I regularly use, and end up having to switch to the full desktop version of the site.

If you need much more than a couple lines of JavaScript and a custom stylesheet to support mobile devices, it invariably means that your site is badly designed (too complex) to begin with, and as soon as you release the mobile version of your site, you're almost certainly going to make me hate your guts and curse your name.

And SPA is even worse. If your site loads significantly faster as a web app, there's something wrong with your site. 99% of the time, most of the resources should be shared across pages, and only the text of the page should be changing. There's usually not an appreciable difference between the "load the full page" case and the "load the body of the page" case from a performance perspective unless something is very, very wrong. There are exceptions, such as storefronts that use precisely the same page layout for every page, but these are exceptions, not the rule, and even then, the extra savings in initial page load time just result in a customer sitting there wondering why there's no data on the page, and thinking your site is broken. The real problem is that every web engineer thinks their site is the exception to this rule, but most of those engineers are wrong.

More to the point, if I'm accessing your site often enough to care about performance, I'm going to download your native app instead of using your mobile site, because it will always be much, much more functional, with fewer limitations, more features, and better performance. If I'm going to your website, it's either because I don't care about performance or, more commonly, it is because your native app is missing features that are only on the full version of your site. Giving me a mobile version won't help with the second case, and the first case is largely unimportant for everybody but the site designers who are trying desperately to shave off a few bytes from their data bill.

BTW, it's possible to do a manifested web app (giving you all the advantages of heavy-duty caching of shared content) without using JavaScript for all your navigation. You just specify the base path of the content directory as an external URL (I forget the details) in the web app manifest. This approach is much, much more user-friendly than a SPA in my experience.

Go right ahead and point me to where a decline in Antarctic ice was a forecast of AGW.

You do know that - below freezing - there's an inverse correlation between temperature and snowfall, don't you? And I really hope you know that it's very rare that temperatures rise above freezing in the vast majority of Antarctica, whether you add a couple degrees to the temperature or not, right? Or did you not know / ever consider that?

Just because you didn't realize something that should have been really bloody obvious to you doesn't mean it was a scientific prediction by your straw-man scientists.