lapinot

I completely agree it's a real thing. But couldn't we say the same thing about homo sapiens? Isn't the amount of domestic cats basically tied to the number of humans across history?

"The ecological dangers are so critical that the International Union for Conservation of Nature (IUCN) lists humans as one of the world’s worst non-native invasive species."

Pretty believable! My take is it's always better to put one's house in order before trying to influence the behavior of others.

I completely agree that in terms of nefariousness of industrial facilities, wind turbines are quite ok (in comparison with other energy infrastructure). But since you're talking about what they replace, i can't help but mention that they almost never replace anything, they're meant to absorb growing demand. That's the single biggest argument for global critics like degrowth: we always talk about switching to better X, but most of the time we also keep the old ones running. We typically picture coal usage as having peaked in the 19c with these images of london in smoke, but in fact it has never been as high as say last year (i didn't look at the numbers, but its basically a steady upwards trend for every primary resource since 200y). Rule of thumb your energy consumption is proportional to your GDP (it's actually pretty accurate).

So that's why, sure, wind or renewable (or even nuclear to some lesser extent) is better than fossil in some ways, but this in itself, in our current system, won't translate to much unless our prime effort goes to first maintain consumption at a steady level and then actually reduce it.

But i'm getting a bit off-topic! :)

It's definitely a genuine concern, at least for some people (let's say degrowth ecologists). (not to say oil companies aren't using these in bad faith too)

Usually this argument exist in the framework of explaining how large wind turbines are actually industrial facilities with associated risks (among which killing birds, waste, need for concrete/infrastructure in agricultural land, ..) and not somehow "free" "green" or "renewable" energy. Modern "wind farms" have basically nothing to do with windmills or small-scale wind power like wind-powered water wells (which typically are used as direct power for mechanical or heat energy): they need global supply-chains and big companies.

I'm not convinced by this part too, but it doesn't invalidate the actual argument that these are partly disjoint.

> Note that you can today depend on git repos [..]

Yes! That's what i'm doing and my whole argumentation is that this should be the encouraged default. Because cargo is already well designed and crates.io (or any custom cargo registry) only brings marginal value to it. Let people organize their infrastructure as they wish, it shouldn't be the business of a language implementation or build system.

I'm not talking about self-hosting, i'm just saying that most people will have their source already on some stable location (typically a hosted forge). I'm not so sure why crates.io should be any different than the typical source host: i don't trust you, so i'll run my own thing, but now people have to trust me and we're back at square one.

All in all your points are mostly valid (i don't fully understand all your arguments about versions as integrity should be handled by git) but again referring to my first message, they are best addressed by a community repository: these kind of guarantees can only be addressed by a trusted entity and there no reason on the world everybody writing rust should be trusting the same entity (with such a lightweight management). It can only fail in some ways.

This being a gordian knot is exactly why it shouldn't exist (or more precisely it shouldn't be such an important/official/recommended thing).

Providing an unified build system and tooling for rust "crates", with cargo etc is all fine, but if you're not prepared to run a registry then don't. It is almost purely a political and people-handling issue. The only value a registry like crates.io provides is to have shorter human readable names instead of git repo urls. Possibly together with the ability to run some analytics on what some people write in rust. This is purely cosmetic and is a WWW anti-pattern (urls have this job).

All these tools (pip, cargo, npm) support git urls just fine. Just don't upload to the registry and make people use your existing git url, everyone will be better off and it already works.

edit: also iirc, crates.io names and rust identifiers by which you import the library are separate (although usually similar), and the identifiers can be altered when specifying a dependency in Cargo.toml. The registry and crate name do not serve any essential functionality.

Note that this problem of squatting (like many others security problems) is mostly a consequence of unmanaged repositories where developers publish themselves (like crates.io here, npm, pypi or the various "app stores"). Well-tended community-organized repositories, like most linux distribution have, do separate the role of package maintainer. This makes a much needed buffer between users and the developers, which regularly have contradicting interests, security-, support- and integration-wise.

See ddevault's two very clear explanations of this issue: https://drewdevault.com/2019/12/09/Developers-shouldnt-distr... and https://drewdevault.com/2021/09/27/Let-distros-do-their-job....

For me it's not the same notion. Imho a proof is by "abstract nonsense" when it is a relatively short sequence of seemingly uninteresting steps that end up proving something non-trivial in the end. And you're left wondering how this stupid symbolic manipulations which looked just like a sequence of reformulations of the initial thing could have possibly proved the statement. This appears a lot in category theory because the manipulated objects are very rich and usually there are a lot of different ways to describe the same thing. Hence you can sometimes just dive into such abstract tunnels and end up at a quite different location giving other insights.

Boilerplate in proofs is usually what we call "administrative arguments".

Nice one! Very neat.

They chose the option that did not imply sharing too much information with discord. The fact that it's hard is mainly because it's not discord's preferred option. So no, it's a perfectly valid choice to make and discord is being a pita. Setting up time-based 2FA is simple. Setting up network (!! email !!) based 2FA is stupid and cumbersome.

OP doesn't like mastodon for the same reasons [they] didn't like Twitter. That would be mostly:

- "It's not really possible to use Twitter without at least a little bit of doomscrolling"

- "I think that the core concept of a "tweet" is fundamentally unhealthy, because by design it promotes angry and extreme content."

- "Most users don't understand that by "dunking" on someone, they are actually promoting the content."

This is basically a critic of fast-paced short interaction based on an infinite timeline. The comment about TV afterwards may seem weird but for me it makes sense. The whole concept of having everything in a single bucket is very TV-like. I don't believe user behavior will be very different on mastodon than twitter: people will follow some very productive accounts and their feed will be dominated by these.

Not the same mechanism but another simple single-motor/continuous-motion walker in lego https://www.youtube.com/watch?v=Nt2DszsjmQM .. The guy has a couple other walkers..

Church-encodings are cute but closures take space, more specifically an unbounded amount of it (for the code, unless you defunctionalize it)! Hence it is much more practical to have a primitive notion of inert data that can be inspected and which has a fixed or at least predictable size.

Although there are also other more efficient lambda-encodings like Scott-encoding / Mendler-style algebras.

See https://firsov.ee/efficient-lambda/, it's a very cool paper. But it also shows it's very tricky to give a type to these encodings. In the end you're almost always better off building "real" datatypes with records and ADTs unless your only goal is to have a minimal theory.

Local unprivileged shell is not an unreasonable thing to get on linux since most people are building random software regularly. Among the things i know i should be doing but i don't: using a dedicated user for building everything; sandboxing the build process using some bwrap/container.

Basically afaik the default C API (`Python.h`) is matched to CPython's internal representations, hence it's a pain to support it for alternative implementations and incurs cost penalties. The preferred way to interact with C code in pypy is through cffi (https://cffi.readthedocs.io/en/latest/) and ctypes (which afaik is implemented in pure python on top of cffi in pypy).

Numpy being itself written in C and C++ it is strongly tied to the C API and has a complicated build process. Some stuff works and some don't (didn't try recently). If you're invested in numerical python you should most likely not use pypy but go for stuff like cython (like scipy does).

For psycopg apparently you can use psycopg2cffi (never tried).

> How does pypy handle packages written in other languages, like rust? can I use pypy if I depend on Pydantic?

PyO3 supports pypy so everything should be fine.

It's a nice read, an important topic, that of not trusting blindly formal proofs. No theorem ever applies to real world objects, it can only say facts about ideas. It's good to keep that in mind but at the same time that's all we got, it's like a basic premise of science. That's why it's important be able to also do testing and have executable models, to validate that the model behaves like you think it should. But it's also what serious people do already even when doing formal proofs. And it's also why there's usually a difference between scientifically "solving" something and the art of making it actually work.

This is a particular teddit instance shutting down, not teddit the software project.

Stuff is moving a lot currently and there is a bumpy road ahead, but there are several courses of action already being mapped out (scraping html, r-e the private gql api, a setting for operators to put some auth token, ..).

https://github.com/libreddit/libreddit/issues/836

https://codeberg.org/teddit/teddit/issues/400

> It is a dialect, written form is German.

Both things are wrong. It's not a dialect in the sense that it is not the same language with special intonation, some new words and new idiomatic sentences. It has its own (much simpler) conjugation and declension scheme. Much closer in feel to a creole.

Its written form is also not german. Good luck reading some of the züri by mike comic strips as a german reader.

It does not, supply chain attack is not that afaik. This is to defend against npm executing arbitrary nefarious code as your user on install of a compromised package.

Also sandoxing npm really means sandboxing node running npm (which is js).

Ever tried flarum? It's my preferred option in the "modern" forum realm, still pretty lightweight (even degrades gracefully without js).

Also if 3) if you have the energy to write and maintain some stateful thingy that manages this dynamic peer information you need to pass around. And while doable, a hack in bash won't cut it if you want reliability and the occasional introspection when things go wrong.

