Not strictly related, but since Copilot could be the next to violate the TOS, I've asked for an official response here: https://github.com/orgs/community/discussions/183809. If someone can help raise this question, it's more than welcome.

Copilot in VSCode is integrated with VSCode's LLM provider API. Which means that any plugins that needs LLM capabilities can submit request to Copilot. Roo Code support that as an option. And of course, there's a plugin that start an OpenAI/Anthropic-compatible web server inside VSCode that just calls to the LLM provider API. It seems that if you use unlimited models (like GPT-4.1) you probably get unlimited API calls. However, those model doesn't seems to be very agentic when used in Claude Code.

GitHub doesn't offer any unlimited style AI model plans so I don't think they'll care. Their pricing is fairly aligned with their costs.

This only affects Claude as they try to market their plan as unlimited with various usage rate limits but its clearly costing them a lot more than what they sell it for.

Copilot plan limits are however "per prompt", and prompts that ask the agent to do a lot of stuff with a large context are obviously going to be more expensive to run than prompts that don't.

MacOS has for me the best basic keybindings even thanks to the keyboard hardware design and the fn button placed on the left side, which is the right one, as it opens the door to have home/end/pgup/pgdown with fn + arrows, and high ie perfect for 65% keyboards, I’ll never understood why pc keyboard and mech ones have the fn on the right side, totally useless.

Another thing MacOS did it right, cmd+c/v for copy/paste. Anyway, I talked about this here: https://www.paolomainardi.com/posts/linux-remapping-keys-wit... and how to remap with Xremap.

Is there a real alternative, where is not not needed Windows in any way, to the Remote Device Management baked into firmware as Apple does with its hardware ? This is biggest missing to bring Linux to enterprises.

> the Remote Device Management baked into firmware as Apple does with its hardware?

What do you mean? Linux had SSH (and before that rlogin) for a very long time already.

Apple devices support MDM. When you purchase the device, the device's firmware is configured to check in with an account owner. The firmware has an integrity feature such that this configuration cannot be removed by a user: https://it-training.apple.com/tutorials/deployment/dm005/

If OP just meant remote management through a BMC then that's not common except for server hardware, and it would have features like Redfish to configure the hardware itself. Apple devices don't have this.

You can also buy hardware to act as a remote keyboard/mouse/monitor and power button, and it supports systems whose motherboards have the right headers: https://pikvm.org/

I don't think it's fair to describe MDM as a firmware-level feature. I think it's entirely implemented and enforced within the environment of a booted macOS; the firmware isn't going to be bringing up a whole network stack to phone home.

If you had Linux on a MDM-enrolled Mac there wouldn't be anything MDM-related running during or after the boot process. But presumably any sane MDM config would prevent the end user from accessing the settings necessary to relax boot security to get Linux installed in the first place.

Yeah, your point about implementation is correct -- much of the MDM functionality runs within macOS.

But, eh, I still think it's fair to describe it as a feature of the firmware. The enrollment and prevention of removal have firmware-level components through Apple's Secure Boot and System Integrity Protection. A user can't simply disable MDM because these firmware-level protections prevent tampering with the enrollment.

Case in point, getting Linux installed in the first place would be blocked by firmware-level boot policies, right? I'm not too knowledge about this, and maybe you are more so.

I think it's important to make a distinction between secure boot features that are local-only, and remote management features. The "Remote Device Management baked into firmware" claim above carries with it some pretty important implications that are, as far as I can tell, not actually true.

It's not too different from scaremongering about Intel ME/AMT which is often maligned even in the context of computers that don't have the necessary Intel NICs for the remote management features.

I agree with your point about OP's statement regarding "where is not not needed Windows in any way, to the Remote Device Management baked into firmware as Apple does with its hardware" I also read that to mean that the firmware solution is self-contained and complete, even though that's pretty misaligned when you consider the meaning of a "remotely" managed device (remotely managed by what?).

But it's still entirely factual in my own description. When a device checks in during initial setup, the firmware-level boot process can receive policies that block alternative OS installation, and that absolutely is a feature of the firmware.

Anyway, I tried to interpret OP's meaning, and provided more detail on how Apple's firmware is special.

Do you think ssh is an equivalent to remote device management? Half the reason Chromebook does well is because it's really good at remote device management.

"Device Management" means "hardware-level backdoor."

Only if it's your hardware. If it's corporate hardware, it's their hardware and you're a guest.

In this post, I explain how to customize key remapping on Linux using xremap, a powerful tool that works with X11 and Wayland. I walk you through the installation and configuration process, showing how to remap keys like `Home`, `End`, and `PgUp` to create a consistent, personalized keyboard setup across different devices.

I miss how the VM are managed, UTM or something else ?

The article discusses the current landscape of open-source generative AI tools for developers, highlighting the rapid growth and adoption of these technologies. It emphasizes the importance of collaboration in open-source communities to drive innovation and overcome challenges related to ethics, security, and scalability. The article also points out the critical role that open-source AI plays in democratizing access to advanced AI capabilities for developers across the globe.

I am wondering if reinstalling the entire Archlinux installation would be a wise choice.

Arch Linux uses a native/unpatched version of OpenSSH without dependency on libsystemd and thus without dependency on xz-utils, resulting in no exploitable code path. This means that at least the currently talked about vulnerability/exploit via SSH did presumably not work on Arch. Disclaimer: This is my understanding of the currently circulating facts. Additional fallout might be possible, as the reverse engineering of the backdoor is ongoing.

This is only correct if the sshd backdoor is the only malicious code introduced into the library.

there are other ways for liblzma to get into ssh (via PAM and libselinux)

Just to extend the sibling comment with an excerpt of the Arch announce mail regarding the backdoor:

  >From the upstream report [1]:
  
  > openssh does not directly use liblzma. However debian and several other
  distributions patch openssh to support systemd notification, and libsystemd
  does depend on lzma.
  
  Arch does not directly link openssh to liblzma, and thus this attack vector is not possible. You can confirm this by issuing the following command:
   
   ```
   ldd "$(command -v sshd)"
   ```
   
  However, out of an abundance of caution, we advise users to remove the malicious code from their system by upgrading either way. This is because other yet-to-be discovered methods to exploit the backdoor could exist.

A streamlined guide to setup your workspaces to work smoothly on shared features for multiple Angular projects, using Angular libraries and npm-link.

This is a very interesting point, the vulnerability scan tool used on the article is this one: https://github.com/anchore/grype-db/blob/main/DEVELOPING.md and here you can see how it works: https://anchore.com/blog/build-your-own-grype-database As you can see there is a database specifically designed for Debian to take in charge the naming convention.

Thanks: it's not trivially clear how I could try it out to check if it works well: it seems to use Debian security tracker to note which CVEs have been fixed, so version numbering scheme should not come into play.

I'll try to find some time later to play with it in depth as it seems to be an interesting set of tools!

This post discusses the issue of managing software dependencies and the potential risks associated with relying on large amounts of code that may be vulnerable or malicious. The author analyzes the number of packages and vulnerabilities in different languages and frameworks, including NextJS, Django, and PyTorch, and provides practical tasks to manage dependencies, such as automating dependencies management and scanning for known vulnerabilities.