All browsers are crashing on FreeBSD 8.1-STABLE amd64

Status
Not open for further replies.
kenorb

kenorb

I've installed FreeBSD 8.1-"STABLE" (amd64) 2 weeks ago. Compiled with default config for core2 (without debugging symbols, because by default fbsd has no space for it in /? another bug?). From that time (when I installed FreeBSD), I can't use my computer properly. Nothing works properly, system crashing, browsers crashing, every 5 minute I've got some problems which normally I shouldn't have. It was working fine on Ubuntu 9.04 and 10.x

Chrome, Firefox, Epiphany, Opera (mostly freezes), etc. I don't know what's going on, but it crashing after few minute of usage. Chrome within 1 minute of usage, Firefox and Epiphany within few minutes of usage, Opera within 15 minutes of usage.

Code: 
> dmesg
pid 30525 (firefox-bin), uid 1001: exited on signal 6 (core dumped)
bge0: promiscuous mode disabled
pid 53995 (firefox-bin), uid 1001: exited on signal 6 (core dumped)
pid 53975 (chrome), uid 1001: exited on signal 4 (core dumped)
pid 54098 (firefox-bin), uid 1001: exited on signal 6 (core dumped)
pid 60069 (firefox-bin), uid 1001: exited on signal 6 (core dumped)

When run Opera, with 10 tabs I've got used more than 1,5GB RAM.
Code: 
71558 kenorb        8  44    0  1588M  1391M ucond   0  21:12 90.97% opera

What happened with browsers which worked on 486 with 64MB RAM? And it worked?;) And now on amd64 with 4 CPUs with 4GB RAM it doesn't?

Why?
 
Code: 
> cat /etc/make.conf
CPUTYPE?=core2
KERNCONF=BRO
MAKEOPTS="-j8"
PERL_VERSION=5.10.1
SUP_UPDATE=/etc/standard-supfile
PORTSSUPFILE=/etc/ports-supfile
DOCSUPFILE=/etc/doc-supfile
# added by use.perl 2010-10-20 18:35:21
PERL_VERSION=5.10.1

Code: 
> sudo pkg_libchk
>
LOL, after test of 965 packages, no any output?;/
It's good or not?
 
Code: 
> sudo pkg_libchk
>
LOL, after test of 965 packages, no any output?;/
It's good or not?
Click to expand...

That's good, it didn't find any problems. Okay, how about /etc/rc.conf and uname -a?
 
Code: 
> uname -a
FreeBSD kenorb 8.1-STABLE FreeBSD 8.1-STABLE #0: Tue Oct 19 15:28:55 BST 2010     root@kenorb:/usr/obj/usr/src/sys/BRO  amd64

Code: 
> grep -v ^# /etc/rc.conf | xargs
apache22_enable=YES mysql_enable=YES mysql_args=--skip-name-resolve cupsd_enable=YES ifconfig_bge0=DHCP background_dhclient=YES hostname=kenorb
inetd_enable=NO nfs_client_enable=YES sshd_enable=YES gnome_enable=YES moused_flags=-3 moused_port=/dev/psm0 moused_type=auto moused_enable=YES 
moused_nondefault_enable=NO hald_enable=YES dbus_enable=YES devd_enable=YES font8x14=iso02-8x14 font8x16=iso02-8x16 font8x8=iso02-8x8 
keymap=uk.iso saver=daemon allscreens_flag=80x50

Code: 
last pid: 42683;  load averages:  3.10,  1.81,  0.92
186 processes: 2 running, 182 sleeping, 2 zombie
CPU: 26.2% user,  0.0% nice,  1.8% system,  0.0% interrupt, 72.0% idle
Mem: 1057M Active, 1909M Inact, 560M Wired, 63M Cache, 416M Buf, 328M Free
Swap: 12G Total, 586M Used, 11G Free, 4% Inuse, 4K In

My: pciconf -vl
is here:
http://forums.freebsd.org/showthread.php?p=108091#post108091

Code: 
> grep -v ^# /boot/loader.conf | xargs
linux_load=YES splash_bmp_load=NO splash_pcx_load=NO vesa_load=YES bitmap_load=YES bitmap_name=splash.bmp bitmap_type=splash_image_data 
loader_logo=fbsdbw nvidia_load=YES agp_load=YES kern.ipc.shmseg=1024 kern.ipc.shmmni=1024 vboxdrv=YES vboxnetflt=YES vboxnetadp=YES 
speaker_load=YES sem_load=YES
 
