Seth Woolley's Blog

Occasional Musings

source mage simpler introduction(0)

Source Mage GNU/Linux

Source Mage is a free and open source project founded on the principle of returning control back to System Administrators.

Our main project, Source Mage GNU/Linux, is an operating system distribution.

We also provide a complete ports-like system with a package management system based on our philosophies of software freedom and returning choice to the administrator.

The package manager is written almost entirely in bash. The ports are intended to be as close as possible to the upstream vendor's vision from source code as downloaded from their website.

The distribution is provided with an easy-to-use basic system installer from which administrators can rebuild to their specification.

The package management core is first-tier, feature-complete, and well-designed.  Custom configuration is exposed at every opportunity for the needy administrators and tweakers of all kinds.

Port scripts are easy to write because of a rich set of libraries and interfaces into the package manager that is balanced with the need for simplicity for simple packages.

The community of developers and users also offers friendly chat rooms, mailing lists, a bugzilla database, and freely viewable and modifiable source code.

All flaws are open and available for review or improvement, and contributions are accepted and guided through peer review and compliance with our core principles and policies.

For ease-of-learning, the command names are based on a sorcerous metaphor of "cast"ing and "dispel"ling "spells" from a "grimoire".

If you're ready for GNU/Linux so advanced, it may as well be magic, then it's time you tried Source Mage GNU/Linux.  http://www.sourcemage.org/

Seth Woolley's Blog sourcemage

source mage introduction(0)

Source Mage GNU/Linux

Source Mage is a free and open source project founded on the principle of returning ever-eroding control back to System Administrators.  Our main project, Source Mage GNU/Linux, is an operating system distribution that also provides a complete ports-like system with a unique and powerful package management system based on our philosophies of software freedom and returning choice to the administrator.

It is written almost entirely in bash, the default shell for most GNU/Linux administrators, so it can be easily modified and extended without recompiling. Every package port is intended to be as close as possible to the upstream vendor's vision and is entirely built from source code downloaded from the respective upstream websites.

The distribution is provided with an easy-to-use, minimalist-oriented, disabled-by-default installer from which the system can be rebuilt entirely from source to your platform with a simple set of commands, is FHS-2.2-compliant for easy software porting and use as a developer platform, and has extensive quality-control processes in place for ensuring that the package collection remains advanced, yet reliable.

The package management core automatically (with sane defaults) prompts and resolves for complex dependencies such as optional dependencies, suggestions, triggers, and sub-dependencies, prompts users for alternative and useful configurations settings (compile-or-run-time), maintains system integrity with a "self-healing" system cleanse  tool, and is unparalleled in its simple, modular design and approach to modern package management designed around "tweakers'" use cases, for example that its approach to uninstalling is dependency-aware and (thusly) can even suggest other likely targets for uninstalling.

Package scripts can be created flexibly as the package manager provides a framework for extensible APIs that is script-oriented through-and-through.  Code re-use through rich library support allows script parsimony and ease of maintenance.  Many packages simply require two files, a DEPENDS file and a DETAILS file, if they follow standard gnu autotool build methods.  As many packages need processes that aren't standard at each and different stages, more files can be "created" in the package directory to override the default processes, replacing them completely or even expanding upon them.

The community of developers and users also offers friendly chat rooms, mailing lists, a bugzilla database, and freely viewable and modifiable source code.  All flaws are open and available for review or improvement, and contributions are accepted and guided through peer review and compliance with our core principles and policies.  For ease-of-learning, the command names are based on a sorcerous metaphor of "cast"ing and "dispel"ling "spells" from a "grimoire".

If you're ready for GNU/Linux so advanced, it may as well be magic, then it's time you tried Source Mage GNU/Linux.  http://www.sourcemage.org/

Seth Woolley's Blog sourcemage

why not gentoo?(0)

Essay

Many people have asked me why not use Gentoo instead of Source Mage?

