jbert

One way to do this is:

- have a way of working out which users can see which objects

- whenever an object changes, note that all observers need to see an update

- either push that notification to the user, or record it ready for the next time they poll

- when a user sees "object X has been updated", have them poll for it's latest state (which may be "deleted").

Possible optimisation: you can decorate some or all the "X has changed" messages with the details of the change, creating a journal

This assumes the server can act as a serialisation point for all updates and so provide a single coherent time-series.

It also requires that the server be able to fail updates which are the result of stale UI data. (e.g. someone tries to edit an object someone else has deleted).

Thanks for that. But afaics, libgcrypt seems to be on a similar level of abstraction as the openssl lib? i.e. implementations of ciphers etc. I then fall into the mistake of http://www.cs.berkeley.edu/~daw/teaching/cs261-f12/misc/if.h... I think? [linking to berkely.edu because the page seems to have gone from matasano.com?]

And I think GPGME is a lib which "under the hood" spawns a command-line gpg process? http://www.gnupg.org/faq/GnuPG-FAQ.html#cant-we-have-a-gpg-l...

At the moment it looks like my choice is between implementing a cryptosystem on top of crypto primitives (from openssl or libcrypt) or seeing if I can get away with shipping a lib which spawns child processes via gpgme.

> If I need to exchange encrypted messages in some store and forward style I'd likely use PGP.

Do you or others have any recommendations for cross-platform library code (at least OSX, Windows, Android, Linux, Windows 8) for this purpose?

I may have understood incorrectly, but I thought that using gpg from code required launching a sub-process (e.g. via gpgme). That makes me very nervous from a library point of view, perhaps I'm wrong to be nervous.

Is the answer still "use PGP/GPG" or is there somewhere else I could look to avoid home-made cryptosystem here?

Isn't this a major difference between core.async and go?

If you perform a blocking operation (Thread/sleep there, but could be, for example, a socket read?) will you run the risk of exhausting the thread pool?

The go runtime handles this by detecting how many threads are in blocking syscalls and spawning more as needed (which I guess could be undesirable).

If I've understood correctly, this is perhaps best summarised as "go makes your sync code run well in goroutines, with core.async you can block everything with sync syscalls in your go block"?

Or perhaps just "go will adjust the size of your thread pool dynamically, core.async requires it to be big enough"

Yes, good point. But it all depends on level of risk, type and amount of data etc.

You don't need any electronics for a film camera. Or any metal, for that matter. It's a risk to take such an item in, but maybe it's worth it for your use case.

And I guess if it's small amounts of text, there's always human memory (or writing on your skin?).

So you are (obviously I guess) trusting the people accessing the data to not abuse it, "helping" that trust with whatever technical countermeasures make it harder to move bulk data.

It's analagous to media DRM. Nothing "works" if the user has admin access on the viewing device. And the only way to ensure that is a "trusted computing" chain all the way from processor boot.

Which is possible, but you have to lock out any viewers who can't demonstrate a secure chain from boot to viewing app (so you can trust the viewing app is "yours" rather than the device owners).

And there's always the analog hole. Unless you can rely on a 'Eurion' (http://en.wikipedia.org/wiki/EURion_constellation)-like mark to stop recording, people can always capture data at the point of display-to-retina.

The only other approach is the after-the-fact blamethrower, where you tag each copy steganographically so that you know who was the original source of any leaked or circulated copies. That wouldn't stop a Snowden though.

> even if the project runs out of money after a few sprints, the most important requirements will have been met. The product owner still gets to prioritise a backlog (the product backlog) according to business and user requirements.

Interesting, but if the team are choosing items from the product backlog there seems no guarantee that the product owner will get the stuff that they consider important done?

If the team assemble their sprint backlog, they'll do their own prioritisation which may not sync with the product owner's.

I dislike the fact that the value in range over a slice is a copy, rather than an alias, to the slice value.

It seems to me to be strictly less useful than the alternative (aliasing).

And I also don't really buy the argument that "it is a normal assignment and so has to copy", since:

    i, v := range s

isn't a normal assignment. It has special rules to do with looping. Having the additional rule that v aliases to the entry seems to me to be a full win (too late to change now I guess).

> Implying we should 'fix' Eternal September is pretty close to implying we should keep important technology out of the hands of those the current users deem unworthy. That prevents both spam and the Arab Spring, both 4chan and Wikileaks.

Not necessarily. The holy grail is growth where culture is preserved, i.e. the rate of acquisition of new users is below the point where they overwhelm the culture.

New users acculturate over time and exposure, so you can roughly model it as "at any time, no more than x% of the users should be 'new'".

That's still exponential growth, so it needn't be elitest. In time, you'll still get to everyone who wants in.

Making it work tho, that's the rub :-)

perl allows both trailing commas and also optional list-quoting which breaks on whitespace (commas unneeded):

    my @stuff = (
      "foo",
      "bar",
      "baz",
    );

