jbert

Thanks very much for that.

In terms of comparing the two approaches, I can see that if you are granting different creds based on a user auth, an STS is useful to grant temporary creds limited to a subset.

I'll need to look up the details of how much more fine-grained the STS tokens are than the IAM creds to see how much difference there is in the anonymous case.

So - there has to be some trust to the client, unless the resource is public (or locked down with end-user creds).

In this case, some kind of creds need to go into the app, right?

So the best practise is simply to make those some creds which: 1) have limited privileges (e.g. just access one S3 bucket) and 2) can be centrally revoked (requiring app update for everyone?)

I've read the link on the amazon Token Vending Machine approach, but I still don't understand why that is better.

If I have the embedded creds to get a token from the TVM, and that token allows me to access an S3 bucket, how is that more secure from using limited IAM creds which just allow direct access to the bucket?

In both cases:

- the creds can be revoked centrally

- possession of the embedded creds allows access to the S3 bucket (either directly, or by fetching a token first)

Would it work to have a different response to collision, namely to apply a reverse of your last step? (A full reverse or partial).

There might still be corner cases, but it would seem to resolve the described issue, since irrespective of where you think the other player is, if you both reverse your motion you should disengage.

I can see 3-body problems being more problematic, but that's probably also the case with the original code.

There's presumably no more energy being dispersed than with manual brakes. The current brakes will heat less (due to energy in the ERS).

If the ERS is full, you either switch over to dumping the heat into the brakes (no ERS, switching problems), or you start to drain the ERS to make room (no switching problems). Draining the ERS will give you the same thermal problem you have with no ERS, except you have the choice of not dumping it into the brake pads - you can have seperate external resistor coils, glowing and radiating.

Still not sure how that helps. In both cases, we have creds embedded in the app which can be used (and only used) for access to the AWS resource.

In one case directly (via an IAM limited account), in another via a token they can request. In both cases, the acct is limited to one specific AWS resource. In both cases, the creds can be revoked centrally. In both cases the creds are embedded in the app.

Smart people who build these things (AWS) seem to think a TVM is a better solution. I don't understand why.

I'm being dumb. I can see that it is preferable to embed credentials for a restricted IAM acct, not your root/master AWS account.

But how does using a TVM improve the situation? Surely you still need to embed creds which allow the app to use the TVM? In that case, an attacker can extract those creds, and ask the TVM for a time-limited token any time they like.

How does using a TVM improve security over embedding the creds of a restricted account?

> but if there are no normal returns involved, nothing on the stack will ever be deallocated, and your program is effectively just one giant memory leak.

This is true, but there is the glorious exception which is "Cheney on the MTA": http://www.pipeline.com/~hbaker1/CheneyMTA.html [https://news.ycombinator.com/item?id=7417906]

This describes a way of implementing a scheme->C compiler using CPS which allows the C functions to never return, and doesn't blow the stack. When the stack gets big enough, you do a garbage collection run, copying live data to a new stack. Then, you reset the stack pointer using a judiciously chosen argument to alloca().

I think the main difference is the way the language and runtime collaborate to schedule multiple events. Note the use of the 'select...case' in the example code.

These slides go into some more examples: http://talks.golang.org/2013/advconc.slide

You end up with a really nice "actor model", where you have a goro which owns some state responding to incoming messages over channels and sending replies.

Slide 24 gives the general structure, but it's a good read.

I wasn't quite getting that code when I first read it.

Now I can see it allows you do "discard" all the pending reads from the input channel (and avoid writing to a possibly-closed 'out' channel), but wouldn't it be better to break the loop in this case for an immediate exit?

i.e. go for 'interrupt' semantics, rather than 'drain'?

You can buy a DVD set which has the original versions (no CGI, Han shoots first etc) on the bonus disks.

http://starwars.wikia.com/wiki/Original_unaltered_trilogy_%2...

IIUC, only the 2008 release set has them. But you can still buy those. Just check the reviews etc carefully to be sure it's the correct release.

I'm not arguing the point that generics are unuseful.

But imho the method should not be named for the compiler-type of it's return value (unless it's a type converter like int2string or similar).

It should be named for the bizlogic/semantic type:

So..not "getURIs()", but better "getBackendPoolMembers()" or "getBackendPoolMemberURIs()" if you have more than one way of representing them.

Long method names are fine. Everyone uses autocomplete. Choose good names and rename them often as the meaning of the code changes over time.

Design is different to the nitty gritty but I'd say not necessarily easier or harder. Just as no battle plan survives engagement, no design survives the realities of implementation.

This is what makes waterfall hard and agile.attractive. it is also what makes someone who can shift mental focus from one to the other more useful.

Personally I think of it in terms of field of view. Zooming out to bigger and bigger picture or down to finer and finer detail.

I guess what I'm saying boils down to "increase your range" - if you're a coder you'll be more useful/valuable the more you can look out. (Whether that be in terms of business sense or devops practicalities).

