Notably, the do not reverse the course on the selling of user data. This is still a non-starter Mozilla. Do you not realize who your core base is? The only people who still use Firefox are people who value privacy and extensibility in our tools. Still a "no" from me dawg

I have 14 years experience and I've never seen anything like the job market for the last 1.5 to 2 years. In the past, when I was looking for a job, I'd have interviews scheduled within the first few weeks of looking. Nowadays any time I put feelers out I get nothing in response.

How is a large swath of the population okay with things like this? How do they not see such things as embarrassing on the national level? I just don't get it.

Hi there, I think I might have found a typo in your example class in the github README. In the class's `workflow` method, shouldn't we be `await`-ing those steps?

Nice catch. Fixing it :)

Not OP, but prettier doesn't break template literals, but it will break non-literal sections of template strings. For example, if we wrote this:

    const foo = `aaaaaaaaaaaaaaa${bbbbbbbbbbbbb}ccccccccccccccc${ddddddddddd}`;

prettier would fix it to

    const foo = 
      `aaaaaaaaaaaaaaa${
        bbbbbbbbbbbbb
       }ccccccccccccccc${
        ddddddddddd
       }`;

(or something similar) and it would be fully equivalent.

I don't like it doing that either tbh but hey prettier is good enough in most cases its worth putting up with it

I have a PR fixing that specific issue: https://github.com/prettier/prettier/pull/15209

Just needs another maintainer's stamp.

> backed off WEI

for now

> I’m still not exactly sure what the difference between useMemo and useCallback is

    const useCallback = (fn, deps) => useMemo(() => fn, deps);

That's it. That's all it is. `useCallback` is a shorthand for `useMemo`, when you want to memo a function definition.

Example:

    const handleButtonClick = useCallback((event) => {
      event.preventDefault();
      window.alert(`Hello, ${name}!`)
    }, [name])

is just shorthand for

    const handleButtonClick = useMemo(() => (event) => {
      event.preventDefault();
      window.alert(`Hello, ${name}!`)
    }, [name])

correct, but with useCallback you don't take an additional perf hit for redefining the inner function on every render.

useCallback is for callbacks, useMemo is for memoized data.

So basically you want something like how typescript does, where you can do this:

    const config = {
      rootDirectory: "/tmp",
      shouldFrobnicate: false,
    }

I'm far from a python expert, more like a TS dev who occasionally tries to write Python, but when I'm in that situation I find that writing one-off classes seems to be python's way of doing things. I'm not a super big fan of it myself, but it works:

    from dataclasses import dataclass
    
    def _create_config():
      @dataclass(kw_only=True)
      class Config:
        root_directory: str = "/tmp"
        should_frobnicate: bool = False
      return Config()
    config = _create_config()

I experimented with making a decorator that could do something like this, but never got it working with `mypy` so I gave up:

    @iife
    def config():
      @dataclass(kw_only=True)
      class Config:
        root_directory: str = "/tmp"
        should_frobnicate: bool = False
      return Config()

the `@iife` would make it so that `config` was a variable, not a `def`, but yeah the whole thing stank so I gave up

> Some individuals, particularly those running Linux, follow a standard called XDG Base Directory Specification. While Murex does not adhere to this standard, instead conforming to the de facto standard defined by the past precedents of previous shells, in order to offer flexibility for those who do prefer the XDG specification Murex does support overriding its own default paths via special environmental variables.

no no no you're missing the point: on POSIX systems, go with XDG by default. cmon guys it's 2023 not 2003

Murex doesn't just target POSIX systems and XDG added a lot of edge case problems I wasn't prepared to deal with at the time. Particularly so back when the shell was first created. So I went with the de facto shell standard instead.

You can override that behaviour if you want to use XDG but making it the default could break backwards compatibility, result in confusing documentation for non-POSIX users and introduce a lot of additional development and testing just to fix something that already works fine.

Like with any open source project, if someone else is willing to commit some time into solving these concerns then I'll gladly merge it. But I need to be pragmatic with how I prioritise my development time.

Anyone have any experience running Windows and WSL2 with Podman Desktop? I'm running W11, with fedora in WSL2. What I've been doing with Docker Desktop is running Docker Desktop on Windows startup, and that gives me access to the docker machine in both powershell and inside my wsl2 environment (for the latter, docker-desktop installs a binary inside fedora-wsl2 at `/usr/local/bin/docker` that communicates to the host)

So far, I uninstalled Docker-Desktop and installed Podman-Desktop, and now I can run `podman` from powershell but not from fedora. I'm about to try `sudo dnf install podman` and hope it connects to the podman-machine? I dunno, it's not exactly clear

> now I can run `podman` from powershell but not from fedora. I'm about to try `sudo dnf install podman` and hope it connects to the podman-machine? I dunno, it's not exactly clear

One thing you could do is just symlink or wrap the Windows podman.exe as `podman` on your WSL guests, and rely on WSL interop at the CLI instead of sharing a socket. This is probably what Docker Desktop does, based on your description (I thought it (used to?) share(s) a socket from the dedicated WSL guest it creates to your other WSL guests).

Alternatively, if you install Podman Desktop via Scoop and have WSL interop enabled for your guests (so that your Windows binaries appear on your Linux guests' PATHs), I think you'll get the same `podman` as your Windows PowerShell sessions access onto your WSL guests for free.

Docker Desktop:

1. In the past, created a managed WSL vm to run containers.

2. At some point, it included the option to use a WSL distro instead, but you had to tell it explicitly.

3. Nowadays it detects whether a default WSL distro is present and uses it to run containers automatically. Otherwise it creates a managed WSL distro just to run containers.

As far as I understand, Podman Desktop still is at (1). You can't tell it to use your own WSL distro.

> I'm about to try `sudo dnf install podman` and hope it connects to the podman-machine? I dunno, it's not exactly clear

I think podman-machine is meant to be executed on the host, but worth a try anyway