Good but slow. Zypper has nice features but for some reason it can only download one package at a time. There is a GitHub issue about this that has been around for years.
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.
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.
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
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.
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
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.
and instead you needed a slap on the wrist so the next time you come to lemmy you’ll think twice about pointing out a community, whatever it is, as idiotic to the point of making a trivial mistake that only you know how to fix with a more-than-trivial workaround. It’s not a matter of being a debian fanboy, in this case the distro packages the vanilla behaviour of an upstream present everywhere, which does exactly the same thing everywhere
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.
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.
Well, I don’t know what kind of mess you made on your machine, nonetheless I find it mind-boggling your assumption that one of the most used/derived distros in the world exits the installation with such an error without anyone noticing/fixing it. That said, glad you fixed it, and for the affection I feel for the Debian project, even happier that you are not a user of it :P
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. https://i.imgur.com/dhFnLgc.png
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)}[
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
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. https://i.imgur.com/xJsXMVX.png
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.
as you wish my friend, I see no value in insisting you’re doing something wrong. Good luck with your distro of choice which, I repeat, I’m glad isn’t debian :D (still PEBKAC, but really, no value in insisting :PPP)
/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.
and I understand you reason that way because you have no clue and THAT’S OK (to some extent). Go ahead and be free, all of this shit is ultimately about that and I’m glad too because I know I’ll keep having a predictable, understandable system so yay for us my friend :)
also, there is not a “specific default”, I don’t care about debian and even if I’m not using since longtime in this thread stupidity has been expressed :P
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?).
sure you’re right! Go ahead, not that I care a lot :P
probably belonging to a divine elite, or maybe one of assholes, it’s enough for me to pay my bills knowing how to use the systems and after a quarter of a century I don’t give a shit if on lemmy some pirate comes along and tells me otherwise, my bills keep paying so ciaoooo :)
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!)
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.
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.
Looks like ee is legacy mbr type with an EFI entry right after it, it could be that somebody has solved mounting this if you deep dive. And maybe an additional package is needed. Buy are you able to remount to sata and just transfer data? becuase you would want to reformat this to a modern GPT and filesystem at some point. Or see if you can pass it through to an XP VM for data transfer.
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.
Yeah, the reason for this is that sometimes Debian doesn’t enable Plymouth splash screens by default, so you just see the text stuff. It actually annoys me a bit.
Not on my computer at the moment, so I can’t remember the exact packages you might need, but if I recall, they should be plymouth-themes and kde-config-plymouth (so that you can choose the splash screen theme in your system settings). You can also find other themes online, but I forgot the name of that website where all the stuff is. Pling? I think it’s that.
Anyway, once you have the themes installed, you need to sudo edit /etc/default/grub and append “quiet splash” (with the quotes) to GRUB_CMDLINE_LINUX_DEFAULT= (“quiet” might already be there).
You can also change the value of GRUB_TIMEOUT= in that file to whatever your preference might be for the duration of grub’s boot menu, but there might be other things you need to adjust in order to hide it completely and still be able to access it if necessary.
After that, run sudo update-grub so that it’s using the new config and choose whichever theme you want in the system settings.
Alternatively, grub-customizer is a GUI app that you can install to do all of the above (which will also update grub when you save your changes). Just don’t touch anything that’s not relevant. Stick to just the duration of the grub boot menu and add the splash parameter. Ignore boot priority, etc.
It should feel less “slow” to start up once all that’s sorted.
Yeah, the reason for this is that sometimes Debian doesn’t enable Plymouth splash screens by default, so you just see the text stuff. It actually annoys me a bit.
I always go through and turn off all the stuff that’s covering up the diagnostic information that I want to see, myself.
“The XDNA driver will work with AMD Phoenix/Strix SoCs so far having Ryzen AI onboard.”. So only mobile SoC with dedicated AI hardware for the time being.
Welp…I guess Radeon will keep being a GPU for gaming only instead of productivity as well. Thankfully I no longer need to use my gpu for productivity stuff anymore
I can’t speak for your exact model, but I’m running kubuntu on my old 2012 MacBook Pro (with an upgraded SSD and maxed-out 16 GB RAM). My daily driver is a desktop, but I spend almost as much time on the laptop. It’s a wonderful experience for my use case, and all the hardware is supported “out of the box”.
Maybe try distro hopping a bit to see which experience is best for your usage. Have fun with it!
I have Arch on a 2013 mbp and it has served very well for years. I think I had to do a little work getting the backlight controls bound to some hotkey combos, but that might depend more on DE than distro. I’m probably going to put NixOS on it, since I’m not using it as my work laptop anymore. Use whatever you want! Debian is always a pleasure, too, in my experience.
Unfortunately Debian stable doesn’t ship our bugfix releases after the major Debian version gets tagged - KDE Plasma in Debian is currently at 5.27.5, and 5.27.10 was released upstream two months ago.
In other words, you’ll be experiencing bugs that have long been fixed… I’d advise to stay away from Debian for KDE Plasma because of that. If you want a Debian based distro with a good KDE Plasma experience, KUbuntu is likely a better choice, even with forced snaps. If you don’t need Debian though I’d recommend taking a look at Fedora KDE or Arch (derivatives).
Thanks for the heads up. I do get that faster updates mean a lot to some folks. There is always an argument for more up to date software but one needs to compromise sometimes. Using debian has been great so far and its working better than ubuntu (which might be a configuration issue). I’ll update if stuff starts breaking.
Man, I feel you. Sometimes you just want to get on with your life without babysitting the OS. Debian will stay out of your way and just work. Enjoy it!
I’m not using Windows. I run Debian on this server.
The bulk of external enclosures that money can buy tell the computer they’re plugged into that the disks have logical sector sizes of 4096 bytes, apparently for compatibility with >2TB drives on Windows XP.
I do not need compatibility with Windows XP as the current year is 2024. My disk has logical sectors 512 bytes in size, but the external enclosures don’t report that. I want to know how I can mount the disk anyway, despite the enclosure’s attempts to thwart me. I know the disk is fine, as it is detected with 512 byte sectors and mounts happily via SATA.
Do you really need 512 byte sectors for any specific reason? If not, just drop it back into the PC, backup contents, reformat, copy data back then put it back in the enclosure. Job done.
linux
Oldest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.