p0llard's comments

Using cryptographic primitives to implement a non-productive asset is one thing; using cryptographic primitives as some kind of ledger goes back to the 70s, heck even Git uses Merkle trees.

What are you getting at?

There's a pretty big difference between corporate treasury software and cryptocurrency scams? Unless you're trying to argue that anything related to finance is a scam?

I don't see what point you're trying to make, it seems such an irrelevant comment that it makes me question your motive and wonder if you're trying to smear Stephen.

> The former, as a general rule, does not create a derivative work. It's specifically called out in the GPL FAQ as something that does not create a derivative work.

Could you point me in the direction of a court ruling establishing this general rule? I couldn't find anything after a quick search.

You didn't mention this part of the GPL FAQ (directly after the part you talked about):

> But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program.

Determining what constitutes "intimiate enough" sounds pretty difficult and open to interpretation: what's a "complex internal data structure"? If PostGIS is serialising its (presumably complex) representations of data and sending them over a socket to your program (and vice versa), then does that count?

I think it's also worth noting that "derivative work" is an established legal term; if it comes to a lawsuit, it's probably more likely that the judge will fall back on established precedent on what constitutes a derivative work and enforce the literal terms of the license as opposed to looking at FAQs written by someone who is not a party to the contract.

> PostGIS via TCP

From a legal perspective I'm unaware of any ruling which establishes a difference between components communicating via TCP and components communicating through function calls at the ABI level (e.g. linked libraries); the latter is apparently enough to constitute a derivative work (see the LGPL/Linking Exception). There are obvious technical differences, but it's not clear that they should be treated any differently from a legal perspective.

> For example, if I build an extension which works with Chrome and Firefox, over a well-defined API, that's an independent work. AGPL/GPL/LGPL does not apply.

> If I have two pieces of code which mutually rely on each other and form a common system, and for example call back-and-forth, or have APIs specific to each other, that generally does form a derivative work.

So why does the LGPL/Linking Exception exist at all? Software which links against libc doesn't have a mutual dependency; libc is quite happy to run crt0 as long as there's a main symbol somewhere, and yet apparently linking against libc would be enough to constitute a derivative work were it not for the exceptions in the LGPL.

> Google states that if, for example, Google Maps used PostGIS as its data store, and PostGIS used the AGPL, Google would be required to release the Google Maps code. This is not true. They would be required to release their PostGIS patches in this situation. AGPL does not extend the GPL in that it makes the Internet count as a form of linking which creates a derivative work, as Google implies, but rather that it makes anyone who uses the the software via the Internet entitled to its source code.

I don't really follow this.

The fact that the linking exception and the LGPL exist at all is enough to infer that the FSF/license authors consider linking against or otherwise using a piece of software as a component of a larger system is enough to make that larger system a derivative work of the smaller component, thus "tainting" (I use this work non-disparagingly) it with the copyleft provisions of the license.

If Google Maps (that is the suite of software running on Google's servers) uses PostGIS as its data store then it seems that without a judicial ruling on whether there's a legal difference between interfacing with a software component by linking against it and interfacing with a software component by using some other software interface, it's not possible to be so certain that there isn't an issue here.

> in the same way that a C program linked against glibc is not a derivative work of glibc

I believe this is only as a result of the linking exception; I don't know if this has ever been tested, but my understanding was that linking (either statically or dynamically) against a library was generally considered enough to be a derivative work.

> These OEM EEPROMs are exposed to the external world, just like normal registers.

> many hardware provides an explicit lock/unlock feature for protecting low-level configurations and registers

Is this really enough? It seems that devices which will eventually be connected to another system outside the purview of the manufacturer should have such registers isolated to as great an extent as possible; if these are only ever touched once during manufacture, they should only be accessible via e.g. JTAG; if the manufacturer sometimes pushes out updates which touch them, they should be on a different PCI(e) BAR which is only mapped into memory for the purpose of an update.

In this case it looks like the driver developers do share some of the blame, but it seems that such systems should be resilient enough to accept a lot more interference (I'm reminded of the FCC regulation, although it doesn't quite fit here since we don't want "undesired behaviour") on interfaces over which they have little to no control; what happens when a bit-flip results in the wrong MMIO address being written to?

> Just let it happen and see what the attractor becomes for this large, dynamical system.

I think the problem with this stance is that "this large, dynamical system" actually determines whether people have food to eat. Playing experiments with the labour market is extremely unethical in my opinion.

> After all, Snowden sheltered in the ecudorian embassy for about a decade.

I think you mean Assange?

But yes, I don't think anyone should be especially surprised by this; although if this were a country with strong diplomatic ties to the US and an extradition treaty then admittedly it would be a different matter.

In general ~/.config is only for config; data should be in ~/.local/share, but a lot of programs get this wrong and abuse ~/.config using it for everything.

Even worse are the programs which use it to cache runtime data; I should be able to add the entire ~/.config to a dotfiles repo without accidentally including personal data (other than that which might reasonably appear in a config file) or ephemeral data.

I haven't run this, so perhaps the behaviour is different to what I'm expecting, but since it uses `XDG_DATA_HOME` (`data_dir` in the `directories` crate) I'd expect it to appear as

    /home/alice/.local/share/dijo/habit_record.json

on XDG compliant Linux.

> Once you start doing quick things with lists like the zip function, or list comprehensions, it's hard to go back.

Totally agree with you on this one, but I'm not sure I'd go so far as to say that they're a defining feature of Python, more of functional languages, from which Python has borrowed a thing or two.

One example I'm aware of is Lawvere's fixed point theorem, of which Gödel's (first) incompleteness theorem, the undecidability of the Halting problem, and Cantor's theorem are all special cases.

Not really related to "group theory, linear algebra, real analysis, etc.", but interesting nevertheless.

It's quite a wide generalisation which really just captures the nature of diagonalisaion arguments, but it does formally tie together various proofs/theorems which "smell the same".

> so for anyone approaching it with an undergrad or lesser background in math, learning it feels a bit like starting with a clean slate

Did you mean without? Algebraic topology would be a pretty standard 4th year undergrad course in the UK.

> "mean" doesn't quite cut it, if you want to be a stickler about it.

I'm going to assume, then, that you didn't read my original comment which started off this line of discussion? By that standard, you just failed the interview. ;)

> It is a bit tongue in cheek.

As was my reply ;)

> "the function f(x) = 15 is an average, but since it's a constant function it will almost always be a terrible one"

It has minimum variance, how can it be a terrible estimator?.. ;)

> So far as I can tell, the common word for statistical mean is "average" in English

You're quite probably right about common parlance..

> but it's not the correct technical language.

..but as you point out it's not really appropriate in a technical context, indeed I don't think I've come across the term "average" being used in this way in technical literature; I've normally either seen expectation (for probability theoretic cases) or mean (for statistical cases).

> So nobody should be hard on themselves for not knowing the difference.

Absolutely, which is why I think being hard on someone for not knowing the difference between "the average" and the median is similarly an issue.

> Couldn't tell an average from a median

Without meaning to attack you personally (especially in the context of the rest of your comment), a comment like this annoys me a bit.

I presume by "average" you mean arithmetic mean, but the median is also an average, and depending on the context the median might be a far more useful statistic than the mean. Confusing the mean and the median is one thing, and perhaps you actually used this terminology in the interview; "confusing" "the average" and the median isn't really worthy of comment, and sounds more like a breakdown in communication between interviewer and candidate rather than a lack of technical knowledge. It just seems vaguely hypocritical to me to be expecting a certain level of ability from the candidate and then using imprecise/informal terminology.