pixelscript

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.

Seeing "please" in the script for some commands but not all of them is giving me INTERCAL flashbacks.

They mutually imply one another.

If something was private, but not secure, well, that implies there are ways to breach the privacy, which isn't very private at all.

If it's secure, but not private, that implies it's readable by someone other than the consenting conversational parties, which makes it insecure.

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.

No one said it was shameful?

It's a huge win, but not the kind of win people reading the statistic with no context (like me) probably thought.

I'm sure a lot of us looked at "15 percent of desktop PCs in India run Linux" and, regardless of whether it was hasty and irresponsible for us to do so, extrapolated that to, "15 percent of Indian PC users are personally selecting Linux and normalizing its paradigms".

But in reality, it sounds more like "15 percent of Indian PC users use Linux to launch Google Chrome". Which is impressive, but not the specific kind of impressive we wanted.

It feels a bit like how I imagine, say, a song artist feels when they pour their heart and soul into a piece of music, it gets modest to no traction for a while, and then years later a 20 second loop becomes the backing track for a massive Tiktok meme, and almost zero of that attention trickles back to their other work.

these sliders are very thin, but not thin enough. neither of my laptops close correctly with one equipped. :(

Ah well. Masking tape suffices.

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.

Maybe you do know, but in case you don't, the "convenience fee" is (usually) just the price the vendor has to pay to process a credit card transaction. Because in order to accept credit cards as payment in the first place, they have to pay the credit card network for the privilege.

Providing the exact same service to you is more expensive for them based entirely on the method you use to pay. You bet they're going to pass that extra expense onto you. The alternative is raising their service charge to eat the cost and screwing over people who pay with check or cash. Which is what most retail stores tend to do.

Though, I agree, I'd rather they just do the fucking math and charge a rate that covers their operating expenses. It's shouldn't be my problem to pay their itemized expenses. Just know that if they did so, we'll be charged the same total either way.

It's a similar argument with tipping culture. "Oh, you have to tip, employees rely on it to make ends meet!" Sure, but why is that my problem? If the business can't create a business model that properly pays for the expenses it needs to function, they should go out of business. Raise prices. I'll pay the same as the tip, fine, just stop playing these frivilous smoke and mirror games with my bill.

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.

The biggest and most obvious encroachment on standard email that Gmail does is opting for a tag system over a folder system. It is superior, but nonstandard. If you rely on this, it's Gmail vendor lock-in for you.

cough cough gmail

~~(I use gmail and need to stop)~~