tison

I'm using typos in more and more repos I write or participate in. It helps to "fix typo" automatically. A real engineering solution; I like it.

Reading your description, the major challenge is about hosting static content with a proper DNS setup.

Then I would suggest you take a look at Vercel Hobby Plan + Godaddy domain. I hosts most of my website under this solution. I ever heard that Godaddy may be an overkill or over expensive, but it's affordable to me and it works, so I save time to do more research.

Here is some website example (I used to use NexT, but perhaps recommend Hugo / Docusaurus today), while a resume page can be too simple to use this "tools".

* https://www.tisonkun.com/blog/greptimedb-community-report#su...

* https://www.tisonkun.org/archives/

I seldom work on AI. For a few years, my opinion has always been: each wave of AI uses different technology. I don't find a continuous flow in this domain, nor do I understand its underneath better.

So, investing in AI is a large risk: back to my university, the popular AI framework is a neural network, logistic regression, supported-vector machines, etc.

Instead, I spent time working on data infrastructure, which keeps evolving but follows a somewhat consistent direction. If you look at databases, the essential building blocks are identical to those fifty years ago.

I first worked on Apache Flink and became a committer after one year as a contributor. And then Apache ZooKeeper and Curator, so did become a committer / PMC member. Later TiDB / TiKV and now GreptimeDB. The knowledge and experience is reusable.

My first job was developing and maintaining a streaming system based on Apache Flink. Thus, it's normal to me that a "full-time opensource developer" can get paid.

Of course, there are some in-house tasks. But still, I spent a lot of time participating in the upstream community and became a committer after about one year's contribution.

That said, after I changed my job, my engagement decreased considerably. But my following jobs are mostly still full-time OSS developers:

* PingCAP for TiDB and TiKV. I wrote its dev guide and built its (new) governance.

* StreamNative for Apache Pulsar.

* Greptime for GreptimeDB.

Many (infra) software MUST BE open source today. You may see my explanation at https://www.tisonkun.com/blog/greptimedb-community-report#su....

I've worked at the ASF for over 5 years. Arriving in the new (Rust) ecosystem and connecting on platforms like HN extend my reach, and I enjoy that people collaborate to deliver software :D

Related thread:

* https://github.com/rustsec/advisory-db/issues/1921

* https://twitter.com/mitsuhiko/status/1772576163371655263

Days before I'd prefer manipulating between threads manually, because I used to do it for years.

But as it goes much mature the async-await especially with stackless coroutine implementation, writing in async-await is more pleasure than handling threads.

Handmade futures can have some pitfalls, like this blog wrote: https://blog.waynest.com/2022/12/async-cancellation/

However, I don't like Rust's trend of making global, implicit async runtime, especially with #[xxx:main]. Runtime should be specified clearly, like Netty channel must explicitly bind to an EventLoopGroup. And Java's CompletableFuture without specifying a concrete executor causes many issues already.

Thanks for your sharing.

I was ever working actively on Apache Kvrocks, an alternative for Redis on Flash. And we benefit a lot from Redis docs to catch up its command. In comparison, Kvrocks docs is clearly "less than awesome".

In my $DAYJOB, I convince my boss that the docs, at least the README is important, as you show the esbuild example here.

Here are two patches to improve the README of it:

* https://github.com/GreptimeTeam/greptimedb/pull/3528

* https://github.com/GreptimeTeam/greptimedb/pull/3522

That in #3522 firstly, I tried to reduce the content and "offload" the detailed docs into the doc site. And in #3528, I found that heading elements center align is still fancy and we need some short, clear introduction and advantages.

Anyway, a good product is the leading 1 and docs is the following 0. Without a good product, no good docs can be present.

If I get "local cache layer" correctly, it's possible. And it's even desired if you want to reduce the deployment burden.

Here are some related codes on how we implement such a layer in GreptimeDB:

* https://github.com/GreptimeTeam/greptimedb/blob/v0.7.0/src/o... * https://github.com/GreptimeTeam/greptimedb/blob/v0.7.0/src/m...

It's ever discussed in https://github.com/apache/arrow-rs/issues/3888 for comparing object_store in Apache Arrow to the APIs provided by Apache OpenDAL.

Briefly, Apache OpenDAL is a library providing FS-like APIs over multiple storage backends, including S3 and many other cloud storage.

A few database systems, such as GreptimeDB and Databend, use OpenDAL as a better S3 SDK to access data on cloud storage.

Other solutions exist to manage filesystem-like interfaces over S3, including Alluxio and JuiceFS. Unlike Apache OpenDAL, Alluxio and JuiceFS need to be deployed standalone and have a dedicated internal metadata service.

This article was written half a year ago. It talks about the bar to open-source participation, productivity, DX, and sustainability.

Make a much smaller JVM-based application Docker Image without JRE.

Sounds likely.

The core part of OpenDAL is a Rust crate that provides fs-like APIs over different storage backends, but we also investigate providing other interfaces like a CLI. We have an experimental binary named `oli`[1].

You're welcome to start a discussion[2] to share how you use rclone and we may find it fit in OpenDAL's scope :D

[1] https://github.com/apache/incubator-opendal/tree/main/bin/ol... [2] https://github.com/apache/incubator-opendal/discussions

It's hard to me ever on OpenDAL also.

But now I have an image that you can use it either as:

1. A drop-in replacement to S3 SDK (AWS's Rust SDK is ...); 2. A quick way to support your users to configure different cloud storage they have (release you from supporting multiple cloud OSS backends with different SDKs).

A few increasing DB projects use OpenDAL in the second way, like Databend, GreptimeDB, QuestDB, RisingWave, etc.

Engula is a serverless storage engine that aims to help users build reliable and cost-effective databases.

The idea comes from that when you want to build a serverless database, you have to build the storage engine from nearly scratch now. For example, CockroachDB and Pebble, TiDB and TiKV, etc. We're aimed at an adaptive storage engine that can be adapted to different workload.

We have published a design document[1] to introduce concepts and architecture.

Engula 0.2 comes with one engine and three kernels:

* A hash engine that supports simple key-value operations.

* A memory kernel that stores everything in memory.

* A file kernel that stores everything in local files.

* A gRPC kernel that stores data in remote gRPC servers.

The release is a join force of our community. Welcome to the discussion forum[2] and share your thoughts. A contributing guide[3] is present describing how the community works.

[1] https://github.com/engula/engula/blob/main/docs/design.md

[2] https://github.com/engula/engula/discussions

[3] https://github.com/engula/engula/blob/main/CONTRIBUTING.md