(old)Puppy Linux Discussion Forum

broomdodger wrote:

Sage wrote:

Where do you get it?

Did you try http://www.opera.com ?
Deb(other) usually works, except Slacko, of course, but mick usually attends to all our needs on that score, notwithstanding an interim issue with Norway.

Yes, but this is something I have yet to learn, which distribution, which package model...

I was hoping for some helpful guidance.

So... Other (DEB) and Debian package?

Well... I will try that, thank you.

Bill

ok,, downloaded:
Other (DEB)
Debian package
double clicked
Opera 12.14 is installed and runs great, seems more memory efficient than Seamonkey
--and--
The screen scaled nicely for this Asus 701 Eee PC with 800x480 display!
That was (too) easy.
Thank you for the nudge.
Bill

broomdodger wrote:

broomdodger wrote:

Sage wrote: Did you try http://www.opera.com ?
Deb(other) usually works, except Slacko, of course, but mick usually attends to all our needs on that score, notwithstanding an interim issue with Norway.

Yes, but this is something I have yet to learn, which distribution, which package model...

I was hoping for some helpful guidance.

So... Other (DEB) and Debian package?

Well... I will try that, thank you.

Bill

ok,, downloaded:
Other (DEB)
Debian package
double clicked
Opera 12.14 is installed and runs great, seems more memory efficient than Seamonkey
--and--
The screen scaled nicely for this Asus 701 Eee PC with 800x480 display!
That was (too) easy.
Thank you for the nudge.
Bill

Sage covered it for me........ sometimes the easy way actually works.

Assuming that a user understands the information requested by remasterpup2 dialogs, and so provides the correct information, this bug would not ever be seen. As the saying goes, "garbage in equals garbage out". Applications don't always do what the user wants, only what the user tells them to.

If this bug only resulted in remasterpup2 failing to produce the desired remaster because the user supplied the wrong information, it might not be worth mentioning. But since the consequences of this bug are a bit severe, I thought it should be reported.

This bug is not the result of recent changes to remasterpup2. This bug has appeared because of a change in behaviour of the fuser utility. The same code worked fine with the fuser supplied with Puppy 4.3.1.


Steps to reproduce - - -

WARNING: Don't try this at home!!!
(at least not unless you have saved everything you are working on to physical media)

