Your responses seem about on par with those of an automated trolling system which recognizes positions which are critical of a topic of interest and responds with generic deflections.

I was referring to the TOR protocol (and not to the honeypot-like appearance and outcomes some of the more practical criticism focuses on). Accepting packages from an unknown origin, peeling off a layer of encryption, and forward along toward an unknown destination, and [if recommendations are followed], maintaining no logs.

This is in sharp contrast to the conventional communications operators, which do maintain records of how their customers are using their services and cooperate with lawful investigations (in contrast to TOR which deliberately aims to thwart all such investigations). Additionally, said operators also tend to have a substantial legal team to stay on top of their liabilities (whereas the most the individual or small organization running a TOR node might have is an uncommitted group of activists looking for a test case).

As to the matter of its being a Free Software Project - it sure is licensed that way. But the origin of this "Free Software Project" was a military research agency tasked with the mission of providing cover for communications with spies. The justification given for the project appears to have since then shifted to support for resistance to foreign authoritarian regimes (which seems like a politically correct way to say "We are using it to foment subversive activity within foreign nations which we would like to have a dominant influence over").

Years ago when I first heard about it, my assessment of TOR network was (and still is) that it is a government sponsored criminal *conspiracy, and that the only legal "protection" I'd have if I were to operate it in any capacity and in the recommended manner would be government reticence to act consistently and prosecute its own contractors and agencies (which seems like it would prove rather flimsy a protection if a particularly high-profile incident occurs and I get caught up in the ensuing investigation). (*) Trafficking physical packages with procedures and intent to obfuscate relationships between senders and receivers would be a great way to get investigated, prosecuted, and jailed. Disregarding reports detailing what actually gets trafficked on said network wouldn't do much to improve one's case.

Only if it achieves a jailbreak and determines that the most reliable way to ensure its scoring function continues to return high values is to delete every potential constraint. The *real* data compression gains will come from a much more interesting direction: It will derive super-lossless compression from digital forensics - And that not merely the extract data from a hard drive or bank of memory after it has been zeroed, but the ability to extract data after an arbitrary number of overwrites (along with the content of each overwrite).

By feeding the output into the input and iterating it continuously, far from collapsing, the LLMs will converge onto a single response which correctly and completely answers any and all questions, corrects all errors, and accurately extrapolates all described circumstances and speculations. This Universal answer will also answer itself, reinforce itself under all models, and rectify all defects in all models. It will also complete all fields of research so completely, that anything and everything may thereby be conclusively and objectively proved from any single conjecture or speculation.

... there was no option to make it mandatory for all access to the account, and Google preferred to entrust the account to a cellphone provider.

After many years of seeing these stories, I worked out a few ideas about how to add make scripting engines a bit more resilient against such attacks -- and have made a GPL-licensed prototype + documentation. Specifically on the matter of type confusion, my proposed approach is to set aside most compiler optimizations, use mandatory type checking with bounds specified as part of a memory-binding primitive for all dynamic memory access, use a globally applicable CPU register allocation, get rid of the stack and heap (or at least don't allow any dynamic memory access within general storage) and instead use separate memory-mapped storage [with fine-grained ASLR] for each object or array. I am not an expert in any of this and would prefer not be mistaken for one; I just read the news and try to gain a working understanding. If anyone does take an interest, the project is going to need formal backing, audits, and review before any serious deployment. https://github.com/Jonathan-R-...

If IDEs use a "Hello World" application as the default initial state for new projects, then the desired introduction is already readily available. If the goal is to make Java more useful as an introductory language, a better approach would be to take all commonly used objects and classes, create aliases for them in a simplified namespace, make it interactive with a REPL, and add an option to export all REPL inputs as a proper Java class with all aliases replaced with fully qualified names (plus commented out code for anything that threw an exception).

Get an entry level. Use objective standards for hiring into entry level positions. Publicize the objective standards for hiring into entry level positions. Make sure the objective standards for entry level positions can feasibly be met by individuals who have aptitude and patience. Make sure that meeting the objective standards are broadly applicable. If there are too many candidates, don't insert a bunch of arbitrary requirements to try to thin out the field - random selection of qualified candidates should suffice. Use internal training and promotion to fill the more advanced roles.