jstimpfle

It would probably have been the best alternative. I remember it felt similar to xterm, wasn't bloated as many others in the way I described. I don't remember why exactly it didn't stick for me, also don't remember any things it did better. One reason might have been compatibility -- out of the box, most programs work quite well with xterm.

I've been on xterm since I've started using Linux seriously in 2008. I probably wouldnt have tested it because was probably a bit obscure then like it is now. It's not perfect, it's baroque, has terrible configurability, no tabs and an ugly context menu. But it's honestly the only usable terminal, none other has stuck with me. Most are far too sluggish to even start up. Then there is key input latency. Then some of the newer ones are only usable with good gpu support, but not from a VM like Virtualbox or maybe VMware where graphics isnt working great.

Another thing for a very long time has been that most other terminals don't support bitmap fonts. This was/is critical for lower DPI monitors. Today I've mostly made the switch to TTF fonts.

__builtin_add_overflow() is type-generic as well, what is the big difference to this Rust stuff? I'd say Rust is more ergonomic here (standardized calls, I don't have to resort to GCC builtins). But it's not fundamentally different in capabilities.

I really don't care about functions vs methods, what is the difference, it's just syntax. Actually, keeping to regular function calls is mostly more readable to me, compared to using methods, using short unqualified method names, mixing function calls and methods calls, nesting/chaining functions and methods.

> The truth here is that you might want a lot of different operations and the C choice is not only to provide a single choice, which made a lot more sense 50+ years ago than it does today, but to provide a singularly bad default.

C has a single '+' operator, just like Rust has. And what that operator does depends on the types to the left and to the right. You can cast between integer types to achieve different behaviours depending on what you want.

About u8::unchecked_sub() etc, those are just regular functions. Not really a language thing. Yes, nothing of that is standardized in C AFAIK, but I'll happily use e.g. __builtin_add_overflow() or whatever in practice.

We can argue all day long what are the right defaults, checked or unchecked operations. If you want to be safe, you want the compiler to emit checks. It's probably possible to get some of those in GCC. If you want to emit streamlined machine code, you'll definitely not want to add checks after every machine instruction.

