ttgurney

Based on the Zombocom reference and general lack of details, this must be a joke, but I don't get the joke. Is it meant to be a parody of something else?

And why not postal mail, for maximum novelty?

Aside, I wonder which CPU is emulated. A real 8086/8088 (for example) will behave differently than a modern x86 CPU that is running in real mode.

Location: Central United States

Remote: Yes -- remote only.

Willing to relocate: No

Technologies: Unix/Linux tooling, POSIX, general back-end stuff (not web), desktop applications, scientific applications. C, Bash/sh, Python 3, Java SE, PostgreSQL database. All in a Linux environment.

Personal portfolio here: https://ttgurney.com. I publish all of my open-source work at the above site. I have created my own Linux distribution as well, which I use as my daily driver.

Email: (my username) @ (my username) .com

Software engineer with CS degree, 6.5 years full time experience, and lifelong interest in tinkering with computers. Looking for opportunities that make good use of my depth of Linux knowledge.

Also have some interest in low-level, embedded, RE. No professional experience there, but I a fine C programmer and can read and write x86 assembly language.

> They do not participate in controversial discussions about Visual Basic or Pascal — they just do their work in those languages without even knowing that there’s so much controversy surrounding their language of choice.

Serious question: are these languages actually controversial? Doesn't "controversy" usually mean people holding strong opinions and frequently disagreeing? I rarely hear anything at all about Pascal or Visual Basic. Maybe they were controversial in the 1990s? Now I'd call them merely unfashionable.

My first open-source contribution was a two-line patch for a bug I found in Eclipse while at work.

Eclipse is known as a Java IDE, but it also provides a widget toolkit and other libraries for developing desktop GUI apps. At the time I was working on a team that had a huge desktop app built on top of Eclipse.

The bug I found was pretty trivial; it was something related to incorrect sizing of one of the widgets in some corner case.

The process was a bit of a pain relative to the size of the change. I had to write a test case, sign a CLA (per Eclipse project rules), and of course one of my four different bosses had to review the change and sign off on it.

At the time I was a junior engineer still eager to prove myself, and I figured all of this effort would be worthwhile just so I could say I got a patch into a major open source project. Nowadays I wouldn't bother with so much process, and certainly wouldn't sign a CLA. Would rather work on my own projects. At most I might send a patch out to a mailing list.

I'm really grateful for Michael Forney's work on this project since I found it a good resource for getting a variety of popular packages to build statically.

I ended up starting my own statically-linked Linux distro, but with some creative differences like shell scripts (vs Lua scripts) and package management. I recently "finished" it (close enough anyway) to the point that I run it as my daily driver.

Not trying to plug my project (it's not public, not yet anyway) but if anyone wants to discuss this sort of thing (distro creation and static linking in particular) and compare notes via email, I'd be happy to.

Speaking from my experience so far as an "adult learner": yes, it's brutal. At least, tournament chess is. Online play is easy for me not to take so seriously. But when I get up on Saturday morning to go to a tournament and spend all day there, and I am writing down every move, and I'm face-to-face with my opponent, the whole thing is a lot emotionally weightier. I've found that I dislike losing and that I experience empathy for my opponents when they lose to me. My favorite games that I've played have been draws.

I spoke a bit with an older and much more experienced player I know about this. He said the only thing that worked for him was to completely stop caring about winning and losing, and to let go of seriousness about the game. His idea was that chess is supposed to be fun; fun is the whole point. Improving is nice, but why bother if the process is not enjoyable in itself? Been thinking a lot about this since then.

I got the DIY edition of this a few months ago and have been using it continuously since then. Nice piece of hardware and I'm glad I bought it. Only big thing missing for me is user-modifiable firmware. Combine this thing with the Coreboot and neutralized Intel ME of Purism's products, and I would have no reason to use anything else. Currently this has a typical proprietary EFI firmware and no legacy BIOS support, which I wouldn't expect most people to care about but I find it a bit annoying.

I've also had some issues with the CPU temperature consistently pushing into the 90s when running big multicore workloads. Not sure why. Rather than look into applying new thermal paste or whatever, I just turned off Intel turbo boost, this is of course a performance hit but it keeps the whole thing very cool and improves battery life.

Hey thanks for your perspective and a couple of mentions of software I'd not heard of (like tcpclient).

I agree that curl is pretty big and bloated. I would not call it a deficiency that Links et al. don't depend on it.

I mostly just was thinking that since I already have curl on my system, it'd be nice to have a browser that reuses that code. Especially since curl has upstream support for the much smaller BearSSL rather than depending on OpenSSL/LibreSSL.

Oh I'm sure the actual work to compile those packages is not much. It's more to do with keeping the number of packages on my system to a minimum.

Actually I would not be surprised if the JavaScript engine can be omitted with just a little bit of patching work... assuming there's not actually a build configuration that leaves it out. I've found that with some software projects and their dependencies, "required" does not always mean required.

I look forward to seeing your 1st release of this program!

> Anyways, if there's a moral to this story it's that writing a browser engine is surprisingly fun, so go for it :)

