_frkl

I was wondering the same, and looked up "hack easiyo", lots of examples of people coming up with their own ways to use the system, without having to purchase the EasiYo printer ink, so to speak.

flask also supports async now, that's one of the main new features of this release.

Right. Worked for me when i tried it with two different web payloads. But i didn't do more than a bit of playing around.

For fun, you could even use redbean ( https://justine.lol/redbean/index.html ), which has been discussed on here recently. That would give you a tiny executable running a webserver that serves your webapp locally. Probably not much advantage compared to a plain html file, though. Might be smaller overall, since everything would be compressed.

It sounds like Seafile would be worthwhile for you to look into, they do syncing quite well (based on a simplified version of git - its quite fast as they don't have to up-/download the whole file if it changes), and sharing also works fine. Doesn't have a lot of other features, but what it does it does relatively well. There are a few issues as with everything, esp. setup and updating is a bit annoying, but overall I'd recommend it. Can also do end to end encryption (with a few caveats, but IMHO good enough).

I haven't looked at pywebview at all, and my experience with electron is also not very good. Apart from the 'native' misnomer, assuming the general concept of such a 'website-as-app' is an acceptable tradeoff in a certain situation, what exactly is bad with pywebview?

That, or if interactivity is not that much of a concern, Jupyter notebooks (maybe with Voilá) is also a good option.

Or ZFS, I wouldn't store that kind of data on other filesystem's without that kind of protection...

You can't use your own domain though, AFAIK. Which means you won't be able to switch providers, which may or may not be a problem.

This is not a very helpful comment. OP has made a pretty convincing argument (to my ears), and you basically say: this is wrong! You need to elaborate, or, if you are not prepared to do that, keep quiet. OP spent some time and effort to make their case. You did not, at all.

If you are disappointed, there's mcfly, which does things with your shell history and ML: https://github.com/cantino/mcfly :-)

As a user of a terminal though, personally I would prefer if development time would be spent on terminal features themselves, instead of a convenience feature I'd think unnecessary. I guess this would be a nice project for somebody who really wants that: create a generic gui app to create those config files for a number of applications....

It's packaged in most distributions, so maybe just use those packages? Also, there are binaries on the Github release page: https://github.com/kovidgoyal/kitty/releases , just download and put them into $PATH manually?

Given all that, I find it perfectly acceptable to offer a curly install script as an additional option for users who don't think those scripts are as problematic as people often claim on hackernews or reddit (I personally am perfectly ok with them -- I have to trust the author of a piece of software anyway, so why not also trust the installer that comes from the same source/host?).

Oh wow, pretty impressive. Have to try that out tomorrow!

This is a fairly comprehensive build system for gui apps in python, I think: https://build-system.fman.io/

True, but depending on what you created, it might open up the path to dual licensing.

That, or using a very restrictive copy left license.

That's why have licenses that forbid certain usages. Obviously those are not 'Open Source' as defined by OSI. If you use such software in ways forbidden by the license, you are liable. Companies would usually be very careful, and would not knowingly ignore the license terms.

Yes, copy left is really your best bet. While 'technically' not open source, there is also parity ( https://licensezero.com/licenses/parity ) which I think brings a few interesting ideas to this space. All of those options make It harder for your open source users though.

I totally agree, and never understood the focus on curly bash script. People seem to be ok to 'git clone; make; sudo make install' something, but hesitate to pipe a remote bash script that comes from the same author, and often is hosted in the exact same repo... At least, nobody ever specifically pointed out how dangerous the make scenario is.

There are a few minor things one should do when writing such a curly bash script, but overall I, personally, don't worry too much about it when I encounter them, I just do my usual security assessment and risk mitigation (which usually does not include reading the code -- that's just not practical).

> You're right that the Open Source Definition doesn't define the term "open source" - usage does. But common usage of "open source" still means "something that meets the open source definition", not "I can see the source code". There are some people who use a different definition, but it's a long way from being well accepted.

True, it'd be interesting if someone did some sort of study on that though, and get some real numbers. I have the impression that people know less and less what the open source definition even is, so maybe this has started to shift in the last few years? I have a feeling, to younger developers, open source means often (in practice): I can see the code, and I can use it without having to pay...

I like having the option, tbh. I usually self host the install scripts, which removes most of the potential issues.

Didn't Prefect open source their orchestration component recently, or am I mistaken? What part of Prefect is still closed?

Why are they not a good fit? From a shallow reading, I thought Prosperity and the Polyform licenses would be fairly similar in intent to the licenses they have on their page. I can't imagine the authors (not author) of Polyform/Prosperity would care either way, and since nobody ever claimed those are open source licenses I don't understand your other ill-made point either. Maybe you refer to the Parity license? That one would make no sense in this context at all, and I doubt anybody would suggest it here.

Also, since your post is fairly negative and unsubstantiated overall, would you care to suggest an alternative?

For what it's worth: JetBrains has a model where they sell cheaper individual licenses that people can buy from their own money (company credit cards/expenses are not allowed), and those can be used for work. And more expensive per-seat licenses for companies/organizations. Also, that also includes a perpetual license for the version at the time of purchase (and discounts for people who upgrade). I think that is overall a fair deal, and keeps the incentives for both developers and customers as aligned as is possible under such circumstances, IMHO. Yearly licensing like this doesn't make much sense for such a product, I think.

I would not write my own license. I'd really recommend you get a lawyer look over the text you have (that shouldn't be too expensive, it's a one time cost), or look at existing ones that are actually written by lawyers. For a public license (to restrict commercial use), I'd recommend both LicenseZero Prosperity ( https://prosperitylicense.com/versions/3.0.0 ) and the Polyform licenses ( https://polyformproject.org/ ).

For the private license, you could use/adapt the LicenseZero Private license ( https://licensezero.com/licenses/private ).

Those are more geared towards developer tools, so I'm not sure whether they'd be a good fit for your product. But all of them are written in simple to understand language so you should be able to figure that out by youself, and at the very least get a few pointers. If not, that is considered a bug with the license, and both projects are very open to feedback.

True, but it also takes away some pain you'd otherwise have. I used to be in the 'Kubernetes is unnecessary overhead for most cases' camp, but since I actually started to use it I think it's a good base for even smaller setups, and I find myself prefering it to other ways of reproducably setting up infrastructure/services. Maybe that's not the case for the people posting here, but often times it seems people who argue against Kubernetes have never really used it and don't have more than a shallow knowledge.

Its hard to put into words without writing a blog post, but in my mind the 'everything is a resource' design introduces a simplicity that counterbalances the complexity that comes with it. One still has to make an informed decision, of course, and sometimes it really is not the right tool ...

I remember the Rockbox firmware for MP3 players having something similar. I was (and am still) amazed how efficient the UI/navigation was in relation to how limiting the (hardward) controls were on some of those players. It took a little while to understand how it works, but that tiny bit of learning curve was well worth it.

Two small things: I might have mis-understood you, but you can't sell Apache licenses for those who need them without those people subsequently having the right to give away your code under that (open) license to anyone they like. Which means, if worst comes to worst, you'd sell exactly one license. Also, there is talk about LicenseZero becoming more flexible in the near future as to which private licenses are offered to buyers (e.g. company-wide licenses), so I'd watch that space.

I think challenging the consensus is equally needed (and high time in this regard, IMHO). To me, 'open source' lost its meaning a while ago, and I welcome new ideas in this space.