How does that compare to https://github.com/Stirling-Tools/Stirling-PDF ?

A cursory check reveals some answers:

* the one you linked is a browser-based thin client; this one runs right on the user's machine

* 100% less Docker and other devslop—drastically simpler deployment and development cycles

It still seems to require a browser to use. But sure, I guess it's easier to start with.

What?

I think Stirling PDF is a great product, but there meant for more Enterprise level users. LuxPDF is meant for very quick file conversions or modifications and is geared towards freelancers, students, small business etc.

https://msty.app (cross-platform) and https://chorus.sh (Mac only) do that though they are both a desktop app rather than a service. Arguably better than putting your API key somewhere online in my opinion.

Is Poe pay per use or a subscription? I don't want to sign up just to find out.

Is it pay per use?

> has that happened with Svelte?

Yes. There are features that have been deliberately kept on the platform level to force you to use the platform instead of implementing it on the framework level or guiding you through it with the docs.

https://svelte.dev/docs/kit/glossary#ISR

ISR _can't_ be implemented at a framework level without tying the framework to the platform. The fact that we instead chose to implement it via a platform-agnostic adapter API surely demonstrates the opposite of what you're implying

This would be true if you also provided an adapter-node, which would work on most traditional servers, and most non-serverless platforms.

The fact that you prioritize the vercel one and not the node native one proves what OP implies in my opinion.

It's platform agnostic but Vercel is the only one that supports it? At least that's in the docs I linked.

I'll let my employer know to update my salary or reduce my workload.

Sounds like a necessary change to send a message. I find it normal that when you go somewhere, you adapt and learn the language. You shouldn't expect other to adapt to you.

IMO the distinction is important; it tells me, broadly, what I can and cannot do with the source code.

Heck, the .NET Framework source has been available for eons (referencesource.microsoft.com), but you can't go compile it and build your own .NET Framework distro (Mono is a different story).

there was some guy on hackernews whose post I had read who had actually compiled .net entirely from source.

Like the issue I think becomes that .net itself was written in .net and so you needed the earlier proprietary versions right?

But Gnu also had a .net compiler and he had actually used it on guix (basically like nix) to really create sort of reproducible .net , I am sure that some reader of this comment will attach the post on which I am talking

I believe this was https://guix.gnu.org/en/blog/2024/adding-a-fully-bootstrappe.... It was submitted to HN but only got a few comments.

The term "open source" was coined for a specific meaning, and codified.

https://en.wikipedia.org/wiki/Open_source

Destroying the meaning of words is an activity for Orwellian villains.

Although OSI claims that they coined the term, there's irrefutable proof that the term was already in-use well before that. Originally, "open source" just meant "source available": https://dieter.plaetinck.be/posts/open-source-undefined-part...

I coined it today to mean something else. There is no reason to take someone's meaning of a word for gospel.

> That's it.

No, that's not it. What you can do with the source code is just as important as the source code being available.

Then call it a new term. Don't change the definition of existing words. An open door isn't an invitation to change it, or to use it for free. It's just an open door and you can look inside.

> The source is there. That's it.

No, that's https://en.wikipedia.org/wiki/Source-available_software

"open source" has been defined by the OSI since decades and this does not fit that definition.

I don't really mind whether it fits someone else's definition really.