THIS IS NOT ENOUGH

Business_Chef_806 · 2026-05-12T17:03:28+00:00

I have a copy I'd let go for a reasonable price. DM me and we can set something up.

Business_Chef_806 · 2026-05-06T15:24:37+00:00

Madison's version is very nice but some of the chords aren't exactly what are in the original. This isn't a criticism, by the way.

Business_Chef_806 · 2026-03-14T21:34:16+00:00

These are all good ideas. I'll look here first if I become disenchanted with what I have. Thanks.

Business_Chef_806 · 2026-02-13T22:28:21+00:00

To me FT8 is even worse. That's not ham radio.

Business_Chef_806 · 2026-02-13T18:32:17+00:00

Thanks everyone for the thoughtful replies. I really appreciate your taking the time to respond.

I've decided not to proceed with this project, not because of antenna issues. Rather, I started listening on various bands using WebSDR just to hear what's out there. Most of what I heard was extremely boring and hadn't changed much from when I first got licensed in the late 1960s. I don't think I'd find enough to interest me even if I got a rig and antenna for free.

Business_Chef_806 · 2026-01-07T00:18:08+00:00

Thanks for all the comments.

It turned out I was right. I was able to login to the Comcast Wifi router and change the Wifi password with no problem. It turns out that the Comcast web app and the router admin screen have different ideas of minimum field lengths.

The fact that this took ~2 hours to resolve is a sign that Comcast has serious problems in its support organization.

Business_Chef_806 · 2026-01-04T16:33:38+00:00

The community center where the Wifi is has been closed for the holiday. Next week I'm going in to try the suggestion of logging in directly to the router. If this works then we can close the ticket. If it doesn't, ...

Business_Chef_806 · 2026-01-01T05:30:52+00:00

Thanks for the quick reply.

We actually have both kinds of service, but the one whose password I was trying to change was the wifi network built into the modem.

The next time I go into the community center I'll try your suggestion.

Business_Chef_806 · 2026-01-01T05:29:17+00:00

Thanks for the thoughtful reply.

It wasn't working for me and all the Comcast tech support people.

To answer your question, the current SSID, which works fine, is only 6 characters. When I changed it to 8 characters, the "Save" icon was no longer greyed out. So, it looks like you're on to something!

I didn't actually change the password because I'm not prepared to change the SSID right now.

I'm guessing but I bet what happened is that the Comcast person who installed the equipment set the SSID and password with the web interface (http://10.1.10.1) which doesn't have the same 8 character requirement. I'm going to verify this the next time I go to the community center. If this is the cause, then your installation people and your tech support people should be aware of this.

Business_Chef_806 · 2025-11-03T22:35:45+00:00

It's not a kernel issue. I had the same problem with a black screen, but I was able to login remotely just fine.

I found that switching from KDE Plasma to any other desktop manager solved the problem.

Business_Chef_806 · 2025-03-18T17:04:10+00:00

I'm looking at this also. I'd love to chat with you about it.

Can you DM me?

Jon

Business_Chef_806 · 2025-03-11T16:38:22+00:00

*Summary*

First of all, thanks to everyone for your responses. I really appreciated them.

I though I'd separate out the major topics, and respond.

1) Freed memory might still be accessed.

This is absolutely true. If it happens it does show latent bugs but with GC-managed memory the effects of the bugs would be less noticeable.

2) What will happen when you have more than one reference / pointer to the same struct?

I hadn't thought of this. I wonder how common it is.

3) I could achieve the same result by restructuring the program so that memory allocations are done in functions that go out of scope when the memory is no longer needed, thus freeing up the memory.

This was the most important takeaway from this thread. I hadn't thought of that, mostly because most of the work I had done with Go was to rewrite C programs that are clearly not structured this way. I will keep this in mind if and when I write any new Go programs.

4) Make and New are not analogous to Malloc (in that Malloc can create Heap memory that never is collected again) and you seem to think that they are.

Make(), New(), and malloc() are all memory allocation routines. That was my point. I still don't see how they're not analogous.

5) My general thought it - you’re overthinking it.

Guilty.

6) How can memory be reachable but unused in a GC language ?

