design your own distro

[lit]code your own language | design-your-own-distro[lit] | [[dictionary-of-programming-concepts]] | [[build-your-own-freedom-lab]] | [[free-media-alliance-best-practices]] | [[quasi]] | [[which-language-should-i-use]]


when you switch your computer on, the first thing youre likely to see is the bios screen. this typically shows the logo for your laptop, desktop or main computer board. it often lets you press keys to choose whether you boot from the hard drive, usb or dvd. you can control pretty much everything that happens after that. because unless youve made a bootable usb, dvd or cd, its probably going to start whatever os you already have on the hard drive. a distribution or "distro", fundamentally, is a collection of software. it is typically bootable, so the only other thing you need to run it is a computer. the reason people say "distro" instead of operating system, is that its much easier to make your own distro than your own operating system-- most distros are the same o.s.: a combination of the **gnu** operating system and the **linux** kernel. although there are other combinations, your distro is probably going to consist of: 1. a bootloader (possibly 2) 2. a kernel (probably linux) which manages the lower-level (machine) aspects of the system 3. an "initrd" which is a file that contains the software needed to start up the system 4. an init system, which manages the startup and higher-level management of the system 5. a text-based shell (possibly a few) 6. a graphical shell (optional) 7. a desktop or window management program (possibly several) 8. applications if this seems like a lot to worry about, please note that several of the choices to make here are based on popularity (others are based on personal preference) and for starters, the bootloader is probably going to be isolinux (part of syslinux) on the cd or dvd, and grub2 if you install the os on the computer. grub2 is by far the most popular option, but your bootable dvd / cd / usb will probably run some part of syslinux. if you read about these, you will probably feel overwhelmed. the truth is, most people who create a distro dont know a lot about either of these things, and you probably wont need to. your first distro will probably include the gnu operating system and the linux kernel, and the initrd is a pretty standard thing now. you might not even decide to make your own, but tweak an existing one. that leaves you to worry about: 1. the init system 2. the text shell 3. the graphical shell 4. the desktop 5. applications and although they are different categories of application, items 2-4 are basically applications themselves. a distro is easier to take apart or change than put together, so we will offer advice on that to get you started. making changes to an existing distro is called "remastering", and thats probably the best way to get started making your own distro. nonetheless, it is good to start thinking about overall design from the beginning.

why design a distro?

good reasons to design a distro are: [lit]*[lit] for fun [lit]*[lit] for learning [lit]*[lit] to create a tool that is useful to you [lit]*[lit] for teaching [lit]*[lit] to remove "suck" if you were lucky enough to use gnu[lit]/[lit]linux between 2007 and 2014, you knew what it was like in its prime. before 2007 or so, gnu[lit]/[lit]linux was still climbing up the ladder in terms of usability, stability and support. 2007 to 2014 was an era of mostly progress. towards the end of this era, the ongoing war against free software entered a new phase at the expense of users. for half a decade, people have worked constantly to remove "suck" from the newer, crappier gnu[lit]/[lit]linux. that doesnt mean that nothing has improved, but a new resistance is forming (and necessary.) some of the increasingly common attacks on free software bear similarity to those used against other competitors of certain large corporations: [url][url] one of the latest attacks is arbitrarily removing floppy support from the kernel. techreport described it this way: "linux is *staying with the times* by dropping support for floppy drives." this is just about the dumbest thing ive ever heard about gnu[lit]/[lit]linux in my life. theres absolutely no advantage to dropping floppy disk support whatsoever. it doesnt provide a security problem, it doesnt bloat the kernel (and it could be made into a separate module if it did) and its one of the most fundamental devices in home computing-- of all time. windows continues to support floppy drives-- so is this "staying with the times" going to put the kernel ahead of windows? certainly not. its a stupid move with likely dubious motivations. floppy drives do still exist, they havent changed much in 20 years, and its not like the kernel developers to drop something like this for no reason. but its one more example of the "suck" that is increasing (for no actual reason) with the ongoing war. could you add floppy support back to the kernel? you could, actually. but more likely is that someone will make a version of the kernel with floppy supported added back in, and then you would add that kernel version to your distro. just because its possible for you to do the work yourself, doesnt mean youre likely to end up doing it all yourself. but this is getting ahead of ourselves. before you decide to take on the distro world, lets talk about some easier things you can do to get started.

a quick start

