oh, I missed that. Brilliant!
8,588 karma · joined March 30, 2016
ckk AT debian DOT org
GPG key: 4096R/AFA8E76004C5CEF0C94C
The problem is indeed alignment.
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.
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.
Anyone know why these wouldn't be covered under a thick layer of sediment?
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).
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 the concept when thinking of a build peocess.
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.
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.
> 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.
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.
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.
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/-/...
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
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
But two interesting data points from the Wikipedia article I linked are that the first aircraft certification for ILS Cat III was in 1968, and Cat IIIB in 1975.
And IIRC by the 1980s, autoland was already a pretty common feature.