Home

https://martin.kleppmann.com/2021/04/14/goodbye-gpl.html

I saw this post on Hacker News, and before I could reply, someone flagged it. Oh well. So I’ll post my thoughts on it here…

First, it’s unfortunate that this post start out with (well-intentioned but probably compulsive) flame-bait about Richard Stallman, which is likely to derail the discussion.

Anyway the author is arguing that GPL is pointless, because:

1) Most things are in the cloud, so companies don’t have to release their GPL modifications.

2) GPL only covers the code, there’s nothing forcing companies to release documentation, etc. or accept outside contributions

3) It’s incompatible with non-copyleft open-source licenses (like BSD), causing fragmentation and difficulty integrating things (see ZFS in the Linux kernel, for instance)

But I think that #3 is actually secretly the main strength of the GPL. Because companies can’t fork it and close-source it, or incorporate it into closed-source programs, open-source idealists prefer to contribute to GPL projects. However, whatever individual or company maintains the project can easily monetize it by selling support. It’s very winner-take-all. This promotes strong leadership, with a strong vision, for each GPL project (as they want to continue selling support). This also discourages fragmentation.

Just look at Linux vs BSD. The Linux ecosystem is very tight-knit. Linux distros typically use the same components (just with different configuration). There aren’t a million implementations of X11, there’s only one! Now compare that to BSD. We have… forks and fragmentation everywhere. FreeBSD even has all of userland included in the repository, as a mitigation against runaway fragmentation.

I agree that the GPL has failed in its goal. It hasn’t been able to provide a competitive alternative to closed-source software (if you find that Linux is competitive to Windows for your needs, you’re very lucky). However, it has allowed open-source to thrive in some software developer and “power-user” niches such as compilers and 3D graphics programs.

I always forget the order of arguments to ln -s. It’s a problem. So here’s my handy-dandy way of remembering it, as a blog post:

ln -s «real file/directory» «symlink you are creating»

Once upon a time, I worked at a company that heavily contributed to and used Chisel (a Verilog generator using a Scala DSL). Now, roughly 3 years later, I tried to make a fun little hardware design using Chisel. I remembered that the people who were contributing to Chisel liked to break backward compatibility for no reason at all, so I decided to stick with the version of Chisel that I was using back in 2018 (3.2.x).

Unfortunately, even with that safety measure, I didn’t get far before running into trouble. Here’s my simple design:

class N64DevCartMain() extends Module {
    val io = IO(new Bundle {
        val n64adi = Input(UInt(16.W))
        val n64readn = Input(Bool())
        val n64ale_l = Input(Bool())
        val n64ale_h = Input(Bool())
        val n64ado = Output(UInt(16.W))
        val romAddr = Output(UInt(32.W))
        val romData = Input(UInt(16.W))
    })
    val addr = RegInit(0.U(32.W))
    when (!io.n64ale_h && !RegNext(!io.n64ale_h)) { // ALE_H falling edge
        addr := (addr & "hffff".U) | ((io.n64adi & "hffff".U) << 16)
    }.elsewhen (!io.n64ale_l && !RegNext(!io.n64ale_l)) { // ALE_L falling edge
        addr := (addr & "hffff0000".U) | (io.n64adi & "hffff".U)
    }.elsewhen (io.n64readn && RegNext(!io.n64readn)) { // read rising edge
        addr := addr + 2.U
    }
    io.romAddr := addr;
    io.n64ado := io.romData
}

I wrote a small test for this also:

package N64DevCartMainTesters {
    class ReadWords(dut: N64DevCartMain) extends PeekPokeTester(dut) {
        val delay = 3
        // Set initial state
        poke(dut.io.n64adi, 0.U(16.W))
        poke(dut.io.n64readn, true.B)
        poke(dut.io.n64ale_l, true.B)
        poke(dut.io.n64ale_h, true.B)
        poke(dut.io.romData, 0.U(16.W))
        // Check initial output
        expect(dut.io.romAddr, 0.U(16.W))
        // Change address to 0x12345678
        poke(dut.io.n64adi, "h1234".U(16.W))
        poke(dut.io.n64ale_h, false.B)
        step(delay)
        poke(dut.io.n64adi, "h5678".U(16.W))
        poke(dut.io.n64ale_l, false.B)
        step(delay)
        poke(dut.io.n64readn, false.B)
        step(delay)
        expect(dut.io.romAddr, "h12345678".U(32.W))
    }
}