the first thing you want to do to get started, is try a gnu[lit]/[lit]linux distro. one of the best distros available is refracta: [url][url] download the most recently-dated iso file with the architecture of your system, amd64 or i386. if you dont know which architecture you have, it is probably amd64, but the i386 version will generally work on both! you need the "image write" or "iso write" option of your cd[lit]/[lit]dvd writing software to write the iso to a dvd. this will create a refracta dvd that you can start up your computer with. starting a computer with a live dvd is tricky if you havent done it before. when the bios screen displays, you generally have a few moments to hit a certain key on the keyboard-- and the key varies by brand and model. the screen will usually display a hint as to which key to use. you may need to go to bios options to disable uefi and secure boot. note that you will need to change these back to run windows again-- if you are serious about getting into free software and gnu[lit]/[lit]linux, it is recommended you obtain a computer you can remove all the software and files (including windows) from. even a 5 or 6-year-old computer can be very useful for this. (if it is older than that, 10 years for example, there are good odds even that will work. you probably want at least 1.5 to 2 gb of ram.) "boot options" if available, will let you try to boot from the dvd without going to the bios. if this fails, you will want to find out how to get to the bios settings on your computer and disable uefi. what do you do when you start using this system? start taking notes of what you would change!

realistic expectations

no matter how reasonable your goals are, your first distro isnt going to be everything you want it to be. youre going to find limitations along the way. if your goal is to make a very useful distro, youre going to need experience first. so enjoy making your first project and dont try too hard at first. its alright, and even a good idea to start with small changes. a distro is ultimately a collection of software and configurations, so changes are going to come down to adding, removing and setting up software. refracta comes with one of the best remaster tools, for which the distro is named: "refracta tools". this lets you start up the computer, make changes to the system, and save or "snapshot" those changes into a bootable distro like refracta itself. this is the "manual" way of remixing a distro.

creating your own language-- for remastering

eventually you may want to try automating your remaster. automating means *creating a system that does the remastering for you.* the difference between a distro builder script and an automated remaster script, is that a builder will generally create a distro without having a starter iso to remix-- and an automated remaster will make automatic changes to an existing iso. functions vital to a language designed for remastering include a way to run shell commands, commands for processing strings, commands for running shell command and then getting the output into a string or array and commands for opening, reading and writing files. you will need shell routines for mounting iso files, and probably running unsquashfs and mksquashfs, since most distros use these to produce the filesystem for a bootable live distro.

true heroes and the politics of suck

people like to avoid politics, because they lead to drama. however, politics and drama are never put aside-- they are only postponed. the best, most ideal politics, can postpone a lot of drama for decades, while people are generally (and genuinely) satisfied. eventually, even these politics fail and have to be renewed, renegotiated, and won back again. depending on your goals, you can avoid politics pretty successfully. first, be easygoing and just go along with other peoples ideas. then, when someone does something thats really bad for people, but no one else is saying anything-- dont say anything. the bad politics arent your fault, but as the first person to say it, the blame will be shifted to you. always putting the team ahead of the goals for a good distro will keep you out of politics, and keep people treating you like a friend. of course if you care about software, or the user-- now youre screwed. because youre going to meet people who pretend to care, who use that as a stepping stone for controlling the project, and theyre going to walk all over these team players. whether it takes months, years or even decades, sooner or later these people will take over. it will start with increased policing of what can only be called "niceness." there will be new standards of "nice" even though people were getting along pretty well until recently. oh no, people will argue-- i mean, its not like things were bad all the time, but there were some really bad flamewars in the past and that sort of thing costs us valuable contributions. lets be clear about that-- any important decision you make is going to gain the project some valuable contributions and cost others. this doesnt mean you shouldnt care-- you absolutely should. but you cant in all instances, because eventually people who dont care are going to blackmail the project with charges of not caring-- and in order to care, you will have to be "agreeable" with them. it doesnt matter who you are-- this has happened to people as central to free software and open source as richard stallman (the founder of free software) and linus torvalds (the author of the linux kernel.) suddenly, "niceness" matters even more than the core or foundation of the thing itself. and of course, "niceness" is subjective. not everybody agrees (or will agree) on what it means. it will ultimately mean what those who really control the project want it to mean. you will find changes in this meaning around times of great upheaval and takeovers-- coups in large projects where the community is right, and other people need a way to do whats wrong. as to right and wrong, it really depends on what you think. some people want to make themselves intermediaries, so that you need them if you want something to change. these people will not care about you educating yourself, they will not care about talk of "freedom" and they wont respect a diversity of opinions-- which is a natural outcome of freedom. the computer "user" isnt sacred per se, but to some people they are sheep and to other people they are significant. what is the significance of the user? everybody is one-- status as a user is the thing we all have in common. user rights are rights for everyone. so the people working on free software projects fall pretty neatly into two camps: *developer-centric*: this doesnt mean technical vs. non-technical. no matter how its done, putting an operating system together is a technical effort, even if its automated. developer-centric means that developers are largely a different class than users-- that we can really ignore the users needs, in favour of developers. one argument youll find used as a false defense of the developer-centric approach is that developers are volunteers, and you should be grateful (and they are not slaves.) this false argument is neatly based on facts: volunteers are not slaves, and there is a time for gratitude. sometimes though, when there is upheaval, the people making the most problems actually are not volunteers-- someone is paying them to do their work, and they are working more for the benefit of the people paying them than for the benefit of the project. most aspects of this arrangement are not necessarily a conflict of interest and theres nothing wrong with paying someone to develop free software. but sometimes the people making trouble are not volunteers, and they are doing things that do not benefit the project-- so why should there be gratitude? this is one of the "ins" where niceness turns into political takeover. *user-centric*: a user-centric approach simply means that the freedom of the user is often taken into account, the needs of the user factor in to a reasonable degree, and developers are not treated as an increasingly separate class. it is possible to have a user-centric project that still leaves the final votes on things with developers, since they are doing the actual work (and may have more technical awareness of the needs of the project.) sometimes this is necessary for quality control. however, when a project that is already user-centric moves towards being developer-centric, you will find great and ongoing protests from users (sometimes there are brief spats, and they dont really count) but other times, you have a takeover that happens within the developer group and the community supports the developers maintaining quality, while other developers use various political strategies to put their motives ahead of the community and common benefit. this is when the community starts to lose what say they always had, and when the project starts to suffer badly. the effects can last for years, and very rarely will a project recover-- staying power through a problem of this magnitude is not common, but it takes a while (often years) for a very large project to fall apart entirely. since the user-centric approach is better for most large projects, making people as equal as reasonably possible and not creating unnecessary divides and takeovers, this guide will suggest choices that suit this purpose. lots of people want to be permanent intermediaries, in simulation of the companies that make non-free software. the real heroes of free software, are the ones who maintain and recover projects from permanent intermediaries, and always try to put more and more power in the hands of the user. thats no easy task, and much easier said than done. but it is what will be advocated here. its impossible to talk about why certain features are recommended over others, without addressing this first.


