The Mailbag (page 2)

MAILBAG #2
Submit comments about articles, or articles themselves (after reading our guidelines) to The Editors of Linux Gazette, and technical answers and tips about Linux to The Answer Gang.

questions about discover
Please solve a doubt about linux H/W detection
OS/X - "Just like real BSD"
Viewing homestead.com web pages
Opera dead in the water

questions about discover

J. Bakshi (j.bakshi at icmail.net)
Sat Mar 25 22:06:39 PST 2006

Dear list,

I am using discover 2.0.6 in a debian sarge(testing) machine with Linux 2.6.8-2-k7 kernel. There is no */etc/discover.conf* file. I can't understand where discover is looking after for its default configuration. Pls let me know so that I can change its scanning options. *discover -t modem* or *discover -t printer* don't detect my modem or printer BUT hwinfo detect these H/W perfectly. What may be the problem ?

I have presently the files in my machine are

   /usr/bin/discover 
   /etc/discover.d 
   /lib/discover
   /usr/share/discover 
   /usr/share/man/man1/discover.1.gz
   discover.conf-2.6
   discover-modprobe.conf
   discover.conf.d
   discover-v1.conf
   discover.d

What to do so that discover can load the drivers module automatically during boot ? Kindly solve my doubts. Please CC to me with best complements

[Rick] - The Debian systems I have at my disposal at this moment don't have discover installed, so I'm limited to the information available on-line. However, searching https://packages.debian.org/ for "discover" turns up a number of packages including the main "discover" one, providing this list of contents on i386 sarge (which is _not_ the testing branch, by the way: sarge=stable, etch=testing -- for quite some time, now):

https://packages.debian.org/cgi-bin/search_contents.pl?searchmode=filelist&word=discover&version=stable&arch=i386

I notice in that list a file called "etc/discover-modprobe.conf". Perhaps that's what you're looking for? Its manpage (also findable on the Internet) describes it as "the configuration file for discover-modprobe, which is responsible for retrieving and loading kernel modules".

> *discover -t modem* or *discover -t printer* don't detect my modem or
> printer BUT hwinfo detect these H/W perfectly. What may be the problem?

Ah, now _that_ is a completely different question. J. Bakshi, you really would be well advised to be careful of overdefining your problem, when you're asking for help. If your _real_ problem is that you haven't yet figured out how to configure Debian-sarge to address your modem and printer, please _say so_ and give us relevant details.

If, by contrast, you claim the problem is that you need to find discover's configuration file, _that_ is all you'll get help with, even if your problem has nothing to do with discover in the first place.

I have a suggestion: Why don't you back up and start over? Tell us about your modem and printer's nature and configuration, what relevant software is installed on your system, what is an is not happening, what you've tried, and exactly what happened when you tried that.

_Note_:
You should not attempt to recall those things from memory, but rather attempt them again while taking contemporaneous notes. Post information from those notes, instead of from vague recollections and reconstructions of events in your memory. Thank you.

[[jbakshi]] - My installed sarge is still in testing mode that's why I have explicitly mention * sarge(testing) * I have no broad-band to upgrade my system. Dial-up is too poor.

Automatically You have given answear of a question which was asked latter -:) Yes, discover-modprobe automatically loads kernel module for the discover_detected H/W .

*cat /etc/discover-modprobe.conf* shows as below
   # $Progeny: discover-modprobe.conf 4668 2004-11-30 04:02:26Z licquia $


   # Load modules for the following device types. Specify "all"
   # to detect all device types.
   types="all"

   # Don't ever load the foo, bar, or baz modules.
   #skip="foo bar baz"

   # Lines below this point have been automatically added by
   # discover-modprobe(8) to disable the loading of modules that have
   # previously crashed the machine:
But I am still looking for the configuration_file which define how the command *discover* detects buses.

I thought this issue is also related with the same doscover_configuration_file but now I have the answear. please see below

I have Epson C20SX parallel inkjet printer.

running *hwinfo --printer* detects my printer correctly. below is the o/p of the command
   14: Parallel 00.0: 10900 Printer
     [Created at parallel.153]
     Unique ID: ffnC.GEy3qUgdsRD
     Parent ID: YMnp.ecK7NLYWZ5D
     Hardware Class: printer
     Model: "EPSON Stylus C20"
     Vendor: "EPSON"
     Device: "Stylus C20"
     Device File: /dev/lp0
     Config Status: cfg=new, avail=yes, need=no, active=unknown
     Attached to: #9 (Parallel controller)
but *discover -t printer* returns nothing. I have founded the answear. man pages of discover (version 2.0.6) says that discover scans only ati, pci, pcmcia, scsi, usb. That's why it can't detect my parallel printer and PS/2 mouse, serial modem

[[[Rick]]] - [Quoting J. Bakshi (j.bakshi at icmail.net):]

> My installed sarge is still in testing mode

No. It's really not.

[Snip bit where I suggest that you start over with a fresh approach, and where you don't do that. Oh well. If you decide you want to be helped, please consider following my advice, instead of ignoring it.]

[[[[jbakshi]]]] -

Please Try to understand

1) I installed Sarge from CD pack. When I did the installation *sarge was in testing mode THEN*

2) Now sarge has become stable

3) As I don't have broadband and the dialup is also too poor, I couldn't upgrade my *installed* sarge hence *that installed sarge in my box is still a testing release*

4) I have no intention to ignore any advice as I need those seriously.

