If the ask is, why was the hardware like that in the first place the answer is because it can’t be fully validated.

But that’s not the question. There are two questions: Who should be responsible for patching hardware vulnerabilities? And if the answer is “the kernel” then should speculative but never demonstrated vulnerabilities be patched? Linus’ answer is the hardware manufacturer, and no.

Is this really the hardware vendor’s problem though? It’s the consumers problem.

Maybe we’re running into the ambiguity of language. If you mean to say, “Who does it cause a problem for? The consumer.” then sure. On the other hand what I mean, and what I think Linus means, is “Who’s responsible for the vulnerability existing? Hardware vendors. Who should fix it? Hardware vendors.”

If the ask is why should a speculative fix go into the Kernel […]

Depends on what you/we/they mean by “speculative”. IMO, we need to do something (microcode, kernel patches, whatever) to patch Spectre and Meltdown. Those have been demonstrated to be real vulnerabilities, even if no one has exploited them yet. But “speculative” can mean something else. I’m not going to read all the LMK emails so maybe they’re talking about something else. But I’ve seen plenty of, “Well if X, Y, and Z happen then that could be a vulnerability.” For that kind of speculative vulnerability, one that has not been demonstrated to be a real vulnerability, I am sympathetic to Linus’ position.

Who said anything about fully validating hardware? “Hardware vendors should solve their own problems” is not the same as “hardware vendors should fully validate their products”.

Of course but presumably on occasion you do work in other languages? I work in all kinds of languages and so jumping between them it’s pretty handy to bridge the gap.

If I were jumping languages a lot, I definitely think it would be helpful. But pretty much 100% of what I’ve done for the last 3-4 years is Go (mostly) or JavaScript (occasionally). I have used chatgpt the few times I needed to work in some other language, but that has been pretty rare.

I think you could definitely still get value out of generating simple stuff though, at least for me it really helps get projects done quickly without burning myself out

If simple stuff == for loops and basic boilerplate, the kind of stuff that copilot can autocomplete, I write that on autopilot and it doesn’t really register. So it doesn’t contribute to my burnout. If simple stuff == boring, boilerplate tests, I’ll admit that I don’t do nearly enough of that. But doing the ‘prompt engineering’ to get copilot to write that wasn’t any less painful that writing it myself.

For small one off scripts it makes them actually save more time than they take to write

The other day I wrote a duplicate image detector for my sister (files recovered from a dying drive). In hindsight I could have asked chatgpt to do it. But it was something I’ve never done before and an interesting problem so it was more fun to do it myself. And most of the one off stuff I’m asked to do by coworkers is tied to our code and our system and not the kind of thing chatgpt would know how to do.

func randomRGB(uid int) color.RGBA {
	b := binary.BigEndian.AppendUint64(nil, uint64(uid))
	h := sha256.Sum256(b)
	return color.RGBA{h[0], h[1], h[2], 255}
}

That took me under three minutes and half of that was remembering that RGBA is in the color package, not the image package, and uint-to-bits is in the binary package, not the math package. I have found chatgpt useful when I was working in a different language. But trying to get chatgpt or copilot to write tests or documentation for me (the kind of work that bores me to death), doing the prompt engineering to get it to spit out something useful was more work than just writing the tests/documentation myself. Except for the time when I needed to write about 100 tests that were all nearly the same. In that case, using chatgpt was worth it.

Is there supposed to be a link?

If I’ve been working in the same language for at least a year or two, I don’t have to look up any of that. Copilot might be actually helpful if I’m working in a language I’m not used to, but it’s been a long time since I’ve had to look up syntax or functions (excluding 3rd party packages) for the language I work in.

I won’t say copilot is completely useless for code. I will say that it’s near useless for me. The kind of code that it’s good at writing is the kind of code that I can write in my sleep. When I write a for-loop to iterate over an array and print it out (for example), it takes near zero brain power. I’m on autopilot, like driving to work. On the other hand, when I was trialing copilot I’d have to check each suggestion it made to verify that it wasn’t giving me garbage. Verifying copilot’s suggestions takes a lot more brain power than just writing it myself. And the difference in time is minimal. It doesn’t take me much longer to write it myself than it does to validate copilot’s work.

do a full encryption of the storage

That’s not how disk encryption works. Data in storage is always encrypted. That’s the whole point. When an app requests data, it is decrypted on the fly. Decrypted data is never stored outside of RAM.

It’s not clear to me that AMD is in breach of contract, though I admit I haven’t looked into it in detail. But regardless, the contract is irrelevant to the open source thing unless that was in the terms of the contract.

If I steal code and release it with an open source license, that license is not valid. The author released his work open source based on an email from AMD. AMD is now saying that email was not legally binding thus the author did not have the right to release it under and open source license thus that license was not legally valid. If you had forked it and continued to use it, AMD could take you to court and say that the license you are operating under is legally invalid.

if you work in a shared codebase then PLEASE just follow whatever convention they have decided on, for the sake of everyone’s sanity.

That goes without saying; I’m not a barbarian.

“readability” is subjective. much like how there is no objective definition of “clean code”.

Did you not see the part where I said it’s less readable “in my opinion”?

i am insisting that people use a common standard regardless of your opinion on it.

