majika

My reasons are made clear in the README. I don't want to contribute to nonfree software. It's pretty simple.

Businesses who want to use my work in nonfree software are welcome to get in touch to negotiate such a license.

IMHO, for anyone who has seriously considered the morality and ethics of software licensing options, the AGPL is the obvious choice. I'm surprised it isn't more popular. It was a shame large donors strongarmed the FSF into splitting it from the GPL, and that the FSF kept pushing the GPL as it's go-to license.

I would suggest working on how to improve your Python tooling; Vim with Jedi, or PyCharm are both great options.

I think Python's module semantics are harder to use and understand, but when you know how to wield them (or reading the code of someone who does) they serve you far better than other systems. Python's module semantics are closer to Java's (explicit packages) rather than Ruby or JavaScript (global namespace), but unlike Java, Python's modules are derived from the file structure and not `package` statements.

The consequence of this is that most Python developers throw everything that should be in the same module into the same file, because that's "easiest". It stops being easy when the file grows large.

What you can do to address the problem of large modules in a single file is to turn the module into a directory of the same name, create an `__init__.py`, then put separate files in that directory to hold sections of the module (e.g. a file for each class if that's appropriate), and then in the `__init__.py` import the classes and whatever else you want to export from the module. Done - and client code needn't change.

Python's module system (and namespace system in general) is one of the largest reasons I prefer it over other dynamic languages. Knowing where every identifier came from in a file makes it so much easier to learn a codebase.

To me, this sounds like a failure of your tooling rather than the code you're reading. Vim with Jedi, PyCharm and PyDev can all jump straight to definitions. What's your development environment?

I'll use `from <module> import <identifiers>` when the identifiers' names express their purpose, and aren't dependent on the module's name. Importing identifiers directly makes the code using them less noisy [0], and makes it possible to replace the source module for the identifiers later on. In Django projects, I'll often need to rename modules or move identifiers between modules, and so using `from` imports makes that a lot easier.

I agree that `as` imports should be used sparingly.

[0]: your suggested solution is even more noisy than using the qualified name, because now you have a variable hanging around and readers have to work out if `now` is going to be reassigned or used later.

If we accept:

- that there's only one class of "humanic" intelligence;

- that we can approximately represent instances in this class of intelligence as vectors of {memory, learning speed, computation speed, communication speed};

- that any AI that could be created is merely a vector in this n-dimensional intelligence space, lacking any extra-intelligent qualities;

- that productivity and achievement increases exponentially the more intelligent being you devote to a problem, but logarithmically for more beings you devote (e.g. a being with intelligence vector {10,10,10,10} might be as productive as 10000 {1,1,1,1} beings);

then this doesn't exclude the possibility of us creating an AI with an intelligence vector twice an average human's intelligence vector, which can suggest improvements to its algorithms and datacenter and chip designs to become 10x as intelligent as a human, and from there it could quickly determine new algorithms, and eventually it's considering philosophy (and what to do about these humans).

The point is: viewing intelligence the way you suggest doesn't help us on what to do about "super" artificial intelligence.

What the web is increasingly unable to do today: provide text content without requiring a code execution environment. This site is another example of that.

All non-application websites should provide all their content in semantic HTML at appropriate HTTP endpoints, with CSS styling (in as few requests as possible) as required per the design, and JavaScript (in as few requests as possible) that takes the semantic HTML and makes it interactive (potentially adding and removing elements from the DOM) as required per the design. The CSS should not depend on mutations resulting from the JavaScript, nor should the JavaScript assume anything of the applied styles (as the user agent should be able to easily apply custom user-styles for your site; e.g. Gmail only providing a limited set of styles that are managed server-side is laughable).

Thus, all content is readable and styled properly without requiring an arbitrary code execution environment. That is what the web was meant to be. Unfortunately, most "web developers" have made the web worse over the past 10 years because simple, functional, minimal technology is not impressive, and hipsters love to show off.

Nor does it help that there are few capitalist incentives for the web being open and malleable -- e.g. so users can easily use a different front-end for Facebook, or users can easily choose to avoid analytics or advertisements, or users might prefer to use the website rather than the app (providing access to personal details, contacts, location, tracking, etc).

The state of the web is emergent and I'm not sure what anyone could do about it (perhaps make a better browser?), but it really irks me when web developers pretend like they're actually doing something good or useful, or that the web is actually in a healthy state. In my experience, it's the people who don't talk about web development who are the best web developers; these are the people who don't wince when they write a HTML document without a single `<script>`.

I didn't find this video helpful at all. You have to skip 10 minutes ahead to get to the actual talk. The talk is stunted and, as always with Rust documentation, dwells only on the basics. Audio isn't clear, but neither is the speaking.

I don't know of a succinct overview of Rust for experienced system programmers, and this video certainly isn't that.

I used Thunderbird and Enigmail for a year or so. I later moved to Evolution for the better GPG experience (no flickering on opening the message as there is with Enigmail) and better GNOME integration. I used Evolution for another year, but its rough edges wore me down; I had to get in the habit of closing it if I wasn't using it, because it would noticeably slow my system down. It would take at least 5 seconds to open. Parts of the UI would often lock up and need a reset by switching between the panes.

I've been using Claws Mail for the past few months. It's simple, fast and stable, and GPG support is fine. That's all I need. It sucks for reading and writing HTML emails, but I'm okay with that. Parts of the UI are still rough (e.g. the main window isn't responsive while the "sending" dialog is open), but it's less worse than Evolution.

For some reason, the author disallows people from viewing pages on his site without running scripts from his domain and from jquery.com.

You can get around this by opening up your web inspector, and disabling the `hidden: true` rule on the top `container` element.

Nothing on the page (or in related linked pages on his site) seems to require JavaScript.

Aside your abstract commentary here is a defense of your argument that the web will lose something valuable if more sites stop directing their visitors' browsers to send requests to advertizing companies and CDNs for resources. I think that's baloney - the web will be better off for it, because it will be faster, more private, and simpler.

No semantic information is lost (except for the semantic information in Google's profile graph - let me play my violin). There's no balkanization, because there's no noticeable difference to end-users (which is why cross-site requests for things like fonts is so nefarious).

The web would provide all the value it currently does, because that value is founded entirely on linking.

You seem to maintain that wanting to achieve private browsing is "paranoid". Can you expand on this belief?

My first sentence does not imply that he's speaking for Google, or other Google employees. cromwellian is an employee of Google, and I would regard his opinion here as being contemptuous of privacy.

Edit: okay, I see the implication now of me referring to all Google employees in that sentence. I had intended for the plural to refer to "more than one", which I think is a safe bet - but it could also be construed as referring to "all" employees. I've qualified the sentence with "some".