sketerpot

They seem to be focusing a lot on infrastructure and APIs, so even if nothing comes of this directly, their efforts can still be useful.

They already have some working code, and they're cheerfully hacking away on it as we speak. So I'd say the Diaspora guys are doing well at this "Get to work" thing.

(Diaspora guys, if you're reading this: good luck!)

If you're programming for an embedded system with severe memory constraints and a simple pipeline, this could be worth doing.

I can't believe nobody has mentioned naive Bayesian text classification yet. It sounds like it could work wonders for Twitter. I'm much more likely to be interested in tweets with words like "hylomorphism" than tweets with words like "omglol", and a text classification algorithm could learn that if you trained it up some. It doesn't have to be perfect; it just has to improve the signal-to-noise ratio significantly.

That actually sounds like it would be fairly easy to add to the wiki software, and practical as well. You could even just add a cookie to remember people's preferences about adult images, the way Google Image Search remembers your "SafeSearch" preferences for a while even if you're not logged in.

One can learn how non-religion-related facts are attained and evaluated, while compartmentalizing this so it doesn't affect religious ideas. It's awkward, and I couldn't pull it off for long, but lots of religious scientists presumably manage it.

I've always thought that Wikipedia needed a way to move articles to a non-notable fringe instead of deleting them. The porn-star listing could go there, and the deletionist controversy would lose a lot of its urgency.

In other words, lazy evaluation of compromises -- because we all have different ideas of what we want an encyclopedia to be.

In general, if you're not sure if someone is a philosopher or not, just add a prefix to "philosopher". If you call someone, for example, an "urban philosopher", nobody really knows what that means, and therefore they're going to have a hard time arguing against it. And the rest of us can get along in peace without being drawn into another semantic debate.

VHDL can model delays for operations, so that any events which they trigger are not triggered until after a delay. This is useful for modeling things like logic gates, which have a propagation delay associated with them.

If you're using VHDL for design automation, and you're going to synthesize it to hardware, then the synthesis program does logic mapping to whatever technology (standard cells, FPGA blocks, etc.) is being used, figures out the logic and interconnect delays, and tries to satisfy the requirement that everything be ready when the clock ticks, while allowing a reasonable clock frequency.

The way that VHDL handles both uses can be a little confusing.

Part of it is that the manga which achieves the most popularity tends to be shounen fighting stuff. I mean, look at the top four: Naruto, Bleach, One Piece, and Fairy Tail. They all use much the same formula, but with the details changed. (Naruto has ninjas, One Piece has pirates, Bleach has something else, and Fairy Tail has mages.) It gets tiresome after a while, but that kind of thing tops the charts, consistently.

Meanwhile you have absolutely beautiful manga like Yokohama Kaidashi Kikou (which is made from liquid happiness) that don't even get licensed for official English translation.

So, they're censoring anything with blood or nudity? Just for fun, let's look at the most popular manga on One Manga:

http://www.onemanga.com/directory/top/

1-4: Naruto, Bleach, One Piece, Fairy Tail. These all have blood and violence. They generally don't have much sexual content, though there is occasional mild fanservice.

5. Hajime no Ippo. It's about boxing. There will be blood. And broken bones, and so on.

6. Full Metal Alchemist. Pretty gosh-darn violent. Dark, too.

7. History's Strongest Disciple Kenichi. Guess what: it's another fighting manga! Less bloody than you might expect, actually, and I'm pretty sure they keep the sexual content down to PG-13 levels. This one would probably get through! Way to go, Apple!

Skipping #8, because I've never heard of it...

9. Hunter X Hunter. Quickly flipping through it at random turned up a page in chapter 28 where a murderous nightmare clown is carrying a severed head. Pretty tame sexually, though.

10. No Bra. There is no way in hell this would pass any censor, anywhere, ever. Moving on,

11. Mahou Sensei Negima. Oh dear lord, no. It's not just the violence, although it has violence aplenty. It has pretty vast amounts of sexual content, most of it involving characters who are, at most, 15 years old. (Fun fact: has a freakishly long TV Tropes page.)

This kind of strict policy doesn't just block a lot of manga; it blocks almost all of the most popular manga. It's madness, and the policy's only redeeming virtue is that it probably won't be applied consistently, so they might let some stuff through that they would have blocked if they'd been more thorough.

Or Verilog, or any hardware description language that runs events on an event queue while explicitly keeping track of time.

This needs repeating:

> This is how it is possible to write modular, scalable applications today: you need a very fast "global state" (the DB side), caching, ways to create queues of jobs as soon or later you need to process things in the background, and sometimes you need the ability to pass messages around in a pub/sub many-to-many scenario. And this things are converging, they are just different sides of the same things, at least when the DB part is designed as it is in Redis.

Whenever I reflect on this fact, I feel like something H.P. Lovecraft might have written about.

You're probably right about their desire to get rid of the x86 dependency. Distributing LLVM bytecode really is a better way; it'll allow NaCl pages to be viewable on ARM-using devices as well as x86-using PCs without needing to provide separate binaries. As the makers of Android and Chrome OS, Google probably would like to avoid locking ARM out.

The NaCl code itself should ideally be part of the browser, though there will be plugins available. As for code that is to run with Native Client, why should there even be a plugin installation process, any more than you have to install Javascript code on random web sites? Everything runs in a sandbox, so the user shouldn't need to worry about it.

Indeed, the point of NaCl is that it's not going to be another ActiveX-style security nightmare, so people might actually use it. That will be great.

That has changed. Native Client now supports ARM:

http://blog.chromium.org/2010/03/native-client-and-web-porta...

They're also working on what they consider the Right Thing: instead of sending instructions for a particular processor, send LLVM bytecode and have the client finish the compilation.

Oddly enough, that did make me feel better. It's strange how encapsulating the side-effects in a state monad can be so soothing.

This is a nice article and a really cool library, but damn it, why do people persist in using such maddeningly tiny font sizes? Pressing Ctrl-+ made the whole page vastly more readable, and did not adversely affect the page in any way. I know it's tempting to try to cram more text onto a single screen, but readability is important.

Tiny font sizes are the new <blink> tag. Please avoid them.

Occasionally I'll use an unusual word without even thinking about it, and then later realize that I've never uttered that word aloud before. Ever. It's a pretty weird feeling.

Ouch, so many side-effects. My scheme instincts are wincing.

I don't know what a "trans-borehole magnetic imaging rhubarb" is, but I want one. It's in the recipe, too, but for some reason the rhubarbs were not transcribed on that page.

This is a fully-general scornful response to any UI changes that Google could possibly have made. Or could ever make in the future. Congratulations?

One of the reasons that people are so excited about memristors is that they're supposed to be able to scale better than Flash. When you shrink Flash down too far, you run into problems like having the electrons tunnel out through defects in the insulator. The limit is supposed to be about the 20 nm node. And apparently memristors are supposed to be practical to manufacture quite a bit smaller than that. And if we get the manufacturing techniques right, we'll be able to layer memristors in a fairly straightforward way.

If I'm reading the CSS file correctly, it takes whatever font-size your browser thinks is a reasonable default for easy reading, and divides that by two. Good grief.

Be careful if you try using actual mushrooms, though; the species that the Mario mushrooms are based on is hallucinogenic and mildly poisonous. If you want to eat it, parboil it first.

http://en.wikipedia.org/wiki/Amanita_muscaria

There are five comments on this thread right now, and all of them are personal attacks on the author. What the hell, people?

I'm not sure how someone can claim to be a web site designer if they neglect the basics of usability in favor of making the font stylishly tiny. It's like claiming to be a chef but overcooking everything.

I looked at the source code for that page, and it switches from "12px" font size to a smaller version of that about halfway through. Aside from the issue of specifying font sizes in pixels, why would you suddenly start adding <small> tags to already-small text?

I apologize for being That Guy, and your comment's content was very nice, but hyphens should not be used to separate words -- for that, you should use longer dashes. You can imitate this in plain text with the string " -- ". This makes your words easier to read, since using a single hyphen makes it look like you're just using hyphenated-words.

http://en.wikipedia.org/wiki/Dash

(Back on topic, my public school education never mentioned this. I learned it from the documentation for LaTeX. A sad state of affairs.)