You are not logged in.
Hello:
dpkg -S apport/package-hooks
$ dpkg -S apport/package-hooks
lxappearance: /usr/share/apport/package-hooks/source_lxappearance.py
pcmanfm: /usr/share/apport/package-hooks/source_pcmanfm.py
yelp: /usr/share/apport/package-hooks/source_yelp.py
libfm-data: /usr/share/apport/package-hooks/source_libfm.py
openssh-client: /usr/share/apport/package-hooks/openssh-client.py
connman: /usr/share/apport/package-hooks/source_connman.py
lxterminal: /usr/share/apport/package-hooks/source_lxterminal.py
pcmanfm, lxappearance, libfm-data, sudo, synaptic, simple-scan, openssh-client, libmtdev1:amd64, connman, lxterminal, cups-daemon, yelp, grub-common, libmtp-common, conky-all: /usr/share/apport/package-hooks
conky-all: /usr/share/apport/package-hooks/conky.py
grub-common: /usr/share/apport/package-hooks/source_grub2.py
simple-scan: /usr/share/apport/package-hooks/source_simple-scan.py
libmtdev1:amd64: /usr/share/apport/package-hooks/source_mtdev.py
sudo: /usr/share/apport/package-hooks/source_sudo.py
libmtp-common: /usr/share/apport/package-hooks/source_libmtp.py
cups-daemon: /usr/share/apport/package-hooks/source_cups.py
synaptic: /usr/share/apport/package-hooks/source_synaptic.py
$
All python scripts.
Fortunately I managed to weed them all out.
Will do the same on all my Devuan installations.
... classified as a technological remnant from a modular idea ...
... cushioning the end-user with "services" so they could go happy without knowing what they were doing.
And here we are, still with all this absolutely unneeded shit in a Linux system.
No wonder every new release brings about more and more (and more) code.
All dirt swept under the rug, festering.
How much more of that is there to be found?
We all know better than that nowadays, don't we?
Yes, we is right.
Seems the pronoun does not include most (if not all) Debian devs.
Makes me wonder if they are not some sort of sleeper scripts.
As always, thanks for your input.
Best,
A.
Hello:
While looking at the active threads, I came across this post by fsmithred:
To get a list of config files that have been changed from the default:
debsums -ca
I did not know about that package (thanks fsr!) nor did I have it installed.
Once installed, I ran it and got a good deal of data which I have always wondered about as I also keep an installation log of sorts but, never thorough enough.
The data included quite a bit of references* to a package named apport which I recalled having deleted from every instance found.
* most if not all in localhost/usr/share/apport/package-hooks
I purged it after I looked it up and decided it was not something I wanted running in my system.
Apport intercepts Program crashes, collects debugging information about the crash and the operating system environment, and sends it to bug trackers in a standardized form. It also offers the user to report a bug about a package, with again collecting as much information about it as possible.
This was back in 05/2025, so it is still in my timeshift snapshots.
I had intended to ask here but forgot all about it till now.
I had a look today and could not find it in the Devuan repositories.
I did find that it was at one time in the Debian repositories:
https://tracker.debian.org/pkg/apport
Could it be that it is a zombie remnant from the original Devuan (jessie or ascii) installation which I dist-upgraded since then?
$ aptitude why apport
i screen Suggests byobu | screenie | iselect (>= 1.4.0-1)
p byobu Suggests apport
$
$ aptitude why byobu
i screen Suggests byobu | screenie | iselect (>= 1.4.0-1)
$
$ aptitude why screen
i screen Suggests byobu | screenie | iselect (>= 1.4.0-1)
p screenie Depends screen
$
I cannot recall having ever installed screen. 8^°
Moot point, purged it.
Q: Why did I have apport in my system if it was no longer* in the Devuan repositories?
* it was accepted in experimental in 09/2014 but finally removed in 03/2019. ie: over 10 years in experimental, never made it to stable after 05/2014.
Me thinks there should be some sort of mechanism (?) to post a notice about things like this when doing a dist-upgrade.
Thanks in advance.
Best,
A.
Edit:
My Devuan Chimaera VM has this without apport being installed:
$ locate apport
/usr/share/apport
/usr/share/apport/package-hooks
/usr/share/apport/package-hooks/openssh-client.py
/usr/share/apport/package-hooks/openssh-server.py
/usr/share/apport/package-hooks/source_grub2.py
/usr/share/apport/package-hooks/source_sudo.py
$
Same for my (default desktop install) Devuan Daedalus VM:
root@daedalus:~# locate apport
/usr/share/apport
/usr/share/apport/package-hooks
/usr/share/apport/package-hooks/openssh-client.py
/usr/share/apport/package-hooks/openssh-server.py
/usr/share/apport/package-hooks/source_apparmor.py
/usr/share/apport/package-hooks/source_cups.py
/usr/share/apport/package-hooks/source_grub2.py
/usr/share/apport/package-hooks/source_mtdev.py
/usr/share/apport/package-hooks/source_pulseaudio.py
/usr/share/apport/package-hooks/source_sudo.py
/usr/share/apport/package-hooks/source_synaptic.py
root@daedalus:~#
Can anyone explain to me why this is so?
apport is not in the Debian / Devuan repositories.
.
Hello:
git.devuan.org is that website.
Was passing by and tried* it out:
Unable to connect
An error occurred during a connection to git.devuan.org.
The site could be temporarily unavailable or too busy. Try again in a few moments.
If you are unable to load any pages, check your computer’s network connection.
If your computer or network is protected by a firewall or proxy, make sure that Firefox is permitted to access the web.
* 128.3.1esr (64-bit) without Pihole or uBlock enabled.
Best,
A.
Hello:
None of my packages are particularly important ...
I beg to differ.
Every bit of work contributed to Devuan Linux is important.
I have been using your TimeShift for the longest while, if I recall correctly, since ascii.
Best,
A.
Hello:
not every "keyring" is the same type ...
... debian and devuan keyrings ...
... contains the keys to authenticate the packages ...
So I gather.
... gnome keyring ...
... should be the gnome-keyring-daemon ...
I see.
... what it does is store your passwords ...
... dbus interface so that other programs can use ...
... upon login your browser does not ask for your local user password to unlock it's password store and allow you to login onto websites.
But I do not want any of that done.
ie: I log in with a specific password as required when required, I have no interest in that being automated.
... replacing the gnome keyring daemon with keepass ...
... need to install a plugin ...
Then why is it that aptitude prints out this:
$ aptitude why gnome-keyring
i backintime-common Depends python3-keyring
i A python3-keyring Depends python3-secretstorage (>= 3.2)
i A python3-secretstorage Recommends gnome-keyring | libkf5wallet-bin (>= 5.97) | keepassxc <- ###
$
I understand that python3-secretstorage needs either gnome-keyring or keepassxc.
libkf5wallet-bin seems to be a transitional package that can be removed so it does not count, leaving keepassxc as the only other alternative to gnome-keyring.
... invested with either pass or keepassxc ...
... consider replacing functionality ...
... with plugins for either of those.
The keepassxc web page FAQ says that it does not support pugins.
Further on, it also says that it requires network access and that if you do not want that particular feature, you have to compile it yourself.
Much to my chagrin, I think I will have to stay with the gnome-keyring daemon so that BiT will continue to work as it has up to now.
Thank you very much for your reply.
Best,
A.
Hello:
This is (sort of) a continuation of this thread from 09/2022.
My Daedalus installation has these keyrings installed:
$ apt list | grep installed | grep keyring
--- snip ---
debian-archive-keyring/stable,stable,now 2023.3+deb12u2 all [installed]
gnome-keyring/stable,now 42.1-1+b2 amd64 [installed]
python3-keyring/stable,stable,now 23.9.3-2 all [installed,automatic]
python3-keyrings.alt/stable,stable,now 4.2.0-1 all [installed,automatic]
$
I checked with aptitude to see just what wants what:
$ aptitude why debian-archive-keyring
i apt Depends debian-archive-keyring
$
$ aptitude why gnome-keyring
i backintime-common Depends python3-keyring
i A python3-keyring Depends python3-secretstorage (>= 3.2)
i A python3-secretstorage Recommends gnome-keyring | libkf5wallet-bin (>= 5.97) | keepassxc
$
$ aptitude why python3-keyring
i backintime-common Depends python3-keyring
$
$ aptitude why python3-keyrings.alt
i backintime-common Depends python3-keyring
i A python3-keyring Suggests python3-keyrings.alt
$
debian-archive-keyring is for apt -> must keep
gnome-keyring is a recommends from python3-secretstorage -> must keep / could replace with keepassxc, also a recommends (?)
python3-keyring is a recommends from backintime -> must keep
python3-keyrings.alt is a suggests from python3-keyrings.alt -> security issues / not needed*
* see the Debian package description here.
Keyrings in this package may have security risks or other implications. These backends were extracted from the main keyring project to make them available for those who wish to employ them, but are discouraged for general production use. Include this module and use its backends at your own risk.
I have purged python3-keyrings.alt with no apparent ill effects, will stay alert.
I use the gnome-disk-utility and am in the process of checking on the various gnome-whatevers installed in my system to see to what extent they are needed.
The one I am working on now is gnome-keyring which cannot be purged because then BiT does not work.
Makes me wonder why a recommends flag like this one isn't a depends flag.
eg:
$ aptitude why gnome-keyring
i backintime-common Depends python3-keyring
i A python3-keyring Depends python3-secretstorage (>= 3.2)
i A python3-secretstorage Depends gnome-keyring |or| libkf5wallet-bin (>= 5.97) |or| keepassxc
$
That said, if I understood correctly, gnome-keyring can be replaced with keepassxc.
Q:
How can I go about doing that without getting myself a hard to solve problem?
eg: screwing up BiT routines
Thanks in advance.
Best,
A.
Hello:
This any help?
Really could not say.
I have only seen this a couple of times before but (from what I can recall) never while booting*, I would have noticed it.
* Between [0.000000] and the end of the boot sequence. (see the time stamp on the dmesg printout)
And it is not reported by dmesg as a warning/alert/critical/error, so it is probably (?) harmless.
The BIOS (a POS if there ever was one) in my U24 WS does not have an entry for HPET and I certainly would not roll a kernel because of this.
More so if I cannot reproduce it or see any ill effects related to it.
Not to mention that I haven't a clue as to go about doing it. 8^°
My ca. 2007 U24 WS could be having this issue due to a less optimized HPET implementation, so it may be worthwhile attempting the tsc=nowatchdog kernel command line fix and wait to see what effect that has.
Thanks for your input.
Best,
A.
Hello:
... don't like feature creep ...
... think about philosophy of use.
+1
... could use some input ...
I hardly ever use the mixer so I could not say much save for the drop down pre-sets.
That said, I am definitely a client for this UI you have put together.
Looking good.
Thanks for the effort.
Best,
A.
Hello:
While checking my dmesg printout to see if I had properly fixed a damaged Palm data cable, I came across this bit:
--- snip ---
[20430.191148] clocksource: timekeeping watchdog on CPU3: hpet wd-wd read-back delay of 785435ns
[20430.191160] clocksource: wd-tsc-wd read-back delay of 209034ns, clock-skew test skipped!
--- snip ---
The printout does not say it is a warning (or alert/critical/error):
$ sudo dmesg --level=alert,crit,err,warn | grep timekeeping
$
I have also found that I can get the clocksource being used:
$ cat /sys/devices/system/clocksource/clocksource0/current_clocksource
tsc
$
But I have not been able to find out what triggers it, its relevance or how it can be avoided.
It is a very small slice of time (0.001s ?) but there must be a reason for a timekeeping watchdog to let the system know there was a delay.
I'd appreciate input on this.
Best,
A.
Hello:
... need to try again.
Indeed ...
And while at it check the sources.list syntax. 8^°
Done.
My RPi3B+ ascii installation is now fully updated/upgraded.
Thanks for your input.
Best,
A.
Hello:
... postfix mail server ...
... pihole.
... local network uses it for dns.
Thanks.
... not tried either of the installer files you listed ...
... give one of the installer images a try and see what happens ...
That would be great, more than anything to get a user sample number greater than 1.
I have been able to solve the /etc/apt/sources.list problem (wrong syntax) and was able to update/upgrade everything.
Of all the packages to upgrade, 75 were security fixes
I expanded the /ext4 partition from 1.75 to 3.0Gb, installed mc and purged all the vim stuff.
Once I get all the rest done, I will see about upgrading.
Q: does the the FAT16 partition need resizing?
Thanks for your input.
Best,
A.
Hello:
Now you know.
Indeed ...
I submitted a review to Kingston:
I made the mistake of relying on the Kingston brand name (as I have consistently done for the past 25+ years) and purchased three DataTraveler 64Gb Exodia M 3.2 USB drives.
The read / write speeds are short of absurd.
There's no need to explain anything, Kingston engineers know all about it.And now Kingston *also* knows that they have lost a client of 25+ years.
Recommends this product ✘ No
They wrote back and actually thanked me for the feedback.
Then had the gall to reply with this nonsense:
We apologize if you are dissatisfied with your product. The Exodia USB drive's are a basic low cost model with no minimum performance ratings based off the datasheet.
... no minimum performance ratings based off the datasheet?
Datasheet?
What datasheet?
Ahhh ...
They must be referring to the read/write data in the datasheet not included in the package nor transcribed anywhere in the package.
So, according to Kingston it could well be 0.5 Mb/s and it would be also a reasonable write speed for a USB 3.2 USB drive.
Like I said in my OP:
Caveat emptor.
It is an utter piece of crap, you will be wasting your money.
Best,
A.
Hello:
Welcome to Devuan.
Before I forget, have a read here.
... test page ...
... jobs from other applications get sent to the printer ...
... Printer Properties dialog reports ...
... but then the state returns to Idle shortly after, without printing anything.
Yes, seen that, been there and solved it.
The problem is that the CUPS archives have been sequestered by the assholes at Apple Corp. and are no longer accessible.
But I found my old CUPS mailing list posts (thanks to rbit) through the Wayback Machine:
https://lists.cups.org/pipermail/cups/2 … 75402.html
https://lists.cups.org/pipermail/cups/2 … 75403.html
TL;DR:
Yes, a package is probably missing.
Read all the links to get the necessary information.
My printer is one of those USB B&W laser M2020W marketed by Samsung / HP but I am confident the solution is probably the same / similar.
I do not use any HP drivers, just the CUPS supplied stuff from the Devuan repositories.
It may be a good thing to remove anything not downloaded from the Devuan repositories, more so it it did not solve the problem.
Should push come to shove, check the post I linked to at the beginning for a place to ask specific CUPS questions.
Let us know how you fared with this.
Best,
A.
Hello:
... a RPi3b+ running devuan.
Nice to know someone else is doing it.
What use do you give it?
... started with ascii on it, some image obtained from ...
Cannot remember but it is probably the same in my case.
... reason for staying on ascii?
No.
It was the image I had made as a backup and stored away before starting to try to do things with the actual installation.
It still had the PW for root (toor) and no UserID.
As I posted earlier, I downloaded two images but neither of them will boot my RPi. (see my previous two posts)
Can you boot from any one of them?
I'd appreciate it if you could verify that for me when you have a minute to spare.
... upgraded mine, one to chimaera the other to daedalus.
Ahh ...
An upgrade.
Methinks that it is another matter altogether.
ie: uprading from an ascii image you were able to boot from to Chimaera or Daedalus vis-à-vis booting from a fresh Chimaera, Beowulf or Daedalus image.
My money is on the UEFI/EFI shit screwing things up.
My backed up image does not have any of that.
The downloaded images do but you can only see them with gnome-disks, gparted does not show them.
... resize the boot partition ...
Not a problem, mount the MicroSD on any Linux box and go at it with gparted.
... setting it up new ...
... a more current image ...
I think it depends on the use given to the RPi.
ie: this hardware was already old and rather crippled when it was released and unless a newer kernel or specific package versions can really make a difference,
I don't see any advantage.
Linux releases gather more and more bloat with each release and this is just a 1Gb rig with 4xUSB 2.0 ports sharing the bus with the GbE port.
Not precisely cutting edge, lean and mean is of the greatest import.
Same goes for my ca. 2011 Asus 1000HE.
I cannot come up with a justification for moving from Beowulf with a backported kernel to a newer release.
Thanks for your input.
Best,
A.
Hello:
... see if I can find it ...
Found the image, booted in an instant.
# uname -a
Linux devuan 4.16.14-v8+ #1 SMP PREEMPT Tue Jun 5 18:50:10 CEST 2018 aarch64 GNU/Linux
#
This is ascii, archived but not a problem for the time being.
And the image as seen by gnome-disks dos not show any &%$#" UEFI/EFI partition.
Probably the reason why it boots without any problems.
I can SSH as root and user but I need to install a few packages.
The /etc/sources.list from the image I saved is this:
## package repositories
deb http://pkgmaster.devuan.org/merged ascii main contrib non-free
deb http://pkgmaster.devuan.org/merged ascii-updates main contrib non-free
deb http://pkgmaster.devuan.org/merged ascii-security main contrib non-free
#deb http://pkgmaster.devuan.org/merged ascii-backports main contrib non-free
Which would be the new list to use for the archived ascii?
Using http://archive.devuan.org/merged/dists ascii/main gets me a "does not have a Release file" error.
Best,
A.
Hello:
... boot an arm64 installer on your Sun Ultra 24 WS ?
Hmm ...
Yeees?
I downloaded both the netinstall-arm64.iso and the desktop-arm64.iso, wrote them to a 32Gb SD card with the Mintstick software at some time suggested by greenjeans and attempted to boot the RPi3B+ first with the netinstall and later with the desktop *.iso.
When nothing* happened I checked the sha256sum files again but found no discrepancy.
* not even a blink from the activity on-board led or the GbE port.
Then I thought* ...
* not really, please bear with me
"This absolute-waste-of-money™ boots from a MicroSD card.
Could it be the that the *.isos are used to install Devuan arm64 'on' the MicroSD cards?
Lets give it a try"
Granted, a dumb idea when seen in retrospective, not with a glass of scotch by my kb.
But when the installer screen appeared on my monitor it suddenly seemed to make sense.
Till it did not. 8^°
Like I mentioned, the idea is to install a headless Devuan to the RPi3B+ to see what can be done with it, if anything (useful) at all.
I have already been able to install the latest OpenWRT but I would like to install some Devuan version.
RaspberryOS works OOTB, but it is systemd crippled, so ...
That netinstall iso has some isolinux software residue ...
Now I understand what was going on.
An 'unrecognised whatever' would have been nice.
And avoided me some embarrassment.
I recall that I once managed to install a Devuan (Chimaera?) desktop version and kept an image somewhere.
I'll see if I can find it and get rid of the excess baggage.
That said, I don't think I'll get too far with 1Gb RAM and a GbE port on the same bus as the 4xUSB 2.0 ports.
The Ethernet throughput will probably be lower than what I get with the WD-MBL via FTP.
Ideas / suggestions welcome.
As always, thanks for your input.
Best,
A.
Hello:
I will try to make it short.
This is just a heads up for forum members, not a thread to discuss anything.
To wit:
Do not purchase a Kingston Kingston DataTraveler Exodia M USB 3.2.
It is an utter piece of crap and you will be wasting your money.
After my +10 year old and very reliable Data Traveler DTS9 USB 2.0 drive went south, I purchased three of these at ~ US$10 ea.
Did not bother with any research as all Kingston drives I have used in the past gave me no grief and worked prefectly well.
No issues, ever.
They are labelled as USB3.2 but as USB drives are all backwards compatible, I saw no problem.
And besides the on-board USB 2.0, my box also has a good quality USB 3.0 PCIe card.
I did not think to look but after running these tests I noticed that read / write speeds are not stated anywhere in the packaging.
Just says USB 3.2 Gen1, whatever that is these days.
So the next time I need to purchase a USB drive, I will check on-line first.
The Kingston brand name is no longer reliable for me.
This is how it is detected by Devuan Daedalus:
$ sudo dmesg
--- snip ---
[ ]usb 3-1.1: new SuperSpeed USB device number 3 using xhci_hcd
[ ] usb 3-1.1: New USB device found, idVendor=0951, idProduct=1666, bcdDevice= 0.01
[ ] usb 3-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ ] usb 3-1.1: Product: DataTraveler 3.0
[ ] usb 3-1.1: Manufacturer: Kingston
[ ] usb 3-1.1: SerialNumber: E0D55EA57403F76139331987
--- snip ---
$
I ran these tests.
Other tests were consistent with these results
# dd if=/dev/random of=/media/groucho/EXODIA64/tmp123 bs=1048576 count=3072
3072+0 records in
3072+0 records out
3221225472 bytes (3.2 GB, 3.0 GiB) copied, 406.307 s, 7.9 MB/s
#
# dd if=/dev/random of=/media/groucho/EXODIA64/tmp123 bs=1048576 count=3072
3072+0 records in
3072+0 records out
3221225472 bytes (3.2 GB, 3.0 GiB) copied, 399.216 s, 8.1 MB/s
#
The first run is on a USB 3.0 socket on a hub at the front of the box and the second from one at the USB 3.0 PCIe card at the back of the box, there is no big difference.
I got a ~+25% write speed increase with a stream of zeroes.
$ cat /dev/zero | pv > /media/groucho/usb1/tmp123
3.00GiB 0:04:36 [10.8MiB/s] [ <=> ]
$
Thinking I had been duped and had fallen for fake Kingston hardware, I searched and found a great many posts with complaints about Kingston, their new marketing practises and these USB drives which seem to be QLC type which would (?) explain the absurd write speed performance.
But it gets worse: not only the complaints line up with what I have experienced with the ones I purchased, I have also read a post that complains about data rot after only two months.
Now you know.
As always, YMMV.
Best,
A.
Hello:
Wanted to try Devuan in the RPi3B+ I have gathering dust in a drawer.
As I am planning to use it as a headless device, I downloaded the netinstall-arm64.iso available here.
Checked the sha256sum, burned it to a new 64Gb USB stick proceeded to boot it from my BIOS only Sun Ultra 24 WS.
TL;RD
It boots, gets to the screen to select the type of installation and that is it.
Any selection made freezes the screen for maybe 5' and then unfreezes but nothing else.
The only selection that goes an additional step is Expert Install but then freezes and like the other options, after ~ 5', unfreezes.
I will try and see what happens with the desktop image and report back, maybe tomorrow.
Any one else has this problem?
Best,
A.
Hello:
This will make it harder to run GNOME on operating systems without systemd.
Hmm ...
A huge loss ...
A truly huge loss indeed. :^(
A.
Hello:
... will all do what was asked in the OP ...
The OP asked about much more than that.
Running in an emulator is only a necessary part of what OP ultimately wanted to do.
... there are certain things my bank will not let you do on their website but only with their app.
The app the OP refers to is the bank's custom application running on a smartphone in the way I previously described.
So the answer to the question/s I posed in my previous post would seem to be a hard no.
None of them will register a real IMEI ...
Exactly.
... depends how your authenticator works.
... sign in to google from the virtual device with a real account.
As far as I can tell, Google et al have absolutely no involvement (at least for the time being) in the client <-> bank transaction through their authenticating servers, none whatsoever.
Banks are run by experienced white collar crooks, not idiots.
Many years ago, I tried to log into one of my bank's websites using the Tor browser, thinking it would be better and safer.
It took a few seconds to get kicked out of the session and instantly get an email summoning me to the head branch to speak with an accounts officer who, sternly produced a disclaimer for me to sign because "third party malware had been detected during my last log in" and assume full responsibility for whatever could happen, lest they terminate my account on the spot if I did not sign it.
Needless to say, he did not take lightly my asking if he was referring to the MS operating system (Win98SE) running on the boxes I used at the office and at home.
So no, for all the reasons I explained in my lengthy post, I do not think it is possible to avoid using a smartphone to do any banking unless the bank allows the use of an 'on-device' authenticator running on your smartphone, something that will never happen.
Basically because, among other things, it is an integral part of the the meta-data farming system that has been put in place in the past 5/10 years.
With no government oversight whatsoever.
Soon enough, you will not even be able to order a pizza at a resturant without a smartphone.
The absence of a printed menu has recently started to become a widespread trend.
ie: sitting at a table in the joint, you actually have to use a smartphone to see the menu on the restautant's web site.
And it is going to get worse. 8^|
Best,
A.
Hello:
Genymotion ...
Android studio ...
Waydroid via Weston ...
Interesting.
Let me see if I understood this correctly:
Using one or any of the applications suggested above, I can log into my bank or whatever secure website requiring a website supplied token* and carry out my business without actually using a smartphone?
* the token sent by the secure server to a smartphone registered under my name with that same server but without using the smartphone in any way.
Yes?
That said, I do obtain secure access to a couple of secure websites using my browser.
But the token is generated by the smartphone itself (ie: me) via an app such as Aegis Authenticator.
All I had to do is copy a QR code generated by the owner of the website and apply it to the authenticator.
Any time I need to access that secure server, I first login to the website (with UserID+PW) and then use the authenticator to generate a six digit number (on demand) in order to complete my access.
No further process is carried out on or by the secure server.
Best,
A.
Hello:
... becoming increasingly difficult to avoid using a smartphone ...
Indeed ...
The final objective is that everyone uses a smartphone for everything.
... have one but hate it.
Same here.
And the local telcos do not offer any dumbphone options.
... doctors' practice ...
... certain things my bank will not let you do on their website ...
... using a PC must be a bit shady ...
A local doctor's association (or whatever it is) has intere$ted / offered their associated physicians access to a dedicated website where, instead of handing you the usual hand written prescription while you are in front to them, they will send it to you via email.
To that effect, all your data and prescription history is stored (safely, never shared or sold mind you) in the association's server.
Not only that, it seems that the chaps actually get some cash for every patient that gets uploaded to the data base.
Like my proctologist's secretary ignorantly explained: "the Dr. saves time when not having to write the prescription". 8^D !!!
The bank where I get my pension deposit and have been a client for more than 25 years one day decided that I would no longer be able to transfer money between my account and any other account (mine or not) if I did not have a token which was (to them) the only possible way to ID myself before the bank's infrastructure if I was using their website.
Gone was the 2FA Auth I had been using and as you would expect, said token could only be generated by an app running in a smartphone I did not have (used a Blackberry at the time).
Needless to say that the process of installing the app involved (you guessed it) uploading photos of your mug like if you were being processed for murder. ie: front / right / left / smiling / not smiling and so on. It's a wonder they did not also want a photo of my tonsils.
I could go on as examples of this bulshit abound so I will stop now and explain why all this is happening worldwide:
It is all about control.
A smartphone is basically a tracking device and all these app shennanigans are meta-data harvesting procedures.
The moment you get your mug shot on-line is the moment it is shared worldwide, istantly associated to all the information you shed permanently with absolutely everything you do with a smartphone. eg: banking, digital wallet payments, etc.
The added bonus for banking institutions is that, sooner than later, any and all client banking activity will have to be done via a smartphone.
Forget your secure Linux box behind a router / firewall at home and, to their shareholder's delight as all their clients will then work for them, welcome to the world of banks without branches, ATMs, tellers, employees, etc.
Like stores of all sorts that, as time goes by, have more self-service checkout tills and less cashiers or humans: you are both the employee (weighing/sorting/checking out the goods) and the client (paying for it all).
I flatly refuse to use them and point out to the employee at the till that if I do, eventually they will be out of a job, a job which they are good at.
Their reply? "I find it very helpful, especially when there are many clients in the store"
Unbelievable.
... just want one to use as a smartphone, and I want it to run in a VM ...
I do not think there is one and given how the system works, I there will not ever be one.
This because the key to all this is that the app runs on the smartphone, ie: the portable data harvesting device registered (via an IMEI <-> your ID pair) to you and working with / through the telco's infrastructure which is (obviously) linked to the rest of the world-wide telco infrastructure and whatever other infrastructure feeds from it.
As far as I know, it is impossible to access that infrastructure directly with a computer / emulator but you can do it if your computer accesses it via your smartphone, I believe there is such a thing for whatsup. You would need to fake quite a few things, the main one being a valid IMEI / your ID pair.
Soon there will be no way of using any telco infrastructure without a registered smartphone.
No dumphones or burner phones will be allowed and all communication devices will have to be linked to a valid ID, meta-data* included, of course.
* full name, address, full facial recognition data, some ID number (passport, etc.) and who knows what else.
Best,
A.
Hello:
One big question ...
I can feel your pain from way down here. 8^°
Food for thought:
From your OP I gather that $$$ is a limitation and a very understandable one.
As you know, I run my Devuan system on a ca. 2007 Sun Microsystems Ultra 24 WS.
Doesn't ever skip a beat and it is the best IT purchase I ever made.
The box is built like a tank, way ahead of its time when it came out and still was 10 years later.
You don't get hardware like this anymore.
Why not consider an older, high quality box to populate with enough RAM, SAS controller / drives and a pair of 4port Gigabit cards?
I think that is where you will get the best bang for your town's money.
And no EFI ...
eg: a Sun Microsystems Ultra 40 M2.
2x AMD 3.0 GHz Opteron dual-core processors + 32 GB of DDR2-667 ECC
2x 10/100/1000BASE-T Gigabit Ethernet ports
8x SATA / SAS HDD slots
2x PCIe x16 graphics slots
2x PCIe x8 expansion slots
1x PCI 33MHz, 32-bit slot
It probably has (like my U24) pins for a RS-232 port, which has to be enabled in BIOS.
Could be quite useful.
You can probably get a basic one for a good price and populate it according to your needs.
eg: run it with no monitor, use 1x PCIe x16 slot for a four port GbE card, 1x PCIe x16 slot an 8 port SAS controller and boot from a SSD drive on an adapter in one of the expansion slots and you will still have 1x PCIe x8 and 1x PCI 33MHz 32-bit slots for whatever else you want to stuff in there.
Just my 0.02 ...
Best,
A.
Hello:
... printer used to work, but has recently refused to print.
For lack of a better reply, I'd say that what you have is a very specific CUPS issue.
... suggestions to track down and fix this?
Unfortunately, Apple Corp. has blocked all acess to the huge source of data/information that were the CUPS archives.
That said, there is are new lists set up by the chap who wrote CUPS:
See here for general instructions:
https://subspace.kernel.org/subscribing.html
See here for specific CUPS lists instructions:
https://subspace.kernel.org/lists.linux.dev.html
For printing-architecture
subscribe printing-architecture+subscribe@lists.linux.dev
unsubscribe printing-architecture+unsubscribe@lists.linux.dev
posting printing-architecture@lists.linux.dev
archive https://lore.kernel.org/printing-architecture/
For printing-users
subscribe printing-users+subscribe@lists.linux.dev
unsubscribe printing-users+unsubscribe@lists.linux.dev
posting printing-users@lists.linux.dev
archive https://lore.kernel.org/printing-users/
The background to all this hassle, more specifically, the archives at https://lists.cups.org/pipermail/cups/:
Up to (at least) May last year, the archive was accessible to anyone, suscribed or not.
Those suscribed to the list could post to all list members by sending mail to cups@cups.org
Just like most standard issue mailing lists ...
Some time ago I needed to look up something and found that attempting to access the archives
returned a *403 Forbidden* page.
A mail to cups-owner@cups org got me this reply:
---
More recent cups related stuff can be found at openprinting.org.
When apple bought cups, those lists went to their servers.
Mike quietly left apple years ago, and it appears that apple has removed the lists.
They own "cups". So Mike had to make a new name.
---
'Mike' obviously refers to Michael Sweet who left Apple in December 2019.
Unfortunately, a further email asking for more information went unanswered.
Bad vibes ...
It seems that I can still post to the list (ie: email does not bounce) and I receive other people's
posts containing replies so the list works, but the thread is not accessible.
I then posted to the OpenPrinting GitHub page asking about this and right away received a
reply from M.R. Sweet himself:
https://github.com/OpenPrinting/cups/discussions/1237
---
Unfortunately, lists.cups.org is an Apple-managed site and we have no control over its
contents or configuration...
The printing-users and printing-architecture lists on kernel.org are the current place for
discussing printing-related issues.
---
The thing is that all this went down without *any* notice sent to the list and the wealth of information that made up the archives are, thanks to the assholes at Apple Corp., lost to any and everyone who ever posted anything there.
The first example of such shitty behaviour came from yet another well known corporation (Oracle): after taking over Sun Microsystems, they blocked all access (mailing lists and downlaods) to anyone without a $ervice contract.
Best,
A.
Hello:
RE: "Devuanite experience"
Please excuse my OT but as you have mentioned it:
... one may still need to have a long list of pinned packages.
My Daedalus box has these:
$ apt-cache policy
--- snip ---
Pinned packages:
pulseaudio -> 16.1+dfsg1-2+b1 with priority -1
pulseaudio:i386 -> 16.1+dfsg1-2+b1 with priority -1
apparmor -> 3.0.8-3 with priority -1
apparmor:i386 -> 3.0.8-3 with priority -1
zeitgeist-datahub -> 1.0.4-5 with priority -1
zeitgeist -> 1.0.4-5 with priority -1
zeitgeist-core -> 1.0.4-5 with priority -1
$
Made me wonder if it was long enough.
Best,
A.