Reader

Jim Garrett

1. Introduction
2. Why binning is so seductive
3. Statistical efficiency
4. Representing Nature

Introduction

Over and over I’ve found my data analysis strategies to be contrary to those of many of my peers. One area of differing inclination is that, when given continuous data, I try very hard to analyze it as continuous, rather than binning it. My preference is, according to standard principles, the theoretically preferred approach: binning is discarding information and loss of information must lose statistical efficiency. Nevertheless, this textbook advice is almost universally ignored.

I’m going to argue here that binning is a bad practice, but not for statistical efficiency reasons. Instead, I argue for trying hard to analyze continuous data on the grounds of clarity. The more we meet Nature where she is, the more clearly we can understand her and make reasonable decisions.

Note: I’ve realized that this blogging platform doesn’t allow one to include figures, unless one has access to the server, which I don’t. I’m in the process of setting up my own web site, at which point I’ll move my blog there. In the meantime, in lieu of figures, I’ll include code to produce the figures. Perhaps this will offer a little tutorial benefit. At least, I’m trying to make lemonade out of a lemon.

Here’s some setup code:

library(rms)
library(mgcv)

## A crude hand-sketched example
template <-
    data.frame(x = c(0, 4, 5, 6, 7, 8,    9,  10),
	       y = c(0, 0, 1, 3, 4, 4.25, 4.5, 4.75))

## A function to linearly interpolate
tempFun <- 
    approxfun(x = template$x,
	      y = template$y)

## Generate 
set.seed(123)
datbin <- data.frame(x = runif(300, 0, 10))

## Transform template to probability scale, ranging from 0.1 to 0.8
invLogit <- function(r) 1 - 1 / (1 + exp(r))

LogitLow <- log(0.1 / 0.9) # -2.197225
LogitHigh <- log(0.8 / 0.2) # 1.386294

datbin$p <-
    invLogit((LogitHigh - LogitLow) / tempFun(10) * tempFun(datbin$x) + LogitLow)

MedianBin <- median(datbin$x) # 4.778207

datbin$XGp <-
    factor(ifelse(datbin$x >= MedianBin, "High", "Low"),
	   levels = c("Low", "High"))

set.seed(456)
datbin$YBin <- rbinom(nrow(datbin), size = 1, prob = datbin$p)

Why binning is so seductive

As mentioned, virtually any academic statistician will argue against binning categorical data on efficiency grounds, and yet the practice is pervasive. Why? I don’t know for sure, but my guesses are as follows.

First, our customers ask for it. Very often a statistician’s customer is a medical clinical researcher, and many clinical researchers are accustomed to seeing a comparison of discrete groups. In fact, many clinical researchers aren’t even aware that any analysis other than comparing groups is even possible, if the response is not continuous. For instance, if the response variable is binomial with a hypothesized probability p that depends on independent study factors, a non-statistician researcher may imagine that a probability is a property of a group, i.e., a proportion of the whole. To evaluate a probability of an outcome given a study factor, we must define a subgroup based on the factor and then count successful outcomes per subgroup. Modelers know that logistic regression can describe the probability p as changing continuously as a function of other factors: it’s possible for every single study subject to have their own distinct probability p.

Therefore a clinical researcher asks for a subgroup definition because they prefer to think that way or they’re unaware of alternatives. Next, the pliable statistical analyst may want to please his customer by fulfilling the request as quickly and directly as possible. This raises questions about what a statistical analyst’s ideal role in collaboration is, but that’s for another day….

Second, binning can simplify analysis. Continuous data cannot be depended upon to be nicely normally-distributed as in textbook cases. There can be non-normal distributions, skewness, outliers, etc. When relating to other variables, we similarly cannot rely on relationships being linear. All of these problems simply go away when we bin. Deciding not to bin is not a simple choice, but is rather a commitment to cultivate an entirely new toolbox of analysis strategies suitable for messy cases.

Given the analyst caught between customers demanding binning on the one hand, and maybe not fully confident about their continuous-data toolbox on the other hand, perhaps it’s no surprise that most analysts simply provide the customer with what the ask for.

Still, I challenge statistical analysts to start nurturing that toolbox. If you want to know how, watch this space.

Statistical efficiency

Let’s consider the question of statistical efficiency and power with a simple hypothetical example. Suppose we are assessing a possible biomarker in a clinical trial, and the biomarker is assayed on 300 subjects. Biomarker values are uniformly distributed over a range. Suppose the clinical outcome is binary. An increased biomarker value contributes to an increased probability of clinical response, and the true relationship is per the piecewise-linear curve generated as follows:

plot(0:10,
     invLogit((LogitHigh - LogitLow) / tempFun(10) * tempFun(0:10) + LogitLow),
     type = "l",
     ylim = c(0, 1),
     main = "True probability of response",
     xlab = "Biomarker value",
     ylab = "Probability of response")

(This produces a piecewise-linear curve that is somewhat sigmoidal, starting from a probability of 0.1 (where it remains for some time), and then it increases rapidly to roughly 0.7. Then it continues increasing, but at a slower rate. Over the range of the curve (from 0 to 10), it reaches a maximum probability of 0.8.)

Even though the curve is crudely piecewise linear, it has some features that complicate real-world analysis:

• It is not linear, not even on logistic scale.
• The probability of clinical response does not reach zero at the low end of the biomarker range, nor does it reach 1.0 at the high end. The biomarker is informative but there are clinical exceptions.
• At the high end, increasing biomarker value contributes to increased probability, but at a slower rate.

We want to assess whether the biomarker is worth investigating further, and if so, the nature of the relationship. I’ll carry out three alternative strategies:

1. Calculate the median value of the biomarker and split cases into biomarker “High” and “Low” groups accordingly. Apply Fisher’s Exact Test to test for association between binary biomarker group and binary clinical outcome.
2. Fit a generalized linear model relating binary outcome to a smoothing spline estimate of the biomarker’s contribution. Use an approximate test against the null model of no relationship. Optionally, we can assess evidence for non-linearity. Obtain an estimate of the relating curve, with pointwise confidence intervals.
3. Similarly, fit a logistic regression model, but use a natural spline expansion for continuous biomarker values. Obtain a likelihood-ratio test against the null of no relationship, and as with the GAM, assess the evidence for non-linearity and obtain an estimate of the curve mediating the relationship.

Should we include fitting a continuous model that assumes linearity? I think not, because we don’t know if that’s the case, and a non-linear relationship is quite plausible.

With alternative (1), Fisher’s Exact Test gives a p-value “< 2.2e-16”. Statistical efficiency is not an issue here.

(The following code evaluates Fisher’s Exact Test with the X grouping against the binary outcome.)

fisher.test(datbin$XGp, datbin$YBin)

With the GAM–alternative (2)–we also find <2e-16 as a p-value against the null hypothesis of no relationship. The following code generates an estimate of this relationship:

GamMod.init <- gam(YBin ~ s(x), family = binomial, data = datbin)

summary(GamMod.init)

