Why switch?

I played with the idea of switching for quite a while. Having switched my daily driver from Windows maybe 6-9 Months ago I made many mistakes in the meantime.

Good and bad

This may have led to a diminshed experience with ubuntu but all in all, I was very pleased to see that Linux works as a daily driver. Still, I was unhappy with the kind of dumbed down gnome experience.

Problems

There were errors neither I nor people I asked could fix and the snap situation on ubuntu (just the fact that they’re proprietary, nothing else).

Installation

Installing debian (and kde) was easier and harder than I expected. The download mirror I used must not have been great although its very close to my location because it took ages although my internet connections is good.

Apps

Since I switched to Linux, I toned down my app diet a lot. Installing all my apps from ubuntu was as easy as writing a short list and going through discover. Later I added flatpak which gave me a couple apps not available through discover (such as fluffychat). The last two I copied directly as appimages.

Games

I was scared that the „old kernel“ of stable debian would be a problem. As it turns out, everthing works great so far, a lot better than on ubuntu which might or might not be my fault.

Instability

Kde does have some quirks that irritate me a bit like installing timeshift (because I tried network backups which dont work with it and the native backup solution does not seem to accept my sambashare) led to a window I could only close by rebooting.

Boot time

What does feel a bit odd is the boot process. After my bios splash, it shows „welcome to grub“ and then switches to the debian start menu for 3 seconds or so, then shows some terminal stuff and then starts kde splash and then login. This feels a lot longer than ubuntu did. Its probably easy to change in some config but its also something that should be obvious.

Summary

So far I‘m incredibly happy although I ran into initramfs already probably because of timeshift which I threw out again. I might do a manual backup if nothing else works. My games dont freeze or stutter which is nice. All apps I had on ubuntu now work on debian and no snaps at all.

