You are not logged in.
Hello:
Welcome to Devuan.
... should these files even exist on a supposedly systemd free fork of debian?
I run Devuan Daedalus on my box:
$ uname -a
Linux devuan 6.1.0-37-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.140-1 (2025-05-22) x86_64 GNU/Linux
$ My system does not have systemctl installed.
No dependency requires it, but it is present in the repository and as such, it can be installed:
$ apt list | grep systemctl
--- snip ---
systemctl-service-shim/stable,stable 0.0.5-1 all
systemctl/stable,stable 1.4.4181-1.1 all
$# apt install systemctl
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Suggested packages:
tini | dumb-init
The following NEW packages will be installed:
systemctl
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 79.8 kB of archives.
After this operation, 279 kB of additional disk space will be used.
Get:1 http://deb.devuan.org/merged daedalus/main amd64 systemctl all 1.4.4181-1.1 [79.8 kB]
Fetched 79.8 kB in 4s (18.3 kB/s)
Selecting previously unselected package systemctl.
(Reading database ... 165616 files and directories currently installed.)
Preparing to unpack .../systemctl_1.4.4181-1.1_all.deb ...
Unpacking systemctl (1.4.4181-1.1) ...
Setting up systemctl (1.4.4181-1.1) ...
Processing triggers for man-db (2.11.2-2) ...
# That said, I don't have much of an idea what it is used for in a systemd-less installation, but I suspect (wild guess) that it is/may be related to all the dummy/shim files Devuan uses to be able to run Debian packages which want to see indications of the presence of systemd to work properly.
ie: a non-dependent dependency, if you will.
If you install it and run it as root from a terminal, you will get a printout with the list of dummy / shim files installed in your system with their status, some with a description of what they are used for.
eg:
# systemctl
.depend.boot.service loaded inactive dead
.depend.start.service loaded inactive dead
.depend.stop.service loaded inactive dead
README.service loaded inactive dead
acpid.path loaded inactive dead ACPI Events Check
acpid.service loaded inactive dead ACPI event daemon
acpid.socket loaded inactive dead ACPID Listen Socket
--- snip ---
connman-wait-online.service loaded inactive dead Wait for network to be configured by ConnMan
connman.service loaded inactive dead Connection service
--- snip ---
zramswap.service loaded inactive dead Linux zramswap setup
150 loaded units listed.
To show all installed unit files use 'systemctl list-unit-files'.
# Cannot say much more than that.
Best,
A.
Hello:
... two hidden dirs, named /.config and /.cache
See this thread: https://dev1galaxy.org/viewtopic.php?id=5596
There is a lot of information about /.config and /.cache there.
In my case, I solved it with this ...
# apt purge pulseaudio && apt autoclean && apt autoremove... and then this: https://dev1galaxy.org/viewtopic.php?id=3904
The end result being this:
$ cat /etc/apt/preferences.d/avoid_pulseaudio
Package: pulseaudio:*
Pin: version *
Pin-Priority: -1
$ In your case, a bit more digging may be necessary.
Or not.
Please let us know how you fared.
Best,
A.
Hello:
From today's edition of The Register:
----------------------------------------------------------------------------------------------------------------------------------------------------------------------
Microsoft admits it 'cannot guarantee' data sovereignty
Under oath in French Senate, exec says it would be compelled – however unlikely – to pass local customer info to US admin.
by Paul Kunert @The Register
----------------------------------------------------------------------------------------------------------------------------------------------------------------------
https://www.theregister.com/2025/07/25/ … guarantee/
As proceedings continued, Carniaux was asked if in the event of an injunction that was legally justified, could he, as Microsoft director of public and legal affairs, "guarantee our committee, under oath" that data on French citizens could not be transmitted to the American government without the explicit agreement of the French government.
"No," said Carniaux, "I cannot guarantee that, but, again, it has never happened before."
The Register asked Microsoft to comment on this but it declined to do so.
So ...
What else is new?
Best,
A.
Hello:
I found some more info on this apport application:
https://nvd.nist.gov/vuln/detail/CVE-2016-9950
https://app.opencve.io/cve/?vendor=apport_project
https://security-tracker.debian.org/tra … -2019-7306
You will notice that Debian refers to all this as a non-issue because apport is not present.
Coming from the creators of systemd, I'll take it with a few grains of salt, low sodium variety.
Paraphrasing the Bard (of Avon, seems there are others):
An apport by any other name would still cause damage
So ...
Just to be on the safe side of whatever may be in there, Devuan users may want to consider purging everything in /usr/share/apport/*
But that's just me and my $0.02.
Best,
A.
Hello:
... but selectively omitted from installation by a simple option in the package preinst script.
Yes, of course*.
*Good luck with that ... 8^°
Thanks for your input.
Best,
A.
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-freeWhich 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.