mkfigos 1.3: combines librepup with refracta

[Sailor Enceladus]

What is so discourteous about changing someones code that is open sourced without first asking them provided credit is given?

If I write some code, open source it and release it, people can do with it what they like except claim that they originally wrote it.
Learnhow2code never claimed it as his own, he simply modified it to suit his needs and made it available again.
Where is the problem in that?

Here's one example. Notice how scientist claims the Farenheit problem in the script is by rcrsn51 when it really isn't:
http://www.murga-linux.com/puppy/viewtopic.php?p=910240#910240

[Pete]

I'm not quite sure what bearing that example has.
Whoever changed that script had every right to in order to make it suit their needs.
Where the problem came in is the over reaction by that user.
The script should have been headed as follows:

Code: Select all

#!/bin/sh
# rcrsn51 2015-09-20 
# modified by Whomever at whatever date
:
:

That would have been the proper way to do it.
I have never come across such resistance to change as on the Puppy linux forum.
Since when does one have to go with hat in hand begging for permission from the original author to change their open sourced script?
Just give them credit, put your name as the one doing the mods and off you go.

[learnhow2code]

Here's one example. Notice how scientist claims the Farenheit problem in the script is by rcrsn51 when it really isn't

that thread is difficult to follow. how many accusations are formed from a simple miscommunication? in any case, if anyone thinks im mishandling their puppy code, they have several options (apart from the usual legal ones, which i think will not get them as far as this very friendly offer): http://www.murga-linux.com/puppy/viewtopic.php?t=107620

now i think this offer is completely unnecessary.

but its there, because hey-- someone here might misunderstand. theres one more place for them to try to get some satisfaction.

Just give them credit, put your name as the one doing the mods and off you go.

probably not the worst idea to note the changes to the scripts made by mkfigos then: \n\n#script edited by mkfigos can probably be added to the scripts in question.

[Marv]

I have never come across such resistance to change as on the Puppy linux forum.

After a decade or more watching novae I think some resistance is to be expected. Scripts grow barnacles over time and even with the best of intentions it can become exceedingly difficult to sort out what myriad changes really do. Documentation and bouncing proposed changes off whoever originally wrote the script if they are still around is really the key. I have an assortment of core puppy scripts and some awk and sed based updaters for them that I have cobbled to better suit my personal needs (on the init script for example) but they stay in my closet. The originals are hoary enough already.

[learnhow2code]

Documentation and bouncing proposed changes off whoever originally wrote the script if they are still around is really the key.

heres the thing marv, i tried several times to ask where the scripts were. when i found them on my own, i noted the changes i planned to make. and i said i would make them, since it was made very clear by people DO NOT BOTHER THE DEVS WITH THIS. so i didnt bother them. nonetheless, they were free to join in any time-- and still are.

i think its great to have conversations, when theyre not full of trolling and attacks and (so much) strawman (im referring to the way these conversations went.)

in the end, i was told people shouldnt be allowed to speak about it-- by the same person that suggested making these changes! so i made them, and i said what the changes would be, in my own thread, and i got attacked some more.

if what the puppy community wants to encourage is communication with devs, this is about as far as possible from the kind of encouragement i need to try to do that. but either way, i tried. now im being critiqued for going ahead instead of doing what i was told not to do. farther up i asked, who am i supposed to believe? who speaks for the community? because until we sort that out, this "right way" is just "one way." the community has no consensus on it, and i get criticized either way-- its plain old catch 22. all this talk of "best practices" has to come after fixing that.

I have an assortment of core puppy scripts and some awk and sed based updaters for them that I have cobbled to better suit my personal needs (on the init script for example) but they stay in my closet. The originals are hoary enough already.

this is a common appeal here.

if im to get to the gist of it, its not wise to share remaster scripts? or put in more practical terms: if you write a remaster script, it should not use any part of puppy?

