Using computers more freely and safely
akkartik.name
akkartik.name
One of the strangest things is when people over-interpret modest remarks as declarations of war against the fabric of sensibility and human decency. This seems to be a trend nowadays.
I don’t think that the author of this article/talk meant to discourage people away from all software contrary to the types he discussed here and it doesn’t sound like that. It reads like a modest appeal.
* Prefer
* "Gravitating away"
* "even one of these suggestions"
* "better than nothing"
* "This isn't always possible. Sometimes we have to use software with millions of users. But I think it helps to rely on small-scale tools as much as possible, and to question tools for large crowds of people at every opportunity."
(I'm the author.)
The problem is that your presentation is not covering the various downsides of choosing "small-scale" software. There are tradeoffs and if you don't explicitly highlight them, it's a disservice to readers.
E.g. You mention that large-scale software for millions is "expensive". But small-scale software is also expensive in different ways. (Software used by only a few can be more expensive in time/labor/hassles because of lack of features, workarounds required, lack of tutorials, etc)
I've written several utilities in the "small-scale" software category for my friends to use and that experience has enlightened me that most people (who are not hackers & techies) should use "software for millions" as the default choice.
If you're one of those that chooses small-scale software (e.g. your old Lua v5.1 anecdote), I think you're already part of a self-selected group and you don't need blogs suggesting it to you. You also are willing to overlook the downsides.
I like most of Clay Shirky's writings on various topics but his particular essay on "Situated Software" which you cited is incomplete and misleading because it doesn't cover "software rot": https://en.wikipedia.org/wiki/Software_rot
I'm not saying we should use situated software everywhere. I'm saying we should _try to_ use situated software everywhere. I think of this as evolutionary adaptation advice. Akin to, "you're evolved to climb trees, avoid plains." My hope is to stimulate demand for situated software, with cascading improvements in availability and convenience.
Situated software has costs of convenience. To that I say, "suck it up." It's good for you. With the full knowledge that most people will ignore me.
It's important to weight the costs on both sides by the impact when costs occur. That's a big part of why I think it's not a contest. One 0-day pays for thousands of problems on the other side.
I used to try a lot of APPS to produce documents and scruture my mind. Notion, google docs, word, calc, excel... It was fine but it I agree that some times is a pain. Google docs run very slow in my computer, Windows overheats in my laptop , etc.
Finally I discovered Emacs. I am pretty bad with elisp but I love it. Now I just use, Emacs, a couple of web browsers, bash, Python and some perl scripts.
While this article oversimplificates some things It has valid points for specific cases. btw, I like this web design!
Do you mean Emacs with Org-mode? Or just plain Emacs? I'm curious, because I don't know much about Emacs but I heard a lot of good things about Orgmode.
Org-mode it's just a mode, Emacs has a ton of modes, major and minor. The GNU Emacs Distribution, the Vanilla Emacs, already comes with org-mode.
It was six months ago. org-mode blown my mind. It was a transcendental experience, I was thrilled. It had everything I wished and much more. Thanks to it I discovered Emacs and I love it, it makes my life easier. What's great about Emacs is that you can solve any question you have with the manual, it's awesome, mind-blowing.
But It has a steep learning curve. I got through vim tutorial in less than an hour. Going through Emacs tutorial took me 4 afternoons, one our every day. It was 4 days because it's too much for one sitting. I almost gave up, I am happy I didn't. You have tot taking it slow, there are a lot of crucial key bindings you have to learn.
If you like writing or ordering idea, notes, etc. I recommend it, at least try it and then decide for yourself. But you have to put some time to get familiar with the Emacs ecosystem. Take it like a pianist, slow and steady makes you learn twice faster.
I am just a novice but this summer I want to try to learn more elisp and try to make one package. I hope this is not off topic. Emacs fits the description of the article, right?
As someone who could've developed an IT/programming career, but didn't because I felt things were already bloating back in the '00s, I agree with the majority: "harvesting your own food" can be rewarding but also a tedious and thankless job. It's certainly not for everyone, but if it works for some people then it is (let's put efficiency aside for a moment) perfectly valid. In fact, being more of a H/W guy I find myself gravitating towards this approach more often than not. Leanness and reproducibility is key for my workflow (I went the RF-world path), I can't afford different end results when a dependency changes/breaks something.
IMHO, keeping up with the modern paradigms for S/W development looks like a never-ending nightmare. Yes it's the modern way, yeah it's the state of the art. Still, I didn't feel it was a wise investment of my time to learn all those "modern dev" ropes, and I still feel that 20 years later. I'm nowhere near antiquated and I'm on top of all things tech (wouldn't read HN otherwise), it's just...
I see former friends/classmates that went this way, and they're in a constant cat-and-mouse game where 50% of time they're learning/setting up something dev-chain related, the rest 50% doing actual work, and 98% of it feeling way too stressed. I see modern Android devices with their multi-MB apps, bloated to hell and beyond for a simple UI that takes ages to open on multi-core, multi-GHZ SOCs. I see people advocating unused RAM is wasted RAM, never satisfied until every byte is put to good use, reluctant to admit that said good use is just leaving the machine there "ready" to do something, but not doing anything _productive_ actually.
And yet.
Without that bloat, without the convienience of pre-made libraries and assist tools for almost every function one could desire, we wouldn't be where we are now. Imagine for a moment doing AI-work, 3D movie rendering, data science etc. with a DBless approach on single-core machines with every resource micro-managed to eke out the most performance. It's simply not feasible, we would still be on the 90s... just a bit more hipster.
This article resonates so well with me. And at the same time, it feels so distant.
But an essential component of this plan is for non-programmers to articulate early and often their desire to migrate away from the current monopoly they are forced to use.
With all that said, my sense is that hardware engineering has its own heap of Sisyphean problems and complexities. I definitely would not go back to working on hardware engineering problems like I did super early in my career (a mix of embedded firmware, device drivers, PCB design, and web development). I shudder at the thought of ever working with anything Verilog/VHDL, Xilinx, or SPICE ever again, or debugging PCB designs on the bench top in the lab with an oscilloscope and a logic probe. At least in school I ran more than a few bodge wires to patch a mistake in a PCB design iteration. Maybe in some sense, it's a blessing that those linear systems theory abstractions fall apart utterly in RF engineering problems, and one has to contend with the fact that all circuits radiate. At least circuits that still contain the magic smoke.
In many ways it's still the same. Transformers use matrix multiplication is their main operation, the underlying matrix multiplication libraries have mostly seen incremental performance improvements over the last two decades or so. Most other ops in eg. core PyTorch are implemented using C++ templates and are mostly familiar to a 2008 C++ programmer. Most of my work is largely C++/Python/Cython as it has been the last 1-2 decades. Sure, the machine learning models have changed, but those are relatively easy to pick up.
I understand the desire to grow your own food and bake your own bread, as a response to the onerous, distressing complexity of the systems we live inside, but you have to accept the cost of that being more work and less connection.
Not to mention platforms like the one we develop makes deploying free software based self-hosted solutions push button, so there really isn't any excuse for sticking to the faceless "crowdware" providers.
Those are not alternatives though. It most certainly does mean more work, and even something as good as achieving mastery & empowerment in this area of your life has opportunity cost that might not be worth it for all.
Which isn't to say I think I should have been a front end webdev chasing after the next new shiney every 3-6 months so I felt like I had my pulse right on the bleeding edge of new technology.
But I use a Jetbrains IDE now quite a bit to write code when I used to be a vi/vim user.
The amount of quality variation that we are willing to accept in our houses is much greater than what we are willing to accept in an automobile. The quality of the automobile is BECAUSE we make millions of the same car over and over again.
I suppose your point is even more valid if we switch to planes. But I'd counter by comparing the levels of regulation between planes and apps. Houses vs apps feels like a fairer comparison on that score.
With software would you expect better quality from an operating system that was one of 50 options each with 100 million of users or something that was one of 5,000,000 options each with 5,000 users? If operating system is an odd corner case, then substitute "Library to Handle Timezones" or something else.
Well it depends on the alternative. If you had to choose between Linux and TempleOS you'd probably get fewer bugs and the ability to do more actual work with Linux. If you had to choose between Windows and TempleOS, you'd probably be able to get more work done with Windows. If you had to choose between MacOS and TempleOS, MacOS would probably let you do more of whatever you were trying to accomplish than TempleOS. Yet TempleOS is only used by a small number of people and only has the resources that you'd expect from something that very few people use.
Now if you are saying that the alternative is to just not use software until it is "mature" you can definitely go back to writing your drafts with pencil and then typing it in a typewriter, but you probably don't actually believe that since you seem to find greater value in using the Internet and software for communication instead of the postal service.
I'm definitely not saying that, right? Hopefully OP conveys what I'm saying.
> If you had to choose between Windows and TempleOS, you'd probably be able to get more work done with Windows.
If you bought a stock and the price climbed up 20% for 19 years before falling 100% in the 20th, do you care that the stock was doing very well for a long time? If you can do more with Windows and get hit by a virus that steals all your bitcoin, TemplateOS probably starts looking quite good at that moment. So it's not a quantitative argument for me of "which side lets me do more work." There are qualitative, almost spiritual questions of "what is this work _for_?" and "what sort of lifestyle can I live with?"
I guess that explains why things like modern refrigerators are so much more reliable and durable than the ones that were made 20 years ago. /s
By that reckoning, modern cars should be just about perfect, modulo certain modern expectations like not emitting greenhouse gases?
The reliability of a modern mass produced automobile is incredible. If a software company could produce software with a few defects as a modern automobile they would rule the world.
Yep, guess which software shows up as a toy CTF challenge for the weekend? Just because you can understand how something works doesn’t mean it’s secure.
* Starting from Lua which seems to have a decent security story;
* Changing a few lines of _safe_ Lua for yourself without introducing new buffer overflows and so on;
* and limiting the reach of those changes to a few thousand people _at most_. (99% of forks won't have even that, thanks to the tyranny of the power law.)
Your comment is very much something I think about. I don't think it's as cut and dried as you make it sound. It seems worth exploring. It seems analogous to doing controlled burns every year to avoid humongous wildfires.
> My first resolution is just to bring less software into my life. It is still early days, we don't really understand computers yet.
While philosophically kind-of true, this approach - especially for things to come - will get you quickly lost in the modern "software-eaten" World, IMHO.
https://spectra.video/w/a1dvx7y6gy1k9pnqDjQBoD (PeerTube)
https://archive.org/details/freewheeling (Internet Archive)
If oversimplifications are being used to prove a point, the argument becomes weak.
I actually read it some months ago, because I'm interested in the smol net, and I use and like the Gemini protocol quite a lot.
Unfortunately this post rants against perceived software obesity quite unreflectedly.
https://pavelfatin.com/typing-with-pleasure/
which shows Gvim on Windows with a maximum latency of 1.2ms - much faster than 30ms on the vintage Apple //e or TI 99/4. Even Eclipse, which usually feels slow to me, came in at a max of 20.8ms. (1.2ms seems very fast to me as I would expect ~2ms of average frame latency even on a 240Hz monitor?)
Which study is correct? Are both of them measuring touch-to-display latency?
It's also worth noting that those vintage 8-bit microcomputers typically used CRT TV monitors at 30Hz, while modern monitors often run at 60Hz or 120Hz or more (possibly with asynchronous refresh), so they will have lower frame latency.
While I haven't tested it myself, I believe newer iPad/Apple Pencil 2 combinations have improved their input latency (they claim 9ms but I'm not sure if that's actually end-to-end touch-to-display latency in something like Notes or Procreate.)
With helpful conclusion I don't mean just stating the facts or comparing transistors or input latency with network latency. As if developers stopped caring and created crappy software on purpose.
The post compares an Apple 2e, which is a single-tasking OS that just displays the pressed key in the basic interpreter on the screen, and modern devices, where it is not always clear, what kind of app or setup is being used. But we know, that it's plenty of layers of GUI and OS code, that most people don't want to miss. Not to mention, that mot of the higher input lag is not detectable by humans in normal work conditions.
Yes, there were years, were CPU performance couldn't keep up with added features, like immediate spell checking. I used computers through all those years and know this first-hand.
And I never dismissed the importance of input lag. I pointed out the oversimplification to support the main argument of the linked post, which suffers from this as a result.
You can do an experiment for yourself along these lines. A few years ago, I pulled out an old laptop that had Gnome 2.x installed as part of an Ubuntu release from circa 2009. In every respect, the hardware from this machine (which itself had been a budget laptop when it was purchased in 2006) was worse than the hardware I was using in my daily life. I was struck (almost startled), however, by the difference in how immediately it responded to my input compared to my daily driver at the time—to the point that it distracted me from the original reason I booted it up in the first place.
A system capable of running Gnome 2.x is no pre-Mac, pre-multitasking system. In fact, it has all the capabilities/affordances that you'd expect and need from systems today. So your characterization is less than kosher (basically a motte-and-bailey).
You're missing the main point: you're just assuming that we must trade those features for improved latency, but this is just not true. The properties he measured are a result of particular architectural and abstraction choices, but other choices could be made that don't necessarily require such sacrifices. For instance, the exokernel.
Unfortunately in IT you always trade one set of problems for another. And clean architectures have to be watered down with time to stay practical.
Nobody is smart enough to predict all pros and cons accurately. We're always smarter after the fact. When we have finished a transition and gained some experience with the new technology. But then it's mostly too late to go back.
On top of that, computing is always a moving target. Now you have to target highly mobile devices with small batteries traveling at high speed in metal tubes connecting to unreliable networks. While more or less related to keyboard input lag, depending on where the action should be registered, you have to be careful where you spend your development resources.
That's why I think this is an oversimplification. True in its deepest form, but neglecting reality.
In another comment[1], I called your earlier characterization a motte-and-bailey[2]. I'd wager it was probably not deliberate in that case. I have to think, though, that you're at least aware of how intellectually dishonest this move is.
Compare like for like. The existence of my phone, running a completely different system and set of applications, has _no_ bearing on how responsive to input an entirely separate machine in a traditional laptop/desktop form factor is or explain why the state of things should have degraded over the last ~10–20 years.
1. <https://news.ycombinator.com/item?id=36115622>
2. <https://en.wikipedia.org/wiki/Motte-and-bailey_argument>
I don't understand this at all (along with several other sentences in your comments).
(I'm the author of OP.)