gchpaco

The most successful Soviet camera designs were to one degree or another rip offs of stuff Zeiss was doing before the war; the LTM cameras in the FED and I think ZORKI series, the folder I have that is near on a dead copy with the opposite handedness of the current Zeiss folder in 1930 (speculation is that someone copied the blueprints upside down), the various Kievs. Almost all of these are very close, visually, to what Zeiss was doing before the war, which would make a lot of sense given what the Soviets did with Zeiss (viz. basically relocating everything they could and calling it "Kiev"; this operation is now known as Arsenal, I think, and did and still does do some high quality work). I suspect the reason why Soviet ergonomics doesn't come up more often in these discussions is because people who own Soviet cameras are usually so delighted to find one that e.g. had the flocking painted on the inside or has the right gears in or generally works that they will put up with the generally Brutalist visual styling.

Which is not to say that they're not perfectly servicable cameras; other than being mirror-reversed that folder I have is one of the most sophisticated of its type ever made, with a coupled rangefinder, a coated (!) Tessar-type lens and different masks in case you were mad enough to want more than 8 shots to a roll of 120. But what design aesthetics are present are almost the same as 1930s Zeiss cameras with perhaps some corners cut for manufacturing.

As you might imagine, the print industry put in a lot of research over the course of the 20th century to ensure that e.g. Coca-Cola's cans come out the same color no matter which factory makes them. As such there are a number of mathematical models, called absolute color spaces, that can be said to name any given color within its gamut precisely. Adobe RGB and sRGB are two that are RGB based.

A different way of doing it are systems like Pantone that has no particular mathematical model; Pantone basically numbers swatches according to some arcane formula and can work with you to precisely reproduce any color you happen to want. If you want a color that isn't represented in their swatches they'll just add another one to the end of the list and do something horribly complex behind the scenes so they can tell you, or more likely your ink vendor, what to look for and what an acceptable color match is. These swatches are frequently named as well as numbered; somewhere on that list is Coca-Cola red, and you don't get to use it. This leads into a bunch of very strange IP law issues that I am not in any way able to talk about knowledgeably.

CIELAB and CIEXYZ are reference color spaces designed to encompass every color an average human can see, and these can be used to define the above standards. CIELAB is probably the best known of these. One of the odder things about CIELAB is that there are colors in gamut for it that no human can see (for example, a color that stimulates only the medium wavelength cone cells).

As a matter of professional practice people who care about this use Pantone PMS references. Photographers, particularly digital ones, tend to just use sRGB or Adobe RGB and look at you funny when you talk about Lab spaces. And virtually no one else cares enough to distinguish between pinkish red and reddish pink in a formal way.

Doesn't mean it can't be statistically valid, the noise just means you need to run more tests.

You can do that in base Tcl; the libraries won't exactly help you and unless they've fixed the dynamic scoping problem it had a decade ago when I last looked at it closures would be obnoxious, but the language itself is really clean and simple, very nice. The implementation is horrible and the original designers didn't really understand what they had, which is why you have really weird libraries like Tk that don't compose especially well (briefly: in Tk essentially every GUI object has global scoping and are named; the naming reflects the scope. It's possible to write GUI libraries for it but it's not trivial).

That's still possible in a negative sum game; all negative sum means is that the sum of the benefits to all parties is less than the sum of the costs to all parties. So if say the US hoses the Mexicans but good it can still come out ahead as long as the Mexicans go down hard.

War is actually a negative sum game today; even "winning" you lose a lot. It's not clear to me if this was ever different for anything larger than Viking raiding parties, though.

Compiler optimizations, CPU pipeline and branch prediction would be my guess, although I'm sure someone else can jump in with more detail. XOR is basically immune to optimized tricks.

It looks as though they're pursuing the unarmored combat of Liechtenauer than the armored knight combat of later period, where swords basically stopped being useful against breastplates and the like and folks went in more for maces and war hammers. Liechtenauer does, IIRC, have halfswording in the basic form but mostly it is about geometry and footwork.

