One of the more ridiculous stories I remember from Uni was sysadmins getting very upset that students were fork bombing the server. But... it was from the students in the systems programming class that were just learning about fork/exec, and bugs happen... I thought it was the most ridiculous thing ever.
Also, this was the late 90s and while you could get linux running, all the servers were Unix, and the profs made it very clear any issues between differences between Linux and Solaris were ours to deal with... so we were essentially forced to login to their servers. We are truly our own worst enemy sometimes.
I still remember being "invited" to a meet-and-greet with the VP of Tech at my college after a fork bomb run amok. 17yo me was sure my academic career was at an end. He let me sweat for a few of minutes and then smiled and offered me a job. <whew>
I was caught by surprise on this. I have P8Pro and while its fine, I was just kind of curious about how much of an upgrade it would be to the 11Pro, especially since I haven't really given the last two years releases any attention.
But the P11 Pro is now 6.3" and the P8 Pro was 6.7" meaning you have to go up to the P11 Pro XL (for another $200) for the same size. Well technically its 6.8" vs 6.7 but I feel this is just a form of shrinkflation and enshittification. Literally no other improvements on the XL as far as I can tell from the specs, not even a larger battery.
While I certainly don't need a bigger phone, I would be pissed if I just hit the buy button and what came out of the box was half an inch smaller.
Portability is a feature. 6.7" have are so big and heavy they are annoying to carry on many pants or while doing many physical activities.
I find my 6.1" Pixel 6a way too big already. I really loved the size of the Samsung Galaxy S6 that preceded it, I think it was the sweet spot at 5.1", large enough to read text, navigate on a map or watch a video while still being pocketable and light.
I think OP is overstating it a bit tbh. So Nvidia has the market for the hardware, which helps, but there is literally no alternative to CUDA. Nvidia keeps it a scalpel for skilled users, its not super easy to use, but unlocks orders of more magnitudes of power for the use cases it excels at vs CPUs. I don't have access to anything like it in the Apple ecosystem.
AMD has had years to try and counter it, but just has not. Google is kinda trying to do an end run around it with TPUs but they are still niche high end stuff with limited availability.
Its really just CUDA, and CUDA can be seen as somewhat akin to C for assembly used by Nvidia's gpus- In many ways a wrapper around the low level hardware that often has those details bleed through.
I think there is a misconception here: CUDA is not even close to being C for assembly used by Nvidia's GPUs, PTX is, and it uses JIT to compile to Nvidia's GPU assembly, SASS. It honestly easier just to have LLMs write PTX directly than to go through CUDA C/C++ at all.
Again, "CUDA" isn't a programming language, it stands for Compute Unified Device Architecture; "C/C++ for CUDA" are the high-level languages that compiles to PTX and then SASS as well CPU orchestration code via NVCC.
And to be honest, pretty much everything you can do in CUDA C/C++, you can also do in HLSL/GLSL compiled to SPIR-V, as long as the Vulkan hardware extension is available.
My point with the c comparison is that it often feels like a very thin layer that still requires you to know a lot about what's going on under the hood. It was more to give a view in what it's like to work with the lib/api.
Maybe I wasn't being precise enough with my language for this forum, and also my last hands on experience with it was roughly 6 years ago, maybe it's gotten better. But it was much less (and forgive the imprecision!) python/pytorch-like where you say hey take this big blob of data and just slice and dice it on your many cores, and more like ok, here is the data, let's cudamemcopy it in these size chunks over to the gpu itself, to be used by this block of threads and run these commands (kernel in cudaspeak) on it. Much more painstaking and micromanagey of the resources.
Pytorch IMHO feels like a proper abstracted API that hides the details and lets you just unleash the fury at the cost of some efficiency, while the cuda api itself, similar to working with C, forces you to really think about the low level details. I have a heavy backend and systems development background, and while it wasn't really intimidating to me, it was like wow you really have to have a deep working knowledge of how these things work and it felt like a step back in time IMHO.
I doubt that's going to satisfy you but I think it gives a clearer picture of what using cuda is like if you typically use higher level languages and haven't touched C since college.
I think you are pretty precise and your comment is appreciated, so I think I need to clarify my wording as well. I think a lot of CUDA C/C++'s difficulties are self-inflicted because they conflate two things into what they call "kernels": runtime and shaders. Fundamentally, GPU programming for compute is easier than either graphics programming as well as CPU programming because you are limited on what you can do on the GPU, memory allocation is static because the matrix size doesn't really change dynamically during runtime and branching behaviors are generally to be avoided for GPU compute.
It's pretty heretical for me to say this, but a lot of GPU compute complexity that Nvidia is doing in CUDA is unnecessary and is by the simple fact that to do anything meaningful you have to either use their library or handle allocation/scheduling yourself. Imagine if JavaScript required you to handroll part of the V8/Node's JIT compiler, allocator and scheduler yourself every time you just want to make a webpage, that is essentially what CUDA is doing.
The actual "program" that runs on the GPU, the compute shaders in PTX/SPIR-V, are very low level but pretty straight forward once you get down to it.
I am not sure I understand your question- MUDs have a text interface, somewhat similar to a command line. It wouldn't be a proper MUD if it had a graphical interface- there are plenty of games out there that do this like Baldurs Gate. The files part of your comment I don't understand either.
So I actually had a use case for this last month. My NAS is too weak to run immich well, so I dusted off my old sandybridge core i7 laptop from ~2011, and it actually benchmarks about 4x my nas, and has 8GB of RAM. But it was still loaded with windows. Long story short, its actually kind of difficult these days to install linux on such an old box, distros have become massive. I searched around in my closet and found my old spindle of burned CDs- and I wanted to go on a nostalgia trip, and every one I tried worked! I used Kodak Golds, which have lived up to their hype.
I even burned a CD of the smallest ubuntu distro I could find, and its happily running linux and hosting Immich, among other things.
Journeyman Project... that brought back a deep rooted memory. Its still not clear to me if my Packard Bell came with a full version or a demo, because I remember being stuck about an hour in and could not figure out how to progress. I also was mildly interested in the game, but had better ones to play- Myst, X-Wing, etc.
Actually, yes, this was the experience I was recalling... it was 1995, not 1993, and it was the 'Turbo' version of Journeyman Project, which came in a CD pack bundled with Windows 95 by Packard Bell (a surprisingly large compilation of software to bundle with such a computer at the time. Man, it was a golden age of progress in the PC world back then).
Since it wasn't the retail version of the game, it did not come with the original instructions; instead they buried the door access code and some other numerical codes you needed during the game in a bundled instruction book for the CD box set. [0](the little teal booklet in this photo) No one ever knew to look in there, because it doesn't appear to be branded to have anything to do with the game.
There are entire sects of people on the internet that share this incredibly frustrating memory from their childhood. [1]
That's really interesting- I wish I could go back 30 years and verify that- I am a bit skeptical to be honest, as a young sponge with my first computer I was reading everything available to me- which wasn't much, a book on windows, and the manuals that it came with. But maybe I missed it.
That booklet doesn't appear to be available online anywhere :(.
Eh... yes but, I can write a sql query and come back a year later and understand it at first glance, or maybe if its really complicated a minute or two.
Writing a regex involves always looking up the syntax, and being unable to read it an hour later without having to carefully disect it. I say this with 20+ YOE and I think I am better than the average bear with them.
That said, knowing what they can do is important and very useful. Its just the implementation that never quite sticks.
> Writing a regex involves always looking up the syntax
No. I mean, I believe it does for you. I use it often enough that it's always fresh. On the other hand, I always need to look up the syntax of CREATE TABLE. My experience can be described the same as yours.
I think the main problem with regular expressions is that there are so many dialects that are subtly different. The same sort of goes for SQL, but it's not quite as bad as regular expressions are.
(Other big problem with regexes is that they are strictly slower than handrolling the equivalent string parsing code, and kind of a denial of service hazard to boot).
I'm personally just at messages. And even then I make it clear I respond when I want to. Only phone rings/notifications I get are for those in my contact list.
Take your phones back. Life is immensely better these days.
Also, this was the late 90s and while you could get linux running, all the servers were Unix, and the profs made it very clear any issues between differences between Linux and Solaris were ours to deal with... so we were essentially forced to login to their servers. We are truly our own worst enemy sometimes.