gchpaco

A real manual has better tactile feedback so you can know when it's safe to hit keys without getting a jam, I think that's a lot of what was going on here.

You know what gets unending amounts of vitreol thrown at you? Working customer service. Especially tech support. I had urges to smash phones whenever I heard them ringing for years after doing tech support for three months. Tech support is a job where you sit on a phone and people abuse you all day, day after day.

Only cops get to pull this sort of crap in response. Find yourself a retail clerk and ask them how much abuse they have to quietly take, every day; it'll shock you.

The Symbol workaround cannot ever clash with uses of `with`. Granted almost everybody considers `with` to be a bad idea nowadays, but that's part of the rationale.

He mentioned being somewhat forgiving when people invariably screwed it up to 'rr' or 'orr', but I think he was Norwegian. So this may be a much more common problem with accepted solutions in his area of Europe. What drove him up the wall was when he typed his name in and the web site would be all "illegal characters in name".

How is ASCII or Latin-1 somehow not an obscure encoding scheme by your parlance? Latin-1 is less common by quite a bit on the web than UTF-8, and ASCII might be if UTF-8 wasn't a superset.

Fact of the matter is people have to get out of the habit of going "oh, that will never be relevant for me", because a) that's unlikely to be true for everybody (for example in a server environment you can't even write perfectly good North American names like Étienne let alone perfectly good older-than-the-country names like Þórr) b) it's unlikely to be true even for you as you will discover the first time you try to read a file written by somebody else c) it promotes intellectual laziness that makes later internationalization efforts difficult to impossible, because they're trying to convince people like you to care about stuff they find inconvenient but that is of vital importance to your customers.

I know of a man whose first name is Þórr who outright refuses to deal with any organization that will not let him write his name, and I have a hard time disagreeing with him.

I'm reminded of the discussions about XP when it was newer. Lotta folks thought XP meant "cowboy away" and then got excited when it invariably didn't work--the original folks said "well, look, you're not doing the process; you can't blame it if you're not doing it".

Now the thing is this looks a hell of a lot like a No True Scotsman argument, especially if you're only glancing at it in passing. Yet, boundary setting is a legitimate thing to do; the XP folks had put up their lists of practices, etc. XP is/was very demanding, very tricky to do; it was an open question for a little while whether it was actually implementable by average organizations. The interface with the product owner was a particular issue, and is still in Scrum.

Put another way, when you say "Scrum says to do X" (say, very few meetings which should go quickly), and someone goes "Scrum sucks because we're constantly in meetings explaining why we're not getting any work done", and you say "You're not doing Scrum"... you have a point. Scrum teams are not supposed to be crunching; if the product has to ship by date X, then some of the features won't get in, and it's the product owner's _responsibility_ to say which ones those are. If the product owner says "I don't care these are all mission critical we can't discard any of them" then you're not doing Scrum, even if you have some highly educated boob with a certificate from some idiot making them a Scrum Ninja or whatever saying that you are!

Now, some of the practices are more important than others, and most of these frameworks say "you kinda need to be flexible, but try it first". So there are grey areas. And sometimes (as with XP) the existence proof that it is even possible to do the process is nontrivial. But kabuki-scrum (thank you, quanticle!) is a real thing.

