Hello:

Indeed ...
The final objective is that everyone uses a smartphone for everything.

Same here.
And the local telcos do not offer any dumbphone options.

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.

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:

For lack of a better reply, I'd say that what you have is a very specific CUPS issue.

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:

@SlySven
I'm afraid you have misquoted me.
The quote belongs to the OP, kapqa.

I would never* spell systemd like that.  8^D !!!

* lest I summon an instant rebuke from our (long time) absentee member, HoaS.

Best,

A.

Hello:

I'm sure you will concur with me in that few and minor are basically relative concepts.

That said, consider having a read at the post I linked to earlier in this thread.
Having done so, reflect upon what place few and minor could possibly have in what transpired.

For a long time now, the established idea has been that any current Linux *.iso (in this case Devuan/Debian) properly dd'd to a USB stick would be able to boot from any machine, provided hardware compatiblity was complied with.

I'd say it is one of those essential parts of the jazz that Linux is all about.
eg: like TCP/IP

With the advent of this UEFI shitload and without having been said otherwise, it stands to reason the idea referenced above still stands.
If that is not what is happening, something is definitely wrong.

And having to apply any modifications, however few and minor, is neither convenient nor acceptable.
The implications of it being considered as such are huge and of significant and extensive reach.

I think my opinion reflects that of a great many Linux users.
As always, YMMV.

Thanks for your input.

A.

Hello:

Right, those are the ones I'veen looking at.

Yes. I was planning on doing that in my present 1000HE setup.

Re: enabling UEFI

So the function to enable UEFI in the *.iso, be it installer or live, is in some part of the respective *.sdk?

If so, maybe the installer could have an option to turn it on/off, depending on the default setting.

As always, thanks for your input.

Best,

A.

Hello:

Yes but not if you are booting a box with no UEFI.
eg: Asus 1000HE
You can just delete the UEFI partition with disks albeit not with gparted which does not see it.

My guess is that because of how the installer works now, any *.iso made for a post Chimaera/Bullseye kernel will produce a UEFI partition, independently of the kernel present in the installation.

This complicates everything.
eg: try to install Daedalus or any post Chimaera/Bullseye release on a USB drive.

All this UEFI, secureboot, apparmor, SELinux et al crap being imposed manu militari by the WinTel consortium will not end well for us. 

Best,

A.

Hello:

No problem.

No, did not touch it.
Just copied the script, labelled and made executable.

Apparently ...

But I think I found a use case where the script does not work.
ie: in UEFI boxes.

As you may recall, I used a Chimaera i386 *.iso.file from the Devuan repository.
devuan_chimaera_4.0.3_i386_desktop-live.iso

This *.iso file did not generate a #$%& UEFI partition when I wrote it to the SD Card.
ie: as expected, gparted reported a single *.iso file while disks reported an *.iso file and the remaining unformatted/empty space.

Then I tried a Bookworm based #!++ i386 *.iso file to see how it would work. -> cbpp-12.0-i386-20230611.iso
Find it here you may want to try it out and see what happens.

TL;DR
Using the #!++ *.iso, Mintstick generates a first partition with an *.iso image, a second UEFI partiton and the remaining empty space.
As a result, the script will delete the partition containing the UEFI shit.

I expect that the same thing will happen with any modern *.iso file beyond Chimaera or equivalent.

In this last test, it deleted the partition with the UEFI shit, left the unformatted empty space untouched and threw the same error we both experienced.
You may want to consider the script looking only for empty and unformatted space.

It's fine with me, all my hardware is non-UEFI (BIOS boot) so I just created a a FAT32 DATA partition by hand.
But how about the cases you will be working on?

That said, the error does not seem to be reproducible.
And since both of us have seen it ie: different hardware, a pause may be effectively needed somewhere in the script.

Best,

A.

Hello:

I've given that some thought.
The weakest link here is the Class 2 2.0Gb SD Card + SD Card reader.
disks clocks it at an average read rate of 10.5MB/s, average write speed is probably slower.
By comparison, the SAS drive from which the *.iso file was read is clocked at an average read rate of 105.2 MB/s.
ie: 10X higher using the same size (10MB) sample.

No need.
Patch the script, test it and let me know the additions.
ie: line number and syntax so I can just add them verbatim to the original.

Best,

A.

Edit:
Posts crossed while I was making espresso.
I'll run the tests and post as soon as I get it done, later tonight or early tomorrow.

.

Hello:

Glad I could be of help.

Box is a ca. 2009 Sun Microsystems Ultra 24 WS with an Intel Q9550 / 8Gb RAM - Linux 6.1.0-37-amd64 x86_64
Swap file in RAM.

