Programming thread

[DavidS877]

Has anyone had to deal with borderline braindead "security auditors"?

Yes.
From stuff like:

"This system has the telnet client installed, that's insecure." "You do realize it doesn't do anything, it just sits there." "Must remove" "Fine, can we install 'nc/NetCat' instead" "Sure"

"This port is open, it's a security vulnerability." "It's a vulnerability on Windows, this is a Linux system and we chose that port for one of our own apps." "Oh, ok" ... next audit ... "This port is open...."

"Stop using insecure SSL ciphers." "We checked the logs, half our idiot clients are still using those." "Well, the checklist says...." Talk to people for approvals, go to tons of meetings, finally get variance.

Then they send you the 200 page report without even bothering to filter by OS or version or verify that it's not patched. 50 pages of Windows vulnerabilities on Linux. 140 more that a real version check would show as patched, RedHat was especially bad for this as they'd backport fixes to versions still listed as vulnerable. 2.3.4 is vulnerable, must upgrade to 2.4.0, but RedHat made 2.3,4-rh1 and patched it but the idiot scanners, and the humans who were supposed to verify the report totally ignored it. 10 pages of maybe actual real stuff.

 

[CrunkLord420]

But MD5 isn't cryptographically secure, sounds like a complaint about not wanting to rehash stuff. I think webshitters like to build versioning into their password hashes, so they can change out the cipher over time. If you truly don't need cryptographical hashing (which you probably do if you're doing file transfers), MD5 is a bad choice when there's fast stuff like xxhash. When I did some contributing to sneedforo I pushed for using blake3 largely for performance reasons. Though, some CPUs have hardware sha256 support.

 

[inception_state]

It really depends on the kind of audit. A lot of places just want an audit that will check the "we were audited" box, either as an ass-covering mechanism or for insurance reasons. Those tend to be garbage, because the company will just hire a company that is cheap or has slick marketing, and they will return a couple hundred pages of auto-generated junk based on automatic scanning tools.

f you truly don't need cryptographical hashing (which you probably do if you're doing file transfers), MD5 is a bad choice when there's fast stuff like xxhash. When I did some contributing to sneedforo I pushed for using blake3 largely for performance reasons. Though, some CPUs have hardware sha256 support.

It depends on the channel being used to transfer the data, and they said it's TLS, so really it should be fine with MD5. If the data channel is busted it doesn't matter what hash you use, because then the attacker can theoretically just MiTM and insert the malicious data, along with a new hash computed on the malicious data. The one edge case there is if the hash is being transmitted via a secure data channel and the large file is not, which I suppose is possible (eg. someone forgot to set TLS=true for the data transfer, but the hashes are downloaded separately from a website). Then it might be possible to craft a useful hash collision. It depends on the underlying data though, because being able to generate a hash collision is different from being able to generate a useful collision. If it really matters that's when you get into stuff like code signing.

 

[wtfNeedSignUp]

I like programming but I hate my algorithms class so fucking much this shit is so gay. I like every other aspect of CS, I just can't into NP Complete reductions and Dynamic Programming to save my life.

