dododo

i think the real reason for not releasing this code is time---you might be surprised at just how much effort goes into making a paper/talk/article polished. sure, you could just release the hacky code you used to do your calculations, but you'd like so much more---for it to be useful, for it to be a credit to you, for it to also do XYZ. research code is efficient in that it gets exactly what you want for the paper; it's rarely usable by anyone else. there is essentially zero payoff in academia in publishing code, and so there's no time to fulfill these desires.

wouldn't it be better to have expected volumes and masses for various items, and where items defer from these expectations, they get inspected fully?

many customs sheets include a declaration of the package contents.

the ones that do change (and improve mostly) are ones where the kernel actually plays a role--file system, network, etc.

the iozone benchmark is a bit surprising, it shows no improvement. but they are hitting 200MB/s, so i wonder if this is simply because linux is hitting the max speed of the disk.

all in all, not very useful.

optimality entirely depends upon your cost function. so pick the right one and optimise. the author clearly has one in mind---paying out the least money to eliminate the debt. but this doesn't seem the right one to me.

for example, i would much rather pay off small debts to friends (which typically have 0% interest) over larger, higher interest rates to banks, simply because there's a social cost owing money to friends, whilst it's kind of the purpose of a bank.

andrew mccallum, one of the originators of conditional random fields and also an NLPer, has recently been using scala: http://code.google.com/p/factorie/

some other examples come to mind: wine's implementation of the windows api, various unices/linux implementing the unix api (but maybe there's some waiver here?), and so on.

from 2003, http://www.highbeam.com/doc/1G1-110814573.html

  Once the decision to purchase is made, 78 percent of the 
  participants said they wanted to use the product right 
  away and therefore choose to immediately download the 
  software. When purchasing CD-ROM versions, specifically, 
  46 percent requested delivery within a few days.

if you take security to be assured in some sense, TCSEC might be a reasonable standard. I do not know of any open source operating system certified to A1, but there is at least one closed source OS: http://en.wikipedia.org/wiki/XTS-400

if you mean track record, in terms of number of compromises, i'd be interested to see the data.

this seems like a pretty big milestone. in particular, clang now has a libc++.

they also mention now supporting objective-c++. that's got to be one strange beast to code in.

many universities still do teach Lisp (in AI courses, for example). this seems like an attempt to appeal to authority, which is another logical fallacy...

it's not a very good rootkit by itself, certainly, as typically rootkits will monkey with the kernel to hide processes and network sockets.

it's interesting because it's probably the simplest rootkit method i can think of (next to setuid binaries). it's less obvious than a setuid. it's not something that anyone sane would use by itself because like i said--it doesn't hide you.

they didn't appear to use pbkdf2 or similar to derive their crypto keys, so that isn't good. but at least they didn't make up their own algorithm (though maybe they're making their own crypto protocol--hopefully not--i couldn't tell from the code).

it's very easy to say "this sucks", it's harder to say "this sucks and here's why" and it's even harder to say "this suck and here's why and here's how i do it in my deployed product"

i don't think factorial is relevant here: combinatorially, factorial represents the process of sampling without replacement: so if you were to be able to only use each letter once in each domain, then you would get 26!/4!26! possibilities for 4c.

this is combinatorics: the art of advanced counting, not probability, really.

i think essentially no one using R professionally would accept Haskell or Clojure as a substitute. having spoken to a few: lisp-like syntax is "unreadable", and Haskell is too much effort.

http://aws.amazon.com/alexatopsites/#pricing

http://www.google.com/support/webmasters/bin/answer.py?answe...

1. break into your machine?

2. break into some machine?

if (1) then i certainly agree that none of this really matters (i apologise if that wasn't clear from my previous comment).

on the other hand, if his objective is (2), and not everyone is using some of this obfuscation, then this separates you from the crowd for a little while (but my model is that as time goes on, you are inevitably exploited).

i realise after your company was exploited it might make you feel like (1) is always the case but for many (2) is the salient threat.

there's probably a bug in some code on your system that's exploitable. maybe openvpn or ssh or its configuration (c.f., debian crypto bug).

under this model, anything that increases the time til (inevitable, under this threat model) success, works.

running ssh or openvpn on a different port or whatever to "hide" it, will help against mass scans for common exploits. it increases the work to find the problem. of course it won't really help against a concerted, targeted attack. but i'm pretty sure unskilled, mass attacks are more common than targeted attacks.

is your claim that dasher does not predict well?

or rather, that google scribe predicts better than dasher?

it would surprise me: dasher adapts to the linguistic habbits of the particular user. it learns in real time.

google scribe doesn't appear to do this. it doesn't know who i am.

http://www.inference.phy.cam.ac.uk/dasher/

it uses this prediction to make it efficient for people who cannot type, type.

http://www.fail2ban.org/wiki/index.php/Main_Page

http://denyhosts.sourceforge.net/

denyhosts has the difference that it synchronises this data amongst many hosts.

2. your point about "using distribution standard ssh, a secure root password and public keys" is a little moot in light of the debian ssh keygen bug? in this case you would have been better off with building ssh yourself (and keeping it up to date).

3. in any case, you are at most risk from your users. if they are compromised, you are also (public key or not).

http://www.clickteam.com/eng/tgf2.php

(i'm also a fan. an web games factory would be awesome.)

although sadly: http://en.wikipedia.org/wiki/Hushmail#Controversy

but for apps installed in developer-untrusted environments, using app keys (and requiring their "protection"--good luck with that) is reminiscent of the dvd/bluray shenanigans.