On Sun, 11 May 2025, Aigars Mahinovs wrote:
>Just because *one* software process produces a loosely compression,
>does not mean that ALL software processes are just lossy compression.
Just because *one* doesn’t doesn’t mean none does either *sigh…*
Please, just, go away. I don’t have the spoons
On Sun, 11 May 2025, Aigars Mahinovs wrote:
>> If you JPEG-compress a photo of the original document then uncompress
>> it, it *is*.
>
>Please, restore a document from the output of "wc". Or from the output
Can you even read?
EOT,
//mirabilos
--
22:20⎜ The crazy that persists in his craziness b
On Sat, 10 May 2025, Aigars Mahinovs wrote:
>An algorithm that only stores and produces an *average* value across a
>wide set of inputs can not be any kind of compression.
It’s not “just” an average: as has been shown, substantial amounts of
substantially unmodified “training data” can be extract
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA384
On Fri, 9 May 2025, Simon Josefsson wrote:
>> So, with all the updates, maybe something like this?
>
>I read this now, and think it is an improvement so I'll second this
>version too.
OK, thanks.
>I realized that I have one additional generic conc
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA384
Hi Simon,
>Okay, I see what you are trying to get at, but I'm not certain things
>can be separated that easily.
hm, true. We probably can also not know whether firmware blobs have
this inside or not. Perhaps it’s best to just leave non-free-firmwar
On Thu, 8 May 2025, Simon Josefsson wrote:
>I don't think it is possible to separate firmware into things that are
>just for enabling of hardware compared to what is running on the main
>CPU. Consider a non-free firmware blob for a future SoC CPU that
>includes camera functionality, it seems poss
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA384
On Wed, 7 May 2025, Simon Josefsson wrote:
>I'll second this option. I think it describes an internally consistent
>policy and give clear practical recommendations.
Thank you.
I’ve been made aware-ish of a few questions regarding this via LWN.
T
On Thu, 24 Apr 2025, Carsten Leonhardt wrote:
>Thorsten Glaser writes:
>
>> Hi! I had not realised it’s going to GR with this, so I’ve drafted
>> a counter proposal [...]
>
>Could you give a brief summary of the main differences you see between
>your and Mo'
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA384
Cover letter
(Please do keep me in Cc, I’m not subscribed to the list.)
Hi! I had not realised it’s going to GR with this, so I’ve drafted
a counter proposal, based on the thread on debian-private around
<93d202fce48ab4b4609d59f7a7
Steve McIntyre dixit:
>Please go and *read* and *respond* in debian-vote. The discussion is
>there, not here.
I wrote where the Reply-To pointed to. Perhaps if that had been
correct…
>You've utterly missed Phil's point about people not seeing or hearing
>boot options.
I didn’t. I pointed out th
Devin Prater dixit:
>I use many different operating systems, as a person who is blind. I don't
[…]
>While text *is* usually accessible, it's not always the easiest to use.
My point here was that there are *other* cases where lack of
lynx support means lack of accessibility, even if this seems
to
Luke Faraone dixit:
>Please, a Debian developer who uses a screen reader is saying that
>"works with lynx is not required to be accessible to people with
>disabilities". Saying you're talking about accessibility, but then
There’s multiple kinds of accessibility. It’s sometimes not obvious.
I do
Sam Hartman dixit:
>Thorsten> Alternative solutions may • have accessibility problems
>Thorsten> (not work with lynx, for example
>
>Working with Lynx is not a requirement for accessibility.
No, but not working with lynx is an accessibility problem.
>Obviously accessibility depends on wh
>At the same time it relaxes the requirement that the secretary must
>conduct a vote via email. There are no current plans to move away from
This is a very bad idea.
Alternative solutions may
• have accessibility problems (not work with lynx, for example)
• require different transport (eMail can
Luca Falavigna debian.org> writes:
> 2. Freedom of upstream discrection
>
> Upstream Developers considering a specific Free Software (including,
> but not limited to, a particular init system executed as PID 1)
> fundamental to deliver the best Software releases, are fully entitled
> to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA384
Ian Jackson dixit:
>I wish to propose the following general resolution, and hereby call
(d-d-a would have been nice, but this time I found it in time.)
>** Begin Proposal **
>
>0. Rationale
>
> Debian has decided (via the technical committee) to
Ian Jackson wrote:
>It would probably be best to lump the uncontroversial ones together
>into one GR proposal. The others should be separate, unless any of
Uh. This will lead to bikeshedding about which ones are controversal.
I would prefer them to be separate votes (I know I'd vote for some
and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA384
I really should not be writing this. I should be sleeping.
I have to get up for work in less than six hours. But I
*really* would love to know a DD vote outcome on something
like the below text, though written with less sarcasm, I
guess. (If this vot
18 matches
Mail list logo
