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.

There's work in progress to allow this. https://bugzilla.mozilla.org/show_bug.cgi?id=885777

I've done this a few times for bugs that have personally annoyed me. Gotta say, it's easy to get started and the reviewers are amazing.

Small unrelated comment: I love how that menu works. It does a really great job as an alternative for the hamburger menu.

It doesn't. :)

It was actually a personal private computer until I left that area and opened up the password. I overlooked changing 'git config user.email !@#$'.

The opposite issue is also capable of happening. Don't misunderstand, I completely acknowledge the fact that this is a very difficult issue to solve and fundamental to git design.

@davidbanham

May I quote you on that? I think I focused too much on the cool factor and not the problem I was trying to address. (Which you summed perfectly.)

I acknowledged that. It's one of those features that isn't perfect when implemented.

There should be a way to stop these commits from happening under my name without going to the computer physically or rewriting history every time it happens. And that only works if you have access to the repository.

At the same time, you have to acknowledge that Mozilla suffered a huge backlash from its user base when Australis was landed on release. For the exact opposite reason you're describing.

I'm not sure if these events are related, but Firefox developers have been talking about this decision in the mailing list for a while. This doesn't come to me as a surprise.

There is. Mozilla doesn't want data from users (unknowingly) being sent across networks to a server by default.

The urlbar is already capable of searching though. It just doesn't give you suggestions for the reason above.

That's actually a lot less than I thought would be in the iOS filesystem.

It doesn't seem like it'd be incredibly hard to remove those symlinks. Although Apple would probably favor fixing the bugs that allow malicious symlinks rather than remove symlinks from their file system driver (the horror!)

How does reverse engineering binaries like this work? Did geohot really go through the entire disassemble during the time of a plane ride?

I'm confused as to why some people in the community believe a party was "backstabbed". Each team/group operated with its own intentions and goals; there's no reason why there had to be cooperation amongst them.

I feel like the reaction to this is more due to a general mistrust of Chinese software and a worship of MobileSubstrate.

I always miss my bus in the morning. I've had the idea to stuff a remote tracker in one of the bus seats for a while... this makes it possible.

Seeing CSS before HTML freaks me out more than it should.

*HTML & CSS

Where do I sign up? :)