throwawayish

joined 1 year ago
[–] throwawayish@lemmy.ml 6 points 10 months ago

There was another post yesterday about this and the community recommended Mint & Pop OS the most. However, I am not looking for windows-like. I want a new & fresh experience like using a smartphone for the first time or switching from ios to android.

While I get why Linux Mint (with the Cinnamon DE) is regarded as a Windows-like, Pop!_OS is far from that. Furthermore, going from iOS to Android is arguably a smaller change than going from Windows to any Linux DE (so even the Cinnamon DE (on any distro)). Regardless, the Desktop Environment is the single most influential part of a distro to how you experience any distro. Therefore, if you actually want a new & fresh experience, then you should definitely check out DEs like Cinnamon, GNOME, KDE Plasma and Xfce^[1]^ on something like a Live USB (perhaps through the use of Ventoy). After you've experienced a bunch of DEs, you should have attained a better grasp of what you like and don't like.

Distrochooser.de recommended kubuntu to me.

While Distrochooser is cool and all, you shouldn't take it too seriously 😅. If possible, consider sharing your results on Distrochooser, that might at least provide us some pointers.

  1. Too many to list actually 😅, and most of them shouldn't be of a concern to a new user (or have simply become mainstays on most distros). The most important 'block' would be the Desktop Environment, though. Furthermore, design choices like release model, independent/derivative, opinionated/blank slate, traditional/atomic etc and a distro's popularity are other important factors in making a decision; while we'd refer to none of them as "building blocks of a distro". However, if there are any "blocks" that you would describe as a hard-requirement for you, then it does make sense to look for a distro that meets those. For example, in my case; a configured SELinux and atomic upgrades^[2]^ are required. As such, the decision already boils down to like two distros 😅. The shopping experience approach would perhaps make more sense if you chose a distro with little to no defaults (à la Arch (or Gentoo^[3]^)). Finally, perhaps it's worth noting that ((Dynamic) Tiling) Window Managers' capability of leaving you in awe for the opportunities and possibilities they provide are more substantial. Thankfully, while not as feature-rich, the more established DEs do offer means to engage with (dynamic) tiling (through extensions/add-ons).
  2. That's hard to find; obviously distros won't advertise what they're missing. Heck, I wouldn't be surprised if they have good reasons for their respective design choices. Still, FWIW, resources like these might be helpful to some. However, you should only look at the tables, the texts found above the tables are at best outdated and perhaps even misleading otherwise. Beyond that, if you narrow the choice between just a couple of distros, then I'm sure the community would be more than willing to point you toward their differences.
  3. Software I would recommend to anyone would be:
    • Distrobox; this excellent piece of software has single-handedly solved package availability across the Linux landscape. Other excellent endeavors like AppImage, Flatpak, Nix and Snap definitely have their uses and are in some aspects superior; but Distrobox' ease of use (contrary to Nix) and (almost) boundless access to packages (contrary to AppImage, Flatpak and Snap) on top of how well it integrates with the rest of your system makes it my personal MVP.
    • Flatseal; must-have if you ever plan on using flatpaks (which you definitely should consider).
  4. It depends entirely on the distro you install. Assuming that you start using a distro with sane defaults (like most new users do), then unless you're using an Nvidia GPU^[4]^ (or other hardware known for causing troubles), you can start using your system however you'd like it; which for most would consist of installing the software they need. Furthermore, concerns related to bloat are a lot less significant/severe on Linux, so you should be fine unless you think the default installed file manager is bloat...
  5. I actually don't know. Perhaps it might be related to creating an as homogeneous experience as possible; apps on Linux either rely on GTK or QT for their appearance/looks etc. Therefore, by foregoing one, the 'awkward' 'out-of-place'-experience that some might experience every so often would have been overcome. But this is a rare concern (I'd say). So unless you're very into how your system looks and feels, it shouldn't be a concern to you.
  6. I think these questions show that you've put some thought into this and that by itself is already very commendable. And I'm actually of the opinion that asking these questions, especially for someone like you, is important. So I would definitely encourage you to continue with asking relevant questions in hopes of making the transition to Linux as pleasant as possible. As for the distros you've mentioned, chances are high that you'd be content with either one of them. However, I wonder if you're making a conscious choice; like would you be able to state why any of these should be preferred on the basis of merit rather than popular vote^[5]^ or what happened to come out of Distrochooser.

  1. Important distinction: these aren't selected for how different they operate/behave compared to Windows(/macOS) but for being some of the more polished DEs found on Linux. For a more exhaustive list, refer to the one found on the ArchWiki; which still happens to miss DEs like Kera 😅.
  2. I wouldn't call atomic upgrades a building block as it's ultimately a design choice.
  3. Gentoo is a great distro, but I would not recommend a new user to engage with it; unless you believe you belong to the sub 1% that can make it work as their first distro. Heck, even Arch is often discouraged to new users. Though I think that Arch might be just up your alley; at least if you enjoy reading the excellent ArchWiki.
  4. In which case, either the installer provided by the distro got your back and the proprietary drivers are installed or you're required to install them yourself. Steps related to these are different per distro, but reading up on your chosen distro's documentation should be sufficient.
  5. Don't get me wrong; I'm not dismissing the popular vote.
[–] throwawayish@lemmy.ml 2 points 10 months ago

Thank you so much for your insights!

[–] throwawayish@lemmy.ml 1 points 10 months ago

Alright, let's first deal with unfinished business.

DistroWatch as useful as statista.com for suggesting your next travel destination. If you had to travel somewhere and had a list of criteria, but didn’t want to spend all day researching, would you go to a travel agent or open an encyclopedia?