plot(GamMod.init,
     trans = invLogit,
     ylim = c(0, 1),
     main = "Logit outcome vs biomarker",
     xlab = "Biomarker",
     ylab = "Logit of outcome probability")

(The figure shows a figure that tracks the true curve, but it is implausibly “wiggly”.)

This tracks the true curve but is too wiggly to be plausible. Manually forcing the smoothing parameter to be large enough so that the curve is almost monotonic, we find:

GamMod <- gam(YBin ~ s(x, sp = 0.05), family = binomial, data = datbin)

plot(GamMod,
     trans = invLogit,
     main = "Logit outcome vs biomarker",
     xlab = "Biomarker",
     ylab = "Logit of outcome probability")

(The code generates a less-wiggly curve that still tracks pretty well.)

The actual predicted probabilities are not very different between these estimates, actually, and they both give p-values of <2e-16 against the null model.

## initial model
summary(GamMod.init)

## Add a linear component to the initial model so that linear and non-linear 
## components can be assessed separately.
GamMod.init.lin <- gam(YBin ~ x + s(x), family = binomial, data = datbin)

summary(GamMod.init.lin)

## smoother model
summary(GamMod)

(The initial and the smoother GAM models both show a p-value for the relationship betweeen X and outcome of <2e-16. Additionally, a linear term is added to the initial model in order to assess the non-linear contribution separately. This shows that p-values for the linear and the non-linear contributions are both very small.)

Applying alternative (3), unpenalized spline regression, we obtain the following curve:

## Use rms package to enable nice ANOVA
RegModBin <- lrm(YBin ~ rcs(x, parms = 5), data = datbin)


## Use base or "stock" glm to support likelihood ratio test via base 
## anova function

RegModBin.s <- glm(YBin ~ rcs(x, parms = 5), data = datbin)

## Plot
## Set of points on X axis for plotting
TmpSeq <- seq(0, 10, length = 200)

## Get predictions on logistic scale, then calculate confidence limits
## on that scale, then transform to probability scale
Preds <-
    predict(RegModBin,
	    newdata = data.frame(x = TmpSeq),
	    type = "lp", se.fit = T)
## has components "linear.predictors" "se.fit"

CIReg <- 
    data.frame(Est = invLogit(Preds$linear.predictors),
	       Low = invLogit(qnorm(0.025,
				    mean = Preds$linear.predictors,
				    sd = Preds$se.fit)),
	       High = invLogit(qnorm(0.975,
				     mean = Preds$linear.predictors,
				     sd = Preds$se.fit)))

plot(range(TmpSeq), c(0, 1), type = "n",
     main = "Outcome probability vs. biomarker",
     xlab = "Biomarker",
     ylab = "Outcome probability")
polygon(x = c(TmpSeq, rev(TmpSeq), TmpSeq[1]),
	y = c(CIReg$Low, rev(CIReg$High), CIReg$Low[1]),
	col = "thistle", border = NA)
lines(TmpSeq, CIReg$Est)
rug(datbin$x[datbin$YBin == 0])
rug(datbin$x[datbin$YBin == 1], side = 3)

In this plot the Y-axis is on the probability scale rather than the logit scale. This is substantially equivalent to either GAM model. Here we can give an informative ANOVA breakdown:

## Generate the ANOVA table
anova(RegModBin)

Factor     Chi-Square d.f. P     
x          69.85      4    <.0001
 Nonlinear  9.89      3    0.0195
TOTAL      69.85      4    <.0001

## Likelihood ratio test using base R
anova(RegModBin.s, glm(YBin ~ 1, data = datbin))

This indicates that there is overwhelming evidence that the biomarker influences the outcome, and furthermore there is strong evidence of a nonlinear component, i.e., a departure from linearity on the logit scale. While this representation doesn’t show exactly how small the p-value is, a standard likelihood-ratio test yields <2e-16, just as the other methods.

In summary, all three approaches indicate strong evidence that the biomarker influences the clinical response. This does not support the idea that the continuous approach is more powerful. The median split represents the biomarker with 1 degree of freedom, while the continuous approaches use roughly 4 degrees of freedom. They yield more information, but “cost” more. It’s a fair trade, but it’s not clear that one always has more power than the other.

Rather, the reason that I recommend a continuous approach is that, in one step, we (1) assess evidence for a non-null relationship and (2) gain a reasonable estimate of that relationship. Further, we do the latter without carrying out substantial optimization or multiple looks at the response, which compromises statistical reliability.

Now let’s think a little more about real life.

Representing Nature

Here’s a true story illustrating how failure to look at continuous data can lead to self-imposed confusion and obfuscation, also cost real money, and delay important projects.

As the resident expert in clinical diagnostic assays in a large pharmaceutical company (that’s not saying a great deal when the company didn’t nurture such expertise), I was pulled into an apparent assay issue impinging on an oncology clinical trial. The assay measured gene copy number (GCN) for a specific gene; a GCN value above a specified cutoff was a study enrollment criterion. That is, it was a companion diagnostic assay (CDx) for the therapy under study. Two labs carried out testing for the study, each serving a different geographic region.

Recently there had been some operational issues with the assay which had required troubleshooting; the assay vendor had confirmed the issue, put a fix in place, and, for good measure, both labs repeated operator proficiency validations. Then patient screening for the study resumed. After some time, however, the trial team noticed that the “prevalence” (incidence of GCN over cutoff) was higher at one lab than the other. It was decided to pause study enrollment once again. zNote that for a pharmaceutical company, completing trials quickly is the coin of the realm; pausing a trial was a Very Serious Matter. Meetings were held, numbers were compiled, and still bigger meetings were held. Finally this expanding process grew to include a bystander previously unaware of the entire study, i.e., me.

When I joined my first meeting, it was chaired by the head of Oncology, which, for the company organization at the time, reported to the CEO. Lots of highly-paid senior people were there; this was one of those meetings where the cash clock ticked quickly.

I was given the information that had been compiled up to then. This included assay positivity counts at each site. I asked, “Where are the GCN numbers for each of the sites? What does the GCN distribution look like at each site?”

Such information had not been compiled!

Consider for a moment what this indicates about priorities and corporate culture. The company was expending significant resources, pausing a trial and using a top executive’s time. It would have been the simplest thing to organize GCN values–they were available in the clinical database, waiting to be visited. There’s no question that the values actually measured would give a more complete representation than the processed values. Yet this value was not widely shared. If this describes your organization too, you have work to do!

As an aside, there’s another aspect to this: when you’re troubleshooting a data-related issue, investigate the data process from first information acquisition to final result before you invest time in a lot of other approaches. At what point does the data begin to look anomalous? Or, if you prefer, start at the end and work towards the beginning. The point is to be systematic and to “scan” the whole process to come to an understanding of the state of things. Looking at continuous data often means looking upstream; I also have an expensive war story about this. The error is committed again and again.

