I believe the blog post below has relevance to Debian's stance on
including minified JavaScript in packages:
https://zyan.scripts.mit.edu/blog/backdooring-js/
To me the problem suggests that it is important from a security and
accountability perspective to 1) include the human-readable source cod
On 08/24/2015 01:54 PM, Simon Josefsson wrote:
> I believe the blog post below has relevance to Debian's stance on
> including minified JavaScript in packages:
>
> https://zyan.scripts.mit.edu/blog/backdooring-js/
>
> To me the problem suggests that it is important from a security and
> accountab
* Thomas Goirand , 2015-08-24, 16:08:
I believe the blog post below has relevance to Debian's stance on
including minified JavaScript in packages:
https://zyan.scripts.mit.edu/blog/backdooring-js/
To me the problem suggests that it is important from a security and
accountability perspective t
On Tue, Aug 25, 2015, at 11:04, Jakub Wilk wrote:
> Do we actually require re-minifying JS code at build time?
You can either ship the unminifyied JS, or minify it at build time.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them.
Quoting Jakub Wilk (2015-08-25 16:04:52)
> * Thomas Goirand , 2015-08-24, 16:08:
>>>I believe the blog post below has relevance to Debian's stance on
>>>including minified JavaScript in packages:
>>>
>>>https://zyan.scripts.mit.edu/blog/backdooring-js/
>>>
>>>To me the problem suggests that it is
❦ 25 août 2015 16:04 +0200, Jakub Wilk :
>>> I believe the blog post below has relevance to Debian's stance on
>>> including minified JavaScript in packages:
>>>
>>>https://zyan.scripts.mit.edu/blog/backdooring-js/
>>>
>>> To me the problem suggests that it is important from a security and
>>> a
On Tuesday, August 25, 2015 05:12:56 PM Vincent Bernat wrote:
> ❦ 25 août 2015 16:04 +0200, Jakub Wilk :
> >>> I believe the blog post below has relevance to Debian's stance on
> >>>
> >>> including minified JavaScript in packages:
> >>>https://zyan.scripts.mit.edu/blog/backdooring-js/
> >>>
> >>
Quoting Scott Kitterman (2015-08-25 17:57:11)
> On Tuesday, August 25, 2015 05:12:56 PM Vincent Bernat wrote:
>> ❦ 25 août 2015 16:04 +0200, Jakub Wilk :
> I believe the blog post below has relevance to Debian's stance on
>
> including minified JavaScript in packages:
>https://zya
Jakub Wilk dijo [Tue, Aug 25, 2015 at 04:04:52PM +0200]:
> >>To me the problem suggests that it is important from a security and
> >>accountability perspective to 1) include the human-readable source code
> >>of JavaScript in Debian packages, and 2) to compile the human-readable
> >>source code int
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, Aug 25, 2015 at 07:17:12PM +0200, Jonas Smedegaard wrote:
> Quoting Scott Kitterman (2015-08-25 17:57:11)
> > AFAIK we've only ever discussed the need to provide source. I don't
> > know why there would be a requirement to reminify.
>
> I se
Scott Kitterman dijo [Tue, Aug 25, 2015 at 11:57:11AM -0400]:
> > No, we don't require to rebuild everything from source. It should just
> > be possible to do it with what is in main. The last occurrence that I
> > can find of this discussion is here:
> > https://lists.debian.org/debian-devel/2014
Bas Wijnen writes ("Re: Security concerns with minified javascript code"):
> AFAIK Debian doesn't *require* generated files to be rebuilt. For
> example, it used to be common practice for a long time to copy
> config.{guess,sub} from autotools-dev instead of regenerating t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, Aug 25, 2015 at 07:08:06PM +0100, Ian Jackson wrote:
> Bas Wijnen writes ("Re: Security concerns with minified javascript code"):
> > AFAIK Debian doesn't *require* generated files to be rebuilt. For
> > example,
* Ian Jackson , 2015-08-25, 19:08:
Not regenerating configure doesn't pose any significant risk that we're
shipping a configure script that we can't regenerate (or, at least,
regenerate an equivalent or better one).
Autotools stuff tends to bitrot, just like everything else. There's a
reason
Jakub Wilk writes ("Re: Security concerns with minified javascript code"):
> Ian Jackson , 2015-08-25, 19:08:
> >I've not heard of people (for example) using private autoconf macros
> >not included in their build tree.
>
> #580190
*reads* *blink*
Err,
❦ 25 août 2015 17:58 GMT, Bas Wijnen :
> I don't see why javascript minification would be different from C compilation
> in a way that would lead to a different way of handling it.
Playing a bit of devil's advocate here, but...
It has already been said numerous time in the past, for some Javas
Vincent Bernat wrote:
>
>Notably, one of the tool is Grunt and its myriad of plugins. Even if
>Grunt was in Debian, we would also need Gulp, then Broccoli, because in
>Javascript, there is always someone thinking that it should be possible
>to do better. We need to leave the Javascript ecosystem ma
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, Aug 25, 2015 at 11:13:15PM +0200, Vincent Bernat wrote:
> ❦ 25 août 2015 17:58 GMT, Bas Wijnen :
>
> > I don't see why javascript minification would be different from C
> > compilation
> > in a way that would lead to a different way of hand
❦ 25 août 2015 22:37 GMT, Bas Wijnen :
>> We need to leave the Javascript ecosystem mature a bit more but in the
>> meantime, a bit of tolerance would be appreciated
>
> The minifier is a compiler. If it's not in main, files that are compiled with
> it cannot be in main. For javascript, the ea
❦ 25 août 2015 22:46 +0100, Steve McIntyre :
>>Notably, one of the tool is Grunt and its myriad of plugins. Even if
>>Grunt was in Debian, we would also need Gulp, then Broccoli, because in
>>Javascript, there is always someone thinking that it should be possible
>>to do better. We need to leave
> For years, we have been able to ship generated files without checking if
> they can really be built from sources (for example, autoconf stuff). And
> JS stuff should comply to stricter standards from day one?
JS stuff has been in Debian for a long time; it isn't fair to say that
this is day one
❦ 26 août 2015 15:44 +1000, Riley Baird
:
>> For years, we have been able to ship generated files without checking if
>> they can really be built from sources (for example, autoconf stuff). And
>> JS stuff should comply to stricter standards from day one?
>
> JS stuff has been in Debian for a
Vincent Bernat writes:
> ❦ 25 août 2015 22:46 +0100, Steve McIntyre :
>
>>>Notably, one of the tool is Grunt and its myriad of plugins. Even if
>>>Grunt was in Debian, we would also need Gulp, then Broccoli, because in
>>>Javascript, there is always someone thinking that it should be possible
>
❦ 26 août 2015 09:04 +0200, Simon Josefsson :
Notably, one of the tool is Grunt and its myriad of plugins. Even if
Grunt was in Debian, we would also need Gulp, then Broccoli, because in
Javascript, there is always someone thinking that it should be possible
to do better. We need
On Wed, Aug 26, 2015 at 12:04 AM, Simon Josefsson wrote:
> Vincent Bernat writes:
>
>> ❦ 25 août 2015 22:46 +0100, Steve McIntyre :
>>
Notably, one of the tool is Grunt and its myriad of plugins. Even if
Grunt was in Debian, we would also need Gulp, then Broccoli, because in
Javascr
> Sure, you can proofread a 30k-line configure script without a
> problem. So, the condition is now "must be generated from source only if
> the generated from is hard-but-not-impossible to read".
Several times over the last year I have modified the output form of
autoconf directly when doing mino
Vincent Bernat writes:
> ❦ 25 août 2015 22:46 +0100, Steve McIntyre :
>
>>>Notably, one of the tool is Grunt and its myriad of plugins. Even if
>>>Grunt was in Debian, we would also need Gulp, then Broccoli, because in
>>>Javascript, there is always someone thinking that it should be possible
>
❦ 26 août 2015 20:58 +1000, Riley Baird
:
>> I would also like to stress that all this stuff is DFSG-compliant.
>
> Doesn't the DFSG require source code, as well as a free license?
Yes and both of them are here. Only the build method is either
unavailable, unspecified or needing network connec
Vincent Bernat writes ("Re: Security concerns with minified javascript code"):
> My point is not that's a good idea. My point is that this has been
> tolerated for years while there was an easy workaround solution (running
> autoreconf).
It was only tolerated because pro
❦ 26 août 2015 12:09 +0100, Philip Hands :
> I note that this page:
>
> https://wiki.debian.org/Javascript/Nodejs/Tasks/grunt
>
> was last touched in March, before the last thread in which you told us
> that packaging grunt is very hard:
>
> https://lists.debian.org/debian-devel/2015/04/msg0
❦ 26 août 2015 13:01 +0100, Ian Jackson :
>> It's "unfair" to ask packages using JS stuff to be
>> "perfect" right now while the difficulties are far greater.
>
> I'm sorry to say that the very fact that the difficulties are more
> severe is an argument /against/ tolerating un-rebuilt minified j
On Wed, Aug 26, 2015 at 12:28:22AM -0700, Vincent Cheng wrote:
> In that case, perhaps those who are most vocally in favour of
> enforcing build-time javascript minification would care to work on a
> debhelper addon to do so (similar to how dh-autoreconf makes dealing
That to me seems the best way
Craig Small wrote:
>On Wed, Aug 26, 2015 at 12:28:22AM -0700, Vincent Cheng wrote:
>> In that case, perhaps those who are most vocally in favour of
>> enforcing build-time javascript minification would care to work on a
>> debhelper addon to do so (similar to how dh-autoreconf makes dealing
>That t
Vincent Bernat writes:
> ❦ 26 août 2015 12:09 +0100, Philip Hands :
>
>> I note that this page:
>>
>> https://wiki.debian.org/Javascript/Nodejs/Tasks/grunt
>>
>> was last touched in March, before the last thread in which you told us
>> that packaging grunt is very hard:
>>
>> https://lists.
Vincent Bernat writes ("Re: Security concerns with minified javascript code"):
> In the Debian context, the problem is hard. But if you allow network
> access and execution of arbitrary code recovered from some random
> registry, rebuilding the minified version from the unmini
Ian Jackson writes:
> Vincent Bernat writes ("Re: Security concerns with minified javascript code"):
>> In the Debian context, the problem is hard. But if you allow network
>> access and execution of arbitrary code recovered from some random
>> registry, rebuildin
❦ 26 août 2015 09:27 -0700, Russ Allbery :
>>> In the Debian context, the problem is hard. But if you allow network
>>> access and execution of arbitrary code recovered from some random
>>> registry, rebuilding the minified version from the unminified one is
>>> quite trivial.
>
>>> I know how i
Hello list,
On 26.08.2015 15:56, Philip Hands wrote:
> Vincent Bernat writes:
>
>> [...]
>> 3. ship a pre-compiled/minified version of the library with sources.
>>
>> I know this sucks, but if I have to pick my poison, I'll pick the last
>> one. I have tried the second solution in the past, nob
On Aug 26, Russ Allbery wrote:
> Maybe there's some pragmatic approach that I haven't thought of yet that
> will make this less painful. That's what I'm hoping for.
Me too: I really care that Debian will continue to be relevant.
--
ciao,
Marco
pgpMdNWptTf8g.pgp
Description: PGP signature
On Wed, Aug 26, 2015 at 1:42 PM, Vincent Bernat wrote:
> Yes and both of them are here. Only the build method is either
> unavailable, unspecified or needing network connectivity.
Sounds like something that should be in contrib?
--
bye,
pabs
https://wiki.debian.org/PaulWise
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, Aug 26, 2015 at 07:35:01AM +0200, Vincent Bernat wrote:
> ❦ 25 août 2015 22:37 GMT, Bas Wijnen :
>
> >> We need to leave the Javascript ecosystem mature a bit more but in the
> >> meantime, a bit of tolerance would be appreciated
> >
> > The
Bas Wijnen writes:
> On the other hand, shipping packages that cannot be rebuilt with tools
> from Debian will also result in angry users. For me personally, one of
> the bigger reasons I use Debian is that we take good care that I can
> modify everything on my system, and use the modified versi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, Aug 27, 2015 at 04:14:53PM -0700, Russ Allbery wrote:
> Bas Wijnen writes:
>
> > On the other hand, shipping packages that cannot be rebuilt with tools
> > from Debian will also result in angry users. For me personally, one of
> > the bigger
❦ 27 août 2015 22:04 GMT, Bas Wijnen :
>> > The minifier is a compiler. If it's not in main, files that are compiled
>> > with
>> > it cannot be in main. For javascript, the easy solution is to not use the
>> > compiler. Non-minified code works fine.
>>
>> Non-minified code is decomposed in
❦ 28 août 2015 01:46 GMT, Bas Wijnen :
> Or alternatively, by packaging the minifier that is being used with the
> package
> that needs it. Yes, that's a horrible idea with lots of code duplication, but
> if I understand the problem, every JS file must be minified with the exact
> version of t
Vincent Bernat writes:
> 28 août 2015 01:46 GMT, Bas Wijnen :
>
>> Or alternatively, by packaging the minifier that is being used with the
>> package
>> that needs it. Yes, that's a horrible idea with lots of code duplication,
>> but
>> if I understand the problem, every JS file must be minif
❦ 28 août 2015 08:22 +0100, Philip Hands :
>>> Or alternatively, by packaging the minifier that is being used with the
>>> package
>>> that needs it. Yes, that's a horrible idea with lots of code duplication,
>>> but
>>> if I understand the problem, every JS file must be minified with the exa
Vincent Bernat, le Fri 28 Aug 2015 07:42:42 +0200, a écrit :
> > Yes, that is a danger. I think putting those things in contrib should be a
> > good solution if rebuilding is such a big problem. Because if it is, the
> > code
> > really really doesn't belong in main.
>
> What will happen is tha
Vincent Bernat, le Fri 28 Aug 2015 10:06:17 +0200, a écrit :
> Maybe it can be trimmed a bit more, but that's still 239 unique
> dependencies.
Note that you don't have to make that 239 debian packages, you could as
well just ship them all in one package, as long as the whole code passes
NEW, i.e.
❦ 28 août 2015 10:29 +0200, Samuel Thibault :
>> What will happen is that maintainers will fallback to the second less
>> horrible solution and cripple the package (by using an older version of
>> the JS lib for example) to allow it to stay in main.
>
> Why would they want to stay in main?
[...
Vincent Bernat, le Fri 28 Aug 2015 10:48:28 +0200, a écrit :
> ❦ 28 août 2015 10:29 +0200, Samuel Thibault :
>
> >> What will happen is that maintainers will fallback to the second less
> >> horrible solution and cripple the package (by using an older version of
> >> the JS lib for example) to a
On Monday 24 August 2015 13:54:21 Simon Josefsson wrote:
> I believe the blog post below has relevance to Debian's stance on
> including minified JavaScript in packages:
>
> https://zyan.scripts.mit.edu/blog/backdooring-js/
Thank you for a nice argument against minification.
During packaging I a
On Fri, 28 Aug 2015 10:45:16 +0200
Samuel Thibault wrote:
> Vincent Bernat, le Fri 28 Aug 2015 10:06:17 +0200, a écrit :
> > Maybe it can be trimmed a bit more, but that's still 239 unique
> > dependencies.
>
> Note that you don't have to make that 239 debian packages, you could
> as well just s
❦ 28 août 2015 10:32 +0100, Neil Williams :
> I still find it hard to believe that *so* much code is required to
> minify JS. The excuse that JS is "moving fast" is nonsense. The reality
> would appear to be that nobody actually *cares* about the mess, they
> just use it.
It's a feature. The JS
Neil Williams, le Fri 28 Aug 2015 10:32:52 +0100, a écrit :
> On Fri, 28 Aug 2015 10:45:16 +0200
> Samuel Thibault wrote:
>
> > Vincent Bernat, le Fri 28 Aug 2015 10:06:17 +0200, a écrit :
> > > Maybe it can be trimmed a bit more, but that's still 239 unique
> > > dependencies.
> >
> > Note that
❦ 28 août 2015 12:03 +0200, Samuel Thibault :
> I wonder why mere gzip compression is not used. Don't all browsers
> support Accept-Compress: gzip?
Minification saves some additional bytes. About 10% (when gzipped).
--
If you tell the truth you don't have to remember anything.
Dmitry Smirnov writes:
> On Monday 24 August 2015 13:54:21 Simon Josefsson wrote:
>> I believe the blog post below has relevance to Debian's stance on
>> including minified JavaScript in packages:
>>
>> https://zyan.scripts.mit.edu/blog/backdooring-js/
>
> Thank you for a nice argument against m
Vincent Bernat wrote:
> (...)
> It has already been said numerous time in the past, for some Javascript
> code, we don't really have the tools in Debian to easily go from the
> source to the minified version. It's possible, but without the
> appropriate tools, it's painful.
I've been using yui-com
Neil Williams writes:
> I still find it hard to believe that *so* much code is required to
> minify JS. The excuse that JS is "moving fast" is nonsense. The reality
> would appear to be that nobody actually *cares* about the mess, they
> just use it.
This is almost certainly correct.
> Usable s
Russ Allbery wrote:
>Neil Williams writes:
>
>> Usable software needs usable tools.
>
>The problem is that this *is* usable for nearly all the people who
>currently use it, who just run one command to install it and have all
>those dependencies pulled from a remote repo for them. Because the
>dep
Steve McIntyre writes:
> Depressingly, it seems a lot of the same web typists don't have any
> problems with doing the equivalent of "curl http://some.site/install.sh
> | sudo bash" . That doesn't mean we have to do the same in Debian. If
> there's no sensible way to do controlled web development
On Fri, Aug 28, 2015 at 4:12 PM, Jean-Michel Vourgère
wrote:
Vincent Bernat wrote:
> > (...)
> > It has already been said numerous time in the past, for some Javascript
> > code, we don't really have the tools in Debian to easily go from the
> > source to the minified version. It's possible, but
On Fri, Aug 28, 2015 at 4:12 PM, Jean-Michel Vourgère
wrote:
Vincent Bernat wrote:
> > (...)
> > It has already been said numerous time in the past, for some Javascript
> > code, we don't really have the tools in Debian to easily go from the
> > source to the minified version. It's possible, but
❦ 28 août 2015 17:37 +0100, Steve McIntyre :
>>The problem is that this *is* usable for nearly all the people who
>>currently use it, who just run one command to install it and have all
>>those dependencies pulled from a remote repo for them. Because the
>>dependency installation process is so
On Fri, Aug 28, 2015 at 07:42:42AM +0200, Vincent Bernat wrote:
> >> The main effect of this religious and overzealous application of our
> >> guidelines is that people just stay away of JS stuff in Debian and
> >> packaging any web-related app is becoming more complex as anyone needs
> >> to deal
Steve Langasek writes:
> […] Nevertheless, for packages that *are* in Debian, we should expect
> that the source package contains the *full* corresponding source code
> for any minified javascript files. If we can't rebuild it then we
> don't actually have the source, and that's a practical as we
]] Vincent Bernat
> 1. package the whole Grunt ecosystem (and maintain it),
> 2. cripple their package by substituting some components by a non-working
> version in Debian or,
> 3. ship a pre-compiled/minified version of the library with sources.
>
> I know this sucks, but if I have to pi
❦ 29 août 2015 19:12 -0700, Steve Langasek :
> Yet you try to compare this with autoconf. Even if we tolerated configure
> scripts today in the archive that we can't rebuild using the software in
> Debian (which by and large we do *not* tolerate - because we've learned our
> lesson), there's a
On Sun, Aug 30, 2015 at 10:14 AM, Vincent Bernat wrote:
> The build script determines the outcome of what will effectively run on
> our users' machine. I fail to see how this is not an important
> issue. But until the effort to get ppc64el, not regenerating the
> configure script was just a fine o
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sun, Aug 30, 2015 at 10:14:13AM +0200, Vincent Bernat wrote:
> The build script determines the outcome of what will effectively run on
> our users' machine. I fail to see how this is not an important
> issue.
You are correct, this is important.
>
❦ 30 août 2015 11:52 GMT, Bas Wijnen :
>> However, this is a readable source code that will accomodate any
>> modification that a end user will deem necessary.
>
> That is not the only reason that we want the user to have source.
> They are not some detached "customer". When we make changes to
On 08/28/2015 01:14 AM, Russ Allbery wrote:
> Bas Wijnen writes:
>
> Last time I checked, Doxygen includes minified Javascript in all of its
> generated output. Would we have to move every piece of Doxygen-generated
> documentation into a separate package so that we could put it in contrib,
> or
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sun, Aug 30, 2015 at 02:12:43PM +0200, Vincent Bernat wrote:
> This is becoming quite a stretch. At this rate, we will fail to match
> SC#2 because we ship previous versions of software and upstream is
> unlikely to accept a patch against a non-curr
On Sun, 30 Aug 2015, Bas Wijnen wrote:
> Why do you care that software is in main, if you evidently do not care about
> any of the rules we have for it?
I don't think that implying that Vincent doesn't not care about Free
Software is very constructive.
Can we please stop this now?
If all the ene
Raphael Hertzog writes:
> In both cases, I worked around the problem by shipping the upstream
> sources in debian/missing-sources/ but I did not support doing changes
> there and did not rebuild the embedded libraries.
>
> In some cases, I do replace the embedded library with a symlink to the
> p
On Mon, 31 Aug 2015 at 16:50 Raphael Hertzog wrote:
> In both cases, I worked around the problem by shipping the upstream
> sources in debian/missing-sources/ but I did not support doing changes
> there and did not rebuild the embedded libraries.
>
I haven't been paying lots of attention to this
On Mon, 31 Aug 2015, Simon Josefsson wrote:
> How would someone rebuild the minified javascript files from the
> missing-sources files?
They would not?
The modified non-minified files are perfectly usable even if they are a
bit larger than the minified ones.
> The included JavaScript file is m
Raphael Hertzog writes:
> On Mon, 31 Aug 2015, Simon Josefsson wrote:
>> How would someone rebuild the minified javascript files from the
>> missing-sources files?
>
> They would not?
>
> The modified non-minified files are perfectly usable even if they are a
> bit larger than the minified ones.
On Tue, Aug 25, 2015 at 07:08:06PM +0100, Ian Jackson wrote:
> Not regenerating configure doesn't pose any significant risk that
> we're shipping a configure script that we can't regenerate (or, at
> least, regenerate an equivalent or better one). I've not heard of
> people (for example) using pri
On Thu, Aug 27, 2015 at 04:14:53PM -0700, Russ Allbery wrote:
> Last time I checked, Doxygen includes minified Javascript in all of its
> generated output. Would we have to move every piece of Doxygen-generated
> documentation into a separate package so that we could put it in contrib,
> or strip
First, let me make it clear that I am firmly in the camp that believes
minified JS cannot be distributed in main unless the tools to recreate
it are also in main. It bothers me that there appears to be a
not-insignificant number of people with upload rights who do not believe
this.
This message i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, Aug 31, 2015 at 08:49:53AM +0200, Raphael Hertzog wrote:
> On Sun, 30 Aug 2015, Bas Wijnen wrote:
> > Why do you care that software is in main, if you evidently do not care about
> > any of the rules we have for it?
>
> I don't think that impl
Hi,
On Mon, Aug 31, 2015 at 09:50:05AM +0200, Raphael Hertzog wrote:
> On Mon, 31 Aug 2015, Simon Josefsson wrote:
> > How would someone rebuild the minified javascript files from the
> > missing-sources files?
>
> They would not?
>
> The modified non-minified files are perfectly usable even if t
On Sep 01, Guido Günther wrote:
> Couldn't we just use the non-minified versions in most situations? A
Not for anything which has actual users over the network.
> heavily loaded wordpress site might not be good example but e.g. doxygen
> documentation probably doesn't suffer much from non minifi
❦ 31 août 2015 11:21 -0400, Marvin Renich :
>> > However, this is a readable source code that will accomodate any
>> > modification that a end user will deem necessary.
>
> I intentionally did not look at the file referred to above, and have no
> idea whether I would consider it to be a "preferr
On Tue, Sep 01, 2015 at 08:15:19AM +0200, Guido Günther wrote:
> Couldn't we just use the non-minified versions in most situations? A
> heavily loaded wordpress site might not be good example but e.g. doxygen
> documentation probably doesn't suffer much from non minified JS.
I fail to see what pro
On Sep 01 2015, m...@linux.it (Marco d'Itri) wrote:
> On Sep 01, Guido Günther wrote:
>
>> Couldn't we just use the non-minified versions in most situations? A
>
> Not for anything which has actual users over the network.
Why? (Don't forget about gzip encoding).
Best,
-Nikolaus
--
GPG encrypt
On Sep 01 2015, Helmut Grohne wrote:
> On Tue, Sep 01, 2015 at 08:15:19AM +0200, Guido Günther wrote:
>> Couldn't we just use the non-minified versions in most situations? A
>> heavily loaded wordpress site might not be good example but e.g. doxygen
>> documentation probably doesn't suffer much fr
❦ 1 septembre 2015 08:21 -0700, Nikolaus Rath :
>>> Couldn't we just use the non-minified versions in most situations? A
>>
>> Not for anything which has actual users over the network.
>
> Why? (Don't forget about gzip encoding).
See:
https://mathiasbynens.be/demo/jquery-size
--
Don't sacrif
> On Mon, Aug 31, 2015 at 11:21:55AM -0400, Marvin Renich wrote:
> > * Bas Wijnen [150830 07:53]:
> > > On Sun, Aug 30, 2015 at 10:14:13AM +0200, Vincent Bernat wrote:
> > > > Is that the preferred form of modification? It depends, but from the
> > > > jQuery author point of view, it isn't:
> > >
On Sep 01 2015, Vincent Bernat wrote:
> ❦ 1 septembre 2015 08:21 -0700, Nikolaus Rath :
>
Couldn't we just use the non-minified versions in most situations? A
>>>
>>> Not for anything which has actual users over the network.
>>
>> Why? (Don't forget about gzip encoding).
>
> See:
> https:
Hi,
On Mon, 31 Aug 2015, Bas Wijnen wrote:
> > I certainly do not want to move wordpress or publican to contrib because
> > some of the javascript libraries that it uses can't be rebuilt from main.
>
> In that case, my question applies to you as well: why do you care for it to be
> in main, if yo
* Raphael Hertzog [150901 12:57]:
> Because we have alternative "compilers" (aka minifier) available to
> recreate another minified file thas should work just as well.
No. Debian does not allow you to ship a compiled C program that was
compiled elsewhere; the maintainer or a buildd is responsibl
On Sep 01, Nikolaus Rath wrote:
> I don't think 28 kB vs 73 kB is a difference that people will notice
> over the network in *most* situations. Even at just 100 kB/s that's
> 0.28 vs 0.73 seconds, and only when the page is first loaded.
Yes, this is a non trivial difference when loading a web pag
On Tue, Sep 01, 2015 at 04:42:15PM +0200, Helmut Grohne wrote:
> On Tue, Sep 01, 2015 at 08:15:19AM +0200, Guido Günther wrote:
> > Couldn't we just use the non-minified versions in most situations? A
> > heavily loaded wordpress site might not be good example but e.g. doxygen
> > documentation pro
Vincent Bernat dijo [Fri, Aug 28, 2015 at 11:54:43AM +0200]:
> > I still find it hard to believe that *so* much code is required to
> > minify JS. The excuse that JS is "moving fast" is nonsense. The reality
> > would appear to be that nobody actually *cares* about the mess, they
> > just use it.
>
Vincent Bernat dijo [Fri, Aug 28, 2015 at 10:48:28AM +0200]:
> >> What will happen is that maintainers will fallback to the second less
> >> horrible solution and cripple the package (by using an older version of
> >> the JS lib for example) to allow it to stay in main.
> >
> > Why would they want
❦ 1 septembre 2015 13:45 -0500, Gunnar Wolf :
>> uglifyjs is a KISS tool to minify. Unfortunately, many projects do not
>> require only minification. They require transpiling (convert from ES6 to
>> ES5 or from CoffeeScript/Typescript/... to vanilla JS) and dependency
>> handling (through loade
Le mardi, 1 septembre 2015, 17.50:26 Vincent Bernat a écrit :
> ❦ 1 septembre 2015 08:21 -0700, Nikolaus Rath :
> >>> Couldn't we just use the non-minified versions in most situations?
> >>> A
> >>
> >> Not for anything which has actual users over the network.
> >
> > Why? (Don't forget about
❦ 1 septembre 2015 21:10 +0200, Didier 'OdyX' Raboud :
> I think we should take a strong move there and exercise (as well as
> justify to the outer world) our free software right to recompile the
> software that we ship to our users: this could mean to only merge & gzip
> JS files if minifyi
1 - 100 of 147 matches
Mail list logo