HN user

Shamar

154 karma

(no-JS) Web: http://www.tesio.it Feed http://www.tesio.it/atom.xml

Research OS: http://jehanne.io Feed http://jehanne.io/atom.xml

Gopher hole: gopher://tilde.team/1/~giacomo/

Posts11
Comments17
View on HN

The documents provide smoking-gun evidence that Meta, Google, Snap, and TikTok all purposefully designed their social media products to addict children and teens with no regard for known harms to their wellbeing, and how that mass youth addiction was core to the companies’ business models. The documents contain internal discussions among company employees, presentations from internal meetings, expert testimony, and evidence of Big Tech coordination with tech-funded groups, including the National Parent Teachers Association (PTA) and Family Online Safety Institute (FOSI), in attempts to control the narrative in response to concerned parents.

“These unsealed documents prove Big Tech has been gaslighting and lying to the public for years

# Declaration

We, the undersigned members of the Open Source community, assert that Open Source is defined solely by the Open Source Definition (OSD) version 1.9.

Any amendments or new definitions shall only be recognized if declared by clear community consensus through a transparent process to be determined.

The problem with hype around LLM is that people without much experience in the field can't think of anything else.

So much they forget the basics of the discipline.

What do you think cross validation is for?

To compare different weights obtained from different initializations, different topologies, different hyper-parameters... all trained from the same training dataset.

Even for LLM, have you ever tried to reduce the size of the vocabulary of, say, Llama?

No?

Yet it's a totally reasonable modification.

What's the preferred form to make modifications like this?

Can you do it fine tuning llama weights?

No.

You need training data.

That's why training data are the preferred form to make modification, because whatever the AI (hyped or not) it's the only form that let you make all modifications you want.

Compiling Emacs on a PDP-11 wasn't cheap either.

And by today standards, a PDP-11 is quite comparable with the cost of the server farms used in training.

And yet Emacs was released under GPL.

So the economic argument is pretty miopic.

It's not just marketing: European AI Act impose several compliance obligations to corporations building AI system, including serious scientific scrutiny on the whole training process.

Such obligations are designed to mitigate the inherent risks that AI can pose to individuals and society.

The AI Act exempts open source from such scientific scrutiny because it's already transparent.

BUT if OSI defines black boxes as "open source", they open a loophole that will be exploited to harm people without being held accountable.

So it's not just marketing, but dangerous corporate capture.

The term "absorbed" was not for the people in the field, but for people who don't know what folding means.

IMHO it's a better metaphor then "learning", because learning is a _subjective_ experience that everyone does and using that term lead inevitably to anthropomorphisation.

"Absorb" match the insight of filters and pipelines, that can be easily understood from any CS student, any "ML expert", any lawyer and any other citizen.

____

As for the network, my argument is simple: if I get back the source dataset from the executable, I think we can agree that such dataset is projected on the numerical matrices that such executable record.

Now where is the dataset?

You might argue that it is recorded _only_ into the gradients logged there (the gradients applied to one single "neuron" for each "layer"), but if so you could reconstruct the source dataset from the logs alone, and in fact, you cannot. You need both the "model" and those gradients in the correct order (and the encodings of inputs and outputs, obviously).

You might ask: "fine, but how much of the source dataset is projected into the gradients and how much is projected into the model?"

To answer, we need to consider that

- the vector space that constitutes the executable is non-linear (the "model" part) and hierarchical (the vectors of the gradients are not independent neither between layers nor between samples)

- (initialization apart) all the values (and the operative value) that the "model" contains comes from the source dataset

Thus I argue that a substantial portion of the source dataset is contained in the "model".

This does not exclude that another substantial portion of the source dataset is also contained into the few logged gradients!

And in fact I've never stated that the "model" contained the whole source dataset.

But if the portion contained into the "model" was negligible, you would be able to get back the sources from those logged gradients alone with negligible errors.

AFAIK, it is not possible, but if you can, please teach me how! I'm always more than happy to be proven wrong if I can learn how to do something that I previously thought impossible!

Beyond the global output and error of each sample from the last epoch, the log also includes the weight update of one single (fully connected) node for each layer.

During the compilation phase, the training dataset is projected on a complex vector space that is constituted by both the "model" of the "neural network" and these logs.

It's just like projecting a shadow over a bidimensional surface: if you discard the data pertaining to one dimension you have no hope to guess what projected it: you need both dimensions.

The logs that are preserved in the compilation process is the part of the vector space that is usually discarded during the "training".

But discarding the "model" would have exactly the same effect: you cannot get back the source dataset from those logs alone. That's why this does not "smuggle the training dataset back".

Indeed the fact that the source dataset is obtainable from the couple "these logs" + "final model", but neither from "these logs" alone nor by the final model alone, proves that a substantial portion of the source dataset is always embedded in the "model", that becomes a derivative work of the sources.

It's worth noticing that while they didn't target specific people or made the attack undetectable through cache control trickery, the tools they are looking for can be used to detect such evidence removal.

So they are probably building a Government database of IP/people using such tools!

This target mainly Russians, but you know, as Mozilla use to say... "this is the Web functioning as designed"!

