Jump to content
Search In
  • More options...
Find results that contain...
Find results in...


  • Content Count

  • Joined

  • Last visited


This user doesn't have any awards

About DevBlox

  • Title

Profile Information

  • Location
    Somewhere in East Europe
  • Gender
    Not Telling
  • Interests
    Enterprise technology, software development, security


  • CPU
    AMD Ryzen 7 3700X
  • Motherboard
    MSI A-PRO X570
  • RAM
    Corsair Vengeance LPX DDR4 4x8GB
  • GPU

  • Case
    be quiet! Pure Base 500 Window
  • Storage
    512SSD + 2TB HDD
  • PSU
    Corsair CX650M 650W
  • Display(s)
    LG 34WL750-B
  • Cooling
    Stock Wraith cooler
  • Keyboard
    CM Storm mechanical (brown switches) + Microsoft Sculpt
  • Mouse
    Steelseries Sensei + Microsoft sculpt mouse
  • Sound
    Audio-technica ATH-M50x
  • Operating System

Recent Profile Visitors

1,169 profile views
  1. Next up - using jpeg for network compression. On a more serous note - deflate will not be quick enough network traffic. It's not a good idea. Yes, it yields a better compression ratio, but it's relatively slow speed will *insert a more violent/expressive phrase for 'utterly destroy'* the performance of a network. That's based on compression benchmarks on larger files (can't find any other sources at the moment), so what you will see does depend on a lot of factors. If there's any seriousness to this - it must be thoroughly benchmarked. That might be: compression ratios, added lat
  2. Since I haven't really worked with a domain language like C# or Java in a long time, I've been using VSCode, and more recently nvim (just vim basically). They're great for pretty much every language that does not rely on IDE automation too much (both of those can perform those functions too, but not out-of-the-box, needs some time to set up usually). Suits my needs well, because of the languages I use. Otherwise, I've used Jetbrains tools in the past, and I've found them great. If I was to jump back into C# or Java, I'd probably use them. I wouldn't exactly want to, but those langu
  3. Multiple implementations for the same operation and then checking for support at runtime.
  4. Here's a start: https://www.gnu.org/software/libc/manual/html_node/Using-Pause.html Obviously daemons are usually not that simple, and are often multi-thread or multi-process (forking) systems. But this should be enough for the thread that listens for OS signals for starters at least. Graceful shutdown is the harder part of the daemonization IMO. Harder to do properly that is.
  5. CPU wise, I get much better performance on my tasks for a much better price. Threads is what I need, and higher-end AMD CPUs have plenty. They have Intel so far back in the dust in this regard it's crazy. GPUs are not as competitive (feature-wise especially), but I've still got one. That's because I run Linux and I don't even need to install drivers on my system, AMD cards have that perk there.
  6. Everyone would probably argue about what programming language to write it in lol. Then end up implementing it in 5 different languages after arguing for days/weeks on the forum and not coming to a compromise. Monkey's paw this `CALLING ALL coders...` thing be. Manufacturers do tend to do this stupid *bleep* of not allowing other programmers to use their integrated 'auxiliary' hardware easily. This area will always stay fragmented until they have some standard in place (read: never). Best solution to that is throwing every RGB part you have into the bin and setting it on fire. And i
  7. In any sort of practical terms and to scale - no. The amount of different knowledge areas and time for development and testing needed to achieve any sort of stability is not at all possible by a small team. You can make a game engine that suits the game you're working on, and that's not a bad thing at all, but you will not achieve what UE achieved AND have a game. The motivation to try to match UE from the get-go is an ill one. You would not be able to keep it going. And if the goal is to make a game, you'd waste a lot of time and effort and not have the game completed before you'd
  8. If it'll build on Linux, I'd sure have a try.
  9. Master Python first. You'll just make it harder for yourself if you try to learn C on top of that, it's a completely different beast, Java is yet another different beast from both of those. In regards of language/level of abstraction/technology specifics at least. You'll get lost in the details, you won't be as effective as fast. Python is much faster to get started with. Even if it's not the best language to do things with in the long long run, arguably, I guess that's just an opinion anyway. Since you can have a professional career out of it still.
  10. Willingness to pull through with a task (exercise, project, whatever) when you don't understand anything and the going gets difficult. Everything else you learn on the go.
  11. I'd dare say VS Code is more flexible, the amount of extensions is vast. It works great on all platforms too, it's not vim, but it's definitely fast enough.
  12. To put things into context: I've been programming for nearly 11 years now in multiple languages along the way, projects big and small. Vulkan is still hard. I can do stuff with it now, way past the triangle, but it's still a massive amount of work. And I can't write anything too complicated because it's not my full time job, and that's the time you need to sink into a game engine to make anything worth while at all. Rome wasn't built in a day, and neither are modern game engines and technology. Imagine your own situation. Follow @straight_stewie's advice. Otherwise you'll just beat yourself up
  13. this In that case, yes, you're all good with that solution. It is probably a better place to start anyway, P2P is a way more complicated, especially when you introduce that third-party. You can minimise the possible damage in case of break-in by segmenting/firewalling (basically DMZ'ing) away that machine from the rest of the LAN, making it more difficult to pivot over it. Not really necessary, but that's an option. I'm not sure about this one, can possibly be a router feature to expire automatically. At least my router does not display any such option. It sounds sil
  14. I imagine you'd like something that works like a P2P system, like torrents or a lot of video calling services. You have only one option really, the UPnP system in your router (it is likely to be turned off by default if it's an office router, because it's notorious for being insecure). You can use that for the application to port-forward itself. The issue with NAT is that if neither peer is able to connect to the other one (closed ports on both, and no UPnP), you need a third party to negotiate a connection for the two peers. So if UPnP is off, that's the only other option, you'd s
  15. Anything newer than 2007, that's with speed considerations. You can do something like C or Pascal (who even uses that anymore) basically on an even more ancient potato. Python will also work. Buy a cheap thing and go with it. You won't need anything faster any time soon.