Yup, the problem with this is that it renders the other claimed advantage of reference counting moot (viz. there is now little or no temporal linkage between when the object's ref count hits 0 and when its destructor/finalizer is called).

The other problem with reference counting, which is I believe insoluble, is that it is inherently O(alldata); that is to say you must perform an operation each time a piece of memory dies, at the very least. This makes it good for collecting older generations in a generational GC (where O(alldata) ~= O(livedata)) but bad for the nursery (where the generational assumption means that O(livedata) << O(alldata)).

Yards are generally not in shapes that look like mazes crossed with Hilbert space filling curves, which the problem statement permits.

Unreinforced brick construction is actually illegal in many parts of California, possibly all. It's pretty easy to reinforce, though; if you sink rebar through the brickwork every now & again, it's as resilient as concrete and arguably prettier.

Admittedly this is much easier in new construction...

In the part of the US I'm in (California) they omit the insulation step, but otherwise yeah pretty much.

Folks in the US do produce real homes, but it's in very small numbers as a pseudo-artisanal thing. http://www.vermontframes.com are pretty neat, for example. The trend in timber framing has been to use structural insulating panels (which are actually pretty good and also, funnily enough, insulate) for infill between the timbers. Technically you can make the entire house out of SIPs, although they're not amazing looking.

Yeah, I don't think that's a reasonable thing to do even if you can do it.

The main reason all this tends to get pushed down to the FS layer is because of the question "what happens if the user accidentally creates two files with the 'same name' but different coding sequences". When it's the difference between README and readme I'm inclined to be like "well, that was dumb, move on with life" but it's different somehow for visually indistinguishable situations.

HFS+ is probably the worst filesystem in common use right now; even FAT has the benefit of simplicity. Most of its issues, however, are with its horrific implementation; the Unicode naming is kind of bad but Linus manages to be wrong about several things.

Regarding case sensitivity: it is generally accepted among the user interface crowd that (Western) users don't really understand that 'C' and 'c' are different things; they're "both" 'c'. Case-preserving is thus the accepted practice. However case manipulation is not an operation that can be done absent a locale; my go to example here is that 'i' upcases to 'I' unless you're a Turk in which case it upcases to 'İ'. Similar although not quite as bad is the fact that 'ß' upcases to 'ẞ' U+1E9E in some exotic circumstances; see http://en.wikipedia.org/wiki/Capital_ẞ for details. Similar limitations apply to sorting, which users also expect.

Regarding Unicode: NFD is a normalization format; it converts 'é' U+00E9 and 'é' U+0065 U+0301--which are semantically identical--into the same coding. As it happens NFD picks U+0065 U+0301 for that string; NFC picks U+00E9. Any time there is ambiguity, NF[CD] will retain the original ordering. Calling it "destroying user data" is meaningless histrionics. Most of the time we tend to use NFC. I am told that NFD has certain advantages for sorting, where one might want to match the French word 'être' with the search string 'etre'; in NFC this requires large equivalence tables but in NFD the root character is the same in both cases. Linus's claim 'Even the people who think normalization is a good thing admit that NFD is a bad format, and certainly not for data exchange.' has a big [citation needed] tag attached.

As it happens, my personal belief is the following: Given that users expect case sensitivity and locale specific ordering, which complicate filesystem design tremendously. Given that users mostly interact with the system through GUI dialogs, which already hide system files (files with the hidden bit in HFS+, or files starting with '.'). Therefore, extract the case sensitivity to a layer, used by the GUI, which can understand the user's locale and so fold case properly. This layer should be available to command line applications so that they can use the same rules if they so choose. The underlying filesystem will then be case insensitive, but is still used to encode Unicode data; the right thing to do here is to normalize. Either NFC or NFD is fine, really.

For pedants: the related NFKC/NFKD forms add a canonicalization step and are absolutely not semantically safe in any way, for all that they're useful for sorting.

Not divisible by three, which comes up a lot. 12 is superior.

60 is probably best, tho.

That's easier said than done. To make some of the mathematical equations work and be legible in several of my papers required a lot of subtle positioning; this was not helped by strict conference page limits or requirements for e.g. 2 column layout (which exposes a lot of weird issues with LaTeX's rendering, which then have to be dealt with). Knuth's original papers, lovely though they are, are much simpler. If you want an example, consider Figure 4 from http://sigwinch.org/Graham/papers/Interface%20Grammars%20for... which was really quite tricky to lay out. I don't have the source code with me right at the moment for some reason, but I recall it being very tricky to modify.

Perhaps this means we should be trying to do simpler stuff, but I'm pretty sure that's impossible in the conference driven world I found myself in.

Not quite the same, but one of the math professors from my alma mater could write faster on a blackboard than most people could write with pencil and paper and was not shy about erasing when he filled up the board. It was always crazy trying to keep up with him.

Nursery gc is proportional to the size of the live object set (here alleged to be 0) plus a constant overhead. It's not a simple thing to benchmark.

If there are no live objects in the nursery, a Cheney-style collector copies nothing and is done. The modification to mark-and-sweep to make it O(live objects) similarly is a bit more sophisticated but routine among high performance GCs.

From OP: "There are huge amounts of objects which are allocated and discarded milliseconds later."

Any mature generational GC should handle this with literally zero overhead. Assuming it is not doing a nursery gc every millisecond, all those objects should die in the nursery almost immediately. It has been well understood for at least twenty years how to do that in O(live objects), and the JVM has for all its many faults a very good garbage collector. So I am quite skeptical. This is also at odds with empirical evidence which is that going from 1.7 to 1.8 with the same world improves framerate.

Now the JVM gc has about a million tuning parameters and most hardcore Minecrafters have a witches brew of tuning that they run with. It's far from impossible that those tuning parameters are totally inappropriate with 1.8. But the GC should handle this fine.

