evv

Here's a fun thought: As humans dig heavy materials out of the earth and build taller buildings, we increase the moment of inertia of the planet. This theoretically slows the rotation of the earth.

Of course, given the huge mass of the earth, the effect so far would be negligible. But maybe it would be noticed in the distant future if it were done on a much much greater scale than it is today.

As more food for thought, we are also changing the moment of inertia by putting so many planes in the sky, and by sending mass to space. If every plane were to land, the earth should rotate slightly faster.

No, most people define "open source" as it is defined by the Open Source Institute.

That is probably why this project was careful to define itself as "Open" and did not use the term "open source". It is licensed under Elastic v2 which is generally known as a "source available" license

I don't see any problem with this as long as it is not advertised as open source, which it is not. Of course they are entirely within their rights to license their code as they see fit. I like to use open source software but I absolutely prefer source-available software over closed source solutions like their competitors (AWS, Azure, and GCP)

This is a good reminder to check the license before you adopt something. Just because the code is on Github, doesn't mean you can do anything with it.

Welcome to Open Source, where being actually open is a competitive advantage!

If you want users of your software to have the brightest future, you need to accept the fact that others can make money and services with your code. If you try to shut that down, people will fork the most recent version of your code that has an OSI compatible license.

Of course, they could have chosen a license like AGPL in the first place, which prohibits services with non-AGPL changes. But then, the product would have been less likely to have the viral growth that HC products enjoyed.

Absolutely. You can use different drivers for Tamagui Animations- CSS for GPU-accelerated animations on web, and Reanimated for fast animations in RN.

https://tamagui.dev/docs/core/animations

I have been using different UI toolkits over the past ~13 years of my professional front-end development career. Probably starting with Bootstrap.

Tamagui has a really elegant combination of a Styling system (the mechanics of applying styles to the underlying systems), a Theming system (the way sizes/colors are passed down within different contexts of the UI), and a Component system (high level components that are ready to use out of the box). In my opinion, this is where Tamagui shines above the competition- each abstraction effectively builds upon the underlying ones, and it gives you a bunch of ready-to-use components so you can start building quickly and worry about the details later. Way better than the "just copy and paste" model of Tailwind which forces you to maintain components and manually create a consistent UI for your app.

We are using Tamagui for our open source electron app + web site. We hope to have a React Native app in the future, so we are strongly opposed to any solution that is overly tied to CSS. If you want to see an example (real-world, messy) codebase that uses Tamagui, please take a look here: https://github.com/MintterHypermedia/mintter/tree/main/front...

The biggest downside, in my experience, is the heavy/complicated/fragile setup process of Tamagui. Although this is typical of any TS monorepo. If you struggle to integrate Tamagui in your codebase, I encourage you to power through the setup phase- the payoff is totally worth it!

Actually I didn't know it used to be open source!

I think they make money by selling data harvested through the extension. So you might be able to pay them to answer "how many websites are using X library/framework"?

Yes.

If npm lets me publish a new version, I'd be happy to remove the Windows binaries.

Oh. As the creator and reluctant maintainer of npm's "ssh-keygen", this is awkward!

First question: does this mean I won't be able to publish patches to the package?

Why do I not want this package under my control? The original package simply calls spawn for your real `ssh-keygen` with the appropriate arguments. No real problem, (although there is very little value here). But a contributor added support for Windows by uploading opaque binary builds for Windows. While I have no reason to distrust the contributor, it is scary to be "responsible" for opaque executables that I did not personally produce.

So, what should I do with this package? Assuming npm lets me do anything?

Fortunately this package is "only" downloaded ~1600 times/week, miniscule for npm. If you are tempted to use ssh-keygen, I recommend you learn how to use execFile/spawn, and use the native program directly.

For context, I published this 10 years ago, as one of my earliest contributions to open source. I probably wouldn't have gone near any security-essential contributions if I had more experience at the time.

You are a legend.

Exactly. If PlatformIO had enough paying customers who needed support for this chip, they would probably want to add support for it themselves.

It's the non-paying "customers" who are the problem here, expecting PlatformIO to grow in ways that the core team sees as unsustainable.

It's not a conspiracy that Google pays Mozilla for default search engine placement.

Maybe that arrangement led to the stagnation of Firefox, without malicious intent from any party. Hanlon's razor, yadda yadda

Yeah this is highly excessive and irregular use of haptics. I expect they will turn that off by default within a week.

I turned off haptics immediately in settings, but most people will be complaining before they figure that out.

It is annoying enough the way that ChatGPT drips out results, but now it acts as a low-quality hand massager and battery drain too?

Not ideal, but the product is still very good and people will happily use it, regardless of these "extra features"

I would argue we are in uncharted waters, so we can't even say for certain that it is important to find optimal formats.

Maybe 15 "standards" aren't enough and we will have 1500 that LLMs will happily use and learn

xkcd/927 may loose relevance in the era of LLM

Thanks. I have re-posted this comment as a reply in your thread.

https://news.ycombinator.com/item?id=34777780

