aboutsummaryrefslogtreecommitdiff
path: root/blog/20200508.org
blob: 1df12e79dc4f0cb3bf1e33a2db3d2b28fc67440a (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
#+TITLE: The Relation of Carbs and KISS
#+AUTHOR: Cem Keylan
#+DATE: <2020-05-08 Fri>

Since I have forked KISS, I have received many questions that can be summarized
as "Why?". I have realized that I never truly answered this question. That's the
reason I am writing this post, to give some background on Carbs, and some
differences between KISS Linux and Carbs Linux for anyone who may be wondering.
Perhaps I could make this a "FAQ" page later on.

** History
:PROPERTIES:
:CUSTOM_ID: history
:END:

I had the idea of creating my own Linux distribution since the May of 2019. Back
then, I had my own [[https://linuxfromscratch.org][Linux from Scratch]] build, and I wanted to slim it down my
own way and replace the software (with musl,sbase,etc.). The name Carbs Linux
was in my mind since then. I wanted to write my own package manager, but I
wasn't satisfied with anything I had built.

I had written some incomplete package managers (all named =fat=) and I quickly
threw them into the trash can, where they honestly belonged. I would want to
share them with you for laughs, but my hard-drive got wiped and I have a problem
of not doing an "initial commit" until a program I write is in a usable state.

I have obtained the 'carbslinux.org' domain name in September 2019, but then
life got on the way, and I stopped for a long time.

One day on Reddit, I saw Dylan's post on [[https://reddit.com/r/unixporn][r/unixporn]] about KISS, and I really
thought that it was interesting. Here is my [[https://www.reddit.com/r/unixporn/comments/ducd34/sowm_kiss_d/f7lua7x][comment]] to Dylan on that post. I
checked out the package manager and the repository. The packaging system was
extremely clean and well-thought. I decided to give it a go and fork KISS.

** Differences between KISS and Carbs
:PROPERTIES:
:CUSTOM_ID: differences-between-kiss-and-carbs
:END:

Now, I still baffle when people ask me this question. My intention was never to
create a distribution with specific differences between KISS. My intention was
being my own BDFL of a distribution I maintain. There are lots of differences
between the main repositories, but they are subtle and not worth talking about.
I personally never even installed KISS Linux on my system. So Carbs, isn't
something like a downstream fork of KISS, it is just a distribution that was
initially based on KISS.

I try to contribute as much as I can to KISS Linux. I think that it is a
brilliant distribution, and it was a great starting point for Carbs. I am really
grateful to Dylan and all the other contributors.

** What I'm working on now
:PROPERTIES:
:CUSTOM_ID: what-im-working-on-now
:END:

Currently I have a few projects that I'm working on for Carbs. These are,

A BSD port for Carbs. For a while, I have been working on BSD compatibility on
my fork of the [package manager]. I have tested, without any more issues, on
OpenBSD and FreeBSD. The biggest issues remaining are choosing a vendor for BSD,
packaging the BSD source, and providing a minimal base (like busybox for BSD).
If you aren't familiar with BSD, it has a single source code for all of the
utilities (kernel, command line programs, etc.). Contributions (even chipping in
ideas) are very welcome.

Adding binary package distribution support natively to the package manager.
Biggest issue in small/old computers are compile times. This feature is for the
bigger packages such as webkit, clang, llvm that take a considerable amount of
time. Some computers with low memories cannot even compile firefox/webkit.

Adding rsync repository support to the package manager. This is not a current
issue, but rather a futureproofing. As time passes, distribution repositories
grow larger. KISS and Carbs are young distributions without this problem right
now. But in something like 5 years, this size will presumably increase to
hundreds of megabytes. At that point it will be pointless to have the repository
sources unless you specifically need them.

** What's up with all the init/service daemons?
:PROPERTIES:
:CUSTOM_ID: whats-up-with-all-the-init-service-daemons
:END:

If you have ever checked the [[https://github.com/carbslinux/repository][repository]], you may have noticed that there are
lots of init/service related packages. I have had my fair share of time with all
of them, and it is an area that I am really interested in. I have even written
my own [[https://github.com/cemkeylan/shinit][init daemon]] and [[https://github.com/cemkeylan/sysmgr][service supervisor]]. I maintain all those packages on KISS
Community Repository as well with the exception of busybox. Those are, =busybox
init/runit=, =runit=, =sinit=, and =sysmgr=. I would definitely recommend
checking out =shinit= and =sysmgr=.

** Why I don't publicize Carbs
:PROPERTIES:
:CUSTOM_ID: why-i-dont-publicize-carbs
:END:

There are a couple of reasons I don't publicize Carbs a lot.

KISS is the better alternative in terms of support and community. I work on
maintaining this distribution just as hard as Dylan, but in the end, Carbs is
based on his original hard work, and I believe that he deserves the recognition
more than I do.

Since I cannot answer questions like "What is the difference?", I prefer staying
as the silent sibling project of KISS Linux. Plus, there is no point in dividing
the newly-emerging community in half.

That's not because I don't have ideas for the future of Carbs, I do. I just
think that I will deserve the recognition once those above lists are checked.

I think that's about it, if you have questions you can send me a mail, ping me
on IRC (my handle is =merakor=), and I will be happy to answer. Maybe your
question fits this post, and I can update it to thoroughly give an explanation.