hashhar

  trino> USE memory.default;
  USE
  trino:default> create table artist (artistid int);
  CREATE TABLE
  trino:default> create table album (albumid int, artistid int);
  CREATE TABLE
  trino:default> insert into artist values 1, 2;
  INSERT: 2 rows
  
  Query 20220804_182827_00005_n4rat, FINISHED, 1 node
  Splits: 19 total, 19 done (100.00%)
  0.52 [0 rows, 0B] [0 rows/s, 0B/s]
  
  trino:default> insert into album values (11, 1), (12, 1), (21, 2);
  INSERT: 3 rows
  
  Query 20220804_182857_00006_n4rat, FINISHED, 1 node
  Splits: 19 total, 19 done (100.00%)
  0.18 [0 rows, 0B] [0 rows/s, 0B/s]
  
  trino:default> select * from (select * from artist limit 2) a cross join lateral (select * from album where album.artistid = a.artistid limit 2);
   artistid | albumid | artistid
  ----------+---------+----------
          1 |      12 |        1
          1 |      11 |        1
          2 |      21 |        2
  (3 rows)
  
  Query 20220804_182930_00007_n4rat, FINISHED, 1 node
  Splits: 41 total, 41 done (100.00%)
  0.35 [8 rows, 232B] [22 rows/s, 661B/s]

But, yes, we do plan to add that eventually after ironing out all the kinks. See https://github.com/trinodb/trino/pull/13094

To be pedantic though Flink also operates on a flush interval so not "real time" by that definition.

> Here, the continuously running Flink job parses the JSON data source directly following the Iceberg table schema definition. This means future schema changes can be facilitated through just one source of truth.

This is the most interesting point. I'd love to take this implementation out for a spin - could solve a lot of pain I know other people deal with too.

Most of the pain (or even grunt-work) of managing data pipelines is updating, validating and managing schemas.

In the past the common approach people suggested was to have each application write the data with the same schema but in practice it's never possible unless it's a greenfield project and the services don't need to talk to other external or pre-existing systems. What ends up happening is that a translator (or validator) service comes up whose job it is to translate across the various schemas. 2x storage in Kafka, 2x compute for the consumers and probably 20x more maintenance and ways things can go wrong.

diff3 has another advantage in the general case as well since it allows you to better understand if something outside of the hunk you're applying also needs to be changed when backporting something.

See `change-password` under https://en.wikipedia.org/wiki/Well-known_URI.

Also having everything system specific live under a single path means easy backups, easy immutable trees that can be A/B swapped for seamless and online updates with easy rollbacks.

No more wondering where the various tools live since everything lives in /usr/bin and more.

By LunaSec IIRC.

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

It really makes a lot of difference especially with podcasts since people tend to enunciate a bit more than usual and end up adding micro-silences that can easily add up into minutes.

I don't see any benefits at all from this.

I currently have a workflow like:

1. Add tags, move and rename files using MusicBrainz Picard.

2. Run beets on the files with the writing, tagging and renaming options disabled.

The keys which are left empty in the yaml need to be provided by a local config file like beets -c secrets.yaml. A sample secret file can be seen here[1].

This means that I can still use beets to do things like fetching lyrics (but not writing to ID3 tags), creating smart-playlists, updating my MusicBrainz collections etc.

Due to this workflow you might find that the beets config is lacking a lot of plugins and configuration that would allow it to replace MusicBrainz Picard like the chroma plugin, fetchart etc.

Some of the cooler beets plugins that complement Picard are:

mbsync: It can fetch updated metadata for existing tracks solving my biggest issue with Picard.

lastimport: To import playcounts from Last.fm

smartplaylist: To generate rule-based playlists. Now I can have playlists by decade or by genre or even something like "songs from 2000-2010 with danceability > x (from AcoustID)"

missing: to list missing tracks from an album

[1]: https://github.com/hashhar/picard-beets-config/blob/master/b...

It talks about exactly what you are saying - why do all raps have to be about guns, violence, drugs and domestic violence etc.

Much hugs to the GitHub SREs.

It's a nice bird's eye view. One thing I'd like is for there to be multiple metrics to use for the size of packages e.g. lines of code, number of files, number of methods etc.

That way you can make sense of what are the heavyweight parts of the codebase.