Over the years, I've learned not to question inspiration. To simply let it drive when it shows up with a full tank. Quite often, I don't exactly know where we're going or even why we're going, but it's repeatedly taken me to just the right place at just the right time, so now I just hop in and say: Let's go! Case in point: Arch + Hyprland. It's been over a year since I created Omakub to smooth out my own exit path from macOS to Linux, and in the process, helped thousands of others enjoy a beautiful, preconfigured, and relatively familiar desktop experience with Ubuntu. And I continue to think this is an excellent choice for Linux, especially for first-time Mac and Windows defectors. But this weekend, I just happened to be home alone, and the hype around Arch + Hyprland got the better of me. While Ubuntu is all about being a friendly place for newcomers to Linux, Arch + Hyprland is the exact opposite: It's Linux on hard mode!  At least that's the reputation, and there's certainly something to that. The Arch ISO literally just dumps you into a terminal with scarcely any direction. Just getting on the Wi-Fi requires learning the arcane command-line options for the iwctl terminal configurator. But besides iwctl, it's actually not that bad anymore. We now have a cheat code for installing Arch in the form of archinstall. It's a terminal interface for getting all the bits like picking a disk and creating the first user done in the correct order, without having to set aside an entire evening just to get the OS installed. So it didn't take long to get Arch up and running. That doesn't get you much further, though! By default, Arch is about as minimal as it gets. There's no default graphical interface. There are no niceties. Not even wget or curl by default! It really is just a bare-bones installation of Linux. But on the other hand, Arch is blessed with the AUR — a Wikipedia-style, community-maintained package management system that seems to have literally every piece of software ever released on Linux, and always in the latest version. A quarter of Omakub is trying to work around the fact that helpful tools like Alacritty or LazyGit or whatever rarely have official packages for Ubuntu, so you're left doing a lot of manual scripting to get everything a developer would want from a modern Linux setup. Not so with the AUR! So that's Arch. But Hyprland is even more hilarious. It's a tiling window manager with something as rare in the Linux world as a keen focus on aesthetics! It looks like it was written by visual artists rather than neckbeards. And it's at the core of the modern r/unixporn Linux ricing subculture. That's not the funny part, though. The funny part is how ridiculously atomized the entire thing is. Hyprland comes with absolutely nothing out of the box. No login screen, no menu bar, no notification system, no file manager, no visual settings application. Just a text-based configuration file, a wiki, and an outline on a map for how to design your own adventure. This means that if you're interested in running Hyprland, and you intend to set it all up from scratch, you're probably signing up for at least a good 10+ hours — just to install and configure everything! Now, there are some precompiled setup scripts out there already, but most of them still require you to do a ton of manual legwork before you reach that beautiful summit of a complete system. So while the downside of Arch + Hyprland is that literally every last detail requires you to make a choice and a config file to move on, it's also its upside: you can change EVERYTHING! And the core window tiling magic of Hyprland is one of the most intoxicating ways of using a computer that I've ever experienced. It looks amazing; it feels amazing (if you prefer using a keyboard instead of a mouse!). I've poured hours and hours into this quest over the weekend, and yet I'm still not even done with my first Arch + Hyprland build! My login screen looks like shit. I haven't decided on a final menu bar configuration. But what is working — the basic tiling flow and look — is so nice that the inspiration keeps driving the project forward. Which, of course, I've already decided to codify. I'm not going through all this work to set up a beautiful, preconfigured, fully-functional, out-of-the-box Arch + Hyprland combo and then not share it with anyone who's curious (and might not have 10–20 hours for this kind of side quest available in their schedule). So of course I registered a domain and found a way to draw some ASCII art: Omarchy is on the way!

Three years ago, Kagi officially launched with a splash on popular technology forum Hacker News (to which we are eternally grateful for helping put Kagi on the map).

