Hi.
My name is Ahmed. I'm a civil engineer
![Smile :) :)](https://cdn.jsdelivr.net/joypixels/assets/8.0/png/unicode/64/1f642.png)
-but all my works are electrical engineer- I'm a developer at Microsoft Tech Club at all I'm still a student
![Frown :( :(](https://cdn.jsdelivr.net/joypixels/assets/8.0/png/unicode/64/1f641.png)
![Smile :) :)](https://cdn.jsdelivr.net/joypixels/assets/8.0/png/unicode/64/1f642.png)
. I'm new to FreeBSD. I want to create my own OS and for sure it will be Unix based. At first I was thinking of Linux but when I heard that BSD is more advanced and secure than any distro of Linux so I've changed my mind. I want to make new icons on KDE or Gnome and new Boot Screen new look for it and change its name for ex I will call it Ahmed Os which Is Based On FreeBSD and it's going to be open source.
So the question is can I create my own OS based on FreeBSD and it will feature a GUI and a BootScreen and a New Name and custom install. I mean to change the install into a graphical installation program like for example Fedora Linux. Can I do that? So if it's possible I want the tutorials.
Hello Ahmed,
I have been developing for FreeBSD for 15 years now and I still don't have it all down yet. I also write code for Microsoft Windows (Applications that run on Windows, not Windows itself as I don't work for Microsoft), and I am a member of the Windows Insider Program, Microsoft Developer Network, and Microsoft TechNet. As you probably know, programming is both an art and a science. To answer your question, in terms of the law, yes. You can build your own derivative of FreeBSD. However, there is a lot of code that forms the base system. Not just the tools and such, but also the kernel. As other people have stated, if you are asking for tutorials to do what you are asking, you won't get very far. Entire books have been written about the subject and there's still more to write.
Remember when I said that programming is both an art and a science? Well, kernel development, and OS development in general goes so far beyond being an art and a science it can be considered to be magic. I have personally written code that runs in kernel space, and it is very easy to panic (BSOD) the system when coding on the other side of the system call tree. I have written a
very simple OS myself that consists of 384 bytes of program which ran on a PIC microcontroller. That environment uses something called cooperative multitasking which means that the programs on there play nice with each other and the OS. However, Windows, Linux, *BSDs, Mac OSX, and others use something known as preemptive multitasking. That type of multitasking is when a program is running along happily minding it's own business and the operating system comes in and rudely severs the program from the CPU and gives it to another program. To pull this off is quite complicated and requires a lot of code. You have to code a scheduler that runs off the interval timer ticks which cuts the CPU time into slices. Those slices are then given to the programs that are running in the system according to some algorithm or priority scheme.
That is
ONE consideration. Another consideration is the platform that this will run on. I would, could, and did write a simple OS for a microcontroller (although it was just a kernel). However, I would not recreate an OS for a common platform like IA-32 or AMD-64 (Intel x86 32-bit and 64-bit) as there are plenty of operating systems around, many of which are free (like FreeBSD). That's when you take an existing system, tailor it for your uses, and then go from there. Not only that, there are multiple platforms to choose from. FreeBSD has Tier 1 support for several (IA-32 & AMD-64 being among them). FreeBSD also has Tier 2 support for other (Sun Sparc comes to mind) platforms as well. Check out the release notes.
So here's a basic list of what you need to consider (What I can think of):
- What are you trying to accomplish?
- What hardware will it run on?
- What peripherals are available?
- How much memory is there?
- How much mass storage is there?
- What type of mass storage?
- What file system will be on the mass storage?
- Communications (Input/Output/Networking)
- What language will it be written in?
- What administrative tools will be available?
I'm sure that others will add to that list. The language bullet point requires a little bit of explanation. FreeBSD, and all Unix to my knowledge is written primarily in C. There is some C++, but it's mostly in C. The rest of it, is written in machine dependent assembler. This is to perform some actions with the hardware that is machine dependent which C doesn't support. Additionally, you will also need to write a device driver for each peripheral that the machine will have attached to it, or potentially have attached.
And then there are the tools that come with the system. The reason why I like the *BSDs, vendor unix's, and Windows, is that it is a fully defined operating system with a kernel, support tools and utilities, a compiler with support tools, and a shell. When dealing with Linux, that's just a kernel. You have to add everything else to it. Hence the 200+ distributions. There's some rather complete and standard ones like SuSE, Slackware, Debian, Red Hat, Fedora Core, etc... however, there's others that leave a bad taste in my mouth like Lindows/Linspire. That one doesn't have the man command. Yes, you read that right. There is no manual with the system.
All of this is just for the OS. The GUI is another type of animal all together. The GUI runs on top of the OS, and it can potentially have even
MORE code than the OS itself has (and often does). With a GUI, the biggest consideration is the video driver. I have written display drives for software pre-Windows 95 running under DOS. What mode will it run in? What resolution? Most of the graphical installers use a standard non-accelerated mode like a VGA 640x480x4 (16 colors) which is available on all VGA cards since about 1993 or so. Once you have decided that, you have to write routines to draw lines, circles, text, window bounds, field bounds, BIT-BLK, etc. Because of the object oriented organization of the interface, C++ is generally used here. The low level routines are generally written in C for administrative routines, or assembler for the actual drawing routines. Then things get more complicated with the accelerators. There is a reason why GPU manufacturers supply their own drivers for their chipsets. Each chipset has its own hardware interface and custom routines. Don't second guess the vendor on how to program their cards.
Now, we need to talk about the installer. The things to consider for the installer are as follows, and I'm sure people will add to this list as well:
- What is the archive format?
- Is the archive compressed?
- What is the disk layout?
- What is the disk format?
- What tools and utilities will the installer have available?
- What is the file database format?
And this is the short list. The archive format is how the files are stored in the source media. FreeBSD uses chunks when installing, but I don't know the details of the actual format those chunks are in. Source files are generally compressed to save space on the installation media or to save network bandwidth. So you will need to consider what compression algorithm do you want to use, if any. The disk layout is how you want things organized. The usual file setup is as follows:
- /boot
- /bin
- /sbin
- /libexec
- /tmp
- /home
- /usr
- /usr/tmp
- /usr/bin
- /usr/sbin
- /usr/src (usually linked as /src)
- /var
- /etc
Solaris and other System V (including most Linux) systems have a /net where some programs go. Not sure behind the rhyme or reason of what goes in /net vs. /usr though. In addition to where to put files, you also have to consider partitioning as well. For me personally, I run two disk systems with the following configurations:
Then you have to consider the format of the file database. This contains the names of the files in the archive, where they will be installed too, and what permissions to install them with.
So, for what your are asking, there's a lot to consider. If you choose to go through with it, then by all means. Open a new project on sourceforge or github, get people to join your project, because it is a project. I am not trying to discourage you, just trying to give you a glimpse into the realities of what you are trying to accomplish. Besides, it's not impossible as this has been done at least twice before (that I am aware of). Apple Macintosh OS-X userland was based on a FreeBSD 4.x using their Mach kernel. The other one was a full fork known as DragonflyBSD. I don't know the details of the reasons behind the fork, but I do know that it was highly political, which I try to avoid.
Have fun and keep coding.