limmeau

The original rdiff-backup author went on to create duplicity. Maybe a big part of the rdiff-backup community has followed him?

I'm using obnam now.

Apparently, this is part of an in-memory NoSQL database with Lua stored procedures, called Tarantool. Has anyone used that?

http://www.tarantool.org/

I also use proportional fonts for Java to make the code look like it's taken from an algorithms textbook. Also, idiomatic Java as produced by IDEs usually doesn't align variables, so the code looks OK as long as the space characters themselves all are of the same width.

The C++ code I work with usually has more strenuous alignments which are only possible to get right in monospace fonts.

So signeds are better because they overflow differently?

If you program C like there's no overflow, it doesn't matter much whether you mis-index the next array with 4294967295 or -1. There's no substitute for overflow-vigilance, and particularly not rules like "such-and-such type is bad and such-and-such type is better".

(BTW: an ex-boss of mine claimed that signed ints were evil because because and insisted on using unsigned for everything, but that's a different story, and I'm glad he's an ex-boss)

Thanks for posting this. Do those Lua scripts run concurrently in any way?

Do you mean Corensic? Their homepage is now "under construction", according to Network Solutions.

frak seems to generate a regex that precisely only matches the input list of strings, no generalizations.

So this seems not to be the tool to auto-create a .gitignore file...

This produces inputs to an arbitrary regex library. You could of course build a regex "(w1|w2|w3|...|wN)" for words w1...wN (assuming an efficient regex library) and save the hassle, but the frak output will hopefully be more compact.

Compare this with the late PyS60, where you installed a little SIS on your phone, 2MB or so, and could then run simple Python scripts. Forwarding all incoming SMSs to another phone number was a six-liner or so.

I've never used it to build big apps, only toyed around with examples, but then again, it wasn't made for the big applications, rather for small ad-hoc scripts.

Kind of Eclipse plugins vs Emacs scripts.

Example: Visualization of 6 months of cell phone data retention of a German politician:

http://www.zeit.de/datenschutz/malte-spitz-data-retention

"no one wants to physically plug a smartcard into a phone"

SIM cards come to mind.

HN submissions can't have both text and a link.

MtGox at $90 and BTCe at $83. Easy arbitrage money? Probably not, but why not?

There's also www.quoka.de, a classified-ads site in Germany and Austria.

Advantage of writing it in C: You can prototype an example client of your runtime in C before your code generator is working.

According to http://xo-learning.org/family-oriented-xo-tablet-debuts-at-w... , this is essentially a 7" Android tablet with a separate educational UI with teaching programs. I wonder if that separate UI could be bundled as an app, eliminating the need for special XO hardware?

No, but maybe your Apple GeForce 5500 graphics drivers and the drivers for the ansible network haven't been backported, so you'd have to run headless and offline. Or in another layer of VM, or two if the VM's virtual hardware is still too new for the old kernel. At some point, you'd just start to believe unseen that the paper's authors were probably right.

That example still completely in the realm of software obsolescence. The LXC API may not be around in 2023's Linux kernels any more, just like Plex86 has been abandoned (and I doubt that Plex86 runs unchanged on a modern x86_64 machine with a 3.x kernel).

But hardware obsolescence is a valid issue, too. That's why I suggested Bochs as a lowest common denominator in another comment.

Pulling the long-time-portability lever one mark further, I suggest Bochs. It's slow because it doesn't use Qemu's dynamic recompilation, but on the other hand, that simplicity makes the job of future archaeologists easier.

However, I fear that a Docker container in 2023 will be as useful as a Plex86 VM image today...

My favourite is "toothbrush head".

I've never much read other fanfiction, and I don't mind the parody at all. Actually, it has kind of spoiled the plain HP for me because I just can't take their fixed gold-silver exchange rate seriously any more.

Next in series: convincing yourself that you're not one of those spammers everyone wants their daughter to not marry.

Repeat after me: "I'm providing people with valuable information that is highly relevant to their purchasing decisions".

Thanks for sharing -- I love puzzles like that.

Just curious: Were the lldb session snippets taken from the original debugger session? I keep getting weird looks when I use a command-line debugger just to have a transcript afterwards. (The weird looks being from people who'd rather send me a screenshot of their GUI debugger's call stack.)

Intelligence people call reading the newspaper "OSINT", open source intelligence. They'll claim there's more to it than reading the paper, of course.

And still, Git, compared to most centralized VCSes, forces you to consciously design the versioning workflow. Where will the repositories be, who pushes where under what circumstances, what repo makes the golden releases, will you merge the upstream into feature branches or will you rebase, all that.

That makes it harder to introduce Git in an organization where nobody brings along enough Git experience to design all that upfront.

You don't really have to understand the data structures any more than in any other VCS.

If you're on Subversion and ignore that the repo is basically a counted list of big file trees with properties on the nodes, you won't get branching right.

If (FSM forbid) you're on MKS and ignore that it keeps per-file version histories somewhere in the belly of the expensive server, you'll try silly things like creating new files on a branch.

And for Git, you learn that there are commits, trees and refs.

How does Frotz deal with the "no interpreters" rule in App Store?

Very appetizing course notes.

However, I wonder if it isn't too painful in the long run to teach OS programming on a target where you have to flip SD cards every time you compile (as opposed to one of those with a hardware debugger included, like Launchpad or ST Discovery).

When I took Operating Systems (INF242 at Oslo) ten years ago, we wrote an operating system for PCs that booted from floppies, and debugging was largely a matter of poking bytes to 0xB800:0000, which made this course somewhat unpopular with students with little low-level programming experience.

Or if you're in the southwest, I recommend 78266, which is Büsingen, a German enclave in Switzerland.