or:

    my @stuff = qw(
      foo
      bar
      baz
    );

or

  my @stuff = qw(foo bar baz);

TIMTOWDI indeed...

Another problem you might notice is a significantly reduced ability to pick out signal from noise. e.g. someone talking against music or engine noise.

I think this is due to the brain being able to 'boost' signals based on directional information, which you can no longer do with one ear.

Social impact => harder to follow conversations in pubs/bars etc.

One useful adaptation is to provide directional hearing by cupping your hand on your ear and pointing the cup in different directions. This also saves you having to turn your head as much.

It's surprisingly effective.

It's also fun for two-eared people. You can pick out distant sounds much more clearly if you cup your hands around your ears and track around. A bit like having an ear telescope.

It does if you use the One True Brace Style:

http://en.wikipedia.org/wiki/Indent_style#Variant:_1TBS

since your eyes would flag:

    if (null != foo); {
       bar();
    }

as badness.

[edit: correct } to {, ta]

Yes, it seems very close to actors but I guess that's not too surprising if you're trying to converge on "ways to do concurrency which don't suck" from different languages.

That's the main trick, but the other pattern there I really liked was the idea of pulling all mutable state into the function which was running as the goroutine (and manipulated by the for-select).

It's a lot like an object instance, responding to messages, changing internal state and emitting messages.

In fact, here is the same approach in SICP, where they start to model objects as messages passed to a closure with internal mutable state:

http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-21.html...

[scroll down a bit for exercise 3.11, the "cond dispatch" is analagous to the "for-select" case dispatch, except of course that golang select handles concurrency.]

It's the old "objects are a poor man's closures"/"closures are a poor man's object" duality.

Thinking about this and defining "value" as "what people want" (i.e. "wealth" in the essay), it seems to me that every freely-entered-into transaction must increase overall value. [Since the two exchanged items must be valued more by their final owners than their initial owners, otherwise the transaction would not occur.] This seems intuitively sensible to me and suggests that trade is a good thing :-)

However, this then leads to some, to me, unintuitive conclusions:

1 - "value" can disappear very rapidly. (I valued an ice cream more than £1, bought it (total value in the world goes up), then ate it (total value in the world goes down)). Also, simply becoming disillusioned with something destroys value (I value it less).

2 - the advertising and marketing industries create a lot of "value", by making people want more. (Yesterday I would only valued a new pair of shoes by brand X at £20. Today I saw an ad which made me covet them. I now value them at £100. If I find them for sale at £40 I will buy them and be very pleased.)

I've not studied economics, is this definition of fairly ephemeral and manipulatable "value" meaningful?

So the issue stopping NFC abuse is the policing of questioned payments?

