fixes: fix dark scheme & port from legacy blog

My old blog only ever had 1 post, but its a good place to start.

astro.config.mjs

@@ -21,7 +21,7 @@ export default /** @type {import('astro').AstroUserConfig} */ ({
   // outDir: './dist',       // When running `astro build`, path to final static output
   // publicDir: './public',   // A folder of static files Astro will copy to the root. Useful for favicons, images, and other files that don’t need processing.
 
-  site: 'https://astro-ink.vercel.app', // Your public domain, e.g.: https://my-site.dev/. Used to generate sitemaps and canonical URLs.
+  site: 'https://nrd.sh',
   server: {
     // port: 3000,         // The port to run the dev server on.
   },

nix/automation/devshells.nix

@@ -6,7 +6,7 @@
   inherit (inputs.std) std;
 in {
   default = std.lib.mkShell {
-    name = "blg.nrd.sh";
+    name = "nrd.sh";
     imports = [std.devshellProfiles.default];
     commands = [
       {package = cell.packages.astro;}
@@ -14,7 +14,7 @@ in {
       {package = pkgs.nodePackages_latest.node2nix;}
       {package = pkgs.nodePackages_latest.svgo;}
       {package = pkgs.nodePackages_latest.yarn;}
-      {package = pkgs.pngout;}
+      {package = pkgs.pngcrush;}
       {package = pkgs.libwebp;}
     ];
   };

package.json

@@ -25,10 +25,9 @@
     "globby": "^13.1.2",
     "gray-matter": "^4.0.3",
     "lunr": "^2.3.9",
-    "mdx": "^0.3.1",
+    "mdx": "^0.2.3",
     "svelte": "^3.50.0",
     "tailwindcss": "^3.0.24",
     "typescript": "^4.3.5"
-  },
+  }
-  "dependencies": {}
 }

public/site.webmanifest

@@ -1,6 +1,6 @@
 {
-    "name": "Astro Ink",
+    "name": "nrdlg",
-    "short_name": "Astro Ink",
+    "short_name": "nrdlg",
     "icons": [
         {
             "src": "/android-chrome-192x192.png",

src/components/Footer.astro

@@ -5,8 +5,8 @@
 ---
 <footer class="footer">
     <nav class="nav">
-        <div>2021  &copy; Copyright notice |  <a href={ SITE.githubUrl } title={`${ SITE.name }'s Github URL'`}>{ SITE.name }</a>
+        <div>2021  &copy; Copyright notice |  <a href={ SITE.githubUrl } title={`${ SITE.ghUser }'s Github URL'`}>{ SITE.name }</a>
-        <ModeLabel client:load/> theme on <a href="https://astro.build/">Astro</a></div>
+        <ModeLabel client:load/> built with <a href="https://astro.build/">Astro</a></div>
         <NetlifyIdentity client:load/>
     </nav>
 </footer>

src/components/Header.astro

@@ -26,7 +26,7 @@
                         <SearchBtn client:visible />
                     </li>
                     <li>
-                        <a href={ SITE.githubUrl } title={`${ SITE.name }'s Github URL'`}>
+                        <a href={ SITE.githubUrl } title={`${ SITE.ghUser }'s Github URL'`}>
                             <SvgIcon>
                                 <path d="M9 19c-5 1.5-5-2.5-7-3m14 6v-3.87a3.37 3.37 0 0 0-.94-2.61c3.14-.35 6.44-1.54 6.44-7A5.44 5.44 0 0 0 20 4.77 5.07 5.07 0 0 0 19.91 1S18.73.65 16 2.48a13.38 13.38 0 0 0-7 0C6.27.65 5.09 1 5.09 1A5.07 5.07 0 0 0 5 4.77a5.44 5.44 0 0 0-1.5 3.78c0 5.42 3.3 6.61 6.44 7A3.37 3.37 0 0 0 9 18.13V22"></path>
                             </SvgIcon>
@@ -55,7 +55,7 @@
         @apply flex gap-4 border-b py-3 /* border-gray-200 dark:border-gray-700 - check styles/global.css */
     }
     .header__logo-img {
-        @apply w-16 h-16 rounded-full overflow-hidden
+        @apply w-24 h-24 rounded-full overflow-hidden
     }
     .header__title {
         @apply text-4xl font-extrabold md:text-5xl text-theme-secondary dark:text-theme-dark-secondary

src/config.ts

@@ -13,10 +13,10 @@ export const NAV_ITEMS: NavItems = {
         path: '/tags',
         title: 'tags'
     },
-    media: {
+    // media: {
-        path: '/media',
+    //     path: '/media',
-        title: 'media'
+    //     title: 'media'
-    },
+    // },
     about: {
         path: '/about',
         title: 'about'
@@ -24,11 +24,11 @@ export const NAV_ITEMS: NavItems = {
 }
 
 export const SITE = {
-    // Your site's detail?
+    name: 'nrdlg',
-    name: 'nrdlog',
+    title: 'nrdlg',
-    title: 'nrdxp - blog',
     description: 'Personal blog of Tim DeHerrera',
-    url: 'https://blg.nrd.sh',
+    url: 'https://nrd.sh',
+    ghUser: 'nrdxp',
     githubUrl: 'https://github.com/nrdxp',
     listDrafts: false
 }

src/data/astro-media.json

@@ -1,34 +1,2 @@
 [
-    {
-        "title": "Ship Less JavaScript with Astro",
-        "description": "Astro is a way to build websites that ships zero JavaScript by default. Only add JS when you need it for maximum performance! Fred K. Schott will teach us how it works.",
-        "url": "https://youtu.be/z15YLsLMtu4?list=PLz8Iz-Fnk_eTpvd49Sa77NiF8Uqq5Iykx",
-        "host": "Jason Lengstorf",
-        "participants": ["Fred K. Schott"],
-        "date": "2021-05-08"
-    },
-    {
-        "title": "Astro: A New Architecture for the Modern Web",
-        "description": "JavaScript meetup for mad science, hacking, and experiments. Hang out virtually on Friday at 4pm Pacific Time each week.",
-        "url": "https://www.youtube.com/watch?v=mgkwZqVkrwo",
-        "host": "Feross",
-        "participants": ["Fred K. Schott"],
-        "date": "2021-06-08"
-    },
-    {
-        "title": "Astro in 100 Seconds",
-        "description": "Astro is an open-source tool that can build static HTML websites using popular frontend JavaScript frameworks (React, Vue, Svelte), while loading fully interactive components as needed https://github.com/snowpackjs/astro",
-        "url": "https://www.youtube.com/watch?v=dsTXcSeAZq8",
-        "host": "Jeff Delaney",
-        "participants": [],
-        "date": "2021-07-12"
-    },
-    {
-        "title": "Yapping About Astro",
-        "description": "Build a static-by-default site using JavaScript components and only load whatever JavaScript you need by opting in very carefully.",
-        "url": "https://www.youtube.com/watch?v=3jPaidbpUIA",
-        "host": "Chris Coyier",
-        "participants": [],
-        "date": "2021-08-07"
-    }
 ]

src/layouts/post-draft.astro

@@ -18,7 +18,7 @@ const { content } = Astro.props
             </div>
             <h1 class="post__title">{ content.title }</h1>
             <h5 class="post__desc">
-                <a class="post__author" href={`https://twitter.com/${content.authorTwitter}`} title={`${content.author + "'s"} twitter`} target="_blank" rel="external">{ content.author }</a> |
+                <a class="post__author" href={`https://github.com/${content.authorGitHub}`} title={`${content.author + "'s"} GitHub`} target="_blank" rel="external">{ content.author }</a> |
                 <span class="post__date">{ new Intl.DateTimeFormat('en-US', { dateStyle: 'full' }).format(new Date(content.date))}</span>
             </h5>
         </div>

src/layouts/post.astro

@@ -18,7 +18,7 @@ const { content } = Astro.props
             </div>
             <h1 class="post__title">{ content.title }</h1>
             <h5 class="post__desc">
-                <a class="post__author" href={`https://twitter.com/${content.authorTwitter}`} title={`${content.author + "'s"} twitter`} target="_blank" rel="external">{ content.author }</a> |
+                <a class="post__author" href={`https://github.com/${content.authorGithub}`} title={`${content.author + "'s"} GitHub`} target="_blank" rel="external">{ content.author }</a> |
                 <span class="post__date">{ new Intl.DateTimeFormat('en-US', { dateStyle: 'full' }).format(new Date(content.date))}</span>
             </h5>
         </div>

src/pages/about.mdx

@@ -1,18 +1,20 @@
 ---
 title: 'About'
-description: 'There is a simple secret to building a faster website — just ship less.'
+description: 'Letters for Humans & Computers'
 ---
 import DefaultPageLayout from '$/layouts/default.astro'
 import Prose from '$/components/Prose.astro'
 
 <DefaultPageLayout content={{ title: frontmatter.title, description: frontmatter.description }}>
     <Prose>
-            Astro-Ink is a crisp, minimal, personal blog theme for Astro, that shows the capability of statically built sites - offering all the goodness and DX of the modern JS ecosystem without actually shipping any JS by default. It's built by...
+        Drinks waaay too much coffee and sometimes it helps; currently an SRE at [IOG](https://iog.io).
 
-            ## Few Bots, Meta-humans & a Guy!
+        Timothy DeHerrera // [@timdeh:matrix.org](https://matrix.org)  // [nrdxp](https://github.com/nrdxp)
-Aftab Alam // [@aftabbuddy](https://twitter.com/aftabbuddy)  // [one-aalam](https://github.com/one-aalam)
+
+        ##
             <div class="author">
-                <img class="rounded-full" width="160" src="https://assets.website-files.com/5e51c674258ffe10d286d30a/5e5358878e2493fbea064dd9_peep-59.svg" title="Aalam" />
+                <img class="rounded-full" width="160" src="https://avatars.githubusercontent.com/u/34083928?v=4" title="Tim" />
             </div>
+        fingerprint: [5471 8D2B 78DC AA9C 7702  96F1 8985 725D B5B0 C122](https://github.com/nrdxp.gpg)
     </Prose>
 </DefaultPageLayout>

src/pages/blog/NixOS-Flakes_and_KISS.md

@@ -0,0 +1,268 @@
+---
+layout: $/layouts/post.astro
+title: NixOS, Flakes and KISS
+description: A simpler way to manage the OS Layer
+tags:
+  - nix
+author: Tim D
+authorGithub: nrdxp
+date: 2020-12-19
+---
+
+## Introduction
+
+This marks the first post of my very own developer blog, and it comes much later
+than I had originally anticipated thanks to the ongoing pandemic, coupled with
+some unforeseen life challenges. My original intent was to start by introducing
+the concept of Nix Flakes, however, an excellent blog series over at
+[tweag.io](https://www.tweag.io/blog/2020-05-25-flakes) has emerged, expanding
+on just that premise. If you are new to flakes, it is highly recommended that
+you check it out before continuing with this post.
+
+Now, I'd like to introduce a project I've been slowly building up since
+flakes were introduced called [DevOS][DevOS].
+
+# So what is it anyway?
+
+After years of working with NixOS, I strongly felt that the community as a whole
+could benefit from a standardized structure and format for NixOS configurations
+in general. It appears that every developer is  essentially reinventing the
+wheel when it comes to the "shape" of their deployments, leading to a lot of
+confusion as to what the idioms and best practices should be, especially for
+newcomers.
+
+Having a mind share to collect the best ideas concerning structure and
+method would be valuable, not only for its pragmatic implications, but also to
+help ease adoption and onboarding for new NixOS users; something that has
+traditionally been difficult up to now.
+
+Of course this really hinges on wider community support, as my ideas alone
+definitely shouldn't be the final word on what constitutes a correct and well
+organized NixOS codebase. Rather, I am hoping to cajole the community forward
+by providing useful idioms for others to expand on.
+
+Even if my ideas lose out in the end, I sincerely hope they will, at the very
+least, push the community toward some level of consensus in regards to the way
+NixOS code repositories are structured and managed.
+
+That said, DevOS appears to be gaining a bit of popularity among new flake
+adopters and I am really quite excited and humbled to see others engage the
+repository. If you have contributed to the project, thank you so much for your
+time and support!
+
+# An Arch KISS
+
+I moved over to NixOS after a decades long love affair with Arch Linux. I found
+their brand of KISS to be pragmatic and refreshing compared to alternatives
+such as Ubuntu or Red Hat. This isn't to dog on those distributions, which I
+also have used and enjoyed for years, but rather to accentuate my affection
+for the simplified, and developer focused workflow that Arch Linux enabled for
+my work stations.
+
+However, over the years, I came to resent the several hours of tedious work
+spent doing what amounted to the same small tasks over and over, any time
+issues arose.
+
+My first attempt to alleviate some of this work was by using Ansible to deploy
+my common configuration quickly whenever it became necessary. However, I ran
+into a ton of issues as the Arch repositories updated, and my configurations
+inevitably became stale. Constant, unexpected breakage became a regular
+nuisance.
+
+I then became aware of Nix and NixOS, and hoped that it would live up the
+promise of reproducible system deployment, and after a brief stint of
+procrastination, I dove head first.
+
+# Great but Not Perfect.
+
+At first everything seemed almost perfect. NixOS felt like Ansible on steroids,
+and there was more than enough code available in nixpkgs to meet my immediate
+needs. Getting up to speed on writing derivations and modules was fairly
+straightforward and the DevOps dream was in sight.
+
+It wasn't all sunshine and rainbows, as channel updates sometimes caused
+the same sort of breakage I moved to NixOS to avoid. But simple generation
+rollbacks were a much more welcome interface to this problem than an unbootable
+system. It was a measurable improvement from the busy work experienced with Arch. All in all, I felt it was
+well worth the effort to make the transition.
+
+It wasn't long before the [rfc][rfcs] that eventually became flakes emerged.
+It seemed like the solution to many of my few remaining gripes with my
+workflow. An officially supported and simple way to lock in a specific revision
+of the entire system. No more unexpected and unmanaged breakage!
+
+Of course it took a while for an experimental implementation to arrive, but I
+found myself digging into the Nix and Nixpkgs PR's to see how flakes worked
+under the hood.
+
+Around the same time, the ad hoc nature of my NixOS codebase was starting to
+bug at me, and I wanted to try my hand at something more generalized and
+composable across machines. I had a first iteration using the traditional
+"configuration.nix", but ended up feeling like the whole thing was more
+complex than it really needed to be.
+
+My eagerness to get started using flakes was the perfect excuse to start from
+scratch, and so began DevOS. An attempt to address my concerns, using flakes.
+
+## How does it work?
+
+First and foremost, I want to point out that the bulk of the credit goes to the
+amazing engineer's who have designed and implemented Nix and the ecosystem
+as a whole over the last decade.
+
+I see a lot of new users struggling to dive in and get up to speed with the Nix
+language, and particularly, getting up and running with a usable and productive
+system can take some serious time. I know it did for me.
+
+The hope for DevOS is to alleviate some of that pain so folks can get to
+work faster and more efficiently, with less frustration and more enthusiasm for
+the power that Nix enables. I especially don't want anyone turning away from
+our amazing ecosystem because their onboarding experience was too complex
+or overwhelming.
+
+# Everything is a profile!
+
+At the heart of DevOS is the [profile][profiles]. Of course, these profiles
+are really nothing more than good ol' NixOS [modules][modules]. The only reason
+I've decided to rebrand them at all is to draw a distinction in how they are
+used. They are kept as simple as possible on purpose; if you understand modules
+you don't _really_ have anything new to learn.
+
+The only limitation is that a profile should never declare any new NixOS module
+options, we can just use regular modules for that elsewhere. Instead, they
+should be used to encapsulate any configuration which would be useful for more
+than one specific machine.
+
+To put it another way, instead of defining my entire NixOS system in a
+monolithic module, I break it up into smaller, reusable profiles which can
+be themselves be made up of profiles. Composability is key here, as I don't
+necessarily want to use every profile on every system I deploy.
+
+As a concrete example, my [develop][develop], profile pulls in my preferred
+developer tools such as my shell, and text editor configurations. It can be
+thought of as a meta-profile, made up of smaller individual profiles. I can
+either pull in the whole thing, which brings all the dependent profiles along
+with it, or I can just import a single profile from within, say my zsh
+configuration, leaving all the rest unused. Every profile is a directory with
+a "default.nix" defining it. You can have whatever else you need inside the
+folder, so long as it is directly related to the profile.
+
+Let's draw the obvious parallel to the Unix philosophy here. Profiles work
+best when they do one thing, and do it well. Don't provision multiple programs
+in one profile, instead split them up into individual profiles, and then if you
+often use them together, import them both in a parent profile. You can simply
+import dependent profiles via the "imports" attribute as usual, ensuring
+everything required is always present.
+
+The key is this, by simply taking what we already know, i.e. NixOS modules, and
+sticking to the few simple idioms outlined above, we gain composability and
+reusability without actually having to learn anything new. I want to drill this
+point home, because that's really all there is to DevOS!
+
+Besides a few simple convenience features outlined below, profiles are the star
+of the show. It's really nothing revolutionary, and that's on purpose! By
+keeping things simple and organized we gain a level of control and granularity
+we wouldn't have otherwise without adding real complexity to speak of.
+
+# Really? Everything?
+
+Yes! Thanks to built in [home-manager][home-manager] integration, users are
+profiles, a preferred graphical environment is a profile. Anything that you
+could imagine being useful on more than one machine is a profile. There are
+plenty of examples available in the "profiles" and "users" directories, and
+you can check out my personal "nrd" branch, if you want to see how I do things
+on my own machines.
+
+# Anything else I should know?
+
+As mentioned briefly above, DevOS also has some convenience features to make
+life easier.
+
+For starters, you might be wondering how we actually define a configuration for
+a specific machine. Simple, define the machine specific bits in a nix file
+under the [hosts][hosts] directory and import any relevant profiles you wish to
+use from there. The flake will automatically import any nix files in this folder as NixOS
+configurations available to build. As a further convenience, the hostname of
+your system will be set to the filename minus the ".nix" extension. This makes
+future "nixos-rebuilds" much easier, as it defaults to looking up your current
+hostname in the flake if you don't specify a configuration to build explicitly.
+
+Now what if we actually just want to define a NixOS module that does declare
+new NixOS options, you know, the old fashioned way? We'll also want to define
+our own pkgs at some point as well. These are both structured closely to how
+you might find them in the nixpkgs repository itself. This is so that you can
+easily bring your package or module over to nixpkgs without much modification
+should you decide it's worth merging upstream.
+
+So, you'd define a package or module the exact same way you would in nixpkgs
+itself, but instead of adding it to all-packages.nix or module-list.nix, you add
+it to pkgs/default.nix and modules/list.nix. Anything pulled in these two files
+will become available in any machine defined in the hosts directory, as well as
+to other flakes to import from DevOS!
+
+This setup serves a dual purpose. For people who already know the nixpkgs
+workflow, it's business as usual, and for individuals who aren't familiar with
+nixpkgs but wish to become so, they can quickly get up to speed on how to add
+packages and modules themselves, in the exact same way they would do so upstream
+proper.
+
+Now what about overlays? Well, any overlay defined in a nix file under the
+overlays directory will be automatically imported, just as with packages and
+modules, and are available to all hosts, as well as to other flakes.
+
+What if I want to pull a specific package from master instead of from the
+stable release? There is a special file, pkgs/override.nix. Any package listed
+here will be pulled from nixpkgs unstable rather than the current stable release.
+Simple, easy.
+
+What about cachix? It's super easy to add your own cachix link just as you
+would a regular NixOS configuration. As a bonus, it will be wired up as a flake
+output so other people can pull in your link directly from your flake! My
+personal cachix repo is setup by default. It provides the packages the flake
+exports so you don't have to build them.
+
+That should just about do it for DevOS's current quality of life features, but
+there are more ideas brewing.
+
+# What's next?
+I'm working on a system for seamlessly importing modules, packages and
+overlays from other flakes, which isn't too hard as it is, but it's messy
+because the current "flake.nix" has a lot of business logic that gets in the way.
+
+Also, I would like to start programmatically generating documentation for
+everything. So users can quickly find what goes where and not have to read
+drawn out blog posts like this to get started. 😛 Nixpkgs is currently
+transitioning to CommonMark for all documentation, and we will probably follow
+suite.
+
+Additionally, I want to implement an easy way to actually install NixOS on the
+bare metal from directly within the project. I know the [deploy-rs][deploy-rs]
+project is working on this, and I'm interested in supporting their project
+in DevOS so as to add extra flexibility and power to installation and
+deployment!
+
+Also, certain parts of the flake should be tested to ensure things don't break.
+We really have no tests to speak of as is. The auto import functions for the
+"hosts" and "overlays" directory are good examples.
+
+## A call to arms!
+If you'd like to help, please jump in. I am very much open to any ideas that
+could reduce the complexity or simplify the UI. If you have a profile you
+believe would be useful to others, please open a [Pull Request][pr].
+
+If you think I am crazy and wasting my time, please don't hesitate to say so! I
+typically find critical feedback to be some of the most helpful. Most of all,
+if you made it this far, thanks for taking some time to read about my efforts
+and please consider giving DevOS a shot!
+
+
+[nix]: https://nixos.org
+[DevOS]: https://github.com/divnix/DevOS
+[rfcs]: https://github.com/NixOS/rfcs
+[modules]: https://nixos.org/manual/nixos/stable/index.html#sec-writing-modules
+[profiles]: https://github.com/divnix/devos/tree/template/profiles
+[develop]: https://github.com/divnix/devos/tree/template/profiles/develop
+[hosts]: https://github.com/divnix/devos/tree/template/hosts
+[deploy-rs]:  https://serokell.io/blog/deploy-rs
+[home-manager]: https://github.com/nix-community/home-manager
+[pr]: https://github.com/divnix/devos/pulls

src/pages/blog/hihiiiiii.md

@@ -1,11 +0,0 @@
----
-layout: $/layouts/post.astro
-title: hihiiiiii
-description: lol
-tags:
-  - test
-author: me
-authorTwitter: me
-date: 2022-10-30T11:25:18.276Z
----
-hid

src/pages/blog/introducing-astro-ship-less-javascript-1.md

@@ -1,65 +0,0 @@
----
-layout: $/layouts/post.astro
-title: Introducing Astro - Ship Less JavaScript1
-description: There's a simple secret to building a faster website — just ship less.
-tags:
-  - astro
-  - jam-stack
-author: Fred K. Schott
-authorTwitter: FredKSchott
-date: 2022-09-28T10:23:31.210Z
-image: https://images.unsplash.com/photo-1589409514187-c21d14df0d04?ixid=MnwxMjA3fDB8MHxwaG90by1wYWdlfHx8fGVufDB8fHx8&ixlib=rb-1.2.1&auto=format&fit=crop&w=1650&q=80
-category: design
----
-
-Unfortunately, modern web development has been trending in the opposite direction—towards more. More JavaScript, more features, more moving parts, and ultimately more complexity needed to keep it all running smoothly.
-
-Today I'm excited to publicly share Astro: a new kind of static site builder that delivers lightning-fast performance with a modern developer experience. To design Astro, we borrowed the best parts of our favorite tools and then added a few innovations of our own, including:
-
-- Bring Your Own Framework (BYOF): Build your site using React, Svelte, Vue, Preact, web components, or just plain ol' HTML + JavaScript.
-- 100% Static HTML, No JS: Astro renders your entire page to static HTML, removing all JavaScript from your final build by default.
-- On-Demand Components: Need some JS? Astro can automatically hydrate interactive components when they become visible on the page. If the user never sees it, they never load it.
-- Fully-Featured: Astro supports TypeScript, Scoped CSS, CSS Modules, Sass, Tailwind, Markdown, MDX, and any of your favorite npm packages.
-- SEO Enabled: Automatic sitemaps, RSS feeds, pagination and collections take the pain out of SEO and syndication.
-
-## H1 is good
-
-### H2 is good too
-
-> links are better
-
-[I know](they-are-better)
-
-This post marks the first public beta release of Astro. Missing features and bugs are still to be expected at this early stage. There are still some months to go before an official 1.0 release, but there are already several fast sites built with Astro in production today. We would love your early feedback as we move towards a v1.0 release later this year.
-
-> To learn more about Astro and start building your first site, check out the project README.
-
-# Example - Syntax Highlighting
-
-## Shell(Bash)
-
-```bash
-# make a new project directory and jump into it
-mkdir my-astro-project && cd $_
-
-# create a new project with npm
-npm create astro@latest
-
-# or yarn
-yarn create astro
-
-# or pnpm
-pnpm create astro@latest
-```
-
-## Python
-
-```python
-print('hello world')
-```
-
-## Javascript
-
-```js
-const func = () => {alert("hello")}
-```

src/pages/blog/introducing-astro-ship-less-javascript.md

@@ -1,65 +0,0 @@
----
-layout: $/layouts/post.astro
-title: Introducing Astro - Ship Less JavaScript
-description: There's a simple secret to building a faster website — just ship less.
-tags:
-  - astro
-  - jam-stack
-author: Fred K. Schott
-authorTwitter: FredKSchott
-date: 2022-09-18T13:10:23.402Z
-image: https://images.unsplash.com/photo-1589409514187-c21d14df0d04?ixid=MnwxMjA3fDB8MHxwaG90by1wYWdlfHx8fGVufDB8fHx8&ixlib=rb-1.2.1&auto=format&fit=crop&w=1650&q=80
-category: design
----
-
-Unfortunately, modern web development has been trending in the opposite direction—towards more. More JavaScript, more features, more moving parts, and ultimately more complexity needed to keep it all running smoothly.
-
-Today I'm excited to publicly share Astro: a new kind of static site builder that delivers lightning-fast performance with a modern developer experience. To design Astro, we borrowed the best parts of our favorite tools and then added a few innovations of our own, including:
-
-- Bring Your Own Framework (BYOF): Build your site using React, Svelte, Vue, Preact, web components, or just plain ol' HTML + JavaScript.
-- 100% Static HTML, No JS: Astro renders your entire page to static HTML, removing all JavaScript from your final build by default.
-- On-Demand Components: Need some JS? Astro can automatically hydrate interactive components when they become visible on the page. If the user never sees it, they never load it.
-- Fully-Featured: Astro supports TypeScript, Scoped CSS, CSS Modules, Sass, Tailwind, Markdown, MDX, and any of your favorite npm packages.
-- SEO Enabled: Automatic sitemaps, RSS feeds, pagination and collections take the pain out of SEO and syndication.
-
-## H1 is good
-
-### H2 is good too
-
-> links are better
-
-[I know](they-are-better)
-
-This post marks the first public beta release of Astro. Missing features and bugs are still to be expected at this early stage. There are still some months to go before an official 1.0 release, but there are already several fast sites built with Astro in production today. We would love your early feedback as we move towards a v1.0 release later this year.
-
-> To learn more about Astro and start building your first site, check out the project README.
-
-# Example - Syntax Highlighting
-
-## Shell(Bash)
-
-```bash
-# make a new project directory and jump into it
-mkdir my-astro-project && cd $_
-
-# create a new project with npm
-npm create astro@latest
-
-# or yarn
-yarn create astro
-
-# or pnpm
-pnpm create astro@latest
-```
-
-## Python
-
-```python
-print('hello world')
-```
-
-## Javascript
-
-```js
-const func = () => {alert("hello")}
-```

src/pages/blog/introducing-astro.md

@@ -1,35 +0,0 @@
----
-layout: $/layouts/post.astro
-title: Introducing Astro - Ship Less JavaScript
-date: 2021-06-08
-image: https://images.unsplash.com/photo-1589409514187-c21d14df0d04?ixid=MnwxMjA3fDB8MHxwaG90by1wYWdlfHx8fGVufDB8fHx8&ixlib=rb-1.2.1&auto=format&fit=crop&w=1650&q=80
-author: Fred K. Schott
-authorTwitter: FredKSchott
-category: design
-tags:
-- astro
-- jam-stack
-description: There's a simple secret to building a faster website — just ship less.
----
-
-Unfortunately, modern web development has been trending in the opposite direction—towards more. More JavaScript, more features, more moving parts, and ultimately more complexity needed to keep it all running smoothly.
-
-Today I'm excited to publicly share Astro: a new kind of static site builder that delivers lightning-fast performance with a modern developer experience. To design Astro, we borrowed the best parts of our favorite tools and then added a few innovations of our own, including:
-
-- Bring Your Own Framework (BYOF): Build your site using React, Svelte, Vue, Preact, web components, or just plain ol' HTML + JavaScript.
-- 100% Static HTML, No JS: Astro renders your entire page to static HTML, removing all JavaScript from your final build by default.
-- On-Demand Components: Need some JS? Astro can automatically hydrate interactive components when they become visible on the page. If the user never sees it, they never load it.
-- Fully-Featured: Astro supports TypeScript, Scoped CSS, CSS Modules, Sass, Tailwind, Markdown, MDX, and any of your favorite npm packages.
-- SEO Enabled: Automatic sitemaps, RSS feeds, pagination and collections take the pain out of SEO and syndication.
-
-## H1 is good
-
-### H2 is good too
-
-> links are better
-
-[I know](they-are-better)
-
-This post marks the first public beta release of Astro. Missing features and bugs are still to be expected at this early stage. There are still some months to go before an official 1.0 release, but there are already several fast sites built with Astro in production today. We would love your early feedback as we move towards a v1.0 release later this year.
-
-> To learn more about Astro and start building your first site, check out the project README.

src/pages/blog/islands-architecture.md

@@ -1,16 +0,0 @@
----
-layout: $/layouts/post.astro
-title: Islands Architecture
-date: 2021-05-08
-image: https://images.unsplash.com/photo-1502085671122-2d218cd434e6?ixid=MnwxMjA3fDB8MHxwaG90by1wYWdlfHx8fGVufDB8fHx8&ixlib=rb-1.2.1&auto=format&fit=crop&w=1698&q=80
-author: Jason Miller
-authorTwitter: _developit
-category: development
-tags:
-- astro
-- jam-stack
-- architecture
-- front-end
-description: Render HTML pages on the server, and inject placeholders or slots around highly dynamic regions.
----
-https://jasonformat.com/islands-architecture/

src/pages/blog/spa-fatigue.md

@@ -1,15 +0,0 @@
----
-layout: $/layouts/post.astro
-title: Second-guessing the modern web
-date: 2021-04-10
-image: https://images.unsplash.com/photo-1501772418-b33899635bca?ixid=MnwxMjA3fDB8MHxwaG90by1wYWdlfHx8fGVufDB8fHx8&ixlib=rb-1.2.1&auto=format&fit=crop&w=1650&q=80
-author: Tom MacWright
-authorTwitter: tmcw
-category: design
-tags:
-- architecture
-- front-end
-- spa
-description: There is a sweet spot of React - in moderately interactive interfaces..
----
-https://macwright.com/2020/05/10/spa-fatigue.html

src/pages/drafts/std.md

@@ -0,0 +1,70 @@
+---
+layout: $/layouts/post.astro
+title: From DevOS to Standard
+description: Why we made Standard, and what it has done for us.
+tags:
+  - std
+  - nix
+  - devops
+author: Tim D
+authorGithub: nrdxp
+date: 2022-10-31
+---
+
+## Two years later...
+DevOS started as a fun project to try and get better with Nix and understand this weird new thing
+called flakes. Since then and despite their warts, Nix flakes have experienced widespread use, and
+rightfully so, as a mechanism for hermetically evaluating your system & packages that fully locks
+your inputs.
+
+Yet when I first release it, I never even imagined so many people would find DevOS useful, and I
+have been truly humbled by all the support and contributions that came entirely spontaneously to the
+project and ultmately culminated in the current version of digga, and the divnix org that maintains
+it.
+
+
+## Back to Basics
+For whatever reason, it really feels like time to give a brief update of what has come of this
+little community experiment, and I'm excited to hopefully clear up some apparent confusion, and
+hopefully properly introduce to the world [Standard](https://github.com/divnix/std).
+
+DevOS was never meant to be an end all be all, but rather a heavily experimental sketch while
+I stumbled along to try an organize my Nix code more effectively. With Standard, we are able to
+distill the wider experience of some of the largest contributors and design something a little more
+focused and hopefully less magical, while still eliminating a ton of boilerplate. Offering both a
+lightly opinionated way to organize your code into logically typed units, and a mechanism for
+defining "standard" actions over units of the same type.
+
+Other languages make this simple by defining a module mechanism into the language where users are
+freed from the shackles of decision overload by force, but Nix has no such advantage. Many people
+hoped and even expected flakes to alleviate this burden, but other than the schema Nix expects
+over its outputs, it does nothing to enforce how you can generate those outputs, or how to organize
+the logical units of code & configuration that generate them.
+
+Many people point to the nixpkgs module system as the sort of "goto" means of managing
+configuration, and while this may be true at the top-level where a global namespace is sometimes
+desirable, it doesn't really give us a generic means of sectioning off our code to generate both
+configuration _and_ derivation outputs quickly.
+
+In addition to that, the module system is fairly complex and is a bit difficult to anticate the
+cost of ahead of time due to the fixed-point. The infamous "infinite traces" that can occur during
+a Nix module evaluation almost never point to the actual place in your code where the error
+originates, and often does even contain a single bit of code from the local repository in the trace.
+
+## A Departure from Tradition
+As the only real game in town, the module system has largely "de facto" dictated the nature
+of how we organize our Nix code up til now. It lends itself to more of a "depth first" approach
+where modules can recurse into other modules ad infinitum. Standard, in contrast, tries to take an
+alternative "breadth first" approach, ecouraging code organization closer to the project root. If
+true depth is called for, flakes using Standard can compose gracefully with other flakes using it
+_and_ those that don't.
+
+For a small project with a single package and maybe one Nix shell to develop it, "Standard" may
+not be entirely necessary, though hopefully not overly encumbering either. But for projects like
+even nixpkgs itself, that have branched off into hundreds or even thousands of project specifc
+derivations, Standard can be invaluable in keeping the complexitly of those interelated pieces
+maintainable over the long term.
+
+## A New Challenger Approaches
+
+TODO

src/pages/media.astro

@@ -1,13 +1,12 @@
 ---
 import DefaultPageLayout from '$/layouts/default.astro'
 import MediaPreviewList from '$/components/MediaPreviewList.astro'
-// import posts from '$/data/astro-media.json'
+import posts from '$/data/astro-media.json'
 
-let title = 'Videos & Screencasts';
+let title = 'Under Construction';
-let description = 'All the great videos on Astro we could find for ya!'
+let description = 'Nothing to see here folks'
 
-const response = await fetch('https://raw.githubusercontent.com/one-aalam/astro-ink/main/src/data/astro-media.json')
+const allPosts = await posts
-const allPosts = await response.json()
 const sortedPosts = allPosts.sort((a, b) => new Date(b.date) - new Date(a.date))
 ---
 <DefaultPageLayout content={{ title, description }}>