Have fun reading SICP! I’m also reading it … in fact, I have been working on it on and off for over 10 years. The reason I never finish it is that I keep piling up more work for myself. First I was just going to read it. Then I wanted to do all the exercises. Test all the exercise solutions. Make it work in multiple Scheme implementations. Generate a website from it. I’m currently in the middle of chapter 3 at https://mk12.github.io/sicp.
Damn, you’ve made a whole project out of it! Seems really good! Personally, I’m just gonna try to read through it and do most of the exercises. It’s exams season right now, so not the best time to start this endeavor, but nonetheless I hope I stick to it. Definitely gonna save your site to my SICP resources.
That in and of itself is an undertaking, considering I recall at least one or two of them having a footnote to the effect of “This exercise is significant and probably worthy of a PhD thesis.”
Hello everyone! As my first submission, I present a small guide to get Emacs up and running as full ISE (Integrated Studying Environment) for SICP. Specifically, I present a workflow that consists of SICP in Texinfo format, a racket REPL and Org-Mode.
One of the solution to make sudo safe, IMHO, is to look at a smaller feature scopes. Less code means less potential vulnerabilities.
That’s also part of the work.
From the README:
Our current target is to build a drop-in replacement for most basic use cases of sudo. […]
Some parts of the original sudo are explicitly not in scope. Sudo has a large and rich history and some of the features available in the original sudo implementation are largely unused or only available for legacy platforms.
I’d love to use doas for more, but a ton of software on Linux expects proper sudo and will break if given something incompatible. New code can & should support doas alongside sudo, but a sudo-compatible executable will be needed on most distributions for the foreseeable future.
for the past couple of years, and I, somewhat surprisingly, didn’t hit any issues at all. While yes, sudo is obviously the right default choice for distros, I have a feeling that a lot of end-users can switch without any problems.
AFAIK, sudo.enable = false merely prevents the sudo NixOS module from putting sudo in the global environment. Might other packages be pulling in sudo and using it anyway?
I also use sudo.enable = false without problems, but I’m not at the computer to check.
Anything can pull in sudo the package, but since it is a setuid program it needs special handling by NixOS to work properly.
That is, there can be no setuid binaries in the nix store for security reasons - all files there are owned by root so if this was allowed then anybody with the ability to build a nix derivation can trivially gain root. Instead, NixOS places setuid wrappers in a specific location outside of the nix store for every binary that needs one.
So while anything could be pulling in sudo, it can not actually use it to elevate privileges.
I’m going to use this opportunity to reiterate one of my favorite excessively-pendantic points: Compilers are called “compilers” due to an accident of history. The original compiler did little more than append a standard library to an assembly program, fixing up function calls to it so that the programmer didn’t need to precompute its memory location. In other words the original compiler was actually a “linker”, and did little more than compile things together.
If things were named logically, a compiler would actually be called a “translator”, because the analogy with the human jobs is nearly perfect. A human interpreter listens to all or part of a statement, then provides the equivalent in another language, with speed being of higher importance than accuracy. Whereas a human translator takes a completed text and takes an arbitrary amount of time to create a product where quality is of paramount importance. (We can perhaps even go so far as to say that languages that are created to be interpreted differ from languages created to be compiled are meant to be used differently, in much the same way that as the distinction between spoken and written natural lanuages.)
If you read IBM documentation from the ‘60s and ‘70s, they often referred to the program that converted FORTRAN or COBOL into machine code as a translator. Even in the ‘90s, the Psion Series 3’s embedded programming language used Translate rather than Compile as the verb in the menu that generated a stand alone (though still bytecode) program. I am not sure when compiler took over from translator as the preferred verb but I tend to use translate and interpret when explaining to non-geeks because they understand the difference between doing a single translation pass over a book and having a version in another language versus reading in one language and speaking each sentence in another (and the relative latency and throughput of both ideas translate directly into the programming language context).
I wonder if partial evaluator is a better term than a translator. A translator can technically translate pascal to C or vice versa without changing the level of abstraction.
I would still call that a translator. The term doesn’t imply how different the two languages are. (And I’m would be surprised if nobody had ever written a Pascal compiler that just compiled to C. If it works, it’s still considered to be a compiler.)
I think the key difference between a conventional compiler and a C to Pascal converter is that it performs a lossy transform. There are many C programs that map to the same x86 assembly, for example, because the act of compiling strips a lot of identifiers and, with optimisation, will reassociate arithmetic and so on. I contrast, a source translator tries to preserve the bits of the source that matter only to humans.
Have fun reading SICP! I’m also reading it … in fact, I have been working on it on and off for over 10 years. The reason I never finish it is that I keep piling up more work for myself. First I was just going to read it. Then I wanted to do all the exercises. Test all the exercise solutions. Make it work in multiple Scheme implementations. Generate a website from it. I’m currently in the middle of chapter 3 at https://mk12.github.io/sicp.
Damn, you’ve made a whole project out of it! Seems really good! Personally, I’m just gonna try to read through it and do most of the exercises. It’s exams season right now, so not the best time to start this endeavor, but nonetheless I hope I stick to it. Definitely gonna save your site to my SICP resources.
That in and of itself is an undertaking, considering I recall at least one or two of them having a footnote to the effect of “This exercise is significant and probably worthy of a PhD thesis.”
Hello everyone! As my first submission, I present a small guide to get Emacs up and running as full ISE (Integrated Studying Environment) for SICP. Specifically, I present a workflow that consists of SICP in Texinfo format, a racket REPL and Org-Mode.
ISE = Integrated Reading Environment? At first I thought a typo, but S and R seem an unlikely swap.
Oops. I meant to write “Studying”, since it isn’t just for passively reading it. Thanks for catching that.
Nice post, thanks for sharing. It’s quite fun to work through SICP natively in emacs
Thank you very much! And thank you for maintaining SICP’s MELPA package!
One of the solution to make
sudosafe, IMHO, is to look at a smaller feature scopes. Less code means less potential vulnerabilities.IMHO, OpenBSD’s doas is a solution to this. It comes as “opendoas” on Debian. It has one of the simplest configuration I’ve ever seen, in addition to a tiny but very powerful feature set.
That’s also part of the work.
From the README:
I’d love to use
doasfor more, but a ton of software on Linux expects propersudoand will break if given something incompatible. New code can & should support doas alongside sudo, but asudo-compatible executable will be needed on most distributions for the foreseeable future.FWIW, I have been using
for the past couple of years, and I, somewhat surprisingly, didn’t hit any issues at all. While yes, sudo is obviously the right default choice for distros, I have a feeling that a lot of end-users can switch without any problems.
AFAIK,
sudo.enable = falsemerely prevents thesudoNixOS module from puttingsudoin the global environment. Might other packages be pulling insudoand using it anyway?I also use
sudo.enable = falsewithout problems, but I’m not at the computer to check.Anything can pull in sudo the package, but since it is a setuid program it needs special handling by NixOS to work properly.
That is, there can be no setuid binaries in the nix store for security reasons - all files there are owned by root so if this was allowed then anybody with the ability to build a nix derivation can trivially gain root. Instead, NixOS places setuid wrappers in a specific location outside of the nix store for every binary that needs one.
So while anything could be pulling in sudo, it can not actually use it to elevate privileges.
You can just make a symlink:
/bin/sudo → /bin/doasThat would not be “proper
sudo”, options are too different.Or even more simple: ssu. 120 lines of code; does one thing, does it well.
I’m going to use this opportunity to reiterate one of my favorite excessively-pendantic points: Compilers are called “compilers” due to an accident of history. The original compiler did little more than append a standard library to an assembly program, fixing up function calls to it so that the programmer didn’t need to precompute its memory location. In other words the original compiler was actually a “linker”, and did little more than compile things together.
If things were named logically, a compiler would actually be called a “translator”, because the analogy with the human jobs is nearly perfect. A human interpreter listens to all or part of a statement, then provides the equivalent in another language, with speed being of higher importance than accuracy. Whereas a human translator takes a completed text and takes an arbitrary amount of time to create a product where quality is of paramount importance. (We can perhaps even go so far as to say that languages that are created to be interpreted differ from languages created to be compiled are meant to be used differently, in much the same way that as the distinction between spoken and written natural lanuages.)
If you read IBM documentation from the ‘60s and ‘70s, they often referred to the program that converted FORTRAN or COBOL into machine code as a translator. Even in the ‘90s, the Psion Series 3’s embedded programming language used Translate rather than Compile as the verb in the menu that generated a stand alone (though still bytecode) program. I am not sure when compiler took over from translator as the preferred verb but I tend to use translate and interpret when explaining to non-geeks because they understand the difference between doing a single translation pass over a book and having a version in another language versus reading in one language and speaking each sentence in another (and the relative latency and throughput of both ideas translate directly into the programming language context).
In greek, compilers are actually called ‘translators’ (μεταγλωττιστές).
Same in Finnish, kääntäjä.
I wonder if partial evaluator is a better term than a translator. A translator can technically translate pascal to C or vice versa without changing the level of abstraction.
I would still call that a translator. The term doesn’t imply how different the two languages are. (And I’m would be surprised if nobody had ever written a Pascal compiler that just compiled to C. If it works, it’s still considered to be a compiler.)
I think the key difference between a conventional compiler and a C to Pascal converter is that it performs a lossy transform. There are many C programs that map to the same x86 assembly, for example, because the act of compiling strips a lot of identifiers and, with optimisation, will reassociate arithmetic and so on. I contrast, a source translator tries to preserve the bits of the source that matter only to humans.