Word of advice: do not do this to any device that you actually depend on. Linux enthusiasm is all fine and fun, but this will kill most practical functionality of your device. I’d say try it out on a old phone you might have laying around but not on your daily driver.
I agree with NixOS as a good choice for this. The most important bit for me is it cleans up really well when you switch. Every other distro I’ve tried tends to leave a lot of mess behind and a lot of duplicate function apps.
Just be ready to clean out your home, maybe add a new user to test them. I set up KDE then went back to gnome and it broke my cursors somehow… nbd but it’s a bit annoying
Can’t say I’ve seen that yet, but it is a good point. Your home directory might still get a little messy. I think the thought of using the config to me a user per-desktop environment you test is problem a good idea.
I use linux to run my law office, so it can be done. Most of what I use is web-based these days, so headaches are minor. That being typed, I’ve been using linux off and on since the 1990s, and there was a fair amount of learning involved. A few notes:
-Libreoffice is good enough for document drafting, unless you’re extremely reliant on templates generated in Word. Even then, that’s a few hours of clerical work that you can farm out with, presumably, no confidentiality issues to flag. Also bear in mind that if you end up using different Linux distributions on more than one computer, then you may run into minor formatting differences between different versions of your word processing software. Microsoft Office will be a reliable option unless you run windows as a virtual machine. There are workarounds, but they aren’t business ready.
-Some aspects of PDF authoring can be tricky if you’re doing discovery prep, redaction, and related tasks in-house. This is very workflow-specific, so if you’re not a litigator or your jurisdiction doesn’t have a lot of specific requirements for pdf submissions, it might not be something that you need to worry about. If it becomes a problem, then a Windows virtual machine might be a solution.
-Video support depends greatly on the linux distribution, so you may want to do a bit of research and avoid distributions like Fedora, where certain mainstream AV formats are not supported by default for philosophical/licensing reasons.
-Compatibility with co-counsel and clients will be hit or miss. I don’t let anything leave my office that hasn’t been converted to PDF and I only do collaboration when there is a special request to do so. I can fall back on a computer that I have which runs Office. It sounds like you have more than one computer, so you can have a backup plan.
-Hardware support is critical. If you need to videoconference and it turns out that your webcam doesn’t have a linux driver, then you may be hosed. Research and test on the front-end so that you don’t find yourself in an embarrassing situation of your own making.
-Learning curves cost money. If you’re using an entirely new set of user software AND you’re hopping between different distributions to find the version of linux that works for you, you’ll waste a LOT of time that you could be using to generate billable work.
Paper printing is no big deal if you stick carefully to your first thought about linux-compatible hardware.
I use Brother laser printers whenever I need a hard copy. That brand tends to work well with linux, but research the model number in conjunction with the distribution that you’re using before you purchase.
Your point about locked in software is very important. Even in my own industry, some of my earlier jobs relied on custom Windows software for billing, dictation, document creation, and more. A lot of former nonstarters have been pushed to the cloud, but there are still challenges.
Depends on what you use. I’ve used Linux for 6 years and I’ve never needed any windows exclusive app. I still do have a laptop that’s running windows for just in case. I literally only open it once a week or so to update it, that’s it. For my use case, Linux has everything.
I don’t even have a single computer in my house with Windows on it anymore, and haven’t for years. Even the disused Windows 7 install I had sitting on an SSD gathering dust in a drawer has now been relegated to a disk image file.
Manjaro is one of the few distros I’ll actively campaign against. They’ve made countless mistakes and questionable decisions in the past, and their repo/packaging lifecycle is known to cause a lot of issues: One, Two, Three, Four. Go for EndeavourOS or Garuda Linux if you want the idea of Manjaro but managed by competent people.
“Countless” mistakes meaning two which were easily fixed.
There’s nothing wrong with Manjaro, in fact it’s probably the most user-friendly Arch distro. I’ve been using it for years and I chose it after trying several various distros and this was the one where everything worked out of the box: graphics, audio, peripherals (including controllers and exotic mice), and of course Steam and gaming.
They package drivers and stable kernels out of the box. They provide an easy to use tool for switching and installing drivers and kernels. They attempt to add extra stability to the distro (not all of us like or need to stay on the very bleeding edge all the time). Delaying the packages has zero relevance for AUR and anybody who believes otherwise should probably stop using AUR because it’s obvious they don’t understand how it works.
People who keep on linking those outdated hate lists about it are actively doing themselves and everybody else a disservice. Promoting hate against an Arch derivative for no good reason will not help Arch’s cause, on the contrary, it makes newcomers to shy away from the whole can of worms and drives them to Ubuntu.
The receipts that I just linked show far more than 2 mistakes. I don’t care whether they have fixed them or not, I care that they have made so many. Trust arrives on foot and leaves on horseback. Distro forks are nothing special, so why use the one with a history of bad management? Use Arch proper or any of the countless Arch forks that use the real Arch repos, which will inherently sidestep a lot of issues that Manjaro created for itself.
You say that delaying packages makes things more stable but there is a clear history of that not being the case, which has already been described in the links I posted. This is most importantly true in terms of delayed security updates. You also don’t understand how the AUR works in conjunction with outdated Manjaro packages, which will cause dependency problems and lead to breakage. This is a very simple cause and effect so I’m not sure how you think you can try to assert “everyone else must misunderstand how dependencies work”.
As for the last bit, no Arch is obviously not being hurt when Manjaro is called out. If anything I’ll bet Arch wishes Manjaro would stop tripping over itself and giving Arch a bad name. They are already sick of Manjaro users using the AUR and complaining every time it breaks their packages, and you can read what Arch’s security team thinks about Manjaro here on r/archlinux (image mirror here if you don’t want to visit that site).
Nobody’s perfect, all Linux distros out there have had a rough start. The ones that endure and stick around are the ones that eventually improve. If you were around when Arch came out you may recall very similar attitudes from fans of other entrenched distros disparaging their efforts. Arch wasn’t born perfect either, they made plenty of mistakes in their early days.
But if you’d demand perfection all the time you’d never use the vast majority of distributions that are trying something new. We need to rise above partisan and petty differences because Linux is a hotbed of innovation and freedom and we as a community need to encourage and nurture trying new things, not dump on it.
This is most importantly true in terms of delayed security updates.
Security updates aren’t delayed in Manjaro, they’re pushed through out of band.
You also don’t understand how the AUR works in conjunction with outdated Manjaro packages, which will cause dependency problems and lead to breakage.
Once you’ve compiled an AUR package it will remain compatible with the system you compiled it on until you update and introduce an incompatibility.
This is true for any Arch or Arch-based distribution. It has nothing to do with when the distro updates packages. It’s purely a coincidental factor of whether a particular AUR package breaks binary compatibility with any particular distro update. Users who don’t regularly update their AUR packages to keep them in sync with the system will seemingly randomly experience breaks, depending on what AUR packages they use. It can and does happen on Arch just as well as any derivate distro. You need to either automate AUR updates or update them by hand to avoid it.
you can read what Arch’s security team thinks about Manjaro here
That’s not the “Arch’s security team”, it’s one person on a 3rd party forum, with a history of issuing personal statements reeking of personal grudge. Yeah I know that comment unfortunately. It’s a singular, isolated piece of flamebait and it makes me sad to see it’s still being bookmarked and passed around 5 years later.
Arch has made a lot of mistakes, and their most recent one where they bricked everyone’s GRUB loader is the one that caused me to stop using it as a general recommendation. This sort of thing would never happen in Debian, and pretending that “every distro makes massive mistakes!” is disrespectful to distros that actually put a ton of effort into making sure these things don’t happen. Sweeping those mistakes under the rug is harmful to new users who don’t know what they’re signing up for when they download the distro that you are sugarcoating, and that is the primary reason to make sure that anyone considering Manjaro is aware of its past so they can make their own decisions.
Security updates aren’t delayed in Manjaro, they’re pushed through out of band.
Manually. Also read as: delayed. The comment from Arch’s security team that you are minimizing is part of the reason why this is a bad idea: “They just forward our security advisories without reading them. Leaving critical security issues to rot in their “stable” repositories while only pushing forward issues that are publicized or users telling them about”. Once again, why would I trust the Manjaro team to be on top of security when they can’t figure out how to keep an SSL cert alive? Their security mailing list hasn’t even been updated in a year.
Once you’ve compiled an AUR package it will remain compatible with the system you compiled it on until you update and introduce an incompatibility.
You are dodging the real dependency problem by focusing on this half. The real dependency problem is that when an AUR package updates and Manjaro’s packages are not new enough for the update, it will cause breakage. AUR packages are built with Arch Linux’s repos in mind and no care whatsoever for the versions of packages that Manjaro holds. Updating your AUR packages frequently will all but guarantee that you will eventually run an AUR update that requires a dependency with a newer version than Manjaro provides, and that app will break (or worse, the AUR package is a dependency for other apps which will cause further breakage). Even Manjaro knows this: “Using AUR also implies Arch stable branch - which is only achievable by using Manjaro unstable or testing branch.”. Also take it from their team: “The AUR is neither officially supported by Arch nor Manjaro. If you do use the AUR on Manjaro, use our unstable branch. Problem solved.”
That’s not the “Arch’s security team”, it’s one person on a 3rd party forum, with a history of issuing personal statements reeking of personal grudge. Yeah I know that comment unfortunately. It’s a singular, isolated piece of flamebait and it makes me sad to see it’s still being bookmarked and passed around 5 years later.
Yes very sad that a member of Arch’s security team made a warning about Manjaro’s security 5 years ago and still we have people pretending that it’s “flamebait” because that’s a convenient excuse to dismiss it.
The real dependency problem is that when an AUR package updates and Manjaro’s packages are not new enough for the update, it will cause breakage.
How many AUR packages do you use? I have about 70 installed right now. Never had a source-level incompatibility happen. You’d have to let system updates lapse for years to lose source compatibility with a current AUR package.
I no longer use Arch, but this wouldn’t have happened to me because I used vanilla Arch. On Manjaro it can happen at any moment that an AUR package silently depends on a new part of a dependency not implemented in the older versions. The AUR does not care to figure out which exact version dependencies are needed for a program, because you are expected to always have an up-to-date Arch system before installing. If the AUR cared about Manjaro compatibility they would need to mark every dependency with a minimum version number, but that’s a lot of effort and the AUR understandably doesn’t care about supporting Manjaro’s repos. If Manjaro stood up its own AUR this would no longer be a problem.
(Personally, I don’t think AUR packages are a good idea for system stability/security even on vanilla Arch, but it is understandable that people like them for their convenience.)
I disagree with this post being downvoted. Manjaro has had a number of issues, including forgetting to renew a cert a few times, accidentlly Ddosing Arch, holding back repo updates but not AUR updates breaking systems, and some allegations of missused funds.
If you’re searching for something, I would also personally reccomend against Manjaro, simpy for the reason that you are less likely to wind up with something broken on most other distros. I do know some people who swear by Manjaro though, and if you’re using it or set on it then that’s fine too (the best OS is the one that brings you the most value).
–
To acutally answer the question above, though, the best distro is the one that you prefer. Platforms like Steam manages it’s own updates and software so the stable/rolling debate doesn’t really apply here. Same with anything installed with distro agnostic package managers (Flatpak, Snap, Appimages). As far as most gaming setups drivers are the only real difference between distros (and you can always change that yourself manually).
A person in this thread already recommended having different colors for different conditions like ssh and running as root, I havent seen anyone mention this specifically but you can determine if the current working directory is writable with something like [ -w “$(pwd)” ] and set the color to red or print a symbol if it doesnt return true.
Also I recommend putting all the code and logic for your shell prompt in a shell function, and using a substitution shell to put it into the PS1 variable like this:
<span style="color:#323232;">__shellprompt ()
</span><span style="color:#323232;">{
</span><span style="color:#323232;"> if [ "$(id -u)" = 0 ]; then
</span><span style="color:#323232;"> local PROMPT_EMBLEM='#'
</span><span style="color:#323232;"> else
</span><span style="color:#323232;"> local PROMPT_EMBLEM='$'
</span><span style="color:#323232;"> fi
</span><span style="color:#323232;"> printf "%s" "$(whoami)@$(uname -n):$(pwd)"
</span><span style="color:#323232;"> printf "n%c " "$PROMPT_EMBLEM"
</span><span style="color:#323232;">}
</span><span style="color:#323232;">PS1='$(__shellprompt)'
</span>
Now this is just a really barebones example, there is a whole lot more you can do like passing in the last exit code through the argv of your shellprompt function like this PS1=‘$(__shellprompt $?)’ and like print it out if its non-zero so you wont have to like echo $? to see if the last command failed, but you should be able to still do this. In my testing, running the shell prompt function in the subsitiution shell didnt effect the $? variable.
In my first comment on another thread about shell prompts, I posted my full shellprompt, it is slightly outdated (I just changed hostname to uname -n), if you cant find it feel free to send a message or just ask, and I will send you the code.
This example is very enlightening. I was kind of aware that one could run shell functions and even use a GIT function in my prompt, but I never thought it through and your example brings the point home.
I’ll waste most probably a few hours to find my perfect prompt function!
Something that should be noted when adding colors to your shell prompt function is adding the non printable characters that keep the terminal from buggin out, this caused me a massive headache until I figured it out. When putting it in the PS1 variable directly you will put [ to begin a color sequence and ] to end one, but printf will print a literal [ and ] so instead you will have to use `
I always use https://luciole-vision.com/luciole-en.html to typeset documents like letters and such. I find it pleasant looking and it is supposedly easy to read for people with dyslexia.
I’m not sure how this is in any way different from android? Android is free software they use to restrict the computing they devices they sell to push more ads and junkware. This is just a different one. Amazon sucks, so I don’t see what move they could make that could be seen as positive. Just don’t buy their garbage devices.
Apparently, this is now part of kdeplasma-addons, so this might be in a separate package, which may not be pre-installed by your distro. I really don’t know, if it means anything, but Nate felt it worth mentioning here: pointieststick.com/…/these-past-2-weeks-in-kde-wa…
My guess is that somebody has some important “Windows” application that they need to run that is calling into Cygwin. That means that the proper way to run it on Linux is almost certainly just to port it from Cygwin to Linux native. How do you do this though if somebody else wrote the code?
linux
Active
This magazine is from a federated server and may be incomplete. Browse more on the original instance.