We want to drive through, from Granite falls to Darrington. I know part (more than half, I guess) is not paved ... but it is open to motor vehicles, right? We'll be in our Jeep.
I'm not sure I've seen a hobby OS project that implements any tests. Most people smoke test, so they know there's a problem if they start up the OS and can't run an app inside it.
But what about the more complicated code paths that can go wrong? If a multi-threaded race happens in memory management or I/O, the system can crash. Or worse: silently corrupt data.
What about performance? Does anyone test for throughput or latency, and then identify regressions or hot spots?
This is just crazy. Did anyone see an announcement for it? I can't enter more than cents (hundreths of a dollar) in any of the purchase UIs, though.
Here's an LTT video comparing memory usage on Windows and Linux.
Linus' credibility is taking lots of hits (did he buy actually that private jet?) and this video sure won't help. I had hoped for something interesting and technical, and it's really just two guys screwing around with computers and looking at graphs that they don't fully understand. Worth a watch for a laugh.
In your OS, what memory allocation strategy did you devise? Are you just making a simple on-demand allocator, or do you reserve and commit pages? Do you have paging implemented? What algorithms did you use for page eviction?
Hello!
How do I setup disjunctions in rules? I'd like to have an action trigger when a post contains certain text and the author is (not verified or less than some Karma or the account is less than some age).
I don't see a way to write the disjunctive part of the rule. Must I make three rules?
title+body (includes): "my string"
author:
account_age: "< some days"
and then also
title+body (includes): "my string"
author:
post_karma: "< my threshold"
with more
title+body (includes): "my string"
author:
has_verified_email: false
?
Is there at least a way to make the message text and reason common among the rules? Otherwise, I have to copy pasta them and repeat myself, which doesn't seem like it will be fun to maintain.
OK, I'm ready. But which should I get?
To me, the keyboard feel is really important, so maybe I'm best with a vintage model.
The display on the Swiss Micros looks like, but I heard the keyboard stinks. And it's out of stock, and more expensive than even the new HP collector's edition.
The collector's edition would be new and working and robust, but I don't know what's changed from the vintage model.
I've been thinking about JankOS, as I'm sure most of you have. One of the reasons I stopped developing it was that I was a bit overwhelmed by the work I thought I needed to do in order to get to the fun parts.
One of the concerning issues was debugging. How could I effectively debug my kernel, and all of the subsystems -- the file system, network, I/O, scheduling? What architecture did I need to build in to make it happen?
There are lots of logging solutions, but those don't always work for high-frequency code paths and for rare events. And certainly not for time sensitive code. At a certain point, there's really no substitute for bing able to attach a debugger.
Which hobbyist OS implementations feature kernel debugging support? How is it implemented? How does it work?
Went through Washington, Oregon, California, Arizona, New Mexico, Texas, more Texas, Louisiana, Mississippi, Alabama, Florida, Georgia, South Carolina, North Carolina, Virginia, West Virginia, Pennsylvania, New Jersey, New York, Connecticut, Massachusetts, Nuh Hampsha, Maine, New Brunswick, Province Quebec, Ontario, Michigan, Wisconsin, Minnesota, North Dakota, Montana, Idaho, and back to Washington.
Took back roads almost the whole way. I figure about 85% of the driving was off the interstate. Though, as I got more tired and homesick, I did take the faster roads. (And in some places, it's just better to be on the interstate.)
No problems at all, though the dealer in Florida overfilled my oil (and I've posted here whinging about that already). No tickets, pretty good weather the whole way. Dodged a couple wildfires.
Spent about seven weeks, including hanging out in Boston for about a week. Got a little homesick, but it's such a wonderful country and a thrill to see it all. Had a great time wherever I went.
Thirty years ago (in 1995) I did a similar trip on my motorcycle. Too old to do it on a bike now, so the GT had to suffice.
For covered call positions, Fidelity Trader+ is showing the underlying bid, mid, and ask in the options view instead of the option's bid, mid, and ask.
This is surprising (therefore confusing) and not particularly useful. Is there a way to change the behaviour, so that the option's pricing is shown instead of the underling pricing?
Maybe this is what's meant by "net", but "Mid" isn't "Net Mid". It's just "Mid". It doesn't seem useful at all. What am I missing?
I have been trying to use Fidelity Trader+ lately. One of the more annoying bugs is that it doesn't remember window layout between restarts.
Maybe it's more accurate to say that it doesn't remember window content. I have a workspace with many charts. After restarting, one of the charts will be forgotten, and one will be duplicated.
This doesn't happen often, and I can't seem to predict when it will.
First, here's my gear:
Head unit: Garmin 830
Rear Hub: Cycleops G2 Hub
Pedals: Garmin X220
Trainer: Yahoo Kickr Snap
I like riding Zwift (despite the bugs). I've been pushing harder on my failing health lately, so I'm spending more time looking at my numbers than ever. 56 now, I've been riding road bikes "seriously" since I was about 14.
A few days ago, Zwift on my laptop wouldn't detect my trainer. I'm not positive what fixed it, but I disconnected the trainer from power for a few minutes, and connected with it from the Wahoo app on my phone for the first time in ... well, a long time. That fixed it up; I could connect from my laptop again.
After that, the distance recorded by my Garmin head unit hasn't been quite right. Before the reconnect incident, the Garmin was recording approximately the same distance that the in-game route had in Zwift. After it, it's about 15% low ... sometimes worse.
I know that the zwift distance is an imaginary number from an imaginary world, computed based on my input weight and power and the frame and wheel choice in Zwift, and drafting and so on. But the numbers were quite close, and were close for a very long time. What happened in that connection reset to knock them out? And if the trainer is adapting resistance for the course, and being moved by my power, why shouldn't they be pretty close?
Here's the actual data:
| Date | Course Name | Garmin | Zwift | Ratio |
|---|---|---|---|---|
| 2026-06-11 | Pacer Group Ride | 14.06 | 14 | 0.43% |
| 2026-06-12 | ||||
| 2026-06-13 | ||||
| 2026-06-14 | Pacer Group Ride | 12.41 | 13.1 | -5.56% |
| 2026-06-15 | Pacer Group Ride | 13.59 | 14.2 | -4.49% |
| 2026-06-16 | Outside | 28.44 | ||
| 2026-06-17 | Volcano Circuit | 7.06 | 7.7 | -9.07% |
| 2026-06-18 | Beach Island Loop | 12.79 | 13.2 | -3.21% |
| 2026-06-19 | Pacer Group Ride | 12.00 | 11.3 | 5.83% |
| 2026-06-20 | ||||
| 2026-06-21 | Pacer Group Ride | 11.74 | 12.5 | -6.47% |
| 2026-06-22 | London Flat | 12.02 | 12.3 | -2.33% |
| 2026-06-23 | Greatest London Flat | 17.99 | 17.3 | 3.84% |
| 2026-06-24 | Temple Trek | 11.27 | 11.6 | -2.93% |
| 2026-06-25 | Pacer Group Ride | 11.30 | 11.7 | -3.54% |
| 2026-06-26 | Twilight Harbor | 6.86 | 7.1 | -3.50% |
| 2026-06-27 | ||||
| 2026-06-28 | Castle to Castle | 21.07 | 22.6 | -7.26% |
| 2026-06-29 | Beach Island Loop | 10.65 | 10.4 | 2.35% |
| 2026-06-30 | London Flat | 11.86 | 12.2 | -2.87% |
| 2026-07-01 | Volcano Circuit | 5.80 | 6.5 | -12.07% |
| 2026-07-02 | Tempus Fugit | 18.92 | 20.2 | -6.77% |
| 2026-07-03 | Going Costal | 15.38 | 16.5 | -7.28% |
| 2026-07-04 | Hilly Route | 8.34 | 9.3 | -11.51% |
| 2026-07-05 | ||||
| 2026-07-06 | Going Costal | 16.32 | 16.6 | -1.72% |
| 2026-07-07 | Loop de Loop | 14.57 | 14.5 | 0.48% |
| 2026-07-08 | Bon Voyage | 31.98 | 31.5 | 1.50% |
| 2026-07-09 | Loop de Loop | 12.23 | 12.7 | -3.84% |
| 2026-07-10 | ||||
| 2026-07-11 | Croissant | 12.69 | 12.4 | 2.29% |
| 2026-07-12 | Volcano Flat | 13.81 | 13.2 | 4.42% |
| 2026-07-13 | ||||
| 2026-07-14 | Flat Route | 11.69 | 11.2 | 4.19% |
| 2026-07-15 | Southern Coast Cruise | 25.07 | 24.1 | 3.87% |
| 2026-07-16 | Casse-Pattes | 24.71 | 24.1 | 2.47% |
| 2026-07-17 | ||||
| 2026-07-18 | Flat Route | 8.93 | 11.2 | -25.42% |
| 2026-07-19 | Flat Route | 9.82 | 11.1 | -13.03% |
| 2026-07-20 | Going Costal | 13.07 | 16.5 | -26.24% |
| 2026-07-21 | Three Musketeers | 31.54 | 36.1 | -14.46% |
Couldn't log in for a few minutes. Then, when I finally did, I have to change my account username. Looks like I'm locked out until I do. No warning.
EDIT: And now that I've chosen a new username (which I hate, BTW) I can't log in successfully.
EDIT2: Cleared cookies for all the Fidelity related sites. Logged in and was prompted for 2FA. Did it correctly, bounced out again. After three more tries, I was able to log in.
This was a terrible user experience and completely avoidable. I love the change, but enforcing it with zero notice and in such a sudden, buggy way was absolutely the wrong path.
These results were produced under best-case conditions (stable FPS at cap, CPU-bound) and are of course specific to my hardware and chosen software stack.
The absolute numbers will look different on other setups, but the gains and losses from each test case should roughly transfer. On a lower refresh rate display, the gains from VRR and the low-latency pacer would likely be even larger.
It added 3.13 ms of latency, more than all other effects combined. Wayland is close, but X11 still wins
Though only by 0.14 to 0.22 ms. Given there are efforts to optimize KWin, this gap will likely close sooner rather than later. And who knows, other Wayland compositors might already be better.
VRR was faster in every pairing (0.26 to 0.45 ms) and also flattened the latency distribution.
0.10 to 0.29 ms in capped scenarios is a nice boost, but the real strength of the fork shows in the uncapped test case, where it gained 0.84 ms over default dxvk.
Additionally, in scenarios where XWayland can’t be avoided, it recovered a full 2.1 ms.
Not factoring in XWayland, applying every optimization (X11, VRR, low-latency) compared to a default setup (which, on a modern Linux system, I assume is plain Wayland) moved the median down by 0.72 ms. That does not sound like a lot, but the raw latency does not tell the whole story as VRR additionally reduces latency jitter, and dxvk-low-latency’s pacer is great at smoothing out real-world scenarios where frame time dips and GPU-bound situations occur.
When I have Fidelity Trader+ running, it uses a high amount of bandwidth. More than 400 kilobts per second, maybe -- up to 1 megabit per second!
I don't have much displayed: maybe 20 graphs, my orders window, my history window. That's about 400 kilobits. Opening a positions window will push me over 1 megabit per second.
If I have 20 graphs, I need about 5 data points per graph every five minutes (since I have the tick set to 5 minutes). Why does it cost 400 kiobits per second to watch 100 data points per minute?
Worse yet, when the market closes, the data rate stays the same. And unbelievably, if my session times out, the data rate remains high until I actually close the app.
400 kilobits per second doesn't sound like much, but it's crazy high: higher than reliably available in many hotels. And if I walk away from my terminal (like on a Friday afternoon, and don't return until Monday morning) the off hours usage is more than 100 gigabits -- about 12 gigabytes of transfer. And that's at the lower 400 kilobit rate!
Why is the bandwith usage of the application so high/ Wouldn't also help Fidelity themselves to optimize the data transfer?