kenorb said:
Code: 
> grep -v ^# /etc/rc.conf | xargs
Click to expand...

Please don't do that. If you want to eliminate comments, the grep alone is enough.

Code: 
apache22_enable=YES mysql_enable=YES mysql_args=--skip-name-resolve cupsd_enable=YES ifconfig_bge0=DHCP background_dhclient=YES hostname=kenorb
inetd_enable=NO nfs_client_enable=YES sshd_enable=YES gnome_enable=YES moused_flags=-3 moused_port=/dev/psm0 moused_type=auto moused_enable=YES 
moused_nondefault_enable=NO hald_enable=YES dbus_enable=YES devd_enable=YES font8x14=iso02-8x14 font8x16=iso02-8x16 font8x8=iso02-8x8 
keymap=uk.iso saver=daemon allscreens_flag=80x50
Click to expand...

Either xarg eliminated quoting, or you did, can't tell. All the mistaken moused stuff from the other thread is still there, and unnecessary defaults.

Code: 
> grep -v ^# /boot/loader.conf | xargs
Click to expand...

"xargs, please take this nice text, strip the important quoting, and turn it into an unreadable paragraph."
 
I just don't want to do the mess with the long posts.
If you think it's ok, that's fine.

Code: 
> cat /etc/rc.conf
# -- sysinstall generated deltas -- # Tue Oct 19 09:43:43 2010
# Created: Tue Oct 19 09:43:43 2010
# Enable network daemons for user convenience.
# Please make all changes to this file, not to /etc/defaults/rc.conf.
# This file now contains just the overrides from /etc/defaults/rc.conf.

# SERVICES
apache22_enable="YES"
mysql_enable="YES"
mysql_args="--skip-name-resolve"
cupsd_enable="YES"

# NETWORK
ifconfig_bge0="DHCP"
background_dhclient="YES"
hostname="kenorb"
inetd_enable="NO"
nfs_client_enable="YES"
sshd_enable="YES"

# XORG
gnome_enable="YES"

# MOUSE
# moused_flags="-3"
# moused_port="/dev/psm0"
# moused_type="auto"
moused_enable="YES"
moused_nondefault_enable="NO"
hald_enable="YES"
dbus_enable="YES"
# devd_enable="YES"

# OTHER
font8x14="iso02-8x14"
font8x16="iso02-8x16"
font8x8="iso02-8x8"
keymap="uk.iso"
saver="daemon"
allscreens_flag="80x50"

Code: 
> cat /boot/loader.conf 
linux_load="YES"
splash_bmp_load="NO"		# Set this to YES for bmp splash screen!
splash_pcx_load="NO"		# Set this to YES for pcx splash screen!
vesa_load="YES"			# Set this to YES to load the vesa module
bitmap_load="YES"		# Set this to YES if you want splash screen!
bitmap_name="splash.bmp"	# Set this to the name of the bmp or pcx file
bitmap_type="splash_image_data" # and place it on the module_path
#autoboot_delay="3"		# Delay in seconds before autobooting,
# beastie_disable="YES"		# Turn the beastie boot menu on and off
loader_logo="fbsdbw"		# Desired logo: fbsdbw, beastiebw, beastie, none
kern.hz="250"			# Set the kernel interval timer rate

# NVIDIA
nvidia_load="YES" 		# load FreeBSD NVIDIA driver
agp_load="YES" 			# load FreeBSD AGP GART driver
kern.ipc.shmseg=1024
kern.ipc.shmmni=1024

# VirtualBox VM
vboxdrv="YES"
vboxnetflt="YES"
vboxnetadp="YES"

# OTHER
speaker_load="YES"
sem_load=YES
Code: 
> cat /etc/make.conf
CPUTYPE=core2
KERNCONF=BRO
MAKEOPTS="-j8"
PERL_VERSION=5.10.1
SUP_UPDATE=/etc/standard-supfile
PORTSSUPFILE=/etc/ports-supfile
DOCSUPFILE=/etc/doc-supfile
# added by use.perl 2010-10-20 18:35:21
PERL_VERSION=5.10.1
 
Lots of possibilities for the problem. Also, you have several threads about various types of crashes, which are probably all related. You're messing with kern.hz, which implies maybe this is all in a VM. Please describe your hardware, and consider solving problems before adding complexity by customizing your configuration and installing new applications.
 
