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
|
<!DOCTYPE HTML>
<html lan=en>
<head>
<title>June Newspost | Carbs Linux</title>
<link rel="stylesheet" href="/style.css">
<meta charset="utf-8">
<meta name="Description" content="Carbs Linux - a simple linux distribution">
<meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no">
</head>
<body>
<p class=header><strong>Carbs Linux - a simple linux distribution</strong></p>
<div class="header">
<nav>
<a href='/'>index</a>
<a href="//git.carbslinux.org">git</a>
<a href='//dl.carbslinux.org'>downloads</a>
<a href='/blog'>blog</a>
<a href='/docs/install.html'>installation</a>
</nav>
</div><div class="border"></div>
<h1>June Newspost</h1>
<p>This will be an active month for Carbs as major changes to the base and the
package manager will be coming up.</p>
<h2>Statically linking the base</h2>
<p>For the past couple of weeks I have been trying to simplify the base and
statically link the core (mostly binaries rather than libraries). I usually see
some people extremely opposed to static linking as I also see the opposite on
people.</p>
<p>I believe that binaries on the core should always be linked statically. This
ensures that an SONAME bump to <code>libObscure.so</code> will not break the core
functionality of your system, forcing you to use external resources to recover
from such an issue. As long as you can compile, use core utilities, edit text,
and access the web, you can solve any given issue on your system.</p>
<p>However, I don’t think that removing shared libraries is sensible either. Not
every piece of software out there is good quality enough to be statically
linked.</p>
<h2>Major changes on the core repository</h2>
<p>There have been drastic changes to the core repository and the base rootfs this
month (with more on the way). Right now changes are as follows.</p>
<h3>Removed from Core</h3>
<ul>
<li><code>git</code></li>
<li><code>libressl</code></li>
<li><code>grub</code></li>
<li><code>bison</code></li>
<li><code>dhcpcd</code></li>
<li><code>ubase</code></li>
</ul>
<h3>Added to Core</h3>
<ul>
<li><code>bearssl</code>, as a <code>libressl</code> replacement</li>
<li><code>byacc</code>, as a <code>bison</code> replacement</li>
</ul>
<h3>Statically linked</h3>
<ul>
<li><code>kiss</code></li>
<li><code>neatvi</code></li>
<li><code>mandoc</code></li>
<li><code>byacc</code></li>
<li><code>m4</code></li>
<li><code>e2fsprogs</code></li>
<li><code>make</code></li>
<li><code>pkgconf</code></li>
<li><code>sbase</code></li>
<li><code>libnl</code></li>
<li><code>wpa_supplicant</code></li>
<li><code>bearssl</code></li>
</ul>
<h2>Making the wiki available offline</h2>
<p>Soon, all documentation regarding Carbs Linux will be avaialable to be installed
from the core repository in a <code>carbs-docs</code> package along with its own document
crawler. Currently, the documentation regarding the installation process is a
little outdated which will also receive some important updates.</p>
<h2>ISO image for Carbs</h2>
<p>I am thinking of releasing an ISO image in order to provide a standardized
environment for installation along with installation helper tools in the spirit
of <code>arch-install-scripts</code>. Let’s see how that’s going to play out.</p>
<a href="/blog/20200617.txt">View Page Source</a>
<div class="border"></div>
<p class=footer>Linux® is a registered trademark of Linus Torvalds</p>
<p class=footer>Copyright © 2019-2020 Cem Keylan</p>
</body>
</html>
|