Unfortunately, this test was flaky, somehow. One in three runs of this test would get an incorrect value in romAddr. Why? Who knows.

I tried updating Chisel3 to the latest version, 3.5.1. But, apparently, the API for instantiating tests was deprecated (in a minor version change!). Here was the test instantiation code:

object Main extends App {
  chisel3.Driver.execute("-td chisel_output".split(" +"), () => new N64DevCartMain())
}

So yeah. I don’t have time for this. What should I try next? Bluespec? MyHDL? SpinalHDL? ROHD? Migen? Clash? There are a ton listed on this page, and I just hope that I can find one that is more stable and than Chisel.

I’m mad. I bought an FPGA board, then discovered that one of the primary features I wanted is missing. How? Well, the website of the manufacturer is seemingly (to me) deceptive. Take a look:

https://numato.com/product/mimas-a7-mini-fpga-development-board/

Now, looking at that page, does this board support programming via USB only? If you’re looking at it with a critical eye, expecting some kind of deception, it’s patently obvious. It says “configurable via USB and JTAG” not “configurable via USB or JTAG”. Ohhh. Then you check the User Manual. Yep, it only has “Configuring Mimas A7 Mini Module Using JTAG”.

But looking at the product page, the existence of the FT2232H is emphasized all over. So you’d think it’s programmable via USB, right? In fact, the Digilent Arty boards use this exact chip and allow configuration via USB. Maybe Numato never got around to making configuration via USB work? Who knows. All I know is, I now have to spend $100 for a used Xilinx JTAG programmer.

I use a beefy build server to do my Linux Kernel compiles. I use github workflows to do the compile in an unattended fashion. I don’t want to SSH into the server to run make menuconfig. What do I do?

I use a Macbook as my daily driver. It would be nice if I could generate the .config file on my laptop. But,.. there’s no way that would work, right? Right?

Turns out, it does. You just need to do the bare minimum hackery. It took me 2 minutes to figure out and do. Here it is:

1. First, you’ll probably run into this error:
   ld: unknown option: --version
ld: unknown linker
scripts/Kconfig.include:56: Sorry, this linker is not supported.
make[2]: *** [menuconfig] Error 1
make[1]: *** [menuconfig] Error 2
make: *** [__sub-make] Error 2
   Just remove the offending line (56) from scripts/Kconfig.include
   In this case, remove this:
   $(error-if,$(success,test -z "$(ld-info)"),Sorry$(comma) this linker is not supported.)
   
2. Next, you’ll probably run into:
   init/Kconfig:53: syntax error
init/Kconfig:52: invalid statement
init/Kconfig:53: invalid statement
init/Kconfig:61: syntax error
init/Kconfig:60: invalid statement
init/Kconfig:61: invalid statement
make[2]: *** [menuconfig] Error 1
make[1]: *** [menuconfig] Error 2
make: *** [__sub-make] Error 2
   Just remove those lines also. In this case, remove these:
   default $(ld-version) if LD_IS_BFD
default 0
   
3. Now run make menuconfig and amazingly, it’ll work.
   

I made this little flowchart to collect my thoughts on driver development in the Windows vs Linux ecosystems. Uploading it here so I can refer back to it when the need arises.

Found this excellent blog post: https://liam-on-linux.livejournal.com/82328.html

This echoes most of what I’ve been feeling about the state of “Linux Laptops”. They’re mostly a scam. Dell slaps stock Ubuntu, plus some preloaded drivers, onto a laptop and calls it “Linux Edition”. System76 isn’t any better. They also slap a custom Ubuntu derivative distro on there, which serves no purpose other than to serve up a prettier UI. Because that’s what the Linux world wants, right? A prettier UI? Not better drivers? Not rock-solid sleep/hibernate/lid/monitor support? Not better update functionality?

At least System 76 is making a new desktop environment in rust. But if it’s to improve performance and stability, or just part of an ongoing war with GNOME remains to be seen.