prmph

I'm talking about the general direction this is taking.

I don't think once this is established in enterprises it is going to stop there.

This is going to make things worse for all kind of use cases that are legitimate but seem non-standard or marginal.

Heck, many websites I visit on the web cannot understand why I, a Ghanaian living in Ghana, might be interested in the service offered or the information therein. I am sometimes blocked for no good reason.

If you are in a third world country, the web is extra hostile. This is going make things worse.

You are committing a type error.

Consciousness does not necessarily arise from computation, just as simulating snowfall on the computer does not make it cold

I hear you, but sometimes it is hard to understand why things just stop working for no apparent reason.

One more example: Whenever I navigate to the Hacker News login page in the mobile browsers on my old iPad, I see: “Sorry”, just that, no other explanation. So I am unable to login, but all other HM pages seem to display fine.

This is what I'm starting to believe. Also, its maybe partly a systems issue: create a product with 1% tolerance for failures; if it has to interface and work with 5 other products with a similar failure rate, suddenly you have maybe 5% chance of failure.

In particular its crazy how connections and cables of all sorts are unreliable now, especially stuff that has to be plugged in and unplugged: USB, Bluetooth, etc.

Yep, never own a domain with NameCheap.

My experience was kind of opposite, but still bad nonetheless. I lost domains I had with them simply because I lost the phone I used for 2FA. After several calls to them, they requested some info. I supplied all they wanted, but it took them more than a year to get back to me, by which time I had lost all interest in maintaining domains with them.

Luckily these were not critical domains; I had bought them in anticipation of building a business on them.

I am moving my domains to CloudFlare.

Sorry, I meant if the couple were regular visitors to those areas in Tuscany known for malaria. I do agree that this test is still inconclusive, which was the point of my original comment.

From TFA:

> “Francesco and Giovanni, a young member of the family, both traveled 25 years apart to areas of Tuscany which were known for malaria,” Giuffra said.

“The court physicians tried to discourage some members of the Medici family from doing these trips, especially in autumn, which was a season particularly favorable for malaria...”

I live in Ghana, we have malaria as a common (not too common though) ailment. I have also had malaria several times, though the last time was almost 9 years ago.

As I understand it, some malaria parasites can remain dormant in the body for a long time. Clinical symptoms develop once the parasite burden and immune response become sufficient to cause illness.

Not sure if the couple had made trips to Tuscany before the last one, but it is interesting they found two species of malaria pathogens.

I thought that was also an interesting angle to consider.

Nice project, but what is "hidden" gem about Elmina castle in Ghana?

If Cape Coast Castle is described as "world renowned", then Elmina should be as well. I live in Ghana their popularity is almost evenly matched.

Also Elmina castle is the oldest and largest European building in existence in sub-Saharan Africa.

One more thing, it is kind of hard to click on specific dots when they are so clustered together. I had to zoom in a lot to see and be able to click on some of the castles I knew were there.

Your article is all over the place and seems to have agenda. It is unable to stay on point and present a coherent argument.

I'd rather trust the Nytimes and the UK intelligence who have confirmed these losses, than some random website pushing an agenda.

By hey, if it makes you happy to create you own reality, you do you.

Japan should be the last country with a complaint. Read up on unit 731, at least, if you are unaware of the rape of Nanking or it does not convince you.

There is more to my comment than meets the eye. You should not assume ignorance on my part.

Why Japan? What do they have to complain about?

Better as one word "vibecounterexamplemaxxing"

It may not be a lot of dying at once, but some modern wars are rivaling these catastrophic wars of old in casualties.

By some counts there have already been at least a million casualties in the Ukraine war, and in Gaza there is probably 100,000 casualties now (military + civilian). And, the conflicts in the eastern Democratic Republic of the Congo over the decades have produced about 5–5.4 million casualties, although accumulated over decades rather than in a single war.

So modern conflicts may be lower intensity and lest existential, but they can be every bit as deadly.

It's not over-engineering if you are committed to what you are building for the long term, and know you'd very likely need stronger architecture at a certain time.

No one starts a project for perfectly objective reasons. Your choice of careers was not perfectly objective, you decided you liked a field, and it seemed you had enough aptitude for it, and then you did the work to get into it, learning as you went along and adjusting.

So it is with all kinds of decisions that go along with starting or changing a software project. Of course are your architectural and engineering acumen increases, you get a goo feel for how to choose good constraints and requirements, and then within the those constraints it is now up to you to find optimal solution for them, not the most over-engineered one.

Like I said before, sometimes going from A-B-C-D is much less efficient (and can actually be counter-productive) in the aggregate than going form A-D directly, even though YAGNI would dictate A-B-C-D. So long as you generally know that D would be needed sooner or later, A-B-C-D can be counter-productive because it causes to you to miss the forest for the trees. Even if you are not doing D immediately, some thought given to D can improve greatly your understanding of the context of A and the roadmap, leading to better design.

Note that string design instincts honed over time make this process work, not building out stuff just because of fads (e.g., microservices) or for some functionality you do not actually need. So here is my point of agreement with the article: the reason teams might waste time over-engineering is not because they are exploring a design space and objectives that is larger than what is strictly required for now; it is because they lack good architectural skill and experience and instincts. Again, considering D upfront can actually simplify the A you build now.