Move up the value chain.

If you can turn a design into code, learn to turn a spec into a design.

If you can turn a spec into a design, learn how to understand a problem and produce a spec to solve it.

If you can understand a problem, learn to talk to people and discover the problems they have so you can solve them for them.

If you can do that, learn a million other things and run your own business.

[You can also skip any of these steps if you're happy managing people to fill in the downstream aspects rather than doing it yourself.]

PRNGs (pseudo-random-number-generators) take in a small amount of randonmness (a seed) and produce a long stream of numbers from that.

Anyone using the same PRNG can look at the output of yours and try to put their PRNG in the same state. If they succeed, the output of theirs will match yours - now and in the future - unless you re-seed.

Two problems can occur here:

1) you seed with something they can predict. e.g. seconds since 1970 (or microseconds since 1970). If they have a reasonable sample of numbers from your system, they can try lots of different seeds and see if they can find the one which gives the same output as you.

2) PRNGs have "internal state", which is a bunch of numbers they mix together. Some PRNGs have the property that if you can you can observe enough numbers in a row from the PRNG, you can turn them back into the internal state locally and then you can do the same thing as if you knew the seed (predict future numbers).

> The problem with Perl, IMO, is that there are too many clever ideas

Perl's learning curve is shallow (easy to pick up) but long (the language is big).

One explicit design goal from perl which isn't talked about much is "huffman coding" in the language. i.e. frequently needed language features should require fewer keystrokes.

This comes directly from Larry's background as a linguist. For example, English has the word "it" to mean "the thing we're talking about". Perl has "$_" to mean the same thing.

The meaning of "it" is dependent on the surrounding context. So it is with perl.

Similarly, it can be confusing to have long, runaway sentences using such context dependent words. You can write bad English and bad perl in this way if you're not careful.

However, the benefit is that, used correctly, it allows you to express yourself clearly and concisely.

I like to use a syntax error if I'm implemented in the middle of a number of related changes. As long as I follow basic hygiene of running/compiling the code before committing, I'll be reminded of where I was.

I typically use '...' for this, since it is/was invalid syntax in pretty much all languages.

Then perl went and added it as a placeholder...

http://search.cpan.org/~jesse/perl-5.12.0/pod/perlop.pod#Yad...

so it now compiles (but will at least throw a not-implemented error).

Duodecimal counting still persists in some places in inches-per-foot and in the UK until 1971 in the "pounds, shillings and pence" old-money system. (12 pence to a shilling and 20 shillings to a pound).

It's interesting to me that both duodecimal and decimal counting are recommended as being easy to calculate with.

The benefits of decimal come from our using base-10 for other purposes. I guess the best of all possible worlds would be to use duodecimal for all units (including our normal number system).

Then we'd get the ease of use of modern base-10 units plus the better factorisation of duodecimal.

(But we'd still have an impedance mismatch with the binary powers. The KB/KiB split wouldn't go away).

I think the thing which is defeating my intuition here is the continuity issue.

"If a periodic function is continuous and nonconstant, then it has a least period, and all other periods are positive integer multiples of the least period."

I think my naive intuition is modelling "periodic function" as "continuous and periodic". Basically, I'm not exercising the the full freedom of the "it's periodic" concept.

There's a good Feynman anecdote on this (from Surely You're Joking...):

------

"I had a scheme, which I still use today when somebody is explaining something that I'm trying to understand: I keep making up examples.

For instance, the mathematicians would come in with a terrific theorem, and they're all excited. As they're telling me the conditions of the theorem, I construct something which fits all the conditions. You know, you have a set (one ball)-- disjoint (two balls). Then the balls turn colors, grow hairs, or whatever, in my head as they put more conditions on.

Finally they state the theorem, which is some dumb thing about the ball which isn't true for my hairy green ball thing, so I say "False!" [and] point out my counterexample."

------

So I think it's useful to consider the most extreme thing which meets your criteria, instead of a "representative" example.

To come back to tech I think a similar mindset is also useful for things like system failure mode analysis. "Yes, but what if that switch dies at the same time...?"