This is very interesting: https://2018.stateofjs.com/javascript-flavors/overview/#tool...

Nearly 70% of JavaScript developers have less than 10 years of experience (with an average of 8.3 years).

This means they have never seen a Web where JavaScript was optional and Web developers were used to test their projects without it.

This in turn explains their outraged reactions to anybody that dare to point out its severe vulnerabilities.

See

https://bugzilla.mozilla.org/show_bug.cgi?id=1487081

https://dev.to/shamar/the-meltdown-of-the-web-4p1m

https://dev.to/shamar/i-have-been-banned-from-lobsters-ask-m...

https://www.reddit.com/r/firefox/comments/9v5qst/1487081_und...

Simplicity awakes 8 years ago

But what's the point of showing it?

To reason about reliability and its impact on costs.

Real systems have 99%+ uptime, or they aren't deployed.

Uptime is not correctness.

failure rates are astonishingly low [...] I don't see you arguing with that, because you can't argue with it. It's the facts!

No, it's your perception.

These are facts:

- https://www.cvedetails.com/

- https://www.debian.org/Bugs/

- https://bugzilla.redhat.com/query.cgi

- https://bugzilla.kernel.org/describecomponents.cgi

- https://bugzilla.gnome.org/query.cgi

- https://bugs.kde.org/describecomponents.cgi

- https://bugzilla.mozilla.org/describecomponents.cgi

- https://bugs.chromium.org/p/chromium/issues/list

do a search in any of these issue tracker and you will be overwhelmed with facts.

Now, I agree that, with huge efforts and costs, over decades many developers and companies managed to go beyond the 99% correctness on some projects.

But with simpler systems and designs, the cost of reaching such level of quality (that most of software do not even aim to reach) would be a tiny fraction.

Not doing "the right thing" works. Doing "the right thing" generally doesn't

I wonder if you read the article at all.

I proposed a third style: simplex sigillum veri.

Simplicity awakes 8 years ago

I'm arguing against what that particular graph insinuates. The idea that nothing works anymore when the sum of all unreliable parts creates a completely unreliable result.

No.

That graph shows the probability of the whole system working correctly (aka as the user expect) if each component is 99% correct.

I confirm this.

But I cannot say how severe is the bug you will face. I never said "nothing work anymore".

That doesn't happen in practice with the actual operating systems (and other systems) that we use.

You overlook the failures.

Each big or small failure count in that graph.

They have a choice between Microsoft Office and LibreOffice, both of which are crap.

Sorry I explained me badly.

Gabriel says this in a more diplomatic way: "users have already been conditioned to accept worse than the right thing".

"Conditioned" aka manipulated aka marketing.

I meant that by only proposing crap against crap you promote crap.

Simplicity awakes 8 years ago

The things that don't work, they generally don't work 100% of the time. The things that do work, they generally work 100% of the time.

If you exclude the guns that kill, guns are safe.

If you exclude all security vulnerabilities of the last decade, all mainstream software is secure.

I don't need a system that is really simple and (as a consequence) super-reliable.

I think you are overlooking how pervasive is computing in your life.

But I can see how a user that have no programming experience could refuse to accept the sad state of today computing.

After all, even entirely correct software cannot prevent hardware faults (which do occur).

You are misreading the intent here: as artifacts built from fallible humans, no software can be perfect.

But if you don't even try to keep complexity low, it will soon become unmanageable and expensive.

Still, as Gabriel said in his essays, you are right that users can be manipulated to accept and even pay for crap.

It's called marketing.

But I don't like it.

Simplicity awakes 8 years ago

Plus in this case the awake call could be named something more intuitive

This is an interesting objection.

I find awake/awakened/forgivewkp intuitive names, but I'm not a native English speaker.

I'm not going to add the syscall parameter (I considered and discarded that option during the analysis), but I welcome suggestions for a better naming.

Simplicity awakes 8 years ago

Jehanne hacker here.

doesn't this suffer from a race condition?

This is a good question I should probably clarify in the article as it has been asked before but I can't answer in that forum (see https://lobste.rs/s/fqilcv/simplicity_awakes#c_8pvo0s).

To prevent race conditions the wakeup can occur only during a blocking system call (not even all, some cannot be interrupted to avoid unintuitive side effects).

it then suffer from the problem that a random buggy library function could request an awake without then doing a blocking syscall (due to whatever logic bug), so then when the process does a blocking syscall that it expects to block indefinitely, it instead gets a syscall with a timeout?

This is by design.

The awake idiom described in the article is pretty simple: if you book a time slice you must release it if it didn't expire.

The operating system cannot prevent userspace bugs.

Wouldn't it be better for the awake syscall to take another syscall as a parameter

This is an option I discarded during the analysis.

It's a matter of trade offs: an additional argument would increase the complexity a lot. In particular, you would need to maintain a map of syscall->wakeups in userspace if you want to be able to `forgivewkp` the right one. And, on successful completion of a sequence of syscalls, you would have to `forgivewkp` all unexpired wakeup in such map.

Thus a single addictional parameter would largely increase the complexity both of the kernel implementation and of the user space code, making several bugs harder to reproduce.