HELP - how do I get consistent Linux with these specs with just MicroCore

[grandma]

RE: HELP - how do I get consistent Linux with these specs with just MicroCore

.............solved....dumped flwm...finally got jwm working per Juanito's instructions - blue screens of death and other issues related to flwm stopped - working smoother - much - with jwm.

Bugs I was chasing for 2 months vaporized - gone - works well. Mouse works well. Graphics and fonts much nicer...

Wish I would have switched back in March. Ah.......the learning curve.

[grandma]

solved - see post above.

[Juanito]

I'd suggest that if you'd like an answer, it might be better to keep your questions short and concise so everybody understands what you're trying to do and what you'd like some help with.

As I understand:

1. you've installed microcore on a windows formatted hard drive/usb stick?

2. you'd like to run a number of perl scripts on boot, but do not want to use backup/restore?

BTW - I use flwm because it does not have any dependencies outside of the base, not because of any possible driver conflicts

[Rich]

Hi grandma
Your lack of focus makes it very difficult to help you. Most of your posts contain a lot of irrelevant
information that serves no purpose other than to add "noise" to your post, and in the process make
it difficult to get to the root of the problem. Based on what I was able to glean from your rambling
I'd like to make a couple of observations.

You need to take a step back, do an install using the install utility (maybe to a USB stick) and spend
some time learning about persistence, backups, and how Tinycore works in general. You appear to
have skipped this step and jumped straight to how you think it should work, and when it doesn't, you
suggest that something is wrong or there is a bug.

It's hard to tell but if you are removing your persistent directories and deleting mydata.tgz then how
are you restoring bootlocal.sh? If you have no persistent directories everything you create will be in
RAM. If you don't back it up you'll lose it when you reboot. You say that the persistent directories are
giving you errors. Are you putting them on an Linux or a Windows type file system?

Personally, based on the kind of problems you are reporting, I think most of them are self inflicted due
to you trying to make inappropriate changes to a system you do not understand.

[beerstein]

Hi there - understanding pesistance needed some time for me.
I think I have a clou now. But there is one question which comes to my mind
rght now:

Using leafpad or other applications I nedd to specify the run option in
rox filer. (right click) How can I make this permanent.

So far at every new TC start I have to set up firefox for .html and leafpad for .lst and so on

thank you in advance for helping me

[grandma]

summarized - see post below

[bmarkus]

Nice post. Who has got time to read? Just an advice. If you really expect help, please be focused, write short. And segment the issues according to priorities.

[gerald_clark]

I agree.
If the poster does not get to the point in the first paragraph, I'm gone.

[grandma]

I guess there are so many "steps" to accomplishing the objectives;

a) they need to be broken into separate topics (which I have tried to avoid), or

b) a step-by-step process (i.e. wiki or tutorial) that accomplishes the objectives.

I apologize if these objectives are not clear. Let me repeat them in this brief list

1. Boot to MC

2. During boot start a script that may call other scripts to accomplish the objectives

3. Load Alsa as that appears to work well with skype and firefox

4. Load a higher screen res to accommodate newer laptops - or the xvesa 24 bit (optional) for older machines.

5. Load flash - actually flash10ff.tcz works well

6. Load skype

7. Finally - load firefox, followed by any additional "add ons" a user might tack onto this base list such as....

8. Read and write to both ext and ntfs file systems - built into the initial kernel used to boot or immediately once loaded with a script driving that tce-load etc.

9. Work with either flwm or jwm or preferably straight MC with some other "multi-tasking small windows manager" - something that doesn't leave "blue screens" when exiting simple programs like the editor

10. Go online immediately - whether by ether or wifi.

11. Play flash videos, music (xmms or vlc).

12. Some would want client email like Thunderbird. Another party I spoke to wants a CAD/CAM program, GIMP, Office etc., while others might want a compiler environment to load. By the time you get to steps 10 and above, it depends on user preferences at this point as to what their "work load" and "tasks" are like. Of course many people will want to change steps prior to 10 - but for 90% of folks using TC in a production environment, most of that (at least this design) is required.

I hope these 12 steps are concise enough to explain what I am trying to accomplish. I hope that the fact I have a system that does this now - if I "prod it along" - gives everyone a little hope - and I hope that once done, working, seamlessly so no user ever (never) has to click "TERMINAL" to accomplish tasks with TC or MC - a 100% automated smooth install - I hope you folks feel I have contributed to the TC community to help pay back the "pain in the neck" time my posts have given you. I realize some might say TC is not suited for these tasks - that Ubuntu or Red Hat/SUSE, Knoppix or some other distro is the proper choice. I have used them - I do not believe their "bloat" adds significantly to either their functionality or their reliability, and certainly not to the speed of day to day performance, though perhaps that bloat does significantly reduce installation and configuration labor. Therefore, my premise - that creating a smooth, seamless TC/MC install that accomplishes these objectives - without the bloat - could (big IF) give TC a lift in the "public acceptance" department of those things it does quite well - run like greased lightning, have a pretty darn friendly (?tolerant?) forum of support, provide one of the most reliable kernel platforms out of all the choices, and have a rather huge, reliable repository...all in all RobertS did a great job, its evolving and I do believe I am not the first to "push" towards these objectives...others are likely to follow...I'll keep working on what I am developing and fingers crossed, angels willing, we'll get there.

