catern

This looks cool!

But: These mostly aren't command line applications, they're mostly terminal applications. They're no more "command-line" than running "firefox" from your shell is "command-line".

There's a big difference... a terminal application takes over your terminal and doesn't have all the usual advantages of command-line applications used from the shell, like history and easy scripting.

I use Sendgrid's free tier in this exact way, for mail from catern.com.

Related: https://en.wikipedia.org/wiki/Hashcash

Are most congresspeople rich enough for that? Private jet flights are very expensive. Being a millionaire won't cut it.

Interesting, I wonder if this could eventually provide a freely redistributable game playable with OpenMW? Then, ironically, most people probably would play this game without the landmass featured in the original Morrowind - only with the new free content created by this project.

It's a bit more modern and neat to use .emacs.d/init.el, one less file cluttering your home directory.

Yes, and in a capability-safe language it's much more difficult to implement those flawed designs. (In the same way memory safety makes a buffer overrun vulnerability much more difficult to implement)

A concrete example is the Network capability mentioned in the article. The syscall to create a new process does not need network access, so in a capability-safe language that part of the OS won't have that capability passed in, so the OS won't be able to create new processes with network access. The Network capability, if desired for this process, will need to be explicitly added later by other code, in the OS or in userspace.

Cross-compiling OpenSSL to Rust and then compiling the Rust would also not get rid of the memory-unsafety vulnerabilities created by writing OpenSSL in C.

Nevertheless, if you wrote OpenSSL in Rust, or any memory-safe language, it would not have those memory-unsafety vulnerabilities.

The same applies when writing in a capability-safe language. It's fairly deliberately ignorant to call these kind of properties "magic".

FWIW that's what like what I do in rsyscall https://github.com/catern/rsyscall http://catern.com/rsys21.pdf

WASI could be used without wasm, in theory. So it doesn't have to couple changes on multiple axes together.

I agree with the other poster, WASI is the next step for those who like CloudABI and Capsicum, and may really win by being coupled to the browser.

Operating systems are also written by programmers. An operating system written in a capability-safe language would not have such ambient authority problems.

Java's SecurityManager is very different from capability-safety. It's much more like setuid: SecurityManager allows or disallows network accesses depending on what code is running. (Literally by inspecting the stack)

If log4j is such a fundamentally bad idea, surely we should expect our tools to stop such ideas from ever being implemented.

In the same way that modern languages are memory-safe (disallowing pointer arithmetic, because it's proven to be a terrible idea), a real modern language would disallow log4j by being capability-safe.

I think the real fix here is to investigate why you're creating possibly-already-existing directories anyway. Most files or directories should either be owned by a specific component (which then creates them and fails if they already exist) or should be assumed to already exist (as a requirement that the environment is set up properly.

I love the idea, but the algorithm for scaling seems a bit off. For example, it shows the human as much larger than the car.

It would be nice if those labeled blocks could be written inline and anonymously - just pass a block as an argument rather than having to actually name the error handling block. Is that supported?

Interesting! That reminds me of the argument that market manipulation makes markets more efficient by increasing the reward available to honest participants. Wash trading being discouraged by high trading fees doesn't have the same incentive structure, but I wonder if you could arrange it the same way?

That's essentially what a Linux distribution is.

That's the cache in the browser, not the cache in the CDN.

Hm, I wonder if this could be circumvented by doing timing attacks against the CDN cache? That's still shared between domains...

>And then - because not bundled - all the modules that will be used on another page will be cached already.

Why isn't anyone else mentioning this feature? I'm not a browser developer but this seems like a clear win, and indeed makes bundling unnecessary. I'm assuming that it's shared between domains, too - or are people's dependencies so fragmented that there's basically no sharing between domains?

Yeah I agree, you'd only want to automate it that way if you couldn't modify the original script, which is kind of a niche use case... anyway I just think it's neat

The idea here can be generalized to a primitive programming construct: The magic function "wish", which can do anything you want, just give it a string description.

For example:

    wish('copy these files to this host', files, host)

You can augment this further by allowing the program to specify a return type from the wish, and magically the wish will produce the type you want. So for example:

    data = wish(Path, 'the path of the data files I need')

Of course, the wish is actually implemented by sending a request to some human user. In my "wish" library for Python http://rsyscall.org/wish/ you can have a stack of handlers for wishes, just like exception handlers. If later you want to automate some wish, you can specify a handler which intercepts certain wishes and forwards the other ones on (by wishing again, just like an exception handler can re-raise).

This is cool, but I don't understand the justification for why a more traditional "just store a sequence of events" undo system wasn't possible. As the author says in the post on the scripting system, the game scripts access virtual interfaces. Those could just record the methods called before forwarding them on - doesn't matter that the scripts make arbitrary method calls. It seems to me that there's nothing inherent to "the level script is arbitrary code rather than a list of commands as data" that makes that style of undo impossible.

Having your screen locker which is written in C be setuid root is a really bad, really insecure idea. That it's supposedly being done for security reasons is replacing a minor, difficult to exploit security issue with something that's essentially guaranteed to be vulnerable.

Upstream is clearly wrong here - whether that means slock should be patched to be sane, or that slock should just not be packaged at all, I couldn't say.

You may already realize this, but you don't need to run a VM per project if you're using Nix; Nix lets you have as many self-contained development environments as you like, all on one machine without VMs or containers.

When it comes to Linux kernel work, yes.

Yes, and it shows (it's notoriously poorly designed)

After reading this article, the theory that comes to mind is that "best practices" not just developer preferences - rather, "best practices" is cargo culting by mediocre programmers, trying to copy techniques that a really skilled programmer once employed to do amazing things.

This is the part of the article that made me think this:

>As I type this, I’m in a discussion about whether it’s better to pass a few unnecessary parameters to simplify a bash script’s internal logic or pass fewer parameters and make the bash script more complex.

This sounds like they're on the verge of parameterized, object-capability design - passing in the paths to operate on, rather than hardcoding some internal logic to determine what to do. If you do this in the right places and at the right time, you can do amazing stuff, reuse scripts in totally novel environments and for novel purposes. At other times, it's not necessary. But I'm guessing neither side really knows how to use that to do amazing stuff.

Some programmers don't have the skill to recognize when a specific technique is justified or unjustified. So, unmoored from technical reality, they just argue about cultural norms - blindly copy what someone else did once, which brought someone else success - cargo culting.

That all sounds very mean, but if this is what's actually going on, I'm not sure what the solution is. Maybe more focus on really impressive and amazing concrete projects, rather than just individual practices in isolation?

Yeah, I think the easiest way to test that Service A is meeting its API obligations is to send some requests to Service B. Hyrum's Law means that that's the only way to really test the important aspects of Service A's API.

And I think this can be generalized into a general philosophy of using your users as a test suite for your API: http://catern.com/usertests.html