• 0 Posts
  • 61 Comments
Joined 1 year ago
cake
Cake day: October 21st, 2023

help-circle
  • I think I got the idea. So essentially a new copy of the file is created and stored only if there is a change, else it just refer to the older SHA. Am I right? Now I understand why LFS was needed for binaries, else it createds a lot of storage problems, but not the huge monorepos.

    I’m not a developer, but a design person who covers much more including architecture. But in my org I happen to teach developers how to use Git. Strange, I know. But that is the case. It gave me a good opportunity to learn Git in depth.

    I went through your blogs and patch stack workflow. I have to say that I have not been happy with the branching workflow and I always felt that is not the best (I agree to the point about “unjust popularity”). The patch stack workflow makes more sense to me. Unfortunately we won’t be able to adopt, since getting everyone to Git itself was a huge effort. Also developers are not that keen into creating good code, but just working working code. I’m extremely frustrated with that.

    Also your blog design is really good. I love it. I always wanted to create something like that. But never managed to sit down and do it. Can you give me a brief about the tech stack used for the blog?

    Do you use RNote for diagrams? The style looks familiar. Or is it something else?


  • Aah. I assumed linting was part of the build also. My bad. I did understand the idea you were mentioning. Just that assumptions kind of threw me off.

    I wanted to ask something related to that. As you mentioned, git takes a snapshot of the repo on every commit. So splitting up the bug fix and other activities means you have 3 or 4 commits instead of one. Let us say we are dealing with a very large repo. This does not look ideal in that context right? So do you think the way you proposed is only suitable for smaller repos?


  • So this bit confuses me. The article says in the intent and scope section that the entire process of bug fixing, in the included example, is literal bug fixing, clean up toggle, correct lints, correct duplication. That point to linting issues.

    The earlier section says that a commit should be ‘buildable’ and ‘testable’. So if there are linting issues, the commit won’t satisfy this criteria right?

    What am I missing here?



  • Hey I understood what you meant. The result that you are trying to achieve is very close to the browser caching normally present is what I meant. When you zoom in it will only load that area. And I don’t think you can specify the number of tiles to be a specific number, since the zoom levels are not linear.

    The offline leaflet I shared in the previous comment actually does the same thing you want to achieve. The difference is the offline mode is discarded immediately when the system is back online. So that library could be modified to incorporate the time dependency and users visiting a point again I specified in the last comment, at least in theory.

    Regarding OSM data, there are zip files available for downloading. Geofabrik and openstreetmap.fr are examples. Another tool is Protomaps, where you can download by drawing a polygon. But these are not going to be the ideal solution for a product like Immich.

    By the way I saw your update. Great job on following up and providing a fix for others. I really really appreciate it.


  • If you are asking about vector maps, I am not really sure, because I have no experience with it. So can’t really comment on that. On raster maps, as you already know every tile is a PNG. The behaviour you described is very similar to the client side caching that usually happens in the browser. Depending on the coordinates in the viewport and zoom level the server provides the tiles.

    Usually to save the map most offline map making tools will ask you to draw a rectangle and select the required zoom levels. In an interactive map, the rectangle is the viewport of the device. So there can be a feature which will download and store the tiles around a specific gps location for a fixed geographical area. That should be doable without much issue. But in this case that may not be a good idea.

    If you visualise all zoom levels stacked over each other, the images need to be retrieved when the user zooms into a point the geographical area will not stay the same. Smaller geographical area is only needed with higher zoom levels. If we only take all the tiles that get downloaded in every layer, it may produce a shape similar to an inverted pyramid. So saving the images as a user zooms in for the first time, may be the best idea.

    Then the saved tiles need to be used again when users zoom in the same area. Also these tiles need not be updated frequently and maybe even once in every 3 months might be enough, that too only when the user zooms in again in that area.

    This can be a little tricky as almost all the tools that create offline maps do it for a fixed area and selected zoom levels, every point in that area gets equal priority. But in this case the point is the important element. The area nearby may not be relevant at all. So that is the part that needs some exploration.


  • I read through your comments and the reply from devs regarding OSM. I will add a few points that can be part of the feature request. I have some experience dealing with maps, and my understanding is you can set up an offline version of OSM, which will get updated only when required.

    leaflet.offline is a library which provides a similar functionality. I think with some modifications this can be implemented to significantly reduce the load on OSM that using it directly.

    Even with a very large zoom level say 11 to 15, a large area of maps takes like a few hundred MBs. We once cached the entire region of California with all the details and it was around 240 MB IIRC. But Immich does not need this much details and it is possible to restrict zoom levels to certain details.

    For someone self hosting several hundreds of GBs of photos, this should be doable without using too much storage. I think the problem will be that this is a huge engineering effort. Depending on the priority of the feature it may not be easy to do this.

    There is a site called Switch2OSM which details almost everything you need to know. The previous link is on how to serve map tiles on your own. Again it is a daunting task and not suitable for everyone.

    If anyone needs a live update of OSM as things get added, look into the commercial offerings.

    In conclusion, it is possible to include a highly optimised version of OSM, instead of putting their servers under heavy load. The catch is, it is not easy and will need a huge engineering effort. I think developers should take a call on this.


  • So many people freaked out by privacy scandals, that made it a billion worth business. first with a massive amount of VPN services, some of them even from the same company and giving them different brands, browsers everywhere with same situation , then self hosting which it seems multiple developers are putting the eye on it as some fresh juice . And FUTO eyes specially

    Can you elaborate this a bit more? Are the first few points about Proton, or in general? And I guess in the case of browsers you meant Chromium. Also I’m not really sure about what you meant regarding self hosting.












  • Replacing a human with any form of tech has been a long standing practice. Usually in this scenario the profitability or the efficiency takes a known pattern. Unfortunately what you said is the exact way the market always operated in the past, and will be operating in the future.

    The general pattern is a new tech is invented or a new opportunity is identified, then a bunch of companies get into the market as competing entities. They offer competing prices to customers in an attempt to gain market dominance.

    But the problem starts when low profit drives some companies to a situation where either they have to go bust or dissolve the wing, or sell the company to a competitor. Usually after this point a dominant company will emerge in a market segment. Then the monopolies are created. After this point companies either increase the price or exploit customers to get more money, and thereby start making profits. This has been the exact pattern in tech industries for several decades.

    In the case of AI also, this is why companies are racing to capture market dominance. Early adopters always get a small advantage and help them get prominence in the segment.