serentty

It worked ridiculously well before I posted it to Hacker News. ;)

Heh, this has an 80 MB hard drive and it is killing me with how small it is. I’m constantly transferring stuff back and forth.

It isn’t running modern software. It is running MS-DOS 6.22. If it’s not loading for you, you can try the snapshot.

It has gotten pretty busy. In case you can’t manage to load it live from the machine, here is a snapshot of it:

https://archive.ph/WUdgc

It could be that it is genuinely not working, but it could also be that it takes a while to start loading. The server can only serve 8 clients at once, over a bandwidth of about 4 KiB/s. So maybe try again and give it some time to load in another tab.

I am definitely not against the addition of the guesser. It was added a bit before the encoding menu was removed, though, so there was a time when they were both there. I mainly wanted to draw attention to the removal of the menu.

I hugely appreciate this! I will definitely install it.

The thing is that I do not agree with you that the ends justify the means. You seem to think that people seeing fewer pages in the wrong encoding in the long run justifies making the problem worse when it does happen. I do not.

And again, I will reiterate that this does not solve that problem anyway because vast swaths of the web are static content that was put there and never touched again, so no one will fix it. Unless we want everything to live on content farms, it is essential to be able to access content like this. You are viewing the web as something that is actively maintained, similar to a software project. That is true for a certain category of website, such as the one that we are on right now. It is not true for the kind of website which is most likely to have borked text encoding.

> So you wouldn't bother to try to get the webmaster to fix the issue, you would just resolve it on your own, letting everyone else be miserable?

I mean that I would not be able to. Huge swaths of the web are static content that was just put there and then just abandoned. The web will remain this way unless everything is moved onto SPA social networks, and I hope that we agree that that would not a good thing.

> It sounds like you don't care if people are punished, as long as it isn't you.

If the added benefit of causing people more inconvenience is that they push for problems to be fixed, I don’t think it’s fair to cause that inconvenience with the intent of using that to solve the problem. I think it’s a manipulative tactic. That is my idea of what “punishment” we’re talking about. What kind of punishment are you thinking of if you think I’m fine with punishment, and who is getting punished by it?

I also would like to point out in the context of the issue of “legacy” content that not all web content is some sort of single-page application that gets maintained. Of course, we don’t expect software to remain compatible with other software forever, but not all websites should be considered software. Consider a video file, for example. We have the expectation that a video file, which is static content with no scripting, will continue to play forever in future media players, or at least that you will be asked to download some obscure codec pack if it doesn’t play by default. I think that a static website with no scripting and just text is the same. A website with just text should continue to work. I think this is pretty different from something like Flash or ActiveX or even cookies, where we are no longer talking about static content.

“Should” is not “is”. As a user, I run into broken sites regularly enough. I still want to be able to see them. I get the “let’s bury all broken legacy and hacks as quickly as possible” mindset, but when it comes to the issue of the main text of a page being unreadable, I think there is a high bar.

> older sites should fix their sites.

A lot of the reason they are considered “older sites” in the first place is because they are not heavily maintained. The thing to remember about the web is this: not all websites are “software” that is maintained. Some of them are static works similar to a movie, with static content.

> The single-byte Latin scripts are semi legible, so that is enough for me.

Did you see the example that I gave of Polish text? I am sorry, but if you feel like reading multiple paragraphs this way is bearable, then we will just be stuck in disagreement.

He straight-up said that it’s not as much of an issue because it’s still legible because not all of the letters are borked. I don’t see how this is a misrepresentation of what he said.

> Also, removing the encoding override is completely separate from that,

It is not separate at all. If the detector cannot do it, and the ability for the user to do it is removed, these issues are intrinsically linked. Sure, there are the other issues you mentioned around keeping it around, but you can’t act like these issues can be considered separately.

East Asian languages are not the main concern here, actually. It’s the various single-byte Latin script encodings, which are incredibly similar. The issue of these being confused is addressed in the thread itself, where he says that such issues will not be fixed, because they are so confusable that fixing the detection of one means breaking the detection of another.

So you think that making things miserable for the remaining 1% is good because it gets them to care, and therefore for the website to be fixed? I’m sorry, but most of the time when a website has a borked encoding, it is some website where I doubt I would ever get in contact with the webmaster anyway. It’s mostly small websites. But small websites are important to maintaining a healthy web where things are not dominated by a few big players.

But perhaps most importantly, I have never agreed with any mindset of that encourages punishing some subset of users in order to get someone to change their ways, even more so if that isn’t even the users themselves.

> dealing with character encoding and supporting the feature is painful (though the will still deal with it under the hood). Mozilla have limited resources and they (and Firefox users) want the browser to be successful and sustainable, and this means focusing resources on things that will make the browser easier to adopt and less confusing rather than chasing the short-lived gains from appeasing a small and stagnant pool of ‘power users’.