$ sudo swapon -s
Filename				Type		Size		Used		Priority
/dev/sdb3                               partition	2749436		0		-2
/dev/zram0                              partition	6291452		0		100
$ 

The memory is a standard Sandisk SD (Class 2) 2.0Gb  Card on a generic USB 2.0 SD /MicroSD Card reader plugged into a USB 3.0 slot.

The difference in read/access speeds between a Class 2 SD card, USB 2.0 reader in a USB 3.0 slot and a swapfile in RAM may (?) account for whatever happens timing wise. I'd say that, in this specific case, you don't need fast.
ie: accurate and reliable would be the thing to aim for.

Best,

A.

Hello:

Indeed it was.  8^°
ie: pebkac

Fixed that.

$ cat /etc/default/su
# restore the old 'su' behaviour
# no 'su-' | just use 'su' as before
# see https://files.devuan.org/devuan_beowulf/Release_notes.txt
# ALWAYS_SET_PATH yes
$

Now, with su and sudo:

[root@devuan isos]# sudo ./fatstick.sh
/dev/sdg: 5 bytes were erased at offset 0x00008001 (iso9660): 43 44 30 30 31
Checking that no-one is using this disk right now ... OK

Disk /dev/sdg: 1.89 GiB, 2032664576 bytes, 3970048 sectors
Disk model: Storage Device  
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x23927a24

Old situation:

Device     Boot Start     End Sectors  Size Id Type
/dev/sdg1  *       64 2333951 2333888  1.1G 17 Hidden HPFS/NTFS

/dev/sdg2: Created a new partition 2 of type 'W95 FAT32 (LBA)' and of size 798.9 MiB.
Partition #2 contains a vfat signature.
/dev/sdg3: Done.

New situation:
Disklabel type: dos
Disk identifier: 0x23927a24

Device     Boot   Start     End Sectors   Size Id Type
/dev/sdg1  *         64 2333951 2333888   1.1G 17 Hidden HPFS/NTFS
/dev/sdg2       2333952 3970047 1636096 798.9M  c W95 FAT32 (LBA)

The partition table has been altered.
Calling ioctl() to re-read partition table.
Syncing disks.
[root@devuan isos]# 

I think it works properly.
ie: as advertised -> no small feat. 

Just one thing ...
At some point towards the end of the job, I think (?) the stick is unmounted and then remounted.
Not sure of that.

The first time I tried the script it ended with a a pop-up with an error and the second partition was not formatted. (unknown)
I then ran the script again and it ended with a formatted FAT32 partition, no errors.

To check, I ran the whole process again: blanked the SD card, ran the format / image writing applications and then the script.

Although the same thing happened ie: the pop-up with an error for writing the second partition, on checking I saw that the second partiton had been formatted.

You may want to test and see if a short pause somewhere between the creation of the second partition and formatting it to FAT32 would avoid that.

Let me know if you need anything else.

Best,

A.

Hello:

No problem, seems you are quite busy.

Done.
Used a 2.0GB SD Card on a generic USB SD/Micro SD Card reader and wrote a Chimaera i386 *.iso.
No problems, was abe to boot my 1000HE both from SD Card in slot and SD Card in reader.

disks and gparted reported as expected.

Labelled the script 'fatstick', made it executable.
Ran is as root, I have specific permissions for sudo and too lazy to add another entry in sudoers.d.

$ sudo ./fatstick.sh
Sorry, user is not allowed to execute './fatstick.sh' as root on localhost.
$ 

But I get an error/warning:

# ./fatstick.sh
(yad:2866): Gtk-WARNING **: 09:21:27.813: cannot open display: 
# 

Something in the script?

Best,

A.

Hello:

I expect that it would be the same with my 1000HE which is ca. 2009.

No idea, but I expect that it could be possible.

From what little I understand, it seems that the task would involve compiling a kernel from source but including only what you need for your netbook.
ie: tailored for your target hardware and compiled on it.

There's also the question of who is going to do it and then maintain it.
For starters, is there a large enough user base?
There used to be specific eee kernels / distributions but as the differnet models were mothballed, they lost all traction.

Interesting side note:
Asus does not have the eee series in theri tech support databases.

I have recently been able to get a very important boost for my netbook by enabling zram and generating a /dev/zram0 swap file.

The Asus eee series is not alone in this.
Absolutely every discontinued and perfectly working netbook / notebook is in the same situation.

All victims of the decades old WinTel consortium. (see what is going on with Win 11 these days)

Best,

A.