diff options
Diffstat (limited to 'src/rss.xml')
| -rw-r--r-- | src/rss.xml | 392 |
1 files changed, 392 insertions, 0 deletions
diff --git a/src/rss.xml b/src/rss.xml new file mode 100644 index 0000000..5788d02 --- /dev/null +++ b/src/rss.xml @@ -0,0 +1,392 @@ +<?xml version="1.0" encoding="UTF-8"?> +<rss version="2.0" + xmlns:atom="http://www.w3.org/2005/Atom" + xmlns:dc="http://purl.org/dc/elements/1.1/" + xmlns:sy="http://purl.org/rss/1.0/modules/syndication/" +> +<channel> +<title>Carbs Linux</title> +<description>a simple busybox linux distribution</description> +<link>https://carbslinux.org</link> +<atom:link href="https://carbslinux.org/rss.xml" rel="self" type="application/rss+xml" /> +<lastBuildDate>Jun Sat 2020 20:00</lastBuildDate> +<item> +<title>June Newspost</title> +<pubDate>Wed, 17 Jun 2020</pubDate> +<dc:creator>Cem Keylan</dc:creator> +<link>https://carbslinux.org/blog/20200617.html</link> +<description><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&rsquo;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&rsquo;s see how that&rsquo;s going to play out.</p></description> +</item> +<item> +<title>kiss 2.0.0 and overall changes</title> +<pubDate>Thu, 28 May 2020</pubDate> +<dc:creator>Cem Keylan</dc:creator> +<link>https://carbslinux.org/blog/20200528.html</link> +<description><h1>kiss 2.0.0 and overall changes</h1> + +<p>Carbs Linux kiss version 2.0.0 has been released which introduces +rsync repositories.</p> + +<p>Git is no longer a mandatory dependency for the package manager, +every git source on the core repository has been replaced with +https sources (sbase, sinit), and rootfs tarballs will no longer +ship with git. Repositories in the upcoming tarball will be rsync +repositories.</p> + +<p>Git is now on the <code>extra</code> repository and is still (optionally) +used in the package manager.</p> + +<p>The idea behind this change is size reductions and increased +speed with rsync. As I said on the previous post, git repositories +get larger and larger over the time span. Currently my personal +copy of the git repository is around 77MB and I have forked KISS +Linux (as a shallow copy) around December. Obviously, I have commits +that I ommitted. I tend to create commits I dislike, which I change +with &lsquo;git reset &ndash;soft HEAD^&rsquo;, which doesn&rsquo;t actually remove the +commits, etc. A user will have a repository much smaller than mine.</p> + +<p>This is a precaution with the added bonuses of speed and dropping a +mandatory dependency.</p> + +<p>You can see the rest of the changelog <a href="https://github.com/CarbsLinux/kiss/blob/master/CHANGELOG.md">here</a>.</p> + +<h2>Binary Repositories</h2> + +<p>A few days ago, I have also published <a href="https://github.com/CarbsLinux/kiss-bin">kiss-bin</a>, a first version +for managing binary repositories. Currently, there are some caveats +that I&rsquo;ll be fixing along the way. I decided not to include this +in the package manager natively as managing the source based and +binary based packages together adds levels of complexity that we +do not want. Instead, this is an extension for kiss which sources +the package manager as a library. I hope to see it being adopted +by others interested on the matter as well.</p> + +<p>That&rsquo;s about it.</p> + +<p>Cheers, +Cem</p></description> +</item> +<item> +<title>The Relation of Carbs and KISS</title> +<pubDate>Fri, 08 May 2020</pubDate> +<dc:creator>Cem Keylan</dc:creator> +<link>https://carbslinux.org/blog/20200508.html</link> +<description><h1>The Relation of Carbs and KISS</h1> + +<p><strong>Date:</strong> May 08 2020</p> + +<p>Since I have forked KISS, I have received many questions +that can be summarized as &ldquo;Why?&rdquo;. I have realized that I +never truly answered this question. That&rsquo;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 +&ldquo;FAQ&rdquo; page later on.</p> + +<h2>History</h2> + +<p>I had the idea of creating my own Linux distribution since +the May of 2019. Back then, I had my own <a href="https://linuxfromscratch.org">Linux from Scratch</a> +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&rsquo;t satisfied with anything I had built.</p> + +<p>I had written some incomplete package managers (all named <code>fat</code>) +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 &ldquo;initial commit&rdquo; until a program I write +is in a usable state.</p> + +<p>I have obtained the &lsquo;carbslinux.org&rsquo; domain name in September +2019, but then life got on the way, and I stopped for a long +time.</p> + +<p>One day on Reddit, I saw Dylan&rsquo;s post on <a href="https://reddit.com/r/unixporn">r/unixporn</a> about +KISS, and I really thought that it was interesting. Here is +my <a href="https://www.reddit.com/r/unixporn/comments/ducd34/sowm_kiss_d/f7lua7x">comment</a> 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.</p> + +<h2>Differences between KISS and Carbs</h2> + +<p>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&rsquo;t something like a +downstream fork of KISS, it is just a distribution that was +initially based on KISS.</p> + +<p>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.</p> + +<h2>What I&rsquo;m working on now</h2> + +<p>Currently I have a few projects that I&rsquo;m working on for Carbs. +These are,</p> + +<p>A BSD port for Carbs. For a while, I have been working on BSD +compatibility on my fork of the <a href="https://github.com/carbslinux/kiss">package manager</a>. 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&rsquo;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.</p> + +<p>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.</p> + +<p>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.</p> + +<h2>What&rsquo;s up with all the init/service daemons?</h2> + +<p>If you have ever checked the <a href="https://github.com/carbslinux/repository">repository</a>, 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 <a href="https://github.com/cemkeylan/shinit">init daemon</a> +and <a href="https://github.com/cemkeylan/sysmgr">service supervisor</a>. I maintain all those packages on KISS +Community Repository as well with the exception of busybox. Those +are, <code>busybox init/runit</code>, <code>runit</code>, <code>sinit</code>, and <code>sysmgr</code>. I would +definitely recommend checking out <code>shinit</code> and <code>sysmgr</code>.</p> + +<h2>Why I don&rsquo;t publicize Carbs</h2> + +<p>There are a couple of reasons I don&rsquo;t publicize Carbs a lot.</p> + +<p>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.</p> + +<p>Since I cannot answer questions like &ldquo;What is the difference?&rdquo;, I +prefer staying as the silent sibling project of KISS Linux. Plus, +there is no point in dividing the newly-emerging community in half.</p> + +<p>That&rsquo;s not because I don&rsquo;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.</p> + +<p>I think that&rsquo;s about it, if you have questions you can send me a +mail, ping me on IRC (my handle is <code>merakor</code>), and I will be happy +to answer. Maybe your question fits this post, and I can update it +to thoroughly give an explanation.</p> + +<p>Cheers, +Cem</p></description> +</item> +<item> +<title>Outsource Repository Concept</title> +<pubDate>Fri, 10 Apr 2020</pubDate> +<dc:creator>Cem Keylan</dc:creator> +<link>https://carbslinux.org/blog/20200410.html</link> +<description><h1>Outsource Repository Concept</h1> + +<p>In April 3rd, I have added submodule support for Carbs +Linux&rsquo;s fork of <code>kiss</code>. Now, from that sentence, it really +doesn&rsquo;t sound exciting at all. But in reality, it opens a +path to lots of creative output, and a better way to manage +multi-user repositories (such as KISS Community).</p> + +<p>When managing a repository of submodules, the repository +maintainer&rsquo;s only job is to deal with adding packages. +A package maintainer doesn&rsquo;t have to wait for the repository +maintainer to update their packages, as they are only making +the changes to their own repositories.</p> + +<p>This way, an end-user can also track from their preferred +maintainers, and do that with the tidyness of a single repository +in their <code>KISS_PATH</code>.</p> + +<p>Carbs Linux now has an outsource repository for some packages. +Firefox and its dependencies have been purged from the main repository, +but can be found on it.</p> + +<p><a href="https://github.com/CarbsLinux/outsource">https://github.com/CarbsLinux/outsource</a></p></description> +</item> +<item> +<title>Roadmap for Carbs</title> +<pubDate>Mon, 06 Apr 2020</pubDate> +<dc:creator>Cem Keylan</dc:creator> +<link>https://carbslinux.org/blog/20200406.html</link> +<description><h1>Roadmap for Carbs</h1> + +<p>It has been a busy week. There are lots of changes in +direction, and more to come. I want to talk a little +about all of them.</p> + +<h2>Carbs Linux Server Going Down</h2> + +<p>It became harder to maintain and pay for the server, and I will be +shutting it down in May. I am currently in the phase of +carrying over everything to <a href="https://github.com/CarbsLinux">Github</a>. The repository and the +website is served on Github now. I have also moved the <a href="https://github.com/CarbsLinux/wiki/wiki">Wiki</a> +to Github and anyone can edit it there. There are some outdated +posts that I will be fixing around this week.</p> + +<p>I am not quite sure where to store the downloads page now. But I +will be switching that to a new source as well. (Maybe Source Forge?)</p> + +<p>I feel a little sad for switching, but serving on Github is faster, +cheaper, and hassle-free.</p> + +<h2>Forking KISS</h2> + +<p>I had a personal fork of KISS, which I enjoyed thoroughly. I didn&rsquo;t +intend to make it the default when I started it, but it has matured +enough to be so. The package manager can now be found on <a href="https://github.com/CarbsLinux/kiss">this repository</a>. +See it for the added changes.</p> + +<p>This will be a change for the better, as I can develop the package +manager as it fits my views.</p> + +<h2>Small Changes on the Website</h2> + +<p>I have made some small changes on the website. The build is not dependent +on Plan9 utilities anymore. It was fun messing around with <code>rc</code> and <code>mk</code>, +but they are quite limited compared to POSIX shell.</p> + +<p>RSS feeds are finally working as intended, both for the <a href="https://carbslinux.org/news.xml">news</a> section, and +the <a href="https://carbslinux.org/rss.xml">blog</a> secion.</p> + +<p>You can see every page&rsquo;s <code>.txt</code> output at the end of the page by clicking +&lsquo;View Page Source&rsquo;. Meanwhile, I will be updating some pages to be a little +more &lsquo;human-readable&rsquo;.</p> + +<h2>Outsources Repository</h2> + +<p>I have opened an <code>outsource</code> repository, which I will be pushing this week. +I will add a new post when I am ready to push it. I think it will be interesting, +it will also make more sense about the changes I have added to the package +manager. The now empty repository, can be found <a href="https://github.com/CarbsLinux/outsource">here</a>!</p> + +<h2>New Tarball</h2> + +<p>Finally, I have released a new tarball today, which can be obtained from the +<a href="https://dl.carbslinux.org/releases">downloads page</a>.</p> + +<p>I am planning to add more of these update posts as I&rsquo;m feeling better about +the website structure overall.</p> + +<p>- Cem</p></description> +</item> +<item> +<title>Switching to New Website</title> +<pubDate>Tue, 28 Jan 2020</pubDate> +<dc:creator>Cem Keylan</dc:creator> +<link>https://carbslinux.org/blog/20200128.html</link> +<description><h1>Switching to New Website</h1> + +<p><strong>Date:</strong> Jan 28 2020</p> + +<p>In case you haven&rsquo;t seen it before, this website +was powered by <a href="http://werc.cat-v.org">werc</a>. And +even though I liked it really much, it was too +powerful for a small website like this.</p> + +<p>So I have decided to reimplement this website with +my own static generation scripts. The source will +probably be on <a href="https://carbslinux.org/git/website/log.html">https://carbslinux.org/git/website/log.html</a> +when I decide to publish the website.</p> + +<p>The generation requires Plan9 programs, although +I have used them just for my enthusiasm. I have built +the site with a combination of mk (instead of make), rc, +and POSIX sh. I am not yet exactly familiar with rc, +but I will replace the shell scripts when I feel like +I can.</p></description> +</item> +</channel> +</rss> |