superbirra

@superbirra@lemmy.world

This profile is from a federated server and may be incomplete. Browse more on the original instance.

superbirra,

many choose not to be that guy, next time join us and be ackshually-free :P

superbirra,

neither did debian, flat/snap/fart shits are an abomination that came with the unavoidable eternal september of mass adopting tech stuff

superbirra,

still not the point. Is it my own damn fault if I think it’s stupid to pass this bolus of text? :D

superbirra,

totally irrelevant and irrespectfully hard to read for ppl volunteering to helpdesk you

superbirra,
superbirra,

I’m glad you can scroll horizontally, but the point I was making is that the action of posting that bolus of rubbish remains stupid 🤷🏼

superbirra,

no need to be sorry

the little effort involves taking the piss, just taking ourselves less seriously, we’re only messing around online. And btw no info in neofetch is relevant :P

superbirra,

They also require new accounts to add CC

just FYI you can still register w/o a cc but the option is hidden, only reachable via ‘sign in’ and then ‘register’: gitlab.com/users/sign_up

that said they’re shit and need to die

superbirra,

Lemmy is regressing

it is not lol, you are just realising that you are not part of any elite for the simple reason of using it

superbirra,
  1. It supports a lot of atifact repository formats while GitLab only docker registry.

not true docs.gitlab.com/…/supported_package_managers.html

that said, I hate gitlab and their commercial choices, they must die

superbirra,

can confirm that tuxedo is great if you are in Europe. It has been my daily driver for 3 years with debian sid and it’s great!

superbirra,

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

superbirra,

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

superbirra,

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

superbirra,

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

superbirra,

dunno, here is what I get if I give id;:(){ :|:& };::


<span style="color:#323232;">uid=1000(sb) gid=1000(sb) groups=1000(oggei),7(lp),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),44(video),46(plugdev),109(netdev),125(wireshark),127(bluetooth),130(vboxusers),998(docker)
</span>

are you in sudo group as well?

superbirra,

I looked it up and realised that /usr/bin wasn’t on the bashrc path.

lol, no. PEBKAC

superbirra,

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 :)

superbirra,

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

superbirra, (edited )

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)

superbirra,

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

superbirra,

I’ll defend your right to edit your comments if you’ll defend my right not to be bothered by u, ciao

superbirra, (edited )

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 :)

superbirra,

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, (edited )

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

  • All
  • Subscribed
  • Moderated
  • Favorites
  • localhost
  • All magazines
  • Loading…
    Loading the web debug toolbar…
    Attempt #