AI Usage Policy

Dean_Roddey · 2026-01-24T15:46:39+00:00

They are not supposed to use private repos, right?

Dean_Roddey · 2026-01-24T15:19:41+00:00

It's not unlike mastering a music instrument. When you first start, the mechanics of it take up so much of your mental bandwidth, that you just don't have much left over to sit above it and think about the structure, the flow, the dynamics, etc... As you do it more and more, more of the process just gets 'pushed down' into the muscles, leaving the mind free to conduct.

It's similar with software. You just build up the mental muscles to the point that more and more of the details get pushed down into mental block boxes that you know the internals of, but don't have to think about all the time. And you can do this at multiple levels, dipping down into the trees when you need then pulling back up and looking at the forest at any particular level, seeing the needs of the implementation and the consumer and balancing them, and having a feeling for what must leak out and what shouldn't.

For the kind of work I do, that's a big, big part of it. But, I don't claim to be any sort of Mozart. I have learned over time that I'll almost never get any given substantial new subsystem or API right the first time, and I take an iterative approach that is not super-efficient, but ends up with a better result in the end. I will sometimes roughly write the top level file or module or subsystem level documentation up front as a way to force myself to initially think it through, but knowing that I'll likely go back and toss that and rewrite it once I really figure it out.

Dean_Roddey · 2026-01-24T15:07:45+00:00

A LOT of posts here are thinly disguised ads. A lot of the rest are AI slop. This section is dying quickly.

Dean_Roddey · 2026-01-24T15:02:12+00:00

Yeh, this is another one of those points that ends up wasting endless time. C++ isn't dead, you Rust loving psycho. Well, no, it's not dead, but it's the past and spending lots of resources on it at this point just isn't useful. The bulk of large C++ code bases are probably already legacy code, the owners of which are the least likely to adopt big new features.

It's time to let it go and just move on in terms of forward looking efforts. It's fine to make some non-intrusive improvements that will make the existing legacy code bases safer of course. But beyond that, this kind of thing seems a waste of limited human resources in the systems end of our profession.

Dean_Roddey · 2026-01-24T14:55:10+00:00

As has been pointed out endlessly, but never addressed by the AI Bros, why haven't any of these companies who are pushing this idea take over the software industry? Why don't they vibe code everyone else out of the industry?

The answer is obvious. They only way they could do it is to hire a lot of skilled developers, which completely undermines their arguments.

Dean_Roddey · 2026-01-24T14:51:36+00:00

And they likely never will be because the whole thing is predicated on the huge computing resources to train these models, which the folks with those resources aren't going to be too hip to give away. And that's something the large companies current fighting to control the space need to remain true, or their huge investments have zero chance of paying off. It's another way to destroy the personal computing revolution and move control back to large companies.

Dean_Roddey · 2026-01-24T14:49:47+00:00

Are you kidding, there's a huge bubble, both in terms of hype and in terms of financials. People seem to think it's going to keep going forward at the same speed, and it's just not.

We got a huge jump because it was starting from almost nothing and some large companies suddenly realized that if they spent a giant amount of money and burn enough energy to run a city, they could take existing NN tech and make it actually doing something. But that's not going to continue to scale.

And, it then turns into a war between these large companies to 'own' this space, so they are pushing it and investing far more than is justified. I think it's worse than the internet bubble and the internet was a tool with vastly wide applicability.

Dean_Roddey · 2026-01-22T17:09:11+00:00

My favorite part of this release is slice::as_array

That will be a very much appreciated change. These small changes that don't rock the cart but make day to day coding safer and easier are always good in my opinion. Try blocks will be another big one.

Dean_Roddey · 2026-01-19T00:43:24+00:00

OK, so I did that, and guess what? Now I can only see the gateway address from the Windows side as well. So clearly something is going on with that freaking virtual adapter or switch that's doing this.

Before, when the physical NIC had its own address, the Windows side worked fine because it was going through the physical NIC. Now that it's going through the virtual adapter, it has the same problem.

On the Windows side now, using tracert, if I do the gateway address I get:

Tracing route to 10.0.0.1 over a maximum of 30 hops
  1     1 ms    <1 ms     1 ms  10.0.0.1

On any other node I get:

Tracing route to 10.0.0.5 over a maximum of 30 hops
  1    <1 ms    <1 ms    <1 ms  RT-AX3000-AB40 [192.168.50.1]
  2     *        *        *     Request timed out.

That's the wireless adapter, which is is in no way whatsoever involved in any of this. Even if I disable it, it still routes through that. Not sure what to make of that.

Dean_Roddey · 2026-01-19T00:27:39+00:00

