(OLD) (ARCHIVED) Puppy Linux Discussion Forum Forum Index (OLD) (ARCHIVED) Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info

This forum can also be accessed as http://oldforum.puppylinux.com
It is now read-only and serves only as archives.

Please register over the NEW forum
https://forum.puppylinux.com
and continue your work there. Thank you.

 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups    
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Sun 20 Sep 2020, 22:17
All times are UTC - 4
 Forum index » Taking the Puppy out for a walk » Announcements
woof-CE needs you
Moderators: Flash, Ian, JohnMurga
This forum is locked: you cannot post, reply to, or edit topics.   This topic is locked: you cannot edit posts or make replies. View previous topic :: View next topic
Page 94 of 97 [1441 Posts]   Goto page: Previous 1, 2, 3, ..., 92, 93, 94, 95, 96, 97 Next
Author Message
mistfire

Joined: 04 Nov 2008
Posts: 1424
Location: PH

PostPosted: Fri 08 Nov 2019, 03:55    Post subject:  

@dejan555 yes it is I think because it was very easily to contribute on Puppy Linux development. Biggest changes are already made in woof-ce
Back to top
View user's profile Send private message 
musher0

Joined: 04 Jan 2009
Posts: 15041
Location: Gatineau (Qc), Canada

PostPosted: Fri 08 Nov 2019, 14:32    Post subject:  

sc0ttman wrote:
musher0 wrote:
mistfire wrote:
More gui improvements on puppy core apps are coming to woof-ce
Shucks. It's stuff with CLI that needs to be developed. Wink


Agreed. Lots of important system setup/config tasks are still impossible or very complicated without X running...

I made a (overly long) post called "Make Puppy CLI more powerful" about that here: https://github.com/puppylinux-woof-CE/woof-CE/issues/1627

One thing we could do is have a puppy-config CLI program, with nice, consistently named commands, that makes it easy to do all the important stuff..

Something like:

puppy-config adblocker <-- runs a cli ad blocker script

puppy-config audio <-- asks some questions, setup as asked, play test sound

puppy-config audio alsa <-- setup alsa so its working, play test sound

puppy-config wifi <-- choose network from list, enter password

puppy-config samba [sharename]

puppy-config bluetooth

puppy-config locale <-- font, language, keybord setup

puppy-config install [drive] <-- asks questions, installs puppy to drive

..etc..

Then the GUIs we already have could be updated/simplified to just call these CLI programs in the background.

As Puppy aims to be easier to use than other Linuxes, a simple tool in the terminal, that replaces more complicated manual setup stuff, would be in keeping with the Puppy philosophy..

And it would pave the way for building barebones Puppies without X that were still easy to setup, customise, etc.

...The arguments given for avoiding the terminal is that is "too hard", "too complicated", "scary", etc..

Well, it would be a lot less scary with puppy-config helping you get setup ..

Thanks for your support to this idea, sc0ttman.

One thing that is often overlooked concerning the CLI interface is that it has visual
arrangement, refresh, and color possibilities, e.g. through ANSI escape codes, which
could make it more appealing to users, even, than bland YAD layouts.

Yes, in a CLI interface you have to figure out where the required keyboard keys are.
But for the user, that is not any more difficult than figuring out where to drag your
mouse to and within a YAD box.

BFN.

_________________
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)
Back to top
View user's profile Send private message 
rufwoof


Joined: 24 Feb 2014
Posts: 3725

PostPosted: Fri 08 Nov 2019, 21:44    Post subject:  

I boot a 11.6MB vmlinuz, a cut down version of Fatdog's Bulldog (initrd cli). That's with the initrd (initramfs/init) built into the kernel, along with all machine specific modules/firmware, so its the only file required in order to boot. Boots in around a second ... a few seconds in total before its also wifi net connected, and includes OpenSSH (so ssh/scp/sftp/sshfs), ccrypt (that I use to encrypt my .ssh folder (ssh keys)), screen (terminal multiplexing), simple-mtpfs (so I can mount my android phone), kexec (to directly boot any other kernel/system), and mc (file manager and text editor). With that I can download any Puppy/distro, and boot (kexec) it. Or kexec any locally stored Puppy (I just tend to boot full Fatdog). Or I can boot it and ssh into hashbang and reattach to a tmux session with multiple windows/sessions for irc, email, w3m ...etc.

