• 8 Posts
  • 726 Comments
Joined 5 年前
cake
Cake day: 2021年1月21日

help-circle

  • /favicon.ico is the only “default” URL. /favicon.ico is usually not an actual “icon” type anymore but PNG or JPG (but with the same URL). Other than that you need to load the HTML and check for Link headers or <link rel=icon> elements. While URLs like /favicon.png may be popular they aren’t part of any actual protocol.


  • Sort of…

    You can just hope that /favicon.ico works. But 1. it often doesn’t and 2. it is often of low quality.

    To find a favicon on a modern site you need to load the HTML and check Link headers and <link rel=icon> elements. However you likely can’t do this client-side for most sites because of CORS. So you need some server (at the very least to strip CORS). That lets you get the URL but 1. you probably don’t want to have connections to external domains for user privacy and 2. some domains will have hot-link protection so you need to fetch the image via your server. You will also want to consider different image formats and sizes to serve the right image to the right client. On top of all of this the site may be using some sort of bot protection which you will have to fight. Google is almost always whitelisted. The site may also have temporary outages so having a cache would be nice, especially if that is almost always populated before you even know the domain exists.

    At the end of the day you do want some sort of API. And while it isn’t complex it isn’t trivial. So it is nice to just let Google handle it. (Other than tracking risks, but you could proxy Google’s API.)


  • While I agree, I think that getting more games on Linux is far more useful. When Linux is almost 3% very few studios will care much. If they can do a small bit of testing on Proton and maybe work around a bug or two they are far more likely to do that then make and test a native build. If this then gets Linux usage to 5, 10 or 20% that will drive more native builds.

    So I agree that it somewhat reduces the incentive to release a native build. But I think that is outweighed by the benefits of making the Linux gaming experience better today which will have a greater impact on availability of native builds in the future.




  • I still recommend it. I’m not fully happy with the situation but for now I consider it my best option.

    1. I consider Chromium-based browsers out of the question as they give too much power to Google. This is already showing to be a problem with new APIs and “features” that Google is pushing into the web platform and the bigger the market share gets the more control they have.
    2. Web browsers are the biggest attack surface that most people have. Displaying untrusted webpages and running untrusted code is incredibly difficult and vulnerabilities are regularly discovered. I don’t yet know a Firefox fork that I trust enough to reliably respond to security vulnerabilities quickly and correctly.

    So for now I am staying with raw Firefox. Not to mention that as a disto-built Firefox I have some insulation from Mozilla’s ToS. But I am very much considering some of the forks, especially the ones that are very light with patches and are mostly configuration tweaks.








  • The most likely situation is that the torrent isn’t good. I would also force a recheck of the torrent to double-check that the files on your disk haven’t been corrupted. But if that file is still saying “0 B” remaining (don’t just look at 100% as it may be rounded) after the recheck then I would bet pretty good money on a broken torrent. If this is a public tracker it is fairly common.

    However even if it is broken you may be able to play by using a different players. Different apps can skip over different forms of corruption, so you may get lucky.



  • The main issue is accepting incoming connections. When you are behind a NAT (as most VPNs are for IPv4) you need some solution (such as port-forwarding) to make your torrent client connectable. This causes a number of issues when torrenting.

    1. When someone starts a download they will try to connect to the seeders. If the seeders are not connectable this will fail.
    2. As a fallback when the seeders notice the leachers they will try to connect to them. If the leacher also isn’t connectable this will also fail.

    If neither party is connectable the download can’t happen, so you may fail to get content that you want.

    This is extra relevant if you are on private trackers where seeding is tracked, has direct value and is competitive. If you are not connectable every new downloader will immediately connect to the connectable seeders and finish the download before your client even knows that they exist. (reannounces for seeders can be very infrequent, such as hourly, so it will take an average of 30min for you to notice a new seeder and try to connect to them). This makes it very difficult to acquire much upload unless there are very few other seeders.

    NAT is evil, all hail IPv6.