Good to know. I'd been fairly intimidated by the idea.

I'll 2nd the code quality. I dug into the Mines code a while back as I wanted to use its puzzle generation algorithm to throw together a text-based version of the game. This turned out to be very easy to do.

Funny seeing this here as I've been thinking a lot about text-based browsers lately. Just a couple days ago I tried to build this one from source, but I put it aside due to the dependencies on PCRE and a JavaScript engine. (I am running a hand-rolled Linux "distro" so I can't just install ready-made binary packages.)

I do really appreciate that this one uses libcurl on the backend. Surprisingly few browsers do this--Lynx, Links, and w3m all have their own networking code. They have bespoke HTML parsing and rendering as well. I'm lately thinking I want to see a text-mode browser that just glues together libcurl, curses, simple HTML rendering, and maybe an existing HTML parsing library. No text-based HTML rendering library exists that I'm aware of.

Also these classic text browsers have their own implementations of FTP, NNTP, and some other legacy cruft. I'm thinking most of this could easily be provided by libcurl (if at all).

Reminds me of the well-known quote I always enjoyed, though I never looked much into the context:

"If something cannot go on forever, it will stop."

https://en.m.wikiquote.org/wiki/Herbert_Stein#Quotes

> Have there been? And why?

A few reasons why people might want to do this:

- Optimizing for small approachable codebase instead of featurefulness or performance (sbase)[1]

- Dissatisfaction with GPL (toybox)[2]

