ckastner

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

A lot of this coincides with my own experiments I did to pass-through consumer AMD GPUs into VMs [1], which the Debian ROCm Team uses in their CI.

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

Most likely, yes. The author mentions vixie-cron, which was the name of the project before Paul Pixie joined/founded(?) ISC, and it was released as ISC from after.

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

This was worked around ages ago in OpenBSD, and the workaround was already included in Debian (and by extension, Ubuntu) when I started maintaining it in 2010 (I no longer do).

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

There is precedent: SpaceShipOne was successfully launched from an airplane [1].

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

I don't know if these are comparable.

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.

Landing can be: https://en.m.wikipedia.org/wiki/Autoland

In fact, it's pretty routine. Don't have the source at hand, but somewhere around 1% of all landings (at airports with ILS) are autolands.

I think it was Boeing that even requires at least 1 autoland per plane every 30 days or so.

You can find videos of this on YouTube. Completely hands-off.

PayPal never did seek a banking license, arguing that it wasn’t actually accepting any deposits [...]

That worked in the U.S.

European banking regulators saw through this ploy and forced them to seek a banking license.

This is a bit misleading as the decline reported is year-on-year and of course sales haven't fully recovered yet.

Quarter-on-quarter or month-by-month would have been much more interesting, could have shown a change in trend. Especially after Musk's departure from the administration.

Oh this is neat. Took me a bit.

The shell treats the first line as a comment. It executes the second line, which eventually exec's the binary so the rest of the file do not matter to the shell.

And the compiler treats the first line as a preprocessor directive, so it ignores the second line.

I initially misread/mistook the first line for a shebang.

There was another 1981 paper that went into this by Boehm "Software Engineering Economics", but I can't find the details right now.

This NASA publication [1] cites a number of studies and the cost increase factors they estimate for various stages of development, including the Boehm study.

[1] https://ntrs.nasa.gov/api/citations/20100036670/downloads/20...