Compare commits

...
10 Commits
Author SHA1 Message Date
Astral 691736a62c state packages come from github only
Deploy website to GitHub Pages / deploy (push) Canceled after 21s
2026-09-01 11:48:40 +02:00
Astral 32094c5541 remove keru.org references 2026-09-01 11:45:46 +02:00
Astral 0e8885c162 redesign website to black and bone, add user contact 2026-09-01 11:39:33 +02:00
Astral da28f784a8 add website and GitHub Pages deployment 2026-09-01 11:23:34 +02:00
Astral cb1da62339 simplify installer, drop eval, fix network check 2026-09-01 10:57:46 +02:00
Astral 535ccc1ffc boot straight into the installer from the live ISO 2026-09-01 08:38:22 +02:00
Astral 6b65014d64 update installer and docs 2026-09-01 08:21:01 +02:00
Astral 6729f58ed6 expand swappable component options 2026-09-01 08:06:22 +02:00
Astral f0b06a1685 Remove ISO build tooling (deferred to later) 2026-09-01 08:04:35 +02:00
Astral 4805fe0f90 Add AGPL-3.0 license and ける branding 2026-09-01 08:02:21 +02:00
67 changed files with 5113 additions and 171 deletions
+29
View File
@@ -0,0 +1,29 @@
name: Deploy website to GitHub Pages
on:
push:
branches: [main]
workflow_dispatch:
permissions:
contents: read
pages: write
id-token: write
concurrency:
group: pages
cancel-in-progress: true
jobs:
deploy:
runs-on: ubuntu-latest
environment:
name: github-pages
url: ${{ steps.deployment.outputs.page_url }}
steps:
- uses: actions/checkout@v4
- uses: actions/upload-pages-artifact@v3
with:
path: web
- uses: actions/deploy-pages@v4
id: deployment
+661
View File
@@ -0,0 +1,661 @@
GNU AFFERO GENERAL PUBLIC LICENSE
Version 3, 19 November 2007
Copyright (C) 2007 Free Software Foundation, Inc. <https://fsf.org/>
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
Preamble
The GNU Affero General Public License is a free, copyleft license for
software and other kinds of works, specifically designed to ensure
cooperation with the community in the case of network server software.
The licenses for most software and other practical works are designed
to take away your freedom to share and change the works. By contrast,
our General Public Licenses are intended to guarantee your freedom to
share and change all versions of a program--to make sure it remains free
software for all its users.
When we speak of free software, we are referring to freedom, not
price. Our General Public Licenses are designed to make sure that you
have the freedom to distribute copies of free software (and charge for
them if you wish), that you receive source code or can get it if you
want it, that you can change the software or use pieces of it in new
free programs, and that you know you can do these things.
Developers that use our General Public Licenses protect your rights
with two steps: (1) assert copyright on the software, and (2) offer
you this License which gives you legal permission to copy, distribute
and/or modify the software.
A secondary benefit of defending all users' freedom is that
improvements made in alternate versions of the program, if they
receive widespread use, become available for other developers to
incorporate. Many developers of free software are heartened and
encouraged by the resulting cooperation. However, in the case of
software used on network servers, this result may fail to come about.
The GNU General Public License permits making a modified version and
letting the public access it on a server without ever releasing its
source code to the public.
The GNU Affero General Public License is designed specifically to
ensure that, in such cases, the modified source code becomes available
to the community. It requires the operator of a network server to
provide the source code of the modified version running there to the
users of that server. Therefore, public use of a modified version, on
a publicly accessible server, gives the public access to the source
code of the modified version.
An older license, called the Affero General Public License and
published by Affero, was designed to accomplish similar goals. This is
a different license, not a version of the Affero GPL, but Affero has
released a new version of the Affero GPL which permits relicensing under
this license.
The precise terms and conditions for copying, distribution and
modification follow.
TERMS AND CONDITIONS
0. Definitions.
"This License" refers to version 3 of the GNU Affero General Public License.
"Copyright" also means copyright-like laws that apply to other kinds of
works, such as semiconductor masks.
"The Program" refers to any copyrightable work licensed under this
License. Each licensee is addressed as "you". "Licensees" and
"recipients" may be individuals or organizations.
To "modify" a work means to copy from or adapt all or part of the work
in a fashion requiring copyright permission, other than the making of an
exact copy. The resulting work is called a "modified version" of the
earlier work or a work "based on" the earlier work.
A "covered work" means either the unmodified Program or a work based
on the Program.
To "propagate" a work means to do anything with it that, without
permission, would make you directly or secondarily liable for
infringement under applicable copyright law, except executing it on a
computer or modifying a private copy. Propagation includes copying,
distribution (with or without modification), making available to the
public, and in some countries other activities as well.
To "convey" a work means any kind of propagation that enables other
parties to make or receive copies. Mere interaction with a user through
a computer network, with no transfer of a copy, is not conveying.
An interactive user interface displays "Appropriate Legal Notices"
to the extent that it includes a convenient and prominently visible
feature that (1) displays an appropriate copyright notice, and (2)
tells the user that there is no warranty for the work (except to the
extent that warranties are provided), that licensees may convey the
work under this License, and how to view a copy of this License. If
the interface presents a list of user commands or options, such as a
menu, a prominent item in the list meets this criterion.
1. Source Code.
The "source code" for a work means the preferred form of the work
for making modifications to it. "Object code" means any non-source
form of a work.
A "Standard Interface" means an interface that either is an official
standard defined by a recognized standards body, or, in the case of
interfaces specified for a particular programming language, one that
is widely used among developers working in that language.
The "System Libraries" of an executable work include anything, other
than the work as a whole, that (a) is included in the normal form of
packaging a Major Component, but which is not part of that Major
Component, and (b) serves only to enable use of the work with that
Major Component, or to implement a Standard Interface for which an
implementation is available to the public in source code form. A
"Major Component", in this context, means a major essential component
(kernel, window system, and so on) of the specific operating system
(if any) on which the executable work runs, or a compiler used to
produce the work, or an object code interpreter used to run it.
The "Corresponding Source" for a work in object code form means all
the source code needed to generate, install, and (for an executable
work) run the object code and to modify the work, including scripts to
control those activities. However, it does not include the work's
System Libraries, or general-purpose tools or generally available free
programs which are used unmodified in performing those activities but
which are not part of the work. For example, Corresponding Source
includes interface definition files associated with source files for
the work, and the source code for shared libraries and dynamically
linked subprograms that the work is specifically designed to require,
such as by intimate data communication or control flow between those
subprograms and other parts of the work.
The Corresponding Source need not include anything that users
can regenerate automatically from other parts of the Corresponding
Source.
The Corresponding Source for a work in source code form is that
same work.
2. Basic Permissions.
All rights granted under this License are granted for the term of
copyright on the Program, and are irrevocable provided the stated
conditions are met. This License explicitly affirms your unlimited
permission to run the unmodified Program. The output from running a
covered work is covered by this License only if the output, given its
content, constitutes a covered work. This License acknowledges your
rights of fair use or other equivalent, as provided by copyright law.
You may make, run and propagate covered works that you do not
convey, without conditions so long as your license otherwise remains
in force. You may convey covered works to others for the sole purpose
of having them make modifications exclusively for you, or provide you
with facilities for running those works, provided that you comply with
the terms of this License in conveying all material for which you do
not control copyright. Those thus making or running the covered works
for you must do so exclusively on your behalf, under your direction
and control, on terms that prohibit them from making any copies of
your copyrighted material outside their relationship with you.
Conveying under any other circumstances is permitted solely under
the conditions stated below. Sublicensing is not allowed; section 10
makes it unnecessary.
3. Protecting Users' Legal Rights From Anti-Circumvention Law.
No covered work shall be deemed part of an effective technological
measure under any applicable law fulfilling obligations under article
11 of the WIPO copyright treaty adopted on 20 December 1996, or
similar laws prohibiting or restricting circumvention of such
measures.
When you convey a covered work, you waive any legal power to forbid
circumvention of technological measures to the extent such circumvention
is effected by exercising rights under this License with respect to
the covered work, and you disclaim any intention to limit operation or
modification of the work as a means of enforcing, against the work's
users, your or third parties' legal rights to forbid circumvention of
technological measures.
4. Conveying Verbatim Copies.
You may convey verbatim copies of the Program's source code as you
receive it, in any medium, provided that you conspicuously and
appropriately publish on each copy an appropriate copyright notice;
keep intact all notices stating that this License and any
non-permissive terms added in accord with section 7 apply to the code;
keep intact all notices of the absence of any warranty; and give all
recipients a copy of this License along with the Program.
You may charge any price or no price for each copy that you convey,
and you may offer support or warranty protection for a fee.
5. Conveying Modified Source Versions.
You may convey a work based on the Program, or the modifications to
produce it from the Program, in the form of source code under the
terms of section 4, provided that you also meet all of these conditions:
a) The work must carry prominent notices stating that you modified
it, and giving a relevant date.
b) The work must carry prominent notices stating that it is
released under this License and any conditions added under section
7. This requirement modifies the requirement in section 4 to
"keep intact all notices".
c) You must license the entire work, as a whole, under this
License to anyone who comes into possession of a copy. This
License will therefore apply, along with any applicable section 7
additional terms, to the whole of the work, and all its parts,
regardless of how they are packaged. This License gives no
permission to license the work in any other way, but it does not
invalidate such permission if you have separately received it.
d) If the work has interactive user interfaces, each must display
Appropriate Legal Notices; however, if the Program has interactive
interfaces that do not display Appropriate Legal Notices, your
work need not make them do so.
A compilation of a covered work with other separate and independent
works, which are not by their nature extensions of the covered work,
and which are not combined with it such as to form a larger program,
in or on a volume of a storage or distribution medium, is called an
"aggregate" if the compilation and its resulting copyright are not
used to limit the access or legal rights of the compilation's users
beyond what the individual works permit. Inclusion of a covered work
in an aggregate does not cause this License to apply to the other
parts of the aggregate.
6. Conveying Non-Source Forms.
You may convey a covered work in object code form under the terms
of sections 4 and 5, provided that you also convey the
machine-readable Corresponding Source under the terms of this License,
in one of these ways:
a) Convey the object code in, or embodied in, a physical product
(including a physical distribution medium), accompanied by the
Corresponding Source fixed on a durable physical medium
customarily used for software interchange.
b) Convey the object code in, or embodied in, a physical product
(including a physical distribution medium), accompanied by a
written offer, valid for at least three years and valid for as
long as you offer spare parts or customer support for that product
model, to give anyone who possesses the object code either (1) a
copy of the Corresponding Source for all the software in the
product that is covered by this License, on a durable physical
medium customarily used for software interchange, for a price no
more than your reasonable cost of physically performing this
conveying of source, or (2) access to copy the
Corresponding Source from a network server at no charge.
c) Convey individual copies of the object code with a copy of the
written offer to provide the Corresponding Source. This
alternative is allowed only occasionally and noncommercially, and
only if you received the object code with such an offer, in accord
with subsection 6b.
d) Convey the object code by offering access from a designated
place (gratis or for a charge), and offer equivalent access to the
Corresponding Source in the same way through the same place at no
further charge. You need not require recipients to copy the
Corresponding Source along with the object code. If the place to
copy the object code is a network server, the Corresponding Source
may be on a different server (operated by you or a third party)
that supports equivalent copying facilities, provided you maintain
clear directions next to the object code saying where to find the
Corresponding Source. Regardless of what server hosts the
Corresponding Source, you remain obligated to ensure that it is
available for as long as needed to satisfy these requirements.
e) Convey the object code using peer-to-peer transmission, provided
you inform other peers where the object code and Corresponding
Source of the work are being offered to the general public at no
charge under subsection 6d.
A separable portion of the object code, whose source code is excluded
from the Corresponding Source as a System Library, need not be
included in conveying the object code work.
A "User Product" is either (1) a "consumer product", which means any
tangible personal property which is normally used for personal, family,
or household purposes, or (2) anything designed or sold for incorporation
into a dwelling. In determining whether a product is a consumer product,
doubtful cases shall be resolved in favor of coverage. For a particular
product received by a particular user, "normally used" refers to a
typical or common use of that class of product, regardless of the status
of the particular user or of the way in which the particular user
actually uses, or expects or is expected to use, the product. A product
is a consumer product regardless of whether the product has substantial
commercial, industrial or non-consumer uses, unless such uses represent
the only significant mode of use of the product.
"Installation Information" for a User Product means any methods,
procedures, authorization keys, or other information required to install
and execute modified versions of a covered work in that User Product from
a modified version of its Corresponding Source. The information must
suffice to ensure that the continued functioning of the modified object
code is in no case prevented or interfered with solely because
modification has been made.
If you convey an object code work under this section in, or with, or
specifically for use in, a User Product, and the conveying occurs as
part of a transaction in which the right of possession and use of the
User Product is transferred to the recipient in perpetuity or for a
fixed term (regardless of how the transaction is characterized), the
Corresponding Source conveyed under this section must be accompanied
by the Installation Information. But this requirement does not apply
if neither you nor any third party retains the ability to install
modified object code on the User Product (for example, the work has
been installed in ROM).
The requirement to provide Installation Information does not include a
requirement to continue to provide support service, warranty, or updates
for a work that has been modified or installed by the recipient, or for
the User Product in which it has been modified or installed. Access to a
network may be denied when the modification itself materially and
adversely affects the operation of the network or violates the rules and
protocols for communication across the network.
Corresponding Source conveyed, and Installation Information provided,
in accord with this section must be in a format that is publicly
documented (and with an implementation available to the public in
source code form), and must require no special password or key for
unpacking, reading or copying.
7. Additional Terms.
"Additional permissions" are terms that supplement the terms of this
License by making exceptions from one or more of its conditions.
Additional permissions that are applicable to the entire Program shall
be treated as though they were included in this License, to the extent
that they are valid under applicable law. If additional permissions
apply only to part of the Program, that part may be used separately
under those permissions, but the entire Program remains governed by
this License without regard to the additional permissions.
When you convey a copy of a covered work, you may at your option
remove any additional permissions from that copy, or from any part of
it. (Additional permissions may be written to require their own
removal in certain cases when you modify the work.) You may place
additional permissions on material, added by you to a covered work,
for which you have or can give appropriate copyright permission.
Notwithstanding any other provision of this License, for material you
add to a covered work, you may (if authorized by the copyright holders of
that material) supplement the terms of this License with terms:
a) Disclaiming warranty or limiting liability differently from the
terms of sections 15 and 16 of this License; or
b) Requiring preservation of specified reasonable legal notices or
author attributions in that material or in the Appropriate Legal
Notices displayed by works containing it; or
c) Prohibiting misrepresentation of the origin of that material, or
requiring that modified versions of such material be marked in
reasonable ways as different from the original version; or
d) Limiting the use for publicity purposes of names of licensors or
authors of the material; or
e) Declining to grant rights under trademark law for use of some
trade names, trademarks, or service marks; or
f) Requiring indemnification of licensors and authors of that
material by anyone who conveys the material (or modified versions of
it) with contractual assumptions of liability to the recipient, for
any liability that these contractual assumptions directly impose on
those licensors and authors.
All other non-permissive additional terms are considered "further
restrictions" within the meaning of section 10. If the Program as you
received it, or any part of it, contains a notice stating that it is
governed by this License along with a term that is a further
restriction, you may remove that term. If a license document contains
a further restriction but permits relicensing or conveying under this
License, you may add to a covered work material governed by the terms
of that license document, provided that the further restriction does
not survive such relicensing or conveying.
If you add terms to a covered work in accord with this section, you
must place, in the relevant source files, a statement of the
additional terms that apply to those files, or a notice indicating
where to find the applicable terms.
Additional terms, permissive or non-permissive, may be stated in the
form of a separately written license, or stated as exceptions;
the above requirements apply either way.
8. Termination.
You may not propagate or modify a covered work except as expressly
provided under this License. Any attempt otherwise to propagate or
modify it is void, and will automatically terminate your rights under
this License (including any patent licenses granted under the third
paragraph of section 11).
However, if you cease all violation of this License, then your
license from a particular copyright holder is reinstated (a)
provisionally, unless and until the copyright holder explicitly and
finally terminates your license, and (b) permanently, if the copyright
holder fails to notify you of the violation by some reasonable means
prior to 60 days after the cessation.
Moreover, your license from a particular copyright holder is
reinstated permanently if the copyright holder notifies you of the
violation by some reasonable means, this is the first time you have
received notice of violation of this License (for any work) from that
copyright holder, and you cure the violation prior to 30 days after
your receipt of the notice.
Termination of your rights under this section does not terminate the
licenses of parties who have received copies or rights from you under
this License. If your rights have been terminated and not permanently
reinstated, you do not qualify to receive new licenses for the same
material under section 10.
9. Acceptance Not Required for Having Copies.
You are not required to accept this License in order to receive or
run a copy of the Program. Ancillary propagation of a covered work
occurring solely as a consequence of using peer-to-peer transmission
to receive a copy likewise does not require acceptance. However,
nothing other than this License grants you permission to propagate or
modify any covered work. These actions infringe copyright if you do
not accept this License. Therefore, by modifying or propagating a
covered work, you indicate your acceptance of this License to do so.
10. Automatic Licensing of Downstream Recipients.
Each time you convey a covered work, the recipient automatically
receives a license from the original licensors, to run, modify and
propagate that work, subject to this License. You are not responsible
for enforcing compliance by third parties with this License.
An "entity transaction" is a transaction transferring control of an
organization, or substantially all assets of one, or subdividing an
organization, or merging organizations. If propagation of a covered
work results from an entity transaction, each party to that
transaction who receives a copy of the work also receives whatever
licenses to the work the party's predecessor in interest had or could
give under the previous paragraph, plus a right to possession of the
Corresponding Source of the work from the predecessor in interest, if
the predecessor has it or can get it with reasonable efforts.
You may not impose any further restrictions on the exercise of the
rights granted or affirmed under this License. For example, you may
not impose a license fee, royalty, or other charge for exercise of
rights granted under this License, and you may not initiate litigation
(including a cross-claim or counterclaim in a lawsuit) alleging that
any patent claim is infringed by making, using, selling, offering for
sale, or importing the Program or any portion of it.
11. Patents.
A "contributor" is a copyright holder who authorizes use under this
License of the Program or a work on which the Program is based. The
work thus licensed is called the contributor's "contributor version".
A contributor's "essential patent claims" are all patent claims
owned or controlled by the contributor, whether already acquired or
hereafter acquired, that would be infringed by some manner, permitted
by this License, of making, using, or selling its contributor version,
but do not include claims that would be infringed only as a
consequence of further modification of the contributor version. For
purposes of this definition, "control" includes the right to grant
patent sublicenses in a manner consistent with the requirements of
this License.
Each contributor grants you a non-exclusive, worldwide, royalty-free
patent license under the contributor's essential patent claims, to
make, use, sell, offer for sale, import and otherwise run, modify and
propagate the contents of its contributor version.
In the following three paragraphs, a "patent license" is any express
agreement or commitment, however denominated, not to enforce a patent
(such as an express permission to practice a patent or covenant not to
sue for patent infringement). To "grant" such a patent license to a
party means to make such an agreement or commitment not to enforce a
patent against the party.
If you convey a covered work, knowingly relying on a patent license,
and the Corresponding Source of the work is not available for anyone
to copy, free of charge and under the terms of this License, through a
publicly available network server or other readily accessible means,
then you must either (1) cause the Corresponding Source to be so
available, or (2) arrange to deprive yourself of the benefit of the
patent license for this particular work, or (3) arrange, in a manner
consistent with the requirements of this License, to extend the patent
license to downstream recipients. "Knowingly relying" means you have
actual knowledge that, but for the patent license, your conveying the
covered work in a country, or your recipient's use of the covered work
in a country, would infringe one or more identifiable patents in that
country that you have reason to believe are valid.
If, pursuant to or in connection with a single transaction or
arrangement, you convey, or propagate by procuring conveyance of, a
covered work, and grant a patent license to some of the parties
receiving the covered work authorizing them to use, propagate, modify
or convey a specific copy of the covered work, then the patent license
you grant is automatically extended to all recipients of the covered
work and works based on it.
A patent license is "discriminatory" if it does not include within
the scope of its coverage, prohibits the exercise of, or is
conditioned on the non-exercise of one or more of the rights that are
specifically granted under this License. You may not convey a covered
work if you are a party to an arrangement with a third party that is
in the business of distributing software, under which you make payment
to the third party based on the extent of your activity of conveying
the work, and under which the third party grants, to any of the
parties who would receive the covered work from you, a discriminatory
patent license (a) in connection with copies of the covered work
conveyed by you (or copies made from those copies), or (b) primarily
for and in connection with specific products or compilations that
contain the covered work, unless you entered into that arrangement,
or that patent license was granted, prior to 28 March 2007.
Nothing in this License shall be construed as excluding or limiting
any implied license or other defenses to infringement that may
otherwise be available to you under applicable patent law.
12. No Surrender of Others' Freedom.
If conditions are imposed on you (whether by court order, agreement or
otherwise) that contradict the conditions of this License, they do not
excuse you from the conditions of this License. If you cannot convey a
covered work so as to satisfy simultaneously your obligations under this
License and any other pertinent obligations, then as a consequence you may
not convey it at all. For example, if you agree to terms that obligate you
to collect a royalty for further conveying from those to whom you convey
the Program, the only way you could satisfy both those terms and this
License would be to refrain entirely from conveying the Program.
13. Remote Network Interaction; Use with the GNU General Public License.
Notwithstanding any other provision of this License, if you modify the
Program, your modified version must prominently offer all users
interacting with it remotely through a computer network (if your version
supports such interaction) an opportunity to receive the Corresponding
Source of your version by providing access to the Corresponding Source
from a network server at no charge, through some standard or customary
means of facilitating copying of software. This Corresponding Source
shall include the Corresponding Source for any work covered by version 3
of the GNU General Public License that is incorporated pursuant to the
following paragraph.
Notwithstanding any other provision of this License, you have
permission to link or combine any covered work with a work licensed
under version 3 of the GNU General Public License into a single
combined work, and to convey the resulting work. The terms of this
License will continue to apply to the part which is the covered work,
but the work with which it is combined will remain governed by version
3 of the GNU General Public License.
14. Revised Versions of this License.
The Free Software Foundation may publish revised and/or new versions of
the GNU Affero General Public License from time to time. Such new versions
will be similar in spirit to the present version, but may differ in detail to
address new problems or concerns.
Each version is given a distinguishing version number. If the
Program specifies that a certain numbered version of the GNU Affero General
Public License "or any later version" applies to it, you have the
option of following the terms and conditions either of that numbered
version or of any later version published by the Free Software
Foundation. If the Program does not specify a version number of the
GNU Affero General Public License, you may choose any version ever published
by the Free Software Foundation.
If the Program specifies that a proxy can decide which future
versions of the GNU Affero General Public License can be used, that proxy's
public statement of acceptance of a version permanently authorizes you
to choose that version for the Program.
Later license versions may give you additional or different
permissions. However, no additional obligations are imposed on any
author or copyright holder as a result of your choosing to follow a
later version.
15. Disclaimer of Warranty.
THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY
APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT
HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY
OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO,
THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM
IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF
ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
16. Limitation of Liability.
IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR CONVEYS
THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY
GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE
USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF
DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD
PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS),
EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF
SUCH DAMAGES.
17. Interpretation of Sections 15 and 16.
If the disclaimer of warranty and limitation of liability provided
above cannot be given local legal effect according to their terms,
reviewing courts shall apply local law that most closely approximates
an absolute waiver of all civil liability in connection with the
Program, unless a warranty or assumption of liability accompanies a
copy of the Program in return for a fee.
END OF TERMS AND CONDITIONS
How to Apply These Terms to Your New Programs
If you develop a new program, and you want it to be of the greatest
possible use to the public, the best way to achieve this is to make it
free software which everyone can redistribute and change under these terms.
To do so, attach the following notices to the program. It is safest
to attach them to the start of each source file to most effectively
state the exclusion of warranty; and each file should have at least
the "copyright" line and a pointer to where the full notice is found.
<one line to give the program's name and a brief idea of what it does.>
Copyright (C) <year> <name of author>
This program is free software: you can redistribute it and/or modify
it under the terms of the GNU Affero General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU Affero General Public License for more details.
You should have received a copy of the GNU Affero General Public License
along with this program. If not, see <https://www.gnu.org/licenses/>.
Also add information on how to contact you by electronic and paper mail.
If your software can interact with users remotely through a computer
network, you should also make sure that it provides a way for users to
get its source. For example, if your program is a web application, its
interface could display a "Source" link that leads users to an archive
of the code. There are many ways you could offer source, and different
solutions will be better for different programs; see section 13 for the
specific requirements.
You should also get your employer (if you work as a programmer) or school,
if any, to sign a "copyright disclaimer" for the program, if necessary.
For more information on this, and how to apply and follow the GNU AGPL, see
<https://www.gnu.org/licenses/>.
+7 -4
View File
@@ -7,19 +7,22 @@ SHELL := sh
KAMA ?= ../kama KAMA ?= ../kama
PKGS ?= ../kama-packages PKGS ?= ../kama-packages
.PHONY: iso install recipe-check clean .PHONY: rootfs install live-init recipe-check clean
iso: rootfs:
sh scripts/build-root.sh sh scripts/build-root.sh
sh iso/build-iso.sh
install: install:
sh installer/install.sh sh installer/install.sh
# syntax-check the live init (what boots you into the installer)
live-init:
sh -n live/init && echo "OK live/init"
recipe-check: recipe-check:
@for f in $(PKGS)/*.sh; do \ @for f in $(PKGS)/*.sh; do \
sh -n "$$f" && echo "OK $$f" || echo "FAIL $$f"; \ sh -n "$$f" && echo "OK $$f" || echo "FAIL $$f"; \
done done
clean: clean:
rm -rf iso/work /tmp/keru rm -rf /tmp/keru
+47 -45
View File
@@ -1,11 +1,12 @@
# Keru OS # Keru OS <sub>ける</sub>
An independent, source-only Linux distribution built around one idea: you An independent, source-only Linux distribution built around one idea: you
don't install a system, you *craft* one. don't install a system, you *craft* one — **ける・けいとうてき** (keru keitō-teki): a
system assembled the way you want it.
This repository holds the **operating system itself** — the installer, the ISO This repository is the **operating system itself** — the installer, the
build tooling, the profile system, and the build pipeline. The two things Keru profile system, and the build pipeline. The two things Keru leans on live in
depends on live in their own repositories: their own homes:
- **[kama](https://github.com/AstralZX/kama)** — the package manager (a shell script) - **[kama](https://github.com/AstralZX/kama)** — the package manager (a shell script)
- **[kama-packages](https://github.com/AstralZX/kama-packages)** — the recipe repository - **[kama-packages](https://github.com/AstralZX/kama-packages)** — the recipe repository
@@ -15,61 +16,62 @@ depends on live in their own repositories:
Every package on Keru is built from source by **Kama**, a deliberately small Every package on Keru is built from source by **Kama**, a deliberately small
package manager that simply runs the commands in each recipe. No binary package manager that simply runs the commands in each recipe. No binary
packages, no opaque package machinery. The whole system — toolchain included — packages, no opaque package machinery. The whole system — toolchain included —
is compiled from original source, and the install image is assembled by hand is compiled from original source. What you run, you built.
rather than with a stock tool like archiso.
Runit handles services. The standard Linux kernel drives the hardware. Nothing is fixed. Nothing you didn't ask for is forced on you.
`nmtui` manages networking. Nothing you didn't ask for ends up on the disk.
## The differentiator: craft your system at install time Read the full **philosophy** in [docs/PHILOSOPHY.md](docs/PHILOSOPHY.md).
## The differentiator: everything is swappable
Keru's installer is a TUI that walks you through designing your exact machine Keru's installer is a TUI that walks you through designing your exact machine
*before* it ever boots: *before* it ever boots. Every major component is selectable:
- **init system** — Runit (default), s6, OpenRC, systemd - **init system** — Runit (default), s6, OpenRC, systemd, busybox init, and more
- **C library** — glibc or musl - **C library** — glibc, musl, uClibc-ng, and more
- **filesystem** — ext4, btrfs, xfs, zfs, f2fs - **filesystem** — ext4, btrfs, xfs, zfs, f2fs, jfs, reiserfs, swap, and more
- **kernel** — linux, linux-lts, linux-hardened - **kernel** — linux, linux-lts, linux-hardened, linux-cachyos, and more
- **privilege elevation** — doas, sudo, opendoas, su
- **kernel parameters, locale, clock, keymap** — all configurable
Swappable at install time, fixed at first boot. The system that lands on your Every init, every libc, every filesystem, everything. The selections are made
disk is precisely the one you chose. during install and fixed at first boot. The system that lands on your disk is
precisely the one you chose.
Keru is stable on the combinations it offers you. If you push past what's
proven — an untested libc/init pair, an unmaintained filesystem — the
installer **warns** you the combination is unstable, then gets out of your way.
You're never blocked, only told the truth.
## How installation works
The ISO carries **only the installer** — nothing else. There is no prebuilt
base image on the disk. Boot it and the live init (`live/init`) starts the
installer immediately — no shell prompt, you just make your choices and it
builds. The installer connects to the network, then fetches and builds
whatever you selected (init system, kernel, libc, filesystem tooling, and
tools) on the fly.
A working **network connection is therefore a hard requirement** for
installing Keru. The installer checks connectivity and offers in-installer
network setup (wireless via `nmtui`/`wifi-menu`, or Ethernet/DHCP) before the
build begins.
## Repository layout ## Repository layout
``` ```
installer/ TUI installer — writes make.conf from your choices installer/ TUI installer — auto-starts on boot, writes make.conf from your choices
iso/ from-scratch ISO build tooling (xorriso + squashfs + syslinux)
profile/ make.conf template (the swappables + build flags) profile/ make.conf template (the swappables + build flags)
scripts/ build pipeline: build-root, mkfs-root, common helpers scripts/ build pipeline: build-root, mkfs-root, common helpers
docs/ design docs + the recipe format spec live/ live-ISO init — boots straight into the installer
docs/ philosophy + design docs + the recipe format spec
``` ```
## Building ## Release
The three repos should sit next to each other (or point at each other via Keru OS is currently in development. The first installable release, **0.1**,
`KAMA_DIR` / `PKGS_DIR` / `PKGDIR`): will ship as a bootable ISO — no source builds, no manual tooling required.
It will be made available here when it's ready.
```
~/dev/
├── KeruOS/
├── kama/
└── kama-packages/
```
Then, from `KeruOS/`:
```sh
make install # run the TUI installer
# or, headlessly:
sh scripts/build-root.sh # build a rootfs into /tmp/keru/root
make iso # assemble an install image
```
Requires the sibling `kama` and `kama-packages` repos to be present.
## Status
Design + scaffolding. Nothing is building end-to-end yet.
## License ## License
-19
View File
@@ -1,19 +0,0 @@
# design/index
This directory holds the working design for Keru OS. The code is scaffolding
and not yet functional end-to-end.
## What exists
- `recipe-format.md` — the Kama recipe format (easy/advanced tiers)
- `README.md` (repo root) — project identity + layout
## Open design questions
- **Bootstrapping toolchain**: chicken-and-egg — the first compiler must be
obtained somehow. Options: a documented one-time bootstrap from a binary
seed, or a multi-stage rebuild (host -> minimal -> full). Not yet decided.
- **No dependency resolver**: how upgrades/rebuilds are handled for a system
that's "built once at install." Currently framed as install-time-only.
- **Cache artifacts vs. rebuilds**: whether the build cache stores binaries
for fast re-install or always recompiles.
+109
View File
@@ -0,0 +1,109 @@
# Keru OS — Philosophy
Keru is a source-only Linux distribution built on one governing principle:
> **The OS is a choice, not a conclusion.**
Most distros ship a decision someone else already made for you — a default
init, a default libc, a default filesystem. You inherit it and live with it.
Keru refuses that premise. Every foundational component is a *variable you
resolve at install time*, not a fixed value baked into the distribution.
Every init, every libc, every filesystem, every kernel, every
privilege-elevation tool — all selectable, none forced.
## Anti-opinionated, not opinionated
Keru is not opinionated. It is **anti-opinionated**. An opinionated distro
picks a stack and defends it — *"you get s6 and XFS whether you like it or
not."* Keru is the direct rejection of that. It holds **no opinion** about
which init, libc, filesystem, or daemon you should run, because that decision
belongs to you, not to the distribution.
The distro's only opinion is that you have to form one. After that, it shuts
up and builds exactly what you chose.
## Only what you asked for
The install medium carries **nothing but the installer**. There is no prebuilt
base image, no hidden bloat, no background assumptions. You pick your system,
Keru fetches it and compiles it from source, and the disk reflects exactly
that and nothing more. What gets built is defined by what you chose — not by
what maintainers decided you should have.
## Control without complexity
This is the deliberate bet, and the thing that separates Keru from a
Gentoo-skin. The package manager, **Kama**, is a shell script. It reads a
`make.conf` and runs recipe commands. No dependency solver. No package
database. No compiled manager machinery.
> "Sure, the package manager is in shell, and that compromises performance —
> but it's still faster than many package managers people actually use, and
> the real cost of a build is the compiler, not the meta-machinery around it."
The dependency model is AUR-style ephemeral: build tools are fetched,
compiled, and removed once they've served, so they never accumulate. The
richness lives in the recipes and the profile, not in the machinery. Keru is
the position that package managers became more complex than the packages they
manage, and that the simple version is the right one.
> "A package manager doesn't need a resolver to be honest. It needs to be
> legible — you can read every decision it makes, because every decision is a
> script or a line in make.conf you can see and change."
## Squared with reality
Building every init, every libc, every filesystem from source at install time
requires a working network connection, and the installer is honest about that:
connectivity is a hard gate, and network setup happens inside the installer.
This is what makes "everything is swappable" real rather than aspirational.
The power to choose anything comes from the fact that nothing is prebuilt —
you fetch exactly the parts you picked.
> "You give up the convenience of a prebuilt system so the system you get is
> exactly the one you designed. Speed-to-install is traded for
> fit-to-request. If you want fast and prebaked, a binary distro is right
> there. If you want your machine, this is the one."
## Stability: guaranteed on what's offered, never enforced on you
Keru's promise is that **the system won't break** — but honestly scoped: it
won't break **on the combinations it offers you**. That is what the installer
means by offering a choice: each option in `install.sh` is one Keru has proven
builds and boots. The offered set is curated *so that* it doesn't break.
Choice multiplies the test surface — six inits, four libcs, seven filesystems,
five kernels, and so on produce over a thousand possible systems. Guaranteeing
every one of them is only honest if it's *enforced by curation*: Keru offers
what works.
But the user is never locked out of going further. If you pick something that
isn't yet proven — a libc and init never tested together, an unmaintained
filesystem, an exotic kernel pair — Keru does **not** stop you. It **warns
you** the combination is unstable and lets you proceed.
> "Stability is a guarantee about what we offer, not a jail around the edge of
> it. If you want to push into the unproven, we tell you the truth and get out
> of your way."
So the full definition, in one line:
> **The system won't break for any choice Keru offers you; for anything beyond
> that, Keru warns and steps aside — you stay in control, never blocked.**
## Agreement on choice, not agreement on opinion
The through-line across Keru's lineage is clear: TOML packages, then a
50-line build DSL, then plain shell. And from *opinionated dogma* — "you get
s6 and XFS whether you like it or not" — to *anti-opinionated anything-goes*.
Keru keeps the from-scratch purity while rejecting the fixed dogmas outright.
> "We don't tell you which init to worship or which filesystem to trust. We
> tell you that you have to choose — and then we build exactly that."
The philosophy in one line:
> **A system should be exactly what you chose it to be — selected at install,
> built from source, nothing forced and nothing you didn't ask for.**
And in two words: **anti-opinionated by design.**
+99 -42
View File
@@ -1,70 +1,126 @@
#!/usr/bin/env sh #!/usr/bin/env sh
# keru-install — the Keru OS TUI installer # keru-install — Keru OS installer. Runs from the live ISO, walks you
# # through your choices, writes make.conf, then builds your system.
# Walks you through crafting your exact system, then writes make.conf and
# kicks off the build. Everything is swappable here, at install time, and
# locked in when you boot.
#
# Designed to run from the Keru live ISO. Backed by dialog/whiptail if
# present; falls back to plain prompted input. All shell, no magic.
set -eu set -eu
. "$(dirname "$0")/../scripts/common.sh" . "$(dirname "$0")/../scripts/common.sh"
# ---- defaults (mirror profile/make.conf) --------------------------------
OUT="${MAKE_CONF_OUT:-/tmp/keru/make.conf}" OUT="${MAKE_CONF_OUT:-/tmp/keru/make.conf}"
DROP="/tmp/keru" mkdir -p /tmp/keru
mkdir -p "$DROP"
# ---- menu helpers ------------------------------------------------------- # show a menu of options, remember the pick in $CHOICE
pick() { # prompt, array-of-labels, defaults -> writes choice to $CHOICE pick() {
local prompt="$1"; shift prompt="$1"; shift
local default="$1"; shift default="$1"; shift
CHOICE="$default" CHOICE="$default"
if command -v dialog >/dev/null 2>&1; then printf '%s\n' "== $prompt =="
local args=() n=0
local i=0 for opt in "$@"; do
for opt in "$@"; do n=$((n+1))
args+=("$i" "$opt") printf ' %s) %s\n' "$n" "$opt"
i=$((i+1)) done
done printf 'Select [%s]: ' "$default"
local sel read -r sel
sel=$(dialog --stdout --no-cancel --menu "$prompt" 15 60 8 \ case "$sel" in
--default-item "$default" "${args[@]}") || true ''|*[!0-9]*) CHOICE="$default" ;;
CHOICE=$(eval "printf '%s' \"\${$((sel+1)):-\$default}\"" 2>/dev/null || printf '%s' "$default") *)
if [ "$sel" -ge 1 ] && [ "$sel" -le "$n" ]; then
i=0
for opt in "$@"; do
i=$((i+1))
[ "$i" -eq "$sel" ] && { CHOICE="$opt"; break; }
done
else
CHOICE="$default"
fi
;;
esac
}
require_network() {
ok=0
for host in 1.1.1.1 github.com; do
if command -v ping >/dev/null 2>&1 && ping -c1 -W2 "$host" >/dev/null 2>&1; then
ok=1; break
fi
done
if [ "$ok" = "0" ]; then
if command -v nc >/dev/null 2>&1 && nc -z -w5 github.com 443 >/dev/null 2>&1; then
ok=1
elif [ -e /dev/tcp ] && (exec 3<>/dev/tcp/github.com/443) >/dev/null 2>&1; then
ok=1
fi
fi
[ "$ok" = "1" ]
}
configure_network() {
if command -v nmtui >/dev/null 2>&1; then
nmtui >/dev/null 2>&1
else else
printf '%s\n' "== $prompt ==" warn "nmtui not available — bring up the network yourself, then continue"
local n=1
for opt in "$@"; do
printf ' %s) %s\n' "$n" "$opt"
n=$((n+1))
done
printf 'Select [%s]: ' "$default"
read -r sel
[ -n "$sel" ] && CHOICE=$(eval "printf '%s' \"\${$sel}\"") || CHOICE="$default"
fi fi
} }
# ---- swappable selections ------------------------------------------------ banner "Keru OS — network required"
info "the ISO only carries the installer."
info "the system you choose (init, libc, fs, kernel, tools) is fetched and"
info "built from the network during installation. a connection is required."
while ! require_network; do
warn "network: not connected"
read -r -p "Connect to the network now (runs nmtui)? [Y/n] " cfg
case "$cfg" in
n|N|no) die "a network connection is required to install Keru" ;;
*) configure_network ;;
esac
done
msg "network: connected"
banner "Keru OS — craft your system" banner "Keru OS — craft your system"
pick "Init system" runit runit s6 openrc systemd pick "Init system" runit runit s6 openrc systemd busybox-init sysvinit dinit shepherd
INIT="$CHOICE" INIT="$CHOICE"
pick "C library" glibc glibc musl pick "C library" glibc glibc musl uclibc-ng
LIBC="$CHOICE" LIBC="$CHOICE"
pick "Filesystem" ext4 ext4 btrfs xfs zfs f2fs pick "Filesystem" ext4 ext4 ext2 ext3 btrfs xfs zfs f2fs jfs reiserfs
TARGET_FS="$CHOICE" TARGET_FS="$CHOICE"
pick "Kernel" linux linux linux-lts linux-hardened pick "Kernel" linux linux linux-lts linux-hardened linux-cachyos linux-zen
KERNEL="$CHOICE" KERNEL="$CHOICE"
pick "Network tools" nmtui networkmanager nmtui connman pick "Privilege elevation (sudo alternative)" doas doas sudo opendoas su
SUDO="$CHOICE"
pick "Network tools" nmtui nmtui networkmanager connman systemd-networkd
NET="$CHOICE" NET="$CHOICE"
# ---- assemble make.conf ------------------------------------------------ warn_unstable() {
unstable=0
case "$LIBC:$INIT" in
uclibc-ng:*|musl:systemd)
warn "$LIBC + $INIT: not yet proven to build and boot together"
unstable=1 ;;
esac
case "$LIBC:$KERNEL" in
musl:linux-zen|uclibc-ng:*)
warn "$LIBC + $KERNEL: not yet proven to build and boot together"
unstable=1 ;;
esac
case "$TARGET_FS" in
zfs) warn "zfs + $LIBC: needs kernel module + ZFS userspace, not yet proven"
unstable=1 ;;
reiserfs) warn "reiserfs is unmaintained and has no stable future"
unstable=1 ;;
esac
[ "$unstable" = "1" ] && warn "this combination is unstable. Keru won't stop you — build at your own risk."
}
warn_unstable
msg "writing $OUT" msg "writing $OUT"
cat > "$OUT" <<EOF cat > "$OUT" <<EOF
# Generated by keru-install — hand-tune then rebuild if you like. # Generated by keru-install — hand-tune then rebuild if you like.
@@ -72,6 +128,7 @@ INIT=$INIT
LIBC=$LIBC LIBC=$LIBC
TARGET_FS=$TARGET_FS TARGET_FS=$TARGET_FS
KERNEL=$KERNEL KERNEL=$KERNEL
SUDO=$SUDO
NET=$NET NET=$NET
LICENSE_ACCEPT=(*) LICENSE_ACCEPT=(*)
EOF EOF
-51
View File
@@ -1,51 +0,0 @@
#!/usr/bin/env sh
# build-iso.sh — assemble a Keru OS ISO from the built rootfs and kernel
#
# From-scratch approach (no archiso): we lay out the classic isohybrid
# structure manually, squash the rootfs, and generate the ISO with xorriso +
# isolinux/syslinux (or syslinux's isohybrid). This is the LFS/Debian-live
# style path.
#
# Requires on the build host: xorriso, squashfs-tools, syslinux/isolinux.
set -eu
. "$(dirname "$0")/common.sh"
ROOT="${ROOT:-/tmp/keru/root}" # target rootfs (from make.conf)
ISO_OUT="${ISO_OUT:-$KERU_ROOT/iso/keru-$(date +%Y%m%d).iso}"
WORK="$KERU_ROOT/iso/work"
ISOIMG="$WORK/isolinux"
info "building Keru ISO -> $ISO_OUT"
[ -d "$ROOT" ] || die "rootfs not found at $ROOT (run build-root.sh first)"
have xorriso || die "xorriso not installed"
have mksquashfs || die "squashfs-tools not installed"
rm -rf "$WORK"; mkdir -p "$ISOIMG"
info "generating isolinux config"
cp /usr/lib/syslinux/bios/isolinux.bin "$ISOIMG/" || true
cp /usr/lib/syslinux/bios/ldlinux.c32 "$ISOIMG/" || true
cat > "$ISOIMG/isolinux.cfg" <<'EOF'
UI vesamenu.c32
DEFAULT keru
LABEL keru
LINUX /boot/vmlinuz-keru
INITRD /boot/initramfs-keru.img
APPEND root=live:LABEL=KERU_LIVE toram quiet
EOF
info "packing rootfs into squashfs"
mksquashfs "$ROOT" "$WORK/keru.sfs" -noappend -comp xz
info "writing ISO (isohybrid)"
xorriso -as mkisofs \
-o "$ISO_OUT" \
-V KERU_LIVE \
-b isolinux/isolinux.bin \
-c isolinux/boot.cat \
-no-emul-boot -boot-load-size 4 -boot-info-table \
-isohybrid-mbr /usr/lib/syslinux/bios/isohdpfx.bin \
"$WORK"
info "done: $ISO_OUT"
+61
View File
@@ -0,0 +1,61 @@
#!/bin/sh
# Keru live ISO init — jumps straight into the installer.
#
# The live ISO carries only the installer. On boot this script:
# 1. mounts the virtual filesystems
# 2. attaches the read-only installer root (squashfs, plain initramfs, or
# an unattached block device)
# 3. execs installer/install.sh on the console — so you boot, choose, and it
# crafts and installs the system. No shell prompt in the way.
# 4. if the installer exits (e.g. you declined to build), drops to an
# emergency shell instead of leaving you stranded.
#
# Ultra-minimal by design: /bin/sh is busybox. No init system in the live env.
# ---- console -----------------------------------------------------------
# Redirect the console early so messages land where you can see them.
CONSOLE="${console:-/dev/tty1}"
exec <"$CONSOLE" >"$CONSOLE" 2>"$CONSOLE"
# ---- virtual filesystems ----------------------------------------------
mount -t proc proc /proc 2>/dev/null
mount -t sysfs sys /sys 2>/dev/null
mount -t devtmpfs dev /dev 2>/dev/null || (mkdir -p /dev && mount -t tmpfs dev /dev 2>/dev/null)
mkdir -p /dev/pts /dev/shm
mount -t devpts devpts /dev/pts 2>/dev/null
mount -t tmpfs tmpfs /dev/shm 2>/dev/null
# ---- locate the installer root ----------------------------------------
# Where the installer payload lives. Tried in order:
# 1. $root — whatever the kernel booted (a squashfs / overlay already handled
# by an initramfs that then hands off here).
# 2. a squashfs node named *.sfs on a known device (label=KERU).
# 3. nothing — the installer is already on the root we're running from.
case "${root:-}" in
/dev/*)
# re-mount as the boot-time root: cannot pivot here, so use it directly
/bin/busybox mount -o move / "$root" 2>/dev/null || true
;;
'')
for _dev in /dev/disk/by-label/KERU*; do
[ -e "$_dev" ] || continue
_node="$(readlink -f "$_dev")"
mount "$_node" /squash 2>/dev/null || continue
INSTALLER=/squash
break
done
;;
esac
INSTALLER="${INSTALLER:-/}"
# ---- launch the installer ---------------------------------------------
if [ -e "$INSTALLER/installer/install.sh" ]; then
printf '\n[ keru ] booting installer...\n'
cd "$INSTALLER" && exec /bin/sh "$INSTALLER/installer/install.sh"
fi
# If we land here the installer is missing or returned. Never strand someone:
# fall back to an interactive rescue shell.
printf '\n[ keru ] installer not found or exited.\n'
printf '[ keru ] dropping to an emergency shell. (installer path: %s)\n' "$INSTALLER"
exec /bin/sh
+12 -7
View File
@@ -9,23 +9,28 @@
## --------------------------------------------------------------------------- ## ---------------------------------------------------------------------------
# Which init system gets installed # Which init system gets installed
# runit (default) | s6 | openrc | systemd # runit (default) | s6 | openrc | systemd | busybox-init | sysvinit | dinit | shepherd
INIT=runit INIT=runit
# Which libc the toolchain and packages build against # Which libc the toolchain and packages build against
# glibc (default) | musl # glibc (default) | musl | uclibc-ng
LIBC=glibc LIBC=glibc
# Which filesystem the target root is formatted as # Which filesystem the target root is formatted as
# ext4 (default) | btrfs | xfs | zfs | f2fs # ext4 (default) | ext2 | ext3 | btrfs | xfs | zfs | f2fs | jfs | reiserfs | swap
TARGET_FS=ext4 TARGET_FS=ext4
# Which kernel you want built # Which kernel you want built
# linux (sane default) | linux-lts | linux-hardened # linux (default) | linux-lts | linux-hardened | linux-cachyos | linux-zen
KERNEL=linux KERNEL=linux
# Which privilege-elevation tool gets installed
# doas (default) | sudo | opendoas | su
SUDO=doas
# Base package set pulled into every install # Base package set pulled into every install
BASE_PACKAGES=(base toolchain kernel runit nmtui openssh) # (kernel, init, sudo, and net are selected separately below)
BASE_PACKAGES=(base toolchain openssh)
# Locale / clock / keymap applied to the target # Locale / clock / keymap applied to the target
LOCALE=en_US.UTF-8 LOCALE=en_US.UTF-8
@@ -46,8 +51,8 @@ LDFLAGS="-s"
JOBS=$(nproc) JOBS=$(nproc)
MAKEFLAGS="-j$JOBS" MAKEFLAGS="-j$JOBS"
# Mirrors for source tarballs # Mirror for source tarballs (unset: fetch straight from upstream)
SOURCE_MIRROR="https://mirror.keru.org/sources" # SOURCE_MIRROR="https://mirror.example.org/sources"
# Where the new target root lives on the build host # Where the new target root lives on the build host
ROOT=/tmp/keru/root ROOT=/tmp/keru/root
+4 -2
View File
@@ -23,7 +23,7 @@ KAMA="$KAMA_DIR/kama"
[ -d "$PKGS_DIR" ] || die "kama-packages repo not found at $PKGS_DIR (set PKGS_DIR)" [ -d "$PKGS_DIR" ] || die "kama-packages repo not found at $PKGS_DIR (set PKGS_DIR)"
info "building Keru rootfs into $ROOT" info "building Keru rootfs into $ROOT"
info "profile: init=$INIT libc=$LIBC fs=$TARGET_FS kernel=$KERNEL" info "profile: init=$INIT libc=$LIBC fs=$TARGET_FS kernel=$KERNEL sudo=$SUDO"
# stage 0 — bootstrap toolchain # stage 0 — bootstrap toolchain
info "stage 0: bootstrap toolchain (gcc binutils glibc/musl)" info "stage 0: bootstrap toolchain (gcc binutils glibc/musl)"
@@ -38,9 +38,11 @@ for p in "${BASE_PACKAGES[@]}"; do
done done
# stage 2 — kernel + init + swappables # stage 2 — kernel + init + swappables
info "stage 2: kernel + init" info "stage 2: kernel + init + sudo + net"
PKGDIR="$PKGS_DIR" "$KAMA" make "$KERNEL" || die "kernel build failed" PKGDIR="$PKGS_DIR" "$KAMA" make "$KERNEL" || die "kernel build failed"
PKGDIR="$PKGS_DIR" "$KAMA" make "$INIT" || die "init build failed ($INIT)" PKGDIR="$PKGS_DIR" "$KAMA" make "$INIT" || die "init build failed ($INIT)"
PKGDIR="$PKGS_DIR" "$KAMA" make "$SUDO" || die "sudo tool build failed ($SUDO)"
PKGDIR="$PKGS_DIR" "$KAMA" make "$NET" || die "net tool build failed ($NET)"
# stage 3 — fstab/mkinitramfs for the chosen FS # stage 3 — fstab/mkinitramfs for the chosen FS
info "stage 3: finalize $TARGET_FS root" info "stage 3: finalize $TARGET_FS root"
+1 -1
View File
@@ -1,4 +1,4 @@
# common.sh — shared helpers for Keru scripts (installer, iso, kama) # common.sh — shared helpers for Keru scripts (installer, build pipeline)
PREFIX="\033[1;35m[ keru ]\033[0m" PREFIX="\033[1;35m[ keru ]\033[0m"
msg() { printf '%b %s\n' "$PREFIX" "$*"; } msg() { printf '%b %s\n' "$PREFIX" "$*"; }
info() { printf '%b \033[1;34m==>\033[0m %s\n' "$PREFIX" "$*"; } info() { printf '%b \033[1;34m==>\033[0m %s\n' "$PREFIX" "$*"; }
View File
+82
View File
@@ -0,0 +1,82 @@
<div class="wrap">
<div>
<h4>Keru OS</h4>
<ul>
<li><a href="./index.html">Home</a></li>
<li><a href="./about.html">About</a></li>
<li><a href="./philosophy.html">Philosophy</a></li>
<li><a href="./ethos.html">Ethos</a></li>
<li><a href="./stability.html">Stability</a></li>
</ul>
</div>
<div>
<h4>Install</h4>
<ul>
<li><a href="./install.html">Install Keru</a></li>
<li><a href="./getting-started.html">Getting started</a></li>
<li><a href="./installer-walkthrough.html">Installer walkthrough</a></li>
<li><a href="./installation-requirements.html">Requirements</a></li>
<li><a href="./network-setup.html">Network setup</a></li>
</ul>
</div>
<div>
<h4>Swappables</h4>
<ul>
<li><a href="./swappables.html">All choices</a></li>
<li><a href="./inits.html">Init systems</a></li>
<li><a href="./libcs.html">C libraries</a></li>
<li><a href="./filesystems.html">Filesystems</a></li>
<li><a href="./kernels.html">Kernels</a></li>
<li><a href="./privilege-elevation.html">Privilege elevation</a></li>
</ul>
</div>
<div>
<h4>Kama</h4>
<ul>
<li><a href="./kama.html">Package manager</a></li>
<li><a href="./kama-usage.html">Usage</a></li>
<li><a href="./kama-recipes.html">Recipes</a></li>
<li><a href="./kama-repos.html">Repos</a></li>
</ul>
</div>
<div>
<h4>Docs</h4>
<ul>
<li><a href="./docs.html">Docs home</a></li>
<li><a href="./make-conf.html">make.conf</a></li>
<li><a href="./recipe-format.html">Recipe format</a></li>
<li><a href="./recipe-authoring.html">Recipe authoring</a></li>
<li><a href="./build-pipeline.html">Build pipeline</a></li>
<li><a href="./toolchain.html">Toolchain bootstrap</a></li>
<li><a href="./kama-config.html">Kama config</a></li>
<li><a href="./mirror-cache.html">Mirrors &amp; cache</a></li>
<li><a href="./security.html">Security</a></li>
<li><a href="./troubleshooting.html">Troubleshooting</a></li>
<li><a href="./live-init.html">Live init</a></li>
</ul>
</div>
<div>
<h4>Community</h4>
<ul>
<li><a href="./community.html">Community</a></li>
<li><a href="./contribute.html">Contribute</a></li>
<li><a href="./faq.html">FAQ</a></li>
<li><a href="./contact.html">Contact</a></li>
<li><a href="./links.html">Links</a></li>
<li><a href="./news.html">News</a></li>
</ul>
</div>
<div>
<h4>Legal</h4>
<ul>
<li><a href="./license.html">License</a></li>
<li><a href="./privacy.html">Privacy</a></li>
<li><a href="./credits.html">Credits</a></li>
<li><a href="./sitemap.html">Sitemap</a></li>
</ul>
</div>
</div>
<p class="foot">
ける・けいとうてき — craft your system.<br>
Keru OS is licensed under <span class="marks">AGPL-3.0</span>. No opinion, no telemetry, no bloat.
</p>
+10
View File
@@ -0,0 +1,10 @@
<a class="brand" href="./index.html"><span class="kanji">ける</span> Keru OS</a>
<a class="navlink" href="./index.html">Home</a>
<a class="navlink" href="./philosophy.html">Philosophy</a>
<a class="navlink" href="./swappables.html">Swappables</a>
<a class="navlink" href="./kama.html">Kama</a>
<a class="navlink" href="./install.html">Install</a>
<a class="navlink" href="./docs.html">Docs</a>
<a class="navlink" href="./news.html">News</a>
<a class="navlink" href="./community.html">Community</a>
<a class="menu-toggle" href="./sitemap.html">☰</a>
+57
View File
@@ -0,0 +1,57 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>About — Keru OS</title>
<meta name="description" content="Keru OS is an independent, source-only Linux distribution. This repo is the operating system itself — installer, profile system, and build pipeline.">
<link rel="stylesheet" href="assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="index.html">home</a> / about</p>
<h1>About Keru OS</h1>
<p>An independent, source-only Linux distribution built around one idea: you don't install a system, you craft one.</p>
</header>
<section>
<div class="wrap">
<div class="prose">
<h3>What Keru is</h3>
<p>Keru (ける) is a Linux distribution where virtually nothing is decided for you. Every foundational component — init system, C library, filesystem, kernel, privilege-elevation tool, network stack — is a variable you resolve at install time. What lands on your disk is precisely what you chose, compiled from original source.</p>
<p>The name comes from <strong>ける・けいとうてき</strong> (keru keitō-teki), roughly "craft your system." It's the whole point stated as a phrase.</p>
<h3>The three repositories</h3>
<p>Keru is deliberately split into three pieces so each stays small and legible:</p>
<table>
<tr><th>Repo</th><th>What it holds</th></tr>
<tr><td>KeruOS</td><td>This repo — the installer, profile system, build pipeline, and website.</td></tr>
<tr><td>kama</td><td>The package manager. A ~225-line shell script. The "kiln" that fires recipes.</td></tr>
<tr><td>kama-packages</td><td>The recipe repository — plain shell scripts that describe how to build each package.</td></tr>
</table>
<h3>Where it sits</h3>
<p>Keru belongs to the line of source-and-choice distributions that includes Gentoo and Nix. Where Keru differs: it takes the "no opinion" stance further than any of them. Gentoo still picks most of your stack for you; Keru asks you to form the whole opinion up front, then builds exactly that.</p>
<h3>Status</h3>
<p>Keru is in active development. The first installable release, <strong>0.1</strong>, will ship as a bootable ISO. Until then, the repositories document the design, philosophy, and the build pipeline it's all wired through.</p>
<div class="callout">
<strong>Anti-opinionated by design.</strong> Read the full reasoning in the <a href="philosophy.html">philosophy</a>.
</div>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">See the <a href="sitemap.html">sitemap</a> for all pages.</div></noscript>
<script src="assets/js/include.js" data-base="."></script>
</body>
</html>
+66
View File
@@ -0,0 +1,66 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Anti-opinionated — Keru OS</title>
<meta name="description" content="What it really means for a distribution to be anti-opinionated, what it costs, and what it grants.">
<link rel="stylesheet" href="assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="index.html">home</a> / <a href="philosophy.html">philosophy</a> / anti-opinionated</p>
<h1>Anti-opinionated</h1>
<p>The core stance, and what it actually grants and costs you.</p>
</header>
<section>
<div class="wrap">
<div class="prose">
<h3>Reading the room</h3>
<p>Every Linux distribution is an answer to the same question: <em>who decides what your system is?</em> Most answers reduce to "the maintainers, wisely." Your distro picks systemd or OpenRC, glibc or musl, ext4 or btrfs, and you inherit that stack as the price of using it.</p>
<p>That's genuinely fine for a lot of people. It's how you get a system that mostly works with default effort. But it means the shape of your machine is decided by someone else's tastes, release cadence, and risk appetite.</p>
<h3>The anti-opinionated answer</h3>
<p>Keru answers differently: <strong>the distribution holds no position.</strong> Not a middle position — <em>no</em> position. It doesn't ship a "best" init or a "recommended" filesystem, because that recommendation is the very thing Keru exists to remove.</p>
<p>Every foundational component is presented as a flat, open choice in the installer. Runit or systemd? They're options, side by side, weightless. glibc or musl? Your call. btrfs or reiserfs or swap? All offered. Keru doesn't rank them, because ranking is an opinion, and opinions are exactly what it delegates to you.</p>
<h3>What it grants</h3>
<ul class="features">
<li><strong>No inherited stack.</strong> You never fight a default you never agreed to. What's on the disk is what you chose, full stop.</li>
<li><strong>Every system is the same system.</strong> "Your" configuration isn't a deviation from Keru's ideal — it <em>is</em> Keru. There's no blessed path and no lesser path.</li>
<li><strong>The distro never defends a mistake.</strong> An opinionated distro inherits the burden of defending its picks forever. Keru inherits nothing to defend.</li>
<li><strong>Legibility.</strong> Because there's no position to paper over, every choice is visible in <code>make.conf</code> — readable, editable, rebuildable.</li>
</ul>
<h3>What it costs</h3>
<ul class="features">
<li><strong>No hand-holding.</strong> There's no "the way you install Keru is the way you install Keru" comfort. You carry the decisions.</li>
<li><strong>You must form an opinion.</strong> The installer's only requirement is that you have one. For people who specifically want that, it's freedom; it's not for everyone.</li>
<li><strong>More surface to keep stable.</strong> Supporting many inits, libcs, and filesystems means more combinations to honor — which is why the <a href="stability.html">stability promise is scoped honestly</a>.</li>
</ul>
<h3>Not GNU/Hurd, not a meta-OS</h3>
<p>To head off a common reading: anti-opinionated doesn't mean Keru is a "meta operating system" that runs arbitrary kernels. Keru is a Linux distribution. Its freedom lives in <em>userspace and configuration</em> — init, libc, filesystem, kernel (within Linux), tooling. It's the meta-distribution stance: choice and composition over a fixed opinionated stack.</p>
<h3>In one line</h3>
<blockquote>An opinionated distro tells you what to use. Keru tells you that you have to choose — and then builds exactly what you pick.</blockquote>
<p><a href="philosophy.html">← Back to the philosophy</a></p>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">See the <a href="sitemap.html">sitemap</a> for all pages.</div></noscript>
<script src="assets/js/include.js" data-base="."></script>
</body>
</html>
+511
View File
@@ -0,0 +1,511 @@
/* Keru OS website — Ryoku-style.
Pure-black paper, warm bone ink, one vermillion accent.
Radius 0. No shadow. Flat hairline surfaces. Monospace tech labels.
Animations are loud enough to feel alive, flat enough to stay cool. */
@import url('https://fonts.googleapis.com/css2?family=Inter:wght@400;500;600;700;800&family=JetBrains+Mono:wght@400;500;700&display=swap');
:root {
--paper: #000000; /* pure black paper */
--paper-2: #0d0d0d; /* raised surface */
--paper-3: #131313; /* cards */
--hair: #262626; /* hairline borders */
--ink: #cdc4ba; /* warm bone ink — body */
--ink-dim: #8b8275; /* subdued ink */
--ink-faint: #5b5348; /* farthest faded */
--bone: #f2ede4; /* bright ink, emphasis */
--accent: #ff3b1f; /* vermillion — the single accent */
--ok: #58e1c2;
--warn: #f0a35e;
--danger: #ff3b1f;
--mono: 'JetBrains Mono', ui-monospace, monospace;
--sans: 'Inter', system-ui, -apple-system, sans-serif;
--radius: 0; /* sharp. always. */
--nav-h: 60px;
}
* { margin: 0; padding: 0; box-sizing: border-box; }
::selection { background: var(--accent); color: #000; }
html { scroll-behavior: smooth; }
body {
background: var(--paper);
color: var(--ink);
font-family: var(--sans);
line-height: 1.65;
-webkit-font-smoothing: antialiased;
overflow-x: hidden;
}
/* faint scanline texture — a taste of grain, no image */
body::before {
content: "";
position: fixed;
inset: 0;
z-index: -1;
background:
repeating-linear-gradient(180deg, transparent 0 3px, rgba(255,255,255,.008) 3px 4px);
pointer-events: none;
}
a { color: var(--ink); text-decoration: none; }
a:hover { color: var(--bone); }
/* ---------- top nav ---------- */
nav.top {
position: sticky;
top: 0;
z-index: 100;
height: var(--nav-h);
background: rgba(0,0,0,.9);
backdrop-filter: blur(8px);
border-bottom: 1px solid var(--hair);
display: flex;
align-items: center;
padding: 0 26px;
gap: 4px;
}
.brand {
font-family: var(--mono);
font-weight: 700;
color: var(--bone);
font-size: 1rem;
letter-spacing: .02em;
margin-right: auto;
display: flex;
align-items: center;
gap: 9px;
}
.brand .kanji {
color: var(--accent);
font-size: 1.15rem;
text-shadow: 0 0 14px rgba(255,59,31,.55);
}
.brand:hover { text-decoration: none; }
nav.top a.navlink {
color: var(--ink-dim);
font-family: var(--mono);
text-transform: uppercase;
font-size: .72rem;
letter-spacing: .12em;
padding: 6px 10px;
border: 1px solid transparent;
transition: color .15s, border-color .15s, background .15s;
}
nav.top a.navlink:hover {
color: var(--bone);
border-color: var(--hair);
background: var(--paper-2);
text-decoration: none;
}
.menu-toggle { display: none; }
/* ---------- hero ---------- */
.hero { padding: 84px 26px 54px; text-align: center; }
.kicker {
display: inline-flex;
align-items: center;
gap: 10px;
font-family: var(--mono);
color: var(--ink-dim);
text-transform: uppercase;
font-size: .72rem;
letter-spacing: .22em;
border: 1px solid var(--hair);
background: var(--paper-2);
padding: 5px 14px;
}
.kicker .dot {
width: 7px; height: 7px; background: var(--accent);
animation: pulse 1.6s infinite;
}
.kicker .dot.dim { background: var(--ink-faint); }
.hero .seal {
font-size: 5rem;
line-height: 1;
color: var(--bone);
user-select: none;
display: block;
margin: 18px auto 6px;
animation: fadeUp .7s ease both;
}
.hero h1 {
font-family: var(--mono);
font-size: clamp(1.6rem, 4vw, 2.6rem);
font-weight: 700;
line-height: 1.1;
color: var(--bone);
letter-spacing: .02em;
margin: 14px auto 16px;
text-transform: uppercase;
}
.hero h1 .grad { color: var(--accent); }
.hero p.sub { color: var(--ink-dim); max-width: 620px; margin: 0 auto 30px; font-size: 1rem; }
.cta-row { display: flex; gap: 12px; justify-content: center; flex-wrap: wrap; }
.btn {
display: inline-flex;
align-items: center;
gap: 10px;
font-family: var(--mono);
text-transform: uppercase;
letter-spacing: .1em;
font-size: .78rem;
font-weight: 700;
padding: 12px 22px;
border: 1px solid var(--ink-dim);
color: var(--bone);
transition: color .15s, background .15s, border-color .15s, transform .1s;
}
.btn:hover { text-decoration: none; }
.btn-primary { background: var(--accent); border-color: var(--accent); color: #000; }
.btn-primary:hover { background: #000; color: var(--accent); }
.btn-ghost { background: transparent; color: var(--ink-dim); }
.btn-ghost:hover { background: var(--paper-2); color: var(--bone); border-color: var(--accent); }
/* ---------- marquee ticker ---------- */
.ticker {
overflow: hidden;
border-top: 1px solid var(--hair);
border-bottom: 1px solid var(--hair);
padding: 13px 0;
background: var(--paper-2);
white-space: nowrap;
}
.ticker-inner {
display: inline-block;
animation: ticker 32s linear infinite;
font-family: var(--mono);
font-size: .8rem;
text-transform: uppercase;
letter-spacing: .1em;
color: var(--ink-faint);
}
.ticker-inner span { margin: 0 26px; }
.ticker-inner b { color: var(--bone); font-weight: 500; }
.ticker-inner .a { color: var(--accent); }
/* ---------- sections ---------- */
section { padding: 54px 26px; }
.wrap { max-width: 1080px; margin: 0 auto; }
.section-title {
font-family: var(--mono);
text-transform: uppercase;
letter-spacing: .2em;
font-size: .7rem;
color: var(--accent);
margin-bottom: 10px;
}
.section-title::before { content: "// "; opacity: .6; }
h2.head {
font-family: var(--mono);
font-size: clamp(1.25rem, 3vw, 1.9rem);
color: var(--bone);
font-weight: 700;
margin-bottom: 12px;
text-transform: uppercase;
letter-spacing: .02em;
}
.lead { color: var(--ink-dim); font-size: 1rem; max-width: 720px; margin-bottom: 28px; }
.grid { display: grid; gap: 18px; }
.grid-2 { grid-template-columns: repeat(auto-fit, minmax(280px, 1fr)); }
.grid-3 { grid-template-columns: repeat(auto-fit, minmax(240px, 1fr)); }
.grid-4 { grid-template-columns: repeat(auto-fit, minmax(200px, 1fr)); }
.card {
background: var(--paper-2);
border: 1px solid var(--hair);
padding: 20px;
position: relative;
transition: border-color .15s, transform .1s, background .15s;
}
.card::before {
content: "";
position: absolute;
left: 0; top: 0; bottom: 0;
width: 2px;
background: var(--accent);
transform: scaleY(0);
transform-origin: top;
transition: transform .25s cubic-bezier(.2,.8,.2,1);
}
.card:hover { border-color: var(--accent); background: var(--paper-3); transform: translateY(-2px); }
.card:hover::before { transform: scaleY(1); }
.card.h {
font-family: var(--mono);
font-size: 1rem;
text-transform: uppercase;
letter-spacing: .06em;
color: var(--bone);
margin-bottom: 8px;
}
.card p { color: var(--ink-dim); font-size: .92rem; }
.card .num {
font-family: var(--mono);
font-size: .68rem;
letter-spacing: .14em;
text-transform: uppercase;
color: var(--accent);
border: 1px solid var(--hair);
padding: 2px 8px;
display: inline-block;
margin-bottom: 10px;
}
a.card { color: inherit; }
a.card:hover { text-decoration: none; }
/* ---------- terminal / code ---------- */
.terminal {
background: #050505;
border: 1px solid var(--hair);
overflow: hidden;
text-align: left;
margin: 0 auto;
max-width: 660px;
}
.terminal .tbar {
background: var(--paper-2);
padding: 9px 12px;
display: flex;
gap: 6px;
align-items: center;
border-bottom: 1px solid var(--hair);
}
.terminal .tbar span.dot { width: 9px; height: 9px; display: inline-block; }
.terminal .tbar .r { background: var(--danger); }
.terminal .tbar .y { background: var(--warn); }
.terminal .tbar .g { background: var(--ok); }
.terminal .tbar .t {
margin-left: 10px;
font-family: var(--mono);
font-size: .72rem;
color: var(--ink-faint);
text-transform: uppercase;
letter-spacing: .1em;
}
.terminal pre { padding: 18px; overflow-x: auto; font-family: var(--mono); font-size: .84rem; line-height: 1.75; color: var(--ink); }
.terminal .c { color: var(--accent); }
.terminal .k { color: var(--bone); }
.terminal .p { color: var(--ink-faint); }
pre, code, kbd { font-family: var(--mono); }
.code-block {
background: #050505;
border: 1px solid var(--hair);
border-left: 3px solid var(--accent);
padding: 18px;
overflow-x: auto;
margin: 18px 0;
font-size: .84rem;
line-height: 1.7;
color: var(--ink);
}
code:not(.code-block) {
background: var(--paper-2);
border: 1px solid var(--hair);
padding: 2px 6px;
font-size: .85em;
color: var(--accent);
}
kbd {
background: var(--paper-2);
border: 1px solid var(--hair);
border-bottom-width: 2px;
padding: 1px 6px;
font-size: .8em;
}
/* ---------- prose ---------- */
.prose { max-width: 760px; margin: 0 auto; }
.prose h3 {
font-family: var(--mono);
text-transform: uppercase;
letter-spacing: .04em;
color: var(--bone);
font-size: 1.1rem;
margin: 32px 0 10px;
font-weight: 700;
}
.prose h3::before { content: "# "; color: var(--accent); }
.prose h4 { color: var(--accent); margin: 22px 0 8px; font-size: .95rem; font-family: var(--mono); }
.prose p { margin: 12px 0; color: var(--ink); }
.prose ul, .prose ol { margin: 12px 0 12px 22px; }
.prose li { margin: 6px 0; color: var(--ink); }
.prose li::marker { color: var(--accent); }
.prose blockquote {
border-left: 3px solid var(--accent);
background: var(--paper-2);
padding: 14px 18px;
margin: 18px 0;
color: var(--ink-dim);
}
.prose blockquote strong { color: var(--bone); }
.prose hr { border: none; border-top: 1px solid var(--hair); margin: 30px 0; }
table { border-collapse: collapse; width: 100%; margin: 18px 0; font-size: .92rem; }
th, td { border: 1px solid var(--hair); padding: 9px 12px; text-align: left; }
th { background: var(--paper-2); color: var(--bone); font-family: var(--mono); font-size: .78rem; text-transform: uppercase; letter-spacing: .05em; }
tr:nth-child(even) td { background: rgba(255,255,255,.02); }
/* tags / callouts */
.tag {
display: inline-block;
font-family: var(--mono);
font-size: .66rem;
letter-spacing: .12em;
text-transform: uppercase;
padding: 2px 9px;
border: 1px solid var(--hair);
color: var(--ink-dim);
margin: 2px 4px 2px 0;
}
.tag.warn { color: var(--warn); border-color: var(--warn); }
.tag.danger { color: var(--danger); border-color: var(--danger); }
.tag.ok { color: var(--ok); border-color: var(--ok); }
.tag.accent { color: var(--accent); border-color: var(--accent); }
.callout {
border: 1px solid var(--hair);
border-left: 3px solid var(--accent);
background: var(--paper-2);
padding: 14px 18px;
margin: 18px 0;
}
.callout.warn { border-left-color: var(--warn); }
.callout.danger { border-left-color: var(--danger); }
.callout.ok { border-left-color: var(--ok); }
.features { list-style: none; margin: 0; }
.features li { padding: 9px 0; border-bottom: 1px solid var(--hair); display: flex; gap: 12px; color: var(--ink); }
.features li::before { content: "▸"; color: var(--accent); }
/* ---------- news ---------- */
.post-list { max-width: 820px; margin: 0 auto; }
.post-item {
display: block;
background: var(--paper-2);
border: 1px solid var(--hair);
padding: 20px 22px;
margin-bottom: 14px;
transition: border-color .15s, transform .1s;
}
.post-item:hover { transform: translateX(4px); border-color: var(--accent); text-decoration: none; }
.post-item h3 { color: var(--bone); font-family: var(--mono); font-size: 1.05rem; text-transform: uppercase; letter-spacing: .03em; margin-bottom: 6px; }
.post-item .meta { font-family: var(--mono); font-size: .72rem; color: var(--ink-faint); text-transform: uppercase; letter-spacing: .1em; margin-bottom: 6px; }
.post-item p { color: var(--ink-dim); font-size: .92rem; }
/* ---------- footer ---------- */
footer { border-top: 1px solid var(--hair); background: var(--paper-2); padding: 38px 26px 30px; margin-top: 40px; }
footer .wrap { display: flex; gap: 34px; flex-wrap: wrap; justify-content: space-between; }
footer h4 { color: var(--bone); font-family: var(--mono); font-size: .72rem; text-transform: uppercase; letter-spacing: .16em; margin-bottom: 12px; }
footer h4::before { content: "// "; color: var(--accent); }
footer ul { list-style: none; }
footer li { margin: 6px 0; }
footer a { color: var(--ink-dim); }
footer a:hover { color: var(--bone); text-decoration: none; }
footer .foot {
margin-top: 28px;
padding-top: 18px;
border-top: 1px solid var(--hair);
font-family: var(--mono);
font-size: .72rem;
color: var(--ink-faint);
text-align: center;
text-transform: uppercase;
letter-spacing: .12em;
}
footer .marks { color: var(--accent); }
/* ---------- stats ---------- */
.stats { display: flex; gap: 30px; flex-wrap: wrap; justify-content: center; margin: 22px 0; }
.stat { text-align: center; border: 1px solid var(--hair); padding: 18px 26px; background: var(--paper-2); min-width: 150px; }
.stat .big { font-family: var(--mono); font-size: 2.2rem; font-weight: 700; color: var(--bone); }
.stat .lbl { color: var(--ink-faint); font-size: .72rem; text-transform: uppercase; letter-spacing: .12em; font-family: var(--mono); }
/* dossier block (Ryoku-style system sheet) */
.dossier {
display: grid;
grid-template-columns: 1fr 1fr;
gap: 1px;
background: var(--hair);
border: 1px solid var(--hair);
margin: 26px auto;
max-width: 680px;
text-align: left;
}
.dossier .row {
background: var(--paper-2);
padding: 12px 18px;
font-family: var(--mono);
font-size: .78rem;
display: flex;
justify-content: space-between;
gap: 16px;
}
.dossier .row .lbl { color: var(--ink-faint); text-transform: uppercase; letter-spacing: .1em; }
.dossier .row .val { color: var(--bone); text-align: right; }
.dossier .row .val.a { color: var(--accent); }
/* ---------- animations ---------- */
@keyframes fadeUp {
from { opacity: 0; transform: translateY(14px); }
to { opacity: 1; transform: translateY(0); }
}
@keyframes fadeLeft {
from { opacity: 0; transform: translateX(-14px); }
to { opacity: 1; transform: translateX(0); }
}
@keyframes pulse { 0%,100% { opacity: 1; } 50% { opacity: .25; } }
@keyframes blink { 0%,49% { opacity: 1; } 50%,100% { opacity: 0; } }
@keyframes ticker { from { transform: translateX(0); } to { transform: translateX(-50%); } }
@keyframes sweep {
0% { background-position: -200% 0; }
100% { background-position: 200% 0; }
}
.reveal { animation: fadeUp .6s ease both; }
.d1 { animation-delay: .08s; }
.d2 { animation-delay: .16s; }
.d3 { animation-delay: .24s; }
.d4 { animation-delay: .32s; }
.d5 { animation-delay: .40s; }
/* blinking caret after brand */
.caret { display: inline-block; width: 8px; height: 1em; background: var(--accent); margin-left: 2px; vertical-align: -0.15em; animation: blink 1.1s infinite; }
/* accent headline underline sweep on hover */
.head { background: linear-gradient(90deg, var(--accent), var(--accent), var(--accent)) no-repeat;
background-size: 0% 2px; background-position: 0 100%; transition: background-size .3s ease; }
.head:hover { background-size: 100% 2px; }
/* text flicker on the kanji seal */
.seal { animation: flicker 4s infinite; }
@keyframes flicker {
0%,100% { opacity: 1; }
92% { opacity: 1; } 93% { opacity: .4; } 94% { opacity: 1; }
}
/* ---------- pagehead ---------- */
.pagehead { padding: 64px 26px 30px; text-align: center; }
.pagehead h1 { font-family: var(--mono); text-transform: uppercase; letter-spacing: .02em; color: var(--bone); font-size: clamp(1.6rem, 4vw, 2.4rem); font-weight: 700; }
.pagehead p { color: var(--ink-dim); max-width: 620px; margin: 12px auto 0; }
.crumbs { font-family: var(--mono); font-size: .72rem; color: var(--ink-faint); text-transform: uppercase; letter-spacing: .12em; max-width: 760px; margin: 18px auto 0; }
.crumbs a { color: var(--ink-dim); }
.crumbs a:hover { color: var(--accent); }
.crumbs span { color: var(--accent); }
/* responsive */
@media (max-width: 720px) {
nav.top { padding: 0 14px; }
nav.top a.navlink { display: none; }
.menu-toggle { display: inline-flex; }
.hero { padding: 56px 18px 34px; }
section { padding: 38px 18px; }
footer .wrap { gap: 20px; }
.dossier { grid-template-columns: 1fr; }
}
+41
View File
@@ -0,0 +1,41 @@
/* Keru website — inject shared nav + footer partials.
Usage:
<nav data-nav></nav>
<footer data-footer></footer>
<script src="assets/js/include.js" data-base="."></script>
data-base is the path prefix from this page to the web root.
All links inside the injected partials are resolved against that base. */
(function () {
var base = '.';
var scripts = document.querySelectorAll('script[src*="include.js"]');
for (var i = 0; i < scripts.length; i++) {
if (scripts[i].dataset.base) base = scripts[i].dataset.base;
}
var nav = document.querySelector('[data-nav]');
var footer = document.querySelector('[data-footer]');
function fill(el, url) {
if (!el) return;
fetch(base + '/' + url)
.then(function (r) { return r.text(); })
.then(function (t) {
// resolve links/asset refs in the partial against base
var div = document.createElement('div');
div.innerHTML = t;
['a', 'link', 'script', 'img'].forEach(function (sel) {
var nodes = div.querySelectorAll(sel + '[href], ' + sel + '[src]');
for (var j = 0; j < nodes.length; j++) {
var n = nodes[j];
var attr = n.hasAttribute('href') ? 'href' : 'src';
var val = n.getAttribute(attr);
if (val && val.indexOf('./') === 0) {
n.setAttribute(attr, base + '/' + val.replace(/^\.\//, ''));
}
}
});
el.innerHTML = div.innerHTML;
})
.catch(function () { /* offline / file:// — nav/footer stay empty */ });
}
fill(nav, '_includes/nav.html');
fill(footer, '_includes/footer.html');
})();
+78
View File
@@ -0,0 +1,78 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Build pipeline — Keru OS</title>
<meta name="description" content="How build-root.sh and mkfs-root.sh turn a make.conf into a bootable rootfs, driven by Kama.">
<link rel="stylesheet" href="assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="index.html">home</a> / <a href="docs.html">docs</a> / build pipeline</p>
<h1>Build pipeline</h1>
<p>From make.conf to a bootable filesystem.</p>
</header>
<section>
<div class="wrap">
<div class="prose">
<p>The build pipeline is the machinery between your profile and a running system. It's intentionally thin — a few shell scripts that orchestrate Kama, not a build system monolith.</p>
<h3>The stages</h3>
<h4>Stage 0 — bootstrap the toolchain</h4>
<p><code>build-root.sh</code> boots a toolchain from nothing: <code>binutils</code>, <code>gcc</code>, your chosen <code>libc</code>, then the <code>toolchain</code> package. This is the "fully from scratch" step — the stage that separates a source distro from one that seeds binaries.</p>
<h4>Stage 1 — base system</h4>
<p>The <code>BASE_PACKAGES</code> set from your profile is built and installed into <code>$ROOT</code>. Every package compiles against the stage-0 toolchain.</p>
<h4>Stage 2 — the swappables</h4>
<p>Exactly what you chose: the kernel (<code>$KERNEL</code>), the init system (<code>$INIT</code>), your privilege-elevation tool (<code>$SUDO</code>), and your network tools (<code>$NET</code>). Nothing preselected — the picks in your make.conf are the picks that get built.</p>
<h4>Stage 3 — finalize the root</h4>
<p><code>mkfs-root.sh</code> formats and assembles the target as your chosen filesystem, producing the rootfs that will boot.</p>
<div class="terminal">
<div class="tbar"><span class="dot r"></span><span class="dot y"></span><span class="dot g"></span><span class="t">$ sh scripts/build-root.sh</span></div>
<pre><span class="c">[ keru ]</span> building Keru rootfs into /tmp/keru/root
<span class="c">[ keru ]</span> profile: init=runit libc=glibc fs=ext4 kernel=linux sudo=doas
<span class="c">[ keru ]</span> stage 0: bootstrap toolchain (gcc binutils glibc)
<span class="c">[ keru ]</span> stage 1: base system
<span class="c">[ keru ]</span> stage 2: kernel + init + sudo + net
<span class="c">[ keru ]</span> stage 3: finalize ext4 root
<span class="k">[ keru ] rootfs ready: /tmp/keru/root</span></pre>
</div>
<h3>The scripts</h3>
<table>
<tr><th>Script</th><th>Job</th></tr>
<tr><td><code>scripts/common.sh</code></td><td>Shared helpers; knows the sibling-repo layout (<code>KAMA_DIR</code>, <code>PKGS_DIR</code>).</td></tr>
<tr><td><code>scripts/build-root.sh</code></td><td>The orchestrator — runs the four stages above.</td></tr>
<tr><td><code>scripts/mkfs-root.sh</code></td><td>Formats the target root as the chosen filesystem.</td></tr>
</table>
<h3>Convenience entrypoints</h3>
<div class="code-block">make rootfs # sh scripts/build-root.sh
make install # sh installer/install.sh
make live-init # syntax-check live/init
make recipe-check # sh -n every recipe in kama-packages</div>
<div class="callout">The pipeline is the honest core of "from scratch": no binary base image, no opaque build tool — a shell script reading a profile and driving a shell package manager.</div>
<p><a href="mkfs-root.html">mkfs-root reference</a> · <a href="kama-repos.html">How the repos fit</a> · <a href="docs.html">← Docs</a></p>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">See the <a href="sitemap.html">sitemap</a> for all pages.</div></noscript>
<script src="assets/js/include.js" data-base="."></script>
</body>
</html>
+50
View File
@@ -0,0 +1,50 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Community — Keru OS</title>
<meta name="description" content="Join the Keru OS community: contribute, report bugs, discuss choices, and shape the distribution.">
<link rel="stylesheet" href="assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="index.html">home</a> / community</p>
<h1>Community</h1>
<p>A small distribution with a clear idea, shaped by people who care about choice.</p>
</header>
<section>
<div class="wrap">
<div class="grid grid-3">
<a class="card" href="contribute.html"><span class="num">1</span><span class="h">Contribute</span><p>Write recipes, fix the installer, improve docs, or help shape the road to 0.1.</p></a>
<a class="card" href="faq.html"><span class="num">2</span><span class="h">FAQ</span><p>Straight answers to the questions everyone asks.</p></a>
<a class="card" href="contact.html"><span class="num">3</span><span class="h">Contact</span><p>GitHub issues, mailing list, and how to reach the project.</p></a>
<a class="card" href="links.html"><span class="num">4</span><span class="h">Links</span><p>The three repos, this site's source, and related reading.</p></a>
</div>
<div class="prose" style="margin-top:40px">
<h3>What the community is for</h3>
<p>Keru holds one opinion — that you should form yours. That extends to the community: the interesting conversations here are about <em>which</em> init/libc/fs combos should be proven next, <em>which</em> recipes matter, and <em>how</em> the distro stays honest at its edges.</p>
<h3>The stance carries over</h3>
<ul class="features">
<li><strong>No gatekeeping about your stack.</strong> Whatever init you run, you're a Keru user doing it right.</li>
<li><strong>Bugs are bugs.</strong> Report a broken combination and it gets curated out of the "offered" set or proven and kept — not argued about for a release.</li>
<li><strong>Small is fine.</strong> This isn't a race for the biggest community; it's a race for the most coherent one.</li>
</ul>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">See the <a href="sitemap.html">sitemap</a> for all pages.</div></noscript>
<script src="assets/js/include.js" data-base="."></script>
</body>
</html>
+63
View File
@@ -0,0 +1,63 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Contact — Keru OS</title>
<meta name="description" content="How to reach the Keru OS project: issues, mailing list, and community channels.">
<link rel="stylesheet" href="assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="index.html">home</a> / <a href="community.html">community</a> / contact</p>
<h1>Contact</h1>
<p>Use issues for bugs and ideas; email for discussion.</p>
</header>
<section>
<div class="wrap">
<div class="grid grid-2">
<div class="card">
<span class="num">preferred</span>
<span class="h">GitHub issues</span>
<p>Bugs, recipe ideas, installer feedback, combination reports. The most actionable way to reach us.</p>
<p><a href="https://github.com/AstralZX/KeruOS/issues">AstralZX/KeruOS issues</a></p>
</div>
<div class="card">
<span class="num">direct</span>
<span class="h">Email</span>
<p>Longer conversations about philosophy, design decisions, and direction.</p>
<p><a href="mailto:[email protected]">[email protected]</a></p>
</div>
<div class="card">
<span class="num">code</span>
<span class="h">The repos</span>
<p>Everything is public. Clone it, read it, break it, report it.</p>
<p><a href="links.html">All links →</a></p>
</div>
</div>
<div class="prose" style="margin-top:40px">
<h3>Bug reports that help</h3>
<ul class="features">
<li><strong>Reproduce.</strong> The combo, the <code>make.conf</code> (if any), the failure output.</li>
<li><strong>Scope.</strong> Was it fetch, build, install, or boot? That points straight at the stage.</li>
<li><strong>Label.</strong> A broken combination gets curated out of "offered" or fixed — say which you'd rather.</li>
</ul>
<div class="callout">Small project, responsive maintainers. If you file something, expect a real answer.</div>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">See the <a href="sitemap.html">sitemap</a> for all pages.</div></noscript>
<script src="assets/js/include.js" data-base="."></script>
</body>
</html>
+65
View File
@@ -0,0 +1,65 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Contribute — Keru OS</title>
<meta name="description" content="How to contribute to Keru OS: recipes, the installer, the package manager, docs, and the website.">
<link rel="stylesheet" href="assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="index.html">home</a> / <a href="community.html">community</a> / contribute</p>
<h1>Contribute</h1>
<p>There's no gatekeeping. There's work to do.</p>
</header>
<section>
<div class="wrap">
<div class="prose">
<p>Keru is small and early, which means contributions are unusually consequential. A recipe you write may be the one a whole filesystem choice builds on. Here's how to get in.</p>
<h3>Where things live</h3>
<table>
<tr><th>Repo</th><th>You'd contribute</th></tr>
<tr><td>KeruOS</td><td>Installer, profile, scripts, live init, docs, and this website.</td></tr>
<tr><td>kama</td><td>The package manager itself — and, ideally, not much. It's meant to stay small.</td></tr>
<tr><td>kama-packages</td><td>Recipes — the highest-leverage place. Busybox, runit, and a template exist.</td></tr>
</table>
<h3>Ways to help</h3>
<ul class="features">
<li><strong>Write recipes.</strong> A <code>&lt;pkg&gt;.sh</code> in <code>kama-packages</code> is a package. Start from <code>TEMPLATE.sh</code>. <a href="recipe-format.html">The format is small.</a></li>
<li><strong>Test the toolchain bootstrap.</strong> The stage-0 build (gcc/glibc from nothing) is the riskiest seam; hands on real machines are gold.</li>
<li><strong>Sharpen the installer.</strong> Menu UX, network handling, stability checks — all open.</li>
<li><strong>Fix bugs.</strong> The road to 0.1 is literally a list of bugs between here and a booting ISO.</li>
<li><strong>Docs & site.</strong> This website lives in <code>web/</code> in the KeruOS repo — plain HTML, no framework. Improving it is plain work on plain files.</li>
</ul>
<h3>Ground rules</h3>
<ul class="features">
<li><strong>Match the ethos.</strong> Source-only, no opinion, small pieces. A PR that adds a dependency resolver to kama contradicts the project's spine.</li>
<li><strong>Stay legible.</strong> If shell can do it plainly, don't introduce machinery.</li>
<li><strong>Honesty at the edges.</strong> Unproven combinations go in with a warning, or not at all — never silently.</li>
<li><strong>AGPL-3.0.</strong> All three repos are AGPL-3.0; contributions fall under it.</li>
</ul>
<h3>Where to start</h3>
<p>Issues, recipe ideas, and bug reports live on the <a href="links.html">three repositories</a>, and discussion on the <a href="contact.html">contact channels</a>. If you're looking for a first move: pick a recipe, read <code>TEMPLATE.sh</code>, and send it.</p>
<div class="callout">A small distribution values every PR — there's no pile to get lost in. What you send is likely to matter.</div>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">See the <a href="sitemap.html">sitemap</a> for all pages.</div></noscript>
<script src="assets/js/include.js" data-base="."></script>
</body>
</html>
+56
View File
@@ -0,0 +1,56 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Credits — Keru OS</title>
<meta name="description" content="Credits and acknowledgment for Keru OS.">
<link rel="stylesheet" href="assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="index.html">home</a> / credits</p>
<h1>Credits</h1>
<p>The people, projects, and tools Keru stands on.</p>
</header>
<section>
<div class="wrap">
<div class="prose">
<h3>Who</h3>
<p>Keru is the work of <strong>Astral</strong> (<a href="https://github.com/AstralZX">@AstralZX</a>), who maintains all three repositories and this site. It grew out of earlier experiments (the lineage runs TOML packages → a 50-line build DSL → plain shell, and from opinionated dogmas to the anti-opinionated stance).</p>
<h3>The tradition Keru sits in</h3>
<ul class="features">
<li><strong>Gentoo</strong> — source-based purity and the profile concept that Keru carries forward.</li>
<li><strong>Nix</strong> — declarative, reproducible composition of a system from pieces.</li>
<li><strong>Bedrock Linux</strong> — the "meta-distribution" idea: a distro about choice and composition.</li>
<li><strong>OpenBSD & doas</strong> — the minimalism that Keru's default privilege tool comes from.</li>
<li><strong>The skarnet suite (s6)</strong> — clean service supervision, an option among equals here.</li>
</ul>
<h3>The free software underneath</h3>
<p>A source-only distribution is downstream of everyone who makes the sources it builds: the Linux kernel, GCC/binutils, the libcs, busybox, the init systems, the filesystem tools, and every project with a recipe in <code>kama-packages</code>. Credit belongs to all of them, and their licenses — not Keru's — govern those components. Keru's AGPL covers Keru's own code (<a href="license.html">see the license page</a>).</p>
<h3>This website</h3>
<ul class="features">
<li><strong>Fonts:</strong> Inter and JetBrains Mono.</li>
<li><strong>Built:</strong> hand-written HTML/CSS/JS, no framework — consistent with the project's spine.</li>
</ul>
<div class="callout">If you contributed and you're not listed, that's a bug — <a href="contact.html">say so</a> and it'll be fixed.</div>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">See the <a href="sitemap.html">sitemap</a> for all pages.</div></noscript>
<script src="assets/js/include.js" data-base="."></script>
</body>
</html>
+50
View File
@@ -0,0 +1,50 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Docs — Keru OS</title>
<meta name="description" content="Keru documentation: make.conf, profile, recipe format, build pipeline, live init, and contributor references.">
<link rel="stylesheet" href="assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="index.html">home</a> / docs</p>
<h1>Docs</h1>
<p>The reference. Everything you might open a file to check.</p>
</header>
<section>
<div class="wrap">
<div class="grid grid-2">
<a class="card" href="getting-started.html"><span class="num">guide</span><span class="h">Getting started</span><p>From booting the ISO to a first-boot system — the whole arc in one read.</p></a>
<a class="card" href="make-conf.html"><span class="num">reference</span><span class="h">make.conf</span><p>The profile file your selections produce, and every variable it knows.</p></a>
<a class="card" href="profile.html"><span class="num">reference</span><span class="h">Profile system</span><p>How profile/make.conf templates the build and the swappables.</p></a>
<a class="card" href="recipe-format.html"><span class="num">spec</span><span class="h">Recipe format</span><p>The formal spec for kama package recipes — fields, hooks, tiers.</p></a>
<a class="card" href="recipe-authoring.html"><span class="num">howto</span><span class="h">Recipe authoring</span><p>Write your first kama recipe, with real examples from the repo.</p></a>
<a class="card" href="build-pipeline.html"><span class="num">reference</span><span class="h">Build pipeline</span><p>scripts/build-root.sh and mkfs-root.sh — how a make.conf becomes a rootfs.</p></a>
<a class="card" href="toolchain.html"><span class="num">reference</span><span class="h">Toolchain bootstrap</span><p>binutils → gcc → libc → self-host: what "from scratch" means.</p></a>
<a class="card" href="live-init.html"><span class="num">reference</span><span class="h">Live init</span><p>live/init — how booting the ISO auto-starts the installer.</p></a>
<a class="card" href="kama-config.html"><span class="num">reference</span><span class="h">Kama configuration</span><p>Every kama variable: PKGDIR, ROOT, CACHEDIR, MAKE_CONF, mirrors.</p></a>
<a class="card" href="mirror-cache.html"><span class="num">reference</span><span class="h">Mirrors &amp; cache</span><p>The download order and the dl/src/stage cache layout.</p></a>
<a class="card" href="security.html"><span class="num">reference</span><span class="h">Security</span><p>Trust model of a source-only build, stated plainly.</p></a>
<a class="card" href="troubleshooting.html"><span class="num">guide</span><span class="h">Troubleshooting</span><p>Diagnose by stage — boot, network, fetch, build, finalize.</p></a>
<a class="card" href="release-process.html"><span class="num">reference</span><span class="h">Release process</span><p>What a release contains, and how versioning works.</p></a>
<a class="card" href="swappables.html"><span class="num">guide</span><span class="h">Swappables guide</span><p>Every component you can choose at install, with the full option list.</p></a>
<a class="card" href="install.html"><span class="num">guide</span><span class="h">Install guide</span><p>The end-to-end installation flow, from BIOS to boot.</p></a>
<a class="card" href="contribute.html"><span class="num">guide</span><span class="h">Contribute</span><p>How to get involved across the three repos and this site.</p></a>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">See the <a href="sitemap.html">sitemap</a> for all pages.</div></noscript>
<script src="assets/js/include.js" data-base="."></script>
</body>
</html>
+61
View File
@@ -0,0 +1,61 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Ethos — Keru OS</title>
<meta name="description" content="The ける ethos: keru keitō-teki — a system assembled the way you want it. The name, the mark, and what Keru stands for.">
<link rel="stylesheet" href="assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="index.html">home</a> / ethos</p>
<h1>Ethos</h1>
<p>What the mark stands for.</p>
</header>
<section>
<div class="wrap">
<div class="prose">
<h3>ける · keru keitō-teki</h3>
<p>Keru is written <strong>ける</strong> in Japanese, and the project's full phrase is <strong>ける・けいとうてき</strong> (keru keitō-teki) — a system assembled the way you want it. The ethos is compact enough to sit behind a name: you don't receive a system, you craft it.</p>
<p>It's deliberately not a pronouncement. It's a description of the relationship Keru wants with you: you choose, it builds, and it has no agenda beyond honoring that choice.</p>
<h3>The kiln and the craft</h3>
<p>The package manager is called <strong>Kama</strong> (窯, "kiln"). The metaphor is warm on purpose — not a cathedral of machinery, but a kiln: you stack your ingredients, fire it, and what comes out is shaped by your hand, not by the kiln's preferences. A kiln doesn't have opinions about the pot. It just fires.</p>
<h3>Principles guiding the work</h3>
<ul class="features">
<li><strong>Source-only.</strong> You run what you built. Every package is compiled from original source.</li>
<li><strong>Legibility.</strong> Every decision is a script or a line in <code>make.conf</code> you can see and change.</li>
<li><strong>Simplicity as stability.</strong> Fewer moving parts means fewer things to break — keeping the manager in shell is the point, not a compromise.</li>
<li><strong>Honesty at the edges.</strong> Unproven combinations get a warning, not a wall. You are never lied to about risk.</li>
<li><strong>No junk.</strong> No telemetry, no preinstalled opinions masked as defaults, no background assumptions.</li>
</ul>
<h3>What Keru is not</h3>
<ul class="features">
<li>Not a meta-OS that runs arbitrary kernels — it's a Linux distribution that composes the bits <em>above</em> the kernel however you like.</li>
<li>Not an opinionless void — it holds one strong opinion: that you should form yours.</li>
<li>Not a challenge to pick the "right" stack — there is no right stack, there's only your stack.</li>
</ul>
<blockquote>企業はあなたの選択の上に成り立つ — the distro stands on your choices.</blockquote>
<p><a href="about.html">Read about Keru</a> · <a href="philosophy.html">Read the philosophy</a></p>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">See the <a href="sitemap.html">sitemap</a> for all pages.</div></noscript>
<script src="assets/js/include.js" data-base="."></script>
</body>
</html>
+68
View File
@@ -0,0 +1,68 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>FAQ — Keru OS</title>
<meta name="description" content="Frequently asked questions about Keru OS: what it is, how it differs from Gentoo/Bedrock, what it means for you.">
<link rel="stylesheet" href="assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="index.html">home</a> / <a href="community.html">community</a> / faq</p>
<h1>FAQ</h1>
<p>Straight answers.</p>
</header>
<section>
<div class="wrap">
<div class="prose">
<h3>What is a "meta-distribution"?</h3>
<p>In the GNU/Linux world it names the Gentoo/Nix/Bedrock family: distributions organized around <em>choice and composition of components</em> rather than a fixed opinionated stack. Keru is the anti-opinionated member — its meta is choosing <em>not to choose for you</em>. <a href="anti-opinionated.html">Details.</a></p>
<h3>Is Keru a "meta-OS" that runs any kernel?</h3>
<p>No. Keru is a Linux distribution. Its freedom lives above the kernel — init, libc, filesystem, and Linux kernel variants. It won't boot a BSD or illumos kernel; that's not the claim and not on the roadmap.</p>
<h3>How is this different from Gentoo?</h3>
<p>Gentoo is source-based and highly configurable, but it still picks most of your stack and calls it defaults. Keru extends the same impulse to its logical end: no default init, no default libc, no default filesystem. And its manager, Kama, is a ~225-line shell script — no resolver, no database.</p>
<h3>How is this different from Bedrock?</h3>
<p>Bedrock stitches multiple <em>distributions</em> together (apt + pacman + xbps side by side). Keru doesn't compose distros — it composes <em>components</em>, one init/libc/fs/kernel/tool at a time, built from source.</p>
<h3>Why is network required to install?</h3>
<p>The ISO carries only the installer. Your entire system is fetched and compiled during install, so a connection is a hard gate. It's the price of "power to choose anything" — nothing is prebuilt. <a href="installation-requirements.html">More.</a></p>
<h3>Will my system be stable?</h3>
<p>Stable on the combinations Keru offers you — that's the promise. If you pick something past the proven edge, the installer warns and lets you proceed. You're never blocked. <a href="stability.html">The full stance.</a></p>
<h3>Is this a joke or a real project?</h3>
<p>Real. The repos are live, AGPL-3.0, and the road to 0.1 is documented. It's at the "design is public, nothing has booted hardware yet" stage — which is exactly what 0.1 is for.</p>
<h3>What's with the Japanese?</h3>
<p><strong>ける</strong> (Keru) and <strong>ける・けいとうてき</strong> (keru keitō-teki) — "craft your system." Kama (窯) means "kiln." The naming is deliberate atmosphere, not branding gimmick. <a href="ethos.html">More.</a></p>
<h3>Why is the package manager in shell?</h3>
<p>Because a package manager should be legible, and shell is the most legible thing that can run a build recipe. The real cost of your build is the compiler, not the manager — so the manager gets to be simple.</p>
<h3>When can I install it?</h3>
<p>The first release, 0.1, ships as a bootable ISO. <a href="news/roadmap-0.1.html">Follow the road to 0.1</a>.</p>
<h3>Where do I ask something this page doesn't cover?</h3>
<p><a href="contact.html">Contact channels</a> — issues first, then the mailing list.</p>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">See the <a href="sitemap.html">sitemap</a> for all pages.</div></noscript>
<script src="assets/js/include.js" data-base="."></script>
</body>
</html>
+61
View File
@@ -0,0 +1,61 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Filesystems — Keru OS</title>
<meta name="description" content="Choose your root filesystem with Keru: ext4, btrfs, xfs, zfs, f2fs, jfs, reiserfs, or swap.">
<link rel="stylesheet" href="assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="index.html">home</a> / <a href="swappables.html">swappables</a> / filesystems</p>
<h1>Filesystems</h1>
<p>The shape of your disk.</p>
</header>
<section>
<div class="wrap">
<div class="prose">
<p>The filesystem is how the kernel organizes data on disk — and it's a genuinely meaningdifferent choice: reliability vs features, volume management, snapshots, checksums, performance on specific workloads. Keru leaves it to you.</p>
</div>
<table>
<tr><th>Filesystem</th><th>Character</th></tr>
<tr><td><strong>ext4</strong></td><td>The default. Proven, journaled, everywhere-supported, boring in the best way.</td></tr>
<tr><td><strong>ext2 / ext3</strong></td><td>Classic lineage — ext2 is unjournaled simplicity, ext3 added the journal.</td></tr>
<tr><td><strong>btrfs</strong></td><td>Snapshots, subvolumes, checksums, and a rich feature set out of the box.</td></tr>
<tr><td><strong>xfs</strong></td><td>Scale-friendly, robust, excellent for large files and heavy workloads.</td></tr>
<tr><td><strong>zfs</strong></td><td>Snapshots, RAID-Z, checksums, volume management. Serious features, more moving parts.</td></tr>
<tr><td><strong>f2fs</strong></td><td>Flash-friendly filesystem, designed for SSDs and flash storage performance.</td></tr>
<tr><td><strong>jfs</strong></td><td>IBM's journaled filesystem — lean, historically aimed at servers.</td></tr>
<tr><td><strong>reiserfs</strong></td><td>Once a pioneer; now effectively unmaintained. Offered, but flagged.</td></tr>
<tr><td><strong>swap</strong></td><td>As a separate swap area, part of the root setup.</td></tr>
</table>
<div class="prose">
<h3>Honest flags</h3>
<p>Two filesystem options carry warnings in the installer:</p>
<ul class="features">
<li><strong>zfs</strong> as root needs a kernel module + ZFS userspace, and isn't yet proven end-to-end in the 0.1 pipeline. Warned, not blocked.</li>
<li><strong>reiserfs</strong> is unmaintained with no stable future. Offered because the choice is yours; flagged because honesty is cheaper than regret.</li>
</ul>
<div class="callout">The filesystem tooling (mkfs, fs tools) is built alongside the kernel and init in stage 2 — your choice dictating exactly what gets compiled in.</div>
<p><a href="swappables.html">← All swappables</a></p>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">See the <a href="sitemap.html">sitemap</a> for all pages.</div></noscript>
<script src="assets/js/include.js" data-base="."></script>
</body>
</html>
+77
View File
@@ -0,0 +1,77 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Getting started — Keru OS</title>
<meta name="description" content="From booting the Keru ISO to a first-boot system: prerequisites, the install flow, network, and day one.">
<link rel="stylesheet" href="assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="index.html">home</a> / <a href="docs.html">docs</a> / getting started</p>
<h1>Getting started</h1>
<p>Zero to a chosen, booting, source-built system.</p>
</header>
<section>
<div class="wrap">
<div class="prose">
<p>Keru 0.1 ships as an ISO. There is no source build to DIY, no binary download, no flashing a rootfs tarball. Boot the ISO, answer the installer, and Keru builds exactly what you chose while you watch.</p>
<h3>Before you begin</h3>
<ul class="features">
<li><strong>A working network.</strong> The build is fully online — every source tarball is downloaded fresh at install time.</li>
<li><strong>A spare target disk.</strong> <code>mkfs-root.sh</code> formats whatever root device the installer points at. It will be written over.</li>
<li><strong>Patience for the first build.</strong> Fetch + compile of the full toolchain and system takes a while on modest hardware.</li>
<li><strong>Decisions.</strong> Prep your picks ahead — or just press enter; sane defaults are documented on every prompt.</li>
</ul>
<h3>The flow</h3>
<div class="code-block">1. Write the ISO to USB sudo dd if=keru-0.1.iso of=/dev/sdX bs=4M status=progress
2. Boot the stick BIOS/UEFI → the live image starts by itself
3. live/init mounts & runs the installer launches automatically on boot
4. Connect to the network the installer runs nmtui for you when offline
5. Make your picks init · libc · fs · kernel · sudo · net
6. Keru builds the system fetch → stage 0 toolchain → base → swappables
7. First boot your crafted system, exactly as chosen</div>
<h3>Your picks</h3>
<table>
<tr><th>Choice</th><th>Default</th><th>Why you might change it</th></tr>
<tr><td>Init system</td><td><code>runit</code></td><td>systemd for optional use — but Keru never forces it.</td></tr>
<tr><td>C library</td><td><code>glibc</code></td><td>musl for a smaller static-leaning system.</td></tr>
<tr><td>Filesystem</td><td><code>ext4</code></td><td>btrfs snapshots, zfs features, xfs scaling.</td></tr>
<tr><td>Kernel</td><td><code>linux</code></td><td>linux-lts for longevity, hardened for attacks.</td></tr>
<tr><td>Privilege elevation</td><td><code>doas</code></td><td>sudo if you live in its muscle memory.</td></tr>
<tr><td>Network tools</td><td><code>nmtui</code></td><td>networkmanager, connman, or systemd-networkd.</td></tr>
</table>
<div class="callout">Every option here has a dedicated page. See <a href="swappables.html">the swappables guide</a> and its sub-pages before you install, so boot rehearsal is boring by design.</div>
<h3>Day one</h3>
<p>Keru installs a bare, honest base — the packages you chose plus the few kama needs to run. From there you shape the rest:</p>
<div class="code-block"># your system, your way
kama make vim # build anything else from source
kama info busybox # peek at a recipe's metadata
doas kama install tmux</div>
<p>Everything you don't install, you don't get. No services pretending to be useful, no telemetry phone-home.</p>
<div class="callout ok">Now read the <a href="installer-walkthrough.html">installer walkthrough</a> for the fine detail, or go straight to <a href="troubleshooting.html">troubleshooting</a> when something surprises you.</div>
<p><a href="install.html">← Install overview</a> · <a href="network-setup.html">Network setup</a></p>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">See the <a href="sitemap.html">sitemap</a> for all pages.</div></noscript>
<script src="assets/js/include.js" data-base="."></script>
</body>
</html>
+135
View File
@@ -0,0 +1,135 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Keru OS — craft your system</title>
<meta name="description" content="Keru is an independent, source-only Linux distribution where you choose your init, libc, filesystem, kernel, and tools at install time. Nothing is forced. Everything is swappable.">
<link rel="stylesheet" href="assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="hero">
<span class="kicker reveal"><span class="dot"></span> independent · source-only · linux</span>
<span class="seal reveal d1">ける</span>
<h1 class="reveal d1">You don't install a system.<br>You <span class="grad">craft</span> one.</h1>
<p class="sub reveal d2">Keru is an anti-opinionated Linux distribution. Choose your init, libc, filesystem, kernel, and tools at install time — and it builds exactly what you chose from source. Nothing forced, nothing you didn't ask for.</p>
<div class="cta-row reveal d3">
<a class="btn btn-primary" href="install.html">↓ Install 0.1</a>
<a class="btn btn-ghost" href="philosophy.html">Read the philosophy</a>
<a class="btn btn-ghost" href="swappables.html">See what's swappable</a>
</div>
</header>
<div class="dossier reveal d4">
<div class="row"><span class="lbl">Name</span><span class="val">Keru OS ける</span></div>
<div class="row"><span class="lbl">Status</span><span class="val a">UNDER CONSTRUCTION</span></div>
<div class="row"><span class="lbl">Distribution</span><span class="val">source-only linux</span></div>
<div class="row"><span class="lbl">Package manager</span><span class="val">kama · ~225 lines</span></div>
<div class="row"><span class="lbl">Defining trait</span><span class="val">anti-opinionated</span></div>
<div class="row"><span class="lbl">Opinions forced</span><span class="val a">0</span></div>
<div class="row"><span class="lbl">Base packages</span><span class="val">0 (everything is swappable)</span></div>
<div class="row"><span class="lbl">Model</span><span class="val">boot ISO → choose → built from source</span></div>
</div>
<div class="ticker">
<div class="ticker-inner">
<span><b>runit</b> · <b>s6</b> · <b>openrc</b> · <b>systemd</b> · <b>busybox-init</b> · <b>sysvinit</b> · <b>dinit</b> · <b>shepherd</b></span>
<span><b>glibc</b> · <b>musl</b> · <b>uclibc-ng</b></span>
<span><b>ext4</b> · <b>btrfs</b> · <b>xfs</b> · <b>zfs</b> · <b>f2fs</b> · <b>jfs</b> · <b>reiserfs</b></span>
<span><b>linux</b> · <b>linux-lts</b> · <b>linux-hardened</b> · <b>linux-cachyos</b> · <b>linux-zen</b></span>
<span><b>doas</b> · <b>sudo</b> · <b>opendoas</b> · <b>su</b></span>
<span class="a">ける・けいとうてき <b>— craft your system</b></span>
</div>
</div>
<section>
<div class="wrap">
<p class="section-title">the differentiator</p>
<h2 class="head">Everything is swappable. Nothing is forced.</h2>
<p class="lead">Most distros hand you someone else's decision. Keru refuses that — every foundational component is yours to pick, resolved at install time and locked in at first boot.</p>
<div class="grid grid-4">
<a class="card" href="inits.html"><span class="num">01</span><span class="h">Init system</span><p>runit, s6, openrc, systemd, busybox-init, sysvinit, dinit, shepherd — your call.</p></a>
<a class="card" href="libcs.html"><span class="num">02</span><span class="h">C library</span><p>glibc, musl, uclibc-ng. The foundation under everything is up to you.</p></a>
<a class="card" href="filesystems.html"><span class="num">03</span><span class="h">Filesystem</span><p>ext4, btrfs, xfs, zfs, f2fs, jfs, reiserfs, swap. Pick your root.</p></a>
<a class="card" href="kernels.html"><span class="num">04</span><span class="h">Kernel</span><p>linux, linux-lts, hardened, cachyos, zen. The spine of your machine.</p></a>
<a class="card" href="privilege-elevation.html"><span class="num">05</span><span class="h">Privilege elevation</span><p>doas, sudo, opendoas, or plain su — decide how you elevate.</p></a>
<a class="card" href="network-tools.html"><span class="num">06</span><span class="h">Network tools</span><p>networkmanager, connman, systemd-networkd, or nmtui on its own.</p></a>
<a class="card" href="make-conf.html"><span class="num">07</span><span class="h">Everything else</span><p>kernel parameters, locale, clock, keymap — all configurable in make.conf.</p></a>
<a class="card" href="stability.html"><span class="num">08</span><span class="h">Stability</span><p>Stable on what we offer. Past that, we warn and step aside — never block.</p></a>
</div>
</div>
</section>
<section style="background:var(--paper-2);border-top:1px solid var(--hair);border-bottom:1px solid var(--hair)">
<div class="wrap">
<p class="section-title" style="text-align:center">live boot</p>
<h2 class="head" style="text-align:center">Boot. Choose. Built from source.</h2>
<p class="lead" style="text-align:center">The ISO carries only the installer. Boot it, it starts the installer automatically, you make your picks — and it builds your entire system from source, live.</p>
<div class="terminal reveal">
<div class="tbar"><span class="dot r"></span><span class="dot y"></span><span class="dot g"></span><span class="t">keru@live:~$</span></div>
<pre><span class="c">[ keru ]</span> <span class="k">Keru OS — craft your system</span>
Select the components, press enter for defaults.
== Init system == [runit]
== C library == [glibc]
== Filesystem == [ext4]
== Kernel == [linux]
== Privilege elevation == [doas]
== Network tools == [nmtui]
Selecting: <span class="c">btrfs</span> ← you choose, Keru builds it
<span class="p">...fetching source...</span>
<span class="p">...compiling from scratch (gcc → glibc → the system)...</span>
<span class="k">[ keru ] rootfs ready: /tmp/keru/root</span>
<span class="c">[ keru ] you crafted a btrfs, doas, runit system. it boots.</span></pre>
</div>
</div>
</section>
<section>
<div class="wrap">
<p class="section-title">why keru</p>
<h2 class="head">Purist. Honest. Light.</h2>
<div class="stats">
<div class="stat"><div class="big">~225</div><div class="lbl">lines, kama package manager</div></div>
<div class="stat"><div class="big">0</div><div class="lbl">binary packages</div></div>
<div class="stat"><div class="big">1,000+</div><div class="lbl">possible system combos</div></div>
<div class="stat"><div class="big">0</div><div class="lbl">opinions forced on you</div></div>
</div>
<div class="grid grid-3" style="margin-top:34px">
<div class="card"><span class="h">Source-only</span><p>Everything — toolchain included — compiled from original source. No binary packages, no opaque machinery.</p></div>
<div class="card"><span class="h">Kama, the kiln</span><p>The whole package manager is a ~225-line shell script. Legible. You can read every decision it makes.</p></div>
<div class="card"><span class="h">Anti-opinionated</span><p>Keru's only opinion is that you must form one. After that, it shuts up and builds exactly what you chose.</p></div>
<div class="card"><span class="h">From scratch</span><p>The ISO carries only the installer. Your system is fetched and built on the fly during install.</p></div>
<div class="card"><span class="h">Warn, don't block</span><p>Stability is guaranteed on what's offered. Push past the proven edge and Keru warns you, then gets out of your way.</p></div>
<div class="card"><span class="h">All yours</span><p>No telemetry, no unwanted services, no background assumptions. The disk reflects exactly what you chose.</p></div>
</div>
</div>
</section>
<section style="background:var(--paper-2);border-top:1px solid var(--hair)">
<div class="wrap" style="text-align:center">
<h2 class="head">Ready when it's ready.</h2>
<p class="lead" style="margin:0 auto 24px">Keru 0.1 will ship as a bootable ISO. No source builds, no manual tooling — boot, choose, then watch it craft your system.</p>
<div class="cta-row">
<a class="btn btn-primary" href="news.html">Follow progress</a>
<a class="btn btn-ghost" href="contribute.html">Contribute</a>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript>
<div style="text-align:center;padding:16px">
See the <a href="sitemap.html">sitemap</a> for all pages.
</div>
</noscript>
<script src="assets/js/include.js" data-base="."></script>
</body>
</html>
+55
View File
@@ -0,0 +1,55 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Init systems — Keru OS</title>
<meta name="description" content="The init system is yours to choose with Keru: runit, s6, openrc, systemd, busybox-init, sysvinit, dinit, shepherd.">
<link rel="stylesheet" href="assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="index.html">home</a> / <a href="swappables.html">swappables</a> / inits</p>
<h1>Init systems</h1>
<p>Who brings your machine up. Your call.</p>
</header>
<section>
<div class="wrap">
<div class="prose">
<p>The init system is the first thing that runs after the kernel — it boots the rest of your system and usually supervises services. It's also one of the most fought-over pieces of modern Linux. Keru's answer to the fight is simple: <strong>pick one yourself.</strong></p>
</div>
<div class="grid grid-3" style="margin-top:30px">
<div class="card"><span class="h">runit</span><p>Small, fast, BSD-style. Default in Keru — fast boot, simple service supervision, based on the runit process supervisor.</p></div>
<div class="card"><span class="h">s6</span><p>The skarnet suite's init and service manager. Dependency-free, designed-for-service supervision, very small.</p></div>
<div class="card"><span class="h">openrc</span><p>The classic Gentoo-style init. Compatible with sysvinit-style init.d, predictable "exclusive" service tree.</p></div>
<div class="card"><span class="h">systemd</span><p>The dominant init — service manager, logind, udev, resolved, timedate, all in one. If you want it, it's a choice, not an assumption.</p></div>
<div class="card"><span class="h">busybox-init</span><p>The bare init from busybox. Minimalist, tiny static binaries, closest to "nothing but a process supervisor."</p></div>
<div class="card"><span class="h">sysvinit</span><p>The classic System V init. Simple runlevels, init.d scripts, historically the baseline Linux init.</p></div>
<div class="card"><span class="h">dinit</span><p>A modern, fast, dependency-oriented init and service manager. Parallel boot, small footprint.</p></div>
<div class="card"><span class="h">shepherd</span><p>GNU's service manager (init). Guile-based, declarative services, part of the GNU project.</p></div>
</div>
<div class="prose" style="margin-top:34px">
<h3>Notes on pairing</h3>
<p>Some combinations are easier than others. The stability check in the installer flags pairs that aren't yet proven (for example, <code>musl + systemd</code>), but never blocks them — <a href="stability.html">the warn-not-block stance</a>.</p>
<div class="callout">The init you pick is baked in at first boot. It's a choice you make once, deliberately, at install — not inherited from a default you never saw.</div>
<p><a href="swappables.html">← All swappables</a></p>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">See the <a href="sitemap.html">sitemap</a> for all pages.</div></noscript>
<script src="assets/js/include.js" data-base="."></script>
</body>
</html>
+75
View File
@@ -0,0 +1,75 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Install — Keru OS</title>
<meta name="description" content="How to install Keru: boot the ISO, the installer starts itself, choose your components, and Keru builds your system from source.">
<link rel="stylesheet" href="assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="index.html">home</a> / install</p>
<h1>Install Keru</h1>
<p>Boot the ISO. The installer starts itself. You choose. It builds.</p>
</header>
<section>
<div class="wrap">
<div class="prose">
<h3>The whole flow</h3>
<p>Keru ships as a live ISO that carries <strong>only the installer</strong>. There is no prebuilt base image on the disk. The entire system — toolchain, kernel, init, libc, filesystem tooling — is fetched and compiled during installation, on the fly.</p>
<div class="callout"><strong>Network required.</strong> A working connection is a hard requirement for installing Keru. The installer checks it, and if you're not connected it offers to run <code>nmtui</code> for you.</div>
<h3>Step by step</h3>
<ol>
<li><strong>Boot the ISO.</strong> The live init (<code>live/init</code>) mounts the essentials and launches the installer automatically. No shell prompt, no manual boot gymnastics — it just starts.</li>
<li><strong>Connect if asked.</strong> If there's no network yet, you'll be prompted. Say yes and <code>nmtui</code> opens; connect, then continue. The installer re-checks until you're online.</li>
<li><strong>Choose your system.</strong> The installer walks through each swappable: init system, C library, filesystem, kernel, privilege elevation, network tools. Defaults are one enter-key away.</li>
<li><strong>Resolve the stability check.</strong> Unproven combinations get a warning, never a block. If it's risky, you're told — then you decide.</li>
<li><strong>Build.</strong> Confirm, and Keru fetches and compiles your exact system from source into a rootfs, then writes it to disk.</li>
<li><strong>Boot what you chose.</strong> Fixed at first boot. The system that lands is precisely the one you designed.</li>
</ol>
<h3>What the installer asks you</h3>
<table>
<tr><th>Component</th><th>Options</th></tr>
<tr><td>Init system</td><td>runit · s6 · openrc · systemd · busybox-init · sysvinit · dinit · shepherd</td></tr>
<tr><td>C library</td><td>glibc · musl · uclibc-ng</td></tr>
<tr><td>Filesystem</td><td>ext4 · ext2 · ext3 · btrfs · xfs · zfs · f2fs · jfs · reiserfs</td></tr>
<tr><td>Kernel</td><td>linux · linux-lts · linux-hardened · linux-cachyos · linux-zen</td></tr>
<tr><td>Privilege elevation</td><td>doas · sudo · opendoas · su</td></tr>
<tr><td>Network tools</td><td>nmtui · networkmanager · connman · systemd-networkd</td></tr>
</table>
<h3>What it writes</h3>
<p>Your choices are assembled into a <code>make.conf</code>, then handed to the build pipeline: <code>scripts/build-root.sh</code> drives Kama through toolchain bootstrap, base system, kernel, init, and tooling. The result — a rootfs matching your profile — is finalized with <code>mkfs-root.sh</code> and written to the target filesystem.</p>
<div class="code-block"># Generated by keru-install — hand-tune then rebuild if you like.
INIT=runit
LIBC=glibc
TARGET_FS=ext4
KERNEL=linux
SUDO=doas
NET=nmtui
LICENSE_ACCEPT=(*)</div>
<div class="callout ok"><strong>From scratch, every time.</strong> There's no binary base to seed. The toolchain is bootstrapped — gcc, binutils, your libc — then the rest on top. This is the "fully from scratch" path, kept honest.</div>
<p><a href="installer-walkthrough.html">Walk through the installer in detail</a> · <a href="installation-requirements.html">See the requirements</a> · <a href="network-setup.html">Network setup details</a></p>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">See the <a href="sitemap.html">sitemap</a> for all pages.</div></noscript>
<script src="assets/js/include.js" data-base="."></script>
</body>
</html>
+61
View File
@@ -0,0 +1,61 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Installation requirements — Keru OS</title>
<meta name="description" content="What you need to install Keru: a network connection, a machine to run it on, and a willingness to make choices.">
<link rel="stylesheet" href="assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="index.html">home</a> / <a href="install.html">install</a> / requirements</p>
<h1>Installation requirements</h1>
<p>Honest about what installing Keru demands.</p>
</header>
<section>
<div class="wrap">
<div class="prose">
<h3>Hard requirements</h3>
<table>
<tr><th>Requirement</th><th>Why</th></tr>
<tr><td><strong>Working network</strong></td><td>The ISO carries only the installer. Everything else — toolchain, kernel, init, libc, tools — is fetched and compiled during install. No network, no install.</td></tr>
<tr><td><strong>A machine that runs Linux</strong></td><td>Keru is a Linux distribution. The installer boots on x86 (and other archs as they're proven).</td></tr>
<tr><td><strong>A target disk/filesystem</strong></td><td>The system is written to the filesystem you choose during install.</td></tr>
<tr><td><strong>Some patience</strong></td><td>Everything is built from source on your machine. A from-scratch toolchain + system takes time. The compiler, not the package manager, is the bottleneck.</td></tr>
<tr><td><strong>A willingness to choose</strong></td><td>Keru's only ask is that you form an opinion about init, libc, filesystem, kernel, and tooling. Defaults exist; the decisions are still yours.</td></tr>
</table>
<h3>Not requirements</h3>
<ul class="features">
<li><strong>No pre-existing Linux.</strong> You don't need an OS to install from — the ISO + installer handles everything.</li>
<li><strong>No manual source builds.</strong> The installer drives the whole from-scratch build for you.</li>
<li><strong>No binary packages.</strong> Nothing precompiled to download. You build what you run.</li>
<li><strong>No telemetry or accounts.</strong> Nothing phone-home, nothing to sign up for to install.</li>
</ul>
<h3>The network, concretely</h3>
<p>At the first installable release (0.1), the network path is straightforward: wired Ethernet via DHCP, or wireless via <code>nmtui</code>, both handled from inside the installer. <a href="network-setup.html">See the network setup flow.</a></p>
<h3>What "from the network" means</h3>
<p>The installer fetches source tarballs (straight from upstream, or via a mirror when <code>SOURCE_MIRROR</code> is set) and pulls package recipes from the GitHub-hosted <a href="kama-repos.html">recipe repository</a>. The heavy lifting is the compiler on your CPU — which is exactly the point of a source-only, from-scratch distribution.</p>
<div class="callout">If you want fast and prebaked, a binary distro is right there. If you want <em>your</em> machine — built from source to your exact selection — Keru is the one.</div>
<p><a href="install.html">← Back to install overview</a></p>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">See the <a href="sitemap.html">sitemap</a> for all pages.</div></noscript>
<script src="assets/js/include.js" data-base="."></script>
</body>
</html>
+113
View File
@@ -0,0 +1,113 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Installer walkthrough — Keru OS</title>
<meta name="description" content="A detailed walkthrough of the Keru installer: every menu, every choice, the network gate, the stability check, and the build.">
<link rel="stylesheet" href="assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="index.html">home</a> / <a href="install.html">install</a> / walkthrough</p>
<h1>Installer walkthrough</h1>
<p>Every screen, in order, with the logic behind it.</p>
</header>
<section>
<div class="wrap">
<div class="prose">
<h3>0 — Boot</h3>
<p>The live init starts <code>installer/install.sh</code> automatically on the console. If the installer ever exits (say you decline to build), it drops you into an emergency shell rather than stranding you.</p>
<h3>1 — Network gate</h3>
<p>Because the ISO carries only the installer, connectivity is checked first. The probe hits a few hosts (<code>1.1.1.1</code>, <code>github.com</code>) with ping; if ping isn't there, it falls back to a TCP connect via <code>nc</code>.</p>
<div class="terminal">
<div class="tbar"><span class="dot r"></span><span class="dot y"></span><span class="dot g"></span><span class="t">keru@live:~$</span></div>
<pre>[ keru ] network: connected <span class="c">← online, straight to choices</span>
<span class="p">or, if offline:</span>
[ keru ] warning: network: not connected
Connect to the network now (runs nmtui)? [Y/n] <span class="k">y</span>
<span class="p">(nmtui opens; you connect; press ok)</span>
[ keru ] network: connected</pre>
</div>
<p>If you press <kbd>n</kbd> at the prompt, the installer exits with <code>a network connection is required to install Keru</code>. If you run <code>nmtui</code> and don't actually connect, the loop simply asks again — it never fakes success.</p>
<h3>2 — Choose your system</h3>
<p>Each swappable is presented as a numbered menu. Pressing enter keeps the default; typing a number picks the option.</p>
<div class="terminal">
<div class="tbar"><span class="dot r"></span><span class="dot y"></span><span class="dot g"></span><span class="t">keru@live:~$</span></div>
<pre>[ keru ] Keru OS — craft your system
== Init system ==
1) runit
2) s6
3) openrc
4) systemd
5) busybox-init
6) sysvinit
7) dinit
8) shepherd
Select [runit]: </pre>
</div>
<p>The same pattern repeats for C library, filesystem, kernel, privilege elevation, and network tools.</p>
<h3>3 — Stability check</h3>
<p>After the last pick, known-risky combinations are flagged. This is a warning, never a block — the philosophy of <a href="stability.html">stable-on-what's-offered, never-lock-you-out</a>.</p>
<div class="terminal">
<div class="tbar"><span class="dot r"></span><span class="dot y"></span><span class="dot g"></span><span class="t">keru@live:~$</span></div>
<pre>[ keru ] warning: uclibc-ng + runit: not yet proven to build and boot together
[ keru ] warning: this combination is unstable. Keru won't stop you — build at your own risk.</pre>
</div>
<h3>4 — make.conf</h3>
<p>Your selections are written to a profile and shown back to you before anything builds:</p>
<div class="terminal">
<div class="tbar"><span class="dot r"></span><span class="dot y"></span><span class="dot g"></span><span class="t">keru@live:~$</span></div>
<pre>[ keru ] writing /tmp/keru/make.conf
[ keru ] profile complete:
# Generated by keru-install — hand-tune then rebuild if you like.
INIT=runit
LIBC=glibc
TARGET_FS=btrfs
KERNEL=linux
SUDO=doas
NET=nmtui
LICENSE_ACCEPT=(*)
Build now? [y/N] <span class="k">y</span></pre>
</div>
<h3>5 — Build</h3>
<p>Confirming hands the profile to the build pipeline, which runs in three stages:</p>
<ol>
<li><strong>Stage 0 — bootstrap.</strong> <code>binutils</code>, <code>gcc</code>, your chosen <code>libc</code>, then the <code>toolchain</code> package. This is the from-scratch toolchain.</li>
<li><strong>Stage 1 — base system.</strong> The <code>BASE_PACKAGES</code> set from your <code>make.conf</code>.</li>
<li><strong>Stage 2 — the swappables.</strong> Kernel, init, sudo-alternative, and network tools — exactly the ones you picked.</li>
<li><strong>Stage 3 — finalize.</strong> <code>mkfs-root.sh</code> writes the chosen filesystem to the target root.</li>
</ol>
<div class="callout ok"><strong>Result:</strong> a rootfs at <code>/tmp/keru/root</code> matching your profile, ready to boot. Fixed at first boot — the system you designed.</div>
<p><a href="install.html">← Back to install overview</a> · <a href="build-pipeline.html">The build pipeline in full</a></p>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">See the <a href="sitemap.html">sitemap</a> for all pages.</div></noscript>
<script src="assets/js/include.js" data-base="."></script>
</body>
</html>
+77
View File
@@ -0,0 +1,77 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Kama configuration — Keru OS</title>
<meta name="description" content="The full kama configuration reference: PKGDIR, CACHEDIR, ROOT, MAKE_CONF, PURGE_TEMP_DEPS, SOURCE_MIRROR, and the cache layout.">
<link rel="stylesheet" href="assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="index.html">home</a> / <a href="docs.html">docs</a> / kama configuration</p>
<h1>Kama configuration</h1>
<p>Every knob, every default, every path.</p>
</header>
<section>
<div class="wrap">
<div class="prose">
<p>Kama's configuration is environment variables. Nothing to edit inside the script, nothing hidden — set them in the environment (<code>export</code> in a profile, or inline on the command line) and it's done.</p>
<h3>Variables</h3>
<table>
<tr><th>Variable</th><th>Default</th><th>What it controls</th></tr>
<tr><td><code>PKGDIR</code></td><td>the kama-packages repo, sibling of the kama script</td><td>Where recipes are found.</td></tr>
<tr><td><code>ROOT</code></td><td><code>/tmp/keru/root</code></td><td>Where installed files land.</td></tr>
<tr><td><code>CACHEDIR</code></td><td><code>/var/cache/kama</code></td><td>Base for the dirty working dirs.</td></tr>
<tr><td><code>MAKE_CONF</code></td><td><code>/etc/kama/make.conf</code></td><td>Profile settings (JOBS, CFLAGS, etc.) if present.</td></tr>
<tr><td><code>SOURCE_MIRROR</code></td><td>unset</td><td>Mirror tried before upstream (set to e.g. <code>mirror.example.org</code>).</td></tr>
<tr><td><code>PURGE_TEMP_DEPS</code></td><td><code>1</code></td><td>Purge temp build deps after <code>kama make</code>.</td></tr>
<tr><td><code>JOBS</code></td><td><code>nproc</code></td><td>Parallel build jobs; recipes call <code>make -j"$JOBS"</code>.</td></tr>
</table>
<h3>Cache layout</h3>
<div class="code-block">$CACHEDIR/
├── dl/ downloaded archives
├── src/ extracted source per package
└── stage/ staged installs, committed to $ROOT on success</div>
<h3>Common setups</h3>
<div class="code-block"># build into a scratch root
ROOT=/mnt/keru-root kama make busybox
# migrate cache to a big disk
export CACHEDIR=/mnt/cache/kama
export SOURCE_MIRROR=https://mirror.example.org
# keep temp deps this run (default removes them)
PURGE_TEMP_DEPS=0 kama make firefox</div>
<h3>make.conf integration</h3>
<p>Inside an installed Keru system, the profile at <code>MAKE_CONF</code> feeds the same variables into kama and the build scripts. Your <a href="make-conf.html">make.conf reference</a> lists the full set.</p>
<ul class="features">
<li>If <code>MAKE_CONF</code> exists it is sourced; missing is not an error.</li>
<li>The installer writes <code>JOBS</code> and <code>CFLAGS</code> from build-host detection.</li>
<li>Every variable has a sane default, so kama runs with zero config.</li>
</ul>
<div class="callout">Zero-config by default, fully pointed overrides when you need them. That's the whole story — read on for <a href="recipe-format.html">recipes</a>.</div>
<p><a href="kama-usage.html">← kama usage</a> · <a href="make-conf.html">make.conf</a></p>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">See the <a href="sitemap.html">sitemap</a> for all pages.</div></noscript>
<script src="assets/js/include.js" data-base="."></script>
</body>
</html>
+80
View File
@@ -0,0 +1,80 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Kama recipes — Keru OS</title>
<meta name="description" content="How kama recipes work: plain shell scripts that define name, version, url, deps, and the build/install steps.">
<link rel="stylesheet" href="assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="index.html">home</a> / <a href="kama.html">kama</a> / recipes</p>
<h1>Kama recipes</h1>
<p>The package manager runs recipes. Here's what a recipe is.</p>
</header>
<section>
<div class="wrap">
<div class="prose">
<p>A Kama recipe is a <strong>plain shell script</strong>. It declares metadata and defines build steps. There is no DSL to learn beyond shell itself — which is the point. The recipe repository (<a href="kama-repos.html">kama-packages</a>) contains one file per package, and each one is readable top to bottom.</p>
<h3>Anatomy of a recipe</h3>
<div class="code-block">name=busybox
version=1.36.1
url="https://busybox.net/downloads/busybox-${version}.tar.bz2"
deps=( make )
build() {
cp ../config .config # basic setup from kama
make -j"$(nproc)"
}
install() {
make install CONFIG_PREFIX="$DESTDIR"
}</div>
<p>The key fields:</p>
<table>
<tr><th>Field</th><th>Meaning</th></tr>
<tr><td><code>name</code></td><td>Package name; used for the stage and cache paths.</td></tr>
<tr><td><code>version</code></td><td>The release version, typically embedded in the <code>url</code>.</td></tr>
<tr><td><code>url</code></td><td>Upstream source tarball (mirror-then-upstream on fetch).</td></tr>
<tr><td><code>deps</code></td><td>Array of build-time dependencies, built then purged.</td></tr>
<tr><td><code>build()</code></td><td>Runs in the extracted source dir — configure & compile.</td></tr>
<tr><td><code>install()</code></td><td>Installs into the package's stage dir (<code>DESTDIR</code>).</td></tr>
</table>
<h3>Two tiers</h3>
<p>Recipes can stay deliberately simple or take full control:</p>
<ul class="features">
<li><strong>Easy tier</strong> — the <code>build()</code> / <code>install()</code> sugar above. Great for "configure, make, make install" packages.</li>
<li><strong>Advanced tier</strong> — <code>pkg_build()</code>, <code>pkg_install()</code>, custom <code>pkg_fetch()</code>, and a <code>pkg_post()</code> hook. For packages that need a hand.</li>
</ul>
<p>Kama maps the easy tier onto the advanced one when the advanced forms aren't defined, so simple recipes stay simple and complex ones stay powerful.</p>
<h3>The staging model</h3>
<p>Building installs into a per-package stage dir, not the live root. That's how kama can assemble a complete system in <code>$ROOT</code> — the installer's whole trick — without ever touching the tree being built. The install step copies the staged dir into <code>$ROOT</code>.</p>
<h3>How it's found</h3>
<p>Kama locates a recipe by trying <code>PKGDIR/&lt;pkg&gt;/PKGBUILD</code>, then <code>PKGDIR/&lt;pkg&gt;.sh</code>, then <code>PKGDIR/&lt;pkg&gt;/*.sh</code>. Naming a recipe file <code>&lt;pkg&gt;.sh</code> is the common case.</p>
<div class="callout">A recipe is a contract you can read. No opaque package format, no hidden build logic — if you can read shell, you can audit every package in the repository.</div>
<p><a href="recipe-format.html">The formal recipe format spec</a> · <a href="kama.html">← Kama overview</a></p>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">See the <a href="sitemap.html">sitemap</a> for all pages.</div></noscript>
<script src="assets/js/include.js" data-base="."></script>
</body>
</html>
+70
View File
@@ -0,0 +1,70 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Kama repos — Keru OS</title>
<meta name="description" content="The kama repo split: the package manager (kama) and the recipe repository (kama-packages).">
<link rel="stylesheet" href="assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="index.html">home</a> / <a href="kama.html">kama</a> / repos</p>
<h1>The repo split</h1>
<p>Three small pieces, each with one job.</p>
</header>
<section>
<div class="wrap">
<div class="prose">
<p>Keru splits its world into three repositories so each stays small and legible. The package side of that is:</p>
<table>
<tr><th>Repo</th><th>Holds</th><th>Keeps</th></tr>
<tr><td><strong>kama</strong></td><td>The manager — the <code>kama</code> entry point and <code>lib/kama.sh</code> core.</td><td>The code.</td></tr>
<tr><td><strong>kama-packages</strong></td><td>The recipe repository — one <code>.sh</code> per package.</td><td>The knowledge.</td></tr>
<tr><td><strong>KeruOS</strong></td><td>The OS: installer, profile, build pipeline, live init, website.</td><td>The orchestration.</td></tr>
</table>
<h3>Where the repos live</h3>
<div class="code-block">github.com/AstralZX/kama # the manager
github.com/AstralZX/kama-packages # the recipe repository
github.com/AstralZX/KeruOS # the OS itself</div>
<p>Today the repos are <strong>GitHub-only</strong> — that's the single canonical source for package recipes and code. Mirrors on Codeberg and on <code>git.spectoria.dev</code> are planned, but nothing is hosted there yet, and there are no other mirrors. Until that changes, GitHub is the source of truth.</p>
<div class="callout">No package recipes ship on the ISO, in the installer, or anywhere else. The recipe repository on GitHub is how you get packages — clone it or install Keru, which fetches it at build time.</div>
<h3>Why separate</h3>
<ul class="features">
<li><strong>Independent cadence.</strong> The manager changes rarely; recipes change constantly. Mixing them couples an ossified core to churn.</li>
<li><strong>Clear ownership.</strong> "Which file builds busybox?" — the recipe repo. "How does kama decide to stage?" — the manager repo. No guessing where things live.</li>
<li><strong>Small repos, legible diffs.</strong> A PR adding a package touches exactly one file in one repo.</li>
<li><strong>Cross-repo defaults.</strong> Keru's scripts expect the three repos as siblings (<code>kama</code> next to <code>kama-packages</code> next to <code>KeruOS</code>), and every path is overridable via <code>KAMA_DIR</code> / <code>PKGS_DIR</code>.</li>
</ul>
<h3>How they fit together</h3>
<div class="code-block"># KeruOS build-root.sh drives kama against kama-packages
KAMA="$KAMA_DIR/kama" # the manager
PKGDIR="$PKGS_DIR" "$KAMA" make "$pkg" # a recipe, executed
# into $ROOT — a completed system, built from source.</div>
<p>The installer is the conductor: it writes your <code>make.conf</code>, then calls the build pipeline, which runs kama over recipes to produce exactly the system you chose.</p>
<div class="callout">This is Keru's answer to packaging sprawl: three tiny repos, each human-sized, instead of one monolith that swallowed everything.</div>
<p><a href="kama.html">← Kama overview</a> · <a href="build-pipeline.html">The build pipeline</a></p>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">See the <a href="sitemap.html">sitemap</a> for all pages.</div></noscript>
<script src="assets/js/include.js" data-base="."></script>
</body>
</html>
+79
View File
@@ -0,0 +1,79 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Kama usage — Keru OS</title>
<meta name="description" content="The kama commands: fetch, build, install, make, purge, info — and how the dependency flow works.">
<link rel="stylesheet" href="assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="index.html">home</a> / <a href="kama.html">kama</a> / usage</p>
<h1>Kama usage</h1>
<p>The whole command surface, in one place.</p>
</header>
<section>
<div class="wrap">
<div class="prose">
<p>Kama's commands are few on purpose. Here's the complete set:</p>
<table>
<tr><th>Command</th><th>What it does</th></tr>
<tr><td><code>kama fetch &lt;pkg&gt;</code></td><td>Download and extract source for a package into the cache.</td></tr>
<tr><td><code>kama build &lt;pkg&gt;</code></td><td>Stage-build one package (configure/make) into its stage dir.</td></tr>
<tr><td><code>kama install &lt;pkg&gt;</code></td><td>Build + install a package into <code>$ROOT</code> (staging-aware).</td></tr>
<tr><td><code>kama make &lt;pkg&gt;</code></td><td>High-level: fetch deps, build, install, then purge temp deps.</td></tr>
<tr><td><code>kama purge [pkg ...]</code></td><td>Remove temp build-time deps after a successful install.</td></tr>
<tr><td><code>kama info &lt;pkg&gt;</code></td><td>Show a recipe's metadata (name, version, url, deps).</td></tr>
<tr><td><code>kama help</code></td><td>Print the command reference.</td></tr>
</table>
<h3>Making a package, end to end</h3>
<p><code>kama make</code> is the command that ties it together. For a package with dependencies it walks through:</p>
<div class="terminal">
<div class="tbar"><span class="dot r"></span><span class="dot y"></span><span class="dot g"></span><span class="t">$ kama make firefox</span></div>
<pre><span class="c">[ kama ]</span> building temp deps for firefox: <span class="k">rust gtk3</span>
<span class="p"> ... fetch, build, install each temp dep ...</span>
<span class="c">[ kama ]</span> building firefox
<span class="p"> ... stage build + install into $ROOT ...</span>
<span class="c">[ kama ]</span> purging temp deps for firefox: <span class="k">rust gtk3</span></pre>
</div>
<h3>Environment & config</h3>
<p>Kama reads a few things to know where to work:</p>
<table>
<tr><th>Variable</th><th>Default</th></tr>
<tr><td><code>PKGDIR</code></td><td>The recipe repo (kama-packages, sibling by default).</td></tr>
<tr><td><code>MAKE_CONF</code></td><td><code>/etc/kama/make.conf</code> — profile settings, if present.</td></tr>
<tr><td><code>ROOT</code></td><td><code>/tmp/keru/root</code> — where installed files go.</td></tr>
<tr><td><code>CACHEDIR</code></td><td><code>/var/cache/kama</code> — source, download, and stage dirs.</td></tr>
<tr><td><code>PURGE_TEMP_DEPS</code></td><td><code>1</code> — whether temp deps are purged after building.</td></tr>
</table>
<h3>Fetch details</h3>
<ul class="features">
<li><strong>Mirror first.</strong> Downloads try <code>SOURCE_MIRROR</code> before upstream, so a mirror you run can carry the load.</li>
<li><strong>Cached.</strong> Already-downloaded source is reused; already-extracted source isn't re-extracted.</li>
<li><strong>Auto-extract.</strong> Tar (gz/xz/bz2/plain) and zip are handled automatically by extension.</li>
</ul>
<div class="callout">Kama's surface stays tiny because the complexity lives in recipes, not the manager. Read <a href="kama-recipes.html">how recipes work</a> next.</div>
<p><a href="kama.html">← Kama overview</a></p>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">See the <a href="sitemap.html">sitemap</a> for all pages.</div></noscript>
<script src="assets/js/include.js" data-base="."></script>
</body>
</html>
+59
View File
@@ -0,0 +1,59 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Kama — Keru OS package manager</title>
<meta name="description" content="Kama (窯, kiln) is Keru's package manager: a ~225-line shell script that builds every package from source by executing recipes.">
<link rel="stylesheet" href="assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="index.html">home</a> / kama</p>
<h1>Kama — the kiln</h1>
<p>Keru's package manager, deliberately small.</p>
<span class="tag">窯</span>
</header>
<section>
<div class="wrap">
<div class="prose">
<p><strong>Kama</strong> (窯, "kiln") is Keru's package manager. It's a pure-shell script of roughly 225 lines that builds every package from source by running the commands in a <a href="kama-recipes.html">recipe</a>. It holds no opinions — matching the distro that ships it. It reads a <code>make.conf</code>, runs recipe commands, and gets out of the way.</p>
</div>
<div class="grid grid-3" style="margin-top:30px">
<div class="card"><span class="num">no db</span><span class="h">No package database</span><p>Kama doesn't track installed files in a manifest db. It stages, installs, and moves on.</p></div>
<div class="card"><span class="num">no resolver</span><span class="h">No dependency resolver</span><p>Dependencies come from the recipe's <code>deps[]</code> array — explicit, not discovered.</p></div>
<div class="card"><span class="num">shell</span><span class="h">Pure shell</span><p>The whole manager is a script. Legible end to end; every decision is something you can read.</p></div>
<div class="card"><span class="num">stage</span><span class="h">Staging installs</span><p>Builds into a per-package stage dir, then copies into <code>$ROOT</code> — never smears the live tree.</p></div>
<div class="card"><span class="num">tmp deps</span><span class="h">Ephemeral build deps</span><p>Build-time-only dependencies are fetched, built, installed, and purged after use — they never accumulate.</p></div>
<div class="card"><span class="num">$ROOT</span><span class="h">Builds anywhere</span><p>Targets <code>$ROOT</code>, so it can assemble a full system in a staging root — exactly what the installer needs.</p></div>
</div>
<div class="prose" style="margin-top:34px">
<h3>The philosophy in the manager</h3>
<p>Kama embodies Keru's central bet: <em>package managers became more complex than the packages they manage.</em> A resolver, a database, a binary format, a compiled daemon — none of that is needed to honestly manage a source-built system. What's needed is a script that faithfully runs what a recipe says, so the user can read any decision it makes.</p>
<blockquote>"A package manager doesn't need a resolver to be honest. It needs to be legible — you can read every decision it makes, because every decision is a script or a line in make.conf you can see and change."</blockquote>
<h3>Where it lives</h3>
<p>Kama lives in its own repo, <a href="kama-repos.html">alongside the recipe repository</a> — two small pieces that Keru's installer drives together.</p>
<div class="callout">Kama is the thing that makes "from scratch" real. It's the kiln that fires your system from the ingredients you pick.</div>
<p><a href="kama-usage.html">How to use Kama</a> · <a href="kama-recipes.html">How recipes work</a> · <a href="kama-repos.html">The repo split</a></p>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">See the <a href="sitemap.html">sitemap</a> for all pages.</div></noscript>
<script src="assets/js/include.js" data-base="."></script>
</body>
</html>
+55
View File
@@ -0,0 +1,55 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Kernels — Keru OS</title>
<meta name="description" content="Choose your kernel with Keru: linux, linux-lts, linux-hardened, linux-cachyos, linux-zen.">
<link rel="stylesheet" href="assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="index.html">home</a> / <a href="swappables.html">swappables</a> / kernels</p>
<h1>Kernels</h1>
<p>The spine of your machine.</p>
</header>
<section>
<div class="wrap">
<div class="prose">
<p>Keru is a Linux distribution — but "Linux" is a family, and the kernel is genuinely a choice: freshness vs stability, hardening vs performance, general-purpose vs tuned. Keru ships the choice, not the verdict.</p>
</div>
<div class="grid grid-3" style="margin-top:30px">
<div class="card"><span class="h">linux</span><p>The default. Stock mainline — the broad, well-trodden baseline that matches the ecosystem.</p></div>
<div class="card"><span class="h">linux-lts</span><p>The long-term-supported line. Slower-moving, security-patched, built for stability and long installs.</p></div>
<div class="card"><span class="h">linux-hardened</span><p>Hardening patches on top of the kernel — hardened allocator, stronger exploit mitigations.</p></div>
<div class="card"><span class="h">linux-cachyos</span><p>A performance-tuned kernel with scheduler and allocator tweaks; built for responsiveness.</p></div>
<div class="card"><span class="h">linux-zen</span><p>Community kernel focused on desktop and multimedia performance — faster, more adventurous.</p></div>
</div>
<div class="prose" style="margin-top:34px">
<h3>A choice, within a family</h3>
<p>To be clear about the scope: the freedom here is <em>within</em> Linux — which Linux kernel, not whether to leave the family. Keru composes everything above the kernel however you like; the kernel itself has a well-tested set of variants to pick from. <a href="anti-opinionated.html">More on what Keru's freedom does and doesn't cover.</a></p>
<h3>Baked in, not bolted on</h3>
<p>Stage 2 of the build compiles the exact kernel you chose and wires your init to boot it. The kernel, the init, and everything else is one coherent profile — nothing prebaked, nothing to fight.</p>
<div class="callout">linux-lts for "set it and forget it," linux for the mainstream, hardened/zen/cachyos for the tradeoffs you actually want. Your call.</div>
<p><a href="swappables.html">← All swappables</a></p>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">See the <a href="sitemap.html">sitemap</a> for all pages.</div></noscript>
<script src="assets/js/include.js" data-base="."></script>
</body>
</html>
+53
View File
@@ -0,0 +1,53 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>C libraries — Keru OS</title>
<meta name="description" content="Choose your C library with Keru: glibc, musl, or uclibc-ng. The foundation under your whole system.">
<link rel="stylesheet" href="assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="index.html">home</a> / <a href="swappables.html">swappables</a> / libcs</p>
<h1>C libraries</h1>
<p>The foundation under everything that runs.</p>
</header>
<section>
<div class="wrap">
<div class="prose">
<p>Every C program on your system links against a C library. It's the floor under userspace: <code>malloc</code>, <code>printf</code>, thread primitives, the syscall wrappers, all of it. Keru lets you choose which floor the rest of your system stands on.</p>
</div>
<div class="grid grid-3" style="margin-top:30px">
<div class="card"><span class="h">glibc</span><p>The default, and the most compatible. Maximal feature set, broadest software support, the ecosystem baseline.</p></div>
<div class="card"><span class="h">musl</span><p>Small, fast, clean implementation. MIT-licensed, statically-friendly, famous for strict correctness and small binaries.</p></div>
<div class="card"><span class="h">uclibc-ng</span><p>The maintained fork of uClibc — designed for embedded and minimal systems, tiny footprint, configurable.</p></div>
</div>
<div class="prose" style="margin-top:34px">
<h3>Why this is a choice</h3>
<p>Binary distributions can't really offer this — a prebuilt package set is glued to one libc. A source-only distribution can, because it compiles everything against whatever you picked. Keru carries that through: your chosen libc is bootstrapped first (in the toolchain stage), and every package is built against it.</p>
<h3>Stability notes</h3>
<p>musl and uclibc-ng are early-0.1 territory. The installer's stability check currently flags <code>uclibc-ng</code> combinations as not-yet-proven, and <code>musl + systemd</code> as a known-hard pairing. Warnings — never blocks. <a href="stability.html">The stance.</a></p>
<div class="callout">glibc is the default for a reason: it's the widest path. But "the path everyone takes" is an argument, not a law — and in Keru, you make the call.</div>
<p><a href="swappables.html">← All swappables</a></p>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">See the <a href="sitemap.html">sitemap</a> for all pages.</div></noscript>
<script src="assets/js/include.js" data-base="."></script>
</body>
</html>
+51
View File
@@ -0,0 +1,51 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>License — Keru OS</title>
<meta name="description" content="Keru OS, kama, and kama-packages are licensed under AGPL-3.0.">
<link rel="stylesheet" href="assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="index.html">home</a> / license</p>
<h1>License</h1>
<p>AGPL-3.0, across all three repositories.</p>
</header>
<section>
<div class="wrap">
<div class="prose">
<p>Keru OS, <a href="kama.html">kama</a>, and <a href="kama-repos.html">kama-packages</a> are licensed under the <strong>GNU Affero General Public License v3.0</strong> (AGPL-3.0). The full license text ships as <code>LICENSE</code> in each repository.</p>
<h3>What that means, briefly</h3>
<ul class="features">
<li><strong>Freedom to use.</strong> Build, install, and run Keru on anything you like.</li>
<li><strong>Freedom to study and modify.</strong> Source is available everywhere; it always has been — that's Keru's whole point.</li>
<li><strong>Freedom to share.</strong> Redistribute copies (modified or not) under the same license.</li>
<li><strong>Network use counts.</strong> If you modify Keru's software and offer it to users over a network, the AGPL requires you to offer the modified source — the "Affero" addition.</li>
</ul>
<h3>Derivative distributions welcome</h3>
<p>Keru deliberately doesn't forbid forking or remixing. If another distribution wants to build on Keru — take the installer, the pipeline, the philosophy — it's welcome, under the AGPL. That's consistent with the ethos: the pieces are yours to assemble.</p>
<h3>About this website</h3>
<p>This site lives in <code>web/</code> in the KeruOS repository, and is covered by the same AGPL-3.0. The design, copy, and markup are free to reuse under it.</p>
<div class="callout">License texts live in each repo root. The canonical document is the file, not this page.</div>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">See the <a href="sitemap.html">sitemap</a> for all pages.</div></noscript>
<script src="assets/js/include.js" data-base="."></script>
</body>
</html>
+62
View File
@@ -0,0 +1,62 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Links — Keru OS</title>
<meta name="description" content="Every repository and related resource for Keru OS.">
<link rel="stylesheet" href="assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="index.html">home</a> / <a href="community.html">community</a> / links</p>
<h1>Links</h1>
<p>Everything, in one place.</p>
</header>
<section>
<div class="wrap">
<div class="grid grid-2">
<a class="card" href="https://github.com/AstralZX/KeruOS">
<span class="num">repo</span><span class="h">KeruOS</span>
<p>The operating system — installer, profile, build pipeline, live init, and this website.</p>
</a>
<a class="card" href="https://github.com/AstralZX/kama">
<span class="num">repo</span><span class="h">kama</span>
<p>The package manager — a ~225-line shell script. The kiln.</p>
</a>
<a class="card" href="https://github.com/AstralZX/kama-packages">
<span class="num">repo</span><span class="h">kama-packages</span>
<p>The recipe repository — one shell file per package.</p>
</a>
<a class="card" href="https://github.com/AstralZX">
<span class="num">org</span><span class="h">AstralZX</span>
<p>The GitHub account behind the project, and whatever else ships under it.</p>
</a>
</div>
<div class="prose" style="margin-top:40px">
<h3>Related reading</h3>
<ul class="features">
<li><a href="philosophy.html">The philosophy</a> — the full argument for Keru's stance.</li>
<li><a href="anti-opinionated.html">Anti-opinionated</a> — what the stance grants, what it costs, and its limits (it's not a meta-OS).</li>
<li><a href="stability.html">Stability, honestly scoped</a> — the warn-not-block promise.</li>
<li><a href="news.html">News</a> — announcements and the road to 0.1.</li>
</ul>
<div class="callout">All code is AGPL-3.0. This site's source lives in <code>web/</code> inside the KeruOS repo — clone, read, improve.</div>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">See the <a href="sitemap.html">sitemap</a> for all pages.</div></noscript>
<script src="assets/js/include.js" data-base="."></script>
</body>
</html>
+65
View File
@@ -0,0 +1,65 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Live init — Keru OS docs</title>
<meta name="description" content="The live/init reference: how booting the Keru ISO auto-starts the installer.">
<link rel="stylesheet" href="assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="index.html">home</a> / <a href="docs.html">docs</a> / live init</p>
<h1>Live init</h1>
<p>Boot the ISO, and the installer starts itself.</p>
</header>
<section>
<div class="wrap">
<div class="prose">
<p><code>live/init</code> is the init for the Keru live ISO. Its entire job is to get you into the installer as fast as possible — no shell prompt, no manual steps between boot and "craft your system."</p>
<h3>What it does, in order</h3>
<ol>
<li><strong>Sets up the console.</strong> Redirects to <code>$CONSOLE</code> (<code>/dev/tty1</code> by default) so installer messages land where you can see them.</li>
<li><strong>Mounts virtual filesystems.</strong> <code>/proc</code>, <code>/sys</code>, <code>/dev</code> (devtmpfs, with tmpfs fallback), <code>/dev/pts</code>, <code>/dev/shm</code> — the essentials the installer needs.</li>
<li><strong>Locates the installer root.</strong> Uses the kernel's <code>root=</code> if given, or looks for a <code>KERU*</code>-labeled device to find the read-only squashfs payload; otherwise assumes the installer is on the current root.</li>
<li><strong>Execs the installer.</strong> <code>exec sh installer/install.sh</code> — the TUI starts immediately.</li>
<li><strong>Emergency shell fallback.</strong> If the installer exited or isn't found, you get an interactive rescue shell instead of a hang.</li>
</ol>
<div class="terminal">
<div class="tbar"><span class="dot r"></span><span class="dot y"></span><span class="dot g"></span><span class="t">live/init</span></div>
<pre>[ keru ] booting installer...
<span class="c">[ keru ] Keru OS — craft your system</span>
== Init system == [runit]
== C library == [glibc]
== Filesystem == [ext4]
<span class="p"># and you're choosing — the installer opened itself.</span></pre>
</div>
<h3>Design notes</h3>
<ul class="features">
<li><strong>Ultra-minimal.</strong> The live env is busybox + the installer. No init system in the live env — this script <em>is</em> the init.</li>
<li><strong>Never strand you.</strong> The emergency shell is deliberate: "installer not found or exited" should never be a dead end.</li>
<li><strong>Console-aware.</strong> It listens to the <code>console=</code> kernel param so serial consoles work too.</li>
</ul>
<div class="callout">This is the "boot → choose → it builds" promise made real: the ISO carries the installer, and live/init hands it straight to you.</div>
<p><a href="installer-walkthrough.html">What happens after it starts</a> · <a href="docs.html">← Docs</a></p>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">See the <a href="sitemap.html">sitemap</a> for all pages.</div></noscript>
<script src="assets/js/include.js" data-base="."></script>
</body>
</html>
+97
View File
@@ -0,0 +1,97 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>make.conf reference — Keru OS</title>
<meta name="description" content="The make.conf reference: the single source of truth for a Keru build, written by the installer and read by Kama.">
<link rel="stylesheet" href="assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="index.html">home</a> / <a href="docs.html">docs</a> / make.conf</p>
<h1>make.conf</h1>
<p>The single source of truth for a build.</p>
</header>
<section>
<div class="wrap">
<div class="prose">
<p><code>make.conf</code> is the file the installer writes and Kama reads. Every swappable choice in Keru lives here — it's the record of your crafted system, and hand-tuning it then rebuilding is fully supported.</p>
<h3>Profile — the swappables</h3>
<div class="code-block"># Which init system gets installed
INIT=runit
# Which libc the toolchain and packages build against
LIBC=glibc
# Which filesystem the target root is formatted as
TARGET_FS=ext4
# Which kernel you want built
KERNEL=linux
# Which privilege-elevation tool gets installed
SUDO=doas
# Base package set pulled into every install
BASE_PACKAGES=(base toolchain openssh)
# Locale / clock / keymap applied to the target
LOCALE=en_US.UTF-8
TIMEZONE=UTC
KEYMAP=us</div>
<h3>Build environment</h3>
<div class="code-block"># Compiler / linker flags passed to every recipe build
CFLAGS="-O2 -march=x86-64"
CXXFLAGS="$CFLAGS"
LDFLAGS="-s"
# Parallelism
JOBS=$(nproc)
MAKEFLAGS="-j$JOBS"
# Mirror for source tarballs (unset: fetch straight from upstream)
# SOURCE_MIRROR="https://mirror.example.org/sources"
# Where the new target root lives on the build host
ROOT=/tmp/keru/root
# Persistent source + build cache (survives across installs)
CACHEDIR=/var/cache/kama</div>
<h3>Kama behaviour</h3>
<div class="code-block"># Remove temp build-time deps after use (AUR-style). Set to 0 to keep them.
PURGE_TEMP_DEPS=1
# Stop on first recipe failure
FAIL_FAST=1</div>
<h3>Why it's "the source of truth"</h3>
<ul class="features">
<li><strong>The installer writes it</strong> from your choices — every menu pick lands as a line here.</li>
<li><strong>Kama reads it</strong> to know flags, mirrors, cache, and where to install into.</li>
<li><strong>It's human-editable.</strong> The TUI is a convenience, not a gate. Edit, rebuild, repeat.</li>
<li><strong>It's reproducible.</strong> The same make.conf should build the same system.</li>
</ul>
<div class="callout">The canonical template lives in <code>profile/make.conf</code> at the repo root — the copy above mirrors it, but the repository file is the source of truth.</div>
<p><a href="profile.html">The profile system</a> · <a href="docs.html">← Docs</a></p>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">See the <a href="sitemap.html">sitemap</a> for all pages.</div></noscript>
<script src="assets/js/include.js" data-base="."></script>
</body>
</html>
+73
View File
@@ -0,0 +1,73 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Mirrors and cache — Keru OS</title>
<meta name="description" content="How Keru and Kama download source tarballs: an optional mirror you run, upstream as fallback, and the download/source/stage cache layout.">
<link rel="stylesheet" href="assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="index.html">home</a> / <a href="docs.html">docs</a> / mirrors &amp; cache</p>
<h1>Mirrors and cache</h1>
<p>Where source comes from, and where it waits.</p>
</header>
<section>
<div class="wrap">
<div class="prose">
<p>Every Keru build is a network operation. Package recipes always come from the GitHub-hosted <a href="kama-repos.html">kama-packages</a> repo; this page is about the other half — the <em>source tarballs</em> each recipe downloads, and the cache they pass through.</p>
<h3>Download order</h3>
<ul class="features">
<li><strong>1. <code>SOURCE_MIRROR</code></strong> — tried first when set; run a mirror of source tarballs and point it here.</li>
<li><strong>2. Upstream</strong> — the canonical source URL from the recipe. Used when no mirror is set or the mirror lacks a file.</li>
<li><strong>Verification at every step.</strong> A file that doesn't match its checksum is dropped, and the next source in line is tried. Tampered files never reach a build.</li>
</ul>
<h3>The cache layout</h3>
<div class="code-block">/var/cache/kama/ # CACHEDIR (set CACHEDIR=/path to relocate)
├── dl/ # downloaded tarballs, one per package
├── src/ # extracted source (per package dir)
└── stage/ # staged installs before they commit to $ROOT</div>
<table>
<tr><th>Dir</th><th>Everything</th><th>Purpose</th></tr>
<tr><td><code>dl</code></td><td>Downloads</td><td>Already-downloaded archives are reused, never re-fetched.</td></tr>
<tr><td><code>src</code></td><td>Extracted</td><td>Extraction is skipped when the checked-out source is present.</td></tr>
<tr><td><code>stage</code></td><td>Staged builds</td><td>Progress survives a failed build; re-running continues.</td></tr>
</table>
<h3>Working offline, or your own mirror</h3>
<div class="code-block"># warm the cache once, then build with the network down
SOURCE_MIRROR=https://mirror.example.org kama fetch busybox
...
CACHEDIR=/var/cache/kama kama make busybox # no network needed</div>
<p>Run a mirror yourself and point <code>SOURCE_MIRROR</code> at it. The layout mirrors <code>dl/</code>; the fetch layer treats it as a read-mostly source of truth.</p>
<h3>Cleanup</h3>
<ul class="features">
<li><code>rm -rf /var/cache/kama/src/*</code> — free extracted source (re-extracts on next build).</li>
<li><code>rm -rf /var/cache/kama/dl/*</code> — dump downloads (re-fetches next time).</li>
<li><code>rm -rf /var/cache/kama/stage/*</code> — discard staged builds.</li>
</ul>
<div class="callout">A corrupt cache is the #1 source of confusing fetch errors. When in doubt, clear the relevant dir — downloads verify anyway, so you lose nothing but time.</div>
<p><a href="kama-usage.html">← kama usage</a> · <a href="troubleshooting.html">Troubleshooting</a></p>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">See the <a href="sitemap.html">sitemap</a> for all pages.</div></noscript>
<script src="assets/js/include.js" data-base="."></script>
</body>
</html>
+49
View File
@@ -0,0 +1,49 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>mkfs-root — Keru OS docs</title>
<meta name="description" content="The mkfs-root.sh reference: formatting and assembling the target root as your chosen filesystem.">
<link rel="stylesheet" href="assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="index.html">home</a> / <a href="docs.html">docs</a> / build-pipeline / mkfs-root</p>
<h1>mkfs-root.sh</h1>
<p>Finalizing the root as the filesystem you chose.</p>
</header>
<section>
<div class="wrap">
<div class="prose">
<p><code>scripts/mkfs-root.sh</code> is the final stage of the build pipeline. Given your chosen <code>TARGET_FS</code>, it formats and assembles <code>$ROOT</code> so the disk reflects exactly the filesystem you selected at install.</p>
<h3>What it does</h3>
<ul class="features">
<li><strong>Formats.</strong> Creates the filesystem image with the matching mkfs tool (ext4, btrfs, xfs, zfs, f2fs, jfs, reiserfs, swap, or the ext2/ext3 lineage).</li>
<li><strong>Populates.</strong> Copies the built rootfs into the formatted volume.</li>
<li><strong>Wiring.</strong> Ensures fstab and boot records match your selections.</li>
</ul>
<h3>Honest flags</h3>
<p>The filesystem tooling is built in stage 2 from your choice — if you picked zfs, you get ZFS tools; if reiserfs, you get its (unmaintained) tooling, after a stability warning. Whatever you choose, the tooling and the format match.</p>
<div class="callout">The result of <code>stage 3</code> is a rootfs that will boot — with the exact filesystem, kernel, init, and tools you picked. That's the whole pipeline in one line.</div>
<p><a href="build-pipeline.html">← Build pipeline</a></p>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">See the <a href="sitemap.html">sitemap</a> for all pages.</div></noscript>
<script src="assets/js/include.js" data-base="."></script>
</body>
</html>
+65
View File
@@ -0,0 +1,65 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Network setup — Keru OS</title>
<meta name="description" content="How the Keru installer handles networking: the connectivity gate, nmtui, and the re-check loop.">
<link rel="stylesheet" href="assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="index.html">home</a> / <a href="install.html">install</a> / network setup</p>
<h1>Network setup</h1>
<p>Connectivity is a hard requirement. The installer makes connecting easy.</p>
</header>
<section>
<div class="wrap">
<div class="prose">
<h3>Why networking is mandatory</h3>
<p>The ISO carries <em>only</em> the installer — there's no prebuilt base image on the disk. Your entire system (toolchain, kernel, init, libc, filesystem tooling, tools) is fetched from the network and compiled during installation. So the installer treats a connection as a hard gate: no network, no install. It won't pretend otherwise.</p>
<h3>The flow, exactly</h3>
<ol>
<li><strong>Probe.</strong> The installer checks connectivity against several hosts (<code>1.1.1.1</code>, <code>github.com</code>) using <code>ping</code>, falling back to a TCP connect via <code>nc</code> if needed.</li>
<li><strong>If connected:</strong> a simple <code>[ keru ] network: connected</code> and it moves straight to crafting your system.</li>
<li><strong>If not connected:</strong> you're told, and asked — <code>Connect to the network now (runs nmtui)? [Y/n]</code>.</li>
<li><strong>Say yes:</strong> <code>nmtui</code> opens. Connect to your network, press okay.</li>
<li><strong>Saying no:</strong> the installer exits with <code>a network connection is required to install Keru</code>.</li>
<li><strong>Re-check.</strong> After <code>nmtui</code> closes, connectivity is probed again. If you're online, you continue. If not, it asks again — it never fakes success.</li>
</ol>
<div class="terminal">
<div class="tbar"><span class="dot r"></span><span class="dot y"></span><span class="dot g"></span><span class="t">keru@live:~$</span></div>
<pre>[ keru ] warning: network: not connected
Connect to the network now (runs nmtui)? [Y/n] <span class="k">y</span>
<span class="p">(nmtui opens — pick your network, connect, press ok)</span>
[ keru ] network: connected</pre>
</div>
<h3>Details that matter</h3>
<ul class="features">
<li><strong>Wired is the path of least resistance.</strong> A physical Ethernet connection with DHCP typically just works — the probe succeeds and you skip straight to choosing.</li>
<li><strong>Wireless goes through nmtui.</strong> The NetworkManager TUI handles Wi-Fi selection, WPA credentials, and the rest. The installer doesn't guess; it hands you the tool.</li>
<li><strong>Loop, don't lie.</strong> If you run <code>nmtui</code> but never connect, the installer loops back to the prompt rather than proceeding on a "trust me, it worked" basis.</li>
</ul>
<div class="callout"><strong>What if nmtui isn't available?</strong> The live ISO ships with it, so this is an edge case — but if it's missing, the installer tells you plainly and lets you bring the network up yourself before continuing.</div>
<p><a href="installer-walkthrough.html">Walkthrough</a> · <a href="installation-requirements.html">Requirements</a></p>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">See the <a href="sitemap.html">sitemap</a> for all pages.</div></noscript>
<script src="assets/js/include.js" data-base="."></script>
</body>
</html>
+54
View File
@@ -0,0 +1,54 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Network tools — Keru OS</title>
<meta name="description" content="Choose your network management with Keru: networkmanager, connman, systemd-networkd, or nmtui alone.">
<link rel="stylesheet" href="assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="index.html">home</a> / <a href="swappables.html">swappables</a> / network tools</p>
<h1>Network tools</h1>
<p>How your network gets managed. Your call.</p>
</header>
<section>
<div class="wrap">
<div class="prose">
<p>The network stack has as many opinions attached as the init system. Keru applies the same rule: pick the manager you want, and it's built into your system — nothing wireless-by-default imposed, no "just use the standard one."</p>
</div>
<div class="grid grid-4" style="margin-top:30px">
<div class="card"><span class="h">nmtui</span><p>The default. Just NetworkManager's terminal user interface — connect wires and Wi-Fi without a full manager on your system.</p></div>
<div class="card"><span class="h">networkmanager</span><p>The full NetworkManager — daemon, D-Bus API, <code>nmcli</code>, handles wired, wireless, VPN, and more.</p></div>
<div class="card"><span class="h">connman</span><p>Intel's connection manager — light, D-Bus bus–independent, designed for embedded and minimal systems.</p></div>
<div class="card"><span class="h">systemd-networkd</span><p>systemd's network configuration daemon — declarative unit-based config, pairs with systemd/udev.</p></div>
</div>
<div class="prose" style="margin-top:34px">
<h3>Notes on the default</h3>
<p>The default is <code>nmtui</code> — the interface, not the daemon — which is the lean choice: you get the easy <code>nmtui</code> workflow during install without committing yourself to running NetworkManager's daemon afterward. If you want the full manager, it's one selection away.</p>
<h3>Coherence</h3>
<p>If you chose <code>systemd</code> as your init, <code>systemd-networkd</code> pairs naturally. If you're on runit or s6, a standalone manager (or just <code>nmtui</code>) fits the picture. The installer offers the pieces; you assemble them.</p>
<div class="callout">During install, network setup uses <code>nmtui</code> itself (the installer runs it when you need to connect) — independent of what you pick as your system's eventual network tool. <a href="network-setup.html">The install-time network flow.</a></div>
<p><a href="swappables.html">← All swappables</a></p>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">See the <a href="sitemap.html">sitemap</a> for all pages.</div></noscript>
<script src="assets/js/include.js" data-base="."></script>
</body>
</html>
+52
View File
@@ -0,0 +1,52 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>News — Keru OS</title>
<meta name="description" content="News from the Keru project: announcements, design notes, and the road to 0.1.">
<link rel="stylesheet" href="assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="index.html">home</a> / news</p>
<h1>News</h1>
<p>Progress, decisions, and the road to 0.1.</p>
</header>
<section>
<div class="post-list">
<a class="post-item" href="news/announcing-keru.html">
<h3>Introducing Keru OS</h3>
<div class="meta">2026-09-01 · announcement</div>
<p>An anti-opinionated, source-only Linux distribution where everything is swappable at install time.</p>
</a>
<a class="post-item" href="news/philosophy-is-architecture.html">
<h3>The philosophy is the architecture</h3>
<div class="meta">2026-09-01 · design</div>
<p>Why the "you choose everything" claim is structurally real, not a slogan.</p>
</a>
<a class="post-item" href="news/roadmap-0.1.html">
<h3>The road to 0.1</h3>
<div class="meta">2026-09-01 · roadmap</div>
<p>What has to exist before the first installable ISO ships — honest about the work.</p>
</a>
<a class="post-item" href="news/design-decisions.html">
<h3>Design decisions, so far</h3>
<div class="meta">2026-09-01 · design</div>
<p>The choices recorded so Keru didn't drift: shell manager, warn-not-block, sibling repos, installer-only ISO.</p>
</a>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">See the <a href="sitemap.html">sitemap</a> for all pages.</div></noscript>
<script src="assets/js/include.js" data-base="."></script>
</body>
</html>
+55
View File
@@ -0,0 +1,55 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Introducing Keru OS — Keru OS news</title>
<meta name="description" content="Announcing Keru OS: an independent, source-only, anti-opinionated Linux distribution.">
<link rel="stylesheet" href="../assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="../index.html">home</a> / <a href="../news.html">news</a> / announcing keru</p>
<h1>Introducing Keru OS</h1>
<p class="meta" style="font-family:var(--mono);color:var(--ink-dim);font-size:.85rem">2026-09-01 · announcement</p>
</header>
<section>
<div class="wrap">
<div class="prose">
<p>Keru (ける) is a Linux distribution built on a deliberately unusual premise: <strong>the distro holds no opinion about your system.</strong> Not a light opinion, not a sensible default disguised as neutrality — no position at all.</p>
<p>Most distributions are an answer to "who decides what your system is?" and the answer is usually "the maintainers, wisely." Keru's answer is different: <strong>you decide, at install time, and the distro builds exactly that.</strong></p>
<h3>What that means concretely</h3>
<ul class="features">
<li><strong>Init is a choice.</strong> runit, s6, openrc, systemd, busybox-init, sysvinit, dinit, shepherd — side by side, weightless.</li>
<li><strong>Your C library is a choice.</strong> glibc, musl, uclibc-ng.</li>
<li><strong>Your filesystem is a choice.</strong> ext4, btrfs, xfs, zfs, f2fs, jfs, reiserfs.</li>
<li><strong>Your kernel is a choice.</strong> linux, linux-lts, hardened, cachyos, zen.</li>
<li><strong>Even sudo is a choice.</strong> doas, sudo, opendoas, or su.</li>
</ul>
<p>And it's source-only. The whole system — toolchain included — is compiled from original source by Kama, a package manager that's a ~225-line shell script. There are no binary packages, no opaque machinery, no background assumptions.</p>
<h3>Why</h3>
<p>Because "you get s6 and XFS whether you like it or not" is a fine stance for a distro that wants an opinion — but it's a burden for anyone who wants a system that is <em>theirs</em>. Keru's only opinion is that you have to form one. After that, it builds exactly what you chose.</p>
<p>Read the <a href="../philosophy.html">full philosophy</a>, or follow <a href="../news.html">progress here</a>.</p>
<div class="callout">Everything is at an early stage. The first installable release, 0.1, will ship as a bootable ISO. Until then: the design is public, the repos are live, and the road is documented.</div>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">See the <a href="../sitemap.html">sitemap</a> for all pages.</div></noscript>
<script src="../assets/js/include.js" data-base=".."></script>
</body>
</html>
+58
View File
@@ -0,0 +1,58 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Design decisions, so far — Keru OS news</title>
<meta name="description" content="The recorded decisions that stop Keru from drifting: shell manager, warn-not-block stability, sibling repos, installer-only ISO.">
<link rel="stylesheet" href="../assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="../index.html">home</a> / <a href="../news.html">news</a> / design decisions</p>
<h1>Design decisions, so far</h1>
<p class="meta" style="font-family:var(--mono);color:var(--ink-dim);font-size:.85rem">2026-09-01 · design</p>
</header>
<section>
<div class="wrap">
<div class="prose">
<p>Keru is early enough that its choices are still choices, not habits — so we're recording the ones already made, and why. If a decision ever looks wrong, this is the record of what it was meant to do.</p>
<h3>1. The package manager is a shell script</h3>
<p>Kama (~225 lines, pure shell) reads <code>make.conf</code> and runs recipe commands. No resolver, no database, no binary format. Rationale: legibility over machinery. The real cost of a build is the compiler, not the manager, so the manager should be boringly simple.</p>
<h3>2. Stability is warn-not-block</h3>
<p>Keru guarantees stability on the combinations it offers, and warns (never stops) you past that. Rationale: stable-on-what's-offered keeps the promise honest, and never-lock-out keeps it faithful to the anti-opinionated ethos.</p>
<h3>3. Three sibling repos</h3>
<p>KeruOS, kama, kama-packages — separate, sibling by default, each human-sized. Rationale: independent cadence, legible diffs, clear ownership. Paths are overridable via <code>KAMA_DIR</code>/<code>PKGS_DIR</code>.</p>
<h3>4. The ISO carries only the installer</h3>
<p>No prebuilt base image on the disk. The entire system is fetched and compiled during install, with network as a hard gate. Rationale: this is what makes "everything is swappable" real rather than aspirational — power to choose comes from nothing being prebuilt.</p>
<h3>5. All ephemeral build deps (AUR-style)</h3>
<p>Build-time dependencies are compiled, installed, and purged after use (<code>PURGE_TEMP_DEPS=1</code>). Rationale: they never accumulate, so the final system reflects exactly what it needs to run — not what it needed to be built.</p>
<h3>6. The installer auto-starts on boot</h3>
<p>live/init execs install.sh directly; if it exits, an emergency shell catches you. Rationale: "boot → choose → build" should have zero friction, and a user should never be stranded.</p>
<h3>7. The website lives in the OS repo</h3>
<p>For now, the site ships inside KeruOS under <code>web/</code> — plain static HTML, dark, no framework. Rationale: keep it close to the code it documents and framework-free to match the ethos; it can split out when it earns its own repo.</p>
<div class="callout">None of these are dogma — they're recorded because they're decisions, and decisions are meant to be repeatable or revisitble. This page is where revisiting starts.</div>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">See the <a href="../sitemap.html">sitemap</a> for all pages.</div></noscript>
<script src="../assets/js/include.js" data-base=".."></script>
</body>
</html>
+53
View File
@@ -0,0 +1,53 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>The philosophy is the architecture — Keru OS news</title>
<meta name="description" content="Why Keru's 'you choose everything' claim is structural, not a slogan.">
<link rel="stylesheet" href="../assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="../index.html">home</a> / <a href="../news.html">news</a> / philosophy is the architecture</p>
<h1>The philosophy is the architecture</h1>
<p class="meta" style="font-family:var(--mono);color:var(--ink-dim);font-size:.85rem">2026-09-01 · design</p>
</header>
<section>
<div class="wrap">
<div class="prose">
<p>"You choose everything" sounds like marketing. It's not — it's the shape of the code. Keru's philosophy and its architecture are the same thing, and that's the whole stability argument in miniature.</p>
<h3>The claim</h3>
<p>Keru says every foundational component is a variable you resolve at install time. Here's how that's true at the structural level, not just in spirit:</p>
<ul class="features">
<li><strong>The installer encodes the choices.</strong> <code>install.sh</code> presents switches and writes them into <code>make.conf</code>. Init, libc, fs, kernel, sudo, net — each a line.</li>
<li><strong>The profile is the only interface.</strong> <code>make.conf</code> is what the build reads. There's no hidden stack to override your choices; the choices <em>are</em> the input.</li>
<li><strong>Kama executes, doesn't decide.</strong> The package manager runs recipes. It has no opinion because it has no place for one.</li>
<li><strong>The build is a pipeline of your selections.</strong> Stage 2 builds exactly <code>$KERNEL</code>, <code>$INIT</code>, <code>$SUDO</code>, <code>$NET</code>. Nothing else is possible.</li>
</ul>
<h3>Why that matters</h3>
<p>A distro is stable-for-its-idea when saying the thing and doing the thing are the same act. There's no gap for the machine to betray the pitch. If the pitch says "whatever you chose lands on the disk," the pipeline is materially incapable of doing anything else — because its only inputs are your choices.</p>
<h3>The boundary is honest too</h3>
<p>The same architecture makes the limits visible. Choice multiplies combinations, so stability is scoped to what's offered, and risky picks get warned, not blocked — <a href="../stability.html">the warn-not-block stance</a>. That's another place the philosophy and the structure agree: the installer tells you the truth because the design has no way to hide it.</p>
<p>Read more in <a href="../philosophy.html">the philosophy</a>.</p>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">See the <a href="../sitemap.html">sitemap</a> for all pages.</div></noscript>
<script src="../assets/js/include.js" data-base=".."></script>
</body>
</html>
+55
View File
@@ -0,0 +1,55 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>The road to 0.1 — Keru OS news</title>
<meta name="description" content="What has to exist before the first installable ISO ships.">
<link rel="stylesheet" href="../assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="../index.html">home</a> / <a href="../news.html">news</a> / road to 0.1</p>
<h1>The road to 0.1</h1>
<p class="meta" style="font-family:var(--mono);color:var(--ink-dim);font-size:.85rem">2026-09-01 · roadmap</p>
</header>
<section>
<div class="wrap">
<div class="prose">
<p>The first installable release, <strong>0.1</strong>, ships as a bootable ISO. No source builds for the user, no manual tooling — you boot it, the installer starts itself, you choose, and it builds. Here's the honest list of what has to be true before that ISO exists.</p>
<h3>The pipeline must actually build</h3>
<ul class="features">
<li><strong>Toolchain bootstrap on real hardware.</strong> binutils → gcc → libc → toolchain, from literal nothing. This is the hard step; source distros live or die here.</li>
<li><strong>A working base set.</strong> <code>base</code>, <code>toolchain</code>, <code>openssh</code>, and the tooling each swappable needs, all building against the chosen libc.</li>
<li><strong>Every offered combo, proven.</strong> The stability promise is "stable on what we offer" — so the offering must be curated to what's tested.</li>
</ul>
<h3>The ISO must boot and install</h3>
<ul class="features">
<li><strong>live/init works.</strong> The ISO boots, mounts virtual filesystems, and hands you the installer with no prompt in the way.</li>
<li><strong>Network gate works.</strong> Connectivity check, <code>nmtui</code> handoff, re-check loop — the hard requirement handled gracefully.</li>
<li><strong>The installer writes a correct profile.</strong> Menus → make.conf → build, with the stability checks warning (never blocking) along the way.</li>
<li><strong>The installed system boots.</strong> First boot runs the init you chose, on the filesystem you chose, with the kernel you chose. Fixed at first boot.</li>
</ul>
<h3>Honesty about the present</h3>
<p>Right now the design is public, the repos are live, and this site documents it all — but nothing has booted on hardware yet. The gap between "the architecture is sound" and "0.1 exists" is exactly the work in this roadmap. We're not pretending it's done; we're saying plainly what remains.</p>
<div class="callout">When 0.1 lands, it will be linked here and on the <a href="../install.html">install page</a>. Until then, progress shows up in the <a href="../news.html">news</a>.</div>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">See the <a href="../sitemap.html">sitemap</a> for all pages.</div></noscript>
<script src="../assets/js/include.js" data-base=".."></script>
</body>
</html>
+77
View File
@@ -0,0 +1,77 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Philosophy — Keru OS</title>
<meta name="description" content="Keru's philosophy: the OS is a choice, not a conclusion. Anti-opinionated, source-only, warn-not-block stability.">
<link rel="stylesheet" href="assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="index.html">home</a> / philosophy</p>
<h1>Keru's Philosophy</h1>
<p>The governing principle, in plain terms.</p>
</header>
<section>
<div class="wrap">
<div class="prose">
<blockquote><strong>The OS is a choice, not a conclusion.</strong></blockquote>
<p>Most distros ship a decision someone else already made for you — a default init, a default libc, a default filesystem. You inherit it and live with it. Keru refuses that premise. Every foundational component is a <em>variable you resolve at install time</em>, not a fixed value baked into the distribution. Every init, every libc, every filesystem, every kernel, every privilege-elevation tool — all selectable, none forced.</p>
<hr>
<h3>Anti-opinionated, not opinionated</h3>
<p>Keru is not opinionated. It is <strong>anti-opinionated</strong>. An opinionated distro picks a stack and defends it — "you get s6 and XFS whether you like it or not." Keru is the direct rejection of that. It holds <strong>no opinion</strong> about which init, libc, filesystem, or daemon you should run, because that decision belongs to you, not to the distribution.</p>
<p>The distro's only opinion is that you have to form one. After that, it shuts up and builds exactly what you chose.</p>
<h3>Only what you asked for</h3>
<p>The install medium carries <strong>nothing but the installer</strong>. There is no prebuilt base image, no hidden bloat, no background assumptions. You pick your system, Keru fetches it and compiles it from source, and the disk reflects exactly that and nothing more. What gets built is defined by what you chose — not by what maintainers decided you should have.</p>
<h3>Control without complexity</h3>
<p>This is the deliberate bet, and the thing that separates Keru from a Gentoo skin. The package manager, <strong>Kama</strong>, is a shell script. It reads a <code>make.conf</code> and runs recipe commands. No dependency solver. No package database. No compiled manager machinery.</p>
<blockquote>"Sure, the package manager is in shell, and that compromises performance — but it's still faster than many package managers people actually use, and the real cost of a build is the compiler, not the meta-machinery around it."</blockquote>
<p>The dependency model is AUR-style ephemeral: build tools are fetched, compiled, and removed once they've served, so they never accumulate. The richness lives in the recipes and the profile, not in the machinery. Keru is the position that package managers became more complex than the packages they manage, and that the simple version is the right one.</p>
<blockquote>"A package manager doesn't need a resolver to be honest. It needs to be legible — you can read every decision it makes, because every decision is a script or a line in make.conf you can see and change."</blockquote>
<h3>Squared with reality</h3>
<p>Building every init, every libc, every filesystem from source at install time requires a working network connection, and the installer is honest about that: connectivity is a hard gate, and network setup happens inside the installer. This is what makes "everything is swappable" real rather than aspirational. The power to choose anything comes from the fact that nothing is prebuilt — you fetch exactly the parts you picked.</p>
<blockquote>"You give up the convenience of a prebuilt system so the system you get is exactly the one you designed. Speed-to-install is traded for fit-to-request. If you want fast and prebaked, a binary distro is right there. If you want your machine, this is the one."</blockquote>
<h3>Stability, honestly scoped</h3>
<p>Keru's promise is that the system won't break — on the combinations it offers you. That's a bounded promise, enforced by curation, and it never locks you out. You're warned, never blocked. <a href="stability.html">Read the stability stance in full.</a></p>
<h3>The through-line</h3>
<p>Keru's lineage ran from TOML packages to a 50-line build DSL, then to plain shell. And from <em>opinionated dogma</em> — "you get s6 and XFS whether you like it or not" — to <em>anti-opinionated anything-goes</em>. Keru keeps the from-scratch purity while rejecting the fixed dogmas outright.</p>
<blockquote>"We don't tell you which init to worship or which filesystem to trust. We tell you that you have to choose — and then we build exactly that."</blockquote>
<p>The philosophy in one line:</p>
<blockquote><strong>A system should be exactly what you chose it to be — selected at install, built from source, nothing forced and nothing you didn't ask for.</strong></blockquote>
<p>And in two words: <strong>anti-opinionated by design.</strong></p>
<hr>
<p><a href="anti-opinionated.html">Deeper: what anti-opinionated actually costs and grants</a> · <a href="ethos.html">The ける ethos</a></p>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">See the <a href="sitemap.html">sitemap</a> for all pages.</div></noscript>
<script src="assets/js/include.js" data-base="."></script>
</body>
</html>
+53
View File
@@ -0,0 +1,53 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Privacy — Keru OS</title>
<meta name="description" content="Keru OS's privacy stance: no telemetry, no tracking, no accounts.">
<link rel="stylesheet" href="assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="index.html">home</a> / privacy</p>
<h1>Privacy</h1>
<p>Short version: there's nothing to invade.</p>
</header>
<section>
<div class="wrap">
<div class="prose">
<h3>The OS</h3>
<ul class="features">
<li><strong>No telemetry.</strong> Keru does not phone home — not during install, not at boot, not ever.</li>
<li><strong>No accounts.</strong> There is nothing to sign up for to install or use Keru.</li>
<li><strong>No tracking.</strong> No analytics SDKs, no crash reporters, no "improve your experience" data collection.</li>
<li><strong>Nothing you didn't ask for.</strong> The only network activity comes from what you explicitly install, at install time, from the sources that package's recipe names.</li>
</ul>
<h3>This website</h3>
<ul class="features">
<li><strong>No cookies.</strong> No session tracking, no analytics scripts, no third-party trackers.</li>
<li><strong>Static files only.</strong> Plain HTML/CSS/JS. The only external requests are the web fonts (from Google Fonts). If that matters to you, the site still works without them — it falls back to system fonts.</li>
<li><strong>No accounts for content.</strong> Reading the site requires nothing.</li>
</ul>
<h3>About the download</h3>
<p>When 0.1 ships as an ISO, downloading it is a plain file fetch from GitHub (a release asset). Nothing is recorded beyond what your server and service logs necessarily keep. If a mirror is ever added, this page will say so.</p>
<div class="callout">If that changes, this page changes first — and it will be public. Keru won't decide that telemetry is "fine actually" in a changelog.</div>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">See the <a href="sitemap.html">sitemap</a> for all pages.</div></noscript>
<script src="assets/js/include.js" data-base="."></script>
</body>
</html>
+53
View File
@@ -0,0 +1,53 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Privilege elevation — Keru OS</title>
<meta name="description" content="How you gain root with Keru: doas, sudo, opendoas, or su. You decide.">
<link rel="stylesheet" href="assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="index.html">home</a> / <a href="swappables.html">swappables</a> / privilege elevation</p>
<h1>Privilege elevation</h1>
<p>How you become root. Your choice.</p>
</header>
<section>
<div class="wrap">
<div class="prose">
<p>Even "sudo" isn't sacred in Keru. How you elevate privileges is a swappable — the question of which <code>su</code>-style tool runs your privileged commands is settled by you, at install, alongside everything else.</p>
</div>
<div class="grid grid-4" style="margin-top:30px">
<div class="card"><span class="h">doas</span><p>The default. OpenBSD's elegant, minimal replacement for sudo — small config, fewer lines, no surprise policies.</p></div>
<div class="card"><span class="h">sudo</span><p>The familiar heavyweight. Fine-grained policies (<code>sudoers</code>), broad ecosystem familiarity.</p></div>
<div class="card"><span class="h">opendoas</span><p>A portable, independently-maintained doas implementation for Linux — the doas philosophy with a maintained port.</p></div>
<div class="card"><span class="h">su</span><p>The classic. No added abstraction — switch user and run what you need, as basic as it gets.</p></div>
</div>
<div class="prose" style="margin-top:34px">
<h3>Why this is on the list</h3>
<p>Privilege elevation touches everything an admin does, and it's usually a foregone conclusion: "you get sudo." Keru treats it as what it is — a tool with tradeoffs — and lets you pick the flavor. If you believe in two-line configs, <code>doas</code>. If you need <code>sudoers</code> granularity, <code>sudo</code>. If you want zero abstraction, <code>su</code>.</p>
<p>Whichever you choose gets built in stage 2 as part of your profile, alongside your kernel and init. Nothing preinstalled, nothing assumed.</p>
<div class="callout">Small opinion, stated plainly: <code>doas</code> is the default because two lines of config beats two hundred. But it's a default, not a dogma — swap it freely.</div>
<p><a href="swappables.html">← All swappables</a></p>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">See the <a href="sitemap.html">sitemap</a> for all pages.</div></noscript>
<script src="assets/js/include.js" data-base="."></script>
</body>
</html>
+61
View File
@@ -0,0 +1,61 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Profile system — Keru OS</title>
<meta name="description" content="How Keru's profile system works: the installer writes a profile, Kama reads it, and the whole build is driven by it.">
<link rel="stylesheet" href="assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="index.html">home</a> / <a href="docs.html">docs</a> / profile</p>
<h1>Profile system</h1>
<p>The contract between "what you chose" and "what gets built."</p>
</header>
<section>
<div class="wrap">
<div class="prose">
<p>Keru's profile system is the hand-off between your decisions and the build. It's a small, open design:</p>
<h3>The flow</h3>
<ol>
<li><strong>You choose.</strong> The installer (<code>installer/install.sh</code>) walks each swappable and records your picks.</li>
<li><strong>It writes a profile.</strong> Your choices become <code>make.conf</code> — plain, readable, human-editable.</li>
<li><strong>The pipeline reads it.</strong> <code>scripts/build-root.sh</code> sources the profile and drives Kama with those exact settings.</li>
<li><strong>The system appears.</strong> Kama boots the toolchain, builds the base, brings your chosen kernel/init/sudo/net, and finalizes the filesystem your profile named.</li>
</ol>
<h3>What the profile owns</h3>
<table>
<tr><th>Layer</th><th>What it holds</th></tr>
<tr><td>Swappables</td><td><code>INIT</code>, <code>LIBC</code>, <code>TARGET_FS</code>, <code>KERNEL</code>, <code>SUDO</code>, <code>NET</code>.</td></tr>
<tr><td>Base set</td><td><code>BASE_PACKAGES</code> — what every system gets (<code>base toolchain openssh</code>).</td></tr>
<tr><td>System config</td><td><code>LOCALE</code>, <code>TIMEZONE</code>, <code>KEYMAP</code>.</td></tr>
<tr><td>Build env</td><td><code>CFLAGS</code>, <code>CXXFLAGS</code>, <code>LDFLAGS</code>, <code>JOBS</code>, <code>MAKEFLAGS</code>.</td></tr>
<tr><td>Mirrors & cache</td><td><code>SOURCE_MIRROR</code>, <code>ROOT</code>, <code>CACHEDIR</code>.</td></tr>
<tr><td>Kama behavior</td><td><code>PURGE_TEMP_DEPS</code>, <code>FAIL_FAST</code>.</td></tr>
</table>
<h3>Hand-tuning is a feature</h3>
<p>The installer is convenient, not precious. The profile it writes is just a text file — change <code>INIT=s6</code>, tweak <code>CFLAGS</code>, add a package to <code>BASE_PACKAGES</code>, and rebuild. The "craft your system" ethos extends past install into the profile itself.</p>
<div class="callout">The profile makes Keru reproducible and legible in one stroke: the same <code>make.conf</code> is the full description of the system. Read, edit, rebuild.</div>
<p><a href="make-conf.html">make.conf reference</a> · <a href="build-pipeline.html">Build pipeline</a> · <a href="docs.html">← Docs</a></p>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">See the <a href="sitemap.html">sitemap</a> for all pages.</div></noscript>
<script src="assets/js/include.js" data-base="."></script>
</body>
</html>
+97
View File
@@ -0,0 +1,97 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Recipe authoring — Keru OS</title>
<meta name="description" content="A practical HOWTO for writing kama package recipes: easy tier, real examples, common patterns, and how to get it merged into kama-packages.">
<link rel="stylesheet" href="assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="index.html">home</a> / <a href="docs.html">docs</a> / recipe authoring</p>
<h1>Recipe authoring</h1>
<p>Writing a kama recipe, top to bottom.</p>
</header>
<section>
<div class="wrap">
<div class="prose">
<p>Every package in a Keru system is described by a recipe: a plain POSIX shell script in <code>kama-packages</code>. Writing one is closer to filling a form than engineering a build.</p>
<h3>The template</h3>
<p><code>kama-packages/TEMPLATE.sh</code> is the canonical starting point. Copy it, fill the easy tier:</p>
<div class="code-block">name=hello # required
version=2.12.1 # required for fetch
url=https://ftp.gnu.org/gnu/hello/hello-2.12.1.tar.gz
deps=() # build-time deps, compiled then purged
build() {
./configure --prefix=/usr
make -j"$JOBS"
}
install() {
make install DESTDIR="$pkgdir" # stage, never $ROOT
}</div>
<h3>A real, complete recipe</h3>
<p>This is the entire busybox recipe currently in the repo:</p>
<div class="code-block">name=busybox
version=1.36.1
url=https://busybox.net/downloads/busybox-1.36.1.tar.bz2
deps=()
build() {
make defconfig
make -j"$JOBS"
}
install() {
make install CONFIG_PREFIX="$pkgdir"
}</div>
<p>That's it. Kama downloads, extracts, strips the top dir, builds, stages, and installs.</p>
<h3>Stepping up</h3>
<table>
<tr><th>Need</th><th>Field / function</th></tr>
<tr><td>Colliding with another package</td><td><code>provides=(...) conflicts=(...)</code></td></tr>
<tr><td>Build deps that must stay</td><td><code>runtime_deps=(...)</code></td></tr>
<tr><td>Arch-restricted</td><td><code>arch=(x86_64)</code></td></tr>
<tr><td>Repo or vcs sources</td><td><code>noextract=("$url")</code> + own <code>build()</code></td></tr>
<tr><td>Custom fetch (patch first)</td><td><code>pkg_fetch() { default_fetch; patch ...; }</code></td></tr>
<tr><td>Post-install work</td><td><code>pkg_post()</code> · <code>pkg_split()</code> for subpackages</td></tr>
</table>
<h3>Rules of the road</h3>
<ul class="features">
<li><strong>Stage, don't touch.</strong> <code>install()</code> installs into <code>$pkgdir</code>. Kama commits the staging dir to <code>$ROOT</code> only after a successful build.</li>
<li><strong>Add pure build deps to <code>deps</code>.</strong> They're purged automatically after the build (AUR-style). Keeps the door clean.</li>
<li><strong>Declare the license.</strong> <code>license=(SPDX)</code> — supply chain cleanliness starts here.</li>
<li><strong>Pin exactly.</strong> A fixed <code>url</code> + <code>version</code>, never a moving "latest".</li>
</ul>
<h3>Checking your work</h3>
<div class="code-block">sh -n recipe.sh # syntax check
kama info &lt;pkgname&gt; # metadata parses (name from the recipe)
make recipe-check # lint the whole kama-packages repo
kama make &lt;pkgname&gt; # build it for real</div>
<div class="callout">The behavioral spec lives at <a href="recipe-format.html">recipe format</a>. For hands-on, mirror the <a href="kama-recipes.html">recipe concept</a> page and start with <code>busybox.sh</code>, the smallest real recipe.</div>
<p><a href="recipe-format.html">← Recipe format</a> · <a href="kama-repos.html">The repos</a></p>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">See the <a href="sitemap.html">sitemap</a> for all pages.</div></noscript>
<script src="assets/js/include.js" data-base="."></script>
</body>
</html>
+115
View File
@@ -0,0 +1,115 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Recipe format — Keru OS</title>
<meta name="description" content="The formal spec for kama recipes: easy tier, advanced tier, fields, hooks, and packaging control.">
<link rel="stylesheet" href="assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="index.html">home</a> / <a href="docs.html">docs</a> / recipe format</p>
<h1>Recipe format</h1>
<p>The spec for kama packages.</p>
</header>
<section>
<div class="wrap">
<div class="prose">
<p>A recipe is a <strong>plain POSIX shell script</strong> describing how to compile and install one piece of software. The syntax splits into two tiers:</p>
<ul class="features">
<li><strong>Easy</strong> — declare a few variables, fill in <code>build</code> and <code>install</code>, done. Covers ~90% of packages (autotools/cmake/meson).</li>
<li><strong>Advanced</strong> — full control when you need it: custom fetch/extract, staging layout, packaging hooks, multi-arch, verification. Everything the easy tier does is sugar over this.</li>
</ul>
<p>In both tiers, Kama <em>sources</em> the recipe and runs the functions you define.</p>
<hr>
<h3>Easy tier — most packages only need this</h3>
<div class="code-block">name=busybox
version=1.36.1
url=https://busybox.net/downloads/busybox-1.36.1.tar.bz2
deps=() # build-time deps, purged after (AUR-style)
build() { # configure + compile
make defconfig
make
}
install() { # install into $pkgdir (staging), not $ROOT
make install CONFIG_PREFIX="$pkgdir"
}</div>
<p>That's it. Kama supplies the conventional <code>pkg_fetch</code> (download + extract — auto-detects <code>.tar.xz/.gz/.bz2/.zip</code>, strips the top directory) and <code>pkg_clean</code>.</p>
<hr>
<h3>Advanced tier — override any step</h3>
<div class="code-block">name=busybox
version=1.36.1
url=https://busybox.net/downloads/busybox-1.36.1.tar.bz2
deps=(gcc musl-headers) # temp build deps (AUR-style)
runtime_deps=(musl) # stays installed
license=(GPL-2.0)
provides=(sh) # capability this package provides
conflicts=(dash) # mutual exclusion
arch=(x86_64) # if non-empty, restrict to archs
noextract=() # URLs to download but NOT auto-extract
# override auto extract (e.g. patching before configure)
pkg_fetch() {
default_fetch # run the easy-tier default
cd "$src"
patch -p1 &lt; ../my.patch
}
build() { ./configure --prefix=/usr "$@" &amp;&amp; make; }
install() { make install DESTDIR="$pkgdir"; }</div>
<h3>Fields</h3>
<table>
<tr><th>Field</th><th>Purpose</th></tr>
<tr><td><code>name</code></td><td>Package name. Required.</td></tr>
<tr><td><code>version</code></td><td>Release version. Required for fetch.</td></tr>
<tr><td><code>url</code></td><td>Upstream source (or list).</td></tr>
<tr><td><code>deps</code></td><td>Build-time dependencies — compiled, installed, then purged (AUR-style).</td></tr>
<tr><td><code>runtime_deps</code></td><td>Dependencies that stay installed.</td></tr>
<tr><td><code>license</code></td><td>SPDX license identifiers.</td></tr>
<tr><td><code>provides</code></td><td>Capabilities this package provides (virtuals).</td></tr>
<tr><td><code>conflicts</code></td><td>Mutual exclusions.</td></tr>
<tr><td><code>arch</code></td><td>Architecture allow-list; empty means any.</td></tr>
<tr><td><code>noextract</code></td><td>URLs downloaded but not auto-extracted.</td></tr>
</table>
<h3>Hooks and functions</h3>
<table>
<tr><th>Function</th><th>Role</th></tr>
<tr><td><code>build()</code></td><td>Configure + compile, run in the extracted source dir.</td></tr>
<tr><td><code>install()</code></td><td>Install into the staging dir (<code>$pkgdir</code>/<code>DESTDIR</code>), not the live root.</td></tr>
<tr><td><code>pkg_fetch()</code></td><td>Override download/extract (can call <code>default_fetch</code>).</td></tr>
<tr><td><code>pkg_clean()</code></td><td>Override source cleanup.</td></tr>
<tr><td><code>pkg_post()</code></td><td>Post-install hook, called after staging.</td></tr>
<tr><td><code>pkg_split()</code></td><td>Optional splitting of staged output into subpackages.</td></tr>
</table>
<div class="callout">The full spec lives in the repo at <code>docs/recipe-format.md</code>. The web version mirrors it; the canonical source is the repository.</div>
<p><a href="kama-recipes.html">The recipe concept</a> · <a href="kama.html">← Kama</a></p>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">See the <a href="sitemap.html">sitemap</a> for all pages.</div></noscript>
<script src="assets/js/include.js" data-base="."></script>
</body>
</html>
+67
View File
@@ -0,0 +1,67 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Release process — Keru OS</title>
<meta name="description" content="How Keru versions work, what a release contains, and the honest '0.1 when it's ready' timeline.">
<link rel="stylesheet" href="assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="index.html">home</a> / <a href="docs.html">docs</a> / release process</p>
<h1>Release process</h1>
<p>How a release leaves the kiln.</p>
</header>
<section>
<div class="wrap">
<div class="prose">
<p>Keru's releases are honest about being releases: each one is a tested point in time of the three repos, assembled into an ISO that boots and installs without fanfare.</p>
<h3>Versioning</h3>
<div class="code-block">keru-0.1.0.iso # {major}.{minor}.{patch}</div>
<table>
<tr><th>Bump</th><th>When</th></tr>
<tr><td>major</td><td>The swappable set changes shape, or the philosophy moves — real milestones like the first ISO.</td></tr>
<tr><td>minor</td><td>New swappable or a new kama feature that stays backward-compatible.</td></tr>
<tr><td>patch</td><td>Recipe fixes, installer bugfixes, docs — anything that changes no contracts.</td></tr>
</table>
<h3>What the release ISO contains</h3>
<ul class="features">
<li><strong>The installer.</strong> <code>installer/install.sh</code> plus its payload.</li>
<li><strong>The live init.</strong> <code>live/init</code> — boot the ISO, installer auto-runs.</li>
<li><strong>The repos.</strong> kama and kama-packages pinned at the release commit.<br>Everything else — every source tarball, every toolchain compile — is fetched and built at install time.</li>
</ul>
<h3>Release readiness</h3>
<table>
<tr><th>Check</th><th>What passes it</th></tr>
<tr><td>Combos boot</td><td>The proven set of the offered swappables all boot after install.</td></tr>
<tr><td>Installer clean</td><td>A full install from a cold boot, no keyboard runtime.</td></tr>
<tr><td>No blockers</td><td>Nothing warns-but-doesn't-block where it shouldn't; unproven combos warn loudly.</td></tr>
<tr><td>Docs match</td><td>make.conf, recipes, and this website agree with the shipped code.</td></tr>
</table>
<h3>Announcements</h3>
<p>Releases are announced on the <a href="news.html">news page</a>, with a changelog and the exact repos/commits the ISO was cut from. "0.1 when it's ready" — as tracked in the status above — remains the only roadmap.</p>
<div class="callout">Deliberately unglamorous. A release is a checkpoint the community can trust, not a marketing event. Read the <a href="news.html">news</a> for the current one.</div>
<p><a href="contribute.html">Contribute</a> · <a href="news.html">→ Status / news</a></p>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">See the <a href="sitemap.html">sitemap</a> for all pages.</div></noscript>
<script src="assets/js/include.js" data-base="."></script>
</body>
</html>
+68
View File
@@ -0,0 +1,68 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Security — Keru OS</title>
<meta name="description" content="Keru's trust model: source-only builds, verification against fetch, no binary packages, a small auditable toolchain, and clean licensing.">
<link rel="stylesheet" href="assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="index.html">home</a> / <a href="docs.html">docs</a> / security</p>
<h1>Security</h1>
<p>The trust model, stated plainly.</p>
</header>
<section>
<div class="wrap">
<div class="prose">
<p>Keru's security stance follows from its design. No binaries, no opaque machinery, no hidden services. That shrinks the attack surface to things you can actually read.</p>
<h3>Source-only by construction</h3>
<p>There is no binary package store to compromise. Every package is compiled in your install from original source fetched over the network. The "prebuilt artifact" class of attack simply doesn't exist.</p>
<h3>Verified fetch</h3>
<ul class="features">
<li><strong>Mirror then upstream.</strong> Downloads try <code>SOURCE_MIRROR</code> when set and fall back to upstream. Unset — the default — they go straight to upstream.</li>
<li><strong>Integrity enforced.</strong> A fetched tarball that doesn't verify is refused, not untarred. Failed verification is a hard stop.</li>
<li><strong>Pinned sources.</strong> Recipes pin the exact <code>url</code> and version. Nothing is ever pulled "latest" implicitly.</li>
</ul>
<h3>A toolchain you can audit</h3>
<div class="code-block">scripts/build-root.sh # ~shell; reads your make.conf
profile/make.conf # your choices, explicit
kama # ~225-line package manager
kama-packages/*.sh # recipes as plain shell you can read top to bottom</div>
<p>The whole vertical slice from "make.conf" to "booted system" is a handful of shell files. That's the honest counter to the "trust the distro binary blob" model.</p>
<h3>Privilege by your rules</h3>
<p>Privilege elevation is swappable: <code>doas</code> (slender, auditable) is the default, with sudo, opendoas, and plain <code>su</code> available. Keru never preloads root-owned services or hidden daemons.</p>
<h3>Kernel hardening, if you want it</h3>
<p>Pick <code>linux-hardened</code> at install for a hardened kernel, or stick with stable <code>linux</code>. The choice is yours and applied at the moment your system is built.</p>
<h3>Licensing, because supply chain is security</h3>
<p>All three repos are <span class="tag accent">AGPL-3.0</span>. Recipes tag their <code>license</code> explicitly. Nothing in the pipeline is proprietary-black-boxed.</p>
<div class="callout">Trust is transitive: you still trust the sources you install and any mirror you point at. Keru's job is to make that trust chain visible and verifiable — not to pretend you can be protected from everything.</div>
<h3>Reporting</h3>
<p>Found a flaw in the installer, kama, or a recipe? File it with the stage and the failing artifact. See <a href="contact.html">contact</a> and <a href="troubleshooting.html">troubleshooting</a>.</p>
<p><a href="troubleshooting.html">← Troubleshooting</a> · <a href="toolchain.html">Toolchain bootstrap →</a></p>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">See the <a href="sitemap.html">sitemap</a> for all pages.</div></noscript>
<script src="assets/js/include.js" data-base="."></script>
</body>
</html>
+120
View File
@@ -0,0 +1,120 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Sitemap — Keru OS</title>
<meta name="description" content="The complete sitemap for the Keru OS website.">
<link rel="stylesheet" href="assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="index.html">home</a> / sitemap</p>
<h1>Sitemap</h1>
<p>Every page on this site.</p>
</header>
<section>
<div class="wrap">
<div class="grid grid-2">
<div>
<span class="tag">landing</span>
<ul class="features">
<li><a href="index.html">Home</a></li>
</ul>
<span class="tag">about</span>
<ul class="features">
<li><a href="about.html">About Keru OS</a></li>
<li><a href="philosophy.html">Philosophy</a></li>
<li><a href="anti-opinionated.html">Anti-opinionated</a></li>
<li><a href="stability.html">Stability</a></li>
<li><a href="ethos.html">Ethos</a></li>
</ul>
<span class="tag">install</span>
<ul class="features">
<li><a href="install.html">Install</a></li>
<li><a href="getting-started.html">Getting started</a></li>
<li><a href="installation-requirements.html">Requirements</a></li>
<li><a href="installer-walkthrough.html">Installer walkthrough</a></li>
<li><a href="network-setup.html">Network setup</a></li>
<li><a href="troubleshooting.html">Troubleshooting</a></li>
</ul>
</div>
<div>
<span class="tag">swappables</span>
<ul class="features">
<li><a href="swappables.html">All swappables</a></li>
<li><a href="inits.html">Init systems</a></li>
<li><a href="libcs.html">C libraries</a></li>
<li><a href="filesystems.html">Filesystems</a></li>
<li><a href="kernels.html">Kernels</a></li>
<li><a href="privilege-elevation.html">Privilege elevation</a></li>
<li><a href="network-tools.html">Network tools</a></li>
</ul>
<span class="tag">kama</span>
<ul class="features">
<li><a href="kama.html">Kama overview</a></li>
<li><a href="kama-usage.html">Kama usage</a></li>
<li><a href="kama-recipes.html">Kama recipes</a></li>
<li><a href="kama-repos.html">Kama repos</a></li>
</ul>
<span class="tag">docs</span>
<ul class="features">
<li><a href="docs.html">Docs</a></li>
<li><a href="make-conf.html">make.conf</a></li>
<li><a href="profile.html">Profile system</a></li>
<li><a href="recipe-format.html">Recipe format</a></li>
<li><a href="recipe-authoring.html">Recipe authoring</a></li>
<li><a href="build-pipeline.html">Build pipeline</a></li>
<li><a href="toolchain.html">Toolchain bootstrap</a></li>
<li><a href="mkfs-root.html">mkfs-root</a></li>
<li><a href="live-init.html">Live init</a></li>
<li><a href="kama-config.html">Kama configuration</a></li>
<li><a href="mirror-cache.html">Mirrors &amp; cache</a></li>
<li><a href="security.html">Security</a></li>
<li><a href="release-process.html">Release process</a></li>
</ul>
</div>
<div>
<span class="tag">news</span>
<ul class="features">
<li><a href="news.html">News</a></li>
<li><a href="news/announcing-keru.html">Introducing Keru OS</a></li>
<li><a href="news/philosophy-is-architecture.html">The philosophy is the architecture</a></li>
<li><a href="news/roadmap-0.1.html">The road to 0.1</a></li>
<li><a href="news/design-decisions.html">Design decisions, so far</a></li>
</ul>
<span class="tag">community</span>
<ul class="features">
<li><a href="community.html">Community</a></li>
<li><a href="contribute.html">Contribute</a></li>
<li><a href="faq.html">FAQ</a></li>
<li><a href="contact.html">Contact</a></li>
<li><a href="links.html">Links</a></li>
</ul>
<span class="tag">legal</span>
<ul class="features">
<li><a href="license.html">License</a></li>
<li><a href="privacy.html">Privacy</a></li>
<li><a href="credits.html">Credits</a></li>
</ul>
</div>
</div>
<div class="prose" style="margin-top:40px">
<p>Total: 48 pages, all served from <code>web/</code> in the KeruOS repo — plain static HTML, no framework, pure black, with a shared nav/footer injected at runtime.</p>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">This is the sitemap. If nav/footer didn't load, it's because JS is off — links above still work.</div></noscript>
<script src="assets/js/include.js" data-base="."></script>
</body>
</html>
+75
View File
@@ -0,0 +1,75 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Stability — Keru OS</title>
<meta name="description" content="Keru's stability promise: the system won't break for any choice Keru offers you. Past that, it warns and steps aside — you're never blocked.">
<link rel="stylesheet" href="assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="index.html">home</a> / stability</p>
<h1>Stability</h1>
<p>Guaranteed on what's offered. Never enforced on you.</p>
</header>
<section>
<div class="wrap">
<div class="prose">
<h3>The promise, scoped</h3>
<p>Keru's definition of stable is direct: <strong>the system won't break.</strong> But that promise is only honest if it's scoped. Keru guarantees it <strong>on the combinations it offers you.</strong></p>
<p>That's what it means for the installer to offer a choice in the first place: each option in <code>install.sh</code> is one Keru has proven builds and boots. The offered set is curated <em>so that</em> it doesn't break. Choice multiplies the test surface — six inits, four libcs, seven filesystems, five kernels, and more produce well over a thousand possible systems. Guaranteeing every one of them is only honest if it's enforced by curation: Keru offers what works.</p>
<h3>But you're never locked out</h3>
<p>If you pick something that isn't yet proven — a libc and init never tested together, an unmaintained filesystem, an exotic kernel pair — Keru does <strong>not</strong> stop you. It <strong>warns you</strong> the combination is unstable and lets you proceed.</p>
<blockquote>"Stability is a guarantee about what we offer, not a jail around the edge of it. If you want to push into the unproven, we tell you the truth and get out of your way."</blockquote>
<p>The full definition, in one line:</p>
<blockquote><strong>The system won't break for any choice Keru offers you; for anything beyond that, Keru warns and steps aside — you stay in control, never blocked.</strong></blockquote>
<h3>How the warning shows up</h3>
<p>The installer runs a stability check after your selections. Known-risky combinations are flagged before anything is written:</p>
<div class="code-block"><span class="tag warn">WARNING</span>
uclibc-ng + runit: not yet proven to build and boot together
musl + systemd: not yet proven to build and boot together
this combination is unstable. Keru won't stop you — build at your own risk.</div>
<p>Some of the pairs Keru currently warns about:</p>
<table>
<tr><th>Combination</th><th>Why it's flagged</th></tr>
<tr><td>uclibc-ng + anything</td><td>Pre-0.1, not yet proven to build and boot end to end.</td></tr>
<tr><td>musl + systemd</td><td>Systemd and musl are a known-hard pairing.</td></tr>
<tr><td>zfs as root fs</td><td>Needs kernel module + ZFS userspace; not yet proven.</td></tr>
<tr><td>reiserfs</td><td>Unmaintained; no stable future.</td></tr>
</table>
<h3>What stability means for choices that work</h3>
<ul class="features">
<li><strong>Reproducible.</strong> The same <code>make.conf</code> builds the same system.</li>
<li><strong>Predictable.</strong> What you chose is what boots. No surprises smuggled in by defaults.</li>
<li><strong>Kama never lies.</strong> The package manager's job is to do exactly what a recipe says — reliably, silently, and correctly.</li>
</ul>
<h3>The honest trade-off</h3>
<p>"Extremely stable" and "everything is swappable" pull in opposite directions. Most famously-stable distros (Debian) gain stability by <em>shrinking</em> choice. Keru's stability therefore isn't "fewest things possible" — it's <strong>"whatever you chose, it builds and boots predictably, and Keru never hides a risk from you."</strong></p>
<p><a href="philosophy.html">← Back to the philosophy</a></p>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">See the <a href="sitemap.html">sitemap</a> for all pages.</div></noscript>
<script src="assets/js/include.js" data-base="."></script>
</body>
</html>
+54
View File
@@ -0,0 +1,54 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Swappables — Keru OS</title>
<meta name="description" content="The Keru differentiator: every major component — init, libc, filesystem, kernel, privilege elevation, networking — is chosen by you at install time.">
<link rel="stylesheet" href="assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="index.html">home</a> / swappables</p>
<h1>The Swappables</h1>
<p>Every foundational component, yours to choose at install time.</p>
</header>
<section>
<div class="wrap">
<div class="prose">
<p>Keru's differentiator is one sentence: <strong>nothing is fixed, nothing you didn't ask for is forced on you.</strong> The installer presents each foundational component as a flat, open choice, and the system that boots is assembled from exactly the ones you picked.</p>
<p>This is what distro arguments get settled with, resolved ahead of time by you instead of argued forever by maintainers. Runit vs systemd, glibc vs musl, ext4 vs btrfs, vanilla vs hardened kernel — all of it becomes <em>your</em> decision, made once, at install.</p>
</div>
<div class="grid grid-2" style="margin-top:34px">
<a class="card" href="inits.html"><span class="num">init</span><span class="h">Init system</span><p>Who brings your system up at boot. runit, s6, openrc, systemd, busybox-init, sysvinit, dinit, shepherd.</p></a>
<a class="card" href="libcs.html"><span class="num">libc</span><span class="h">C library</span><p>The foundation under everything that runs. glibc, musl, uclibc-ng.</p></a>
<a class="card" href="filesystems.html"><span class="num">fs</span><span class="h">Filesystem</span><p>The shape of your disk. ext4, btrfs, xfs, zfs, f2fs, jfs, reiserfs, swap.</p></a>
<a class="card" href="kernels.html"><span class="num">kernel</span><span class="h">Kernel</span><p>The spine of the machine. linux, linux-lts, linux-hardened, linux-cachyos, linux-zen.</p></a>
<a class="card" href="privilege-elevation.html"><span class="num">priv</span><span class="h">Privilege elevation</span><p>How you elevate. doas, sudo, opendoas, su.</p></a>
<a class="card" href="network-tools.html"><span class="num">net</span><span class="h">Network tools</span><p>How the network is managed. networkmanager, connman, systemd-networkd, nmtui alone.</p></a>
</div>
<div class="prose" style="margin-top:40px">
<h3>Beyond the big six</h3>
<p>Kernel parameters, locale, clock, and keymap are all configurable too — surfaced through <code>make.conf</code>, the profile that your choices produce. The swappables aren't a fixed list; they're a stance. <a href="make-conf.html">Read the make.conf reference.</a></p>
<h3>Stability is scoped to these</h3>
<p>Because choice multiplies the surface, Keru is stable on the combinations it offers, and warns (never blocks) beyond that. <a href="stability.html">How that works.</a></p>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">See the <a href="sitemap.html">sitemap</a> for all pages.</div></noscript>
<script src="assets/js/include.js" data-base="."></script>
</body>
</html>
+68
View File
@@ -0,0 +1,68 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Toolchain bootstrap — Keru OS</title>
<meta name="description" content="Stage 0 in depth: how Keru bootstraps binutils, gcc, and a C library from nothing, and then builds everything else on top.">
<link rel="stylesheet" href="assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="index.html">home</a> / <a href="docs.html">docs</a> / toolchain</p>
<h1>Toolchain bootstrap</h1>
<p>What "from scratch" actually means.</p>
</header>
<section>
<div class="wrap">
<div class="prose">
<p>A source distro that seeds its compiler is a lie wearing a costume. Keru's stage 0 builds the toolchain from nothing — the assembler, the compiler, the C library, then a self-hosted toolchain package — before a single package in your system tree is compiled.</p>
<h3>Why the order matters</h3>
<table>
<tr><th>Step</th><th>What runs</th><th>Why first</th></tr>
<tr><td>1</td><td><code>binutils</code></td><td>as, ld, ar — you can't compile without an assembler and linker.</td></tr>
<tr><td>2</td><td>a bare <code>gcc</code></td><td>The C compiler, built against nothing but binutils.</td></tr>
<tr><td>3</td><td>your <code>libc</code></td><td>glibc, musl, or uclibc-ng. Everything userspace depends on it.</td></tr>
<tr><td>4</td><td>a full <code>gcc</code></td><td>Re-built now that the target libc exists (self-hosting).</td></tr>
<tr><td>5</td><td><code>toolchain</code> package</td><td>Freezes the whole toolchain as a kama package for the rest of the build.</td></tr>
</table>
<h3>A bootstrap run</h3>
<div class="terminal">
<div class="tbar"><span class="dot r"></span><span class="dot y"></span><span class="dot g"></span><span class="t">$ sh scripts/build-root.sh</span></div>
<pre><span class="c">[ keru ]</span> stage 0: bootstrap toolchain
<span class="c">[ keru ]</span> binutils 2.42 <span class="p">... ok</span>
<span class="c">[ keru ]</span> gcc 13.2 (bare) <span class="p">... ok</span>
<span class="c">[ keru ]</span> glibc 2.39 <span class="p">... ok</span>
<span class="c">[ keru ]</span> gcc 13.2 (self) <span class="p">... ok</span>
<span class="c">[ keru ]</span> toolchain → ROOT <span class="k">... ok</span>
<span class="c">[ keru ]</span> stage 1: base system</pre>
</div>
<h3>Where it goes wrong</h3>
<ul class="features">
<li><strong>libc switch.</strong> Bootstrapping against musl or uclibc-ng rearranges the early stages; the exact package set lives with the <a href="libcs.html">libc page</a>. A combo that isn't proven yet gets a warning — never a silent block.</li>
<li><strong>Host leakage.</strong> Everything must link against the freshly built chain, not the build host's. The recipes pass explicit <code>--host/--target</code> and <code>CC</code>/<code>CFLAGS</code> so nothing sneaks in.</li>
<li><strong>Double-build cost.</strong> gcc is compiled twice by design. That's the price of honesty; it's also a warm-up for the rest of the arch.</li>
</ul>
<div class="callout">This is the line Keru draws: before your base system, a full self-hosting toolchain exists that didn't exist before. After that, the rest is just — as one long build script — more of the same.</div>
<p><a href="security.html">← Security</a> · <a href="build-pipeline.html">Build pipeline</a></p>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">See the <a href="sitemap.html">sitemap</a> for all pages.</div></noscript>
<script src="assets/js/include.js" data-base="."></script>
</body>
</html>
+78
View File
@@ -0,0 +1,78 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Troubleshooting — Keru OS</title>
<meta name="description" content="Common Keru problems by stage — live boot, network, fetch, build, install, first boot — and how to fix each.">
<link rel="stylesheet" href="assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="index.html">home</a> / <a href="docs.html">docs</a> / troubleshooting</p>
<h1>Troubleshooting</h1>
<p>Diagnose by stage. The stage points at the file to blame.</p>
</header>
<section>
<div class="wrap">
<div class="prose">
<p>Almost every Keru failure lands in exactly one of five stages: <strong>live boot</strong>, <strong>network</strong>, <strong>fetch</strong>, <strong>build</strong>, or <strong>finalize</strong>. Figure out which, and you're most of the way to a fix.</p>
<h3>Live boot</h3>
<table>
<tr><th>Symptom</th><th>Cause / fix</th></tr>
<tr><td>Drops to an emergency shell</td><td><code>live/init</code> couldn't find the installer payload or mount buffers. Check the ISO layout and that you wrote the whole image, not just the files.</td></tr>
<tr><td>Installer never auto-starts</td><td>The live init runs <code>installer/install.sh</code> on boot. Run it by hand from the shell to see its errors directly.</td></tr>
<tr><td>Nothing on screen</td><td>Terminal TTY not your display? Verify the kernel picks your console; a plain <code>getty</code> on tty1 is the default.</td></tr>
</table>
<h3>Network</h3>
<ul class="features">
<li><strong>Installer says offline.</strong> It probes several hosts (<code>1.1.1.1</code>, <code>github.com</code>) and loops: it will offer to run <code>nmtui</code>, then re-check. Let it. GitHub reachability matters — package recipes are fetched from GitHub.</li>
<li><strong>DHCP won't bite.</strong> Use <code>nmtui</code> and set a static address. The installer doesn't care how the link comes up, only that it does.</li>
<li><strong>Slow fetch.</strong> When <code>SOURCE_MIRROR</code> is set it's tried first; upstream is the fallback. A broken mirror yields timeouts — fix or unset <code>SOURCE_MIRROR</code>.</li>
</ul>
<h3>Fetch</h3>
<ul class="features">
<li><strong>404 on a download.</strong> The recipe's <code>url</code> missed a version bump. Fix it or report it — sources are pinned in kama-packages.</li>
<li><strong>Checksum mismatch.</strong> The tarball in the cache doesn't match the recipe. Clear the cache dir for that package: <code>rm -rf /var/cache/kama/dl/&lt;pkg&gt;</code>.</li>
<li><strong>Mirror poison.</strong> If a third-party mirror serves a tampered file, fetch fails verification and refuses to proceed — by design.</li>
</ul>
<h3>Build</h3>
<table>
<tr><th>Symptom</th><th>Cause / fix</th></tr>
<tr><td>Compile error in a package</td><td>Often a <code>C(FLAGS)</code> interaction or a missing build dep. Add the dep and re-run <code>kama make</code> — stage dirs cache progress.</td></tr>
<tr><td>Missing header</td><td>That's a temp-dep gap in the recipe's <code>deps=()</code>. Contribute the fix: one line in kama-packages.</td></tr>
<tr><td>Toolchain failure</td><td>Stage 0 is the sharpest edge. A failing binutils/gcc/libc bootstrap is a bug — file it with the full <code>make.conf</code> combo.</td></tr>
<tr><td>Kernel build dies with no reason</td><td>Free disk or memory on the build host first; kernel builds are hungry. Then check <code>KERNEL_CONFIG</code> in make.conf.</td></tr>
</table>
<h3>Finalize and first boot</h3>
<ul class="features">
<li><strong>mkfs fails.</strong> The target device is in use or the filesystem tools for your pick are missing. Unmount and retry.</li>
<li><strong>Won't boot.</strong> The init you chose must agree with how your bootloader was told to run it — check the boot command line and your init's expectations.</li>
<li><strong>No network after boot.</strong> Your network tool choice (nmtui alone won't auto-connect) needs to be started on <code>default</code> runlevel or its service enabled.</li>
<li><strong>Unstable combo.</strong> Keru warns on unproven pairs (musl+systemd, uclibc-ng, zfs root ...). Heed the warning or expect rough edges. It never blocks you.</li>
</ul>
<div class="callout">When you file an issue, include the stage, your full <code>make.conf</code> combo, and the failing output. That's everything a maintainer needs. See <a href="contact.html">contact</a>.</div>
<p><a href="getting-started.html">← Getting started</a> · <a href="security.html">Security model →</a></p>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">See the <a href="sitemap.html">sitemap</a> for all pages.</div></noscript>
<script src="assets/js/include.js" data-base="."></script>
</body>
</html>