OSDev.org

vvaltchev wrote:Do you know this epic essay? https://www.dreamsongs.com/RiseOfWorseIsBetter.html
In my experience, developers kind of actually divide between those two groups. Do you dislike Linux because you prefer the "MIT approach"?

I knew this essay, but it's been a long time since I've read it last time. I don't fit in there well, but I think Linux fails for both approaches. They were fast in their development so they reached production level fast. But that was at a cost: The code is a badly-designed, over-complicated mess. Of course it proves the talent of the coders who made Linux. I have no problem admitting that most (probably all) of them are better coders than myself. But they exclude mediocre coders, probably on purpose as they look down on them.

I like the "suckless" philosophy, though it is unclear what precisely is a suckless kernel. Definitely Mach is NOT of my taste, too.
Here is a link
https://suckless.org/philosophy/

EDIT: vvaltchev's kernel (Tilck) comes close to my ideal kernel)
Greetings
Peter

Linux is interesting. I personally favor something with a good structure and simplicity. That is what I am trying to achieve in my OS. The only kernel that comes near my personal tastes is the BSDs, and L4 is pretty good as well. I also like QNX. Windows could be good, but, well, it's as slow as molasses and has very poor design choices. My OS is more like Windows the Linux, however. But Windows has around 2700 threads with just Task Manager running! Not to mention 233 processes.
My OS choices come down to one thing. I hate bloat. Linux is bloat.

I think Linux is a very bad design based on an ancient "Unix" concept that should have died long ago. In fact, while Windows has shed it's poor DOS legacy, Linux still carries the much older and equally poorly designed "Unix" legacy. The POSIX concept is just as bad, and the whole environment is extremely complex & bloated.

I never heard about the "suckless" philosophy and I'm not sure if I understand what's really about, after reading their manifesto. I have to spend more time there, to get a better idea. I was thinking about what to answer to your comments about Linux and then:

PeterX wrote:EDIT: vvaltchev's kernel (Tilck) comes close to my ideal kernel

I.am.shocked. I never expected that anybody here would say something like that. It seemed to me that everybody here believes their kernel is the best in the universe and that anything else sucks including Linux, Windows, MacOS X, etc. Mine, received just one comment in the announcement, so I got the impression that, at least in this community, people are not interested in it. I don't know what to say other than a big THANK YOU, SO MUCH.


Said that, positive emotions apart, maybe it would be interesting to go deeper and try to understand our philosophy towards software development. Which trade-offs are we happy to do when writing code, which we aren't. At the end, in theory, you and I should end up with similar views, because otherwise why a project of mine be "close to an ideal" for you?

I'm not prepared to formally state my value-system about software now, but I can start saying that I oscillate between the "MIT approach" and the "New Jersey approach". Deep inside, I'm probably more a "New Jersey", but sometimes that leads to me places that I don't like enough so I escape to the "MIT approach" and the cycle repeats. I'm incredibly good at making people following either of those two approaches to HATE ME. I don't know how I do that.