But back to our story: in not much time the team pointed me to GCN numbers and I was able to determine that the clinical cutoff for GCN was very near the median GCN value. This is not necessarily an error, but it is definitely problematic: a small shift in the distribution of measured values, such as can easily happen with many assays, will induce a substantial change in positivity rate. I fitted density estimates; they had similar shapes but one was shifted slightly higher than the other. If I shifted the higher density down by the difference in medians, the densities lined up quite well, and furthermore the apparent positivity rates closely agreed.

This difference in median was smaller than the noise in the assay, so an assay scientist wouldn’t worry too much about it, and would certainly recommend against placing the assay in a context where a trivial change (relative to assay variability) would be interpreted gravely. Red flags and warnings should have gone up when the clinical cutoff was suggested.

The team decided to carry out a paired sample study. Regulatory requirements prevented either lab from sending clinical samples to the other lab, but the assay vendor could split samples, test them, and send them to each lab. Then we could compare each lab to the vendor. Long story short, it turned out there was a small difference between the vendor and both labs, and in the same direction, but this difference was not meaningful. The trial resumed. Frankly, while there was an observed difference, when interpreted with quantitative data and an understanding of variability, there was no real issue. By looking at processed data and not turning quickly to the underlying quantities when questions arose, the team had gotten themselves in very costly tizzy.

Here’s what I’ve taken away from these experiences:

• Model continuous data when possible. It’s probably closer to the data that Nature gave you than binned or otherwise processed data. – Transforming such data towards a Gaussian distribution is fine, in fact it’s often beneficial.
• Analyzing data close to what Nature gave you will give you a more complete assessment. It may have some analysis complications, but it will give the decision-making team more confidence.

For more on this topic, check out Frank Harrell Jr.’s essays How to Do Bad Biomarker Research and a chapter on Information Loss.

#continuousdata #dataanalysis #statistics

2024年12月13日【ZWTV中旺電視】南加州聖蹟寺舉辦《恭迎南無阿彌陀佛佛誕法會》

2024年12月13日【中天北美新聞】南加州聖蹟寺舉辦《恭迎南無阿彌陀佛佛誕法會》

Byłaś i już Cię nie ma...

「與濼漫談」聖僧高人為什麼拜年輕人為師

年代新聞 ：驚！圓寂10天後！ 法體神變？返老回春？ 「因海長老」傳奇

Aspołeczna kawiarenka

I znowu myślę o opuszczeniu moich socjali... Znowu, bo w połowie sierpnia usunęłam swoje konto na mastodonie. Niestety tak już mam. Gdy życie daje mi za mocno w kość, to uciekam od wszystkich. We wrześniu poprosiłam o ,,przywrócenie do życia” mojego starego konta, więc jakoś tam wróciłam. A że życie nie jest fajne, a ludzie tym bardziej, to znów chciałabym się schować przed całym światem. Najlepiej tak, by mnie już nikt nie znalazł.

Nie jest niczym odkrywczym, że nie potrafię się odnaleźć wśród ludzi. A już socjalmedia to coś, czego nie da się ogarnąć w jakikolwiek sposób. A przynajmniej ja tego nie potrafię. Ostatnio natknęłam się na komentarz typu ,,to nie twój stoliczek, więc się nie wtrącaj do dyskusji” a później jeszcze, że ,,jak ktoś ma chorobę morską to nie pcha się na statek”. Nie brałam udziału w tamtej dyskusji, ale były to osoby znajome, z którymi raz na jakiś czas rozmawiam i ogólnie mam z nimi jakiś kontakt.

No więc ja już od dawna nie wędruję po ,,obcych” stoliczkach. To znaczy, nie odzywam się za bardzo pod postami innych ludzi. Ograniczam się do kilku osób, uznanych przeze mnie za ,,w jakimś stopniu bezpieczne”. Siedzę głównie przy ,,swoim” stoliczku i jak ktoś się odezwie do mnie to odpowiadam. I, wbrew temu co myśli sobie osoba, która wspomniała o unikaniu niebezpiecznych miejsc, wydaje mi się, że mój ,,własny” stoliczek też nie jest dla mnie bezpieczny. Bo co z tego, że ja unikam osób, które dla mnie stanowią zagrożenie. Korzystając z analogii do choroby morskiej. Ja mam chorobę morską, dlatego nie zapuszczam się w morze. Ale ci, co nie mają choroby morskiej i pływają sobie po tym morzu, nie mają też choroby lądowej, więc nie unikają miejsc w których ja bywam. W szczególności nie unikają mnie, bo im nie zagrażam w żaden sposób. Zazwyczaj osoby, których z jakichś powodów unikam, nie mają żadnych oporów, żeby odzywać się do mnie. A to dla mnie oznacza ryzyko. Bo nawet gdy mam w nazwie tęczową nieskończoność, to i tak większość osób na to nie zwraca uwagi albo nie mają pojęcia z czym to się wiąże. Pomijam ludzi, którym się po prostu nie chce, oprócz nich są jeszcze tacy, którzy zapominają. Spotkałam się też z osobą, która wiedząc, że jako autystka mam problem z ironią i sarkazmem ,,pozwoliła sobie na odrobinę ironii”. No bo dlaczego nie...

W cuda nie wierzę, w ludzi tym bardziej... Dlatego bezpiecznym miejscem dla mnie jest moja własna szafa. Powinnam tam sobie siedzieć, nie wychylać się i tylko kilku osobom dać namiary na tę moją szafę w nadziei, że o mnie nie zapomną i czasem się odezwą...

róża

moi bliscy usłali mi życie różami stąpam więc teraz boso po drogach usłanych kolcami

Chaos

Moim nieodłącznym towarzyszem życia zawsze był chaos. Czasami mniejszy, czasami większy, ale zawsze był. I choćbym nie wiem jak bardzo się starała, to nigdy nie potrafiłam sobie odpowiednio zaplanować i poukładać ani dnia ani tygodnia. W zasadzie jedyny czas kiedy moje życie było w jakiś sposób regularne to czas szkoły, studiów i te kilka lat pracy. Jak widać, była to regularność narzucona z zewnątrz, do której potrafiłam się jakoś dostosować. Nie zawsze perfekcyjnie, ale w jakimś stopniu mi się udawało, przynajmniej jeśli chodzi o obecność. Sama z siebie jednak nie potrafiłam nigdy wprowadzić żadnej rutyny. I nie chodzi tu o brak umiejętności zaplanowania sobie dnia czy tygodnia pracy. O nie, plany to ja potrafię robić. Problem zaczyna się z ich realizacją.

Dzieje się tak, gdyż nie potrafię w żaden sposób odnaleźć się w czasie. Nie wiem dlaczego, ale nie potrafię odpowiednio zgrać czynności z czasem. Np. jak mam gdzieś być o konkretnej godzinie to albo jestem dużo za wcześnie, albo biegnę na ostatnią chwilę. Nie trudno zauważyć, że marnuję sporo czasu wiecznie gdzieś na coś czekając. Drugą rzeczą, która utrudnia mi realizację planów jest jakieś wewnętrzne coś, nie wiadomo co, które siedzi sobie we mnie i jak tylko sobie postanowię, że zrobię jakąś rzecz, to automatycznie to coś sprawia, że nie jestem w stanie zrealizować zaplanowanej rzeczy. Nie wiem co to jest i z czego wynika. Najbardziej oczywiście owo coś przeszkadzało mi przed wszelkiego rodzaju egzaminami, kiedy ważne było zaplanowanie sobie nauki.

