premchai21

Reading this leaves me troubled. Why not the XLink vocabulary, for instance? I can understand something like this appearing for JSON if only so that people have an intrametalinguistic transition path for their JSON APIs, but letting so much existing work on interoperable XML representations fall by the wayside could be unfortunate.

Did you actually register the media types?

“Any and all elements are legal in a HAL representation provided they do not conflict with HAL's reserved elements.” If I'm reading this right: please, please, no. Not in XML. Allocate a namespace URI and use it. Let's not start down the path of everyone having to watch out for everyone else's element names again.

The idea of identifying multiple packed related resources (which could otherwise be top-level resources) in the same document is interesting. I don't immediately recall specific prior specifications there, but I'd definitely want to go through the W3C site with a fine-toothed comb to check. E.g., Atom feeds already can embed XML fragments of almost any other type (though most commonly XHTML) as entry content; there may be some evolution of that available.

Electrolytic capacitors are capable of popping violently should they become internally shorted by excessive overvoltage or reverse bias. The aqueous electrolyte destabilizes and produces hydrogen, which builds up pressure inside the casing until it leaks or blows. Dramatic video: http://www.youtube.com/watch?v=ToWsF3HcQUU

I can vaguely imagine a charging circuit being designed to have what amounts to a current source rather than a voltage source, but I don't know enough in detail to confidently associate that idea with the story in question.

Except for the Flash that's necessary in the background for the more advanced audio modes.

I don't see how it does. Making note of the entrenchment bonus granted by a language already known by much of the target audience isn't necessarily making a value statement about the bonus or secondary effects thereof.