im not trying to put words in your mouth, i know youre not forbidding anything-- but it sounds like you might be trying to make a case against changing puppy at all, or just "leaving it to someone else."

licensing aside, if the puppy community is against derivative puppies, i can consider dropping the puppy part of fig os. but theres a whole subforum dedicated to puppy derivatives-- which this thread is in-- the subforum is entitled "puppy derivatives."

so if youre NOT saying that we should just leave puppy well enough alone, whats the alternative? join a club? join a committee? be part of woof-ce? and of course, stay away from puppy otherwise-- hands off puppy (not absolutely, but maybe.)

i welcome corrections to any misunderstandings of what youre saying. im not really sure i follow but id like to figure out the local culture (which has changed since my time here years ago) if thats possible for an ordinary person.

[Robert123]

@Learninghow2code

Stick with your vision you have been a gentlemen throughout this thread, you other detractors should hang your heads in shame - disgusting behaviour and unfornately nothing new.

[s243a]

I appreciate any and all efforts to innovate with puppy liinux. Keep up the good work, learnhow2code, not that I know anything about the ping issue nor have I tried your pupplet.

So back to the original post, are these two different distributions merged into one or are you just providing an option to boot from one of the two?

[learnhow2code]

I appreciate any and all efforts to innovate with puppy liinux. Keep up the good work, learnhow2code

thank you very much.

So back to the original post, are these two different distributions merged into one or are you just providing an option to boot from one of the two?

yes! (there is an option to boot from one or the other. the idea is also to mix them. the sfs files of both distros get opened and mixed and edited, although so far no dramatic mixes have taken place.) ive considered copying binaries / libraries from the refracta mode to puppy mode, and ive considered copying binaries (with required libs) from puppy mode to refracta mode.

on the mixing, ive mostly copied puppys default wallpaper, but then this went through rebranding, per suggestions from the puppy community. puppys isolinux configuration is mixed with the one from refracta.

there would be other mixing features by now, but i took time to work on something related to puppy mode-- it can do things to the puppy mode, or the refracta mode, or both, or mix things from one side to the other.

as to who can understand this, let me offer this script as evidence of a theory: packaging and distro building are so similar, they practically use the same kinds of scripts and files. put another way: distro building is packaging on a bigger scale.

[s243a]

I appreciate any and all efforts to innovate with puppy liinux. Keep up the good work, learnhow2code

thank you very much.

So back to the original post, are these two different distributions merged into one or are you just providing an option to boot from one of the two?

yes! (there is an option to boot from one or the other. the idea is also to mix them. the sfs files of both distros get opened and mixed and edited, although so far no dramatic mixes have taken place.) ive considered copying binaries / libraries from the refracta mode to puppy mode, and ive considered copying binaries (with required libs) from puppy mode to refracta mode.

on the mixing, ive mostly copied puppys default wallpaper, but then this went through rebranding, per suggestions from the puppy community. puppys isolinux configuration is mixed with the one from refracta.

there would be other mixing features by now, but i took time to work on something related to puppy mode-- it can do things to the puppy mode, or the refracta mode, or both, or mix things from one side to the other.

as to who can understand this, let me offer this script as evidence of a theory: packaging and distro building are so similar, they practically use the same kinds of scripts and files. put another way: distro building is packaging on a bigger scale.

If you could strip out all the windows manager stuff as separate sfs files then I would expect mixing would work as follows.

First load the the libraries from the less dominant distribution and than the libraries from the more dominant distribution and finally load the windows manager. So three sfs files, one for each step.

As long as the kernel is the same than this shouldn't be an issue.

I'm not sure how much is contained in the boot image but the boot image should match the more dominant distribution. So this way we have mixing. I suppose the kernel might not even have to be the same because it is possible to upgrade a kernel but not the libraries. Still though, we would have to pick one kernel.

[Marv]

im not trying to put words in your mouth, i know youre not forbidding anything-- but it sounds like you might be trying to make a case against changing puppy at all, or just "leaving it to someone else."

