Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Fri 18 Apr 2014, 04:14
All times are UTC - 4
 Forum index » Taking the Puppy out for a walk » Misc
Shahor 04052013
Moderators: Flash, JohnMurga
Post new topic   Reply to topic View previous topic :: View next topic
Page 2 of 3 [35 Posts]   Goto page: Previous 1, 2, 3 Next
Author Message
vovchik


Joined: 23 Oct 2006
Posts: 1285
Location: Ukraine

PostPosted: Thu 30 May 2013, 17:38    Post subject:  

Dear lguleder,

Thanks. I am still using 32-bit for most everything, but have a quad-core CPU, most of it just sitting there. Smile

with kind regards,
vovchik
Back to top
View user's profile Send private message 
Iguleder


Joined: 11 Aug 2009
Posts: 1775
Location: Israel, somewhere in the beautiful desert

PostPosted: Fri 31 May 2013, 10:43    Post subject:  

I haven't heard of any quad-core 32-bit, x86 processor. If you decided to use 32 bit software, that's up yo you already.
_________________
My homepage
Back to top
View user's profile Send private message Visit poster's website MSN Messenger 
ICQ Number 
vovchik


Joined: 23 Oct 2006
Posts: 1285
Location: Ukraine

PostPosted: Fri 31 May 2013, 13:42    Post subject:  

Dear lguleder,

I have got one of these:

Intel® Core™ i7-2600

and one if these:

AMD Athlon(tm) 64 Processor 3000+.

Am I in luck?

With kind regards,
vovchik
Back to top
View user's profile Send private message 
jamesbond

Joined: 26 Feb 2007
Posts: 1875
Location: The Blue Marble

PostPosted: Fri 31 May 2013, 14:14    Post subject:  

vovchick, I assume you're not kidding Laughing
The "64" in the your "AMD Athlon(tm) 64 Processor 3000+" definitely stands for something Laughing

Generally speaking:
- Any Intel CPU (not Atom) after CoreDuo supports 64-bit (that includes Core2 Duo, i3, i5, i7, generation 1, 2, 3 ...)
- Any Intel Atom CPU equal or newer than N450 onwards supports 64-bit
- Any AMD CPU equal or newer than Athlon 64 supports 64-bit ...

If you're not sure, visit this: http://www.cpu-world.com/.
Find your CPU there, then look in the "Features" page and see if your CPU has either AMD64 or EM64T - both means the 64-bit support.

cheers!

_________________
Fatdog64, Slacko and Puppeee user. Puppy user since 2.13
Back to top
View user's profile Send private message 
laurentius77

Joined: 30 Mar 2011
Posts: 60

PostPosted: Thu 05 Sep 2013, 16:31    Post subject: Any news about Shahor?  

I discovered Shahor yesterday. Iguleder is the guy that, in the past, posted a guide about compiling a Puppy kernel. Using his guide I was successful with that. After this I used his script in building kernels.
Shahor is great. It's very fast and runs perfectly on my ultrabook Acer S-391. It recognized my WiFi card and everything works like expected.
I didn't manage to mount any internal or external drive (USB or harddrive).
I will try to compile some applications because I understood that all the developers tools are in their place.
I hope Iguleder didn't abandon this great project.
I didn't try roar-ng ii but i think it has the potential to compete with woof.
For Shahor it needs more customization in order to allow the user to tweak settings, to remaster the distribution. For temporary remastering I have some ideas regard extract main .sfs, include the files and create .sfs again but a proper tool will be welcomed.
Thanks for all your effort and please keep going because this project has a great, great potential.
Back to top
View user's profile Send private message 
Iguleder


Joined: 11 Aug 2009
Posts: 1775
Location: Israel, somewhere in the beautiful desert

PostPosted: Sat 07 Sep 2013, 13:47    Post subject:  

Thanks for the feedback! Smile

I'm currently working on another distro, which should make roar-ng II even cooler.

My new idea is to build a distro from two parts:
- A kernel and a static collection of core binaries (e.g udev). This part should be totally independent from other distros - very hard to maintain, so it's tiny and doesn't change much. Very secure, extremely tiny, very fast. I already have a prototype - boots in about 2 seconds and achieves a shell running as root, with a SSH server on and impressive RAM usage of 11 MB on x86_64. Very Happy
- A "main SFS" from packages of another distro, as we do in Puppy. We already have enough experience with this part. It should contain that distro's C library, shell, applications, graphics stack, etc'. However, these will run inside a so-called "sandbox".

The great feature this design allows is swapping of the main SFS, with packages of another distro, so you have one "core Puppy", with Slackware/Ubuntu/Debian/etc' packages in the form of interchangeable add-ons. Each time, that sandbox contains packages of another distro.

Also, I think it could be cool to have multiple "main SFSs", each from another distro, so you gain access to all packages of these distros and even can run them in parallel. Cool

