2·
1 month agoYou’re not referring to this satire article by chance?
- 0 Posts
- 29 Comments
Joined 1 year ago
Cake day: January 5th, 2024
You are not logged in. If you use a Fediverse account that is able to follow users, you can follow this user.
3·2 months agoWhat board/connector is affected? At worst, a replacement connector and a soldering iron should be able to replace the damaged connector and get your printer in a functional state.
UPDATE: if you are referring to certain mainboard connectors, it may be best to replace the mainboard if you don’t have the tools for replacement. I see surface-mount connectors for some things on the mainboard that can be difficult to replace correctly without more unique tools.
10·2 months agoGrapheneOS only publishes updates for devices with active security updates. Your device is EOL and therefore won’t receive any further mainline updates. It still will receive extended support from the Android 14 legacy branch with whatever security patches arrive in upstream AOSP, but unlikely to see device-specific patches nor firmware patches. Your device isn’t getting the same care and attention that active devices are receiving nor will it receive any future versions of Android through GrapheneOS.
1·4 months agoFor what it’s worth, I do think OCIS is worthy of switching to if you don’t make use of all of the various apps Nextcloud can do. OCIS can hook into an online office provider, but doesn’t do much more than just the cloud storage as of right now.
That said, the cloud storage and UX performance is night and day between Nextcloud/Owncloud and OCIS. If you’re using a S3 provider as a storage backend, then you only need to ensure backups for the S3 objects and the small metadata volume the OCIS container needs in order to ensure file integrity.
Another thing to note about OCIS: it provides no at-rest encryption module unlike Nextcloud. If that’s important to your use case, either stick with Nextcloud or you will need to figure out how to roll your own.
I know that OCIS does intend to bring more features into the stack eventually (CalDAV, CardDAV, etc.). As it stands currently though, OCIS isn’t a behemoth that Nextcloud/Owncloud are, and the architecture, maintenance is more straightforward overall.
As for open-source: OCIS released and has still remained under Apache 2.0 for its entire lifespan thus far. If you don’t trust Owncloud over the drama that created Nextcloud, then I guess remain wary? Otherwise OCIS looks fine to use.
You use Steam for games on Linux primarily. Independent native games exist as well. Many Windows-only titles will be best run through Proton: Valve’s modified WINE bundle. Other store titles can be configured to run through WINE or Proton via apps like Lutris or Heroic (GOG, Itch.io, Epic Games, etc.).
7·4 months agoI believe it’s mostly drawing tablet support in Qt and in turn porting to Qt6 that’s holding native Wayland builds back.
For the most part, you won’t be able to escape Unix-like paradigms when using Unix-like systems. Notably, users have to exist in some form. You don’t necessarily need to give them passwords for the frontend signage, but they need to exist. The shortlist of setting up cage would be:
- install your favorite server distro of choice
- Have a rootless, sudoless user available to use
- install cage and your app(s) of choice
- Add autologin for the user and edit the user’s BASH profile to autolaunch cage
- Attend to any other backend setup (remote access, only allowing tty1 to exist, etc.)
- reboot
It’s not quite a few clicks, but this can in contrast also be fully automated trivially if it’s something you need to setup more than once.
In what way does Windows fulfill a ‘kiosk’ display mode better than Linux for you? Are you looking for permanent installations or just temporary lockdown to a single application. One of the more modern and straightforward methods currently is using cage.
Cage lets you spawn a Wayland compositor from command-line (or via system service, obviously) that launches either a singular or multiple exclusively-fullscreen applications.
3·4 months agoAn aside to the technical question of how to migrate profiles to older versions:
DO NOT DOWNGRADE FIREFOX BELOW 131.0.2 OR ESR 128.3.1, 115.16.1
I feel that given this recent vulnerability, it is important to make this notice.
Otherwise:
For migrating profiles between the same major version, Mozilla provides a guide for full profile migration. This also works with forwards compatibility. I generally wouldn’t try to go backwards however as many new major versions change the data format and contents of your profiles, which older versions have no idea how to interpret.
For downgrading, it’s best to export bookmarks, go through your important addons and backup the settings for each one that needs configuration, and take note of anything you’re previously modified in about:config to your preference. Perhaps take screenshots of your tab bar and overflow menu as well so you can recustomize them to your liking easily on the downgraded version.
What hardware, audio interface, and sound server is in use for your 5.1 Surround setup?
14·5 months agoA key list of compatible/incompatible components to look for:
- GPU
- Network Interfaces (Ethernet and Wi-Fi)
- Audio Interfaces (not that much of an issue anymore)
- Disks
- Motherboards
- CPU (excluding x86 ecosystem)
- Peripherals
The explanations for this are pretty long, but are meant to be fairly exhaustive in order to catch most if any pitfalls one could possibly encounter.
GPU:
A big one is the choice between AMD, Intel, and NVidia. I am going to leave out Intel for compute as I know little about the state it is in. For desktop and gaming usage, go with AMD or Intel. NVidia is better than it used to be, but still lags behind in proper Wayland support and the lack of in-tree kernel drivers still makes it more cumbersome to install and update on many distros whereas using an AMD or Intel GPU is fairly effortless.
For compute, NVidia is still the optimal choice for Blender, Resolve, and LLM. Though that isn’t to say that modern AMD cards don’t work with these tasks. For Blender and Davinci Resolve, you can get them to use RDNA+ AMD cards through ROCm + HIP, without requiring the proprietary AMD drivers. For resolve especially, there is some serious setup involved, but is made easier through this flatpak for resolve and this flatpak for rocm runtime. ML tasks depend on the software used. For instance, Pytorch has alternate versions that can make use of ROCm instead of CUDA. Tools depending on Pytorch will often have you change the Pytorch source or you may have to manually patch in the ROCm Pytorch for the tool to work correctly on an AMD card.
Additionally, I don’t have performance benchmarks, but I would have to guess all of these tasks aren’t as performant if compared to closely equivalent NVidia hardware currently.
Network Interfaces:
One section of hardware I don’t see brought up much is NICs (including the ones on the motherboard). Not all NICs play as nicely as others. Typically I will recommend getting Ethernet and Wireless network interfaces from Intel and Qualcomm over others like Realtek, Broadcom, Ralink/Mediatek. Many Realtek and Mediatek NICs are hit-or-miss and a majority of Broadcom NICs I have seen are just garbage. I have not tested AMD+Mediatek’s collaboration Wi-Fi cards so I can’t say how well they work.
Bluetooth also generally sits into this category as well. Bluetooth provided by a reputable PCIe/M.2 wireless card is often much more reliable than most of the Realtek, Broadcom, Mediatek USB dongles.
Audio Interfaces:
This one isn’t as much of a problem as it used to be. For a lot of cards that worked but had many quirks using PulseAudio (a wide variety of Realtek on-board chipsets mainly), they tend to work just fine with Pipewire. For external audio interfaces: if it is compliant to spec, it likely works just fine. Avoid those that require proprietary drivers to function.
Disks:
Hard drives and SSDs are mostly fine. I would personally avoid general cheap-quality SSDs and those manufactured by Samsung. A lot of various SATA drives have various issues, though I haven’t seen many new products from reputable companies actually releasing with broken behavior as documented by the kernel. If you wish to take a detailed look of devices the kernel has restricted broken functionality on, here is the list.
Additionally, drives may be one component beside the motherboard where you might actually see firmware updates for the product. Many vendors only release EXE files for Windows to update device firmware, but many nicer vendors actually publish to the LVFS. You can search if a vendor/device is supplied firmware here.
Motherboards:
In particular, motherboards are included mainly because they have audio chipsets and network interfaces soldered and/or socketed to them. Like disks, motherboards may or may not have firmware updates available in LVFS. However, most motherboard manufacturers allow for updating the BIOS via USB stick. Some laptops I have seen only publish EXE files to do so. For most desktop boards however, one should be able to always update the motherboard BIOS fine from a Linux PC.
Some motherboards have quirky Secure Boot behavior that denies them being able to work on a Linux machine. Additionally some boards (mostly on laptops again) have either broken or adjustable power state modes. Those with adjustable allow for switching between Windows and standard-compliant modes.
Besides getting a Framework laptop ‘Chromebook edition’, I don’t think there is much you will find for modern boards supporting coreboot or libreboot.
CPUs:
For your use case, this doesn’t really matter. Pretty much every modern x86 CPU will work fine on Linux. One only has to hunt for device support if you are running on ARM or RiscV. Not every kernel supports every ARM or RiscV CPU or SoC.
Peripherals:
Obviously one of the biggest factors for many new users switching to Linux is their existing peripherals that require proprietary software on Windows missing functionality or not working on Linux. Some peripherals have been reverse engineered to work on Linux (see Piper, ckb-next, OpenRazer, StreamController, OpenRGB).
Some peripherals like printers may just not work on Linux or may even work better than they ever did on Windows. For problematic printers, there is a helpful megalist on ArchWiki.
For any other peripherals, it’s best to just do a quick search to see if anyone else has used it and if problems have occurred.
A couple things to check using a quick bash script:
#!/usr/bin/env bash cd /sys/class/power_supply/BAT*/ echo "Charge cycles: $(cat cycle_count)" printf '%s\0' 'Health: ' & bc <<< "scale=3; ($(cat charge_full) / $(cat charge_full_design)) * 100"That should print out the wear cycles the battery has endured and its reported capacity over design capacity. If your battery has less than 1000 cycles and the health reported from the battery is less than 80%, it might be best to contact Framework for warranty replacement as the battery is likely defective.
Just note that with Bambu printers about past data collection practices and their in general mid to atrocious after-sales support. If this doesn’t deter you, then go ahead and get one.
I do a lot of my functional parts in ABS, ASA though printing such material may be difficult on an open-air machine. The two obvious choices will generally be PLA or PETG. PLA is one of the most common printed materials, and is fairly balanced in material strength. PETG parts are more likely to permanently deform heavily before fully snapping, as well as they have a but more temperature resistance than PLA. Additionally most PETG plastics hold up decently well to UV, often making them more suitable for parts that need to be outdoors.
PLA takes not much consideration on surface to print, as most printers come with a smooth PEI build sheet by default. It will however need more cooling than printing with PETG at equivalent speeds. If you use a PEI sheet for PETG, make sure it is textured. You will destroy a smooth sheet if it doesn’t have some kind of release coating to lower its adhesive properties to PETG.
There is no guarantee for spools of filament to actually arrive dry, so a filament dryer isn’t a bad idea. I don’t have any particular recommendations for a good filament dryer. I have a Filadryer S2 from Sunlu, but am not impressed by it.
For multi-monitor: use Wayland. For 2.5Gbps Ethernet NICs, they never work properly on any system in regard to performance, but I presume you are referencing the subpar Realtek NICs not connecting? Depending on the distro, you likely won’t have the driver and/or firmware package preinstalled to make it work.
Alongside many others, I agree that using QEMU through GUI frontends like virt-manager or GNOME Boxes, or even server-focused solutions like Cockpit+VM plugin or Proxmox layered on top of your installation.
I just want to note a decent point against other solutions like VirtualBox or the VMWare products that work on Linux: these solutions that don’t rely on QEMU almost certainly need the user to install out-of-tree kernel modules (that in some cases may also be proprietary). QEMU and its frontends don’t need out-of-tree modules in a majority of distros and can work out of the box with all features (given BIOS configuration of the host and hardware supports them).
Running the same memory constraints on a 1.18 vanilla instance, most of the stack memory allocation largely comes from ramping the render distance from 12 chunks to 32 chunks. The game only uses ~0.7 GiB memory non-heap at a sane render distance in vanilla whereas ~2.0 GiB at 32 chunks. I did forget the the render distance no longer caps out in vanilla at 16 chunks. Far render distances like 32 chunks will naturally balloon the stack memory size.
For clarification, this is Vanilla, a performance mod Fabric pack, a Fabric content modpack, Forge modpack, etc. that you are launching? If it’s the modpack that you describe needing 8gb of heap memory allocated, I wouldn’t be surprised the java stack memory taking ~2.7 GiB. If it’s plain vanilla, that memory usage does seem excessive.
Depending on version and if modded with content mods, you can easily expect Minecraft to utilize a significant portion memory more than what you give for its heap. Java processes have a statically / dynamically (with bounds) allocated heap from system memory as well as memory used in the stack of the process. Additionally Minecraft might show using more memory in some process monitors due to any external shared libraries being utilized by the application.
My recommendation: don’t allocate more memory to the game than you need to run it without noticeable stutters from garbage collection. If you are running modded Minecraft, one or more mods might be causing stack-related memory leaks (or just being large and complex enough to genuinely require large amounts of memory. We might be able to get a better picture if you shared your launch arguments, game version, total system memory, memory used by the game in the process monitor you are using (and modlist if applicable).
In general, it’s also a good idea to setup and enable ZRAM and disable Swap if in use.
As far as KDE vs. GNOME is concerned: KDE contains a lot of customizable features as an expectation and thus has great support for a wide array of customization. Both KDE and GNOME are extensible, with third-party extensions to extend or change functionality available. What makes GNOME less customizable, albeit supporting stylesheets and extensions, both are not expected to be used in any form (outside of defaults provided via Adwaita), and neither do many independent apps written in GTK3, GTK4. GNOME offers fairly minimal customization options without resorting to GNOME Tweaks, third-party extensions, and unsupported customized themes: all things that can break GNOME as while the customization does exist, the developers don’t embrace it and have no expectation to not break it with any update.