infinity0

The algorithms are opaque but how's that different from a human's own brain? We don't have a very good view into a judge's own life experiences from which his own decisions are based either. At least with an algorithm we have a chance of seeing how it really works, in principle. All the data is recorded and the code is available.

> The reality is that if the algorithm looks like it’s doing the job that it’s supposed to do, and people aren’t complaining, then there isn’t much incentive to really comb through all those instructions and those layers of abstracted code to work out what is happening.”

If a judge is performing well are you going to run an expensive background audit on him, or open up his brain to try to see how he "really works"?

The difference is that algorithms today are practically run by centralised organisations that control it plus the data, rather than having lots of humans all slightly different making their own decisions in a semi-centralised[^] distributed fashion. But the opaqueness is nothing new.

[^] because most human organisations today are hierarchical, but at least most people have some sense of self-agency.

It would usually be the same airline that did the long flight or one of their partners - but Ryanair and Easyjet don't do those partnerships with Chinese airlines. I've also gotten a lot of their flights and hardly ever see Chinese tourists, mostly local (or other European) tourists in fact.

Funny that they blame Ryanair and Easyjet, who only serve Europe, in the first sentence, then plaster a big photograph of a field full of Chinese tourists that most likely did not use Ryanair or Easyjet to get there.

You think the world only has 1 nuke?

Also it looks like 40 was an overestimate by me, the real number is 15: https://www.google.com/about/datacenters/inside/locations/in...

The author includes an incorrect diagram swapping around the definitions of distributed vs decentralised, then ignores that one of the design criteria of the internet was to survive against nuclear attack.

Google's 40 centralised global datacenters wouldn't stand up very well to that sort of thing. Centralisation only works when nobody stronger is around to compete with.

In this case, many does mean most.

Facebook or Google doesn't have the ability to crush or buy any competition that arises, that provide a more open platform? Which world are you living in?

The article says "Many computer users" not "Many customers". Furthermore when the article mentions "customers" elsewhere we can probably assume it means "Intel customers" which is a much greater subset than the group you're talking about, and which would be probably less than 1% as numerous as the "Many computer users" that run javascript.

lol, javascript

web search "spy in the sandbox"

> Another issue is whether the customer should install the fix at all. Many computer users don’t allow outside or unprivileged users to run on their CPUs the way a cloud or hosting company does. For them, these side-channel and timing attacks are mostly irrelevant, and the slowdown incurred by installing the fix is unnecessary.

lol, javascript

Nobody's trying to impress you mate

That's like saying monopolies don't decrease the competitiveness of the market, just the "competitiveness" of their own products for their own consumers.

They have the power to censor posts on their platforms, and use it, just like the Chinese government has the power to censor the internet in China, and use it.

Why are you asking such an obvious question?

Again, this country-vs-country bullshit propaganda.

The web is already less open from the efforts of US companies developing massively centralised platforms like Google, Facebook, and so on, you're familiar with the story. And they look very eager to play into the Chinese government's rules for their own profit, whilst at the same time paying lip service to liberal principles and internet principles of openness.

At the same time there's plenty of Chinese investment into decentralised cryptocurrencies, probably more so than coming from US investment groups. Some large western companies are doing more blockchain research for sure, but the vast majority of them are only interested in those within the context of their own centralised, privatised, permissioned systems.

Enough of this China vs US crap, your narrative is simply wrong. If you give a shit about the open principles of the internet, talk about the actual projects in reality actually trying to preserve these principles, and stop narrating based on false political boundaries.

Pretty ironic that a couple days ago there was some article claiming that China was about to collapse because it was going through "an orgy of investment" in an attempt to grow whilst its recent projects did not generate any actual revenue.

TL;DR some professors are worried that their poorly-paid students doing grunt-level work that professors find beneath themselves to do, will realise quite quickly what the better deal is after working 80% for a company and 20% for a university.

That's a very interesting question, especially since the training data is also (partly) generated by the software in a self-feedback loop. For the case of Leela Zero, most of it has been generated by Leela Zero itself based on its own algorithm, but some of the data has been supplied from the data set generated by the Facebook ELF Go engine. (They used it as a shortcut to catch up to the level of ELF, and then surpass it.)

In order to reproduce the current best-weights then, one would have to record exactly what versions of Leela Zero and ELF was used to generate which subsets of data, and which subsets were used to create further subsets of the data. I don't think anyone has kept that information around, so I'd guess the current best-weights will not actually be reproducible, ever.

In future, one can imagine other software that could keep track of this information, and then be actually able to reproduce a particular resulting set of weights.