Right now it's Samsung SyncMaster 2443s. The trick is to go into the font stuff and explain the LCD layout to the font renderer. I think MacOS already does this but on Linux it's usually somewhere in Appearance.

I typically work around this by having dual monitors and having one mounted vertically and the other horizontally.

This article is superficially correct but omits enormous amounts of detail.

Woodblock printing is ancient, mostly used for religious texts but requires very little infrastructure. Obviously not suitable for small printing runs, as the entire block has to be carved at once.

Bi Sheng invented movable type using porcelain characters. But Chinese is fantastically ill suited to that sort of printing; it was viewed historically as a novelty and not used basically at all. He decamped to Korea where he found a more receptive audience, IIRC.

Gutenburg's type alloy and the casting process were the real core of the innovation; the rest of the technology existed, but wasn't compelling without the ability to mass produce characters and with a reliable type alloy.

Oddly enough and for reasons I don't fully understand, woodblock printing didn't take off in Europe until after moveable type came in; mostly for illustrations, IIRC.

Funny you cite Germany as not as reliant on consumer demand; one of the things that keeps being cited as hurting Germany right now is that the rest of the Eurozone is its major customers, and they can't afford German goods on account of depression.

Because rebase, and rebase -i especially, gives you the ability to break your patches into discrete this-one-one-goddamn-thing patches (which is awkward in a "oh, you committed it? Then you committed it forever" SCM like Perforce or SVN), you should do so. It makes it a lot easier to review than the "so this does X, but also fixes some syntax errors and adds logging" style. And that means you should make the patch comment reflect what it is doing. Some errors here are inevitable but it's something to which I aspire.

Edit: to be a little clearer; your traditional SCM has a write-once-never-change model for the trunk of development. This has a problem in a peer review situation, and the problem is this: I may go forth with the best of intentions to decompose things into discrete patches. But when you get down to brass tacks, changes to the system tend to happen in any given order--you might discover a latent bug when testing your feature that has nothing to do with your feature. Now you have two choices: you can wait and commit nothing until everything is great, which means you're not integrating with the mainline, which means that integrating will be incredibly painful, which leads to locks; or you commit as it comes in the moment, which is much better for integration and much easier to back out partial changes and generally get all of the non-backup elements of an SCM, but which is the very devil to peer review. With rebase -i, it is quite easy to commit in the second style in the moment and then clean them up for peer review later; that is the ability to revise history means you can make decisions immediately without worrying that they will be cast in stone forever and ever anon.

I wasn't always this much of a hardliner on the subject, but my current job uses Perforce as the main SCM and I have realized that I disagree with almost every decision Perforce makes across the board. I still use it, because any SCM is way better than no SCM and I don't want to explain git to everyone else, but my actual development occurs with git-p4.

If you think of the change set as the subject, so the question is 'what does this do?' and the answer is 'fix X' then it makes more sense. Past tense suggests you might be thinking of it as a journal or something that you're not supposed to do with git due to rebase etc.; each commit ought to stand on its own.

That said I don't think this is significant enough to add up to a compelling reason either way.

Well, fclose can fail, for example; it can as part of the closing process flush its buffer and that can fail like any other I/O process. Further, sometimes the error than happened during a previous write(2) call is only detected in the close(2); think NFS and quotas, or check the man page. So already we have errors that occur during teardown that need to be handled somehow.

Similarly one can imagine using RIAA to hold a file lock, or a temporary directory; this is a perfectly reasonable thing to do but there are dozens of reasons why the final rm -rf of the tempdir could fail.

The idea that somehow object teardown is immune to failure is overly naive, and the fact that you can't accommodate it easily in RIAA is quite disappointing and makes the whole paradigm much less useful for carefully coded software.

This problem is easily resolved by noting that you think the method has to 'belong' to one type or another instead of exist as a first class object of its own. In practice this was done first in Lisp (the 'generic function' works better with typical Lisp environments than endless (send object message) calls, in particular with functions like map), and then the fact that the generic function treated one and only one argument specifically was noticed. From here we get multiple dispatch in a very natural way, a concept that is quite awkward in a language like Smalltalk.

