Shitpost so hard they cannot tell when you actually got brain disease, it's a really long-term bit.
Timeline
Post
Remote status
Context
22
@w0rm I'm about to save some people who wouldn't give me the time of day a couple months ago
@graf thank you for always being a friend to us. I hope you are not meaning us as qpeople who wouldn't give me the time of day.
@w0rm no, I am helping people who deserve it, you deserve my time but p seemed busy, I can call you personally while I do this work if you'd like
@eriner @w0rm @graf
> lets be real, all interpreted languages are dog shit slow.
Haskell's compiled, but find a Haskell program that is faster than the equivalent awk.
Not the case, no. Ruby isn't even that slow, but Rails does retarded shit like blowing out the method dispatch cache multiple times per *request*, it's all factoryfactories. I *just* said "things written in the same language that do not use Rails". I do not think you know how goddamn retarded Rails is. Ruby's a great language if you're not an idiot; unfortunately, it got popular with idiots, and I watched this happen, having used it before Rails existed. (Luckily, most of the idiots left for JS, but a handful of total dipshits have stuck around.)
> bash & /dev/tcp
bash is terrible and their "/dev/tcp" bullshit is terrible and netcat is not hard.
> lets be real, all interpreted languages are dog shit slow.
Haskell's compiled, but find a Haskell program that is faster than the equivalent awk.
Not the case, no. Ruby isn't even that slow, but Rails does retarded shit like blowing out the method dispatch cache multiple times per *request*, it's all factoryfactories. I *just* said "things written in the same language that do not use Rails". I do not think you know how goddamn retarded Rails is. Ruby's a great language if you're not an idiot; unfortunately, it got popular with idiots, and I watched this happen, having used it before Rails existed. (Luckily, most of the idiots left for JS, but a handful of total dipshits have stuck around.)
> bash & /dev/tcp
bash is terrible and their "/dev/tcp" bullshit is terrible and netcat is not hard.
@p @w0rm @graf I never said "compiled languages are always fast", I said all interpreted languages are slow.
> bash is terrible
I mean, I use zsh, but when you want a reverse shell you have to use what's there, and bash usually is. Sometimes for one reason or another it can't be done with bash, but most systems that have bash also have perl. IIRC most distro distributions of nginx include perl as a runtime dependency.
@eriner @w0rm @graf
> I never said "compiled languages are always fast", I said all interpreted languages are slow.
It's still wrong.
> I use zsh
"The only shell worse than bash, until fish got popular."
> when you want a reverse shell you have to use what's there, and bash usually is
They have an entire /bin/sh.
> IIRC most distro distributions of nginx include perl as a runtime dependency.
Half of them nowadays mandate Python. Almost any box is going to have Python.
> I never said "compiled languages are always fast", I said all interpreted languages are slow.
It's still wrong.
> I use zsh
"The only shell worse than bash, until fish got popular."
> when you want a reverse shell you have to use what's there, and bash usually is
They have an entire /bin/sh.
> IIRC most distro distributions of nginx include perl as a runtime dependency.
Half of them nowadays mandate Python. Almost any box is going to have Python.
it isn't always about what's present, but various runtime restrictions that you have to test. Sometimes it works, sometimes acls and policy flag/prevent weird shell interactions that are commonly "malicious", such as /dev/tcp interaction. Though, zsh's (if present) tcp module often isn't ;)
Unless the app is written in python and using it for runtime, my experience is that python is far more rare than bash or perl.
@eriner @w0rm @graf
> various runtime restrictions that you have to test. Sometimes it works, sometimes acls and policy flag/prevent weird shell interactions that are commonly "malicious", such as /dev/tcp interaction
It's not even a real /dev; gawk (almost certainly present) has a different, incompatible /inet/{tcp,udp}/$shit and is almost guaranteed to be present and probably overlooked if zsh is.
> my experience is that python is far more rare than bash or perl.
bash maybe because I don't know of anyone that *doesn't* ship bash, but Debuntu requires Python nowadays, I believe CentOS/RHEL require it.
> various runtime restrictions that you have to test. Sometimes it works, sometimes acls and policy flag/prevent weird shell interactions that are commonly "malicious", such as /dev/tcp interaction
It's not even a real /dev; gawk (almost certainly present) has a different, incompatible /inet/{tcp,udp}/$shit and is almost guaranteed to be present and probably overlooked if zsh is.
> my experience is that python is far more rare than bash or perl.
bash maybe because I don't know of anyone that *doesn't* ship bash, but Debuntu requires Python nowadays, I believe CentOS/RHEL require it.
Replies
8
@phnt @eriner @graf @w0rm This shit I do not get; Python is a pain in the ass, it's not as convenient for scripting as the shell or Perl or Ruby, and it's not stable. A shell script or a C program from the 80s will often still work now, Ruby code that I wrote for 1.6 still works in 3.x; even *JavaScript* manages backwards-compatibility. Good luck getting a Python program from last year to build cleanly without guessing which Ubuntu version that guy was running and then building in a chroot.
@p @w0rm @eriner @graf I don't know how Python can make so many breaking changes in every minor release bump, it's beyond my understanding. The reason why it is so prevalent in core systems utils now is that it was bundled with OSes by default at some point and then using Ruby for system utils became a "It's better, but you would need to download a whole new language instead of using the one in the OS already. So we'll use the worse option that comes with the OS." It's one of the reasons why I don't really use Ruby myself either; most things are either posix shell or Python.
Ruby also didn't and still doesn't have a good reputation when it comes to speed, but not like Python is any better with its arrays. Python sidestepped the issue by bolting more C libraries to it.
Ruby also didn't and still doesn't have a good reputation when it comes to speed, but not like Python is any better with its arrays. Python sidestepped the issue by bolting more C libraries to it.
@phnt @w0rm @p @eriner @graf
> I don't know how Python can make so many breaking changes in every minor release bump, it's beyond my understanding
On that exact topic: there are unpatched CVEs in Python (edit: releases; they fixed in master or whatever) right now because they're concerned that fixing the CVEs would be a breaking change.
except the only explanation for wanting that behavior is to use the vulnerability
> I don't know how Python can make so many breaking changes in every minor release bump, it's beyond my understanding
On that exact topic: there are unpatched CVEs in Python (edit: releases; they fixed in master or whatever) right now because they're concerned that fixing the CVEs would be a breaking change.
except the only explanation for wanting that behavior is to use the vulnerability
@phnt @eriner @graf @w0rm
> "It's better, but you would need to download a whole new language instead of using the one in the OS already. So we'll use the worse option that comes with the OS."
Yeah, I can see picking Python over Perl 5; just *barely*, though.
> Ruby also didn't and still doesn't have a good reputation when it comes to speed, but not like Python is any better with its arrays.
Well, reputation rather than actual performance.
On the other hand, 99% of the times you use any scripting language and 90% of the time you use an application- or systems-programming language, if it's CPU-bound instead of I/O-bound, you've fucked up.
> Python sidestepped the issue by bolting more C libraries to it.
Yeah, and "This looks better when I'm typesetting my paper" cascades into an ecosystem.
> "It's better, but you would need to download a whole new language instead of using the one in the OS already. So we'll use the worse option that comes with the OS."
Yeah, I can see picking Python over Perl 5; just *barely*, though.
> Ruby also didn't and still doesn't have a good reputation when it comes to speed, but not like Python is any better with its arrays.
Well, reputation rather than actual performance.
On the other hand, 99% of the times you use any scripting language and 90% of the time you use an application- or systems-programming language, if it's CPU-bound instead of I/O-bound, you've fucked up.
> Python sidestepped the issue by bolting more C libraries to it.
Yeah, and "This looks better when I'm typesetting my paper" cascades into an ecosystem.
@p @w0rm @eriner @graf We need this, but for Python and its indentation.
i_do_not_care_for_javascript-semicolon-insertion.jpg
i_do_not_care_for_javascript-semicolon-insertion.jpg
