• UmeU@lemmy.world
    link
    fedilink
    arrow-up
    5
    ·
    2 months ago

    Office Depot. They are still using IBM machines from the 90s with receipt printers the size of a shoebox.

  • Epzillon@lemmy.ml
    link
    fedilink
    arrow-up
    27
    arrow-down
    1
    ·
    2 months ago

    Using Filezilla FTP client for production releases in 2024 hit me hard

      • sznowicki@lemmy.world
        link
        fedilink
        arrow-up
        2
        ·
        2 months ago

        It had a major security problem in like 2010. Later everyone moved to git and CI/CD so nobody knows what happened after that.

      • dfyx@lemmy.helios42.de
        link
        fedilink
        arrow-up
        12
        arrow-down
        1
        ·
        2 months ago

        Filezilla itself is not the problem. Deploying to production by hand is. Everything you do manually is a potential for mistakes. Forget to upload a critical file, accidentally overwrite a configuration… better automate that stuff.

        • Epzillon@lemmy.ml
          link
          fedilink
          arrow-up
          4
          ·
          2 months ago

          This. Starting at the company in 2023 and first task being to “start enhancing a 5 y/o project” seemed fine until I realized the project was not even using git, was being publically hosted online and contained ALL customer invoices and sales data. On top of this i had to pull the files down from the live server via FTP as it didnt exist anywhere else. It was kinda wild.

        • Contravariant@lemmy.world
          link
          fedilink
          arrow-up
          1
          ·
          2 months ago

          Wait so the production release would consist of uploading the files with Filezilla?

          If you can SSH into the server, why on earth use Filezilla?

  • CrabAndBroom@lemmy.ml
    link
    fedilink
    English
    arrow-up
    27
    ·
    2 months ago

    I had a boss at an animation company (so not exactly a hub of IT experts, but still) who I witnessed do the following:

    • Boot up the computer on her desk, which was a Mac

    • Once it had booted, she then launched Windows inside a VM inside the Mac

    • Once booted into that, she then loaded Outlook inside the Windows VM and that was how she checked her email.

    As far as I could ascertain, at some point she’d had a Windows PC with Outlook that was all set up how she liked it. The whole office then at some point switched over to Macs for whatever reason and some lunatic had come up with this as a solution so she wouldn’t have to learn a new email thing.

    When I tried to gently enquire as to why she didn’t just install Outlook for Mac I was told I was being unhelpful so I just left it alone lol. But I still think about it sometimes.

    • linearchaos@lemmy.world
      link
      fedilink
      English
      arrow-up
      14
      ·
      2 months ago

      I’m not certain that it’s still the case but several years ago Outlook for Mac was incapable of handling certain aspects of calendars in public folders shared groups and there was some difficulty with delegation send as.

      At the time the best answer I had was for the Mac users to use Outlook as much as possible and then log into webmail when they needed to send us. It’s been a few years so I can’t help but think it’s been fixed by now. Or the very least equally broken on PC.

  • NABDad@lemmy.world
    link
    fedilink
    English
    arrow-up
    42
    ·
    2 months ago

    It’s it too soon to say, “letting Crowdstrike push updates to all your windows workstations and servers”

  • solomon42069@lemmy.world
    link
    fedilink
    arrow-up
    25
    ·
    2 months ago

    One of my ex employers sold a construction company a six figure “building logistics system” which was just a Microsoft Access file. And the construction dudes had to use a CDMA dongle to remote desktop into a mainframe to open their access files. A travesty.

  • flamingo_pinyata@sopuli.xyz
    link
    fedilink
    arrow-up
    37
    ·
    2 months ago

    Source control relying on 2 folders: dev/test and production. Git was prohibited due to the possibility of seeing the history of who did what. Which made sense in a twisted way since a previous boss used to single out people who made mistakes and harras them

    • InFerNo@lemmy.ml
      link
      fedilink
      arrow-up
      15
      ·
      2 months ago

      Just share a git user, come on. Have everyone check in under the same name “development” or whatever, but no version control whatsoever?

  • wintermute@discuss.tchncs.de
    link
    fedilink
    arrow-up
    30
    ·
    2 months ago

    I was hired to implement a CRM for an insurance company to replace their current system.

    Of course no documentation or functional requirements where provided, so part of the task was to reverse engineer the current CRM.

    After a couple of hours trying to find some type of backend code on the server, I discovered the bizarre truth: every bit of business logic was implemented in Stored Procedures and Triggers on a MSSQL database. There were no frontend code either on the server, users have some ActiveX controls installed locally that accessed the DB.

    • rekabis@lemmy.ca
      link
      fedilink
      arrow-up
      5
      ·
      2 months ago

      every bit of business logic was implemented in Stored Procedures and Triggers on a MSSQL database.

      Provided the SP’s are managed in a CVS and pushed to the DB via migrations (similar to Entity Framework), this is simply laborious to the devs. Provided the business rules are simple to express in SQL, this can actually be more performant than doing it in code (although it rarely ever is that simple).

      There were no frontend code either on the server, users have some ActiveX controls installed locally that accessed the DB.

      This is the actual WTF for me.

      • wintermute@discuss.tchncs.de
        link
        fedilink
        arrow-up
        5
        ·
        2 months ago

        There was no version control at all. The company that provided the software was really shady, and the implementation was so bad that the (only) developer was there full time fixing the code and data directly in production when the users had any issue (which was several times a day).

  • Thurstylark@lemm.ee
    link
    fedilink
    English
    arrow-up
    25
    ·
    2 months ago

    Freight shipping company still running on a custom AS400 application for dispatch. Time is stored as a 4-digit number, which means the nightside dispachers have their own mini Y2K bug to deal with every midnight.

    On one hand, hooray for computer-enforced fucking-off every night. On the other hand, the only people who could fix an entry stuck in the system because of this were on dayside.

    Apparently, this actually isn’t uncommon in the industry, which I think is probably the worst part to me.

    • paws@cyberpaws.lol
      link
      fedilink
      arrow-up
      4
      ·
      2 months ago

      Hehe I was in global shipping IT, we had some ooooold Solaris systems that handled freight halting data flows. Windows Server 98 servers that handled data for very large shippers. Every daylight savings time change something would break.

  • Crackhappy@lemmy.world
    link
    fedilink
    English
    arrow-up
    35
    arrow-down
    2
    ·
    2 months ago

    Wells Fargo. I worked for them for a few years and I have never banked with them after witnessing the travesty of inefficiency and incompetence, literally in my face.

  • MeetInPotatoes@lemmy.ml
    link
    fedilink
    English
    arrow-up
    23
    ·
    2 months ago

    A behavioral health company with 25 iPads deployed to field employees as patient data collection devices all signed into the same iCloud account instead of using MDM or anything.

    They all had the same screen lock PINs and though most of the data was stored in a cloud based service protected by a login, that app’s password was saved by default.

  • calamityjanitor@lemmy.world
    link
    fedilink
    arrow-up
    57
    ·
    2 months ago

    My partner worked for a local council. They reset your password every 90 days which prevented you from logging in via the VPN remotely. To fix it you’d call IT and they’ll demand you tell them your current password and new password so they can change it themselves on your behalf.

    Even worse, requesting a work iphone meant filling out an IT support ticket. So that IT could set up your phone for you, the ticket demanded your work domain username and password, along with your personal apple account username and password.

    • nicerdicer@feddit.org
      link
      fedilink
      arrow-up
      14
      ·
      2 months ago

      along with your personal apple account username and password.

      I would never ever share my personal Apple account with work related things. I prefer to have my private stuff seperated from work related things.

      I once worked for a small company that had such a setup: All devices were Apple, and everything was connected with the company owners private Apple accounts. That means that I was able to see personal calendars and to an extend some email-related things - Things that reveald more about a person than you wanted to know.

  • DJDarren@thelemmy.club
    cake
    link
    fedilink
    English
    arrow-up
    20
    ·
    2 months ago

    Probably not as bad as some of the other examples here, but the company I currently work for has its 10tb shared drives backing up to a server that’s right next to it in the same cabinet. Those two servers, plus all of the networking hardware and a variety of ancillary devices are all plugged in to one socket via a bunch of extension cords.

    Yes, the boss has been told to get it sorted, but he’s the kind of older guy who doesn’t give a shit.

    • InFerNo@lemmy.ml
      link
      fedilink
      arrow-up
      8
      ·
      2 months ago

      Happened to us, they put the backups on a different device, away from the servers, but still in the same premise. Cryptolocker locked everything on the network, including the backups. No off-site backups.