Toke Høiland-Jørgensen
Posts
145Following
376Followers
296
@c_chep @jon
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...) 🤷♂️
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
@c_chep
@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 :/
@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
@pettter
@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...
@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
@seatsixtyone
Haha, yup, but for some reason the Swedes keep refusing to fix their spelling :P
Haha, yup, but for some reason the Swedes keep refusing to fix their spelling :P
0
0
0
@jon
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.
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
@seatsixtyone
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" :)
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
@Foxboron
@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...
@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
@Foxboron
@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 :)
@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
@Foxboron
@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...
@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
Toke Høiland-Jørgensen
toke
Looks like I managed to reconfigure my router to be multi-homed, while logged in through SSH over the existing WAN connection, without screwing something up and locking myself out. Phew! 😅
1
0
1
Toke Høiland-Jørgensen
toke
This is pretty spot on. At this stage, the problem with #climate change isn't that we don't know what the solutions are, it's that we are not applying them fast enough. But we could be, and doomism isn't helpful.
"The facts tell us that the general public is not the problem; the fossil fuel industry and other vested interests are; that we have the solutions, that we know what to do, and that the obstacles are political; that when we fight we sometimes win; and that we are deciding the future now."
https://www.theguardian.com/commentisfree/2023/jul/26/we-cant-afford-to-be-climate-doomers
"The facts tell us that the general public is not the problem; the fossil fuel industry and other vested interests are; that we have the solutions, that we know what to do, and that the obstacles are political; that when we fight we sometimes win; and that we are deciding the future now."
https://www.theguardian.com/commentisfree/2023/jul/26/we-cant-afford-to-be-climate-doomers
0
3
1
Toke Høiland-Jørgensen
repeated
repeated
Now at @aj@gts.sadauskas.id.au
ajsadauskas@aus.socialHi, we're a tech startup run by libertarian Silicon Valley tech bros.
We're not a newspaper, we're a content portal.
We're not a taxi service, we're a ride sharing app.
We're not a pay TV service, we're a streaming platform.
We're not a department store, we're an e-commerce marketplace.
We're not a financial services firm, we're crypto.
We're not a space agency, we're a group of visionaries who are totally going to Mars next year.
We're not a copywriting and graphic design agency, we're a large language model generative AI platform.
Oh sure, we compete against those established businesses. We basically provide the same goods and services.
But we're totally not those things. At least from a legal and PR standpoint.
And that means all the laws and regulations that have built up over the decades around those industries don't apply to us.
Things like consumer protections, privacy protections, minimum wage laws, local content requirements, safety regulations, environmental protections... They totally don't apply to us.
Even copyright laws — as long as we're talking about everyone else's intellectual property.
We're going to move fast and break things — and then externalise the costs of the things we break.
We've also raised several billion in VC funding, and we'll sell our products below cost — even give them away for free for a time — until we run our competition out of the market.
Once we have a near monopoly, we'll enshitify the hell out of our service and jack up prices.
You won't believe what you agreed to in our terms of service agreement.
We may also be secretly hoarding your personal information. We know who you are, we know where you work, we know where you live. But you can trust us.
By the time the regulators and the general public catch on to what we're doing, we will have well and truly moved on to our next grift.
By the way, don't forget to check out our latest innovation. It's the Uber of toothpaste!
0
4
0
@jpelckolsen
Quite happy with Fitotrack. Open source, not snoopy, does basic mapping and statistics on your phone, and can even talk to bluetooth heart rate monitors. No automatic upload anywhere, though, but as far as I'm concerned that's a feature 😊
https://codeberg.org/jannis/FitoTrack
Quite happy with Fitotrack. Open source, not snoopy, does basic mapping and statistics on your phone, and can even talk to bluetooth heart rate monitors. No automatic upload anywhere, though, but as far as I'm concerned that's a feature 😊
https://codeberg.org/jannis/FitoTrack
1
0
2
Toke Høiland-Jørgensen
toke
FFS, spent hours beating my head against a wall trying to figure out why this service was starting up and then randomly dying after a few seconds...
... Well, turns out it was because of a misconfigured firewall on the NFS server it was talking to, so some connections would just hang, causing IO stalls. Fix the firewall rule, and presto, everything is running perfectly!
At least it wasn't DNS! 😅
... Well, turns out it was because of a misconfigured firewall on the NFS server it was talking to, so some connections would just hang, causing IO stalls. Fix the firewall rule, and presto, everything is running perfectly!
At least it wasn't DNS! 😅
0
0
1
@gd2
I was going to do TPM sealing on a recent install until I discovered that the server in question doesn't have a TPM chip.
That would definitely solve the "unattended" part (I think?), but would reduce the protection afforded by the encryption to making it easier to decommission the disks. Which I guess is the main benefit for an always-on server anyway?
I was going to do TPM sealing on a recent install until I discovered that the server in question doesn't have a TPM chip.
That would definitely solve the "unattended" part (I think?), but would reduce the protection afforded by the encryption to making it easier to decommission the disks. Which I guess is the main benefit for an always-on server anyway?
0
0
0