No, not at all. I've seen and see many things that should be changed in puppy. When I think they are universal enough to warrant inclusion I try to offer the suggestion as close as I can get to the original author. If I think they are my personal quirks only or have the potential to break or change what other people think of as established script behavior I rewrite or manually remaster for my own bedevilment. It's not change or no change, just a matter of style in my view... and I for one am trying very hard to be constructive here and on the forum overall.

[learnhow2code]

0.8: upgrade to latest refracta, upgrade to icewm, added leafpad, hsetroot, yadless, battery indicator in icewm, added "auto-edited by" to scripts that might otherwise be thought of as unedited.

0.9: icewm menus fixed, puppy yad upgraded, simple python server, rox copied from puppy to refracta

[ally]

@code

I've had a quick play, it's a bit beyond me sorry

if you fancy ftp'ing stuff to me I'll put it up on the archive

[learnhow2code]

@code

I've had a quick play, it's a bit beyond me sorry

curious what you did, but thats ok.

if you fancy ftp'ing stuff to me I'll put it up on the archive

thanks, i might!

[ally]

downloaded the mkfigos 0.9 script, downloaded refracta

fig9 is installed, devx loaded

ran script:

./mkfigos09.sh: line 4: proginf: command not found
./mkfigos09.sh: line 6: isov: command not found
./mkfigos09.sh: line 7: isoname: command not found
./mkfigos09.sh: line 9: syntax error near unexpected token `mainv'
./mkfigos09.sh: line 9: `function addquoted mainv toquote'

[learnhow2code]

ran script:

./mkfigos09.sh: line 4: proginf: command not found
./mkfigos09.sh: line 6: isov: command not found
./mkfigos09.sh: line 7: isoname: command not found
./mkfigos09.sh: line 9: syntax error near unexpected token `mainv'
./mkfigos09.sh: line 9: `function addquoted mainv toquote'

so, heres the story there-- its actually really simple (and something i ought to consider changing.)

fig scripts are technically "compiled" (wait, not compiled like configure, make, etc-- it has no deps or multiple commands...) so its a bit facetious to put #!/usr/local/bin/fig29 at the top-- but that would have helped here.

originally this was a proof-of-concept and i wasnt sure anyone would actually try to use it, but i have updated the top post to include things like:

* you will need fig-- which you would already have if you were running fig os. you can get the .pet for fig here: http://www.murga-linux.com/puppy/viewto ... 501#909501

so you install that pet, and then to run mkfigos you do it like this:

# fig29 mkfigos09.fig

# ./mkfigos09.fig.py

but for your effort, allow me to take a moment to compile it for you:

(compiled mkfigos09.fig.py attached-- just rename it to drop the .gz)

if the forum drops the +x then either chmod +x mkfigos09.fig.py OR...

# python mkfigos09.fig.py

either of these will let you run the attached script.

[learnhow2code]

1.0:
* switched from tahr 6.0.5 to librepup based on 6.0.2
* modprobe e1000 added to puppy mode for qemu compatibility
* more compression for sfs
* default wallpaper removed in puppy mode

[ally]

hey code

finally got around to running your '09 script which created figos0.9.iso

I'm not clever enough to understand what changes I should see over and above a 'normal' tahrpup build

I have tried '10 script but I get a syntax error on line 4, again sadly I have no understanding



http://archive.org/download/Puppy_Linux ... gos0.9.iso

[quirkian2new]

@learnhow2code, i think nearly all of the members in this puppy forum will appreciate all kinds of effort for innovation & technology advance for puppy linux. So keep up with your good effort.

Other innovative efforts like PUPBSD is also being discussed in the following thread :

http://www.murga-linux.com/puppy/viewtopic.php?t=107542

thanks

[learnhow2code]

finally got around to running your '09 script which created figos0.9.iso

I'm not clever enough to understand what changes I should see over and above a 'normal' tahrpup build