Questionable puns aside, it’s Pride Month and we’re excited to celebrate by bringing you these updates hand-made by real LGBTQIA+ community members from around the world!—and possibly some straight cis folks too. This rainbow of releases includes some important accessibility updates, tons of bug fixes, and of course a few new features. Window Manager & Dock Another absolutely massive release of our window manager is out that fixes about 20 reported issues and a brand new Gesture Controller thanks to Leonhard and Leo. You can now Swipe up in Multitasking View to close windows, app titles in Multitasking View are now always shown—making them accessible for touch screen setups—and screenshots taken with a keyboard shortcut will send a notification that you can use to view it in Files, just to name a few headlining features. If you want to read the full release notes, Good Luck Babe they’re quite long. A new release of our Dock is also out which brings back a couple of old Plank features: showing multiple dots for apps with multiple running windows and cycling through app windows when you hold a drag-n-drop over its icon. Plus you can now open context menus with a long-press. And there’s a number of bug fixes including things related to hide modes and memory usage. Thanks again to Leo and Leonhard for their hard work here. System Settings Leonhard fixed a crash when setting custom hotcorner commands and we now only show the Applications Menu hotcorner action in its corresponding panel corner—that’s top-left for folks reading left-to-right and top-right for folks reading right-to-left. Plus there’s a new option to enable hotcorners even while an app is fullscreened. As a follow up to last month’s fixes, choosing light or dark mode in System Settings will now properly snooze your schedule instead of disabling it all together—a great convenience for those of us who suffer from eye strain or headaches and need to occasionally reach for that dark mode during the day. Plus, the Reduce Motion setting now covers a whole new range of animations—perfect for folks who get motion sick or find animations distracting. Leonardo tackled a couple of crashes in Display settings including one when mirroring, and another when new displays are attached while System Settings is open. We fixed an issue that prevented CalDAV accounts from connecting in Online Accounts settings. And Alain snuck in a few design tweaks, fixing button alignments etc. And More Thanks to feedback from Aaron, Notifications and the Shortcut Overlay both got releases that add screen reader support. Corentin addressed some Flatpak sandbox issues with an updated Apparmor Profile—especially notable if you’d had trouble with Steam. We now use BeaconDB as our location services provider. And thanks to Ryo we’re now shipping the latest version of GNOME Web which brings improved performance and web compatibility as well as a redesigned bookmarks sidebar. Get These Updates As always, pop open System Settings → System on elementary OS 8 and hit “Update All” to get these updates plus your regular security, bug fix, and translation updates. Or set up automatic updates and get a notification when updates are ready to install! Community Pride I want to take a little space to say that our community is for everyone regardless of gender or sexual identity. We’ve long been made up of lots of different kinds of folks and I’m really proud of that. Open Source software should never be a space that is restricted to a narrow set of identities. In a time where many companies are withdrawing their support for the LGBTQIA+ community, I think it’s incredibly important that we make a strong statement against hate and don’t give in to the pressure to erase queer people in some sad attempt to be “apolitical”. Free Software has always been political, and its politics are freedom and inclusivity and so are ours. Sponsors At the moment we’re at 23% of our monthly funding goal and 336 Sponsors on GitHub! Shoutouts to everyone helping us reach our goals here. Your monthly sponsorship funds development and makes sure we have the resources we need to give you the best version of elementary OS we can! Monthly release candidate builds and daily Early Access builds are available to GitHub Sponsors from any tier! Beware that Early Access builds are not considered stable and you will encounter fresh issues when you run them. We’d really appreciate reporting any problems you encounter with the Feedback app or directly on GitHub.

