chriswarbo

How long do you spend on transit that most of those are necessary?

Toilets are useful immediately (speaking from experience!)

Tables are useful even on short trips of a few minutes; e.g. I usually have a notebook and pen in my pocket, and writing much easier on a table (even the little fold-out ones, if I can't get a seat at the proper tables).

I often eat on trains; though I admittedly tend to avoid the dining options, since it's much cheaper to bring my own food and eat my seat's table (fold-out or otherwise). If I'm with others, we can also drink alcohol together, without a "designated driver" having to abstain.

The Nix commands have a decent approach: passing `--help` will invoke `man` on the relevant manual (sub-commands tend to have individual man pages).

Define "nicely".

For example, many pagers don't work well when stdin is line-buffered (they assume they'll see individual key presses as they happen)

Pagers can also conflict with keys that the terminal emulator is using for a different purpose. This is especially annoying when the terminal emulator is using those keys for pager-like functionality in the first place!

An example of both of these is Emacs `shell-mode`.

(I personally set `PAGER=cat` in my Bash profile, which avoids most of these shenanigans)

Why would anyone working on such code send it anywhere (other than, say, to AWS for hosting)?

Source: I work on such code. We don't allow devs to use (cloud-based) LLMs.

This doesn't seem to account for Jevons paradox: if driving is made faster and more convenient, then more people will drive more; which can lead to an overall increase in CO2 emissions, collisions, etc.

I'd imagine there would be a lag between the initial efficiency increase, and the subsequent usage increase; since drivers (current and potential) would have to actually notice the change and adjust for it (consciously or otherwise).

Most cars can fit 5 people

So you agree that most cars are far larger and heavier than required? First search result for "average car occupancy"[1]:

In 2022 the Average Number of Occupants Per Trip for Household Vehicles in the United States Was 1.5

This discrepancy is the reason for car pooling, ride-sharing, etc. (Note that Uber, Lyft, etc. are taxi services, not "ride sharing"; since the drivers themselves are not typically intending to travel the routes they drive)

roads also carry buses

Yes, which is why cars should be removed from such roads, to avoid slowing down buses.

ambulances

Emergency vehicles can drive in places where cars are forbidden (cycle paths, pedestrianised roads, etc.)

trucks that carry every single product* in the economy.

Again, you're undermining your own argument: the subsidies given to private car infrastructure are so large, that freight companies exploiting that infrastructure can end up more cost-effective than those which use rail; despite rail being more efficient not only in terms of fuel, but also in terms of labour (since so many trucks would be required to do the job of a single freight train, and each of those trucks require a separate driver). Also note that heavier vehicles degrade the road infrastructure disproportionately; which is even more reason to reduce the number of trucks as far as possible.

[1] https://www.energy.gov/cmei/vehicles/articles/fotw-1333-marc...

If every road were free of traffic, every destination had unlimited parking at the door, everyone already owned a car, and driving carried no direct or indirect costs, almost everyone would drive everywhere.

Cars don't even have tables; let alone toilets, dining areas, sleeping cabins, etc. Even those which do (e.g. RVs) would require a solo traveller to stop in order to use them.

No thanks, I'll stick to the train.

I was responding to this part:

if our universe is undecidable

My point is, there would be no way to empirically test this; and therefore, it would make no observable difference, there would be no way to exploit/utilise such effects, etc.

In essence: there's no way to tell the difference between a real halting oracle (which would imply an undecidable universe), versus a computable approximation which just-so-happens to be more powerful/sophisticated than the approximations we compare it against.

Sure, we can prove that some abstract systems are undecidable and that others aren't. Yet that distinction is inherently unfalsifiable, and hence physically "useless".

I think the day needs time units which are factors of 10x or 1000x to match SI prefixes

The nice thing about metric/SI prefixes is that they're generic multipliers, which can be used with any units we like. If you want to use them with day as the unit, you can just do that; nothing extra is required, and the meaning is clear (though unfamiliar!).

There is an alternative approach though: we could use prefixes for sexagesimal multiples (base 60). This has precedence, since we have a system of binary prefixes like "kibi" and "mibi".

For divisions, we can use the standard progression of "minute", "second", "third", "fourth", etc. to say there are 60 minutehours in an hour (or more generally, 60 minutefoo in a foo); that there are 3600 secondhours in an hour; and so on. Abbreviating "minutehour" to "minute" and "secondhour" to "second" when we're talking informally about time would be similar to abbreviating "kilogram" to "kilo" when talking informally about mass.

I'm not aware of any standard names for multiples (rather than divisions). My proposal[1] is “prota” for 60x, “defter” for 60x60x, “trito” for 60x60x60x, and so on; as Greek alternatives to the Latin "minuta", "secundus", "tertia", etc. (which "minute", "second", "third", etc. are derived from[2]). This Greek/Latin combo would match the multiply/divide naming of decimal, e.g. kilo (x1000, Greek) vs milli (/1000, Latin), hecto (x100, Greek) vs centi (/100, Latin), etc.

That would make an hour equal to protaminute, or one deftersecond.

[1] http://www.chriswarbo.net/projects/units/prefix_factors.html