Jak tak sobie patrzę z perspektywy czasu i analizuję swoje życie, to okazuje się, że nigdy tak naprawdę nie uczyłam się do egzaminów. Ani do matury, ani na studiach. Akurat jeśli chodzi o egzaminy typu matura i sesje na studiach, to oprócz braku umiejętności zrealizowania planu nauki/powtórek, czynnikiem utrudniającym był stres i presja czasu. Im bliżej egzaminu tym większa niemoc zrobienia czegokolwiek. Dlatego mój sukces na egzaminach nieodzownie związany był z regularnym uczęszczaniem na zajęcia i samodzielną pracą w ich trakcie a także samodzielnym wykonywaniem tzw. prac domowych czy robieniem po prostu w domu dodatkowych zadań, bo najzwyczajniej w świecie sprawiało mi to przyjemność. Jak się można domyślić, jeśli czegoś nie lubiłam to miałam problem.

Z powodu tego wewnętrznego czegoś, czasami łatwiej zrobić mi coś spontanicznego, niż zrealizować plan. Czyli wypisz, wymaluj chaos.

Pomijam już rzeczy typu, zaczynam robić jedną rzecz, a kończę zupełnie z czymś innym, bo akurat coś zobaczyłam, usłyszałam itp... Kolejny temat rzeka a raczej łańcuszek czynności, nie do końca powiązanych ze sobą.

Ale ten chaos to nie tylko trudności w takim, codziennym funkcjonowaniu. To także trudności na mojej drodze do odnalezienia siebie. Bo ten wszechobecny w moim życiu chaos sprawiał, że przez długi czas nijak nie potrafiłam odnaleźć w sobie spektrum autyzmu, o którym wcześniej wielokrotnie słyszałam i próbowałam nawet czegoś o spektrum szukać ale odbijałam się za każdym razem od rutyny, której u mnie nie mogłam po prostu dostrzec w żaden sposób.

Gdy odkryłam o sobie prawdę, chaos stał się powodem do niepokoju. Bo jak już odkryłam, to szukałam osób podobnych do mnie, między innymi w tych moich socjalmediach. Od dawna miałam jedną koleżankę, dzięki której w zasadzie powoli zaczęłam ruszać temat. Później kolejna osoba z sieci. Co mnie zaczęło niepokoić, to właśnie ich bardzo poukładane życie. Ja takiego nie mam. U mnie rutyna jest, ale na opak. Dotyczy tylko konkretnych rzeczy. A więc jak mam biegać to muszę odstawić w domu cały rytuał przygotowawczy, a jak biegnę, to stałą trasą, z telefonem w ręku, żeby widzieć jakie mam tempo i jaki puls. Gdy tylko GPS przestaje działać, to zaczynam panikować i najczęściej nie jestem w stanie biec. Ale to tylko bieg. Natomiast nie potrafię biegać regularnie np. 3-4 razy w tygodniu. Tego już za wiele. Taka rutyna jest poza moim zasięgiem. I takich przykładów jest pełno. Dana czynność wykonywana wręcz rytualnie, ale bez zachowania regularności w czasie.

Odpowiedź na to jest tylko jedna. Jestem bardziej neuronietypowa, niż mi się wydawało. Spektrum autyzmu to tylko jeden składnik. Jest jeszcze drugi, który zaburza ten pierwszy. W zasadzie one wzajemnie na siebie oddziałują, a raczej na mnie, wprowadzając niemałe zamieszanie, przez które trudno dostrzec i jedno i drugie...

Odkrycie drugiego składnika dało mi chyba upragniony spokój. Taki wewnętrzny. Bo w końcu wszystko pasuje, układa się w jakąś jedną, spójną całość. I nawet gdy nie ułożyłam swojej układanki całkowicie, to i tak jest lepiej. Bo nie czuję już, że mam jakby dwa niepasujące do siebie zestawy puzzli.

Poza tym, już sama świadomość tej całości sprawiła, że w pewnym sensie trochę łatwiej mi w takim codziennym życiu. Bo już nie kopię się sama z sobą, nie próbuję na siłę robić rzeczy wbrew sobie, bo wiem, że to i tak jest bez sensu. I najważniejsze, nie mam już tego uczucia, że zupełnie nigdzie nie pasuję.

Tutaj tym bardziej nie będę robić niczego wbrew sobie. A zatem, w zgodzie ze sobą, wbrew temu co kiedyś pisałam, nie będzie żadnego planu tego miejsca, nie będzie regularnego pisania...

Witam w moim chaosie który tu był, jest i zawsze będzie...

A pesar de que la rudeza es una pieza fundamental para la construcción de roles y esquemas de relación en nuestras culturas, me parece que se habla poco de este elefante en medio del salón cuando se habla de psicología o cuando se analiza el funcionamiento de la sociedad.

La rudeza es uno de los ingredientes que suelen utilizarse en la receta de la masculinidad. Cada hombre usará de este ingrediente en mayor o menor medida pero parece difícil prescindir de él, como del ajo en las cocinas mediterráneas. El niño varón suele asumir que tiene que desarrollar su capacidad de rudeza para ser reconocido como plenamente masculino, el varón debe aprender a reprimir sus emociones, la única emoción cuya manifestación no cuestiona la masculinidad tradicional es la ira.

La rudeza es también una defensa frente a la conflictividad de las relaciones interpersonales en todos los ámbitos, una advertencia de respuesta violenta (física o verbal) ante eventuales agresiones.

La rudeza también funciona una estrategia para proteger la autoestima de la humillaciones de la convivencia y una manera de hacer algo más llevaderas las situaciones de dominación soportadas, muy especialmente en el ámbito laboral y militar, porque se supone que la rudeza revaloriza al individuo, compensando la desvalorización derivada de soportar y verse obligado a asumir situaciones de dominación. Frente a la dominación se reacciona con obediencia, que desvaloriza, y con una pose de rudeza, a la que se le atribuye un efecto valorizador, sobre todo en los machos.

El servicio militar obligatorio era una escuela de rudeza que enseñaba que el desarrollo de cierto nivel de rudeza era necesario para lograr la validación del grupo y de la autoridad. La supresión del servicio militar obligatorio ha reducido la valoración social de la rudeza, sin embargo las abundantes fantasías militares de la cultura del entretenimiento, siguen enalteciendo la rudeza, sobre todo como elemento de la construcción de la identidad masculina, pero también como elemento a valorar en ciertas identidades femeninas, de ruptura con la niña o con comportamientos de mujer tradicional.

