The con is that it’s not very powerful. I haven’t attempted to code on a gaming handheld, but I’ve had issues with a midrange laptop being under powered. RAM is probably the biggest issue. My life improved noticeably when I upgraded my main machine to 64 GB. Granted I was doing particularly heavy work. It really depends on what you’re doing. You could get away with it for some work, but it’s going to be painfully slow for other stuff.

The key difference is that compilers don’t fuck up, outside of the very rare compiler bug. LLMs do fuck up, quite often.

Copilot frequently produces results that need to be fixed. Compilers don’t do that. Anyone who uses copilot to generate code without understanding how that code works is a shit developer. The same is true of anyone who copies from stack overflow/etc without understanding what they’re copying.

I’d create my own macro or function for that. I have enough ADD that I cannot stand boring shit like that and I will almost immediately write a pile of code to avoid having to do boring crap like that, even with copilot.

Using git reset --keep would just make more work since I’ll have to throw away uncommitted changes anyways. Removing uncommitted changes is kind of the whole point, it is called ‘reset’ after all. If I want to preserve uncommitted changes, I’ll either stash them or commit them to a temporary branch. That has the added benefit of adding those changes to the reflog so if I screw up later I’ll be able to recover them.

If you’re using reset with uncommitted changes and you’re not intentionally throwing them away, you’re doing something wrong. git reset —hard means “fuck everything, set the state to X”. I only ever use it when I want to throw away the current state.

I have not and will not ever use AI generated code that I don’t thoroughly understand. If you properly understand the code you’re committing there shouldn’t be any damage. And beyond AI you should never commit code that you don’t properly understand unless it’s a throw away project.

I’ve run into that exact issue with copilot (deleting my tests). It is infuriating.

I don’t think I’d trust it to refactor code for me, not for anything important. I’d need to completely understand both the initial state and the result on a statement-by-statement level to be confident the result wasn’t secretly garbage and at that point I might as well write everything myself.

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.

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

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.