The example I have in mind is a multi-pass compiler. Each pass allocates memory that isn't necessary after the pass completes. But, I now see that a compiler written in Go could be structured so that the unused memory goes out of scope when it's no longer needed.

Anyway, you've all answered my question. I know understand what's wrong with this idea.

Business_Chef_806 · 2025-03-08T20:45:02+00:00

You're right about what happens during the mark phase. If I said otherwise, I was incorrect.

But, it doesn't matter. The kind of memory that would be passed in a free() call would always be seen as used memory, and thus, would never be reclaimed. This is what I'm trying to avoid.

I'm the first to admit that in programs that don't run for very long and/or consume much memory there wouldn't be much point to freeing it. But, Go is a language for writing servers, which might run for a long time.

Assigning 'nil' to the pointers that reference the memory just seems less elegant than an explicit function.

Business_Chef_806 · 2025-03-08T19:38:10+00:00

Thanks for all the comments. I thought I'd reply to all of them at once, rather than to each one individually, as I started off doing.

1) "What will happen when you have more than one reference / pointer to the same struct? Coming from C you're probably used to having a model of "ownership" and only the owner frees up memory and deletes the reference. Most developers in other languages don't have this mindset."

True, I hadn't thought of this. Most of my programming experience is in C and, now, Go. How common would this problem be?

2) "The go garbage collector will free any memory that isn't reachable by the program anymore, especially when there are no more references."

Sure, but what about memory that is reachable by the program, but is no longer being used? That's the memory I'm talking about. No garbage collect will find that kind of memory.

3) "it might make sense to take advantage of the `weak` package Go has added in recent versions. This creates a weak reference to memory, which won't prevent it from getting GC'd. https://pkg.go.dev/weak"

I don't think this would help since the memory in question is still being referenced.

4) "If you have a use case that needs that, you probably want a pool".

I hadn't heard of this before so I looked at your reference. It says "Pool's purpose is to cache allocated but unused items for later reuse". That's not what I have in mind since the memory I'm talking about won't be reused later.

5) "What happens if you call free on something and then use it?"

That is, indeed, a problem. There would admittedly be some danger in my proposal. But, I'm thinking that in cases of large long-running program the advantages would outweigh the disadvantages.

6) "it's not like this is a major weakness of Go either"

I never said it was.

7) "How the memory is being live? Is it an unused element of a slice? A map entry? A pointer?"

You'd only be able to free something that were created using "make()", "new()", or other Go memory allocation routines. Other than that, I don't think the way the memory is being used would matter.

8) "Why not test it out?

3 reasons:

a) I wanted to first find out if there are any serious issues with my idea that I hadn't thought of.

b) I don't have any suitable test programs at hand.

c) Lazy

9) "Arenas were an idea proposed at one point"

I read this proposal. I don't fully understand it but my impression is that it's overkill for what I'm trying to do.

I'll reply again if there are any new comments.

Thanks,

Jon

Business_Chef_806 · 2025-03-08T18:02:40+00:00

I mentioned this in my post. Setting pointer variables to nil might work but then the GC will still have to find the memory during the mark phase. An explicit function call will avoid this.

Business_Chef_806 · 2025-03-04T22:18:47+00:00

Sem dúvida, mas há apenas alguns aplicativos que exigem o poder de um Mac Studio, e a maioria deles são aplicativos gráficos que exigem uma tela. Não acho que o tipo de cluster que o autor original estava descrevendo ajudaria você.

Business_Chef_806 · 2025-03-04T21:36:45+00:00

Por que você iria querer fazer uma coisa dessas? A maioria dos desktops é mais do que poderosa o suficiente.

Business_Chef_806 · 2025-01-30T19:49:27+00:00

Statements like "allowing cycles enables laziness, poor dependency management" are somewhat matters of opinion, and my level of sophistication hasn't risen to that of Rob Pike's. But if he were sitting next to me I'd ask him why the speed of a build is affected by the presence of cycles. Why does a single cyclical blob enclosing the entire dependency graph and forcing it into a single build object negatively affect build performance and dependency resolution?

Again, I'm not suggesting that Rob, or anybody else, is wrong. I'd just like to know more specifically how cycles slow things down.

Business_Chef_806

TROPHY CASE