¿La rudeza es un elemento que la empresa valora positivamente al seleccionar personal? Podría ser percibida por el seleccionador de personal como un indicador de aguante a la presión del dominio jerárquico (el trabajador rudo podría pensarse que no es tan propicio a coger una baja por ansiedad) y como un indicador de que el candidato a trabajador no cultiva otras habilidades sociales más trasversales que pueden perjudicar el control de la plantilla por el superior jerárquico al establecer lazos entre los trabajadores o al poner en entredicho, por comparación, las habilidades del mando.

El hombre de mediana edad, normalmente enfrentado a la realidad de una actividad laboral insatisfactoria, a una proyección social insuficiente y a la frustración de no haber alcanzado las promesas vitales que ofrece a los jóvenes nuestra sociedad de mercado, suele trabajar una coraza de cierta rudeza para compensar esos pequeños (muchas veces inevitables e incluso naturales) fracasos que dañan su identidad y autoestima. La rudeza puede ser un sustitutivo del estatus no logrado, pero incluso puede acompañar a la ostentación de estatus, como un adorno más. El rock viejuno, con toda una colección de grupos que lo cultivan, hace abundante uso de una imagen de rudeza de mediana edad.

Cerveza y tatuajes se han convertido en elemento de identidad de una buena parte de la población, demostración no solo de estar en la cultura contemporánea si no también de rudeza.

Siendo la rudeza un complemento importante para las personas de clase trabajadora y clase media, se entiende el potencial de la ideología rojiparda. La izquierda con origen en el 68, la izquierda más postmoderna, no se relaciona bien con esa demanda de identidad ruda. En cambio el rojipardismo si puede cultivar la imagen ruda o al menos, aceptarla.

Quizás la rudeza debería ser un elemento tenido mucho más en cuenta por la psicología y la crítica cultural, teniendo en cuenta el papel tan importante que juega al configurar el carácter y la cultura.

Some thoughts on statistical modeling and data science James Garrett

Some years ago, in a large pharmaceutical company, an academic paper circulated among some of the members of the statistical staff (of which I was one). It addressed the question of how logistic regression compared to machine learning (ML) methods in predictive accuracy with clinical trial data. The authors of the paper applied logistic regression models and found equal or better predictive performance than had been reported earlier with ML methods.

The paper was greeted by the statisticians with an uncomfortably tribal quality—I think someone may have literally written, “Hooray for our side!” If that wasn't the literal statement, the discourse within the group certainly ran along that line, such was the feeling of siege that prevailed.

