premchai21

You might be referring to Greenling (http://www.greenling.com/), though I don't recall whether they're the only one.

Among other things, MyModule.camelize doesn't provide an extension point for polymorphism. Consider a serialization library in which different classes should be able to have separate freeze/thaw behavior. It's possible to do this in current-day Ruby without easy collisions, but it tends to involve cumbersome manual prefixing or emulating method dispatch yourself.

Methods being namespaced in packages separately from the class hierarchy is something CLOS has that I miss in almost all the more Smalltalk-y languages.

fork() only leaves the one thread running in the child, and at that point the fd tables are no longer shared, so trying to detect and close unwanted descriptors in the child after fork is not racy by itself as a way of mitigating the possibility of uncontrollable non-CLOEXEC opens elsewhere in the process (though this doesn't preclude it being a bad idea for other reasons).

There's signed commits, yes. Is there also "apply these but only if they have a valid signature from one of these people"? That's what I didn't see.

Darcs's send and apply work on this principle, of course, though I haven't seen it applied to XMPP specifically. As I recall, the manual even has an example of how to add an easy hook in Mutt to apply a patch from email. git diff and git apply are available for single patches, of course, and git format-patch and git am are optimized for the mail case so that multiple commits can be sent at once, though darcs apply has integrated PGP signature checking and at a glance I don't see anything similar in the git versions. git-send-pack and git-receive-pack also have an underlying role not strongly coupled to the overlay transport, but seem to be designed for bidirectional communication so that the repositories can negotiate about which objects they already have.

If you change it so that what feels "natural" to you is not what feels "natural" to everyone else, then you are in for a world of hurt when you find that all the resources you were relying on are no longer presented in a way that you're compatible enough to access.

As it happens, I'm currently in a slow period and looking around for side projects that might lead to money. The other posters have some reasonable general ideas, but if you're willing to provide more detail, I can see whether it's the sort of thing that I'd be able to either help with or find someone else for—right now I can't determine enough from your post to say anything useful that hasn't already been said. You can send me email at my HN username at mailforce.net, if you wish. :-)

I had not! That appears to work for now, though I'm not convinced it will continue working if Twitter continues going the way they are. For some reason that didn't appear in my search; thank you.

Sure, but you have to be careful of the gradual lockdown effect as more people get involved. The handling of non-public information is a cross-cutting concern. If everyone builds their software and security models around the assumption that all posts are visible to everyone (because it's the common case, and they decided, just as you're saying, that supporting the common case was the most important thing), then going back later after everyone's gotten attached to the software and trying to add private multicast without any leaks can be a nightmare. No one will be able to use it because their friends won't be able to use it unless every piece of software in between makes it work.

I'm tempted to compare to how deploying new transport protocols over IP is nearly impossible for consumer clients now, because everyone's built NATs that assume TCP and UDP, because those were the common cases and therefore the important ones and now anything else is instantly hosed. It's a bit of a bad example, though, because in the case of transports there are other reasons as well.

Well, let me clarify just in case: the “impossible” is an exaggeration, since they will eventually respond to things like email, but it's not enough to keep up. Many of the socially-important multicast messages only occur on Twitter. I've been meaning to subscribe to them with a local aggregator, since for those whose tweets are publicly visible that should be sufficient, but while my existing RSS links still work, I can't find any way to acquire new ones, so right now I'm reduced to manual polling.

Does that really qualify as open-Web facilities, though? Is it “show it to these people”, or is it “show it to these Google Plus users”? The latter is not appreciably better than the LiveJournal case, for me, and in fact this provides a demonstration of the lock-in effect.

Here's another one: Dreamwidth runs an LJ-derived codebase, arguably an improved one (they had considerably better separation of “subscribe” and “authorize” last I checked, rather than a “friends list” that conflates these), and some of the people I contact on LJ have moved there, but they all have continuous crossposts back to the original LiveJournal, and if I moved there I think either no one would read anything I wrote, or else the comment streams would be so disjoined that I would be effectively a strange-looking LJ user anyway.

That last is also a concrete example of why nonexclusivity is not a complete solution. The resource that's being fought over is not where one can read but where a bunch of other people do read. If everyone views your content at Phuubaar's House of Crossposts, then if Phuubaar cuts you off, you are still hosed in the general case even if you provide the same stream somewhere else, because those users are not going to know about it or are going to find it too inconvenient to subscribe.

And the tooling around Atom and RSS aggregation all seems to be built around the idea that feeds are almost always public. I haven't had any success with the idea of creating a private Atom feed and expecting any of my friends to be able to read it. Either it'll require authentication, at which point the software usually won't be able to access it, or I can try to use a capability-URL style, at which point one of them will punch it into their favorite everyone-shares-everything social aggregator (Google Reader?) and then my (illusion of) confidentiality is gone.

This is terrible, and I don't know how to fix it.

I have a large chunk of friends and acquaintances who now conduct their ongoing visible conversations with each other almost entirely on Twitter, many of whom have started becoming impossible to reach by other means.

They also have visible half-conversations with a similar number of other people whose tweets are “protected” so that only “confirmed followers” can read them. I don't see OStatus doing anything with the latter, and I don't think those people are going to move to public streams, and if they don't move, the other people interspersed with them won't move because it'll become impossible to talk to them. This is more or less the same reason I still reluctantly keep a LiveJournal: the open-Web facilities for “but only show it to these people” are severely lacking (and I haven't found a good way of doing anything about this yet).