wblock said:
Lots of possibilities for the problem. Also, you have several threads about various types of crashes, which are probably all related. You're messing with kern.hz, which implies maybe this is all in a VM. Please describe your hardware, and consider solving problems before adding complexity by customizing your configuration and installing new applications.
Click to expand...

I'm not customizing anything that works and when I had this crashes, I'd default option (hz=1000).
Yesterday I've changed it to:
Code: 
> sysctl -a | grep kern.hz
kern.hz: 250
Somebody told me that this is the best option for desktop.

Every browser is crashing, but those crashes probably are separated:

Firefox.
Before I added: sem_load="YES" to loader.conf (but it didn't help).
See: more /usr/ports/www/firefox/pkg-message
Yesterday I recompiled the world and kernel, by removing question mark from CPUTYPE=core2.
And also upgraded Firefox from 3.6.10 to firefox-3.6.12.
I don't know which was the fix (from those two), but I'm using it now on the forum and works fine for now, I'll see later.
So probably there were some bugs in recent version, but I'd no time to find them.

Epiphany
it showing following errors when trying to debug:
Code: 
> gdb epiphany 
...
open dsp: No such file or directory
Program received signal SIGBUS, Bus error.
[Switching to Thread 809a041c0 (LWP 100654)]
Program::addControlInCurrentFrame (this=0x809bf5400, ctrl=0x80fc29580) at program.cc:846
846	program.cc: No such file or directory.
	in program.cc
Could be some bug (I couldn't find anything), but I don't care for now about this browser.
When I'll find the time, I'll try to debug it.

Opera
Opera is the most stable browser. It uses for unknown reason lots of memory and too much CPU, but it choosing to slow down, rather than to crash. Probably there is some hard-coded limit.
Started with 9 tabs:
Code: 
35289 kenorb        5  44    0   380M   283M ucond   2   0:11 27.98% opera
35289 kenorb        5  44    0   376M   283M ucond   2   0:12 14.79% opera
35289 kenorb        5  44    0   380M   280M ucond   1   0:19 23.58% opera
Sometimes I'm using around 100, so it's not the best choice. But at the end it probably crashing, because process using too much memory at once?

Chrome
Following the reported bugs and backtraces above, one crash was related to DNS-prefetching (SEGV in Google URLFetcher, and alternative DNS-prefetcher), second some bug related to SIGINT, gdb and freeze (which I had on Linux as well), other random freeze (which I had on Linux as well), third one to SIGTRAP (which probably is not a bug)
and probably the last one is related to debug symbols and FreeBSD
See: http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2010-09/msg00480.html
Guy has similar problem on 8.1-STABLE, his kernel even panic:)
There is also setting which could be related to this crash: kern.ipc.shm_allow_removed.
Ruben said:
I have changed the shared memory backend for Chromium with this upgrade:
you MUST make sure that 'sysctl kern.ipc.shm_allow_removed=0' for this
stable build to work. The latest port can be found here:
Click to expand...
See: http://www.freebsd.org/cgi/query-pr.cgi?pr=146302
chrom...@hybridsource.org said:
If you were running an early build of Chromium for FreeBSD, you might have set it to 1, but it needs to be 0 for all Chromium builds since 7 months ago.
...
Oh, are you compiling these in Debug mode on amd64? I never got Debug mode on FreeBSD amd64 to work- it would crash as soon as you type something in the omnibox- so if that's what you're building, the crashiness is expected.
Click to expand...
Change of kern.ipc.shm_allow_removed didn't help for me (still crashing on start).
The weirdest thing is that it crashing on start (without gdb), and not crashing when I'm trying to debug it;/
I tried to download the recent sources of Chrome and compile it, but compile process is not user-friendly, but it's another issue.
 
Too many tabs open in Opera probably. I'd only have more than twenty open in sites (like this one) that use small amounts of memory to load/view/refresh. If you use several browsers, I'd clean out each's cache upon exit (one can write a simple .sh) to start with a fresh slate. Just something to try to lessen the time until it is all fixed.
 
The same problem with Firefox again:

Code: 
Program terminated with signal 5, Trace/breakpoint trap.
No backtrace;/
#0  0x0000000801c65097 in ?? ()
#1  0x0000000801c6555a in ?? ()
#2  0x00007fffffffcc4d in ?? ()

But this time signal 5, instead of 6.
 
kenorb said:
I'm not customizing anything that works
Click to expand...

Yet it seems very few things actually work for you, and you're changing lots of things at the same time. Building new kernels, changing config defaults, installing more applications, and problems, problems, problems.

That last one is specifically included as an example of self-inflicted foot-shooting.

Every time you change one of these things, it adds another variable to the already-existing problems, making them harder to solve.
 
Or, as I was about to say: stop trying to dig your way out of the quicksand. Wipe and start over. You can't keep opening threads with only-happening-to-you types of problems, blaming the operating system and the ports for everything, but not yourself.

Speaking of X/GUI systems, I run the same OS version (8.1 STABLE / amd64), a lot of the same ports (at least Firefox and Chromium (9 even)), and with zero problems. Have done so for a long time now, and I'm a frantic, daily updater and rebuilder of all sorts of stuff, kernels, ports, you name it. Bad things should happen to me all the time. But they don't.

And seeing the (lack of) response to most of your problems and queries: if it's _that_ unique: start over.
 
Maybe because most people doesn't use most of the features of their system as much as I do? Doesn't use anything else apart of: ls, cat, cd, eventually awk, sed? Doesn't compile the kernel for amd64 and using default configuration of everything? If something will crash, they do restart and they don't care or simple they can't find or don't want to waste their time on looking for solutions or bugs? They're not programmers and not using dev tools? Playing with FreeBSD for fun, not for work?
For me if something doesn't work, there is the problem which should be fixed. If nothing else has the problem, doesn't mean that problem doesn't exist, maybe people don't want to waste their time on forum, because they will read 1 of the 4 common answers: man, Google, reboot or reinstall.
You are simply don't care about nothing (it works on my machine), this is the main reason why OpenBSD, NetBSD are already DEAD (caveman systems), no support for SMP, no support for nothing.
I was surprised that even default dhclient doesn't support option 119, when most of the Linux'es does. Maybe after 10 years it does?

My configuration of everything was DEFAULT. I only changed the things which simply doesn't work.
I didn't change any line in my kernel conf (apart of debug symbols).
Basically without any changes make.conf, rc.conf, loader.conf, ports-supfile, system can't be configured and doesn't work by default.
I'm nearly to remove FB, and buy a Mac (also BSD-based) to do my work.
 
Listen, we have 16,000+ FreeBSD users on these forums. The most active users are, like me, constantly compiling, recompiling, tweaking, testing/building/running custom kernels, playing around with options, compilers, and flags. You're absolutely not unique in that respect - however you may simply lack knowledge, experience, and insight into how to tweak what, and how to back out of stuff that backfires. Like the version,v files that you got from csup in another thread: there's absolutely no way that a default setting or a properly changed setting or a properly executed command can saddle you with version files -- but it may lead to enormous problems. Make small errors with two or three other default settings and commands, and your problems deteriorate exponentially. Been there, done that. You don't get anywhere without 'suffering the learning curve' first; part of it is: admitting you're not perfect and make mistakes, before blaming something that works fine for others.

That your problems appear to be unique (and rather puzzling most of the time) makes it clear that you're doing something other people don't do (because they know better, or take things one step at a time instead of jumping too far ahead -- not because they're not 'adventurous' or 'cutting-edge', or something pompous like that), leading to things that are systemically and fundamentally wrong. That whole list of activities you enumerated - almost _everybody_ who works on the console on FreeBSD servers does that, and they do much more. A lot of us are experimental by nature. You simply cannot attribute the numerous errors you experience to some 'FreeBSD mentality' that does not agree with you, or the notion that 'we' do not understand 'you', because you're on the 'cutting edge of tweakdom' in some way. You're not, believe me. That, to me, sounds more like a caveman and/or ostrich mentality than a willingness to admit that you're in way over your head and need to find a way out of the mess you're in. You have to be able to own up to that instead of blaming everyone and everything around you.

I suggested starting over and sticking to the defaults until you've had ample experience with the OS and its subsystems, contributed applications, the ports tree, etc. Most of the people tweaking and testing out new things know which defaults to leave alone (through shame), and which ones one can safely tweak and deviate from (from experience). You're simply not that far advanced yet. That's no shame, and I'm not bashing you over the head. I am giving you a reality check based on having dealt with the OS for 6 major versions and over 15 years on 100+ machines (lost count of the amount of updates/upgrades/rebuilds..).

So again: wipe, start over, leave everything alone that you have no full understanding of, and expand from there. FreeBSD may be an acquired taste which requires a hands-on approach and a willingness to learn, but it obviously pays off dividend to a majority of its users every single day. If that sounds like too big an investment, by all means move on to something that suits you better. Just don't imply that FreeBSD is the problem when you do. It may not be a match, but a problem it ain't.
 
kenorb said:
My configuration of everything was DEFAULT. I only changed the things which simply doesn't work.
I didn't change any line in my kernel conf (apart of debug symbols).
Basically without any changes make.conf, rc.conf, loader.conf, ports-supfile, system can't be configured and doesn't work by default.
Click to expand...

In that other thread I just posted about how your ports-supfile had errors. So is this due to FreeBSD miscopying a couple of lines, or was it an error on your part? All of these problems have the ring of the old "my program doesn't work, it must be a bug in the compiler" complaint that's popular with CS students before they learn humility.

I'm nearly to remove FB, and buy a Mac (also BSD-based) to do my work.
Click to expand...

It does look like FreeBSD is not right for you, or vice versa.
 
Finally I could compile Firefox with debug symbols!
http://forums.freebsd.org/showthread.php?t=19041
Ended with patch. Hard one!;)

Now Firefox it's crashing on start.
Code: 
New block
###!!! ABORT: X_ShmCreatePixmap: BadImplementation (server does not implement operation); 2 requests ago; id=0x3e00004
Re-running with MOZ_X_SYNC=1 in the environment may give a more helpful backtrace.: file nsX11ErrorHandler.cpp, line 182
Trace/BPT trap
+ exitcode=133
+ exit 133
The same problem:
http://forums.freebsd.org/showthread.php?t=15446
From June 27th, and still not fix?
Reported couple of bugs in Bugzilla, reported there.

EDIT: Finally fixed Firefox crash by removing flashplugin-mozilla
See solution: http://forums.freebsd.org/showpost.php?p=109189&postcount=9
 
I never write posts that refer to somebody's opinion on some OS. I find these conversations never-ending with zero entropy. Nevertheless, by reading this thread I have to agree with dutchdaemon and wblock:

People starting a thread with a title of the form "All browsers are crashing on 'X'" and deduce that 'X' is to blame, have a narrowed view on things. It is highly unlikely that an OS, even Microsoft ones, would fail to start any browser/program/utility, no matter how "bad" they can be. So, if this would happen to me, I would do what dutchdaemon said: start from scratch.

"Minor tweaks" -as you imply on your threads- like CPUTYPE=core2, may cause a lot of problems to your system's stability. And if so, a thread named "my x,y,z programs all crash on my system" should have initially started as: "after this tweak, my system is unstable". It has to do with causality. See the symptoms, find the real cause, and look/ask for a remedy. In case you follow the "ask for a remedy" path, then try to be a bit more polite. Even if you ARE a great unix-like user, nobody cares, especially if you act in that way.

Share your thoughts and problems in a polite way. Everybody will be happy to help you or learn from your ideas. Keep your complexes out of public rooms; they may come back like a boomerang.

Sorry for my "political reply" on this thread, I have never done it...until now.
 
Sorry, but all my problems are based on reproducible steps, proofs and backtraces which end up with the real BUGS and patches. And I'm not only one who reports those bugs. And it's not my fault, but software and system bugs and some system incompatibility. If something doesn't work, I'm not imagine it. People probably doesn't post their problem here, because they know already the answer: start from scratch or why you customized your system (don't do that!)?!

