With the specs of the PSP, the punny little GBA will likely be emulated within weeks, and with the 802.11 and that juicy 32 megs of ram it will be able to run roms right off your windows box. The GBA has like 640K of ram.
There is tonz more info at http://help.orkut.com/
Here are some links from when you are logged in. They redirect to the home page if your not.
http://www.orkut.com/Friends.aspx
http://www.orkut.com/Communities.aspx
http://www.orkut.com/Search.aspx
http://help.orkut.com/
http://www.orkut.com/Logout.aspx
The goal of the MHS project is to define a Modern Hierarchy Standard for UNIX-like operating systems which will further enable them to evolve, innovate, grow, and compete with Windows and other modern OSes. Specifically, MHS technology will provide the following benefits: 100% Application Directory Oriented Internationalization of Directory Names More Intuitive Directory Names Fewer Root Directories Support for Case-Insensitive File Systems Full Coexistence with Legacy FHS Increased System Flexibility A new hierarchy will be a big enough change to make distributions switch to application directories. Set of environmental variables pointing the location of major system directories. Applications would no longer need to hard code directory names. System level directories grouped together under a common directory. (/System)
Currently, the directories are expected to be moved to the following locations:/bin =>/System/Commands/sbin =>/System/Commands/boot =>/System/Boot/dev =>/System/Devices/etc =>/System/Config/lib =>/System/Libraries/proc =>/System/Process/mnt =>/Mount/opt =>/Apps/tmp =>/Temp/home =>/Users/usr/bin =>/System/Executables/usr => mostly placed under/System/var => mostly placed under/System
All paths will be lower-case on a case-sensitive file system. As shown otherwise.
Application developers and distribution makers will need to use the/Apps directory rather than cramming everything into/usr.
The autoconf family of tools will be patched to support the new hierarchy which will make most applications translate easily.
Although it can still be done, MHS will not support the same level of shareability (i.e. mounted over a network) as the legacy FHS standard.
FHS can be emulated via symlinks and MHS can be emulated on existing FHS systems. A kernel/file system hack of some kind may be done to have the legacy directories disappear in directory scans, to help improve user friendliness.
In addition to the standard, the project is developing a set of scripts that will setup the new hierarchy on existing FHS compatible systems.
The standard will not be finalized until a Linux distribution ships based upon it.
The Unix tree rethought: an introduction to GoboLinux (Technology)
By LodeRunner
Lately, there has been lots of discussion on the current state of Linux as a desktop system, and articles pop up here and there, occasionally with very good ideas. However, none have surprised me more than this one. It was all very hyphothetical, but had pretty radical ideas on how the author thought the Linux directory tree should be reorganized. This was clearly the most polemical part of the article, and raised many discussions whether something like this could actually be implemented. And that's the reason for my surprise: we had this implemented for over an year. GoboLinux is a Linux distribution based on an alternative directory tree, which has evolved from a custom LFS installation to a distro that's used and maintained by a small group of people today. It was interesting to see that there are a lot of people interested in ideas similar to ours. So, maybe it's time for us to come out of the shadows.
A bit of history
We all remember the time when talking about Linux distributions for the desktop meant arguing which has the best installer. Much has evolved since: the easy, graphical installers are here, but we're not quite there yet. Among the usual rants on "why (insert pet peeve here) is the problem", some interesting ideas come up from time to time. More interestingly, some people started to believe maybe it's time for more adventurous attempts.
Oddly, GoboLinux did not start as one of those. The whole thing started when I had to install programs at the University. As I had no write access to the standard Unix directories, I created my own directories under $HOME the way I saw fit. I upgraded the programs from source constantly, and couldn't use a package manager. My solution was the most obvious one: to place each program in its own directory, such as ~/Programs/AfterStep. Soon the environment variables (PATH, LD_LIBRARY_PATH...) got bigger and bigger, so I created centralized directories for each class of files, containing symbolic links: ~/Libraries, ~/Headers and so on. A natural evolution was to write shell scripts to handle the links, configures and Makefiles.
This system proved itself to be very convenient to use. At my home system, I started to gradually remove pre-compiled packages and recompile them with those scripts. I was moving towards a completely custom Linux system, which I jokingly called LodeLinux. When I had it about 80% complete, the Great Filesystem Crash struck. It was time to start it all over again, but this time through a different route: instead of "deconstructing" an existing distribution, a friend (André Detsch) and I (Hisham Muhammad) spent two days building a modified Linux From Scratch system. Without much fuss, on March 20, 2002, GoboLinux was born. A month later, we presented an article at the 3rd. Workshop on Free Software called "A new proposal for the Unix directory tree".
What is it all about?
GoboLinux is definitely not "yet another Linux distro for the desktop". It is entirely based on an alternative directory structure. Every program lives in its own directory: you'll find XFree86 4.3 at/Programs/XFree86/4.3/, and ping at/Programs/Netkit-Base/0.17/bin/ping. To see what programs are installed in the system, all you need to do is ls/Programs.
For each category of files, there is a directory under/System/Links grouping files from each application as symbolic links: Executables, Libraries, Headers, Shared and Manuals. For compatibility, each "legacy" directory is a link to a corresponding category. Therefore,/bin,/sbin,/usr/bin,/usr/local/bin (and so on) are all symlinks to
Slashdot Mirror
Oh the irony is killing me.
The code name for C# was Cool. Java is so un-Cool.
Since Rutan and Co called the Space Ship One project Tier One, it makes sense that they are planning a tier two. Probably an orbital flight.
Knowing Rutan he's probably already got the design figured out for an orbital vehicle and has been running simulations of it.
Who knows, maybe there is even a tier three... the moon.
With the specs of the PSP, the punny little GBA will likely be emulated within weeks, and with the 802.11 and that juicy 32 megs of ram it will be able to run roms right off your windows box. The GBA has like 640K of ram.
There is tonz more info at http://help.orkut.com/ Here are some links from when you are logged in. They redirect to the home page if your not. http://www.orkut.com/Friends.aspx http://www.orkut.com/Communities.aspx http://www.orkut.com/Search.aspx http://help.orkut.com/ http://www.orkut.com/Logout.aspx
So, if the site is down, how the heck did you get a copy of the ISO?
Hopefully GoboLinux and LinuxStep will join the the MHS standard so that this kind of improvement can start to spread to other distros.
/bin => /System/Commands /sbin => /System/Commands /boot => /System/Boot /dev => /System/Devices /etc => /System/Config /lib => /System/Libraries /proc => /System/Process /mnt => /Mount /opt => /Apps /tmp => /Temp /home => /Users /usr/bin => /System/Executables /usr => mostly placed under /System /var => mostly placed under /System
/Apps directory rather than cramming everything into /usr.
http://mhs.sf.net
The goal of the MHS project is to define a Modern Hierarchy Standard for UNIX-like operating systems which will further enable them to evolve, innovate, grow, and compete with Windows and other modern OSes.
Specifically, MHS technology will provide the following benefits:
100% Application Directory Oriented
Internationalization of Directory Names
More Intuitive Directory Names
Fewer Root Directories
Support for Case-Insensitive File Systems
Full Coexistence with Legacy FHS
Increased System Flexibility
A new hierarchy will be a big enough change to make distributions switch to application directories.
Set of environmental variables pointing the location of major system directories.
Applications would no longer need to hard code directory names.
System level directories grouped together under a common directory. (/System)
Currently, the directories are expected to be moved to the following locations:
All paths will be lower-case on a case-sensitive file system. As shown otherwise.
Application developers and distribution makers will need to use the
The autoconf family of tools will be patched to support the new hierarchy which will make most applications translate easily.
Although it can still be done, MHS will not support the same level of shareability (i.e. mounted over a network) as the legacy FHS standard.
FHS can be emulated via symlinks and MHS can be emulated on existing FHS systems. A kernel/file system hack of some kind may be done to have the legacy directories disappear in directory scans, to help improve user friendliness.
In addition to the standard, the project is developing a set of scripts that will setup the new hierarchy on existing FHS compatible systems.
The standard will not be finalized until a Linux distribution ships based upon it.
Since the site is down, I found a story on Kuro5hin.org by the core developer of the distro.
/Programs/XFree86/4.3/, and ping at /Programs/Netkit-Base/0.17/bin/ping. To see what programs are installed in the system, all you need to do is ls /Programs.
/System/Links grouping files from each application as symbolic links: Executables, Libraries, Headers, Shared and Manuals. For compatibility, each "legacy" directory is a link to a corresponding category. Therefore, /bin, /sbin, /usr/bin, /usr/local/bin (and so on) are all symlinks to
http://www.kuro5hin.org/story/2003/5/9/05015/626 49
The Unix tree rethought: an introduction to GoboLinux (Technology)
By LodeRunner
Lately, there has been lots of discussion on the current state of Linux as a desktop system, and articles pop up here and there, occasionally with very good ideas. However, none have surprised me more than this one. It was all very hyphothetical, but had pretty radical ideas on how the author thought the Linux directory tree should be reorganized. This was clearly the most polemical part of the article, and raised many discussions whether something like this could actually be implemented. And that's the reason for my surprise: we had this implemented for over an year. GoboLinux is a Linux distribution based on an alternative directory tree, which has evolved from a custom LFS installation to a distro that's used and maintained by a small group of people today. It was interesting to see that there are a lot of people interested in ideas similar to ours. So, maybe it's time for us to come out of the shadows.
A bit of history
We all remember the time when talking about Linux distributions for the desktop meant arguing which has the best installer. Much has evolved since: the easy, graphical installers are here, but we're not quite there yet. Among the usual rants on "why (insert pet peeve here) is the problem", some interesting ideas come up from time to time. More interestingly, some people started to believe maybe it's time for more adventurous attempts.
Oddly, GoboLinux did not start as one of those. The whole thing started when I had to install programs at the University. As I had no write access to the standard Unix directories, I created my own directories under $HOME the way I saw fit. I upgraded the programs from source constantly, and couldn't use a package manager. My solution was the most obvious one: to place each program in its own directory, such as ~/Programs/AfterStep. Soon the environment variables (PATH, LD_LIBRARY_PATH...) got bigger and bigger, so I created centralized directories for each class of files, containing symbolic links: ~/Libraries, ~/Headers and so on. A natural evolution was to write shell scripts to handle the links, configures and Makefiles.
This system proved itself to be very convenient to use. At my home system, I started to gradually remove pre-compiled packages and recompile them with those scripts. I was moving towards a completely custom Linux system, which I jokingly called LodeLinux. When I had it about 80% complete, the Great Filesystem Crash struck. It was time to start it all over again, but this time through a different route: instead of "deconstructing" an existing distribution, a friend (André Detsch) and I (Hisham Muhammad) spent two days building a modified Linux From Scratch system. Without much fuss, on March 20, 2002, GoboLinux was born. A month later, we presented an article at the 3rd. Workshop on Free Software called "A new proposal for the Unix directory tree".
What is it all about?
GoboLinux is definitely not "yet another Linux distro for the desktop". It is entirely based on an alternative directory structure. Every program lives in its own directory: you'll find XFree86 4.3 at
For each category of files, there is a directory under