This article relates to the Manux operating system, version 0.0.1. The reader is assumed to be familiar with the command line usage of another Unice.
Let's distinguish the main cases :
Well, that's bad. If the module is "ide", it means the module couldn't contact your hard drive. In this case, you can try using Linux to find your drive's ports, then force their detection in noyau/démarrer_ide.c. (Hey, you're a kernel hacker, aren't you?) Otherwise, well, try debugging the bug yourself, or report it to me. (Not sure if I will be able to do much if I can't reproduce it, though.)
Whoops.... That's very bad. And I know this is a possibility, because they are still bugs in the kernel that I wasn't able to reproduce (they occur very rarely, but disproportionately often during installation). Report it and retry; and if it's reproductible, try tracking it down... Sorry.
No it doesn't :-) . The installation of some packages is very long, and takes several minutes - just wait. (On the other hand, if it really hangs, then you've a kernel bug on your hands... And I never had this, so if you do, I have to suspect it's hardware-related. Try slowing down the "ide" module's I/O and see if this helps.)
What? It certainly shouldn't. Report me at which point it happens, and check whether it's reproductible or not.
That's perfectly normal, ignore it.
(Oh, you're curious as to why this happens? The installer is a standard Manux process, so it is chrooted. But there's no /packages in its chroot, because the Linux portion of the installer cannot create a directory hardlink, and the initial C code of the Manux installer only performs the strict minimum before executing the installation script. So /packages is passed to it as a command-line parameter. But /packages is not in /... , so the anti-collision algorithms had to give it a new name in /... , and they chose one composed of two unprintable characters. Then, for debugging purposes, this scripts prints out what it does, which includes launching commands located in /packages. So the two unprintable characters get written, and since my implementation of the kernel console doesn't object to printing what should be unprintable characters, you see these weird characters on the screen.)
You'll need good eyes to spot this, but it's true. Just after installation, when entering runlevel 2, the last init script fails. That's because the installer had to complete its task before, so the filesystem it tries to mount is already mounted. That's totally harmless, ignore it.
Very likely, but I've never tried it.
Let me guess... You're reading this without having tried it, aren't you?
Manux has no notion of a "root" user. Privileges, currently unimplemented, can be given to any user.
However, the basic principle under Manux is that access right implies use right - that is, if you can access a resource, you should be able to use it. (Not necessarily to write into it - but that's another issue).
As an example, under Manux, /etc/shadow has mode 666. This may sound like the most evil thing ever done in the world of the UNIX daemons, until you realize that no unprivileged user has direct access to this file. Instead, they can only alter it by using "passwd", which is clearly unproblematic. And, since the ability to launch a program doesn't imply the access to their chroot, they cannot use this to make arbitrary modifications to this file.
As an aside, this also explains why the SUID and SGID bits on executables are ignored : with this architecture, they are completely useless.
UID 0 corresponds to the "sys" user, and GID 0 to the "sys" group. These identifiers correspond to the operating system, and shouldn't be used by anybody else. Additionnally, these identifiers' usefullness has been deliberately reduced - they cannot execute any program that has a user-specific cache or a user-specific configuration (like vim or less).
This was done for two reasons. Firstly, no operating-system level program should have any part of its execution dependant on user-specific data; secondly, this prevents users from trying to use UID 0 anyways, as making it useable requires significant modification of the operating system. Manux is not a full and true UNIX, and cannot be used in the same way - even if it happens to have native binary compatibility with Linux.
Let's assume it lies on the partition Linux calls /dev/sda6. First, make a mount point :
$ mkdir mnt5
Then create a block file representing your partition :
$ mknod hd0,5 b 0 0
Theoretically, at this point, you should need to associate this file to the peripheral, but this isn't implemented for hard drive partitions, so a kernel hack identifies the partition based on its name - in other words, you have nothing to do. Then become admin :
Mount this partition :
# smount -t ext2 hd0,5 mnt5
and leave admin mode :
Currently, Manux can only mount ext2 partitions... But as it happens, ext3 is only ext2j, a journalized variant of ext2. You can safely mount it as ext2.
Other partitions, however, will remain unmountable.
Simple shell functions meant to avoid mistypings. They only add or remove /sbin and /usr/sbin from your PATH and change your prompt. In particular, they don't alter your privileges. You can safely modify them as you wish.
"smount" is a variant of mount that doesn't check the caller's UID. Yes, this is perfectly safe - under Manux, that is. Because if you can access a special file representing a hard drive in read-write mode, then you can mount it.
Uh... Sorry, that's currently unimplemented.
You need to use "./make" instead of "make". That's because make, being chrooted, has no access to the programs required to compile it (or anything else), so they have to be injected in its arborescence.
Curious about how it's done? See "cat ./make" :-) .
A technicality - as long as /dev/env/HOME isn't done, there's no way to make the MANPATH dependent upon the user's homedir. This is required, because we can't give a user access to arbitrary manpages : this would be an information leak (telling him/her that a certain software/version that he/she hasn't access to is actually installed).
# patch_kernel <module>
The script scripts/maj_noyau illustrates this very well (it updates the kernel with the newly compiled code. Don't worry, it's not called automatically).
If you want to play with it, try injecting the ephemodule "hw" (éphémodules/divers/hw.c), then use "test_sys".
# init 0 ; exit
# exec init 0
If you use a standard Anglo-saxon or German keyboard, there's already a keyboard map for you. During the installation, under Linux, simply specify --lang [de|en], and the required keyboard map will be loaded at boot time.
For the others, or if you notice that I've made an error in the aformentionned maps, I fear you will have to create or alter your map by yourself. The maps are located in the include/a0/kbd_maps directory of the kernel source, and the ephemodules that load them are the ephemodules/misc/kbd_* files. Once you've created a keyboard map and compiled a new kbd_XX epemodule to load it, simply perform a patch_kernel kbd_XX, and the keyboard will be reconfigured.
Good question. Let's distinguish 3 cases :
The first kind of data loss can and does happen, rarely, but it does. It can be caused by trouble with the hard drive module, ide (this issue has disappeared on my computers, but of course, this says nothing about yours), or by an impromptu kernel panic when you've typed something but not yet saved it (this has become excessively rare, and anyways, has never been a big deal).
The second kind of data loss did happen to me... Once, years ago, when I was debugging the ext2 module. It apparently actually lost me some files in my Linux distribution, but they shouldn't be that important, because I never found out what had been damaged in the first place. Since then, no, I personnaly never encountered the second class of data loss.
As for the third, well, what can I say... Beware of rm -rf, it tends to be effective on both systems.
That being said, the fact that I never encountered trouble in this regard is not a guarantee that you won't. And, since saving one's data is a good idea anyways, if you intend to use it on real hardware, you should consider doing such a backup (or using separate hardware if you have some).
Actually, the package format is really integrated with the system's architecture. For example, it uses the dependencies of programs to build their chroots, by creating the required hardlinks (including directory hardlinks) in their root. Thus, no other package format can replace it.
Again for technical reasons (although platform uniformization is also a motivation). Without placing the graphical server in kernel space, it becomes impossible to express things like "application A is allowed to to a screenshot, but not B, and as for C, it is allowed to do so, but when it does one, it has to be falsified so that it believes itself to be the only active application".
Additionnaly, graphical servers need to interact far too strongly with the hardware to be placed in userspace.
That being said, all these considerations don't exclude that the graphical server be made partly or totally compatible with an other one, be it X11, Wayland, Mir, or something else. On this point, I haven't studied their interfaces enough to say something.
Yes, it is. However, I only noticed it after learning about capability-based operating systems, so this wasn't the goal. That's also why it is so different from other capability-based OSes : it has several kind of capabilities, and is not strictly persistent. Also, it doesn't verify some usual properties of capability-based operating systems, because having a capability doesn't always imply the right to make a copy of it. That's because capabilities aren't evaluated independently of their user.
That's another of its particularities. If you want to describe it in terms of capabilities, Manux considers files to be resources, file names capabilities, directories capability sets, and chroot arborescences the set of capabilities of a program.
However, some things cannot be handled through capabilities, like the right to use link(2), as this would allow programs to make copy of the capabilities they are passed, or the right to bypass UID/GID checks. These will be implemented through UNIX-like capabilities, which aren't true capabilities but privileges.
Well, there isn't much right now, because I never needed any. I'll do it, but there's still so much to do...
By the way, I consider documentation to be part of the software, so if you want to contribute doing only documentation, that's fine with me. Simply, if you write a complete document, you'll have to state explicitely that you agree to its inclusion in the software, and its licensing under the Manux Licence.
As an aside, I've read some texts stating that documentation was the recommended way for women to involve themselves in a FLOSS project. I have to say I'm uncomfortable with this : women's programming abilities aren't inherently inferior to men's, but since practice is the best way to progress in this domain, such an approach will lead to a de facto inferiority, as well as an exclusion from the domain that genuinely interests some of them. So, dear girls and women, do documentation if that's what you wish, but if you prefer to do programming, fire gcc!
He who can do more can do less. If one can withstand a zero-day exploit, then one can also withstand an already-published exploit or handle an aggressive software. And, as the winner of the 2007 Underhanded C Contest, I can guarantee you that proof-reading the source code won't protect you against this.
Well, let's be honest : I think that in terms of security, the current situation of computing is catastrophic. The faintest problem in the smallest software can give access to all the data of a person! And everybody seems to think this is normal, as if nothing could be done.
And the disorder in the organization of userspace is obvious : an attacker can hide a file anywhere, they are unpackages files everywhere. Go figure what comes from where!
And the problems of compatibility between programs and between libraries are annoying, and the incompatibilities between distributions are a very bad thing for the free software world.
When I started it, I thought that, since nobody had ever done it, it should be impossible, and that, in the course of doing it, I would discover why. Well, nuts, it works very well!
When I realized this, I decided to finish it, and make it operational. We'll see whether it has success or not, but in any circumstance, I consider that it constitutes an important enough advance in operating system architecture to justify the efforts I put into it.
Index of the documentation