one of the biggest issue i see is the devicetree nonsense. It makes every single laptop and bios version very unique and requires a lot of housekeeping. There are also big chunks of work (as i understand it) to be done around hibernate and decent suspend support.
My experience (wanted to use x13s as daily sriver) is that there was good progress for about a year, until jhovold was leading the charge, but something expired and qualcom as far as i can tell forgot that some progress should happen on x1 and x8c as well as x2.
I would love to go framework and the specs here look pretty awesome but 5g modem is a must have for me and they dont really have an option for that. I am guessing due to the antennas.
i am not sure about the OP or the motivation and I am not a Streak runner/mover myself, but I do see the appeal of it, that will keep someone moving and exercise more or less consistently. Overall maybe the bad it is doing on bad days, is compensated with the good it is doing on good/average days. It is a long term motivator. For me now that i was cycling about 2-300km per week last year, going to nearly 0 this year so far because life and stuff, makes it pretty hard mentally to get back into the saddle, because of reduced performance, fatigue and just the general feeling of what it felt like to be in a faster group ride that I would get dropped from and i need to work my way back up there in performance and endurance. Having a streak going might have helped with this.
whatever happened to printing the passwords qr code.
The tech might itself is interesting. My first thought was archival though. Storing whatever we have on paper archives.
I am not sure it is the same. First of all the limitation in usage for a phone/laptop reduces the utility, but for a transportation device it is way worse. On phone/laptop you can use the main functions while charging, but tethered. On a car the main function is the only thing you cant use.
There does not have to have a single battery standard, could be s/m/l, like coincell, aaa, aa etc.
> Would you trust the people and systems that the battery hasn't been tampered with and is in good working order?
Do you trust random utilities/charger manufacture?
> new battery, but empty, to a random one at a swapping station.
Would you care if it is within regulated thresholds and you can get another one any time you want?
is that infra more expensive than preparing for the holiday events when half the nation decides to relocate to somewhere else and they need on the go charging? Not just the charging stations, but grid usage etc.
It would be nice if instead of the fast charging problem the focus would be shifted to standardized battery packs, that can be field replaced. I don't really want to own 50-100kwh battery. I just want to use the charge in it and happy to pay for that.
> Sure that's great, not particularly helpful to the masses who misunderstand the tool. I worked as a network engineer for a decade receiving bunk MTR reports where people freak out because they're seeing "packet loss" which was inexistent on the data forwarding plane (you know the one that actually matters).
Understanding can be improved. Bunk MTRs are easy to spot. You tell them this is not an issue because .... . Than they will learn and usually that customer will stop sending you bunk MTRs.
I'm pretty sure that the people that are opening tickets with providers/network teams because they have nothing better to do is nearing 0. The fact that they ran an MTR shows that they were doing some troubleshooting and at the end of the day a problem needs to be solved. It may not be on your end but that needs to be investigated but the same would apply for a crappy iperf throughput test. IMHO Any clue/information into where that problem is, is helpful. You may need to filter relevant from irrelevant.
But if I get to pick one out of 2 problems, one has a crappy iperf results, the other has an MTR that has a loss that carries over, I would probably pick the second because that at least gives me indication on whereabouts should I start looking.
> Time shouldn't be wasted measuring the control path and then investigating to confirm it is the control path and not data path. You cannot make these mistakes using traceroute and ping separately because traceroute doesn't have a notion of a "per-hop" loss indicator.
traceroute does have per-hop indicator, it's the * in the output, it's just so often off that nobody pays much attention. You can't really catch issues that are related to route-flaps or reroutes with traceroute. with MTRs it becomes pretty clear if a reroute happens in the middle of your test. I guess you can keep running traceroute but I will leave it to you to sift through the output of that nightmare and than it effectively became MTR, with worse output.
There are also many options available in MTR that is not there in traceroute (to trigger these packets by tcp or udp packets), fix local or remote port etc. Even if you just run it with 3 packets per hop, you will have way more options. You don't have to use it as a continuous monitor to indicate packetloss but can give you the traceroute level information in a much cleaner format and you have more options to choose from.
> ping doesn't involve intermediate hops (unless an intermediate hop generates an ICMP diagnostic for an echo request).
ICMP echo requests and replys can be subject to different QoS treatment as TCP/UDP traffic, so that also doesn't necessarily gives you the right idea when testing for end to end connectivity issue.
Iperf imho is the best bet, and if you want to be really accurate you pick the src/dst port for client/server just to be sure you get into the same Class as your problematic traffic.
As a sidenote MTR packets are also ride the data-plane until they reach the TTL=1.
Right, so control-plane packet rates are rate limited (to some definition of sane), but they are applied to all applications, traceroutes, pings alike.
An argument could be made for a device configured as such to show loss on ping but not on mtr if you configure the rate limits so that the icmp reply rate is lower than ttl expired rates. Which tool would be wrong than? Would you blame ping for producing misleading results?
The running counters and the ability to pick out the obvious rate limiting when the loss doesn't cascade into the hops to me is akin to traceroutes * * * output. It doesn't always mean that the packets are blackholed, connectivity is broken, it just means the tool is producing an artifact due to network configuration or network characteristics. Further investigation is needed to figure out what's going on.
MTR imho is giving you much more insight into the network than traceroute or ping separately. It doesn't resolve the usual firewall/rate limiting artifacts, but gives you way more information about paths if you know how to interpret them.
It's one of the best tools to troubleshoot packetloss on the internet and generally routed networks. It gives you way more information than ping or traceroute could potentially give.
If you run it in TCP or UDP mode you can even nail down the physical interface that's erroring in a LAG/LACP bundle due to being able to manipulate the 5 tuples very well.
I'm also curious about the flags you used for ping and mtr that showed you this discrapancy.
Todays matle.io had a few positions that were inconsequential to the mate itself and could be a lot of pieces other than the solution that could be reached through normal game so it's pretty much a guessing game.
My experience (wanted to use x13s as daily sriver) is that there was good progress for about a year, until jhovold was leading the charge, but something expired and qualcom as far as i can tell forgot that some progress should happen on x1 and x8c as well as x2.