• 0 Posts
  • 12 Comments
Joined 1 year ago
cake
Cake day: July 1st, 2023

help-circle



  • I just recently started working with ImGui. Rewrite compiled game engines to add support for HDR into games that never supported it? Sure, easy. I can mod most games in an hour if not minutes.

    Make the UI respond like any modern flexible-width UI in the past 15 years? It’s still taking me days. All of the ImGui documentation is hidden behind closed GitHub issues. Like, the expected user experience is to bash your head against something for hours, then submit your very specific issue and wait for the author to tell you what to do if you’re lucky, or link to another issue that vaguely resembles your issue.

    I know some projects, WhatWG for one, follow the convention of, if something is unclear in the documentation, the issue does not get closed until that documentation gets updated so there’s no longer any ambiguity or lack of clarity.



  • ShortFuse@lemmy.worldtolinuxmemes@lemmy.world-----BEGIN PRIVATE KEY-----
    link
    fedilink
    arrow-up
    15
    arrow-down
    1
    ·
    edit-2
    2 months ago

    Yeah, except for the first few bytes. PKCS8 has some initial header information, but most of it is the OCTET_STRING of the private key itself.

    The PEM (human “readable”) version is Base64, so you can craft up a string and make that your key. DER is that converted to binary again:

    /**
     * @see https://datatracker.ietf.org/doc/html/rfc5208#section-5
     * @see https://datatracker.ietf.org/doc/html/rfc2313#section-11
     * Unwraps PKCS8 Container for internal key (RSA or EC)
     * @param {string|Uint8Array} pkcs8
     * @param {string} [checkOID]
     * @return {Uint8Array} DER
     */
    export function privateKeyFromPrivateKeyInformation(pkcs8, checkOID) {
      const der = derFromPrivateKeyInformation(pkcs8);
      const [
        [privateKeyInfoType, [
          [versionType, version],
          algorithmIdentifierTuple,
          privateKeyTuple,
        ]],
      ] = decodeDER(der);
      if (privateKeyInfoType !== 'SEQUENCE') throw new Error('Invalid PKCS8');
      if (versionType !== 'INTEGER') throw new Error('Invalid PKCS8');
      if (version !== 0) throw new Error('Unsupported PKCS8 Version');
      const [algorithmIdentifierType, algorithmIdentifierValues] = algorithmIdentifierTuple;
      if (algorithmIdentifierType !== 'SEQUENCE') throw new Error('Invalid PKCS8');
      const [privateKeyType, privateKey] = privateKeyTuple;
      if (privateKeyType !== 'OCTET_STRING') throw new Error('Invalid PKCS8');
      if (checkOID) {
        for (const [type, value] of algorithmIdentifierValues) {
          if (type === 'OBJECT_IDENTIFIER' && value === checkOID) {
            return privateKey;
          }
        }
        return null; // Not an error, just doesn't match
      }
    
      return privateKey;
    }
    

    I wrote a “plain English” library in Javascript to demystify all the magic of Let’s Encrypt, ACME, and all those certificates. (Also to spin up my own certs in NodeJS/Chrome).

    https://github.com/clshortfuse/acmejs/blob/96fcbe089f0f949f9eb6830ed2d7bc257ea8dc32/utils/certificate/privateKeyInformation.js#L40

    Edit: To be specific, PKCS8 is usually a PKCS1 (RSA) key with some wrapping to identify it (the OID). The integers (BigInts) you pick for RSA would have to line up in some way, but I would think it’s doable. At worst there is maybe a character or two of garbage at the breakpoints for the RSA integers. And if you account for which ones are absent in the public key, then anybody reading it could get a kick out of reading your public certificate.


  • Burn-in is a misnomer.

    OLEDs don’t burn their image into anything. CRTs used to burn in right onto the screen making it impossible to fix without physically changing the “glass” (really the phosphor screen).

    What happens is the OLED burns out unevenly, causing some areas to be weaker than others. That clearly shows when you try to show all the colors (white) because some areas can no longer get as bright as their neighboring areas. It is reminiscent of CRT burn-in. LCDs just have one big backlight (or multiple if they have zones) so unevenness from burnout in LCDs is rarely seen, though still a thing.

    So, OLED manufacturers do things to avoid areas from burning out from staying on for too long like pixel shifting, reducing refresh rate, or dimming areas that don’t change for a long time (like logos).

    There is a secondary issue that looks like burn-in which is the panel’s ability to detect how long a pixel has been lit. If it can’t detect properly, then it will not give an even image. This is corrected every once in a while with “compensation cycles” but some panels are notorious for not doing them (Samsung), but once you do, it removes most commonly seen “burn-in”.

    You’d have to really, really leave the same image on your screen for months for it to have any noticeable in real world usage, at least with modern OLED TVs. You would normally worry more about the panel dimming too much over a long period of time, but I don’t believe lifetime is any worse than standard LCD.

    TL;DR: Watch RTings explain it


  • There is no section 15 or 16 in GPLv3, but I did find section 7 saying:

    Requiring preservation of specified reasonable legal notices or author attributions in that material or in the Appropriate Legal Notices displayed by works containing it; or

    But that’s an optional thing that you must add onto the GPLv3 license. I’ll have to keep that in mind for the future.

    That would explain why what I’ve read mentioned it’s not guaranteed in GPLv3 (when comparing to MIT). I’ll have to figure out what that notice would look like.



  • I don’t care if people make money to use my code. I just want my name attached to it somehow, even if you make it closed sourced which is MIT and OpenBSD. I hope you do use my code and even if you heavily reference it to make something new, carry that forward so more can learn and benefit.

    I also don’t understand “better for the end user” arguments either. I have a library that people want to be included in another project, but that project is GPL. They won’t merge my code unless I change my code to be GPL. So everyone who wants them merged is out of luck. I can’t merge their code either with mine. What is supposed to happen is I freely give up my name to the code and restrict it to only being GPL and for GPL projects. Essentially, assimilate and join with the Borg. No, thanks.

    And while that’s from my experience, I’ve also seen good projects get traction, have excitement over it, and fall off the earth because they end up making it GPL. Everyone interested in adopting it, personal or business, just disappear. Then something with less restrictions comes along and gets adopted.

    End-users move to what’s better for them, and if you have a library that is only for GPL, you can end up limiting your options with a wasteful purity test. If you want it to be free you’d give freely with no restrictions. And if you think, “You can contact me to discuss licensing” that doesn’t happen. It’s still a restriction and almost nobody actually bothers.