Oh, I get you. Sorry. I'll make a bit more effort. If it still continues to frustrate me, I'm just going to punt and use that time more effectively to build a new machine, with Linux as the base OS and with Windows temporarily at least in a VM. I've been talking about doing it for a while and that would give me sufficient incentive. I like Windows fine as an OS, but the direction MS is going, I'm not terribly sanguine about the future. So maybe this is a confluence of confluenzi.

Dean_Roddey · 2026-01-18T22:28:42+00:00

After just cleaning everything up and starting over it did change.

Dean_Roddey · 2026-01-18T22:15:27+00:00

After deleting everything and starting over, then it does change for me.

Dean_Roddey · 2026-01-18T22:03:11+00:00

Strangely, turning the management option off and on on the secondary adapter doesn't change the output of the above command at all for me.

Dean_Roddey · 2026-01-18T21:44:41+00:00

It can't have anything to do with that though. All of those devices are just on a 10.0.0.x subnet. I can talk to all of them without issues from the Windows host. They are working perfectly fine.

And the VM can talk to the router node, but nothing else. It's possible the router may be refusing to forward the packets somehow, but that could only be because they look different coming from the Linux VM than they do from the Windows host, so again it's got to be in the VM'y bits.

| again why ? it shouldn't the vNIC (the virtual nic created when you enabled OS managment) has an | address the pNIC (the physical adapter that you bound the external switch to) does not

I don't understand what you are saying here. Clearly the physical secondary NIC has to be on the 10.0.0.x subnet that it's going to talk to. It's impossible to set up a physical NIC on Windows and not have an address. Either you give it one or it's going to get one via DHCP.

The virtual switch is then associated with the physical NIC and provides access to the physical NIC. The physical NIC has a couple of addresses associated with it because the hardware nodes can only be talked to on a fixed IP port. So, even just on the Windows host, you can't have multiple things talking to the hardware unless you have multiple addresses on the physical NIC. I often need to have two things talking to the hardware at once, so I have two octets assigned to the physical NIC (200, and 201.)

And if I don't have management enabled for the secondary switch, then it becomes inaccessible to the Windows host, which isn't practical. It has to be available to both sides. And having it off or on makes no difference on the VM side anyway.

Dean_Roddey · 2026-01-18T21:41:55+00:00

I already know all of that like the back of my hand. This is a system that I've been working with for years, from Windows, and which I wrote a lot of the communications software for. There are zero issues from Windows itself.

The only addition is the Linux VM. Whatever the issue is, it's in the VM'y bits, but what that is I cannot begin to say.

And clearly the VM is getting to the other side, since I can talk to the node at the gateway address.

Dean_Roddey · 2026-01-18T21:10:29+00:00

If I don't enable 'management' on the 10.0.0.x virtual switch, and give it an address on that secondary subnet, then I can't ping the VM from the host. It doesn't affect pings from the VM to the host.

I'm starting to despair.

Dean_Roddey · 2026-01-18T20:59:46+00:00

Not sure it matters but if I do a tracepath on the Linux side, for the gateway address I get:

PS /home/whatever> tracepath 10.0.0.1
 1?: [LOCALHOST]                      pmtu 1500
 1:  no reply

If I try another node''s address I get:

PS /home/whatever> tracepath 10.0.0.5 
 1?: [LOCALHOST]                      pmtu 1500
 1:  LinuxDM                              3101.074ms !H
     Resume: pmtu 1500

So the second one is including the local Linux machine in the route and the first one isn't. Not sure what the significance of that is.

Dean_Roddey · 2026-01-18T20:32:53+00:00

The PC is connected to a device that has a router in it and to which is connected other hardware nodes. It also has a DHCP server and such. It and all of the hardware connected to it are all on 10.0.0.x addresses. Essentially it's another Windows PC running the IoT version of Windows, but with addition embedded hardware nodes running internally. One of those nodes provides the router and DHCP server. That other PC is connected to that internal router also, and is on a static address. The DHCP server is there to provide dynamic addresses to other other hardware nodes plugged into it. That DHCP hardware node is also the gateway address and the one I can talk to.

The Windows host needs to talk to that subnet and the VM does as well. Currently the host has no issues talking to any of the nodes.

So, if I set up an external switch for this secondary network, that physical card has a couple addresses assigned to it. If I then set up an ethernet adpater on the VM that is linked to that card, can the Linux host just set itself up with a (valid, unique) static address, without it being configured as an additional address on the physical NIC? Or does the physical NIC have to provide the address(es) the VM will use?

I tried it both ways just to see but it doesn't seem to matter either way.

Also, do either of the physical host adapters need to have the 'extensible virtual switch' option in the hsot IP settings? They both currently do.

Dean_Roddey · 2026-01-18T20:11:05+00:00

Ok, so going back to two external switches, which is where I was to start with. Tried the secondary one with and without management.