Dealing with character encodings is indeed painful, but they are not dropping support for all of these legacy encodings. If they did, I am sure it would simplify things a lot in terms of maintenance, but they are too widespread in existing content to do that. Firefox will still use a legacy encoding if it detects it. All they are doing is removing the ability to tell Firefox that a website uses a certain encoding. The idea that this option is a maintenance burden is kind of hard for me to believe.

So now you have to rely on hardcoded heuristics based on the website’s domain name instead of just being able to choose. There are so many complicated heuristics to choose this hard-to-predict factor which it still gets wrong often. Removing the user’s control over this seems like a dreadful move.

> This is a feature that is really not often used, whose omission is not fatal, which often requires several tries to get right, and which is increasingly less useful thanks to gradual changes on the Web.

How often do you visit small indie websites in non-English languages? Because in my experience, as soon as you do, this is not a rare occurrence.

I agree that good detection is important and I am glad that he is working on it, but I don’t think that the level of detection which is possible is a good replacement for the menu, based on what he himself has indicated he thinks is possible to achieve in Firefox.

A while back, Firefox removed the ability to override the text encoding of pages. If Firefox gets the encoding wrong, you are screwed. The thing is, according to the developers themselves, detecting various single-byte Latin encodings is very unreliable, and they have indicated that making Firefox detect one encoding more reliably nearly always means introducing failures at detecting another one, so there will be no progress in this area. Despite this, they have seen it fit to remove the encoding menu, because telemetry shows that most users don’t use it, and because when they do, it often takes them multiple tries to guess the correct encoding. Their solution? To replace it with a “guess again” button, completely removing the ability to choose manually. Henri, one of the developers responsible for this change, has argued that as long as both encodings are Latin-script encodings with a common ASCII subset, it is not catastrophic for the user to be stuck with the wrong encoding, because the text is likely “still legible”. To give an example of what he is calling an “acceptable” level of mojibake, consider this text from the Polish Wikipedia, encoded as Latin-2 and decoded as Latin-1.

> Hamidiye turecki kr±¿ownik pancernopok³adowy z pocz±tku XX wieku, wodowany w 1903 roku, zbudowany w brytyjskiej stoczni Armstronga. Wyporno¶æ normalna okrêtu wynosi³a 3904 tony, a d³ugo¶æ siêga³a 112 metrów. Napêd stanowi³y maszyny parowe o mocy 12 000 KM, pozwalaj±ce na osi±ganie maksymalnej prêdko¶ci 22 wêz³y. Artyleria g³ówna sk³ada³a siê z dwóch pojedynczych dzia³ kalibru 152 mm i o¶miu dzia³ kalibru 120 mm. S³u¿y³ w marynarce Imperium Osmañskiego podczas wojen ba³kañskich oraz I wojny ¶wiatowej, a nastêpnie w marynarce Republiki Turcji do 1947 roku.

Personally, I think this change is ridiculous. It has been a few versions already since it was rolled out, but people are still complaining in the issue tracker. I know one Russian guy who has resorted to using an extension which replaces arbitrary strings in order to correct common mojibake sequences in order to deal with the regression in functionality brought about by this change.

If you feel strongly about this like I do, I strongly encourage you to comment in the Bugzilla thread. Yes, the web should be using Unicode these days, but if it isn’t, that is not your fault as a user, and making the experience miserable for the end user is not justifiable.

> RISC-V has a bunch of competing vector instructions.

There is only one standard V extension. Alibaba made a chip with a prerelease version of that V extension which is thus incompatible with the final version, but in practice that just means that the vector unit on that chip is not used because it is incompatible, not that there are now competing standards

Once again, you’re comparing the compressed instructions without telling anyone that that’s what you’re doing, because you are convinced that the compressed instructions will never be performant on a mobile or desktop core. The foundation disagrees, and every manufacturer competing in mobile-class RISC-V chips disagrees. Even if you think that they are wrong, that is the plan they are going forward with. Real world RISC-V chips targeted at the mobile space support the compressed instruction. Even if you think that they are wrong to do so, the support is there. So what you are doing is refusing to compile for the instruction set the chips actually support, instead targeting what you think they should be doing instead, and then declaring that the code density is worse. This is nonsense.

8-wide is the absolute state of the art. Last I checked, AMD’s fastest core was 4-wide, and Intel’s was 6-wide. I only know of Apple doing 8-wide, and not anyone else. So branding this as the minimum necessary for mobile devices when even most desktops do not achieve it is silly.

What's the point of posting this now? Pure UWP is practically dead. Microsoft has made most of the new APIs and GUI features originally meant for UWP available to all Windows programs through WinRT/COM. UWP is simply being absorbed into the wider Windows ecosystem. You only need to deal with the UWP sandbox these days if you're a masochist.

Oh nice, this is my post. Feel free to ask questions. I'm hoping to help make Rust more portable through my adventures.