Re: [Libcdio-devel] Distraction over Wikipedia topic, was Rock Ridge and libisofs/xorriso 'AL' extension

[Natalia Portillo]

Hi,

On 25/07/17 17:44, Thomas Schmitt wrote:
> Second a short distraction over the Wikipedia topic. :))
> Third section will be about interaction with Kali.
> 
> 
> Natalia Portillo wrote:
>> If you create an interesting tool and/or structure specification whatever,
>> YOU CANNOT create the wikipedia page yourself,
> 
> The advantage of this rule is that the one or two levels of quotation
> can filter out the idiosyncrasies of manuals written by the developers
> or very experienced users.
> The disadvantage is that misunderstandings can sneak in, to which the
> original experts would never come.
> 
> Maybe i would have tried to tunnel underneath that rule if i had suspected
> that AAIP causes problems with readers.
> 

Even then other problems would arise that you wouldn't be able to
correct, and ignorance will spread.
Personally I've had that problems with FAT and NTFS filename namespaces.

In the case of the first one, it arises with everybody defending that
LFNs where introduced with VFAT while I always corrected it. It's as
simple as installing Windows 3.1 yourself and seeing that VFAT.VXD is
the 32-bit protected mode driver introduced there while LFNs first
appear on FASTFAT.SYS driver in Windows NT 3.1.

In the case of the second one, it arises with allowed characteres in
NTFS volumes. After a fierce discussion in the talk page a decade ago
some people has silently put "win32 namespace" and "posix namespace"
allowances that stays nowadays. Except that NTFS namespaces are called
"long" that allows any character but NUL and "short" with the same
restrictions as DOS (8.3, uppercase, etc), and whatever Win32 subsystem,
NTVDM subsystem, OS/2 subsystem, POSIX subsystem and Linux subsystem
limit on their interfaces has nothing to do with NTFS itself.

But that happens with almost every technical article nowadays (not only
about filesystems, but about anything computer related, e.g. the Apple
II article saying color was added in a later model when one of the best
selling points of the original one was its color output), and the people
with the best knowledge to correct the information is limited by two points:

1.- The "independent research" policy that is precisely what made you
the one who knows best about that issue in the world.
2.- The majority wins, as you're just one against a thousand that
without research (as they won't use yours because is "independent")
think they're themselves in the possession of truth when they are, quite
the contrary.

So here I am being the engineer that cracked "independently" a
filesystem whose only knowledge about it before I did were the original
developers (and they lost their documentation :p) sitting watching how
my information can't be propagated by their stupid rules while ignorance
and misinformation becomes prevalent beyond my ability to fight their horde.

Rocky, sorry for the spam :/

>> I'm in the same situation having done DiscImageChef
> 
> Yeah. Sometimes it is painful to see under-representation or even
> mis-representation of one's work.
> 
> Apropos:
> Looking at https://github.com/claunia/DiscImageChef i miss a reference
> to the El Torito boot pointers of ISO images. Is this included in the
> topic "ISO 9660" ?
> (One may also find MBR, GPT, Sun Disklabel, APM, MIPS Volume Header,
>  DEC Bootblock, PReP, CHRP, or HP-PA PALO inside ISO 9660 images.
>  I have a byte-level description in
>    https://dev.lovelyhq.com/libburnia/libisofs/raw/master/doc/boot_sectors.txt
> )

Do you refer in code or in documentation?
My ISO9660 code is in need for a rewrite, it's a fast and dirty join of
different C snippets I had a decade ago :p

'bout MBR, GPT and APM inside ISO images that's already done, the rest
are I'm right now on it, but for me ISO images present a problem:
They represent a 2048 bytes/sector device, while all of that hacks are
aligned to 512 bytes/sector.

So I'm unsure if I should code misalignment handling in the "bootblocks"
code or create a "MODE SELECT" to the disc image code like old CD drives
had :/

I will check your documentation, thanks!

Regards,
Natalia Portillo