As you develop software, you are a creator of intellectual property yourself. Do you think it’s okay to engage in piracy?
Depends on what it’s for. If the product costs a lot, for what it is, I may pirate it. If it is cheap, and the people who developed it, actually need the money from the buyers, I may buy it,
You have been rather adamant about others not stealing from you.
Though you seem to have a more cavalier attitude about you stealing from others.
What an incredible self-righteousness!
You have been rather adamant about others not stealing from you.
Good point. I may reconsider my view on pirating, but it still depends on what I am pirating. If I am pirating a retro game from the 80s, there isn’t anywhere, where I can clearly buy it, and most copies of retro games which are considered pirated, are on legal websites like the Internet Archive.
and this is a book that’s still legally available and used in university courses on operating systems
My views on piracy are two-fold – I would like people to respect the licenses on the software I myself I write, but at the same time it is okay if the software/content/etc. cannot be practically acquired legitimately today (i.e. it is not being sold anymore), excluding extreme means such as buying a whole used computer and physically removing ROM chips just to extract the code from them.
This may be a stupid question.
I was wondering, do I have to initialize the ram on the luckfox lyra in the kernel, or do I just set variables of how much ram the system has, as I do want Astralixi OS to be easily port-able to other hardware.
So how do I do this, without other developers, needing to re-write the whole kernel if they want to port Astralixi OS to their hardware, and all they would have to do it write drivers for their hardware.
How far have you got with reading and understanding the book I recommended?
PS: By the way, I didn’t just recommend the book. I also suggested that you first find a goal in software development that is easier to achieve. Wouldn’t that be a better start?
I’ve read chapter 1 and 2 of the book.
What do you think are achivable goals for my OS because as this will be last version, the goals are the following:
- port the OS to Luckfox Lyra
- add a TUI/basic GUI
- allow app running through C
- allow plugins (to change UI, add features etc) through C
- make some basic apps
- add few new features
- make sure whole OS takes 16mb or ram
- test for ANY bugs
- release
So you’ve read 2 out of 18 chapters, and just the introduction
A more achievable list would start with postponing the OS
Start with making the apps you want for a different OS, that way you know what features your OS needs to support
Then make your OS an actual OS on the pico, not the lyra
Port the apps you made earlier to your OS
At some point learn why your obsession with ram usage makes little sense
Bug free code is a lie, and a final release means unmaintained software which most people won’t use
Honestly, if I wanted to learn to build an actual OS, on the cheap and without pirating stuff, I’d branch a working open source version I liked, look at what it’s doing, and try modifing it to suit my needs and goals.
As it’s a learning exercise, I’d leave it open and WELCOME people to look at it, offer criticisms, point out issues, and offer suggestions.
Or go retro to a simpler time, and build one for an 8-bit processor.
I don’t get your obsession with the Luckfox Lyra – it is an essentially closed platform meant only for use with Linux. I would highly recommend targeting the RP2350 myself – it is much more open, still has a decent amount of SRAM, and is fast enough for very many applications.
Also, by aiming for really ambitious targets like this you are just setting yourself up for failure. I would think much smaller – try starting out doing something like writing a very simple round-robin multitasking kernel (e.g. Linus Torvalds started out with a kernel with two processes, one which displayed "A"s on the console and one which displayed "B"s on the console; I would recommend doing the same), and only once that is working start thinking bigger, and then only gradually. Don’t try to attack lofty targets in one go.
I’m going for the luckfox lyra, to make the PicoCalc my main computer, with more processing power.
Is it possible to achieve a simple goal, by having a CLI operating system?
Like would anyone get disappointed if I switched from TUI to CLI. I might not switch, but I might.
Don’t be angry with me, but no one will be disappointed.
If you ever build an OS, I doubt that it will offer any advantages over established systems that anyone will use it. Setting this goal is evidence of a lack of knowledge or megalomania.
If, in 10 years’ time, I realise that I was wrong and Astralixi is the system of choice, I will be happy to say that I chatted with the genius who created it and underestimated him.
However, the fact is that, based on what I read in your posts today, you have such fundamental questions about the topic that the goal is currently far too ambitious.
Remember that in Unix-like operating systems, you still have the shell, and TUI and GUI interfaces on top of that are mere optional add-ons fundamentally. A proper shell is far more flexible and powerful than a typical TUI or GUI anyways when implemented properly. Of course, TUI’s and GUI’s have their place, e.g. a TUI is often much more friendly for editing text (e.g. emacs, vi) than a pure command line text editor (e.g. the infamous standard text editor, ed).
My own OS for the PicoCalc, zeptoforth, uses a Forth REPL as its shell, and the only areas in which it even gets into the realm of TUI’s are its text editors (e.g. zeptoed). I have never thought “wouldn’t it be great if zeptoforth had an elaborate TUI or GUI in the place of its Forth REPL”.
One thing to remember that when implementing a shell is that a good shell is more than just a parser of parameters that are fed into commands. Rather, a good shell allows having things like user-defined commands and scripts and means for tying together different commands and scripts to make more elaborate commands. For instance, the zeptoforth REPL exposes the full power of the Forth language to the user, including not only user-defined Forth words, variables, constants, buffers, exceptions, and like, but also features such as filesystems, console IO redirection, tasks, streams, channels, locks, semaphores, heaps, and pools. With such features it gives considerable power to the user, far beyond that provided by a mere command parser.
Where can I find all the pin definitions and other documents for the Luckfox Lyra and all of the PicoCalc’s peripherals (display, keyboard and sdcard slot)
#define LCD_SCL (10) // serial clock (SCL)
#define LCD_SDI (11) // serial data in (SDI)
#define LCD_SDO (12) // serial data out (SDO)
#define LCD_CSX (13) // chip select (CSX)
#define LCD_DCX (14) // data/command (D/CX)
#define LCD_RST (15) // reset (RESET)