Shahor 04052013

Puppy related raves and general interest that doesn't fit anywhere else
Message
Author
User avatar
vovchik
Posts: 1507
Joined: Tue 24 Oct 2006, 00:02
Location: Ukraine

#16 Post by vovchik »

Dear lguleder,

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

with kind regards,
vovchik

User avatar
Iguleder
Posts: 2026
Joined: Tue 11 Aug 2009, 09:36
Location: Israel, somewhere in the beautiful desert
Contact:

#17 Post by Iguleder »

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.
[url=http://dimakrasner.com/]My homepage[/url]
[url=https://github.com/dimkr]My GitHub profile[/url]

User avatar
vovchik
Posts: 1507
Joined: Tue 24 Oct 2006, 00:02
Location: Ukraine

#18 Post by vovchik »

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

jamesbond
Posts: 3433
Joined: Mon 26 Feb 2007, 05:02
Location: The Blue Marble

#19 Post by jamesbond »

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

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 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]

laurentius77
Posts: 82
Joined: Wed 30 Mar 2011, 07:02

Any news about Shahor?

#20 Post by laurentius77 »

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.

User avatar
Iguleder
Posts: 2026
Joined: Tue 11 Aug 2009, 09:36
Location: Israel, somewhere in the beautiful desert
Contact:

#21 Post by Iguleder »

Thanks for the feedback! :)

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. :D
- 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. 8)

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 :)) 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:
Attachments
teaser.png
(39.2 KiB) Downloaded 865 times
[url=http://dimakrasner.com/]My homepage[/url]
[url=https://github.com/dimkr]My GitHub profile[/url]

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#22 Post by technosaurus »

I posted a similar demo here:http://www.murga-linux.com/puppy/viewto ... 586#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.
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

User avatar
Iguleder
Posts: 2026
Joined: Tue 11 Aug 2009, 09:36
Location: Israel, somewhere in the beautiful desert
Contact:

#23 Post by Iguleder »

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.
[url=http://dimakrasner.com/]My homepage[/url]
[url=https://github.com/dimkr]My GitHub profile[/url]

laurentius77
Posts: 82
Joined: Wed 30 Mar 2011, 07:02

Lazyux distro

#24 Post by laurentius77 »

Iguleder wrote:Thanks for the feedback! :)

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. :D
- 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. 8)

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 :)) 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.

laurentius77
Posts: 82
Joined: Wed 30 Mar 2011, 07:02

Re: Lazyux distro

#25 Post by laurentius77 »

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

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. :D
- 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. 8)

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 :)) 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.

User avatar
Iguleder
Posts: 2026
Joined: Tue 11 Aug 2009, 09:36
Location: Israel, somewhere in the beautiful desert
Contact:

#26 Post by Iguleder »

Workin' on it :lol:

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 8)

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 :D

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.
[url=http://dimakrasner.com/]My homepage[/url]
[url=https://github.com/dimkr]My GitHub profile[/url]

simargl8

#27 Post by simargl8 »

with lazy-utils you decided to rewrite Linux commands? :?

User avatar
Iguleder
Posts: 2026
Joined: Tue 11 Aug 2009, 09:36
Location: Israel, somewhere in the beautiful desert
Contact:

#28 Post by Iguleder »

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.
[url=http://dimakrasner.com/]My homepage[/url]
[url=https://github.com/dimkr]My GitHub profile[/url]

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#29 Post by technosaurus »

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)
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

User avatar
Iguleder
Posts: 2026
Joined: Tue 11 Aug 2009, 09:36
Location: Israel, somewhere in the beautiful desert
Contact:

#30 Post by Iguleder »

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.
[url=http://dimakrasner.com/]My homepage[/url]
[url=https://github.com/dimkr]My GitHub profile[/url]

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#31 Post by technosaurus »

Iguleder wrote: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.
I was talking more of a non-threaded non-forking multifunction binary. Its fairly easy to accomplish - 1 buf, as many fd as are needed and an event loop. Use argv to set values to TRUE to enable each desired "daemon" Inside the event loop read the fd(s) into the buf for each enabled daemon, do what ever needs to be done with the buf and continue... just for the simple ones to save the multiple elf, buf, and _start overheads.
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

laurentius77
Posts: 82
Joined: Wed 30 Mar 2011, 07:02

build Lazyux

#32 Post by laurentius77 »

I want to test Iguleder's new "Lazyux". I downloaded the stuff from github [/url]https://github.com/iguleder/lazyux[url] and I run build_all.sh. I've got a sysroot folder with a LFS inside and the folder "built_packages" with all compiled packages. Does anybody know where can I found a tutorial in order to make a bootable distro from this? Because I suppose I have to get an initrd and vmlinux. Please if you want to help me with a tutorial it will be a great thing. What is the another script "build.sh" for?
[/url]

User avatar
greengeek
Posts: 5789
Joined: Tue 20 Jul 2010, 09:34
Location: Republic of Novo Zelande

Re: build Lazyux

#33 Post by greengeek »

laurentius77 wrote:I want to test Iguleder's new "Lazyux".
His latest iso is here:
ftp://dimakrasner.com/lazyux-08122013.iso

User avatar
Flash
Official Dog Handler
Posts: 13071
Joined: Wed 04 May 2005, 16:04
Location: Arizona USA

#34 Post by Flash »

I'm guessing it can't be run from a multisession DVD. :(

laurentius77
Posts: 82
Joined: Wed 30 Mar 2011, 07:02

Re: build Lazyux

#35 Post by laurentius77 »

greengeek wrote:
laurentius77 wrote:I want to test Iguleder's new "Lazyux".
His latest iso is here:
ftp://dimakrasner.com/lazyux-08122013.iso
Thank you, I got it and I am testing it now.

Post Reply