matthiasl

Erlang's ordsets() module has O(N) insertion. Since there's theoretical disagreement, here's experimental verification:

  11> f(), Ord_bench = fun(N) -> Random = [random:uniform(N) || _ <- lists:seq(1,N)], F = fun(Item, Set) -> ordsets:add_element(Item, Set) end, lists:foldl(F, ordsets:new(), Random) end.

#Fun<erl_eval.6.99386804> 12> timer:tc(fun() -> Ord_bench(10000) end). {337691, [1,2,3,4,5,7,8,10,12,13,14,15,16,17,18,19,21,23,24,26,27,28, 29,36,39,40,42|...]} 13> timer:tc(fun() -> Ord_bench(100000) end). {37167977, [1,2,3,5,7,9,10,11,12,15,16,17,18,19,20,21,23,24,25,26,27, 29,30,33,34,35,38|...]}

So, 337 ms turns into 37 seconds, roughly 100 times slower, when I increase the data size tenfold, which is what you'd expect from O(N) insertion.

Repeating for gb_sets, the results are 49 ms versus 484 ms.

Could the misunderstanding be that you don't realise that the ordsets module specifically guarantees that the representation is an ordinary sorted list?

(I am aware of e.g. skip lists. But that is not the same Erlang data structure as a sorted list.)

Your Erlang syntax is a bit off. You mean

f(<<Length:32, Packet:Length/binary, Rest/binary>>) ->

I wonder how well you could track cash if you wanted to.

ATMs could OCR and log the serial numbers of bills they dispense, and they obviously know who they're dispensing to. Banks could do the same with incoming cash at the end of the business day.

The tracking would be weaker than with electronic payments since some notes will be re-used after being given as change, but it'd still be useful to a government that wants to track its population.

> they want to nationalize all private banking

That would be crazy. But I can't see where the article says that, nor can I see it said in the opinion piece by the chairman of the Swedish reserve bank which the article links.

The chairman of the Swedish reserve bank makes two suggestions:

1. Modify the RIX system of settlements in the reserve bank. One suggested modification is to extend its operating hours, currently it closes at 17:00 each day. I don't think anyone would consider that a radical proposal.

2. Force banks to handle cash, i.e. if you want to be a bank, then you have to let people withdraw and deposit cash at your branches.

This second point sounds almost bizarre, a bit like demanding that you can't be a restaurant if you don't serve food. But the current situation is that the major banks in Sweden have rapidly reduced the number of branches that handle cash. Swedbank, one of the big four, has roughly 100 branches in Stockholm, the capital, but only two of them handle cash.

You can deposit small amounts of cash in ATMs, about $1000. Anything beyond that and you have to make a trip to one of the two branches that still handles cash.

It's changed, but not correct.

Currently, all the units in the 'fact box' are KWh. That is "Kelvin Watt hours", which makes no sense. You want kWh, i.e. lower case 'k', upper case 'W', lower case 'h'.

Wikipedia has a reasonable article explaining that 'K' is Kelvin and 'k' is the prefix for 10^3: https://en.wikipedia.org/wiki/International_System_of_Units

Same problem in the footnotes, though MWh is correct, so that's good.

Would be nice to fix the units in the article.

In the 'fact sheet' box, the only correctly abbreviated unit is the 'km'. Every 'KWh' should be 'kWh', i.e. kilo and not Kelvin. Similarly, footnote 1 uses both kwh and KWh, neither of which are right. The numbers in the box are interesting, especially since I can't find them on the train's official site (where did they come from?).

The last row in the 'fact sheet' box says "Power of solar plant at station: 30Kwh". Should that be 30 kW? Or is there a battery at the station as well, in which case the text should probably be different. The train's own website (second link in the blog post) doesn't mention a battery at the station and refers to the connection to the grid as "just like a bank", which makes me think that the train is solar powered in a 'bookkeeping' sense.

