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.
Corbin
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.
So, you've never known any Unix hackers? I worked for a student datacenter when I was at university, and we were mostly vim users; as far as text-editor diversity, we did have one guy who was into emacs and another who preferred nano. After that, I went to work at Google, where I continued to use vim. As far as fancy IDE features, I do use syntax highlighting and I know how to use the spell checker but I don't use autocomplete. I've heard of neovim but don't have a good reason to try it out yet; maybe next decade?
Hi! You are 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.
Secondarily, you are the first person to give me a solid reason as to why the current paradigm is unworkable. Despite my mediocre recall I have spent most of my life studying AI well before all this LLM stuff, so I like to think I was at least well educated on the topic at one point.
Unfortunately it seems that your education was missing the foundations of deep learning. PAC learning is the current meta-framework, it's been around for about four decades, and at its core is the idea that even the best learners are not guaranteed to learn the solution to a hard problem.
I am somewhat curious about what architecture changes need to be made to allow for actual problem solving.
First, convince us that humans are actual problem solvers. The question is begged; we want computers to be intelligent but we didn't check whether humans were intelligent before deciding that we would learn intelligence from human-generated data.
You always need to read what the machine generated for you; the machine can only write code for you, not understand code for you. Here, the biggest issue is that copy might not work if the input and output containers are different, if the input has multiple framerates or audio tracks, etc.
Well done. I recently revived the BadRAM kernel patch in order to do something similar; memtest86+ supports that functionality too, using , , , .
Hi! Welcome to the Nix community. You've made an unfortunate choice for your first package, because VPNs usually need to be integrated with system networking to function properly, and Nix without a daemon or NixOS is not able to do that. A distro has multiple pieces, including package management (putting executables and libraries onto your disk) and system configuration (interacting with the low-level hardware). Nix is a package manager; NixOS is Nix and also system configuration and some other stuff like booting.
For the specific case of Mullavad, I found this community documentation:
Warning: Mullvad VPN currently only works if systemd-resolved is enabled.
All you need to know here is that systemd is part of the system configuration; systemd-resolved is part of how some Linux systems look up names. Nix's version of Mullavad VPN is only compatible with a specific NixOS configuration.
Honestly, it's great to hear that the GUI and nix-env are working for you; those are things that often break on unusual targets. It sounds like the only thing that doesn't work is something which cannot work as installed.
@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.