Firstly, I think you're taking this waaaayyyy more seriously than it was intended. Secondly
double foo = 1.2;
printf(foo);
puts(foo);
won't compile, while
double foo = 1.2;
display(foo);
works fine.
Incidentally I actually think display is the only thing on this list that is probably worth using, you could also probably extend it to accept multiple arguments relatively simply as well.
Specifically, printf is an oddball function because it uses the varargs mechanism, and the whole format strings mechanism is inherently risky because it effectively bypasses the type system and says "trust me." Back when I was learning C, on a Mac with THINK C, misusing printf was a sure-fire way to crash the computer very quickly, especially since misaligned accesses of 16-bit or 32-bit words caused crashes. Compilers now go to a great deal of trouble to try to do additional safety and consistency checks.
Don't get my wrong, I grew up using printf, and it is massively useful. But it was designed when computers were much smaller and simpler, and design tradeoffs were made back then that probably wouldn't be chosen today. So printf, along with a whole family of related functions, has been a seething mess of a security and safety hole longer than most programmers have been alive.
The popular C compilers have a feature where they will do some additional type checking on the arguments passed to "format" functions. You can mark your own functions with this attribute.
printf is not an oddball function. Also, typechecking format strings in general does not have to be that complicated. They are still used in golang.
Of all the security pitfalls of C, the format string design of printf is way down the list. As others have noted, printf is not what makes the C type system weak.
Sure, but that's varargs being the special cased but, not printf (I've written printf implementations for some ebedded systems, it's always just regular C code).
This works for a literal, but the author was probably thinking of "print a string that comes from somewhere else" where you do the first thing to avoid format characters to be interpreted.
The point is, for simple things, to not have to specify how they appear.
> Well... Because it should have been
> printf("Hello, World!\n");
No. You don't really want to do that. If you're doing that, use puts [0] . All this requires is a modification to one string in memory and you have an injection vulnerability.
GCC automatically replaces printf("foo\n") with puts("foo") even with -O0. Clang does it too, albeit I have to enable optimizations: https://godbolt.org/z/drw4xP . As a result I never use puts for literal strings, this way if I want to add dynamic parameters later I don't have to change the function call.
I'm pathologically lazy.
Also as others point out typically the literal string will be in a ro segment so tampering with it won't be easy unless the code runs in a rather exotic environment.
The good practice that you seem to have read about and badly misunderstood is that the format string argument to a printf family function should always be a string literal right there in the code calling it. The concept of changing printf("foo") to printf("%s", "foo") for 'security' against your own hardcoded string literal is more bizarre than any of the intentionally bizarre convolutions in your posted project.
No, a format string attack. If you replace the start of the string with various specifiers, you can lift out pointer addresses and write to them. You can't do that with puts. Worst you can do with puts is read.
puts()'s attack surface is smaller than printf()'s.
This is not how your message appeared to me - "printf() is vulnerable to injections, use puts() instead". Both are vulnerable to "unintended read()-s".
printf is vulnerable to both read and _write_ attacks when you misuse it by only supplying the single argument. It's vulnerable to injections that can lead to remote execution and all sorts of CVEs.
puts is sometimes vulnerable to read attacks, but not often.
That's not UB, that's implementation dependent, AFAIK the C standard says nothing about read-only memory. Attempting to modify a string literal is indeed UB but that would only happen if an attacker managed to attempt to modify the string, not when the program is used normally.
Other important security features like N^X are also not specified in the C standard either, so what's the point of worrying about just printf format strings?
TBH it’s not pedantic to understand the difference between undefined, implementation-defined, and unspecified behavior. It’s part of knowing the language. One of my standard interview questions for C candidates is to ask them to describe and provide an example of each.
Is there really a meaningful difference between implementation-defined and unspecified? I'd say they're shades of gray based on how pedantic the compiler documentation is.
Is it really not UB to attempt to modify RO things? Typically (on major implementations, e.g. GNU/Linux or MSVC/Windows) it will crash, and I don't think it is allowed to crash on non-UB things?
In order to modify that string, even in RW pages, the attacker already has to have access, at which point the point is moot. It's like saying "if you can change memory, then you can change memory"....
They are nearly equivalent in terms of functional security.
Function isn't everything though. One example shows an awareness of the security issue and good habit being used despite the low impact. I'd argue that there is a security benefit to using one over the other.
Additionally, it's not as simple as saying "if you can change memory, then you can change memory". Memory exploits are quite often chains of small issues these days and not the simple buffer overflow of old.
For example, being able to overwrite one byte somewhere could lead to the ability to change only part of a variable address. That could be used to redirect a write to the constant string in memory.
Sure it's contrived, but scenarios like this do happen.
shows an awareness of the security issue and good habit being used.
printf("%s\n", "Hello, World!");
shows that you think "%s\n\0Hello, World!" (or however the compiler decides to lay out those strings) can't be overwritten with "%p%nHello, World!" (or something to that effect), but "Hello, World!\n" somehow can.
We've spent the last 20 years cleaning up after the shoddy work of people (like you) who think avoiding the deficiencies of a thin wrapper over assembly is just a matter of good habits, rather than actually understanding what the hell they're doing.
And breaking up constants into misordered, mishmashed fragments isn't even a good habit in the first place.
Edit: Come to think of it, given that the original complaint was:
> > printf("Hello, World!\n");
> [...] All this requires is a modification to one string in memory and you have an injection vulnerability.
There's also the fact that it's you who is arguing in bad faith, since a: habit wasn't part of it to begin with, and b: you haven't given any example of a case where a habit of writing `printf("%s\n","<some text>");` rather than `printf("<some text>\n");` is useful for anything whatsoever, security or otherwise.
By that same logic, puts("Hello, world!"); is also vulnerable to DoS attack and information leak since someone could have removed the NUL terminator at the end of the string and have puts() read uninitialized/unmapped memory. Which is absurd logic.
In a lot of cases the attacker can only write to a limited range of memory addresses. If that string happens to fall in that range, they can use it to write to other addresses and/or find out where in memory certain things are stored.
So their ability to write to a limited range of addresses can be extended to a larger range.
It's also not defined whether the executable code is in RO memory or RW memory. By your argument, we should also be concerned that the attacker could modify the code directly.
While I'm not a fan of the specific changes shown in this article, I do agree with the principle of "remove boilerplate when possible". I found that the largest amount of boilerplate I ever wrote was in main() to parse the command line, and to that end I wrote a "magic getopt", which handles both short and long options in-line without external tables (https://www.daemonology.net/blog/2015-12-06-magic-getopt.htm... ); and PARSENUM, which handles the common cases of parsing human-readable values while appropriately checking for overflow (https://github.com/Tarsnap/libcperciva/blob/master/util/pars...).
I know it's bad preprocessor magic, but I kinda liked that. I thought about hacking together a quick "Oberon-ish" to JS "transpiler" for a while, of course going along with a decidedly Wirth-ian code style. I might call it "werenotwirthy".
But there's also the appeal of the dreaded Incunabulum...
This particular code isn't about the post. It's about Bournegol, which doesn't actually exist anymore, and is actually quite hard to track down any examples of.
It's...not, though? The Bourne Shell was released under a free license years ago along with the rest of v7, and it's just a macro hack. Very much still exists, and pretty easy to find.
On C language an expression which evaluates to any non-zero value is considered as True. So for example this kind of statement would not likely behave as intended:
To emphasise: This is about Bournegol. Nothing to do with this post.
> Can you explain why?
Because it isn't how most C libraries expect true/false to be defined.
stdbool in C99 standardized things a bit, but before then what was generally accepted was:
> true is 1
> false is !true (Often 0 in practice).
Which means that any trivial:
if(true) { ... }
Won't work under Bournegol. Instead you _need_ to compare when doing an if statement.
So the C-programmer is easily tripped up. False will work as expected, but True won't... All the time. There may be times it does work. Leaving the programmer throwing their hands in the air.
Most cases I've seen accept anything as true as long as the LSB is 1, and quite strictly 0 as false. Everything else is up in the air. The value -1 is definitely true. :)
As far as I know, std library specifically uses the word "nonzero" in the documentation to denote non-false value. Therefore you should be using !, &&, || for any boolean ops, but never == nor !=
This just in: you can write bad code in any language.
In this case, that language is the C Preprocessor, already well documented and widely accepted as a Bad Language To Start With.
The title of the article is misleading: it's not "destroying C" it's writing Bad Code using the C Preprocessor. It's not destroying C any more than a series of bad puns destroys the English language.
I've been a C programmer for several years now (out of necessity - C is still the best language for firmware and embedded development)
There's been a lot of noise on the internet about Rust and C++20 and "modern" languages. I recently had an opportunity to try some of these first hand.
Honestly the new language features are all terrible with few exceptions. In general, anything that was added to a language to support generics or to hide pointers and memory management from the developers on a language that isn't a lisp has only produced more harm than good.
I grew up as a programmer always thinking about the underlying CPU and the underlying memory and how my code would interact with both of them. It requires greater care as a programmer and tools like static analysers, code reviews and rigorous testing are extremely important. Improving these tools and coming up with new ones is far more useful (in my opinion) than trying to update C.
Yes C has it's flaws. Sometimes, those flaws are important and a replacement language is useful. I find that Go is a very interesting replacement for C at sufficiently higher up the stack. Something like Haskell probably will best fill in the gaps between C and Go.
I'm not convinced that fixing C with something like C++ was a good idea. Similarly, anything that's trying to fix C++'s problems is unlikely to come up with a decent way to have generics and hide memory and pointers from developers.
If I was going to create my own language, I'd keep it like C, remove some of the undefined behaviors, add support for Posits, 128 bit and arbitrarily wide signed and unsigned integers, features for explicit cache management (!!!), container classes as part of a standard library, Go-lang style interfaces and bake in something like cppcheck into the compiler.
> I grew up as a programmer always thinking about the underlying CPU and the underlying memory and how my code would interact with both of them. It requires greater care as a programmer and tools like static analysers, code reviews and rigorous testing are extremely important.
This is the double-edged sword of C and other lower level languages though. The programmer is given great power over their environment, but as the saying goes with great power comes great responsibility. Not all programmers are capable of handling that responsibility, and even those who are make mistakes from time to time. If you don't need the power, there's a strong case to be made for giving some of it up in exchange for also reducing the number of ways you could misuse it.
There will always be a place for low level programming in performance-critical code or extremely resource constrained environments, but there's a lot of software out there that spends most of its time waiting on I/O or user interaction while running on systems with gigabytes of free RAM and a half dozen idle cores. In those cases I believe the use of safer languages should be encouraged.
I understand it's against the rules to suggest someone hasn't read the article.
But I think it's pretty clear from this comment that the article has zero to do with the posted article. The article's title was provocative and humorous, bc it's abt using C in a very peculiar way. It's not about the tired argument of "should we replace C with Rust/etc." which the above poster and many others have glommed onto. This waterfall of irrelevant comments has no place next to this article which is abt a very specific, interesting set of techniques.
There was a great talk from a C/C++ compiler writer about why you can't remove undefined behaviors while at the same time keeping C like speed.
Simple example: accessing an array past it's end it's undefined behaviour. If you want to remove this, you need to add bounds checking (either to raise an error or to just return 0).
> There was a great talk from a C/C++ compiler writer about why you can't remove undefined behaviors while at the same time keeping C like speed.
I don't think this is true. Look at Zig, they don't seem to have a problem removing a lot of C's undefined behaviour, while still being able to surpass C in speed in many cases.
> Simple example: accessing an array past it's end it's undefined behaviour. If you want to remove this, you need to add bounds checking
Zig does indeed do bounds checking. I think the way it can still compete with C is:
- Zig should be better at propagating constants (Better module system, Link-Time Optimization by default, and I think avoiding undefined behaviour helps here too). Arrays/slices do often have constant bounds.
- You can choose to build with or without bounds checks (--release-safe, --release-fast). This means you're more likely to discover out of bounds problems during debugging, since you'll always get errors in those cases. But you have the option to release a fast version.
Julia has another interesting solution to bounds checking, where you can mark a piece of code with @inbounds to declare that you assume array access is within bounds.
I think some undefined behaviour can also be detrimental to performance. If you pass two pointers to a function, and it's undefined whether they alias or not, there are optimisations you can't do.
> I think some undefined behaviour can also be detrimental to performance. If you pass two pointers to a function, and it's undefined whether they alias or not, there are optimisations you can't do.
I think this results from a misunderstanding of how undefined behaviour works in C. When a program exhibits undefined behaviour it is not a valid C program. The compiler may just assume (instead of having to prove) that it doesn't happen.
Example: the memcpy(3) standard library function. C says the behaviour is undefined if the given areas overlap. That means the implementation can perform optimizations "knowing" that there is no overlap. A valid C program can't possible invoke memcpy with buffers aliasing each other (because then, the program would be invalid). The compiler is not required to issue a diagnostic about these kinds of incorrect programs and just compiles your code assuming they don't exist.
> you can't remove undefined behaviors while at the same time keeping C like speed.
This is absolutely correct. The specs of C allow so much undefined behavior in order to let the compiler just emit the instructions for the arithmetic operation or memory access or whatever. For edge cases like overflow and bounds, C deliberately says "not my problem" and you just get whatever that hardware architecture happens to do with that instruction. It's a deliberately leaky abstraction.
It's more that things were left undefined for portability and compiler authors (ab)used them for optimization enough for that to become de facto true (especially now that portability is easier).
And if all C users decided that, now that portability is much easier, it was time to define some of that behavior, it would happen.
But, as much as people want to blame optimizing compilers for their behavior around UB, absolutely no one is going to sacrifice C's performance for safety.
Only if you define it to be something dumb like an error or returning 0. It should instead be defined as the hardware behavior: a load to the resulting linearly-calculated address which enters an implementation-defined exceptional state (e.g. SIGSEGV/SIGBUS) if that address does not represent readable memory.
There are a lot of undefined behaviors that only exist out of inertia and laziness. For example there's a bunch of things that should be syntax errors that are instead UB.
> Simple example: accessing an array past it's end it's undefined behaviour. If you want to remove this, you need to add bounds checking (either to raise an error or to just return 0).
What's wrong with saying "it will either return an unspecified value or trap"?
> In general, anything that was added to a language to support generics or to hide pointers and memory management from the developers on a language that isn't a lisp has only produced more harm than good.
I understand why you would want explicit memory management, but what specifically is harmful about generics?
Have you looked into Zig (https://ziglang.org/)? It's a little more than what you've asked since it does support compile time generics. But is specifically targeted at removing undefined behavior and improving safety.
I can second this recommendation. Zig is really the best language I seen so far at attempting to be a direct replacement to C (Rust is good too, but maybe a bit too advanced.. feels more like a C++ replacement)
The compile time generics is kind of necessary to replace some of the stuff people use C preprocessor macros for. I think Zig is just taking the idea of having compile time evaluation of code to its natural conclusion, and it ends up being a lot cleaner than C with preprocessor magic.
The only thing they've added which isn't necessary for a "better C", is the async stuff they're working on now. But I think it's still a good idea.
For embedded, C++ can still be useful. You just won't use most of it. I still like using classes; destructors can free up more resources than just memory. But yes, you can get most of what you need out of C.
I also suspect that Haskell fits above Go, not between Go and C.
Other than that, I'm pretty much in agreement with you.
Even a subset of that would be amazing to me -- "removed all of the undefined behaviors, added 128 bit signed and unsigned integers, features for explicit cache management (!!!), and container classes as part of a standard library"
> I grew up as a programmer always thinking about the underlying CPU and the underlying memory and how my code would interact with both of them. It requires greater care as a programmer and tools like static analysers, code reviews and rigorous testing are extremely important.
And yet, even projects filled with extremely strong engineers who participate in all the best practices and run interprocedural static analysis and sophisticated fuzzers still write piles of security vulns in c programs.
In particular: "remove some of the undefined behaviors"
I think the confusion caused by this is not nearly worth the optimization gained.
Compiler folks will say "but look, this loop is 58% faster!" but ignore the fact that slow code can be optimized through other means, including profiling, restructuring, etc.
Or avoid them when your compiler hasn't documented if they support it. Such as gcc supporting union type punning in c++. Many compilers allow for reinterpret_cast'ing too, e.g. gcc and -fno-strict-aliasing
This is more of knowing your language and tools. UB isn't some magic beast either, it's where it isn't really feasible for a language that runs on many platforms to dictate what happens. What should the std's say when you shift a signed int too far? Often the HW will have a way of doing it and others will not, so either don't do that or know your implementation
>In general, anything that was added to a language to support generics or to hide pointers and memory management from the developers on a language that isn't a lisp has only produced more harm than good.
Why should I care or need to worry about pointers and memory management in every part of my code?
Yeah as a C# developer I need to be aware if I'm passing a variable by value or reference.. but I don't want to and should not need to define this all the time. I know that built-in simple types (int, string, double) etc are passed as value... and everything else is passed as reference. So it's basically a non-issue.
I grew up learning C/C++ and having to deal with all the crap. Why oh why do I want to handle all of this myself?
I just want to code and focus on getting things done... C#, for example, allows me to do that.
You saying these things have "produced more harm than good" is so obviously coming from a more academic standpoint, or purist in the sense of "oh my god he doesn't even realize that those 8 bytes are going to be held up until the garbage collector comes, whereas I can deallocate that precious memory right away!". Sorry but almost no one cares. Yeah there are times where you need to care, but for most developers that time is... never.
The elitist attitudes on HN are astounding sometimes. Heaven forbid someone code without also managing every aspect of the underlying hardware!
How do you think these luxuries you were provided were given to you?
If you are operating within a managed usermode level of an operating system then what you say is perfectly valid, especially for programs that do not require high availability such as web servers. You can program in a managed environment and trust in your languages JIT/GC to handle low level optimization.
On embedded systems, software that requires high availability (video games for example), or kernel mode drivers and firmware, you are not always allowed that luxury. Understanding of and strong micromanagement of how memory is allocated and moved around the system becomes more and more crucial. It could be hardware limitations of the device that cause this, or in the case of firmware or drivers, any overhead that would be acceptable in a usermode application will be felt throughout the environment when you work on low-level.
TLDR you and the parent post are talking about apples and oranges.
GNU lambdas are incredibly evil. In order for lambdas to capture their environment and yet still be available as a function pointer, the compiler makes the stack executable and stores the trampoline code on the stack.
I found this one really fascinating, they're using both statement expression and nested functions. Their (reformatted) example of:
int (*max)(int, int) =
lambda(int, (int x, int y) { return x > y ? x : y; });
macro-expands to
int (*max)(int, int) =
({ int _(int x, int y) { return x > y ? x : y;}; });
So they have a statement-expression with just one statement in it - the value of that statement is the value of the whole statement-expression. And the one statement inside the statement expression is a declaration of a nested function named _. Statement-expressions decay their return types, so that function gets converted to a function pointer. And thus your "lambda" is a pointer to a GCC nested function.
Notice the second underscore at the end? The compound statement contains a nested function definition followed by an expression statement which "returns" the function just defined. The function definition alone wouldn't work.
A lambda that does not close over its environment is not really a true lambda. It's just a normal function with function scope. I suspect we have some difference in terminology difference: what I call lambda is what you call nested functions. I hate it when there are those kind of trivial terminology differences.
You can do that with this. Because it does technically contain a nested function called _ it's just GCC usually makes that function a normal function if it contains no variables from the parent's scope.
If you reference the outer scope inwards, however, you will end up with an executable stack. And you won't have a borrow checker to tell you the the value that the lambda mentions is no longer at the same address. In fact, you have no flags to warn you of that event.
C++ has lambdas. GNU-C has a hack that is truly terrifying to behold if you use it to the full power.
My friend served as a military officer and told me a story. Every evening before lights out, he had to count soldiers via a roll call, a 10-minute routine. If someone coughed during that (no matter what intent), then suddenly many soldiers began to cough, and that ruined everything. The only solution he figured out to remain legal/moral was to pause and start it all over if someone coughs.
Those defines remind me of how Bourne shell was originally written using such a system to make the source look more like Algol 68. It might even still be maintained that way in BSD to this day [0].
"to this day" in 1994 is very much not "to this day" in 2020.
The various BSDs use the Almquist and Korn shells for /bin/sh nowadays. Indeed, M. Van der Linden was out of date even back in 1994. At that time, BSD had already been largely freed of AT&T code, such as the Bourne shell, for 3 years. It's now approaching 3 decades.
// remove more clutter
#define O printf
#define R return
#define Z static
#define P(x,y) {if(x)R(y);}
#define U(x) P(!(x),0)
#define SW switch
#define CS(n,x) case n:x;break;
#define CD default
When I started learning C++, there was't a C++ compiler available for my Atari ST (late 80s), there was only Borland C. So instead I used the C preprocessor to emulate classes, virtual functions etcetera. Not everything could be implemented this way, but it looked like C++ close enough for me to learn it.
That's basically how C++ was originally created, or the prototype, "C with Classes", albeit with a custom preprocessor. [0]
> In October of 1979 I had a pre− processor, called Cpre, that added Simula− like classes to C run-ning and in March of 1980 this pre− processor had been refined to the point where it supported onereal project and several experiments.
Recognising that you could do it that way is kinda awesome. Maybe not entirely uncommon, but you drafted a powerful bit of software yourself.
Thanks, awesome paper (which remind me that I should read the ARM at some point).
Interesting stuff:
"Cfront [the fist c++ compiler] was (and is) a traditional compiler front− end performing a complete check of the syntax and semantics of the language"
"[...] the C compiler is used as a code generator only. [...]. I stress
this because there has been a long history of confusion about what Cfront was/is. It has been called a preprocessor because it generates C, and for people in the C community (and elsewhere) that has been taken as proof that Cfront was a rather simple program – something like a macro preprocessor."
Cfront being a preprocessor is something that gets repeated often. As you correctly point out, cpre was the preprocessor and it wasn't realy C++ yet.
> C-- (pronounced cee minus minus) is a C-like programming language. Its creators, functional programming researchers Simon Peyton Jones and Norman Ramsey, designed it to be generated mainly by compilers for very high-level languages rather than written by human programmers. Unlike many other intermediate languages, its representation is plain ASCII text, not bytecode or another binary format.[1][2]
> There are two main branches of C--. One is the original C-- branch, with the final version 2.0 released in May 2005.[3] The other is the Cmm fork actively used by the Glasgow Haskell Compiler as its intermediate representation.[4]
Yes. In addition to C--, there is a long tradition of FP (and not only) languages targeting C as a (portable) back end representation. That's how many scheme compilers worked for example. LLVM itself at some point had a C backend.
C has its place; every language has its quirks. I think a lot of emphasis needs to be put on testing code. Like SQLite uses Tcl to script tests. C is easy to test because the “software units” are only structures and functions.
> C has its place; every language has its quirks. I think a lot of emphasis needs to be put on testing code.
The library that this post is a subset of, actually does have a testsuite. It compiles every example, and it's own documentation. The testsuite still needs to grow, and check evaluations rather than whether something "works", but it's getting there.
A really good example of this is the implementation of Objective-C. I believe even the original C++ implementation by Bjarne Stroustrup were also C macros.
The end result reminds me of Julia. Enough to make me wonder if there's something like it underneath Julia somewhere, or if that's how it started (unfortunately I don't have time to really dig in to it right now).
In some subtle way C was already "destroyed" with the introduction of C89. The K&R C had simplicity and beauty to it. Include files were small as they only contained the essential stuff (mostly definitions of structs). UNIX version 7 - the last "true" edition of UNIX - including its entire userspace - was still written in it. X Window system was written in it. Vi was written in it. Now all people do is complain.
Amen, brother! For a language that has been so supremely successful in the "real world", i simply don't understand the HN crowd's disdain for it.
As an aside, "printf format strings" are actually a DSL and hence the complexity. In their book, The Practice of Programming Kernighan & Pike actually show how to implement something similar for Network Packet encoding/decoding. It is quite neat and validates the power of this approach.
I used to be really interested in new languages and compilers. Now ... let's just get on with making Machine Programmers / CASE tools. I don't want to be futzing around with individual lines of code anyway. I guess I want to be like a very technical PM.
I can't help but be reminded of some of the horrifying basic.h and pascal.h macro-filled headers I can remember from long, long ago. Except people actually used those...
I love the simple and lightweight interface, but everything is hard to discover.
Sourcehut? Sounds great- I'd love to replace my Gogs/gitlab instance with something more lightweight. Let's download the source and run it.
I guess click on "git" on https://git.sr.ht/? Wait that's where I already am with no indication that that is the selected tab.
Ok maybe the link for sourcehut? https://sourcehut.org/
Cool. There's some links about pricing, ignore that and click on "100% free and open source software"
Now I am just at a list of what appears to be about 20 repos, all with helpful names like sr.ht-apkbuilds.
I can tell that this person has put a ton of work into making something that is probably fantastic, but it is really all presented in an undiscoverable way. I still have no idea what language this project is written in, how to deploy or maintain it.
I assume https://git.sr.ht/~sircmpwn/git.sr.ht might be what I want, but it still looks like the inscrutable mess that reminds me of hgweb. There's not even a readme on the first page, let alone the source or anything useful. There's a link to https://man.sr.ht/git.sr.ht/installation.md. Which looks like it might be what I want, but I guess I'm old and at this point I've lost interest.
I'm definitely being crotchety, but I wish this information was organized in a more useful way. I can tell Drew has put a lot of time into it, but I don't feel like it is being shared in an effective way. And I would definitely never pay for software like this. Please someone tell me I'm crazy and this UI makes perfect sense to them.
It sounds like you're going to the main page, expecting to download it and deploy it yourself.
It isn't surprising that the main interface is pointing you to _use_ it, rather than deploy it.
If you click on the help hub, _man_, you'll find what you're looking for straight away:
> Hacking on or deploying sourcehut yourself? Resources here.
---
> I guess click on "git" on https://git.sr.ht/? Wait that's where I already am with no indication that that is the selected tab.
That's incorrect. If you look to the left of the nav bar, you'll see some text with red highlighting exactly where you are.
> I still have no idea what language this project is written in, how to deploy or maintain it.
If you click the dev resources link, then you'll find this nice and obvious quote:
> sr.ht core is a Python package that provides shared functionality across all sr.ht services. It also contains the default templates and stylesheets that give sr.ht a consistent look and feel.
> If you look to the left of the nav bar, you'll see some text with red highlighting exactly where you are.
That looks part of the "logo", not part of the navbar. There is at most a minimal difference in the actual "tabs". Of course the reason is that this isn't actually a navbar/tabs but a list of applications offered by sourcehut, this is really noticeable if you click on git when you're at an actual git repository (e.g. https://git.sr.ht/~sircmpwn/scdoc) note that the red text highlighting where I am already says git, so clicking on git shouldn't do anything if it was actually a tab bar, but in reality it navigates to https://git.sr.ht/
Part of what makes sr.ht great is that it's made of tools that can be used together or separately. If you want to use it for just task tracking, great. If you want to use it for task tracking, git repo, and CI/CD, that's fine. If you want to use it for task tracking on a project that keeps code on github and does CI on gitlab... It still works great:)
I always wonder why it doesn't support git push over https?
See https://git.sr.ht/~sircmpwn/git.sr.ht , and find "Clone" section. It said https is read-only, only git protocol supports write.
I've already said this a couple other places but I really wanted to say: "This is amazing and it would be hilarious if you wrote a CNoEvil vs. BOURNEGOL head to head article".
Off topic, but in today's bitter and divided world, it's reassuringly wholesome that people can still get together to recite the alphabet in GitHub comments.
One can do something like
and claim that C is awful and that is so much better.