[[[[[Rick]]]]] - [Quoting J. Bakshi (j.bakshi at icmail.net):]

> 2) Now sarge has become stable

I know all this.

[no broadband]

> hence *that installed sarge in my box is still a testing release*

i knew what you were saying, but it's was somewhat misleading to refer to sarge as the testing branch. Irrespective of the state of your system's software maintenance, it's 2006, and sarge is now the stable branch. Shall we move on?

> 4) I have no intention to ignore any advice as I need those seriously.

OK, so, when you wish to do that, you'll be starting fresh by describing relevant aspects of your hardware and system, and saying what actual problem you're trying to solve, what you tried, what the system did when you tried various things, etc. You may recall that _that_ was my advice.

I said you weren't electing to follow my advice because you weren't doing that. So far, you still aren't. But that is still my suggestion. To be more explicit: You started out by defining your problem as "discover" configuration -- but there was actually no reason to believe that was the case. Therefore, you were asking the wrong question. Start over, please.

[Thomas] - I'm jumping in here to say that "discover" is a real PITA. It's the most annoying package ever, and should die after installation. It conflicts no end with anything held in /etc/modules, and actively disrupts hotplug for things like USB devices.

You don't need it for anything post-installation. If you somehow think you do, you're wrong.

Please solve a doubt about linux H/W detection

J. Bakshi (j.bakshi at icmail.net)
Wed Mar 29 04:19:05 PST 2006

Dear list,

Please help me to solve a doubt. In linux world *discover* *hwinfo* *kudzu* are the H/W detection technology. Do they directly probe the *raw* piece of H/W to collect information about it ? what about lspci, lsusb, lshw ?? Do they also provide H/W information by probing the *raw* piece of H/W or just retrieve the information which are already provided by some H/W detection technology as mentioned above ?? kindly cc to me.

[Thomas] - Not as such. They tend to query the kernel which itself has ""probed"" the devices beforehand.

> lsusb, lshw ?? Do they also provide H/W information by probing the
> *raw* piece of H/W or just retrieve the information which are already
> provided by some H/W detection technology as mentioned above ??

What difference does it make to you if it has or has not? I'll reiterate once more that you DO NOT need discover at all. In fact, it's considered harmful [1]

[1] Just by me, for what that's worth.

[[jbakshi]] - Nothing as such but my interest to know those technologies, specially from those who have already used those and quite aware the advantage and disadvante. Thanks for your response.

[[jbakshi]] - Just find out from man page. *lspci -H1* or *lspci -H2* do direct H/W access. *lspci -M* enable bus mapping mode

[[Kapil]] - In case that makes you feel happier Thomas, I saw a mail (which I can't find right now) that indicates debian-installer team is in agreement with you. However, the replacement "udev/hotplug/coldplug" may also make you unhappy :)

[[[Thomas]]] - Ugh. :) Udev is a fad that perpetuates the dick-waving wars of "Oooh, look at me, I only have three entries in /dev. You have 50000, so mine's much better". It has absolutely *no* real advantage over a static /dev tree whatsoever.

[[[[Pedro]]]] - What about the symlink magic explained here (https://reactivated.net/writing_udev_rules.html)?

To hotplug different scanners, digital cameras or other usb devices in no particular other, and make them appear always in the same known point inside the filesystem, looks like a good feature. How would that be done without udev?

[[[[[Thomas]]]]] - You can use a shell-script to do it. I did something similar a few years ago.

[[[[Ben]]]] - Are you sure, Thomas? Not that I'm a huge fan of Udev - it smacks too much of magic and unnecessary complexity - but I like the idea of devices being created as they become necessary. Expecting some Linux newbie to know enough to create '/dev/sr*' or '/dev/audio' when the relevant piece of software throws a cryptic message is unreasonable. Having them created on the fly could eliminate a subset of problems.

[[[[[Thomas]]]]] - Well, pretty much. At least you have some kind of assurance that the device "exists" whether it's actully attached to some form of physical device or not. Plus, one the permissions are set on that device and you have the various group ownerships sorted out... it's trivial.

I realise Udev does all of this as well, but you have to have various node mappings and layered complexity not observed with a static /dev tree. Then there's all sorts of shenanigans with things like initrds and the line for some kernels. It's just not worth the effort to effectivelty allow a "ls /dev" listing to show up without the use of a pager. ;)

[[[[Ben]]]] - Well, actually, now that I'm thinking about it - so could a '/dev' that's pre-stuffed with 50,000 entries. Hmm, I wonder why that's not the default - since, theoretically, these things take no space other than their own inode entry.

OS/X - "Just like real BSD"

The following originally came under the thread "Please solve a doubt about linux H/W detection". Given the drift, I've renamed this subthread for benefit of findability.

OBTW - I would like to get my hands around the throat of the person who decided that '/dev/dsp' and '/dev/mixer' are unnecessary in OS/X. Really, it would only be for a few moments... is that too much to ask?

(Installing X11+xmms on the latest OS/X is a HUGE PAIN IN THE ASS, for anyone who's interested.)

[Thomas] - That's not the only thing that's unneccesary in OS/X from what I hear. :)

[[Ben]]- [rolling eyes] Don't get me started. "Just like real BSD"... yeah, *RIGHT*.