Interface Builder was impossible in the C++s of the day. It is merely extremely difficult today. Remember that what IB did was build the UI using the actual elements, so you could play with it even without the logic hooked up, serialized that entire object tree, and then deserialized it at runtime.

I buy mine from Unicomp, and have been pretty satisfied. Although admittedly I've only ever bought two, and both of them have survived years of use.

Based on username, I would guess Zmacs.

There's important differences in color response, although a lot of the most modern films have very similar color response to digital (because the one was designed to mimic the other, obviously). The grain is also difficult to mimic precisely; film, being an analog medium, has sometimes superficially higher resolution than a lot of digital sensors but this is because it degrades continuously (whereas digital tends to be superb until you reach the handful of pixels range).

This is all, of course, in the context of color films. Black and white films are particularly difficult to mimic with digital, partly due to spectrum rendition issues that are difficult to recreate in post processing, partly due to very different grain structure (B&W grain is generally sharper than the dye clouds you get with color films), and it must be admitted partly due to romanticism on the part of film partisans.

The US military is unusually detached from reality. The ISS was under constant budgetary supervision and periodic redesigns despite costing, I think, maybe a tenth the F35 program.

None of which are likely to happen, I'd point out, because vim, emacs, bash and zsh are all tied into some sort of notion of a virtual terminal with software controlled cursors, etc etc etc. Plan 9's TTY is astoundingly primitive by those standards; essentially it emulates a line printer but doesn't even have the good grace to allow backspacing. Oddly, said terminal exposes the contents of the scrollback buffer—both read and write—to a file, which is how the native Plan 9 history mechanisms work. This is entirely deliberate, of course, and a substantial part of what makes the system so different and interesting, but step #1 to porting those would involve reinventing xterm, basically.

In theory for vim and emacs you could work around that by using the graphical interface, much as say Acme does. I would estimate this to be at least as much work as porting from X11 to, say, Cocoa was, and possibly even worse. And this port would only get you a vim or an emacs that was materially identical to its Unix counterpart—no Acme style control FS and essentially no cooperation with the normal Plan 9 UI elements.

Unfortunately that would be tantamount to wanting it designed and written by completely different people; Pike and Thompson are clearly comfortable with that level of abstraction, to judge by Go.

Moreover OSes designed with higher level languages tend to end up in a very different place even if they start with superficially similar assumptions—compare for example the early Lisp Machine OSes with TOPS-20, or ITS. "Everything's a filesystem" tends to mean "everything's a stream of bytes", which is in some ways a defeat for strong typing at the OS level for all that it can be convenient. I know I've had to write text level parsers for things like the output of multipath -ll (which is not standardized and is intended for human readibility and so changes radically every now and again, but is still the best source of some of that data). Now with Plan 9's FS structure you can arguably turn tree-structured data into a filesystem with files as the leaves, but this doesn't generalize well to non-tree-structured data.

That said I really like the OS, and I'm even willing to admit that Acme is pretty good (just not to my Emacs-tainted taste). But I can't imagine what a relational DB would look like in that idiom, unless it's "SQL query as filename". Individual tables, fine, but joins? Transactions?

Some of the papers I have written actually made the problem simpler with math--XML Schema being notoriously impenetrable, for example, and XACML not being much better.

And if you notice, they're still doing it. And it was still just as wrong.

I have a limited amount of time in my life and no wish to spend it playing "spot the logical fallacy in every paragraph" with McArdle. I have found it more efficient to learn that she is a feckless human being who will lie (by omission and otherwise) and entirely ignore her than teasing out the truth in her writings, which would require reading in detail the primary sources she is allegedly summarizing as well as the ones she silently omits.

Calling ad hominem is well and good and something to keep in the back of your mind, but I tend to agree with Daniel Davies that "giving known liars the benefit of the doubt" is more likely to steer you wrong.

Unreinforced brick will indeed fall down in even modest earthquakes. In new construction it is possible to sink rebar into the wall, at which point it is at least the equal of concrete (and certainly more attractive); however a lot of people don't want to bother with perceived time and expense and so we go back to concrete and stick framing.

Much construction in California is penny wise and pound foolish. It is routine to omit insulation from the walls in new construction, never mind that it will pay for itself in savings on heating and cooling bills. Wooden houses can be destroyed in an earthquake if the quake shakes them off their foundations; fixing this is simple and easy during construction but, again, wasn't done for a long time. I believe the only reason it is done now is code requirements—it would not overly surprise me to learn that the builders can't be bothered even in new construction.