https://dataswamp.org/~solene/2024-01-03-laptop-review-novacustom-nv41.html
In this blog post, I'm reviewing a NovaCustom NV41 laptop with many operating systems
https://dataswamp.org/~solene/2024-01-03-laptop-review-novacustom-nv41.html
In this blog post, I'm reviewing a NovaCustom NV41 laptop with many operating systems
https://dataswamp.org/~solene/2024-01-03-laptop-review-novacustom-nv41.html
In this blog post, I'm reviewing a NovaCustom NV41 laptop with many operating systems
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:
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:
Questions:
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:
chezmoi
's author implies not to be a fan of this.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")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*...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
.chezmoi
and Nix' Home Manager are used together to manage the dotfiles is perfectly fine.Final update: (for the foreseeable future)
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 !https://www.youtube.com/watch?v=8wjfurlQszI
As this is our most requested video to date, we decided to put Ben, one of the Technical Analysts here at Star Labs in front of a camera and show you a brief...
https://www.youtube.com/watch?v=8wjfurlQszI
As this is our most requested video to date, we decided to put Ben, one of the Technical Analysts here at Star Labs in front of a camera and show you a brief...
@throwawayish
@lemmy.ml