jbert

In 2013, does it make sense to put each user in a docker/lxc container? I don't know the resource overhead, but I'd hope/expect that it would be within tolerances.

Then you can have rich features like includes without worrying about file-based info leak. (cpu-timing attacks are perhaps another kettle of fish).

I think this is pretty the same thing as storing a secure cookie?

Except the 'cookie' is the private key on the phone, so it's tied to the phone not to a particular browser.

Other than that, I don't see a difference between the two?

I think this is basically a long-lived session cookie, stored out-of-band.

I also don't see how the public/private keypair changes anything. Why not just store the nonce on the phone? If the nonce has only ever gone over https to the user, no-one else will know it.

Thanks. I misunderstood the original comment to refer to golang code. The edited comment is clearer.

Thanks. I misunderstood your (original, unedited) comment to refer to a golang goro (go func()), not clojure go macro.

Yes - this seems to be a key difference of golang's approach. The runtime+scheduler conspire to make a blocking goro much cheaper than an OS thread.

> Doing blocking operations inside a go is a anti-pattern.

Sorry - could you elaborate please?

In my understanding, in golang it's fine to block a goro with a blocking call, whether that be a blocking syscall (read/write/sleep) or a blocking read from/write to channel (perhaps multiplexed with select).

The scheduler will run other goros on the threadpool until the blocking call finishes. That's the "secret sauce" which allows you to write synchronous code in go without single-thread-per-goro (and requires a runtime to arbitrate the system calls and schedule goros)

> Somebody on Quora once wrote beautifully about how it's impossible for the rich to ever understand what it's like to be truly, horribly poor- because there is no escape. There is no safety.

Jarvis Cocker wrote quite a good song in that vein:

http://www.azlyrics.com/lyrics/pulp/commonpeople.html

Interesting, thanks. Note however that the ZX spectrum also did tokenized input. Each key corresponded to a different basic token: http://fms.komkon.org/Speccy/SpeccyKeys.gif.

In the context of lexing and parsing, I was wondering about this idea. The program entry system is kind of like a potentially context-aware parser. No more syntax error are possible...

Are there many (computer) languages which don't use a text file (in some encoding or other) as their 'normal' representation?

If the compiler interpreter wants a tokenized input, perhaps we could/should save in that format?

