• 0 Posts
  • 18 Comments
Joined 1 year ago
cake
Cake day: September 25th, 2023

help-circle


  • My thoughts exactly when reading this.

    I believe people when they claim to develop free software. Often because it’s software the dev wants for themselves anyway and they’ve merely elected to share it rather than sell it. The only major cost is time to develop, which is “paid” for by the creation of the product itself.

    You (OP) are proposing a service. Services have ongoing fees to run and maintain, and the value they create goes to your users, not you. These are by definition cost centers. You will need a stable source of funding to run this. That does not in any way mix with “free”. Not unless you’re some gajillionaire who pivoted to philanthropy after a life of robber baroning, or you’re relying on a fickle stream of donations and grants.

    You indicate in other comments you will not open the source of your backend because you don’t want it scooped from you and stealing your future revenue. That’s fine, but what revenue? I thought this was free? What’s your business model?

    It sounds like what you want to do here is have a free tier anyone can use, supported by a paid tier that offers extended features. That’s fine, I guess. But if you want to “compete with DuckDuckGo”, you are going to need to generate enough revenue to support the volume of freeloaders that DDG does. If your paid tier base doesn’t cover the bill, you will need to start finding new and exciting ways to passively monetize those non-revenue-generating users. That usually means one or more of taking features away and putting them behind the paywall to drive more subscriptions, increasingly invasive ads on the platform, or data-harvesting dark patterns.

    Essentially what I’m saying here is, as-proposed, the eventual failure and/or enshittification of your service seems inevitable. Which makes it no better than DDG long term.

    It is, at any rate, a very intriguing project.




  • People tend to contribute to the projects they already have the skills for.

    People also tend to pick up new skills when they have a driving incentive to do so, like supporting a project they have a vested interest in seeing improved.

    You need to learn the language’s structures

    Most of the bread and butter ones have analogues in other languages you should readily understand. More language-unique structures are rare; the more niche they are, the lower the odds your ability to contribute in a meaningful way hinges on your understanding of them.

    you need to learn how the compiler works

    You really don’t, though? Modern compilers, particularly the Rust compiler, are designed to abstract away as much of the details of compilation as possible. If the project really does need to tickle the compiler a certain way to get it to build, it will almost certainly have a buildscript and/or a readme.

    you need to learn the libraries that the FOSS project is using

    This is true regardless of the language in use. I’m not sure why you brought it up.

    you need to learn the security pitfalls for the language

    I would imagine most of these language-specific security footguns are either A) so specific that you will never hit the conditions where they apply, B) are so blazingly obvious that code review will illuminate what you did wrong and you can learn how to fix it, or C) so obscure that even the project owner doesn’t understand them, so you’d be at minimum matching the rest of the codebase quality.

    Mind, I am not insinuating that one can simply bang out a whole new submodule of a project in an unfamiliar language with minimal learning time. Large contributions to large projects can be hard to make even when you’re a veteran of the language in use, as the complexity of the project in and of itself can be its own massive barrier. But not every contribution needs to be big. And for most contributions, I don’t believe the language is the most significant barrier to entry. It’s a barrier, sure. But not the biggest one.

    I’d wager it’s not having a significant impact on the volume of contributions to Lemmy in particular.



  • This is a tremendous amount of cope. Implying there are Lemmy users just lining up to contribute PRs if only it wasn’t written in Rust. Give me a break!

    If someone was competent enough to author code that’s fit to pull into a project like Lemmy, they’re more than capable of translating those skills to Rust. No language seeing modern significant use is so esoteric that a reasonably seasoned developer couldn’t make something competent in it within a week of starting to learn its syntax. Maybe a day, even, if the language you are trying to learn is highly similar to one you already know.


  • I like KeePassXC because it’s written in C and is thus cross platform, while KeePass is written in C# and relies on Windows UI libraries. You can run KeePass on Linux (and I did without usability issue for years) but it will look god awful.

    I won’t knock plugins, everyone has weird use cases, but I don’t know what people need KeePass to do that it doesn’t already do out of the box. I’ve certainly never felt the need for any.




  • It stops bot FARMS from being feasible.

    If preventing Jimmy Bumfuck from spinning up a couple sock puppets is your fear, yeah, PoW systems don’t help. But those are rarely the problem.

    For a phishing scam or astroturf operation to be worth it, you need tens of thousands of accounts all running the same script. Those get filtered hard by PoW systems.

    Phone validation works just as well, and stops Jimmy Bumfuck from making sock accounts. But now every user must be stapled to a phone number. Maybe that’s a worthwhile trade to you, but it sure doesn’t seem to be to everyone replying to you.


  • The vibe I get here in the American midwest is that bars belong clustered on a narrow strip downtown, in very high density so you can bar hop on foot, but located far away from housing so no one has to deal with the rowdiness it attracts.

    I definitely understand and agree with the argument that small shops and services like post offices, gas stations, and grocery stores being interspersed within walkable neighborhoods can only be a good thing. But for anyone viewing bars through this lens, dividing and conquering them ends up detracting from a crucial part of the experience.

    I suppose if you prefer calmer bars, or if your local bar is the haunt of your local clique that you happen to be a part of, a small, lonely bar would be a nice experience. But that’s not what I’d say most people I know go to bars for.


  • Huh?

    I’ve built simple WebGL renders in Firefox several times. The websites for TWGL and three.js, the two most popular JS libraries for WebGL rendering that contain several demos, also load and work correctly and have for years. It clearly works in Firefox to a significant extent.

    There must be something Firefox is not quite compliant with, or less performant at, than Chrome, though. If you look at Patreon’s website since their logo change, it runs fine in Chrome but chugs in Firefox. I don’t know if it’s WebGL related but I wouldn’t be surprised.