TempleOS VS linux

This says that Terry didn't release the source code for the kernel or the bootloader. I'm not sure if I'm reading that correctly, since the entirety of TempleOS was built within TempleOS:

- Kernel: https://github.com/cia-foundation/TempleOS/tree/archive/Kern...

Dw https://github.com/cia-foundation/TempleOS I just hacked temple os.

Here's the source code for the game (in HolyC of course).

HolyC is recognized by Github, so it's something else. See here: https://github.com/cia-foundation/TempleOS

You can see all the code on GitHub.

wdym: it's right here

Terry was an exceptionally good programmer who just went literally crazy, though. The parts of TempleOS where the sane part of him managed to win out are impressive as hell.

Perhaps this? https://github.com/cia-foundation/TempleOS

- https://github.com/torvalds/linux/blob/master/Documentation/...

> Electron Performance Crisis: Modern email clients built with Electron and React Native suffer from severe memory bloat and performance issues. These cross-platform frameworks, while convenient for developers, create resource-heavy applications that consume hundreds of megabytes to gigabytes of RAM for basic email functionality.

No (real) customer has ever, or will ever, care about this. Discord and Slack are pretty much case-in-points: bloated Electron apps that just about everyone on the planet has installed on their computers. I personally hate React, but technology decisions are irrelevant to the long-term success of startups. (As long as they don't grossly interfere with customer experience, the feature set, etc.)

> Final Warning: After analyzing hundreds of email startups, the evidence is overwhelming - 80%+ fail completely. Email isn't broken, and trying to "fix" it is a guaranteed path to failure.

First, I'd bet money that figure is actually wrong: the failure rate is likely way higher than 80%. And I'm honestly not sure how anyone could seriously think a 20% exit rate is bad in just about any vertical (but especially a "boring" one like email).

> Resources: Volunteer developers can't sustain enterprise-level software

What am I even reading here? Author does realize openssl[1], Linux[2], and many other "enterprise-level" pieces of software are entirely (or almost entirely) maintained by volunteer developers, right?

Anyway, the post had its opposite intended effect on me: it made me think about ways I could reinvent email.

[1] https://github.com/openssl/openssl

[2] https://github.com/torvalds/linux

Yeah, it's very easy. Real devices usually adhere to the specs.. only very few exceptions: https://github.com/torvalds/linux/blame/master/drivers/hid/h... .. /s

What is the source of “Firefox Moves to GitHub”? It could just be a mirror, just like Linux also has an official mirror on GitHub.

https://github.com/torvalds/linux

It's basically the same in the x86 world : your bios is customised to the board

The sad part is that on ARM the kernel is usually also custom compiled for the board.

If you go and look in https://github.com/torvalds/linux/tree/master/arch/arm you see a zillion "mach-xxx" directories for different SoC architectures, even if they all use Arm.

Device-tree is a partial solution, but no-one seems to have an incentive to finish the job and let a single image run on any (sufficiently recent) arm board. It's difficult for the community to fix because most people have only their own board. Someone would need to pay for a CI rig with every board, and some kernel devs to do the work of building a single kernel to run across everything.

Linux is a open source OS Kernel Unix based created by Linus Torvals in 1997 and released on GitHub and this OS turn so popular because is 100% free to download, make your own OS called Distro(Distribution or Linux Distribution) and every Distro are ruled to be Free and a lot of Linux based Distros was make, the most popular is :

This is even reflected in the ELF format itself. There's this really arcane dichotomy between sections and segments.

Sections are very detailed metadata that all sorts of things use for all sorts of purposes. Compilers use them. Debuggers use them. Static and dynamic linkers use them. Anyone can use them for any purpose whatsoever. You can easily add your own custom sections to any executable using tools like objcopy. It's completely arbitrary, held together by convention.

Segments, on the other hand, don't even have names. They are just a list of file extents required for the program to actually execute and their address space locations. The program header table is essentially a sorted list of arguments for the mmap system call.

This is Linux kernel's ELF loader:

https://github.com/torvalds/linux/blob/master/fs/binfmt_elf....

It basically just mmaps in all of the PT_LOAD segments of the ELF file, copies stuff like arguments and environment and then starts a thread at the entry point specified in the ELF header.

It's just that when loading dynamic ELFs it jumps into the dynamic linker, not the actual program. It's as though every single program had a #!/lib64/ld-linux-x86-64.so.2 shebang line. The absolute path is even hardcoded into the executable itself.

  readelf -a $(which cat) | grep -i interpreter

Yeah same, we maintain some eBPF probes spanning 4.11 to latest kernel, and holy hell, it's really bad. The worst offender being some old RedHat kernels with half-baked backports of the eBPF features containing a bunch of weird bugs or features that aren't perfectly in line with what's used in mainline...

Here's a fun bug we recently had: we had to ban substractions in our program (replacing them with an __asm__ macro) because of a bug in linux kernel 5.7.0 to 5.10.10, which had the (indirect) impact of not properly tracking the valid min/max values in the verifier[0]. The worst part is, it didn't cause the verifier to reject our program outright - instead, it used that information to optimize out some branches it thought were never reachable, making for some really wonky to debug situation where the program was running an impossible control-flow[1], resulting in it returning garbage to user-space.

All this to say, CORE is really only half the problem. Supporting every kernel in existance is still a huge effort. Still worth it compared to the alternative of writing a linux kernel driver though!

[0]: https://github.com/torvalds/linux/commit/bc895e8b2a64e502fbb...

[1]: https://github.com/torvalds/linux/blob/bc895e8b2a64e502fbba7...

I built a fast tree builder for any public GitHub repo via the linux shell.

`gitterbugs` (gbgs) clones, analyzes and renders a beautiful, readable and size-annotated tree of any GitHub repository in seconds.

For example, `gbgs https://github.com/torvalds/linux` produces:

```