There's been some new features in the past few years. But you're right that the general pace of new features is slow. There's only about 0.8 developers working on the game.
However, if you're the type of person that likes to work on spreadsheets to calculate profit margins and market trends, Prosperous Universe is worth checking out.
But libgit2 exists, right? It may not have 100% feature parity with git, but that's a linkable library that gives you a lot of functionality when working with git repos.
I bet someone shares this link every time you post about bicycles, but since I didn't see anyone share it yet in this thread, I'll take the opportunity to do so:
> But it is just so tiresome that Google never consults their community. There was no advance notice of this change that I could find. Just a bunch of frustrated users in my inbox blaming me for breaking something.
I get it. This unequivocally sucks. It's a clear loss of functionality for a group of people who are educated about the advantages and disadvantages of embedded EXIF data. But I don't honestly think Google could have consulted their community. It's just too big. So when the author says:
> Because Google run an anticompetitive monopoly on their dominant mobile operating system.
I don't think the problem here is that Google is anticompetitive (though that's a problem in other areas). I think it's just too big that they can't possibly consult with any meaningful percentage of their 1 billion customers (or however many Android users are out there). They may also feel it's impossible to educate their users about the benefits and dangers of embedded location information (just thinking about myself personally, I'm certain that I'd struggle to convey they nuances of embedded location data to my parents).
I will note that Google Photos seems to happily let you add images to shared albums with embedded location information. I can't recall if you get any privacy-related warnings or notices.
> It might be true that you'll never fix a given bug, but shouldn't there be a record of the "known defects", or "errata" as some call them?
Yes, fully agreed. But closing a bug doesn't preclude that. A closed bug isn't refutation or denial of a defect. It's just an indication that there is no plan to fix the bug. Not every bug system works like this though. My bug tracker works like this, and I should have more clearly described what a "closed bug" is in my earlier posts.
I used to think that there is no harm in keeping the bug open. I think if you honestly feel that you have the time and resources to go back to the bug and fix it, then by all means keep it open.
But I find that sometimes I can tell from experience that the IR is not actionable and that it will never be fixed. Some examples:
* There's not enough info to reproduce the issue and the user either can't or won't be able to reproduce it themselves. Intermittent bugs generally fall into this category.
* The bug was filed against some version of the software that's no longer in production (think of the cloud context where the backend service has been upgraded to a newer version).
Sometimes the cost to investigate a bug is so high relative to the pain caused that it just closed as a WONTFIX. These sometimes suck the most because they are often legitimate bugs with possible fixes, but they will never be prioritized high enough to get fixed.
Or sometimes the bug is only reproducible using some proprietary data that I don't have access to and so you sometimes have no choice but to ask the bug filer "can you still reproduce this?".
Computer systems are complicated. And real-world systems consisting of multiple computer systems are even more complicated.
I don't work at Apple, so I can't comment on that. But that doesn't always help. There's been plenty of times where I have a full HAR file from the user and I can clearly see that something went wrong, but that doesn't always mean I can reproduce the issue. (I recognize a HAR file doesn't represent the complete state of the world, but it's often one of the best things a backend developer can get)
I recognize that this is annoying from a user perspective, but I do understand it. Not all bugs are easily reproducible (and even if they are 100% reproducible for the user, it's not always so easy for the developers). Also sometimes you make a change to the code that you think might be in a related area, and so sometimes the most "efficient" thing is just to ask the user to re-test.
When I close an old bug that is not actionable, I do feel bad about it. But keeping the bug open when realistically I can't really do anything with it might be worse.
> Generate better visuals with more accurate, legible text directly in the image in multiple languages
Assuming that this new model works as advertised, it's interesting to me that it took this long to get an image generation model that can reliably generate text. Why is text generation in images so hard?
This is obviously just a research project, but I do wonder about the next steps:
* After exploring an learning about a virtual world, can anything at all be transferred to an agent operating in the real world? Or would an agent operating in the real world have to be trained exclusively or partially in the real world?
* These virtual worlds are obviously limited in a lot of important ways (for example, character locomotion in a game is absolutely nothing like how a multi-limbed robot moves). Does there eventually need to be more sophisticated virtual worlds that more closely mirror our real world?
* Google seems clearly interested in generalized agents and AGI, but I'm actually somewhat interested in AI agents in video games too. Many video games have companion NPCs that you can sort of give tasks to, but in almost all cases, the companion NPCs are nearly uncontrollable and very limited in what they can actually do.
> Coupons shall be accepted for eligible foods at the same prices and on the same terms and conditions applicable to cash purchases of the same foods at the same store except that tax shall not be charged on eligible foods purchased with coupons.
Obviously lawyers are going to be involved in interpreting these rules. But as a lay person, I wonder: a store cannot charge a different price to someone who is buying food with a SNAP coupon. But for someone who has SNAP benefits, but isn't using a SNAP coupon to buy food (you know... because the government isn't funding the program), do these rules still apply?
I remember vividly a childhood experience when a car I was in ran over a dog -- it ran towards the side of the car and went under the rear wheels of the car. I'm not sure there's any reaction time (human or otherwise) that would have prevented that from happening.
> just how Apple cannot block their developer tools from being able to transfer apps onto an iPhone.
If I recall correctly (I might be wrong, because this was 10+ years ago), but Apple did exactly this when the iPhone was first released. When the iPhone first came out, Apple released its XCode devtools for free, including an iOS emulator that you could use to test your iPhone app. But you had to pay a $99 USD per year "developer program" free in order to use the devtools to test the app on your physical device.
If Google is also blocking preventing you from loading your own software onto your own phone with adb unless you pay a free, then this would be a very important thing to call out explicitly.
I really enjoy Helix, but I can't install it everywhere, and so I end up going back and forth between Helix and Vim depending on what machine I'm working on. This puts a lot of pressure on my muscle memory -- I often type a vim keybinding while in Helix or a Helix keybinding while in vim.
I'm not an android developer, so I'm missing some context and key information. But I have a question: When Google is asking developers to "register" their apps as part of this new program, are they just trying to keep a mapping from some code signing key to a government ID? Or are they trying to do a code review process that is similar to submitting to an app store?
I know both are objectionable in their own way, but these two scenarios are quite different and I want to understand this better.
Some years ago, "iroh" was supposed to a replacement for ipfs. However since then, they (very smartly, in my opinion) dropped those ambitions and are just focused on being a high-quality library for anyone writing a P2P app (like ipfs).
I often see projects attempting to be a universe tool to solve every possible problem, and I think the iroh folks were smart to scale back and narrow their focus
First paragraph of the "4. Discussion and Conclusion" section
> We speculate that the participant’s fair skin and lack of hair were significant factors that reduced the attenuation of light to feasibly detect a signal. In addition to the participant wherein a signal was observed, the experiment also included trials on seven other subjects. The details of the subject pool are as follows: two females and six males; 25 to 35 years old; 14.5 to 15.5 cm head diameter; Fitzpatrick skin types: 3 type I, 4 type II, and 1 type V; hair types: 1 bald, 4 short and light-colored, and three dense and dark-colored. We did not observe any significant time-correlated signals above background noise for the seven other subjects.