There's also the issue of social networks including things that are de facto currency-like: “number of followers” on Twitter is an obvious one. In a distributed network these usually can be faked, or at least are that way on the UI side since it's hard to generate a UI for that that doesn't drive the user's security-related cognitive load through the roof. (Or reveal more information about subscriptions than people prefer, but that's a shakier reason since some existing networks already reveal that graph.)

Is there any push for OStatus or other distributed social network approaches to handle these use cases? I haven't been able to find any, and OStatus seems to think the restricted stream case is explicitly out of scope.

All right, I see it in C99 as well now (§6.5.2.3 footnote 82, if I'm not mistaken). Thanks for the correction.

I actually use macros along the lines of:

  #define LOAD(TYP, ptr) (*((TYP *)memcpy((TYP[1]){ }, ptr, sizeof(TYP))))
  #define REINTERPRET(AS_TYP, FROM_TYP, val) LOAD(AS_TYP, (FROM_TYP[1]){ val })

In practice (that I've found, with GCC), the memcpy and single-use temporaries get optimized away entirely. In strict C99, writing one member of a union and then reading a different member of the same union is undefined in the general case, last I checked. http://cellperformance.beyond3d.com/articles/2006/06/underst... seems to agree, but suggests that every major compiler recognizes it as a de facto idiom and supports it anyway.

It does in 3.7.13 (and presumably older versions, but I don't have a solid record of this immediately available).

But, last I checked, you could PRAGMA foreign_keys=off temporarily, which would also inhibit the automatic handling of foreign key constraints in other tables when the target table is renamed or dropped. Then you can create a new table, populate it, drop the old one, rename the new one to the old name, and turn foreign_keys back on, and the constraints will now target the new table.

Resuming fetching multiple unfetched fragments of a resource is already possible with HTTP range requests. Checking the entire file can be done if the server provides a Content-MD5 header (though I'm not sure actual client use of this is widespread), and checking parts of it is infrequently useful by itself to the processing application and would be highly application-dependent even if so. The big win of BitTorrent is the distribution of available channel capacity over the swarm of downloaders; if you're not going to use that part, HTTP does quite well by itself.

It is actually possible, though not necessarily advisable, to pay US taxes using credit cards: http://www.irs.gov/efile/article/0,,id=101316,00.html

In a billiard-ball model one would construct a NOT/inverter with a crab source that normally flows straight to the output but can be misdirected into a drain by crabs coming in from the input. Of course you need a crab source for this, but this is little different from electronic transistor-based computers, where the inverse of Vss is Vdd and the Vdd comes from the power supply.

I suppose being able to try out the API on the software level is useful, yes. I'm not sure how one is supposed to figure out whether results are likely to be good enough for a given application if they're so unpredictably degraded. I do suspect my perception is being colored by the website text, as quoted above.

504 Gateway Timeout would be the obvious one, since if I'm reading this correctly it's essentially a timeout of zero; 5xx status codes are indicative of retriability later on.

But I think that sort of performance would make the free tier essentially worthless. “All you have to do is hit our API endpoint, and BAM, you get results back.” Except you really don't. Analogy: a caching DNS resolver that returned an instant SERVFAIL if the results weren't already in memory wouldn't be considered acceptable even for demo purposes anywhere that I've seen.

I wish I had time to write a more thorough response right now, but I just did a short test with Debian sid and its GCC 4.6.3 on a modern Xeon machine under Xen (so, not the best performance testing device, so take this with some salt).

At -O9, the compiler optimizes a masks-and-shifts swap of a uint64_t into a bswapq instruction identical to the one emitted by the GCC-specific __builtin_bswap64; this can be coupled with an initial memcpy into a temporary uint64_t. Loading individual bytes and shifting them in emits a pile of instructions that take up 16 times as much code space and ~35% runtime penalty (2.7 s versus 2 s). This is measured in a loop decoding a big-endian integer into a native uint64_t and writing it to a volatile extern uint64_t global, 2^30 iterations, function called through a function pointer.

Aligned versus unaligned pointers seem to make no real difference on this CPU, using a static __attribute__((aligned(8))) uint8_t[16] and offsets of 0 (aligned) and 5 (unaligned) from the start of the array.

I also tried a function with the explicit cast-shift-or that uses an initial memcpy into a local uint8_t[8] in case the compiler was doing something strange with regard to memory read fault ordering as compared to the explicit memcpy in the two bswapq-generating versions. This resulted in some very "interesting" code that shoves the local array into a register and then very roughly masks and shifts all the bits around, at about a 100% penalty from the bswapq functions. :-(

If anyone's interested in the details, reply and I'll try to put them somewhere accessible, though it may take a little while.

LZO, though, has the potential problem or benefit (depending on your situation) of not being readily incorporable into proprietary software without navigating Oberhumer's commercial-license maze, unless there's some form of clean-room reimplementation around that I don't know about. (“LZO Professional” at http://www.oberhumer.com/products/lzo-professional/ claims to be available only as a “binary-only evaluation library” under NDA; I don't know whether “evaluation” in this context would obstruct use in an actual product.) The zlib license makes it much easier to deploy. liblzma seems to be in the public domain.

"Octachoron" would work just as well (progression from "tetragon" and "hexahedron").

Do Tokyo Cabinet and Kyoto Cabinet still use totally unprotected mmap? Last I checked, truncating the DB file in the middle of an operation would take down the entire process with SIGBUS, and I assume a disk error would do something similar. This seems like it'd be bad for fault tolerance. Or are storage devices just that reliable nowadays, or does enough else break along with them that they're considered a critical component anyway?

As a mild counterpoint, I semi-recently tried to start habitually compiling my executables with -fPIE on my AMD64 development machines, and at least several months ago, the GDB I got from Debian sid was not up to the task of debugging such a creature and would fail to attach to the process and emit mysterious error messages. AMD64 being a mature architecture where I would expect PIE to have a significant benefit, it wouldn't surprise me if this were true for ARM also, or if other toolchain elements had similar problems. So that could provide a disincentive to switch over to position-independent executables.

I would think that a significant part of money-handling costs (in the general case) is mitigating risk of loss of money through fraud, theft, and similar means. That risk would have to be very small to be ignorable at scale. If you process ten transactions of a thousand dollars each and have to refund one of them out-of-pocket because it was invalid and the thief moved the money out of reach, that's a lot different from processing ten transactions of one dollar each with the same per-transaction risk. It makes sense that this would lead to amortized risk-level × transaction-amount costs.

Let me clarify: I didn't mean to say “this is directly part of the commons”. My main objection was to the idea that it was unambiguously not part of the commons (“as far from … as you can get”). I think that is incorrect because it is ambiguous: the physical world enforces more interference than you seem to imply.

I currently live in an area in which my window coverings are regulated to show an off-white color on the outside when closed, for what little that's worth. And almost all jurisdictions have some regulation on public clothing: public nudity is often punishable, for instance, thus excluding clothing with the color “invisibly transparent”. I neither directly support nor directly reject such laws, at the moment.

My best approximation of a “correct” solution might have involved upgrading everyone's perceptual filtering capability enough to obviate most commons regulations, but I've recently gone through a (possibly fake—I haven't stabilized the prionic meme filter yet) realization that humans are not at all what they seemed to me to be earlier on, and the inference propagation has not converged, so that shouldn't be treated as a stable opinion.

Actually, it's not. As far from the commons as one can get might be more like a heavily shielded, localized room in a remote area with no sound, light, or other effects going in or out except for some set of operators.

What is the sight one sees upon traveling through an area? A composite of many things, but including a large amount of the public faces of shops if there are any. Yet surely that sight has a considerable impact on the common areas.

I'm guessing that Flash being embedded from scribdassets.com is the list? I don't suppose there's a way to get access to this in plain text, or even a raster image?