1. Mount a non-Puppy virtual CD or real CD/DVD, preferably non-writable. (Actually, the program should never get as far as writing -- but it doesn't hurt to be safe.)

2. Run remasterpup2.

3. Forget that you have a non-Puppy CD in the drive and select it when prompted to "Choose the CD/DVD drive...".

Expected results: remasterpup2 gives an error message and exits.

Actual results: X and sometimes other processes are killed, sometimes enough to bring Puppy down.


Here's what's happening - - -

After the user selects the CD or virtual CD, remasterpup2 checks to be sure it has the initrd.gz file. If it doesn't, it is not the proper CD, so remasterpup2 unmounts it, after killing any process that was using it.

That behaviour goes back to the days when the user was only asked to identify the CD/DVD drive. I guess the idea was to automatically eject a CD/DVD that was obviously not the one needed, so that the user could then mount the proper CD. Nowadays the user is asked to mount a virtual CD or put the proper CD in the drive before this dialog appears.

In the days of Puppy 4.3.1 this might cause a few surprises, such as killing ROX-Filer if it had a window open for the mount point, but it didn't crash Puppy.

Here is what changed: remasterpup2 uses the fuser utility to determine what processes are using the device, and to kill those processes before unmounting the CD. It seems that the old fuser utility (fuser (PSmisc) 22.5, as in Puppy 4.3.1) didn't list any processes for block devices unless the device was mounted and the mount point was in use. The newer fuser utility (fuser (PSmisc) 22.14, as in Puppy Racy 5.2.2 and 5.4.91) doesn't treat block devices specially, and so lists a ton of processes using them, whether the mount point is in use or not. When it starts killing them, things are not pretty.


Here is a suggested solution - - -

Rather than modify the existing test to work with the new version of the fuser utility, I decided to try a new test that takes place before the user is asked to choose the CD or virtual CD. This way the user can't choose a CD without initrd.gz, so there is no need to unmount such a CD, or kill any processes.

I've also included a suggested fix for another minor bug. In recent versions of remasterpup2, the CD drive began showing up in the $VIRTUALCD list, so appeared twice in the list of choices in the dialog.

A modified version of remasterpup2 (based on the 2013-Mar-07 version in Woof) is attached.

I've also attached a diff file. The "@@ . . . @@" numbers in the following explanation identify the related code blocks in the diff file.


@@ -85,6 +86,27 @@

This block of code has been added to the choice_cdd function. If the function is passed "filter" as an argument, this code filters out any mounted device that doesn't contain the files initrd.gz and $PUPPYSFS in its top directory. By filtering out any mounted device that doesn't have initrd.gz, the user is never given the opportunity to choose that device, and so the code that checked after the user chose the device (and the troublesome call to fuser in that code) never executes.

It also filters out any mounted device that doesn't have the proper $PUPPYSFS file (e.g., puppy_racy_5.4.91.sfs). This was not checked by the code before, but one of the message boxes displayed a WARNING to the user to be sure that the CD or virtual CD is correct for the currently running Puppy, and suggested to the user that it can be checked by ensuring that the CD or virtual CD has the proper $PUPPYSFS file. Now that is double-checked by this code.

If there is some legitimate reason that a user would have to ignore that warning, and use a CD without the proper $PUPPYSFS file (although I can't think of such a reason), then this check for the proper $PUPPYSFS should not be implemented.

Also, if the check for the proper $PUPPYSFS is implemented, perhaps the check for initrd.gz is now unnecessary (although I suppose that someone might have a CD that isn't a Puppy Live-CD, but just happened to have the proper $PUPPYSFS file in its top directory).


@@ -369,7 +391,7 @@

This corrects another bug. Previously the CD drive was being added to VIRTUALCD.


@@ -380,12 +402,12 @@

The first call to the choice_cdd function now passes the "filter" argument so that the filtering will be done. (The second call, which only executes if the user is using a virtual CD and so hasn't yet selected a CD drive, is unchanged, so doesn't pass any argument, and no filtering will be done.)

The final change is to the first line in the obsolete code that previously checked the user's choice of CD or virtual CD to be sure that it contained initrd.gz, and unmounted it if it did not (after killing all processes that were using it). I've only added a comment to this line, but the if/fi block could certainly be eliminated, since in theory it should never execute any more.

Hi all,

I was somewhat surprised and somewhat taken aback when I discovered the sound byte associated with using the trash: namely a loud belching or burping noise. I'm hoping this is a mistake of some sort and not an attempt at humor... I am only one voice, so I would ask the Community to consider if this is how we want to present Puppy Linux to the rest of the world...

Respectfully,
Monsie

Monsie wrote:Hi all,

I was somewhat surprised and somewhat taken aback when I discovered the sound byte associated with using the trash: namely a loud belching or burping noise. I'm hoping this is a mistake of some sort and not an attempt at humor... I am only one voice, so I would ask the Community to consider if this is how we want to present Puppy Linux to the rest of the world...

Respectfully,
Monsie

It also affects Slacko and is incredibly stupid, annoying, and
disgusting.

Interesting - yet to try - however, opinion from user “Croc Ddee

Also yet to try, but I agree it is less than professional. The following might suffice.
http://www.soundsnap.com/tags/dustbin_lid

Downloading Racy 55 now. This should be interesting -- I've got this one system that won't play nice with any puppy that has a 2.6.x.x kernel. I've yet to try a 3.x.x.x kernel on it because it's a Celeron M board (processor soldered down, it's a very strange board indeed!) and I can't find anything that's both 3.x.x.x and non-PAE.

Does anyone know whether Racy 55 uses aufs or UnionFS? I know Racy 53 uses UnionFS --it's in the release notes-- but I'm not sure about Racy 55. This *might* be good to know, for my board.

Just in brief: what happens is, right after "recognizing media devices" and right before xorgwizard kicks in, something goes horribly wrong and I get this massive wall of text that I really don't understand. It's a little different each time, too. I've a thread on the subject here --> http://murga-linux.com/puppy/viewtopic.php?t=84108

I know Racy 53 uses UnionFS

Racy-5.2.2 uses unionfs, racy-5.3 aufs.

Whoops

OK then, anyone know of a non-PAE variant of Racy 522?

rjbrewer wrote:

Monsie wrote:Hi all,

I was somewhat surprised and somewhat taken aback when I discovered the sound byte associated with using the trash: namely a loud belching or burping noise. I'm hoping this is a mistake of some sort and not an attempt at humor... I am only one voice, so I would ask the Community to consider if this is how we want to present Puppy Linux to the rest of the world...

Respectfully,
Monsie

It also affects Slacko and is incredibly stupid, annoying, and
disgusting.

Agreed. Sorry about that. I'm not taking responsibility for the noise but I do for not finding it before release.

Trash fix available.

Racy 55 boots on my board!! I am quite happy!

Now, an actual bug to report...

Text mode does not work after entering graphics mode. If I CTRL+ALT+BKSP out of graphical mode, I get a blinking cursor that does absolutely nothing and is hard to see anyways. If I tell the firstrun wizard that I want to reconfigure Xorg (76Hz refresh is out of range on my LCD, had to plug it into a circa-'06 CRT to make it work) it dumps me to a black screen with absolutely nothing on it.

...er, remind me the keyboard shortcuts for different TTYs? Maybe that would help.

Worth noting, the motherboard I'm using has such a weird VGA output that I'm forced to use a graphics card. Of course it's nVIDIA, and it's my only PCI graphics card... I'll ask a friend of mine with a tech shop if he's got a spare PCI ATi/AMD card...

it's a Celeron M board

'mobiles' have always been a problem
'Celeries ' have always...ditto
'on-board' graphics - you already identified as cr*p.
Perhaps you didn't see my own solution? I have completely stopped testing anything from the Wintel cartel; even gifts of these I now refuse. Life has been so much better.
Why waste time trying to fix the unfixable?! Leave it to the masochists and pass that hardware down the line.

Otherwise, on AMD kit the latest Wary, Racy, Slacko and Precise are working spectacularly, yes, even with nV cards, even on old bangers, and with Opera!

Sage, I do not have the option of switching processor brands, or even processors, on this board. (IIRC the last time one could choose Intel or AMD for a given motherboard was the Super Socket 7! Of course there was also Cyrix back then as well...) Nor do I have even the $10-15 to acquire an ATi/AMD PCI graphics card from eBay.

Also I've had quite a different experience from you, it seems, when it comes to hardware-software interactions.

I have several functioning computers in my house right now --
A 386 box for nostalgia purposes
The Infernal Dell, laptop, P2 300MHz
HP Compaq tc4200 'convertible' laptop/tablet, Pentium M 1.73GHz
IBM ThinkPad T42 with T41 screen, Pentium M 1.6?GHz
ASUS EeePC 1000HEB netbook, Atom N270 1.6GHz
Commell LE-370Z system, Celeron M ULV 600MHz
"Hoover" (loud fans), my mother's desktop, Atom D510
Compaq Presario SR2173WM desktop, AM2 Athlon64 3500+
No-name spare box (custom build by me), skt754 Sempron somethingorother

The ONLY Linux-able systems (this excludes the 386, which has no math coproc), of the above list, which have given me problems, are...
The Infernal Dell, very low horsepower
Commell LE-370Z, very strange hardware
Compaq Presario, had issues with an ATi graphics card that thought it had HDMI when it didn't, which (oddly enough) mucked up the sound rather than the graphics!

I have had exactly ONE problem EVER with running Puppy on a Pentium M system of ANY kind. You see, some Puppies come with PAE, which I find more a misfeature (purposefully placed with good intentions) than anything else. I don't place blame on anyone for that, it's a good idea -- just that it doesn't work everywhere, particularly on Pentium M setups. My solution is, when I know I'm going to need to run Puppy on eg the Thinkpad, I steer clear of any Puppy that mentions PAE. That's all. I certainly don't go to the Puppian who made it and say "SEE, WHY'D YOU HAVE TO PUT THAT JUNK IN THERE?!" I daresay that would be a little much.

Further, I even MADE several Puplets on a system I no longer own (sold it because I needed money) -- an HP Pavilion s7220n with a Celeron M CPU and Intel integrated graphics. These Puplets were, to put it bluntly, rather poorly constructed -- I'm not very good with software -- so they are (at this time) no longer in circulation.

My point here being -- it's not really a "mobiles" or "integrated graphics" or even "Wintel" issue at all. Different computers have different problems. To blame it all on one manufacturer -- or even a few manufacturers -- only complicates things. They are still making hardware. People will still use that hardware -- and if they want Puppy, they will be running Puppy on that hardware. You can flame the companies, but that's essentially biting the hand that feeds you -- you still need to be able to support and use their stuff!

*ahem*

Returning to the subject of the Commell board that's giving me all this grief, it's worth noting that I gave up on integrated graphics long ago -- in my experience, these are usually quite reliable (even the "Wintel" ones!), BUT this board has something very strange where none of my monitors work properly with it, and only one will even recognize that there is a signal emanating from the board. Hence the graphics card, which I got off another forum for shipping when I had the $6 or so required (I don't even have that right now!) -- I accepted an nVIDIA card because I did not know there would be problems with it later.

Having said all of that, I would be far more interested in seeing some software-based solutions to the problems caused by using nVIDIA cards with this version of Racy, or a version of Racy that has neither PAE nor nVIDIA driver issues, rather than continuing to (rather unproductively) flame companies that don't do what you'd like them to do.

Keep in mind that those companies you rail against almost certainly have no direct involvement in (or even a strong effect on) Puppy and therefore can't really be blamed anyways. What the Puppy Devs do matters. What some company somewhere does, that may or may not be incorporated into Puppy, is far, far less significant indeed.

starhawk wrote:Racy 55 boots on my board!! I am quite happy!
Worth noting, the motherboard I'm using has such a weird VGA output that I'm forced to use a graphics card. Of course it's nVIDIA, and it's my only PCI graphics card... I'll ask a friend of mine with a tech shop if he's got a spare PCI ATi/AMD card...

This worked for me with a newer Nvidia card in Racy 5.5:

I booted with puppy pfix=nox,ram and ran xorgwizard,chose nouveau, and
xwin to the desktop.

I'll try it, and edit this post with the results.

Thank you, Billtoo!

EDIT: my copy of Racy 55 absolutely insists on ignoring pfix=nox -- and Xorg tells me that the driver for my card MUST be the Xorg 'vesa' driver.

Of course, popping out to text mode still doesn't work.

I'm going to call that non-success.

starhawk

Lucky you, seem to have had better 'luck' than many with your kit. I draw my comments from many different Fora, not just Puppy. As for flaming, flame where flame is due and the WIntel cartel richly deserves it - another £484,000 from M$ just this week for their duplicity; could've been the statutory $7.4bn according to the rules. Have you forgotten how the US Dept of Justice took them apart? The company with the BIG reputation for destroying all opposition - yes, even in the USofA. As for Intel, rubbish company - take a look at any System Info utility and see the long list of microcode bugs attributed to them back as far as 8088. And they have always had thermal issues due to bad design. Most recently they've had to license microcode from little ol' AMD because they couldn't get their 64bit designs to run 32bit apps. It defies belief that folks still buy their stuff, even in the USA where they have decent Sunnyvale alternatives.
Ever heard of leverage?!

Now let's get down to business. Where are you? What freebies can I send you? Bear in mind that I don't do laptops. I can probably accommodate many of your other modest requests. Let me know.

The only system I've ever used with severe thermal issues was the system that taught me something about AMDvsIntel -- namely that AMD chips really do tend to run hotter than Intel chips. It was an Acer Aspire budget laptop, with a Turion64 x2 in it. I sold it for us$80 after I got my paws on something even slightly better (the ASUS netbook IIRC) and I still feel like the buyer wound up with the short end of the deal. There are no polite words for just how bad that thing was.

I'm in NC, US -- ZIP code 27344.

If you have an ATi/AMD (one and the same now) PCI graphics card, that would be great -- old 32bit PCI, not PCI-Express! I cannot use 3.3v-only cards (look up "pci voltage keying" on Google if you're not sure what I mean) -- but 5v and universal PCI cards will work fine for me.

I'm also looking for a Mini-ITX form factor board, but I'm looking for an Intel one! It needs to be a Pentium M board with a 400/533 MHz front side bus (FSB) -- I want to put a really fast Pentium M in it, and those are all either 533 MHz FSB chips, or insanely expensive, or both -- right now I have a 400MHz-only board, and the best and second-best chips for it are $60 and $30 on eBay right now! Needless to say, ain't got that kinda money.

I will also note that, at least at this time, I can afford neither to pay your shipping costs, nor ship something to you as compensation -- USPS raised their prices on overseas shipping dramatically on Jan 27, and I don't have any money right now anyways wish I did, I really do!

There is a Service Pack for Wary and Racy 5.5, bumps to version 5.5.1:

http://bkhome.org/blog2/?viewDetailed=00176

starhawk: PM your address and I will send you a PCI card, gratis. PCI card are not voltage discriminated, only AGP. I know all about the notches and dual purpose cards, make sure you really mean PCI.
It's not the perceived heat generated that's important, it's the design technology to dissipate same. AMD processors are more long lasting and reliable, they mastered the design and fab processes early on. Criticism of their performance index is also without merit - they generally outperform that rated index by a good margin. Furthermore, their late single core devices from the Applebred and Thoroughbred-B range run much cooler, clock much faster than anything I've ever seen from Intel.
True ITX boards were originally proprietary with all smc and excessively priced. Late comers had interchangeable cpu but were also overpriced, unreliable and I've never seen or heard of an Intel one, so, perhaps, they weren't issued widely?
I'm guessing you're less than half my age so missed the x86 vs. TI fiasco, perhaps haven't yet read about the terrible impatience of the man from Big Blue when hunting an OS in the Sunshine State that landed the world with half-a-century of disasters and continuing criminal behaviour of M$?!