Regarding this blog post, I don't understand how AGPL is a good fit for the first stated use case.

>Case 1: You fork our code to build your own billing system at your company. It’s awesome and we would be grateful if you could take some time to share your code as well, as it could help other companies. This is _strongly encouraged but not required_, as we understand not all companies can afford to do this.

And later in the quoted explanation of AGPL:

> "If you run a modified program on a server and let other users communicate with it there, your server must also allow them to download the source code corresponding to the modified version running there."

If you fork the project, your company's customers are communicating with your forked code. So are you required to publish your forked changes? Only required to share the fork with paying customers? Or as your desired case states, not required?

(In any case, Lago looks very cool. Thanks for pushing forward the conversation on open licensing!)

I don't understand how AGPL is a good fit for the first stated use case.

>Case 1: You fork our code to build your own billing system at your company. It’s awesome and we would be grateful if you could take some time to share your code as well, as it could help other companies. This is _strongly encouraged but not required_, as we understand not all companies can afford to do this.

And later in the quoted explanation of AGPL:

> "If you run a modified program on a server and let other users communicate with it there, your server must also allow them to download the source code corresponding to the modified version running there."

If you fork the project, your company's customers are communicating with your forked code. So are you required to publish your forked changes? Only required to share the fork with paying customers? Or as your desired case states, not required?

(In any case, Lago looks very cool. Thanks for pushing forward the conversation on open licensing!)

> - The plan appears that user names are delegated to the centralized DNS system (https://github.com/nostr-protocol/nips/blob/master/05.md)

DNS is not centralized, it is distributed. A name server can delegate authority to other servers. Every nation has their own, which I consider sufficient decentralization. (Although it does rely on IANA to list addresses of root name servers, which is perhaps the centralization you refer to)

Do you propose another naming system?

Definitely sarcastic. Amazon didn't only survive the .com crash, but they ultimately thrived because a huge number of competitors were culled.

Even if this thread is fake, for me this is the most memorable thing about that phone

https://twitter.com/cooperlund/status/1185243122210656261

The original Markdown spec is very clear that HTML is allowed. So MD itself is absolutely a superset of HTML

https://daringfireball.net/projects/markdown/syntax#html

But in practice people mostly use MD variants, such as the "GitHub Flavored Markdown Spec" which may have some limits on HTML usage

https://github.github.com/gfm/#html-blocks

> I'm dropping your software without a second thought.

Ha, it sounds like more work to replace a free piece of software with something else than to use your own patched version. Especially if you have to replace it with something inferior or proprietary. If there are better-maintained alternatives, why did you adopt it in the first place?

Pull requests take work to review and test. You shouldn't take that for granted and assume everything will be merged for free.

If you manage to review and test fixes faster than the original, or if you're willing to add features and maintain the code yourself, go and promote your fork!

MJML-React is awesome to use because of the JSX support: 1. you can integrate real JS without using some templatey thing, and 2. type safety with TS, helpful for auto-completion and robustness

Anyways it seems that Wix is no longer maintaining the project and Faire has taken it on: https://github.com/Faire/mjml-react

The whole paragraph is self explanatory and makes sense in this article because it prohibits huge swaths of people from adopting EVs.

Some people tend to freak out when race is mentioned, I suppose, so they can't even read a few more lines of context.

I really miss the early days of Sketch (DrawIt, anyone?)

As a developer it's been a bittersweet journey to see Sketch grow to be so popular amongst designers.

In 2012 I was excited to "buy" Sketch for $50, but I am less enthused to subscribe at $100/year. At this point I'm looking for a more lightweight and longer-lived solution. Figma is a nice alternative but the price is likely only going up from here.

The license seems a bit ambiguous. $49 for a "one user license", I hope that really means "one developer"?

But one developer can build an app used by many users. So I suppose you are oddly pressured into buying the more expensive license because you probably have more than one "user"?

Generally, I feel uncomfortable investing in source-available tools. That said, if I needed a PDF viewer in a React app in a pinch, I'd probably reach for this and pay for the full license.

More details on the license found here: https://react-pdf-viewer.dev/license/

This is the part that would freak out most lawyers: "You may combine the Item with other works and make a derivative work from it. The resulting works are subject to the terms of this license."

I didn't know about this!

But on the client I would use a JSON-schema validator anyways, otherwise I'd need something like "json-schema-to-zod"? Seems like a roundabout way to address my problem

Nice! I have been happily using json-schema-to-ts for this exact thing.

And if you're doing code generation, there is also json-schema-to-typescript

Zod is great, but JSON-schema is my pick because it is easily serialized. So a client can query for the schema of the data it should send or receive, including descriptions/metadata that is useful for presenting a UI.

By this logic we should also get rid of Discord? It is basically owned by Tencent (aka, is also owned by China).

I am not sure what makes the most sense from a foreign policy perspective. But we should be careful about our selective attention.

Agree its a bit unnatural, but it seems workable. My problem with the auxiliary table is, I wouldn't know how to implement the unique constraint.