I can read this one of two ways: either you’re making an assertion about what people are currently doing, or you’re telling me/others what to do. In the first case, you’re wrong. I’ve seen many examples of self-closed <br> tags in the open source projects I’ve contributed to and/or read through. In the second case, IDGAF about your opinion. When I contribute to an existing project I’ll do what they do, but if I’m the lead engineer starting a new project I’ll do what I think is the most readable unless the team overwhelmingly opposes me, ‘standards’ be damned, your opinion be damned.

The spec says self-closing is “unnecessary and has no effect of any kind” and “should be used only with caution”. That does not constitute a specification nor a standard - it’s a recommendation. And I don’t find that compelling. I’m not going to be a prima donna. I’m not going to force my opinions on a project I’m contributing to or a team I’m working with, but if I’m the one setting the standards for a project, I’m going to choose the ones that make the most sense to me.

Sorry, I forgot about this. I’ve attached my full configuration at the end. The steps are:

1. If the container is on a server, SSH to it or whatever.
2. Execute docker exec --privileged -it container_name bash.
   • --privileged is required to make delve work. I don’t entirely remember why.
   • -it is something like --interactive and --terminal, it’s what you need to get a proper interactive shell.
   • container_name is the name of your container.
   • bash can also be sh or pwsh or whatever shell your container has (hopefully it has one).
3. Launch delve dlv attach PID --headless --listen=:2345 --accept-multiclient --api-version=2.
   • PID is the ID of the process you want to debug. This should be 1 if you’re debugging the main process of the container.
   • --listen=:2345 says to listen on (TCP) port 2345 on all interfaces (0.0.0.0)
   • The other flags are the one that vscode-go expects.
4. If the container is on a server, forward ports ssh ${USER}@${SERVER} -NL LOCAL:2345:REMOTE:2345.
   • LOCAL is the local IP to listen on, usually localhost. When a process connects to your local IP, it will be forwarded to the remote.
   • REMOTE is the remote IP to connect to, this should be the IP of your container. When a connection is forwarded from your local machine, this is where it is forwarded to. My containers are set up with --net host so I can use localhost as REMOTE but that’s not the default so you may have to use docker inspect to figure out your container’s IP.

I also included the path substitution configs I use. I generally debug these by pausing the target, clicking on something in the stack trace, seeing what path it tries to load, then adjusting the substitute path so that it loads the correct file.

{
  "name": "Attach to a docker container",
  // Get a shell in the container: `docker exec --privileged -it ${NAME} bash`
  // Launch delve:                 `dlv attach 1 --headless --listen=:2345 --accept-multiclient --api-version=2`
  // Forward the port (if remote): `ssh ${USER}@${SERVER} -NL localhost:2345:localhost:2345`
  // Then run this debug config
  "presentation": {
    "group": "99-Miscellaneous",
  },
  "type": "go",
  "request": "attach",
  "mode": "remote",
  "remotePath": "${workspaceFolder}",
  "port": 2345,
  "host": "127.0.0.1",
  "substitutePath": [
    // // Full paths (GitLab Docker build)
    // {
    //   "to": "/go/",
    //   "from": "${env:HOME}/go/", // <-- MODIFY THIS if you're not using the default GOPATH
    // },
    // {
    //   "to": "/root/",
    //   "from": "${workspaceFolder}",
    // },
    // Trimmed paths
    {
      "to": "gitlab.com/accumulatenetwork/accumulate/",
      "from": "${workspaceFolder}/",
    },
    {
      "to": "github.com/AccumulateNetwork/",
      "from": "${env:HOME}/go/pkg/mod/github.com/!accumulate!network/", // <-- MODIFY THIS if you're not using the default GOPATH
    },
    // {
    //   "to": "",
    //   "from": "${env:HOME}/go/pkg/mod/", // <-- MODIFY THIS if you're not using the default GOPATH
    // },
  ],
}

The TL;DR is that you have to exec —privileged and execute dlv attach within the container then tell VSCode to connect. I’ll look up my notes tomorrow and post more details.

Attaching to and debugging a process most certainly does work. I did it yesterday. Your issue is that Go doesn’t have any way of telling the process to pause until a debugger attaches. Which is frustrating but not the same issue.

Specifically for debugging stdin, by far the easiest way to do that (in VSCode) is "console": "integratedTerminal". Another comment links a stack overflow answer that includes other options.

If a spec tells me I should do something that makes my code less readable in my opinion I am going to ignore the spec every time.

AppArmor is part of the kernel. Why does it require patches?

GMT doesn’t have daylight savings but London does

I have no issue with their drivers working with their cards. I have issues using a proprietary, out of tree driver that taints my kernel and forces me to jump through hoops to get it to work whenever I recompile my kernel, which happens maybe once a month when Gentoo’s kernel source package is updated.

Also I use Wayland (because that’s what KDE defaults to).

I was an Apple fan for most of my life. And then Jobs died. The man was a huge asshole by all accounts but he sure knew how to design. Since then Apple has become just another tech giant making average products driven by business majors.

I’m about ready to rehome my RTX 2080 and get an AMD card so I don’t have to deal with Nvidia’s proprietary garbage or the shit-tier open source drivers.