However let's step back a bit. On a high-level, nobody actually cares that the results are not fully deterministic, they only care that it is a faithful representation of what the source code does. This is true both for software determinism and for weights-model determinism. Being deterministic is a (relatively) easy property, which when we achieve it, allows us to verify that the results (binary software, trained weights) don't contain backdoors or other unpleasantness that's not visible in the source code. But the latter is what we "actually" care about.

If we can achieve the latter property without achieving determinism, then we are also mostly satisfied. That would involve being able to examine the model directly and see what it does, and see that it doesn't contain backdoors or other things. I can't even begin to imagine how to achieve this, it is a hard problem and the solution to this, would also solve the criticism of these AI weights/models being opaque and not really contributing much to human knowledge.

Determinism is still useful for other purposes though. If you know exactly how something was produced, you have much greater control and understanding of how to tweak it, which might actually help us with the aforementioned goal of deeply-understanding these weights from a human perspective.

For Leela Zero it's basically just the computing resources, the software is done using an abstract but openly-specified GPU execution system OpenCL, similar (as far as I understand) to an instruction set architecture (ISA).

Whether the abstract execution system is implemented in a proprietary or free way is a separate issue. For example these days it's hard to execute x86 instructions without running some sort of proprietary microcode and/or management engine. For comparison, OpenCL has many competing implementations, including the free open source MESA graphics drivers.

jQuery is actually one of the nicer javascript libraries.

- knows what it is, i.e. a web javascript module, it doesn't try to inappropriately wrap itself in CommonJS/AMDJS wrappers

- doesn't need node/npm to run

- doesn't need node/npm to build

Debian packager of Leela Zero here.

Most of the questions raised in the thread were basically irrelevant to Leela Zero, which does everything "correct" from the point-of-view of a strict interpretation of free software:

- open freely licensed data set - open freely licensed training code

The only issue relevant for user software freedom, is that the results of the training process can't be reproduced easily.

I was irritated at the thread because 90% of it was theorising about some alternative situation where the data set was not free, or the training code was not free. That is not the situation we have with Leela Zero, we can skip that discussion and focus on what's actually at issue, i.e. the reproduction / verification of the training process.

Oh so that's what the rust crates fuchsia-zircon and fuchsia-zircon-sys are for. They are dependencies of the mio and rand crates.

Cargo.toml links to https://fuchsia.googlesource.com/garnet/

A step in the right direction for machine learning in science, but they could have done some more research into naming conflicts:

$ apt-cache show quilt

Package: quilt

[..]

Description-en: Tool to work with series of patches

Quilt manages a series of patches by keeping track of the changes each of them makes. They are logically organized as a stack, and you can apply, un-apply, refresh them easily by traveling into the stack (push/pop). . Quilt is good for managing additional patches applied to a package received as a tarball or maintained in another version control system. The stacked organization is proven to be efficient for the management of very large patch sets (more than hundred patches). As matter of fact, it was designed by and for Linux kernel hackers (Andrew Morton, from the -mm branch, is the original author), and its main use by the current upstream maintainer is to manage the (hundreds of) patches against the kernel made for the SUSE distribution. . This package provides seamless integration into Debhelper or CDBS, allowing maintainers to easily add a quilt-based patch management system in their packages. The package also provides some basic support for those not using those tools. See README.Debian for more information.

$ zcat /usr/share/doc/quilt/changelog.gz | tail -n3

Version 0.26 (Tue Oct 21 2003) - Change summary not available

Would this also benefit non-top-level thunks?

We had a ridiculous space-leak at DFINITY just last month where the workaround I found involved turning off full-laziness [1] as well as using a variant of `Control.Monad.forever` defined in terms of `(>>=)` rather than `(* >)` - which is how `Control.Monad` does it, which interacted badly with how Conduit implements `(>>=)` and `(* >)`. We never got to the bottom of exactly why it leaked but I'll be sure to try it out again with GHC 8.6. However it's not clear that long-lived CAF data would have been the problem in our case.

[1] https://www.well-typed.com/blog/2016/09/sharing-conduit/

More funding coming this way for RISC-V

I did a similar thing a couple years ago, it should still be pretty up-to-date:

https://infinity0.github.io/droid-hacks/

I go into a bit more detail than the OP does, though with less-flowing prose.

Surprised that he missed out 192.168.0.0/16

How does it compare to KDE Marble?

Indeed, having lockdown on by default would be reasonable.

There is an argument that "it's useless" [1] without SecureBoot but so what? Separation of concerns is a good principle and allows external people to reason about the behaviour much more easily.

There is no point implementing logic like "if x == 0 then y = 0; return x * y" when a simple "return x * y" will suffice. In fact it's actively harmful as it raises the complexity.

[1] http://lkml.iu.edu/hypermail/linux/kernel/1804.0/01621.html

Note that on certain US visa applications, they ask you whether you've ever renounced US citizenship for the purposes of avoiding tax.