- Desire to replace C (described as an "unsafe" language) with Rust or Go (examples exist but I don't know of specific ones)

[1]: https://core.suckless.org/sbase/

[2]: https://landley.net/toybox/

One thing I've noticed about lists like these is that the tools are mostly flashy and feature-packed, almost invariably with colorized output, sometimes with funky Unicode symbols like check marks, and usually written in a fashionable language like Rust or Go.

Some of them, I've found, don't work too well on the Linux framebuffer console, which is where I spend most of my time. They seem to be designed with 256-color terminals in mind.

I get the appeal, but small and simple stuff written in C, with very few dependencies, is more to my taste. I'm wondering if there are many others who feel similarly.

Thinking of moreutils[1] as a classic example that solves problems not easily solved by the standard POSIX tools, but in a very straightforward and non-flashy way.

[1] https://joeyh.name/code/moreutils/

Good thoughts, thanks. This mirrors my own experience. The whole thing did seem very approachable to me. Pretty sure we had to implement a FORTH in a programming languages course I took back in college as well, so I had that basic familiarity with it.

Actually writing FORTH programs, on the other hand, is for me a real brain-bender. It seems to require a very different kind of thinking than does programming in C (for example).

Don't remember how I stumbled on this site, but it had to have been 15-20 years ago that I did. Was pleasantly surprised to see that it's still online and that the author is still singing the praises of DOS.

One thing I did not notice in the article is that the frequency of spam and scammers might make people more cynical and mistrustful of others in general. Just speculating based on my own experience. People treating me and people close to me like trash reinforces my belief that the world in general just sucks. And if I want to resist that attitude for the sake of my emotional well-being, I have to consciously go looking for counterexamples. It's tiresome.

In my own personal use-case: my backups include a file that contains a list of every file that is backed up and each file's xxhash.[1] So verification is as simple as running "xxhsum --check" on this file. This is a bit slow, but it's much faster than something like SHA-256. And I don't know what scheme would be significantly faster. I just threw this together to solve my problem of verifying backups, without doing much research into the problem.

The backup is to physical media so that makes this scheme easy. Don't know if or how this could be applied to online backups.

[1]: https://cyan4973.github.io/xxHash/

I find this kind of language positively disgusting:

> Your file will be reviewed

> A decision will be made

> If the file is found to be...

> ... restrictions will be removed ...

It is the archetypical "mistakes were made".

Note the constant use of passive voice, intended to hide the actor, and to keep you from even thinking about who is doing these things and thus who is responsible.

By the way, no better is the most likely alternative "Google will review...". I'll leave deducing the reasons why as an exercise for the reader.

> A disclaimer is when you state a reason why people might want to discount your opinion, usually due to a conflict of interest. E.g., "I work at Revolut."

I believe the word you both are looking for is "disclosure":

https://english.stackexchange.com/questions/115850/disclaime...

A tangential question, not addressed by the article: why is "true" now implemented as a binary written in C?

As expected, the GNU version is comically large[1], but even the "suckless" version is a compiled binary[2].

I'd guess that nowadays "true" is usually a shell builtin. Are there circumstances where the actual /bin/true gets called and that the overhead of forking off a shell to run it (the empty shell script) is too much?

[1] https://git.savannah.gnu.org/cgit/coreutils.git/tree/src/tru...

[2] https://git.suckless.org/sbase/file/true.c.html

Fun historical article.

I found this especially amusing:

> By March 22, 1880, the New York Times reported, “No pestilence has ever visited this or any other country which has spread with the awful celerity of what is popularly called the ‘Fifteen Puzzle.’ It is only a few months ago that it made its appearance in Boston, and it has now spread over the entire country. Nothing arrests it. Neither age nor sex is spared by it, and it now threatens our free institutions, inasmuch as from every town and hamlet there is coming up a cry for a ‘strong man’ who will stamp out this terrible puzzle at any cost of Constitution or freedom.”

Aside, as an enthusiast of tiny software, the first thing that came to my mind was the implementation of this puzzle on the original Macintosh, which fit into 600 bytes:

https://www.folklore.org/StoryView.py?story=Puzzle.txt

There's also a more modern implementation out there in the same spirit, for Xorg on x86 Linux. Supposedly it compiles down to a 1700-byte executable:

http://muppetlabs.com/~breadbox/software/tiny/puzzle.asm.txt

> When you make an extra copy of a song, you commit intellectual property theft

Don't forget "piracy"--associating copying information with looting a ship and killing everyone on board. I'd love to see an end to this ridiculous modern usage of this word.

Maybe an obvious one, but at my last org I often wished for more emphasis on keeping patch sets SMALL. I might have liked some kind of soft ban against putting huge patch sets up for review. I'm talking like 1000+ line stuff. In my experience, no one wants to review those; it's incredibly tedious.

I say "soft" ban because there are exceptions. I don't mind huge patch sets if the changes are proportionately trivial: One example is mechanical search-and-replace jobs on large codebases. But the 3000-line new module that just gets dumped on reviewers all at once is in bad taste. It's the responsibility of the author of the code to ensure that it is broken up in a way that makes reviewers' job tolerable. My opinion.

> Most machines of the time had 4Mb of RAM. Something seriously powerful had 16Mb.

Yes I did mean to write MB rather than GB; thanks for the correction.

On that note, I found this 1995 newspaper article (linked from Wikipedia) on the subject. Conclusion was that W95 ran on 4MB, but slowly:

https://archive.seattletimes.com/archive/?date=19950924&slug...

Funny that the writer remarks on having a bunch of Windows open and still having "73% resources free". I think I remember reading in one of the contemporary books (maybe Andrew Schulman's Unauthorized Windows 95) that the dialog that shows the % resources free inflates the number significantly.

Yes, I wrote GB but meant MB. (I suppose because the former is more common nowadays.)

Yes, thanks. Fixed

I appreciate the idea and the ease of use.

How is the key being stored? What would make sense to me is that the key is given in in the URL as a query parameter, so that it is not actually stored anywhere on the server side. But that doesn't look to be the case.

> We use AES encryption with a 4096-bit key.

I have never heard of 4096-bit AES. Typically the expert opinion I have heard on AES key lengths is that 128-bit is enough and that 256-bit is overkill reserved for the paranoid.

I am reminded of Bruce Schneier's warning sign #5 of cryptographic snake oil: ridiculous key lengths: https://www.schneier.com/crypto-gram/archives/1999/0215.html...

I don't mean to imply that this tool is "snake oil"--just that "4096-bit AES" is not a good look in light of the above advice from a highly respected cryptographer.

(On the other hand, 4096-bit keys are often used with RSA. But that is a different kind of algorithm with a different purpose.)