TL;DR: If you feel adventurous, debian and kde are a pretty awesome mix and rid you of the proprietary ubuntu snap store. It also doesnt tell you that you can get security upgrades if you subscribe to ubuntu pro. Works the same if not better.

  • IronKrill
    link
    fedilink
    arrow-up
    2
    arrow-down
    3
    ·
    edit-2
    10 months ago

    I tried installing Debian recently as well but didn’t get too far into it. I was annoyed at the base configuration* though. I wasn’t able to use sudo, so I went to add myself to the sudo group and it told me the command didn’t exist… I looked it up and realised that /usr/sbin* wasn’t on terminal path. Extremely fixable but something I never ran into on other distros, made me nervous how many other tweaks I may have to do.

    I was simultaneously testing Lubuntu and ended up sticking with that after following install instructions for another app kept complaining about bookworm errors. Perhaps the Debian version was too new?..

    * Edited a couple of details to make them more accurate.

    • haui@lemmy.giftedmc.comOP
      link
      fedilink
      arrow-up
      2
      ·
      10 months ago

      I suppose it depends on a lot of things. Errors are pretty common once you start installing a lot of apps in any distro imo. Especially unstable and sid are more up to date but as the name suggests less stable.

      • IronKrill
        link
        fedilink
        arrow-up
        1
        ·
        10 months ago

        As far as I know I was on the stable version. I downloaded the one right on their front page, which was 12.4.0 net install.

        • haui@lemmy.giftedmc.comOP
          link
          fedilink
          arrow-up
          1
          ·
          10 months ago

          Thats stable atm. No clue what it was back then. It took me a bit to add myself to the sudo group since sudo visudo doesn’t work. No idea what the use of that is.

          • superbirra@lemmy.world
            link
            fedilink
            arrow-up
            1
            ·
            10 months ago

            you obviously can’t use sudo visudo if you’re not already in the sudoers file LOL - is the same security, which you also desire, as having a spare set of keys in the bowl at the entrance to your house, where, however, no one comes unless they already have a key to open the door

            • haui@lemmy.giftedmc.comOP
              link
              fedilink
              arrow-up
              1
              ·
              10 months ago

              I made a mistake, fine. Visudo doesnt work either from my recent experience. At the very least, it should say „dont use sudo as root“ instead of „the command doesnt exist“.

              You could have explained it without the elitist touch. Tyvm

              I added my user to the sudo group and rebooted (as relogging doesnt work either).

              So, debian is cool but you can definitely see how fanboiism keeps it from being great.

                • haui@lemmy.giftedmc.comOP
                  link
                  fedilink
                  arrow-up
                  1
                  ·
                  10 months ago

                  I have no idea what you‘re talking about. I didnt point out anything and surely didnt need a slap on the wrist. Whatever bdsm fantasy you‘re having atm.

                  I was nice enough to admit my mistake, whereas you were a jerk enough to make fun about it you sad person. Now go away.

      • superbirra@lemmy.world
        link
        fedilink
        arrow-up
        1
        arrow-down
        1
        ·
        10 months ago

        beside op’s bashrc fud, it’s a common newbie misconception that testing and sid are not stable like some kind of exotic experimentation would make them so. It is more a stabilization process in respect to the project’s policy/processes and you will definitely find /usr/bin in pathh in either testing and sid rofl

      • IronKrill
        link
        fedilink
        arrow-up
        1
        ·
        edit-2
        10 months ago

        Well, I don’t know what to tell you when I had just installed and the system tells me the command does not exist, so I look up the error and adding the path to bashrc fixed the issue. The only PATH export in that bashrc file is the one I added after searching the issue.

        • tal@lemmy.today
          link
          fedilink
          arrow-up
          2
          ·
          10 months ago

          It was probably /usr/sbin you’re thinking of rather than /usr/bin. IIRC – don’t quote me on this – Red Hat puts it in non-root user paths by default, and Debian doesn’t.

          • IronKrill
            link
            fedilink
            arrow-up
            2
            ·
            10 months ago

            You’re correct. That’s one of the few useful things superbirra mentioned, and I’ve updated the parent comment to correct my initial error. I was recalling from memory and just remembered it was a “bin” folder.

        • IronKrill
          link
          fedilink
          arrow-up
          1
          ·
          10 months ago

          I’m curious now so am going to try re-installing from their homepage.

          • IronKrill
            link
            fedilink
            arrow-up
            1
            ·
            10 months ago

            You don’t need to be defensive about this. I’m just sharing my experience, I’m not trying to insult Debian or it’s maintainers. And yes I believe anything can happen considering the crazy bugs I have seen get shipped. Windows wiping One Drive files, multiple Steam bugs on Linux that can wipe your system, etc. Or it may be my choices during install, but it is still unusual compared to all of my Ubuntu installs.

            Anyway, I took another shot at it and it still happened. I downloaded the 12.4.0 net install that is on the front page of debian.org. Installed two different times in Virtualbox, once using the graphical and once using the CLI install, using two different mirrors. I unchecked Gnome and ticked LXDE during installation (as I did before), because that is the DE I wanted. I would hope that would not change bashrc settings. Tried sudoing and got the exact same error.

            Here’s the generated .bashrc which I have not touched.

            .bashrc
            # ~/.bashrc: executed by bash(1) for non-login shells.
            # see /usr/share/doc/bash/examples/startup-files (in the package bash-doc)
            # for examples
            
            # If not running interactively, don't do anything
            case $- in
                *i*) ;;
                  *) return;;
            esac
            
            # don't put duplicate lines or lines starting with space in the history.
            # See bash(1) for more options
            HISTCONTROL=ignoreboth
            
            # append to the history file, don't overwrite it
            shopt -s histappend
            
            # for setting history length see HISTSIZE and HISTFILESIZE in bash(1)
            HISTSIZE=1000
            HISTFILESIZE=2000
            
            # check the window size after each command and, if necessary,
            # update the values of LINES and COLUMNS.
            shopt -s checkwinsize
            
            # If set, the pattern "**" used in a pathname expansion context will
            # match all files and zero or more directories and subdirectories.
            #shopt -s globstar
            
            # make less more friendly for non-text input files, see lesspipe(1)
            #[ -x /usr/bin/lesspipe ] && eval "$(SHELL=/bin/sh lesspipe)"
            
            # set variable identifying the chroot you work in (used in the prompt below)
            if [ -z "${debian_chroot:-}" ] && [ -r /etc/debian_chroot ]; then
                debian_chroot=$(cat /etc/debian_chroot)
            fi
            
            # set a fancy prompt (non-color, unless we know we "want" color)
            case "$TERM" in
                xterm-color|*-256color) color_prompt=yes;;
            esac
            
            # uncomment for a colored prompt, if the terminal has the capability; turned
            # off by default to not distract the user: the focus in a terminal window
            # should be on the output of commands, not on the prompt
            #force_color_prompt=yes
            
            if [ -n "$force_color_prompt" ]; then
                if [ -x /usr/bin/tput ] && tput setaf 1 >&/dev/null; then
            	# We have color support; assume it's compliant with Ecma-48
            	# (ISO/IEC-6429). (Lack of such support is extremely rare, and such
            	# a case would tend to support setf rather than setaf.)
            	color_prompt=yes
                else
            	color_prompt=
                fi
            fi
            
            if [ "$color_prompt" = yes ]; then
                PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ '
            else
                PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '
            fi
            unset color_prompt force_color_prompt
            
            # If this is an xterm set the title to user@host:dir
            case "$TERM" in
            xterm*|rxvt*)
                PS1="\[\e]0;${debian_chroot:+($debian_chroot)}\u@\h: \w\a\]$PS1"
                ;;
            *)
                ;;
            esac
            
            # enable color support of ls and also add handy aliases
            if [ -x /usr/bin/dircolors ]; then
                test -r ~/.dircolors && eval "$(dircolors -b ~/.dircolors)" || eval "$(dircolors -b)"
                alias ls='ls --color=auto'
                #alias dir='dir --color=auto'
                #alias vdir='vdir --color=auto'
            
                #alias grep='grep --color=auto'
                #alias fgrep='fgrep --color=auto'
                #alias egrep='egrep --color=auto'
            fi
            
            # colored GCC warnings and errors
            #export GCC_COLORS='error=01;31:warning=01;35:note=01;36:caret=01;32:locus=01:quote=01'
            
            # some more ls aliases
            #alias ll='ls -l'
            #alias la='ls -A'
            #alias l='ls -CF'
            
            # Alias definitions.
            # You may want to put all your additions into a separate file like
            # ~/.bash_aliases, instead of adding them here directly.
            # See /usr/share/doc/bash-doc/examples in the bash-doc package.
            
            if [ -f ~/.bash_aliases ]; then
                . ~/.bash_aliases
            fi
            
            # enable programmable completion features (you don't need to enable
            # this, if it's already enabled in /etc/bash.bashrc and /etc/profile
            # sources /etc/bash.bashrc).
            if ! shopt -oq posix; then
              if [ -f /usr/share/bash-completion/bash_completion ]; then
                . /usr/share/bash-completion/bash_completion
              elif [ -f /etc/bash_completion ]; then
                . /etc/bash_completion
              fi
            fi
            
            • superbirra@lemmy.world
              link
              fedilink
              arrow-up
              1
              ·
              10 months ago

              also let’s be curious about the things we copy-paste in order to prove whatever theory: in literally the first line of your bashrc non-login shells are named. What are those non-login? If we need to defined them like that, do also we have a non-non-login ones? How do they get executed? How do they get initialized? Let’s explore and understand some new stuff (that we should have learned already, but who cares, it’s not our job!)

            • superbirra@lemmy.world
              link
              fedilink
              arrow-up
              1
              ·
              edit-2
              10 months ago

              lol I’m not defensive at all, I swear I don’t need that :D. The theme here is that you keep thinking you don’t have an ass because you’re looking for it on your forehead instead of between your butt cheeks :D

              What we can already see:

              • sudo is indeed installed, and in path
              • bash is running since system is newly installed => /usr/bin is obviously in path (bash lives in /usr/bin/bash)

              set | grep ^PATH will show that /usr/bin is indeed in path, also the fact that grep runs tell it path is correct, since grep lives in /usr/bin/grep :)

              that said, your user isn’t in the sudoers file because you choose to give login access to root during install (which is strange, because no sudo package get installed if you choose that, so you probably made some other strange not-obvious thing), and no, groupadd can’t be run by the user you keep being after a failed sudo invocation (of course you can invoke it w/ the fully qualified path which is /usr/sbin/groupadd w/ /usr/sbin not in user’s path because the binary here usually require high permissions).

              now you have a chance to learn something: where is PATH env var configured? Is it in your home or outside? Why and how it gets parsed?

              cmon, let’s explore a bit my good boy, let’s be curious about the world that is not wrong by default and only we are right ;) let’s learn stuff, for real

              • IronKrill
                link
                fedilink
                arrow-up
                1
                arrow-down
                1
                ·
                edit-2
                10 months ago

                I never said sudo was not installed, I said I wasn’t able to use sudo, which I wasn’t. This is why I went to run groupadd, which is when I discovered that it is not on PATH, which it isn’t. You’re right I shouldn’t have run groupadd as an unpriviledged user, that is fair, although it also isn’t on my root PATH.

                You’re also correct that /usr/bin is on PATH, so my initial statement is not correct: /usr/sbin is not on PATH. Forgive me mixing up the two, it didn’t seem like an important disctinction earlier when I recalled the experience off memory.

                Going back to my original post though, I was simply stating that every Ubuntu variant I have used sets me up with all this out of the box, meanwhile Debian immediately required more set up. It felt more “raw”. I can see the logic behind these changes, but as a new user it was off-putting as compared with every other distro I had used. That is all my point was. I got around the issue, it was not world-ending, but, to quote earlier me, I “was annoyed”. Simple as. I was sharing my experience with Debian because the pitfalls I encountered seemed relevant to the thread title: coming from Ubuntu to Debian.

                now you have a chance to learn something

                cmon, let’s explore a bit my good boy, let’s be curious about the world that is not wrong by default and only we are right ;) let’s learn stuff, for real

                I am not averse to learning and I have learned a couple of new things, yes. Thank you for the insight. It doesn’t change my initial statement.

                your user isn’t in the sudoers file because you choose to give login access to root during install

                This makes sense, thanks. I don’t really mind not having sudo from install though, I mentioned it because it is what started me down the “groupadd” road.

                so you probably made some other strange not-obvious thing

                I followed the graphical install and used default options except for LXDE.

                  • Adanisi@lemmy.zip
                    link
                    fedilink
                    English
                    arrow-up
                    2
                    arrow-down
                    1
                    ·
                    10 months ago

                    /usr/sbin not being included in PATH by default is definitely annoying, but I understand why it is that way. It’s because they’re infrequently accessed admin tools.

                    If it was my decision, I’d include them in PATH though.

                • superbirra@lemmy.world
                  link
                  fedilink
                  arrow-up
                  1
                  arrow-down
                  1
                  ·
                  10 months ago

                  which then I mean, if you don’t have an attention span that lasts at least until the end of other people’s comments, what are you doing here :D

                  • IronKrill
                    link
                    fedilink
                    arrow-up
                    1
                    arrow-down
                    1
                    ·
                    edit-2
                    10 months ago

                    I read your entire comment and responded to everything relevant. I didn’t break down every sentence word by word because most people don’t enjoy reading those sorts of replies, so I kept it to the bits that required a response. I don’t know what you are talking about at this point, but considering I had the attention span to spend an hour re-installing Debian twice to verify, I don’t think that is the issue here. I have been exceedingly pleasant considering your condescending tone, so your repeated quips and assumptions of the worst are uncalled for.

                    I stated an experience I had that I disliked. You stated my experience didn’t happen, and I have laid out how it occured and explained what my initial issue was. I am allowed to dislike how a distro does things while acknowledging it is doing those things intentionally. I thank you for the bits of wisdom amongst your snark, but I’m going to go do more enjoyable things now. And maybe I’ll use Debian on my next server, sorry to disappoint you since you are so determined to gatekeep it (or why else are you so glad I’m not using it?).