valand

Thanks to you, "My server is a phone now" becomes much more interesting now as the server is now a perpetual non-physical entity that inhabits a new physical form, the phone.

I also think this. But more in the sense where both end of the LLM are trained using words through repeating arithmetics, considering LLM itself is a repeating pattern of connections, the space in the middle if extracted the same way as the beginning and the end would become data that make sense to us.

Can the awareness simply come from injecting knowledge of itself during fine tuning and then during a chat a system prompt is injected to add a particular context that triggers its self-knowledge?

Fun fact, V8 interns strings! But it doesn't seem to intern big ones.

In a sense, this is how being in a foreign country where people talk in other languages and act within their own culture. They are more productive than you because the environment fits them more than it does you at that time.

And this acclimation is also similar to https://en.m.wikipedia.org/wiki/Mathematical_maturity, how you talk with math people the from math village and feel you are stupid because you're not familiar with the symbols, the vocabularies. But when you have learned the language, you will see that you become better and better at learning, you have the means to gain more means--forming some sort of a positive feedback loop.

The only thing I disagree is the title. And maybe number 3; estimate is needed for pseudo-reassurance and comparison; it's ok to not be accurate. And don't spend hours to be accurate.

Agency prison is often overlooked, a superset of vendor-locks. When google domain was sold to squarespace, lots of people complained that they can't pay manually; it seemed unimportant to domain ownership, but they moved to cloudflare anyway; they were forced to migrate, freedom was taken, it was hurtful.

Maybe I'll add - simplicity the author referred to (or I would prefer to call it process elegance) needs experience and knowledge. For no 4,5,6 especially.

The history - surviving or not - contained often overlooked wisdom. Looking at the past reveal that our predecessors struggled the same struggle. It's also wise to realize that time can be too scarce for that; let others that have done teach us; keep our mind open.

Good, elegant article overall.

A similar sentiment: when one can talk about past trauma without reacting negatively, even more joking about it, one has overcome it.

While euphesim displacement is naturally occurring, it doesn't mean it is the best course for the common's sanity.

Not to mention the namespace exhaustion that goes along with it :D

Ok. I might have misworded my answer, but assuming that cloudflare has to do more about this, what would it be?

Aside from process host and protocol, what makes it different from, let's say publicly available google drive?

Must or mustn't they filter customers is a matter of law.

However, putting the responsibility to mitigate this problem in its entirety is very inefficient and ineffective. If Cloudflare would have a team dedicated for this effort, bad actors would simply switch providers, beating $200k/year effort by couple clicks.

Notice that the malware ultimately takes effect when the user executes the file.

This sounds more like an interaction design problem that should be solved in the OS level; the OS interface is one of the logistical bottleneck for the malware delivery path.

At this point --- and speaking for non power-user --- this should be an OS interaction design problem.

Framing cloudflare as the enabler is missing the bigger picture.

I remember back in the day I needed to turn off autoplay on Windows to not get accidentally infected by malicious drives.

No one was insane enough to blame the CD-RW and flash drive manufacturers.

Much appreciated!

Never dug deep into Bevy's subcrates, but does this mean you have more control from the JS side? (e.g. when I want to interlace the main loop tick with something from the JS side)

One thing I learnt going from frontend development, to distributed system database, development, and then back:

These neanderthal grade tools have the same problem: attempting to abstract away unabstractible problems. The MO of said tools are to limit expressiveness rather than provide context or knowledge.

Take the multi-tab syncing you mentioned. Syncing will always take a loop and a buffer, assuming a channel of communication is not a problem. Those can be in a library, in a browser's built-in API, abstracted away, or you can write it by yourself. But when you don't write it, you don't have control over it (e.g. when to sync, how to interlace the syncing with other operations).

A better toolings work in the level of paradigm. Instead of simply abstracting, bring complexity to clarity and provide the learning ramp.

Not software engineering exclusively, but this article in system domain in general https://donellameadows.org/archives/leverage-points-places-t...

Can't do c++ on phone, but on Rust that code executes 22 operations/microseconds in Rust Playground.

Are you sure you are measuring it correctly?

https://play.rust-lang.org/?version=stable&mode=release&edit...

As someone who delved with both system design and ui design, yes, this name overloading is frustrating

You mix up development problem with computational problem.

If you can't use formal proof just because the user can't be arsed to wait where it is supposed to be necessary, then the software project conception is simply not well designed.

A software business is made when someone needs an automated computation and buys a program from someone else.

The buyer has a specific requirement, which is distilled into a specification. The specification is implemented. Implementation that doesn't match with the specification is a bug.

Now in order to verify the implementation's correctness relative to the specification there must be a QA.

The idea that people forgets to add QA in the software development process is wild because it means people are forgetting how to conduct business.

It was a mandatory class too in the univ I attended.

What was not taught about were the techniques of QA's, the variety of tests and design pattern enforcements that would reduce QA cost by tenfolds.

See libuv and event loop.

"Single threaded" is not a selling point of JS, but a statement of its limitation and it refers to how JS event loop is executed.

Implementing multithreading doesn't make sense for some people unless they can attain the same "ease of use" of JS.

Basically, pushing (e.g. revving) an engine beyond its structural limit.

I found Donella Meadows' book insightful, but I only read it after I understand system thinking so I might be biased. I wonder how insightful vs confusing it is to people from different paradigms

The author uses the general meaning of the word and not the now-popular subset meaning: scientific theory.

Even this is an over simplification of inversion of control.

Dependency injection is one form, but even a library that exposes parameters is also a form of inversion of control.

The degree of control is what varies, whether it is a mere flag (boolean), a variant directive (complex struct), a turing complete construct (pointer of instantiated function) or anything in between.

What I am saying is that this concept has been reduced as it is popularized and it isn't doing justice to the original powerful concept.

Often the people who overfocus on the beauty of the flower are those detached too far from the customers, too many indirections that hide failures and pressure

I always deplore this shallow influencing of design patterns without proper examination of whether said design pattern fits or is even correctly described by the popularizer. People fail to realize that inversion of control is necessary ONLY if some controls need to be inverted.

To be fair, "inversion of control" is a great concept, but unfortunately told in a very specific way across time so the meaning now has changed into an inferior form of the original.

It's neutral. However, a brief negative implication: it's less "idiomatic", as in the pattern that's commonly advertised as best practices

> but articles like this one are probably the things that can lead to the kind of unproductive bikeshedding that is sometimes experienced in PRs and other discussions

I'd counterargue that if these trivial principles are established beforehand, unproductive bikeshedding of this type will happen less on PRs and other discussions.

> as long as the function is properly named, has a good interface (including expressive types), a clear purpose, is properly documented, doesn't make excessive use of side effects etc.

In performance-sensitive software where DOD thrives, more care needs to be put into these "in the small" things because that is how compiler optimization works. Then, it changes the rule of the game: statement semantics become crucial, self-documenting code makes more sense, in-code comments are for reasoning exclusively, and "documentation" becomes "specification and user manual".

Not even strictly DOD, this trivial principle produces better semantics and drives better code separation down the line.

Several years ago I was exposed to DOD (and then this principle) when working on complex JS/TS-based for long-running systems. It results in better code navigability, accurate semantic synthesis, and easier subsequent refactors.

The side effect: some people remarked that the code looked like C