[2] AFAIK the naming comes from "pars minuta" meaning "small part", with further divisions being "second small part", "third small part" and hence giving us "seconds", "thirds", etc. For consistency, we should really use "firsts" instead of minutes (or maybe "primes" from the Latin "prima").

There's no way to empirically spot an uncomputable process, since it would require infinitely-many observations.

For example, if aliens claim their machine solves the halting problem, we could test it on millions of inputs whose halting/not-halting behaviour we already know; but even if it works for all of them, there's no way to know that it works for all inputs. For all we know, it might be a huge lookup table which happens to cover all of those inputs we tried.

Information and computation are not the same thing.

Shannon information, sure.

However, algorithmic information (Kolmogorov complexity, etc.) is based on computation.

They're not tied to anything physical; but they are a mathematical sweet spot.

24ths and 60ths are useful fractions because 24 and 60 are highly composite numbers, i.e. they have many divisors. 60 is a particularly good choice, since it's a "superior highly composite" number; and so is 12, if we consider an AM or PM period, rather than a full rotation.

Such divisibility was important before the invention/discovery of general fractions (i.e. the rational numbers). Babylonian arithmetic used something akin to base 60 floating-point, which could represent halves, thirds, quarters, fifths, and their sums and products (but not e.g. sevenths, or reciprocals of higher primes; in the same way base 10 floating-point can't represent a third).

Minute, meaning "small", describes the shifting of the radix point in such a base 60 floating-point system. Second, as in the ordinal 2nd, describes a further shift of radix point; and likewise for thirds, fourths, etc. for ever-smaller increments.

I tend to run all my terminals in Emacs, which TUIs tend to interfere with (e.g. providing their own keybindings which clash with those of Emacs; providing their own panes/scrollbars/etc. which don't have any of the functionality that Emacs provides; etc.).

I'd much rather have application functionality provided by a CLI, over stdin and stdout; and have Emacs provide its TUI-like layer on top.

I don't mind short-lived TUIs, like config wizards; but would still prefer a CLI that prints a few lines to stdout and reads text from stdin; rather than curses-like things that attempt to print whole "screens" at a time, and are driven by a mess of control characters and internal state.

The worst ones are those that (a) want to live for a long time, and (b) hammer the terminal with updates despite no user interaction taking place. These AI agent TUIs tend to be the most obnoxious; e.g. having a bunch of "spinners", which would traditionally be placed at the end and updated using backspace, but for some reason these AI companies have implemented by redrawing the entire screen, based on some HTML/DOM/React layout algorithm; with the result being a whole bunch of CPU & RAM spent, and a headache from staring at the flickering mess it draws.

I think the slider would be recognized as a toggle in its usual context of a settings screen by most people who have seen a settings screen before, but not that specific design for a toggle.

I've been using computers since the early 90s; we got our first home computer when I was four; I've used many different operating systems.

As a professional Web developer, it took me an embarrassingly long time to figure out what those slider widgets are supposed to mean. It's still very easy to get them wrong/confused (both as a user, and as the designer/dev making the form), e.g. when the affirmative state involves a negative setting, like "Mute" (does "on" mean "muted"; or does "on" refer to the audio, which I can use this to mute?)

In Windows 95, those toolbar icons were still actual buttons. In Windows 2000, they are recognizable as a button when activated, but in their default state they're not and you have to hover over them:

This is something I've struggled with as toolkits change and old widget themes stop working. There are still some decent themes out there (e.g. Skulpture for Qt has been my default for many years), and with a little patching they can be dragged into working on the latest toolkit versions. Yet I can't seem to avoid this "you have to hover over to see that it's actually a button" behaviour. Very annoying!

I've switched my git projects to push their objects into IPFS and their refs to pkkarr. That feels more distributed than the sorts of HTTP servers mentioned in TFA.

Anybody who cares about my repos potentially disappearing can contribute to their hosting by re-providing those repos from their own machines. (Note that only someone with the private key can create new records for a pkarr address).

That's mostly a side-benefit though: I mostly wanted something I can `git push` and `git pull`, that is self-hosted, and self-organises across a bunch of underpowered machines with unreliable network connections, with minimal coordination.

the same principles apply to US dollars

Currencies are a little different, since they are required to pay taxes; and payment of taxes is enforced (to varying degrees) by state violence.

Hence if you believe you will be taxed ("death and taxes" being the only certainties in life, etc.) then the currency associated with that tax has value, in that it avoids imprisonment, etc.

Isn't Not Just Bikes some US expat/biking maximalist?

According to their videos, they prefer trams within cities; generally take trains between cities; and acknowledge that cars are very useful for places which aren't so well connected (e.g. places that are far apart which aren't on a train line). They think encouraging the use of cars within cities is a bad idea (dangerous, scales poorly, makes those areas less pleasant to be, etc.).

Not what I'd think of as a "biking maximalist".

They do show themselves cycling to places that are nearby. Does that make Youtubers who record videos in their car "driving maximalists"?

I didn't want to read a whole ton of text and C code details

There's no C in there? It seems to be Python and shell scripts.

I don't have any answers or strong opinions yet, but I feel like the legal/societal conversation should focus on "actions taken via XYZ" rather than "technology underlying XYZ". Similar to how GDPR, etc. cover actions like collection/storage of personal information, not specific technologies like cookies (despite what many believe!).

In particular, your examples bring these things to mind, which might be worth considering alongside:

- Any machine can host a server, with no third-party required except an ISP (if we're being pedantic, even that's not needed if use a mesh network, etc.). The main barrier to connectivity IME is NAT, but there are ways around that (e.g. make it a .onion service). I played with all of the above as a teenager, so it's not unrealistic.

- "Hosting a website" covers a lot of things, some of which are already illegal (e.g. CSAM). Just because we can spin up something without jumping through social media sign-up hoops, doesn't mean it can't/shouldn't be subject to legal questions.

- Hosting a website/blog/etc. does not come with the same questionable baggage as social media (algorithmic feeds, PII, tracking, identity verification, communication, etc.). We might opt in to such things, e.g. by accepting comments on posts, but I'd distinguish such two-way, "user generated" activity from merely "hosting a website". Technologically, such things require some dynamic system (usually a self-hosted or third-party backend), rather than "just" a static HTML server.

- There is no technological difference between a blog used like a personal diary, and a blog used to post reviews of Lego. Is there a societal difference? What about if they include photos?

- Posting things on a personal website/blog has an implicit understanding that it's being published and shared with the world (that feels like the whole point of a blog). Social media has muddied those waters, by claiming things like "privacy settings", which can give the impression that posts are not being published and shared with the world.

- When it comes to activities like receiving comments, two-way communication, unsolicited messages from anonymous strangers, etc. the more relevant "basic tech" feels like running a server for email, IRC, Jabber, etc. rather than a web site; since those place such "dangerous" aspects front-and-centre. Email is the most obvious, but I mention the others since getting external systems to trust a self-hosted email server is notoriously tricky!

btw, Git also supports the HTTP protocol ...

In fact, Git supports any protocol! If you add a git remote like

    git remote add my-remote my-super-duper-protocol::some-sort-of-address-thingy

I use remotes like "pkipfs::y5a9inx61aski4miz4sgmg55qgbazxhfwab3i6ee1ypa6rnumi8o", which invokes a custom git-remote-pkipfs command that pushes/pulls object data to IPFS and resolves/updates refs as subdomains of a specified pkarr address.

Whenever I try something else, I always seem to keep going back to E16. Back in the day, it worked well in Gnome 2.x; these days I tend to use it in XFCE, but it feels a bit less integrated.

Exactly the same thing happened when git showed up (alongside the same things for bzr, darcs, hg, etc. too!)

https://git-scm.com/docs/git-worktree

I suppose it depends what you mean by "horribly break things".

The only thing I've noticed is that `jj` will leave the git repo with either a detached HEAD, or with a funny `@` ref checked out.

I don't think that would trouble someone who's experienced with git and knows its "DAG of commits" model.

For someone who's less experienced, or only uses git for a set of branches with mostly linear history (like a sort of "fancy undo"), I could imagine getting a shock when trying to `git commit` and not seeing them on any of the branches!

It wants me to start with the new and describe command

jj doesn't "want" anything.

I always end a piece of work with `new`: it puts an empty, description-less commit as the checked-out HEAD, and is my way of saying "I'm finished with those changes (for now); any subsequent changes to this directory should go in this (currently empty) commit"

The last thing I do to a commit, once all of its contents have settled into something reasonable, is describe it.

In fact, I mostly use `commit` (pressing `C` in majutsu), which combines those two things: it gives the current commit a description, and creates a new empty commit on top.

I often find that in the process of making one change, I have also made several other changes, and only recognize that they are distinct after following the ideas to their natural conclusion.

I do that all the time. With git, everything starts "unstaged", so I'd use magit to selectively stage some parts and turn those into a sequence of commits, one on top of another.

With jj I'd do it "backwards": everything starts off committed (with no commit message), so I'd open the diff (`D` in majutsu), selecting some parts and "split" (`S` in majutsu) to put those into a new commit underneath the remaining changes. Once the different changes are split into separate commits, I'd give each a relevant commit message.

Tooling can support both (e.g. don't assume all hashes have the length of a SHA1, etc.); but they can't be used together in one repo.

Haskell has a package to make testing this sort of thing easier https://hackage.haskell.org/package/inspection-testing

Pipelines are usually built up step by step: we run some vague, general thing (e.g. a `find` command); the output looks sort of right, but needs to be narrowed down or processed further, so we press Up to get the previous command back, and add a pipe to the end. We run that, then add something else; and so on.

Now let's say the output looks wrong; e.g. we get nothing out. Weird, the previous command looked right, and it doesn't seem to be a problem with the filter we just put on the end. Maybe the filter we added part-way-through was discarding too much, so that the things we actually wanted weren't reaching the later stages; we didn't notice, because everything was being drowned-out by irrelevant stuff that that our latest filter has just gotten rid of.

Tricks like this `\#` let us turn off that earlier filter, without affecting anything else, so we can see if it was causing the problem as we suspect.

As for more general "why use CLI?", that's been debated for decades already; if you care to look it up :-)