joshmoz

It's cool that they were able to do this with two machines, and I don't want to detract from that, but it's probably worth pointing out that a "machine" is not a very useful unit of capacity. These two machines could be dual core i5s or they could be 20 core xeon boxes with hugely varying amounts of memory and storage. Too bad they don't clarify, I'm curious.

Will see if we can clarify re: your first point. Probably have to live with the caps but will ask about that too.

Thanks for the feedback.

The idea here is that we need to be able to modify terms quickly if need be (e.g. if a critical issue is identified), but hopefully that will never be the case. Under normal circumstances we will post the updated agreement quite a while before it takes effect. Current thinking is that we'll try for 45-90 days.

Thanks for your feedback.

You're looking at the key which defines what CRITICAL means. Look further down the page for info about actual vulns. I believe they're running a bit late posting the vulns for 38 today.

The CA itself is not ready yet. When it is, you can use the client in a simple mode to grab a certificate and drop it wherever you want, without automated configuration.

Thanks for pointing this out! Filed a bug:

https://github.com/mozilla/mozjpeg/issues/139

I said in another comment that we'd release 3.0 tomorrow, we'll probably hold up the release to investigate this.

We have no plans to use mozjpeg in Firefox, it will continue to use libjpeg-turbo. The decoder that comes with mozjpeg is unmodified from libjpeg-turbo, mozjpeg is focused on compression for those serving up images.

FYI, I plan to officially release mozjpeg 3.0 tomorrow.

Thanks for the writeup and your work on this release, Kornel!

We'll have very broad compatibility from day one via cross-signing by IdenTrust.

What you're seeing today is demos, not the software in its final form. You're also seeing it demo'd with a focus on the most simple usage. There are, and will be, advanced options.

We'll be doing quite a bit of work based on user feedback between now and when we go live. We're well aware that we need to cater to a variety of types of users.

This is not an attempt to reduce the CA system to a single CA. The intent here is to provide a simple and free way for anyone to get basic DV certs. If we can also contribute to CA best practices, and help improve the CA system in general, we'd like to do that too.

Let's Encrypt is only planning to issue DV certificates, since that is the only type that can be issued in a fully automated way. Many organizations will want something other than DV, and they'll have to get such certs from other CAs.

Also, our software and protocols are open so that other CAs can make use of them.

IdenTrust will be cross-signing our roots while we apply to root programs.

"cjpeg" is the basic command-line tool for making use of the mozjpeg library to create JPEG images.

libjpeg-turbo and IJG JPEG libraries also have "cjpeg" tools as their basic command-line encoder. The tool for mozjpeg works almost exactly the same way, but it has some extra option flags, can take JPEG input (the others can't), and re-defines the "-baseline" option to something more intuitive (see v2.1 release notes).

I don't think that fact that you're only looking at lossless compression is clear enough in the post. People see "JPEG" and "compression" and they assume you're talking about lossy compression. The post doesn't include the word "lossless" to describe what you're doing, people have to figure it out.

Happy to hear you're seeing benefits from mozjpeg, and I look forward to the results of your work optimizing run-time performance. Thanks for giving mozjpeg a shot, publishing your results, and contributing back!

Yes, building the source will produce (among other things) a command line application called "cjpeg", which can encode or re-encode.

Daala development is proceeding at a rapid pace. We're just not ready to bring Daala into this conversation quite yet.

IIRC... That is in reference to libpkix, the certificate validation component of NSS. I believe Mozilla developers are working on a replacement for it, called mozilla::pkix, in large part due to libpkix being overly complex. Last time I checked mozilla::pkix was pretty far along.

https://bugzilla.mozilla.org/show_bug.cgi?id=915930

The Mozilla WebP bugs are a mess due to loads of poor comments. Read at your own risk. The bug you cite has been superseded by a new bug with the same poor quality of comments.

I recently posted a more detailed summary of my own views on the second bug:

https://bugzilla.mozilla.org/show_bug.cgi?id=856375#c174

This was discussed with the author of libjpeg-turbo. His priorities are different, it was agreed that a fork is best.

We would like to develop in the open, and hopefully with community participation.

No shell script or second step involved. Functionality is built in and on by default.

This is just a start, we wanted to have something people could use on day one. Further developments to come.

Release notes include a link to a list of new contributors and their contributions. Never noticed that before.

https://blog.mozilla.org/community/2014/02/03/firefox-27-new...

Looked up some past numbers:

  Firefox 24: 43 new contributors, 32 volunteers
  Firefox 25: 51 new contributors, 39 volunteers
  Firefox 26: 43 new contributors, 27 volunteers
  Firefox 27: 41 new contributors, 35 volunteers

I think Mozilla considers its employees and the employees of known major contributing companies to not be volunteers.

Firefox dev here. Sorry to hear you're having issues with Firefox. This has not been my experience, would love to know more specifics about apps that don't work in Firefox.

Would be hugely helpful if you could file a bug (bugzilla.mozilla.org) when you see something that doesn't work, but if you want a quicker way to help I'll file the bug for you. Just send me a one line email with the problematic URL. joshmoz at gmail

Relevant reading... The author(s) of libjpeg-turbo on IJG priorities:

http://www.libjpeg-turbo.org/About/Jpeg-9

You guys (parent & parent) should realize you don't have nearly enough information to support your conclusions. You need to travel a lot more to generalize like that. You come off as jaded know-it-alls who think romantic viewpoints and optimism are for children and idiots.

I started un-jaded then I came to the same conclusion as you two. I kept going though and I'm changing my mind again - the world is not all the same, and there is plenty of opportunity for adventure. Maybe I'll change my mind again, I don't know everything either, but I hope I don't.

I don't know exactly what you guys did or didn't do, but my advice would be to adjust your strategy for where you spend time, and push yourself to pay closer attention. Maybe learn another language if you haven't already so you can really dive in.

Study author here. For Y-SSIM and IW-SSIM we convert the images to grayscale (MATLAB 'rgb2gray') before running the scoring algorithms. We aren't running the algorithms on luma planes. See published code and methodology.

The Rust language is being designed to be ideal for use in building a Web rendering engine. Mozilla's rust-based engine experiment is called Servo:

https://github.com/mozilla/servo

I worked on Camino quite a bit in the early 2000s, it was a great experience. It's funny to think that we really felt we were contributing greatly to the appeal of Mac OS X by providing the kind of browsing experience Apple should have provided on the OS much earlier, given their focus on it being designed with the Web in mind.

Eventually Mozilla hired me to help re-write the Firefox port to Mac OS X because the product lagged so far behind Camino. Once I got deep enough into that project my Camino contributions dropped off. Dedicated volunteers carried on. I had forgotten that they still hadn't shut it down yet.

Anyway, congrats to Camino on the long run! It was a great option, particularly for earlier Mac OS X users, and a joy to work on.

Google pays to ship FoxIt's closed-source PDF engine with Chrome.

Adobe was not paying Mozilla for anything like that. Chrome simply includes a paid closed-source product (FoxIt, iirc). This was and is not an option for Mozilla for multiple reasons.

It took Mozilla a while to get here, which is unfortunate, but the result is an open-source PDF reader that doesn't add yet another binary rendering engine to the browser (think security, hack-ability). Creating it made Gecko and the web platform better, because it pushed us. There is more work to do, but it's a great start and a welcome change to how these features are implemented.

A bit more info in a blog post that I wrote:

https://boomswaggerboom.wordpress.com/2013/02/19/exciting-st...