Obviously the code-entry system (not sure that it's an 'editor' at this point) has to have an efficient way to let you select which tokens to enter (and enter free text in allowed places, i.e. string literals and comments).

That could either be 'one token per key' a la ZX Spectrum Basic (the only system I'm aware of which works this way): http://en.wikipedia.org/wiki/ZX_Spectrum#Firmware or something which looks the same as auto-complete to the end-user.

The typing experience would be much like a modern IDE, but would not allow you to enter or save incorrect text strings where a token was required, and would not require a lexing step (since it would be saved as tokens, or possibly even as an AST).

> I gathered current requirements and implemented them in the simplest way possible.

If you can get complete current requirements, that's fine. The issue with this is "all the stuff which falls through the cracks".

In the example from the post, some code to "handle case where internet explorer is not installed". That the sort of thing which would often be missed in requirements gathering, discovered in the field and then patched into the codebase.

Sure - if you have one of:

* close-enought-to-perfect requirements

* close-enought-to-perfect regression tests

then a rewrite isn't too hard. But achieving either of the above is something I'd consider a hard problem.

Do you have a particular way of getting signoff that your current requirements are "complete"? That would be worth knowing :-)

I'd guess:

- write a little code to drive this API: http://stackoverflow.com/questions/7785096/read-laptop-batte...

- and either use a task scheduler to run your code every minute, or startup a long-lived process which just does this and sleeps

- output in whatever format you like. CSV is obviously good, but given richer APIs on windows you could dump it straight into an excel sheet I guess.

> Can someone explain the boiling water on his tongue?

The main thing stopping the molecules of a liquid boiling away (flying off, out of the container) is the pressure exerted by the gas above or around them.

If you make the liquid molecules move faster (i.e. give them energy, i.e. heat them up), a greater proportion of them will be able to overcome this pressure. So heating increases evaporation and leads to boiling - which we're familiar with.

Alternatively, if you reduce the pressure of the gas pushing the liquid molecules together, you don't need to heat up the liquid as much to get the same evaporation/boiling effect.

Reduce the gas pressure enough and the liquid will boil at a very low temperature.

> but all they really could do is incur losses for the customer.

If they could inject "incorrect" trades, could they put themselves on the other side of those trades via normal means and so benefit from such losses?

OK, thanks for the detail.

I've suffered from having designed bad/limited APIs before and watching as people dig into bits I didn't want them to dig into, limiting what I can do in the future.

Not sure on the best way to avoid it, but I guess it's a 'nice problem to have' since at least people are using your API.

> You are allowed to deconstruct the id that way because it's the only way to get the information.

If the API has a usable purpose without providing that info, then I think I'd disagree with you - since you're reverse-engineering the implementation to get more data out.

Reverse engineering is OK, but implicitly carries the risk that stuff will change and break you without warning, in which case you can't really complain, in my opinion.

If the API's purpose can't be fulfilled without that info, then the API was probably broken as designed (you needed to parse the id to get the info, they just didn't document it).

Perhaps his debt was in bitcoins, so it also increased (as priced in USD)

I'm not an fb developer and don't know the platform, but was that documented as the format? i.e. were you expected/allowed to destructure an id in that way or was it intended to be opaque?

> Because the "metal must be moved" number is way too low.

I can see that the regulation might be ineffective because of that.

But I don't see how anyone could claim such a regulation makes it more profitable to make late shipments.

I still don't see how the claim made of "The only way that Goldman could possibly make more money by artificially delaying shipments would be because of a market-distorting regulation." gibes with "metal must be moved" as the offending regulation.

Could you elaborate on how the "metal must be moved" rule incentivises delayed shipments?

Interesting comparison.

Would you rather implement POSIX over Win32 or Win32 over POSIX?

Because if your adversary is monitoring all the telecoms networks and/or is reasonably capable of backdooring your laptop, you can assume that they'll be able to impersonate you to your digital lockers (and/or know where they are, because you are in regular contact with them).

Why should the manually managing your stringbuilders be preferable to having the compiler do it for you? The example given is:

  String result = foo() + arg;
  result += boo();
  System.out.println(“result = “ + result);

creates 3 StringBuilders. I would have thought that it wouldn't be particularly hard to track that the input to subsequent "+" was the output of a previous stringbuilder, allowing easy re-use?

No, they just go into the zone.

You run a server for example.net. Your server will respond to any requests sent to it for records in that zone.

Someone attempting to reach your site will query the parent zone (.com) for NS records for your zone. So they will query for NS records for example.com against a server which is authoratitive for .com.

(How do they find .com server? They ask the root servers. How do they find the root servers? That's the bootstrap info.)

Thanks for the detail. I was worried about the escapes in the echo, but didn't check.

Agree. Or actually I start with a 'head -100' so I don't handle too much data in my pipeline until it's ready.

I've never aliased it, but yes I use your 'hist' a lot. Useful for things like "categorise log errors" etc.

Does everyone else edit command history, stacking up 'grep -v xxxx' in the pipeline to remove noise?

If I'm working on a new pipeline, my normal workflow is something like:

  head file     # See some representative lines
  head file | grep goodstuff
  head file | grep good stuff | grep -v badstuff
  head file | grep ... | grep ... | sed -e 's/cut out/bits/' -e 's/i dont/want/'
  head file | grep ... | grep ... | sed -e 's/cut out/bits/' -e 's/i dont/want/' | awk '{print $3}' # get a col
  head file | grep ... | grep ... | sed -e 's/cut out/bits/' -e 's/i dont/want/' | awk '{print $3}' | sort | uniq -c | sort -nr  # histogram as parent

Then I edit the 'head' into a 'cat' and handle the whole file. Basically all done with bash history editing (I'm a 'set -o vi' person for vi keybindings in bash, emacs is fine too :-)

I like slicing and dicing with awk, grep and friends too.

One thing I find odd that you have to drop to a full language (awk, perl etc) to sum a column of numbers. Am I missing a utility?

  echo "1\n2\n3\n" | sum # should print 6 with hyphothetical sum command

I suppose more generally you could have a 'fold initial op' and:

  echo "1\n2\n3\n4\n" | fold 0 +   # should print 10
  echo "1\n2\n3\n4\n" | fold 1 \*  # should print 24

But I guess at that point you're close enough to using awk/perk/whatever anyway. Which probably answers my question.

I don't disagree that human-readable doesn't mean "verbose", but in answer to:

> Why would I not save resources whenever I can, even though I don't need to do it?

It's a cost-benefit. You don't spend your evenings clipping coupons all the coupons you can (which would save you some pennies). Or if you do, you don't stay up late to do it. The benefit to you of some free time is greater than the benefit of saving the pennies.

Similarly, the cost of mild verbosity is balanced against the benefit.

Basically, I don't buy an absolutist position of "save wherever you can". There are costs to saving, make a judgement whether it is worth it.

> For who, how often and when exactly? As far as I have understood, we are doing something wrong if we have to deal with debugging protocols which implement an abstraction, rather than just let the abstraction do it's job.

Any time you're debugging "one layer above" and you're in Sherlock Holmes territory (i.e. the problem seems impossible, so one of your basic assumptions must be incorrect) you have to check stuff.

And if you check your protocol by using the protocol-parsing tool which comes with your protocol implementation, you're not doing an independent test that it's actually working OK.

As a more concrete example, I'm using a library doing AWS request/responses over HTTP. There are various places I could add instrumentation to dump information but:

- it takes work to add or enable. I can grab the on-the-wire protocol with strace or tcpdump (this a reason why it's always good to provide a non-SSL option for your protocol)

- whatever is causing the problem could be below the layer I'm logging at

- they are all error prone. Maybe I miss a part of what goes on the wire. The data-on-the-wire is the only thing which matters for the protocol. The other end has no additional state.

When you're debugging, you have to validate stuff. And look for patterns. Human-readable protocols facilitate both of those difficult activities, reducing friction.

I watched simple text-based internet protocols eat the efficient, ASN.1 OSI protocols for breakfast. From the OSI side of the fence.

You can talk about efficiency until you're blue in the face, but human-readability is very useful.

I used to be able to pretty much parse a hexdump of an X.400 P1 PDU by eye (certainly if I could reformat in a text editor), but even today I found it useful to eyeball a recalcitrant programs's HTTP request/response cycle by simply catching it under strace and grepping for "HTTP".

It's a massive reduction of friction to have human-readable protocols. I used to make the argument that it didn't matter and I was wrong.