Posts
125Following
343Followers
271
repeated
Ada Palmer
adapalmer@wandering.shop
When facing the "All we need is STEM!" approach to education, my usual response is:
Developing the vaccine was the STEM problem; distribution & getting shots in arms was the Social Science problem; getting people to trust it & combatting misinformation was the Humanities problem -- which did we fail?
0
13
1
repeated
warthog9
warthog9@social.afront.orgWell, vger (as of right now) no longer directly attempts to deliver to gmail/google/googlemail just to get the ridiculous backlog out of the primary mail paths. Vger (1 machine) is kicking all of that queue over to 8 other machines and letting them go try to get that delivered and queue up somewhere where it's not going to cause everyone else pain.
This should, at least for now, settle out several things, but if you are seeing mail wonkiness give postmaster@ a ping and I'll take a look.
Also if you are on Gmail and doing kernel dev, might be worth looking at other email providers.
2
8
0
repeated
Rob Ricci
ricci@discuss.systemsSince I've seen a lot of chatter about people switching to #Firefox as Google ramps up the enshitification of #Chrome, let me tell you about a killer feature for people who (a) need multiple accounts on the same websites (eg. devs) or specifically (b) have to use multiple Google accounts.
Firefox has an official addon called Multi Account Containers that lets you trivially set up color coded tabs that have separate sets of cookies. Log into your dev account in one, and your test account in another. Log into your personal #gmail in one and have another tab next to it with your work Gmail. I'm actually not signed in to any Google accounts in most my tabs, I just have containers for the specific tasks I do on Google products.
It'll take you 30 seconds to set up.
Add-on: https://addons.mozilla.org/en-US/firefox/addon/multi-account-containers/
Mozilla's explanation: https://support.mozilla.org/en-US/kb/containers
3
21
0
repeated
Sarah Brown
goatsarah@thegoatery.dyndns.orgTechbros: self driving cars are inevitable!
Also techbros: prove you are human by performing a task that computers can’t do, like identifying traffic lights.
2
19
0
repeated
Lesley Carhart 
hacks4pancakes@infosec.exchange
We need to have a talk, and I’m having a really hard time having it with my awesome hacker friends, because everyone is super duper emotionally invested and is deeply hurt by it.
I hope you all aren’t - because it involves all of us and it’s important. It’s not about any of y’all individually or your hard community work.
The talk is about how to make all of our cybersecurity conferences and events and meetups more accessible and conformable for young hackers because I’mreallysosorry, we’ve somehow become Old, and the stuff that we are ingrained with as “hacker culture” like movies, music, and memes all were created before they were born - and they may or may not have any emotional attachment or enjoyment of them at all.
That’s the conversation we need to have and that we are all responsible for and I swear it’s not aimed at any conference or person because we are all in this filter bubble of watching the Matrix and listening to Prodigy and remembering the hamster dance and all of that stuff while awesome was like a quarter century ago.
Part of building a community is thinking about including everyone and their culture under a mantle of good ethics and goals. So we really, really need to start having a chat about when we lean on the 90s hacker aesthetic and memories to the exclusion of people under 30. I had a wake up call hearing some students complaining about it.
57
9
0
repeated
Well, the WiFi access point inside the train is basically a femtocell, just using a different radio interface. The AP-to-client hop is not usually the bottleneck, though, the train-to-infrastructure hop is. Think of it like a 5G router like you have at home, sitting on top of the train. That's the device that needs to be fixed. Or, well, preferably the whole bloody 5G network...
I actually know of a Swedish company (Icomera) selling connectivity services to trains etc. I believe DB is one of their customers. They have some sort of bandwidth and handover solution which is pretty advanced and they would be perfectly positioned to fix this problem. Unfortunately I have never managed to convince them of the need (it's "not a problem for them" according to the guy I talked to way back when...) 🤷♂️
1
0
0
@jon
Yes and yes (it seems) :/
A lot of the problem stems from the fact that benchmarks optimise for single stream TCP throughput. And a good way to get a really good score on such a benchmark is to add heaps of buffers everywhere. Which sucks for literally everything else. Yet this is what is still routinely done, even with 5g equipment.
One of the 5G buzzwords is (ostensibly) latency, so at least that has made the industry start paying attention to it as a concept. But I've still seen benchmarks of 5G equipment with seconds of buffering built-in, so it seems more like it'll be yet another benchmark to game: ultra low latency as long as the link is idle, but still bufferbloat out the wazzoo as soon as you run any real traffic on it.
Even my (allegedly) high-class business grade gigabit fibre connection has 30-40 ms of bufferbloat one hop away from me if I don't apply my own traffic shaper. It's infuriating :/
1
0
1
@jon
Yeah, something that runs a ping in the background and collects the samples with time and location stamps would be pretty instructive, I think. I often do this manually when I'm on a train, by just running a ping in a terminal window, and it is quite common to see it spike above 30 *seconds* of RTT.
If you want to be really fancy you could also have the utility monitor the link for idleness and run a speedtest-like test occasionally to stress test the link over time. But if you're using the connection for other things, that's usually enough to suss out bad latency behaviour, at least with the quality of the connections I've experienced on most trains...
0
0
0
Haha, yup, but for some reason the Swedes keep refusing to fix their spelling :P
0
0
0
Side note: the reason the internet connection experience on most trains is so horrible is not actually a lack of bandwidth. Everything you do with the WiFi on a train would work fine with a couple of Mbps of *reliable* low latency connectivity.
The problem plaguing train connection is terrible reliability and enormous amounts of bufferbloat leading to latency spikes in the tens of seconds. This is what leads to the stuttering and unusable internet experience only too common on trains, not a lack of bandwidth.
Unfortunately, no app I'm aware of measures this correctly. Some speedtest apps have started including latency under load measurements (including speedtest.net) which is a start, but for a train in motion I'd really like a long-running latency measurement that clearly showed the worst case spikes. Plotting it on a map would be cool as well.
5
6
13
Nice! Small nit on the price listing for the train from Copenhagen: the plural of "krone" is "kroner", so it should be "310 kroner". But also in the context of a train from Denmark to Sweden, it's easy to mistake Danish and Swedish kroner/kronor, so may be clearer to specify it unambiguously as "310 DKK" :)
1
0
1
@dvzrv @Mehrad @fabiscafe
Hmm, so IIUC, the function of a transparency log in a package signing context is basically that you can say "if I ever encounter a package with a valid signature but no entry in the transparency log, something fishy is going on". Right?
In which case that seems orthogonal to which keys do the signing? If you're building a log of the signatures of dev keys it would supposedly happen at the point where the package is uploaded to the mirrors, and so the same kind of verification of the log could be done?
It would be problem for any developer who wanted to have a separate private repo signed with the same key, I guess, but that seems like a "don't do that, then" kind of issue?
Anyway, I guess this is a bit of a hypothetical discussion anyway as it's not terribly likely that anyone is going to build such a log. And if you do end up with some kind of transparency log you'd probably want it to tie all the way back to the sources, not just attesting binary build blobs? Which also implies centralised build servers...
0
0
0
@dvzrv @Mehrad @fabiscafe
Well, from a user PoV, an undiscovered compromise of a developer signing key would potentially result in a malicious package ending up on my system whether the dev key is directly trusted by my local system, or whether it's transitively trusted by the automatic resigning system. And transparency logging could be implemented without resigning the packages (I think?).
Which means that the main benefit would be that a compromised dev key could be revoked quicker in the centralised setup. Offset by the fact that an already-distributed malicious package can't be revoked individually without rotating the full distro signing key.
I don't actually consider myself immensely qualified to say anything about the magnitude of the relative risks involved here; I think I would probably agree with you that the resigning model is preferable, on balance. My point was more that I can see why someone would make the opposite call when factoring in the cost and risk of running the centralised infrastructure, especially 10 years ago :)
1
0
0
@fabiscafe @Mehrad @dvzrv
I always assumed it was to avoid having to maintain a centralised signing infrastructure? With all the care that needs to be taken to avoid compromise of a high-value target that a distribution signing key would be? I don't think this is a totally crazy tradeoff to make, and TBH I consider the occasional manual update of the keyring package a minor annoyance at most...
2
0
0
1
0
4