I have bad news for you if you think non paywalled / non phone# required discord communities are immune to AI scraping, especially as it costs less than hammering traditional websites as the push-on-change event is done for you in real time chat contexts.
Especially as the company archives all those chats (not sure how long) and is small enough that a billion dollar "data sharing" agreement would be a very inticing offer.
If there isn't a significant barrier to access, it's being scraped. And if that barrier is money, it's being scraped but less often.
> Does this commercial company expect volunteers to give them images for free which give their paid subscriptions value?
Yes, to an extent, because it costs money to store and serve data, no matter what kind of data it is or it's associated IP rights/licensing/ownership. Regardless, this isn't requiring people to buy a subscription or otherwise charging anyone to access the data. It's not even preventing unauthenticated users from accessing the data. It's reducing the rate at which that data can be ingested without ID/Auth to reduce the operational expense of making that data freely (as in money) and publicly available. Given the explosion in traffic (demand) and the ability to make those demands thanks to automation and AI relative to the operational expense of supplying it, rate limiting access to free and public data egress is not in and of itself unreasonable. Especially if those that are responsible for that increased OpEx aren't respecting fair use (legally or conceptually) and even potentially abusing the IP rights/licensing of "images [given] for free" to the "Library built on the back of volunteers".
To what extent that's happening, how relevant it is to docker, and how effective/reasonable Docker's response to it are all perfectly reasonable discussions to have. The entitlement is referring to those that explicitly or implicitly expect or demand such a service should be provided for free.
Note: you mentioned you don't use docker. a single docker pull can easily be 100's of MB's (official psql image is ~150MB for example) or even in some cases over a GB worth of network transfer depending on the image. Additionally, there is no restriction by docker/dockerhub that prevents or discourages people from linking to source code or alternative hosts of the data. Furthermore you don't have to do a pull everytime you wish to use an image, and caching/redistributing them within your LAN/Cluster is easy. Should also be mentioned Docker Hub is more than just a publicly accessible storage endpoint for a specific kind of data, and their subscription services provide more that just hosting/serving that data.
Are they doing things the way they're doing it just to get it done, or are they doing it because they feel it's the right way to do things and they want to get it done right?
If the former, then fair question. If the latter, then you answered your own question at the start of that sentence.
> Don’t let that work go to waste.
Which is what would happen if they gave up and wrote it in C if they're goal is not just to get it done, but to get it done right.
Doesn't mean there aren't better/alternative ways to do things. Doesn't mean it's not worth asking if a lang other than rust may be better for certain/all parts of this (And yes, that includes C). But it also doesn't mean their hard work is going to waste just because the work is hard.
General AI on non-objective ("best" is undefined here and for what usecase/priorities?) broadly covered topics like this instance is mostly just a regression to the mean with bias bleed in from other knowledge graphs (eg, trying to use correct grammar/tense (linguistics) in place of endianness(compsci)). As we traverse further into the depths of the dead internet theory, and more AI slop pollutes the internet (and in turn/tandem, poorly curated synthetic datasets), there is some inevitable Ouroboros style reinforcement here too.
So a simple filter in the sense of "omit anything too similar to X" would just omit the mean result within your given deviation. It's effectively asking, "What are some truly insane ways to use PostgreSQL", which is an interesting thought experiment, though if it actually produces useful results then you've basically just written a unit-test (Domain test?) for when AI slop evolves into full on AI jumping the shark.
If you're doing it based on cross-linking (source-citing), you're basically doing Page-Rank for AI.
If you time gate familiarity to posts only up to the NLP/General AI explosion in 2022 or so, well that might still be useful today, but for how long?
If you were to write a "Smart" filter, you're basically just writing the "PostgreSQL Best Practices" article yourself, but writing it for machines instead of humans. And I don't know what to make of that, but frankly I was lead to believe that if nothing else, the robopocalypse would be more interesting than this.
> the goal is to make it "easy" for the users to write correct programs.
I've only ever dabbled in Golang, but isn't the goal of Go ultimately to make it easy for devs to maintain programs with their hyperfocus on non-breaking changes and backwards compatibility (With previous versions)? It's less about being easy/nice to write the first time, but that you don't have to re-write it again and again with each version change, no?
I'm not saying the OP Article is correct, again, not familiar enough with the language to comment on that, but the whole reason I keep wanting to adopt it (just don't have the time) is everyone I know that uses it always sings its praises for the above features. Seems to be the defining point that drives it's adoption, at least among those I interface with.
I'm not sure how making the language more expressive and less prone to errors makes programs more difficult to maintain? I'm not suggesting they keep adding new features and I do think they got that right. Too many languages keep bloating their languages with new features. A small feature set is the right goal, but I just think they picked the wrong feature set. The features are too primitive and put the burden onto their users vs. the lang devs.
There is no inherent correct or not, just opinion. If Go meets your needs, go for it (pun not intended, but still comical lol). I honestly don't think the ideal language exists (and it will look a little different for everyone), but something between Rust and Go with a little bit of OOP would be a sweet spot I think.
> I'm not sure how making the language more expressive and less prone to errors makes programs more difficult to maintain
I never said nor contested that it did. I was questioning what the design philosophy or general appeal of the language was. If what you believe it is/should be differs from the maintainers themselves, then naturally you're going to likely have friction with how it solves problems or implements features in the first place, as you have divergent goals/philosophies. That doesn't make it a poorly designed language, it makes it the wrong tool (for you) for the job.
To abstract the concept: Nails and Screws are both perfectly valid approaches to fastening things in general, but if you expect a hammer to turn screws effectively, you're gonna have a bad time because your approach/philosophies are misaligned, not because the Hammer is poorly designed. That also doesn't mean there isn't merit in the discussion of the pros and cons of nails and screws and when/how to use them, but that's fundamentally a separate (if adjacent, and still valid) discussion.
EDIT: also, just want to clarify, I don't know Golang, so have no skin in the "is it better/worse/correct". I've long been a supporter of "the best tool for the job is the one you know", with perhaps the only exception to that being Brainfuck[0], unless your intended goal is just to fuck with people lol.
That isn't my argument. My argument is that the features chosen are worse on all accounts, and better on either none or almost none, therefore it is poorly designed language.
A few examples:
Multiple return vs. tuple: tuples can regarded as a single entity OR multiple entities
null pointer vs Option type: impossible to have null pointer exceptions
enums vs integers: no need to roll it yourself or have "stringer" code generator
multiple return errors vs result type: prevent accidental use of value when not valid
The list goes on. Go DID do some really nice things on balance: channels, go routines, etc. I think work quite well. I just think starting from a "C mindset" was the wrong foundation in which to build a language at this point in time.
Also, a good example of what you are talking about would be functional vs. imperative programming. THAT is very much in line with your argument, but that isn't what I'm talking about.
That is in fact what I'm trying to get you to understand. You're arguing a different point than what was proposed. What you propose is entirely valid, but is missing the forest for the trees.
Your goals for what a language should be/do and what Golangs Goals for a language should are not equivalent. You admit it yourself in part here:
> I just think starting from a "C mindset" was the wrong foundation in which to build a language at this point in time.
It's why I've entirely bypassed your attempts to discuss the nuance.
You may disagree with the "C mindset" and other design principles, but ignoring the context of why decisions were made is not productive discourse for determining whether something is designed well or not, which again, was your original and very firmly stated assertion up top.
There is more to a language than it's abstractions and syntax/syntactical sugar and paradigm. Learning curve, intuitiveness, familiarity, conventions, devex (creating and maintaining) and usecase and who is intended/expected to use it are all important as well, and inform why certain decisions are made.
In other words, Thinking people need to move on from the C mindset is an entirely valid argument to make. It has no bearing on whether C or C-inspired languages are designed well, as it entirely ignores what those designs were intended to achieve and who they were trying to cater to.
TL;DR: How well something caters to your goals isn't the same discussion of how well it's designed to cater to someone elses/it's own stated goals. So yes, you feel it's badly designed because you refuse to acknowledge it's not trying to cater you, and that it has no duty to.
You can change the behavior of your layer activation key(s) so that you aren't n+1ing your buckies, and can also customize the keymap of all layers (including the baselayer) so that you don't have Ctrl and A sharing the same physical key between layers to avoid that exact issue. Though, if you do choose to do that, there is still a way to send Ctrl-A (using one shot keys [2] for example). I've listed a few options you have for your layer activiation key behavior from the qmk wiki [0] as it's more succinct than the zmk wiki [1], but QMK and ZMK (which the Ergo S-1 uses) both share similar functionality in this way. Non exhaustive list of layer-activation behavior from the QMK wiki:
> MO(layer) - momentarily activates layer. As soon as you let go of the key, the layer is deactivated.
> TG(layer) - toggles layer, activating it if it's inactive and vice versa
> TT(layer) - Layer Tap-Toggle. If you hold the key down, layer is activated, and then is de-activated when you let go (like MO). If you repeatedly tap it, the layer will be toggled on or off
You can also use Macros if you'd prefer (but not required) to handle triple (or more) buckies, which both ZMK and QMK firmwares support.
I will note that this Ergo S-1 seems to be missing at least 8 keys that most other Ergodox keyboards have (the 3 keys of the inner column on each side and the bottom right and left corner keys) so total physical keycount appears to be closer to a 60% kb. So in that way, you're going to be more dependent on using layers (or Macros) in general than even other ergodox (such as the Ergodox-ez [3] style keyboards of this type.
EDIT: Apologies, I wasn't paying attention to usernames when responding to comments and basically gave you this answer twice across two different comments. Deleted the other as this one is more complete/to the point.
> They can't just slap more memory on the board, they would need to dedicate significantly more silicon area to memory IO and drive up the cost of the part,
In the pedantic sense of just literally slapping more on existing boards? No, they might have one empty spot for an extra BGA VRAM chip, but not enough for the gain's we're talking about. But this is absolutely possible, trivially so for someone like Intel/AMD/NVidia, that has full control over the architectural and design process. Is it a switch they flip at the factory 3 days before shipping? No, obviously not. But if they intended this to be the case ~2 years ago when this was just a product on the drawing board? Absolutely. There is 0 technical/hardware/manufacturing reason they couldn't do this. And considering the "entry level" competitor product is the M4 Max which starts at at least $3,000 (for a 128GB equipped one), the margin on pricing more than exists to cover a few hundred extra in ram and extra overhead in higher-layer more populated PCB's.
The real impediment is what you landed on at the end there combined with the greater ecosystem not having support for it. Intel could drop a card that is, by all rights, far better performing hardware than a competing Nvidia GPU, but Nvidia's dominance in API's, CUDA, Networking, Fabric-switches (NVLink, mellanox, bluefield), etc etc for that past 10+ years and all of the skilled labor that is familiar with it would largely render a 128GB Arc GPU a dud on delivery, even if it was priced as a steal. Same thing happened with the Radeon VII. Killer compute card that no one used because while the card itself was phenomenal, the rest of the ecosystem just wasn't there.
Now, if intel committed to that card, and poured their considerable resources into that ecosystem, and continued to iterate on that card/family, then now we're talking, but yeah, you can't just 10X VRAM on a card that's currently a non-player in the GPGPU market and expect anyone in the industry to really give a damn. Raise an eyebrow or make a note to check back in a year? Sure. But raise the issue to get a greenlight on the corpo credit line? Fat chance.
Of course. A cheap card with oodles of VRAM would benefit some people, I'm not denying that. I'm tackling the question of would it benefit intel (as the original question was "why doesn't intel do this"), and the answer is: Profit/Loss.
There's a huge number of people in that community that would love to have such a card. How many are actually willing and able to pony up >=$3k per unit? How many units would they buy? Given all of the other considerations that go into making such cards useful and easy to use (as described), the answer is - in intel's mind - nowhere near enough, especially when the financial side of the company's jimmies are so rustled that they sacked Pat G without a proper replacement and nominated some finance bros in as interim CEO's. Intel is ALREADY taking a big risk and financial burden trying to get into this space in the first place, and they're already struggling, so the prospect of betting the house like that just isn't going to fly for the finance bros that can't see passed the next 2 quarters.
To be clear, I personally think there is huge potential value in trying to support the OSS community to, in essence, "crowd source" and speedrun some of that ecosystem by supplying (Compared to the competition) "cheap" cards that aschew the artificial segmentation everyone else is doing and investing in that community. But I'm not running Intel, so while that'd be nice, it's not really relevant.
I suspect that Intel could hit a $2000 price point for a 128GB ARC card, but even at $3000, it would certainly be cheaper than buying 8 A770 LE ARC cards and connecting them to a machine. There are likely tens of thousands of people buying multiple GPUs to run local inferencing on Reddit’s local llama, and that is a subset of the market.
In Q1 2023, Intel sold 250,000 ARC cards. Sales then collapsed the next quarter. I would expect sales to easily exceed that and be maintained. The demand for high memory GPUs is far higher than many realize. You have professional inferencing operations such as the ones listed at openrouter.ai that would gobble up 128GB VRAM ARC cards for running smaller high context models, much like how you have businesses gobbling up the Raspberry Pi for low end tasks, without even considering the local inference community.
Comparing a WSE-3 to a H100 without considering the systems they go in or the systems, cooling, networking, etc that supports them means little when doing cost analysis, be it CapEx or TCO. A better (but still flawed) comparison would be a DGX H200 (a cluster of H100's and their essential supporting infra) to a CS-3 (a cluster of WSE-3's and their essential supporting infra in a similar form factor/volume of a DGX H200).
Now, is Cerebras going to eventually beat Nvidia or at least compete healthily with Nvidia and other tech titans in the general market or a given lucrative niche of it? No idea. That'd be a cool plot twist, but hard to say. But it's worth acknowledging that investing in a company and buying their products are two entirely separate decisions. Much of silicon valleys success stories are a result of people investing in the potential of what they could become, not because they were already the best on the market, and for nothing else, Cerebras approach is certainly novel and promising.
Especially as the company archives all those chats (not sure how long) and is small enough that a billion dollar "data sharing" agreement would be a very inticing offer.
If there isn't a significant barrier to access, it's being scraped. And if that barrier is money, it's being scraped but less often.