mc's F2 "menu" can be user-defined, or you can set up multiple menu's, one menu for each folder. When you're familiar with mc as a file manager/text editor its relatively quick/easy to use. In keeping with that I created a ncurses menu system that works along similar lines/style as mc (see attached image).

Puppy looks to be widely usable, functional when moved from machine to machine. There's little in the way of Puppy to be refined to be single machine specific. Trying to downsize Puppy to be single machine specific, removing firmware/modules etc. is awkward. And much of Puppy size is modules/firmware, much of which might never be used, but is loaded every time.

A combination of being able to use one Puppy (devx) to compile a machine specific kernel (localyesconfig) that also included a mc style ncurses menu system could be made relatively easy for novices to build/run. And once you have a basic network connected system running, adding additional functionality via the likes of loading sfs's can be used to expand that small 'setup' system into a full blown desktop gui system. Or just used to boot a local copy of a full system. With the added advantage of being able to sense (scan) for what hardware is actually available after the initial small kernel has been booted, but prior to downloading/booting the main (full) system.

In short, I'd suggest a TUI (text user interface) .. along the lines of mc or the old Turbo Pascal style IDE as the front end to cli actions/scripts. That tui/scripts could even be downloaded from a central server rather than being contained within the vmlinuz.
s.png
 Description   
 Filesize   28.79 KB
 Viewed   961 Time(s)

s.png


_________________
( ͡° ͜ʖ ͡°) :wq
Fatdog multi-session usb

echo url|sed -e 's/^/(c/' -e 's/$/ hashbang.sh)/'|sh
Back to top
View user's profile Send private message 
musher0

Joined: 04 Jan 2009
Posts: 15041
Location: Gatineau (Qc), Canada

PostPosted: Fri 08 Nov 2019, 22:38    Post subject:  

Nah, I don't like back-ports! Laughing
_________________
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)
Back to top
View user's profile Send private message 
sc0ttman


Joined: 16 Sep 2009
Posts: 2806
Location: UK

PostPosted: Sat 09 Nov 2019, 10:25    Post subject:  

Quote:
I boot a 11.6MB vmlinuz, a cut down version of Fatdog's Bulldog (initrd cli). That's with the initrd (initramfs/init) built into the kernel, along with all machine specific modules/firmware, so its the only file required in order to boot. Boots in around a second ...

Sounds quite good Smile

I do think Puppies should offer a kernel that supports as much hardware as possible "out of
the box" though, with loads of firmware..

Doing that is very user friendly - Puppy users can just "download and boot" on a wide range
of PCs, laptops, etc, without needing any kernel or firmware knowledge/installation/setup.

Quote:
In short, I'd suggest a TUI (text user interface) ...as the front end to cli actions/scripts.


A simple "main menu" or "welcome menu" ncurses script, which offers easy ways to run various
system tools (puppy-config stuff I mentioned above), or recovery scripts (fsck, etc) would make
the CLI/terminal experience in Puppy about as easy as any other distro.

.. Kind of separately..

It would be great to have ncurses working as early in the boot process as possible, although
I've no idea if it can work in the initrd.

I am biased but if nrcurses does work in the initrd, I'd like to see Pkg (and ncurses) work
even from inside the initrd, so that Pkg (and Pkgdialog) can be used even before mounting the
main filesystem (rootfs)...