Signed quantities are a good default, and are easier to deal with when doing subtractions and mixing integers of different widths. (And integers includes pointers here, so it's very hard to not have different widths).

However unsigned integers are still very useful, I'd say essential, in low-level programming. For example when doing buffer management and memory allocation.

   - bitwise operations
   - modular arithmetic implemented with just ++, -- (ringbuffers, e.g TCP sequence numbers)
   - using the full range of a 8-bit, 16-bit, 32-bit datatype (quite common)
   - splitting a positive quantity into two smaller quantities, e.g. using a 16-bit index as 8-bit major index plus 8-bit minor index.

etc.

Don't forget that the signed vs unsigned integer is in some sense an artificial distinction. Machines have you put the distinction in the CPU instructions themselves, they don't track a "signed" property as part of values. And it can make sense to use the same value in different ways. However, C and many other languages decided to put a tag on the type, so operator syntax can be agnostic to signedness, and the compiler will choose the appropriate CPU instruction.

The way he conducted those interviews, and the conclusions he drew from them, may have been flawed. Because the situation now is that C has unsigned types and Java mostly has not.

And despite all pitfalls especially around mixing signed and unsigned in C, unsigned types are very useful, I'd in fact say that for low-level programming they are essential.

By adding to the language itself, you mostly make stuff worse. The major reason why C is useful is its quite stable syntax and semantics. Language is typically not the area where you want to add code. It's much better (and much easier) to invent function APIs. See how they shake out, if they're good you might get some adoption.

True, but you do incur potential data races _everywhere_. There's no relation to bounds checking specifically.

Bounds checks have nothing to do with data races. GP is right, you can add bounds checks. Either using macros or (in C++) with templates and operator overloading.

> Fun fact: wifi is not an acronym for anything, the inventors simply liked how it sounded.

Most certainly it's a reference to "Sci-Fi" or "Hi-Fi".

> If you’d like to argue that version control should be centralized, shallow, and sparse by default then I agree.

I get your sentiment, but I know how working with e.g. SVN feels. Just doing "svn log" was a pain when I had to do it. The "distributed" aspect of DVCS doesn't prevent you from keeping central what you need central. E.g. you can have github or your own hosting server that your team is exchanging through.

The main point of distributed is speed and self-sufficiency which is a huge plus. E.g. occasional network outages and general lack of bandwidth are still a thing in 2026 (and remain so to some extent for the foreseeable future).

Now, could git improve and allow some things to be staged/tiered/transparently cached better? Probably, and that's where some things like LFS come in. I don't have a large amount of experience in this field though, because what I work with is adequately served by the out-of-the-box git experience.

> Less and less people feel it, because people old-enough to have used branch-powered VCSes have long forgotten about them, and those who didn't forget are under-represented in comparison to the newcomers who never have experienced anything else since git became a monopoly.

I'm old enough to have used SVN (and some CVS) and let me tell you branching was no fun, so much that we didn't really do it.

Just because there is one project apparently using this in a way that indicates someone could perceive something as a weakness... It doesn't mean it's a real weakness (nor that it's serious).

You can just not move branches. But once you can do it, you will like it. And you are going to use

   git branch --contains COMMIT

which will tell you ALL the branches a commit is part of.

Git's model is clean and simple, and makes a whole lot of sense. IMHO.

Then just do git pull --unshallow whenever you see fit. I normally don't do --depth 1 because cloning repositories is rarely my bottleneck. Just saying that when you need a relatively fast clone time, you can have it.

Most code most people work on isn't about algorithms at all. The most straightforward algorithm will do. Maybe put some clever data structure somewhere in the core.But for the vast majority of code, there isn't any clear algorithmic improvement, and even if there was, it wouldn't make a difference for the typically small workloads that most pieces of code are processing.

I'll take it back a little bit, because there _is_ in fact a lot of algorithmically inefficient code out there, which slows down everything a lot. But after getting the most obvious algorithmic problems out of the way -- even a log-n algorithm isn't much of an improvement to a linear scan, if n < 1000. It's much more important to get that 100+x speedup by implementing the algorithm in a straightforward and cache friendly way.

git clone --bare --depth=1 https://github.com/torvalds/linux

Takes 21 seconds on my work laptop, indeed a corporate Windows laptop with antivirus installed. Majority of that time is simply network I/O. The cloned repository is 276 MB large.

Actually checking the kernel out takes 90 seconds. This amounts to creating 99195 individual files, totaling 2 GB of data. Expect this to be ~10 times faster on a Linux file system.

So what's your problem?

Now that is interesting too, because git is very fast for all I have ever done. It may not scale to Google monorepo size, it would ve the wrong tool for that. But if you are talking Linux kernel source scale, it asolutely, is fast enough even for that.

For everything I've ever done, git was practically instant (except network IO of course). It's one of the fastest and most reliable tools I know. If it isn't fast for you, chances are you are on a slow Windows filesysrem additionally impeded by a Virus scanner.

The hidden compile-time cost of <insert almost any C++ feature>

I've started out with a longer reply, but let's try and condense it a little: I concede you can still find this issue, especially on less than 4k displays, but it's becoming less and less of an issue, because of improving software. Where you see the issue, it's simply a software problem -- CSS or Chrome or the website/app should be fixed.

I don't see much of this issue anymore, on my 27" 4K screen, set to 175% scaling. It's logical that if you want to do arbitrary scaling or zooming, and want to keep all distance ratios perfectly intact, you will experience some ugliness from antialiasing (less and less noticeable as you go to ~4K and beyond). That will be so regardless of scaling, even when it's set to 100%.

So if it ought to look good, software simply needs to be written more flexibly! 1px in CSS doesn't mean 1 physical pixel but it is a (quite arbitrary) physical distance, defined as 1/96th of an inch. It's all up to the app and the software stack deciding line widths and how they will actually come out on a screen in terms of pixels lit. They should _respect_ the scaling setting (like 150%) but they also are in full control, in principle, to make it look good.

<hr> lines come out are perfectly fine on my screen (175% 4K) with Firefox and Chrome.

1.5px width lines will come out quite bad with 100% scaling, but will look perfect with 150% scaling obviously.

Notice that vector fonts generally look better if you have a reasonably high-dpi display. But on average, it doesn't matter if you test font sizes of 20pt or 21pt or 17pt or whatever. Why is that? Because font rasterizers already snap to pixels. They properly quantice geometric objects. They don't make arbitrary stubborn choices like "it must be exactly 1/96th of a virtual inch wide" but they are a little flexible to fight antialiasing.

And the more higher DPI monitors there are, the less software will be making stubborn choices.

I'm one of those people who are super sensitive to the issues you describe, and let me tell you this: Scaling value (like 150%) is just an integer number.

For the most part, non-ancient renderers (3D but also to a large degree 2D renderers), do not care about physical pixels, and when they do, they care the same amount no matter what the DPI is.

Raster data has a fixed number of pixels, but is generally not meant to be displayed at a specific DPI. There are some rare applications where that might be true, and those are designed to work with a specific display of a given size and number of pixels.

It's especially older applications (like from the 90s and 00s) that work in units of physical pixels, where lines are drawn at "1 pixel width" or something like that. That was ok in an age where targetted displays were all in the range of 70-100 DPI. But that's not true anymore, today the range is more like 100 to 250 or 300 DPI.

One way to "fix" these older applications to work with higher DPIs, is to just scale them up by 2 -- each pixel written by the app results in 2x2 pixels set on the HiDpi screen. Of course, a "200%" display i.e. a display with 192 DPI should be a good display to do exactly that, but you can just as well use a 160 DPI or a 220 DPI screen and do the same thing.

It's true that a modern OS run with a "scaling" setting of 150% generally scales up older applications using some heuristics. Important thing to notice here is that the old application never considered the DPI value itself. It's up to the OS (or a renderer) how it's doing scaling. It could do the 2x2 thing, or it could do the 1.5x thing but increase font sizes internally, to get sharp pixel-blitted fonts when it has control over typesetting. And yeah, some things can come out blurry if the app sends final raster data to the OS, and the OS just does the 1.5x blur thing. But remember, this is an unhappy situation just for old applications, and only where the OS receives raster data from the App, instead of drawing commands. Everything else is up to the OS (old apps) or the app itself (newer, DPI-aware apps).

For newer applications, e.g. on Windows, the scaling value influences nothing but the DPI value (e.g. 150% or 144 DPI) reported to the application, everything else is up to the app.

> which means you have subtle display artifacts.

No. 150÷ just means 96dpi * 1.5

I've had a keyboard like that and with it, xterm (and nothing else) felt like it was displaying the characters even slightly before I had pressed them. It was a weird sensation (but good)

If you're typing just one character per second you'll still feel the difference. Latency is stress inducing.

How so?

With regards to Linux kernel implementation, I could map you out a list of sequence points caused in the kernel by above sequential "shell script", proving that no other process could observe d and then a using two subsequent "stat" calls. I could imagine that a single directory listing (getdents) could happen to first visit a and then d, though -- I don't know the internals of that.

With regards to POSIX specification, I don't know the details but anything less than that guarantee would be very a huge robustness problem.

Assuming that the two `mv` commands are run in sequence, there shouldn't be any possibility for a and d to be observed "at once" (i.e. first d and then afterwards still a, by a single process).

why is this being downvoted? If there's something wrong, explain?

I don't think that's happening in practice, but 1) it may not be specified and 2) What you say could well be the persisted state after a machine crash or power loss. In particular if those files live in different directories.