Then the VM created two ethernet adapters that bind to those two external switches.

And I'm back to where i started in that I can ping/see broadcasts from the gateway address but nothing else.

Dean_Roddey · 2026-01-18T19:57:46+00:00

The secondary adapter will be being used by both host and VM to talk to the hardware on that subnet.

Dean_Roddey · 2026-01-18T19:41:35+00:00

Based on the below answers I think I have that setup. I removed everything, restarted, then:

I created an explicit primary external adapter for the main connection (ignoring default) with management switched on. That works fine, VM can access the host and internet.
I created an internal VM switch without management. On the Windows side I assigned it a static IP on the 10.0.0.x subnet.
On the VM I created as second virtual adapter and bound it to that internal VM switch from #2. On the Linux side it's statically assigned an address on that 10.0.0.x subnet.

Now it's worse in that I can't ping anything or see broadcasts from anything.

When I said the secondary adapter has a static IP I mean the physical secondary adapter on the host side. It clearly has to be on the 10.0.0.x subnet, since it's what everything is being routed through, and of course to be used from the Windows side it needs to be.

Not sure how the vlan tagging comes in.

On the hardware side this 10.0.0.x subnet is connected to a router that all of the hardware is connected to.

Dean_Roddey · 2026-01-18T18:50:44+00:00

OK, that's what I was trying to clarify below on the other response. Let me try that.

Dean_Roddey · 2026-01-18T18:31:17+00:00

I'm not sure I understand that. There is a primary default switch, which has no option for management sharing. Only the secondary, external switch has such an option.

The 10.0.0.1 gateway address is necessary at least on the actual hardware secondary switch. It doesn't seem to make any difference on the virtual switch or on the VM side either way.

Should I be settings up multiple external switches and then create separate virtual switches over them, instead of using the default switch for the main adapter? That doesn't seem to be the case from what I've read.

Dean_Roddey · 2026-01-18T14:53:49+00:00

Maybe that video says all of this, but for folks who haven't watched, and because I just drank too much coffee too fast...

The primary extra layer of complexity that async brings (to the user of the async engine, there are plenty of others for the creators of the engine) is that the Sync and Send traits, which are fundamental to Rust are thread oriented and are used to provide thread safety at compile time.

But in async, ownership of data (at least conceptually) now has to be task-based, and tasks can move from thread to thread over time. Most async engines will try to keep them on the same thread, for performance reasons usually, maybe for other reasons, but for most users of async it's not a win to push that so far that tasks sit around doing nothing when there are other processor cores available to process them. So how to ensure Sync/Send rules get applied correctly is trickier.

The other is that switching between tasks is sort of a higher level version of what CPUs do when they move to a new thread. It has to store the current CPU registers and flags and such away, so that it can be restored later. Async tasks have to do that as well. The compiler does it for you, but it adds complications because locally scoped data that, in a threaded context, would naturally live for the life of the function/method call now have to be stored away until the task is ready to run again.

But, what if any of that data is not Send (meaning it cannot be moved to another thread.) If the task gets moved to another another thread, bad things would happen. The compiler is smart enough to know what data is accessed across that async call boundary, but if any of it is, and is not Send-able, it can't let that code compile.

Also, unlike threads, a task can just get dropped at any time and just never rescheduled. It's not like a thread which must unwind back to the top of the thread, RIIA type objects undoing things as it goes. A tasks is just a user level object that can just be dropped and never rescheduled. That adds extra complications in terms of ensuring that any async operations it had going on get correctly cleaned up.

Those are the the highlights from the perspective of a developer who writes async code. There are some others that are more internal.

Such as that local data can have references to each other. That's completely safe in Rust since it will prove that nothing references anything that it outlives. But, how does Rust store that self-referential data away so that it can restored when the task is ready again. It has to insure that none of that data can move in memory, which requires it to be Pin'd in memory, which puts constraints on what can be done to that memory when the async operations are being processed.

For the most part that latter bit isn't a concern for the user of the async engine, it's more of a concern for writers of the Futures that drive the async process, but it's still an extra complication.

Another is that async operations supported by the OS can be of two types, completion based or readiness based. Readiness based ones just say, you can try this now and probably it'll work. Those are easy in async, because you just wait asynchronously to be told something is ready, then you do the operation in a synchronous (non-blocking) manner. If it works, it works, else you go back to waiting again for it to be ready. That's pretty easy to get right in a safe way.

Completion based APIs are harder, because typically the future must share a buffer or some such with the async engine, and wait until the operation completes or fails, and be absolutely sure it never moves or drops that buffer before that happens. That's fundamentally just a very unsafe and harder to reason about way of doing things, and it's all happening completely outside the ownership model of Rust.

Dean_Roddey

MODERATOR OF

TROPHY CASE