To summary:
Epiphany and Firefox was crashing, because of flashplugin-mozilla, which is available in ports and it's buggy.
http://www.google.co.uk/search?hl=e...iphany+"BadWindow+(invalid+Window+parameter)"
(7,070 results)
I was not imaging this problem.
Reported the BUG in flashplugin (which is available officially in ports) into the right place:
https://sourceforge.net/tracker/index.php?func=detail&aid=3105876&group_id=110956&atid=657852
Maybe somebody will treat it more seriously, instead of talking about nothing here.
Most people don't know where to start and how to report that kind of problems, they simply just uninstalling broken software and using alternatives.
Firefox wasn't crashing only for me.
See: http://forums.freebsd.org/showthread.php?t=15446
Why ports doesn't say in pkg-message?: This port is 5 years old and doesn't work, use xxx instead.

Reported the bug here: http://www.freebsd.org/cgi/query-pr.cgi?pr=152080

http://forums.freebsd.org/showthread.php?p=109193
Chrome is crashing, because of SEGVs in the code (which is not normal). Reported proper BUGS here:
http://code.google.com/p/chromium/issues/detail?id=60907
http://code.google.com/p/chromium/issues/detail?id=60897
see more reports in #3 and Chrome developers didn't tell me to start from scratch. They have enough knowledge to solve that problem in their code to make it working on FreeBSD.
Bug with readlink when compiling Chrome is caused that readlink doesn't support -f param. It's not my fault that FreeBSD utils are not compatible with GNU (man readlink). The same with mktemp, sed, even beep, etc.
Other bugwhen following the out-of-dated wikihappening as well for other people.