I agree that DistroWatch is very useful as a more general resource rather than whatever you think Distrochooser is capable of. However, similar to DistroSea, it provides excellent information for anyone that is more interested in a specific distribution. Especially the reviews (by both the site maintainer(s) and visitors) are especially very valuable and the closest thing we have to an aggregated user reviews for distros. For good measure, I'm talking about the content of the reviews not the numerical representation.

but I disagree with a lot of things you said.

I'm so stoked to read these. I genuinely mean this btw*; every time someone informs me on why they disagree with me is an opportunity for me to learn new stuff.

I could quote everything I disagree with and write a paragraph

Please do. I mean it.

however it would be a meaningless endeavor as a moderator looking at the post would probably decide against adding distrochooser to the sidebar - regardless of my opinions.

This is very defeatist of you, though. And FWIW something which I didn't expect from you. If you can even make (just) one person (in this case, perhaps me) learn something new, then that should be worth the effort. As you should be aware by now, I'm a lot more active on Lemmy than I should 😅, but this also means that having me (or anyone for that matter) be on your side might just be the thing you need to have this succeed eventually.

[–] throwawayish@lemmy.ml 3 points 10 months ago

XY problem confirmed. Thank you OP!

There have been complaints in posts about people asking for advice on which disto to use, that there are too many such posts.

This is a legit concern.Thank you for trying to tackle this!

Provide users the tools to possibly answer the question themselves before creating a post.

Noble. And in its essence, it makes a lot of sense.

DistroChooser is a self-help tool for that purpose.

As a self-help tool it's very bad. Sorry*. I actually hoped that you would mention how it might be used as a basic requirement for anyone that asks which distro to use. The enforcement could be done with a bot which simply scans if any link to distrochooser is present in a post that remotely resembles one that asks for advice on which distro to use. I would actually even argue against this, but I think we might be able to reach an agreement on which questions are actually worth keeping around for further use...

  • keep answering posts --> more complaints, possibly silent quitting of community

Honestly, this is better than to limit newbies to strictly stick to Distrochooser for asking which distro they should use 🤣.

  • write bot --> I ain’t got the time, maybe somebody has, dunno what the bot would do

I haven't got any experience with building a bot, but I suppose it works by scanning for words in posts. In that case, simply 'flagging' everything that contains the words "which" or "what" in combination with "distro(s)" or "distribution(s)" and ask them to refer their questions to a dedicated Lemmy community in which they can ask would already solve a lot.

  • find alternative website --> I ain’t got the time

You don't have to find an alternative website. Nor write one yourself. As it stands, as far as I'm aware, there's simply nothing that satisfies the basic needs for this.


So what do I propose? Relegating these questions to their own dedicated Lemmy community is probably a great and easy solution. If something like a test/algorithm/flowchart/quiz/whatever has to be created, then that one might need substantial effort to get off the ground. However, perhaps comments like these might be helpful as a blueprint.

[–] throwawayish@lemmy.ml 2 points 10 months ago (2 children)

Sorry, I think I might have confused OmniOS with QubesOS.

😅, but QubesOS isn't a derivative of OpenBSD either. It might have inspired some of its parts, but fundamentally it's a completely different beast.

ZFS is itself a security feature because of how well it guarantees the fidelity of your data.

Do you happen to know if this goes beyond what Btrfs(/Bcachefs) provides on the Linux side of things?

[–] throwawayish@lemmy.ml 1 points 10 months ago

Honestly, I don't know if that's the case; I always got scared whenever I saw the prerequisites for Heads in combination with the strict list of supported hardware. FWIW, the NV41 that's used for enabling Heads on NovaCustom's device is included in the short list of supported hardware for Heads, while -unfortunately- the same doesn't apply to the StarBook. I would love to be proven wrong though!

[–] throwawayish@lemmy.ml 2 points 10 months ago (2 children)

ADDENDUM:

Alright, let's get to the elephant in the room (Distrochooser's questions).I'll go over every single question and offer my feedback.

  1. Software: Use case: This is one of the better questions. But, unfortunately, not without its faults. For one, it somehow thinks that "I want to use Linux for anonymous web browsing." and "I prefer a distribution which is supported by game publishers." is somehow mutually exclusive. The only way this would make any sense at all is if somehow "anonymous web browsing" implies strict adherence to Tails or QubesOS and their guidelines. But since when is it not possible to boot up a Whonix VM on any ordinary distro for anonymous browsing, while Valve's Proton handles everything on the gaming side of things. Furthermore, the inclusion of both "I want to execute all programs in an isolated environments." and "I want to use Linux for anonymous web browsing." on the very first question seems as if the audience that has watched Mr. Robot are somehow treated like first-class citizens, while I thought this intended to be useful for the more general newbie. This also somehow implies that Linux is for the h4ck0rs or something. It would make a lot more sense to pose a question like that after the security sensibility has been measured first. Why is this even the first question? Wouldn't it make more sense to know what hardware is targeted in the first place? Verdict: Fine question, but needs work.
  2. Computer knowledge: This question somehow implies that knowing your ways around a computer is better or something for when you want to use Linux. Why? Is it even important to know if one is adept with Windows or macOS before they use Linux? Aren't most people more accustomed to mobiles OSes anyways? If anything, I would argue that preconceived notions on how other desktop OSes work might be detrimental. Verdict: Pointless.
  3. Linux and you: This should be useful, right? Well..., didn't we already settle on the fact that we wanted this for new users? So then what does it add if we know they're complete strangers to Linux or (instead) have used it once like 5 years ago? Verdict: Pointless.
  4. Installation: Presets: Assuming that "I want to choose the settings by myself" and "I want to configure as much as possible using graphical applications" are the same except for how the former is more akin to an archinstall while the latter is basically the same but with a GUI, then for the new user we would always want the GUI-based, right? Alright, as for the choice that remains... I actually don't know why either one would be necessarily preferred over the other. Being able to choose sounds good, but what actually do we get to choose? This question is honestly too vague for me without grabbing any installer with it. I wonder if you think the same... Verdict: I, personally, don't understand the use (case) or what it tries to achieve. Pointless.
  5. Hardware support: The single best question on the list. I would argue the possibility should be explored in which something akin to a hardware probe should be implored in order to dismiss a huge bulk of the distros simply for not being well-optimized for the hardware. Verdict: MVP, while it's already useful in its current iteration, I do think it deserves more work before it can be actually useful for most people.
  6. Source for help: I guess this question tries to take into account the dynamic between how user interactions happen with on one hand well-documented projects with a small and non-vocal user base, while on the other hand we have projects that aren't well-documented but depend on user participation to bridge the gap. I wouldn't be surprised if this is yet another artifact from the times in which the "RTFM"-reply was to be expected for asking a stupid question. The 'meta' has changed so much since that this question simply seems outdated and doesn't deserve to be on the list. For beginners, we should always encourage the use of distros with both an excellent (or at least sub-par) documentation and a lively, vocal, active and helpful community. Verdict: Pointless.
  7. User experience: At best, it's an artifact of when ElementaryOS actually was a thing and rightfully deserved to be mentioned in recommendation lists. However, at the other end of the spectrum this is a false and misleading dichotomy between GNOME (and GNOME-like DEs) and KDE Plasma (and KDE-like DEs). Honestly, it's an insult to both GNOME and KDE Plasma (and most DEs for that matter) to be compared to macOS and Windows respectively. And I haven't even gone over how it affects oversimplification and the resulting false expectations. Don't get me wrong, I think that -conceptually- asking for how one would like to interact with their system is very important. And if anything, exploring DEs like GNOME, KDE Plasma, Cinnamon and Xfce (etc) is one of the most important steps a new user can take in deciding which distro they should pick. But instead of asking a question like that, we should instead put our efforts into making a test distro of sorts in which one can easily explore different DEs. I'm sure something like that already exists or can simply be achieved through using a bunch of ISOs and Ventoy. But I digress... FWIW, I even saw in your post history that you made the same analogy, which just shows how misleading it is if even a veteran user for 15 years can be misled. Verdict: Pointless. But, conceptually, deserves a lot more love.
  8. Distributions: Price: Why is this even included? Yes, I'm aware that Zorin OS Pro exists. But this, by itself, doesn't justify the inclusion of this question. Verdict: Pointless.
  9. Distributions: Scope: Does it even make sense to ask a newbie if they would like to choose their own basic programs? I think this question has potential, but requires a precursory question in order for it to be unlocked after it has been determined the user is in fact a 'tweaker'. Otherwise, this question doesn't hold any value. Furthermore, Distrochooser isn't even 'smart' enough to know that minimal installers for Fedora and openSUSE exist for those that seek more freedom in what is installed on their systems... Verdict: Pointless, unless newbie also (somehow) happens to be a 'tweaker'.
  10. Distributions: Ideology: For the Libre distros; sure, let's overwhelm the new user with this as well /s. Verdict: Pointless.
  11. Distributions: Privacy: I think this question is fine. I think it needs a couple of gentle touches to be actually useful, but there's potential and it deserves its place. Especially considering the amount of people that actually gravitate towards Linux for privacy concerns. Verdict: Fine question, but deserves some gentle touches.
  12. Administration: Any new user should be able to install software from something that looks like a storefront AND needs to educate themselves on how the terminal could be used to that effect. sudo apt/dnf/zipper install name-software shouldn't be too much to ask. Verdict: Pointless.
  13. Software: Updates: Good question. The conclusions Distrochooser takes from this are laughable, but it doesn't undermine that it's a good question. Verdict: Fine question, needs work.

