notriddle

There’s no technical reason why this has to be hard. If jira was at jira.atlassian.com and bitbucket was bitbucket.atlassian.com, they would have the same origin, plus they would make the relationship between them visible to any moderately savvy user. It’s only complicated because they allow their marketing dept to make it complicated.

> It only works with a low population.

That’s the point. Killing lots of people lowers the population, but it doesn’t stay low. Over time, the population will always approach the carrying capacity, so the only way to permanently lower the population is to make the carrying capacity lower.

> How about intelligently designing applications that you yourself want to use?

The people who use the apps I make aren't always me. Many of them are very good at things that I know nothing about, but I usually know more about computers than they do. Sometimes the differences are even harder to account for, having different preferences, different ways of thinking, and participating in different cultures.

I remember when I wrote a pretty harsh rant about a wget GUI [1]. This thing is much, much better.

[1]: https://news.ycombinator.com/item?id=30797575

Just for fun, here's a list of things IMHO this one does right, and the wget one does wrong:

* They actually have an option for specifying where the output data goes, and it's right at the top.

* "Open..." buttons. OpenSSL doesn't ask you to type local filesystem paths directly into the thing.

* There don't seem to be any sentinel values in here. Every optional config option has a checkbox or radio button to turn it on, instead of some magic like setting it to -1.

* The spacing is a lot better. I don't see any places where the connection between checkboxes and their text entry fields is ambiguous, if you're willing to assume left-to-right, top-to-bottom associativity.

And here's a few things it still does wrong:

* Text boxes that won't get used should be grayed out.

* The text output and display options make no sense at this stage. Instead, allow the user to configure what they see after running. Output everything, and use various kinds of disclosure widgets to to filter the output.

* Multiple rows of tabs are bad [2]. These should be separate apps, like how LibreOffice Writer and Impress use the same backend but have separate start menu entries.

[2]: https://www.nngroup.com/articles/tabs-used-right/

The question isn't really whether people use extensions. Obviously they use and enjoy them when they're there.

The question I'm asking is how Firefox manage to take 25% of Microsoft's market share, but Ubuntu didn't? Ubuntu has always been much more customizable than Windows, just like Firefox was much more customizable than IE. LibreOffice allows you to continue using the "classic" UI, just like how everyone on HN complains that Microsoft's Ribbon was a mistake, yet somehow LibreOffice remains at a partly 200 million to Microsoft Office's 1.2 billion. Why were customizable libpurple IM clients never as popular as the official ones?

This is why I think Firebug breaking the compatibility/market-share death spiral and inducing developers to make their webapps work in Firefox irrespective of Firefox's market share is so important. It's the biggest factor I know of that's actually different between Firefox's situation and the situation with so many other FOSS products.

> Are you saying that these large instances would refuse to interoperate with each other?

Likely. It's the same thing that happened to the big XMPP instances.

There are other ways that open systems turn closed. I'm not sure which one would happen to the Fediverse, but given how often it has happened, and the variety of proximate causes and exact end-states, I'm betting my money on the Fediverse turning closed somehow.

* The XMPP path where the biggest instances just decide they aren't going to federate with anyone else any more.

* The SMTP path where the big instances gradually accumulate anti-abuse mechanisms that make the barrier to entry too high for anyone who requires reliable delivery and isn't one of them.

* The IRC path where the network fractures into centrally-controlled coalitions that federate with each other but not with anyone outside the coalition.

* The NNTP path where the cost of running a server kept going up, the number of servers kept going down, and now if you want access to the entire network, you have to pay a subscription fee to one of three companies.

* The Git path where a single instance bundles value-adds that lead to most users just using the one central service.

There is only one extension that ever really mattered: Firebug.

A lot of developers wound up using Firefox to develop web apps even when the web app was intended to be used in IE. That's important because it broke the vicious cycle where nobody used Firefox because nobody developed for Firefox and nobody developed for Firefox because nobody used it.

You might use other extensions, as do I, but this is such a deal-breaker that barely anything else matters. The browser that runs your dev tools will be able to run your app, obviously, so being the browser with the good dev tools is a tactic to make sure web pages will actually run in it.

