Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)T
Posts
3
Comments
79
Joined
3 yr. ago

  • i’d like to try gnome or kde plasma

    I'm surprised to see that no one has mentioned the following yet:

    "KDE Edition

    In continuation with what’s been done in the past, Linux Mint 18.3 will feature a KDE edition, but it will be the last release to do so.

    I would like to thank Kubuntu for the amazing work they have done. The quality of Plasma 5 in Xenial made backports a necessity. The rapid pace of development upstream from the KDE project made this very challenging, yet they managed to provide a stable flow of updates for us and we were able to ship good KDE editions thanks to that. I don’t think this would have been possible without them.

    KDE is a fantastic environment but it’s also a different world, one which evolves away from us and away from everything we focus on. Their apps, their ecosystem and the QT toolkit which is central there have very little in common with what we’re working on.

    We’re not just shipping releases and distributing upstream software. We’re a product distribution and we see ourselves as a complete desktop operating system. We like to integrate solutions, develop what’s missing, adapt what’s not fitting perfectly, and we do a great deal of that not only around our own Cinnamon desktop environment but also thanks to cross-DE frameworks we put in place to support similar environments, such as MATE and Xfce.

    When we work on tools like Xed, Blueberry, Mintlocale, the Slick Greeter, we’re developing features which benefit these 3 desktops, but unfortunately not KDE.

    Users of the KDE edition represent a portion of our user base. I know from their feedback that they really enjoy it. They will be able to install KDE on top of Linux Mint 19 of course and I’m sure the Kubuntu PPA will continue to be available. They will be able to port Mint software to Kubuntu itself also, or they might want to trade a bit of stability away and move to to a bleeding edge distribution such as Arch to follow upstream KDE more closely.

    Our own mission isn’t to diversify as much as possible in an effort to attract a bigger chunk of the Linux market, and it’s with a bit of sadness that we’re letting this edition go. We focus on things we do well and we love doing to get better and better at doing them. KDE is amazing but it’s not what we want to focus on.

    With Linux Mint 18.3, we’ll release one more KDE edition. I wanted this announcement to come before the release. It will hurt its popularity of course, but I wanted to give users time, either to react right now or to take their time, upgrade and adapt to this later on. I’m sure this edition will be missed and I hope its users understand our decision."

    From this Linux Mint blog post*.

    Note that this doesn't mean that you can't use KDE Plasma (or GNOME for that matter). Though you have to be aware that you'll be on your own whenever something breaks. And if you have to ask how to change Desktop Environment in the first place, then I think that you might not be ready yet for such a ride. Instead, consider using a distro that actually does offer GNOME and/or KDE Plasma editions of its distro; the likes of Fedora, openSUSE and Pop!_OS come to mind.

  • Seriously, if you want an IDE for Python and C#, VS Code with the Microsoft plugins is and will be miles ahead of the VIM experience.

    Someone else already pointed how VS Code has become the most popular IDE (at least according to statistics found on stackoverflow). While categorically I'd like to dismiss VS Code for not adhering to F(L)OSS, VSCodium -however- actually does fit the bill. And while formerly I've had bad experiences on it related to how the plugin ecosystem is configured by default compared to VS Code, I've since learned how it works on VSCodium. So I shall set it up in case Emacs and/or (Neo)Vim somehow seem to be less fit for the job and/or I can't be bothered at that moment to configure Emacs/(Neo)Vim to do my bidding.

    Learn vi

    Will do.

    The time trying to force VIM/EMACS into a descent IDE will never come back and the theory sounds better than it will be in reality.

    I understand the concerns. And I agree that I should be realistic in how I approach this. Nonetheless, I'm faithful for it to be a very productive endeavor. Thank you for chiming in!

  • I’m not using lsp in Neovim so if I need lsp I’ll just pull out emacs. If I’m already in the terminal I’ll usually pull out Neovim to edit a file, but if I’m writing like markdown or something that uses images I like the ability to display images inline in emacs. LaTeX is always something I do in emacs because there’s a built in pdf viewer in emacs and there’s built in spell check also. In the terminal in emacs, sometimes I open up Neovim to do a quick edit because of muscle memory from the terminal. One thing that’s really cool about Neovim is that you can embed it in other applications, so if I really have to use an ide that’s not emacs, I’ll just do that.

    Wow, the insights! Vehemently noting these down somewhere Heck, I think you've cracked the code. Since I've created these posts, I became more and more aware of how great both Emacs and (Neo)Vim are. And while I was already flirting with the idea to perhaps use both, I think you've just completely obliterated any other option; which is a good thing. As such, I'm actually grasping for words that would somehow be able to properly convey the feelings of gratitude I currently experience. For whatever it's worth; thank you from the bottom of my heart!

    Yeah there’s a thing called EAF, which allows python and javascript to be embedded in emacs. It allows for more complex applications to be built in emacs, similar to VSCode. I’m not sure how difficult it is to make something with EAF, but I haven’t really seen any things written in it that aren’t in the EAF organization. I think the future could be EAF or maybe something like EAF to be able to leverage the power of the javascript ecosystem like how VSCode does for a lot of plugins. There have been some attempts to rewrite emacs in different languages, but emacs is too large, and you would lose the old ecosystem by doing that.

    Once more; much appreciated!

    There’s a larger community around Doom Emacs, and Doom Emacs looks nicer. Honestly though it doesn’t matter that much which one you use since they are both pretty good.

    Yet again; I'm grateful! Have a good one! I wish you and your loved ones the best!

  • Unless you really want vim bindings

    I kinda do for how ubiquitous Vim keybindings are.

    try them out.

    Regardless, I think I will try it out after I'm at least somewhat productive with Vim.

    I much prefer the way Kakoune works over vim

    I think preference is generally subjective. So you're completely in your right to prefer Kakoune over Vim (and vice versa). Though, if possible, would you mind elaborating what you prefer exactly and why?

    while still being close enough so that you can pick it up quickly if you already know vim and the other way around.

    Doesn't that disrupt muscle memory?

  • I probably would have never got into Emacs at all if I had to start with vanilla.

    Very interesting. I assume this is due to the amount of effort that would have been required for it to acquire some of the functionality you were expecting out of it. Am I right?

    IMO Lisp is what makes Emacs great, and vimscript is (was?) an absolute nightmare for anything complex. I don’t think lua is a bad language, but I’ll still take Lisp any day for this purpose.

    This is actually a great point that I somehow completely ignored so far. I intend to put my teeth in GNU Guix at some point in the future. As Guile Scheme and Lisp are -to my knowledge- at least in some way related, using Emacs should at least provide an excellent platform for me to get accustomed to what it is yet to come. Thanks for mentioning that!

    What I described isn’t using containers. Nix just provides an environment for processes to run in, and direnv-mode ensures it’s using the right environment for a given buffer in Emacs. So for example I don’t have OmniSharp or dotnet in my user $PATH, but they are provided by the nix expression in a particular project directory. That allows lsp-mode to start OmniSharp as a language server, or I can run dotnet build using the Emacs compile command.

    That sounds very compelling! Thanks for that insight! Perhaps I should stop procrastinating and get on with learning Nix 😅.

    You can define containers with nix and manage them with nixos-container. I do that for testing server deployments, or running sandboxed services, but I’ve never needed something that complex for a dev shell.

    Yet another reason in support of learning Nix.

  • I'm so grateful for the time it took you to write this down. Thank you so much for your contributions in this conversation! I've greatly enjoyed reading every one of your replies. While I am currently not in the state to make any promises related to sticking to Neovim in the long run. I do think that I'm at least very interested to explore its possibilities. Have a good one! Cheers!

  • Wow! Excellent and thorough response. Thank you so much for taking your time 😊!

    It is very nice being able to see what your action is going to effect before you do it - unlike in vim when you just hope you have hit the right movement keys.

    That's awesome! Which does beg the question why the others haven't implemented such functionality (yet)?

    And it also pops up a small window for leader keys (like space) which show you what you can do with it making it far more discoverable then vim/neovim without needing to pour though hundreds of pages of manuals to even get a glimpse of what it can do or needing to go back to them to remember something that you dont use very often.

    Interesting. If I'm not mistaken, both Spacemacs and Doom Emacs offer similar functionality through the emacs-which-key package. I would think that Neovim should have some plugin that does something similar, but perhaps not.

    Just about everyone that I have seen use it over vim have highly praised it and it has quite a few contributors already (700+ on github), which is very impressive compared to vim (about 300), and neovim (more then 1100).

    I didn't expect for them to be so many 😜. Hmm..., food for thought; thanks for pointing that out!

    And keep in mind that vim has been around so long thanks to a single maintainer, Bram Moolenaar, who passed away this year. Which is not a great sign for vims future for the next 20 years.

    I definitely understand that Vim's future is lot less certain compared to two years ago due to the passing of Bram Moolenaar. However, and I might be wrong on this, but I feel as if Vim has reached a critical mass of following such that it'll probably continue to exist in some healthy form regardless.

    In general I think you make a excellent case for Helix. I'm actually considering if I should reconsider it (if that makes sense). Uhmm..., but two questions remain:

    • I shouldn't expect remote accessing some random server will allow me to use Helix, right? Is there any other way to make this work? Or..., should I just learn both Vim and Helix' Vim + Kakoune amalgamation?
    • Vim is literally ubiquitous and plugins that enable its features can be found on almost any 'platform'. It's unrealistic to expect Helix' adoption to be at that rate (yet). However, would you happen to know if at least the likes of VS Code and/or Jetbrains' IDEs support it? And if so, how good their support/implementation is?
  • I tend to use both, depending on the situation, with a lighter nvim config. Sometimes the 3 second emacs startup time is annoying so I use vim then. I think its fine to try both.

    Could you elaborate more upon your workflow? Like, in which situation do you prefer Emacs and when do you prefer Neovim? I get that the lighter option is preferred when you want to perform a quick edit or can't be bothered with startup time. But I want to know it beyond that and -if possible- what led you to favor one over the other in each situation.

    Regarding emacs declining popularity, I think that in the long term it could be a problem, since most people don’t want to learn elisp just to configure their editor. Elisp is very powerful in emacs, but its design is very different to other languages, so as emacs contributors get older, it could possibly lead to less and less new contributors.

    How do you envision Emacs' future? Would, at some moment in the future, some kind of compatibility layer of sorts be developed that lower the entrance barrier? To my knowledge, Emacs has -contrary to Vim- been more open to community development. So I don't expect something like NeoVim to be developed for Emacs as there's less need for it. But I don't know how much they'd be willing to change Emacs for the sake of making it more attractive for new users.

    Idk about the vim distros, but I think Doom Emacs is easier for beginners to get into.

    Compared to Spacemacs I assume*. If so, would you mind elaborating?

  • I appreciate your input. Thank you!

    Also, there are too many plugins to serve the same purpose and I found it difficult (compared to neovim) to figure out the difference between them.

    Interesting.

    Finally, the level of customization was also less granular than what offers neovim.

    Very interesting. I'd love to hear more about this. Could you elaborate?

    I would add that neovim and emacs both have a steep learning curve but I personaly found the level of support and core and plugins documentation for neovim more accessible, readable, and better organized.

    I wouldn't be surprised if this is in part attributable to the fact that Emacs is both an older project and is generally-speaking a bigger and/or more capable piece of software.

    I completely share your vision about what an IDE should be doing. I’m old school and adhere to the “do one thing but do it right” philosophy. Also, I hate relying on one tool for several needs because if anything goes wrong it has multiple impacts.

    I've often heard Emacs users pose the argument that Emacs as an Elisp interpreter does just one thing. It's just that this single thing allows the myriad of functionality it offers. So in that sense comparing it to a terminal/console seems more apt than comparing it to a text editor. I wonder what you think of that argument.

    As a side note, I use neomutt as my email client and you can nicely couple neovim to it to write your emails ;)

    Hehe, that's cool! Currently I'm really happy with Thunderbird so I don't expect to move away anytime soon, but I'll keep it in mind.

  • I use Emacs + spacemacs in VI mode as a base for all my text editing

    Do you specifically prefer using Spacemacs as a base over Doom Emacs? Or is the usage of Spacemacs primarily attributable to it coming earlier to the scene?

    Furthermore, as you're using it in "VI mode", would it be fair to assume that you've got some experience/history with Neo(Vim) as well? If so, what led you to making the switch from (Neo)Vim to Emacs?

    For dev environments I mostly use nix + direnv + direnv-mode.

    Very interesting! Relying on Nix rather than Distrobox has been something I've been pondering upon. But besides the fact that I'm still very new to Nix as an ecosystem, I've also got my concerns related to what degree the containers can be sandboxed. Do you happen to have some insights on this?

  • Hi!

    I’ve briefly shared my experience with neo(vim) and emacs here.

    Thanks for sharing that! I've just read through it and it was a very interesting read. Would you mind elaborating upon the following statement?

    "the lack of uniformity across plugins coding which sometimes created some conflicts"

    I think the main factor of choice would be to know if you prefer to build your own perfect tool with just what you need and expand as you go (i.e. neovim) or just have a do-it-all ready tool right out of the box (i.e. emacs).

    That is indeed something that concerns me regarding Emacs. Like being able to surf on the internet or using it as a email client isn't quite what I expect out of my IDE 😅. I guess the extensibility should allow 'minimal' installations, but this is something I should read more into. Thanks for pointing that out!

  • How long did you try using Vi (or any other "mode-switch vietnam-era editors with cult like followings")? Have you experimented with any starter kit/distribution/config (or whatever) to ease you in? What do you use now?

    Btw, I agree that stand-alone Vi probably is too far of a departure from modern IDEs. As far as I know, it's not even possible to give it IDE-like functionality apart from a few basic ones. Both Vim and especially Neovim do a better job at bridging the distance. FWIW, Vim only exists like for three decades now, while Neovim's first release happened in 2014; almost 10 years ago.

  • I have used vim/neovim for years and cannot go back to a non-modal editor. But TBH I got sick of its configuration. You need far too many plugins and config to get things into a sane working order to be usable on a day to day bases for any type of development. It takes ages to learn and become as productive as you were before and a lifetime to refine.

    Interesting. Though I can definitely see where you're coming from. Uhmm.., have you used any of the Neovim distributions to make maintenance easier?

    For the past year or so I have switched to helix and don’t plan on going back to vim/neovim as my main editor ever again.

    Both Helix and Lapce have certainly piqued my interest as FOSS alternatives to VS Code. However, both have issues related to how well their current Vi(m) implementation is. As you've touched upon it; Helix' keybindings and 'sentence-structures' are different to those found on Vi(m).

    Furthermore, neither of the two have existed long enough to be able to profess any statement regarding their longevity. Like, there's no guarantee that I can keep using either of the two 20 years into the future. While no program is able to 100% guarantee that, undoubtedly, the track records for both Emacs and Vi(m) testify that -if anything- they would be the most likely ones to survive 20 years down the line; like how they've done for the last couple of decades.

    I appreciate the input, but I simply don't want to invest in a program whose future is very unclear to me at this point in time.

  • As a long-time Vi user I would highly recommend giving it a shot for a solid month to see if it clicks for you.

    Makes sense. Thanks for the tip!

    Emacs is dead near as I can tell.

    Am I correct to assume that you think that Emacs is dying? If so, would you be so kind to elaborate on why you think that's the case?

  • openSUSE's Richard Brown has given multiple talks over the years comparing these three. I'd suggest anyone to look at those for a great rundown on how these universal package managers compare to one another. His most recent talk can be found here; in which he actually does some kind of recap as well.

  • steamos is debian-based

    This used to be the case until the launch of the Steam Deck, on which SteamOS (3) is actually based on Arch instead. However, SteamOS is a very special distro based on Arch due to 'immutability', how it achieves said 'immutability', the implications thereof, 'freezing' of packages, inability to install packages persistently without some hacking etc. So, SteamOS is not representative of how Arch works in general.

    while popos is ubuntu-based

    And Ubuntu is based on Debian.

    is that the biggest part of how a distribution works, ie commands, etc.?

    If we take your average (popular) distro, so the likes of Gentoo, NixOS etc are dismissed as they are very unique compared to the others, then arguably the most important differentiators would be: Model for updates, package manager and available packages. One might delve deeper into this and with the advent of stuff like Distrobox this becomes a lot more blurred, but traditionally speaking the aforementioned three things used to be the main differentiators. Beyond those, the end-user has the freedom to do whatever with their system. For example, Pop!_OS comes with GNOME + their own touches by default. However, the desktop mode of SteamOS comes with KDE. But you can install KDE on Pop!_OS and even customize it very closely to how it's done over at SteamOS. This is not a special quality of Pop!_OS, but of Linux in general.

    Good ui/ux is important for me so i should maybe use nitrux or deepin

    It's important to note that both of these are not unique in what they offer in terms of UI/UX. You can recreate 99% of it yourself, simply by installing the appropriate desktop environment; which constitutes most of the UI/UX. Nitrux has KDE as its desktop environment (with a touch of Maui), while deepin uses the Deepin desktop environment. Personally, I wouldn't recommend any desktop environment beyond Cinnamon, GNOME, KDE and Xfce. Don't be discouraged by this though, feel free to put Nitrux and deepin on a Live USB to get a feel for them. Regarding good UI/UX, your best bets are probs Kubuntu, Linux Mint, openSUSE and Pop!_OS. Honourable mention would be MX Linux, but I don't recommend systemd-less distros to newer users.

    that are debian-based

    Sure, Nitrux is based on Debian. But it's immutable, systemd-less and favors AppImages over Flatpak/Snap. It's a cool project, but I find it hard to recommend to a newer user. While deepin is less unique by comparison, it's far from a distro that's known for its polish. I'd argue it's mostly just eye-candy instead 😅.

    or is it a bad idea to choose a less common distro for a amateur like me?

    Bullseye! This isn't a hard rule though. I started venturing into Linux through a somewhat obscure distro as well 😅. But, at the time, I researched for about a week which distro to install and why. Afterwards I spent another week on how I should install it and what should be considered for install. And then I installed it, after which I spent almost two weeks getting the system to a working state. It still wasn't quite there yet, but after spending a month on it from start to finish I wanted to move on to something else 😅. I kept the install, don't get me wrong. And it became my daily-driver. After some time I even 'fell in love with it'. But like, I know that I can be stubborn about things like this and persevere where others might have preferred to hit their heads to the wall instead. So your mileage may vary...

    Do you have any advice for me?

    As you've correctly assessed, you are indeed lost 😅 . That's fine, I think almost all of us have been lost at some point in time. Uhmm..., but honestly, I think you're conflating two very distinct things. Pop!_OS is a general-use distro on which you can do whatever. And most distros that people talk about and engage with are similarly general-use distros. SteamOS, on the other hand, isn't quite like that. Sure, you may hack your way and achieve some things with it. But it's false to believe that you can find any distro that qualifies as SteamOS but on your laptop. Before giving you any recommendations, would you be so kind to answer the following:

    • Your post is written in a way that implies that you want to forego Pop!_OS for another distro that's more like SteamOS. Therefore my question would be:
      • What things from SteamOS did you prefer over Pop!_OS? Please be specific and elaborate*.
  • Aight, I actually don't know a lot about it, but I guess something that looks like an answer is better than none. So without further a due.

    First of all, Nitrux is quite unique, so I won't be able to do it justice regardless. However, I'd say that it being an 'immutable' distro with OpenRC and focusing on AppImage (over Flatpak/Snap) is the primary one. It's important to note that Nitrux' model doesn't allow you to install .deb packages natively at all. So in that regard, it's one of the less flexible among its 'immutable' siblings. It does offer great support for Distrobox, so you can install your debs, rpms and from the AUR etc if you so desire within a container instead; you can even install other desktop environments with this. Waydroid works. AppArmor is configured. KDE Plasma looks fantastic on Nitrux, but they offer even more spice through their Maui Shell.

  • ....

    Jump
  • (Manjaro keeps breaking itself for a laugth)

    Are you perhaps using the AUR more than you should on a Manjaro installation? Just for your information; because Manjaro holds back packages for a couple of weeks, any package from the AUR might conflict with those 'outdated' packages and thus cause some breakage. If you really need those packages, then you should consider container solutions like Distrobox to resolve this. Note that trying things like installing a custom kernel won't work through Distrobox.

    So the main options probably consist of:

    • Just plain Arch; archinstall has made it a lot easier to install. Furthermore, after everything is set and done, it can literally be Manjaro without outdated packages and less bugs etc, or actually whatever you would like your Linux installation to be. Setting up is the most daunting part though. Fortunately, the Arch Wiki does an excellent job in providing a resource at every set of the journey. Recommended if you're not scared of setting up your system from a blank slate.
    • Any other Arch-based distro, really. There are a ton of recommendations found in the other comments and there's even more if you check out Distrowatch for Arch-based distros. If you kinda know what you'd want from a future system, but can't be bothered with setting it up directly from Arch, then this might be recommended based on the specifics of your demands and to what degree existing distros align to that. For whatever it's worth, I think Garuda Linux is an interesting option for those that want to move on from Manjaro. Similary to Manjaro, it's opinionated on how your system is/should be configured. That's why it's also one of the few Arch-based distros (like Manjaro) that offers -out of the box- the means to rollback to a working system whenever anything unfortunate befalls your system, Garuda achieves this through coming pre-configured with Btrfs+Snapper. It should be noted, though, that Garuda is considered bloated by some. However only you can decide for yourself if their offering is bloated to you or not. So check out its Xfce edition -or any that sound interesting to you- for yourself, if you're interested. If you think it's interesting, but are still too much bothered by the bloat, then perhaps their Lite versions are more to your liking.

    There are a lot of options beyond Arch-based distros. However, as I don't know what made you gravitate towards Manjaro in the first place and what you've come to (dis)like since, it's hard to pinpoint what exactly you'd like. If the AUR has been your main reason for using Manjaro in the first place, then it's important to note that Distrobox also grants access to the AUR from any of the other popular distros out there. So you're not confined to just using Arch(-based distros) unless you really need some custom kernel that is somehow only available in the AUR.

    • If you checked out Manjaro for its unsuccessful attempt at providing a stable rolling release, then you should check out the most successful attempt with openSUSE Tumbleweed. It has a respectable amount of packages and enables users through OBS (OpenSUSE Build Service) to extend this significantly. Its installer offers the option to go for a minimal installation.
    • If rolling release has scarred you, but you still want up-to-date packages, then consider Fedora. Huge community, AUR-like repo in COPR and once again a very respectable amount of packages make it definitely worth a mention. It offers the so-called Fedora Everything ISO (Network Installer) that acts as the installer for minimal systems.