Parent comment is wrong. The default UX used in Ubuntu may actually be confusing for newbies, as it’s quite different compared to Windows. Just check some screenshots or videos and you can see for yourself. I’d instead recommend going for a distro which uses a more familiar UX (ie the Desktop Environment).
Perhaps a distro which uses KDE, XFCE, Cinnamon, MATE or LXQt by default (these are “desktop environments” (DE) - which is a collection of the desktop shell components (eg start menu, taskbar, dock etc) plus default applications that go with it eg the file manager, document viewer etc). A desktop environment like the ones I mentioned above, in their default settings, should be familiar to most Windows users. Now whilst you can install any DE on any distro, it can be a daunting task for newbies, plus, the settings might not be optimal for you. So it’s better to go with a distro that comes with such easy-to-use DEs by default. Examples of such distros include Linux Mint and Zorin. These, by default, should look quite familiar to you, and should be even more easier to use than Ubuntu.
Both Mint and Zorin are based on Ubuntu, so most of the documentation for Ubuntu should be relevant to Mint and Zorin as well. But if you’re not sure, just include quotes for your distro when you’re doing a web search, eg how do I do this in Linux “Mint” will ensure you’ll only get results with “Mint” in the page.
Are you sure about that? Most countries around the world have a Linux user group of some sort. Find out what your local group is called, get in touch and I’m sure you’ll be able to find someone who’ll be more than happy to help.
This was already fixed in 6.1.66. Both are “old” kernels, so it’s nothing to worry about, unless you/your distro was deliberately staying on 6.1 for some odd reason (yes, I’m aware 6.1 is LTS, but so is 6.6).
Not quite. Bcachefs can be used on any drive, but it shines the best when you have a fast + slow drive in your PC (eg NVMe + HDD), so the faster drive can be used as a cache drive to store frequently accessed data.
A GPU is used for a lot more than just gaming these days. It’s used to render videos, accelerate normal 2D programs (like some terminal emulators), accelerate some websites/webapps (those which use WebGL for eg); also modern DEs like Gnome and KDE also make use of it very heavily, for instance for animations and window transitions. Those smooth animations that you see when you activate the workspace switcher or window overview? That’s your GPU at work there. Are your animations jittery/laggy? That means your setup is less than ideal. Of course, you could ignore all that and just go for a simple DE like XFCE or Mate which is fully CPU-driven, but then the issue of video acceleration still remains (unless you don’t plan on watching HD videos).
Without the right drivers (typically NOT nouveau, unless you’re on a very old card), you may find your overall experience less than ideal. As you can see in their official feature matrix , only the NV40 series card fully supports video acceleration - these are cards which were launched between 2004-2006 - that’s practically ancient in computer terms and I highly doubt your PC uses one of those. Now recent-ish cards do support video acceleration, but you’ll need to extract the firmware blobs from the proprietary drivers (which can be a PITA on normal Debian as it’s a manual process), plus, even after that, the drivers won’t support some features that may be required by normal programs, as you can see from the matrix.
The natural solution of course would be to install the proprietary nVidia drivers, but you do NOT want to do that (unless you’re a desperate gamer) as there’s a high possibility of running into issues like not being about to use Wayland properly, or breaking your system when you update it - just Google “Linux update black screen nVidia” and you’ll see what I mean.
You’ll be avoiding a lot of headache if you just went with AMD; or even just onboard graphics like Intel iGPUs (if your CPU has it) would be a much better option - because in either case, you’ll be using fully capable and stable opensource drivers and you won’t face any issues with that.
None of the comments here explain how WINE works, so allow me to elaborate a bit.
WINE is like a translator or a compatibility layer. When a Windows program tries to perform a function that would normally require Windows, WINE steps in and translates that request into something the Linux system can understand and process.
As you may know, Windows programs work by making API calls (eg using Win32 APIs) to operate and perform basic tasks. WINE takes these API calls and translates them to their Linux equivalents (POSIX calls, to be specific, which means Wine can run on several Unix-like systems). This way, when a program asks to say, open a file, or display something on the screen, WINE converts these requests into a form that Linux can execute.
WINE’s approach is about providing compatibility for user-level applications rather than replicating the internal workings of the Windows kernel. It includes various libraries and components that mimic the behavior of those in Windows. This helps in executing the Windows applications as if they are running in their native environment.
The core of it is NTDLL. NTDLL.dll is a core Windows library that provides low-level system functions to interact with the Windows NT kernel. In WINE, ntdll.dll is adapted to work with the Linux kernel instead.
Then you have the Win32 API libraries, providing the basic APIs that Windows applications use for functions like window management, text rendering, and system calls. Examples include user32.dll (for user-interface functions), gdi32.dll (for graphics device interface functions), and kernel32.dll (for basic system functions).
Shell32.dll for handling Windows Shell API functions related to file operations and the user interface.
DirectX Support, for running games and multimedia applications. WINE implements parts of DirectX, like Direct3D for 3D graphics, DirectDraw for 2D graphics, and DirectSound for sound processing. Note that WINE’s implementation converse Direct3D calls to OpenGL, whereas there are community projects like DXVK and VKD3D which translates these calls to Vulkan.
Finally there’s a Registry Implementation, so that applications that need to read or write to the registry can function correctly.
Of course, there’s a LOT more to it, the above is just an example of some key components. Basically Wine has reimplemented (coded from scratch) various libraries and executables that, on the outside, look like standard Windows dlls/exes, but internally they use POSIX APIs to talk to the Linux kernel and other POSIX components. This, along with the Syscall translations, bridges the gap between Windows programs and Linux.
Now naturally, this is neither a perfect, nor a complete implementation of Windows APIs; plus there are some things which Wine will never implement (such as ntoskrnl.exe), so not every program will work as expected - so check out the Wine AppDB for compatibility reports with various Windows apps.
Well it’s Black Friday and HDDs are going for cheap. 6TB is nothing these days, when you could get a 16TB external drive for only $200, or a internal SATA one for $185. Or you could replace/supplement your entire NAS with a single 6TB drive for only $50.
Disk space is cheap now, so upgrade your storage, convert your music to FLAC, problem solved.
Foreground targets are where writes initially go. Data is moved from foreground to background targets while idle or as needed. Data which is read from the background targets is moved to promote targets.
If you set your NVMe as a promote target, SSD as foreground and your HDDs as background targets, all writes would first go to your SSD, then get copied to your HDD during idle, and finally the copy of the data on your SSD will then be marked as a cached copy. In case your SSD becomes full, then it’ll store the data on other drives. As for the promote targets, any time you read data from either the SSD or HDD that wasn’t on the NVMe, it would get cached to it, so the next read will be faster.
The main point of the foreground vs promote is to prioritize write vs read speeds. If you value faster writes, then set your NVMe as foreground. If you value faster reads, then set your NVMe as promote. Of course, you can also set your NVMe as both foreground and promote to benefit from both faster reads and writes.
But since you plan to introduce an SSD in the mix, you can create a single group for your NVMe + SSD, and a second group for the HDDs, and set your SSD group to foreground + promote, which will simplify things.
If you’re concerned about chucking both the SSD and NVMe in the same group, no need to worry cause bcachefs will automatically prioritize reads from drives with lower latency as mentioned in the wiki.
If they are different speeds, reads for replicated data will be sent to the ones with the lowest IO latency.
But regardless of which setup you go for, main thing to remember is to use the NVMe (or the group containing the NVMe) as the promote target, as that will be your primary cache drive.
Yes, I do provide a password on boot, as you said, keys can be extracted from the hardware so that’s not secure, which is why I don’t use the TPM to store the keys.
There are no hooks necessary in the bootloader, as it’s the BIOS which prompts you for the password and unlocks the drive.
And yes, there have been implementation problems in the past, but that’s why the Opal 2.0 standard exists - don’t just buy any random self-encrypting drive, do your research on past vulnerabilities for that manufacturer, and check if there are any firmware updates for the drive (don’t just rely on LVFS).
Also, the common hardware attacks rely on either a SATA interface (to unplug the drive while it still has power) or older external ports vulnerable to DMA attacks such as PCMCIA or Thunderbolt 3.x or below; so those attacks only affects older laptops. Of course, someone could theoretically install a hardware keylogger or something, but this is also why you have chassis intrusion detection, and why you should secure and check any external ports and peripherals connected to your machine. Overall physical security is just as important these days.
But ultimately, as always, it comes down to your personal threat model and inconvenience tolerance levels. In my case, I think the measures I’ve taken are reasonably secure, but mostly, I’ve chosen Opal for performance and convenience reasons.
Yeah, unfortunately it looks like the reader on the X1 is a special case. Thankfully, this isn’t an issue with my Z13 - the reader itself worked out-of-the-box, just had to enroll my fingerprint from the Settings menu and then added fprintd to my pam.d rules.
No headphone jack, no buy. It’s not a question of whether a headphone jack is useful to you, it’s just the principle of it - there’s no good reason to remove it (especially for the asking price of FP5), and more importantly, it goes against what the Fairphone stands for, IMO. I can understand if it were some other profit-driven company making a shrewd business decision, but for Fairphone to do it, seems very unfair to me.