• 1 Post
  • 114 Comments
Joined 2 years ago
cake
Cake day: June 30th, 2023

help-circle


  • Mostly the latter. We don’t do any optimizations on our product whatsoever. Most important thing is to say yes to all the customers and add every single feature they want. Every sprint is spent adding and adding and adding to the code as much as we can and as quickly as we can. Not a single second is allotted to any discussion about performance or efficiency. Maybe when something breaks, but otherwise we keep piling on more crap at full speed non-stop. I have repeatedly been told “the fast way is the right way” followed by laughter. I was told to “merge this now” on multiple occasions even when I knew that the code was shit, and told the team as much. I am expected to write code now and think about it later.

    As you can expect, the codebase is a bloated nightmare. Slow as shit, bugs galore, ugly inconsistent UI, ENORMOUS memory use, waaaaaay too frequent DB access with a shit ton of duplicate requests that are each rather inefficient themselves. It is a rather complex piece of lab management software, but not so complex that it should be struggling to run on dedicated servers with 8 gigs of RAM. Yet it does.









  • Twice, because usually it’s two sticks.

    In any case, RAM failure is rare enough that quadrupling its chances is not gonna make any meaningful difference. Even if it does, RAM is the easiest thing to replace in a PC. Don’t even need to go offline while waiting for a new stick. Someone who’s got the cash to build that thing in the first place won’t be too upset by the cost of another 32gb stick either, I don’t think.




  • It’s a translator. Takes commands that are meant for windows to understand, and translates them into something Linux can work with. If the program requires the services of the kernel, for instance, it makes its system call as usual but the call gets converted to a command for the Linux kernel. At the end of the day it’s the Linux kernel doing the work that was aimed at the windows kernel, and there is no windows kernel anywhere at all. That’s unlike an emulator where you’d be running the windows kernel inside your Linux environment.

    Wine also creates a windows-looking file structure so that programs can find the stuff they’re looking for where they expect them to be. Like, it creates a “program files” directory somewhere in your filesystem and tells the windows applications to look there if they need to. There’s more to it, but you get the gist I hope.

    In a way, wine extends your Linux environment to support windows stuff. Whereas an emulator would create a new windows environment entirely. The goal is not to trick software into thinking it’s on a windows machine, it’s to make it work on Linux. The difference there is that by making it work on Linux you can make it work together and share resources with the rest of the system instead of remaining isolated in its own emulated environment.




  • Well you see one client demanded some absolutely stupid very obscure feature that was so absolutely stupid that it could only reasonably be achieved by hacking some bullshit together on their on-premise bare-metal installation that they insisted on not giving you proper access that you needed. Then something went wrong with that hacked-together one-off bullshit, and the digital equivalent of this was the only way to figure out what the hell was happening.