I guess that sums that up. Thank you.

[Juanito]

1. Boot to MC

I presume this part works - are you booting from a linux or windows formatted partition?

2. During boot start a script that may call other scripts to accomplish the objectives

How are you storing the scripts - backup/restore, re-master, or?

3. Load Alsa as that appears to work well with skype and firefox

Are you loading this "onboot" or is it loaded via a script?

4. Load a higher screen res to accommodate newer laptops - or the xvesa 24 bit (optional) for older machines.

Done by a script I presume? Is it a perl script?

9. Work with either flwm or jwm or preferably straight MC with some other "multi-tasking small windows manager" - something that doesn't leave "blue screens" when exiting simple programs like the editor

Here's where it sounds like things start to go wrong - what are you trying to do when you get a "blue screen" when exiting editor?

[Rich]

Hi beerstein
You might want to start a separate thread for your question.

[grandma]

1. Boot to MC - I presume this part works - are you booting from a linux or windows formatted partition?

I was booting to MC - then loading xvesa and then using firefox with no windows manager due to blue screen issues. 2 weeks ago I gave up on that (firefox was a cripple without a windows manager) - and now boot regular tc with a desktop=jwm and a onboot.lst with a jwm.tcz in it.

I have 2 laptops - one has TC on a NTFS partition (older laptop) using grub. This was the machine I spent most of my early days on.

The other laptop is booting from a usb drive - fat. I spend most of my time on this laptop these days and only go to the other one to fire up windows so I can use skype in a pinch. I use syslinux on the usb drive and boot the new laptop with that. The other laptop can't boot from usb.

2. During boot start a script that may call other scripts to accomplish the objectives - How are you storing the scripts - backup/restore, re-master, or?

TCE and /TCE/OPTIONAL have the stock files (Svolli version) - on both the ntfs laptop and usb drives.

So - you would say /mnt/sdb1/tce  and /mnt/sdb1/tce/optional (USB boot - nice laptop)

or on the NTFS machine its /mnt/hda1/tce - aka C:\tce and C:\tce/optional.

In the /mnt/sda1/tce folder is a file - onload.sh - that is executed on boot, establishes an area in ram at /opt/prldesk and loads scripts that mirror the structure below - about 4mb. In the /tce/optional folder are the normal tcz files and the one Lee created - onload.tcz - which is also present in onboot.lst. This little gem gives me the abilty to "call" onload.sh on boot without storing a persistent /opt/bootlocal.sh or .X.d script.

On the same drives is a folder off the root called prldesk - as in /mnt/sdb1/prldesk

That folder has subfolders

/mnt/sdb1/prldesk/sh (sh files)
/mnt/sdb1/prldesk/htm (html and js)
/mnt/sdb1/prldesk/img (pictures)
/mnt/sdb1/prldesk/tmp (quickies)
/mnt/sdb1/prldesk/logs (script results)
/mnt/sdb1/prldesk/prlff (firefox configuration/preference files)
and under that
/mnt/sdb1/prldesk/prlff/b1 (default browser)
/mnt/sdb1/prldesk/prlff/b2 (no cookie/no pop up browser)
/mnt/sdb1/prldesk/prlff/b3 (form saving browser) etc.

Each /prlff/bX folder has a copy of a firefox configuration different from the others for specific sites/use so I don't have to change prefs.js every time - the sh scripts call the correct profile based on a table I have of web sites.

None of this is perl...though it started that way back in March/April - none of it is perl today.

On boot the onload.sh file (about 600 lines) scans the drives to find a prldesk.tgz file with all the scripts, html files - and if it fails, goes and fetches the tgz online (if it can get online) and unpacks it to /opt/prldesk to mirror the structure above. The hard drive version - call it a frugal install of the desktop - is really just there to store mostly the firefox files - the rest are not really required since the sh files and the others come right out of the tgz on boot and go to the /opt/prldesk folder - this is the main operational folder in ram.

Once the tgz file is found - where ever it may be (usually in /tce/optional) it is extracted to /opt/prldesk - and a small configuration file is made - basically a sh file that says where things are - (wow - that was a huge stick of dynamite that just went off - oh boy - happy 4th) - and that configuration file is copied to /bin, /bin/usr etc. etc. - every folder in the path to ensure any user can get the directions later.

