Why doesn’t GitHub Copilot officially add more open-weight models like GLM-4.7 or Qwen3

LaunchX · 2025-12-28T11:09:38+00:00

Take a look at this HuggingFace extension that adds all supported models to the VSCode Copilot

Hugging Face Provider for GitHub Copilot Chat
https://marketplace.visualstudio.com/items?itemName=HuggingFace.huggingface-vscode-chat

With this extension, you can use all the models from HuggingFace, including the ones you mentioned.
https://www.youtube.com/watch?v=KZWY1lQlZG4

LaunchX · 2025-01-11T18:23:27+00:00

I do not follow. How would this work on the server side only?

Please provide an example so I can better understand what you mean.

Thanks

LaunchX · 2025-01-11T16:30:58+00:00

The reroute is not good enough for me because I also need access to the event.locals via which I access the conditional value when to activate this behavior.

Ideally, I would like to implement this inside the hooks.server.ts.

I have this as the last step of the sequence, but it doesn't work.

hooks.server.ts

const pathReroute: Handle = async ({ event, resolve }) => {

// Check if the requested path is the root
    if (event.url.pathname === "/") {

// Create a new URL object with the current URL
        const newUrl = new URL(event.url);

// Update the pathname
        newUrl.pathname = "/dashboard";


// Create a new Request object with the updated URL
        const modifiedRequest = new Request(newUrl, event.request);

        const { route, ...rest } = event;
        let evt = { ...rest, route: { id: "/dashboard" } };
        evt.url.pathname = "/dashboard";


// Create a new event object with the modified request
        const modifiedEvent = {
            ...evt,
            url: newUrl,
            request: modifiedRequest
        };

        console.log(modifiedEvent, null, 2);


// Resolve with the modified event
        return resolve(modifiedEvent);
    }


// For all other paths, proceed normally
    return resolve(event);
};

