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.
What gives you this impression?
That is a myth that keeps getting propagated. https://plan9.io/sys/doc/auth.html
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 stand corrected on tlssrv
POST /api/users
|> validate: `
name: string(3..50)
email: email
age?: number(18..120)
team_id?: number
`
|> jq: `{ sqlParams: [.body.name, .body.email, .body.age] }`
|> pg: `INSERT INTO users (name, email, age) VALUES ($1, $2, $3) RETURNING *`
|> result
ok(201):
|> jq: `{ success: true, user: .data.rows[0] }`
validationError(400):
|> jq: `{
error: "Validation failed",
field: .errors[0].field,
rule: .errors[0].rule,
message: .errors[0].message
}`
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.
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.
If you're also using jq you might as well ditch Jansson and use jq's `jv` API. I highly recommend it.
From what I can tell jq’s C lib doesn’t yet expose a way to set custom allocators.
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.
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.
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
Your brain is a box.
Your body is a box.
/s
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
This little change was mind-blowing for me so I always try to share when I can :)
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.
https://learn.microsoft.com/en-us/windows/win32/com/com-tech...
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.
> data has to be organised in some way
Yes it does.
https://www.cincom.com/blog/smalltalk/smalltalk-programming-...
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.
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.
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.
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.
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
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
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.
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.
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.
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, it's cumbersome and hacky and still limited. The beans idea lost popularity and mindshare.
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.
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 prefer this type of writing for comedy generally
I guess time will tell if this is a new ‘thing’ people do ¯\_(ツ)_/¯
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.
Not sure what it has to do with Sam Altman though.
trust me.
*##body:style(text-transform: lowercase !important;)
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 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.
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.
Interestingly your semi-colons stand out much stronger than the periods for me.
[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/
But the topic is long-form, published content. Writing styles communicate tone, which may change culturally with generations.
let host;
if (document.referrer) { host = (new URL(document.referrer)).host; }
if (host === "news.ycombinator.com" || host === "lobste.rs") {
let style = document.createElement('style');
// let transform = host === "lobste.rs" ?
style.textContent = `
body { text-transform: uppercase; }
pre, code { text-transform: none; }
`;
document.head.appendChild(style);
console.log("HN readers clearly can't handle the typing habits of the average trans girl.");
return;
}Answer: The text will be mostly all lowercase, along with some sentence case
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.
https://en.wikipedia.org/wiki/Bernard_Greenberg
https://www.donhopkins.com/home/archive/humor/flame-manual.t...
Proposed Symbolics guidelines for mail messages
BSG 4/11/84
>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.