as alluded to previously, the most popular operating system that you can remix, and the one with the widest range of applications and ease-of-use (from friendly-first to advanced) is the gnu operating system with the linux kernel. the most likely bootloader for your live dvd (remixing to a cd size is also possible) is isolinux from syslinux, and it is recommended you not start with worrying about the initrd. this is sometimes the trickier part of the distro to modify, and there are various ways of accomplishing it depending on how the distro is put together. hopefully there will be better, more modular tools for doing that in the future. if you accept that challenge as an experienced developer, thank you. so once again, this leaves us to focus on these features of the distro: 1. the init system 2. the text shell 3. the graphical shell 4. the desktop 5. applications several good init systems exist. examples are openrc, gnu shepherd, sysvinit and runit. each of these have their own strengths and weaknesses, but it is recommended that you avoid systemd. it is hosted and developed on servers that are controlled by microsoft, which is a fine example of a company you dont want controlling the key infrastructure of your operating system. as bradley m. kuhn puts it: "microsoft is unique among proprietary software companies: *they are the only ones who have actively tried to kill [free software]*. it's not often someone wants to be your friend after trying to kill you for ten years" additionally, systemd is heavily criticised year after year for taking control away from users and from communities. it is an incredibly divisive software project, which won its lead developer a pwnie award for his attitude towards security. it is possible to run an operating system without an init. for most people, the init provides a "first process" (process id 1) that runs even when other processes fail-- it will often include tools to manage processes-- particularly ones that start, stop and restart in the background. before the shells start, there are login processes that precede them. users typically dont worry about the init, but people who create distros do. unless you have a specific reason to change the init, or unless you are trying to get rid of systemd, the best thing to do is probably just use whatever init comes with the distro builder, automated remastering script or remaster tool. swapping out init systems is sometimes trivial-- often not. which brings us to:

the text shell

most operating systems actually start the text shell before the graphical shell. even most macs running os[lit]/[lit]x (now macos) have a single-user mode that starts in a text-only shell. when the system starts up, after the bios screen and the bootloader, (which can typically run as text-only or in graphics or "framebuffer" modes) the kernel and initrd will load the system. this is often displayed on screen as a series of messages that indicate if startup was [ ok ] or [ failed ] and sometimes there are warnings. the warnings are often nothing to be concerned about, and some distros choose to cover this part of the process up with a boot splash, graphic or animation. you can choose to customise these, but doing to requires the initrd to be opened, modified and then compressed into a single file again. finally there are typically one or more "virtual" screens opened, which you can switch between using ctrl-alt-f1 through ctrl-alt-fn, where fn is the function key number corresponding to that screen. each virtual screen may include a login prompt (text-based) or graphical login manager, if you have a graphical shell running.

the graphical shell

(coming soon) if you have questions, and you already have a neocities account, ask here: [url][url] if you dont have an account, join neocities here: [url][url] or a forum here: [url][url]

[lit]happy coding![lit]