I use the split keyboard all the time and for some reason my fingers seem programmed for the y key on the left hand, almost always. I've been using and noting this for a while but didn't realize that it extended to other keys. I think it's perfectly done; I use it by accident a lot and didn't even realize for a whole where the y key actually was! And this from a guy who types on Dvorak mostly.

Yup, in the working world it was not unusual for secretarial professionals to be expected to turn out a perfect page every time or redo it until it was perfect.

The one thing the M doesn't convey of the total Selectric experience was the immediate and alarming belief that, after every keystroke, the typewriter had launched itself an inch forward (no mean trick considering how heavy they are!). They usually didn't do this, but I've never had that 'did I just stick my finger into a bear trap?' feeling with anything else, even other electric typewriters.

The observer, of middle 20th century American desks, might think that the solid oak frame and general bombproofedness is at attempt to convey solidity in the person behind the desk, a psychological trick. They may be that, but they are also built the way they are because people typed on them with these things, and lightly built IKEA desks could very easily shake themselves to bits. I recall a story involving a typewriter lift in the side of one of these desks, of US Navy vintage, whose massive spring was calibrated for some ridiculously heavy typewriter--possibly a Selectric. When the typewriter itself was on the platform, it rose smoothly and gradually to a working height. When the platform was unloaded or loaded with, as I recall, a CD collection, the right word for what happens next unless you are extremely careful is "catapult" or possibly "major concussion and several months worth of dental work".

No keyboard has ever even loosely approximated this unless it was also connected to a typewriter (the TTYs and whatnot). Which, on balance, is probably a good thing.

What they're actually doing is conflating programmer and sysadmin here; the tasks they're assigning to the 'on-call programmer' are very similar to the ones I would expect as a sysadmin to get. Things like monitor the service, act as first responder, coordinate fixes; there's precious little that is actual programming there until you get into fixing it, and even there the goal is minimizing downtime, not debugging the change into working on the live system; typically "revert whatever changed" is one of the first tools for this work.

An actual need to do programming instantly and with no warning is quite a different proposition, not one that I'm aware of having ever been needed in any of the companies I've worked for.

Ada 95 is a very different language from Ada 83, cleaning up a bunch of rough edges in the latter. That said I still don't really like it, for aesthetic reasons more than anything else.

That's a good point, and what I actually did last time this came up. signalfd on Linux just codifies this convention, but it is (particularly in evented code) an excellent idea.

Signals do not interact gracefully with the rest of libc or the kernel, let alone concurrency. Signals can come in and interrupt kernel system calls--this is what EINTR is there for. When in the signal handler itself, the list of libc functions it is safe to call is small; the Single UNIX specification only guarantees less than 120 functions. V7 signals are not reliable and so it is dangerous to be in the signal handler for an extended period of time; but even BSD and SysV reliable signals have a list of caveats as long as my arm. The synchronous (think SIGFPE or SIGSEGV)/asynchronous (think SIGINT) distinction is an additional complication that the interface needed like it needed an additional head. And I haven't even gotten into the interactions between signals and process groups. Basically signals are a primitive, crude and dangerous form of IPC that one is nonetheless obligated to pay attention to.

As a rule of thumb I generally prefer to use signal handlers to set a small amount of global data and nothing else, and have the main interrupt loop notice and deal with the condition. It's possible to use weird siglongjmp things to get to the main loop if you are not there already, but (like longjmp in general) it is kind of weird and bizarre.

Actually anything that's gotten as far as journal publication should be exactly reproducible; I remember having to include the packages I was using and everything else in one archive for my couple of journal publications. Conceded that folks are not quite so careful for off the cuff work; same thing as having file:/// URIs in web pages.

