• 11 Posts
  • 710 Comments
Joined 4 years ago
cake
Cake day: January 21st, 2021

help-circle


  • This isn’t how YouTube has streamed videos for many, many years.

    Most video and live streams work by serving a sequence of small self-contained video files (often in the 1-5s range). Sometimes audio is also separate files (avoids duplication as you often use the same audio for all video qualities as well as enables audio-only streaming). This is done for a few reasons but primarily to allow quite seamless switching between quality levels on-the-fly.

    Inserting ads in a stream like this is trivial. You just add a few ad chunks between the regular video chunks. The only real complication is that the ad needs to start at a chunk boundary. (And if you want it to be hard to detect you probably want the length of the ad to be a multiple of the regular chunk size). There is no re-encoding or other processing required at all. Just update the “playlist” (the list of chunks in the video) and the player will play the ad without knowing that it is “different” from the rest of the chunks.


  • That is a pretty weak argument. The issues are minor and in a library that people are moving off of to a better build and stronger validated library. Yes, it should have been like that in the first place, but the problem is minor and being addressed.

    I would look more to the various features of Matrix that aren’t encrypted like room names, topics, reactions, … and not to mention the oodles of unencrypted metadata. I really wouldn’t call Matrix a high-privacy system.

    I like Matrix and use it regularly, but it definitely doesn’t have a privacy-first mindset like Signal does. I’m hoping that this improves over time, but without a strong privacy first leadership it seems unlikely to happen.





  • The concern is that it would be nice if the UNIX users and LDAP is automatically in sync and managed from a version controlled source. I guess the answer is just build up a static LDAP database from my existing configs. It would be nice to have one authoritative system on the server but I guess as long as they are both built from one source of truth it shouldn’t be an issue.


  • Yes, LDAP is a general tool. But many applications that I am interested in using it for user information. That is what I want to use it for. I’m not really interested in storing other data.

    I think you are sort of missing the goal of the question. I have a bunch of self-hosted services like Jellyfin, qBittorrent, PhotoPrism, Metabase … I want to avoid having to configure users in each one individually. I am considering LDAP because it is supported by many of these services. I’m not concerned about synchronizing UNIX users, I already have that solved. (If I need to move those to LDAP as well that can be considered, but isn’t a goal).


  • I do use a reverse proxy but for various reasons you can’t just block off some apps. For example if you want to play Jellyfin on a Chromecast or similar, or PhotoPrism if you want to use sharing links. Unfortunately these systems are designed around the built-in auth and you can’t just slap a proxy in front.

    I do use nginx with basic with in front of services where I can. I trust nginx much more than 10 different services with varying quality levels. But unfortunately not all services play well.



  • How are you configuring this? I checked for Jellyfin and their are third-party plugins which don’t look too mature, but none of them seem to work with apps. qBittorrent doesn’t support much (actually I may be able to put reverse-proxy auth in front… I’ll look into that) and Metabase locks SSO behind a premium subscription.

    IDK why but it does seem that LDAP is much more widely supported. Or am I missing some method to make it work






  • kevincox@lemmy.mltoPrivacy@lemmy.mlIn search for a good VPN
    link
    fedilink
    arrow-up
    8
    arrow-down
    1
    ·
    21 days ago

    I mean it is always better to have more open source. But the point of the multi-hop system is that you don’t need to trust the server. Even if the server was open source:

    1. You wouldn’t know that we are running an unmodified version.
    2. If you need to trust the server then someone could compel us to tap it or monitor it.

    The open source client is enough to verify this and the security of the whole scheme.




  • Here is the problem with crop quality:

    1. Most of the purchase decision is what is observable at the store.
      • Does it look good.
      • What is the price.
      • How is the smell, texture, weight…
    2. Some happens at home, and you might remember for next time.
      • How does it taste.
      • How long does it last.
      • Does it make you feel satisfied.
    3. It is basically impossible to know how good food was for you.
      • You eat a lot of food and the response is delayed.
      • Even if you have a response you probably don’t properly understand your body.
      • In the end most of the “health” of food is just your believes and marketing.

    So there is basically no business pressure to have crops be nutritious.


  • Yeah, I can’t believe how hard targeting other consoles is for basically no reason. I love this Godot page that accurately showcases the difference:

    https://docs.godotengine.org/en/stable/tutorials/platform/consoles.html

    Currently, the only console Godot officially supports is Steam Deck (through the official Linux export templates).

    The reason other consoles are not officially supported are:

    • To develop for consoles, one must be licensed as a company. As an open source project, Godot has no legal structure to provide console ports.
    • Console SDKs are secret and covered by non-disclosure agreements. Even if we could get access to them, we could not publish the platform-specific code under an open source license.

    Who at these console companies think that making it hard to develop software for them is beneficial? It’s not like the SDK APIs are actually technologically interesting in any way (maybe some early consoles were, the last “interesting” hardware is probably the PS2). Even if the APIs were open source (the signatures, not the implementation) every console has DRM to prevent running unsigned games, so it wouldn’t allow people to distribute games outside of the console marker’s control (other than modded systems).

    So to develop for the Steam Deck:

    1. Click export.
    2. Test a bit.

    To develop for Switch (or any other locked-down console):

    1. Select a third-party who maintains a Godot port.
    2. Negotiate a contract.
      • If this falls through go back to step 1.
    3. Integrate your code to their port.
    4. Click export.
    5. Test a bit.

    What it could be (after you register with Nintendo to get access to the SDK download):

    1. Download the SDK to whatever location Godot expects it.
    2. Click export.
    3. Test a bit.

    All they need to do is grant an open source license on the API headers. All the rest is done for them and magically they have more games on their platform.