this is so many kinds of wonderful...

first of all, youre the first person to upload a copy of my iso, ever! and youre the second person (on the planet) to upload an iso containing my programming language, which is in fig os.

there are some other interesting things about this-- one is that refracta was clearly downloaded, because the initrd and vmlinuz differ from the puppy initrd and vmlinuz-- but the squashfs is missing.

im guessing this is because mksquashfs failed on your machine on the larger file, but it obviously modified the smaller puppy sfs, because it contains changes i made. in fact, the 10-chapter book i did a preliminary version of is in there, along with evince (one of the better tools for reading it.)

but the best part is-- either from an evaluation standpoint or from a technical standpoint, the ping scripts are not edited! *evil grin* -- this is either because sed didnt work or because you removed those lines. either way, im tickled.

youve done an excellent job and thank you for putting this up. as much as id like to get you more into this process, that was never my intention-- i didnt want you as a guinea pig, i wanted it to work properly for you the first time so you could upload it.

you have uploaded it, and it does work-- thank you very much! i will reply to the other things you mentioned:

I have tried '10 script but I get a syntax error on line 4, again sadly

i think you got the syntax error with version 1.0 for the same reason you did the first time on 0.9.

without expecting you to follow any of this (its simply not your job to) i will explain in case it helps someone:

the "fig" files im putting in this thread, have this naming convention:


[ filename ] DOT [ fig ] DOT [ gz ]
- or -
[ filename ] DOT [ fig ] DOT [ py ] DOT [ gz ]


the DOT gz part just makes it so the forum will allow it first, chop that off the name (rename) and you get:


[ filename ] DOT [ fig ]
- or -
[ filename ] DOT [ fig ] DOT [ py ]


mostly i upload the file as a DOT-fig file-- these files have never worked for you. you renamed one as .sh and it ran in bash-- that will never work. to make it work, you would have to install the fig pet (or use the iso you uploaded) and run it like this:

fig29 mkfigos10.fig #### (if you use fig os, its fig29.py)

[ now a lot of stuff happens on the screen ]

you get: mkfigos10.fig.py


thats the other thing i uploaded for you: mkfigos09 DOT fig DOT py.


the dot-fig file runs with fig, which then gives you the dot-fig-dot-py file.


then you run the .fig.py file, which is actually a python script, and as youve demonstrated by creating an iso, it works! (though it calls mksqashfs twice, and seems like it worked on the smaller file but not the larger one.)

this is really the important part though:

http://archive.org/download/Puppy_Linux ... gos0.9.iso

thanks again! thats awesome.

if at some point in the future youd like to upload a later version, i can make you another .fig.py file-- that seems to work for us.

as for the ping scripts, im very curious if that was the script that didnt modify them or you that removed the lines i wouldnt suspect you, its just that sed is really reliable! i honestly dont know which scenario is less likely. its fun if you changed it-- i admire your stubborn initiative if you did.

however if you didnt, im just as curious why sed didnt work on your setup. i would suspect busybox, but i did try using mkfigos on puppy. perhaps i didnt try the sed commands? i will almost surely try to recreate your iso (i build it myself many times, but not always the best way.)

if youre not a coder but would like to be, theres a book for you in the .iso you uploaded.

i strongly recommend skipping the intro and starting with chapter 1-- i need starhawk to cut it down for me, but so far he has other stuff to work on cant really blame him.

cheers!

[ally]

ok, how do I fix the current figos09.iso? there is new.sfs in 'newsfs' folder, should this replace the tahr one, what about naming?

the mkfig10 is named nkfigos10.fig.py and I run using python mkfigos10.fig.py

apologies for my lack of knowledge, always happy to have a go just way above!

I will create a new archive page when '09 gets corrected, and no I didn't mess with the ping script, wouldn't know how, the only thing I changed was the download location for tahr from ibiblio to nluug as it's faster