This really reminds me of what Plan 9 was aiming for — breaking out of the 'box' by making everything a file, using per-process namespaces, and cleanly exposing system and network resources with proper permissions. It had that same idea: your environment shouldn't be a prison, it should be a flexible, composable space. (https://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs) (https://fqa.9front.org/fqa0.html)
Yes, but it also removes a lot of footguns. Access to resources (ie. paths mostly) is controlled almost entirely by the parent process, which makes access controls highly pluggable and flexible.
The real problem is Plan9 never really had a lot of attention put on the things that make having a sane security policy good. Factotum seems, at best, to be bolted on after the fact.
It literally was, it didn't exist until the 4th edition of Plan9. That isn't to say it isn't a good idea (or implementation), but security is very clearly not a primary concern in Plan9.
That paper is about factotum which was introduced in 4th edition, like I said. Regardless, I'm more talking about the fact that transport encryption still isn't used ubiquitously to my knowledge.
> That paper is about factotum which was introduced in 4th edition, like I said.
Which describes that yes, there was security in Plan 9 prior to Factotum, just that it wasn't good enough.
> Regardless, I'm more talking about the fact that transport encryption still isn't used ubiquitously to my knowledge.
It certainly is. You get SSL/TLS for free on Plan 9 as its a service. You dont mess with security code and instead use tlssrv(8). See https://man.9front.org/8/tlssrv
Yes, you would eventually be capable of sharing GPU power, devices, audio, anything. Imagine all your machine´s idle power available to others. Right now your GPU is barely being used.
I think OpenDoc was meant to be this kind of thing as well. I mean the breaking out of the box part, you can read what other programs write kinda thing.
plan9 sucks and people who think it's cool just admit their own bad taste. Unix haters handbook made the case against Plan9 even before anyone thought of the stupid idea.
Nice take. You sound like the kind of person who only ever reads other peoples opinions and then parrots them creating the illusion that you have knowledge. Meanwhile you never bothered to boot the OS or see why people like it. It's actually pretty fucking amazing but that's okay, you are obviously too smart to use it since you read Unix Haters. Have fun with creaky old Unix.
It's definitely unpleasant when opinions you hear seem like they might be parroted, but at least it's in good faith. I find it frustrating to hear argumentation that shames, rather than attempt to correct or add anything.
Just this past week I've been working on a toy/experimental web DSL [0] that uses dynamically loaded shared libraries as middleware that pass per request arena-allocated Jansson json objects between steps in a pipeline. It's extensible in that new middleware can be created. Influenced by bash and OCaml/F#, here is some kind of demo of the syntax:
oh hey Will! long time no see lol, it's been ages. small world.
i think this is on a good track! i like that it's designed to be extensible while still keeping some amount of structure, and that the DSL makes things very compact. how are those filters implemented? are you spawning a shell to run jq or are you interpreting in-process or something like that?
in general i'd love to see a bunch more DSLs, i think using general-purpose languages for everything is most of the time not actually helpful (cc https://jyn.dev/constrained-languages-are-easier-to-optimize...). i have some vague thoughts about how to make interop between DSLs and the host language easier but i need to think about them some more.
I've wanted to do just this. I've used libmicrohttpd, and... it's not my favorite. But if you're going to do it in C then libmicrohttpd is probably the best API to use. You get bonus points for using jq :)
If you're also using jq you might as well ditch Jansson and use jq's `jv` API. I highly recommend it.
One thing that sold me on Jansson is that you can set custom allocators which work very well with the request arena. Once those allocators are set the json objects continue to use the arena even when used in middleware. This makes memory management a cinch!
From what I can tell jq’s C lib doesn’t yet expose a way to set custom allocators.
Oh right, no, jq has a custom out-of-memory handler. But it should be trivial to extend src/jv_alloc.[ch] to let you set not just a custom nomem handler but also a custom allocator, and then you can use thread-locals in your allocator.
The key point of the article is "your data is trapped inside your program", i.e. data models can't generally be shared between programs. One thing that has improved my life has been using apache arrow as a way to decrease the friction of sharing data between different executables. With arrow (and it's file based compressed cousin parquet), the idea is that once data is produced it never needs to be deserialized again as you would with json or avro.
Sharing data is just totally undefined for the overwhelming majority of all data in the world, because there just isn't any standard for the format the data should be in.
Data models are even harder, because whereas data is produced by the world, and data formats are produced to intentionally be somewhat generalized, data models are generally produced in the context of a piece of software.
How are you handling data update? Last I checked, Arrow and similar systems had extremely poor performance if you needed to mutate data at even modest rates.
you create an output arrow table and populate it with rows. but w/r/t the original idea, arrow data always comes with a schema and is efficient and compact, so it makes it easier to share data between different programs.
Computers are boxes, therefore all software is literally (and figuratively) "in a box", are they not? This might seem like a frivolous jest, but it is not. For example, the author points out that clojure, java, kotlin can interoperate, but notes they are stuck in the same jvm 'box'. This generalizes and recurses, so you must find a specific place to stop, and then motivate that.
One likely place to stop is at "processes". But this must be motivated since ultimately processes are as synthetic a convention as a language thread - it's just that the runtime is called a "kernel" instead of a "runtime".
Ultimately I think what the author is getting at is a data problem, not a code problem. Or rather, it's yearning toward a world where data and code are strongly decoupled, conventions around data are standardized, so that processes written in disparate tooling can successfully interoperate locally. However I doubt there is much appetite for a "model of everything" registry (such things have been tried, and failed, in the past). That said we might take another stab at this, since LLMs make likely that software will become more dynamic in terms of translating data structures at runtime such that one program can examine a peer program and its data structures, and how to map them to local data structures, thus achieving interoperability without a centralized agreement on representation.
Having used SOAP and GraphQL, I really disagree with this characterization.
The problem I have seen at most organizations is they simply want their APIs to reflect their database schema, even if its not a good or useful idea. They throw junk over the wall.
They carry this practice over from REST to GraphQL and of course its horrible, its not a good way to use the technology.
Now organizations that understand GraphQL allows you to create a data schema unbound by its sources, they leverage GraphQL quite well, and its very pleasant to use. Unfortunately not enough organizations do this, or do this well.
SOAP was and is still simply a bad protocol and had tons of issues ranging from security to payload size to parsing issues between different clients
There is nothing you can do with GraphQL you couldn't do with soap or vice versa. They're equivalent protocols. Maybe people got better at API design in the middle but that's not related to the protocol
The whole point is to decouple the two. The gql queries are written for purpose, they’re not suppose to care about the data sources. This becomes even more important when a single query may grab data from more than a single source.
originally i had them both in one article but it was getting to be really quite long and i am still thinking through what i want to say in the follow-up
A bit off-topic, but in a shell pipeline like that, if you put your pipe chars at the end of the line you don't need backslashes and you can comment out bits of the pipe for devving.
This little change was mind-blowing for me so I always try to share when I can :)
There's an additional factor on the phone and increasingly the computer: mutual distrust.
All the apps are carefully sandboxed, because left unattended they will steal your data. The new category of AI largely works by sending your data to a server in the US where it can be surveilled. It would be great to have interoperability but first the user has to have confidence that it's not going to be weaponized against them.
The "in a box" phenomenon is very tangible to me when I am using the iOS Shortcuts feature. Its capabilities are so powerful, but its utility will always have a ceiling because app publishers' interests are generally not aligned with exposing a Shortcuts API to users. The more easily a user can automate and script the tasks that they use your app for, the less engagement their metrics will show.
It is worse on phones, but most desktop computing feels like this too, at least when you're not at a command line. I've been trying to puzzle out what I'd like computing to look like instead, but I don't get far beyond a concept of "objects" and "actions" as fundamental building blocks. How to actually expose this... yeah, it's tough.
COM, buddy! Publish your interface with a known UUID, anyone can claim support for your interface in the system registry, there's a standard way to initialize libraries and pull objects supporting the interface out of it, so now you can pull other peoples' applications into yours, without knowing anything about their software. This is used _all over the place_ on Windows, for things like arbitrary cross-application embedding and context menu support... at least before we realized we miiiight want to have some notion of "computer security".
have you seen https://pharo.org/ by chance? it's a smalltalk IDE built in smalltalk, which means that the whole thing is editable at runtime. it's hard to describe before you see it, https://pharo.org/features has some demos.
I tried pharo, its an interesting thing but I don't see it as a particularly practical solution.
Yes its editable in runtime, but not the whole thing and not reliably so: I remember changing some low level array methods that broke the whole image.
Even in pharo your data has to be organised in some way and if you add new code to existing image you have to know how to reach the data you need.
And the biggest downside to productivity and stability is it doesn't have a type system and every action can fail because the receiver doesn't support a particular message.
There's a tension between the bash economy which is too simple but pleasantly terse and the powershell economy which has a richer data structure but feels painfully verbose.
Clear APIs and better semantics. Another post points out how gross mistrust gets in the way but there are alao little mistrusts. For instance if there was an API to compare restaurant menus and order things through an agent that moves power up to the agent who can influence who gets the business.
That is, I'm not afraid of being branded subversive because I like to eat strange foreign foods, I'm afraid that I'm going to get the worst pizza in town instead of the best pizza in town because somebody paid off Apple or because Google or Facebook can put up a tollbooth in front of new entrants or that they might not be interested in working with or being fair with independent restaurants because private equity has bought most of them up.
Zawinski's Law, when taken literally, argues that programs all eventually need to be communicated with by people and other programs using a generic protocol and without using program-specific or domain-specific libraries to do so.
Unix shells (local), I'll add in HTTP (remote), and Email (remote and asynchronous) are the only forms that are ubiquitous, precisely because they enforce no structure for the payload. The structured alternatives are only popular in specific domains because they create their own ecosystem. As long as input can clearly be parsed, which goes hand in hand with being human-readable as long as you're not trying to be too efficient, you get schema implicitly transmitted out of band (by having output that you can visually inspect) and interoperability for anything that can read and write text.
I'd be interested in other directions this might go, but I remain skeptical of anything that will introduce and enforce a new paradigm that requires adding complexity to programs to accommodate it.
- Powershell and nushell have an "interior" design (within a process/VM)
- while POSIX shell, bash, OSH, and YSH have an "exterior" design (between processes)
And I'll claim that the exterior design is the glue you need in large, heterogeneous systems. Making the shell "interior" and "easy to use" is at odds with the role as essential glue -- it creates pressure for something else to be used instead.
The lowest common denominator between a PowerShell, Elvish, Rash, and nushell script is a Bourne shell script (and eventually a YSH script)
I also claim this isn't theoretical -- there are probably a non-trivial number of bash scripts gluing together PowerShell and other shells. IMO it's better to have 1 type of glue, than 2 or more types, which I call "Unix sludge / Cloud sludge".
---
And I disagree with this part, which references protocol buffers:
> how do you get a schema? well, you establish in-band communication. RPC is ...
Protocol buffers transmit schemas OUT of band, usually via a monorepo. The data sent over the wire can't be interpreted without the schema information compiled into the binary.
The monorepo works well enough within Google, but even there it failed to scale (probably around the time of "Alphabet", e.g. Waymo and other companies)
Also, protobufs are biased toward C++; users of other languages feel this friction to varying degrees. In general, they'd rather use .gob for Go, pickle for Python, JSON for JS, Java serialization, etc.
> And I'll claim that the exterior design is the glue you need in large, heterogeneous systems.
Yes, but the specific format (and the way that the data transmission between processes and other pieces of the system is working) for the "exterior" design is an effect of the operating system. A different operating system might have a different way.
Whether it is interior or exterior, there is going to be different data types and other differences between structures, used in different ways. (One example of a difference which does not merely involve the interpretation of byte sequences, is transmissions of capabilities in systems that use capability-based security.)
I think that it is helpful to have a combination of interior and exterior functions, although most things will be exterior. However, for some things it is more helpful to do them internally within a process, for various reasons (including efficiency, requirements according to the specific operating system in use, security, and others).
> IMO it's better to have 1 type of glue, than 2 or more types
It might depend on the specific use. For some uses, it might be necessary to do it differently.
I also think that it is a mistake to assume one character set or one operating system for everything, though. However, even then, you probably wouldn't need more than one type of glue for many things, even if this "type of glue" is not the same as you would use in a different system.
> The data sent over the wire can't be interpreted without the schema information compiled into the binary.
A program is unlikely to be able to do much with data that the program is not designed to handle, regardless of how the schema is tramsmitted, so in-band communication of the schema probably wouldn't help much.
However, there can be multiple levels; e.g. with DER format, a program that does not understand the specific schema would still be able to read most of the values (with some exceptions if implicit types are used), sequences, etc, but does not know what any of that stuff means.
(I use DER format in some programs and formats that I do, because I think it is better than JSON in many ways.)
These issues are also things that my own ideas of operating system design would hopefully improve some of this. The command shell has a combination and data format would hopefully be more helpful.
the specific format ... for the "exterior" design is an effect of the operating system. A different operating system might have a different way.
I'd say it's both the operating system and the hardware. The OS tends to follow the hardware (network, disk), and there's only one kind of hardware that I know of: that which traffics in bytes, or blocks of bytes.
You can (and should) build formats on top of that, like UTF-8 and JSON, but at bottom it's bytes. Which is of course not true of the "interior" designs -- those are more like in-memory data structures created by the .NET VM, and invisible to the outside world, without serialization.
It might depend on the specific use.
I'll have to write this out fully later, but the argument is that using 2 types of glue is strictly worse than using 1, because you create a combinatorial explosions of code. You also create more software interfaces, and interfaces are where bugs tend to happen.
More code and more interfaces leads to more bugs. One type of glue is better!
Also, the glue should be dynamically typed. Because shell is for gluing together say Rust and Go, which have wildly different type systems. It's better to have 2 type systems than 3. If you have 3, then you need more glue.
Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.
—Zawinski's Law of Software Envelopment
Its THE Zawinski of XEmacs so maybe not the best example.
Emacs has it right though, more right than wrong, they just, as a community, hate humans.
Data and data collections should have app-tributes, apps shouldn't have data.
The problem with most operating systems is that they need to model space time and minds as first class but they don't.
I've been using my own personal OS for years now that I call imtropy, once your abstraction maps to reality everything becomes easier to reason about.
The simple fact is most people and programmers are stuck in logic and rationality when they should think a layer deeper, coherence is all that matters.
Yes, including about Emacs users "hating humans". I use Emacs, and I'm very fond of humans. Plus my reading of the Emacs community is that there's loads of interesting and respectful people. Where's the hating humans bit?
It's a highly-dimensional box, isn't it? This age-old tension between interface standards and business/innovation speed.
Everything is a file is a good example of a fundamental and major standard that lasts till today and even though IPC kind of didn't make it all the way, I think about the core UNIX philosophy and Alan Kay's thoughts around as very, very accurate in terms of where we've ended up and what the likely ways out look like to me.
> Your data is trapped inside the box that is your program.
Well if we're going to get philosophical about it, "I" happen to be ~30 trillion cooperating boxes known as cells, so say nothing of all the other enclosed, enclosing, or cross-connecting boundaries one might draw.
Keeping the data/molecules/etc. "hostage" is probably to my benefit, as opposed to an, er, Evangelion ending.
and always, always, always, you are at the mercy of the program author.
Not if it is open source, and you're willing to put some effort into it. When I write code I like to think of it more as using a computer effectively instead of programming.
Yes, interoperability, extensibility, composability and the tyranny of program author is a problem. JVM with runtime-loading of classes and it's once popular beans standard is one of closest approximations, known to me, of the most general "local" solution.
Yes, it's cumbersome and hacky and still limited. The beans idea lost popularity and mindshare.
Ever heard the cliche about “designing a game with no rules”? Seems pretty similar to “structured data with no boxes.” I think data boxes as defined by the author are not inherently bad. Optimization and specialization go hand-in-hand.
The solution is so simple as to be boring: keep your stuff in files on the filesystem.
Your data is in a box. SaaS put your data in other people’s servers. Phones put your data in a hidden store because app APIs only let developers do it that way - and Apple decided people don’t want filesystems.
But this is all reverting back: you can download your data thanks to GDPR, and phones have file browsers now.
Every computer has a filesystem. Even ones that pretend not to. It’s the common-denominator of computing.
Am I the only one who finds the Sam Altman-esque 'all lowercase except for proper nouns like Linux but not including the pronoun i' writing style unbearable to read?
"Please don't complain about tangential annoyances—e.g. article or website formats, name collisions, or back-button breakage. They're too common to be interesting."
(Of course annoyances are annoying, but they're also distracting, and they tend to get stuck at the top of threads, choking out more interesting conversation.)
I definitely find it difficult, cognitively, for long-form writing. It's also the second time recently I've seen all-lowercase blog-post-length content, after previously having never seen it, so I wonder if something is happening culturally to pull text-message style formatting up into the rank of published content.
Yeah, I suspect that's the intention. There's a definitely a cultural break. To me, lowercase creates a casual tone in texts/chat. But in long form, especially published (i.e. purposefully displayed to an audience), it sends me a tone of disinterest or laziness at worst; or at best, simple innocent ignorance/mistakenness (like misspelling). Clearly neither is the case here though.
oh yeah i definitely agree! the tone communication can be useful but in longform writing it gets very grating and confusing/distracting. it's also just more social engineering to pretend to be authentic when one is clearly not.
i prefer this type of writing for comedy generally
I wonder if unconventional writing styles are becoming the signal for deliberate content. If text is too polished– or even using certain punctuation– can lead to readers questioning whether AI assisted in the creation of the text.
It looks like this particular blog previously used conventional capitalization from 2017 to late 2023. The first post in this style appears to hint at a kind of shift in identity of the author, so perhaps, in this instance it is more a signal of personal expression or tribalism than non-AI-ness. Then again, we may see the line between the two continue to blur.
I waste brain cycles correcting the author's formatting mistakes while simultaneously trying to understand the meaning. Thus I read slower, but not the productive kind of slow reading—I am not contemplating the concepts more deeply. I am slowed down by a lazy lack of editing, for no gain.
Not sure what it has to do with Sam Altman though.
What I find pretentious is the legion of commenters who can't find anything better to comment on and instead pretend they're smart by nitpicking some stylistic choice in the most low-effort way possible.
Classic case of "you're pretentious", "no, you're pretentious". It's exhausting how often we reach for the word "pretentious" when we have bitter feelings about one person's opinion of another person or their work.
I just used it because he did. My real feeling was exhaustion. More of those comments than comments about the subject matter of the post. Like going to a swimming meet as a pro and finding it full of kids instead.
It's cool if you're on desktop Slack or Messenger or something between friends, but making a conscious choice to go into your phone's settings and turn capitalization off for everything you do is a bit weird and over the top.
Seems to be a trend though now to do it everywhere in public. I've seen the htmx author do that and the guy who wrote the second forked version of opencode.
I'd closed the tab by the end of the first sentence. If the author can't be bothered, then neither can I. I tend to find people who do this have a superiority complex, they think they're so much better than everyone else that they're justified in offloading their own tiny cognitive load on to everybody else.
The author put a lot of effort into actually writing the thing, and correctly capitalized quotes, which clearly indicates a stylistic choice. You aren't willing to read text that isn't written in your preferred style, but you believe it's the author who has a superiority complex?
So, you barely read one sentence, then went to the comments, read an entire thread, and took the time to post about how the author probably thinks they are superior to you?
I strongly recommend rethinking that approach. You ascribed intentions to the author and then spent more time getting upset about them than you did interacting with the content.
There are actually interesting points in that text, yet here we are getting fussy about the author's supposed lack of decorum. That's really disappointing to me.
Funnily enough, I didn't read an entire thread, I read that one comment and posted an agreement to it. I'm not overly fussed if you are disappointed in me.
I do it a lot, do me a favor and don't attribute it to Sam Altman since some of us have been doing this for a long time. If you don't like it, you don't have to read it, but you also don't need to be patronizing and close-minded about how others choose to express themselves.
I think writing like this is disrespectful to your audience since they have to put in extra effort to parse your text. If you choose to express yourself like that, fine, but it's not patronizing to point this out.
i tend to draft everything lowercase, and then go back and uppercase things depending on how much of a formal vibe i'm going for. capitalization rarely helps me formulate an idea, and so my writing often splits into phases: (1) formulation, (2) polish.
also, it's worth noting that proper capitalization does not automatically yield text worth reading. from that perspective, i like lower case text as a form of rebellion against the artifice of rules; any rebellion against particular aesthetics is fair game in my book. more generally, i'm skeptical of process advocacy in cases where the process seems to be done for its own sake.
on the flip side, good grammar helps me parse sentences, so i do sympathize with arguments in its favor.
I find all lowercase messes with my parser, and is fustrating to read. I think I may treat sentences as a single unit, and use the capitilization to detect the boundaries. Without it I find bouncing to/from sentences slower (which can happen if a latter sentence/paragraph adds more context, and I want to revisit the previous idea).
Interestingly your semi-colons stand out much stronger than the periods for me.
i like it. maybe because i grew up with phones and texting but having perfect punctuation reads very formal to me, and if im reading a personal blog post i assume its casual reading. if i get a text that ends in a period mark, i assume the person typing it is MAD. i also just like lowercase glyphs more they look more pleasing to me
I agree. A quick search tells me the practice was started for legibility in hand-written manuscripts [1], or for that and also to emphasize the importance of the writer (seems egotistical to me :)) [2], or those reasons and also to help distinguish English from other languages but we don't really know [3].
for reasons I don't (want to) understand, lowercase i and psychopathic credit stealing prompting seem to yield best results for llms... e.g. "i want xyz how do i do it, ok please do so", not "I'm trying to do xyz. Could you guide me through?"
i hate this writing style so much. i have to do extra work fighting autocorrect to make it seem like i just rolled out of bed and typed it out on my phone. i am so smart, see, i don't care about Big Establishment Grammar, my ideas are so good it will pierce through
your brain is only fighting it because it's expecting capitalization, the same way parens put new lisp users off and javascript has difficulty shedding its semicolons; it's all just struggling to let go of something that was drilled into you.
Sounds like the author got called out for not capitalizing the start of her sentences[1] and decided that, if HN readers want capital letters, they will get them.
Which is funny because if you engage Reader Mode in the browser, everything becomes proper except sentences, which still start with lowercased letters for some reason. Names are still properly capitalized. It's truly bizarre
Communication has not been merely a matter of personal habit — it follows commonly accepted standards for exchanging information within a group. Ignoring these conventions risks your message being unread, unheard, or misunderstood.
That said, it seems possible the author is intentionally addressing a specific subgroup that has agreed upon a different set of communication rules.
Proposed Symbolics guidelines for mail messages
BSG 4/11/84
>It is impermissible to use the term "EMAIL".
>It is customary to attack the someone by including his or her message, indented (unless you are using MM), and replying point by point, as someone debating someone they are watching on TV, or hearing on the radio.
>It is considered artful to append many messages on a subject, leaving only the most inflammatory lines from each, and reply to all in one swift blow. The choice of lines to support your argument can make or break your case.
>Mail should be at least a mixture of upper and lower case. Devising your own font (Devanagari, pinhead graphics, etc.) and using it in the mail is a good entertainment tactic, as is finding some way to use existing obscure fonts.
>Sending the mail from Unix is frowned upon (although this has gotten much better).
>Replying to one's own message is a rarely-exposed technique for switching positions once you have thought about something only after sending mail.
>You get 3 opportunities to advertise your Rock band, no more.
>Idiosyncratic indentations, double-spacing, capitalization, etc., while stamps of individuality, leave one an easy target for parody.
>The entire life, times, collected works, expressions, and modalities of Zippy the Pinhead are a common ground for much of the metaphor, rhetoric, and invective which pass daily through the mail. An occasional parenthetical "yow" CORRECTLY USED will endear one to the senior systems staff. So will puns and other remarks addressed directly to the point.
>Including a destination in the CC list that will cause the recipients' mailer to blow out is a good way to stifle dissent.
>When replying, it is often possible to cleverly edit the original message in such a way as to subtly alter its meaning or tone to your advantage while appearing that you are taking pains to preserve the author's intent. As a bonus, it will seem that your superior intellect is cutting through all the excess verbiage to the very heart of the matter.
>Keeping a secret "Hall Of Flame" file of people's mail indiscretions, or copying messages to private mailing lists for subsequent derision, is good fun and also a worthwhile investment in case you need to blackmail the senders later.
This really reminds me of what Plan 9 was aiming for — breaking out of the 'box' by making everything a file, using per-process namespaces, and cleanly exposing system and network resources with proper permissions. It had that same idea: your environment shouldn't be a prison, it should be a flexible, composable space. (https://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs) (https://fqa.9front.org/fqa0.html)
Cool idea. Seems like it would require an entirely new philosophy vs our present one on security.
Yes, but it also removes a lot of footguns. Access to resources (ie. paths mostly) is controlled almost entirely by the parent process, which makes access controls highly pluggable and flexible.
The real problem is Plan9 never really had a lot of attention put on the things that make having a sane security policy good. Factotum seems, at best, to be bolted on after the fact.
> Factotum seems, at best, to be bolted on after the fact.
What gives you this impression?
It literally was, it didn't exist until the 4th edition of Plan9. That isn't to say it isn't a good idea (or implementation), but security is very clearly not a primary concern in Plan9.
> but security is very clearly not a primary concern in Plan9.
That is a myth that keeps getting propagated. https://plan9.io/sys/doc/auth.html
That paper is about factotum which was introduced in 4th edition, like I said. Regardless, I'm more talking about the fact that transport encryption still isn't used ubiquitously to my knowledge.
> That paper is about factotum which was introduced in 4th edition, like I said.
Which describes that yes, there was security in Plan 9 prior to Factotum, just that it wasn't good enough.
> Regardless, I'm more talking about the fact that transport encryption still isn't used ubiquitously to my knowledge.
It certainly is. You get SSL/TLS for free on Plan 9 as its a service. You dont mess with security code and instead use tlssrv(8). See https://man.9front.org/8/tlssrv
I didn't see there wasn't, I said it wasn't a priority.
I stand corrected on tlssrv
Yes, you would eventually be capable of sharing GPU power, devices, audio, anything. Imagine all your machine´s idle power available to others. Right now your GPU is barely being used.
I think OpenDoc was meant to be this kind of thing as well. I mean the breaking out of the box part, you can read what other programs write kinda thing.
What an awesome username!
plan9 sucks and people who think it's cool just admit their own bad taste. Unix haters handbook made the case against Plan9 even before anyone thought of the stupid idea.
Nice take. You sound like the kind of person who only ever reads other peoples opinions and then parrots them creating the illusion that you have knowledge. Meanwhile you never bothered to boot the OS or see why people like it. It's actually pretty fucking amazing but that's okay, you are obviously too smart to use it since you read Unix Haters. Have fun with creaky old Unix.
It's definitely unpleasant when opinions you hear seem like they might be parroted, but at least it's in good faith. I find it frustrating to hear argumentation that shames, rather than attempt to correct or add anything.
Just this past week I've been working on a toy/experimental web DSL [0] that uses dynamically loaded shared libraries as middleware that pass per request arena-allocated Jansson json objects between steps in a pipeline. It's extensible in that new middleware can be created. Influenced by bash and OCaml/F#, here is some kind of demo of the syntax:
I'm generally curious as to how jyn thinks this would fit in to their box-based framework.[0] https://github.com/williamcotton/webpipe
oh hey Will! long time no see lol, it's been ages. small world.
i think this is on a good track! i like that it's designed to be extensible while still keeping some amount of structure, and that the DSL makes things very compact. how are those filters implemented? are you spawning a shell to run jq or are you interpreting in-process or something like that?
in general i'd love to see a bunch more DSLs, i think using general-purpose languages for everything is most of the time not actually helpful (cc https://jyn.dev/constrained-languages-are-easier-to-optimize...). i have some vague thoughts about how to make interop between DSLs and the host language easier but i need to think about them some more.
> how are those filters implemented? are you spawning a shell to run jq or are you interpreting in-process or something like that?
Interpreting in-process. There's a jq C lib, libjq-dev.
I hope you're doing well! I've very much enjoyed your recent blog posts.
I've wanted to do just this. I've used libmicrohttpd, and... it's not my favorite. But if you're going to do it in C then libmicrohttpd is probably the best API to use. You get bonus points for using jq :)
If you're also using jq you might as well ditch Jansson and use jq's `jv` API. I highly recommend it.
One thing that sold me on Jansson is that you can set custom allocators which work very well with the request arena. Once those allocators are set the json objects continue to use the arena even when used in middleware. This makes memory management a cinch!
From what I can tell jq’s C lib doesn’t yet expose a way to set custom allocators.
You can set a custom allocator, but it's global. You could contribute a feature to set thread-local custom allocators -- it'd be quite easy.
Oh right, no, jq has a custom out-of-memory handler. But it should be trivial to extend src/jv_alloc.[ch] to let you set not just a custom nomem handler but also a custom allocator, and then you can use thread-locals in your allocator.
This looks really neat! I typically don't like these DSLs, but this is one I would actually use.
The key point of the article is "your data is trapped inside your program", i.e. data models can't generally be shared between programs. One thing that has improved my life has been using apache arrow as a way to decrease the friction of sharing data between different executables. With arrow (and it's file based compressed cousin parquet), the idea is that once data is produced it never needs to be deserialized again as you would with json or avro.
Data and data models are not the same.
Sharing data is just totally undefined for the overwhelming majority of all data in the world, because there just isn't any standard for the format the data should be in.
Data models are even harder, because whereas data is produced by the world, and data formats are produced to intentionally be somewhat generalized, data models are generally produced in the context of a piece of software.
How are you handling data update? Last I checked, Arrow and similar systems had extremely poor performance if you needed to mutate data at even modest rates.
you create an output arrow table and populate it with rows. but w/r/t the original idea, arrow data always comes with a schema and is efficient and compact, so it makes it easier to share data between different programs.
Computers are boxes, therefore all software is literally (and figuratively) "in a box", are they not? This might seem like a frivolous jest, but it is not. For example, the author points out that clojure, java, kotlin can interoperate, but notes they are stuck in the same jvm 'box'. This generalizes and recurses, so you must find a specific place to stop, and then motivate that.
One likely place to stop is at "processes". But this must be motivated since ultimately processes are as synthetic a convention as a language thread - it's just that the runtime is called a "kernel" instead of a "runtime".
Ultimately I think what the author is getting at is a data problem, not a code problem. Or rather, it's yearning toward a world where data and code are strongly decoupled, conventions around data are standardized, so that processes written in disparate tooling can successfully interoperate locally. However I doubt there is much appetite for a "model of everything" registry (such things have been tried, and failed, in the past). That said we might take another stab at this, since LLMs make likely that software will become more dynamic in terms of translating data structures at runtime such that one program can examine a peer program and its data structures, and how to map them to local data structures, thus achieving interoperability without a centralized agreement on representation.
It's not long now until we re-invent SOAP and pretend it's a productivity breakthrough.
This is called GraphQL
Having used SOAP and GraphQL, I really disagree with this characterization.
The problem I have seen at most organizations is they simply want their APIs to reflect their database schema, even if its not a good or useful idea. They throw junk over the wall.
They carry this practice over from REST to GraphQL and of course its horrible, its not a good way to use the technology.
Now organizations that understand GraphQL allows you to create a data schema unbound by its sources, they leverage GraphQL quite well, and its very pleasant to use. Unfortunately not enough organizations do this, or do this well.
SOAP was and is still simply a bad protocol and had tons of issues ranging from security to payload size to parsing issues between different clients
There is nothing you can do with GraphQL you couldn't do with soap or vice versa. They're equivalent protocols. Maybe people got better at API design in the middle but that's not related to the protocol
Why wouldn't you want your database schema to match how you use it?
The whole point is to decouple the two. The gql queries are written for purpose, they’re not suppose to care about the data sources. This becomes even more important when a single query may grab data from more than a single source.
Versioning is big one. Initially you can have them same/similar, but it is important to have that capability over time.
The vocabulary you speak/write every day is a box.
Your brain is a box.
Your body is a box.
/s
I like this post but the whole thing is a tease for an unwritten next article
lol yeah it absolutely is
originally i had them both in one article but it was getting to be really quite long and i am still thinking through what i want to say in the follow-up
A bit off-topic, but in a shell pipeline like that, if you put your pipe chars at the end of the line you don't need backslashes and you can comment out bits of the pipe for devving.
This little change was mind-blowing for me so I always try to share when I can :)
thanks :) i prefer to have the pipes on the new line so it’s more clear how the data flow works, but that’s a cute trick.
I feel this the most on mobile platforms where the phone really should be acting as your agent but instead we're stuck with all these apps.
There's an additional factor on the phone and increasingly the computer: mutual distrust.
All the apps are carefully sandboxed, because left unattended they will steal your data. The new category of AI largely works by sending your data to a server in the US where it can be surveilled. It would be great to have interoperability but first the user has to have confidence that it's not going to be weaponized against them.
The "in a box" phenomenon is very tangible to me when I am using the iOS Shortcuts feature. Its capabilities are so powerful, but its utility will always have a ceiling because app publishers' interests are generally not aligned with exposing a Shortcuts API to users. The more easily a user can automate and script the tasks that they use your app for, the less engagement their metrics will show.
It is worse on phones, but most desktop computing feels like this too, at least when you're not at a command line. I've been trying to puzzle out what I'd like computing to look like instead, but I don't get far beyond a concept of "objects" and "actions" as fundamental building blocks. How to actually expose this... yeah, it's tough.
COM, buddy! Publish your interface with a known UUID, anyone can claim support for your interface in the system registry, there's a standard way to initialize libraries and pull objects supporting the interface out of it, so now you can pull other peoples' applications into yours, without knowing anything about their software. This is used _all over the place_ on Windows, for things like arbitrary cross-application embedding and context menu support... at least before we realized we miiiight want to have some notion of "computer security".
https://learn.microsoft.com/en-us/windows/win32/com/com-tech...
have you seen https://pharo.org/ by chance? it's a smalltalk IDE built in smalltalk, which means that the whole thing is editable at runtime. it's hard to describe before you see it, https://pharo.org/features has some demos.
I tried pharo, its an interesting thing but I don't see it as a particularly practical solution.
Yes its editable in runtime, but not the whole thing and not reliably so: I remember changing some low level array methods that broke the whole image.
Even in pharo your data has to be organised in some way and if you add new code to existing image you have to know how to reach the data you need.
And the biggest downside to productivity and stability is it doesn't have a type system and every action can fail because the receiver doesn't support a particular message.
Doesn't editing "the whole thing" include edits that break stuff?
> data has to be organised in some way
Yes it does.
Smalltalk implementations usually do support live coding "allowing developers to modify and experiment with code while the program is running".
https://www.cincom.com/blog/smalltalk/smalltalk-programming-...
There's a tension between the bash economy which is too simple but pleasantly terse and the powershell economy which has a richer data structure but feels painfully verbose.
interesting. how would you make it better?
Clear APIs and better semantics. Another post points out how gross mistrust gets in the way but there are alao little mistrusts. For instance if there was an API to compare restaurant menus and order things through an agent that moves power up to the agent who can influence who gets the business.
That is, I'm not afraid of being branded subversive because I like to eat strange foreign foods, I'm afraid that I'm going to get the worst pizza in town instead of the best pizza in town because somebody paid off Apple or because Google or Facebook can put up a tollbooth in front of new entrants or that they might not be interested in working with or being fair with independent restaurants because private equity has bought most of them up.
Zawinski's Law, when taken literally, argues that programs all eventually need to be communicated with by people and other programs using a generic protocol and without using program-specific or domain-specific libraries to do so.
Unix shells (local), I'll add in HTTP (remote), and Email (remote and asynchronous) are the only forms that are ubiquitous, precisely because they enforce no structure for the payload. The structured alternatives are only popular in specific domains because they create their own ecosystem. As long as input can clearly be parsed, which goes hand in hand with being human-readable as long as you're not trying to be too efficient, you get schema implicitly transmitted out of band (by having output that you can visually inspect) and interoperability for anything that can read and write text.
I'd be interested in other directions this might go, but I remain skeptical of anything that will introduce and enforce a new paradigm that requires adding complexity to programs to accommodate it.
every object should have its own url
> there is no interop between powershell and nushell
FWIW I wrote a post about this design issue:
Oils Is Exterior-First (Code, Text, and Structured Data) - https://www.oilshell.org/blog/2023/06/ysh-design.html#survey...
That is
- Powershell and nushell have an "interior" design (within a process/VM)
- while POSIX shell, bash, OSH, and YSH have an "exterior" design (between processes)
And I'll claim that the exterior design is the glue you need in large, heterogeneous systems. Making the shell "interior" and "easy to use" is at odds with the role as essential glue -- it creates pressure for something else to be used instead.
---
Maybe the more pithy statement is here:
A Sketch of the Biggest Idea in Software Architecture - https://www.oilshell.org/blog/2022/03/backlog-arch.html
The lowest common denominator between a PowerShell, Elvish, Rash, and nushell script is a Bourne shell script (and eventually a YSH script)
I also claim this isn't theoretical -- there are probably a non-trivial number of bash scripts gluing together PowerShell and other shells. IMO it's better to have 1 type of glue, than 2 or more types, which I call "Unix sludge / Cloud sludge".
---
And I disagree with this part, which references protocol buffers:
> how do you get a schema? well, you establish in-band communication. RPC is ...
Protocol buffers transmit schemas OUT of band, usually via a monorepo. The data sent over the wire can't be interpreted without the schema information compiled into the binary.
The monorepo works well enough within Google, but even there it failed to scale (probably around the time of "Alphabet", e.g. Waymo and other companies)
Also, protobufs are biased toward C++; users of other languages feel this friction to varying degrees. In general, they'd rather use .gob for Go, pickle for Python, JSON for JS, Java serialization, etc.
> And I'll claim that the exterior design is the glue you need in large, heterogeneous systems.
Yes, but the specific format (and the way that the data transmission between processes and other pieces of the system is working) for the "exterior" design is an effect of the operating system. A different operating system might have a different way.
Whether it is interior or exterior, there is going to be different data types and other differences between structures, used in different ways. (One example of a difference which does not merely involve the interpretation of byte sequences, is transmissions of capabilities in systems that use capability-based security.)
I think that it is helpful to have a combination of interior and exterior functions, although most things will be exterior. However, for some things it is more helpful to do them internally within a process, for various reasons (including efficiency, requirements according to the specific operating system in use, security, and others).
> IMO it's better to have 1 type of glue, than 2 or more types
It might depend on the specific use. For some uses, it might be necessary to do it differently.
I also think that it is a mistake to assume one character set or one operating system for everything, though. However, even then, you probably wouldn't need more than one type of glue for many things, even if this "type of glue" is not the same as you would use in a different system.
> The data sent over the wire can't be interpreted without the schema information compiled into the binary.
A program is unlikely to be able to do much with data that the program is not designed to handle, regardless of how the schema is tramsmitted, so in-band communication of the schema probably wouldn't help much.
However, there can be multiple levels; e.g. with DER format, a program that does not understand the specific schema would still be able to read most of the values (with some exceptions if implicit types are used), sequences, etc, but does not know what any of that stuff means.
(I use DER format in some programs and formats that I do, because I think it is better than JSON in many ways.)
These issues are also things that my own ideas of operating system design would hopefully improve some of this. The command shell has a combination and data format would hopefully be more helpful.
the specific format ... for the "exterior" design is an effect of the operating system. A different operating system might have a different way.
I'd say it's both the operating system and the hardware. The OS tends to follow the hardware (network, disk), and there's only one kind of hardware that I know of: that which traffics in bytes, or blocks of bytes.
You can (and should) build formats on top of that, like UTF-8 and JSON, but at bottom it's bytes. Which is of course not true of the "interior" designs -- those are more like in-memory data structures created by the .NET VM, and invisible to the outside world, without serialization.
It might depend on the specific use.
I'll have to write this out fully later, but the argument is that using 2 types of glue is strictly worse than using 1, because you create a combinatorial explosions of code. You also create more software interfaces, and interfaces are where bugs tend to happen.
More code and more interfaces leads to more bugs. One type of glue is better!
Also, the glue should be dynamically typed. Because shell is for gluing together say Rust and Go, which have wildly different type systems. It's better to have 2 type systems than 3. If you have 3, then you need more glue.
"I don't glue on top of my glue" - https://oils.pub/ysh.html
>
Its THE Zawinski of XEmacs so maybe not the best example.Emacs has it right though, more right than wrong, they just, as a community, hate humans.
Data and data collections should have app-tributes, apps shouldn't have data.
The problem with most operating systems is that they need to model space time and minds as first class but they don't.
I've been using my own personal OS for years now that I call imtropy, once your abstraction maps to reality everything becomes easier to reason about.
The simple fact is most people and programmers are stuck in logic and rationality when they should think a layer deeper, coherence is all that matters.
Do you have some more details about those things?
Yes, including about Emacs users "hating humans". I use Emacs, and I'm very fond of humans. Plus my reading of the Emacs community is that there's loads of interesting and respectful people. Where's the hating humans bit?
It's a highly-dimensional box, isn't it? This age-old tension between interface standards and business/innovation speed.
Everything is a file is a good example of a fundamental and major standard that lasts till today and even though IPC kind of didn't make it all the way, I think about the core UNIX philosophy and Alan Kay's thoughts around as very, very accurate in terms of where we've ended up and what the likely ways out look like to me.
> Your data is trapped inside the box that is your program.
Well if we're going to get philosophical about it, "I" happen to be ~30 trillion cooperating boxes known as cells, so say nothing of all the other enclosed, enclosing, or cross-connecting boundaries one might draw.
Keeping the data/molecules/etc. "hostage" is probably to my benefit, as opposed to an, er, Evangelion ending.
and always, always, always, you are at the mercy of the program author.
Not if it is open source, and you're willing to put some effort into it. When I write code I like to think of it more as using a computer effectively instead of programming.
Yes, interoperability, extensibility, composability and the tyranny of program author is a problem. JVM with runtime-loading of classes and it's once popular beans standard is one of closest approximations, known to me, of the most general "local" solution.
Yes, it's cumbersome and hacky and still limited. The beans idea lost popularity and mindshare.
Ever heard the cliche about “designing a game with no rules”? Seems pretty similar to “structured data with no boxes.” I think data boxes as defined by the author are not inherently bad. Optimization and specialization go hand-in-hand.
The solution is so simple as to be boring: keep your stuff in files on the filesystem.
Your data is in a box. SaaS put your data in other people’s servers. Phones put your data in a hidden store because app APIs only let developers do it that way - and Apple decided people don’t want filesystems.
But this is all reverting back: you can download your data thanks to GDPR, and phones have file browsers now.
Every computer has a filesystem. Even ones that pretend not to. It’s the common-denominator of computing.
Swift has interoperability with Java (early stages, but works).
Once again, todsacerdoti proves one of my personal axioms: that he is the submitter of the worst blog crap on HN.
Am I the only one who finds the Sam Altman-esque 'all lowercase except for proper nouns like Linux but not including the pronoun i' writing style unbearable to read?
"Please don't complain about tangential annoyances—e.g. article or website formats, name collisions, or back-button breakage. They're too common to be interesting."
https://news.ycombinator.com/newsguidelines.html
(Of course annoyances are annoying, but they're also distracting, and they tend to get stuck at the top of threads, choking out more interesting conversation.)
I definitely find it difficult, cognitively, for long-form writing. It's also the second time recently I've seen all-lowercase blog-post-length content, after previously having never seen it, so I wonder if something is happening culturally to pull text-message style formatting up into the rank of published content.
My guess is it’s meant to come off as more authentic and conversational, like an informal chat.
It's often used as a tone signifier: https://www.theguardian.com/society/2025/feb/18/death-of-cap...
Yeah, I suspect that's the intention. There's a definitely a cultural break. To me, lowercase creates a casual tone in texts/chat. But in long form, especially published (i.e. purposefully displayed to an audience), it sends me a tone of disinterest or laziness at worst; or at best, simple innocent ignorance/mistakenness (like misspelling). Clearly neither is the case here though.
oh yeah i definitely agree! the tone communication can be useful but in longform writing it gets very grating and confusing/distracting. it's also just more social engineering to pretend to be authentic when one is clearly not.
i prefer this type of writing for comedy generally
Probably an article written by an LLM which has been instructed to look _more human_.
I guess time will tell if this is a new ‘thing’ people do ¯\_(ツ)_/¯
It's fine in tweets and even HN/Reddit comments, but it becomes a tacky affectation when used in longer form, deliberate content.
I wonder if unconventional writing styles are becoming the signal for deliberate content. If text is too polished– or even using certain punctuation– can lead to readers questioning whether AI assisted in the creation of the text.
A quick search shows that others have made this connection between Altman and lowercase and non-AI authenticity: https://ted-merz.com/2023/12/18/writing-in-lowercase/
It looks like this particular blog previously used conventional capitalization from 2017 to late 2023. The first post in this style appears to hint at a kind of shift in identity of the author, so perhaps, in this instance it is more a signal of personal expression or tribalism than non-AI-ness. Then again, we may see the line between the two continue to blur.
No. It's obnoxious signaling/tribal adherence. Relevant [1].
[1] https://www.youtube.com/watch?v=F4ifVvgZU58&t=623s
I waste brain cycles correcting the author's formatting mistakes while simultaneously trying to understand the meaning. Thus I read slower, but not the productive kind of slow reading—I am not contemplating the concepts more deeply. I am slowed down by a lazy lack of editing, for no gain.
Not sure what it has to do with Sam Altman though.
it's pretentiousness thinly disguised as modesty.
trust me.
What I find pretentious is the legion of commenters who can't find anything better to comment on and instead pretend they're smart by nitpicking some stylistic choice in the most low-effort way possible.
Classic case of "you're pretentious", "no, you're pretentious". It's exhausting how often we reach for the word "pretentious" when we have bitter feelings about one person's opinion of another person or their work.
I just used it because he did. My real feeling was exhaustion. More of those comments than comments about the subject matter of the post. Like going to a swimming meet as a pro and finding it full of kids instead.
I was trying to be ironical.
You can use your ad blocker to lowercase the entire internet like this
it might become bearable eventually.It's cool if you're on desktop Slack or Messenger or something between friends, but making a conscious choice to go into your phone's settings and turn capitalization off for everything you do is a bit weird and over the top.
Seems to be a trend though now to do it everywhere in public. I've seen the htmx author do that and the guy who wrote the second forked version of opencode.
Weird. I actually never noticed that while reading the entire article. And I'm almost 50. No idea what that says about me.
I'd closed the tab by the end of the first sentence. If the author can't be bothered, then neither can I. I tend to find people who do this have a superiority complex, they think they're so much better than everyone else that they're justified in offloading their own tiny cognitive load on to everybody else.
The author put a lot of effort into actually writing the thing, and correctly capitalized quotes, which clearly indicates a stylistic choice. You aren't willing to read text that isn't written in your preferred style, but you believe it's the author who has a superiority complex?
They didn't put enough effort in. It's not a preferred style, it's correct written English.
So, you barely read one sentence, then went to the comments, read an entire thread, and took the time to post about how the author probably thinks they are superior to you?
I strongly recommend rethinking that approach. You ascribed intentions to the author and then spent more time getting upset about them than you did interacting with the content.
There are actually interesting points in that text, yet here we are getting fussy about the author's supposed lack of decorum. That's really disappointing to me.
Funnily enough, I didn't read an entire thread, I read that one comment and posted an agreement to it. I'm not overly fussed if you are disappointed in me.
It's something I experimented with as an edgy teenager. It's not something I'd expect from an adult.
I do it a lot, do me a favor and don't attribute it to Sam Altman since some of us have been doing this for a long time. If you don't like it, you don't have to read it, but you also don't need to be patronizing and close-minded about how others choose to express themselves.
I think writing like this is disrespectful to your audience since they have to put in extra effort to parse your text. If you choose to express yourself like that, fine, but it's not patronizing to point this out.
Maybe you're not the intended audience! :)
i tend to draft everything lowercase, and then go back and uppercase things depending on how much of a formal vibe i'm going for. capitalization rarely helps me formulate an idea, and so my writing often splits into phases: (1) formulation, (2) polish.
also, it's worth noting that proper capitalization does not automatically yield text worth reading. from that perspective, i like lower case text as a form of rebellion against the artifice of rules; any rebellion against particular aesthetics is fair game in my book. more generally, i'm skeptical of process advocacy in cases where the process seems to be done for its own sake.
on the flip side, good grammar helps me parse sentences, so i do sympathize with arguments in its favor.
I find all lowercase messes with my parser, and is fustrating to read. I think I may treat sentences as a single unit, and use the capitilization to detect the boundaries. Without it I find bouncing to/from sentences slower (which can happen if a latter sentence/paragraph adds more context, and I want to revisit the previous idea).
Interestingly your semi-colons stand out much stronger than the periods for me.
CAPITALS AT LAST
https://archive.org/details/livestimesofarch0000marq/page/20...
Good meme.
i like it. maybe because i grew up with phones and texting but having perfect punctuation reads very formal to me, and if im reading a personal blog post i assume its casual reading. if i get a text that ends in a period mark, i assume the person typing it is MAD. i also just like lowercase glyphs more they look more pleasing to me
I didn't know that was a thing. It's purpose seems to be different for the sake of being different.
"I" being capitalized is one of the most weird quirks of the English language.
I agree. A quick search tells me the practice was started for legibility in hand-written manuscripts [1], or for that and also to emphasize the importance of the writer (seems egotistical to me :)) [2], or those reasons and also to help distinguish English from other languages but we don't really know [3].
[1] http://www.alt-usage-english.org/excerpts/fxwhyisi.html [2] https://www.thesaurus.com/e/grammar/whycapitali/ [3] https://greatbigstory.com/why-do-we-capitalize-the-word-i/
arguably it makes what would otherwise be a very little letter stand out more in text
No.
Agreed. Honestly - life's too short to read a text the author couldn't even be bothered to capitalize correctly.
for reasons I don't (want to) understand, lowercase i and psychopathic credit stealing prompting seem to yield best results for llms... e.g. "i want xyz how do i do it, ok please do so", not "I'm trying to do xyz. Could you guide me through?"
Tell me you didn't grow up on IRC and AIM without telling me you didn't grow up on IRC and AIM
I did grow up on IRC and AIM. I use all-lowercase even today in text-messaging. I explicitly undo autocapitalization of "lol", and so on.
But the topic is long-form, published content. Writing styles communicate tone, which may change culturally with generations.
i hate this writing style so much. i have to do extra work fighting autocorrect to make it seem like i just rolled out of bed and typed it out on my phone. i am so smart, see, i don't care about Big Establishment Grammar, my ideas are so good it will pierce through
My output is so high that editing anything more completely than iOS automatically handles for me is a waste of my time
... or people who type in lowercase just keep autocorrect off?
your brain is only fighting it because it's expecting capitalization, the same way parens put new lisp users off and javascript has difficulty shedding its semicolons; it's all just struggling to let go of something that was drilled into you.
Sorry, I couldn't finish reading because the entire article is in capitals.
Looks like it checks for the referrer in main.js and adds the uppercase text-transform if you come from HN:
Sounds like the author got called out for not capitalizing the start of her sentences[1] and decided that, if HN readers want capital letters, they will get them.
[1] https://news.ycombinator.com/item?id=39027187
Which is funny because if you engage Reader Mode in the browser, everything becomes proper except sentences, which still start with lowercased letters for some reason. Names are still properly capitalized. It's truly bizarre
It's a less... dramatic... version of what happens when HN links to JWZ's blog.
But where's the testicle in an egg cup?
What would happen if no "Referer:" HTTP header is sent and Javascript engine is absent or disabled
Answer: The text will be mostly all lowercase, along with some sentence case
Right? Who thinks that is acceptable in 2025?
Someone who is writing on their personal blog and doesn't give a damn what is "acceptable" to some rando on the Internet?
If you're publishing a public blog, by definition your audience is randos on the internet. Also, the author is posting in this thread.
it was acceptable in 2024? what year did it become unacceptable?
Since October 1995 and the publication of RFC 1855.
https://www.rfc-editor.org/rfc/rfc1855
Communication has not been merely a matter of personal habit — it follows commonly accepted standards for exchanging information within a group. Ignoring these conventions risks your message being unread, unheard, or misunderstood.
That said, it seems possible the author is intentionally addressing a specific subgroup that has agreed upon a different set of communication rules.
Status of this Memo: This memo does not specify an Internet standard of any kind. - MY FAVORITE kind of Memo :)
Some other handy passive-aggressive electronic mail techniques, courtesy of Bernard Greenberg from Symbolics (BSG 4/11/84):
https://en.wikipedia.org/wiki/Bernard_Greenberg
https://www.donhopkins.com/home/archive/humor/flame-manual.t...
>It is impermissible to use the term "EMAIL".>It is customary to attack the someone by including his or her message, indented (unless you are using MM), and replying point by point, as someone debating someone they are watching on TV, or hearing on the radio.
>It is considered artful to append many messages on a subject, leaving only the most inflammatory lines from each, and reply to all in one swift blow. The choice of lines to support your argument can make or break your case.
>Mail should be at least a mixture of upper and lower case. Devising your own font (Devanagari, pinhead graphics, etc.) and using it in the mail is a good entertainment tactic, as is finding some way to use existing obscure fonts.
>Sending the mail from Unix is frowned upon (although this has gotten much better).
>Replying to one's own message is a rarely-exposed technique for switching positions once you have thought about something only after sending mail.
>You get 3 opportunities to advertise your Rock band, no more.
>Idiosyncratic indentations, double-spacing, capitalization, etc., while stamps of individuality, leave one an easy target for parody.
>The entire life, times, collected works, expressions, and modalities of Zippy the Pinhead are a common ground for much of the metaphor, rhetoric, and invective which pass daily through the mail. An occasional parenthetical "yow" CORRECTLY USED will endear one to the senior systems staff. So will puns and other remarks addressed directly to the point.
>Including a destination in the CC list that will cause the recipients' mailer to blow out is a good way to stifle dissent.
>When replying, it is often possible to cleverly edit the original message in such a way as to subtly alter its meaning or tone to your advantage while appearing that you are taking pains to preserve the author's intent. As a bonus, it will seem that your superior intellect is cutting through all the excess verbiage to the very heart of the matter.
>Keeping a secret "Hall Of Flame" file of people's mail indiscretions, or copying messages to private mailing lists for subsequent derision, is good fun and also a worthwhile investment in case you need to blackmail the senders later.
Unclear, but it looks to be somewhere around the year 1000.
[flagged]
Agreed. Now the article appears to be in ALL CAPS for me, even the code block.
good catch. fixed the code block.
It definitely is.