khm

Dmitry Bolkhovityanov has led an effort to extend the VGA BIOS font to cover much more unicode space: http://www.inp.nsk.su/~bolkhov/files/fonts/univga/index.html

I've made upscaled versions for high-density displays and a truetype version, with contributed postscript: http://sciops.net/downloads/vga/

Your XO shipped with Sugar. Assuming it's an XO-1, the latest OS and installation instructions are here: http://wiki.laptop.org/go/Release_notes/13.2.10#XO-1

I have one. They're real.

You're full of shit. I was a Freddie Gray protestor and I lived in the city. There wasn't a single bus from anywhere.

That argument is not compelling, given the number of people and organizations that self-host email.

That was Rangboom from 9netics[1]. Archive link because the site now serves a very narrowly-focused photographic art installation.

Their later effort was called "9p cloud."[2]

1 - https://web.archive.org/web/20170311182215/http://www.9netic...

2 - https://www.9pcloud.net/

HTTPS does not provide authentication sufficiently well to put every egg in its basket.

As for "better understood," the authors of this standard work for Google, Verizon, Microsoft, and Comcast. Combined they probably serve most of the email in the western hemisphere.

There is no excuse for overcomplicating a proposed standard -- and "we have this stuff lying around" is no exception. This plan has the effect of causing a networking protocol to depend on an entire series of unrelated networking protocols.

It does not bode well for the future of independent email operators and it provides no path forward for integrating existing devices. It pushes many, many extra steps onto client devices, necessitating entire additional libraries of software to deal with them. That's not a problem for companies with tens of thousands of developers at their beck and call -- but it is only going to raise the barrier-to-entry of operating an independent service.

MTA-STS is pretty ill-conceived. In essence it mandates that compliant MTAs also run a concurrent web service. The authors do not explain why this is useful instead of the simpler approach -- enhance SMTP to reject mail on port 25 with a NEEDS-TLS error, then fall back to implicit TLS (what port 465 was originally for).

You're missing the point. Supercomputer networks tend to be things like infiniband, where you're (usually) not using TCP and the whole point is to enable things like RDMA (yes, that stands for remote direct memory access). IPoIB is available but you pay a performance penalty; on Cray's interconnect the TCP emulation performance has traditionally been really bad.

Google's approach (to anything) is irrelevant to supercomputing, where users' program execution is managed by schedulers and the supercomputer is treated as one unit, despite being made up of many potentially-autonomous nodes. Just about all of the tech you've namedropped is completely unrelated to the manner in which HPC code networks.

Having said that, nobody uses rsh for performance, because if you really want performance you have to skip TCP altogether. People in HPC who are using rsh are using it because of inertia: the same reason the Top500 is the world's largest repository of csh users.

GPFS.

I've worked for the DoD on tons of stuff, from operating and maintaining research supercomputers to operating and maintaining M2A2 Bradley fighting vehicles.

The DoD is the single largest employer in the world. This sophomoric implication that all three million people live and breathe to slaughter the innocents is downright stupid.

I respect your decision not to engage with military operations, but this bizarre ranting isn't productive, and isn't going to alter the course of wars. Consider running for office instead.

I am three miles from my office. There is a lovely river trail running from my back yard to my office building. There is regular bus service from my front yard to my office building.

I drive a motorcycle to work because I damn well feel like it. Unless the weather is bad -- then I drive a car.

I managed to serve for nearly a decade without committing or witnessing any war crimes. You're going to have to dial back the pearl-clutching if you want anyone to take you seriously.

There is a world of difference between incidents of some soldiers in a military of millions failing in their duties and that failure being a national defense policy. You are indicating the latter and I am personally denying the truth of that accusation.

Because the OS you care about on your smartphone isn't linux or ios, it's webkit/blink, and nobody on earth has the capital and the business case for porting a modern web stack to anything at all different. The BSDs are allowed to play because of POSIX, but only if they hop on the video driver treadmill.

In short, there's no money in it, which is the real takeaway from this article.

You'll find instead that it will turn any community into an echo chamber. This sort of tone policing accomplishes nothing but belittling differing viewpoints and alienating users who may (publically or privately) disagree with charitable interpretations.

When the dust clears, you'll have a harmonious web forum -- in which no information is exchanged.

Martin Luther disagrees.

In my experience, things that leave pelican cases in smoking ruins were unable to destroy zero halliburton products. I was sufficiently impressed that I switched luggage brands.

Very little, since it's primarily for internal DoD use. It was never meant to be a part of the commercial 'web of trust' nonsense, and exists so that DoD doesn't have to trust idiots like Comodo.

There is no such thing as a 'large commodity cluster.' You can order a pile of commodity parts and spend the next five years fiddling with it as you watch your metrics fall into the toilet, or you can contract with a systems integrator with domain experience to make sure that you can actually accomplish the work you set out to do. When you're moving an established set of software from a known environment into a new cluster, it helps to have a wide array of technical experts and SLAs in place to ensure that the environment -- here meaning the physical compute infrastructure, storage service, and software installation -- is reliable and maintainable, so that your team can focus on their core mission -- in this case, the modeling software.

"Chaos monkey" works fine when you're dealing with random cloudstuff and you are in a position to duck-punch your production code. When you have a large dataset that you need to process reliably and predictably, the mantra shifts to "fail never", and that requires engineering up front in combination with carefully-planned maintenance.

Full disclosure: I've worked on this specific supercomputer. While I'm not on the admin team in question, I do work with them occasionally and I have a lot of respect for them -- their job is not an easy one.

Yes.

They're not. They're just the only ones who insist on doing it with a filesystem that can't handle the load.

The other problem is that their interconnect is relatively fragile. It's comparatively easy to crash the entire network, at which time your filesystem goes away and processing stops.

But thanks to Lustre, even when it's good, it's bad.

Ah, a Cray. Buck up; there are better supercomputers.

Your assumptions are incorrect.

This post is years old, and those systems went into production in July of 2013.

rc appeared in v10 unix in 1989. Tom Duff, the author, named it.

Cat-v is under "page view every five seconds" load basically continually. You don't have to imagine how to write the web server, because the source is available for your perusal, in friendly, easy-to-read shell scripting.

The site has trouble because we have devoted our meager resources to other tasks. If someone wants to donate beefier servers I'd gladly replace the aging, asthmatic machines that comprise 9cloud.

It's been my experience, however, that people generally don't want to spend that thousand dollars.

thanks for your intervention.

I don't know what "hellbanned" means, but I'm unsurprised I got banned for posting about malloc() in a web programming forum.

cat-v.org runs werc[1], a minimalist web not-framework written by Uriel in the rc shell[2], served by rc-httpd[3], a web daemon also written in the rc shell, by eekee.

The site is served by a single plan 9 virtual machine hosted by myself and maintained by stanley lieber. Further website optimization is not particularly high on our to-do list. Anyone who wants to donate CDN services or front-end varnish machines is welcome to get in touch.

[1] http://werc.cat-v.org/ [2] http://doc.cat-v.org/plan_9/4th_edition/papers/rc‎ [3] http://man.cat-v.org/9front/8/rc-httpd

cat-v.org is operated by stanley lieber and hosted by myself; sl is very very careful to limit modifications to things that were either expressly in uriel's todo list or else so obviously uriel-like that their omission would be glaring.