[i.e. someone with a auth key can basically choose to charge people what they want (by using modified aerials), it's up the the people charged to complain sufficiently to get that auth key revoked]

I'd imagine that there might be a low bar of complaints to get a key revoked, but perhaps a higher bar to start legal proceedings?

Am I right in thinking that the only thing stopping NFC working at greater distances is signal strength?

If so, presumably someone could make a targetted aerial which would allow functioning over greater distance (like the 'pringle can wifi' approach). If I understand correctly, you will still increase the distance with only one end using a directional antennae.

If so, couldn't someone walk through a crowd and skim passers-by fairly easily?

I think it's less about "one true kernel" with too much control by an established crew and more about system integration and risk.

The vast majority of people don't run a Linus kernel. They run a distro kernel. Distros can (and do) ship multiple kernels with different sets of patches and options. They have a default, but they also have a default web server and C compiler.

The kernel is abused by all kinds of different workloads. Distros choosing to offer kernels with more "speculative" patches will have to support them. The kernel is a risk-averse environment. I think that's the reason, not fiat by Linus.

Also note, a good counterexample to your main point is the android kernel. Linus-kernel:Android-kernel is quite close to gcc:llvm.

Replacing big chunk of functionality takes a lot of resources, so it helps to be apple (LLVM) or google (android kernel).

Also, don't underestimate kernel modules either. If you want to, say, expose page table information that "linux doesn't let you", you can write a module to do so.

[edit - removed Con Kolivas related part of response. Don't want to drag up old flamewar.]

That's an interesting perspective.

Thinking in those terms, the benefits of the "privileged lib" are:

- has a lot of functionality (support for hardware X, Y etc, good implementations of important, difficult algorithms)

- interoperability and network effects, if you use this library you can conveniently interoperate with other applications using it.

You can also get around the "strictly more expensive calling convention" by writing your code to run as a loadable kernel module. Obviously that's inconvenient, but that's kind of the point of this - trading convenience for performance.

Does dropping packets matter if you're looking for hot keys?

As long as you manage to be fair in what you drop, surely all you really need is a representative sample (even 1-in-100 or whatever would do).

"the only reason it's not fixed is because it's not used very often."

What is your view on the word 'children'?

Standards bodies ossify over time.

In Europe in the 80s/early 90s, X.25 comms, full seven-layer OSI stack and X.400 email was the "real thing", standardised by OSI, mandated by government procurement and implemented by telcos. This was "commercial grade" networking and email, with TCP/IP and SMTP being derided as "academic".

The IETF were the scrappy, pragmatic upstart. "We believe in rough consensus and working code".

I've not followed many later IETF standardisations, but I did take a passing interest in CAP (calendar access protocol) a few years back. (since there wasn't a good open source calendaring stack (not sure there is now, either, tbh).

It seems to me as a distant observer/potential implementor, CAP would be very hard to get started on. It mandated the use of otherwise unused-at-the-time BEEP [http://tools.ietf.org/html/rfc3080] (for good reasons - the same good reasons OSI mandated their full 7 layer stack...), embedded (unspecified parts or SQL92 (without a grammar!)) and seems to me a daunting prospect. It looked to me as though they were really saying "everyone doing CAP has to really have an SQL backing store with a particular schema and you pretty much have to pass these queries through to it".

So I see OSI->IETF->W3C as a progression over time. Not sure where to now...

[I'm sorry if I'm harsh to the people who put a lot of effort into CAP. I didn't contribute and so I don't really have the right to criticise, but from a potential implementors pt of view, it seemed daunting. I'm also not tracking any current IETF work, so I know I have a narrow view and am likely wrong in many ways.

update: ...and I've just skimmed the final RFC and they do have a grammar for the SQL subset. I recall that that wasn't present in the drafts available at the time.]

Not in the sense of "wrong", but in terms of difficulty of comprehension, for me it's call/cc in scheme:

http://en.wikipedia.org/wiki/Call-with-current-continuation

The main thing which helped me get some kind of grip on it was having worked through longjmp/setjump in C some time ago.

Agree with that, but would also like to throw in a scenario where there wasn't a sterile environment, but conditions were harsh enough for all present life to die, leaving you with a 'sterile' thin soup containing the building blocks of DNA based life.

That might shave a bunch of time off of the time needed.

Thanks for posting "negative" results. I think it's good science.

Is possible/likely that that is (partially-) chicken manure?

If so, reducing/eradicating endemic chicken salmonella might also remove it from the manure.

As I understand it, the runtime has to clone a new thread for each sync call into the OS.

That is the (only) mechanism by which a goro can perform such a sync operation without risking blocking the process.

It's entirely possible under some workloads that those blocking OS calls require other goros to make progress (think pipes), so this could result in deadlock (although for some workloads it wouldn't I guess).

I played around with a go server to do some simple scaling numbers - looking at possibly using go to implement a large-number-of-idle-connections notification server.

I found the (good) result that I could spawn a new goroutine for each incoming connection with minimal (~4k) overhead. This is pretty much what you'd expect since a goro just needs a page for it's stack if it's doing no real work. I had something like 4 VMs each making ~30k conns (from one process) to the central go server with something like 120k conns.

I found one worrying oddity however. Resource usage would spike up on the server when I shut down my client connections (e.g. ctrl-C of a client proc with ~30k conns).

Reasoning about things a bit, I think this is due to the go runtime allocating an OS thread for each goro as it goes through the socket close() blocking call. I think it has to do this to maintain concurrency. So I end up with hundreds of OS threads (each only lives long enough to close(), but I'm doing a lot at the same time).

Can anyone comment:

- is this guess as to the problem likely to be correct?

- is this "thundering herd" a problem in practice?

- are there ways to avoid this? (Other than not using a goro-per-connection, which I think it the only idiomatic way to do it?)

My situation was artificial, but I could well imagine a case that losing, say a reverse proxy, could cause a large number of connections to suddenly want to close() and it would be a shame if that overwhelmed the server.

The UK "Grey Book" email system (http://en.wikipedia.org/wiki/Coloured_Book_protocols) used email addresses the other way around (in the same timeframe that the UK was using a stack over X.25 as their internetworking protocol).

For example, a user at Imperial College (IC) would have been: user@uk.ac.ic, rather than user@ic.ac.uk as they might today.

Email gateways existed to convert between the different systems, but when all country codes were added to the internet, some addresses were simply ambiguous. (An address ending in .cs might be either czechoslavakia or a computer science department.)

The main email software responsible for this slicing and dicing was known as PP, which helps explain the excellent quote on ASR (alt.sysadmin.recovery) a few years later:

http://home.xnet.com/~raven/Sysadmin/ASR.Quotes.html [search page for "mail transfer agents"]

ssh with no cipher still requires authentication, and can stil use pubkey auth.

So "ssh with no cipher" means "people can snoop, but I can use proper auth". But rsh means "plaintext pw - or worse things if allowed".