Jump to content

dcgreen2k

Member
  • Posts

    1,929
  • Joined

  • Last visited

Awards

This user doesn't have any awards

6 Followers

About dcgreen2k

  • Birthday Oct 01, 2000

Contact Methods

  • Other
    https://github.com/dcgreen115

Profile Information

  • Gender
    Male
  • Location
    Virginia, USA
  • Interests
    Cars, computers, and programming
  • Occupation
    Computer Engineering Grad Student, Cybersecurity Researcher
  • Member title
    Toyota Fanatic

System

  • CPU
    AMD Ryzen 5 5600X
  • Motherboard
    MSI B350M Pro VDH
  • RAM
    4x8GB Corsair Vengeance LPX, 3200 C16
  • GPU
    EVGA RTX 2080Ti
  • Case
    In Win 101
  • Storage
    Samsung 970 EVO, 1TB M.2
  • PSU
    Rosewill SMG 750W, 80+ Gold
  • Cooling
    AMD Wraith Spire
  • Keyboard
    Rosewill Neon K91, Kailh Brown
  • Mouse
    Logitech G303

Recent Profile Visitors

3,240 profile views
  1. I've been meaning to pop an SSD into that system for a while now, might give me a chance to test how it performs without that old hard drive.
  2. From personal experience, you can run GTAV on mostly Low settings and 1280x1024 resolution at a playable FPS with a C2Q Q6600 and GTX 750Ti. The main issue I had was that textures wouldn't load in if you drove around too fast, but that may have been due to the old hard drive in that system. I was even able to run it with a C2D E6700, but the missing textures problem was much worse.
  3. Visited my parents' house and found the CPU my first PC came with, a Core 2 Duo E6700. I remember it being decently capable for work and light gaming, but I eventually replaced it with a Core 2 Quad Q6600 once I graduated from just playing Minecraft and flash games. I still have that system - might pop this CPU back in to see how it fares in 2024.
  4. I bought a Blue Snowball iCE for gaming a couple years back and I've been very satisfied with it. It looks to be around the maximum end of your budget.
  5. That's pretty surprising to me. The majority of the people on my research team use Linux for work, with only a couple on Windows. We don't have any MacOS users. I totally agree with that. This kind of minimal GUI is definitely uncommon - I only know one person who does this kind of thing and he lives inside NixOS and Emacs.
  6. I found this in one of his videos, is this what you're talking about? It looks like he's just using a window manager to get the super clean look. At the top of the screen, you can see he has GitHub open in a web browser and GNU Emacs as his text editor. A lot of the terminal-based work he does seems to be done through Emacs plugins, although I'm not super familiar with it.
  7. I don't think you can customize the default terminal, but you can customize the GUI ones. Everybody uses GUI based terminal emulators because of how much more convenient they are - the functionality is largely the same between the two since they're just bash terminals.
  8. If this is meant to go on your personal machine, I highly recommend keeping the desktop environment. It makes everyday use much easier. That being said, if you'd like to have Debian boot to a terminal by default, run the command: systemctl set-default multi-user.target To have it boot to the GUI, run this: systemctl set-default graphical.target Alternatively, if you want to switch to a terminal from your desktop, use Ctrl+Alt+F* https://wiki.debian.org/Console. On my system, Ctrl+Alt+F3 brings me to a terminal and Ctrl+Alt+F2 brings me back to the graphical environment. If you'd like to keep the GUI but have it use less resources, you can install a lightweight desktop environment. Xfce and Lxde seem to be popular for this.
  9. The first time I ever had to take off/reinstall a heatsink was when I upgraded my first gaming PC's CPU to a Core 2 Quad. I forgot to buy thermal paste so I decided I'd just use the stuff that was already on the old CPU. The problem was that this PC was around 10 years old at the time, so the existing thermal paste was completely dried up. Being excited with one of my first major upgrades, I decided to just scrape off the dried crumbles of thermal paste and scatter them on the new CPU, and surprisingly, it worked. It never thermal throttled and could play games all day long. A few months later, I replaced the dried thermal paste with toothpaste. That also worked great.
  10. I can't say too much about the Windows API, but to answer the question in your title: Yes, libraries written in C++ generally will not work with C code (unless you do things like writing wrappers for the C++ code). In contrast, most "plain" C code can be used in C++ just fine. There are some C features/syntax that aren't valid in C++ though: https://en.wikipedia.org/wiki/Compatibility_of_C_and_C%2B%2B If you want to learn C++, go ahead. I certainly find C++ nicer to use than C for building larger programs, although there's a lot of added complexity for someone new-ish to programming. It also has a much larger standard library compared to C (hooray, generic data structures). As for the Rust vs. C++ argument, it's really up to you to decide. Rust is newer, popular, and has builtin memory safety while C++ is a lot more mature. C++ is my choice because of how common it is in my fields of interest, but I'll get around to learning Rust too someday.
  11. The actual code that gets generated appears to be mostly the same, aside from some differences in how they name things and manage the stack. The lines with INCLUDELIB in the MSVC version are likely directives for the linker. LIBCMT is just the system's C library and OLDNAMES seems to be a compatibility layer for Windows: https://devblogs.microsoft.com/oldnewthing/20200730-00/?p=104021
  12. Memory error checkers are used very often, and UBSan seems to be the most popular currently. I believe the usefulness of those tools is somewhat tied to how good the project's architecture and testing practices are. If you thoroughly test a module as soon as you write it, it's easy to pinpoint errors and fix them before they propagate to later parts of the project. On the other hand, if you wait to write any tests, have sparse tests, or write spaghetti code, then going through a list of errors, fixing old code, and making sure nothing breaks is going to be a painful process.
  13. I agree - there are tools to help find and debug these kinds of errors like valgrind and ubsan, but it's better to use a language that prevents them entirely for important applications. I remember one of my cybersecurity professors mentioning how he switched most of his department's new developments to Go for this reason. That certainly seems like what's going to happen. I know embedded systems development has an incredibly high concentration of C and C++ code due to speed and memory constraints, but there's been growing interest in Rust toolchains for the popular MCUs.
  14. Can confirm. When you get down to the level of C and C++, all accesses to heap memory and things like passing variables by reference require pointers. If you go down a level further to assembly, ALL memory accesses require pointers, both to the stack and the heap. Languages like Java and Python still use pointers, they just do a good job of hiding it from you.
×