Currently, roar-ng II does not allow this design. I'm doing some research (well, weekend is over - I'll continue on the next one Smile) regarding UEFI support, so I can write a tiny script that generates a UEFI-bootable x86_64 ISO with nothing but the core distro inside, which is x86_64 only at the moment.

Later, I want to take roar-ng II's boot process and merge it with this thing. Wink

EDIT: here's a teaser. As I said, you get a working root shell Wink
teaser.png
 Description   
 Filesize   39.2 KB
 Viewed   734 Time(s)

teaser.png


_________________
My homepage
Back to top
View user's profile Send private message Visit poster's website MSN Messenger 
ICQ Number 
technosaurus


Joined: 18 May 2008
Posts: 4134

PostPosted: Tue 10 Sep 2013, 12:11    Post subject:  

I posted a similar demo here:http://www.murga-linux.com/puppy/viewtopic.php?p=590586#590586

Things to consider:
Linux-3.10 is LTS, ... may be a good basis going forward. I especially like the finit_module syscall that appeard in 3.8 (make loading kernel modules much easier in C)
Rob Landley's tmpfs for initrd patch to avoid the double copy on load and allow remounts
https://lkml.org/lkml/2013/6/29/101
Fork my init.c above instead of a shell version (hint print out the contents of argv and envp and compare to parsing /proc/cmdline) It starts here, but I've been working on an ultraminimal C library for it here
goingnuts posted a build of static multicall binary of xfbdev+jwm+rxvt in the pupngo thread iirc, but you will still need some kind of shell for jwm's StartupCommand to work (for mine I made a small sh-c wrapper that does argv+=2 (to get rid of "sh" and "-c" ) and fork()s and execvp(argv[0],argv))

My fastest way to get to a full desktop was to modify the kernel's vga=ask code into vga=max (vga=ask is a PITA) ... instead of keeping a set of functional modes, it just multiplied WxHxbpp and used the MAX ... then use xfbdev in the initramfs.
My code was pretty hacky, so never submitted it to LKML, but booted to desktop full res was under 2s in Qemu, but akash_rawal cleaned it up a bit here:
http://www.murga-linux.com/puppy/viewtopic.php?t=78993

btw, I like what you did with rox-lite and think it could be a good starting point for a project I have been mulling over for quite some time - a full gtk desktop environment in a single process for all GUI applications, tray applets, daemons ... The concept is pretty simple, use inotify (actually its glib wrapper funcs) to monitor directories and have its events trigger: load/unload gtkbuilder files for apps, desktop widgets and tray applets, or plugins and shell scripts for control, $HOME/Desktop (.desktop files, symlinks, directories for desktop similar to other DEs). Basically a replacement for a DE, pwidgets, gtkdialog, my own SIT (multiple icon tray app) and some additional functionality (webkitgtk could be a in a plugin and work something like this) ... glade would be easier than hand crafting gtkdialog xml. I was planning to do the whole thing from scratch so it could be MIT licensed, but I got stuck at the desktop on what would seem a simple task... trying to get a background image onto a gtkiconview.

_________________
Web Programming - Pet Packaging 100 & 101
Back to top
View user's profile Send private message 
Iguleder


Joined: 11 Aug 2009
Posts: 1775
Location: Israel, somewhere in the beautiful desert

PostPosted: Fri 13 Sep 2013, 02:56    Post subject:  

Yeah, I'm already using 3.10 and it's quite good.

This is my init - still uses an init script (so I can mount, print stuff nicely, etc', easily).

The desktop will come later (maybe), but don't worry - no decisions were made.

_________________
My homepage
Back to top
View user's profile Send private message Visit poster's website MSN Messenger 
ICQ Number 
laurentius77

Joined: 30 Mar 2011
Posts: 60

PostPosted: Tue 17 Sep 2013, 15:37    Post subject: Lazyux distro  

Iguleder wrote:
Thanks for the feedback! Smile

I'm currently working on another distro, which should make roar-ng II even cooler.

My new idea is to build a distro from two parts:
- A kernel and a static collection of core binaries (e.g udev). This part should be totally independent from other distros - very hard to maintain, so it's tiny and doesn't change much. Very secure, extremely tiny, very fast. I already have a prototype - boots in about 2 seconds and achieves a shell running as root, with a SSH server on and impressive RAM usage of 11 MB on x86_64. Very Happy
- A "main SFS" from packages of another distro, as we do in Puppy. We already have enough experience with this part. It should contain that distro's C library, shell, applications, graphics stack, etc'. However, these will run inside a so-called "sandbox".

The great feature this design allows is swapping of the main SFS, with packages of another distro, so you have one "core Puppy", with Slackware/Ubuntu/Debian/etc' packages in the form of interchangeable add-ons. Each time, that sandbox contains packages of another distro.

Also, I think it could be cool to have multiple "main SFSs", each from another distro, so you gain access to all packages of these distros and even can run them in parallel. Cool

Currently, roar-ng II does not allow this design. I'm doing some research (well, weekend is over - I'll continue on the next one Smile) regarding UEFI support, so I can write a tiny script that generates a UEFI-bootable x86_64 ISO with nothing but the core distro inside, which is x86_64 only at the moment.