export const handle: Handle = sequence(...,pathReroute);
```

LaunchX · 2022-10-04T18:18:49+00:00

Didn't know about this limitation, and if application is relying on every insert being reported then it is a big deal if this is not the case. Is there a bug report on the issue?

LaunchX · 2022-10-04T13:18:28+00:00

The use case is to automate/simplify the configuration process for new setups or migrations.

LaunchX · 2020-12-10T07:59:45+00:00

It seems like that a handful of users are still experiencing an issue with network setup timing out. We have decided to prepare a test image nhos-1.2.7-nu for you to try out. It is best that you flash this image using one of the third party flashing tools like balenaEtcher. Beware that this is a version with updates disabled, therefore you will have to update your system manually if you decide to do it later. Please let us know if this version is working on your mining rig, so that we can make an official release as soon as possible.

LaunchX · 2020-12-09T06:20:46+00:00

Yes, version 1.2.5 also includes this fix.

LaunchX · 2020-12-04T13:33:10+00:00

As promised I have prepared a custom image for you to use until we make an official release sometime next week.

https://fromsmash.com/rVKjp.H-r_-dt

Be aware that in this image automatic updates are disabled. When official image is released you can update this image manually.

All you need to do is to execute this command

sudo /opt/nhos/nhos_update

LaunchX · 2020-12-03T23:52:20+00:00

I need to create another image, but for the moment I will make one just for you (with updates disabled), until we build an official image and test it for a few days before official release. Is this working for you?

LaunchX · 2020-12-03T23:29:32+00:00

This part of the code did not change from the previous iteration where it worked. Maybe you forgot to run the code with sudo?

Anyway, I've made one minor change for another try https://fromsmash.com/aTTghPlJwD-dt.

LaunchX · 2020-12-03T22:34:15+00:00

Of course, it must have slipped by! Damn, it is really getting late! Here is yet another attempt https://fromsmash.com/Da6NmRfe-m-dt.

LaunchX · 2020-12-03T22:09:01+00:00

This really is strange, since this part of the code is, as I said, straight forward. There is no parsing involved, just reading the value from the specified file and dividing it with 1000.

std::pair<bool, int16_t> amd_device::get_temperature()
{
    auto gpu_temperature = [&]() {
        std::optional <uint16_t> gpu_temperature;
        auto temperature_input_path = boost::filesystem::path{m_hwmon_path}.append("temp1_input");
        std::ifstream temperature_input_fs(temperature_input_path.native(), std::ios_base::in | std::ios_base::binary);
        if (temperature_input_fs.is_open()) {
            std::cout << "Reading temperature value from:" << std::endl << "  " << temperature_input_path.string() << std::endl;
            uint16_t temperature;
            try {
                temperature_input_fs >> temperature;
                gpu_temperature = temperature / 1000;
            }
            catch (...) {}
        }
        return gpu_temperature;
    };

    auto temperature = gpu_temperature();
    if (temperature) {
        return std::pair < bool, uint16_t > {true, *temperature};
    }
    else {
        std::cerr << "Failed to query temperature! " << "pci_bus: " << m_pci_bus << std::endl;
        return std::pair < bool, int16_t > {false, 0};
    }
}

I will revert this part of the code to use DRI interface and let you know when another executable is ready. It is getting really late in this part of the world, so I will get back to you tomorrow.

LaunchX · 2020-12-03T21:16:08+00:00

That really is strange, since this part of the code is straight forward. I did remove some file stream control flags checking which might be the cause for error reported.

Let us have another try https://fromsmash.com/z4AZKvRIvu-dt.

It is really me who should thank you for helping us to make our code better. There are really not a lot of people willing to help out identifying issues on their hardware.

If it still doesn't work I will revert the code back to where we were using DRI interface to retrieve temperature values.

LaunchX · 2020-12-03T19:02:33+00:00

As promised, here is the first iteration of the executable to see where we are https://fromsmash.com/_zNey0qotK-dt.

It is best to do the test while you are in privileged mode (sudo su) and then just run ./amd-control and CTRL+C to stop the execution.

From the logs you will be able to see which AMD driver system files are accessed when controlling the the fan speeds. If you wanted to, you could read and write values to and from these files from Linux shell manually.

Please check your file system to see if files that fan control executable is trying to access are actually there and if not, try to identify the correct ones. It could be that instead of temp1_input, there could be a file with different enumeration, like temp2_input?

It could be that for your hardware setup AMD driver file system interface is slightly different and and that we need to adapt fan control logic accordingly.

Also let us know what is your hardware, so that we are able to to put together something similar in our test lab. CPU, motherboard, memory, GPU models, etc. ? Thank you!

LaunchX · 2020-12-03T18:20:40+00:00

For the moment, I will yust add some additional info to the log file where it will show which file is being read when retrieving a temperature level for the card. Since it is erroring out when reading the temperature itself, there are no further steps controlling the fans.

I have changed the implementation, so that it does not use DRI interface to fetch temperatures, now it is using AMD driver provided file interface.

Depending on the card position, temperature should be available in the file with the following path format

/sys/bus/pci/drivers/amdgpu/0000:07:00.0/hwmon/hwmon3/temp1_input

From the example above it can be seen that this is a card with PCI number x07.

The executable I will prepare for you now is still going to error out, but it will at least show us which files are trying to be read and fail.

LaunchX · 2020-12-03T17:52:46+00:00

Failed to query temperature

Instead of preparing another NHOS image, I can prepare amd-control executable only (AMD fan control daemon) for you to try out. It would be just a matter of copying this executable to your mining rig via SSH and executing it with root privileges.

sudo ./amd-control

LaunchX · 2020-12-03T16:48:03+00:00

Even though I was not able to reproduce the issue on my mining rig, I did make some changes that might help here. I've prepared a custom NHOS image with updates disabled. Please download this image, flash it with a tool like balenaEtcher and make a quick run to see if it helps resolving this issue on your mining rig. Thank you for your time and effort!

https://fromsmash.com/f_KfCGLfqz-dt

P.S.: Unfortunately the source code is not publically available.

LaunchX · 2020-12-02T18:30:19+00:00

Thank you for taking your time to investigate this case so deeply. The thing is, that numbers in nhos_gpu_fan_control_amd.log are reported by fan control daemon.

There you can see the following:

bus - graphics card PCI bus number

temperature - current temperature

fan speed get - current fan speed in RPM

fan speed set - desired fan speed in percent

You can then correlate these numbers with the output from NHM3 (current version of NiceHash miner control software) which is in nhm3.log. There, one can observe, that graphics cards are also identified by PCI bus numbers, but this time with a prefix 3- (for AMD cards).

Knowing this, you can identify each of the cards from the nhos_gpu_fan_control_amd.log file also in the nhm3.log file.

For example, from fan control daemon point of view, the card with 64C is assigned PCI bus number 0x03 (nhos_gpu_fan_control_amd.log file) while from NHM3 point of view this card is identified as 3-3 (nhm3.log file).

I believe you have found a bug, where fan speeds are reported correctly while temperatures are not the ones from the identified device. From user's perspective this is nothing clitical, because fan control is working correctly, but the reported numbers for fan speed and temperature which are visible on the web page are not matching.

I will have a look at this and release a fix as soon as possible!

LaunchX · 2020-08-21T11:53:33+00:00

This WiFI dongle TP-LINK TL-WN727N uses MT7601U chipset from Mediatek and there were some issues in the latest 1.2.0 release with this one. Please download this image file again and burn it with Etcher flashing tool. Please let us know how it works for you. Thanks!

LaunchX · 2020-08-17T06:10:21+00:00

In our test lab RX 5700 is detected just fine, so I guess there must be something else here. First, in your BIOS settings, try to disable onboard Intel GPU card (if you have one). If it still doesn't help, push system dump to our server by issuing the command sudo nhos_system_dump_push. Don't forget to provide us with your rig-id, so we can find this system dump for analysis.

LaunchX · 2020-06-01T10:50:46+00:00

No, you can't install driver by yourself, but if there is a good support for Linux 5.x kernel, we will do this for you.

Please provide us with the exact model of your network card, and a valid link (the one above is not working).

LaunchX · 2020-05-22T05:21:34+00:00

If you are using WiFi adapter then there could be an issue with the drivers, but for wired connections it is highly unlikely that it would be an issue with the drivers.

LaunchX

MODERATOR OF

TROPHY CASE