Via Ihaveavoice
Uncategorized
6
Posts
1
Posters
0
Views
-
Via Ihaveavoice
L'ha lasciata m*rire congelata in alta montagna.
Lui, Thomas Plamberger di 36 anni, è un esperto scalatore, mentre lei, Kerstin Gurtner di 33 anni, era a livello principiante.
Essendo lui l'esperto, era il solo responsabile di tutte le decisioni prese e ci sono stati tutta una serie di "errori" che hanno portato alla m*rte per assideramento, a meno 20 gradi percepiti, della donna:
1. Ha deciso di scalare la montagna austriaca più alta, il Grossglockner di 3.798 metri, in inverno, con delle condizioni estremamente dure, certamente non adatte ad un principiante.
2. Ha fissato l'orario di partenza con circa 2 ore di ritardo rispetto a quanto ragionevole per un tour di quel tipo in condizioni invernali (buio, meteo, lunghezza e difficoltà della via).
➡️
-
Via Ihaveavoice
L'ha lasciata m*rire congelata in alta montagna.
Lui, Thomas Plamberger di 36 anni, è un esperto scalatore, mentre lei, Kerstin Gurtner di 33 anni, era a livello principiante.
Essendo lui l'esperto, era il solo responsabile di tutte le decisioni prese e ci sono stati tutta una serie di "errori" che hanno portato alla m*rte per assideramento, a meno 20 gradi percepiti, della donna:
1. Ha deciso di scalare la montagna austriaca più alta, il Grossglockner di 3.798 metri, in inverno, con delle condizioni estremamente dure, certamente non adatte ad un principiante.
2. Ha fissato l'orario di partenza con circa 2 ore di ritardo rispetto a quanto ragionevole per un tour di quel tipo in condizioni invernali (buio, meteo, lunghezza e difficoltà della via).
➡️
➡️
3. Ha lasciato che la compagna indossasse scarponi morbidi da snowboard, non idonei ad una salita di quel tipo, mentre lui, chissà come mai, aveva quelli adeguati.
4. Arrivati al rifugio intermedio, alla luce del meteo e delle condizioni, non sono tornati indietro, ma hanno proseguito verso la vetta.
5. Non ha effettuato per tempo una chiamata di emergenza prima dell'imbrunire, nonostante il ritardo accumulato e le condizioni sempre più critiche.
6. Sebbene fossero bloccati da circa le 20:50, l'uomo non solo non ha lanciato un allarme, ma quando verso le 22:50 era passato l'elicottero dei soccorsi, non ha dato alcun segnale di emergenza, lasciando che l'elicottero se ne andasse.
➡️
-
➡️
3. Ha lasciato che la compagna indossasse scarponi morbidi da snowboard, non idonei ad una salita di quel tipo, mentre lui, chissà come mai, aveva quelli adeguati.
4. Arrivati al rifugio intermedio, alla luce del meteo e delle condizioni, non sono tornati indietro, ma hanno proseguito verso la vetta.
5. Non ha effettuato per tempo una chiamata di emergenza prima dell'imbrunire, nonostante il ritardo accumulato e le condizioni sempre più critiche.
6. Sebbene fossero bloccati da circa le 20:50, l'uomo non solo non ha lanciato un allarme, ma quando verso le 22:50 era passato l'elicottero dei soccorsi, non ha dato alcun segnale di emergenza, lasciando che l'elicottero se ne andasse.
➡️
➡️
7. I soccorritori hanno tentato più volte di contattarlo telefonicamente dopo il sorvolo, ma lui non ha risposto. La prima comunicazione è avvenuta solo alle 00:35, in cui la conversazione è stata “poco chiara” e poi l’alpinista ha riattaccato, mettendo poi il telefono in modalità silenziosa e non rispondendo più.
8. Hanno trascorso un’ora e mezza rannicchiati sotto la cima, tempo in cui l'uomo non ha fatto nulla per chiamare i soccorsi o almeno mettere al riparo la donna, dandole il sacco da bivacco o le coperte di emergenza che aveva con sé. Non le ha neppure tolto il pesante zaino, per facilitarle i movimenti.
➡️
-
➡️
7. I soccorritori hanno tentato più volte di contattarlo telefonicamente dopo il sorvolo, ma lui non ha risposto. La prima comunicazione è avvenuta solo alle 00:35, in cui la conversazione è stata “poco chiara” e poi l’alpinista ha riattaccato, mettendo poi il telefono in modalità silenziosa e non rispondendo più.
8. Hanno trascorso un’ora e mezza rannicchiati sotto la cima, tempo in cui l'uomo non ha fatto nulla per chiamare i soccorsi o almeno mettere al riparo la donna, dandole il sacco da bivacco o le coperte di emergenza che aveva con sé. Non le ha neppure tolto il pesante zaino, per facilitarle i movimenti.
➡️
9. L'uomo è sceso da solo, lasciando la compagna intorno alle 2:00 del mattino, ma ha chiamato i soccorsi solo alle 3:30, proprio quando c'era una tempesta in corso che rendeva impossibile qualsiasi volo.
Ora l'uomo è indagato per om*cidio colposo, proprio a causa di questi "errori", poiché essendo lui l'esperto, tutta la responsabilità delle decisioni ricadeva completamente su di lui.
Ma vi dirò di più, anche una persona inesperta può capire che alle 10 di sera a 3000 metri di altezza, con meno 20 gradi percepiti, e un elicottero di soccorso che viene a prendervi, è il caso di salire...
No, questi non erano semplici "errori", questo è palesemente un femminicidio studiato alla perfezione per restare impuniti.
➡️
-
9. L'uomo è sceso da solo, lasciando la compagna intorno alle 2:00 del mattino, ma ha chiamato i soccorsi solo alle 3:30, proprio quando c'era una tempesta in corso che rendeva impossibile qualsiasi volo.
Ora l'uomo è indagato per om*cidio colposo, proprio a causa di questi "errori", poiché essendo lui l'esperto, tutta la responsabilità delle decisioni ricadeva completamente su di lui.
Ma vi dirò di più, anche una persona inesperta può capire che alle 10 di sera a 3000 metri di altezza, con meno 20 gradi percepiti, e un elicottero di soccorso che viene a prendervi, è il caso di salire...
No, questi non erano semplici "errori", questo è palesemente un femminicidio studiato alla perfezione per restare impuniti.
➡️
Non solo, sono più che sicura che sia stato lui a spingerla in una scalata di questo tipo, magari deridendola o sminuendola se lei provava ad obiettare... Lei si è fidata di lui, e lui l'ha ucc*sa, facendola m*rire in un modo atroce.
Mi auguro che la giustizia austriaca si renda conto che non sono stati semplici "errori", e che gli dia la pena che merita.
A tutte le donne, invece, dico: non fidatevi mai di nessun uomo, soprattutto se vi mette in condizioni potenzialmente pericolose, pensate sempre voi stesse a tutelare la vostra vita.
A t r o c e
-
Non solo, sono più che sicura che sia stato lui a spingerla in una scalata di questo tipo, magari deridendola o sminuendola se lei provava ad obiettare... Lei si è fidata di lui, e lui l'ha ucc*sa, facendola m*rire in un modo atroce.
Mi auguro che la giustizia austriaca si renda conto che non sono stati semplici "errori", e che gli dia la pena che merita.
A tutte le donne, invece, dico: non fidatevi mai di nessun uomo, soprattutto se vi mette in condizioni potenzialmente pericolose, pensate sempre voi stesse a tutelare la vostra vita.
A t r o c e
Anche qua:
se quel coglione del fidanzato vostro non bada alla vostra sicurezza e al vostro benessere psicofisico come se fossero i propri, scappate a gambe levate.
-
undefined oblomov@sociale.network shared this topic
Feed RSS
Gli ultimi otto messaggi ricevuti dalla Federazione
-
Molto interessante,
ho collegato un cavo di rete tra data port e il PC con Linux Mint
Nel gestore applicazioni c'è APCUPSD
Che ho installato
Adesso che faccio?
-
When I started building Fedify, an ActivityPub server framework, I ran into a problem that surprised me: I couldn't figure out how to add logging.
Not because logging is hard—there are dozens of mature logging libraries for JavaScript. The problem was that they're primarily designed for applications, not for libraries that want to stay unobtrusive.
I wrote about this a few months ago, and the response was modest—some interest, some skepticism, and quite a bit of debate about whether the post was AI-generated. I'll be honest: English isn't my first language, so I use LLMs to polish my writing. But the ideas and technical content are mine.
Several readers wanted to see a real-world example rather than theory.
The problem: existing loggers assume you're building an appFedify helps developers build federated social applications using the ActivityPub protocol. If you've ever worked with federation, you know debugging can be painful. When an activity fails to deliver, you need to answer questions like:
Did the HTTP request actually go out? Was the signature generated correctly? Did the remote server reject it? Why? Was there a problem parsing the response?These questions span multiple subsystems: HTTP handling, cryptographic signatures, JSON-LD processing, queue management, and more. Without good logging, debugging turns into guesswork.
But here's the dilemma I faced as a library author: if I add verbose logging to help with debugging, I risk annoying users who don't want their console cluttered with Fedify's internal chatter. If I stay silent, users struggle to diagnose issues.
I looked at the existing options. With winston or Pino, I would have to either:
Configure a logger inside Fedify (imposing my choices on users), or Ask users to pass a logger instance to Fedify (adding boilerplate)There's also debug, which is designed for this use case. But it doesn't give you structured, level-based logs that ops teams expect—and it relies on environment variables, which some runtimes like Deno restrict by default for security reasons.
None of these felt right. So I built LogTape—a logging library designed from the ground up for library authors. And Fedify became its first real user.
The solution: hierarchical categories with zero default outputThe key insight was simple: a library should be able to log without producing any output unless the application developer explicitly enables it.
Fedify uses LogTape's hierarchical category system to give users fine-grained control over what they see. Here's how the categories are organized:
Category What it logs ["fedify"] Everything from the library ["fedify", "federation", "inbox"] Incoming activities ["fedify", "federation", "outbox"] Outgoing activities ["fedify", "federation", "http"] HTTP requests and responses ["fedify", "sig", "http"] HTTP Signature operations ["fedify", "sig", "ld"] Linked Data Signature operations ["fedify", "sig", "key"] Key generation and retrieval ["fedify", "runtime", "docloader"] JSON-LD document loading ["fedify", "webfinger", "lookup"] WebFinger resource lookups…and about a dozen more. Each category corresponds to a distinct subsystem.
This means a user can configure logging like this:
await configure({ sinks: { console: getConsoleSink() }, loggers: [ // Show errors from all of Fedify { category: "fedify", sinks: ["console"], lowestLevel: "error" }, // But show debug info for inbox processing specifically { category: ["fedify", "federation", "inbox"], sinks: ["console"], lowestLevel: "debug" }, ], });When something goes wrong with incoming activities, they get detailed logs for that subsystem while keeping everything else quiet. No code changes required—just configuration.
Request tracing with implicit contextsThe hierarchical categories solved the filtering problem, but there was another challenge: correlating logs across async boundaries.
In a federated system, a single user action might trigger a cascade of operations: fetch a remote actor, verify their signature, process the activity, fan out to followers, and so on. When something fails, you need to correlate all the log entries for that specific request.
Fedify uses LogTape's implicit context feature to automatically tag every log entry with a requestId:
await configure({ sinks: { file: getFileSink("fedify.jsonl", { formatter: jsonLinesFormatter }) }, loggers: [ { category: "fedify", sinks: ["file"], lowestLevel: "info" }, ], contextLocalStorage: new AsyncLocalStorage(), // Enables implicit contexts });With this configuration, every log entry automatically includes a requestId property. When you need to debug a specific request, you can filter your logs:
jq 'select(.properties.requestId == "abc-123")' fedify.jsonlAnd you'll see every log entry from that request—across all subsystems, all in order. No manual correlation needed.
The requestId is derived from standard headers when available (X-Request-Id, Traceparent, etc.), so it integrates naturally with existing observability infrastructure.
What users actually seeSo what does all this configuration actually mean for someone using Fedify?
If a Fedify user doesn't configure LogTape at all, they see nothing. No warnings about missing configuration, no default output, and minimal performance overhead—the logging calls are essentially no-ops.
For basic visibility, they can enable error-level logging for all of Fedify with three lines of configuration. When debugging a specific issue, they can enable debug-level logging for just the relevant subsystem.
And if they're running in production with serious observability requirements, they can pipe structured JSON logs to their monitoring system with request correlation built in.
The same library code supports all these scenarios—whether the user is running on Node.js, Deno, Bun, or edge functions, without extra polyfills or shims. The user decides what they need.
Lessons learnedBuilding Fedify with LogTape taught me a few things:
Design your categories early. The hierarchical structure should reflect how users will actually want to filter logs. I organized Fedify's categories around subsystems that users might need to debug independently.
Use structured logging. Properties like requestId, activityId, and actorId are far more useful than string interpolation when you need to analyze logs programmatically.
Implicit contexts turned out to be more useful than I expected. Being able to correlate logs across async boundaries without passing context manually made debugging distributed operations much easier. When a user reports that activity delivery failed, I can give them a single jq command to extract everything relevant.
Trust your users. Some library authors worry about exposing too much internal detail through logs. I've found the opposite—users appreciate being able to see what's happening when they need to. The key is making it opt-in.
Try it yourselfIf you're building a library and struggling with the logging question—how much to log, how to give users control, how to avoid being noisy—I'd encourage you to look at how Fedify does it.
The Fedify logging documentation explains everything in detail. And if you want to understand the philosophy behind LogTape's design, my earlier post covers that.
LogTape isn't trying to replace winston or Pino for application developers who are happy with those tools. It fills a different gap: logging for libraries that want to stay out of the way until users need them. If that's what you're looking for, it might be a better fit than the usual app-centric loggers.
-
This post did not contain any content.
-
-
Voglio un robot.
Non mi interessa che balli la lambada.
Non mi interessa che diriga un'orchestra filarmonica.
Non mi interessa che possa fare attività mineraria nella fascia degli asteroidi andandoci con la Lambretta.
Mi basta che accenda la stufa (come sapeva fare qualsiasi contadinә analfabeta dell'epoca di Carlo Magno) e che la mantenga accesa aggiungendo legna al momento opportuno.
Chiedo troppo?
-
Since yesterday my server has again been getting absolutely obliterated by AI scrapers. This time, though, load is below 1, but I'm getting up to 10 requests a second and all of my Apache workers are in state "R". "apachectl restart" fixes it... for a while.
What levers do I have to pull on this? E.g. maybe it would be sensible to drop connections if they stay in "R" for more than a couple seconds?
This 12 year old post suggests some sysctl.conf changes, but I have...
-
Che se fai 2 conti sul fatto che una certs percentuale della popolazione non ha la patente, circa il 30-35%, ti rendi conto che ci sono più auto che persone che possono guidarle, allora ha ancora meno senso.
Auto ferme il 95% del tempo su suolo pubblico.
-
@oblomov
in realtà io un po' rosico perché l'albero in casa non lo posso fare...cioè potrei ma poi sai quanto ci si diverte Luna?
Da che son qui l'ho fatto una volta sola, quando il vecchio gatto Mocio, il primo gatto, non aveva ancora un anno.
L'albero (di plastica) è stato prontamente abbattuto il giorno stesso, poi messo in soffitta ed è ancora là.
@Ann_in_a @LaVi
