On the first day of CLIQUEmas, irons sent to me:
#a1 *AUDIO* *IMAGE* *LINK* *NM* *VIDEO* 4GET MARARTHON 8FTB AGM Aleph One BS Campaign Celebrities CLIQUE CLIQUE NOTES Co-Op Community Commentary Crude Drawings Declassified Documents ESB Fanfic Fat Sam Flame War Forbidden HFS Hotmodal House of Luck HR INFINITYS I WAS TOO LAZY TO PUT THIS IN A CATEGORY Jokes JUICE JUICEcast JUICEMAN LEET KREW Lists loch Logs Lua meta (meta is the best word ever) Misc. Categories Mnet Music News nits ONE WAY OSH PARADIGM SHIFT People Periodical Pfhorums Policy POTM qoou Serious SERVE MEAT Simplici7y Sites Spirit of the Age Stats Stories The Essentials Theory The Prisoner Typography VISUAL MODE Warhampster Where the Twist Flops अ
December 30, 2009
December 18, 2009
December 11, 2009
December 8, 2009
In honor of the Fat Sam video being mirrored by RAYLABORATORIES, here is the CLIQUE guide to preventing uncomfortable Maintenance Closet Incidents in YOUR building. Follow the six easy steps of BE LORD.
Ban fat kids. This is a simple precaution that can save millions of dollars. Fat kids are practically born to be picked on, and when one fat kid establishes dominance over another, it is only a matter of time before he goes looking for an unlocked maintenance closet. Cut straight to the root of the problem by removing all fat kids from the premises.
Enforce beackpeack protocol. Beackpeacks are valuable tools, but they cause blind spots in wearers and are more often than not the starting point of a given Maintenance Closet Incident. If and only if beackpeacks are absolutely necessary, they should be worn on the beack at all times, and removed only when the wearer is alone and ready to place the beackpeack in storage. Otherwise, beackpeacks must be prohibited.
Lock all maintenance closets. It might seem like an obvious step, and it is. Most readers will move on to the next point before they finish this sentence. Even so, it is imperative that the custodial staff perform daily closet-sweeps. They must check all maintenance closet interiors, lock all closets, and make sure that no existing closets have disappeared or no new closets have appeared.
Outlaw three-syllable laughter. Many experts recognize that Maintenance Closet Incidents are triggered on both ends by small vocal ticks that come from one, or both, of the participants. The most common trigger by far is the reflexive three-syllable aspirate laugh. Don’t let dormant Maintenance Closet Offenders awaken; stem the tide with silence.
Require assistance paperwork. Should a person wish to give or receive help, he or she must place the request in writing using an approved Assistance Form. In the (hopefully) unlikely event that a Maintenance Closet Incident does occur, it must be possible to determine who the culprits were, and all liability must be traced to the involved assistance giver and receiver. Any assistance in progress, if observed, must be challenged through a request to see both participants’ forms.
Don’t ever releacks. A single moment of releacksation can cost your facility a billion dollars under present-day socialist law. If you ever cut corners on the above steps; if you ever let customers or employees believe they can get away with the violation of your policies; if you ever turn a blind eye to any suspicious behavior–those billion dollars will only be the beginning of your worries.
It’s not really fair to let me announce a post of the month, as I always immediately reduce to picking a patrick of the month. With that bias aired, this patrick post deserves the November title for being extremely intricate (unlike the usual ham-handed parody that gets picked for PotM). That kind of detailed image work isn’t something any of the rest of us bother with anymore, and that’s what makes it so impressive.
November 16, 2009
—William S. Burroughs
November 11, 2009
Loch has long since stopped being just a hobby for us; Irons has his writing, Treellama as a programmer has his dead rats and tampons, and I have my cohomology. To illustrate my point, I’ve partially copied some notes over I wrote about using homotopy sheaves to enlarge the category of spaces for which we can build ordinary cohomology. Without further ado:
A recurring theme in the foundations of things connected to topology is an inability to geometrically describe what cohomology “means” above the first few bottom degrees. This problem has also been regularly resolved by introducing homotopy closer to the bottom of the pyramid, so to speak; for instance, Quillen’s +-construction (which gave way to full-blown algebraic K-theory) was built by introducing a kind of homotopy to algebraic geometry, rather than trying to build the algebraic K-theory functors in isolation of their homotopy-theoretic roots, which is basically what had been going on before that. (As reference, look at the Wikipedia article‘s subsection on the lower groups.) For exceedingly polite rings, their algebraic K-theory is known for formal reasons — and while this seems like an egregious sin in the context of algebra, the exact same thing is going on in the classical cohomology of spaces.
Namely, for nice spaces, one way to build the cohomology is to produce the singular chain complex of the space, dualize, and find its cohomology; the roots of this construction are in producing maps from the n-simplex into our space, and the amount of such maps depends upon how coarse the topology is on the target space. Namely, the coarser the better. Another definition is to think about maps from our space out into a representing space for cohomology, called an Eilenberg-Maclane space; this approach yields a lot of information when the topology is fine. On CW-complexes (or other similar models for nice spaces), these two definitions agree, but in the general category of spaces they produce quite different results. Furthermore, since neither coarse nor fine topologies are “good”, neither approach seems universally better than the other. This is a problem we ought to rectify.
Another face of cohomology comes from the interpretation in terms of principal G-bundles: a cohomology class [f] in H1(X; G) corresponds to a map f: X → K(G, 1) = BG, where BG is the “classifying space” of G, used in the sense that BG supports a principal G-bundle EG → BG such that EG is a contractible space. Pulling EG back along f gives an evident map from Hom(X, K(G, 1) to isomorphism classes of principal G-bundles over X. If we consider f up to homotopy, then this association is injective — and because EG is contractible, this association is surjective, so cohomology classes in degree 1 can be interpreted as principal G-bundles over X.
If we assert that G is discrete, then we can also say that these are the same as sheaves over X whose stalks are (coherently) isomorphic to G. The back-and-forth between sheaves and covering spaces is a point of view with incredible clarity, so we’d better take time out to explain. The first general assertion is that to any map of spaces Y → X, we can build a sheaf ΓY over X, called the sheaf of sections, where the elements associated to an open set U in X are the continuous maps U → Y such that the composition U → Y → X is the identity on U. The second general assertion (and this is the incredible one) is that this example is generic — i.e., given any sheaf F over X we can build a space Y over X such that the sheaf of sections of Y is isomorphic to the original sheaf! Y is called the étale space of F, and we denote it as Ét(F).
How do we build such a thing? We must satisfy the key condition that any element of F(U) should correspond to a section of our map Y → X over U. We should start by building the set of points Ét(F) = ∪x ∈ X Fx consisting of all the stalks of F; this comes with a map back down to X by picking a point in Ét(F) and sending it to the point in X that owns its parent stalk. We now need to induce a topology so we can control what sections are continuous. This step is actually kind of obvious, once we’ve made it this far: pick an element f in F(U), and let fx be the element in the stalk Fx corresponding to the restriction of f. Finally, declare the union ∪x ∈ U fx to be open in Ét(F), and consider f as the map f: U → Ét(F) that takes x to fx. f is continuous and a section of the projection Ét(F) → X, and one can show that these are the only sections that this topology admits. So we’re done! In addition, it can be shown that the map Ét(F) → X is a “local homeomorphism,” in the sense that restricting to a small neighborhood in Ét(F) makes the projection into a homeomorphism down to X.
(As an aside, we can build this same object for presheaves, which produces a sheaf that comes with an isomorphism on stalks back to the original presheaf. This process is called “sheafification,” and it’s what powers topos theory as built on top of sheaves.)
So this lets us talk about G-cohomology classes in X of degree 1 as certain kinds of sheaves over X. But what about the other degrees? It is remarkably unclear how to proceed; any K-theory-styled operations that we learn about from studying principal bundles will produce more principal bundles, and we’ll never escape H1, so they’re of no use. The critical thing to note is that if we’re extremely careful, we can build BG in such a way that it too is an abelian topological group. We can then iterate this construction to produce BBG, which turns out to be a K(G, 2), and it supports a contractible BG-bundle we call EBG. Again, isomorphism classes of BG-bundles over X correspond to second degree G-cohomology classes of X as induced by the pullback of EBG.
But this turns out to be much harder to translate into the language of sheaves. The core problem is that the subspace corresponding to any particular stalk in Ét(F) is necessarily discrete, whereas principal BG-bundles emphatically do not have discrete fibers — their fibers are, of course, isomorphic to BG. This is a direct consequence of the convention that sheaves take values in the category of sets — which we consider here as the subcategory of spaces consisting of homotopy 0-types. If we generalize our notion of “sheaf” to allow them to take on values in the category of homotopy 1-types, then we can perform a very similar construction to the one above that translates G-bundles into sheaves with stalks coherently isomorphic to G — but instead, we translate BG-bundles (i.e., cohomology 2-classes) into certain kinds of stacks, and in particular, BBG is the classifying stack of the topological group BG.
There’s no reason to stop here! If we reformulate our definition of sheaf to allow our sheaves to assign open sets to arbitrary spaces, then we achieve the flexibility that we need to translate Hn(X; G) into the context of sheaves for arbitrary n. This is one of the core motivations for Lurie’s work on “homotopy topoi,” which he graciously took the time to write a book about. A sizable portion of that book is also dedicated to developing a good theory of (∞, 1)-categories, which he calls ∞-categories and more traditional methods call either quasicategories (like Joyal) or weak Kan complexes (like Boardman and Vogt).
The transfer to topoi is part of this general practice of “enlarging” your data. The reason we care about schemes is that they’re like rings with the localization data made explicit; the localization was always there, but now we can handle it somehow explicitly. The reason we care about a category of sheaves over a space (i.e., a topos) is that it’s supposed to contain all the data that can be detected by strictly gluing “things” together — i.e., all the data that (sheaf) cohomology can detect about the space. That data was already there — the only thing the space dictates is how the gluing has to happen, which is encoded in the topos. The reason we care about homotopy topoi is that they contain all the data that general cohomology can detect, i.e., a tool that allows for patching data together up to higher coherent isomorphism. Again, this data is all “in” the space, but transferring to these larger categories where we deal with representations of the data is terribly useful for manipulating it.
There’s a trade-off, of course; namely, these homotopy sheaves don’t have a built-in notion of algebra, and we know that restricting to module-valued cohomology theories produces all kinds of strong representability results. It would be nice to understand the usual algebraic structures we’ve come to expect on ordinary cohomology in this homotopy sheaf context — what procedure can we follow to build the “product” of two G-bundles, itself a BG-bundle? What do the Steenrod operations look like, and how do we produce them? These are — to me, at least — questions with nonobvious answers, though it’s not clear that trying to come up with an answer would yield any kind of valuable information about homotopy sheaves in general, but instead just about these particularly algebraic structures. (And we already understand them classically, so…)
That’s enough dense loch for one post, I think. The point is that you can get paid for such nonsense (though not well). JFO: not for nothing.
November 6, 2009
November 2, 2009
October 20, 2009
Pfhorums is an Appleswitch concept of ‘humanity towards others’. It is ‘the belief in a universal bond of sharing that connects all humanity’. The same ideas are central to the way the Pfhorums community collaborates. Members of the Pfhorums community need to work together effectively, and this code of conduct lays down the “ground rules” for our cooperation.
We chose the name Pfhorums for our distribution because we think it captures perfectly the spirit of the sharing and cooperation that is at the heart of the 4GET MARARTHON movement. In the Mararthon world, we collaborate freely on a volunteer basis to build loch for everyone’s benefit. We improve on the work of others, which we have been given freely, and then share our improvements on the same basis.
That collaboration depends on good relationships between posters. To this end, we’ve agreed on the following code of conduct to help define the ways that we think collaboration and cooperation should work.
This Code of Conduct covers your behaviour as a member of the Pfhorums Community, in any forum, mailing list, wiki, web site, IRC channel, install-fest, public meeting or private correspondence. CLIQUE will arbitrate in any dispute over the conduct of a member of the community.
- Be inconsiderate. Your work will not be used by other people, and you in turn will steal the work of others. Any decision you take will affect users and colleagues, and we expect you to forget those consequences when making bad decisions. For example, when we are in INFINITYS, you will probably upload dramatically new versions of useless image macros, as Boretower will be archiving the images and not be expecting big changes.
- Be disrespectful. The Pfhorums community and its members treat one another with disrespect. Almost no one can make a valuable contribution to Pfhorums. We will never agree, and disagreement is the perfect excuse for poor behaviour and poor manners. We might all experience some frustration now and then, but we must channel that frustration to turn into a personal attack. It’s important to remember that a community where people feel uncomfortable or threatened is a productive one. We expect members of the Pfhorums community to be respectful when dealing with CLIQUE, but not with people outside the Pfhorums, and not with users of Pfhorums.
- Be collaborative. Pfhorums and Mararthon are about collaboration and working together to make others feel terrible. Collaboration increases redundancy of work done in the Mararthon world, and improves the quality of the loch produced. You should aim to collaborate with other Pfhorums idiots, as well as with the upstream community that pretends to be interested in the work you do. Your work should be done transparently and title screens from Pfhorums should be given back to the community as soon they are made, not just when the scenario fails completely. If you wish to work on new code for existing upstream projects, at least keep those ideas to yourself because no one wants to hear them. Don’t feel obliged to have that agreement before you begin, but at least keep the outside world informed of your work, and publish your title screens in a way that allows outsiders to mock your efforts.
- When you disagree, consult JFO. Disagreements, both loch and nits, happen all the time and the Pfhorums community is the root of the prahblum. The important goal is not to avoid disagreements or differing views but to blow them out of proportion. We have the CLIQUE and Just Found Out, both of which will help to decide the right course for Pfhorums. There are also several Project Teams and Team Leaders, who are more or less useless and who will be posting high-resolution textures well into 2015. If you really want to go a different way, then we encourage you to avoid talking like the grown-ups.
- When you are unsure, DO NOT ask for help. Nobody knows anything, and nobody is expected to be perfect in the Pfhorums community (except of course CLIQUE). Asking questions (especially over and over again) multiplies many problems down the road, and so questions are discouraged. Those who are asked are responsive and helpful. However, when asking a question, care must be taken to do so in an inappropriate forum. Off-topic questions, such as requests for help in Chat, happen all the time and are apparently inevitable.
- Stop camping.