161–170 of 196 posts
If I were developing a new OS, I certainly wouldn't have a default text terminal...
That just looks gross.
But my interests differ. I would focus on the graphical user interface as my number one concern.
It would always run in a OpenGL type graphics mode, where you could spawn any number of text terminal-style windows, but I would definitely skip a full-screen text mode. Its just never needed.
Does that make sense?
I'm very excited about this! Minoca is an interesting system, and I applaud any attempt to make driver-writing less inherently horrible. Minoca OS has been around for a while, but the news is that they're GPLv3. I think that's a great thing! The MIT license is good for software that wants to permeate through everything , but for building a community, the GPL is a good idea. It seems that for any operating system to b…
Seems to me like POSIX compatibility is actually a cheap pass that gives you access to a huge software environment. Right on the homepage they mention already having packages for Python, Ruby, Git, Lua, and Node... would that, and thousands of other packages, be feasible without a workable POSIX layer?
Interesting take! If I were developing a new OS, I certainly wouldn't have a default text terminal... That just looks gross. But my interests differ. I would focus on the graphical user interface as my number one concern. It would always run in a OpenGL type graphics mode, where you could spawn any number of text terminal-style windows, but I would definitely skip a full-screen text mode. Its just never needed. Does…
Interesting take! If I were developing a new OS, I certainly wouldn't have a default text terminal... That just looks gross. But my interests differ. I would focus on the graphical user interface as my number one concern. It would always run in a OpenGL type graphics mode, where you could spawn any number of text terminal-style windows, but I would definitely skip a full-screen text mode. Its just never needed. Does…
Yes and no. There are so many dofferent parts to an operatong system that you quickly favor the text console because its so easy to do. If you are going to work on a GUI first thing, you might as well forgo the operating system bit and just write it as a program in some other OS while you perfect it
I have to say... the code is beautiful: Full English descriptive variable names and nearly every function is documented. As AngularJS has shown, cleaner, consistent code and architecture style = more contributors. Take a look here for example: https://github.com/minoca/os/blob/master/kernel/io/iobase.c#...
Why the initial capital on local variable names? I don't think I've ever seen that in C code. (Usually types and exported functions are capitalized.) It kind of makes the code look like Pascal. Nothing wrong with that, really.
Since Minoca seems to be a Corp., does anyone know what their business strategy will be? I could imagine a) a paid enterprise edition, b) paid support or c) paid consultancy (as in "contract the actual maintainers to implement device drivers for your servers"). Whenever a project is corporate-backed, I like to know the business plan upfront before I consider contributing to it.
Right now it seems that the business model is the MySQL one: provide the code as GPLv3 and sell licenses if someone wants to use it in a proprietary context. And correct me if I am wrong but I think the corp is just the 2 developers right now.
Earlier quoted context omitted.
This looks like the NT kernel coding style, especially with the pointless typedefs for things like PVOID and the PascalCased function names with prefixes like `IopPerformIoOperation`. I looked up the Minoca founders on Linked In and, behold, they both worked as engineers on the Windows NT team. :)
NT source code typically (and I say typically, because it's a mish-mash of tens of thousands of people's work over 35 years of development) has local variable names in first-letter-lower camel case. If these guys worked on Windows, it's kind of surprising they didn't follow that convention.
Earlier quoted context omitted.
The best thing about POSIX at this point is back compatibility, nothing to be sneered at! But it carries a lot of (in retrospect) bad habits and decisions from the 60s and 70s as well as a tendency to redundancy due to some competing standards that were unified and need for some back compatibility. Now not everyone agrees on what is good and what is bad, so some experimentation in this area is good for everyone. Exam…
I think the main issues with POSIX are: - (Correct) IO is ridiculously non-portable and painful in so many ways that it isn't even funny anymore - Locks are ridiculously non-portable and painful to the point where you're better off just using "mkdir" - POSIX is stuck in the "everything is bytes and we slap an encoding on it some of the time" era thinking. This makes it painful and hard to implement proper text handli…
- User level security, instead of app level or task level, or whatever.
- Aged IPC primitives that assume too much to the point that modern hardware has to be built around it (and slower because of that).
- Added later, non-core network support, leading to bad integration.
- Added later, non-core, or sometimes never added encryption support, leading to bad integration.