hi,

clipka <ano### [at] anonymousorg> wrote:
> Am 06.08.2021 um 15:43 schrieb jr:
> ...
>> [not] using a VM with a BSD or some Linux...
>
> I did resort to working with a VM for some time for testing code for
> *NIX compatibility, but given my low knowledge level of the *NIX world I
> found it rather a hassle compared to my Windows jockey mouse-pusher
> comfort zone. Particularly the process of transferring the
> version-to-test to the test VM kept bothering me.

directory trees/drives can be shared.


> Nowadays I have the Windows Subsystem for Linux at my disposal if needs
> be, which feels a bit more integrated. For instance, I can pop up an
> Ubuntu terminal from my Windows explorer, taking me straight to a
> specific directory on my Windows file system.
>
> It still is a thing I try to avoid though.

</shakes-head>  :-)


> ... So even if I can't avoid
> a detour through the *NIX world entirely, I'll need to spend less time
> there because I already know what I'm about to encounter there.

don't really agree.  for instance, there never has been a functional, let alone
conceptual, equivalent of X on MS Windows.  (was glad to read (in 'INSTALL'?)
that the preview X window proper may be brought back)


>>> And a developers' manual...
>> moot, of course, but wonder whether publishing that to the wiki would have been
>> so very different (time+effort-wise).
>
> Abso-bloody-lutely.
>
> The Wiki is primarily designed to host content entered manually via the
> Wiki interface itself.
>
> I presume there are also channels for bulk uploads of content, but
> they'd have to be in a format supported by the Wiki.
>
> The developers' manual is currently a guesstimated 90% automatically
> generated from the source code, and 10% manually edited information,
> compiled by a dedicated tool that generates either a suite of
> full-fledged HTML pages or a single PDF.
>
> To cram that content into the Wiki would have required writing import
> scripts. And I have 0 - zero, zilch - knowledge about the Wiki import
> format, while presumably Jim has just as much knowledge about the format
> generated by said tool (beyond the fact that it's HTML, of course).

well, adding a link to the "suite of full-fledged HTML pages" certainly would
not be too .. taxing.

agree on editing aspects etc, though that doesn't apply for generated stuff.


>> ... my browser has to divulge all sorts of info about the system
>> it's running on.
>
> Does it though? Or is it just set to freely do that, and the other end
> takes the liberty to make use of that?
>
> If you were to bar your browser from divulging that information, would
> you really hit a brick wall?

is besides the point.  I think that the onus is on the site to only ask for what
 is needed.  personally, I take what I need, I do not grab more/everything just
because I can, and expect (of course) the same from others.

my "solution" to this is to use a dedicated machine[*] for all browsing.

[*] a Chromebook, so I have an option to "powerwash" if needed.


>> ... captcha ...
>
> It's been ages since I've seen an issue reporting page that doesn't
> require you to at least disclose your e-mail address. Which is all for
> the better in my opinion, because as a developer I want a chance to
> contact the issue reporters, in case I have further questions.

sure, email would be ok (even with verification ;-)).


>> sure.  true also of alternatives, like eg 'fossil'.
>
> Now I think you're confusing the technological platform (such as Git)
> with a particular service based on that platform (such as GitHub).

perhaps, though it seems comparable to me.


regards, jr.

Post a reply to this message