...if ncurses doesn't work in initrd (i.e it can't be compiled statically), there is still the option of
using lots of "list and picker" type things like fzy (https://github.com/jhawthorn/fzy),
selecta, etc..

Quote:
One thing that is often overlooked concerning the CLI interface is that it has visual
arrangement, refresh, and color possibilities, e.g. through ANSI escape codes, which
could make it more appealing to users, even, than bland YAD layouts.

Agreed. Making nice looking CLI programs that are well presented, easy to understand, simple
inputs, clear options (etc) is entirely possible, including color coding, nice spacing, formatting, etc...
Even without ncurses (which many users don't like)..

Continuing with nice CLI presentation ideas:

IMVHO, I also think Puppy should be one of the only distros to ship a modified "Nerd Font" version
of Deva Vu Sans (or Bitstream Vera), as these "Nerd Fonts" also include icons built right
into the fonts themselves.. These icons can be used in the terminal (if found to be available).

See this screenshot:


_________________
Pkg, mdsh, Woofy, Akita, VLC-GTK, Search
Back to top
View user's profile Send private message 
rufwoof


Joined: 24 Feb 2014
Posts: 3725

PostPosted: Sat 09 Nov 2019, 13:48    Post subject:  

sc0ttman wrote:
A simple "main menu" or "welcome menu" ncurses script, which offers easy ways to run various system tools (puppy-config stuff I mentioned above), or recovery scripts (fsck, etc) would make the CLI/terminal experience in Puppy about as easy as any other distro.

.. Kind of separately..

It would be great to have ncurses working as early in the boot process as possible, although I've no idea if it can work in the initrd.

I am biased but if nrcurses does work in the initrd, I'd like to see Pkg (and ncurses) work even from inside the initrd, so that Pkg (and Pkgdialog) can be used even before mounting the main filesystem (rootfs)...

Just recompiled the kernel config I'm using with that ncurses menu included as a dynamically linked (i.e. copied over the bin as-is and also copied over the libs) and that booted/ran ok. That was within initrd, i.e. was run within a setsid cttyhack child process within init, that when exited out of resumes pid 1 (normal init/console). The reason I use the setsid cttyhack for tty/pseudo terminal is to enable job control (screen/background tasks etc.) that otherwise (console) isn't available. I originally coded that ncurses menu to just show the menu, and exit with a exit string of whatever option was selected, and I have a wrapper script that loops around showing the menu, trapping the selected return text (requested action string) in a case statement, and launching the associated action for that, before re-showing the menu again. As-is that menu is fixed (as compiled into the C program), but relatively easy to change and recompile. With the ncurses program and libs added it expanded the vmlinuz to 12MB (around 360KB larger compared to without the ncurses program/libs).

That is without mouse point/click functionality. You have to (the way it is coded i.e. mirrors mc type controls) press F9 to activate the menu and then the first letter of whatever highlighted choice you want to run, or use the arrow keys to navigate/enter to select.

Fatdog has slapt-get cli based package manager alongside gslapt (gui based package manager), so along with wifi net connected I guess that could also be run within init. However I haven't actually tried that.

My vmlinuz is compiled to be very machine specific, but no reason why that couldn't be bloated out by including modules/firmware for a wide range of hardware. Doing so however would expand the size considerably and in that case it would perhaps be best to have initramfs_data.cpio (initrd) outside of vmlinuz. I suspect however that you'd be looking at something like a 80MB system. At that sort of size you might as well just use a bare-bone type puppy as a early stage init boot (something like a xvesa type puppy), do whatever configuration/action you desired within that before exiting to resume init/pid 1 and boot the main/full puppy.

_________________
( ͡° ͜ʖ ͡°) :wq
Fatdog multi-session usb

echo url|sed -e 's/^/(c/' -e 's/$/ hashbang.sh)/'|sh
Back to top
View user's profile Send private message 
mistfire

Joined: 04 Nov 2008
Posts: 1424
Location: PH

PostPosted: Sat 16 Nov 2019, 09:15    Post subject:  

Some woof-ce accomplishements this 2019
* Improved package management and sfs loading
* Improved PTP and MTP support
* Improved puppy core apps gui
* Improved disk image file mounting
* XDG Desktop compliance
* Improved touchpad support
* Added non-acpi support
Back to top
View user's profile Send private message 
rockedge


Joined: 11 Apr 2012
Posts: 1874
Location: Connecticut, United States

PostPosted: Mon 25 Nov 2019, 11:38    Post subject:  

At the moment using the kernel-kit to produce a 5.2.21 SMP PREEMPT RT kernel and I am running into this error immediately
Code:
./funcs.sh: line 7: vercmp: command not found


I am running Bionic64-v8 with a kernel 4.19.25-rt16 #1 SMP PREEMPT RT
and I do not have the command vercmp on board. Nor do I see a way to get it...so please let me know how to include this command or can I bypass the function?
Back to top
View user's profile Send private message Visit poster's website 
mikeslr


Joined: 16 Jun 2008
Posts: 3913
Location: 500 seconds from Sol

PostPosted: Mon 25 Nov 2019, 14:26    Post subject:  

vercmp is not in the Ubuntu repos. Per Arch, it is a version comparison utility. https://www.archlinux.org/pacman/vercmp.8.html, Distros employing it seem to be few and far between. https://pkgs.org/download/vercmp; https://pkgs.org/download/filevercmp. See also, https://github.com/diorahman/vercmp. They do not appear to be either arch or kernel specific.

And perhaps the idea for a work-around, https://unix.stackexchange.com/questions/163702/bash-script-to-verify-that-an-rpm-is-at-least-at-a-given-version

As always, the information I transmit may be entirely misleading. Shocked Laughing
Back to top
View user's profile Send private message 
rockedge


Joined: 11 Apr 2012
Posts: 1874
Location: Connecticut, United States

PostPosted: Mon 25 Nov 2019, 14:53    Post subject:  

hello mikeslr,

I think I know what is happening and why vercmp did not work on one Bionic64 and does on another. Some thing in the save folder is eliminating or while listing it. I was able to compile a kernel 5.2.21 just now successfully and am now looking into the patches needed to build this as a true real time kernel.

The goal is to create a Puppy Linux that can run LinuxCNC in it's full capacity and direct CNC machines. Although so far there are errors still during compiling LinuxCNC, it is getting closer. I am using for that kernel 4.19.27-rt16 SMP PREEMPT RT right now but if successful in building a newer version 5 real time kernel I will use it.
Back to top
View user's profile Send private message Visit poster's website 
BarryK
Puppy Master


Joined: 09 May 2005
Posts: 9400
Location: Perth, Western Australia

PostPosted: Mon 13 Jan 2020, 04:45    Post subject:  

I was very surprised today. Those of you who have been developing with Puppy for many years will probably know about "PuppyHardwareProfile" for /etc/X11/xorg.conf, which, in a nutshell, handles booting a usb-stick on different PCs, with different video chips and monitors.

Yesterday I have enhanced this a bit in woofQ, my fork of Woof2, and then I looked at woof-CE on github, and it seems that PuppyHardwareProfile was removed in 2016.

See my blog post:

https://bkhome.org/news/202001/improved-hardware-profiling-for-xorg.html

Has hardware-profiling for Xorg been moved or implemented in some other way in woof-CE, or is it really gone?

_________________
https://bkhome.org/news/
Back to top
View user's profile Send private message Visit poster's website 
peebee


Joined: 21 Sep 2008
Posts: 4391
Location: Worcestershire, UK

PostPosted: Mon 13 Jan 2020, 07:49    Post subject:  

BarryK wrote:
I was very surprised today.
Has hardware-profiling for Xorg been moved or implemented in some other way in woof-CE, or is it really gone?

https://github.com/puppylinux-woof-CE/woof-CE/commit/1bf49330d9cab47f37191845ddbd8ba6e297a152 of 20-Jun-2016
says:
Quote:
xwin: logic to replace xorg hardware profiles

This attemps to replace the hardware profiles stuff
based on ddcprobe.

The xorg.conf-auto-pc template is good enough..
it's pretty generic and very specific to puppy,
so it can work with a variety of
hardware from a 1997 video card to a 2016 one.

This new logic will attemp to run X a second time
if it fails the first time
(falling back to a generic template..)

If the system does not crash after that
then there's a chance to run xorgwizard...

_________________
LxPup = Puppy + LXDE
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64
Back to top
View user's profile Send private message Visit poster's website 
BarryK
Puppy Master


Joined: 09 May 2005
Posts: 9400
Location: Perth, Western Australia

PostPosted: Mon 13 Jan 2020, 10:49    Post subject:  

peebee wrote:
BarryK wrote:
I was very surprised today.
Has hardware-profiling for Xorg been moved or implemented in some other way in woof-CE, or is it really gone?

https://github.com/puppylinux-woof-CE/woof-CE/commit/1bf49330d9cab47f37191845ddbd8ba6e297a152 of 20-Jun-2016
says:
Quote:
xwin: logic to replace xorg hardware profiles

This attemps to replace the hardware profiles stuff
based on ddcprobe.

The xorg.conf-auto-pc template is good enough..
it's pretty generic and very specific to puppy,
so it can work with a variety of
hardware from a 1997 video card to a 2016 one.

This new logic will attemp to run X a second time
if it fails the first time
(falling back to a generic template..)

If the system does not crash after that
then there's a chance to run xorgwizard...


Yes, but falling back to a "generic template" is not hardware-profiling -- it is what we had prior to 2007 before hardware-profiling was introduced.

If someone modifies xorg.conf and the files in xorg.conf.d, for booting on a particular PC, that is likely to be inappropriate when boot on another PC.

If you then go to the trouble of configuring xorg.conf and xorg.conf.d on the second PC, then it won't work on the first.

As far as I can see, looking around on woof-CE, Xorg effectively no longer has hardware profiling.

_________________
https://bkhome.org/news/
Back to top
View user's profile Send private message Visit poster's website 
s243a

Joined: 02 Sep 2014
Posts: 2626

PostPosted: Mon 13 Jan 2020, 11:37    Post subject:  


_________________
Find me on minds and on pearltrees.
Back to top
View user's profile Send private message Visit poster's website 
jamesbond

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

PostPosted: Mon 13 Jan 2020, 13:00    Post subject:  

s243a - you had a wrong closing url tag.
Here is your post, when the closing tag has been fixed.

s243a wrote:
BarryK wrote:
I was very surprised today.
Has hardware-profiling for Xorg been moved or implemented in some other way in woof-CE, or is it really gone?
https://github.com/puppylinux-woof-CE/woof-CE/commit/1bf49330d9cab47f37191845ddbd8ba6e297a152 of 20-Jun-2016
says:
Quote:
xwin: logic to replace xorg hardware profiles

This attemps to replace the hardware profiles stuff
based on ddcprobe.

The xorg.conf-auto-pc template is good enough..
it's pretty generic and very specific to puppy,
so it can work with a variety of
hardware from a 1997 video card to a 2016 one.

This new logic will attemp to run X a second time
if it fails the first time
(falling back to a generic template..)

If the system does not crash after that
then there's a chance to run xorgwizard...


Yes, but falling back to a "generic template" is not hardware-profiling -- it is what we had prior to 2007 before hardware-profiling was introduced.

If someone modifies xorg.conf and the files in xorg.conf.d, for booting on a particular PC, that is likely to be inappropriate when boot on another PC.

If you then go to the trouble of configuring xorg.conf and xorg.conf.d on the second PC, then it won't work on the first.

As far as I can see, looking around on woof-CE, Xorg effectively no longer has hardware profiling.


I like knowledge on this issue but I do wonder if there is anything useful here:
mistfire wrote:
@thinkpadfreak I implemented autoconfig because of my experiences of using puppy across different computers with save file loaded. It will only trigger when tazpuppy detects changes on hardware setup such as changing video cards or display monitors when the computer booting up. This makes TazPuppy a truly portable OS.


http://murga-linux.com/puppy/viewtopic.php?p=1009440&search_id=686705073#1009440
or perhaps the old puppy way of doing it was better than whatever mistfire implemented in tazpup? I don't know so I'll let the experts discuss Smile

_________________
Fatdog64 forum links: Latest version | Contributed packages | ISO builder
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 94 of 97 [1441 Posts]   Goto page: Previous 1, 2, 3, ..., 92, 93, 94, 95, 96, 97 Next
This forum is locked: you cannot post, reply to, or edit topics.   This topic is locked: you cannot edit posts or make replies. View previous topic :: View next topic
 Forum index » Taking the Puppy out for a walk » Announcements
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.4037s ][ Queries: 13 (0.2860s) ][ GZIP on ]