Isn't Anthropic anti software engineering? This state of affairs is exactly what you should expect.

I don't know, this is a company that is pushing the narrative of software engineers becoming obsolete. Why do you think they would have respect for Software Engineering processes. As few as they are concerned, a few coders working in isolation with Claude Code is all that you need. (pun unintended)

The vendor of a piece of software decides how best they'd like to be paid.

A subscriptions approach allows them to avoid demanding a big payment upfront, and allows them to continue improving the software without you having to pay substantial sums to get new licensed versions. It has pros and cons vs licensing, but is a legitimate monetization strategy.

That the bits already exist on your machine is irrelevant. Your entitlement to use the bits is what is at issue here. Being already in possession of stolen goods does not entitle you to use them.

As it should be.

You'd prefer they get nothing for the effort they put into developing the software?

I could not disagree more.

I can't even fathom how someone can say this with a straight face. Judging by the absolute garbage (architecture-wise) that the frontier models put out, I pity anyone taken in by this sort of thinking. They regularly tie themselves in knots and dig deeper holes for themselves without my intervention.

Software is exact; its maths. We would not tolerate a machine that operates on the basis proving/applying theorems right like 60% of the time. How we think this is suddenly acceptable in software engineering baffles me. CVEs can kill people, bad software can cause severe harms

But maybe I should not be on here arguing about this. I should be out there working on how to profit off such fundamental misunderstandings.

Quality is the ratio of the value you derive from the software to the cost to you of using it.

Most typical quality attributes can be subsumed under this schema.

If the software costs too much to change because the architecture is poor, that reduces the quality.

If the interface is poor or it is slow unnecessarily, it costs you more time to use it, and that reduces its value to you and hence its quality.

If the software is insecure, you may actually lose privacy or even money using it.

If the software is not robust, you run the risk of losing data and time, etc. when using it

> The RxScanner is a handheld spectrometer that scans a pill with infrared light, then sends the item’s molecular profile to an AI model equipped with a pharmaceutical database. In seconds, the AI identifies the medication from its molecular profile—or reports that it’s phony.

Is every tech, including database search "AI" now?

End-to-end encryption is about protecting data at rest on the vendor's servers. TLS only secures data in transit.

The article's argument is a bit like saying TLS protects plain-text passwords in transit, so there is no need to store them in hashed form in the database.

Sure, the article makes good arguments about the trust that is still implicit in E2EE, but it goes too far in its dismissal of it.

But we are talking about protecting data at rest on the vendor's servers. Unless the vendor stores no user data at, how does TLS protect that data?

Your argument is a bit like saying TLS protects plain-text passwords in transit, so there is no need to store them in hashed form in the database.

Two problems I see with the authors argument. Maybe someone more knowledgeable can chip in to correct me if I'm wrong:

1. Aren't E2EE systems designed to prevent decryption of content already created in the past sitting on the vendor's servers? Yes, the vendor could go rogue, but, assuming they currently have implemented E2EE right, it means any change to the client can only compromise content created in the future from that point onward, no? So why is the article implying Apple could have provided a back-doored iOS to bypass the encryption for existing content?

2. I also don't find the argument that E2EE is only a legal trick fully convincing. There are several other incentives for a vendor to implement it apart from avoiding legal issues: preventing insider abuse, reducing liability, improving customer trust, and resisting mass surveillance

These are real engineering motivations. The threat model is not: "Protect you if <vendor> becomes actively malicious tomorrow." Its more like "Protect messages stored on <Vendor>'s servers from attackers, employees, hackers, routine legal requests, and passive surveillance."

I'm not sure why people have not hit on the following hybrid architecture that works so well for me.

I make use of table-valued db functions (IMO the most underrated feature of relational DBs) to define virtual relations/tables. I implement a set of CRUD db functions per entity. Then, on the app side, I define (or generate) DTO types representing these virtual relations. Finally, I use a custom ORM I wrote myself, which defines a general and consistent storage API, to talk to the db functions, using the DTO types.

The advantages of this approach are numerous, some include:

- I have full control of the SQL that goes into constructing the virtual table, I can leverage all the goodness of SQL here. I can even define multiple virtual relations per physical table, or read-only relations, etc, all by implementing the appropriate sets of CRUD db functions

- On the ORM side, I have all the goodness of static typing, a consistent API for all CRUD methods, a full fluent query DSL, etc

- Since, unlike tables or views, db functions can be passed arguments, i am able to layey all kinds of goodness on top of the basic CRUD actions, like audit info passing, custom upsert strategies, some level of record-based authorization, etc

But this architecture does require you to know and write SQL. IMO the value of ORMs do not lie in avoiding SQL; it lies in the capability to express consistent SQL at a higher level of abstraction, but you still need to understand your SQL.

Way to miss the point.

I said I can be sure of what I am recollecting, not whether the my recollection actually matches what happened.

My internal reality I hope tracks external reality.

And what I can be certain about is what my internal reality is.

And if you think I cannot be sure of that, I think I can be certain about I think my internal reality is.

And if you think I cannot be sure of even that, I think I can be certain about I think what I think my internal reality is.

It's perception all the way down, recursively. The reality is result of this taken to infinity.

> a bunch of narratives our brains thread into a cohesive story ex post facto

That is exactly the reality I am asserting, whether or not they actually describe an "external" reality