It's a muddy comparison given that NumPy is commonly used with other BLAS implementations, which the author even lists, but doesn't properly address. Anaconda defaults to Intel oneAPI MKL, for example, and that's a widely used distribution. Not that I think MKL would do great on AMD hardware, BLIS is probably a better alternative.
The author also says "(...) implementation follows the BLIS design", but then proceeds to compare *only* with OpenBLAS. I'd love to see a more thorough analysis, and using C directly would make it easier to compare multiple BLAS libs.
Their implementation outperforms not only the recent version of OpenBLAS but also MKL on their machine (these are DEFAULT BLAS libraries shipped with numpy). What's the point of compairing against BLIS if numpy doesn't use it by default? The authors explicitly say: "We compare against NumPy". They use matrix sizes up to M=N=K=5000. So the ffi overhead is, in fact, neglectable.
And as I understand that license, you are allowed to use Timescale for anything that doesn’t involve offering Timescale itself as a service. If you were using Timescale to process lots of time series transactions in your backend, it doesn’t seem to me like that would break the license.
(Which is to say that if, like Tembo, you’re offering Postgres as a service you do indeed have a problem. But for other use, should be fine)
The tricky thing with these licenses (BSL, SSPL, etc.) is that you can use them freely for internal stuff, but suddenly, if you make your product public (assuming it uses, e.g., TimescaleDB), things can get muddy. Everyone wants the flexibility to either open-source or commercialize a successful internal product in the future.
The problem is that, even if your app is not a mere frontend for TimescaleDB/Mongo/Redis, you can get sued, and you'll have to spend unnecessary time and money proving things in court. No one wants this, especially a startup owner whose money and time are tight. Also, even if your startup/company uses some of these techs, potential company buyers will be very wary of the purchase if they know they'll have to deal with this later.
I would assume TimescaleDb only sues if you money. In this case you can also afford a commercial license. If you hit big just contact them and tell there was a problem having a correct license earlier and you want to fix the situation.
There is 0% chance Timescale would sue mom’n’pop operation for breaking their license.
Your assumptions are based on good faith, and businesses are not run on that :) Imagine Oracle or IBM bought Timescale; that 0% chance suddenly increases dramatically.
I imagine legally would need a lawsuit to set a precedence, and if a license owner sets an over-reaching precedence of what a wrapper is, they risk losing customer trust and companies avoiding them like the plague.
e.g. timescaledb going after a tsdb as a service company offering tsdb behind a graphql wrapper vs timescaledb going after a financial company offering timeseries data collection and viewing.
I think a good border test would be, would timescaledb allow you to offer a metrics and logging service? technically you're offering timeseries database functionality, but it's in a constrained domain, and very clearly a different product, but still effectively CRUDing timeseries data.
That’s the internal use restriction. There is also the restriction more relevant to the use cases I’m talking about on Value Added Products which is “the customer is prohibited, either contractually or technically, from defining, redefining, or modifying the database schema or other structural aspects of database objects”.
Which is, basically, saying that you can do anything that doesn’t give your customers the ability to redefine and modify the database schema as long as you are creating a product that is adding value on top of timescale. Is any of this 100% clear? Not any more that legalese generally is, and of course probably wise to talk to a lawyer if you’re concerned about it. Timescale has made their intent with the license clear in the past with blog posts and such though.
"Linux x86_64" is present on my UA on Linux, and "Windows NT 10.0; Win64; x64" on Windows. Probably a bug or just untested on Firefox. Just a bit annoying.
I'll add that this is the first site that misdetects anything like that.
I maintain a few niche (electric power systems) packages, and I wouldn't mind a one-time or yearly fee, or a fee per project created. I say this as a Brazilian who lived in the middle of nowhere and managed to have a website in the 90's as a teen. If a monetary fee is not desirable, some other hurdle/challenge would probably work fine.
Recently I've seen someone on Reddit trying to automate the creation of PyPI projects through GitHub Actions. The person was complaining that the first deployment couldn't use an API key for that project since it didn't exist. So I'm not surprised some people are trying to do the same for malicious purposes.
The PyPI front page lists 455k projects. If you search for "test", you'll see there's a lot of throwaway projects (note that test.pypi.org is a thing). I'm mostly an EE researcher and I'm not sure students need a low barrier to entry to PyPI, since pip and other tools support installing from GitHub without too much hassle and there are also other non-PyPI package indices. Student packages/projects tend to be abandoned soon after graduation. An archived repo (with a license...), on GitHub or somewhere else, sounds more reasonable and also has more visibility that could end in code reuse someday (through the service's own search and search engines in general). I'd love to understand why so many people repeat this meme that student and teens need trivial access to production infra like PyPI.
So, I'd say being too inclusive, allowing fully unrestricted trivial creation of projects is kinda foolish. There needs to be some extra step, be it a fee, identity confirmation, manual moderation/approval, or something else. I'm sure the PyPA devs/maintainers have ideas.
> There needs to be some extra step, be it a fee, identity confirmation, manual moderation/approval, or something else. I'm sure the PyPA devs/maintainers have ideas.
When I was younger, I always thought computing was so incredibly cool, because me, just some blind kid in Florida, could contribute and make things and share things and just ...participate. I would talk to friends trying to go in to other careers, and excitedly talk about what I was working on and be curious why they never did anything related to what they wanted to do when they grew up.
Now, I understand how this comes about, bit by bit, with the best of intentions.
And I hate it.
Please, just no.
If you want to set up a corporate only, super-sekret clubhouse of a PyPi that only the authorized developers can push to, well, the source code for PyPi is right here[0]! And here's Stripe[1]!
But please don't break even more of the open, free Internet that I grew up with, I'm pleading with you.
The ones who broke the commons are the ones who abused it by uploading malware and lazy student projects. You shouldn't blame the host for trying to maintain standards in light of this. When you have a tragedy of the commons scenario, the solution is to regulate the commons. Otherwise it will lose all value for everybody.
> Recently I've seen someone on Reddit trying to automate the creation of PyPI projects through GitHub Actions. The person was complaining that the first deployment couldn't use an API key for that project since it didn't exist. So I'm not surprised some people are trying to do the same for malicious purposes.
Sorry for the tangent, but: you can do this now! If you use trusted publishing, you can register a "pending publisher" for a project that doesn't exist yet. When the trusted publisher (like GitHub Actions) is used, it'll create the project[1].
All of this is supported transparently by the official publishing action for GitHub Actions[2].
Interesting, thanks for the links. By the way, the one I mentioned was in r/learnpython, which is probably not exactly the ideal audience for such a feature.
No problem. And I agree completely -- it'd be really nice if newcomers could copy a template (or even better, have a tool make one for them) that handles all of this behind the scenes.
> Later, several Telegram users said they could no longer use the messaging app after local carriers complied with the ruling. Google and Apple were also ordered to block the app.
So yes, apparently they can. Or did you think it needed Telegram's cooperation?
Even if it is possible to install apps manually, most users are not "power users" able or even just willing (or willing to learn) to do that. Another aspect of the much more curated software world of Android or iPhone vs. PCs, where blocking would indeed be mostly useless even for regular users.
Jailing people for that is beyond horrible. Why would anyone want to appoint a legal representative in a country that does things like that, I have no idea.
I have no idea why these corporations come here either. Only reason I haven't left this place behind is my family refused to leave with me. They must be making truckloads of money if they put up with this.
To be able to "do business" there, whatever it may entail. Contrary to the popular held opinion on certain online communities, businesses must respect local laws and regulations to be able to conduct their activities.
The only "law" the executive broke was making the judge angry. Even the other judges acknowledged he was wrongly detained and released him. Says so in the article.
It uses Mapbox GL JS v2.x, which is no longer open-source and is tied to the TOS, so the distinction of using Mapbox tiles or not doesn't seem to matter. Just loading the library requires a token from Mapbox.
GIMP already supported ARM though, this is about "Apple Silicon". Since the post itself doesn't mention specific challenges, I guess it serves more to inform macOS users of the availability than foster discussion or provide any insight.