I continually find this particular point useful and enlightening. (Joel's whole corpus of stuff is worth a read. At the risk of causing a hacker news "joel storm" of submissions, check out the pricing/segmentation piece: http://www.joelonsoftware.com/articles/CamelsandRubberDuckie...)

For example, after discussing the subject of promises (in the sense of the tool to manage and abstract asynchronous program flow) with a colleague, it occurred to me that the reason we care about async behaviour is that a "function call" is a leaky abstraction, in that it takes a variable amount of time.

We think of a function call as "doing X, Y and Z". The fact that it takes time to do it, blocking our 'thread of execution' causes us the problem that we can solve with the overhead of async programming (or threading, or...)

(By 'function call' I'm glossing over system call, library call, embedded cpu-eating loop.)

From this perspective, you can see that an alternative to working around the leak is plugging (some of) the leaks - which is the approach golang takes, by shuffling around threads of execution to avoid them being stalled by blocking system calls.

That perspective is useful to me and helps me understand why I think I prefer the golang approach, "more robust abstraction".

Such escapements can be made a feature:

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

Apache has a nice system where all allocations come out of pools. http://apr.apache.org/docs/apr/2.0/group__apr__pools.html

You can then create a new pool to handle a single http request, then discard the whole pool with one free when the request has finished.

Perl seems to pass nearly all the tests (including uppercasing baffle):

  $ perl -E 'use utf8; binmode STDOUT, ":utf8"; say uc("baffle");'

BAFFLE

The only failure I can see is that it treats "no<combining diaresis>el" as 5 characters (so reports length as 5 and reversing places the accent on the wrong character). That's documented here: http://perldoc.perl.org/perluniintro.html#Handling-Unicode "Note that Perl considers grapheme clusters to be separate characters"

All else seems to work though (including precomposed/decomoposed string equiality etc). The docco also says that perl's regex engine with Do The Right Thing with matching the entire grapheme cluster as a single char.

My guess/intuition was that walking backwards might defeat any memory pre-caching at various layers (CPU, OS).

I wrote this quick-and-dirty code [http://codepad.org/d9ilykxA] to try and test the effect.

To me, it's a little interesting how it various with optimisation level, but I've not picked apart the assembly to see what's going on.

Under gcc 4.8.1, 64bit ubuntu):

  -O0 forwards 4.37s, backwards 4.88s (fowards faster)
  -O1 forwards 2.67s, backwards 2.66s (same/backwards faster)
  -O2 forwards 2.67s, backwards 2.66s (same/backwards faster)
  -Os forwards 3.33s, backwards 3.00s (backwards faster)

and the same under clang:

  -O0 forwards 3.35s, backwards 4.11s
  -O1 forwards 2.67s, backwards 2.67s
  -O2 forwards 0.69s, backwards 0.77s
  -Os forwards 2.67s, backwards 3.00s

So...it's not as simple as "forwards or backwards always faster", unless the test code is simple enough to be defeated by the optimiser in some cases which real code wouldn't.

Also - what is going on with clang -O2?

It's interesting that the population seems to be very critical of any food-health articles, presumably from over-saturation of poor science reporting. (Best example of this I know of - http://kill-or-cure.herokuapp.com/ - a study of things the UK's "Daily Mail" "newspaper" has claimed cause or cure cancer, many are in both categories).

But it is also clear that what and how we eat has a significant effect on our health, which is interesting and relevant to us.

How to sort the wheat from the chaff?

A "truth database" or factchecking site might be pretty useful. Or would it just boil down to "eat your vegetables and do a bit of exercise"?

Dumb question: What breaks with the following approach?

1) set last_write_wins=true (so all updates, always apply, as described in the article)

2) avoid the "partition/rejoin may cause old values to stomp on new" issue by having "rejoin detection" which refuses to rejoin if clocks are "too out of sync"

I think it's unfair to lump the faster-than-light-neutrino experiment in as bad science. They pretty much said "this is really odd, please suggest your explanations".

I see it as they had removed the "continued mutual goodwill" from the equation, and were offering nothing additionally. (If my current employer asks me to sign something without any additional incentive, I'm not going to say no without inspecting it, since our continued mutual goodwill is important to me.)

That kinds of puts them into the same category as someone who comes up to you on the street and asks you to sign something. You don't owe them anything - there's no goodwill - there's no upside. They get "basic politeness" but not co-operation.

Sure, it might not cost you anything to sign, but you'd at least need to spend the effort (or money for a lawyer) to ensure that.

It looks like the underlying feature which enables reverse debugging, Process Recording, could do what you describe:

https://sourceware.org/gdb/wiki/ProcessRecord

the data may only be in-process, if so it would need to be save-able and load-able.

Could do, but why tie to time? What you actually trying to minimise is time spent queueing. So record when people arrive and apply a discount/surcharge depending on how long they queued (or just based on the number of people ahead of them in the queue).

Seemingly perversely, a long wait would imply a higher cost for the meal.

It's basically congestion charging based on queue length/time rather than time of day.

I'm not sure what the definition of a tax haven is, but here's a page from the jersey govt. I don't study this, but it seems like it is a light/very light tax regime?

http://www.gov.je/LifeEvents/MovingToJersey/HighValueResiden...

"companies are generally taxed at 0% and there is a special 10% rate applying to certain regulated financial businesses."

"There are no 'wealth' taxes such as capital gains tax or inheritance tax."

"the first £625,000 of world wide income (including Jersey based) will be taxed at 20% thereby accruing the £125,000 per annum minimum tax contribution all personal income over £625,000 will be taxed at 1%"