I 100% agree! Am a pretty new user of Nobara as a daily driver, switched like a month ago (I did have extensive CLI experience with Linux servers, along with Kali VM for work), and I’ve only realized what DE actually is only a week ago, because no one mentioned how important choice it is - it was usually just a note, that wasn’t given enough importance.
So please, if you’re ever recommending any linux distro to somenone who’s asking, please include a short paragraph about what DE is and how importnant choice it actually is, and that they should not ignore it. I hated Gnome, and KDE feels so much better (only found about it when reinstalling broken first Fedora install to Nobara), but I didn’t know I can switch or that there was that choice in the first place - I though KDE vs Gome is a back-end thing, similar to X11 vs Wayland. It’s not, but people don’t usually explain it when recommending distributions.
Yeah, you can run them with some heavy modding. I’ve done it with Photoshop 2021 and Premiere 2021. Takes a lot of work and debugging, but it’s doable.
Probably an idea as old as time but wouldn’t it work to stream adobe products from a terminal server?
Let me elaborate: two major fronts I’ve seen are “I type data and write emails” types that can easily work on the terminal and “I make heave graphics and video editing and cant work without 4090 gpu” which we usually just leave to it.
Obviously there are more nuances but most should be doable in terminal unless no internet or very bad internet. I’m somewhat hopeful this would work. Everyone has a very efficient linux pc/laptop and the heavy lifting is done by windows vms with adobe suite running on shared A100s. And while they are not used they could be rented out for extra cost efficiency.
I use substance painter and I need it to work. I don’t want to spend hours messing around trying to make it work and jumping through hoops.
Wine for DCC is great if you enjoy tinkering with pipelines rather than using them, but impractical for people who are trying to reliably get work done.
I’ve heard great things about system76, never had one of their laptops myself but still have the desktop I got in 2011 (Wild Dog Pro). I personally use the frame.work 13, and it has been working great with Arch installed. I do not recommend Arch, use something like PopOS, or LinuxMint.
2 type c’s and 2 type A USB are in it 99% of the time. I have the HDMI, and display port modules but have rarely used them. I also keep the 2.5Gb Ethernet for when I break the WiFi to get back into the router, and a microsd for when I reflash my raspberry pi’s .
Other than they fit nicely into a pocket in my backpack…no. The main reason I love their product is the reparability aspect, allowing me to swap ports is just a neat feature.
I guess that makes sense, I can still just put the dongle I already have for edge cases like plugging into a DisplayPort monitor, needing Ethernet, etc. Also I didn’t realize until someone else commented that they have extra storage ones, that would probably be one for me
Oh man that’s the same as me! I’ve been having all sorts of issues with reliability with mine so I was curious if it was different generations. I guess I’m unlucky?
I was typing up a reply and realized this said most of what I was saying. The only thing I’d add is that support matters, popularity matters. Supported or popular HW platforms are less likely to have small random niggles than an off the shelf dell laptop. System 76 or tuxedo lines are ideal supported platforms. Think pads area super popular.
PopOS or Mint are as easy to use as ubuntu, but without being chained to snaps, which everyone is moving towards flatpaks except canonical
Ah yes, simplicity. MBR, with all its limitations had one killer feature: it was extremely simple.
UEFI, as powerful as it is, is the opposite of simple. Many moving parts, so many potential failure points. Unfortunately, it seems like modern software is just that: more complex and prone to failure.
True, but… When MBR Grub drops to rescue or doesn’t appear at all, it’s not only difficult (at least for newbies) but somewhat random if you can actually boot a given OS. With EFI Grub, I’ve often managed to boot using BIOS boot override to launch a usable Grub configuration.
Actually grub 0.x series had much more useful rescue shell tab completion than the latest release. You could easily list all boot devices, partitions, and even filesystems and their contents. All from the rescue shell. Consequently, you could boot into Linux and reinstall grub in the MBR to fix it. All that without using a boot CD/USB! Good luck doing that with the latest version of grub and UEFI.
Also getting into the BIOS on legacy firmware was also very simple. On most machines it’s the three finger salute followed by either F1, Delete or rarely F11 or F12.
The boot process was simple, and the BIOS had just one simple task: load and execute the first 512 bytes of the disk that was designated as the boot device. That’s it.
Asus --> Del - Enter BIOS, F8 - Boot menu (very confusing since Windows also uses F8 for the recovery mode boot menu, so you have to press F8, then when the boot menu appears, chose the boot device, then have one hand on Enter and the other on F8 again, so that you hit Enter and start tapping like crazy on F8 to enter the rescue mode menu… annoying as hell)
GigaByte --> Del or F2 - Enter BIOS, F12 - Boot menu, Alt + F10 - Copy main BIOS to backup BIOS
MSI --> Del or F2 - Enter BIOS, F11 - Boot menu
ASRock --> Del or F2 - Enter BIOS, F11 or F10 - Boot menu
Biostar --> Del - Enter BIOS, F9 - Boot menu
Intel --> F2 - Enter BIOS, F10 or F12 - Boot menu
I used to remember some of the brand name PCs as well, but time has gotten the best of me 🤷.
The boot process was simple, and the BIOS had just one simple task: load and execute the first 512 bytes of the disk that was designated as the boot device. That’s it.
This is actually what I love about MBR nowadays. It’s simple enough so no one wants to mess with it and render the rig unbootable and obscure enough so no one (MS) actually checks if there is anything there that might trigger warnings (non-MS code).
Great, you can accomplish the bare essentials with Linux.
Now how do I install a program called chirp for programming 2 way radios?
Searched for a week and gave up as each set of instructions lead down a broken, redundant dependency rabbit hole with no solution in sight, Flatpack this, snap that, no explanation or even a searchable clue that could begin me a solution.
In windows I just unzip the nightly build to a directory of my choice, run the executable and it works.
Sure… Not everyone knows or needs to know about these edge case applications, but point stands, it works in windows, and everyone encounters an edge case sooner or later.
I’m keen to ditch the Microsoft hole, and I have no issue with making an effort to learn, but I can’t afford to or my life in hold for hours or days at a time in order to accomplish things that already work in seconds.
I think my simple issue here is… I’m not incompetent. I can comfortably navigate a fine system in a shell, can mount and unmount, can tar -xvzf a tarball, can do most things up to writing a shell script from scratch (could cobble something
Investigating further I think I do see your issue. You started out installing software the way you do on Windows: Going out to the vendor’s website and downloading a .exe. I went straight to my distro’s package manager and installed a .deb, which worked fine…even if I got a 4-year old version of the software.
I will notice that on chrip.danplanet.com, it does briefly mention the legacy version can be installed “On Linux, via flatpak” which doesn’t seem to be true at least anymore; neither Mint’s software manager nor flathub.org return any relevant hits for “chirp.”
Let’s see if I can get it installed on my Mint machine by simply copy-pasting the commands listed on this page.
One criticism I can level right now about this tutorial page: Step 1. Install Distro Packages branches, you’re supposed to use the APT command if using Debian, Ubuntu, Mint, Raspbian etc . or the DNF command if using Fedora and compatible (which would include Red Hat, Nobara etc. Instructions for Arch-based distros are not included, I suppose if you Arch btw you don’t need them. It’s probably in the AUR. Point is this is a branching path, but doesn’t have a 1.1 or 1.2. Next up, under Install CHIRP (and Python dependencies) this also branches, but has a 2.1 and 2.2 notation. My distro, Mint 21.1, is based on Ubuntu 22.04, so I cound in the Ubuntu 22.10 and earlier section, so I’ll run that command.
It returns an error, and on further examination, it’s pretty clear as to why. PIP is Python’s package manager, which can and usually does download packages from a central repository, but in this case the ./ in the command means its looking for a file in this directory. Just above this, in a place that doesn’t look like a step in this process, it’s telling us to download the latest .tar.gz from another page.
So I go to this page and download the chirp-20231223-py3-none-any.whl file, noticing that this is a different file name than the one listed in the tutorial command. Since I used Firefox to download this file, I know that it landed in my ~/Downloads folder. I cd ~/Downloads, then run the pip command, substituting the name of the file I just downloaded.
The next instruction is to run ~/.local/bin/chirp, so it apparently installed it in the .local/bin hidden directory. Running that command launched the program successfully. It prompted me if I wanted to create a desktop icon, which isn’t exactly what this did. What it did was create a .desktop file, which added CHIRP to my application menu…which is what I wanted it to do anyway. But I could have done this manually because it told me what the command to launch the program was.
The documentation isn’t 100% straightforward. The formatting of two different either/or branches are not formatted similarly, and the “download the file” part doesn’t look like a step, it’s mentioned in insufficient detail as part of the description of the next step. There isn’t enough information in this tutorial alone to figure this out, you have to have looked around the site a bit and have some experience doing this to figure it out.
This is also a personal note, but I would prefer that end-user applications not be installed with PIP. If you’re not going to publish to the native package formats like .deb or .rpm, I would prefer you published a Flatpak on Flathub, or if you’re being really lazy an appimage.
I think I’m going to contact the webmaster here with these critiques, to hopefully make it more consistent and clearer.
My first attempt was apt-get install. I’m fairly comfortable with Linux as a server (basic lamp setup) though I make no claims if being an expert.
It’s clearly not in the default repos for Raspian (at least not when I tried), and that could be half my issue, my hardware while popular is not x86 or x86-64.
Huh. I’ve used chirp under Linux before and I just installed it with my package manager. Maybe it wasn’t available on your distro? Then it can get a lot more tricky. The other problem with these things can be permissions… once you have chirp installed maybe you need to add your user to the dial out group in order to be able to use the serial port to flash the radios.
No software is guaranteed to run on all platforms: the developers choose to make it available or not.
I did some quick googling, and it seems fairly easy to install it:
Use Ubuntu (if you’re not familiar with, and don’t want to be familiar with terminal basics), and install chirp from the Ubuntu App store. Snap is just a name of their package format, and their app store links to snap craft.
If you’re not using Ubuntu, that’s your choice, you’ll either have to install snap, then do the same, but it’s more work. Or play with the terminal just a bit to follow their instructions.
Details
If you’re on Ubuntu or have snap installed - it’s a one click operation to install chirp: snapcraft.io/chirp-snap
Supposing that you’re asking in good faith, the answer appears to be to make a Lemmy post. There is a fair overlap with the HAM and *nix communities, especially the PubNixes. Chirp is fairly well-known so, package manager is likely the way to go.
Don’t know why I could not see this repply until today. It’s been ascertained that chirp is not in the repo for Raspian Linux, so indeed that option never worked.
I’ll try compiling it now. Also, it took me a while to realize FF is Firefox.
Edit: It failed! I tried 2 times, it starts compiling, but after some time, I just find the terminal closed and it doesn’t run. Anyways I won’t bother with it, I only did it to torture my computer a little.
I have a fairly “bleeding edge” laptop with an RTX3000 series GPU and an AMD CPU/APU and I have been surprised at how well it runs on Linux.
Not only is my battery life consistently better but it handles the GPU switching flawlessly and performance in games is also consistently noticeably better than what I experienced running Windows on the same hardware.
Even in just the last year or two the advancements in Linux support have been downright incredible! (At least in my personal experience)
Of course I’m using Nvidia’s proprietary drivers, but I was in Windows too and my experience has only improved by switching to Linux.
I tried installing it on my 3 years old (at the time) Surface Book and while some things worked they certainly didn’t work as well as in Windows. I messed around with a specially crafted Linux kernel for the Surface devices and that was a bit better but the wifi routinely stopped working after resuming from sleep. The touchscreen worked but not with the pen. The device also consumed huge amounts of battery life when sleeping. Would not recommend.
I remember in 2008 when I was in university trying to use Linux on my laptop. I had to run a script at the command line to connect to my uni’s wifi, because the UI always failed to connect. Then I had to keep wpa_supplicant running in a terminal window the entire time.
linuxmemes
Top
This magazine is from a federated server and may be incomplete. Browse more on the original instance.