Another nit is that San Francisco has "solar insolation" and not "insulation".

I do exactly this too for the occasional mail that I really can't read as plain text.

One concern is that I'm letting through all web bugs and, perhaps, outright malicious HTML. If anyone has a solution for that, something like filtering the HTML, I'd love to hear it.

"TCP does have a CRC-32 checksum"

Where?

TCP has a checksum in the header, but it is neither 32 bits nor is it a CRC.

It seems important to mention that the study looks at the behaviour of a few hundred people in Italy and Sweden playing a _game_ which simulates earning money, paying tax and possibly being audited. I.e. the study is not actually about the compliance rate of real taxation.

tptacek's description of the paper he cites, i.e. "Here's a study comparing Sweden's compliance rate with that of Italy's, and finding them roughly similar" leaves out the crucial point that the whole paper is about a game, not real taxes.

Your scheme successfully avoids revealing the password to a rogue server, so it solves the immediate problem.

But your scheme has made the password hash be the password, which is unacceptable because it's equivalent to storing the plaintext password on the server.

Illustration. Here's /etc/shadow

    cyphar:salt:hash

With your scheme, an attacker is allowed to log in by providing

    f(nonce + hash)

so that's a red flag: the attacker doesn't need to know the password, just the hash. Looking at it another way, you've made the hash be the password.