Case when I couldn't compile Firefox from ports using WITH_DEBUG, is definitely FreeBSD ports BUG, because doesn't work at all and probably not many people needed to compile it with debug symbols. I'd the same problem couple years ago, no committed fix till today.
Reported BUG: http://www.freebsd.org/cgi/query-pr.cgi?pr=152043
Serious reply with working patch. Nothing about 'start from scratch'.

The problem which I had in the network, that half of internal hosts wasn't working only for me on FreeBSD (all colleges said: don't use FreeBSD, install Linux), and it was working on all Linux in my work, was because dhclient is too old and doesn't follow new features (rfc3397 implementation) (checked in source as well, it's missing), it's not my fault as well that something wasn't implemented, which is in the most of operating systems in nowadays.
Reported bug here: http://www.freebsd.org/cgi/query-pr.cgi?pr=151940

Couple of years ago I even sent the patch in simple killall.c which was buggy on FreeBSD 5.10-"STABLE", because of SEGVs crashes and I stopped to using it because of problems similar to which I've again. Basically it wasn't working as a desktop, too many problems with it every day (comparing to other OS).

etc. etc.

It just annoying to use some system, where nobody care and all problems are threated as: use default settings or start from scratch, instead of helping with specified problem why does it happen. If somebody has lack of knowledge, better to not post anything, rather than to raise your own personal value.
 
