ckastner

oh, I missed that. Brilliant!

Can't believe it's already been 10 years...

https://joelgrus.com/2016/05/23/fizz-buzz-in-tensorflow/

This, exactly. For example, cheating is a strategy. If cheating gets an agent to the goal faster than the other strategies, what's so surprising about the agent picking that strategy?

The problem is indeed alignment.

> Are you saying people haven’t been throwing unneeded GPU capacity on the market? That is happening.

That, by itself, doesn't have to mean anything.

AWS is far more compute capacity than Amazon needs, but that's not because Amazon misjudged how much capacity they need. They built it out to sell it to others, leveraging know-how and economies of scale to do so very profitably.

Note that we are still in the discussion period, and more proposals can and will be added. Some might even be withdrawn.

The death knell was Elop announcing that Nokia would be exclusively Windows, at a time when Windows had low single-digit market share and where this exclusivity was a one-way street. Other major manufacturers continued to ship Windows phones, and they did that in parallel to their main Android line.

I never understood what the end game here was. If they had wanted market dominance based on someone else's OS, they could have just used the well-established Android. There was little to gain (their efforts of promoting Windows Phone would have also helped the competition's offerings) and all to lose.

> Isotopic dating shows that whale falls in this region have occurred since at least 5.3 million years ago

Anyone know why these wouldn't be covered under a thick layer of sediment?

> He’s the richest man on the planet and doesn’t have a track record of not paying for shit he buys.

My impression was the other way around. The shenanigans he pulled around the Twitter acquisition were just farcical, and at Twitter he repeatedly refused to pay owed rent, etc. (I assume as a ploy to renegotiate terms).

> They are not. They are best practices if you want reproducible builds.

Or if you're writing a test suite, and you want failing test results to be actionable.

Or you have any other type of behavior that you'd like to reproduce somehow.

One of the first things app developers ask for in bug/issue templates are the steps to reproduce something. I wonder why you'd think that they would suddenly be opposed to thyroid concept when thinking of a build peocess.

I agree that compromised source dependencies are the bigger problem, but that doesn't mean a compromised build infrastructure isn't. Just this last week, we had two Linux kernel LPEs that could have been leveraged to implement just such an attack, for example.

Another thing to consider is that Debian has quite a few derivatives who may also rebuild packages from source, so you have a multiplier there.

> There was no bug or attack on Debian since 2007 that reproducible packages would prevent.

I'm reading this as a suggestion that the reproducible builds effort was an ineffective deterrent.

However, note that your observation could also be explained by the opposite: the reproducible builds effort was an effective deterrent, so nobody bothered with attempts.

> And it just ups the the contribution barrier to Debian higher

Until yesterday, the package just got flagged in the tracker, and you could either ignore it, or fix it yourself, or the kind people behind the reproducible builds effort supplied a patch themselves.

Now, you can no longer ignore it. But fixes are often trivial. Use a (stable) timestamp provided by the build, seed RNGs with some constant (instead of eg: time), etc. These are best practices anyway.

> The reason is this:

> Both ethical and safe conduct depend on context and intent.

The same apples to knives, and they can be plenty useful, and used in a safe manner.

Yes, exactly. Anyone training a model to replace themselves, is replacing themselves -- with something that can run 24/7 and can easily scale. And the better the model, the easier to replace.

Hence why I'm so surprised that MZ, of all people, is arguing in this direction.

I would think that the potential for malicious abuse alone should have scared him off of this.

I can understand the appeal; being able to be "present" without the time cost can mean (possibly significantly more) presence at the same cost. This could be very attractive especially to those managing personal relations, like sales representatives.

But I'm surprised that the risks seem to be so underestimated.

Once this clone exists, what happens if it gets out into the wild? Imagine everyone having full access do what is effectively a digital model of your personality. Imagine your competition putting your own model to use against you.

And the better the approximation of this model, the worse the damage to yourself.

USB/IP has been pretty useful to me, though locking it down is a bit of a chore, as it does not natively support any type of authentication or authorization (a not unreasonable design decision).

I can't really say as I don't use them. This is a host mostly working as a CI worker connected via ethernet.

I just scanned for WiFi networks and that worked fine. I also see that GPIO is not enabled for CIXP1 devices in Debian's kernel; I'll ask the kernel team to enable it.

The Radxa Orion O6 is a really nice ARMv9.2 ITX board, and supports UEFI boot. Installation of Debian trixie using Debian's vanilla installation media went flawlessly, and it's been running fine for 6 months now.

Austrian media are reporting that Peter Steinberger had a $100m exit with PSPDFKit in 2021.

I'm extremely curious what OpenAI's offer was. The utility of more money is diminished when you're already pretty wealthy.

> So the illegality rests at the point of output and not at the point of input.

It's not as simple as that, as this settlement shows [1].

Also, generating output is what these models are primarily trained for.

[1]: https://www.bbc.com/news/articles/c5y4jpg922qo

> To call training illegal is similar to calling reading a book and remembering it illegal.

Perhaps, but reproducing the book from this memory could very well be illegal.

And these models are all about production.

somewhat related:

"Seymour said he thought it was odd that Apple bought a Cray to design Macs because he was using Macs to design Crays. He sent me his designs for the Cray 3 in MacDraw on a floppy.” reports KentK.

https://cray-history.net/2021/07/16/apple-computer-and-cray-...

> Some 30 years ago, someone challenged me to tell the difference between Pepsi and Coke in a blind taste test.

I did something similar with co-workers recently, who didn't believe there is a meaningful difference between brands. I blind-tasted 6 different glasses and got each one right. I got my favorite (Coke) right just by the first smell, I just had to taste to see whether it was diet or not.

Not that this is a skill or anything. Its just that each of the brands I tasted has a strong characteristic flavor to me, and the difference between real sugar and artificially sweetened is also stark. I've been drinking diet versions for ages precisely because the sugary ones are just too sweet for me.

How low could that floor be, in dollar terms?

The financial engineering with the Twitter/X takeover was already pretty bold, but Tesla would probably still be a chunk an order of magnitude larger than that.

There is some nuance to this. Adding comments to the stated goal "Everyone who interacts with Debian source code (1) should be able to do so (2) entirely in git:

(1) should be able does not imply must, people are free to continue to use whatever tools they see fit

(2) Most of Debian work is of course already git-based, via Salsa [1], Debian's self-hosted GitLab instance. This is more about what is stored in git, how it relates to a source package (= what .debs are built from). For example, currently most Debian git repositories base their work in "pristine-tar" branches built from upstream tarball releases, rather than using upstream branches directly.

[1]: https://salsa.debian.org

Coincidentally, the first issue (referencing Navi 21) was the one I started these experiments with, and this turned out to be pretty informative.

Our Navi 21 would almost always go AWOL after a test run had been completed, requiring a full reboot. At some point, I noticed that this only happened when our test runner was driving the test; I never had an issue when testing interactively. I eventually realized that our test driver was simply killing the VM when the test was done, which is fine for a CPU-based test, but this messed with the GPU's state. When working interactively, I was always shutting down the host cleanly, which apparently resolved this. A patch to our test runner to cleanly shut down VMs fixed this.

And I've had no luck with iGPUs, as referenced by the second issue.

From what I understand, I don't think that consumer AMD GPUs can/will ever be fully supported, because the GPU reset mechanisms of older cards are so complex. That's why things like vendor-reset [3] exist, which apparently duplicate a lot of the in-kernel driver code but ultimately only twiddle some bits.

[3]: https://github.com/gnif/vendor-reset