figured it out, solution in one of the comments I replied to… basically my laptop was non-discoverable by default and there is no setting in the system to make it discoverable
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.
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 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.
No - I’ve been working on a headless server, and ideally I need this thing to be written into /etc/fstab and work reliably from the command line. I could plug the drive into my laptop to have a look in some GUI tools if you think there’s one around that can circumvent the sector size mismatch, but in the end I’ll need a CLI method.
Gotcha. Worst case, if you can mount it using any tool (GUI or CLI), then maybe you can copy its contents to another drive, reformat it, and copy the contents back.
Surge XT is a must. Best FOSS synth there is IMO. 3 oscillators in 2 scenes. Filters, effects, all the LFOs and envelopes in the world, all the modulation, expression aftertouch, etc you need. A bunch of presets out of the box. Very flexible synth, though can be a bit learning curve to get going.
Honorable mentions to Dexed (basically a software DX7), GeonKick (for synthesizing drums), and pianoteq (proprietary, but best there is in piano synth with native linux support).
I am mostly a windows user these days, but fifteen years ago I ran Linux as my main OS.
I ran Ubuntu on a Dell Latitude E5400, at first I ran Gnome 2 or KDE 4 as my DE, but got annoyed with how much vertical space they used, so I learned how to use Fluxbox.
Fluxbox is great, a small stacking WM, that is easy to configure and worked like I wanted it.
I still set it up to run gnome-settings-daemon as I had no idea on how to do apply a GTK theme without it.
The really annoying part of running fluxbox as a WM was that I never figured out how to shut down the computer from a menu, it allways complained about me not having permissions to shut down the computer, so I used to do a log off and before the GDM login screen loaded I could press the power button on the laptop and have it shutdown the computer gracefully, timing was key, but it worked.
The whole WM landscape of Linux was a big turn off for me. I had used CDE on Solaris before and never really thought about choosing or customizing my DE. That was one of the big reasons I ended up loving OSX (no choice of WM and very few customization options, along with globally consistent hotkeys) and ended up using that as my primary GUI Unix environment, along with headless Linux for most of the last ~20 years.
Right. Actually one of the things I love about Linux is that it offers so many options so you can make your own combination to create the perfect system for your specific needs.
You can get all the visual distractions out of your way and tweak litterally everything to an incredible granular level. No other OS can pretend to be so user focused while staying so simple in appearance. You’re not adapting to your system, it’s built for you.
The problem I have with customization options is that I don’t want to customize it, and when I go looking for a setting to change, I don’t want to be drowning in options that I’ll never use. The way I always thought about it is when I buy a saw or a hammer, I go straight to using it. I don’t customize my saw or hammer. That’s not why I buy them. I buy them to build things with them. The tool is not the end goal. Similarly, the DE is not the end goal. I want to spend time getting work done, not spend time customizing my environment.
Recently though I’ve been looking around again a little bit, looking for a DE that has what I want out of the box. LXDE seems closest so far.
We’re exactly on the same page: “the tool is not the goal”. The only difference may be that I see chosing options for an app as options for a tool. If I want to cut wood or metal I need a different saw. Even though the tool is basically the same it doesn’t serve the same purpose. Hence I configure options once and for all, like I would consider which hardware I need exactly in terms of use, ergonomic, power… before buying it.
I don’t spend time tweaking the look of a tool because it’s doesn’t fit my approach of things anymore. As such I don’t even use a DE. But I feel the need to build the right tool (i.e. system app) I need to perform a job as efficiently as possible while keeping the tool itself minimalist and as invisible as possible. On my daily use I have tools that I couldn’t live without anymore but if you ask me a list I will either forgot them or put them at the bottom because I will not think about them right away since they became a second nature.
I certainly see the comfort of the out of the box approach and it can serve a lot of people. In my use case I just realize that - using the example above - it could be like using a wood saw on metal in some cases. It may work but not as good as you would expect to have the job done properly. Also, the fit them all approach means building an app with tons of options activated and I prefer to have available to me only the options I really need. The philosophy feels less bloated to me and I’m not overloading my system with stuff I’ll never use. It’s more time consuming at first to chose the right app but with time it became quick enough and it definitely save me way more time in the long run when I use my system.
The zones are there so you can set your ports/services as needed for home, work, public wiffi etc. the idea is you leave your ports alone and just swap adapter to the zone you are working in. Network Manager has a quick toggle on wifi to do this from connection settings. So at home your laptop has ssh, smb open etc, when you connect to starbucks wifi you set wifi to public. The other part of zones is each as a fallback default you can specify. So if a port or service traffic doean’t match your home zone you can have if failover to default, in my case default is public. if that doean’t match either it can failover to “drop” or “block” etc. they have a heirachy.
if you are just dealing with cli it can be intimidating. You can try OpenSUSE in a VM and use the Yast Firewall Gui tool to play around with adapter, default, zones, services and ports and get familiar with the idea behind it.
I believe you may have misinterpereted my post. I wasn’t asking why zones exist, I was asking specifically why one cannot delete the default zones in Firewalld.
I see. I guess my point was they exist for a reason, as the default target of one zone handsover to the next zone (target) and then its target, in order to handle traffic not in your zone rules. Maybe you know that already. If you have a static machine at work mayne you don’t need home zone, but it is not causing “bloat”. You would also still need drop, block and so on. My thought is if you think firewalld is bloat, just use iptables directly.
I see. I guess my point was they exist for a reason, as the default target of one zone handsover to the next zone (target) and then its target, in order to handle traffic not in your zone rules.
Yes, I am aware of that. Just allow the user to specify the zones though. Why force the default ones?
but it is not causing “bloat”.
It is if it’s saving alternative configuration that will never be used.
It makes sense for them to include the Reject, drop, type for obvious reasons, the others seem like they asked “what will be the most common use cases for networks?” so they threw them in as work, home, public and trusted, external, dns , etc so that somebody starting out doesn’t have to create zones from scratch. I doubt having one extra zone takes up very much in the way of kb of space. compared to how much junk I have in my downloads folder that i should triage. What would be nice though would be a rename function, because we may have different Work rules depending on which workplace you are at that day with a system.
linux
Top
This magazine is from a federated server and may be incomplete. Browse more on the original instance.