@@briangroh444 you are correct in that SMSGTE is no longer a service. It has since been replaced by a new SMS service by NA7Q I believe with the call "SMS" that you must opt in to beforehand.

@@q5go84q this crotchety OM is shaking his cane at you... :)

They seem to have had the mindset that "If it ain't broke don't fix it". Well, where does the money go that they get for dues?

LoTW is the most bizarre app I have ever seen. It seems to have been optimized around being used from the moon with the crazy cryptographic stuff. It is difficult to set up - far beyond the computer skills of the average ham. Why it's not simply a website that you log into with a username/password and upload a CSV is beyond me. I gave them this feedback years ago and it was summarily dismissed.

Love your channel, btw. Keep it up!

Thanks!

ASL2 is depped replaced by ASL3 which is Debian 12. ASL3 being buggy.. well are you reporting the bugs to them? A very big issue in many many many projects is 1 guy doing all the work which if it is a small project you can get by with but large projects the 1 guy doing everything leads to disaster. just look at the xz issue from earlier in the year.

Many big platforms started with Python as a backend such as Instagram, but the ones that grew quickly found python became a major bottleneck and had to change to a lower level language. Python is my language of choice for almost everything. It's a flexible tool, but it is not the best for resource/processing intensive applications backend. A database backend of this size doesn't need to be rust exactly, but it needs to be written in a snappy language nevertheless, and C++ is growing quite old now. I think python not scaling well is common and accepted knowledge in the programming industry. That's why some implementations like C python have spawned to try and combat it. But programming languages are like tools. Some are some better for specific tasks and when possible, the "efficient" thing to do is use the right language for the job. Pythons great for prototyping, AI, and some web back ends, but it starts to show its speed when doing a lot of processing.

@@ModernHam Were you privy to precisely how AARL used Python? Like you and I, its use may have been specific to preprocessing data loads, data analysis, scraping etc - tasks which fall outside what ou are describing. Also, I doubt that ARRL had much of a problem with scaling to begin with. Their primary site was written in php for crying out loud. If the goal is to do forensics on the attack, why suggest a change to their stack when the more scalable options generally introduce additional attack vectors, complexity and technical debt? That's why I'm scratching my head. ARRL is not Instagram, and was never in a position to exploit what you propose to begin with. I'm not defending ARRL, which is why I'm questioning how supportive and engaged management was with their IT staff. That seems consistent with the pattern I've seen with them for the 42 years I've been a subscriber and user of their resources.

Python doesn't scale well.. # 1. Global Interpreter Lock (GIL) - limits true parallelism with threads. # 2. Dynamic typing - runtime type checks slow performance. # 3. Interpreted language - slower than compiled languages. # 4. Memory management - garbage collection adds overhead. # 5. Concurrency limitations - limited use of multi-core CPUs. # 6. Inefficient multithreading - multiprocessing has high IPC cost. # 7. Dependency on third-party libraries - varying scalability. # 8. Interpreter overhead for large codebases - slow without JIT. # 9. High memory usage - inefficient data structures. # 10. Blocking libraries - many lack native async I/O support. ### 1. **Global Interpreter Lock (GIL)** - **Single Threaded Limitation**: Python's CPython implementation uses a Global Interpreter Lock (GIL), which essentially limits the execution of threads to one at a time, even on multi-core systems. This means that multi-threading, a common approach to scale applications, doesn't effectively utilize all CPU cores. For CPU-bound tasks, this can significantly hinder scalability. ### 2. **Dynamic Typing** - **Runtime Overhead**: Python's dynamic typing makes it easy to write flexible code, but this flexibility comes at the cost of runtime overhead. Types are checked at runtime, and variables can change types, which requires extra computational effort, reducing performance compared to statically-typed languages. For highly concurrent or high-performance requirements, this can become a bottleneck. ### 3. **Interpreted Language Overhead** - **Performance Limitations**: Python is an interpreted language, meaning the code is not compiled to machine-level instructions beforehand but is interpreted line-by-line at runtime. This significantly affects performance, making Python slower compared to compiled languages like C++ or Java. This limitation makes Python less suitable for applications needing high processing power, which can limit its scalability. ### 4. **Memory Management** - **Automatic Garbage Collection**: Python’s memory management relies on garbage collection, which automatically frees unused memory. While convenient, it can introduce latency and unpredictability in performance, particularly in memory-intensive applications where managing memory manually could result in more efficient scaling. The garbage collector can add overhead and reduce efficiency under high loads. ### 5. **Concurrency vs. Parallelism Challenges** - **Limited Parallelism**: Due to the GIL, Python has a harder time taking full advantage of multi-core architectures. While concurrency can be achieved via `asyncio` for I/O-bound operations, true parallelism (e.g., in CPU-heavy tasks) requires workarounds like multiprocessing, which involves the overhead of creating separate processes and communicating between them, rather than efficiently using threads. ### 6. **Scaling with Multithreading vs. Multiprocessing** - **Inefficient Multithreading**: While Python has a `multiprocessing` module that allows scaling by using multiple processes, this approach comes with the overhead of inter-process communication (IPC) and memory duplication. This is generally less efficient compared to threading in other languages, which can lead to higher resource usage and limit scalability for some types of workloads. ### 7. **Dependency on Third-Party Libraries** - **Varying Quality and Efficiency**: Many of the tools that make Python great for rapid development rely on third-party libraries. These libraries vary in quality, and some may not be optimized for scalability. Dependency on third-party solutions means that applications may inherit inefficiencies or lack of scalability that come from less optimized code. ### 8. **Interpreter Overhead for Larger Codebases** - **Code Execution and Compilation Overhead**: As applications grow larger, the cost of interpretation and the lack of a just-in-time compiler (JIT) like those found in some other languages (e.g., Java's JVM) can lead to slow execution times. Tools like PyPy (a JIT compiler for Python) can mitigate this, but the standard CPython interpreter is not optimized for this kind of performance, leading to scaling challenges. ### 9. **Memory-Intensive Operations** - **Less Efficient Use of Memory**: Python’s data structures, such as lists and dictionaries, are very convenient but consume more memory compared to similar structures in lower-level languages. When scaling applications that need to handle large datasets, Python's higher memory usage can become problematic, particularly for memory-intensive operations that require efficiency and low latency. ### 10. **Lack of Native Asynchronous I/O Support in Libraries** - **Blocking Libraries**: Many of Python’s popular libraries, such as those for database interactions or networking, are not natively asynchronous. This lack of support means that certain operations can block the entire program flow, making it harder to build scalable, non-blocking architectures unless specific effort is made to use async-compatible alternatives.

They keep asking me to join, but I refuse. The details behind this hack told me I do not want to store much financial or other personal information with them. They need to get that IT house in order.