Concrete examples? I hate over-engineering. I hate code bloat. I'm careful about adding dependencies to my projects: the less dependencies, the better. But, when a dependency (whether it's a tool or a library, it doesn't matter) adds a great amount of value to my project, I'm certainly fine with adding it. I'm for "code evolution" rather than the "design it once, never touch it again" approach, because the latter doesn't work as it's supposed to, take an incredible amount of time and leads to over-engineering. (Still, that doesn't mean that I'm fine with the first thing that comes to my mind, either.) I like A LOT having a consistent interface, but I'm ready to do break that in order to improve the performance or to make some code-paths much simpler. Also, when it does make a difference, I prefer to design the software for the machines, trying to make it as clear as possible for the humans (I'm talking about the source code), instead of doing the opposite: create an object-oriented hierarchy that maps the "real-world", but that's inefficient for the machines.
I like software that has virtually no latency (on the human scale). E.g. I get frustrated when I click on a menu and it takes 200-300 ms to load. It MUST BE much faster than the human perception. I hate when software starts "half-loaded" and then, whatever you do, you have to wait because of the lazy-loading. I hate when anything lags, in general. I'm a huge fan of user experience as an ultimate "force" above any software trade-off. OK, I think it's enough, for the moment.

In this article on my blog: https://vladonsoftware.wordpress.com/20 ... e-mindset/
I believe you could understand more about my philosophy, while (hopefully) having some fun. (I have funnier articles too.)

What do you believe? Do you share any the values/principle I just enlisted? Which ones? Also, would you be so kind to try explaining a bit more why you like my project so much? What's the thing that most impressed you?

rdos wrote:I think Linux is a very bad design based on an ancient "Unix" concept that should have died long ago. In fact, while Windows has shed it's poor DOS legacy, Linux still carries the much older and equally poorly designed "Unix" legacy. The POSIX concept is just as bad, and the whole environment is extremely complex & bloated.

I completely agree. It is really a holdover from the pre SVR4 days. The Unices that came the closest to good are Mach and OpenBSD seems good.
EDIT - I'm quite impressed by Tlick as well. It is proof that you don't need bloat to work. I have always searched for a good kernel that isn't bloated. Tlick is exactly that.

As for my kernel's design, I intend to keep everything in separate, clean, components. It has a lot more components, but that is mainly for security (as that is the number 1 goal). For example, I have a resource manager which takes everything user mode uses (files, threads, processes, etc), and they have ACLs on them, they have a certain interface, they have data associated with them, plus more. But for the most part, I intend to keep it clean and simple.

I'm, too, not exactly MIT-type or New-Jersey-type. I was more of an MIT type in the past and now tend more to the New-Jersey-type, but not fully. Yes, people in general get hostile at someone who dares to have a different opinion or doesn'T fit in their mental schema.

The "always measure" is not my philosophy. I don't know similarities between our philosophies, but I'm sure they are there. As you said I like your kernel so I probably think and work similar to you. I also am similar to bzt, eekee and Schol-Are-Lea, I think. For example I like the simplicity of Scheme and Forth. But my pragmatism come through causing me to code in Assembler, C and C++. I'm a bit torn there.

There is another distinction between programmers:
1. Programmers who like to code low level/backend.
2. Programmers who like to code frontend and GUI.
I am (1.) and I think bzt probably is, too.

Producing a small and simple kernel has several side effects, one of them is that it runs fast (normally) and that you can optimize it quite well because you have it easy to analyze it. (OK bloated spaghetti code can be optimized well, too, by refactoring the complicated stuff but that is hard work.)

I am used to software "lag" because I used Windows95 (and following versions).

Well, the good thing of your kernel is that
a) it aims at being small and simple (Linux never tried to be that)
b) provides Linux compatible interface.
c) Your code seems to be quite readable, but I am not good at reading other people's code.
Actually (c) is a side effect of (a). Generally speaking I like simple software. I like a simple editor more than an IDE for example.

I also like Managarm which is Microkernel + Linux interface.

If Tilck gets more stable/production stage I might even use it for my day-to-day work (ok that's a bit in the future, if/when Linux applications actually can run on Tilck). I'm planning on writing a simple graphics stack ontop of the UEFI-linux kernel (which is in most parts identical to Legacy-BIOS-Linux.) But first there are other projects: Hacking bare bones UEFI and some non-system-programming project.

User experience is very important for every software, be it a kernel, a game, an office suite or whatever. There are even employees in some companies who are responsible for user experience, because the managers know that it is so important. There's even an abbreviation for it: UX.

I would say I am an MIT. I prefer low level coding. My design is complete yet simple, and I appreciate anything following that philosophy.

nexos wrote:EDIT - I'm quite impressed by Tlick as well. It is proof that you don't need bloat to work. I have always searched for a good kernel that isn't bloated. Tlick is exactly that.

Thank you nexos, I really appreciate that!

PeterX wrote:For example I like the simplicity of Scheme and Forth. But my pragmatism come through causing me to code in Assembler, C and C++. I'm a bit torn there.

OK, I'm a "native" C and C++ programmer instead. I started with C++ (which I used mostly as C, no STL etc.) when I was 10. Because of the early age, some people told me I had a form of imprinting towards those languages. I learned and liked many other languages after that, but never so much like C and C++. Maybe the imprinting theory is correct?

PeterX wrote:There is another distinction between programmers:
1. Programmers who like to code low level/backend.
2. Programmers who like to code frontend and GUI.

Yeah, that's kind of true. But, I love low-level programming and I like GUI programming as well. Maybe I'm weird, I don't know. Professionally, the distinction between embedded/low-level, backend, and frontend is very clear, however. Still, I kind of feel that the other distinction impacts more how well you can work with another developer.

PeterX wrote:Well, the good thing of your kernel is that
a) it aims at being small and simple (Linux never tried to be that)
b) provides Linux compatible interface.
c) Your code seems to be quite readable, but I am not good at reading other people's code.
Actually (c) is a side effect of (a). Generally speaking I like simple software. I like a simple editor more than an IDE for example.