At least they have Perl, Python, ssh, tar, and find (well, some freakin' weird version of 'find', but at least it's there) pre-installed. That part keeps me sane when dealing with Macs. Last night, a friend of mine who uses one asked my opinion of various $EXPENSIVE_BACKUP_PROGRAMS for his Mac. My response was "why would you want to actually spend *money* on this? You have 'tar', 'cpio', and 'pax' already installed." Made him happy as a lark; 'tar cvzf' was right up his alley even though he'd never so much as seen an xterm before.

[[[Kapil]]] - There is also "fink" which (in conjunction with "xterm") is a lifesaver when it comes to turning a Mac into something almost normal. (For those not in the know---"fink" is "apt" for OS/X which actually uses a .deb packaging format as well).

This alone makes OS/X far-far better than its predecessors. Sample of earlier conversion with typical Mac user whose computer I wished to use for a brief while.

[[[[Ben]]]] - Well... more or less. As in "more broken or less useful". You get a subset of the APT utilities for the command line, as well as Fink Commander which is a GUI; "apt-get", or at least the repository behind it, is badly broken since at least a quarter (IME) of the "available" packages have unsatisfiable dependencies. It also throws persistent errors (something like "/usr/foo/bar/zotz/cc1plus not executable") which can't be fixed by installing any of the available software. As well, "apt-cache search" provides a meager subset of the listings shown at Fink.org - e.g., there are several dozen OpenOffice packages shown at the latter, whereas the former has never heard of OO.

Fink Commander is even more "wonderful": when you hit the 'Upgrade Fink Commander' button, it breaks itself _and_ the entire APT kit due to a stupid interface error (the CLI app that it's wrapping blocks on a question - you can see it in the dialog area - and there's no way to feed its STDIN; all you can do is kill the GUI, which interrupts the process half-way through installation.) To fix it, you have to remove the '/sw' directory - which contains *all the software you ever installed with Fink* - and start from scratch. That's the recommended procedure. Cute, eh?

Building a compiler toolchain on a Mac with Fink, BTW, is impossible. They've got GCC - both 3.3 and 4.0 - but literally almost *nothing* else that's required.

In short, pretty bloody awful. It kinda smells like *nix, even sorta resembles it... but falls way short when there's any real work to be done.

[[[Kapil]]]

Me: I'd just like a terminal window.
Mac user: What's that?
Me: A window where you type commands.
Mac user: What are commands?
Me: Things you tell the computer to do.
Mac user: You can actually tell the computer to do things? The Mac doesn't work that way. You point and click and it guesses what you want to do and just goes ahead and does it.

At this point each of us walks off in disgust+surprise at having met an alien right here on earth.

[[[[Ben]]]] - Don't even bother asking; they won't have any idea. Just hit 'Apple-F' in Finder, type 'Terminal', click on the icon, and do your work as they sit there in utter bafflement. :)

