- 0 Posts
- 52 Comments
[…] there were rumours some French guy got arrested and had his LUKS encryption fail on him, so you never know.
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!)
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/binis 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
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
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’: https://gitlab.com/users/sign_up
that said they’re shit and need to die
- It supports a lot of atifact repository formats while GitLab only docker registry.
not true https://docs.gitlab.com/ee/user/packages/package_registry/supported_package_managers.html
that said, I hate gitlab and their commercial choices, they must die
hahaha I swear to you that seeing you strain so hard to push your fallacies who knows where makes me laugh. Believe it or not, there remains a world of people out there laughing at those who use this garbage, and your social media woes will not, as usual, shift half an ounce of reality :) believe it or not, lemmy is not reality, outside those servers there is a real world :) but please, feel welcomed to keep supporting I don’t know what theory, you’re welcome, at least at this party :PP
lol I’m not defensive at all hahahaha rest assured my opinions aren’t changed by such a stupid zealot conversation, also this fact you don’t entirely read comments you’re replying about contibute to the lulz. Don’t react too bad to the money thing, one day or another you could also start working in this industry but if I could choose I’d go w/ dog training (I’m speaking for me, I’d really go that way). Cheers my friend
tbf, flatpaks are problematic shit noobs tend to appreciate because reasons. That said, beside the fact steam ships its own chroot, I’m a happy sid user and I don’t even have this imaginary problem of things being ‘very old’ sooo … but I can confirm you shouldn’t add weird third party repos or shitty flatpaks :)
nginx is no acronym or other shit you bad bot :P