You complain so much to the point that nationalism is becoming prevalent but when someone tries to force you to be independent you complain every way possible to not be independent? But then when you are dependent you complain about not being equivalent.
I do think that between luddite or "ai pilled" ai usage should be much more in favor of "ai pilled".
However, this isn't a plug to be using AI for coding everything, but a more general plug that AI should be integrated to a lot more things outside of the mainstay of chatbots.
There is a lot of merit to using AI to establish a new abstraction layer.
To me this is a major problem of everyone saying security through obscurity is bad. But then those same people reinforcing encryption as a gospel of security.
As far as I know, there are no secrets in the world. Encryption is not providing security to anything. It only gives you guarantees wrt to a certain interpretation/perspective.
Modern encryption is underpinned by, no common folk (not no one or even the people who would have the ability to which are probably the ones that should be worried about) should be able to decrypt your contents _within your lifetime_ - which in and of itself is a pragmatic goal, but does not ensure secrets remain secrets.
If I open source something, I am not your parent, if you decide to wing it just because it is open source that is your problem not mine.
You are not obligated to use anything anyone open sources. If you can't take responsibility for your own actions that's on you, not the person who open sourced it - that is what generally all the licenses state to begin with.
Craft is caring about the x in y = mx + b, while the so called "it's a means to an end" care about the y.
The difference between "craft lovers" and "doers" is that one operates at a better fitting abstraction (that is more aligned to the values of capitalism).
You can say "doers" are just "craft lovers" in and of itself - there is little distinction between them - this is just reiterating the change from binary to high level languages.
I've tried nearly all the models, they all work best if and only if you will never handle the code ever again. They suck if you have a solution and want them to implement that solution.
I've tried explaining the implementation word and word and it still prefers to create a whole new implementation reimplementing some parts instead of just doing what I tell it to. The only time it works is if I actually give it the code but at that point there's no reason to use it.
There's nothing wrong with this approach if it actually had guarantees, but current models are an extremely bad fit for it.
There are multiple layers and implicit perspectives that I think most are purposefully omitting as a play for engagement or something else.
The reason why LLMs are still restricted to higher level programming languages is because there are no guarantees of correctness - any guarantee needs to be provided by a human - and it is already difficult for humans to review other human's code.
If there comes a time where LLMs can generate code - whether some term slop or not - that has a guarantee of correctness - it is indeed probably a correct move to probably have a more token-efficient language, or at least a different abstraction compared to the programming abstractions of humans.
Personally, I think in the coming years there will be a subset of programming that LLMs can probably perform while providing a guarantee of correctness - likely using other tools, such as Lean.
I believe this capability can be stated as - LLMs should be able to obfuscate any program code - which is pretty decent guarantee.
I think you are expecting some kind of collaborative OSS type of library.
For LLMs to have replaced Tailwind - in part by using it themselves - this does not have mean that there _will_ be another library to reuse. In the context of LLMs, it becomes so "cheap" to customize the webpage that a library is no longer needed.
Tailwind in and of itself can be considered a "highly structured LLM" - if they so took it that far.
Bose's brand is built on audio quality. There is close to little negative impact open sourcing the API (server) in this case will bring to their brand.
For a game, open sourcing the server generally means anyone can basically mess it up and with the internet make it available to everyone to see. Then the responsibility is on the developer to protect their "brand".
The plethora of WoW private servers is not a good example. These are from individuals, or groups of people who willfully reverse engineered it on their own. This is different from a company expressly permissing and implicitly giving a grant on allowing a similar product to exist - the difference is that one gives credibility, which the other does not.
“Nothing to Hide” is more akin to a fundamental truth than a deviancy.
If you wish to hide something, why have you leaked it in the first place?
Why not ask the other question? Why are you trying to hide public information to begin with? Why are you introducing encryption on top of an underlying public interface.
This is intentionally different from are there things one would generally not be to be widely accessible or generally public.
There is nothing to hide if it is already public, because it is already public, you can't hide it even if you want to, you're only making it more difficult for a general member of the public to access that data. Even if you consider that "hiding", the source is still public.
"Open Source has a specific definition and this license does not conform to that definition."
To be fair, this wouldn't be an issue if Open Source stuck with "Debian Free Software". If you really want to call it a bait and switch, open source did it first.
There are bleeding edge issues, everyone dials into transformers so that's generally pain proof.
I haven't exactly bisected the issue but I'm pretty sure convolutions are broken on sm_121 after a certain size, getting 20x memory blowup from a convolution from a 2x batch size increase _only_ on the DGX Spark.
I haven't had any problems with inference, but I also don't use the transformers library that much.
llama.cpp was working for openai-oss last time I checked and on release, not sure if something broke along the way.
I don't exactly know if memory fragmentation is something fixable on the driver side - this might just be the problem with kernel's policy and GPL, it prevents them from automatically interfering with the memory subsystem to the granularity they'd like - see zfs and their page table antics - or so my thoughts on it is.
If you've done stuff on WSL, you have similar issues and you can fix it by running a service that normally compacts and clean memory, I have it run every hour. Note that this does impact at the very least CPU performance and memory allocation speeds, but I have not have any issue with long training runs with it (24hr+, assuming that is the issue, I have never tried without it and put that service in place since getting it due to my experience on WSL).
It'll be either "cheap" like the DGX Spark (with crap memory bandwidth) or overpriced with the bus width of a M4 Max with the rhetoric of Intel's 50% margin.
For this form factor it will be likely ~2 years for the next one based on Vera CPU and whatever GPU. The 50W CPU will probably improve power efficiency.
If SOCAMM2 is used it will still probably be at most near the range of 512/768 GB/s bandwidth, unless LPDDR6X / LPDDR7X or SOCAMM2 is that much better, SOCAMM on the DGX Station is just 384 GB/s w/ LPDDR5X.
Form factor will be neutered for the near future, but will probably retain the highest compute for the form factor.
The only way there will be a difference is if Intel or AMD pump their foot on the gas, which this makes maybe 2/3 years of it, with another 2 years unless they have something cooking it isn't going to happen.
You complain so much to the point that nationalism is becoming prevalent but when someone tries to force you to be independent you complain every way possible to not be independent? But then when you are dependent you complain about not being equivalent.
It doesn't work both ways.