[[[[[Breen]]]] - Don't forget to drag Terminal.app to the Dock so that it's there when you need to fix something the next time...

Viewing homestead.com web pages

Bob van der Poel (bvdp at uniserve.com)
Sun Feb 19 12:51:53 PST 2006

Just wondering if there is a simple (complex? Any?) solution to viewing certain websites which rely way too much on absolute positioning code? Most sites on www.homestead.com are quite un-viewable on my system with Firefox. They render somewhat better with Opera.

I think the problem is one of expected font and font size. I use a fairly large min. size ... but don't know if this is the problem or not.

Here's an example of something completely impossible to read: https://www.yahkkingsgate.homestead.com/ using Firefox. Again, it fares better (but still pretty ugly) in Opera. I don't have a windows box handy, but am assuming that it renders okay using IE.

[Lew] - For what it's worth, I tried several sites from the "site sampler" on www.homestead.com, and didn't find any readability (or operability) issues with Firefox 1.5.0.1 running in Slackware Linux 10.1

From my Firefox Preferences window, my

  Default Font -> Bitstream Vera Serif (size 12)
  Proportional -> Serif (size 12)
  Serif -> Bitstream Vera Serif
  San Serif -> Bitstream Vera Sans
  Monospace -> Bitsream Vera Sans Mono (size 12)
  Display Resolution -> 96 dpi
  Minimum Font size -> 12
  "Allow pages to choose their own fonts" checked
  Default Character Encoding -> Western (ISO-8859-1)

(https://www.yahkkingsgate.homestead.com/) Renders well for me, same settings as above.

[[Bob]] - Thanks for taking time to have a look. I'm wondering if I'm missing some fonts for firefox? I'm using the same firefox version. My font settings were different, but changing them to what you have doesn't seem to make much difference. Certainly, my min. is much larger ... 16 as opposed to your 12. I'm using a 19" monitor ... and the 12 is completely unreadable.

In my /etc/X11/fs/config I have the following:

#
# Default font server configuration file for Mandrake Linux workstation
#


# allow a max of 10 clients to connect to this font server
client-limit = 10


# when a font server reaches its limit, start up a new one
clone-self = on


# alternate font servers for clients to use
#alternate-servers = foo:7101,bar:7102


# where to look for fonts
#
catalogue = /usr/X11R6/lib/X11/fonts/misc:unscaled,
         /usr/X11R6/lib/X11/fonts/drakfont,
         /usr/X11R6/lib/X11/fonts/drakfont/Type1,
         /usr/X11R6/lib/X11/fonts/drakfont/ttf,
         /usr/X11R6/lib/X11/fonts/100dpi:unscaled,
         /usr/X11R6/lib/X11/fonts/75dpi:unscaled,
         /usr/X11R6/lib/X11/fonts/Type1,
         /usr/X11R6/lib/X11/fonts/TTF,
         /usr/X11R6/lib/X11/fonts/Speedo,
         /usr/share/fonts/default/Type1,
         /usr/share/fonts/default/Type1/adobestd35,
         /usr/share/fonts/ttf/decoratives,
         /usr/share/fonts/ttf/dejavu,
         /usr/share/fonts/ttf/western


# in 12 points, decipoints
default-point-size = 120


# 100 x 100 and 75 x 75
default-resolutions = 100,100,75,75


# use lazy loading on 16 bit (usually Asian) fonts
deferglyphs = 16


# how to log errors
use-syslog = on


# don't listen to TCP ports by default for security reasons
no-listen = tcp

Does anything here leap out?

[Francis] - Is that because text 1/6th of an inch high is too small for you to read, or because 12pt-text on your display is not 1/6th of an inch high?

If the latter, you may see some benefit from telling your X how many dots-per-inch your screen actually uses. For example, a 19" diagonal on a 4:3 aspect ratio monitor (a TFT screen, for example) means the horizontal size is about 15.2 inches; if you display at 1600x1200 pixels, that's about 105 pixels per inch.

If X then believes you're displaying at 100 pixels per inch, everything measured in inches will be about 5% smaller than it should be. For text at the edge of legibility, that's enough to push it over.

[[Ben]] - Not only that, it'll usually result in a bad case of the jaggies (aliasing) in text when X tries to interpolate that fractional size difference. This definitely _will_ make marginally-legible text unreadable.

[[Bob]] - Well, probably a bit of both. I can not read 1/6" lettering anymore. Used to ... but that was when I was younger can could do a lot of things I can't now. Of course, I could break down and get glasses to see the screen, but I'm resisting. I already need to put on cheaters when I read a book, etc (mind you, I seem to manage not to badly in bright light). Ahh, the joys of aging. But as someone told me: aging beats the alternatives.

[Francis] - "xdpyinfo" will tell you what X thinks the current dimensions and resolution are. If they don't match what your ruler tells you, you should consider reconfiguring.

[[Ben]] - [Nod] If there's one thing I've learned from playing around with all the X resolution configuration options, it's exactly that. As a testimonial from the positive side of things, once I got X resolution properly synched up with the actual screen size, I was able to switch to 1280x1024 without any problems. Previously, that mode produced unreadable text in many applications.

(Yes, I'm aware that I could tweak ~/.gtkrc, etc. I found it ridiculous that I would have to - and, once I got X configured correctly, I didn't have to. I like for the world to make sense, at least sometimes. :)

[[[Bob]]] - And I learn that the interface between user programs and X is hopelessly broken. Now, we are not going to fix that little issue :)

I have discovered one thing in Firefox: in the menu bar there is a <view><page style> which (I think) lets you diable the css stuff (not clear, but I think that is what it does). At least, doing that I can get rid of all overlaying text.

But, the interesting thing is that now matter what I do the page I was trying to view presents itself with overlaying text. If I turn off the min. text size completely I can get text too small for any mortal to read, but it still overlays. I've also installed additional fonts (namely some msfonts collection), but that doesn't seem to make any difference.

Oh well, perhaps we should just let ugly find its own home :)

[Francis] - If the problem is broken absolute positioning code, the quick answer is to use a browser which ignores absolute positioning code.

I don't see anything obvious in the firefox about:config page to disable that bit of their rendering or layout engine, though. If you accept that (a) you will see their content in a layout they did not expect or desire (which is already the case); and (b) you *will* see their content (which is not already the case), use a browser with CSS support which tries to be perfect at the "ignore it completely" end of the scale, rather than any which try to get to the "implement it all correctly" end. I'll mention w3m and dillo, but I'm sure you'll be able to find one that suits you. (These other browsers do have their own quirks and configuration requirements, so depending on how your distribution set things up, you may have some testing and learning to do before things work the way you want them to. And it's also possible that things *won't* work the way you want them to, no matter what.)

w3m -- the content seems all there, but the links are a bit tough to follow (because of the design choices they made: <a href=link><img alt="" src=img></a> doesn't leave much clickable space for the link).

dillo -- the content seems all there, and the images seem all there. Just not both where the designer might have hoped. Keep scrolling down...

For contrast: my firefox, in my "normal" config -- some text/text overlap, but nothing major obviously unreadable; with 16pt minimum text -- lots of unreadable bits because of text/text and text/image overlapping.

[Ben] - There's a large number of pages on the Net that are badly broken WRT layout; however, over time, I've discovered (much to my surprise) that
*other*, less- (or even un) broken pages exist as well. Based on this amazing fact, I've developed a strategy: as soon as I encounter the former, I do a bit of clicking, or even typing, and I'm soon looking at the latter. :)

Seriously - truly bad layout can make a page nearly unusable, which is much like not having the info in the first place. Given that much of the data on the Net is available in multiple places, I consider finding an alternate site - rather than trying to curse my way through
  {
     font: 3px bold italic "Bloody Unreadable";
     text-background: bright-white;
     color: white;
  }
that's half-hidden behind a blinking yellow "THIS SITE UNDER CONSTRUCTION!!!" GIF - to be a perfectly valid strategy, unless the info on that specific site is truly unique. For me, it saves lots of wear and tear - and time.

