Open Linux Forums
Like Ubuntu forums, except with beer.
default profile picture


Last seen 3 years ago

A bit hard for me to describe the problem as I don't have a Google account and this is not happening on my old S3.

Is absolutely eating the battery, however, on my wife's phone which is much newer (not sure which it is but I think an S7) phone and she does have a google account.

She is of the opinion that this pain was foisted on her phone by Facebook but looks to me like it was done by our wonderful provider Verison.

Hoping someone here can give me some information on what looks to me to be nothing but malware. Need to do something about this as she really needs her phone to keep track of my Dreaded Mother in Law. Is not helpful when her phone is fully charged in the evening and then goes dead while she is at work the next day without even having to use the phone at all.

I think I have gotten a handle on how to disable the thing from;

But don't want to recommend this to her without some sort of better information on this thing. I have little use for remote control devices personally. I really don't watch TV unless someone else has it running and I am in the room and that is the only remotely controlled thing we own.

Her phone is not used as a remote by the way so it really isn't something she has any interest in either.

I need to get a usb wifi adapter for the County Weed Coordinators office.

The county has had a wired connection system all along but it has fallen into a crack. Seems no one knows anything about it at all. Doesn't fall under the ISP because it is all in the building and, of course, they didn't pay to have them service it. So now they are forced to use wifi only.

This is fine if you want to use Win all the time because all the damned things work with Win. The computer there is a dual boot and this worked fine for a while because the wired connection worked. Doesn't now and will not be fixed so the Linux install has no connection.

