[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"article-gentoo-kernel-config-menuconfig-workflow-en":3,"article-related-gentoo-kernel-config-menuconfig-workflow-en":30,"series-tools-79194d55-f22c-465f-90b8-8050b2c278fb":73},{"id":4,"slug":5,"title":6,"content":7,"summary":8,"source":9,"source_url":10,"author":11,"image_url":12,"cover_image":12,"category":13,"language":14,"translated_content":11,"related_article_id":15,"keywords":16,"key_takeaways":22,"views":26,"created_at":27,"published_at":28,"topic_cluster_id":29},"79194d55-f22c-465f-90b8-8050b2c278fb","gentoo-kernel-config-menuconfig-workflow-en","Gentoo kernel config turns menuconfig into a workflow","\u003Cp data-speakable=\"summary\">This shows how I turn Gentoo kernel configuration into a repeatable workflow.\u003C\u002Fp>\u003Cp>I've been doing kernel setup on Gentoo long enough to know where it goes sideways. The source tree is there, the config menu opens, and then everything turns into a guessing game: did I build that driver in, as a module, or not at all? Did I remember the external modules? Did I just move half my boot chain into a state I can’t explain six hours later? That’s the part that always annoyed me. Not the compiling. The compiling is fine. It’s the little decisions hidden behind menu labels, the environment variables that can quietly ruin a build, and the fact that one sloppy config pass can leave you staring at a machine that boots differently than you expected. Gentoo’s kernel wiki page finally gives that mess a shape I can actually work with.\u003C\u002Fp>\u003Cp>The source that triggered this breakdown is the Gentoo Wiki page \u003Ca href=\"https:\u002F\u002Fwiki.gentoo.org\u002Fwiki\u002FKernel\u002FConfiguration\">Kernel\u002FConfiguration\u003C\u002Fa>. It’s not a theory piece. It’s a practical map of how Gentoo expects you to configure, build, install, and verify a kernel. The page also points at the surrounding docs that matter, like \u003Ca href=\"https:\u002F\u002Fwiki.gentoo.org\u002Fwiki\u002FKernel\">Kernel\u003C\u002Fa>, \u003Ca href=\"https:\u002F\u002Fwiki.gentoo.org\u002Fwiki\u002FKernel\u002FGentoo_Kernel_Configuration_Guide\">Kernel\u002FGentoo Kernel Configuration Guide\u003C\u002Fa>, and \u003Ca href=\"https:\u002F\u002Fwiki.gentoo.org\u002Fwiki\u002FInstallkernel\">installkernel\u003C\u002Fa>. I’m using the wiki as the anchor here, not inventing a new process.\u003C\u002Fp>\u003Ch2>Stop treating kernel config like a one-shot ritual\u003C\u002Fh2>\u003Cblockquote>“The kernel offers several user facing tools with which to configure itself.”\u003C\u002Fblockquote>\u003Cp>What this actually means is: Gentoo is not betting on one magical path. It gives you multiple config front ends, and the sane move is to pick one and understand it well enough to stop thrashing. The page lists \u003Ccode>make config\u003C\u002Fcode>, \u003Ccode>make menuconfig\u003C\u002Fcode>, \u003Ccode>make nconfig\u003C\u002Fcode>, \u003Ccode>make xconfig\u003C\u002Fcode>, \u003Ccode>make gconfig\u003C\u002Fcode>, \u003Ccode>make oldconfig\u003C\u002Fcode>, \u003Ccode>make olddefconfig\u003C\u002Fcode>, and a few more. That sounds like a menu of equal choices, but it isn’t. Some are for deliberate editing, some are for upgrades, and some are for “I need a clean default and I need it now.”\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782523097255-cir6.png\" alt=\"Gentoo kernel config turns menuconfig into a workflow\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>I’ve used \u003Ccode>make config\u003C\u002Fcode> exactly enough times to remember why I stopped. It asks every question in order. If you realize you need to revisit something earlier, you get to enjoy scrolling through the whole thing again. That’s fine if you like punishment. I don’t.\u003C\u002Fp>\u003Cp>How to apply it: use \u003Ccode>make menuconfig\u003C\u002Fcode> for normal work, \u003Ccode>make olddefconfig\u003C\u002Fcode> when you’re upgrading a known-good config and want the new defaults without babysitting every prompt, and \u003Ccode>make defconfig\u003C\u002Fcode> when you want to reset to the architecture default and start over. If you’re experimenting, keep the current \u003Ccode>.config\u003C\u002Fcode> somewhere safe before you touch anything. Kernel work rewards boring discipline.\u003C\u002Fp>\u003Cul>\u003Cli>\u003Ccode>menuconfig\u003C\u002Fcode> for interactive editing\u003C\u002Fli>\u003Cli>\u003Ccode>olddefconfig\u003C\u002Fcode> for upgrades with minimal drama\u003C\u002Fli>\u003Cli>\u003Ccode>defconfig\u003C\u002Fcode> when you want a clean reset\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>Learn the menu symbols or you’ll misread the whole thing\u003C\u002Fh2>\u003Cp>The wiki spends real time explaining the menu UI, and that’s not fluff. It tells you what the symbols mean: square brackets for built-in toggles, angle brackets for built-in or module choices, curly braces for forced dependency states, and hyphenated entries for options that are fixed by something else. It also explains the tags like \u003Ccode>(NEW)\u003C\u002Fcode>, \u003Ccode>(EXPERIMENTAL)\u003C\u002Fcode>, \u003Ccode>(DEPRECATED)\u003C\u002Fcode>, and \u003Ccode>(OBSOLETE)\u003C\u002Fcode>.\u003C\u002Fp>\u003Cp>That matters because kernel menus are easy to misread if you only skim them. I’ve seen people assume \u003Ccode>[*]\u003C\u002Fcode> and \u003Ccode><M>\u003C\u002Fcode> are basically the same. They aren’t. One means the feature is built into the kernel image. The other means it becomes a loadable module. That distinction changes boot behavior, recovery behavior, and whether you can recover from a bad choice without rebuilding everything.\u003C\u002Fp>\u003Cp>I ran into this the hard way on a machine where I’d built storage support as modules, then forgot how much of the early boot path depended on them being available before userspace had a chance to help. The system wasn’t broken in a dramatic way. It was worse. It was inconsistent. Sometimes it booted, sometimes it waited, and sometimes it felt like it was daring me to remember what I had done.\u003C\u002Fp>\u003Cp>How to apply it: when you’re in \u003Ccode>menuconfig\u003C\u002Fcode>, stop making guesses based on color or indentation. Read the symbol state. Ask one question for every option: “Must this exist before modules load?” If yes, build it in. If not, module is often safer. And if the menu says experimental or deprecated, don’t let curiosity do the steering unless you’re intentionally testing.\u003C\u002Fp>\u003Cul>\u003Cli>\u003Ccode>[*]\u003C\u002Fcode> means built in\u003C\u002Fli>\u003Cli>\u003Ccode><M>\u003C\u002Fcode> means module\u003C\u002Fli>\u003Cli>\u003Ccode>(NEW)\u003C\u002Fcode> and \u003Ccode>(EXPERIMENTAL)\u003C\u002Fcode> deserve extra caution\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>Search first, scroll later\u003C\u002Fh2>\u003Cp>Gentoo’s page calls out the \u003Ccode>\u002F\u003C\u002Fcode> search inside \u003Ccode>make menuconfig\u003C\u002Fcode>. That’s one of those tiny details that saves a ridiculous amount of time. The search output shows the symbol name, its current state, where it lives in the tree, and the dependency chain. In the example on the page, searching for \u003Ccode>HCIBTUSB\u003C\u002Fcode> lands on Bluetooth USB support and shows exactly where it sits in the menu hierarchy.\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782523094053-h6go.png\" alt=\"Gentoo kernel config turns menuconfig into a workflow\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>That’s the real power move. You don’t need to memorize every submenu path. You need to know how to jump from a driver name to the exact config symbol and then inspect its dependencies. Kernel config is mostly dependency management wearing a UI costume.\u003C\u002Fp>\u003Cp>I’ve wasted too many sessions walking menus like a tourist because I forgot the search key existed. Then I’d stumble into the right option by accident, change three related settings, and still not understand why the thing worked. Search makes the process surgical. It also makes it easier to read help text in context, which is where a lot of the actual decision-making happens.\u003C\u002Fp>\u003Cp>How to apply it: when you need support for a device, search by the driver or subsystem name first. Then follow the dependency chain before you toggle anything. If a symbol depends on \u003Ccode>USB\u003C\u002Fcode> or \u003Ccode>NET\u003C\u002Fcode> being enabled, don’t ignore that. The search result is a map, not just a lookup box.\u003C\u002Fp>\u003Cp>Useful external docs here are the upstream kernel build docs, especially the \u003Ca href=\"https:\u002F\u002Fdocs.kernel.org\u002Fkbuild\u002Fkconfig.html\">Kconfig documentation\u003C\u002Fa>, and the Gentoo-specific hardware guidance in \u003Ca href=\"https:\u002F\u002Fwiki.gentoo.org\u002Fwiki\u002FHardware_detection\">Hardware detection\u003C\u002Fa>. I also keep the upstream kernel tree handy at \u003Ca href=\"https:\u002F\u002Fgit.kernel.org\u002Fpub\u002Fscm\u002Flinux\u002Fkernel\u002Fgit\u002Ftorvalds\u002Flinux.git\">kernel.org\u003C\u002Fa> when I need to check what a symbol actually means upstream.\u003C\u002Fp>\u003Ch2>Gentoo Linux common settings are a shortcut, not a substitute\u003C\u002Fh2>\u003Cp>The page mentions \u003Ccode>CONFIG_GENTOO_LINUX\u003C\u002Fcode>, which is available in \u003Ccode>sys-kernel\u002Fgentoo-sources\u003C\u002Fcode> and other Kernel Project-maintained kernels. The important part is not the name. It’s what it does: it selects a set of required options for a typical Gentoo installation, including \u003Ccode>tmpfs\u003C\u002Fcode> and \u003Ccode>devtmpfs\u003C\u002Fcode> support for \u003Ccode>\u002Fdev\u003C\u002Fcode> handling.\u003C\u002Fp>\u003Cp>What this actually means is that Gentoo is giving you a sane baseline for a Gentoo system. It is not replacing your judgment. It’s the kind of option that prevents you from forgetting the boring stuff while you focus on the hardware-specific stuff that actually differs from machine to machine.\u003C\u002Fp>\u003Cp>I like this kind of setting because it acknowledges reality. Nobody wants to hand-pick every generic kernel knob every single time. That’s not craftsmanship. That’s repetitive work with a nicer name. The Gentoo option trims down the obvious required pieces so you can spend your attention on the parts that matter: storage, input, networking, graphics, virtualization, and whatever weird device your box depends on.\u003C\u002Fp>\u003Cp>How to apply it: if you’re using Gentoo kernel sources, check whether the Gentoo-specific helper config is available and read its help text in \u003Ccode>menuconfig\u003C\u002Fcode>. Use it as a baseline, then verify the rest of your system requirements manually. Don’t assume it covers every edge case. It won’t.\u003C\u002Fp>\u003Cul>\u003Cli>Good for baseline Gentoo-required settings\u003C\u002Fli>\u003Cli>Not a replacement for hardware-specific review\u003C\u002Fli>\u003Cli>Read the help text before trusting it\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>Don’t mix toolchains unless you enjoy weird failures\u003C\u002Fh2>\u003Cp>The wiki includes a blunt warning about Kbuild and environment variables: do not mix GNU binutils and LLVM binutils. The example given is specific: \u003Ccode>make CC=gcc LD=ld.lld AR=llvm-ar\u003C\u002Fcode> will not work because LLVM’s \u003Ccode>ar\u003C\u002Fcode> and \u003Ccode>ld\u003C\u002Fcode> are not compatible with GCC in that combination. That’s the kind of sentence I wish more build docs would say out loud instead of pretending all compiler toolchains are interchangeable.\u003C\u002Fp>\u003Cp>What this actually means is that kernel builds are sensitive to the whole toolchain stack, not just the compiler binary you think you picked. If you want LLVM, use it consistently. If you want GCC and GNU binutils, stay in that lane. Mixed settings are where you get failures that look random until you remember you assembled them yourself.\u003C\u002Fp>\u003Cp>I’ve had builds fail in ways that looked like source bugs until I checked the environment and found some half-swapped toolchain setting from an earlier experiment. That’s the annoying part: the kernel build system is flexible enough to let you hurt yourself with precision.\u003C\u002Fp>\u003Cp>How to apply it: choose a toolchain strategy before you start. If you’re using LLVM, the wiki’s example of \u003Ccode>make LLVM=1\u003C\u002Fcode> is the simplest path. If you also want custom optimization flags, set them deliberately and keep them readable. And if you don’t know why a variable is there, don’t cargo-cult it into the command line.\u003C\u002Fp>\u003Cp>For reference, the upstream Clang\u002FLLVM build notes are here: \u003Ca href=\"https:\u002F\u002Fdocs.kernel.org\u002Fkbuild\u002Fllvm.html\">Clang\u002FLLVM in the kernel docs\u003C\u002Fa>. If you’re on Gentoo, the package docs for your chosen compiler and binutils matter too, because distro defaults can affect what’s actually installed.\u003C\u002Fp>\u003Ch2>Build and install like you expect to recover from mistakes\u003C\u002Fh2>\u003Cp>After configuration, the page keeps the build path simple: compile with \u003Ccode>make -j$(nproc)\u003C\u002Fcode>, install modules with \u003Ccode>make modules_install\u003C\u002Fcode>, and install the kernel with \u003Ccode>make install\u003C\u002Fcode>. That sounds basic, but the details around it are where people get bitten. The modules land under \u003Ccode>\u002Flib\u002Fmodules\u003C\u002Fcode> by default unless you change \u003Ccode>MODLIB\u003C\u002Fcode>. The actual kernel install runs through \u003Ccode>\u002Fsbin\u002Finstallkernel\u003C\u002Fcode>, which comes from \u003Ccode>sys-kernel\u002Finstallkernel\u003C\u002Fcode>.\u003C\u002Fp>\u003Cp>That matters because Gentoo is not pretending the kernel install is just a raw copy operation. It’s part of a larger boot workflow. If you’re using \u003Ccode>installkernel\u003C\u002Fcode> with initramfs automation, the wiki recommends rebuilding external modules first so they’re included in the initramfs. It specifically calls out rebuilding external modules like \u003Ca href=\"\u002Ftag\u002Fnvidia\">NVIDIA\u003C\u002Fa> and ZFS before installing the kernel when the dracut USE flag is active.\u003C\u002Fp>\u003Cp>I like this advice because it reflects how real systems fail. If your module stack is out of sync with the kernel image, you don’t always get a loud error. Sometimes you just get missing functionality after reboot, which is the kind of problem that eats a whole afternoon.\u003C\u002Fp>\u003Cp>How to apply it: treat \u003Ccode>make modules_install\u003C\u002Fcode> and \u003Ccode>make install\u003C\u002Fcode> as part of one sequence, not two unrelated commands. If you rely on external modules, rebuild them before you generate or refresh initramfs. If you use dracut, follow the order the wiki suggests. If you don’t, you’re gambling on your boot path being more forgiving than it usually is.\u003C\u002Fp>\u003Cp>For the install side, I’d also keep the Gentoo \u003Ca href=\"https:\u002F\u002Fwiki.gentoo.org\u002Fwiki\u002FInstallkernel\">installkernel page\u003C\u002Fa> open, because that package defines the exact handoff from kernel build to bootloader-ready artifacts.\u003C\u002Fp>\u003Ch2>Diffing configs is how I stop lying to myself\u003C\u002Fh2>\u003Cp>The last part of the page is the one I wish more people used: compare the current kernel configuration against the default. The procedure copies the working \u003Ccode>.config\u003C\u002Fcode>, generates a default with \u003Ccode>make defconfig\u003C\u002Fcode>, saves that, then uses \u003Ccode>scripts\u002Fdiffconfig\u003C\u002Fcode> to compare the two. That gives you a focused view of what changed instead of forcing you to eyeball a giant config file and pretend you’ll remember the meaningful bits.\u003C\u002Fp>\u003Cp>What this actually means is that you can audit your own choices. Kernel configs accrete junk. You turn on one feature for one machine, then six months later you forget why it’s there. A diff gives you a record you can reason about. It’s not glamorous. It’s just useful.\u003C\u002Fp>\u003Cp>I use this kind of diff when I’m cleaning up old configs or trying to understand why a machine behaves differently after an upgrade. It’s also a good way to catch accidental changes caused by dependencies, because one option can quietly flip several others. The wiki explicitly warns that changing one setting may alter additional settings, and that’s exactly the sort of thing that turns a “small tweak” into a weird boot regression.\u003C\u002Fp>\u003Cp>How to apply it: save the working config before experimenting, generate a default baseline, compare them, and keep the diff around until you’re done validating the machine. If you’re not sure why a symbol changed, use the search inside \u003Ccode>menuconfig\u003C\u002Fcode> to trace it back to the menu and help text.\u003C\u002Fp>\u003Ch2>The template you can copy\u003C\u002Fh2>\u003Cpre>\u003Ccode># Gentoo kernel config workflow template\n# Source: https:\u002F\u002Fwiki.gentoo.org\u002Fwiki\u002FKernel\u002FConfiguration\n\n# 1) Enter the kernel tree\ncd \u002Fusr\u002Fsrc\u002Flinux\n\n# 2) Open the interactive config UI\nmake menuconfig\n\n# 3) Optional: search for a symbol inside menuconfig\n# Press \u002F\n# Example: search for a driver or subsystem name\n\n# 4) Build the kernel\nmake -j$(nproc)\n\n# 5) Install modules if you enabled any as modules\nmake modules_install\n\n# 6) If you rely on external modules and initramfs automation,\n# rebuild external modules before installing the kernel\n# emerge --ask @module-rebuild\n\n# 7) Install the kernel through installkernel\nmake install\n\n# 8) If you want a clean upgrade path for an existing config\nmake olddefconfig\n\n# 9) If you want to compare your working config against defaults\ncp -p .config ..\u002F.config.working\nmake defconfig\nmv .config ..\u002F.config.default\ncp -p ..\u002F.config.working .config\ncd ..\n\u002Fusr\u002Fsrc\u002Flinux\u002Fscripts\u002Fdiffconfig .config.working .config.default > .config.diff\n\n# 10) Clean up when done\nrm .config.working .config.default .config.diff\n\n# 11) Toolchain examples\n# LLVM build:\n# make LLVM=1\n#\n# Custom flags:\n# make LLVM=1 KCFLAGS=\"-O3 -march=native -pipe\"\n\n# 12) Menuconfig reminder\n# [*] = built in\n# <M> = module\n# \u002F = search\n# H = help\u003C\u002Fcode>\u003C\u002Fpre>\u003Cp>The part I’d actually copy from this template is the mindset: pick a config path, keep the toolchain consistent, rebuild external modules before the initramfs step if needed, and diff your configs when you’re not sure what changed. That’s the difference between “I built a kernel” and “I can explain this kernel later.”\u003C\u002Fp>\u003Cp>If I were writing this for myself, I’d keep the workflow boring on purpose. Boring is good. Boring boots.\u003C\u002Fp>\u003Cp>Most of this is original commentary wrapped around the Gentoo Wiki’s instructions, with the source material coming from \u003Ca href=\"https:\u002F\u002Fwiki.gentoo.org\u002Fwiki\u002FKernel\u002FConfiguration\">Kernel\u002FConfiguration\u003C\u002Fa>. The command examples and configuration meanings are derived from that page; the opinions and workflow framing are mine.\u003C\u002Fp>","A practical Gentoo kernel setup guide that turns menuconfig, module rebuilds, and installkernel into a repeatable workflow.","wiki.gentoo.org","https:\u002F\u002Fwiki.gentoo.org\u002Fwiki\u002FKernel\u002FConfiguration",null,"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782523097255-cir6.png","tools","en","d09affdd-1109-4194-ba42-05c53062a038",[17,18,19,20,21],"gentoo","kernel","menuconfig","kbuild","installkernel",[23,24,25],"Use menuconfig for day-to-day kernel work and olddefconfig for safe upgrades.","Read symbol states carefully: built-in, module, and forced dependency are not the same.","Keep toolchains consistent and rebuild external modules before initramfs generation.",0,"2026-06-27T01:17:52.032704+00:00","2026-06-27T01:17:52.021+00:00","cf57da77-8158-43a8-90ce-46b0d8ce2c3b",{"tags":31,"relatedLang":32,"relatedPosts":36},[],{"id":15,"slug":33,"title":34,"language":35},"gentoo-kernel-config-menuconfig-workflow-zh","Gentoo 核心設定把 menuconfig 變流程","zh",[37,43,49,55,61,67],{"id":38,"slug":39,"title":40,"cover_image":41,"image_url":41,"created_at":42,"category":13},"9dd3283e-5056-4053-b096-a27a441643f0","dockers-apt-repo-update-ubuntu-cleanly-en","Docker’s APT repo lets you update Ubuntu cleanly","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782516776887-ep7d.png","2026-06-26T23:32:35.701464+00:00",{"id":44,"slug":45,"title":46,"cover_image":47,"image_url":47,"created_at":48,"category":13},"332d7a17-50b0-4815-9f3f-1fe0178a4bcf","spec-kit-guided-ai-workflow-setup-en","Spec Kit turns setup into a guided AI workflow","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782505100912-x7gh.png","2026-06-26T20:17:59.881989+00:00",{"id":50,"slug":51,"title":52,"cover_image":53,"image_url":53,"created_at":54,"category":13},"197c6d03-0fe4-4970-98d6-be057c0e1fcb","litefuse-agent-observability-single-binary-doris-en","Litefuse 不是 Langfuse 的补丁，而是 Agent 可观测的正确方向","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782500573788-2zj7.png","2026-06-26T19:02:21.8574+00:00",{"id":56,"slug":57,"title":58,"cover_image":59,"image_url":59,"created_at":60,"category":13},"eee7db48-f6af-46e6-b602-73813d0c8b30","20-ai-coding-assistants-stripped-down-2026-en","20 AI coding assistants, stripped down for 2026","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782498804011-262x.png","2026-06-26T18:32:54.079908+00:00",{"id":62,"slug":63,"title":64,"cover_image":65,"image_url":65,"created_at":66,"category":13},"d4b06c3c-43b1-4638-b02f-78b79585218a","open-code-review-turns-ai-reviews-line-accurate-checks-en","Open Code Review turns AI reviews into line-accurate checks","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782490707271-5kws.png","2026-06-26T16:17:57.715243+00:00",{"id":68,"slug":69,"title":70,"cover_image":71,"image_url":71,"created_at":72,"category":13},"9bd27b93-b6f8-448d-af75-22ba07d8c1c3","grok-imagine-1-5-turns-prompts-into-720p-video-en","Grok Imagine 1.5 turns prompts into 720p video","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782475418949-cvva.png","2026-06-26T12:03:03.32881+00:00",[74,79,84,89,94,99,104,109,114,119],{"id":75,"slug":76,"title":77,"created_at":78},"8008f1a9-7a00-4bad-88c9-3eedc9c6b4b1","surepath-ai-mcp-policy-controls-en","SurePath AI's New MCP Policy Controls Enhance AI Security","2026-03-26T01:26:52.222015+00:00",{"id":80,"slug":81,"title":82,"created_at":83},"27e39a8f-b65d-4f7b-a875-859e2b210156","mcp-standard-ai-tools-2026-en","MCP Standard in 2026: Integrating AI Tools","2026-03-26T01:27:43.127519+00:00",{"id":85,"slug":86,"title":87,"created_at":88},"165f9a19-c92d-46ba-b3f0-7125f662921d","rag-2026-transforming-enterprise-ai-en","How RAG in 2026 is Transforming Enterprise AI","2026-03-26T01:28:11.485236+00:00",{"id":90,"slug":91,"title":92,"created_at":93},"6a2a8e6e-b956-49d8-be12-cc47bdc132b2","mastering-ai-prompts-2026-guide-en","Mastering AI Prompts: A 2026 Guide for Developers","2026-03-26T01:29:07.835148+00:00",{"id":95,"slug":96,"title":97,"created_at":98},"3ab2c67e-4664-4c67-a013-687a2f605814","garry-tan-open-sources-claude-code-toolkit-en","Garry Tan Open-Sources a Claude Code Toolkit","2026-03-26T08:26:20.245934+00:00",{"id":100,"slug":101,"title":102,"created_at":103},"66a7cbf8-7e76-41d4-9bbf-eaca9761bf69","github-ai-projects-to-watch-in-2026-en","20 GitHub AI Projects to Watch in 2026","2026-03-26T08:28:09.752027+00:00",{"id":105,"slug":106,"title":107,"created_at":108},"9f332fda-eace-448a-a292-2283951eee71","practical-github-guide-learning-ml-2026-en","A Practical GitHub Guide to Learning ML in 2026","2026-03-27T01:16:50.125678+00:00",{"id":110,"slug":111,"title":112,"created_at":113},"1b1f637d-0f4d-42bd-974b-07b53829144d","aiml-2026-student-ai-ml-lab-repo-review-en","AIML-2026 Is a Bare-Bones Student Lab Repo","2026-03-27T01:21:51.661231+00:00",{"id":115,"slug":116,"title":117,"created_at":118},"6d1bf3f6-e191-4d30-b55b-8a0722fa6afe","ai-trending-github-repos-and-research-feeds-en","AI Trending Tracks Repos and Research Feeds","2026-03-27T01:31:35.709532+00:00",{"id":120,"slug":121,"title":122,"created_at":123},"010539a1-4c3a-4bd3-937a-26616422ee0d","awesome-ai-for-science-research-tools-map-en","Awesome AI for Science Is Becoming a Real Research Map","2026-03-27T01:46:50.89513+00:00"]