The above may seem obvious as hell to some, but lots and lots of people tend to get hyperfocused on Must Fix This Problem instead of looking at alternatives - I've done it myself, lots of times, and still catch myself doing it on occasion. Larger context is something that usually bears consideration.

My own default browsing technique consists of firing off my "google" script, which invokes "w3m" and points it at Google.com with a properly-constructed query. I page through the hits that Google provides, search until I find what I want, and - if I really need a graphical browser to examine the content, which is only true in about 5% of the cases - I hit '2-shift-m', which fires up Mozilla and feeds it the current URL (since I've set "Second External Browser" in 'w3m' to 'mozilla'.) I very, *very* rarely have to deal with really bad layout since text mode prevents many problems by its very nature.

(If the page really *is* unique, _and_ is badly broken, _and_ you really need to view it in a graphical browser, _and_ you have to keep going back there, Mozilla and Firefox have a plugin that allows you to "edit" the HTML of a given site and remembers your edits locally. Whenever you go to that page, your edits are auto-applied. Unfortunately, I don't recall the name of the plugin... Jimmy, I think I learned about it from you. Do you recall the name?)

[[Jimmy]] - Mozilla and Firefox let you override the CSS for any page you want (user.css IIRC); there's also Greasemonkey for Firefox, which lets you
run your own javascript on any page.

Recently, I came across something that allows you to edit a web page and save your edits as a Greasemonkey script: I'll pass on the link as soon as I can dig it up.

[[[Predrag]]] - Platypus(https://platypus.mozdev.org)? I also like Web Developer(https://www.chrispederick.com/work/webdeveloper/)

[[[[Jimmy]]]] - That's it!

[Ben] -

> > I think the problem is one of expected font and font size. I use a
> > fairly large min. size ... but don't know if this is the problem or not.

It would often be a problem, yes. Many sites are laid out so that there's no room for the expansion necessary to accomodate larger text.

( https://www.yahkkingsgate.homestead.com/) Looks totally fine in 'w3m'. Oh, and if I want to view it in a larger font, I simply Ctrl-right-click my xterm and set the fontsize to 'Large', or even 'Huge'.

This is why I prefer to use the 'Tab' key in 'w3m' rather than clicking the links: it never misses, no matter how small the link. :)

[[[Bob]]] - Yes, reformatting and rewriting broken code is always an option :)

But, really, the "problem" is that a guy using a cheap (relatively) out-of-the-box windows system can view these sites just fine (I'm assuming here since I have not tried it). And, one fellow here says it views fine with his Firefox. So, I have to assume that something on my setup is buggering up things.

I get lots of overlays when viewing the site. Nope, not the end of the world by any means. But, this is not the only one and I guess I was in an easily-annoyed mood yesterday :)

Since starting this thread I have added extra TT fonts, played with my resolutions and the font settings in firefox. Gotten some "interesting" results, but none which fix the problem.

Oh well, life does go on without reading badly formatted html!

[[[Karl-Heinz]]] - opera also has that option of using user-css -- which means switching off the regular css and having basically no styling at first. Then you can swtich on some default CSS sheets like high-contrast b/w or w/b,... This helps on many sites to make them quite readable and usable -- if the site works without css that is. If they broke the layout so badly that the page (links,...) won't work unstyled I usually refuse to stay at that site.

And yes: I also have a rather large min. font size and that *does* lead to trouble when boxes stay fixed but the text gets (much) larger then intended by the designer. I'm a strong advocate of fluid box layout which adapts to font changes ;-)

[[[[Bob]]]] - I'm quite convinced that being able to specify absolute positioning or absolute font size in html is a dumb thing. No idea why people think it
is necessary. Interesting that at one time html was supposed to be browser agnostic.

Opera dead in the water

bob van der Poel (bvdp at xplornet.com)
Mon Mar 13 09:39:44 PST 2006

The fat lady will not sing. Actually, no one on the opera stage will sing....

I just upgraded my internet connection from a very slow dialup connection to a much faster Ka satellite. Still slow by some measures, but when it is all you can get you get happy real fast.

Everything seems to work just dandy. Everything except the Opera browser. No matter what site I try to access I get messages like:

[[[[[[[[[[

You tried to access the address https://www.shopping.com/?linkin_id=3005960, which is currently unavailable. Please make sure that the Web address (URL) is correctly spelled and punctuated, then try reloading the page.

Make sure your Internet connection is active and check whether other applications that rely on the same connection are working.

Check that the setup of any Internet security software is correct and does not interfere with ordinary Web browsing.

If you are behind a firewall on a Local Area Network and think this may be causing problems, talk to your systems administrator.

Try pressing the F12 key on your keyboard and disabling proxy servers, unless you know that you are required to use a proxy to connect to the Internet. Reload the page.

]]]]]]]]

Heck, I can't even get the Opera help pages.

I have tried disabling all my firewall settings, but that has no effect. Besides, that is silly since firefox and konqueror both work just fine. I just tried lynx and it works fine as well.

SOoooooo ... any idea why opera is being such a pain? BTW, I had version 8 installed and just tried a 9.0 beta. I've dumped my .opera file.

I suspect that there is a proxy or firewall issue, but am no expert in this. Suggestions?

[Neil] - Have you followed the advice above? Does opera have a proxy server setup (if you click F12 is there a tick by "enable proxy servers")?

[[BobV]] - Thanks Neil. Yes, I have tried that. Just checked again, and there is NO tick beside that option. Just to test, I clicked on the option, but the tick does not appear. Which is probably just as well since I don't have a proxy server set up.

[[[Neil]]] - The error messages you were getting sound like those I got when I had Opera set up to use privoxy and it wasn't running. It seems that network access is not an issue, as you say konqueror and firefox are both working OK, but it sounds as though opera is having a problem with network access.

As it's a beta, you may be best asking on one of the opera newsgroups hosted at news.opera.com

Sorry I couldn't help more.

[Ben] - A couple of things to try:

1) Fire up a web server on your machine and try surfing to https://localhost - even if you somehow, somewhere magically created a firewall without knowing about it, you should still be able to get through to your own host.

[[BobV]] - Nope. Not on any of my browsers. I assume that is since I don't have apache (or other) server running. But that should not effect web access?

[[[Ben]]] - Bob, you've got to read _every_ part of what's been written. If you don't fire up a web server, then you can't expect to surf to 'localhost' - there won't be a web server there. It wasn't a question of affecting web access but of testing your browser's ability to connect to a server *known* not to be behind a firewall.

[[[[BobV]]]] - Opps. Yes "web server". Okay ... I don't need one on my system and I've not time to go though and install a full blown server. Is there something simple I can install just to test this?

[[[[[Karl-Heinz]]]]] - what do you use for printing? If its a cups server, try: https://localhost:631/

[Ben] -

2) Look at a local file. I.e., try a URI like file:///etc/hosts - that will tell you if your browser is capable of rendering anything at all.

[[BobV]] - Yes, that works with everything, including opera. I can view pages stored on my system with opera.

[[[Ben]]] - OK, so rendering works - that's a plus.

[Ben] -

> I have tried disabling all my firewall settings, but that has no effect.
> Besides, that is silly since firefox and konqueror both work just fine.
> I just tried lynx and it works fine as well.

Well, it's obviously in Opera itself. However, whether it's something hosed in the settings - shouldn't be, but you never know - or the app itself is dead, you can't really tell without experimenting.

> SOoooooo ... any idea why opera is being such a pain? BTW, I had version
> 8 installed and just tried a 9.0 beta. I've dumped my .opera file.

Hmmm, *beta*. Dangerous waters you swim in, Bob... :)

[[BobV]] - Well, remember that I did have a non-beta installed. That didn't work either. So, that's when I tired the newer version with the same problems.

[Ben] - If you really want to see all the files that Opera sources as it starts up - which may be a bit more than just that .opera file - you should run 'strace' on it and look for "open" calls, like so:

   strace -o opera.strace /usr/bin/opera
or wherever your executable is. Then, open "opera.strace" and search for lines starting with "open":
   grep '^open' opera.strace | less
You may find some interesting clues in there.

Conversely, if you just want the thing to work (as opposed to fixing the problem), then just revert to the last working version you used. :)