Alright, so let's make up the score:

  • Deserve to be on the list: 3
  • Pointless: 8
  • The hardware probe should be explored to take over the function of hardware specifics (or anything that's similarly effective)
  • Finally, the question about User experience should be reworked to implore the user to try a bunch of different Desktop Environments.

As you should be aware, I wasn't as fire-y in the second half as I was in the first. This might be related to tiredness etc. Regardless, as it stands Distrochooser asks 8 questions too many that are not only pointless, but for their presence they also are misleading; thus they're ultimately bad. Two questions deserve a lot more love for what they're capable to bring to the table and one might argue that their current presence is nothing but a disservice to them. Finally, the remaining 3 questions... Surely, we should be able to ask those through a bot/template, right? Wouldn't that be a lot better and more efficient?

And we haven't even touched upon the myriad of questions that should be asked instead. Security vs Convenience? Which software they intend to use and if they've been able to actually find alternatives for those that simply aren't supported on Linux? Automatic upgrades in the background vs deliberate updates?^[3]^ Etc...


  1. Of course if the user even intends to use a distro that's not 'stable' like how Debian Stable is 'stable'.
[–] throwawayish@lemmy.ml 2 points 10 months ago (3 children)

I got bored 😅. So here is my second response. But please, before reading this one, consider reading my other reply first. It's a lot shorter anyways 😅.

So fundamentally, I think we're misunderstanding one another. In your defense, I can understand it; as I'm just one of the many responders and you might simply not have been able to take the time to understand what it is that I'm trying to convey and why. In my case, I think it might be related to the XY problem; i.e. you're proposing a solution (adding Distrochooser to the sidebar) for which hope will resolve an issue that remains to be stated. For all we know, you actually try to solve something else and you perceive Distrochooser in being capable of playing a vital role in that without being aware of how else the actual problem should be tackled instead.

In this reply I will try to bridge the gap that might have made you misunderstand what I tried to say in my first comment under your original post.

IMO you’re thinking too much as an advanced user for a simple user.

I think you might be absolutely right. The thing is, though, that I have never been one of those users that post a question like "Which distro?" without providing anything beyond the most basic specifics.

Some insights from my personal Linux journey(FWIW, this is me. And this was more of a last-ditch effort in hopes of finding something to dual boot into. By contrast, for my first distro I had spent a week of my free time digging through (video-)guides and Reddit threads until I had dismissed everything besides the distro I landed on. It seems that I did a good enough job as I'm still confidently using it. And while I've used and experimented with other distros since (mostly as a dual boot), my first distro is the only one I refer to as home. And the interesting part is that I'm fully aware that chances are very slim that a random bystander would ever have suggested me (as a newbie) the use of Fedora Atomic. So by doing the research myself, I've actually enabled myself to start with my ideal distro from the get-go. And yes; that means I've revisited my choice a couple of times by now, but every revisit just made me more confident in my choice.

The only point I agree on is the NVIDIA GPU.

I therefore assume you disagree not with the entire post (as you seem to be taking a liking to DistroSea), but instead refer to the parts in which I go over some more fundamental questions. I think you've missed what I tried to say with that and have also missed the hint^[1]^ to make more clear why I even said those things.

Alright, let's dismiss for a moment that the Distrochooser's questions themselves need a lot of work done and proceed right to a 'results-screen'. This is probably how I would fill it in on an average day*. In the very first sentence, we're confronted with the word stable without giving any useful information on what this means and why this is even mentioned here. Similarly, the word unstable is used without ensuring that the (potential) newbie actually has a proper understanding of what it stands for. According to your logic^[2]^ these things shouldn't even matter! So why does Distrochooser even bother to spend a sentence on this for every one of their entries? And that's why I actually agree with you! But if Distrochooser chooses to include it, then they at least have to be precise and elaborate on what they mean with this and why the new user should care. So, to be clear, my two bullet points weren't meant as "Distrochooser should definitely somehow include these as they're vital to their choice.", but instead it was meant as "Alright, if this format for Distrochooser is chosen (with all of its faults), then the least Distrochooser should do is provide information on what the points (and used terms/words/phrases) in the 'results-screen' actually mean for the newbie user. And if it's not addressed, then this automatically discredits Distrochooser as a reliable introduction/orientation to distros for new users.". Because as it stands, a lot of the small niche distros that happen to be derivatives of Debian/Ubuntu are regarded as somehow "stable" while something like Fedora isn't. And thus the newbie that just wants a stable system will be fooled/misled into using any of those fringe distros over Fedora. Which is just straight up BS.

I’ve never heard of nor used Garuda. As I said, feel free to contribute.

Don't worry, others already took care of that. The fact that it hasn't been implemented yet just shows that this is not a productive endeavor. On that note, I didn't even notice how Garuda's more popular sibling EndeavourOS is also absent in Distrochooser's results...

Never heard of DistroSea. It seem like a good complement to ~~DistroChooser~~ anything that narrows down choice

Fixed that for you. Especially considering the fact that Distrochooser is (perhaps) more misleading than anything else. This point is a dead horse by now (at least under this post of yours), but I will be more elaborate at a later point.

DistroWatch as useful as statista.com for suggesting your next travel destination. If you had to travel somewhere and had a list of criteria, but didn’t want to spend all day researching, would you go to a travel agent or open an encyclopedia?

The response on this depends on the XY problem, therefore I will refrain from commenting on this for now.

I think many in the community, like yourself, have forgotten what it’s like to give just enough of a fuck to change something but not to want to be too invested. A beginner isn’t going to want to understand why a system is stable or not: they just want a stable system. You don’t have to explain to them “Yeah, so the configuration is a file, you see? Only you edit that file. Then you run this command that interprets the file and build a dependency tree, downloads everything necessary, to a partition that’s temporarily mounted as read-write, symlinks to…”. Nobody cares. The average user DGAF.

Imagine if you just wanted to get a vacuum cleaner at the store with 3 criteria. Imagine you don’t give a rat’s ass about vacuum cleaner. You just want to point the thing at the ground, let it succ all the bits, but as quietly as possible, and not break down in 2 years to force you back out here. But the sales person you get harps on about the genius of the person who invented some internal component you’ve never heard of, goes on to explain why, ideologically, getting a certain brand is the only way because blablablabla. Maybe you’d buy a vacuum cleaner just to shut them up or walk out of the store.

These two paragraphs are at best you misunderstanding/misinterpreting what I said and why I said those things and that's where I'll leave it (for now).

My optimal experience would be the sales person listening to me, lining up the best candidates, and explaining, in bullet points, why they are there. Then finally, ask me if I have a favorite and to give me a test environment. If I don’t understand something, I can ask more questions.

Generally-speaking, I agree with this. But I hope you're not (even remotely) insinuating that this is even remotely close to the Distrochooser experience.


  1. Hint: "I’m honestly not even sure if the one(s) responsible for writing the parts of Distrochooser even know(s) themselves" from my first reply.
  2. "A beginner isn’t going to want to understand why a system is stable or not: they just want a stable system." and "Nobody cares. The average user DGAF."
[–] throwawayish@lemmy.ml 1 points 10 months ago

Good question! However I think it's wise to concentrate on a particular word/phrase before actually answering your query.

In an immutable setup on Fedora (trying to main Bazzite) is the correct way to use zsh and oh my zsh as my main shell

Currently, it's not always clear if there even is a correct way of installing some of these (more) edge cases. Therefore, I wouldn't be surprised if you'd see 'seasoned' Fedora Atomic users that have all tackled these in very different ways while being satisfied with (not only) their own solutions (but also approve the respective solutions of their peers).

As for your query, I would say that starting to use Fedora Atomic and pointing out correctly some of the more common ways to install software while being aware of the ambiguity that exists with the chosen installation method for this specific piece of software is already very commendable. So I would like to congratulate you on that!

But, you shouldn't be afraid to stick to what's easy (aka don't allow good to be the enemy of perfect). If the extra time required for changing your base system doesn't bother you at all (which happens automatically in the background anyway), then layering it (thus installing with rpm-ostree) is probably the easiest method while protecting you from a lot of possible edge cases you might have to deal with otherwise. Traditionally, zsh (and other shells) were layered (thus installed with rpm-ostree) and uBlue itself included (perhaps still does) just commands to change root shell to zsh, fish etc. This might have changed in the last few weeks, but I think it should still be a safe bet. FWIW, I have never had any troubles pertaining to my zsh installation and any of its plugins (might as well link the managed zsh-config I rely on).

[–] throwawayish@lemmy.ml 1 points 10 months ago* (last edited 10 months ago) (4 children)

OpenBSD and its derivatives (like OmniOS)

First time hearing of OmniOS, thank you for mentioning it! EDIT: I just took a look at it and it doesn't seem to be based on OpenBSD, at least the one I could find seems to be a derivative of Solaris instead. Though, I might simply not have found what you referred to*.

because it of its security-oriented features, especially things like ZFS

Does OpenBSD's implementation of ZFS offer security features as well?

I would like to switch my daily driver, a Linux laptop, to OpenBSD so I can get used to using it as an administrator, but I worry about OpenBSD being able to support the laptop hardware, especially things like WiFi, BlueTooth, and managing the battery, screen dimming, laptop lid, and so on.

Do you think that using OpenBSD inside of a qube (from QubesOS) is perhaps something worth considering? Or don't you think there's any merit of doing this over the use of any virtualization software found on any other system?

I have another Linux computer with a Radeon graphics card which connects to my TV that my children use for video games, and watching streaming video, and I would like to switch this to OpenBSD as well but I worry that it will not be able to run Steam games very well.

From what I've read, running games on OpenBSD is a lot less mature compared to running games on Linux. Though, perhaps it's worth noting that cloud gaming solutions (like Google Stadia in the past) are known to work great on OpenBSD. Not sure if you would want that, though.

(On a more general note) I definitely agree that OpenBSD works wonderfully on the server side of things. But I've gotten skeptical over time to its feasibility as a desktop OS. Note that I'm well aware that OpenBSD's developers use it as their daily drivers, so I definitely recognize the possibility. However, when it's lacking features like Secure Boot (or any form of Trusted and/or Measured Boot for that matter), I just find it hard to justify putting it on something like a laptop that I carry around all the time. I hope that you can prove to me that my logic/understanding is flawed and that I should reconsider the use of OpenBSD as a desktop OS.

[–] throwawayish@lemmy.ml 2 points 10 months ago

It has been my pleasure 😊!

[–] throwawayish@lemmy.ml 2 points 10 months ago

Aight. I've changed the comment a bit 😅 since. Perhaps it's more useful for you now 😉.

12
submitted 10 months ago* (last edited 10 months ago) by throwawayish@lemmy.ml to c/privacyguides@lemmy.one
 

Disclaimer: I'm not affiliated in any way to any of the parties involved in this review. I just enjoy reading Solène's writings in general and found myself to be especially in fond of this specific article. I share this in the hopes that others might somehow benefit from this as well!

The relevance of the review for this specific community would be that NovaCustom produces excellent laptops to be used with Linux (and other open source operating systems). Furthermore, in the review the reviewer installs a bunch of different distros and tests how they work on the device. Perhaps most importantly; Qubes OS -which is endorsed by Privacy Guides- has this specific device on their Certified hardware page. Which already is very commendable, however it's extra special when one realizes it's the only laptop with a modern CPU on the list.

25
submitted 10 months ago* (last edited 10 months ago) by throwawayish@lemmy.ml to c/linux@lemmy.ml
 

Disclaimer: I'm not affiliated in any way to any of the parties involved in this review. I just enjoy reading Solène's writings in general and found myself to be especially in fond of this specific article. I share this in the hopes that others might somehow benefit from this as well!

The relevance of the review for this specific community would be that NovaCustom produces excellent laptops to be used with Linux (and other open source operating systems). Furthermore, in the review the reviewer installs a bunch of distros and tests how they work on the device.

 

cross-posted from: https://lemmy.ml/post/9648279

I would like to premise this with the following:

  • The best approach is probably just testing out each and every editor that interests me until I've found what works best for me.
    • However, I wonder to what degree a test as such would be representative when the likes of Emacs and (Neo)Vim are considered; both of which are known for being a life time learning process.
  • I don't literally expect Emacs or (Neo)Vim to be drop-in replacements for any IDE. Some of the most basic IDE-functions are absent by default and some (perhaps more advanced) functionality might simply not be attainable at all.
  • I am not interested in anything that remotely resembles a flame war. The community at Lemmy has so far been very kind to me; let's keep it that way 😜.

Motivation

I've had experiences with Atom, VS Code and some of Jetbrains' IDEs like Pycharm and Rider. While I've been generally content with all of them, it leaves a bad taste in my mouth whenever I'm forced to switch IDEs because their lifetimes and/or lack of extensibility doesn't allow me to responsibly continue using them. As such, I'm interested in a long time investment that will grow as I will. Both Emacs and (Neo)Vim have passed the test of time and I honestly don't think they'll cease to exist in the upcoming decades, that's why I would love to start using either one of them.

Furthermore, Vi(m) keybindings seem to be somewhat ubiquitous and almost any IDE offers some support. As such, improving my Vi(m)-game should only net-positive my productivity (at least eventually). Also, fluency will benefit me whenever I'm remote accessing any random server as they will always have Vi(m) installed. Thankfully, this doesn't force me to use Vi(m) (or Neovim) just yet, because Emacs offers with Evil perhaps the single best Vi(m) implementation; outside of native Vi(m)*.

My setup:

  • I'm on a custom image of uBlue using their startingpoint as template. For those unaware; an oversimplification would be that it is Fedora Silverblue with some extras.
  • As such, I would like to have my developer environments local and have used Distrobox to that extent using steps similar to the ones outlined over here. But I'm not married to that specific way of utilizing local containers. So please feel free to recommend me something that's at least as good.
  • If I go for Emacs, then I will definitely rely on Evil.
  • If possible, I would like to use it for C#, Python and Rust. Furthermore, I engage in editing Bash scripts, Dockerfiles, Linux config files, texts written in Latex and/or Markdown and other files written in Nix or JSON. As both are very extensible, I don't expect any issues, but I might be wrong.

Questions:

  • First of all, does it make sense for me to only consider these two?
  • Can the split between Vim and Neovim be interpreted as the first schism and as such be a forebode for what's yet to come?
  • Google Trends suggests that Neo(Vim) is ever-popular. On the other hand; not only is Emacs relatively less popular, but its popularity seems to be slightly declining. Should this worry me regarding their long-time future? Especially considering that a thriving community is literally the lifeline for both of them.
  • For those that have used both extensively, which one do you prefer (if any) and why?
  • While I understand that the power of both of them lies primarily in how one can literally make them behave however suits their workflow best. Therefore, the use of premade configs and/or starter kits/distributions should (ideally) only be used either temporary or as a starting point. However, at this point, they provide a decent showcase of what each 'platform' has to offer. So:
 

cross-posted from: https://lemmy.ml/post/9648279

I would like to premise this with the following:

  • The best approach is probably just testing out each and every editor that interests me until I've found what works best for me.
    • However, I wonder to what degree a test as such would be representative when the likes of Emacs and (Neo)Vim are considered; both of which are known for being a life time learning process.
  • I don't literally expect Emacs or (Neo)Vim to be drop-in replacements for any IDE. Some of the most basic IDE-functions are absent by default and some (perhaps more advanced) functionality might simply not be attainable at all.
  • I am not interested in anything that remotely resembles a flame war. The community at Lemmy has so far been very kind to me; let's keep it that way 😜.

Motivation

I've had experiences with Atom, VS Code and some of Jetbrains' IDEs like Pycharm and Rider. While I've been generally content with all of them, it leaves a bad taste in my mouth whenever I'm forced to switch IDEs because their lifetimes and/or lack of extensibility doesn't allow me to responsibly continue using them. As such, I'm interested in a long time investment that will grow as I will. Both Emacs and (Neo)Vim have passed the test of time and I honestly don't think they'll cease to exist in the upcoming decades, that's why I would love to start using either one of them.

Furthermore, Vi(m) keybindings seem to be somewhat ubiquitous and almost any IDE offers some support. As such, improving my Vi(m)-game should only net-positive my productivity (at least eventually). Also, fluency will benefit me whenever I'm remote accessing any random server as they will always have Vi(m) installed. Thankfully, this doesn't force me to use Vi(m) (or Neovim) just yet, because Emacs offers with Evil perhaps the single best Vi(m) implementation; outside of native Vi(m)*.

My setup:

  • I'm on a custom image of uBlue using their startingpoint as template. For those unaware; an oversimplification would be that it is Fedora Silverblue with some extras.
  • As such, I would like to have my developer environments local and have used Distrobox to that extent using steps similar to the ones outlined over here. But I'm not married to that specific way of utilizing local containers. So please feel free to recommend me something that's at least as good.
  • If I go for Emacs, then I will definitely rely on Evil.
  • If possible, I would like to use it for C#, Python and Rust. Furthermore, I engage in editing Bash scripts, Dockerfiles, Linux config files, texts written in Latex and/or Markdown and other files written in Nix or JSON. As both are very extensible, I don't expect any issues, but I might be wrong.

Questions:

  • First of all, does it make sense for me to only consider these two?
  • Can the split between Vim and Neovim be interpreted as the first schism and as such be a forebode for what's yet to come?
  • Google Trends suggests that Neo(Vim) is ever-popular. On the other hand; not only is Emacs relatively less popular, but its popularity seems to be slightly declining. Should this worry me regarding their long-time future? Especially considering that a thriving community is literally the lifeline for both of them.
  • For those that have used both extensively, which one do you prefer (if any) and why?
  • While I understand that the power of both of them lies primarily in how one can literally make them behave however suits their workflow best. Therefore, the use of premade configs and/or starter kits/distributions should (ideally) only be used either temporary or as a starting point. However, at this point, they provide a decent showcase of what each 'platform' has to offer. So:
 

cross-posted from: https://lemmy.ml/post/9648279

I would like to premise this with the following:

  • The best approach is probably just testing out each and every editor that interests me until I've found what works best for me.
    • However, I wonder to what degree a test as such would be representative when the likes of Emacs and (Neo)Vim are considered; both of which are known for being a life time learning process.
  • I don't literally expect Emacs or (Neo)Vim to be drop-in replacements for any IDE. Some of the most basic IDE-functions are absent by default and some (perhaps more advanced) functionality might simply not be attainable at all.
  • I am not interested in anything that remotely resembles a flame war. The community at Lemmy has so far been very kind to me; let's keep it that way 😜.

Motivation

I've had experiences with Atom, VS Code and some of Jetbrains' IDEs like Pycharm and Rider. While I've been generally content with all of them, it leaves a bad taste in my mouth whenever I'm forced to switch IDEs because their lifetimes and/or lack of extensibility doesn't allow me to responsibly continue using them. As such, I'm interested in a long time investment that will grow as I will. Both Emacs and (Neo)Vim have passed the test of time and I honestly don't think they'll cease to exist in the upcoming decades, that's why I would love to start using either one of them.

Furthermore, Vi(m) keybindings seem to be somewhat ubiquitous and almost any IDE offers some support. As such, improving my Vi(m)-game should only net-positive my productivity (at least eventually). Also, fluency will benefit me whenever I'm remote accessing any random server as they will always have Vi(m) installed. Thankfully, this doesn't force me to use Vi(m) (or Neovim) just yet, because Emacs offers with Evil perhaps the single best Vi(m) implementation; outside of native Vi(m)*.

My setup:

  • I'm on a custom image of uBlue using their startingpoint as template. For those unaware; an oversimplification would be that it is Fedora Silverblue with some extras.
  • As such, I would like to have my developer environments local and have used Distrobox to that extent using steps similar to the ones outlined over here. But I'm not married to that specific way of utilizing local containers. So please feel free to recommend me something that's at least as good.
  • If I go for Emacs, then I will definitely rely on Evil.
  • If possible, I would like to use it for C#, Python and Rust. Furthermore, I engage in editing Bash scripts, Dockerfiles, Linux config files, texts written in Latex and/or Markdown and other files written in Nix or JSON. As both are very extensible, I don't expect any issues, but I might be wrong.

Questions:

  • First of all, does it make sense for me to only consider these two?
  • Can the split between Vim and Neovim be interpreted as the first schism and as such be a forebode for what's yet to come?
  • Google Trends suggests that Neo(Vim) is ever-popular. On the other hand; not only is Emacs relatively less popular, but its popularity seems to be slightly declining. Should this worry me regarding their long-time future? Especially considering that a thriving community is literally the lifeline for both of them.
  • For those that have used both extensively, which one do you prefer (if any) and why?
  • While I understand that the power of both of them lies primarily in how one can literally make them behave however suits their workflow best. Therefore, the use of premade configs and/or starter kits/distributions should (ideally) only be used either temporary or as a starting point. However, at this point, they provide a decent showcase of what each 'platform' has to offer. So:
 

I would like to premise this with the following:

  • The best approach is probably just testing out each and every editor that interests me until I've found what works best for me.
    • However, I wonder to what degree a test as such would be representative when the likes of Emacs and (Neo)Vim are considered; both of which are known for being a life time learning process.
  • I don't literally expect Emacs or (Neo)Vim to be drop-in replacements for any IDE. Some of the most basic IDE-functions are absent by default and some (perhaps more advanced) functionality might simply not be attainable at all.
  • I am not interested in anything that remotely resembles a flame war. The community at Lemmy has so far been very kind to me; let's keep it that way 😜.

Motivation

I've had experiences with Atom, VS Code and some of Jetbrains' IDEs like Pycharm and Rider. While I've been generally content with all of them, it leaves a bad taste in my mouth whenever I'm forced to switch IDEs because their lifetimes and/or lack of extensibility doesn't allow me to responsibly continue using them. As such, I'm interested in a long time investment that will grow as I will. Both Emacs and (Neo)Vim have passed the test of time and I honestly don't think they'll cease to exist in the upcoming decades, that's why I would love to start using either one of them.

Furthermore, Vi(m) keybindings seem to be somewhat ubiquitous and almost any IDE offers some support. As such, improving my Vi(m)-game should only net-positive my productivity (at least eventually). Also, fluency will benefit me whenever I'm remote accessing any random server as they will always have Vi(m) installed. Thankfully, this doesn't force me to use Vi(m) (or Neovim) just yet, because Emacs offers with Evil perhaps the single best Vi(m) implementation; outside of native Vi(m)*.

My setup:

  • I'm on a custom image of uBlue using their startingpoint as template. For those unaware; an oversimplification would be that it is Fedora Silverblue with some extras.
  • As such, I would like to have my developer environments local and have used Distrobox to that extent using steps similar to the ones outlined over here. But I'm not married to that specific way of utilizing local containers. So please feel free to recommend me something that's at least as good.
  • If I go for Emacs, then I will definitely rely on Evil.
  • If possible, I would like to use it for C#, Python and Rust. Furthermore, I engage in editing Bash scripts, Dockerfiles, Linux config files, texts written in Latex and/or Markdown and other files written in Nix or JSON. As both are very extensible, I don't expect any issues, but I might be wrong.

Questions:

  • First of all, does it make sense for me to only consider these two?
  • Can the split between Vim and Neovim be interpreted as the first schism and as such be a forebode for what's yet to come?
  • Google Trends suggests that Neo(Vim) is ever-popular. On the other hand; not only is Emacs relatively less popular, but its popularity seems to be slightly declining. Should this worry me regarding their long-time future? Especially considering that a thriving community is literally the lifeline for both of them.
  • For those that have used both extensively, which one do you prefer (if any) and why?
  • While I understand that the power of both of them lies primarily in how one can literally make them behave however suits their workflow best. Therefore, the use of premade configs and/or starter kits/distributions should (ideally) only be used either temporary or as a starting point. However, at this point, they provide a decent showcase of what each 'platform' has to offer. So:
 

Incoming long post, please consider reading at least the following TL;DR before commenting.

TL;DR: Interested in finding the means to manage my dotfiles in a declarative, 'immutable'/read-only way and with automatic sync across two devices (and a fleet of container environments). The method shouldn't require the management of my packages.


First of all, I'm still relatively new to managing dotfiles. So far, git has been doing fine, but time has come to upgrade.

Goals: As I've moved from a non-declarative way of administrating my system to one in which some elements are declarative, it just feels appropriate to apply a touch of 'declarative-ness' to managing dotfiles as well.

Furthermore, as I've been using image-based ('immutable') distros for some time already, I want to explore the possibilities of managing dotfiles within that 'immutable' paradigm.

Specifics of my usage: The primary desire is to have it working on two systems simultaneously. If possible, changes to one should 'automatically' apply to the other and vice versa. Furthermore, the exact content of the managed dotfiles is not the same on both, so differentiation is a requirement. My container workloads can be handled by the likes of chezmoi and or yadm. Nonetheless, being able to manage their dotfiles as well is definitely a plus.

Options that I've explored and associated (potential) challenges:

  • Nix' Home Manager. From what I've gathered, this offers by default most of what I desire. However, I'm interested to know what the limitations are of managing dotfiles only as I'm not interested in installing any Nix packages. So it would have to manage the dotfiles of packages/software/whatever that weren't installed with Nix. ~~Furthermore, to my knowledge, Nix doesn't play nice with container environments; while this is not a hard requirement, I hope to be wrong on this.~~ EDIT: Could not find sources to back this up.

  • Guix with guix home. Unless I'm wrong, this is Guix' Home Manager. So it's met with similar challenges like those found in the previous paragraph. Furthermore, I'm interested to know if either of the two fares better than the other for my use case.

  • While chezmoi, yadm and other known dotfiles managers technically offer a solution, their respective solutions aren't declarative or 'immutable' by default. While I'm sure someone might be able to hack one of them to better fit my needs, I'm not sure if I'm personally willing to commit to that. EDIT: Apparently chezmoi is declarative. I currently wonder which other dotfiles managers I might have mistakenly dismissed for disregarding the possibility that they might be declarative. Furthermore, chezmoi seems to allow declarative control on the read-write permissions of files, which might allow restricting files to just read-only.

  • Old, trusty git. Probably furthest removed from what I desire by default, but perhaps someone knows how to make it fit regardless.

Please feel free to inform me if I've missed anything! Thanks in regards 🙂 !

EDIT: So far chezmoi has surprised me pleasantly with the possibilities it offers. But before committing, I would like to have some input from our residents that swear by Nix/Guix.


Update: It has been over 24 hours since the last time a comment was posted under this post. While I do hope to receive replies from at least two commenters eventually, I'm less optimistic on getting any replies from those that have significant experience with guix home. Though I'd love to be wrong on that.

For posterity's sake; first of all, this has been a great conversation and so I'd like to thank everyone that has contributed! Secondly, I've tried to spend a good portion of the last 24 hours to read up on the subjects that were touched upon and evaluate them accordingly. This has led to the following discoveries that might be worth sharing:

  • Ansible is a legitimately good piece of software that can be used for this purpose, even if chezmoi's author implies not to be a fan of this.
  • While Ansible applies configs 'convergent' (when done right), Nix' Home Manager is able to do so 'congruent' and does so effortlessly in the sense that -with the advent of flakes- one 'simply' does it the 'correct' way regardless (though checks and whatnot help elevate everyone to that level relatively easily). I'm not confident on how chezmoi fares compared to the other two. Refer to this article for more info on what 'convergent' and 'congruent' mean in this context. (TL;DR: "ansible will make changes to get it closer to a target state, whereas nix will reach the target state by constructing the target state again")
  • Due to the point raised in the previous bullet, (when mastered) Nix' Home Manager simply seems a far superior option compared to Ansible. Thus Ansible is dismissed in favor of Nix' Home Manager.
  • I've also come to appreciate how powerful of a tool chezmoi is. Nonetheless, I couldn't stop noticing how many people that have used chezmoi at some point in time eventually switched to Nix' Home Manager for salvation. With those that didn't stick to Nix' Home Manager being open that it was often related to not being able to get it to work *gulp*...
  • At this point it seems that Nix' Home Manager is the clear victor, but Guix' guix home hasn't been represented (yet). So that's what I intend to figure out before committing fully to either Nix' Home Manager or (perhaps) Guix' guix home.
  • As a final note, using any of the tools mentioned doesn't exclude the use of the other tools. Sometimes one tool just fares better in one particular task compared to the other. Thus, one should not be afraid to mix and match these to best fit their needs. As such; a setup in which Ansible, chezmoi and Nix' Home Manager are used together to manage the dotfiles is perfectly fine.

Final update: (for the foreseeable future)

  • The question how Nix' Home Manager fares against Guix' guix home didn't matter in the end 😅, but this is related to how my system works. In case it wasn't clear yet, I daily drive Fedora Silverblue. And as it stands, I'm unaware of any method that enables one to install Guix on Fedora Silverblue without putting SELinux from enforcing to permissive. I don't want to forego SELinux' enforcing mode for Guix, especially when Nix can be installed without being forced to do that. As such, I'll start my (perhaps long overdue) journey into the wonderful world of Nix. I would like to once again thank everyone that has contributed! And also thank you for reading this :P !
view more: next ›