OH: It’s just JavaScript, right? I know JavaScript. My coworker who will inevitably spend the rest of the day debugging an electron issue — @jonkuperman.com on BlueSky “It’s Just JavaScript!” is probably a phrase you’ve heard before. I’ve used it myself a number of times. It gets thrown around a lot, often to imply that a particular project is approachable because it can be achieved writing the same, ubiquitous, standardized scripting language we all know and love: JavaScript. Take what you learned moving pixels around in a browser and apply that same language to running a server and querying a database. You can do both with the same language, It’s Just JavaScript! But wait, what is JavaScript? Is any code in a .js file “Just JavaScript”? Let’s play a little game I shall call: “Is It JavaScript?” Browser JavaScript let el = document.querySelector("#root"); window.location = "https://jim-nielsen.com"; That’s DOM stuff, i.e. browser APIs. Is it JavaScript? “If it runs in the browser, it’s JavaScript” seems like a pretty good rule of thumb. But can you say “It’s Just JavaScript” if it only runs in the browser? What about the inverse: code that won’t run in the browser but will run elsewhere? Server JavaScript const fs = require('fs'); const content = fs.readFileSync('./data.txt', 'utf8'); That will run in Node — or something with Node compatibility, like Deno — but not in the browser. Is it “Just JavaScript”? Environment Variables It’s very possible you’ve seen this in a .js file: const apiUrl = process.env.API_URL; But that’s following a Node convention which means that particular .js file probably won’t work as expected in a browser but will on a server. Is it “Just JavaScript” if executes but will only work as expected with special knowledge of runtime conventions? JSX What about this file MyComponent.js function MyComponent() { const handleClick = () => {/* do stuff */} return ( <Button onClick={handleClick}>Click me</Button> ) } That won’t run in a browser. It requires a compilation step to turn it into React.createElement(...) (or maybe even something else) which will run in a browser. Or wait, that can also run on the server. So it can run on a server or in the browser, but now requires a compilation step. Is it “Just JavaScript”? Pragmas What about this little nugget? /** @jsx h */ import { h } from "preact"; const HelloWorld = () => <div>Hello</div>; These are magic comments which affect the interpretation and compilation of JavaScript code (Tom MacWright has an excellent article on the subject). If code has magic comments that direct how it is compiled and subsequently executed, is it “Just JavaScript”? TypeScript What about: const name: string = "Hello world"; You see it everywhere and it seems almost synonymous with JavaScript, would you consider it “Just JavaScript”? Imports It’s very possible you’ve come across a .js file that looks like this at the top. import icon from './icon.svg'; import data from './data.json'; import styles from './styles.css'; import foo from '~/foo.js'; import foo from 'bar:foo'; But a lot of that syntax is non-standard (I’ve written about this topic previously in more detail) and requires some kind of compilation — is this “Just JavaScript”? Vanilla Here’s a .js file: var foo = 'bar'; I can run it here (in the browser). I can run it there (on the server). I can run it anywhere. It requires no compiler, no magic syntax, no bundler, no transpiler, no runtime-specific syntax. It’ll run the same everywhere. That seems like it is, in fact, Just JavaScript. As Always, Context Is Everything A lot of JavaScript you see every day is non-standard. Even though it might be rather ubiquitous — such as seeing processn.env.* — lots of JS code requires you to be “in the know” to understand how it’s actually working because it’s not following any part of the ECMAScript standard. There are a few vital pieces of context you need in order to understand a .js file, such as: Which runtime will this execute in? The browser? Something server-side like Node, Deno, or Bun? Or perhaps something else like Cloudflare Workers? What tools are required to compile this code before it can be executed in the runtime? (vite, esbuild, webpack, rollup typescript, etc.) What frameworks are implicit in the code? e.g. are there non-standard globals like Deno.* or special keyword exports like export function getServerSideProps(){...}? When somebody says, “It’s Just JavaScript” what would be more clear is to say “It’s Just JavaScript for…”, e.g. It’s just JavaScript for the browser It’s just JavaScript for Node It’s just JavaScript for Next.js So what would you call JavaScript that can run in any of the above contexts? Well, I suppose you would call that “Just JavaScript”. Email · Mastodon · Bluesky

In hot weather I like to drink my coffee in an iced latte. To make it, I have a very large Bialetti Moka Express. Recently when I got it going again after a winter of disuse, it took me a couple of attempts to get the technique right, so here are some notes as a reminder to my future self next year. It’s worth noting that I’m not fussy about my coffee: I usually drink pre-ground beans from the supermarket, with cream (in winter hot coffee) or milk and ice. basic principle When I was getting the hang of my moka pot, I learned from YouTube coffee geeks such as James Hoffmann that the main aim is for the water to be pushed through the coffee smoothly and gently. Better to err on the side of too little flow than too much. I have not had much success trying to make fine temperature adjustments while the coffee is brewing, because the big moka pot has a lot of thermal inertia: it takes a long time for any change in gas level to have any effect on on the coffee flow. routine fill the kettle and turn it on put the moka pot’s basket in a mug to keep it stable fill it with coffee (mine needs about 4 Aeropress scoops) tamp it down firmly [1] when the kettle has boiled, fill the base of the pot to just below the pressure valve (which is also just below the filter screen in the basket) insert the coffee basket, making sure there are no stray grounds around the edge where the seal will mate screw on the upper chamber firmly put it on a small gas ring turned up to the max [2] leave the lid open and wait for the coffee to emerge immediately turn the gas down to the minimum [3] the coffee should now come out in a steady thin stream without spluttering or stalling when the upper chamber is filled near the mouths of the central spout, it’ll start fizzing or spluttering [4] turn off the gas and pour the coffee into a carafe notes If I don’t tamp the grounds, the pot tends to splutter. I guess tamping gives the puck better integrity to resist channelling, and to keep the water under even pressure. Might be an effect of the relatively coarse supermarket grind? It takes a long time to get the pot back up to boiling point and I’m not sure that heating it up slower helps. The main risk, I think, is overshooting the ideal steady brewing state too much, but: With my moka pot on my hob the lowest gas flow on the smallest rings is just enough to keep the coffee flowing without stalling. The flow when the coffee first emerges is relatively fast, and it slows to the steady state several seconds after I turn the heat down, so I think the overshoot isn’t too bad. This routine turns almost all of the water into coffee, which Hoffmann suggests is a good result, and a sign that the pressure and temperature aren’t getting too high.