zvr

Yes, it was essentially a "zoom" wheel.

Writing in a plan "no GPL/LGPL code" does not actually mean "forget all the GPL/LGPL code that you have ever seen, so that you start from a clean slate".

Remember that we're talking many years ago, in the previous century.

The only way to "automatically" deposit cash was to put it into an envelope and then drop it in the machine. IIRC, you used to write the total amount on the outside of the envelope, together with your bank account information.

The machine was emptied at regular intervals, the envelopes were transferred to the bank, and an employee was manually opening them, verifying the amount, and credit your account.

Decades ago I worked on an ATM that "recycled" money. It did not only had the usual boxes of banknotes that were filled by the bank, but it also accepted deposits. Usually deposits are put in an envelope by the client and an envelope is stored in the machine; this makes reconciliation easy, since a bank employee opens the envelope, counts the money, and confirms the deposit transaction.

But on this ATM, people would deposit their banknotes directly. The machine would recognize and count them, crediting the correct amount to the person's account. And later, when someone wanted to get money out of the ATM, the machine would use these exact banknotes!

It was an innovative design, which saved the bank a lot of money (in ATM-caring trips) and provided people with a real service, since they could use the ATM longer, instead of getting error messages that it was out of cash (well, it never said that it was something more generic like "problem in operation").

As one can imagine, it was an interesting challenge designing the software and thinking of all the tests covering what might go wrong...

Mine is €34.51 to €35.55 (a 3% increase).

Back in the day, there was Tkman, a GUI manpage reader written in Tcl/Tk. It actually used rman (for Rosetta man) that transformed the roff man sources to a more expressive format.

Just a comment pointing people to https://www.librarything.com/ which I find so much better than goodreads.

Regarding the taxonomy of WEMI (work, expression, manifestation, and item), all of them are useful since we are talking about books at different levels. From "I have read Don Quixote", which is about the work (translations are the same), to "My Don Quixote has coffee stains", which is about the item.

The last time something similar happened (Google vs Oracle), the legal battles lasted more than a decade. It would be a very bold decision by ARM to commit to this strategy (implement "CUDA" and fight it out in courts).

Before the "ZLUDA" project completion, they would be facing a lawsuit for IP infringement, since CUDA is owned by NVIDIA.

I would be very interested in seeing a single IDE with "excellent Vim support".

Correct, but the "if Amy works for Global Corp and has the authority to sign legal documents on their behalf" does a lot of work here.

At $WORK, a multi-billion company with tens of thousands of developers, we train people to never "click to accept", explaining it like "look, you wouldn't think of sitting down and signing a contract binding the whole MegaCorp; what make you think you can 'accept' something binding the company?"

I admit we're not always successful (people still rarely click), but at least we're trying.

Really, never realized it?

Πίτα, τυρό-πιτα, σπανακο-τυρό-πιτα, ζαμπονο-σπανακο-τυρό-πιτα, ...

Another enthusiastic Zotero user here. Current library has 13,775 items and for a low yearly price one can have multi-device sync and support the project. I'm also syncing to a server I own, for complete data ownership (just in case).

This matches my experience completely: more than 40 years using vi and then vim, my fingers and my brain know to do.

I've tried to use VScode, especially since people said that it could emulate vi... it can't. Some of the basics are there, but then you forget you are in a different program, and use something that works in vim... and it fails. A couple of times with catastrophic results: I lost a file completely after typing a command.

I actually repeat the experiment every year or so, but I do not see much improvement.

Nice work!

Your documentation should definitely list the Unicode code points / glyphs covered, for people to get an idea which scripts are supported.

Also, the repository has a LICENSE file with the MIT license text, but the actual font file (.ttf) embeds the information that it's licensed under SIL Open Font License 1.1. One of these two pieces of information needs to be corrected.

From the abstract: NVIDIA's CUTLASS library provides a robust and expressive set of methods for describing and manipulating multi-dimensional tensor data on the GPU. These methods are conceptually grounded in the abstract notion of a CuTe layout and a rich algebra of such layouts, including operations such as composition, logical product, and logical division. In this paper, we present a categorical framework for understanding this layout algebra by focusing on a naturally occurring class of tractable layouts.

Would it be possible to use a SQLite file instead of a PostgreSQL instance? Or do you rely on some specific PostgreSQL functionality?

Interesting and I haven't tried it yet.

But the "Usage Guidelines" part of the "License" section at the end of the README says: "License required for: Commercial embedding in products you sell or offering Mantic as a hosted service."

This is not completely true, since it seems that the software is licensed under AGPLv3, which of course allow the use of the software for any purpose, even commercial.

Fascinating!

