A cyclist pedaling up a mountain isn't a "collaboration" between a bicycle and a human. This is the same. You don't see feral bicycles roaming the land. All models are ultimately built and run by humans, with human-provided instructions. And as with any program, it's garbage in, garbage out.
More apt analogy here: a cyclist pushing a bicycle down the mountain and seeing it somehow get down the whole track without falling down, is not a collaboration between a bicycle and a human. The human was not involved beyond giving the initial push.
Cyclist still chooses the time, mountain and direction the bicycle gets pushed in. Bicycles have no agency and only go down because gravity. Bicycle will not "discover" tree or wall, any outcome solely the result of cyclist's decisions even if thrown bicycles don't have generally deterministic paths. Don't anthropomorphize the bicycle.
If I told you to pick an encrypted message from the web site and decrypt it, and you went and did it with no further input from me, would you okay with me calling it a collaboration to decrypt the message?
Probably not, but then again I have an ego, and I have other things going on in my life than decrypting random stuff for someone else's enjoyment. Both of which aren't true for an agent/LLM.
It's a machine - when we attribute it human concepts such as victory, mistakes, ethics, we also shift responsibility away from the operator and soon enough bad people will use it as an umbrella. The agent ate my homework! The agent bombed a school! Bad agent, no!
The bicycle -- a simple method of transport powered entirely by humans -- used analogically to prove a point about [clears throat] automation.
I think this sounds somewhat less silly in English because "automotive" and "automative" don't have the same hyper-visible affinity, but all the same; you may want to consider the car as a more viable analogand.
If you want to stick with hardware, Behringer have a few cheap, fun and effective semimodulars (standalone, no need for rack) like the Neutron and K2. Best Bang for the buck.
Ah, asking the real questions. The speed of a closed ecosystem CPUs such as Apple's is irrelevant. As long as Linux or BSD doesnt't run on it in a stable fashion, I'm not interested.
It's not even that Linux is that great. But Windows and MacOS user experience have degraded so much in the last decade due to user hostile decisions and lack of vision, they essentially nullify advances made on the hardware side.
POWER should be the real competitor. If only it had laptop class implementations...
I genuinely think that GNOME is more user-friendly than macOS by a wide margin.
The majority of computer users today are familiar with either Windows or iOS/Android primarily. They're not coming from UNIX CDE machines or Macs on-average, they want a desktop that behaves like their phone does and reinforces/rewards their intuition from Windows. They want to click (X) on a window to confidently close it, they want to mash the Start key to search for an app, they want to tap "Install" on a storefront instead of dragging a DMG icon into ~/Applications. All of the little idiosyncrasies that macOS clings to doesn't help people learn it.
It's more efficient to use all the cores briefly and go back to whatever background task than have long running mixed load. This also matches performance expectations, you generally want the web page displayed _now_ and the compile to finish ASAP while accepting it will take _some_ time.
IMO compile-time annotation processors such as Lombok and MapStruct are far from the most magic part of Java. They're straightforward code generators. Their impacts is localized to where they get applied and you can actually see the code that's generated. They're very good for diminishing boilerplate. They're no worse than Rust's very standard #[derive(xyz)] proc macros.
Having the code being generated on the fly (instead of a one-shot) means it follows the rest of the structure it's derived from i.e. equals() and hashCode() don't risk to be forgotten when adding a field to a class (hello maddening Map<> lookup errors)
Also, yes, Lombok is _funky_ in how it works but there are "pure" alternatives like AutoBuilder and AutoValue if one cares.
Dynamic runtime agents are deprecated functionality. In a few releases agents have to be specified at JVM startup. Mockito (I bet it's the most common user of that feature) and current JVMs already warn about it.
Another issue with Lombok is that it requires IDEs and other tools to be aware of it. Missing integration with other annotation processors only causes "definition of external element not found"-style errors.
Because 'manuscript' means hand-written. LLMs think if they write it enough times, it'll become true. Then they'll grow hands and then not only will RAM be in short supply but keyboards too.
I get the sentiment. But for the record, O&O has been around for a long time, they were known for their excellent defragmentation tool, which isn't so much required nowadays. Their business model was never close to Adware (to my knowledge).
ShutUp has also been around for a while and always seemed to me like a O&O side project by someone who got really pissed at Windows taking the spyware tangent. The distribution model is still that of shareware / freeware (no source), because that's what O&O does. But as far as closed software goes, that's _probably_ as clean as it gets.
Windows has had built in defrag since at least WinXP. I can't remember if Win2000 had it - I think it did. It runs in the background and you don't have to worry about it. 3rd party defrag tools are snake oil, like registry cleaners and so on.
IIRC W2K didn't have one. Defragmentation can use different strategies which may impact the time it takes and additional perf gains if the right files are next to each other. The builtin defrag tool doesn't give any option. So "snake oil" I'm not so sure.
Also, a watching a proper defragmenter run was an OCD soothing experience before we had stray kitten and powerwashing videos galore. I know I'm not alone with this experience.
I know for sure NT4 didn't have defragging built in, because I was a Windows server admin back in the primordial soup that was sysadmin'ing in the 90's.
>OCD soothing experience
I've always felt it was a certain kind of person who found amusement in watching a defragger work. I'm absolutely sure that 3rd party tools made sure to incorporate the equivalent blinkenlights to give the impression that their tool did something useful.
I'm pretty sure some versions of DOS had a defrag tool, or at least windows 9x had a DOS mode equivalent where you could see the block map getting moved around.
Nothing would have prevented building a nice, lightweight system in Java in 2007 had one thrown away the conventions that had infested it at that point.
Java's problem never was the language which has been as serviceable as any other since the JDK1.4 days. It is straightforward to compile (no metaprogramming, type erased generics), linking is delayed to runtime and dependencies are all precompiled to bytecode which _should_ make for very fast builds.
The problems came from the multitude of Internet-bubble era tool vendors which overcomplicated everything in order to sell high priced "corporate-level" solutions and imposed that certain coding style. Java is still known for this today because it appears in so many vintage codebases and is still being applied by coders who never revised their practices from 22 years ago.
My theory is that Rob Pike was jealous of Java because it has succeeded with a model similar to his own Inferno (bytecode, C syntax) and this aligned with Google's ask of developing something that would be outside of Sun's lawyers reach.
Java and the JVM does show its age specifically in one era, and that is its OO-dogmatism which it inherited from the 1990s OO wave (i-was-there-gandalf.gif). Even the opcode set in the VM reflects this everything-an-object mentality.
While it's been made to work, the JVM itself isn't the greatest VM for hosting other non-Java-shaped languages because of this.
When the Java people showed up to Python, they brought a bunch of that FrameworkFactoryItis with them, it was looking pretty bleak for a couple years. The culture that springs up around a language is as important as the language itself, even more so. It spreads to the libraries, and in turn the applications.
reply