gluxon

[deleted]

PortableApps.com is where I started programming back when I was 11 years old in 2008.

The community completely changed my life. I learned a lot about writing software on forums and the IRC channel from numerous people that were just willing to give advice to a stranger. I'm glad this community is still alive.

I proudly say my first programming language is NSIS. (The Windows scripting language most wrappers on the site are written in.)

Thank you John.

As of the date of this document (2013), no. This is technically not legal. The Library of Congress exempted phones from the DCMA but not video game consoles.

I don't believe the ruling has changed since 2015.

> The Register also confirmed that the exemption for gamers should not extend to jailbreaking of console software because such jailbreaking is strongly associated with video game piracy.

https://copyright.gov/1201/2015/fedreg-publicinspectionFR.pd...

> If it doesn't have any absolutely positioned or floating child elements, wouldn't that imply contain: content?

I think the goal is to avoid analyzing child elements at all. So you can layout a given set of children at one layer of the DOM tree at once rather than having to dig deeper into one node to know where to put its sibling.

> And if you add overflow: auto or hidden, wouldn't that infer to contain: strict?

I think browsers would only be able to reasonable infer "contain: strict" on elements with both overflow auto/hidden and fixed width/height.

I'm guessing that "contain: strict" would allow you to avoid defining fixed height and width then? (That was just my first guess. There may be other reasons.)

I believe this would eliminate many uses of large list rendering libraries (such as react-virtualized/react-window). That's pretty neat.

The same caveats seem to be present for strict containment mode though. The width/height of a strictly contained element wont't update if its contents change.

> For those driving without Autopilot, we registered one accident or crash-like event for every 1.92 million miles driven. By comparison, the National Highway Traffic Safety Administration’s (NHTSA) most recent data shows that in the United States, there is an automobile crash every 492,000 miles. While NHTSA’s data includes accidents that have occurred, our records include accidents as well as near misses (what we are calling crash-like events).

I'm not quite sure what to make of this data. How is it that Tesla cars (without autopilot) are in 4x less accidents than average?

How do you handle situations where two items (lets call them A and B) are both moved before a third item C?

Then wouldn't A and B both have a "SortVal" that's 1 less than C's SortVal? That would make your SortVals non-unique and order arbitrary.

There may be other reasons, but here's one. The solution with fractions supports ORDER BY syntax. With the self-referential foreign keys, you would have traverse through from the beginning with multiple queries for that behavior.

It's also a lot harder to query results in order while specifying an offset.

> If there were better frameworks to use that would allow code reuse across all platforms it would certainly make this easier.

I feel that this is exactly what web applications try to solve in the first place.

I'm curious to see what these charts will look like when watchOS 2 is released, or if it'll even make a difference.

P.S. Good to see you here John.

> Every feature in the browser should be polished, functional, and a joy to use. Where we can’t get it to that state, we shouldn’t do it at all. In some cases that will mean spending time to make it great. In other cases that will mean removing code that we don’t see ourselves improving any time soon. In other cases it will mean finding third party services or addons that can do the job better than we can.

Pay close attention to this. This change in philosophy around features and incorporating third party services is going to create a Firefox that's radically different from releases in the past. For better or worse we've already started seeing these changes with the recent Pocket integration.

> We’re not like most organizations, so we have to partner differently. We worked with Pocket to amend their Privacy Policy to be more in line with our principles. We made sure the code that shipped with Firefox was licensed appropriately.

Amending Pocket's Privacy Policy is something I was not aware of, and I think puts things in perspective. I have a little more faith in the Pocket decision now. It shows that the move was well thought out and Mozilla wasn't a Read It Later, Inc (Pocket's developer) pushover. Regarding the topic, Dave recognizes the community criticism later in the email.

> But folks raised objections, and we need to address that. Some of the objections were about policy and strategy, and I’m not going to address those in this thread. But we did hear specific complaints about how the code was integrated. Folks said that Pocket should have been a bundled add-on that could have been more easily removed entirely from the browser. We tend to agree with that, and fixing that for Pocket and any future partner integrations is one concrete piece of engineering work we need to get done. Pocket was also given first billing on the main screen, and that may not be a scalable solution. We’re going to need to figure out how to best surface these things in our UI.

I admire this a lot. I just hope that future partnerships are announced well in advanced and the community has time to comment on implementation. I think integrating third party services will be an improvement, but only if executed well. Open-minded ideas like this certainly would have avoided problems like Microsoft's negligence of IE during the previous decade.

> "I didn't contest what he said, as I didn't want to get argumentative with a guy with a shotgun," Joe said. "So I went back to my place [and] inspected it."

The person in the article did mention arguing on site was a bad idea. I think he was right to stand up for his property rights through email later when he was in his house and significantly more safe in comparison. History has taught us that appeasing an aggressor is generally a bad idea for the long term.

The "Mozilla Manifesto and Pocket" email thread in the Firefox Dev mailing list gives some insight from the developers. [1]

To paraphrase: it seems they wanted a reading list feature but found it pointless to re-implement an existing solution with many desired features. (Work which was started but appears to have been scrapped.) This rationalized piggy-backing on Pocket. It gives Firefox a reading list for its users without Mozilla having to maintain it.

My personal problem with this has more to do with the anti-competitive nature of integrating services rather than Pocket's closed source.

[1] https://groups.google.com/forum/#!topic/firefox-dev/B3jJq_kU...

It was brought up in the Firefox Dev mailing list: https://groups.google.com/forum/#!topic/firefox-dev/B3jJq_kU...

I do agree that the discussion should have been in the Mozilla Governance mailing list though.

From what I understand of Superfish, Mozilla (and other browser vendors) can't just blacklist the certificate. That would make all HTTPS connections error out. A message notifying users of the issue is all they can do.