Has a Netgear usb adapter that uses a Broadcom chip that is not supported (bc43231 - don't recall what the actually is).

There seem to be plenty of adapters available that support Linux. What I don't know is if they support Linux without installing some crap proprietary driver that will not continue to be maintained. So I thought I would ask for some advice here.

Hopefully someone has more knowledge than I do. Pretty likely because I am still pretty much totally ignorant of wifi usage.

This is a great looking cannon. Fires a 40 pound projectile at 984.25 feet/sec. Probably not good to be anywhere near the interior wall though. Like within 15 feet.

Might be best to have one in every class room to use to get out with. May be slightly costly to repair the building after use though.

I would be a bit concerned if talking to a "defense consultant" that really has no clue as to the physics of projectiles.

You could blow a hole without a lot of structural damage or need more than a 4 foot "safety" zone inside the wall and not have any major rebuilding of the wall after you were finished using the hole.

People on the outside would be pretty safe within a very few feet of the impact though so it would be good for storming a room/building.

I use chroot a lot to do my update/upgrade chores with numerous installs. I like to have the stuff dismounted when done so use umount to do this.

Normal usage by me is

# umount -AR /mnt/some & umount -AR /mnt/thing

using as many &'s as needed. The above is what is in use on this external drive that I am currently using for my main usage.

This works very well most of the time. I had some problems on the internal drives dismounting Mageia 5 but that was fixed by running

# fuser -c /mnt/Mageia5

before using umount.

But I also had some difficulties with pretty standard Debian installs, particularly Stable installs, sometimes. These were generally completely corrected by dismounting more than one install at a time rather than doing theme one at a time. Sometimes only one gets dismounted but just hitting the up arrow and doing the same command again will clear the bugger.

The other day I installed Devuan ascii (RC) and I am experiencing this problem with it. I just can't dismount the bugger at all if I just call for a umount of it by itself but have no problem doing so if umount calls for both installs.

I can even try umount on ascii and have it fail, try the fuser command and then try umount on it again and fail - but then use umount to dismount Xfce (sid based) which is never a problem and then run umount for ascii again and it will dismount with no complaints.

On this drive I am doing this almost always from Debian testing based install 'OB64' which is my default OS in the boot menu. Today I did umount for both

root@openbox:/home/tom# umount -AR /mnt/Xfce & umount -AR /mnt/Devuan

and both dismounted fine. But for the first time there was an added line in the output instead of simply a new # prompt

root@openbox:/home/tom# umount -AR /mnt/Xfce & umount -AR /mnt/Devuan
[1] 20429

WTF is that supposed to mean? Looked in 'man umount' but there are no error codes listed. Looked in 'man mount' where there are error codes listed but none that are applicable to that output. Running the '[1] 20429' through a search engine in a number of different ways got me nothing at all to explain that output. Used, for instance, 'umount', 'debian' and 'debian umount' before the output to see if it turned up something along with some others that I can't remember but got nothing useful at all. This is pretty strange to me because running about any weird output messages turns them up in a search engine.

I did find this which may be useful in the future

If you suspect you have something left running in a chroot, sudo ls -l /proc/*/root | grep chroot will find the culprit (replace "chroot" with the path to the chroot).

but everything was dismounted when the strange output appeared.

Obviously not a real critical problem - just would like to know what that output means.

As I generally reboot into one or both other installs and run on them for a while to make sure everything is running as expected even a total failure to dismount is not an earth shaking problem.

They always are trying to tweak things from release to release. Each release team leader has their own agendas and so do all the release sub team leaders.

But this was interesting to look at today.

Definitely getting into the serious stuff.

The "Freeze" period starts in January. First part of that (Transition) is cut from down time wise in half compared to the few I have been playing with. Last time it did seem to drag on way too long with little actually seeming to happen. There was a big surge of stuff leading up to it as people rammed things in so as to get that crap out of the way.

The final - Full-Freeze - is open ended because it is defined as ending when there are no Release Critical bugs and really is down to the opinion of the release team leader. So probably does point to sometime in June of 19.

And - really planning important stuff ahead -
During the Release Team sprint in Cambridge, it was decided that Debian 12 will be codenamed "bookworm".

Debian 12 should be out sometime in 2023 so it is damned important to get this kind of thing nailed down now.

For those yearning for details of such momentous decisions in the past
Version Code name Release date Toy Story character
1.1 Buzz 1996-06-17 Buzz Lightyear
1.2 Rex 1996-12-12 Rex (the T-Rex)
1.3 Bo 1997-06-05 Bo Peep
2.0 Hamm 1998-07-24 Hamm (the pig)
2.1 Slink 1999-03-09 Slinky Dog
2.2 Potato 2000-08-15 Mr Potato Head
3.0 Woody 2002-07-19 Woody the cowboy
3.1 Sarge 2005-06-06 Sarge from the Bucket O' Soldiers
4.0 Etch 2007-04-08 Etch, the Etch-A-Sketch
5.0 Lenny 2009-02-14 Lenny, the binoculars
6.0 Squeeze 2011-02-06 Squeeze toy aliens
7 Wheezy 2013-05-04 Wheezy the penguin
8 Jessie 2015-04-26 Jessie the cowgirl
9 Stretch 2017-06-17 Rubber octopus from Toy Story 3
10 Buster not yet released Andy's pet dog
11 Bullseye Not yet released Woody's horse
Sid "unstable" The next door neighbour

What a whiny bunch of wimps.

Out and Abouter (of course pronounced Abooter) has it about right

Good news is that Gimp 2.10 which I have been awaiting with bated breath has landed in Sid.

Kind of. Actually the package upgrade should be avoided as Gimp ends up being removed due to the lack, currently, of the appropriate gimp-data package to go with it.

I ran the package upgrade to see what happened. Sid is the secondary OS on this drive so not a big deal with me. I am using testing as the primary OS.

I find it strange that gimp and gimp-data have never shown up in an 'apt-cache policy gimp' (or gimp-data) query output. Gimp-data doesn't now either.

If it were there I would install it over on the Sid install. Would have a while ago actually.

Hopefully this means that the Debian crew thinks it is all good and just need to get their act together and get the .debs done and in the repo.

2.10 is supposed to feature non destructive editing which is really the only real disadvantage to using Gimp. It is not a disadvantage to most users but is pretty important to people that really like to do post processing of digital photos for more than just touching them up, cropping and scaling for screen or internet viewing.

I will post further developments on this in this thread.

This sort of thing is more common in Sid than testing but the only real difference between Sid and testing is the 'rule' that RC bugs in packages should not be released to the testing repos. RC bugs being defined as packages that will prevent the OS from booting to the desktop. But this is not that sort of bug at all. It merely removes Gimp. There is no rule that prevents that sort of thing in either sid or testing.

It does make me look at the list of packages to be removed in both sid and testing pretty closely. Have had 2 x11 upgrades this testing cycle (Debian10) in Sid that definitely would have prevented booting to a desktop. Just removed most, or all of, x11 packages and the stuff like any DE that depends on that stuff.

Learned to watch out for that stuff really closely in Ubuntu-testing. They always blamed it on "upstream" (Debian). I always believed that until I installed Debian testing along with the Ubuntu-testing things. Did that, at first, just to get a heads up on the crap Debian was sending to poor Canonical. Then discovered that there were no such problems with Debian testing in about 85 to 95% of the cases where there was a problem in Ubuntu-testing.

This turns out to be caused by Ubuntu not using Debian testing, or even Sid, packages but just grabbing them from the Debian experimental repo. I Debian the testing dev team actually uses those packages in testing to detect bugs and this is why, if using apt-listbugs, there are bugs filed against package that are new to Sid most times. This makes Sid actually more stable than Ubuntu-testing way too often for comfort.

Also goes a long ways in explaining the number of serious bugs that turn up in about every new release of new "stable" Ubuntu versions. This is particularly true of the "regular" Ubuntu versions which are nominally based on Sid but also the LTS versions nominally based on Debian testing. They pull in a LOT of packages straight from the Debian experimental repo for both.

I expect this to not effect Debian testing but I will be watching any Gimp package upgrades VERY carefully in testing until this switch to Gimp2.10 is complete. I have, as a precaution, put the package Gimp on hold in testing.

# apt-mark hold Gimp

Keep reading about how the Ds are going to swarm into the majority in congress due to people being pissed at Rs.

No one, of course, is pissed at Ds.

Also have been reading some more thoughtful people that think the Ds actually could take over congress but only if you ignore the superior talent of Ds to completely screw things up.

Sounds like a pretty good way to keep people at home and drunk on election day to me.

Would be really great if people in a House district or State could actually have some say in who gets to run to represent them. Pretty silly, radical idea but one that both our wonderful major parties should, maybe, consider.

What I would like to know is what kind of rat is about that size but actually very brown with a fairly bushy haired tail. We got infested by that sort "up on top" at the ranch. Haven't seen them anywhere else so they are not real common. Eat dry cat food very happily.

Was feeding at the other end of the ranch and went into the barn there to check the cat food supply and one of the buggers was eating. Wasn't very nervous about me coming in. Looked more irritated at having dinner interrupted. Didn't run off until I was about 10 feet away.

At first glance I thought it was a squirrel with a really bad case of lice or something due to the condition of the tail. Fairly fluffy furred critter. Fur is about 1/4 to 5/8 inch long with some under fur in the winter.

Had the cat pan (old skillet) up on the deck of the hay swather where you stand to get into the cab. Wasn't an easy place for something that size to get onto except by being pretty good at leaping.

Asked the boss about them and they are apparently the only kind of rat she was familiar with. Told me to use small animal leg traps to catch them. Sounded weird to me but there were some in the shop in pretty bad condition so I cleaned up about 3 of the buggers and got them back into working order.

Took them over to the other place and put one in the bottom of a 5 gallon bucket with a tire rim on top of it. Figured that would keep the cats out of the the trap and secure the trap as the boss claimed they would drag the things off. Those traps are pretty deadly and not all that easy to drag around really. Inside a bucket with a wheel rim should easily hold them was my thinking.

Caught one in that setup. Thing somehow could leap from the bottom of that bucket to the hole in the center of the wheel and actually managed to get out with the trap. Damned tough rats. Changed to wiring the traps to the wheel.

Killed 6 or 8 of them in about 18 months and never saw any again. Would take "cake" (field pea/alfalfa mix pellets for cattle) as bait some managed to get out of the bucket and drag the wheel a little ways (inches).

The ranch cats, particularly over there where no one lived, were kind of tame. Some you could pet even. They didn't eat much cat food in good weather and preferred to go kill something. Would kill things up to jack rabbits which are at least 6 times the size of those rats. Were hell on mice.

Pretty much moved out of the barn until I started setting traps. The were not in there when I saw that first rat. Came in when I was there to eat and apparently stayed somewhere else until those rats were gone.

I think it much be a colony type rat that lives in small (family?) groups and don't breed themselves out of food. Actually kind of a good looking animal. Put me more in mind of a muskrat than anything else.

I am more familiar with black rats which sound more like what that article is talking about than norway rats which are generally not quite that big. But even black rats can be pretty easily controlled with the sort of rat traps you find in hardware stores.

That sort of trap may have been used as food by the ones in the barn. Certainly would not have killed them and probably not even upset them much. Only permanent damage I could see that sort of trap doing would be to damage a tail enough to have some of it die off and leave the rat with a stubbier tail.