mct | 8 months ago | on: Show HN: A DOS-like hobby OS written in Rust and x86 assembly
mct's comments
mct | 2 years ago | on: Let's compile like it's 1992 (2014)
mct | 3 years ago | on: Voyager spacecraft begin to power down
FYI, though, I think this may be looking at the wrong object ID. It selected "31", which appears to be the entry for one of the Lagrange points. Voyager 1 and 2 appear to have negative ID numbers, "-31" and "-32".
mct | 3 years ago | on: Internet Mail 2000
mct | 4 years ago | on: Zoom court hearing postponed after accused found in same location as witness
Are there any other court feeds you've found interesting?
mct | 4 years ago | on: Netcat – All you need to know
mct | 4 years ago | on: Python is 1.3x faster by just adjusting some compiling options for libpython
mct | 5 years ago | on: Look Up Unknown Phone Numbers Using Facebook Reset Password
mct | 5 years ago | on: The UNIX Time-Sharing System (1974)
Youch. Was the PDP-11 really so unreliable?
mct | 10 years ago | on: Netcat.c
mct | 10 years ago | on: Show HN: Manage passwords with GPG
mct | 10 years ago | on: Show HN: Calc, a simple command-line calulator in C
Two weeks ago, after becoming fed up with having to copy and paste results from one line to the next, I wrapped it in a repl and added bc(1)-like support for "." expanding to the last value. Rather embarrassingly, I started to implement bc(1)-style variables, but then realized this was incredibly silly as you can simply use perl variables directly. :-)
https://github.com/mct/junkdrawer/commits/master/bin/calc
I fully support writing other calc implementations, especially in languages such as C! It's a great exercise, and can become very complex very quickly. bc(1) supports arbitrary precision (try: echo "scale=500; 4a(1) 42" | bc -l), which is super awesome. In C, I've only implemented RPN calculators, never infix, which would be fun to try.
mct | 10 years ago | on: How to Install Ubuntu Linux on your Dell PC
Thanks!
mct | 10 years ago | on: Get Your Shit Together
This is one of the reasons I've been putting off completing a will :-( Is there a good option for going about this without naming an executor?
mct | 10 years ago | on: Get Your Shit Together
mct | 10 years ago | on: Using BitTorrent with Amazon S3
mct | 11 years ago | on: Spacemacs – Emacs advanced kit focused on Evil
They are keybindings my fingers reach for everyday without thinking about it, similar to how I use j, k, h, l without thinking about it.
mct | 11 years ago | on: Spacemacs – Emacs advanced kit focused on Evil
* Toggling if search results should be highlighted (:set hls, :set nohls)
* Opening the filename under the cursor in a new window (^W f)
Completely emulating an entirely different editor is very, very difficult :-(
I applaud everyone contributing to these projects, and hope they continue to improve! They've already come a very long way from evil, and viper-mode.
mct | 11 years ago | on: How doctors choose to die (2012)
Thanks!
mct | 11 years ago | on: Standard way for Authoratitive DNS servers to refuse ANY query
* When no entry already exists in the cache, bind will forward the ANY query to an authoritative server and return the result.
* When some information is already present in the cache, bind will return only the information already cached, without querying more information from an authoritative server
Thus, if you need to know if a specific RR exists, you must query for that specific RR.
Still, to aid humans in debugging DNS problems, a nice compromise might be to allow ANY queries only over TCP. That would alleviate the spoofing problem.
I was playing with a toy TCP/IP stack, and decided using SLIP over a pty on Linux was a great way to interface with the kernel. Unfortunately it looks like macOS previously shipped with slattach(1) a very long time ago, but no longer does.
I'm curios if other people have used SLIP on macOS to get a dead-simple, cross-platform API to the networking stack?
The alternative would be to use tun/tap on Linux and utun on macOS, but SLIP would be so much nicer.