4 ms·

Sadly, I don't have any link -- it was a commercial and proprietary soft real-time system, mainly for embedded use (we made it as portable as we could, but neve

Sadly, I don't have any link -- it was a commercial and proprietary soft real-time system, mainly for embedded use (we made it as portable as we could, but never ported it to something truly general-purpose like x86). It was functional and reliable more than it was fancy. Certainly nowhere near the scope of Redox. But it had preemptive multi-tasking, a driver model somewhat akin to Linux's (but without loadable modules) and some networking support, which we managed to fit in a few KB of RAM. I'm saying all this in the past tense because the company was sold off a few years ago and I have no idea what happened to the IP, if anyone is still developing it and so on. I only wanted to mention it because operating systems have this intimidating reputation, which is not only a little unfair, but seems to hold people back. I've seen a lot of very good programmers thinking they couldn't be part of a team that develops one, when it was in fact well within their possibilities. And, historically, this has been true for a very long time. Many applications that run on operating systems are far, far more difficult to program than the system they're running on, or at least require vastly more knowledge in order to get right than writing the OS. > Your website is interesting but a tad hard to follow due to the "organization" scheme. ;) The joy I get out of doing it again vastly outweighs the pain of writing HTML by hand, but barely :-).

nickpsecurity 11y ago
Good work. Not quite an OS like what they're trying to build, though. I've always thought these discussions could benefit from different categories of OS like single vs multi-user, UNIX-like vs non, embedded vs desktop vs server, local vs distributed, and so on. A soft-real-time, single-user OS is much easier to write than a UNIX alternative that's similar in capabilities. So, one can certainly write a RTOS more easily than many applications on servers or desktops but the statement seems apples to oranges applied to mainstream perception of OS's (aka desktops, servers, or iOS/Android). "The joy I get out of doing it again vastly outweighs the pain of writing HTML by hand, but barely :-)." Haha. I can't talk given how disorganized my stuff is. Hell, I don't even have a blog: I have text files and PDF's I send to people that ask. Gopher is on another level compared to how I do things. Nonetheless, it's good to know people that did embedded systems as I'm slowly accumulating knowledge on that sort of thing in my exploration of secure hardware/software systems. Really wish I spent more time on embedded and HDL's back when my brain worked reliably. That's where best bang-for-buck in security and reliability are. The more people write openly on such topics the better. So, consider organizing anything you have on the magic you used to do stuff like that web server. Side note. I'm peripherally gaining information on doing 8- or 16-bit software for microcontrollers. Hell, I even have some docs (and maybe HDL source) on a 1-bitter although with 8-bit ALU. Do you have any resources I can give to new people showing the tricks people use to reliably do complex or fast stuff with them? SymbOS would probably be high-end of that but I intend to use them in peripheral controllers, monitoring, and such.
- notalaser 11y ago
  > Good work. Not quite an OS like what they're trying to build, though. Absolutely, that's why we managed to get something that worked, despite being at least six times as few people who also had to work on other projects :-). Redox is an order of magnitude more complex, because it's trying to solve problems that are an order of magnitude more complex. I just want to dispel some of the "black magic" air around these things. > Side note. I'm peripherally gaining information on doing 8- or 16-bit software for microcontrollers. Hell, I even have some docs (and maybe HDL source) on a 1-bitter although with 8-bit ALU. Do you have any resources I can give to new people showing the tricks people use to reliably do complex or fast stuff with them? SymbOS would probably be high-end of that but I intend to use them in peripheral controllers, monitoring, and such. You mean re. digital design, or microcontroller software? If it's the latter, I'm not sure what to recommend... most of what I know is stuff that every programmer knows + experience you get out of working on embedded devices (and, of course, failing a lot). Fundamentally, programming these devices is no different than programming other computing devices (save, perhaps, for the Harvard architecture, but that's fairly inconsequential), you just work based on other assumptions regarding what's acceptable in terms of failure, performance degradation and so on. I guess related resources that might help a lot would be: * Jean Labrosse has a series on his uC/OS kernels. I think the latest is uC/OS-III. I haven't read it, but Labrosse's work in general is extraordinary, so this book may be what you're looking for. * If you don't mind Ada, Building Parallel, Embedded, and Real-Time Applications with Ada is a pretty good book on the subject, too. I've skimmed it and at least the aspects related to reliability are well-treated. * If you haven't already read it, van der Linden's "Expert C Programming" is still a very good read. I don't doubt that languages such as Rust and Go are the future for programming higher-end systems, but I don't see C going away on the lower-end in the next 10-15 years, and frankly, I don't think Rust solves too many of the problems I encounter on these systems. * For dealing with resource-constrained systems in general, Bitsavers.org has exceptional stuff, but it requires some digging and extrapolation. Old computers are a semi-serious hobby of mine -- it's fun, but I also learned a lot of interesting things from studying old systems. Good recommendations may come from Ganssle's (www.ganssle.com) Embedded Muse, too. Oh, speaking of which... > I have text files and PDF's I send to people that ask. ...can I ask :-)?

nickpsecurity 11y ago

Good work. Not quite an OS like what they're trying to build, though. I've always thought these discussions could benefit from different categories of OS like single vs multi-user, UNIX-like vs non, embedded vs desktop vs server, local vs distributed, and so on. A soft-real-time, single-user OS is much easier to write than a UNIX alternative that's similar in capabilities. So, one can certainly write a RTOS more easily than many applications on servers or desktops but the statement seems apples to oranges applied to mainstream perception of OS's (aka desktops, servers, or iOS/Android). "The joy I get out of doing it again vastly outweighs the pain of writing HTML by hand, but barely :-)." Haha. I can't talk given how disorganized my stuff is. Hell, I don't even have a blog: I have text files and PDF's I send to people that ask. Gopher is on another level compared to how I do things. Nonetheless, it's good to know people that did embedded systems as I'm slowly accumulating knowledge on that sort of thing in my exploration of secure hardware/software systems. Really wish I spent more time on embedded and HDL's back when my brain worked reliably. That's where best bang-for-buck in security and reliability are. The more people write openly on such topics the better. So, consider organizing anything you have on the magic you used to do stuff like that web server. Side note. I'm peripherally gaining information on doing 8- or 16-bit software for microcontrollers. Hell, I even have some docs (and maybe HDL source) on a 1-bitter although with 8-bit ALU. Do you have any resources I can give to new people showing the tricks people use to reliably do complex or fast stuff with them? SymbOS would probably be high-end of that but I intend to use them in peripheral controllers, monitoring, and such.

notalaser 11y ago
> Good work. Not quite an OS like what they're trying to build, though. Absolutely, that's why we managed to get something that worked, despite being at least six times as few people who also had to work on other projects :-). Redox is an order of magnitude more complex, because it's trying to solve problems that are an order of magnitude more complex. I just want to dispel some of the "black magic" air around these things. > Side note. I'm peripherally gaining information on doing 8- or 16-bit software for microcontrollers. Hell, I even have some docs (and maybe HDL source) on a 1-bitter although with 8-bit ALU. Do you have any resources I can give to new people showing the tricks people use to reliably do complex or fast stuff with them? SymbOS would probably be high-end of that but I intend to use them in peripheral controllers, monitoring, and such. You mean re. digital design, or microcontroller software? If it's the latter, I'm not sure what to recommend... most of what I know is stuff that every programmer knows + experience you get out of working on embedded devices (and, of course, failing a lot). Fundamentally, programming these devices is no different than programming other computing devices (save, perhaps, for the Harvard architecture, but that's fairly inconsequential), you just work based on other assumptions regarding what's acceptable in terms of failure, performance degradation and so on. I guess related resources that might help a lot would be: * Jean Labrosse has a series on his uC/OS kernels. I think the latest is uC/OS-III. I haven't read it, but Labrosse's work in general is extraordinary, so this book may be what you're looking for. * If you don't mind Ada, Building Parallel, Embedded, and Real-Time Applications with Ada is a pretty good book on the subject, too. I've skimmed it and at least the aspects related to reliability are well-treated. * If you haven't already read it, van der Linden's "Expert C Programming" is still a very good read. I don't doubt that languages such as Rust and Go are the future for programming higher-end systems, but I don't see C going away on the lower-end in the next 10-15 years, and frankly, I don't think Rust solves too many of the problems I encounter on these systems. * For dealing with resource-constrained systems in general, Bitsavers.org has exceptional stuff, but it requires some digging and extrapolation. Old computers are a semi-serious hobby of mine -- it's fun, but I also learned a lot of interesting things from studying old systems. Good recommendations may come from Ganssle's (www.ganssle.com) Embedded Muse, too. Oh, speaking of which... > I have text files and PDF's I send to people that ask. ...can I ask :-)?