• 0 Posts
  • 14 Comments
Joined 4 months ago
cake
Cake day: July 5th, 2024

help-circle



  • If you install each OS with it’s own drive as the boot device, then you won’t see this issue.

    Unless you boot Windows via the grub boot menu. If you do that then Windows will see that drive as the boot device.

    If you select the OS by using the BIOS boot selection then you won’t see this issue.

    I was bitten by Windows doing exactly this almost 15 years ago. Since that day if I ever had a need for dual-boot (even if running different distros) each OS will get it’s own dedicated drive, and I select what I want to boot through the BBS (BIOS Boot Selection). It’s usually invoked with F10 or F11 (but could be a different key combo.


  • While I generally agree with that, that’s not what seems to be happening here. What seems to be happening is that anyone who boots Windows via grub is getting grub itself overwritten.

    When you install Linux, boot loaders like grub generally are smart and try to be helpful by scanning all available OSes and provide a boot menu entry for those. This is generally to help new users who install a dual-boot system and help them not think that “Linux erased Windows” when they see the new grub boot loader.

    When you boot Windows from grub, Windows treats the drive with grub (where it booted from) as the boot drive. But if you tell your BIOS to boot the Windows drive, then grub won’t be invoked and Windows will boot seeing it’s own drive as the boot drive.

    This is mostly an assumption as this hasn’t happened to me and details are still a bit scarce.






  • But it could also be for legal reasons, like websites where you can post stuff for everybody to see, in case you post something highly illegal and the authorities need to find you. Another example is where a webshop is required to keep a copy of your data for their bookkeeping.

    None of these require your account to “exist”. There could simply be an acknowledgement stating those reasons with “after X days the data will be deleted, and xyz will be archived for legal reasons”.

    Mostly it’s 30-90 days where they keep your data, just in case somebody else decided to delete your account or you were drunk or something

    This is the only valid reason. But even then this could be stated so that the user is fully aware. Then an email one week and another one day before deletion as a reminder, and a final confirmation after the fact. I’ve used services before that do this. It’s done well and appreciated.

    This pseudo-deletion shadow account stuff is annoying.


  • What the user was doing is that they don’t trust that the system truly deleted the account, and they worry it was just deactivated (while claiming it was “deleted”). So they tried to do a password recovery which often reactivates a falsely “deleted” account.

    I’ve done this before and had to message the company and have them confirm the account is entirely deleted.



  • Using Relational DBs where the data model is better suited to other sorts of DBs.

    This is true if most or all of your data is such. But when you have only a few bits of data here and there, it’s still better to use the RDB.

    For example, in a surveillance system (think Blue Iris, Zone Minder, or Shinobi) you want to use an RDB, but you’re going to have to store JSON data from alerts as well as other objects within the frame when alerts come in. Something like this:

    {
      "detection":{
        "object":"person",
        "time":"2024-07-29 11:12:50.123",
        "camera":"LemmyCam",
        "coords": {
        	"x":"23",
        	"y":"100",
        	"w":"50",
        	"h":"75"
        	}
        }
      },
      "other_ojects":{
         <repeat above format multipl times>
      }
    }
    

    While it’s possible to store this in a flat format in a table. The question is why would you want to. Postgres’ JSONB datatype will store the data as efficiently as anything else, while also making it queryable. This gives you the advantage of not having to rework the the table structure if you need to expand the type of data points used in the detection software.

    It definitely isn’t a solution for most things, but it’s 100% valid to use.

    There’s also the consideration that you just want to store JSON data as it’s generated by whatever source without translating it in any way. Just store the actual data in it’s “raw” form. This allows you to do that also.

    Edit: just to add to the example JSON, the other advantage is that it allows a variable number of objects within the array without having to accommodate it in the table. I can’t count how many times I’ve seen tables with “extra1, extra2, extra3, extra4, …” because they knew there would be extra data at some point, but no idea what it would be.


  • JSON data within a database is perfectly fine and has completely justified use cases. JSON is just a way to structure data. If it’s bespoke data or something that doesn’t need to be structured in a table, a JSON string can keep all that organized.

    We use it for intake questionnaire data. It’s something that needs to be on file for record purposes, but it doesn’t need to be queried aside from simply being loaded with the rest of the record.

    Edit: and just to add, even MS SQL/Azure SQL has the ability to both query and even index within a JSON object. Of course Postgres’ JSONB data type is far better suited for that.