> 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.

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.

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.

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.

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

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

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

And these models are all about production.

"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-...

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.

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.

(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

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

The Debian package rocm-qemu-support ships scripts that facilitate most of this. I've since generalized this by adding NVIDIA support, but I haven't uploaded the new gpuisol-qemu package [2] to the official Archive yet. It still needs some polishing.

Just dumping this here, to add more references (especially the further reading section, the Gentoo and Arch wikis had a lot of helpful data).

[1]: https://salsa.debian.org/rocm-team/community/team-project/-/...

[2]: https://salsa.debian.org/ckk/gpu-isolation-tools

Debian's fork is still based on vixie-cron, but it couldn't have been the one because of the aforementioned patch.

Here's a link to a patch [1] from a version from when the package still kept standalone patches.

It's been a long long time and I honestly don't remember the details, but Debian's cron(8) still says [2]: Special considerations exist when the clock is changed by less than 3 hours, for example at the beginning and end of daylight savings time. If the time has moved forwards, those jobs which would have run in the time that was skipped will be run soon after the change. Conversely, if the time has moved backwards by less than 3 hours, those jobs that fall into the repeated time will not be re-run.

Edit: According to this bug report [3], this workaround first entered Debian in 1999.

[1]: https://sources.debian.org/src/cron/3.0pl1-137/debian/patche...

[2]: https://manpages.debian.org/unstable/cron/cron.8.en.html

[3]: https://bugs.debian.org/8499

Comments URL: https://news.ycombinator.com/item?id=45488690

Points: 4

# Comments: 0

The great force downward is (mostly) irrelevant if there is nothing below. Just hang the rocket between two towers over a void, with the atmosphere below.

[1]: https://en.wikipedia.org/wiki/SpaceShipOne#Launch_aircraft

Comments URL: https://news.ycombinator.com/item?id=45288356

Points: 11

# Comments: 1