Both are mainly doing a number of examples until you memorize the process. Dynamic Programming is just saving solutions along the way of some easier to reach places. NP complete reductions are more annoying (and I don't remember as much) but it's just doing enough examples until everything you encounter is just a variation.

 

[Strange Looking Dog]

I recently gave unity's job system a try, and it's kind of cool, but I really wish it didn't have all the stupid restrictions on referencing managed types from jobs. Like, sure managed types can't have as good cache contiguity as unity's bespoke allocator, but the restriction makes onboarding infinitely more difficult than it needs to cause you basically have to rearchitect everything just in order to begin using jobs at all. I'll even take responsibility for my race conditions! You don't need to protect me from myself!

 

[Fcret]

Has anyone had to deal with borderline braindead "security auditors"?

Yes, inside the Java world there's a currently a massive kerfuffle because the move from Spring 5 to Spring 6 feels like it's being forced by these retarded security auditing suites all the big corpos buy. The issue at hand is CVE-2016-1000027 which can result in RCE if you use Spring Web 5.x in a specific way to deserialize data. Instead of doing code analysis to figure out if you're actually using Spring Web 5 in an unsafe way though, shit like Sonar and AquaSec all just check the dependency graph of your project and mark it as CRITICAL if you use Spring Web 5 at all.

Complete niggercattle security theater but we still have to waste time doing the upgrade because fancy tool says so.

 

[Inafune Fanfiction]

Yes, inside the Java world there's a currently a massive kerfuffle because the move from Spring 5 to Spring 6 feels like it's being forced by these retarded security auditing suites all the big corpos buy. The issue at hand is CVE-2016-1000027 which can result in RCE if you use Spring Web 5.x in a specific way to deserialize data. Instead of doing code analysis to figure out if you're actually using Spring Web 5 in an unsafe way though, shit like Sonar and AquaSec all just check the dependency graph of your project and mark it as CRITICAL if you use Spring Web 5 at all.

Complete niggercattle security theater but we still have to waste time doing the upgrade because fancy tool says so.

I just want to git gud with C++. Then most resources and books skip a few steps going from arrays to data structures and skimp over things like header files.

 

[DavidS877]

I just want to git gud with C++. Then most resources and books skip a few steps going from arrays to data structures and skimp over things like header files.

How to git gud with C++: Learn C

Stroustrup disagrees with me, but has a good FAQ here:

https://www.stroustrup.com/bs_faq.html

And, being the guy who literally wrote the language, I'd recommend at least taking a look at his book if you haven't:

https://www.stroustrup.com/4th.html

Also maybe this one, but I've never read it:

https://www.stroustrup.com/programming.html

 

[DiggieSmalls]

I just want to git gud with C++. Then most resources and books skip a few steps going from arrays to data structures and skimp over things like header files.

I know. I also wish more classes went over the build system from the ground up since its such an integral part of the language.

 

[Strange Looking Dog]

How to git gud with C++: Learn C

Stroustrup disagrees with me, but has a good FAQ here:

https://www.stroustrup.com/bs_faq.html

And, being the guy who literally wrote the language, I'd recommend at least taking a look at his book if you haven't:

https://www.stroustrup.com/4th.html

Also maybe this one, but I've never read it:

https://www.stroustrup.com/programming.html

Eh tbh I'd start with C++ and work backwards to C once you're comfortable with it. I've been tutoring a friend in C and shit like printf is a major stumbling block. C++ makes the essential stuff a lot easier to pick up. For example it's way easier to explain that << means "send this to that" than what an escape sequence or format specifier mean and do.

Now I'm talking starting from absolute basics, if they have a background in other languages you can probably go straight to C no problem.

 

[Rusty Metal Skull Gun]

Eh tbh I'd start with C++ and work backwards to C once you're comfortable with it. I've been tutoring a friend in C and shit like printf is a major stumbling block. C++ makes the essential stuff a lot easier to pick up. For example it's way easier to explain that << means "send this to that" than what an escape sequence or format specifier mean and do.

Now I'm talking starting from absolute basics, if they have a background in other languages you can probably go straight to C no problem.

I see where you're coming from, but I disagree. So much of C++ is going to seem like magic if you don't understand C. I think printf is simpler than std:: cout for newbies, as the latter manages to be both ugly and inconsistent.

 

[Fcret]

I just want to git gud with C++. Then most resources and books skip a few steps going from arrays to data structures and skimp over things like header files.

There's nothing that special about header files. They just declare things. Your .c files contain your actual function definitions and your .h files contain the declarations that they exist so the compiler can be satisfied. The only real 'trick' you need to learn for headers is include guards.

 

[Strange Looking Dog]

I see where you're coming from, but I disagree. So much of C++ is going to seem like magic if you don't understand C. I think printf is simpler than std:: cout for newbies, as the latter manages to be both ugly and inconsistent.

From my (somewhat limited) teaching experience actually understanding what either printf or cout takes a pretty large foundation that is out of scope for a beginner, and yet you need to know how to use them in order to learn anything else in the language. It's pretty much expected that the learner will see them as magic initially, even necessary that they do so. They're not going to understand printf either for quite some time, so they might as well do the initial part of their learning with more intuitive "magic".

Additionally, if the learner is remotely engaged they'll probably have questions about how printf works, what the format specifiers are, what they mean, why they're needed... and they'll probably ask these questions fairly early on. An explanation is inevitably going to have to touch on varargs (a relatively obscure feature to begin with) just to explain the semantics of the function; imagine having to explain varargs —even in general terms— to someone hasn't even really encountered pointers yet. With streams these questions just don't even come up. That passing an integer into cout should cause an integer to be printed to the console seems fairly self explanatory.

Keep in mind I'm not arguing that understanding cout as a whole is easier than printf —printf is definitely less complicated in terms of implementation— I'm only arguing that understanding the semantics of cout is easier than that of the semantics of printf; and for a beginner that's what's important.

 

[DavidS877]

From my (somewhat limited) teaching experience actually understanding what either printf or cout takes a pretty large foundation that is out of scope for a beginner, and yet you need to be able to use them in order to learn anything else in the language. It's pretty much expected that the learner will see them as magic initially, even necessary. They're not going to understand printf either for quite some time, so they might as well do the initial part of their learning with more intuitive "magic".

Additionally, if the learner is remotely engaged they'll probably have questions about how printf works, what the format specifiers are, what they mean, why they're needed... and they'll probably ask these questions fairly early on. An explanation is inevitably going to have to touch on varargs (a relatively obscure feature to begin with) just to explain the semantics of the function; imagine having to explain varargs —even in general terms— to someone hasn't yet even really encountered pointers. With streams these questions just don't even come up. That passing an integer into cout should cause an integer to be printed to the console seems fairly self explanatory.

Keep in mind I'm not arguing that understanding cout as a whole is easier than printf —printf is definately less complicated in terms of implementation— I'm only arguing that understanding the semantics of cout is easier than that of the semantics of printf; and for a beginner that's what's important.

If "printf" is too complicated I'd suggest they go to a real language, like BASIC. Maybe on a ZX-81 where all the keywords were printed on the keyboard so they can't misplace the list because they probably would just gnaw on the book if you gave them one.

You don't need to know how it's implemented to use it, and you certainly don't need to know how to use varargs or even what they are other than "yes, printf can take multiple arguments, it says that in the book, you did read the book didn't you?" Or the examples section of man 3 printf

You'll generally encounter pointers on about your second day with C, and how to implement varargs much much later.

 

[Fcret]

printf is soykaf and iostream is overengineered

you put 1 in rax, 1 in rdi, and the pointer to your string in rsi and then slam that mf syscall instruction

 

[DavidS877]

printf is soykaf and iostream is overengineered

you put 1 in rax, 1 in rdi, and the pointer to your string in rsi and then slam that mf syscall instruction

LDA #$20
JSR $FFD2
rinse, repeat

 

[DagothUr]

Is programming some kind of dark art that only certain people (autist) can do?
I don't mean super leet-trannydev, optimized x86 ASM or weirder stuff like functional programming / oop. Just being able to look at:

nigger = INPUT
PRINT nigger

and at least sort of understand what is happening.

When I was doing computer science GCSE some years ago almost nobody could do even the most trivial exercises in python without great effort and constant hand-holding. It's like they would look at the tutorial sheet (which just has the answer and a basic description) and mentally shut-down and block it out when they see funny looking brackets and shit.

And when they actually write their own code from a brief it goes without saying that it just didn't happen. They would have to have it done for them. Which just means they wouldn't learn anything.

It goes beyond just having trouble getting used to the more rigid and foreign syntax of programming languages and just
I remember one time we were asked to write a simple python program that asked your name then printed it back out with some flavour text.
And this one nigger just hardcoded his name into the print statement and didn't see any problem with it.

Are normies just incapable of understanding?

 

[Strange Looking Dog]

If "printf" is too complicated I'd suggest they go to a real language, like BASIC. Maybe on a ZX-81 where all the keywords were printed on the keyboard so they can't misplace the list because they probably would just gnaw on the book if you gave them one.

You don't need to know how it's implemented to use it, and you certainly don't need to know how to use varargs or even what they are other than "yes, printf can take multiple arguments, it says that in the book, you did read the book didn't you?" Or the examples section of man 3 printf

You'll generally encounter pointers on about your second day with C, and how to implement varargs much much later.

The limiting factor in this case isn't intelligence, it's knowledge and you're looking at this from the perspective of an already experienced programmer. It all seems pretty simple in retrospect, but for someone who is literally brand new to programming —the guy I was teaching had never even opened a terminal before— the ways that you do even basic things in C can frequently be less intuitive than the C++ equivalents. Sure, maybe it's technically all the same shit under the hood, and "back in my day..." but posturing is irrelevant to the concerns of actually learning the language. Once you know one, you'll have a very good foundation for the other, so you might as well start with whichever language that offers the easiest onboarding process.

I learned C++ when I was fifteen (quite some time ago) and actually teaching somebody else the craft has been eye opening in terms of the amount of unconscious information which I know, but don't know that I know.

printf is soykaf and iostream is overengineered

you put 1 in rax, 1 in rdi, and the pointer to your string in rsi and then slam that mf syscall instruction

It really is a shame that the stream libraries were produced during cpp's manic OOP phase. Still though, the ability to create formatting overloads is a massive advantage over the C equivalents in practice. Lends itself to easier code reuse and much more legible formatting.

Is programming some kind of dark art that only certain people (autist) can do?

I mean sort of, if you can't think abstractly then it's just a total nonstarter. As it happens, a lot of people don't think abstractly very well, but you def don't have to be a sperg either.

 

[Rusty Metal Skull Gun]

Is programming some kind of dark art that only certain people (autist) can do?
I don't mean super leet-trannydev, optimized x86 ASM or weirder stuff like functional programming / oop. Just being able to look at:

nigger = INPUT
PRINT nigger

and at least sort of understand what is happening.

When I was doing computer science GCSE some years ago almost nobody could do even the most trivial exercises in python without great effort and constant hand-holding. It's like they would look at the tutorial sheet (which just has the answer and a basic description) and mentally shut-down and block it out when they see funny looking brackets and shit.

I've heard similar things before. It does appear that, for whatever reason, a large chunk of the population isn't capable of understanding even trivial programming stuff. It's weird.

Additionally, if the learner is remotely engaged they'll probably have questions about how printf works, what the format specifiers are, what they mean, why they're needed... and they'll probably ask these questions fairly early on. An explanation is inevitably going to have to touch on varargs (a relatively obscure feature to begin with) just to explain the semantics of the function; imagine having to explain varargs —even in general terms— to someone hasn't even really encountered pointers yet. With streams these questions just don't even come up. That passing an integer into cout should cause an integer to be printed to the console seems fairly self explanatory.

But by the same token, a proper discussion of std:: cout will include namespaces, the overloading of the << operator, what << means when it's not overloaded, whatever the fuck std:: cout is in the first place (a global object??), how std:: endl flushes the buffer...

I'm looking forward to std:: print in C++23, which should make everybody happy.

 

[std::string]

Once you know one, you'll have a very good foundation for the other, so you might as well start with whichever language that offers the easiest onboarding process.

This is why I think the concept of "learning a language" is ultimately pointless and why a lot of students struggle with programming courses. Congratulations you made a Python program that asks your name and repeats it to you. That's boring as fuck, who cares.

If I was designing a programming course it'd just be head first into using Python to analyze real world data sets. How many people diagnosed with type 2 diabetes require a below-the-knee amputation? Of those, what's the mean time between diagnosis and amputation? Does the patient's age at the time of diagnosis influence this? etc.

I'm of the mindset that if you give people real problems to solve they're going to be much more interested and they'll accidentally learn to program along the way.