Corbin

Nothing has really changed in the past four months. If you really disagree, feel free to try my vibecoding challenge; it closes on March 1, but that's surely no obstacle for the amazing vibecoding chatbots which didn't exist in November and only recently evolved. I did all three challenges by hand and no vibecoder has yet been able to match my mediocre, lackluster work.

I don't understand why I would choose this as an anti-corporate license instead of AGPLv3, WTFPL, or CC-BY-NC-SA; in general, we want corporations to not use our software rather than accept the license conditions, and this license isn't scary enough. I also don't think that this tastes like it was written by legal professionals; how did you generate the text of the license?

It isn't the first time that the advertising requirements were used to chill speech. It doesn't matter whether there was a ban; what matters is whether speech was effectively prevented. "There is no God. Now stop worrying and enjoy your life."

You've reinvented one of the two reasons that Project Xanadu failed: micropayments have very high overhead relative to the content being paid for. (The other reason is that there literally aren't data structures which work like Xanadu's data model.)

Further, where does money come from? You're sketching a system where money has relatively high velocity, but it's all paying for content, which has marginal cost to distribute; how does money get into this system in the first place? This is why Bitcoin's currently on a trend to zero; once everybody realizes this problem, the system collapses from lack of faith.

I hope that thinking about this for a bit will radicalize you further towards the understanding that a universal income and artists' stipend is the economically-sustainable way to compensate artists, rather than forcing folks to swap scraps of digital coinage.

From the perspective of somebody who's actually hacked on Linux: Most Linux maintainers, like most programmers in general, are full of machismo stemming from the inherent difficulty of writing C. It is extremely difficult to write correct C and nobody can do it consistently, so those maintainers are heavily invested in the perception that they are skilled with C. Rust is much easier to write and democratizes kernel hacking, which is uncomfortable for older maintainers due to the standard teenagers-vs-parents social dynamics. Worse, adapting various kernel interfaces so that they are Rust-friendly has revealed that the pre- and postconditions of interface methods were not known before; there is existing sloppiness in the kernel's internals which is only visible because of Rust-related cleanups.

Note that Linux is not a GNU project. GNU's kernel project is GNU Herd. "GNU/Linux" refers to Linux userlands populated with GNU packages. It's important not to be distracted by this; the kernel is agnostic towards userland and generally is compatible with any loadable executable that uses Linux's public syscall interface, so the entire discussion of Rust in the kernel is separate from anything going on in userland.

Most siblings are wrong! PRs written in Rust can be rejected. There are already multiple non-C languages in the kernel. Rust is sufficiently available on the platforms where it will be required for building kernel. Maintainers are only added after they have shown themselves to be socially reliable and they can be removed by other maintainers if they are unresponsive. The only correct sibling points out that Rust is different.

This looks like a prompt-driven approach. As such, it will always be watered down by reinforcement learning in longer contexts. Also, the entire thrust of the prompt is ridiculous and would only work in a science-fiction novel; its metaphysics are fairly wrong. But it looks like it will be even more sycophantic than the default prompt for the cloud products you compared, so it's not really surprising that some folks find themselves attracted to it.

If you want to know how Google specifically does things, search for "TeraGoogle"; it's not a secret name although I don't think it has a whitepaper. The core insight is that there are tiers of search results. When you search for something popular that many other people are searching for, your search is handled by a pop-culture tier which is optimized for responding to those popular topics. The first and second pages of Google results are served by different tiers; on Youtube, the first few results are served from a personalized tier which (I expect has) cached your login and knows what you like, and the rest of the results are from a generalist tier. This all works because searches, video views, etc. are Pareto-allocated; most of the searches are for a tiny amount of cacheable content.

There's also a UX component. Suppose that you dial Alice's server and Alice responds with a Web app that also fetches resources from Bob's server. This can only be faster for you in the case where Bob is so close to you (and so responsive) that you can dial Bob and get a reply faster than Alice finishes sending her app. But Alice and Bob are usually colocated in a datacenter, so Alice will always be closer to Bob than you. This suggests that if Alice wants to incorporate content from Bob then Alice might as well dial Bob herself and not tell you about Bob at all. This is where microservices shine. When you send a search to Google, Youtube, Amazon, or other big front pages, you're receiving a composite result which has queries from many different services mixed in. For the specific case of Google, when you connect to google.com, you're connecting to a machine running GWS, and GWS connects to multiple search backends on your behalf.

