The problem is Apple's vertically integration of their software and hardware without much of the public documents make it very hard to develop open source for. And the fisaco between the wider Linux kernel community and Rust camp, of course. marcan quit because of the Rust drama last year (just one year ceremony recently ironically) in Linux kernel.
PS: btw I'm of the anti-Rust in Linux kernel camp. I'm a Rust enthusiast, but I just don't believe Linux kernel is the right place.
It's 2026 and there is still no Cargo support to build kernel modules. You still need to make linker script hacks to add the object file into the makefiles, and you tell me that is "out of experimental status". I asked for Cargo support in 2020 IIRC and it is still not here...oh boy.
That means dependencies still have to be vendored by hand-picking and we cannot rely on scanning the dependency graph for GPL.
I like the font of old school IDEs like this. At one point I used Fixedsys Excelsior and Consolas exclusively, until I needed to run IDEs on Linux. I still love those blocky fonts but the lack of CJK alignment is quite annoying.
I think one of the issue is that the register allocation algorithm -- alongside the SSA generation -- is not enough.
Generally after the SSA pass, you convert all of them into register transfer language (RTL) and then do register allocation pass. And for GCC's case it is even more extreme -- You have GIMPLE in the middle that does more aggressive optimization, similar to rustc's MIR. CCC doesn't have all that, and for register allocation you can try to do simple linear scan just as the usual JIT compiler would do though (and from my understanding, something CCC should do at a simple cost), but most of the "hard part" of compiler today is actually optimization -- frontend is mostly a solved problem if you accept some hacks, unlike me who is still looking for an elegant academic solution to the typedef problem.
Note that the LLVM approach to IR is probably a bit more sane than the GCC one. GCC has ~3 completely different IRs at different stages in the pipeline, while LLVM mostly has only canonical IR form for passing data around through the optimization passes (and individual passes will sometimes make their own temporary IR locally to make a specific analysis easier).
If stevefan1999's referring to a nasty frontend issue, it might be due to the fact that a name introduced by a typedef and an identical identifier can mingle in the same scope, which makes parsing pretty nasty – e.g. (example from source at end):
typedef int AA;
void foo()
{
AA AA; /\* OK - define variable AA of type AA */
int BB = AA * 2; /\* OK - AA is just a variable name here \*/
}
void bar()
{
int aa = sizeof(AA), AA, bb = sizeof(AA);
}
In your example bar is actually trivial, since both the type AA and the variable AA are ints both aa and bb ends up as 4 no matter how you parse it. AA has to be typedef'd to something other than int.
Lexical parsing C is simple, except that typedef's technically make it non-context-free. See https://en.wikipedia.org/wiki/Lexer_hack When handwriting a parser, it's no big deal, but it's often a stumbling block for parser generators or other formal approaches. Though, I recall there's a PEG-based parser for C99/C11 floating around that was supposed to be compliant. But I'm having trouble finding a link, and maybe it was using something like LPeg, which has features beyond pure PEG that help with context dependent parsing.
Clang's solution (presented at the end of the Wikipedia article you linked) seem much better - just use a single lexical token for both types and variables.
Then, only the parser needs to be context sensitive, for the A* B; construct which is either a no-op multiplication (if A is a variable) or a variable declaration of a pointer type (if A is a type)
Well, as you see this is inherently taking the spirit of GLL/GLR parser -- defer parse until we have all the information. The academic solution to this is not to do it on token level but introduce a parse tree that is "forkable", meaning a new persistent data structure is needed to "compress" the tree when we have different routes, and that thing is called: graph structured stack (https://en.wikipedia.org/wiki/Graph-structured_stack)
What I had specifically in mind definitely wasn't using OCaml or Menhir, but that's a very useful resource, as is the associated paper, "A simple, possibly correct LR parser for C11", https://jhjourdan.mketjh.fr/pdf/jourdan2017simple.pdf
This is closer to what I remember, but I'm not convinced it's what I had in mind, either: https://github.com/edubart/lpegrex/blob/main/parsers/c11.lua It uses LPeg's match-time capture feature (not a pure PEG construct) to dynamically memorize typedef's and condition subsequent matches. In fact, it's effectively identical to what C11Parser is doing, down to the two dynamically invoked helper functions: declare_typedefname/is_typedefname vs set_typedef/is_typedef. C11Parser and the paper are older, so maybe the lpegrex parser is derivative. (And probably what I had in mind, if not lpegrex, was derivative, too.)
I have no idea why do we need to have a witch hunt like this. Many people have Epstein anyway and not all of them is able to approach his inner ring (ahem circle), but you are attacking all the people that approached or interacted with him.
A fixed plan that is not so flexible, not pay-as-you-go, but predictable and economical. Elastic cloud are elastic in terms of that you can change the compute you want, you can change the storage, either block or object, and you can use their premium network as much as you can, long as you have the money and got clearance on the end of the month. Scaling is therefore what those elastic cloud offers, albeit in a premium price.
Meanwhile, small service providers might not actually need those premium features, and just want something that is cheap and makes economical sense. They don't need the state-of-the-art hardware and just want something that works.
That's why while the AAGO (AWS, Azure, GCP and Oracle) attracted a lot of big corpo, that is, almost all of Forbes 500s used them, DigitalOcean and Vultr, with their $5 plan, is those who won the small businesses.
Right now I'm running a setup with Fedora on my work machine, CachyOS on my laptop, Windows on my home battlestation gaming rig and a Mac Mini M4 I bought for a educational discount. I basically run 3 different kernels, and I feel the same with the author here.
Windows 11 is such a mess that Microsoft thought that they are Apple, so they want to enforce Microsoft Account just like Apple enforces Apple ID to some extent, except this time Microsoft is staking in higher than Apple -- Any active "exploits" that bypasses Microsoft Account got patched not so soon after they are published, and that is what finally intrigued me.
Unfortunately, some of my games runs on Easy Anti-Cheat, and to my knowledge, the Linux switch is opt-in rather than opt-out, most game developers simply didn't put the Linux as a matter on the table even with the introduction of Steam Deck and Steam OS.
I'm planning to wipe my PC after settling some scores, and I still have to go for Windows, but except I will be rolling back to Windows 10 IoT LTSB. Chances are, if I have another drive (which is slowing going into the unobtainium territory, just like RAM)
But, long as I settled that dust, I will bring another PC back to my home. I'm planning to get another CachyOS on that.
PS: btw I'm of the anti-Rust in Linux kernel camp. I'm a Rust enthusiast, but I just don't believe Linux kernel is the right place.
It's 2026 and there is still no Cargo support to build kernel modules. You still need to make linker script hacks to add the object file into the makefiles, and you tell me that is "out of experimental status". I asked for Cargo support in 2020 IIRC and it is still not here...oh boy.
That means dependencies still have to be vendored by hand-picking and we cannot rely on scanning the dependency graph for GPL.
Redox would fare much better.
reply