Thank you for doing this! I really mean it. We need more developers who care about keeping websites lean and fast.
There's no good reason a regular site shouldn't work on GPRS, except maybe if the main content is video.
1GB RAM per 1TB storage is really only required if you enable deduplication, which rarely makes sense.
Otherwise, the only benefit more RAM gets you is better performance. But it's not like ZFS performs terribly with little RAM. It's just going to more closely reflect raw disk speed, similar to other filesystems that don't do much caching.
I've run ZFS on almost all my machines for years, some with only 512MiB of RAM. It's always been rock-solid. Is more RAM better? Sure. But it's absolutely not required. Don't choose a different file system just because you think it'll perform better with little RAM. It probably won't, except under very extreme circumstances.
ZFS doesn't really need huge amounts of RAM. Most of the memory usage people see is the Adaptive Replacement Cache (ARC), which will happily use as much memory as you throw at it, but will also shrink very quickly under memory pressure. ZFS really works fine with very little RAM (even less than the recommended 2GB), just with a smaller cache and thus lower performance. The only exception is if you enable deduplication, which will try to keep the entire Deduplication Table (DDT) in memory. But for most workloads, it doesn't make sense to enable that feature anyways.
In my experience, writing a few lines to handle errors is really not as big of a deal as a lot of people make it out to be. However, I've seen numerous times how error handling can become burdensome in poorly structured codebases that make failure states hard to manage.
Many developers, especially those in a rush, or juniors, or those coming from exception-based languages, tend to want to bubble errors up the call stack without much thought. But I think that's rarely the best approach. Errors should be handled deliberately, and those handlers should be tested. When a function has many ways in which it can fail, I take it as a sign to rethink the design. In almost every case, it's possible to simplify the logic to reduce potential failure modes, minimizing the burden of writing and testing error handling code and thus making the program more robust.
To summarize, in my experience, well-written code handles errors thoughtfully in a few distinct places. Explicit error handling does not have to be a burden. Special language features are not strictly necessary. But of course, it takes a lot of experience to know how to structure code in a way that makes error handling easy.
SerenityOS serves as a cool side project for those who like to tinker with OS dev. I don't think it was "born" with any other goals in mind. Neither was their browser project, it just happened to turn into something a lot more serious.
This is big news. Defer can simplify control flow a lot, especially in early-return cases like handling errors. No longer do we have to write deeply nested ifs or the madness that is goto. Resource acquisition and cleanup can now be right next to each other.
Now we just have to hope that standardization goes well. The C standard moves very slowly, and that's probably a good thing. But defer is such a simple yet powerful feature that the cost/benefit ratio should easily justify its inclusion.
> maybe today you can still build a win10 binary with a win11 toolchain, but you cannot build a win98 binary with it for sure.
In my experience, that's not quite accurate. I'm working on a GUI program that targets Windows NT 4.0, built using a Win11 toolchain. With a few tweaks here and there, it works flawlessly. Microsoft goes to great lengths to keep system DLLs and the CRT forward- and backward-compatible. It's even possible to get libc++ working: https://building.enlyze.com/posts/targeting-25-years-of-wind...
Strongly agree with this article. It highlights really well why overcommit is so harmful.
Memory overcommit means that once you run out of physical memory, the OOM killer will forcefully terminate your processes with no way to handle the error. This is fundamentally incompatible with the goal of writing robust and stable software which should handle out-of-memory situations gracefully.
But it feels like a lost cause these days...
So much software breaks once you turn off overcommit, even in situations where you're nowhere close to running out of physical memory.
What's not helping the situation is the fact that the kernel has no good page allocation API that differentiates between reserving and committing memory. Large virtual memory buffers that aren't fully committed can be very useful in certain situations. But it should be something a program has to ask for, not the default behavior.
There's still plenty of mandatory reading. It's not unusual for high schoolers to have to read at least two books per semester.
Here's the problem though: It's just too easy to... you know... not do it. Teachers have no way of reliably telling the difference between those students who complete their reading assignments honestly and those who make due with summaries and AI assistance. Don't ask me how I know ;-)
It's the closest thing to a Unix successor we ever got, taking the "everything is a file" philosophy to another level and allowing to easily share those files over the network to build distributed systems. Accessing any remote resources is easy and robust on Plan9, meanwhile on other systems we need to install specialized software with bad interoperability for each individual use case.
Plan9 also had some innovative UI features, such as mouse chording to edit text, nested window managers, the Plumber to run user-configurable commands on known text patterns system-wide, etc.
Its distributed nature should have meant it's perfect for today's world with mobile, desktop, cloud, and IoT devices all connected to each other. Instead, we're stuck with operating systems that were never designed for that.
There are still active forks of Plan9 such as 9front, but the original from Bell Labs is dead. The reasons it died are likely:
- Legal challenges (Plan9 license, pointless lawsuits, etc.) meant it wssn't adopted by major players in the industry.
- Plan9 was a distributed OS during a time when having a local computer became popular and affordable, while using a terminal to access a centrally managed computer fell out of fashion (though the latter sort of came back in a worse fashion with cloud computing).
- Bad marketing and posing itself as merely a research OS meant they couldn't capitalize on the .com boom.
- AT&T lost its near endless source of telephone revenue. Bell Labs was sold multiple times over the coming years, a lot of the Unix/Plan9 guys went to other companies like Google.
Tech companies can certainly be forced to build surveillance into their chat applications and operating systems. This doesn't have to be about backdooring crypto.
> Enforcement can only be arbitrary.
Sure, but it would be forced upon the vast majority of the population. Tech-savvy people will find ways to circumvent it, so will criminals, but that doesn't make mass surveillance of all others any less scary.
Yeah, hosting on or at least tunneling through a commercial IP address is definitely required in order not to be flagged as spam. Personally, I chose the latter option of hosting my MTA at home but tunneling its traffic through a VPS in a datacenter. It's been working pretty well ever since, although I'm not sure it's worth the effort versus just using a cheap hosted provider.
Unfortunately, Memory64 comes with a significant performance penalty because the wasm runtime has to check bounds (which wasn't necessary on 32-bit as the runtime would simply allocate the full 4GB of address space every time).
But if you really need more than 4GB of memory, then sure, go ahead and use it.
Well, sometimes things aren't as amazing as they look on the surface. And it's totally understandable if you don't want to spend the time and effort to solve the problems you mentioned.
Some people/communities might be interested in this compiler regardless. It doesn't hurt to spread the word. We need more compiler diversity, research, and development.
Also, don't sell yourself short - completing a project of this magnitude and complexity as a solo dev is something few people are able to do. If I worked in HR, I would try to hire you instantly ;-)
Hope to see more awesome software from you in the future!
Wow, hats off to you! This is one of the most impressive solo projects I've seen in a while!
Making a toy C compiler isn't rocket science, but developing one that's complete and production-ready is whole nother story. AFAICT, Kefir fits into the latter category:
- C17/C23 compliance
- x86_64 codegen
- debug info gen
- SSA-based optimization passes (the most important ones)
- has a widely-compatible cc cli
- is extensively tested/fuzzed
Some advantages compared to the big three (GCC, Clang, MSVC):
- It's fairly small and simple
- That means it's understandable and predictable - no surprises in terms of what it can and cannot do (regarding optimizations in particular)
- Compilation is probably very fast (although I haven't done any benchmarking)
- It could be modified or extended fairly easily
There might be real interest in this compiler from people/companies who
- value predictability and stability very highly
- want to be in control of their entire software supply chain (including the build tools)
- simply want a faster compiler for their debug builds
Think security/high assurance people, even the suckless or handmade community might be interested.
So it's time to market this thing! Get some momentum going! It would be too sad to see this project fade away in silence. Announce it in lots of places, maybe get it on Compiler Explorer, etc.
(I'm not saying that you have to do this, of course. But some people could genuinely benefit from Kefir.)
P.S. Seems like JKU has earned its reputation as one of the best CS schools in Austria ;-)