[[BobV]] - okay. Did this with -eopen and -econnect. But, nothing obvious shows up.

[[[Ben]]] - What do you mean by "nothing obvious"? I'm certain that there are _some_ files that Opera is opening as it starts up.

[[[[BobV]]]] - I meant "nothing obvious TO ME". Maybe you can see something in the attached log file.

[[BobV]] - I think I'll just be content to use firefox :)

[[[Ben]]] - Well, as I've said - you have to know what your goal is. If it's just to use a browser, then there are plenty of options (including using Firefox.) If you're trying to figure out the problem with Opera, then you need to do some troubleshooting - which is what we've all been pointing you toward. :)

[[Thomas]] - This is why strace has an '-e' flag:

   strace -eopen -o opera.strace opera

It's a pity Opera isn't dumping core, as that would have been much easier to remedy. :)

[[[Neil]]] - I would have thought connect would be more interesting than open.

[[[[Ben]]]] - I see both as useful, certainly - it would be interesting to see which 'connect' fails - but I think the 'open' calls should come first in the troubleshooting stack. If there's some sort of a configuration file that's left over from the previous install of Opera, it would be a good idea to "neutralize" it while testing. Also, seeing that a given 'connect' fails rarely tells you why it has done so, whereas an 'open' failure always reports the reason.

[[[Neil]]] - Also /usr/bin/opera is a script on my system, so the -f option to follow children would be essential to get anything useful from strace.

[[[[Ben]]]] - Ah - good point. I've never used Opera under Linux, so no way for me to know, but definitely a good thing to keep in mind. As well, it may make
sense to just run the executable that the script calls; I recall a Mozilla startup script (the last time that I installed Mozilla from a tarball) that was seriously broken, but the browser itself ran just fine.

[[BobV]] - [Quoting Ben]

>1) Fire up a web server on your machine and try surfing to https://localhost - even if you somehow, somewhere magically created a firewall without knowing about it, you should still be able to get through to your own host.

Nope. Not on any of my browsers. I assume that is since I don't have apache (or other) server running. But that should not effect web access?

[[[[[Karl-Heinz]]]]] - what do you use for printing? If its a cups server, try: https://localhost:631/

[[[[[[BobV]]]]]] - In Firefox that works fine (and Lynx).

Now Opera. 1st time I tried it I got the same "can't access" error. Well, I'm pretty sure I did. I just tried it again so I could copy down the error and it worked fine. Well, as far as accessing the main cups menu. I can go though the various cups options in opera, until I go to the download software item which brings up:
  You tried to access the address https://www.cups.org/, which is currently 
  unavailable. Please make sure that the Web address (URL) is correctly 
  spelled and punctuated, then try reloading the page.