It seems to me that it should be possible to use memcpy between multiple C variables to avoid straight type-punning, and then have the compiler reöptimize it into aliased memory or registers (assuming the source isn't volatile memory or something like that, in which case things get trickier anyway). This is roughly what I do in my C programs these days.

In some cases, declaring alignment may be hard to do portably; it's probably possible to use union tricks to force there to exist a dummy statement that implies certain alignment without breaking the aliasing rules, but I don't know for sure since I haven't run into such cases in practice yet.

As a nonrepresentative example, the simple function:

  uint64_t foo(char x[8]) {
    uint64_t y; memcpy(&y, &x[0], 8); return y;
  }

gets compiled into a single « movq (%rdi), %rax » by gcc -S -O2 on my AMD64 machine with GCC 4.6.1.

While I can't confirm it definitively, it looks as though it may require Flash to handle the audio underneath. If so, this is unfortunate, but perhaps understandable: as nice as the audio tag is for basic purposes, the lack of precise control makes composing sounds together problematic. The Audio Data API helps with that, but it's pretty nonportable still.

Last I checked, the LuaJIT allocator on AMD64 platforms uses only a small part of the address space for the Lua heap, partly so that more efficient type-punned representations can be used internally. I don't remember what the limit is exactly, but it's only a few GB (and beyond that the GC starts having trouble anyway). I don't know whether this applies to the machine-code JIT output, or to external cdata arrays, but it's something to watch out for here.

One major hazard is consumer-grade Internet service that has onerous terms that prohibit running servers from a home connection, for any number of reasons. (Some would see this as cultural complicitness with “client/server as technosocial class division”, but the effect is similar regardless of how it's spun.) A related technical problem is the use of carrier NAT, which gets very tricky to traverse.

So actually getting devices to call home to the “personal cloud” seems like it would be harder to make happen, and more importantly, harder to make reliable, because you can't use economic power to force at least one side to act in a convenient manner. This would drain the life out of any attempt at “you don't have to think about it very much”.

> Any member of the public can visit a local university or large public library and get access to any book or journal article they desire.

This has not been entirely my experience. Unfortunately, I only have a half-remembered anecdote rather than data, but what I've found is that journals in some university libraries are becoming less accessible in paper form. Instead, one is directed to a JSTOR subscription or such. Of course, in order to access the electronic version, one must authenticate to the network with a university ID. This erodes the effect you describe.

Can anyone else confirm or refute this trend? Am I merely imagining it?

I'm curious: are there reasons you were searching for a female designer specifically? (Unless I'm misinterpreting that sentence, that is.)

> So long as your CD doesn't include any square waves, you're golden.

Could you explain what you mean by this? Are you referring to certain patterns that fall within standard Redbook audio parameters that FLAC then fails to encode properly? Or perhaps to characteristics of CDs or CD playback equipment that are difficult to duplicate on modern-day computers? I can imagine something like preëmphasis being problematic sometimes, but that seems to have little to do with square waves.

A problem arises, however, when what appears “brazen” to people who have already interacted with a community for a long period is not so obvious to anyone else. Many community standards (such as “nice”) are nebulous and have vastly differing thresholds and signaling methods, and this is not something that can be easily resolved up-front. Applying subterfuge early in the process makes it possible for a well-meaning entrant to randomly lose by misinterpreting things early on, then being denied feedback that would allow them to make a more informed decision about their behavior. They are further punished by throwing their participatory resources into an invisible hole while thinking all is well. This is easily nontrivial collateral damage, depending on the set of visitors.

It's more like hiding a treasure chest somewhere in the ocean (of cryptographic tokens) and then losing the map (private key) when your ship (filesystem) sinks. (Arrrr!) This is something that happens with physical objects of monetary value as well, including cash itself.

So without the knowledge of how much cash I'm hoarding in my closet, how can you accurately value USD? I don't know how much of the answer is “you can't, exactly, but there's enough other trading that it doesn't matter” (which could apply to Bitcoin as well) versus “the value is fixed by external factors such as the US government”.

Hrrrm. This redefinition, while trivially possible, seems irrelevant. Possession of assets is first and foremost a practical matter. (I think you understand this, but for the benefit of the discussion…)

In the case of primary real-world goods, possession comes from being able to physically access the state of various matter and energy: I physically own a house to the extent that I can reliably live in it and make modifications to it and so forth. I physically own food to the extent that I can make use of it by eating it. Other people can alter the game by acting as environmental forces to change the set of available interactions.

In the case of fiat currency and economic goods, practical ownership (including but not strictly identical to theoretical legal ownership) is similarly determined, but with more of a focus on laws of people rather than the laws of physics; the former are backed by the latter, but usefully form a separate conceptual layer.

The case of Bitcoin is also analogous, but there is now a focus on the laws of mathematics as they apply to the state space in which the Bitcoin system operates, and in particular to the practicalities of computing—a strong cryptographic attack could still destroy the system.

So the reason that owning all the early Bitcoins prime is not useful is the same reason owning all the virtual dollars in a parallel system to the US banks is not useful despite being able to invent whatever such system you want. Because no one will recognize this, the amount this changes your set of available physical interactions with regard to primary goods is very small. (I haven't taken weird social goods into account in the above, but I think a similar argument applies since they also require external recognition.)

That said, I think the GP poster would do well to clarify what ey meant by “unique properties”, and perhaps whether (as I interpret it) “unique” is meant to be “of the set of currently active systems, for some fuzzy activity threshold”, thus excluding Bitcoin prime and the infinite variations thereof.

Actually, while the Bitcoin system itself does not arbitrarily distribute any money to new clients, there does exist a Bitcoin Faucet[1] to help newcomers try the system out, allowing various people to acquire a few free cBTC once.

[1] http://freebitcoins.appspot.com/

The part of this that stands out to me: the OS claims to be open source. But the bootloader is proprietary. Why? Does the source depend on proprietary specifications that have been embedded in parts of it or something? The documentation doesn't obviously preclude writing a replacement, but nor does it seem to be designed to encourage such a thing. On the surface it's not complex enough for this to be a huge task, but I'm suspecting there's at least one strange grinding obstacle in the way…

Are you sure about “none” being singular in that context? I agree that the title is inconsistent, but I'd have written “None of us know what we're doing” (if I couldn't just pick some other phrasing).

gcide defines “none” as “No one; not one; not anything; – frequently used also partitively, or as a plural, not any.” and also offers “None of their productions are extant. –Blair”, both purportedly from 1913 Webster. So it seems that the pronoun can be interpreted in either number as needed.

I'm certainly glad if MessagePack allows non-string keys in maps, as it apparently does (I've only read the spec so far, but not had a chance to try the code). This is a real pain in JSON.

My stock “basic data type” set comes mainly from Ruby these days. I wince a little at the lack of interned-symbol type, but it's possible to live without that. But what of string encodings? In a recent piece of code which I wouldn't mind replacing with MessagePack, I prefix strings with fixnum IANA encoding numbers. I suppose that's too much to ask in this context, though… ? How do other people deal with this—just force everything to UTF-8?

The big problem with mmap seems to be handling I/O errors. The most transparent uses of mmap are for executables. Failing to page in part of the program can probably reasonably result in a crash. But what of a server process handling a pile of different data on unreliable disks? Destroying the entire process on a single I/O error isn't ideal.

On Windows it seems like the best way to handle these errors is by either embedding SEH into the surrounding code or adding a vectored exception handler globally. On Unix, you have to set a SIGBUS signal handler. But then, mmap is apparently not guaranteed to be async-signal-safe if you want to remap a zero page over the broken one, and longjmp out of a signal handler is its own pile of potatoes; both seem to work on various modern Unixoids, but I haven't been able to find documentation saying that they'll continue to work. And with longjmp, or on Windows (where you can't remap pages over other pages directly, that I know of), any surrounding code that accesses the map needs to be abortable all the way up to a suitable error point rather than just having to handle bogus values. Much code assumes that a simple memory access will not cause a recoverable exception that may result in reëntering the code later.

And if you're in a library on Unix, good luck getting permission from the main process to alter signal handlers. The hook mechanism isn't as rich as that in Windows, so with the exception of large application framework libraries that are expected to take over the process anyway, it's an invasive and possibly irreversible activity.

This is all sad, because I love the idea of mmap. I was tinkering with a C library for accessing certain kinds of files, and I want to do it with all mmap, but I'm not sure I can overcome the I/O error problem adequately. (The blocking and address space problems are not too bad here; they impact performance and capacity, but not correctness.)

Actually, I'm in the target audience for phone books. I love receiving those (within reason). I wish I had more right now.

Why? Two main reasons. One is for actually looking up local telephone numbers. I prefer this to looking them up on the Web in many cases: the paper book doesn't call home, the business directory is harder to game, and it's all pre-localized. And it doesn't take away the choice of looking things up on the Web if I feel it's necessary, at the cost of some extra traceability &c.

The second reason is that I use extras as structural supports. Monitor too low (for instance)? Wrap phone book in duct tape. Now it's a brick. Construct environmental modifications out of phone bricks. They're relatively light while being solid, and they're already bound together, so you don't have the trouble of trying to make the rectilinear shape ex nihilo. I suppose I could buy stacks of newsprint paper or something, but going out and buying things is awkward, and phone books are often distributed free, so I'm only paying for time and duct tape.

FWIW, the main article has "GLBSE", not "GBLSE".

Obligatory story from the Old New Thing: http://blogs.msdn.com/b/oldnewthing/archive/2006/12/01/11847...

For reference, the wavelength of an 8 KiHz electromagnetic wave (the Nyquist frequency at their sampling rate) is over 36 km. (Edit: at the speed of light in vacuum, that is.)

Perhaps I'm misunderstanding something, but this would seem to limit the spatial resolution that could be achieved by sampling a single stream of passive voltages at that rate, and I would expect differences between materials to mostly be on the microscale. But they don't say what other constraints might be in effect or what the materials or environment are, either, so…

What would you recommend more specifically? In particular, whatever LastPass is doing seems likely to be fragile unless there's consensus about how to identify a form as one that accepts tokens (usually a username/password combination) to authenticate an existing user, or similarly set parameters for a new user, or change authentication tokens, or…

In the Unix world, there are various extant mechanisms for this around: PAM, LDAP, &c. However, I haven't detected any published rough consensus for the Web; searching for terms like “design login form common field names username password” doesn't turn up anything obvious.

The only strong heuristic that I can think of is detecting form fields of password type, and then distinguishing the use cases temporally based on whether you already have tokens cached.

> But have YOU read all the fine print when opening an account with your bank?

Yes. Paraphrased:

Bank agent: “You'll also have to sign this.” (Hands over a sheet of paper.)

Me: “Let's see here… […] ‘comply with the Deposit Agreement and Disclosure’. I need to see a copy of the Deposit Agreement and Disclosure, please.”

Agent: “Of course.” (Hands over a booklet.)

Me: “All right. Well, you may have to wait a bit…” (Starts leafing through the booklet. Cut to analog clock, then to clock fifteen minutes later.)

It was the same thing with signing up for public storage. “… ‘agrees to the Privacy Policy, which is incorporated by reference’. I don't seem to have a copy of the Privacy Policy here.” “Here you go,” and another sheaf of paper appears.

Note that in these cases I'm still basing my interpretation on a lot of contextual and cultural information, because while the alternative of trying to get them to lock down all the definitions separately would be amusing, it would fail. In many cases, every one of the relevant providers is in a position to drop me, whereas I'm reliant on at least one of them accepting me, so the power balance is tipped heavily in their favor.

(Compacted for space. Original. Use tr '/' '\n' | sed -e 's/^ //' -e 's/ $//' to reëxpand, with a paragraph break being "\n\n". Sorry for the repeated initial edits and such; I had to try to work out the HN formatting rules.)

When humans try to learn symbolic math / How many of them struggle with the test! / The teacher thought of like a psychopath / Dishonoring the realm of human zest

“We must have our emotions!” students cry / “Or else we'll run around like apes, confused / Our brains are built for stories, not to scry / A world of numbers, strangled and abused.”

The teacher sighs, “They always drag their feet / Unless they're cornered, up against the wall. / To risk my job with answers incomplete! / They'll never use it later, after all.”

Then, big surprise! The math is found at fault / Tear-stained by cringing memories of school / “Dispense with all the symbols, and Exalt / Thine Intuition”—that shall be the rule.

Professors' lamentations curse the air / Hung out to dry for calling any bluff / “To shun defective math must be unfair / For surely no one understands the stuff.”

So woe to ye from near the world of forms / Who strain to show the populace your realms / They're immunized against your grand transforms / And explanation only overwhelms.

(Now, please don't take this poem at its word / Or treat it as authoritative fact / Exaggerated story and absurd / Polemic leave specifics inexact

The author's nearly made of symbols, note— / Despite the slow decay of some to blanks / So though he doesn't mean to seem to gloat / He'd rather keep his “freakish” symbols, thanks.)

That certainly wasn't my intention specifically. I mentioned htmlspecialchars because it was the example being used upthread, but any API with analogous functionality is potentially subject to similar provisos, and if any surrounding cultural element encourages its use without thinking through the syntax layers, it can have a similar effect. I assumed this was implicit.

(Note that I haven't been able to see the original video so far, so add salt to taste.)

> If you manage to make a single tab commit that much memory as a delta without Flash (remember, 13 MB to > 400 MB) please screenshot about:memory and get back to me.

I can understand this as a weak prediction, but it certainly doesn't work as a strong one. I can trivially make a tab use over a gigabyte of memory in recent Chromium by creating a gazillion nested objects in JavaScript. (I just did, in fact. If you really want the screenshot and/or source, say so and I'll post it somewhere.) Absent some default limit in V8 that I haven't encountered, I could presumably make it use unbounded memory. I can also create apparently-unbounded latency in a single tab's UI this way, by chewing up CPU in blocking JavaScript code, though this will eventually trigger the “page seems unresponsive” dialog box.

I would also tend to expect an exploit to potentially abuse the JavaScript engine by straining its limits, including things like pouring a large number of identical objects onto the heap to fill memory with exploitable patterns.

I use single-quoted attributes on a regular basis when editing XML (and HTML, which I edit as XML) documents by hand, mainly because it conserves a noticeable amount of Shift keying on the US keyboard layout. If necessary I mechanically translate them into double quotes ex post facto, but I don't bother if I can assume a style of parser that will handle the single quotes.

> Inside on* handlers and style attributes, the rules are different.

That may be so, but I'm not sure I'd call that an “HTML” escaping problem per se. An attribute always has an additional syntax, and you have to account for the subsyntaxes of whatever attributes are in place—but those aren't at the HTML layer proper, only implied by it. E.g., a's href attribute takes a URI. onfoo attributes take JavaScript code. style attributes take CSS. So in order to make HTML “safe” (FSVO “safe”) when it contains those attributes, you have to make those values “safe” recursively according to their subsyntaxes—e.g., if you want to allow CSS with url(), then you have a URI inside CSS inside an HTML attribute inside an HTML document inside (for instance) a UTF-8 string, and you have to take all the layers into account.

It may be that a lot of people don't realize there's several potential layers of syntax involved, think of it as a monolithic and simple thing, and then get confused when it is not. Things like PHP htmlspecialchars can inadvertently encourage this kind of inaccurate view.

(I'm not disagreeing with you exactly, just describing from a variant perspective. A bit of redundancy in discussion can create an antialiasing-like effect.)