| then they went back and said no, you need to remove those safeguards to which Anthropic is (rightly so) saying no.
So one thing to call out here is that the assumption that DoW is working on specifically these use cases is not bullet proof. They simply may not want to share with anthropic exactly what they are working on for natsec issues. /we can't tell you/ could violate the terms.
It is also dumb that DoW accepted these terms in the first place.
What a failure as a species that parents are not trusted or believed to be capable of raising their children. Therefore let's build out the panopticon.
The actions of the government should always be publicly observable. This is what keeps it accountable. The fear that a person might be unfairly treated due to a long past indiscretion does not outweigh the public's right to observe and hold the government to account.
Alternatively consider that you are assuming the worst behavior of the public and the best behavior of the government if you support this and it should be obvious the dangerous position this creates.
The only logical end of this is that they should ban 3d printers and cnc mills to unlicensed individuals. Which, is probably the goal. Things like 3d printers, drones, GPUs, general purpose computers, vpns, encryption, talking to people in private and the like are far too dangerous for the citizenry to be allowed to do without appropriate oversight and approval.
> To prohibit a great people, however, from making all that they can of every part of their own produce, or from employing their stock and industry in the way that they judge most advantageous to themselves, is a manifest violation of the most sacred rights of mankind.
Your argument based on false equivalence bias might work with in a megachurch but not here.
Amazon dropping Parler, a shitty US-based right wing social network nobody outside the US ever heard of, is totally on the same level as US waging economic warfare against Europe and laying claim on sovereign countries like Canada and Greenland. /s
You're projecting a lot, are you by chance attending the same megachurch? Or is it called gigachurch now? Do they also offer drive-in to grab a coffee and soda before service?
There's a docuseries about the US called "The Righteous Gemstones" - I can highly recommend it.
Your HN submission was flagged for being anti-Ukraine propaganda.
I fully understand why you whine about Parler but you are not a credible actor by any means. There is no reason to take any of your bad faith arguments serious.
Id agree if it were a VP of Eng (total mess) or Product (should know and be bought in on the dev process) but this is a VP of sales. Depending on the company they can be much more operational and I would just assume that they asked the individual due to familiarity or happenstance and didn't understand the level of effort to deliver.
Quickly understanding the urgency/importance of the ask while communicating the impact it is having on the deliverable is the right call. Good business people work like this all the time. Seeing the discussion is a good learning opportunity for a junior.
| My personal take is that folks involved with the change severely underestimated the societal impact that it had. The fact that proper build support is non-existent to this day shows that agents are not a priority. That's okay if it isn't a priority, but when it was communicated with Mockito I perceived it as "Mockito is holding the JVM ecosystem back by using dynamic attachment, please switch immediately and figure it out on your own".
Id like to hear the platform team's perspective on this. As it stands, it is a pretty sad state of affairs that such a prominent library in the ecosystem was made out to be the scapegoat for the adoption of a platform change. It is not a healthy thing to treat the library maintainer community like this.
The JDK team has advertised these changes for years. People who want to do wild & crazy dynamic stuff in their testing infrastructure still can, with a tiny amount of added setup. This is the correct tradeoff, vs having the JVM pessimistically unable to apply all sorts of optimizations because they never know when their users might have inadvertently opted into runtime shenanigans.
| Android being Google's .NET, after Google being sued by coming up with Google's J++, Android Java dialect.
The Oracle v Google was specifically over copyright infringement concerning the Java APIs used in Android's original implementation (Dalvik/ART), not about creating a "J++" dialect.
Android never ran a JVM on mobile because it cannot be optimized for resource constrained devices a solution like DalvikVM was necessary. If you want to level critiques about creating fragmented dialects of Java I would recommend starting with J2ME. The only nice thing I can say about J2ME is at least it died.
The Android ecosystem was far too mature for Fuchsia/Dart to be successful without a very compelling interop story that was never produced.
As a technology Kotlin met Android's platform and community needs. Advocacy and politicking played a minimal, if any, role.
Nokia and Sony Ericsson were using J2ME perfectly fine, as did Blackberry. I should know ad ex-Nokian.
Kotlin met nothing, it was pushed by Kotlin heads working on Android Studio, telling lies comparing Kotlin to Java 7, instead of Java was already offering at the time.
To this day they never do Kotlin vs Java samples, where modern Java is used, rather the version that bests fits their purpose to sell why Kotlin.
Fragmentation, what a joke, the fragmentation got so bad in Android, that JetPack libraries, previously Android X, exist to work around the fragmentation and lack of OEM updates.
Gosling said it better, regarding Google's "good" intentions
J2ME was an alphabet soup of incompatible implementations stuck somewhere between Java 1.2 and 1.3. Getting code to run across device manufacturers was a huge engineering burden. In fact doing something like JetPack for that world would be technically impossible.
If Sun was offering some technically relevant foundation for the smartphone era, it would have been able to actually have some adoption. They were starting from a leading position (obviously - see blackberry or Nokia), and in the space of 3 to 4 years they completely disappeared.
That ship sailed decades ago. Too much software and middleware expects GET to not have a body and who knows how itll break when you start sending one. Obviously you can do it today and it might work and then randomly break when the code between client and server changes.
Adding a new http method is the only way to support something like this safely. If something in between doesn't know what to do with QUERY it can just respond with a 501.
Fun fact - GET and HEAD are the only required methods one needs to implement to be an http server. It is a pretty low bar :)
So one thing to call out here is that the assumption that DoW is working on specifically these use cases is not bullet proof. They simply may not want to share with anthropic exactly what they are working on for natsec issues. /we can't tell you/ could violate the terms.
It is also dumb that DoW accepted these terms in the first place.
reply