It's a no for me.

I'd be more interested in the reverse, that is compiler and PL techniques applied to machine learning.

The important point here was given infinite space.

> The beauty of the Web stack is that all of what you are describing is optional.

The problem is not that you cannot write lightweight accessible and beautiful websites, you can. The problem is that this is now all part of the "default web browser" and so many people are taking advantage of its widespread availability to use it without a good reason to. Most commonly fingerprinting, tracking, following corporate dev fads, etc. And because of that it is now borderline impossible to have a decent experience using a lightweight browser because so many websites make crucial use of stuff they should really not. It's possible but it takes time and know-how, personally i don't find it fun enough to invest more time than crafting my ublock whitelists. And this is already more than most people (even people that would be able to do it).

Nothing you say is wrong per se. But what GP is saying i believe is that most website should not need these features to provide value to users. And indeed most website useful to me are still mildly interactive documents. The problem is that web browsers, standards, ecosystems inflated to cater these few webapps needing advanced control over the machine. In a sense web is just the new java: a new environment said to be "cross-plateform" where it is in fact just a new plateform that got its vm ubiquitous.

The web-as-vm has nothing wrong, but it has eaten the web-as-interactive-documents. And now to have a lightweight web experience not focused on webapps i am stuck with the heavyweight runtimes with even more stuff on top just to disable features, lock down invasive websites that grabbed the newly available features to implement invasive anti-features, etc.

Comparing wikipedia to facebook or twitter is ludicrous. They don't do any kind of data analysis (apart from some full-text indexing, which you can do easily on a laptop, it's a basic demo from FTS tools to index wikipedia). Sure they host media and handle lots of traffic but that's about it. It costs money for servers and some network engineers.

I'm quite surprised to read what feels like a cloudflare ad from THC..

Indeed, most likely the question of paying or not wasn't even asked properly and this is just the norm.. In any case my point is that the problem of this capture from some scientific publishers is much deeper than just a problem of how publishing is setup. Its one of the many symptoms of how current research institutions are governed.

Might be of interest: the ocaml interpreter runs on some kind of ZINC machine iirc, which is implemented here: https://github.com/ocaml/ocaml/blob/trunk/runtime/interp.c