Obscurity is not real security

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?

GitLab, Inc is a business and it’s not run by idiots. If federation was going to make them a bunch of money, they’d put a team on it. Relying on an outside group to execute your business goals is terrible management. It’s clear federation is not one of their business goals.

They may advertise it, but they’d be working on it themselves if they thought it would bring in serious revenue.

GMT doesn’t have daylight savings but London does

IMO that list is the obvious answer to “which packages can’t be removed without breaking the system”. Sufficiently obvious that I consider your insistence on specific “requirements” to be obnoxious. Though for that specific phrasing I would not include the terminal emulator or file browser. Using a system without them would be annoying but entirely doable.

You seem to be implying that applications could be considered basic functions. I can understand that perspective, but an application such as a music player or browser is certainly not a basic function of the OS, and I think it’s a stretch to call those a basic function of the desktop environment. Maybe a better word is ‘essential’. User applications are not essential to the OS, and the only applications I consider essential to the desktop environment are a terminal and a file browser, though the last one is negotiable. Of course things like the system setting app (or whatever GNOME calls it) are essential, but that’s a component of the desktop environment and not a user application. So my list is:

• The kernel
• The init system
• Essential system components and services such as dbus and pipewire without which the OS and/or desktop environment will be degraded or not function.
• A terminal emulator app
• A file manager app

The obvious answer is packages that aren’t essential for basic functions of the OS/desktop environment.

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.

Two cocktails will get me tipsy, two beers if they’re strong, but I can drink an entire bottle of vodka (over the course of 2-3 hours) without blacking out. Or at least I could in college, I’m not looking to try again.

That’s an artifact of JavaScript, not JSON. The JSON spec states that numbers are a sequence of digits with up to one decimal point. Implementations are not obligated to decode numbers as floating point. Go will happily decode into a 64-bit int, or into an arbitrary precision number.

I’m interpreting that as clickbait - just something they added to the title to drive traffic.

hackthebox is essentially a puzzle solving platform where the puzzles are designed to teach you hacking. You’re not supposed to hack the platform.