• 32 posts
  • 331 comments
Joined 3 years ago
Cake day: June 11th, 2023
  • Keyboard is a central part of my workflows and input, but CLI only narrowly.

    I regularly fire up Nushell, and occasionally use specific or dedicated tools (git, edit, …), but generally, no, relatively to other usage, I wouldn’t say I leverage CLI tools much, although that’s subjective and relative. I wouldn’t call it unusual either, though. Relatively common, actually.

    I certainly have no problem firing up a shell and using Shell, CLI, or TUI, and if a tool or util is good or important enough, I will do so and use them when I need or want to use them for (specific) things or work.

  • From the linked webpage readme:

    2.1 Classify. Each file is labelled permissive (at least one permissive license detected, no conflicting non-permissive license), no_license (no licenses detected, or only non-license legal texts such as CLAs), or non_permissive. The permissive allowlist follows the Blue Oak Council list plus licenses categorized as Permissive or Public Domain by ScanCode. Files classified as non_permissive are excluded from both released datasets.

    From https://www.bigcode-project.org/docs/about/the-stack/:

    v1.1: The three copyleft licenses (MPL/EPL/LGPL) were excluded and the list of permissive licenses extended to 193 licenses in total. The list of programming languages was increased from 30 to 358 languages. Also opt-out request submitted by 15.11.2022 were excluded from this ersion of the dataset. The resulting near-deduplicated dataset is 6TB in size.

    So MPL/EPL/LGPL are already not part of the dataset.

    So… why were they in there? Was this added for v1.1?

    “one permissive license” - So if my project includes a lib and I include the license file for that for the license notice…?

  • Noteworthy: They crawled only the default branch HEAD and inlined all source content.

    • The file contents are included inline. The decoded UTF-8 source text is embedded directly in the dataset, so it is fully self-contained — you can start training the moment the download finishes.
    • It reflects the state of GitHub in August 2025. The corpus is a direct crawl of GitHub repositories at their default-branch HEAD, capturing roughly two additional years of open-source code compared to The Stack v2.
  • We want to give developers agency over their source code by letting them decide whether or not it should be used to develop and evaluate machine learning models.

    crawled directly from GitHub and built to pre-train code LLMs with full-repository context

    Repositories that opted out are removed from the dataset before each patch release.

    “agency”

    Which AI company will not use v1 which has all of the data but will use later patch releases instead which have less data?

  • Unfortunately, these crawlers instead try to read every single page from Codeberg, no matter if it makes sense. This includes all the different issue filter variants, Git history, as well as the actual files at any point in Git history - even if they are still equal.

    I’m surprised they don’t lock some things behind account logins. Is it that hard to decide what would be acceptable to no longer serve without an account?

    Does the full commit and change history have to be available without an account, under these circumstances? If we think about what would be minimally enough:

    • Current branch head tree
    • Tag trees (you can link to release source state and [potentially/manually] compare between releases)

    Not having a change log history nor code change diff seems like a big loss to me, but you have to draw the line somewhere, and that seems acceptable to me.

    To me, Codeberg is in a better position to do so than smaller instances. I already have an account because it has many [relevant/significant] projects, is a home of public good, and is under an appropriate org.

In Brief:

  • Two motions regarding “artificial intelligence” and Large Language Models (LLMs) were voted on among Codeberg e. V. members and passed.
  • We are promising to not use any of your data to train LLM and explain what the planned Terms of Use change mean for ‘vibe-coded’ projects.
  • We believe that LLMs endanger the free/libre software ecosystem as a whole.

The blog/news post then goes extensively into where Codeberg understands itself to be in the development landscape, and their voting results. They present their interpretation of the current software development and hardware landscape under the influence of LLMs, and the consequences they take. And how it changes not only development in general, but FOSS collaboration and projects specifically.

To us, it seems ridiculous to see projects with a single developer and virtually no users consuming as much or even more resources than some of the largest community projects on Codeberg, which operate frugal with CI/CD and storage resources. We do not believe it is reasonable for Codeberg to invest our precious donation money into hosting of large ghost projects.

  • Yeah. Building something and solving your gaps yourself is much better for learning than following a walkthrough.

    A walkthrough can be effective onboarding if you’re already familiar with the concepts. Otherwise, it takes the right kind of learning mindset to effectively take away results; not just following along, but internalizing the concepts and constructs.

    For beginners, both the language and the concepts are new. Repetition/Multiple occasions help with internalizing.

Andrew Kelley quit his job in 2018 to build a programming language. Eight years later, Zig powers Ghostty, TigerBeetle and Uber’s cross-compilation. It’s top 5 most admired on Stack Overflow. There’s just one thing missing: 1.0. Andrew Kelley explains why.

Vitaly talked to Andrew about:

  • Why Zig has no 1.0 after a decade, and why that’s deliberate
  • Why Zig left GitHub
  • Why Zig banned AI from Zig
  • What makes Zig better than C (and why every other C replacement failed)
  • Andrew’s take on Open Source

It’s a long interview, but I found it very interesting and worth it.

  • Zig compiler project is about 600,000 lines of code - roughly the same size as Bun before the rewrite, and I’m clocking 16s to build from scratch with a clean cache, followed by 90ms for each subsequent edit with incremental compilation enabled.

    That’s impressive compilation performance. And so most certainly when contrasting it to Rust.

    Brb, I am rewriting everything in Zig.

  • Usually, when CI fails, it’s a flaky CI failure or that I have in fact not run it locally.

    I guess some context is missing. My build flow seems much simpler. I check the CI steps overview and step log, and then I know what’s wrong. That doesn’t take 20 min. More like ~3 min.

    At work, we use Jenkins and the runners are owned infrastructure. If I debug what goes wrong in the CI environment, I go into the pipeline definition, and do the calls locally, just like that, on the command line. No need for complicated environment replication beyond that. dotnet restore, dotnet build --no-restore, dotnet package --no-build, dotnet test --no-build, etc.

    If it’s not CI specific, issues show up in the normal local tooling without special env prep.