We're trying to hire an Angular design engineer, so now the recruiter is the person trying to get management to switch to React to make his search easier. The tech doesn't matter too much, but the market forces do.
An issue I've noticed with court imposed fines is that they seem to be set based on the cost of the incident involved, not relative to the finances of the org/person being fined. A pipeline is very expensive, so fines end up being very expensive regardless of the receiver's ability to pay. OTOH, a large company can destroy lives with impunity since the cost of a person's entire lifetime earnings is not material to a multinational corporation's bottom line. This seems backwards to me. Fines should be set in such a way as to properly disincentivize behavior and adjusted to the means of the person/organization paying them.
You missed the point of the court's decision. This was a civil trial for damages. Criminal fines weren't a factor here. The intent of damages is to make the plaintiff whole. The defendant's finances aren't supposed to be a factor.
There's a good chance that the total damages will be reduced on appeal. This case will drag on for years.
I'd love to see the training data open sourced for all models so we can be sure no copyright material has been used. Just kidding, we all know it's stolen.
Loki by Grafana Labs is nice (https://grafana.com/oss/loki/). There was a time (3+ years ago) where the product was changing pretty rapidly and much of the documentation was on git, so we had a few headaches doing minor version bumps, but I believe its much more mature now.
- It is non-trivial to setup and operate. It requires properly configuring and orchestrating numerous components - distributor, ingestor, querier, query frontend, compactor, consul, ruler, memcache, index service, etc. - see https://grafana.com/docs/loki/latest/get-started/architectur...
- Its' configs tend to break with every new release, since some configs become obsolete and some configs change names and/or structure.
- It is very slow on "needle in the haystack" queries such as "search for logs containing some rarely seen trace_id", since it needs to read, unpack and scan all the logs at object storage. This may be also very expensive if the object storage service charges for read IO.
- It doesn't support log fields with big number of unique values (aka high-cardinality log fields). It you'll try storing logs with high-cardinality fields into Loki, then it will quickly explode with enormous RAM usage. Recent Loki releases provide half-baked solution for this problem - "structured metadata" ( https://grafana.com/docs/loki/latest/get-started/labels/stru... ), but it is still experimental and requires non-trivial configs (aka it doesn't work).
I'm not the person you asked -- and I also want to be transparent that I only PoC-ed it and due to external circumstances didn't get it all the way out to production -- but I really like how https://github.com/metrico/qryn (AGPLv3) thinks about the world. It is, like SigNoz, unified (logs, metrics, traces) but it actually implements several of the common endpoint schemes allowing it to pretend to be "your favorite tool" which plausibly helps any integration story <https://github.com/metrico/qryn#%EF%B8%8F-query> and <https://github.com/metrico/qryn#-vendors-compatibility>. Had I gotten it up and running, I was going to contribute a Splunk ingest adapter since that was what we were trying to replace
I believe one could do that with SigNoz, too, so I don't mean to imply that trickery was qryn specific, just that I didn't want to get into the "constantly resizing io3 PVC" game
Take a look at VictoriaLogs - https://docs.victoriametrics.com/victorialogs/ . It is a single small executable, which runs out of the box with the default configs (e.g. it is zero-config) and stores all the data into a single directory (support for object storage coming soon).
Lots of people have mentioned Polars' sane API as the main reason to favor it, but the other crucial reason for us is that it's based on Apache Arrow. That allows us to use it where it's the best tool and then switch to whatever else we need when it isn't.
People here don't seem to realize the importance of Canadian content rules in maintaining a cohesive national identity and supporting local content producers. The overwhelming barrage of U.S. media necessitates funding the creation of Canadian content, artists and points of view.
reply