And I'm hesitant to complain about it too greatly; my father's PhD thesis cannot be reproduced without a specific type ball for a Selectric and I know of numerous people who have kept dragging their old text files off disk packs to magtape to 8" disks to 5 1/4" disks to 3 1/2" disks and finally to CD ROMs where they have to duplicate all the CDs every few years lest they become unreadable due to dye fade. I know several photographers who are downright paranoid about an almost literal bitrot—if you ever want to see someone spitting mad with rage, telling a photographer that his precious negative or RAW file cannot be located, or read, or even decoded (a nontrivial issue with RAWs and older image formats, and depending on language and system even with text files!) will get you there.

Saying "if you preserved the files, we will recreate your masterpiece exactly" might be an overreaction to this but it's not impossible to understand where people are coming from. Particularly the poor dears coming from Word where moving a document from 2002 to 2008 will change the typesetting subtly and sometimes not so subtly.

The TeX community in general has a philosophy that anything written since 1983 (TeX'83) or so should a) compile and b) produce precisely the same typeset document if it is recompiled today. This has obnoxious issues and is one of the reasons for the profusion of packages--the norm is to change the name for incompatible changes so that old users can continue on.

I played around with Lout for a good while during my brief fling with alternative typesetters; this included tracking down some of the (quite scarce at the time and still not easy to find) troff macro documentation.

It's cute and I liked that the language was generally sane but ultimately the typesetting quality was noticeably inferior to TeX even for block text; for setting mathematics Lout manages to make almost every single decision subtly wrong. Lout text quality is about comparable to troff in this way. If I'd never seen TeX it would look probably fine, or at least acceptable, but I can't stand to look at it today.

Tufte's books are actually very readable and approachable, unlike say TAOCP (which is very well written but so unbelievably dense…). I don't think it's unreasonable to expect people to actually read them.

If you want to go IDE qua IDE, with the shell linking everything up, tmux is much easier to control from the command line than screen is. The multiple sessions business is actually quite cool with a utility like tmuxinator; you can switch to and from them and retain clipboard status, etc. The way the window splitting works reminds me a lot of xmonad (which I also run) and I'm not sure yet which mode of use I like better. Screen doesn't handle multiple clients with different window sizes especially gracefully; because I run tmux and xmonad I tend to have weird shaped windows, which behave exactly as you might hope with multiple clients.

I'm not sold sold on tmux over screen, but I do like what I'm seeing.

I am actually of the opinion that UEFI isn't "complex" enough—the best BIOS I've ever used is OpenBoot, with the Forth interpreter. Simple in some ways but very very flexible, more than enough to blow your while leg off. And yet more pleasant to use than anything else.

Here are some of the situations I run into on a regular basis at my current company, which is Perforce based, where I wish we were git based instead. This would be as true in Subversion. They might be maybe less true in Mercurial or Bzr, I'm not as familiar with those ones.

* I am hacking on some bit of code, so I set up a Perforce branch. While I'm at it I notice some ugliness and want to refactor it. I could make a new Perforce branch and put it there and then do some horrible merging apparatus but it's complicated and they live forever and it takes me out of the flow state, so I just make a commit. It is now very difficult to extract that commit from its context so that I could apply it independently.

* I make a mistake on a commit that is on a private Perforce branch, or maybe I did something out of order. The Perforce way is "you shouldn't have done that, then." and so my commit logs are full of "fix stupid typo" type commits that are basically just noise.

* I forget to add a file to Perforce and nothing tells me about it, ever, until we get to testing (or sometimes to production!) and Puppet won't run because it can't find some file <foo>. This is fixed with the 2012 betas and p4 status, but those require a server upgrade (because the p4 client is a thin wrapper around what the p4d server understands) and that isn't in the cards yet. This alone is enough to make me want to use git-p4 for everything.

* You can really tell that Perforce is built around a file system of RCS files sometimes. While it has atomic commits, many, many operations are based on individual file revisions (labelling, cherry picking, merging). This leads to the following:

* Cherry picking in Perforce is hard, because it's hard to get handle on the content of a changeset, as opposed to individual upticks in each of the files referenced. It can be done but it is a lot of effort, way more so than in git.

This is not the entirety of my complaints about Perforce, by any means, but they're the most visible UI limitations compared to what I'm used to from git.