• 0 Posts
  • 25 Comments
Joined 5 years ago
cake
Cake day: May 31st, 2020

help-circle
  • Yeah, I don’t like when corporations put stuff like that into their ToS, but at the same time, I 100% understand why every open-source license under the sun has it. You’re giving it away for free, so you don’t want people to sue for more than you’re providing for free.

    Mastodon.social is currently very much in the latter camp of giving things away for free. I also understand that a service is yet another beast than a piece of software, since they hold your personal data and may leak/sell it. But yeah, at this point in time, I wouldn’t want someone to be able to sue Mastodon.social out of existence. I guess, it depends a lot on how it’s formulated in the end…


  • It should be noted that theoretically, we don’t know how this external API is implemented. The vast majority of APIs are REST APIs and with REST APIs, there’s a decent chance that you can download an OpenAPI definition from the server which provides the API.

    REST APIs are basically APIs which use HTTP(S) for transport and then there’s some specific rules how the API should be designed. Often times, these rules are not strictly followed and people still refer to such an API as “REST”, because they assume that any HTTP API is a REST API. But yeah, similarly the guides you’ll find will likely also work with general HTTP APIs.


  • Sounds to me like they’re not trying to create a website for now, but rather just process some data, which they can later display in a static webpage.

    So, I’m guessing something like this:

    +--------+     +---------+     +----------+
    | Static |     | Their   |     | External |
    | Web    |---->| Own     |---->| API      |
    | Page   |     | Backend |     |          |
    +--------+     +---------+     +----------+
    

    But yes, unless there’s a lot of data to crunch, the design one would usually go for is rather:

    +-----------+     +----------+
    | *Dynamic* |     | External |
    | Web       |---->| API      |
    | Page      |     |          |
    +-----------+     +----------+
    

    So, the data calculations would happen in the user’s browser. You would still need some hosting for that webpage, but there’s lots of free services to put a simple webpage up.

    And yes, when you go with that latter design, then JavaScript would be the typical choice. It’s still possible to do it with Rust, using WebAssembly (e.g. a colleague of mine has built a small statistics webpage which gets data directly from GitHub, using the Leptos framework), but it is definitely the less beaten path.

    Having said all that, frankly, fuck the usual way of doing things. If you’re comfortable with Hugo for frontend work, then I think it’s legit to build a little backend to take over the dynamic part. Better to build a useful project and learn something than to get stuck trying to learn the ‘correct’ path of doing it. Especially if you’d rather learn about Rust than JS.



  • Yeah, the wording is confusing. A long time ago, there was no paid software, there was only software where you got the source code and other software where e.g. it was pre-installed on some hardware and the manufacturer didn’t want to give the source code.

    In that time, a whole movement started fighting for software freedom, so they called their software “free”.




  • I don’t have much experience with IPv6 yet either, but as I understand, the primary benefit is that you can get rid of a lot of the crappiness of IPv4, which you might just deem ‘normal’ at this point, like NAT and DHCP. It does happen quite a bit, for example, that we’d like a unique identifier for a host, but with IPv4, you need to store a separate UUID to accomplish that.



  • Ephera@lemmy.mltoFediverse@lemmy.world*Permanently Deleted*
    link
    fedilink
    English
    arrow-up
    2
    arrow-down
    2
    ·
    5 months ago

    Well, any software needs to include a license of some form, if you want it to be usable by others. But if it’s not an open-source or libre license, then it’s a proprietary license. That’s not necessarily a bad thing. At that point, it depends on what’s actually written into the license. But it’s also not a good thing, as you miss out on various open-source benefits due to there being no proven legal compatibility with open-source licenses. Well, and if I remember correctly, FUTO’s license actively prohibits reuse of the code anyways.






  • Hmm, I don’t know anything about Whoogle, but from other privacy-conscious search engines, I would expect it to work when you use that URL in your bookmark.

    Three things I can imagine:

    • Something in your hosting stack strips the URL parameters, like maybe your reverse proxy, if you use one. You might be able to see in the Whoogle or web server logs, which URLs actually reach it. Might need to set it to debug/trace logging.
    • Maybe there’s a flag in the Whoogle configuration you need to enable to accept these preference URLs.
    • It’s a bug in that Whoogle version.





  • Agile tries to solve this differently.

    First and foremost, it puts you into tight-knit communication with your team and the customers, so just ask if anyone remembers why it is like that.

    If no one does, then Agile enables to basically fuck around and find out.

    Which is to say, change it to how you think it’s supposed to be and see if anything breaks / anyone complains. If that happens, Agile allows you to react quickly, i.e. to change it back and quickly release a fixed version.

    But yeah, as the others said, if your team feels like documents work better for them, then do Agile and documents. That’s why retrospectives are an integral part of Agile, because it’s not a perfect plan how to work together. You’ll know best what works in your context.