> Browser memories let ChatGPT remember useful details from your web browsing to provide better responses and suggestions, while maintaining privacy and user control. Users can opt-in during setup or in Settings > Personalization > Reference browser memories.
> As you browse in Atlas, web content is summarized on our servers. We apply safety and sensitive data filters that are designed to keep out personally identifiable information (like government IDs, SSNs, bank account numbers, online credentials, account recovery content, and addresses), and private data like medical records and financial information. We block summaries altogether on certain sensitive websites (like adult sites).
So the actual content of every page you visit is sent to ChatGPT servers. That is WAY more invasive than anything Chrome does afaik.
From the article, individual video segments were 2-6 MB in size and SQS and Kinesis have a 1MB limit for individual records so they couldn’t have used either service directly. At least not without breaking their segments into even smaller chunks.
You're right, I didn't pay attention there. Still seems that there a many solutions better suited than S3. Probably a classic case of "We need an MVP fast, let's optimize later".
Modules are weird. In Java world there exists consensus on dependency management via Maven-style repositories (Maven Central is the primary distribution channel) and all tools support it. You handle your dependency tree outside of your code and just import packages from libraries available on classpath. It’s possible to continue doing that that without using modules, so the case for using them is still unclear to many people. Where the actual hate may have come from is an old story with migration from Java 8 to Java 9, where modules hidden the access to certain internal APIs, breaking some libraries which relied on them, making that migration painful. Today their value is probably 0/10, but there’s no reason to hate.
The use case for modules is to have a unit of organizing code (deciding what is visible and accessible to who) at a higher level of abstraction than a package. It allows library authors to be much more explicit about what is the public API of their library.
Ever wrote "List" in Intellij and instead of importing "java.util.List" Intellij prompts you to choose between like twenty different options from all the libraries you have included in your classpath that have implemented a public class named "List"? Most likely 90% of the libraries did not even want to expose their internal "List" class to the world like that but they got leaked into your classpath just because java didn't have a way to limit visibility of classes beyond packages.
Yes, but at what cost? Many libraries can solve visibility problem with package level visibility. And modules cost a lot: dependency management was a non-goal for them, so anyone who wants to use module path instead of classpath, has to declare dependencies twice. It was a big mistake not to integrate modules with a de facto standard of Maven.
> Many libraries can solve visibility problem with package level visibility
The only way of doing this would be to put all classes in the same package. Any nontrivial library would have hundreds of classes. How is that a practical solution?
Well designed non-trivial libraries should be open for extension and thus should not hide most of the implementation details, leaving the risk of too tight coupling to users. E.g. if I‘m not 100% satisfied with some feature of a library, I should be able to create a slightly modified copy of implementation of some class, reusing all internal utilities, without forking it. So no, modules as means to reduce visibility are not as cool as you think. And given the specific example of the list, it’s possible to filter out irrelevant suggestions for auto-complete or auto-import in IDE settings.
So goalpost moved from “libraries can solve visibility problem with package level visibility” to “libraries should not try to solve the visibility problem because it is not even a problem at all”?
No, it has not. If you are software engineer you should understand the difference between what I actually said and what you quote from logical perspective. I said "many libraries", not "all". For majority of use cases package level visibility is sufficient and is more granular. Yes, many libraries have already migrated and include module-info, but they still are fully compatible with classpath and actively use more classic mechanisms for visibility control. How many projects do use modules? I haven't seen a single one yet.
To add to this, modules make it easy for external tools like GraalVM native-image to produce self-contained binaries that are smaller compared to the standard practice of distributing fat binaries (i.e. large JARs).
Directly or indirectly many (or most) projects ended up depending on something which was using an unsupported backdoor API because it provided a marginally useful capability. The module system restricted access to these APIs and everything stopped working, unless you added some magic command line arguments to gain access again.
So for most people, the initial impression of modules is negative, and then they just decided to rule the feature out completely. This has created a sea of useless criticism, and any constructive criticism is hardly observed. Improvements to module configuration (combine it with the classpath), would go a long way towards making modules "just work" without the naysayers getting in the way.
>Directly or indirectly many (or most) projects ended up depending on something which was using an unsupported backdoor API because it provided a marginally useful capability. The module system restricted access to these APIs and everything stopped working, unless you added some magic command line arguments to gain access again.
Is it even theoretically possible for a project like this to not run into these kind of issues? Like literally the project's goal is to enable library authors to be more explicit about their public API. So breaking use cases that use unsupported backdoor APIs very much seems like a predictable and expected result?
Early on there were things you couldn't do without using com.sun.* classes, so people got used to doing that. It's been many years since that was all fixed, though.
I have a company with ~20 developers only. And already I have an ArchUnit test stating that public classes within "com.companyname.module.somepackage.internal" cannot be used anywhere outside "com.companyname.module.somepackage".
Surely almost everyone who has worked in a large enough codebase and thought about large-scale modularity can see the use case for a unit of abstraction in java higher than a package?
Yes, in theory they are good. In practice they cause enormous amounts of pain and work for library maintainers with little benefit to them (often only downsides). So, many libraries don’t support them and they are very hard to adopt incrementally. I tried to convert a library I maintain to be a module and it was weeks of work which I then gave up and reverted. As one library author said to me “JPMS is for the JDK itself, ignore it in user code”.
Given how much of a coach and horses modules drove through backwards compatibility it also kind of gives the lie to the idea that that explains why so many other language features are so poorly designed.
They're fine, but they're incompatible with building fat-jars ro have single file deployment and dead to me because of that.
Spring does some ugly jar-in-jar custom classloader stuff which I hate out of principle because it's spring.
Oracle hates that people build fat-jars and refuses to adress the huge benefit of single file deployables.
What if I told you - you can use a batteries-included framework, and still write your own libraries specifically only for things you want your own version of and want to share across projects?
The problem isn't that I don't know how to use a batteries included framework. The problem is that you guys don't know there is even an option to reuse your code by writing libraries.
Why are you assuming you cannot write your own library and use it with Spring? It's not an either/or, just like most frameworks are. You are framing it as if there is only one way to do it in spring.
Please do not project things like "you guys don't even know..". I'm one of "you guys" , and have built production code in a variety of languages and frameworks. So this "you guys" knows exactly what he/she is talking about.
All this because I told one guy who asked "what exactly is “cronService”? you write in each service or copy/paste each time you need it?" that they can reuse code by writing a library instead of copy/pasting it?
If this is the level of incompetence encouraged by a framework, I would avoid using it just to avoid the chance of hiring people like you.
Just kidding. Spring boot is great. But yeah, I would fire people with this attitude without blinking an eye.
* Why would I write my own database driver or encryption just because I wanted to implement my own "cronService"?*
how do you decide whether you will write your own or pull in a dependency? this is a legit question. you did start this with writing your own “cronService” (which is about as insane as writing your own database driver) so asked about it.
I really did not. I only said that if you were to create your own cronService, you can reuse it by creating your library rather than copy pasting code (which is obviously insane).
> which is about as insane as writing your own database driver
No, it is not. Spring Boot’s support for async jobs and scheduled jobs is lacking. A lot of people roll their own. Including yours truly.
It is also much easier than writing a database driver so there is that.
Compare with the functionality offered by async job systems of other full stack frameworks - eg django with celery and rails with solid-queue. It’s not even close.
I am not saying there aren't more robust scheduling libraries, people still use Quartz a lot in the Java ecosystem - was just wondering what specifically are you up against that you cannot solve with Spring's scheduling?
That's what I thought at first too. At first glance they look equivalent, telling API users what the expected result of a method call is. In that sense, both are equivalent.
But after experimenting a bit with checked exceptions, I realized how neglected exceptions are in Java.
- There's no other way to handle checked exceptions other than try-catch block
- They play very badly with API that use functional interfaces. Many APIs don't provide checked throws variant
- catch block can't use generic / parameterized type, you need to catch Exception or Throwable then operate on it at runtime
After rolling my own Either<L,R>, it felt like a customizable typesafe macro for exception handling. It addresses all the annoyances I had with checked exception handling, and it plays nicely with exhaustive pattern matching using `sealed`.
Granted, it has the drawback that sometimes I have to explicitly spell out types due to local type inference failing to do so. But so far it has been a pleasant experience of handling error gracefully.
I would say one we are allowed to bash upon, forgetting the history of key programming languages with checked exceptions predating Java (CLU, Modula-3 and C++), whereas the other is the cool FP programming concept that everyone coding is coffee shops is supposed to find cool.
Semantically from CS point of view in language semantics and type system modelling, they are equivalent in puporse, as you are very well asking about.
I point it out because I think the distinction is interesting.
Can we build tools that helps us work with the boundary between isosemantic and isomorphic? Like any two things that are isosemantic should be translatable between each other. And so it represents an opportunity to make the things isomorphic.
reply