Does this help track down the problem???

[[[[[[[Brian]]]]]]] - It sure feels like a proxy problem to me. Works fine on localhost stuff, but not out to the world? When Firefox works to the outside world? I will go to the wall on this one - let's see if I can get Opera running on this Gentoo AMD64 setup...

{cue Jeopardy music}

Okay, emerge search shows Opera 8.5 available via portage. Installing pulls in app-emulation/emul-linux-x86-qtlibs-2.2 (needed because of the AMD64-ness)

And here we go ... https://portal.opera.com/startup/

That just works (tm).

Now: In Firefox (which you say is working), Select from the menu Edit -> Preferences. On the General tab, click the connection settings button. What does it say there? Of the 4 options (Direct connection, Auto-detect proxy, Manual proxy, Automatic proxy), which radio button is enabled? If it says that Direct Connection is the way, well then. I'm confused. If. OTOH, one of the others is selected, and you can translate those settings to Opera's Tools -> Preferences: Advanced Tab, Network, click on Proxy Servers dialog, then maybe this will have been some help.

[[[[[[[[BobV]]]]]]]] - Yup, "Direct Connection"

I'm confused as well :)

CHecking (again) opera under Tools->Preferences->Advanced->Network it says to click for setting proxies if not connected directly to the internet. Double checking that, these fields are all empty.

[[[[[[[Brian]]]]]]] - Odd that lynx works, if proxying is on. What does

   echo $http_proxy
yield, from the commmand line?

[[[[[[[[BobV]]]]]]]] - Nothing. Nor does "set | grep -i htt"

Just to summarize some things:

- this all worked just fine before I upgraded from dialup to my new connection. I had a 8.x version installed (which worked fine). When that didn't work with the new connection I dl'd 9.0 beta ... but the results are identical.

- every other net aware program I've used so far (Thunderbird, Firefox, Bittorrent, gtk-gnutella, ntpd ...) all work just fine.

- the only things I did when the new "modem" was installed was to use the Mandriva wizard to set up the ethernet. As soon as the connection was established, everything worked. The only thing I didn't need to do was to dial in.

My only other GUESS is that it is something to do with my connection. The broadband connection is Ka satellite. I did check with the provider, but they had nothing on the help system for Opera problems.

Also, I've checked a number of web references and did find some stuff similar, but they appear to be of the windows + proxy type.

Getting ready to erase opera ...

[[[[[Ben]]]]] - [quoting BobV]

Is there
> something simple I can install just to test this?
> >>>strace -o opera.strace /usr/bin/opera

I happen to really like 'thttpd'. Dirt-simple, no configuration necessary, and nicely secure. E.g.: create a directory with an 'index.html' file in it (grab any HTML file and rename it), then 'cd' to that directory and type 'su -c thttpd'. Enter your root password, and there you are; you should now be able to see that page by surfing to https://localhost/ .

[[[[[[Thomas]]]]]] - I happen to prefer its so-called predecesor: lighttpd, since this addresses several glaring limitations and bugs in thttpd.

[[[[[Ben]]]]] - [quoting BobV]

> >>okay. Did this with -eopen and -econnect. But, nothing obvious shows up.
> >
> >What do you mean by "nothing obvious"? I'm certain that there are _some_
> >files that Opera is opening as it starts up.
>
> I meant "nothing obvious TO ME". Maybe you can see something in the
> attached log file.

Let's see... here's some interesting stuff:

> open("/home/bob/.opera/opera6.ini", O_RDONLY|O_LARGEFILE) = 4
> open("/home/bob/.opera/lock", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 4
> open("/home/bob/.opera/lock", O_RDWR|O_CREAT|O_LARGEFILE, 0666) = 4
[ ... ]
> open("/home/bob/.opera/styles", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 5
> open("/home/bob/.opera/styles/debugwithoutline.css", O_RDONLY|O_LARGEFILE) = 6
> open("/home/bob/.opera/styles/accessibility.css", O_RDONLY|O_LARGEFILE) = 6
> open("/home/bob/.opera/styles/contrastbw.css", O_RDONLY|O_LARGEFILE) = 6
> open("/home/bob/.opera/styles/contrastwb.css", O_RDONLY|O_LARGEFILE) = 6
> open("/home/bob/.opera/styles/hidecertainsizes.css", O_RDONLY|O_LARGEFILE) = 6
> open("/home/bob/.opera/styles/disabletables.css", O_RDONLY|O_LARGEFILE) = 6
> open("/home/bob/.opera/styles/hidenonlinkimages.css", O_RDONLY|O_LARGEFILE) = 6
> open("/home/bob/.opera/styles/imageandlinkonly.css", O_RDONLY|O_LARGEFILE) = 6
> open("/home/bob/.opera/styles/nostalgia.css", O_RDONLY|O_LARGEFILE) = 6
> open("/home/bob/.opera/styles/showstructure.css", O_RDONLY|O_LARGEFILE) = 6
> open("/home/bob/.opera/styles/textonly.css", O_RDONLY|O_LARGEFILE) = 6
> open("/usr/share/opera//ini/pluginpath.ini", O_RDONLY|O_LARGEFILE) = 5
> open("/home/bob/.opera/pluginpath.ini", O_RDONLY|O_LARGEFILE) = 5

Well, you did say that you blew all that away - so presumably, all of the above got created fresh.

> open("/home/bob/.kde/share/config/kcmnspluginrc", O_RDONLY|O_LARGEFILE) = 5
> open("/usr/lib/jre-1.4.2_09/lib/i386/libORBitCosNaming-2.so.0", O_RDONLY) = -1 ENOENT (No such file or directory)

Hmmm... could be time to upgrade that JRE version. Mozilla gave me lots of grief until I did, anyway.

You're right; doesn't seem to be anything obvious. :)

[[[[[[BobV]]]]]] - Cool. Got thttpd running. Serves out the thttpd "got it working" message in both firefox and opera. Firefox will take me to the program's web
site; opera just hangs (seemingly forever).

Doing a bit more playing and I've another hint here.??? When you launch opera try a web address it hangs. Apparently forever (at least more than 5 minutes). Try the same address, same behaviour. Try another address and you get the "unavailable" error message. From that point on accessing anything external brings the "unavailable" message.

I'm really starting to think it is a network problem due to my satellite connection. But, that really does seem silly. Doesn't it?

[[[[[[[Ben]]]]]]] - Well, it can't be the network since the other browsers use the network without any problems. It sounds as though the code that does the
socket-related functions in Opera is broken (which makes Neil's suggestion of checking the 'connect' calls a better guess than mine. :)

Just out of curiosity, try this:
   strace -f -o opera.strace -e trace=connect `which opera`
The resulting file should be pretty short - and might show exactly where Opera is falling down. If it does, that would be a bug report that Opera developers might be very happy to see.

[[[[[[[[BobV]]]]]]]] - Okay. Here it is. Hope it means more to you than to me :)

[[[[[[[[[Ben]]]]]]]]] -

   > 18802 connect(3, {sa_family=AF_FILE, path="/tmp/.X11-unix/X0"},   19) = 0
   > 18810 +++ killed by SIGKILL +++

*That* looks like the dude. When Opera makes that call to the X socket - which, BTW, you should check to make sure that it exists and is usable:
   ben at Fenrir:~$ ls -l /tmp/.X11-unix/X0 
   srwxrwxrwx 1 root root 0 2006-03-17 11:29 /tmp/.X11-unix/X0
   ben at Fenrir:~$ netstat|grep X0
   unix  3      [ ]         STREAM     CONNECTED     8734     /tmp/.X11-unix/X0
   unix  3      [ ]         STREAM     CONNECTED     6769     /tmp/.X11-unix/X0
   unix  3      [ ]         STREAM     CONNECTED     6551     /tmp/.X11-unix/X0
   unix  3      [ ]         STREAM     CONNECTED     5811     /tmp/.X11-unix/X0
   unix  3      [ ]         STREAM     CONNECTED     5747     /tmp/.X11-unix/X0
   unix  3      [ ]         STREAM     CONNECTED     5214     /tmp/.X11-unix/X0
   unix  3      [ ]         STREAM     CONNECTED     5212     /tmp/.X11-unix/X0
   unix  3      [ ]         STREAM     CONNECTED     5208     /tmp/.X11-unix/X0
   unix  3      [ ]         STREAM     CONNECTED     5198     /tmp/.X11-unix/X0
   unix  3      [ ]         STREAM     CONNECTED     5193     /tmp/.X11-unix/X0
   unix  3      [ ]         STREAM     CONNECTED     5191     /tmp/.X11-unix/X0
   unix  3      [ ]         STREAM     CONNECTED     5177     /tmp/.X11-unix/X0
- that subprocess in Opera dies (perhaps it's killed by some kernel process for trying to corrupt the stack? That's just a SWAG on my part, and you'd need to do a full 'strace' and look at the calls that would have been between 18802 and 18810.) I would venture to say that it's internal to Opera rather than the library that does the 'connect' call; there's lots of other stuff that would break if 'connect' itself was at all buggy.

[[[[[[[[BobV]]]]]]]] - Thanks again for taking time to work though this little mystery.

[[[[[[[[[Ben]]]]]]]]] - You're welcome, Bob. [grin] I have lots of fun with this kind of detective work; helps me improve my own troubleshooting skills for when I need them.

[[[[[[[[[[BobV]]]]]]]]]] - Just to close this thread out :) I have reinstalled my linux distro (Mandriva 2006), downloaded Opera 8.5 and it connects/runs just fine. Honestly, I have no idea what the original problem was ... but I suspect that something broke when I changed from a dialup/ppp system to using the new connection (satellite with a LAN modem). I really do wish I knew what the problem really was ... but that'll have to remain one of the many mysteries of life!

This page edited and maintained by the Editors of Linux Gazette

Talkback: Discuss this article with The Answer Gang

[BIO]

Kat likes to tell people she's one of the youngest people to have learned to program using punchcards on a mainframe (back in '83); but the truth is that since then, despite many hours in front of various computer screens, she's a computer user rather than a computer programmer.

When away from the keyboard, her hands have been found full of knitting needles, various pens, henna, red-hot welding tools, upholsterer's shears, and a pneumatic scaler.

Copyright © 2006, Kat Tanaka Okopnik. Released under the Open Publication license unless otherwise noted in the body of the article. Linux Gazette is not produced, sponsored, or endorsed by its prior host, SSC, Inc.

Published in Issue 127 of Linux Gazette, June 2006

<-- prev | next -->