You can remedy 2) by doing fsync() on the parent directory in between. I just asked ChatGPT which directory you need to fsync. It says it's both, the source and the target directory. Which "makes sense" and simplifies implementations, but it means the rename operation is atomic only at runtime, not if there's a crash in between. It think you might end up with 0 or 2 entries after a crash if you're unlucky.

If that's true, then for safety maybe one should never rename across directories, but instead do a coordinated link(source, target), fsync(target_dir), unlink(source), fsync(source_dir)

> That's where the standard should come in and say something like "starting with C++26 char is always 1 byte and signed. std::string is always UTF-8" Done, fixed unicode in C++.

> I never said always

Yes you totally did. And regarding "add some new methods for which it has to be UTF-8", there is no need at all to add UTF-8 methods to std::string. It would be a bad idea. UTF-8 is not bound to a particular type (or C++ type). It works on _any_ byte sequence.

std::string _cannot_ be made "always UTF-8". Is that really so contentious?

You can still use it to contain UTF-8 data. It is commonly done.

First, because of existing constraints like mutability though direct buffer access, a hypothetical codepoints_size() would require recomputation each time which would be prohibitively expensive, in particular because std::string is virtually unbounded.

Second, there is also no way to be able to guarantee that a string encodes valid UTF-8, it could just be whatever.

You can still just use std::string to store valid encoded UTF-8, you just have to be a little bit careful. And functions like codepoints_size() are pretty fringe -- unless you're not doing specialized Unicode transformations, it's more typical to just treat strings as opaque byte slices in a typical C++ application.