I profoundly do not understand why one needs Hugo or Jekyll or whatever other generator. Why not write HTML in the first place? It's so absurdly easy and it makes you not depend on external infrastructure at all.
I tried some generators but it was so much more complicated than writing a style sheet and some pages. Maybe for some more complex use-case, okay, I get it, but the author's blog is so minimal and simple.
edit: today I learned people have very strong opinions about static site generators. Good valid reasons, y'all. Maybe my use case really is too simplistic!
- the ability to update every page on my site at-once in a uniform fashion (want to change the page layout or add a link in the footer, either you're manually editing a hundred HTML files or a couple lines in a single template file)
- Syntax highlighting. My blog has code blocks so I would have to manually invoke a syntax highlighter for each code block (and every time I update the code I'd have to do it again).
- auto-invoking graphviz and gnuplot. Similar to the code blocks, I write graphviz dot and graphviz blocks as code in my blog posts and have my static site generator render them to images. If I was manually writing the HTML then I'd either end up committing the built binaries (rendered images) to git (which, of course, is bad practice but ultimately inconsequential when talking about small SVGs for the few charts/graphs on my blog) or I'd have to have a "build" step where a script invokes graphviz/gnuplot to output the images which is the first step on the road to a static site generator.
- Avoiding name collisions with internal anchor links (the kind with the `#` symbol that scrolls the page). I use these for footnotes and code block references. I could manually assign names for these for each blog post, but when combining multiple blog posts into a single list-view for the home page, there is the risk that I might reuse the same `#fn1` anchor across multiple blog posts. Using a static site generator, I don't need to concern myself with naming them at all and I have my static site generator assign unique names so there are no conflicts.
Because then you have 200 blog posts and suddenly you realize "oh I wanna add an author section to all my blog posts". That is 200 files to edit. Could you write a script to do the edit? Sure, but then you pretty much build a static site generator.
Or at least, you will have as you realize things like you only wanted to do that on certain categories or whathaveyou.
You can in principle just write HTML with no script support, but it itself becomes an exercise in conspicuous asceticism. It is not unreasonable to want things like "the last 5 posts" on every page on a blog, or an RSS feed, or any number of other very basic, simple things that are impractical with an editor and raw HTML.
Obsidian is a nice middle ground between WYSIWYG and plain text - it doesn't send markup characters into the ether but at the same time does show you something close to the final text in real time.
Closest thing we've had to WordPerfect's Reveal Codes in decades.
I thought this too, but then it hit me that it will need pagination as the number of blog posts grow. Also updating links, footers, menus, headers etc also quickly becomes a nightmare.
Id like to see you writing a semantically correct, accessible, responsive <figure> block containing an image of a chart displaying some data.
It takes me nine characters plus URL and alt text in markdown using Hugo. I would be surprised if you get it right on the third try without consulting MDN, spending time to research, do image conversions, and fiddle with the <picture> tag and its srcset attribute.
That's a very technical perspective. If you're a note taker, you ALREADY write in a format that is comfortable for you. And like the vast majority of people who enjoy putting proverbial pen to paper, you aren't thinking about bloody html tags.
The goal of generators is to reduce the friction of taking your notes/articles/etc. and wrapping them in thematically consistent HTML/CSS for your site. Once you've got it tuned/setup for your blog, they're pretty easy to use.
Obviously in your use-case where you find static site generators more complicated, then you can stick with raw html.
When I want to write longer content, the last thing I want to think about in that process is html tags. Doesn't matter how simple - if it distracts from content, it has no place at that stage of the process. I'm also very likely to include code snippets in any post I write and I extremely don't want to write the code colouring by hand every time.
Because writing in markdown is a nicer experience. You could convert markdown to html using Pandoc, but another nice thing that these blog generators do is templating and indexing. Neither of which is necessary, but still, they're nice, especially if it happens automatically when you push to github.
How do you plan to manage 1,000+ posts with HTML and make changes that are similar across all pages, say, the location of your static assets (images) or something common like footer, nav, etc?
I mean… yes, obviously? There’s a lot less room for exploitation of white collar workers in wealthy countries than sweatshops. Though performance quantifying software still deserves a lot of scrutiny for removing humanity from work in any context.
Nobody is stopping you from using master, you can do whatever you want. The author even recognizes that very clearly in the text.
You can name all your default branches `megazord`. Hell, you can fork git, call it "gitzord" and enforce your `megazord` branch as The Correct Main Branch Name for every user. Feels good to be free, doesn't it?
After using delta for a while, I'm going back to the regular diff view... it's not that it isn't good, but I'm constantly copying diffs (yes, I know I can generate patches) and the pretty output breaks that workflow.
Also, when your terminal is a bit small it's a bit hard to see things. But it's really good software, I recommend anyone who's reading to give it a try.
Most tools that do formatted output, if they’re well-behaved, should try to detect if their output is a pipe and if so, disable formatting.
Some examples that I can think of off the top of my head (in addition to git) are ripgrep and jq, both of which do the right thing and strip formatting.
I have Gemini set to decipher HN comments that I don't immediately understand. This is a macos only command `pbcopy`?
Aside: Gemini mentioned it didn't want me to ask it questions about bikeshedding what shade of blue on a website header so I think it's got our number.
Yes pbcopy is a mac thing. On Linux, there are of course many different commands in different environments/distros. xsel, xclip, wl-clipboard, wlclip to name a few.
On windows, powershell has Get-Clipboard and Set-Clipboard, and cmd.exe has `wsl` to fix the issue of having used cmd.exe to begin with.
> I guess some older or more closer to the metal parts will stay in C
I suppose the biggest reason is that C programmers are more likely than not trained to kinda know what the assembly will look like in many cases, or have a very good idea of how an optimizer compiler will optimize things.
This reminds me I need to do some non-trivial embedded project with Rust to see how it behaves in that regard. I'm not sure if the abstraction gets in the way.
After writing some non-trivial and performance sensitive C/C++ code, you have feeling of how that code behave on the real metal. I have that kind of intuition, for example. I never had to dive to the level of generated ASM, but I can get ~80% of theoretical IPC with just minding what I'm doing in C++ (minimum branching, biasing branches towards a certain side, etc.).
So, I think if you do the same thing with Rust, you'll have that intuition, as well.
I have a friend who writes embedded Rust, and he said it's not as smooth as C, yet. I think Rust has finished the first 90% of its maturing, and has the other 90%.
I write embedded rust full-time and can say there's nothing that I can do in C that I can't do in rust. Sure the tools/frameworks are a lot more mature, but a combination of the PAC for register access (maybe a bit of community maintained HAL) and a framework like RTIC is pretty much all I need.
I am not convinced, given the amount of heavy lifting that the Rust type system does, that rusty Rust is nearly as brain-compilable as C. However, you can write the equivalent of C in many languages, and Rust is one of them. That kind of code is easy to compile in your head.
It's not brain-compilability, it's getting used to what that specific compiler does with your code you brain-compile.
So, I have a model for my code in my brain, and this code also has a real-world behavior after it's compiled by your favorite toolchain. You do both enough times, and you'll have a feeling for both your code and the compiler's behavior for your code.
This feeling breaks when you change languages. I can brain-compile Go for example, but compiler adds other things like GC and null-pointer protection (carry local variables to heap if you're going to hit a null pointer exception after returning a function). Getting used to this takes time. Same for Rust.
> I suppose the biggest reason is that C programmers are more likely than not trained to kinda know what the assembly will look like in many cases, or have a very good idea of how an optimizer compiler will optimize things
This is the only way Hellwig's objection makes any kind of sense to me. Obviously, intra-kernel module boundaries are no REST-APIs, where providers and clients would be completely separated from each other. Here I imagine that both the DMA module as well as its API consumers are compiled together into a monolithic binary, so if assumptions about the API consumers change, this could affect how the module itself is compiled.
I've done a non-trivial embedded project in C. (Quadcopter firmware). The language doesn't get in the way, but I had to write my own tooling in many areas.
> have not yet found a hardware independent Linux distro that can be reliably updated in an IOT context
I'm part of the team that builds an immutable distro based on OSTree (https://www.torizon.io) that does exactly that.
Docker/Podman support is first-class as the distro is just a binary, Yocto-based one that we maintain so users don't have to. You can try our cloud for free with the "maker" tier. To update a device you just drop a compose file with the web ui and massively update a fleet. You can even use hardware acceleration from the containers using our reference OCI images.
The layer is open (https://github.com/torizon/meta-toradex-torizon) and will get Raspberry Pi support soon but you can integrate already easily with meta-raspberrypi (we can also do this for you very quickly ;-)).
This comment makes zero sense. It's a meta-distribution: it builds a custom one for you. Professional custom embedded distros are a different beast altogether from the vanilla distros.
When one of the key guys behind the VCS says things like "especially when the alternative is something as broken as Git" about other control systems I really don't feel like using said tool.
This is a good reminder to me that I need to control my tongue as well; I have said things like the Pijul author did in that thread, and I need to do better.
I can’t still edit that comment to explain, but I meant it sincerely. When someone sees a foible of their own in others and moves to correct it, that’s awesome and commendable.
Eh, you never can tell. I assume someone thought I was being sarcastic. I don't care if someone downvotes me, but I'd hope it'd be because I'd genuinely said something dumb or unkind.
Well he didn't really call cvs/subversion broken, to semi quote, he basically said that subversion people were trying to improve on cvs and you cannot do that because cvs is inherently broken.
Its not damning to call something broken, plenty of software has bugs that make it unusable and are broken to many people. In fact, many tools have been made in anger at other tools not doing what you want them to do. This is just the software inception cycle. You should be allowed to be angry at the brokenness of software... its what allows improvement.
Oh God, this is such an astute observation. I think it worked so well on me that I didn't even think about the "deep" portion initially. Goes to show how effective these things are psychologically.
I tried some generators but it was so much more complicated than writing a style sheet and some pages. Maybe for some more complex use-case, okay, I get it, but the author's blog is so minimal and simple.
edit: today I learned people have very strong opinions about static site generators. Good valid reasons, y'all. Maybe my use case really is too simplistic!
reply