Thanks for the feedback. It feels to me that you and @nexos like Tilck for the same reason, but I'd like to understand better what you mean with "code bloat". I got that you consider Tilck "not bloated" while the Linux kernel "bloated". The question is for @nexos as well. Can you explain better that? For example, I cannot hide the fact the Tilck do not have support for most of the hardware and it works only on i686. If, in the future, the project started to support plenty of hardware devices and other architectures, will that make it "bloated" or not? If not, can you define how "bloat" differs from "size"? I have some sort of definition of mine, but I'd like to hear yours first, guys.

PeterX wrote:If Tilck gets more stable/production stage I might even use it for my day-to-day work (ok that's a bit in the future, if/when Linux applications actually can run on Tilck).

First, I'm flattered that you'd use it. Unfortunately, you know, the amount of things you'll need the kernel to be able to run for using it day-to-day is huge. The project is far from there. However, actual (simple) Linux applications already run there. If you install gcc-multilib on your host system, you'll be able to run 32-bit linux apps, so you can run the same app on Linux and Tilck. Just link statically with a libmusl i686 toolchain and drop the binary in the 'sysroot' directory.

Anyway, I never intended it to become a desktop OS, because that's a kind of a "mission impossible". But, even if I wanted, I don't have enough time to make it possible. Unless other people don't start contributing, it will remain a mid-sized project I'll have fun hacking with in my free time. Every successful (big) open source project starts with a guy who works initially on it to the point the project is something worth showing and, at that point, maybe even slowly, the project starts to gain contributors. Without other people, it's impossible to achieve "great things". For the moment, I had some minor contributions, but nobody took interested in seriously contributing, so far.

PeterX wrote:I'm planning on writing a simple graphics stack ontop of the UEFI-linux kernel (which is in most parts identical to Legacy-BIOS-Linux.)

Sorry, I didn't get that. What do you mean with "UEFI-linux kernel" ? The Linux kernel is the same, no matter if it boots via UEFI or not. I don't quite understand what you're working on.

vvaltchev wrote: Anyway, I never intended it to become a desktop OS, because that's a kind of a "mission impossible". But, even if I wanted, I don't have enough time to make it possible. Unless other people don't start contributing, it will remain a mid-sized project I'll have fun hacking with in my free time. Every successful (big) open source project starts with a guy who works initially on it to the point the project is something worth showing and, at that point, maybe even slowly, the project starts to gain contributors. Without other people, it's impossible to achieve "great things". For the moment, I had some minor contributions, but nobody took interested in seriously contributing, so far.

I fear that this site/forum, by its very nature, will get you some feedback, but little in the way of actual contributions.

The problem is, the people who frequent these forums are probably intent on implementing their own kernel, probably to the exclusion of others. I know I am. Once my code is in a usable state that I'd consider shareable, I'd love feedback, but I'm under no illusion that anyone will actually contribute much code wise.

vvaltchev wrote:Thanks for the feedback. It feels to me that you and @nexos like Tilck for the same reason, but I'd like to understand better what you mean with "code bloat". I got that you consider Tilck "not bloated" while the Linux kernel "bloated". The question is for @nexos as well. Can you explain better that? For example, I cannot hide the fact the Tilck do not have support for most of the hardware and it works only on i686. If, in the future, the project started to support plenty of hardware devices and other architectures, will that make it "bloated" or not? If not, can you define how "bloat" differs from "size"? I have some sort of definition of mine, but I'd like to hear yours first, guys.

For me, bloat is anything unnecessary. Supporting more hardware wouldn't be bloat. Bloat, for example, is Linux using Red Black trees in the scheduler. That is unnecessary. Everything is good with queues. In my opinion, less is a lot of times more

For my kernel, I plan on having everything a modern OS needs, just making these insides less bloated.

vvaltchev wrote:Anyway, I never intended it to become a desktop OS, because that's a kind of a "mission impossible". But, even if I wanted, I don't have enough time to make it possible. Unless other people don't start contributing, it will remain a mid-sized project I'll have fun hacking with in my free time. Every successful (big) open source project starts with a guy who works initially on it to the point the project is something worth showing and, at that point, maybe even slowly, the project starts to gain contributors. Without other people, it's impossible to achieve "great things". For the moment, I had some minor contributions, but nobody took interested in seriously contributing, so far.

I have been trying to find a project to join in my free time away from my OS. I may start making contributions to Tilck in the near future. I am going to examine its codebase and really get familiar with its internals. It has great design goals that fit in great with my OS philosophy.

thewrongchristian wrote:I fear that this site/forum, by its very nature, will get you some feedback, but little in the way of actual contributions.

The problem is, the people who frequent these forums are probably intent on implementing their own kernel, probably to the exclusion of others. I know I am. Once my code is in a usable state that I'd consider shareable, I'd love feedback, but I'm under no illusion that anyone will actually contribute much code wise.

You’re totally right, I know. I have no illusions either. Just, I thought pointing out that no matter how promising my project seems to be, it will get nowhere unless other people join it. I’ve been working on it for a few years now, but I cannot go on forever at this speed, you can imagine why. The same applies for most projects here, sadly.

Still, I can make an argument in favor of contributing to projects here: you could share the amazing (or terrible, it depends) experience of working with other people and have a lot of fun, while learning exactly what you want. Sending a patch to a project here, will trigger a very different reaction than sending a patch to the Linux kernel. Here (probably) people will spent time with you and have more patience. Working alone (I’ve done it, a lot), is simple, fast and nice at the beginning, but sooner or later, it becomes also a little sad. I’m not sure that if I could go back in time I would like to re-write all of that. I have mixed feelings.

nexos wrote:For me, bloat is anything unnecessary. Supporting more hardware wouldn't be bloat. Bloat, for example, is Linux using Red Black trees in the scheduler. That is unnecessary. Everything is good with queues. In my opinion, less is a lot of times more

For my kernel, I plan on having everything a modern OS needs, just making these insides less bloated.

I understand now what you mean.

nexos wrote:I have been trying to find a project to join in my free time away from my OS. I may start making contributions to Tilck in the near future. I am going to examine its codebase and really get familiar with its internals. It has great design goals that fit in great with my OS philosophy.

Wow, man! That would be great. I was just discussing with @thewrongchristian about how unlikely it is to find contributors here..

rdos wrote:I think Linux is a very bad design based on an ancient "Unix" concept that should have died long ago. In fact, while Windows has shed it's poor DOS legacy, Linux still carries the much older and equally poorly designed "Unix" legacy. The POSIX concept is just as bad, and the whole environment is extremely complex & bloated.

Well, Unix can't be all that bad, given that all major operating systems are converging on it. Those that don't learn from Unix are doomed to re-implement it, badly.

I mean, Windows moved from DOS to NT. What are NT's most distinguishing features? Oh, basically everything from Unix (multiuser support, symlink support in the FS, ...). MacOS moved from their bespoke kernel to XNU, which claims not to be a Unix, but is very much a Unix anyway.

And yes, POSIX is bloated. Some parts of it read like somebody documented their implementation and now everybody has to do the same things. Ever read the description of system()? Jesus! However, POSIX is a standard one can support, and once supported, you immediately gain access to thousands of software packages. Therefore, unless you plan on re-implementing everything (like, say, font renderer, GUI toolkit, web browser,...), POSIX is really the only way to go. However, full conformance is not necessary to gain access to most of those packages.

nullplan wrote:

rdos wrote:I think Linux is a very bad design based on an ancient "Unix" concept that should have died long ago. In fact, while Windows has shed it's poor DOS legacy, Linux still carries the much older and equally poorly designed "Unix" legacy. The POSIX concept is just as bad, and the whole environment is extremely complex & bloated.

Well, Unix can't be all that bad, given that all major operating systems are converging on it. Those that don't learn from Unix are doomed to re-implement it, badly.

I mean, Windows moved from DOS to NT. What are NT's most distinguishing features? Oh, basically everything from Unix (multiuser support, symlink support in the FS, ...). MacOS moved from their bespoke kernel to XNU, which claims not to be a Unix, but is very much a Unix anyway.

And yes, POSIX is bloated. Some parts of it read like somebody documented their implementation and now everybody has to do the same things. Ever read the description of system()? Jesus! However, POSIX is a standard one can support, and once supported, you immediately gain access to thousands of software packages. Therefore, unless you plan on re-implementing everything (like, say, font renderer, GUI toolkit, web browser,...), POSIX is really the only way to go. However, full conformance is not necessary to gain access to most of those packages.

Haven't Apple been touting "MAC OS X is REAL UNIX, we've got PAPERS (a copy can be found at https://www.opengroup.org/openbrand/cer ... /1212p.pdf) to prove it"?

People need to read the haters handbook