Later, I want to take roar-ng II's boot process and merge it with this thing. Wink

EDIT: here's a teaser. As I said, you get a working root shell Wink


This concepts sound great and in my opinion should be include:
- the secure tiny core updated by the distro developer with the latest security patches. The builder for this core must include possibility to customize and change the kernel
- the devx.sfs maintained also by the distro developer and used to compile applications from sources
- an application sfs which can be created, updated and remastered by the user. User must have the choice to create this "apps sfs" from scratch in order to include just the desired application and nothing else more
- a sfs which includes just apps configurations and settings. Having this separated you can have a frugal distro with customized configurations (including specific firewall configurations) that are kept even after updating the apps sfs which not touch this configurations sfs
- the devx.sfs should offer the possibility to compile server applications like asterisk, openvpn, postfix, etc. from source
- the distro should offer possibility to mount external USB drives, connect to wired and wireless networks
The separated sfs offer the possibility to have a very secure and convenient distro. Even having a separate sfs for each application can be convenient sometime. In this way you can update just the desired sfs when an update is needed without affecting other applications.
The distro should have the possibility in setting which sfs's are loaded on the next bootup
Now I will try to have installed your new concept of distro.
Thank you for your work in Linux community, you have great ideeas and you are doing a great job.
Back to top
View user's profile Send private message 
laurentius77

Joined: 30 Mar 2011
Posts: 60

PostPosted: Tue 17 Sep 2013, 15:45    Post subject: Re: Lazyux distro  

laurentius77 wrote:
Iguleder wrote:
Thanks for the feedback! Smile

I'm currently working on another distro, which should make roar-ng II even cooler.

My new idea is to build a distro from two parts:
- A kernel and a static collection of core binaries (e.g udev). This part should be totally independent from other distros - very hard to maintain, so it's tiny and doesn't change much. Very secure, extremely tiny, very fast. I already have a prototype - boots in about 2 seconds and achieves a shell running as root, with a SSH server on and impressive RAM usage of 11 MB on x86_64. Very Happy
- A "main SFS" from packages of another distro, as we do in Puppy. We already have enough experience with this part. It should contain that distro's C library, shell, applications, graphics stack, etc'. However, these will run inside a so-called "sandbox".

The great feature this design allows is swapping of the main SFS, with packages of another distro, so you have one "core Puppy", with Slackware/Ubuntu/Debian/etc' packages in the form of interchangeable add-ons. Each time, that sandbox contains packages of another distro.

Also, I think it could be cool to have multiple "main SFSs", each from another distro, so you gain access to all packages of these distros and even can run them in parallel. Cool

Currently, roar-ng II does not allow this design. I'm doing some research (well, weekend is over - I'll continue on the next one Smile) regarding UEFI support, so I can write a tiny script that generates a UEFI-bootable x86_64 ISO with nothing but the core distro inside, which is x86_64 only at the moment.

Later, I want to take roar-ng II's boot process and merge it with this thing. Wink

EDIT: here's a teaser. As I said, you get a working root shell Wink


This concepts sound great and in my opinion should be include:
- the secure tiny core updated by the distro developer with the latest security patches. The builder for this core must include possibility to customize and change the kernel
- the devx.sfs maintained also by the distro developer and used to compile applications from sources
- an application sfs which can be created, updated and remastered by the user. User must have the choice to create this "apps sfs" from scratch in order to include just the desired application and nothing else more
- a sfs which includes just apps configurations and settings. Having this separated you can have a frugal distro with customized configurations (including specific firewall configurations) that are kept even after updating the apps sfs which not touch this configurations sfs
- the devx.sfs should offer the possibility to compile server applications like asterisk, openvpn, postfix, etc. from source
- the distro should offer possibility to mount external USB drives, connect to wired and wireless networks
The separated sfs offer the possibility to have a very secure and convenient distro. Even having a separate sfs for each application can be convenient sometime. In this way you can update just the desired sfs when an update is needed without affecting other applications.
The distro should have the possibility in setting which sfs's are loaded on the next bootup.
The distro should be multiuser. This is a must when it is used as a dedicated server operating system and server applications must not be runned as root.
Now I will try to examine on github your new concept of distro.
Thank you for your work in Linux community, you have great ideeas and you are doing a great job.
Back to top
View user's profile Send private message 
Iguleder


Joined: 11 Aug 2009
Posts: 1775
Location: Israel, somewhere in the beautiful desert