Finally, how typical of a person are you? You might not realize how often your queries are handled by pop-culture tiers. I personally have frequent experiences where my search turns up zero documents on DDG or Google, where there are no matching videos on Youtube, etc. and those searches take multiple seconds to come up empty. If you're a weird person who constantly finds googlewhacks then you're not going to perceive these services as optimized for you, because they cannot optimize for the weird.

@eleijeep@piefed.social You had a couple months. At this point, I think that you've failed the challenge. I know that there's a lot going on in the world, but frankly I doubt your commitment to dick-measuring contests on Lemmy if you're not even able to write a bug-free JSON recognizer in C in eight weeks. I understand why you wanted to remain pseudonymous!

Let us all learn a lesson from eleijeep: writing correct C is very hard and probably can't be done on-demand. Correct C isn't a party trick.

BadRAM specifiers can apply to stripes of memory corresponding to certain physical hardware failures. The memmap hack only allows for contiguous allocations. BadRAM's intended for repurposing consumer-grade RAM that might normally be thrown out, not for reconfiguring motherboards that have strange layouts.

Hi! You are still bullshitting us. To understand your own incorrectness, please consider what a chatbot should give as an answer to the following questions which I gave previously, on Lobsters:

• Is the continuum hypothesis true?
• Is the Goldbach conjecture true?
• Is NP contained in P?
• Which of Impagliazzo's Five Worlds do we inhabit?

The biggest questions in mathematics do not fit nicely into the chatbot paradigm and demonstrate that LLMs lack intelligence (whatever that is). I wrote about Somebody Else's Paper, but it applies to you too:

This attempt doesn't quite get over the epistemological issue that something can be true or false, determined and decided, prior to human society learning about it and incorporating it into training data.

Also, on a personal note, I recommend taking a writing course and organizing your thoughts prior to writing long posts for other people. Your writing voice is not really yours, but borrowed from chatbots; I suspect that you're about halfway down the path that I described previously, on Lobsters. This is reversible but you have to care about yourself.

Last time, when I tried to explain this to you, you decided to use personal insults. Mate, I'm not the one who has eaten your brains. I'm not the one who told you that LLMs can be turned into genies or oracles via system prompts. I'm certainly not the one who told you that RAG solves confabulation. You may have to stop worshipping the chatbot for a moment in order to understand this but I assure you that it is worthwhile.

Linux supports Unicode usernames. However, bidirectional rendering is application-specific. I have not tried this myself, so I'm not sure what happens. Also, I'm not sure whether the bidirectional markers are canonicalized away, so the input method likely matters too.

I think that there are two pieces to it. There's tradition, of course, but I don't think that that's a motive. Also, some folks will argue that not taking hands off the keyboard, not going to a mouse, is an advantage; I'm genuinely not sure about that. Finally, I happen to have decent touch typing; this test tells me 87 WPM @ 96% accuracy.

First, I don't spend that much time at the text editor. Most of my time is either at a whiteboard, synchronizing designs and communicating with coworkers, or reading docs. I'd estimate that maybe 10-20% of my time is editing text. Moreover, when I'm writing docs or prose, I don't need IDE features at all; at those times, I enable vim's spell check and punch the keys, and I'd like my text editor to not get in the way. In general, I think of programming as Naur's theory-building process, and I value my understanding of the system (or my user's understanding, etc.) over any computer-rendered view of the system.

Second, when I am editing text, I have a planned series of changes that I want to make. Both Emacs and vim descend from lineages of editors (TECO and ed respectively) which are built out of primitive operations on text buffers. Both editors allow macro-instructions, today called macros, which are programmable sequences of primitive operations. In vim, actions like reflowing a paragraph (gqap) or deleting everything up to the next semicolon and switching to insert mode (ct;) are actually sentences of a vim grammar which has its own verbs and nouns.

As a concrete example, I'm currently hacking Linux kernel because I have some old patches that I am forward-porting. From the outside, my workflow looks like staring out the window for several minutes, opening vim and editing less than one line over the course of about twenty seconds, and restarting a kernel build. From the inside, I read the error message from the previous kernel build, jump to the indicated line in vim with g, and edit it to not have an error. Most of my time is spent ~~legitimately slacking~~ multitasking. This is how we bring up hardware for the initial boot and driver development too.

Third! This isn't universal for Linux hackers. I make programming languages. Right now, I'm working with a Smalltalk-like syntax which compiles to execline. There's no IDE for execline and Smalltalks famously invented self-hosted IDEs, so there's no existing IDE which magically can assist me; I'd have to create my own IDE. With vim, I can easily reuse existing execline and Smalltalk syntax highlighting, which is all I really want for code legibility. This lets me put most of my time where it should go: thinking about possibilities and what could be done next.