Then onload.sh calls the next script - also running as root - and that script (#2 in the series) grabs any user data from the hard drive - like modified firefox preferences that were saved from a prior session - and layers those on top of the "default/stock" data sitting in /opt/prldesk folders.

Once that script has done its job, it calls the next script - actually about 5 of them - all running as su -c "script" tc - and gets the alsa sound, flash, skype, firefox and other aps working  based on a "user configured" script that uses tiny core specific methods to "load" applications - like tce-load.

Each script has a fallback - which is the setup.sh script - and that analyzes if tcz files are missing (automatically goes and fetches them), as well as missing dependencies (analyzing error messages automatically) - and reviews the /tmp/tcloop folder as things load to see if everything landed ok - as well as messages from attempts to run an ap after loading.

Basically every loaded ap goes through an audit to verify it came online and the user got what they wanted and if not, the audit process tries to figure out where it bombed and correct that whether its a missing ap, dependancy, memory issue or has to go online to fetch etc.

3. Load Alsa as that appears to work well with skype and firefox Are you loading this "onboot" or is it loaded via a script?

The only things loaded with onboot.lst are kmaps, proxy, jwm and onload.tcz - everything else is scripted.

4. Load a higher screen res to accommodate newer laptops - or the xvesa 24 bit (optional) for older machines. Done by a script I presume? Is it a perl script?

No perl - I have an "append" command in the syslinux file - desktop=jwm - and the old xvesa line is still in there - which I guess I could remove now. jwm has proven to be a bit more reliable and I am gonna stick with it. I know you like the other one and I wish it had worked - but ... uh... ain't going back.

9. Work with either flwm or jwm or preferably straight MC with some other "multi-tasking small windows manager" - something that doesn't leave "blue screens" when exiting simple programs like the editor Here's where it sounds like things start to go wrong - what are you trying to do when you get a "blue screen" when exiting editor?

Really strange this "problem" - and I do get it on both machines - and whether or not I have booted with any scripts or just a plain jane stock boot - sooner or later it appears - but only with flwm - though I did see it twice with jwm - but not normally. With flwm it was a regular event within 1 - 3 minutes and seemed to get worse.

It may be the svolli compile.

It may be the fact the older laptop was only 256MB of ram and I was packing a lot in there - I'd often get a "cannot allocate memory" message after 5 - 10 aps had loaded.

Remember I am running firefox AND skype - two memory and cpu hogs - plus flash - and on a 256mb laptop, it could easily choke. I was delighted when I had 5 flash screens running once plus a skype call in progress - with flwm - and the audio tracks were clean - windows would never do that for me - but the reality is I doubt the machine - either one (with 3gb of ram in one of them) - would ever run consistently at this level of cpu/memory usage. JWM seems to be more stable - and generally faster response, the only thing missing is the alt-tab to light up the drop down tool bar - flwm had that - jwm requires a right click to the desktop and if wbar disappears, I am screwed...another reason I want to launch from my own "home built" desktop - which will present options no matter what. Wbar has not been my favorite and its gonna be "snuffed" once I have my menu/system more stable.

Anyway...the system does get online much more consistently than wifi-radar did - as in tonight and on prior occasions - even if some of the scripts bomb I spent a lot of time on that wifi utility - I am shooting my signal 1/4 mile and back and there is a ton of cross channel traffic especially from the main isp here (who I do not use and is twice as strong as everyone else) so it had to work and does a pretty good job of locking in. I get 1.5MB - 3MB and considering the distance I am shooting signal, that's pretty good.

As for system performance popping open windows, loading spreadsheets etc. - I have not had the memory issues (cannot allocate memory) that I had with flwm - although I am on the newer laptop which has 3gb of ram compared to the 256mb I had before.

Bottom line - you were 110% right that much of the problem is my lack of knowledge of the environment/OS - and add to that a completely unstandard configuration and as I said - only the smallest violins of sympathy apply (thank you)...

but when its working it works well - and runs fast and if I could get rid of jwm altogether and just run the desktop I built (which is essentially a firefox browser) and boot from micro core - that'd be great.

But firefox won't multi-task without something else below it - and resizing doesn't always work either. When I was running straight MC and xvesa - no flwm or jwm - firefox was a crippled event - but did run - but some key maps didn't work right  - fonts were horrid - and in general - was not gonna fly.

It would be nice to have a wm with zero dependencies that didn't blue screen out. This bug pops up when I enter an editor from aterm - type editor filename and it sits there - nothing happens - or when I exit a file - save - X and what was a white background - black text - becomes a solid powder blue square on flwm's canvas...wierd. So if I go to another terminal prompt - hunt down the job and kill it - sometimes it would make the blue square go away - and other times I'd start popping open editors until one landed right on the same spot - then exit that one - and the blue square "might" go away. Again - this happened on both laptops - whether or not I ran my scripts or a stock boot. It may be related to the svolli compile I run. I tried the newer 3.6 (or was it 3.7?) but I couldn't figure out how to get it to read and write ntfs right out of the hole on boot so had to go back to svolli 3.5 for now.