The end!
Okay, my dissertation is done. Apart from adding a few preformatted bits to the bibliography and looking at the final paragraph ONE LAST TIME to make sure it's okay I am finished. Bed for a few hours now, and then I go to print the evil bastard.
Yay.
Rest.
I cannot remember what it feels like.
Seventh NetBSD Reply
shane,
On Thu, Sep 25, 2003 at 11:38:36AM +0100, Shane M. Coughlan wrote:
> Dear All
>
> I am currently developing a mock-up system that will be using a *BSD distro
> for an automated install. The system wil have a carefully selected set of
thats an easy bit to do.
> packages, but will not be intended to do a 'Linux' and litter the place. It
> will be built to boot into a GUI (test machines will run KDE 3.1.4 with
> XFree), and to do so automatically after install. KDE will include KOffice
> and OpenOffice on the test machines.
thats a bit of heavy duty code reviewing ..
> The brief is to create a minimal Unix system based on a solid core. It
most of the bsd will do that, pity bsdi bit the dust and is no longer
doing buisness, this project would be much easier with them on board as
a partner.
your probably think 'where is this moron going with all of this
just hang in a bit more ... ok.
> would be intended to run desktop machines and workstations, and to be
> a small and light as possible. It should have the option of
> installing a 'server kit' module to put all the bits needed to run an
> Apache server onto it, and it should be ready for the development of
> a 'security kit'. The security kit is the key part.
ok, this is were the rubber hits teh road, teh petrol vapour gets
compressed in teh cylinder chamber and teh coil gets ready to deliver
teh ignition spark ... its alive, its alive ... sorry about that its
early in teh morning and i get a bit melo-dramatice about this time of
day.
> It is intended for the commercial development
commercial development, not a problem anybody with a computer, a desk a
quiet room in teh house attic, or out the back as we in australia like
to put our garage converted, sheds, work rooms, hide away from teh
wife, kids and so on. oops nearly forgot stinking hot nas, or is it san
server in teh corner to hold the gui dev kits to cover the microsoft
basic elements ... oh you said unix, ummm even teh militry uses
microsoft why do you think they have so many publically embarasing
glitches, just do some search of teh public archives no, not google,
rather teh real meta data searching servers ... sorry i cannot remember
the 3 or 4 that exist in australia, but just find a reasonably good
university site and start difing through the toolkits and you will
eventually find it .. its used by teh phd students and thier revieers
to check the work being done/handed in etc etc.
if you want i'll dig up the article and fwd'd it you latter, after i've
woken up, yes ?
> of military-grade
this is teh real question, do you ... i'm not meaning to offend you,
but to this point in time you have not made any noises that sound like
you mifht have even a basic understanding of what you are involved in
or getting ready to do ...
militry-grade do you know your orange or for that matter blue and or
white book securityu levels, and how they are expected to be
implemented, and, the bigest killer especially if you expect to
actually sell your dev kit to virtyally any militry or for that matter
govt entities that have anything to do with the militry at any level is
to have your software security grade c3 certified ...
microsoft nt is certified c3 secure so that it can be sold to militry
org's and govt dept's that work with militry orgs and or have need of
security clearences ... oh the small print that most peopl fail to read
is that nt is c3 secure as long as it is not connected to anouther
computer by an form or networking .. i think that, that means 'sneaker
net' or even by serial cable and absolutely not by any form of tcp/ip
or netbui/netbios or whatever microsoft called their netmanager
software kit all those years ago.
umm you see non of teh bsd's are certified secure at any orange book level
even c3 etc, etc, etc al all. to do this requires lot and lots of
money. numbers in teh hundred of thousands last time i looked at this a
decade or two ago.
are you still interested ???
> defensive and offensive tools.
> It's a conceptual puzzle at the moment, though I hope to have perhaps a test
> machine active before the end of October.
conceptual financial and educational puzzle, one need find out what
kind of environment one is swiming in before they get too far from
shore, the return might prove to be fatal.
i used to be a system analyst, now i am a full time card carrying
invalid pensioner. i worked with people doing govt contracting,
development in national importance infrastructure projects and a few
other stuffs that i had to sign our national (fedral govt) secrets acts
which lasts for some 50 years after i have died ... i'm 50 odd now and
still going stron inspigth of the doctors, my invaliding disabilities
and other bits and piceses here and thier.
ummm please excuse teh typing i've been a practicng dsylexic for some
51 yeasr now, what teh dsylexia misses the damaged neurology rounds up
and managages to mangle into a pretty meaningless mess ... grin.
with kind regards and best wishes.
sincerely
jonathan
My reply:
Well, firstly I'm not even slightly interested in the US or primary European
markets (or Australia). These countries can afford to spend a whole
kaboodle on software like NT. I'm looking at developing nations.
Secondly, I do have a relatively high awareness of network and system
security. Enough to know it's a muddle (understatement). My current
university work is on cyber warfare.
Thirdly, I have looked at these books before, and must say that I conclude
they are not very useful. The world is networked. The computers we will
use are network. Warfare's future is networked. I think we need to work
from there.
I'm interested in developing a 'clean' base system with high ease-of-use and
then trying to get sponsorship. Unix with niceness, if you will. The idea
is that you can bang it on computers easily (to upgrade existing machines),
and drop in a highly secure module for network operations. I envision
sandboxes being of more and more important, and I have a concept for signed
and encrypted file sharing that should provide a framework for LAN and WAN
(at the same time with different access for different people) systems. The
key would be getting all the machines running the OS and security module
(even if they were too low-powered to run the GUI) so that they could be
part of the trusted network system. I don't like the hardware (US
dependent) security coming with Windows Longhorn. I think we'll need
something else.
Regards
Shane
Musing about creating a new operating system
This was originally posted on my personal blog on the 12th of September:
I continue my musing about the construction of NextGEM, a Unix-based OS for i396 and perhaps other platforms (PPC?). The idea is to try and impliment the ease-of-use design principles of GEM into the Unix platform, and to marry it with high security.
Q: Why do we need another operating system?
A: Windowsis still bug prone, insecure and closed. Linux is still too hard to set up and use (and it's too targeted at geeks and technical types), and MacOS is too limited regarding the hardware it will run on.
Q: So what type of operating system do we need?
A: We need something that works on multiple layers. It needs to have a small, portable and stable core. It needs to be highly secure and expandable. It needs to have an interface and functions that make it as transparent as possible to the end user. It needs to be MacOS meets military-grade Unix, with the flexibility traditionally found in the i386 platform.
Q: How can something like that be built?
A: By building on existing and proven opensource technology, and introducing closedsource improvements to allow for market capture. An example is to use something like NetBSD to create a core, Xfree86 and KDE on top for the enviroment, OpenSSL and GnuPG providing security and so on. Two versions of the operating system could be created. An opensource version and a special 'high security' version. This way the operating system can be developed in the opensource community, and at the same time special closedsource security modules can be added for commercial sales.
Q: Wouldn't this make it yet another closedsource operating system?
A: No. The operating system would be opensource and highly secure without the closed modules. The closedsource modules would be intended to meld military security with ease-of-use, and would be targeted at governmental and military users. Given the portability and multilingual nature of NetBSD and KDE, many developing nation's could be targeted, and healthy revenue obtained without making the end user suffer.
Q: So it would be an easy-to-use Linux with high commerical potential?
A: Well, basically yes.
I have decided to play with NetBSD as the core of this OS, as NetBSD seems to be small, supports many systems, and is highly secure (and proven).
Now I am thinking about what to load on my test machines. Initial thoughts lead me to conclude that two models should be tested. They are as follows:
Model one - High power, integrated interface (including encryption)
NetBSD
(on BFF? Can it run on XFS? What about Reiser4?)
XFree11
KDE
KOffice and tools
GnuPG
Snort GUI
EFS? (encrypted FS?)
Model two - runs on slower machines, application directory potential
NetBSD
(on BFF? Can it run on XFS? What about Reiser4?)
XFree11
Sawfish
Rox desktop
Abiword and other Gnome tools
GnuPG
Snort GUI
EFS? (encrypted FS?)
The idea is to create a minimal system, work out to make it do an automatic install, and try to create a boot CD. This would comprise release 0.2. At this stage I'd like to do testing and iron out bugs. It would be a public test release. The question is which model to follow. That's where 0.1 comes in. That'll be where I privately evaluate both systems, and decide which offers the greatest degree of ease of use and stability. Perhaps others would be interested in helping out during this evaluation stage?
Anyway, I have NetBSD 1.6.1 now, so that's what NextGEM 0.1 (0.2 etc) will be based on. Before release 1 of NextGEM is out NetBSD 2.0.0 may have arrived. I'll keep it in mind.
Testing testing testing. And configuring. It's early days yet (and NetBSD documentation stinks).
Sixth NetBSD Reply
My last three firewalls deployed in a commercial environment have been
NetBSD. YMMV. :)
Cheers,
Al
Interesting. Seems I have proof it can do commercial stuff.
Fifth NetBSD Reply
Here is number five:
I don't know that I would break down the differences between NetBSD and
FreeBSD as being primarily "academic" and "commercial" in that sense.
I think NetBSD could be a very excellent base for your project. However
there are some known limitations w.r.t. hardware support in
NetBSD-1.6.1, especially on i386, and for those reasons FreeBSD may make
a more practical base for your project.
(I use NetBSD as the basis for similar types of projects, though my
applications are much more server oriented and I also desire much more
architecture independence than FreeBSD currently offers.)
--
Greg A. Woods
My reply:
I may regret asking this, but what known limitations are likely to come and
bit me (especially on the i386 flavour of the system)?
I notice a problem with ISA network cards and a USB setting in BIOS which
can cause trouble, an issue with monitors going to standby and PCMICA model
problems (all fixable)...is there something else?
Regards
Shane
http://gem.shaneland.co.uk
Another quibble
Now Ben, the main programmer:
But why is it called NextGEM? It has nothing to do with GEM!
Regards,
Ben A L Jemmett.
My reply:
Because the GEM code does not allow me to go where I want to go next, but I
don't want to leave GEM behind. I think the code on which GEM is based is
far too limited to give it an application on today's machines, but I am not
prepared to abandon the system I have worked on because of that.
There are many design elements of GEM that I like, and that I wish to bring
towards Unix. This has a lot to do with the look and function of the GUI.
It's something that you can pick up in no time. I plan to edge towards that
with KDE theming. Secondly, I do not want to shelve all the time spent on
OpenGEM when I switch to this new project. OpenGEM will continue, and will
run on NextGEM. Perhaps I can even get GEM apps running on NextGEM (when
you try to run them a script called DOSEMU to start GEMVDI and the APP).
Think MacOS 9 > MacOS X. It was a complete technological replacement.
Ditto. The difference is that I also plan to continue developing OpenGEM.
Regards
Shane
http://gem.shaneland.co.uk
Fourth NetBSD Reply
Here is the third reply from the NetBSD mailing list:
Three things you may wish to look at in NetBSD-current:
* verifiedexec - upload fingerprint of binaries that may be executed into
the kernel. binaries whose fingerprints do not match cannot be executed.
http://netbsd.gw.com/cgi-bin/man.cgi?veriexecctl++NetBSD-current
http://netbsd.gw.com/cgi-bin/man.cgi?verifiedexec++NetBSD-current
* cgd - disk-based encryption
http://netbsd.gw.com/cgi-bin/man.cgi?cgdconfig++NetBSD-current
http://netbsd.gw.com/cgi-bin/man.cgi?cgd++NetBSD-current
(if you want "users" to encrypt individual files then you probably
don't gain much in using tcfs instead of gpg.)
* systrace - security policies for individual processes.
http://netbsd.gw.com/cgi-bin/man.cgi?systrace++NetBSD-current
http://netbsd.gw.com/cgi-bin/man.cgi?systrace+4+NetBSD-current
Also, -current has a non-executable stack, and other regions, depending
on what architecture you are using.
> Now, my question...I was drawn to NetBSD because of its small size (not much
> package litter in basic install...wonderful) and its portability. However,
> I notice the consensus online appears to be that NetBSD is mainly for
> academic use, and that FreeBSD is better for commercial use, especially
> things like servers.
http://www.NetBSD.org/gallery/sites.html
"what consensus?"
Not everyone likes where I am going...
Here is a message I just got from Gene Buckle, the guy who got the DR GEM code GPLed in 1999...he does not like the idea of moving from GEM (my OpenGEM project) to Unix and calling it GEM. Or so I think...here is his text:
So instead of improving GEM and making it more capable, you're going to
use unix and KDE and _call_ it GEM. How astonishingly lame.
g.
My reply:
Oh no! Oh no! There is a cunning bit you see...OpenGEM will continue as
the 16bit OS I'm working on, and the Unix will be my 32/64bit toy for a
specific purpose (high security computing). At the moment the guys at
www.maxframe.com are playing with OpenGEM to get it working on REAL/32, a
32bit DOS, and I am monitoring FreeDOS32. If the userbase of low-end
machines needs it I will be continuing OpenGEM as a more mature 16bit system
(remember, soon it becomes one with FreeDOS and is a full OS distro), and
then it'll become a 32bit distro that will run very well on 386 machines
with 2megs of RAM. If Ben and co get multitasking working sometime (hint
hint) it would be great.
I think GEM is limited as a GUI, but useful. I think it has a life BUT not
on high end hardware.
I think *NIX systems are too hard to set up and maintain and that the
advantages they offer are almost overshadowed by this.
I think I can address both these problems.
OpenGEM for the first one
NextGEM (Unix) for the second.
Once I have NextGEM running I will be getting it to run OpenGEM through
DOSEMU. I will also be working to get some filters made to convert docs
made in OpenGEM applications to stuff that can be read by KOffice and
OpenOffice. The EVENTUAL idea would be to have two systems (one for low low
end hardware and one for more powerful hardware) that can interact well with
each other.
Some of the framework for this has been accomplished in another way by Heinz
lately, as we had a request for networking with OpenGEM. He got networking
running fine with OpenGEM 2.1.0 and GEMWeb using MS Client.
You see, I am pushing for a complete development model. I would not call it
lame so much as necessary.
Regards
Shane
http://gem.shaneland.co.uk
Third NetBSD reply
Here is the third reply from the NetBSD people over the NetBSD vs FreeBSD question:
First, this sounds like an interesting project and I wish you the best
of luck with it.
As for your question FreeBSD vs NetBSD: Given that your goal is to have
a bloat-less system, I would think it would be easier to fork your
project from a highly portable bloat-less "acedemic" system like NetBSD
than trying to pare down a bloated "commercial" system like FreeBSD.
Second NetBSD reply
I just got another mail from NetBSD people:
If you want it to have light and small KDE is definitive the wrong desktop environment. I recommend using of ROX (rox.sourceforge.net), it's light, very fast, elegant and have a very smart DND concept.
Best regards, Tilo
Here is my reply:
That's interesting! I actually started looking at ROX before I came to KDE. However, the problem with ROX is that development seems to be a little bit messy, and though AppDirs are lovely (and I personally want them) there is still no way for applications to know what else is installed on the system. This makes everything very isolated, while I think is really the wrong direction to go in these days. Also, GTK and the Gnome enviroment does not have the same neat design regularity that KDE has, and I feel this is very important to the end use. ROX is still very much something under development, while KDE is mature. As I am targeting end-users, and absolutely NOT targeting people who want a development enviroment, I feel ROX would be the wrong way to go. KDE can offer me (a slight big and slightly slow) integrated, common and tested enviroment with a clear planned progression and fix bug fixes, especially in the security arena. It's a compromise that I feel needs to be made to allow people to have a 'safe' desktop enviroment. Also, the Qt license is more appealling for commercial development.
Regards
Shane
http://gem.shaneland.co.uk
Re: Secure Linux Distribution project
This is not going to interest everyone, but I keep coming back to a post I found on a NASA site about secure distros:
>On Thu, May 13, 1999 at 04:05:35PM -0400, J. Lasser wrote:
>
> Right now, I'm looking for a few things:
>
> 1. A list of other folks who've secured Linux distributions in the
> past and would be interested in unifying their work with others.
> It seems that most folk who have done this (myself included) did
> a lot of installation-specific stuff that could likely be
> generalized to some extent.
>
> 2. A list of other similar projects we should be corresponding
> with. Also, sites with information on how to do this are good
> too.
>
> 3. Anyone who wants to be on our mailing list (not yet created,
> but will be soon.)
>
> 4. Anyone who would like a leadership role in the project. PLEASE
> don't say you do unless you're really serious about it -- we've
> got a rather tight timeline and I don't want to mess around.
>
> 5. General comments, pointers, and advice are always welcome.
>
> 6. Anyone with lots of experience with the Red Hat installer. :-)
>
> 7. Anyone who'd like (okay, like's a pretty strong word) to
> maintain some web pages for this.
>
Hello, this is very interesting. I'd like to tell you about two
distributions that I've made that you've probably never heard about.
The first one is called GNSL and the other one is called Samsix.
The first one is a distribution that we made in the company I recently
worked for (we were bought) - called GNSL (www.guardian.no/gnsl/).
This distribution was based on Linux 2.0. It was mostrly used for
firewall setups. It included a lot of extra securelevel checks that
made the setup pretty "hardened". Really, you couldn't do much -
almost all interesting system calls were disabled and the files were
immutable.
Then Andrew came along with the POSIX.6 patches to Linux 2.0 and I
took those and ported them to 2.1, and they were later included in
2.2. I then started on a distribution that would rely on capabilities
instead of securelevel as a primary security mechanism. Using
capabilities, it is clearly possible to make a more flexible
distribution. Security is always a tradeoff, but with better tools
you can create a more flexible distribution while being able to have
the same level of confidence in the system.
This second system was made one year ago and was put in use around
August. Samsix is still the only distribution I know of that has used
capabilities at all! Today, Samsix is used for DNS, mail, web-server,
disk-server, and some experimental services like LDAP.
We made this distribution in cooperation with UNINETT which is a
Norwegian research organisation. Their customers are Universities and
other educational institutions.
So I've been involved with building some secure Linux-distributions.
Because of that I have used a lot of time thinking about secure linux
distributions, and I'm positive about one thing - building on RedHat
is wrong. This is if you want to make a secure _operating system_.
If you just want to provide crypto-packages or various improved stuff
(relay.com-domain), that's ok. But when I'm talking secure _operating
system_ you want to change the system from beneath. You want to:
o Crypto support
- In the kernel
- IPsec & friends integrated.
- Crypto in most applications
- Swap to encrypted partitions
- Boot from encrypted partitions (secure against physical theft)
- Tag certain partitions as encrypted
- Support smart-card readers, crypto-hardware.
o Patch programs to use various improved mechanisms.
- Secure logging/auditing, better syslog
- Use capabilities on daemons.
- Support MAC, Auditing.
- Modify libc in sorts of ways.
o Hardened features
- You need to be careful where files are put so that you can
have most of the system mounted read-only.
- Run with / read-only.
- Use kernel-features that others might not want to use such as
random PID and no-exec stack.
o Packaging
- Want to be able to require authenticated packages.
- Have a package-system which knows whether the source was
authenticated, where the patches came from etc.
o Have different defaults on configuration files.
o Have a system for caging processes
o Strive for B1 compliance
So I'm pretty sure that a secure linux will have
o Different packages
- because they contain crypto
o Different config-files
- because the audience is different
o Different startup-scripts
- because you want to support encrypted partitions, IPsec, VPN
o Different kernel
- because you need a lot of extra features
o Different libraries.
- because you use enhanced security features in the kernel or
outside the kernel
- because you use crypto
o Different file-structure layout
- because you want to support read-only mounting of various
file-systems
Also, consider that when a new distribution is born, there is an
opportunity of not being backwards-compatible. For instance, a new
distribution doesn't have to be compatible with /etc/sysconfig/*, but
can support linuxconf directly.
astor
--
Alexander Kjeldaas, Fast Search & Transfer, Trondheim, Norway
There is another post related to this at:Re: Secure Linux Distribution project. This guys catch my attention because they are thinking through a lot of the issues I am dealing with.
First NetBSD reply
Here's the first reply I got regarding the NetBSD vs FreeBSD:
Well, asking "NetBSD or FreeBSD" in such way on NetBSD list is quite
pointless ;) Of course, go with NetBSD. Why? Currently FreeBSD 5.x series is
very, very unstable[*]. Also I noticed, that FreeBSD 5.x in some areas is
going in the direction, where NetBSD was long time ago (rc.d scripts, for
example). NetBSD 1.6 seems to have a better kernel hardware support layer
(I'm not saying NetBSD supports more hardware, I'm just saying, that it
supports, for example, combo PCMCIA cards, while FreeBSD 4.x and 5.x can't).
Also, this might be a good thing: if you use pkgsrc to create packages for
your system, and if sometime you will have to create Linux-based
distribution of it (because of incompatible hardware, for example), pkgsrc
should also work on Linux (I haven't tested it with KDE, but postgresql +
apache + php4 compile and work very good on RedHat 8.0).
NetBSD 1.6 is also much less memory-consuming than FreeBSD 5.1[*].
KDE works very good on NetBSD for me. It's fast, it doesn't coredump too
often (I haven't tested KOffice too much, BTW). It is a good choice for a
GUI, but another good choice seems to be Xfce 4 (from pkgsrc-wip.sf.net).
The only bad thing is (only sometimes) the interactivity[*] of NetBSD. While
normal work (I use Xemacs + konqueror + glade-2 + xfce + mysql + php +
postgresql + apache) NetBSD seems to be faster, than FreeBSD 5.x[**] and it
for sure consumes less memory. But when I unpack a large tar archive to
compile some files, the system sometimes just stops for a second (I have an
old IDE HDD). As I said, this effect doesn't occur while normal work. I am
running on a default setup, I suppose it could be much better if I tweak it
a bit (renice XFree86 and some other processes).
Go for NetBSD, you should not regret it. It's clean, fast, small and doesn't
include much bloat (well, unless you count kernel sources for the
architectures you won't use ;).
Regards,
--
Michal Pasternak :: http://pasternak.w.lub.pl
Noise to meet you.
[*] Disclaimer: on my machine, on my setup.
[**] Disclaimer: I am talking about my subtle, inner feelings. For you it
might be totally different. No, we don't want to talk about it.
Touching base with the NetBSD crowd
I have made the first step in determining where I want the NextGEM OS to go by contacting the experts. I emailed the following to the NETBSD lists...and I guess I'll just have to wait n see what they say:
Dear All
I am currently developing a mock-up system that will be using a *BSD distro for an automated install. The system wil have a carefully selected set of packages, but will not be intended to do a 'Linux' and litter the place. It will be built to boot into a GUI (test machines will run KDE 3.1.4 with XFree), and to do so automatically after install. KDE will include KOffice and OpenOffice on the test machines.
The brief is to create a minimal Unix system based on a solid core. It would be intended to run desktop machines and workstations, and to be a small and light as possible. It should have the option of installing a 'server kit' module to put all the bits needed to run an Apache server onto it, and it should be ready for the development of a 'security kit'. The security kit is the key part. It is intended for the commercial development of military-grade defensive and offensive tools.
It's a conceptual puzzle at the moment, though I hope to have perhaps a test machine active before the end of October.
To make the test machine I was thinking of NetBSD 1.6.1 with an install that will call source packages of XFree86 4.3.0, KDE 3.1.4, KOffice 1.2.1 and OpenOffice 1.1.
GnuPG will be included and will be integrated into KDE using KPGP.
I think there will be two distinct stages to the development. The first is the creation of the test machine with the required packages. The second is working out how to automate the installation of the packages from CD. Knoppex Linux is an example of a nearly totally automated install. I'd like something along these lines.
The end result will ideally be a BSD which has a controlled amount of packages on it. One of the first stages of the security kit will be the creation of a file-checker to verify each of the applications and libraries on the system when it boots. Another will be the implimentation of automatic file-encryption in certain areas of the system. From a clean-install security measures will be built to create a system that is relatively secure. I am examining TCFS (transparent cryptographic file system) as a possible way of making sure user-files are safe, and I'm looking with interest at Reiser4, though I am aware that it's a LONG way from finished.
Now, my question...I was drawn to NetBSD because of its small size (not much package litter in basic install...wonderful) and its portability. However, I notice the consensus online appears to be that NetBSD is mainly for academic use, and that FreeBSD is better for commercial use, especially things like servers. Given that you guys are experienced in such things, and honest, can you tell me what you think about that? OpenBSD is interesting, but it seems to have a lot of hiccups with things like laptops. I'm not looking at it for this reason.
Regards
Shane Coughlan
http://gem.shaneland.co.uk
NextGEM and language support
Note: I think I should include KDE language support for:
English
German
French
Spanish
Chinese (traditional)
Chinese (simplified)
Japanese
in the first release of NextGEM (release 0.1). This will allow people to develop it and use it in a large amount of my target markets.
Because I am using KDE 3.1.x as my initial release GUI I could release NextGEM (KDE bits) in the following languages:
Afrikaans
Arabic
Bosnian
Catalan
Czech
Danish
German
Greek
British English
Esperanto
Spanish
Estonian
Farsi
Finnish
French
Hebrew
Croatian
Hungarian
Italian
Japanese
Lithuanian
Latvian
Maltese
Norwegian Bookmal
Dutch
Norwegian Nynorsk
Polish
Portuguese
Brazilian Portuguese
Russian
Slovak
Slovenian
Swedish
Tamil
Thai
Turkish
Ukrainian
Vietnamese
Chinese Simplified
Chinese Traditional
Zulu
I'm not sure about NetBSD. It only appears to have (differently formatted) documentation in English, German, Japanese and Chinese. I'm not sure if it includes both traditional and simplified.
I will of course also look into FreeBSD, but NetBSD seems to be the most portable option for me.
NextGEM site now active
The formatting for the NextGEM news site is now okay (though I will be changing the title from Shane Land OpenGEM to Shane Land NextGEM shortly; NextGEM is a complete replacement of OS and GUI system, not a continuation). This site will now serve as the home of the NextGEM project to create a easy-to-install-and-use Unix with the ability to run high security applications.
|