(FWIW, I initially thought your scheme worked, but couldn't believe a solution had been overlooked and so I tried it with a concrete example and only then realised where the problem lay. )

Try designing a specific means to do this and you'll find that it's not easy.

E.g. your first idea might be "ok, so the client just sends a SHA-256 hash of the password, simple." But... if you do that, then the SHA-256 hash _is_ the password. A rogue server can capture that SHA-256 hash to log in elsewhere.

So you might try and improve that scheme by having the server supply something to hash together with the password. But that means you can't use /etc/passwd anymore, since that doesn't store the password, it just stores a hash with one particular salt.

How is sugar regulated differently to MSG in Australia?

(Looking at Food Standards Australia, the requirements on MSG are that it's declared as an ingredient with an exception if it's naturally present in the food. How is that different to what's required for sugar? http://www.foodstandards.gov.au/consumer/additives/msg/Pages...)

Pause frames came with 802.3x, in 1997. That's much later than any of the protocols you name, by a decade or two.

"I wonder if he knew they were going to print a photo of him."

The fourth paragraph of the article starts with "He was however happy for the Guardian to publish a photograph of him".

I can't see the problem either.

I don't think it's a capitalisation problem; when using 'Watt' as a name, e.g. James Watt, you need to capitalise. But the unit is 'watt', with a lower-case 'w'. The symbol is an uppercase W. Reference: Table 3, in "NIST Special Publication 330: The international System of Units (SI)", Taylor et al (2008).

Nor do I think there's a problem with confusing energy and power, as there currently is in the original title.

So, what's the problem? Jaquesm's "And you still got it wrong" comment is unhelpful because it doesn't identify a specific problem. Maybe he feels that the sound doesn't actually come from the cable. Or maybe the cable isn't carrying 50 kW. I don't know. Maybe there is an obvious problem I'm missing.

An effect, from the same charts, which partially mitigates what you're highlighting is that Norway has a totally different balance of exports versus imports:

    Canada: Imports $437 B Exports $438 B
    Norway: Imports $92  B Exports $147 B

A longer summary: the maximum height of a siphon pumping water, at sea level, predicted by barometric pressure is about 10m.

But the tensile strength of water is nonzero (a surprise to me) and that is enough to allow much higher siphons if you first remove dissolved gases from the water.

The paper speculates that several hundred metres may be possible, perhaps even more. The paper also describes an actual experiment where they showed that a 15 metre high siphon works in practice.

From an engineering point of view, I don't know if it is better or not, but the article implies that construction costs scale much better if you leave the rock there.

If you wanted to make an unadorned column of water underground, you'd have to remove all the rock where the column is. Without knowing anything about that sort of construction, I'd guess the cost is proportional to the volume of the cylinder.

The proposed design requires removing a ring of rock plus a disk at the bottom. The article claims that the construction cost is therefore proportional to the cylinder's area.

There are also other reasons which are plausible, but they're not as interesting. Rock is denser, so you get more energy storage per unit volume. (Because: potential energy is given by E = m g h, where m is the mass raised. Adding a rock on top means you get greater mass)

It's a good place to meet people.

It's interesting.

It's fun.

Is "DACs" a typo for "DSPs"? If you really do mean DACs, can you elaborate on what those DACs were doing and how that was replaced by FPGAs?

There are different trade-offs for the capture filter language and the display filter language.

The capture filter language considers short and bounded runtime (no loops) to be paramount. Roughly, when you're capturing, it's important that your filters eat a limited amount of resources. Juha talks about this in the article.

The display filter language abandons the careful runtime limits in favour of being more powerful. You can go higher up in the stack, you can use regexes, etc. That's acceptable because you're usually doing it offline.

The conclusion of Juha's article is, roughly, "the libpcap DSL is sometimes frustrating, but I'm not aware of a clearly better alternative". I agree. I'd love it if someone invented something prettier but still solid.

It's a bit more complicated than that.

Wireshark allows two different filtering languages in two different places, used at different times.

Your first example ("ip.addr=127.0.0.1") is a display filter. You enter those in the text field at the top of the GUI.

Your third example, 'host 127.0.0.1' is a 'capture filter'. You can enter capture filters in Capture/options.

The hardware I work with uses a supercap to keep the real-time clock going during power failures. Previously, button cells were used for that.

> Well actually Erlang is not single-threaded it is multi-scheduler and multi-process.

I think the parent and you are talking about separate things.

Erlang the language is single threaded. Erlang the language has no concept of threads. That's what I think the parent was referring to, since he writes "concurrency model".

The BEAM Erlang VM, on the other hand, uses multiple schedulers and multiple threads, pretty much as you describe. Most people regard that as a characteristic of the VM _implementation_, not the concurrency _model_.

    > I've never been able to construct a series of tokens in
    > which the meaning changes based on which of those you
    > use, and it's legal either way.

Here's a series of tokens where switching comma to full stop means different things and both are legal:

    1> 1,0.
    0
    2> 1.0.
    1.0

In the first line, the comma is an expression separator. Attempting to use a full stop instead results in a floating point number.

    f(X, Y) when X, Y -> ok.
    g(X, Y) when X; Y -> ok.

In this case, the guard in f is turned into a guard sequence by switching a comma to a semicolon. Both are legal.

Matt

I'm not Kolev, so I don't know his reasoning. But I can guess.

USSD is interactive. That lets you keep the one-time password's validity time short since you know when the subscriber sees the one-time password. The other is that it's straightforward to require an interactive step, e.g. "press 7 to get a code".

The interactive step makes an attack based on SMS forwarding harder. The short timeout makes an attack based on having limited access to a victim's phone harder.

Not sure if the security improvements are worth the useability problems---people aren't familiar with USSD and, because it's not used as often, mobile terminal software for it is likely to be buggier.

Are you citing Skype and SAP as _exceptions_ to your rule?

As far as I know, Skype was started by Europeans in Europe. And so was SAP. The SAP founders appear to be about as German as you can get.

A simple explanation is that the journalist is over-simplifying a source which said "...found a semiprime".

I know nothing about LUA syntax, so I also have no idea which part of this is new and which part is ordinary LUA.

Is -- calculate sum(x for x^2 in 1..n) a comment or is it the output of a code transform?

It seems that they have an internet in mind where you consider packets that left the country to be less secure than ones which stayed in the country.

One way to implement that would be something like RFC 3514, except that the E bit gets set whenever a packet crosses a border, and never cleared.