Full-disclosure: I'm a Source Mage developer, but if I thought I could get work done with the larger party, I would have jumped ship a long time ago.  Here are some of the things I can't accept about Gentoo.

  • Gentoo's public freenode channels won't accept questions or suggestions about how things are done in Gentoo.  Compiling this list has been ever difficult becuase of their behavior, and that in itself is a major reason not to use a distro.  Granted, I'm straightforward, but that's no reason to ban somebody.
  • Gentoo's release engineering process isn't.  I have a few problems with it, notably that they publish from a live tree and have zero QA control over it.  A notable Gentoo developer was ejected from the team after bringing up a number of issues with their process that could be improved.  They only listened to some of his suggestions and ignored the most important ones.  When he continued to bring up issues, he wasn't treated well and returned the favor, giving them justification to ostracize him.  Some of the issues are:
    • Gentoo uses a "live tree".  Wow, nobody in their right mind would do this.
    • Gentoo doesn't have a quality control system other than individual package masks.  This is a major problem because intra-version interactions can never be controlled and deployed until after the fact.  Testing is not an atomic process in Gentoo since they work from a live tree.  Either of this or the point above on their own wouldn't be so bad, but the combination is deadly.
    • Gentoo doesn't test packages in a formal way.  Developers are merely supposed to judge this for themselves.  This wouldn't be too bad, except for the fact that, yes, they use a live tree.
    • Gentoo has lots of packages, many of which are stale.  Their package versioning system leads to a larger tree with increased staleness and more testing requirements.  I suggest a way to indicate versions that aren't stale, or that are officially supported and/or tested with the latest bits on the live tree.
    • Gentoo has few policies to control quality on their ebuilds.  Rather than have process bugs lead to policy changes, developers are allowed to run amok on the source tree.  One platform is able to annihilate the quality of another platform (happened with the OS X porting team recently).  This kinda goes back to general release engineering policies, but it applies to other policies as well.
  • Gentoo doesn't rearchitect parts of their system that need rearchitecting for a few reasons: the initial developers are gone and changing their code is risky, especially since it's undocumented; while portage is written in Python, it was a learning project for drobbins, who essentially was clueless on how to leverage object-orientated design-techniques in his code writing; ebuild maintainers are famous quibblers, who hold back needed changes.
  • Gentoo developer relations team is composed of non-techies who take it upon themselves to interfere with technical discussions by eliminating developers who have the wherewithall to understand how to criticize a system.  Eliminating sources of critique leads to ignorant fanboyism -- the fanboyism that gentoo users are utterly famous for.  This was brought to my attention to Gentoo developers themselves, some of whom left the project, others still are there (one even is still in developer relations supporting the status quo as usual).
  • Gentoo doesn't really like to enable choices if that means a fundamental change is needed.  Take for example the constant question: when is the next kernel release going to hit the tree (live trees are great!)?  Gentoo portage tracks the size of each tarball as well as the hash so a developer can't write an ebuild to support arbitrary versions that authenticate source integrity with gnupg keys automatically.  I was banned from freenode's Gentoo channel for suggesting that this was a limitation that was unneeded.  The response was that it was faster -- while it isn't really.  I was banned before I had an opportunity to explain myself -- while an IO-bound operation is happening the overhead to compute a checksum is negligible, and the IO has already been cached in the VM-layer by downloading it, that the time wasted is so small compared to the flexibility, and remember that there's only time saved if there's an error.  Bailing out with an error sooner rather than later isn't much help if there's still a problem -- sooner as in a second or two on average.

That's just my issues with Gentoo behavior and release engineering.  There are other issues I have with the distro of a technical nature that I won't go into for now, since my expertise is really release engineering.  I'm sure others can pitch in where I left off (or check out http://www.sourcemage.org/Gentoo ).  Everything I mention here as being a problem is not a problem with Source Mage.  We chose to ignore what Gentoo was doing despite their popularity and simply ended up with a better system.

For example, when newbies claim that upgrading Gentoo broke their boxes, they are told to read the docs -- why do they need to read the docs for simple upgrades?  The system shouldn't let itself get HOSED by a simple update.  Sure, break a service or something and that's no big deal, but absolutely HOSE the system due to a g++ ABI change is a simple matter to fix -- well, it might not be so simple if you're using, say, Portage, written in Python that may be optionally linked to g++.  Source Mage lets the package maintainer have so much control that they can actually integrate in almost anything they'd need and override virtually every default action in sorcery to keep an update working while not requiring user intervention, even in the case of the most dangerous updates, like glibc, ncurses, bash, (and Python).

In theory, http://paludis.berlios.de/ might be able to replace many of the problems with Portage, but only if the Gentoo developers are willing to accept this drastic a change.  I haven't looked into it too deeply, but it looks as if it's better architected and immune from a number of the existing problems.  Let's hope it doesn't introduce many other problems already solved by Portage.

Seth Woolley's Blog sourcemage

sourcemage conversion of md5 to sha512 95% complete(0)

Update

I've spent the last few days mangling the entire grimoire over to the new unpack_file API for validating sources using high bit hashes:

http://wiki.sourcemage.org/Source_Integrity_Checking_Standards

A few sed and perl scripts and waiting for the SCM to resolve changes between integrates and now it's mostly done.  I have a few leftover spells that I don't have source files for that I wasn't able to regenerate the proper SHA512 for it.

In other news, now I'm third place in the grimoire bullet rankings: http://smgl.positivism.org:8080/files/smgl-credits

Seth Woolley's Blog sourcemage security

Linux Weekly News Article Published(0)

Article

I got published by Linux Weekly News!

You can read it here: http://lwn.net/Articles/145993/

It's about Source Mage GNU/Linux http://www.sourcemage.org/ , for which I am the QA Team Leader.

Seth Woolley's Blog sourcemage