Wealthy people have a very bad tendency to rewrite history for their own benefit.
That is a detriment to our species. History should not be written by the conquerors; it harms us all.
Since we’ve suffered from near-total media capture, all our channels have become untrustworthy. That needs to change.
First, is that we need to promote unaffiliated voices whose primary concern is the truth, rather than profits, influence, or power. There are plenty of people out there who say things that are very close to reality. They are uncorrupted by other desires.
Many are not professional writers; they are just doing their best to work on their own simple blogs. They are clear, with little intent, rational thinking, and the fragments of reality that they glimpse are closer to the truth.
There should be a place where ordinary, everyday people can see these works and know that they are genuine. They have been vetted and preserved.
But we need more than that. Far more.
These writings need commentary. They will not be perfect and are even subject to change over time, as more of reality presents itself.
So the original postings should be preserved, and the authors should be allowed to submit edits, which appear alongside them. History gets recorded in black text on a white background.
Any sort of statements that may be in doubt are rendered with yellow backgrounds. It’s not necessarily wrong, but it’s not necessarily right either. As well, any text that is now known to be wrong is rendered with a red background. It should serve as a warning that the author did accidentally drift away from reality, from the truth, but it does not cast judgment on why they did it.
As links, there should be all sorts of commentary about the text. You can pick a yellow sentence and explore why it is not white. That commentary too is colored based on how it is received. There will be commentary on the commentary, turtles all the way down. A nested world whose complexity reflects our own.
In that way, you can read the original works, but can follow through on any sort of issues related to how well that work actually matches reality.
Obviously, to get this requires a large network of reviewers that are willing to dig into what is said and question it objectively. Within this group, there will be a lot of discussions, which are subject to the same treatment.
As time progresses, our colouring of certain works may change. Those changes should be examinable, and the reader should be able to question them as well. Things that we used to believe were true can sometimes be put in a more evolved light as we learn more. Things that we assumed may be wrong. Reality is immutable, but our perception of it is dynamic.
In that sense, the posts are the tip of the iceberg for much larger discussions and arguments underneath. If we get a community of people dedicated to finding and preserving the truth, this repository will be a trustworthy place to not only get to know reality better, but also to monitor the changes in the way we perceive it as a species.
On top of the words from individuals, we can add significant references from other places, where restrictive laws like copyright allow. If media or institutions donate works, they would be added here as well, and as much as we can get from the public space.
There should be no limits as to the content. It is whatever people feel is important enough to talk about at the time of writing, as it will represent our focus as societies and as a species.
The contributors will be voted in to be included. If you know of people who routinely say well-crafted things that are trustworthy, you can nominate them. If they agree to contribute, the words and images from their blogs will be copied by others into this site. It will archive them for posterity.
Some people will have a small number of works included; some may have their lifetime works there.
It’s worth noting that by opening commenting and fact-checking, some people may find it to be rather brutal. But the goal is not ad hominem attacks; rather, it is to take the words themselves and assess them for being truthful. As such, the posts will not be mostly red. This site is not a place to shame people writing for ulterior motives, just one to preserve the works that we mostly agree are truthful.
The site and repository should be funded with zero strings attached. It can be individuals, governments, or even companies, but it cannot be subject to any sort of restrictions other than that the money is applied to the setup and running of the site. The community, hopefully large and objective, will decide what to pursue. Someone who funded this work can never be allowed to use that as a means of having some works altered or deleted. Once something is preserved, it must stay that way. Changing it would betray the whole purpose of the effort.
Independent government funding, at a higher level like the UN, would be best. Maybe an international institute to gather together the funding that is itself hands-off from the site and the content. As a source of truth, this knowledge is ripe for corruption, so the highest priority would be preservation of what already exists, then ensuring access to the people. Adding to it is important, but only as a third priority.
Getting back to the intent, we have a period in our history where ordinary people can satiate their curiosity about our reality and are able to put some of what they learned into the public domain. This was a rare moment when information was not controlled by wealthy or powerful people. We’ve seen this ability get created, and now we see endless attempts to stop this from continuing. But because it had value, and it led to at least some small enlightenments in our world, it is a very worthy exercise to continue with. Lies only benefit the elite; the truth benefits everyone else. Our world gets better when it is no longer hostage to the whims of madmen.
Thursday, October 8, 2026
Thursday, October 1, 2026
Bloat
Bloat, the burning of unnecessary computer resources, is a symptom of a lack of knowledge.
Most people are not deliberately trying to make their code resource-inefficient. It’s just that they have a job to do, and they know just enough to get it barely done. Extras like bloat, security, and extendability are off the table. To handle them properly requires knowledge they do not have, nor the time to acquire it.
There are infinite ways to accomplish any task with a computer. But these days they are all wrapped in inconsistent primitives or calls which are often quite messy. If you understand what’s really below that level, you can figure out how to utilize it to do only exactly what you want. But if you don’t really understand how they work, you're left chaining them together and fiddling until the output approximates your goals.
This has been understood since the 60s, often called the software crisis. The higher we build the house of cards, the more disconnected each new generation gets from what's holding it all up.
The rise of don’t look before you leap philosophies of development fuelled the problem. Coders are in such a panic rush that they just have to grasp at what is easiest, but combined with tunnel vision, that is also usually what is pretty wasteful too.
If you’ve got some fiddling to do with a string, then most people pick the most popular primitives. When they realize that the combination does a bit of extra work, they discount it as a micro-optimization. It’s not; it's a lack of knowledge driving the deoptimization or bloat, as we like to call it.
If they knew more about how it worked underneath, they’d pick a different set and augment that with better code of their own. The output would be the same, but the wasted steps would be gone. They weren’t needed.
That’s a trivial example, but we see this with fiddling, calling libraries and APIs, allocations, polling, queuing and caching, pretty much all over the place. There is some reasonable way to encode the steps, but getting there requires understanding what the steps actually do. Not a guess or a vague understanding, but not enough knowledge to be able to implement them yourself.
Q&A sites fuel this, because they give people a magic sequence, thus offering them the option to just blindly use it.
If you knew better, most people would choose to write the code properly; it doesn’t take more time. If they write bloated stuff, it is because they didn’t know better.
When computers were really slow, bloat was obvious and often unworkable. As Moore’s law kicked in, bloat became just another consequence of the race to get more code out there. But as Moore’s law fades, we'll be forced to return to those early days when people coded with more precision. To do that, they’ll need depth. You can’t correctly pick the best underlying steps if you have no idea what’s actually underneath. Figuring that out will keep you ahead of the pack.
Most people are not deliberately trying to make their code resource-inefficient. It’s just that they have a job to do, and they know just enough to get it barely done. Extras like bloat, security, and extendability are off the table. To handle them properly requires knowledge they do not have, nor the time to acquire it.
There are infinite ways to accomplish any task with a computer. But these days they are all wrapped in inconsistent primitives or calls which are often quite messy. If you understand what’s really below that level, you can figure out how to utilize it to do only exactly what you want. But if you don’t really understand how they work, you're left chaining them together and fiddling until the output approximates your goals.
This has been understood since the 60s, often called the software crisis. The higher we build the house of cards, the more disconnected each new generation gets from what's holding it all up.
The rise of don’t look before you leap philosophies of development fuelled the problem. Coders are in such a panic rush that they just have to grasp at what is easiest, but combined with tunnel vision, that is also usually what is pretty wasteful too.
If you’ve got some fiddling to do with a string, then most people pick the most popular primitives. When they realize that the combination does a bit of extra work, they discount it as a micro-optimization. It’s not; it's a lack of knowledge driving the deoptimization or bloat, as we like to call it.
If they knew more about how it worked underneath, they’d pick a different set and augment that with better code of their own. The output would be the same, but the wasted steps would be gone. They weren’t needed.
That’s a trivial example, but we see this with fiddling, calling libraries and APIs, allocations, polling, queuing and caching, pretty much all over the place. There is some reasonable way to encode the steps, but getting there requires understanding what the steps actually do. Not a guess or a vague understanding, but not enough knowledge to be able to implement them yourself.
Q&A sites fuel this, because they give people a magic sequence, thus offering them the option to just blindly use it.
If you knew better, most people would choose to write the code properly; it doesn’t take more time. If they write bloated stuff, it is because they didn’t know better.
When computers were really slow, bloat was obvious and often unworkable. As Moore’s law kicked in, bloat became just another consequence of the race to get more code out there. But as Moore’s law fades, we'll be forced to return to those early days when people coded with more precision. To do that, they’ll need depth. You can’t correctly pick the best underlying steps if you have no idea what’s actually underneath. Figuring that out will keep you ahead of the pack.
Thursday, September 24, 2026
Webapps
In the early days of the Web, people struggled to make websites more dynamic. The original web technologies were centred around static presentations; they were pretty good at this.
As the trends matured, more and more technologies became available to make the sites dynamic, but also to use them to essentially wrap other programs and systems. The web interface was born; people gave these the cool name of webapps.
In those days, most serious developers continued to produce native GUIs. The web technologies seemed hokey and crude. Many were just mindless fronts that called the real stuff in the back. Light clients calling APIs.
The problem with native apps was portability. There were more operating systems back then, and it was crazy expensive to rewrite the same program for each one. The technologies for writing stuff once and getting it to run everywhere were a great idea, but the implementations were generally too limited to be useful.
What the web promised, though, was a guaranteed way to avoid portability problems. These promises, however, were quickly disrupted by the browser wars and by the emergence of mobile devices.
That led to a huge wave of ‘frameworks’ that all promised portability across all of these different platforms and form factors. Initially, they helped; webapps grew a little more sophisticated. But somewhere along the way, they all got pretty convoluted. Suddenly crafting a reasonable webapp was a whole lot more effort than just crafting native apps. That bump in complexity was rewarded with a visible drop in quality. Webapps started to become extremely buggy.
The browsers themselves grew in sophistication, but their integration was compromised by huge security failures. The web became a free-for-all for scams, driving a lot of people into silos.
They are still just a limited window into some features, but most of the ways to extend them are too fiddly to be practical.
So we’re left with most interfaces starting on browsers, then getting mobile cousins, then maybe better native versions. Oddly ironic since, except for form factor, they're all a bunch of interactions on a whack load of widgets. The foundations for graphical user interfaces haven’t changed for decades, just after the client/server split. All of these modern technologies trace a close lineage to their earlier generations.
If we were going to rethink this, it would be to go way back to the portability days. We’d still like to write one set of code that covers all three locations, pushing each right to its limits. That is, you’d grab a webapp you like, run it natively, and it would save your files locally. If you run it on a phone, it would give you the option of local or hosted.
If you can wire in optional platform capabilities and some dynamic form factor support, then you really could return to a point where writing interfaces wasn’t the bulk of the development effort. If it was near trivial to dump out 80% of the boring screens in a few days, then you could spend more time deciding which widget arrangements were best suited for which tasks, rather than expensive widget/presentation wiring and refactoring.
Webapps suck. They almost didn’t, but then fate intervened. We don’t need more siloed clumps of monetizable half-baked features; we have enough already. We need better adaptive and integrated tools that allow us to spend less time on computers, not more. The answer to this is not probabilistic personalized interface generation; more opaque, crappy code will only make things worse. It is to rework our foundations and get back to some of the great ideas of the past that we skipped over too quickly.
As the trends matured, more and more technologies became available to make the sites dynamic, but also to use them to essentially wrap other programs and systems. The web interface was born; people gave these the cool name of webapps.
In those days, most serious developers continued to produce native GUIs. The web technologies seemed hokey and crude. Many were just mindless fronts that called the real stuff in the back. Light clients calling APIs.
The problem with native apps was portability. There were more operating systems back then, and it was crazy expensive to rewrite the same program for each one. The technologies for writing stuff once and getting it to run everywhere were a great idea, but the implementations were generally too limited to be useful.
What the web promised, though, was a guaranteed way to avoid portability problems. These promises, however, were quickly disrupted by the browser wars and by the emergence of mobile devices.
That led to a huge wave of ‘frameworks’ that all promised portability across all of these different platforms and form factors. Initially, they helped; webapps grew a little more sophisticated. But somewhere along the way, they all got pretty convoluted. Suddenly crafting a reasonable webapp was a whole lot more effort than just crafting native apps. That bump in complexity was rewarded with a visible drop in quality. Webapps started to become extremely buggy.
The browsers themselves grew in sophistication, but their integration was compromised by huge security failures. The web became a free-for-all for scams, driving a lot of people into silos.
They are still just a limited window into some features, but most of the ways to extend them are too fiddly to be practical.
So we’re left with most interfaces starting on browsers, then getting mobile cousins, then maybe better native versions. Oddly ironic since, except for form factor, they're all a bunch of interactions on a whack load of widgets. The foundations for graphical user interfaces haven’t changed for decades, just after the client/server split. All of these modern technologies trace a close lineage to their earlier generations.
If we were going to rethink this, it would be to go way back to the portability days. We’d still like to write one set of code that covers all three locations, pushing each right to its limits. That is, you’d grab a webapp you like, run it natively, and it would save your files locally. If you run it on a phone, it would give you the option of local or hosted.
If you can wire in optional platform capabilities and some dynamic form factor support, then you really could return to a point where writing interfaces wasn’t the bulk of the development effort. If it was near trivial to dump out 80% of the boring screens in a few days, then you could spend more time deciding which widget arrangements were best suited for which tasks, rather than expensive widget/presentation wiring and refactoring.
Webapps suck. They almost didn’t, but then fate intervened. We don’t need more siloed clumps of monetizable half-baked features; we have enough already. We need better adaptive and integrated tools that allow us to spend less time on computers, not more. The answer to this is not probabilistic personalized interface generation; more opaque, crappy code will only make things worse. It is to rework our foundations and get back to some of the great ideas of the past that we skipped over too quickly.
Subscribe to:
Posts (Atom)