On Sunday, April 10, 2011 09:57:12 PM Duncan did opine:
> gene heskett posted on Sun, 10 Apr 2011 10:03:32 -0400 as excerpted:
> > On Sunday, April 10, 2011 08:45:58 AM Duncan did opine:
> >> gene heskett posted on Sun, 10 Apr 2011 01:56:17 -0400 as excerpted:
> >>
> >> If you're seeing actual code in that file (plasma-desktop-appletsrc),
> >> you're either looking at the wrong one, or it's /seriously/
> >> corrupted!
> >
> > No, what I saw was the [] sections, multiplied several to the line in
> > some cases, with name=whatever's following.
> >
> > See my plasma-desktop-appletsrc at:
> > <http://gene.homelinux.net:85/gene/stuff4george/plasma-desktop-applets
> > rc> as it exists this morning. And I had to restart httpd just now,
> > no idea what killed it. You can back out to just the 'gene' and see
> > what keeps me out of the bars _most_ of the time. ;-) I need to redo
> > the front page pix though, I was in the process of doing something
> > about my weight, about 200 lbs there in 2004, from a high of about
> > 215 10 years ago to 165 now. The beard is a little shorter now as
> > the weather is warming, and the hair is shoulder length today. And a
> > few more dings on my face from the dermatologists scalpel. I should
> > wear more sunscreen, but I have enough allergies as it is. Mrs #3,
> > 21 years and counting. A Good girl. The pix are generally dual
> > linked by jigl.pl, so if you click on a thumb, you get a slide, click
> > on the slide and get the camera output.
>
> Just FWIW, backing out to just http://gene.homelinux.net:85 yields a
> simple "server alive" message.
Thats expected, you need the 'gene' too.
> I don't run my own server and don't
> claim to have the skills to do so (tho I could certainly learn them),
> so take this with that caveat, but I've /read/ that crackers see such
> generic homepages as an indication that the server may not be well
> configured, properly updated, etc -- IOW, an invitation to probe and
> potentially exploit any weakness found.
>
> So I'd recommend pointing that at something, perhaps your /gene page,
> whatever. Unless you intentionally do that as a honeypot or something.
>
> Meanwhile, you do have it on a non-standard port, 85, making it a bit
> more obscure. That's good, but as I'm sure you know, it won't keep the
> port- scanners from finding it.
The non-std port deadends at DD-WRT, the port 85 is required because most
ISP's, and shentel is no exception, block incoming port 80 in order to
force the customer to use their web server so they can load it with
advertising. 85 is not assigned in the services file, so I used it. Have
been for several years.
> Unless you have it behind an IP-filtering firewall and just let my IP
> in, of course, as I believe you could have gotten it from the headers
> of my post.
I wasn't overly concerned, DD-WRT does a rather admirable job of ignoring
the black hats>
> Meanwhile, I guess you're shorter than I am. I'm about 295 or so
> (285-305), holding after dropping from 325 or so, peak, but don't
> believe I appear /that/ much heavier, so gotta be taller. The
> challenges of being a geek and spending all that time in front of the
> computer instead of at the gym/pool/field/whatever...
Exactly.
> Of course as you implied earlier with the diabetes mention, there are
> health implications... When I go above 300, I hardly need to look at
> the scale to know as I feel it. I've started biking again, and changed
> my diet some, thus stabilizing just below 300, but I don't believe in
> yoyo dieting, so while reversing the previous trend of gaining 5-10
> pounds a year to losing that would be nice, currently, stabilizing at a
> bit under 300 is reasonable.
The enforced lack of starches the sugar says I can't eat are part of my
weight loss. Unforch, I've been a carnivore all my life, and the meats are
suger-free, so I take a few vitamins to make up for the breads and spuds
that are off-limits. The anti-glucose medication, metformin hydrochloride,
has a side effect of sucking the B vitamins & calcium out, so you have to
put them back strong enough to stop the leg cramps.
> > I might have a question about what I can start in one of these []
> > sections.
> > I have several background, non gfx apps that I have to start by hand
> > after a reboot because putting them in rc.local is too early. X (kde)
> > seriously needs its own version of rc.local that is user specific.
> > Maybe it does, but I haven't found it. My own version of ~/gene/etc
> > if you will. One in particular needs to be run as soon as kmail has
> > done its initial check-mail scan and is settling down to rebuilding
> > the indices.
>
> This particular file (plasma-desktop-applets) is only config info for
> plasma-desktop. It describes containers (activities, panels) and
> plasmoids, the applets that run in them. These aren't apps on their own
> and run in plasma context, so you can't and wouldn't want to run just
> any app from here.
>
> kde /does/ have a facility such as you describe, however.
>
> Graphically, it is managed from kcontrol (the kde3 name, I refuse to
> call it the way too generic and not descriptive systemsettings that
> kde4 uses, as in general at least as shipped by kde, it's not in
> general global systemsettings at all, but rather, user-specific kde
> settings, thus the kde3 term precisely applies, the generic kde4 term
> most definitely does *NOT* apply, and like that guy in "The Emperor's
> New Clothes", I'm not going to be forced into pretending it does!),
> system administration (umm...! tho a few of these actually /are/ or can
> be system level, date and time, for instance), startup and shutdown
> (NOT system level, user level), autostart.
>
> What that does is place either *.desktop files (if using add program) or
> symlinks (for scripts) into appropriate startup (or shutdown) dirs.
>
I don't think I've seen that.
> The *.desktop files mechanism is apparently freedesktop.org cooperative
> standard compliant, and should launch the apps the *.desktop files point
> to for any compliant window-manager/desktop-environment (not just kde).
> The directory used for *.desktop files is accordingly determined by the
> freedesktop.org standards, and is $XDG_CONFIG_HOME/autostart/ . Like
> the $KDEHOME var discussed earlier, $XDG_CONFIG_HOME denotes the
> variable that will determine location if found in kde's environment
> when it starts. The default location if unset is ~/.config , so the
> default location for these *.desktop files is ~/.config/autostart/ .
> Of course, since this is an X related mechanism, the only option for
> *.desktop files is startup.
>
> Presumably you could manage the *.desktop startup directory manually by
> adding/removing desktop files to/from it as appropriate, tho I've not
> tried it.
>
> The scripts mechanism is kde specific. For startup, the location used
> is configured in kcontrol, common appearance and behavior, account
> details, paths. I don't actually remember for sure the default as mine
> has been customized for so long, but IIRC it was $KDEHOME/Autostart or
> some such.
>
> By default (checkbox in the graphical script-add mechanism), kde creates
> symlinks to the script files as added, instead of copying the scripts
> themselves. Presumably you can manage the location manually by adding
> the scripts or symlinks yourself.
>
> If you add a script in the GUI, it defaults to startup when added.
> However, once added, the run-on column in the kcontrol applet becomes a
> drop-down box, and it's possible to select two other options as well,
> shutdown, or pre-kde-startup.
That isn't where these need to be, they should start a few seconds after
kmail has been started.
> While kde allows you to add arbitrarily named startup scripts, if you
> attempt to switch the dropdown to shutdown or pre-kde-startup, it'll
> protest that only *.sh extension files can be used. Never-the-less, it
> moves the symlink to the associated dir, even without the .sh extension.
> Whether it actually runs it in that case, I don't know.
>
> Unlike the location of the dir for kde startup scripts, I don't see a
> GUI setting for the shutdown and pre-kde-start dirs. However, they
> appear to be $KDEHOME/shutdown (for shutdown, of course) and
> $KDEHOME/env (for pre- kde-start). The previously discussed $KDEHOME
> explanation of course applies-- it'll be ~/.kde4 by default. After
> discovery of the GUI method for managing the shutdown dir, I actually
> did create a script and manually symlink it into that dir, for an
> earlier kde4 version, and it worked, tho I don't need it any longer.
> So I know manual management of the shutdown dir works as I used it.
> (FWIW, the script I had killed the akonadi mysql backend which would
> otherwise continue running under my desktop username, even after all
> login and X sessions for it were gone. I no longer need the script as
> the sqlite backend matured and I use it now. sqlite is more
> appropriate for the akonadi usage than a full-fledged mysql session,
> anyway, IMO, tho it wasn't thread-safe when kde4/akonadi was originally
> released thus the mysql default until the sqlite solution matured.)
> Presumably the pre-kde-start/env dir works similarly.
>
> A couple notes:
>
> 1) The scripts do I believe have to have execute permissions set or they
> won't run.
>
> 2) I don't know for sure as I've never had occasion to try it, but I
> expect that if you put a script in the pre-kde-start/env dir and it
> starts anything you want kept running, you may have to background it
> and probably disown it as well, using standard shell ops, to keep it
> from holding up kde start until it's finished running or from dying
> with the script. This, because as the name of the dir suggests, it's
> designed for setting up the environment and other such things, so kde
> itself likely won't run until the scripts located in the env dir
> terminate.
>
> > And I just had to kill yet another copy of knotify4, hung at 95% of a
> > core,
> > bouncing from core to core. When I went to bed it was about 20 down
> > in an htop display, using no cpu. And it has now been restarted, by
> > kdeinit I assume, running normally again.
>
> Sounds like you may need to setup a babysitter script, to watch for
> knotify4 runtime abuse and kill it when necessary.
>
> Or simply (well, perhaps not-so-simply, but anyway...) find whatever
> notification is bad and fix it. Presumably the problem is being
> triggered when a notification tries to play a corrupt soundfile or some
> such. Find said soundfile and fix it, or said notification and either
> disable it or point it at a different soundfile, and the problem will
> likely go away. Notification config is in kcontrol as well.
Humm. I have a filter that sends any 5* files to then trash dir, and it
plays the waw waw failure message when it does, but not always all of it.
I can stop that easily.
Thanks Duncan.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
<http://tinyurl.com/ddg5bz>
<http://www.cantrip.org/gatto.html>
"Stupidity, like virtue, is its own reward"
-- William E. Davidsen
___________________________________________________
This message is from the kde mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.