The constant rhetoric around extensions is an irrelevant sideshow. It's the web pages that actually matter. Nobody would have bothered to use Firefox unless the majority of web pages they use work in it, and Firebug is the primary reason why so many web pages did work in it, along with Google strategically choosing to support Firefox as a way to hedge their bets against Microsoft making adversarial changes to IE to cut Google off.

> Familiarity, inertia and monopolistic competition

Also compatibility, marketing, and being installed out of the box.

In its heyday, Firefox had between 25% and 50% market share, depending on country. Compared to Internet Explorer 6, it was:

* More stable.

* Less buggy.

* More secure.

* More featureful.

* Usually faster than IE6, though it took a bit longer to start.

* Better development tools, which indirectly lead to web pages working better in Firefox than in IE6 even if that's not what management wanted.

* ActiveX, which is clearly the way Microsoft wanted you to make "web apps," had to be hidden behind scare prompts, so public web pages couldn't use it.

Here's Internet Explorer's big selling points, which allowed it to hold onto between 50 and 75% of the market share:

* It shipped with Windows.

Google Chrome only managed to unseat it by paying OEMs, which means that, de facto, Chrome now ships out of the box with Windows, too.

> Back in the day in Haskell I dreamed of a system where you could type out a type signature and a fully tested rated implementation would be imported from an "open source" service.

The type signature of GPT-3 is `string -> string`

Use I2P for that.

It's almost certainly true that the closer you got to the ancestral environment, the more fulfilling people's lives would be. That's hunter-gatherer society, not serf farming. In the grand scheme of things, brick laying and lumber are still pretty modern. The hypothesis is that, in the ancestral environment, your instincts would actually be working in your favor, so good things would actually feel good, and bad things would feel bad.

Of course, the logistics of undoing the neolithic revolution are mind-boggling. You're supposed to learn to be a hunter-gatherer over a lifetime, not to be thrust into it in the middle of your adult life. If some leader-type tried to abandon complex society right away, it would probably go about as well as the Cultural Revolution went. Lots of people accidentally picking the wrong mushrooms and killing themselves, because their parents never taught them how to tell them apart.

Report this at https://webcompat.com/

Mozilla can add a special case to make Firefox lie about its UA by default.

If "information is a measure of surprise", then you don't want every prediction to be wrong. You want every prediction to have a 50% chance of being wrong. Half of your experiments should be failures.

Does Portal really count as “non-violent”? You commit murder at least once.

Whether they’re malicious or not, I don’t want to send them the session cookie for an unrelated website.

> I've never seen a cert error in the wild that wasn't an expiration of a valid cert or a misconfiguration.

I have. Usually caused by a captive portal.

> The boogeyman of MITM attacks which PKI certs protect from is used to justify a lot of terrible changes to the web that aren't reflected by reality.

The move to use HTTPS everywhere was started in response to packet sniffing tools like Firesheep. That’s not a boogeyman; it’s a proof of concept that works in realistic scenarios.

> Why MITM Amazon when people will happily treat an order email sent from a Gmail account as legitimate?

So what? How about solving both problems?

Use UnsafeCell if that’s your problem.

How is this even a question?

If you want E2E encryption, you sacrifice good full-text search, because you have to build the index on a computer that has access to the plaintext, which means doing it on an endpoint. It’s not as nice as doing it on the server.

If you want to hide metadata, the state of the art is onion routing, and that adds a lot of latency. The only other way that’s even been attempted is Enclave computing, which basically just moves the trust from the service operator to the enclave vendor. Enclave computing is better than nothing, but it belongs in a defense-in-depth approach, not a privacy strategy in itself.

And if you want to avoid fingerprinting, you lose responsive design. Those two things are just directly in conflict here.

The problem with this line of reasoning is:

* I cannot, in good conscience, say that image support was a mistake. There is too much valuable work that cannot be expressed well in text and needs to be graphical. Ditto sound and video.

* Once you’ve added images, you need rich text. If it’s not there, people who insist on doing it anyway will fake it using pictures of text, which is simpler than proper rich text support, but also a lot worse because it doesn’t work with TTS, cannot be indexed for search, and doesn’t work with the clipboard.

The “pictures of text” problem is not just professional designers justifying their paychecks. They’re all over the place on Twitter and Facebook, because of the poor text formatting options they provide.

If you want to include shrinkflation, it’s going to wind up involving a lot of data entry.

