|
[SMS] - Superb Mini Server Project Support Forum |
|
|
|
View previous topic :: View next topic |
Author |
Message |
jacek4000 Member
Joined: 04 Oct 2008 Posts: 28
|
Posted: Sat Oct 04, 2008 10:25 pm Post subject: Will be there an 64 bit version like blue white ? |
|
|
Once I have seen an romanian distro blue white only for AND 64bit
procesor. Are you planning such a version ? |
|
Back to top |
|
gerasimos_h Site Admin
Joined: 09 Aug 2007 Posts: 1757 Location: Greece
|
Posted: Sun Oct 05, 2008 11:18 am Post subject: |
|
|
I know bluewhite distro, also Slamd64 is available for 64bit architecture.
I've thought it my self but not for now.
gerasimos_h _________________ Superb! Mini Server Project Manager
http://sms.it-ccs.com |
|
Back to top |
|
Shingoshi Junior Member
Joined: 05 Feb 2009 Posts: 6 Location: Salem, Oregon
|
Posted: Thu Feb 05, 2009 5:29 am Post subject: Re: Will be there an 64 bit version like blue white ? |
|
|
jacek4000 wrote: | Once I have seen an romanian distro blue white only for AND 64bit
procesor. Are you planning such a version ? |
I have just downloaded the latest version of SMS.Native.CD-1.4.1-Install.iso. I currently have Slamd64 installed on my big machine. I'm about to install this on another 32-bit machine to test the layout. If I am pleased with it, I will then start producing an SMS64. None of the other 64-bit Slackware variants are intended for server usage. And since this is my primary concern, I will develop this myself. This may likely occur though as a modified system. But if I find that I can easily produce two versions (one in standard form, matching the original intent/structure of SMS, and another utilizing my optimizations), I will do so. But the use of my optimizations are of higher concern to me.
I use this tool for building all of my packages:
http://distro.ibiblio.org/pub/linux/distributions/amigolinux/download/src2pkg/src2pkg-1.9.7-noarch-17.tgz
I definitely recommend it to anyone needing to build their own packages, as everything is done as the normal user, removing the chance of filesystem corruption. And the build tool is highly configurable. Read the /etc/src2pkg/src2pkg.conf and the package's documentation. It is unlikely you'll be disappointed with it.
Xavian-Anderson Macpherson
Shingoshi _________________ The immediate equalization of all knowledge among all beings. :: Shingoshi Dao |
|
Back to top |
|
gerasimos_h Site Admin
Joined: 09 Aug 2007 Posts: 1757 Location: Greece
|
Posted: Thu Feb 05, 2009 6:59 am Post subject: |
|
|
If you choose to create a 64bit version I'll try to support it as much as I can, as for your optimizations, you can suggest ideas to make SMS better, I'm open in suggestions.
I'm trying to make the best out of SMS, to satisfy every user.
gerasimos_h _________________ Superb! Mini Server Project Manager
http://sms.it-ccs.com |
|
Back to top |
|
Shingoshi Junior Member
Joined: 05 Feb 2009 Posts: 6 Location: Salem, Oregon
|
Posted: Thu Feb 05, 2009 7:36 am Post subject: |
|
|
gerasimos_h wrote: | If you choose to create a 64bit version I'll try to support it as much as I can, as for your optimizations, you can suggest ideas to make SMS better, I'm open in suggestions.
I'm trying to make the best out of SMS, to satisfy every user.
gerasimos_h |
I must be completely forthright with you. Most of what I want to do, is radically contrary to standard Linux conventions. I'm interested in creating a system which closely resembles a combination of GoboLinux and others which use AppDirs. Every package with the exception of the kernel (and a few others which require them not to be) will be self-contained. They would be mounted in memory to run when required, and unmounted when not being used. But this is still under consideration, due to some perceived difficulties.
My intent is to have a system which never obsoletes packages due to broken dependencies (mainly missing/removed libraries). Doing this, requires how files are stored on the system. While the package names will not change, all of the hyphens ("-") in any package name will be translated to "/". This will create groups of packages which have a common prefix, like gnome-*, to gnome/*/*. So the result is likely a complete departure from the FHS. I am right now in the process of defining how my filesystem layout will appear. And I'm pretty certain, you won't like it. But, I could be wrong. I'll post what I come up with here to show you. Although I've been working on this for a very long time, I keep updating my concept in light of difficulties or objections that are raised.
Basically, I'm wanting to use SMS as my development platform. Src2pkg (as previously noted) is what I use for all of my development work. It will be installed on SMS, and all work will proceed from there. Simply stated, this won't be a Slackware system. Although the packaging will remain compatible with pkgtools-tukaani. So you should be able to upgrade directly from any existing Slackware-based distribution to the one I'm developing.
The final result is that there exists a server which never has broken resources. It is also intended to provide clustering as a native feature. The ultimate goal here is to have a Public Technology Server. It would function like a public library, but directed towards the technology, research and development sector.
Xavian-Anderson Macpherson
Shingoshi _________________ The immediate equalization of all knowledge among all beings. :: Shingoshi Dao |
|
Back to top |
|
Shingoshi Junior Member
Joined: 05 Feb 2009 Posts: 6 Location: Salem, Oregon
|
Posted: Thu Feb 05, 2009 7:48 am Post subject: Here's a preview of what I'm intending to do... |
|
|
/admin # This is the replacement for /root.
/admin/exec # This is the replacement for /sbin and /usr/sbin.
/users # This is the replacement for /home.
/system # This matches the /windows directory on that other system.
/system/kernel # This is where everything that is part of the kernel exists. /boot /lib/modules kernel-headers kernel-source
/system/devices # The new /dev directory.
/system/libraries # The new /lib directory.
/system/config # This is the replacement for /etc.
/database # This is where all of the system databases are kept. MySQL, PostgresSQL, sqlite etc...
/devel # This is the new location of /usr/src, /include, and /usr/include.
/devel/include # Self-explanatory.
/devel/build # This is where the package builds are performed.
/devel/distfiles # This where all of the sources are stored.
/distccache # This is where the distccache directories for each package are mounted during compilation.
/packages # This is where all packages are held on disk, before being loaded into memory.
/runtime # This is where packages are mounted in memory to be run, and removed when done.
/share # This is where /doc, /man and everything else that would have been in /usr/share, will be now.
/www # This is where all of the system webservers will be configured to run from.
The /packages directory is the local package repository. The system will keep a list of all available packages in the repository. It will show the user whether the package is loaded (in memory) or not. Any package which is needed by any user would be loaded (installed) into memory under the /runtime directory. Packages will be created as a complete lzma-squashfs.iso. That package would then be mounted using loop and run in that manner. The package is then umount(ed) from /runtime when done being used.
A work in progress!!
Xavian-Anderson Macpherson
Shingoshi _________________ The immediate equalization of all knowledge among all beings. :: Shingoshi Dao |
|
Back to top |
|
gerasimos_h Site Admin
Joined: 09 Aug 2007 Posts: 1757 Location: Greece
|
Posted: Thu Feb 05, 2009 8:32 am Post subject: |
|
|
Well that's quite radical I would say, you want to rearrange/re-configure the whole linux tree environment.
I don't think though rearrange dirs will help with what you want to achieve.
Even Macs have /etc /usr /var dirs.
You want an app running independently, without any shared libraries, that can be done. If I 'm correct PC-BSD where having apps running from one and only directory. Macs do it in the past, newer do it but not for all apps.
Of course your vision or a part of it, might be the future of a linux system.
I'll try to help as much as I can with SMS packages.
gerasimos_h _________________ Superb! Mini Server Project Manager
http://sms.it-ccs.com |
|
Back to top |
|
Shingoshi Junior Member
Joined: 05 Feb 2009 Posts: 6 Location: Salem, Oregon
|
Posted: Thu Feb 05, 2009 9:40 am Post subject: |
|
|
gerasimos_h wrote: | Well that's quite radical I would say, you want to rearrange/re-configure the whole linux tree environment.
I don't think though rearrange dirs will help with what you want to achieve.
Even Macs have /etc /usr /var dirs.
You want an app running independently, without any shared libraries, that can be done. If I 'm correct PC-BSD where having apps running from one and only directory. Macs do it in the past, newer do it but not for all apps.
Of course your vision or a part of it, might be the future of a linux system.
I'll try to help as much as I can with SMS packages.
gerasimos_h |
I have to Thank You!!
That's a much better response than what I expected. In fact, based on my past experiences with many others with whom I've shared this, I'm really surprised.
Actually the applications will provide their libraries to other applications. The libraries just won't be in a single location. I'm currently working out the details of that though. I've had good feedback about why this will cause real problems. It might require that the user only install applications built specifically for the system. But that shouldn't be a real problem. Because everyone using the system (the entire user base for the distribution) will be participating in the compilation of packages. It would be kind of like a DISTCCACHE@HOME. The intent is to have running updates of the build system to each user, implementing x/deltas and rsync. The build system will reflect what's provided by Gentoo, ArchLinux and others like them.
Back to the library issue. Packages would be created like small iso's. They would be mounted to a common (/runtime) mount point on tmpfs. This will be done using bind, or loopback. Each package would write it's files into memory, creating an overlay of images all mounted to the same place. The system should be phenomenally fast. Yes, it would require systems with large amounts of memory.
My big server has 16GB, in which I also have /tmp mounted on tmpfs. This particular board I have (a Tyan S4980: http://www.newegg.com/Product/Product.aspx?Item=N82E16813151089) is a quad-socket foundation with 4 DIMM slots/cpu. Fully configured, it will hold 128GBs of memory. Not that I could afford that. I'm currently debating getting two more 1TB drives for that machine to do my devel work on it. Beware! The price of the processors to use all four sockets, is horrendous. Not for the faint of heart. And my heart is definitely faint.
I would also recommend this board (http://www.newegg.com/Product/Product.aspx?Item=N82E16813151070) as a great way to build a dedicated build engine. The price varies, but is right now at $60. This board will work well with these processors (http://www.newegg.com/Product/Product.aspx?Item=N82E16819105130). And you can't beat this price for memory (http://www.newegg.com/Product/Product.aspx?Item=N82E16820134652).
I also should point out to you, that it should be no real problem for me to create packages for SMS64 using src2pkg. Src2pkg can create $pkgname.src2pkg scripts which can be easily edited for multiple configurations. So what I do, won't eliminate my being able to help you with SMS. I would ask that you download the src2pkg package and test it. It will give you firsthand experience of how things will proceed. The author of that package is a very generous and helpful man. I've annoyed him with my ideas for a few years now. And some of them he has actually implemented into the code of src2pkg. Sometimes, I actually can some up with good ideas. Granted, sometimes they are a real stretch from the norm.
Thank You very much!!
Xavian-Anderson Macpherson
Shingoshi _________________ The immediate equalization of all knowledge among all beings. :: Shingoshi Dao |
|
Back to top |
|
Shingoshi Junior Member
Joined: 05 Feb 2009 Posts: 6 Location: Salem, Oregon
|
Posted: Thu Feb 05, 2009 10:34 am Post subject: |
|
|
gerasimos_h wrote: | Well that's quite radical I would say, you want to rearrange/re-configure the whole linux tree environment.
I don't think though rearrange dirs will help with what you want to achieve.
Even Macs have /etc /usr /var dirs.
You want an app running independently, without any shared libraries, that can be done. If I 'm correct PC-BSD where having apps running from one and only directory. Macs do it in the past, newer do it but not for all apps.
Of course your vision or a part of it, might be the future of a linux system.
I'll try to help as much as I can with SMS packages.
gerasimos_h |
This is where my /etc is on this system:
/system/config # This is the replacement for /etc.
/usr is likely uneeded, as it will be served by /runtime instead.
/var may be divided. But most likely it will be mounted under /system.
The three main distinct directories are /system, /packages and /runtime.
/system is where everything that's required for the operation of the system goes.
/packages is where the repository for all available packages are maintained. This is useful for local networks serving many computers.
/runtime is the location where each package is mount in memory using the tmpfs. Every package will be mounted here, in an overlay(ed) manner.
And granted, I could largely stick with the general Linux structure. But each package would be like a snapshot of the full system root. I'm thinking that maybe I should use tlz (a tgz using lzma compression) for the package format, in which the iso is contained to be installed later into memory. It's either that, or I need to have a modified pkgtools which handles installing the package into /runtime as the package's root. Haven't figured that out yet. So it's not cast in stone, as yet.
I think this is the easiest and most straightforward way of doing things:
installpkg --root=/runtime $@
Xavian-Anderson Macpherson
Shingoshi _________________ The immediate equalization of all knowledge among all beings. :: Shingoshi Dao |
|
Back to top |
|
Shingoshi Junior Member
Joined: 05 Feb 2009 Posts: 6 Location: Salem, Oregon
|
Posted: Thu Feb 05, 2009 1:30 pm Post subject: Just another point of consideration... |
|
|
As I continue to think this through, I keep coming up with new ideas. Here's a starting point I'd like to examine in detail. Do you think we can easily do this with SMS? https://wiki.ubuntu.com/BootToRAM
Here's a distribution which is dedicated to running from ram:
http://slitaz.org/en/
Would you be willing to start by making SMS capable of booting to ram, as described above. There are some other considerations to be made. For one thing, since SMS is a server environment, we really need to have rsync handling the backup of everything in ram to disk on a period basis. I've seen scripts for that using cron.
Xavian-Anderson Macpherson
Shingoshi _________________ The immediate equalization of all knowledge among all beings. :: Shingoshi Dao |
|
Back to top |
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You can attach files in this forum You can download files in this forum
|
|
|
|
SMS - Superb! Mini Server Project © 2016
Powered by phpBB © 2001, 2002 phpBB Group
iCGstation v1.0 Template By Ray © 2003, 2004 iOptional
|
|
|
|