kenorb said:
Sorry, but all my problems are based on real proofs and backtraces which end up with the real BUGS and patches. And I'm not only one who reports those bugs. And it's not my fault, but software and system bugs and some system incompatibility. If something doesn't work, I'm not imagine it. People probably doesn't post their problem here, because they know already the answer.

Firefox was crashing, because of flashplugin-mozilla, which is available in ports and it's buggy.
Click to expand...

Yes, except that port is not recommended for Flash in the Handbook Browsers chapter, or anywhere else that I'm aware of. What FreeBSD bug caused that port to be installed? What FreeBSD documentation advised installing it, so we can fix it?
 
wblock said:
Yes, except that port is not recommended for Flash in the Handbook Browsers chapter, or anywhere else that I'm aware of. What FreeBSD bug caused that port to be installed? What FreeBSD documentation advised installing it, so we can fix it?
Click to expand...

Are you expecting me to read each time handbook with around 50 pages, before I run following command:
Code: 
> portsearch -n flashplugin | head -n2
Port:	flashplugin-mozilla-0.4.13_5
Path:	/usr/ports/www/flashplugin-mozilla
> sudo portinstall flashplugin-mozilla
Do you do that each time?
This is the solution?

Or the proper permanent solution is to inform the users directly in ports about 5 year old, broken and not supported port which crashing your all browsers. Isn't IGNORE option in Makefile is for that purpose?
http://www.freebsd.org/cgi/query-pr.cgi?pr=152080
 
kenorb said:
Are you expecting me to read each time handbook with around 50 pages, before I run following command:
Code: 
> sudo portinstall flashplugin-mozilla
Do you do that each time?
This is the solution?
Click to expand...

It's not 50 pages. Only 270 words about the Flash plugin, in fact.

A user who wants Flash should not install ports because "flash" is part of their name. They don't need to guess, because the right way is clearly described in the Handbook Browser chapter's section on the Flash plugin.

I do check the Handbook for things that are new to me, yes. Wouldn't reading those 270 words first have saved you a lot of time and trouble? That's why they're there.

Or the proper permanent solution is to inform the users directly in ports about 5 year old, broken and not supported port which crashing your all browsers. Isn't IGNORE option in Makefile is for that purpose?
http://www.freebsd.org/cgi/query-pr.cgi?pr=152080
Click to expand...

If that port is broken, it should be fixed or removed. But that's not a solution to your problem at all, which is that it's simply the wrong port.

The solution is already in the Handbook: the correct procedure is well-documented, tested, and proven. People used to other operating systems may have to adjust their mindset in order to see how effective this is.
 
Status
Not open for further replies.
Back
Top