There is no such thing as ethical production under capitalism.

What can be asserted without proof can be denied without proof.

This is a strawman. Nobody wants to eat pesticides.

"Common sense" was that you don't eat the poison. You remove it from the food first. You also remove any soil on the food, and if the food is sold in a box or can, you don't eat that, either.

The thing I want to learn, because I'm more interested in learning than I am in reveling in how right I am, is whether common agricultural poisons can be rinsed off with a bit of tap water, or if they're too sticky or too easily absorbed for that to be sufficient. Apparently they can't be washed off this easily, which is annoying, because I rather like buying my apples without worms in them.

> In the meta it's listed as the author name.

If I was designing a search engine, I wouldn't use keywords in meta tags for ranking. It's too vulnerable to keyword stuffing attacks.

There is no way you can expect a non-technical user to understand the full implications of a prompt like that.

Tell LibreOffice to save the file as Flat XML.

> I can’t see how Apple can make a net profit on the repair itself at $69 for modern phones, so the profit motive/outcome must come from tilting people towards replacing a phone with a trade-in credit.

Apple could probably sell the devices at a loss and still make money overall on App Store commissions.

Exactly what time period in what part of the world are you thinking of? If you go back too far, you'll hit a time when places of worship were the government, or at least so entangled in it as to make no difference. If you don't go back far enough, you'll hit a time when work houses and sanitariums were commonplace, which might be inhumane by modern standards, but definitely count as "government programs to help the poor."

> The only way to properly close a file is to use regular old explicit control flow with if statements. Then you can handle the errors in the normal way.

Other than crashing the program, what could you possibly do?

This is what portable software has to work with [1]:

       If close() is interrupted by a signal that is to be caught, it shall return -1 with errno set to [EINTR] and the state of fildes is unspecified. If an I/O error occurred while reading from or writing to the file system during close(), it may return -1 with errno set to [EIO]; if this error is returned, the state of fildes is unspecified.

And it's not just the standard being dumb. Here's what Linux's manual page says about it [2]:

       Retrying the close() after a failure return is the wrong thing to
       do, since this may cause a reused file descriptor from another
       thread to be closed.  This can occur because the Linux kernel
       always releases the file descriptor early in the close operation,
       freeing it for reuse; the steps that may return an error, such as
       flushing data to the filesystem or device, occur only later in
       the close operation.

       Many other implementations similarly always close the file
       descriptor (except in the case of EBADF, meaning that the file
       descriptor was invalid) even if they subsequently report an error
       on return from close().  POSIX.1 is currently silent on this
       point, but there are plans to mandate this behavior in the next
       major release of the standard.

       A careful programmer who wants to know about I/O errors may
       precede close() with a call to fsync(2).

       The EINTR error is a somewhat special case.  Regarding the EINTR
       error, POSIX.1-2008 says:

              If close() is interrupted by a signal that is to be
              caught, it shall return -1 with errno set to EINTR and the
              state of fildes is unspecified.

       This permits the behavior that occurs on Linux and many other
       implementations, where, as with other errors that may be reported
       by close(), the file descriptor is guaranteed to be closed.
       However, it also permits another possibility: that the
       implementation returns an EINTR error and keeps the file
       descriptor open.  (According to its documentation, HP-UX's
       close() does this.)  The caller must then once more use close()
       to close the file descriptor, to avoid file descriptor leaks.
       This divergence in implementation behaviors provides a difficult
       hurdle for portable applications, since on many implementations,
       close() must not be called again after an EINTR error, and on at
       least one, close() must be called again.

And, just to finish it off, Windows is completely silent on this matter. It mentions EBADF, and that's it [3]. The CloseHandle() function, which POSIX close() (a.k.a. _close()) uses under the hood, also doesn't seem to say anything about whether CloseHandle() failing on a file leaves the handle opened, closed, or in limbo.

And since all of these documentations reserve the right to not actually flush the file when it's closed, any warnings or errors are going to be "best-effort" anyway. If you really want to make sure the file actually gets written, call fsync().

[1]: https://pubs.opengroup.org/onlinepubs/9699919799/functions/c...

[2]: https://www.man7.org/linux/man-pages/man2/close.2.html

[3]: https://docs.microsoft.com/en-us/cpp/c-runtime-library/refer...