Absolutely anything? GitHub slowly became a standard through market share. Concourse CI is much better, in fact nearly anything is better than GitHub as it doesn't have first class container support.
I blame this on two things, technology and the financialization of everything.
Long ago places had large parks, outdoor swimming pools, cities became less of a place to live and more of an efficient use of space/money and thus the human aspect was removed.
Technology in the sense of games, twitter, chat, etc removes the superfical need for human contact but ruins real bonds with people
Low level how does this compare to Victoriametrics, you can get the high cardinality with clickhouse and other columnar dbs but the tradeoff is more ram usage, slower queries, io, etc
the tradeoff with regards to slower queries and io only comes into play if the TSDB is performing a narrow lookup on a handful of series. In that case it’ll be faster. But when you scale up to 100s of millions, columnar dbs like Parseable win because-
a) there's no per-series inverted index and labels are parquet columns so memory is not bounded by cardinality
b) data lives on much cheaper object storage (parseable gives an option to cache data locally to remove io bound latency)
c) columnar store helps with faster data scanning by aggressively pruning and filtering data out
Most time series databases are columnar in some way. It is just because sotring and compressing timestamps and values as separate columns is way more efficient. So it is not a trait on its own, unless you compare yourself with Postgres.
> a) there's no per-series inverted index and labels are parquet columns so memory is not bounded by cardinality
Lack of inverted index is trade-off, in the same way as having that index. Default per-label inverted index in Prometheus, Mimir, VictoriaMetrics is convenient for users - requires no configuration from user side, all read queries, despite which time series selector was used, are as fast as they could be. Although, VictoriaMetrics doesn't store its whole index in-memory. It only stores what's "hot" now.
If you don't index all the labels, then you either asking user to choose what matters most, or intelligently decides what should be indexed. Either of these choice can take you to a corner case when query speed will be negatively affected despite having enough resources to burn.
> c) columnar store helps with faster data scanning by aggressively pruning and filtering data out
Columnar layout is not enough. Faster reads are achieved by reducing random seeks. A sequential read of a big chunk of data will always outperform multiple reads that pull the same data but from many places.
The same data can be stored in a columnar database with and without preserving data-locality (a trait that helps doing sequential reads). Let's talk time series. If in columnar database I'd decide to sort the columns by some common label and not by "timestamps" - data locality will be lost for typical queries that request "last 30min" of data.
The issue is "physically demanding", look at the guys that are 50+ in the trades, they have all sorts of physical issues from working in the trades. I say this as someone who has two JM qualifications.
Serious injuries which will nag for the rest of your life do happen, but they're extremely rare. All things being equal, physical work is vastly better for your body than sitting at a desk for 8 hours a day. Desk work is associated with increased chances of heart disease, obesity, mental health issues, and much more. We're not meant to be sedentary, but desk work basically requires that.
The confounding factor is lifestyle. Kicking back after a hard day of physical work with a huge meal and a few beers feels amazing, but that's going to wreck somebody's health if that turns into a lifestyle. And similarly, a gym rat who works a desk job is going to probably be in excellent shape.
Gym rat + desk job hints at passable cardiovascular health though. An overall healthy body in the modern age is very tough* and time-consuming when you consider all aspects..
I know 5 people closely that have had long careers in the trades.
They are all physically damaged in ways I am not from sitting at a desk.
What I notice about the trades is that the conversation from the inside is mostly about retirement because the work is not fun the way I find my white collar work to be fun.
Well okay you have your anecdotal evidence while I have mine, and they seem to be opposed to each other so I guess the truth lies somewhere in the middle. Some like it and some don't. Some hurt their bodies and some don't. It also matters a lot which trade exactly. Painting ship tanks is not good for the lungs it seems to me.
I'm not so sure about that. I think there are things you can do in either case, but you do not want to be in roofing for 40 years. I would take a 100% sedentary job over roofing 10/10 times
All things are relative. As I'm sure you know, roofing is one of the deadliest professions there is with an on-the-job mortality rate of about 50/100k per year. Do it for 40 years and your risk of dying on the job is almost 2%. That seems high, but the interesting thing is, about 17% of men who celebrate their 18th birthday won't make it to their 60th birthday. [1] So even if you do roofing for 40 years, your odds of dying on the job are much less than your odds of dying due to something else. Life's short - often said, but often only realized much too late in life for it to matter.
You also have to appreciate one other thing about health. 30-40 years ago digital work was a very small part of the labor force. Today it's a large part. So we're only starting to see the long-term consequences of sedentary work, on a large scale in relatively recent times. Then you also need to pair this with the emergence of endless entertainment of the internet to also create the possibility of sedentary work paired with sedentary lifestyles. I expect we'll find that the aggregate health outcomes of this are going to dwarf even smoking.
The issue imo with Gentoo is the compiler flag explosion, the giant case statement I had long ago for packages that would fail to compile on even simple standard -Werror= was huge.
I often think of Debian as a bit moldy from some changes over the years with legacy support (kludges?) in place, where it seemed more like an outdated Arch Linux at some point once it had switched to systemd.
But if I were CERN, I understand the choice of not getting involved with newer forks that aren't novel distributions you can trust to be around for the long haul. I would choose Debian as well in their place.
RHEL is EOLing CPU architectures that CERN still relies on heavily.
> RHEL 9 mandated x86-64-v2, requiring instruction sets like SSE4.2 and POPCNT, while RHEL 10 targets x86-64-v3. CERN's accelerator infrastructure manages more than 2,200 specialised front-end computers and 17,000 embedded devices, including legacy Core 2-era and custom industrial boards, engineered for 10- to 15-year lifecycles aligned with long-term accelerator shutdown windows. Upstream microarchitecture mandates threatened to abruptly obsolete thousands of functional, purpose-built control nodes.
And they are, in fact, planning to continue to use RHEL and/or AlmaLinux on their desktop and datacenter machines, even going so far as to adapt Fedora's build system to support building Debian packages[1] to leverage their existing RPM infrastructure.
As I understand it (from reading another article[2] posted on HN a few days ago), this change applies purely to the layer of machines that more or less directly interface with their experimental hardware, which has requirements more akin to industrial controllers than workstations or servers when it comes to the expectation of long service life with limited windows for scheduled maintenance.
reply