(Unfortunately, I cannot find that paper now. A search on this topic uncovers many papers on the relative predictive accuracy of logistic regression on clinical data. It's been a topic of some concern, apparently.)

I had been studying statistical modeling methods advocated by Dr. Frank Harrell, Jr., whom I like to call “The most respected ignored statistician in America.” He's an elected fellow of the American Statistical Association, which is as close to a Nobel Prize as the statistics world comes. He specializes in exploratory modeling of clinical data. He mined decades' worth of statistical thinking to synthesize an exploratory modeling workflow that is purported to be thorough, efficient, and likely to yield replicable results.

The funny thing about this methodology is that at any single given point in its process, it is utterly familiar to statisticians. Logistic regression here; sure, feeling right at home. Model selection criteria there; got it. Assessment of correlations among predictor variables; of course. However, when you put all the pieces together and take it from A to Z, the whole is not familiar at all. On two occasions, with two large corporations, sat with large statistics groups and heard Dr. Harrell walk through his process. I've left the room watching audience members nodding their heads and saying the good Doctor had made a lot of convincing points. But would they incorporate these ideas in their own work? “No, my clients would never let me.” That's why I say Harrell is highly respected yet mostly ignored.

One aspect that figures prominently in Harrell's workflow is inclusion of spline expansions to enable simple non-linearity for continuous predictors. In over ten years of work within the large statistical group, I had seen lots of logistic regression models, but not one included a spline expansion.

So it was interesting indeed when I looked more closely at the paper which “scored one for our side.” It didn't give a lot of detail about how the logistic regression models were fitted, but they contained spline expansions. It seemed extremely likely that the creators of the models were aware of Harrell's process. At any rate, by using splines they were out of step with typical practice.

In fact, this paper wasn't a win for “our side,” if “our side” refers to statisticians who fit models in the typical manner. It was a win for something completely different, neither ML nor typical statistical practice. It was a win for what statistical modeling could be, but rarely is. I believe my colleagues were a little quick to accept this paper as representing their practice. It suggested a middle way between traditional statistical modeling and ML, a way which can predict as well as ML, can be as flexible in many respects, and can be more informative to boot. If the data is appropriate.

I intend to write a follow-up essay soon suggesting why I think Harrell's approach works well for most clinical data sets, so stay tuned. I'll also offer some thoughts on a way to categorize statistical and ML modeling methods according to their behavioral properties, to aid in picking the right method for the data set at hand. We really shouldn't be organized in tribes at all; there is no best modeling method, there is only a method that is best at exploiting the features of a particular data set. What are those features? I'll offer my suggestions soon.

2024 覺行寺新春萬燈供佛祈福法會

powrót

wygląda na to że chyba wróciłam z zaświatów obłędu do świata Nic jeszcze nie w pełni sprawna jeszcze nie w pełni sił wciąż przyczajona czekam na ten właściwy moment by wreszcie zacząć normalnie żyć

Hace poco acabé la novela “Elantris”, de Brandon Sanderson y ya pude escuchar el podcast https://www.ivoox.com/elantris-brandon-sanderson-audios-mp3_rf_30156272_1.html sobre la novela, que tenía reservado para escuchar cuando me acabara el libro.

El relato me gustó mucho. Es de fantasía, pero el tipo de magia que describe me hacía pensar en que podía haber un sistema tecnológico detrás, que los aones eran una interface holográfica para para manejar un sistema informatizado oculto que manejaba algún tipo de infraestructura tecnológica planetaria. Incluso me pareció que el dios Jaddeth, en su misterioso trono subterraneo esperando para salir a a superficie, podía ser una inteligencia artificial disputando el control del sistema. Los seones también tenían pinta de ser una inteligencia artificial con un cuerpo energético o con una presencia proyectada en el mundo físico.

En el podcast se compara los aones con runas, pero creo que, tal y como los describían en la novela, se parecerían más a ideogramas chinos (cuyo origen se piensa que estuvo asociado a prácticas mágicas). En cambio, la escritura de Fjordell, que usan en la religión Shu-Dereth, me parece que recordarían más a las runas.

Las tramas políticas de la novela me parecen un mecanismo de relojería muy impresionante.

Durante la lectura, el personaje de Galladón me lo imaginaba con la cara de Morgan Freeman.

La traca final con que acaba la novela me parece quizás un poco exagerada, todo muy al filo, un poco como en una película de acción de Hollywood.

Quizás a los personajes les falte un poco de textura, seguramente porque “Elantris” fue la primera novela publicada de Sanderson, pero el autor no llega a caer en una dinámica de personajes (diálogos, comportamientos...) propia del cine comercial, un pecadillo muy frecuente en autores de ciencia ficción estadounidense.

Der Singularity Viewer hat vor allem in OpenSim noch viele treue Anhänger. Was diese aber zumeist nicht wahrhaben wollen: Der Viewer ist eigentlich mausetot. Oder vielleicht eher untot. Seit 2020 sind keine neuen Binaries mehr herausgekommen. Und es werden auch keine mehr kommen. Der ganze Viewer wird nicht mehr weiterentwickelt werden.

Warum das so ist und warum das so kam, möchte ich hier erzählen.

Singularity ist eigentlich ein uralter Viewer. Vor etwa zehn Jahren wurde er von Ascent geforkt, was seinerseits ein Fork von Inertia war mit dem Ziel, den vor 14 Jahren gestarteten, aber nur kurze Zeit entwickelten Inertia in Second Life zugelassen zu bekommen.

Asbach-Code

So alt der Viewer ist, so alt ist zu erheblichen Teilen natürlich auch der Code. Und wenn man aus der Software-Entwicklung eins gelernt hat, dann ist das: Wenn Bibliotheken oder andere Abhängigkeiten, gegen die etwas entwickelt ist, aktualisiert werden, wird der Code, der gegen sie entwickelt wurde, nicht mitaktualisiert. Jedenfalls nicht, wenn es nicht unbedingt notwendig ist.

Niemand eröffnet einen Issue, weil irgendeine Abhängigkeit aktualisiert wurde, um den Code entsprechend zu modernisieren, wenn der Code auf dem Stand von vor sieben Jahren immer noch wunderbar kompiliert. Und selbst wenn, wird der Issue nicht etwa gefixt, sondern ignoriert oder mit Won't Fix geschlossen. Den Aufwand, etwas zu „reparieren“, was funktioniert, ohne daß sich sichtlich irgendetwas verbessert, macht sich kein Entwickler. Selbst wenn jemand einen Pull Request einreichen würde mit einer gründlichen Code-Modernisierung, dürften viele Kernentwickler keine Lust haben, den zu überprüfen, wenn er nichts wirklich repariert oder verbessert.

Natürlich fängt der Compiler irgendwann an, „Deprecated“-Meldungen auszugeben. Und die werden mit der Zeit immer mehr. Die werden aber geflissentlich ignoriert. Kompiliert ja und läuft hinterher auch. Also alles in Ordnung. „Deprecated“ wird von vielen Entwicklern als „stilistisch veraltet“ angesehen. Tatsächlich aber bedeutet es: „Wird demnächst nicht mehr unterstützt, also kommt in die Puschen und bringt euren Code auf Stand!“

Die ganz schlimmen Finger copy-pasten sogar Code, der deprecated ist, oder schreiben ganz neuen Code, der gleich deprecated ist, weil sie das schon immer so gemacht haben. Außerdem: Wer achtet denn beim Kompilieren darauf, was genau deprecated ist?

Und irgendwann geht’s einfach nicht mehr

Eines schönen Tages dann bekommt man auf seinen Rechner per Systemupdate neue Versionen der Bibliotheken und des anderen Zeugs, gegen die man baut. Auf einmal kompiliert der eigene Code nicht mehr. Was bis gerade eben noch deprecated war, wird jetzt endgültig gar nicht mehr unterstützt.

Dann hat man als Entwickler ein Riesenproblem. Einige Entwickler erinnern sich an die „Deprecated“-Meldungen und sagen: „Hätte ich mal …“ Andere reden sich ein, daß das doch niemand hätte ahnen können, daß das mal passieren würde – nur daß eben die „Deprecated“-Meldungen genau das eben angekündigt hatten.

Gewissenhafte Entwickler würden nun eine sofortige Modernisierung ihres ganzen Code in Angriff nehmen, und zwar mit höchster Priorität. Wenn man allerdings zigtausende oder hunderttausende Codezeilen hat, ist das ein Riesenaufwand, auch ein zeitlicher.

Um trotzdem irgendwas kompilieren zu können, versuchen einige daher, auf irgendeinem Wege alte Versionen ihrer Abhängigkeiten zu installieren. Noch viel mehr Entwickler tun das aber, um die Code-Modernisierung entweder möglichst lange aufzuschieben oder ganz vermeiden zu können. Natürlich bringt auch das nur etwas bei statischen Builds, die die Abhängigkeiten nur zum Kompilieren brauchen und hinterher ohne diese Abhängigkeiten laufen. Ansonsten wäre das Ganze nämlich allmählich auch bei den Nutzern nicht mehr lauffähig.

Irgendwann kommt man dann aber an einen Punkt, an dem die alten Versionen der Abhängigkeiten des eigenen Code auf der eigenen Maschine nicht mehr installierbar sind, weil ihre eigenen Abhängigkeiten nicht mehr da sind bzw. per Update auf eine zu neue Version gebracht werden. Selbst dann gibt’s Entwickler, die schlicht und ergreifend ihre Maschine, auf der sie entwickeln, einfach nicht mehr updaten. Nicht, daß sie sich dann endlich mal dran machen würden, ihren Code auf Stand zu bringen. Natürlich nicht, denn seit aus „deprecated“ „nicht mehr unterstützt“ wurde, hat sich die Menge an eigentlich nicht mehr unterstütztem Code nicht verringert, sondern vermehrt, weil auch der Entwickler sich nicht aufgeschlaut hat, wie man’s denn heute macht.

Paradebeispiel Python

Singularity ging letztlich vermutlich an zwei Abhängigkeiten zugrunde. Die eine ist die GNU Compiler Collection, kurz gcc, die andere Python. Der Python-Anteil im Singularity-Code macht zwar nur 0,6% aus, aber auch die können sich quer stellen.

Schon das ganze Jahrzehnt über gibt es Riesenärger mit uraltem Python-2-Code, von dem irgendetwas abhängt, den auf Python 3 zu bringen aber wie ein unmögliches Unterfangen wirkt. Eigentlich wäre das Migrieren von relativ aktuellem Python-2-Code, also auf dem Stand von Python 2.7, nach Python 3 nicht so überwältigend schwierig. Aber wenn etwas bis heute auf Python 2 basiert, dann basiert es wahrscheinlich auf einer ziemlich alten Version von Python 2, also Python 2.5 oder älter, das noch keine Python-3-Bestandteile hat. Und wieder hat sich niemand je die Mühe gemacht, den Code zu modernisieren, weil er ja auch unter Python 2.7 wunderbar lief. Allen „Deprecated“-Meldungen zum Trotze.

Calibre zum Beispiel, eine E-Book-Verwaltung, ist von 2006, also aus der Zeit von Python 2.5 und somit der Zeit vor Python 3. Python 3.0 war im Dezember 2008 erschienen; zeitgleich kam Python 2.6 raus, das schon Elemente von Python 3 enthielt. Schon im Juni 2009 kamen Python 3.1 und Python 2.7 hinterher. Seitdem wurde aber höchstwahrscheinlich am Bestandscode von Calibre genau gar nichts modernisiert, nicht nach Python 3.1, nicht mal nach Python 2.7.

Auch noch 2008 kündigte die Python Foundation an, die Unterstützung von Python 2 im Jahr 2015 einzustellen. Python-Entwickler hatten sechs Jahre Zeit, ihre Projekte auf Stand zu bringen. Sehr viele haben genau gar nichts gemacht. Anfangs hatten sie keine Eile, dann vergaßen sie es ganz einfach und entwickelten mitunter lustig auf dem vollkommen veralteten Stand von Python 2.5 oder älter weiter, und als der Termin vor der Tür stand, hätte die Zeit nicht mehr gereicht. Das betraf durchaus wichtige, kritische Sachen, auf die nicht verzichtet werden konnte. Also wurde der Support von Python 2 bis 2020 verlängert. Dann sollte aber Ende sein.

Einige drückten nun auf die Tube. Spätestens ab 2018 saßen ihnen einige Linux-Distributionen im Nacken, die sagten, wenn sie nicht auf Python 3 gehen, fliegen ihre Projekte raus.

Schließlich fingen 2020 Linux-Distributionen an, das ab Jahreswechsel 2019/2020 offiziell nicht mehr unterstützte Python 2 aus ihren Softwarequellen zu entfernen. Damit mußten natürlich auch diejenigen Pakete aus den Quellen geworfen werden, die von Python 2 abhingen. Die Entwickler wurden angeschrieben; sie sollten entweder ihre Sachen schleunigst auf Python 3 bringen, oder die werden aus den Quellen entfernt. Einige reagierten wieder erst, als große Distributionen ankündigten, ihre Kreationen aus Versionen mit Langzeitunterstützung (Debian stable, Ubuntu LTS etc.) zu entfernen.

Das betraf letztlich nur noch sehr wenige Projekte. Aber Calibre betraf es sehr wohl. Der einzige Entwickler fing daraufhin an zu jammern, daß Calibre über eine halbe Million Codezeilen auf Python-2-Stand hatte, die könne er nie und nimmer auf Python 3 bringen. Das klang schon sehr danach, als wenn das ganze Ding tatsächlich immer noch praktisch komplett auf Python-2.5-Stand war, also genau überhaupt nichts aus Python 3 eingebaut hatte. Und der Entwickler schlug vor, er könne statt dessen die Weiterentwicklung von Python 2 übernehmen, dann könnten die Distributionen das weiter in ihren Quellen behalten, und er bräuchte Calibre nicht aufwendig zu sanieren. Das schien ihm wirklich der geringere Aufwand zu sein. Allerdings lehnten die Distributionen das ab.

Letztlich konnte Calibre nur weiter bestehen, indem es bis September 2020 doch noch auf Python 3 aktualisiert wurde. Daran wirkten wohl einige Freiwillige mit. Außerdem wurden in diesem Zuge den Entwicklern von Plugins, die immer noch auf Python 2 aufbauten, Pistolen auf die Brüste gesetzt: Wenn die nicht auch auf Python 3 aktualisieren, fliegen ihre Plugins raus. Einige Plugins, die schon längst nicht mehr weiterentwickelt wurden, sind wohl tatsächlich geflogen.

Auch wenn bei Singularity nun der gesamte Python-Anteil auf dem Stand von Python 2.5 sein, also keinerlei Spuren von Python 3 enthalten sollte, ist Python längst nicht das größte Hindernis. Das ist vielmehr gcc, denn Singularity ist größtenteils in C++ geschrieben.

Extremfall gcc

Auch C++ ist nicht TeX, wo 46 Jahre alter Dokumentencode heute noch kompiliert und das daraus resultierende Dokument haargenau so aussieht, wie wenn es vor 46 Jahren kompiliert worden wäre. Es ist auch nicht LaTeX, wo das mit einer Zeitdifferenz von 40 Jahren noch funktioniert. C++ entwickelt sich nicht nur weiter, es baut auch mal Sachen um und schmeißt alte Sachen raus.

Das heißt: Knapp vier Jahrzehnte alter C++-Code kompiliert heutzutage nicht mehr unbedingt. Und schon zehn Jahre alter Code kompiliert heute nicht mehr, wenn er nur ausgefuchst genug ist.

Genau deshalb gibt es ja „Deprecated“-Meldungen. Kaum ein Entwickler folgt irgendeiner Mailinglist, die Änderungen in Compilern ankündigt. Aber was beim Kompilieren passiert, das sehen die meisten. Also wird genau da darauf hingewiesen, daß Teile des Code so veraltet sind, daß das schon kritisch wird und schleunigst behoben werden sollte. Blöderweise ignorieren Entwickler meistens kleinere Mengen an „Deprecated“-Meldungen als harmlos und zu vernachlässigen. Und wenn die Meldungen sich häufen, wird es ihnen zuviel Arbeit, endlich was dagegen zu machen.

Durch sein Inertia-Erbe ist der Code von Singularity zu erheblichen Teilen auf dem Stand von Mitte der 2000er, also bestenfalls dem von C​+​+​03. Auch dieser Code wurde nie auf einen neueren Stand gebracht.

Der C++-Compiler in der Collection heißt g++. Mit g++ 4 war der Code noch kompilierbar, wobei wahrscheinlich neuere Versionen jede Menge „Deprecated“-Meldungen ausgaben. Aber schon der g++ 5 konnte den Code nicht mehr in etwas Ausführbares umsetzen.

gcc 5 kam schon im April 2015 raus, aber Singularity wurde auf einem Ubuntu-LTS-Rechner kompiliert. Ubuntu 14.04 LTS „Trusty Tahr“ kam noch mit gcc 4.8.2. Mit dem Upgrade auf Ubuntu 16.04 LTS „Xenial Xerus“ wurde das aber ersetzt durch gcc 5.3.1. Und schon war Singularity nicht mehr kompilierbar. Das war schon vor gut neun Jahren.

Statt jetzt aber den veralteten Code auf Vordermann zu bringen, ging man einen einfacheren Weg – und bastelte irgendwie wieder gcc 4 auf die Maschine drauf. Aber nicht, um sich für die Code-Modernisierung die nötige Zeit zu verschaffen, sondern wohl eher in der Hoffnung, damit den Code überhaupt nie modernisieren zu müssen. Dahinter stand auch die Hoffnung, daß es bis in alle Ewigkeit möglich sein würde, gcc 4 unter Ubuntu zu installieren.

Nichts geht mehr

Ziemlich genau vier Jahre später wurde Singularity das letzte Mal erfolgreich kompiliert, und zwar immer noch unter demselben alten Ubuntu „Xenial“. Das war im Frühjahr 2020. Inzwischen waren Ubuntu 18.04 LTS „Bionic Beaver“ und Ubuntu 20.04 LTS „Focal Fossa“ erschienen. Es dürfte klar sein, warum der Rechner, auf dem Singularity kompiliert wurde, nicht auf eine der beiden Versionen upgegradet wurde. Vielleicht hatte man festgestellt, daß die alten gcc-4-Pakete schon unter „Bionic“ nicht mehr installierbar waren.

Normalerweise hätte spätestens 2018 die Aussicht, daß gcc 4 irgendwann nicht mal mehr nachinstalliert werden kann, auch nicht aus losen Paketdateien, der Tritt in den Hintern sein müssen, der dazu hätte führen müssen, den Code von Singularity endlich auf einen Stand zu bringen, der nicht schon seit mindestens drei Jahren völlig veraltet war. Passiert ist aber wieder genau gar nichts. Man hatte ja Ubuntu „Xenial“, das lief, da war gcc 4 installiert, Singularity kompilierte, alles war gut.

Wie gesagt, bis Frühjahr 2020. Da wurde noch einmal eine neue Release-Versionen kompiliert, 1.8.9, die erstmals Bakes-on-Mesh neue Beta-Versionen kompiliert. Etwas später folgten ein paar neue Beta-Versionen. Wahrscheinlich ist dann irgendwas mit dem Rechner passiert, auf dem kompiliert wurde. Zu diesem Zeitpunkt dürfte das der einzige noch verfügbare Rechner mit Ubuntu „Xenial“ gewesen sein, auf dem also gcc 4 installierbar war.

Aktuell war damals ja Ubuntu „Focal“, das gcc 9.3.0 mitbrachte und als erstes Ubuntu LTS kein Python 2 mehr. Der Support für Ubuntu „Xenial“ lief noch bis April 2021, aber ich glaube nicht, daß Ubuntu für diese alte Version noch Images zum Installieren zur Verfügung stellte. Hätte also der Rechner, auf dem Singularity kompiliert wurde, neu aufgesetzt oder durch eine andere Maschine ersetzt werden müssen, hätte kein Ubuntu mehr installiert werden können, mit dem Singularity hätte kompiliert werden können.

Ein mögliches Szenario ist also, daß irgendetwas mit dem Entwicklungsrechner bzw. dem Rechner, auf dem kompiliert wurde, passierte. Irgendetwas, das die Weiterverwendung der alten Ubuntu-Installation unmöglich machte, z. B., daß die Festplatte ihren Geist aufgab.

Wie auch immer: Der Rechner stand so, wie er war, nicht mehr zur Verfügung. Es brauchte Ersatz. Dieser Ersatz hätte aber Ubuntu „Xenial“ von 2016 als System gebraucht. Schon 2020 hätte man das Problem gehabt, daß man „Xenial“ nicht mehr hätte installieren können, sofern man kein entsprechend altes Installationsmedium mehr hatte und auch kein ISO-Image, um eins zu bauen. Und wer bewahrt so etwas auf? Schlimmstenfalls hatte man auch die gcc-4-Pakete verloren oder verschlampt und konnte die auch nirgendwo mehr herunterladen, weil Ubuntu „Trusty“, von dem sie kamen, seit 2019 nicht mehr unterstützt wurde.

So hatte man keinen Rechner mehr, auf dem Singularity hätte kompiliert werden können. Man hatte auch keine Möglichkeit mehr, einen Rechner aufzusetzen, mit dem man Singularity hätte kompilieren können. Schon die eh notwendige Weiterentwicklung, um mit Neuerungen in und neuen Anforderungen von Second Life Schritt zu halten, schaffte man 2020 gerade noch so mit Ach und Krach. Selbst die Website war damals schon in Teilen veraltet; das Versprechen, die Singularity-Erklärseite auf den damals aktuellen Stand von Version 1.8.9 zu bringen, wurde nie eingelöst; sie ist bis heute auf dem Stand von Singularity 1.7.0. Da war also auch nicht daran zu denken, den Code von Singularity so aufzufrischen, daß er wieder kompilierbar wäre.

Heutiger Stand

Inzwischen ist 2024. Die letzte Ubuntu-Version, auf der Singularity hätte kompiliert werden können, kam vor zehn Jahren heraus und wird seit fünf Jahren nicht mehr unterstützt. Auch andere Linux-Distributionen unterstützen gcc 4 schon lange nicht mehr. Und selbst die aktuellsten Singularity-Binaries starten, obwohl sie weitgehend statische Builds ohne großartige Abhängigkeiten sind, unter mehr und mehr Linux-Distributionen inzwischen überhaupt nicht mehr.

Vielleicht hätte man noch eine Chance, Singularity unter Arch Linux oder einem seiner Derivate zu kompilieren, ohne den Code anfassen zu müssen. Im Arch User Repository gibt es sehr viele Sachen auch noch in wirklich uralten Versionen, so auch gcc 4.9 und Python 2.7.18. Aber das wäre wirklich für sehr weit Fortgeschrittene – und der Sprung von Ubuntu nach Arch wäre heftig – und würde auf eigene Gefahr laufen, weil beides von den jeweiligen Anbietern schon ewig nicht mehr unterstützt wird.

An eine Weiterentwicklung von Singularity wäre aber selbst dann nicht zu denken. Inzwischen ist sehr viel passiert. Singularity unterstützt noch Windlight, das inzwischen nicht nur in Second Life, sondern auch fast im gesamten Hypergrid durch EEP ersetzt wurde; das wiederum unterstützt Singularity noch nicht. Von Physically-Based Rendering will ich gar nicht erst anfangen.

Es wäre allerdings reiner Wahnsinn, das in den Singularity einbauen zu wollen, wie er jetzt ist. Schon vor acht Jahren ging der Code von Singularity nur noch mit Tricks und unter Verwendung eines veralteten Compilers zu kompilieren. Wenn überhaupt, muß der ganze Code als allererstes um mehr als ein Jahrzehnt modernisiert werden. Ansonsten wäre der Einbau neuer Features wie ein nagelneuer Anbau an einem Gebäude, das seit acht Jahren wegen Baufälligkeit gesperrt ist.

#OpenSim #SecondLife #FürFortgeschrittene #Software

Es un engorro que cada administración tenga una sede electrónica con sus propios requerimientos, en unas puedes entrar con dificultad y en otras no porque tienen sus propios requerimientos técnicos. En unas comunidades autónomas los operadores jurídicos pueden relacionarse con los juzgados por la plataforma Lexnet y en otras tienen su propia plataforma, que exige una inscripción independiente del profesional. Dificultades que generan un reflejo centralista. Pero también es razonable que cada administración quiera controlar su presencia en red y sus datos. Todo un dilema.

¿No sería lógico aplicar un sistema de federación a las plataformas públicas, al estilo #Fediverso? Un software de la UE, más o menos abierto, federable e interconectable, que pudieran utilizar para crear su sede electrónica la Comisión Europea, los estados centrales, los estados federados, las regiones, las comunidades autónomas, los landers, los cabildos, las diputaciones, los ayuntamientos, los poderes judiciales, los sistemas de Seguridad Social, etc. Así se podría hacer compatible una mayor accesibilidad de las plataformas públicas y sedes electrónicas, a la vez que las administraciones tendrían el control de su ciberespacio.