I completely agree with this. To me, Terraform is just “API calls as configuration, in a deterministic manner” - I want/need it to match whatever I can do manually myself, it’s just a way of having infrastructure as code.
I hadn’t thought about Arabic in terminals. As I understand it, in Arabic, ligatures are semantically meaningful. How does that work in a fixed-width terminal?
Yesterday. I updated the VM build script for running containers with Podman to enable the Linux ABI layer. With this, I could pass --os linux to the pull and run commands and run Linux applications. I’d really recommend it as a way of running Limix-only things on FreeBSD. You can just pull the container image for your favourite Linux distro, install packages, and have all of the lifecycle management handles by Podman.
I guess the same could be said for eschewing any standard library implementation of CLI argument parsing in favor of something more powerful. I’ve taken to just using ‘argparse’ instead of Click and ‘flag’ instead of Cobra. Sure, the latter in the two examples might be allow me to do more, but given a reasonable structure for the CLI, it’s not a Herculean task to swap them out down the line should it become necessary. In the meanwhile, one less direct dependency (and several less indirect dependencies) brings a sort of peace of mind.
As an aside: the link to the clap project has a typo in it.
I fundamentally disagree with this framing. The reason that memory safety is such a problem is that violating it invalidates axioms that unrelated parts of the program depend on. If I hold a pointer to an object and do not share it, the contents of that object will not change unless I change it and it can hold secrets that are not exposed to the rest of my code. If I hold a pointer to an immutable object, that object will not change. I can build complex systems starting from these assumptions. If there is a use after free bug or an out of bounds memory access then these assumptions no longer hold. It doesn’t matter where the memory safety bug is, if it’s in the same protection domain (address space on conventional systems) then all bets are off for the whole of the rest of my system.
This is why CHERI is designed to provide guarantees that work across languages. With the CHERI JNI work, I showed that you can implement FFI from a type safe language into arbitrary native code without allowing it to violate type safety. With CHERIoT, we give you a strong set of memory safety guarantees that everything from assembly on up must respect, which the compilers can use to ensure foreign code does not violate their assumptions.
With Verona, we are building the interoperability model on top of the region abstraction, so we can express a set of objects that can be corrupted by a call to a foreign library. We can then implement that isolation with SFI, process isolation, CHERI, or any other mechanisms that come along.
The fact that a problem is hard to solve is no excuse to redefine it as a simpler one and pretend that you’ve solved it.
It’s normally a good idea to express this kind of limit as a fraction of total RAM. Most *NIX systems compute things like the default for the maximum number of file descriptors like this, for example. 10 years after you introduce them, RAM is so big that users don’t see the limits.
Some of it was just page tables. NT moved a bunch of things into userspace services that each needed their own address space. That’s only a few tens of KiBs per process, but a dozen of those add up. Some of it came from being fully 32-bit (no 16-bit thunks). Some came from features that weren’t present in the 9x series, such as NTFS with ACL support, multi-user support, and access control on all kernel objects. I am not intimately familiar with NT of that era, but I don’t think it was particularly over-engineered. Its requirements were fairly similar to contemporary UNIX systems (it’s direct competitors).
Isn’t this 100% GitHub’s fault? They’re allowing malicious actors to impersonate them on their own platform. Shouldn’t this expose GitHub to litigation?
I’m reading that “by default” to imply two important positions:
The presence of FFI intrinsics does not inherently render a language memory-unsafe.
Whether a language is memory-unsafe depends on the idioms and practices applied in its natural state, not to some carefully-crafted subset.
For (1), if the presence of ctypes or unsafe { } meant that Python and Rust aren’t memory-safe, then it would be impossible by definition for any memory-safe language to be used for most programming tasks. There must be some way to either call out to external libraries (such as libc) or invoke OS syscalls directly, otherwise writing even the most trivial “hello world” binary would be impossible.
For (2), it is possible to define subsets of nearly any language that can be proven memory-safe. C is memory-unsafe because it’s possible to write int x = 0; int *y = &x; int z = y[100]; – the existence of specialized safety-oriented dialects such as MISRA-C or Barr-C does not change this fundamental property of the C language.
The “by method” feature is so cool and matches one of the main things I like to do with dafny: have a provably correct simple recursive implementation along side a formally verified optimized version. Turns out that’s supported as a first class feature!
I think there are often abstractions that simplify things. After all an ext4 driver and vfs is usually a better way to interact with a block device than just seeking around /dev/sda.
But the key difference with something like terraform is that often abstraction of configuring a service isn’t a goal. The goal is to abstract the CRUD operation of that resource. So yes the 200% problem applies but don’t forget you might be getting something new in return.
I personally don’t like using terraform and I like better than the other solutions out there. Except maybe pulumi. I’m still on the fence because writing pulumi unironically is more like writing React than it is plain javascript. You’re writing code sure, but fundamentally you’re still configuring some graph that’s being executed/resolved in a non-straighforward way.
To elaborate on this (with the caveat that I’m not a professional engineer so everything I’m about to say could be bunk), I draw a distinction between automation and abstraction. Automation doesn’t necessarily hide details and using an automation tool properly requires you to understand the technical details of what it’s doing and how that relates to the ways in which you use it. Abstraction does aim to let you reason about a more simplified model than whatever got abstracted. Automation makes you more efficient at executing and iterating, but it doesn’t help you plan things; abstraction helps you reason about what you’re working on and can reduce the amount of iteration you need to do, but it won’t help you execute once you have your plan worked out.
To my mind, Terraform mostly operates as an automation tool. A well-designed Terraform module with the goal of abstracting standard operational goals can absolutely be a good abstraction tool, but that’s a property of the module, not of Terraform. It is true that Terraform abstracts cloud providers CLIs, but it crucially doesn’t abstract cloud providers’ services and options, which seem to be the example topic at hand here. If we didn’t have Terraform or similar tools, we’d do about the same amount of reasoning about infrastructure and relationships between components, but we’d be moving slower because we’d be maintaining and tweaking them in Bash scripts or something else brittle and overgeneralized.
Anyway where I’m going with this is that it’s important not to confuse one thing for the other. Trying to build abstraction features into an automation tool isn’t inherently wise, and unless it also helps automation I think it’d be bloat, and vice versa. Expecting automation tools to provide good, non-leaky abstractions is a recipe for disappointment, but conversely automation usually needs to be designed on the same level abstraction it’s meant to be used in, or it’s practically going to force leaks trying to accommodate a different number of Cuils.
I completely agree with this. To me, Terraform is just “API calls as configuration, in a deterministic manner” - I want/need it to match whatever I can do manually myself, it’s just a way of having infrastructure as code.
JavaScript mostly uses Unicode character properties to define its lexical syntax, so whitespace is Zs plus a few explicitly enumerated characters. https://262.ecma-international.org/#sec-white-space
Quite interesting! Dactyl- is finger in Greek, I wonder how this term evolved.
I hadn’t thought about Arabic in terminals. As I understand it, in Arabic, ligatures are semantically meaningful. How does that work in a fixed-width terminal?
Yesterday. I updated the VM build script for running containers with Podman to enable the Linux ABI layer. With this, I could pass
--os linuxto the pull and run commands and run Linux applications. I’d really recommend it as a way of running Limix-only things on FreeBSD. You can just pull the container image for your favourite Linux distro, install packages, and have all of the lifecycle management handles by Podman.I guess the same could be said for eschewing any standard library implementation of CLI argument parsing in favor of something more powerful. I’ve taken to just using ‘argparse’ instead of Click and ‘flag’ instead of Cobra. Sure, the latter in the two examples might be allow me to do more, but given a reasonable structure for the CLI, it’s not a Herculean task to swap them out down the line should it become necessary. In the meanwhile, one less direct dependency (and several less indirect dependencies) brings a sort of peace of mind.
As an aside: the link to the
clapproject has a typo in it.I fundamentally disagree with this framing. The reason that memory safety is such a problem is that violating it invalidates axioms that unrelated parts of the program depend on. If I hold a pointer to an object and do not share it, the contents of that object will not change unless I change it and it can hold secrets that are not exposed to the rest of my code. If I hold a pointer to an immutable object, that object will not change. I can build complex systems starting from these assumptions. If there is a use after free bug or an out of bounds memory access then these assumptions no longer hold. It doesn’t matter where the memory safety bug is, if it’s in the same protection domain (address space on conventional systems) then all bets are off for the whole of the rest of my system.
This is why CHERI is designed to provide guarantees that work across languages. With the CHERI JNI work, I showed that you can implement FFI from a type safe language into arbitrary native code without allowing it to violate type safety. With CHERIoT, we give you a strong set of memory safety guarantees that everything from assembly on up must respect, which the compilers can use to ensure foreign code does not violate their assumptions.
With Verona, we are building the interoperability model on top of the region abstraction, so we can express a set of objects that can be corrupted by a call to a foreign library. We can then implement that isolation with SFI, process isolation, CHERI, or any other mechanisms that come along.
The fact that a problem is hard to solve is no excuse to redefine it as a simpler one and pretend that you’ve solved it.
I wasn’t assuming an adversarial setting.
It’s normally a good idea to express this kind of limit as a fraction of total RAM. Most *NIX systems compute things like the default for the maximum number of file descriptors like this, for example. 10 years after you introduce them, RAM is so big that users don’t see the limits.
Some of it was just page tables. NT moved a bunch of things into userspace services that each needed their own address space. That’s only a few tens of KiBs per process, but a dozen of those add up. Some of it came from being fully 32-bit (no 16-bit thunks). Some came from features that weren’t present in the 9x series, such as NTFS with ACL support, multi-user support, and access control on all kernel objects. I am not intimately familiar with NT of that era, but I don’t think it was particularly over-engineered. Its requirements were fairly similar to contemporary UNIX systems (it’s direct competitors).
Isn’t this 100% GitHub’s fault? They’re allowing malicious actors to impersonate them on their own platform. Shouldn’t this expose GitHub to litigation?
I don’t think this should be tagged “zig”
I’m reading that “by default” to imply two important positions:
The presence of FFI intrinsics does not inherently render a language memory-unsafe.
Whether a language is memory-unsafe depends on the idioms and practices applied in its natural state, not to some carefully-crafted subset.
For (1), if the presence of
ctypesorunsafe { }meant that Python and Rust aren’t memory-safe, then it would be impossible by definition for any memory-safe language to be used for most programming tasks. There must be some way to either call out to external libraries (such aslibc) or invoke OS syscalls directly, otherwise writing even the most trivial “hello world” binary would be impossible.For (2), it is possible to define subsets of nearly any language that can be proven memory-safe. C is memory-unsafe because it’s possible to write
int x = 0; int *y = &x; int z = y[100];– the existence of specialized safety-oriented dialects such as MISRA-C or Barr-C does not change this fundamental property of the C language.You will get the length measure after shaping when writing a text rendered. Together with most of the graphical representation.
I understand the technical reason why it behaves like that, it’s still terrible..
Nt is the first modern kernel that’s still similar to what we have today. Yep, those features comes with a price, and the tradeoff is worth the cost.
This seems vacuous. We live in the real world; the world is not safe.
The “by method” feature is so cool and matches one of the main things I like to do with dafny: have a provably correct simple recursive implementation along side a formally verified optimized version. Turns out that’s supported as a first class feature!
I think there are often abstractions that simplify things. After all an ext4 driver and vfs is usually a better way to interact with a block device than just seeking around /dev/sda.
But the key difference with something like terraform is that often abstraction of configuring a service isn’t a goal. The goal is to abstract the CRUD operation of that resource. So yes the 200% problem applies but don’t forget you might be getting something new in return.
I personally don’t like using terraform and I like better than the other solutions out there. Except maybe pulumi. I’m still on the fence because writing pulumi unironically is more like writing React than it is plain javascript. You’re writing code sure, but fundamentally you’re still configuring some graph that’s being executed/resolved in a non-straighforward way.
To elaborate on this (with the caveat that I’m not a professional engineer so everything I’m about to say could be bunk), I draw a distinction between automation and abstraction. Automation doesn’t necessarily hide details and using an automation tool properly requires you to understand the technical details of what it’s doing and how that relates to the ways in which you use it. Abstraction does aim to let you reason about a more simplified model than whatever got abstracted. Automation makes you more efficient at executing and iterating, but it doesn’t help you plan things; abstraction helps you reason about what you’re working on and can reduce the amount of iteration you need to do, but it won’t help you execute once you have your plan worked out.
To my mind, Terraform mostly operates as an automation tool. A well-designed Terraform module with the goal of abstracting standard operational goals can absolutely be a good abstraction tool, but that’s a property of the module, not of Terraform. It is true that Terraform abstracts cloud providers CLIs, but it crucially doesn’t abstract cloud providers’ services and options, which seem to be the example topic at hand here. If we didn’t have Terraform or similar tools, we’d do about the same amount of reasoning about infrastructure and relationships between components, but we’d be moving slower because we’d be maintaining and tweaking them in Bash scripts or something else brittle and overgeneralized.
Anyway where I’m going with this is that it’s important not to confuse one thing for the other. Trying to build abstraction features into an automation tool isn’t inherently wise, and unless it also helps automation I think it’d be bloat, and vice versa. Expecting automation tools to provide good, non-leaky abstractions is a recipe for disappointment, but conversely automation usually needs to be designed on the same level abstraction it’s meant to be used in, or it’s practically going to force leaks trying to accommodate a different number of Cuils.