Stanford University has published the complete set of lectures for their LLM course of last semester. 9 videos of around 1h50m each:

• Lecture 1 - Transformer https://www.youtube.com/watch?v=Ub3GoFaUcds

• Lecture 2 - Transformer-Based Models & Tricks https://www.youtube.com/watch?v=yT84Y5zCnaA

• Lecture 3 - Transformers & Large Language Models https://www.youtube.com/watch?v=Q5baLehv5So

• Lecture 4 - LLM Training https://www.youtube.com/watch?v=VlA_jt_3Qc4

• Lecture 5 - LLM tuning https://www.youtube.com/watch?v=PmW_TMQ3l0I

• Lecture 6 - LLM Reasoning https://www.youtube.com/watch?v=k5Fh-UgTuCo

• Lecture 7 - Agentic LLMs https://www.youtube.com/watch?v=h-7S6HNq0Vg

• Lecture 8 - LLM Evaluation https://www.youtube.com/watch?v=8fNP4N46RRo

• Lecture 9 - Recap & Current Trends https://www.youtube.com/watch?v=Q86qzJ1K1Ss

All types of SBOMs can be described in the same standardized format. SPDX 3.0 has a specific property and a set of values this one can take: https://spdx.github.io/spdx-spec/v3.0.1/model/Software/Vocab...

The digital signing of SBOM artifacts, so that one can verify authorship and authenticity, is something external to the SBOM data, on top of them.

If you are asking about a standardized way to check these, across all computing environments, I think this is a tall order. There are obviously environments currently where this check is present, and there are environments where this is rigorously enforced: software will not load and execute unless it's signed by a specific key and the signature is valid. But the environments are so diverse, I doubt a single verification process is possible.

> This is just FUD. XeLaTeX/LuaLaTeX do not introduce any "complications"

Well, there are still some packages that work flawlessly with pdfLaTeX, but not completely with LuaLaTeX or XeLaTeX --- microtype is the canonical example.

"manually creating an SBOM" is a much lower priority requirement than "easily, accurately, and completely creating an SBOM".

The whole idea is to use specific libraries to produce and consume SBOMs.

You wouldn't expect people to "manually create" JPG images, would you?

Software Bill Of Materials (moving to System Bill Of Materials), as lots of comments here explain.

What is a "UK" ? ;-)

> What happens when you vendor/patch/fork a dependency?

You change the supplier property (and most probably the version). This is how you distinguish between OpenSSL 3.1.4 from OpenSSL project and OpenSSL 3.5.4-1~deb13u1 from Debian project.

> What happens to vulnerabilities that are not in code paths not used by your software, or only under certain flags?

You record this information in the SBOM, using structures like "this software has this vulnerability reported, but it's not affected by it in this case" (see, for example, VexNotAffectedVulnAssessmentRelationship in SPDXv3).

I completely agree that its purpose is not to replace lockfiles.

It was dropped exactly because it was flat and it was becoming completely unmanageable.

SPDX v3 is based on a graph model that can represent hierarchies natively. It can then be serialized in a file, for example, in JSON format.

Think of the SBOM as a "table of contents" for the software you are receiving. Another metaphors that has been used is the "nutrition label" that you get in all packaged food.

So, it's a list of the "software components" that are inside a piece of software. And then you add metadata about each of these components: what's its name? its version? its hash? Up to now we're in lockfile territory.

But you want more information: what is the license? who supplied it? what is the security status? does it have known CVEs? are they relevant?

And then you go to special cases, like "AI" software: oh, it's a model? how was it trained? on which data? Or like software that has to be certified, to be used when safety is important.

An SBOM is capable of providing all this information. Take a look at the different parts that SPDX provides, and it's an ever expanding area.

Ah, but there are actually different types of SBOMs, that describe the software in different parts of its lifecycle. It's a completely different outcome to record the software when looking at its source, at what is being distributed, or at what is being installed, for example.

At some point we realized that we were talking across each other, since everyone was using "SBOM" to describe different contents and use cases.

The consensus was expressed around 3 years ago, and published in https://www.cisa.gov/sites/default/files/2023-04/sbom-types-...

Exactly.

To understand what an impossible task this is, there is no need to think about different ecosystems (PyPI vs NPM vs Cargo vs ...). Even in the case of different Linux distributions, the package managers are so different that expecting them to support the same formats is a lost cause.

The format is standardized, to the highest level possible: ISO/IEC 5962:2021 defines SPDX v2.2.1. The actual standard text is available for free at the ISO website (and other places, like spdx.org).

The newer version, SPDX v3.0, will become ISO/IEC 5962:2026, and work is already underway for further versions.

What is not standardized at all are the integration of processes for producing/consuming/maintaining SBOMs in the software development world.