PostPosted: Tue 17 Sep 2013, 18:49    Post subject:  

Workin' on it Laughing

Here is the collection of minimalistic system tools that forms the base. Besides the applets contained in it, the distro contains musl, dash and tcsh - that's it Cool

Currently, it boots but I need to implement:
- A tiny udev replacement (i.e a simple tool that receives uevents and runs modprobe) - I removed kmod and udev, since I want to replace them with my own, tiny implementations (insmod, rmmod and modprobe are ready and work great)
- ifconfig
- route
- A DHCP client, maybe

EDIT: my udev replacement is sort of ready - it was able to automatically detect my USB mouse and load the right driver. Now, I'm writing a kernel build script - once the kernel is done building I'm going to build a new image of the distro, which has only the kernel, musl, lazy-utils and a shell; no eudev, kmod, toybox or BusyBox Very Happy

EDIT: works great. I built a small x86_64 distro image with Linux-libre, musl, lazy-utils, tcsh, dash and several console applications (e.g Lynx, htop, etc'). Looks good - my udev replacement (kmoduled) loaded all required modules and RAM usage is insanely low, 11-15 MB.

_________________
My homepage
Back to top
View user's profile Send private message Visit poster's website MSN Messenger 
ICQ Number 
simargl8

Joined: 06 Feb 2013
Posts: 65

PostPosted: Thu 19 Sep 2013, 07:40    Post subject:  

with lazy-utils you decided to rewrite Linux commands? Confused
Back to top
View user's profile Send private message Visit poster's website 
Iguleder


Joined: 11 Aug 2009
Posts: 1775
Location: Israel, somewhere in the beautiful desert

PostPosted: Thu 19 Sep 2013, 09:06    Post subject:  

Yes, for several reasons:
- The BusyBox code is extremely ugly. It contains lots of legacy code meant for use with Linux 2.4 and C library hacks.
- BusyBox doesn't build against musl.
- The only alternative to BusyBox, toybox, lacks many features. It looks much better, but it's relatively young and unstable.
- I need a udev applet. The BusyBox mdev applet is redundant, since today we have devtmpfs.
- I want to provide my own init, syslogd, klogd and so on. I don't like the BusyBox daemons.

It's already possible to build a bootable LiveCD with musl, lazy-utils and dash.

_________________
My homepage
Back to top
View user's profile Send private message Visit poster's website MSN Messenger 
ICQ Number 
technosaurus


Joined: 18 May 2008
Posts: 4134

PostPosted: Thu 19 Sep 2013, 20:15    Post subject:  

Not to mention the multicall binaries have all the overhead of functions not in use. If you do small standalone utilities it reduces the running footprint, instead of each fork to run utils from within also adding a lot of additional overhead (though copy-on-write reduces it some)... if you want to reduce the startup time of small utils, you can use readahead to reduce the loadtime (if you are running xfbdev/xvesa a good time to use readahead is during its startup) I wrote my tiny libc just for these kinds of small utils to minimize the size enough to fit entirely in cache (if you don't use sstrip, the elf headers are usually bigger than the program, otherwise a program can be ~500b with the right compile options)

RE: udev applet, I started rewriting the old unoptimized hotplug scripts and echoing the handler to /proc/sys/kernel/hotplug -- it becomes pretty simple with devtmpfs and allows you to add random hooks to things like a desktop drive tray (a jwm menu is a quick, robust way ... I wrote a test way back in scottman's akita thread IIRC) Originally it was just a wrapper that refreshed the drives as needed then called the "real" handler, but it turned out to not be that complicated to handle most of the events that actually needed it - no libudev integration though -- I wish the whole udev + dbus thing were replaced with 9fs like in Plan9 ... but that would involve kernel patches to sys, proc,...

RE: daemons - it would be nice to have a lot of the common daemons combined into 1 configurable process. I started that project once but got stuck @ cupsd (what a cluster bomb of code/docs)

_________________
Web Programming - Pet Packaging 100 & 101
Back to top
View user's profile Send private message 
Iguleder


Joined: 11 Aug 2009
Posts: 1775
Location: Israel, somewhere in the beautiful desert

PostPosted: Fri 20 Sep 2013, 03:39    Post subject:  

technosaurus wrote:
RE: daemons - it would be nice to have a lot of the common daemons combined into 1 configurable process.


I'm against this, because I don't like multi-call binaries and because I don't like systemd. I'm trying to provide a modular alternative, which doesn't force the user to use all the included daemons.

_________________
My homepage
Back to top
View user's profile Send private message Visit poster's website MSN Messenger 
ICQ Number 
Display posts from previous:   Sort by:   
Page 2 of 3 [35 Posts]   Goto page: Previous 1, 2, 3 Next
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Taking the Puppy out for a walk » Misc
Jump to:  

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 cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.1011s ][ Queries: 13 (0.0060s) ][ GZIP on ]