snide

> For example, jumping to a specific position in a source code file, scrolling and clicking gets me there much quicker than navigating with the keyboard alone

I say this with the intention of providing context, not to say the way you do things is bad. It's all user preference in the end and there is no wrong way.

Lots of folks consider your "fast" example with a mouse as their "slow" example that forced them into learning more advanced features of their editor. For example. Most Vim users can get to any character or partial string, or parameter, or line, or paragraph, or function start or what you have within three quick keys on their home row. They do this quickly, and can immediately start doing other things right after because their hands never moved.

The mouse is fast because people don't need to memorize things. The keyboard is fast because the keyboard is fast.

It's like the old joke from the movie Heist. "What do you mean you don't like money? That's why they call it money".

Has anyone worked in a "two crews" system where there wasn't resentment? Or where people didn't want to naturally migrate to the "future crew".

I like the idea of this on paper. I have a hard time believing it can work in practice. The closest I've seen are library teams that build some service (say a design system + components) that other teams utilize.

I don't remember seeing anything like this with Lemon Squeezy.

There was a brief period of time where having one of these 3D cards in quake led to a pretty heavy advantage for gamers.

I can very clearly remember installing the card and then loading up 2Fort4 in the Team Fortress mod and suddenly being able to see THROUGH THE WATER.

Sniper's paradise!

This is beautiful. I'm a "Let's Split" style keyboarder as well so this made me giddy! There's a distinct lack of solid cases out there for this layout style.

You mention possibly mass producing the next round. Please add a notify email list or something. I'd be all over this.

Disclosure: I'm a happy Turso customer.

I think this is going to be one of several blog posts they are writing essentially providing users with escape hatch ways to deal with features they've dropped. It wasn't just their edge DB play, but also the multi-tenant "schema only" db system they dropped recently. Both can be done on your own, with setup, and I think they're doing their best to show that to users through these kind of posts.

What's sort of hidden from this is that I believe they charge more for embedded syncs, so they have an incentive for you to use them vs. their edge system (which was on them to maintain globally). Embedded syncs are nice, because for every 5th "response time" benchmark we see from their competitors in the hosted Postgres world, Turso can basically say "0" to.

I'm honestly more surprised they dropped the multi-tenant stuff. That seems like a real use case for in the field devices. I'm guessing they likely have better ways to handle it in their rewrite, and don't want to maintain the current version till they release all the new stuff.

Overall though I've found Turso very stable.

VCR let you record anything. Something on TV you wanted to watch later? Set the timer, it recorded on that channel at that time.

A DVD might have been peak consumer, but it didn't have nearly the versatility of VCR. Hell, I could record 6 hours of content on 1 tape!

For Android folks, my friend built an app to limit / restrict the apps and websites your phone has access to. It's essentially like workplace fleet management, but for yourself.

I have a little more personal self control, but found his technical implementation pretty neat!

https://limitphone.com/

Yes. That's essentially what I was looking for. A generic playbook for something like this.

Hey Eric! I think of you whenever I open Python documentation and see some of my old work!

That's good to know that at least I'm not crazy for also open sourcing the billing code. I feel less worried.

Open source just gives away the code, without setting up resources for the people who work on it. If I charge for the service, which is owned by the members, I could presumably pay upkeep (hosting, dedicated workers...etc).

As far as I know this is how places like REI or some groceries work. They are essentially customer owned. I'm not an expert in this, which is why I was asking for advice.

That's interesting, but I was thinking something possibly even farther. That the members of the co-op are the people that pay for the SaaS itself. Essentially the yearly fee is "dues" towards the organization.

Thanks. I didn't know about either of these groups.

This gets difficult as more employees join. Typically companies set aside a portion initially, and then keep splitting that portion.

There are consumer-owner / member-owned co-ops where the people that purchase the service (say in a yearly subscription) end up as owners.

Anyone using the Neovim plugin and suddenly starting to get rate limit errors? I'm already on pro, but it's asking me to upgrade to pro in Neovim?

Hi CJ ;-)

Hope you're doing well! (I built this with CJ).

I'd add a couple other points.

1. Documentation should be more than half of your team's time. If it's well documented, and has copy/paste content, people will use it because they are lazy and you gave them the easiest solution.

2. Don't think of yourself as building the UI library only. Take the time to work downstream in the product and help the product teams convert to the new stuff. If you're seen as friendly and supportive, rather than adding more work on a team, it makes things easier.

3. Constantly show off your work in large gatherings. Most folks aren't aware of cool stuff you're doing or why it might be useful. Show, don't tell.

These things fail when the upstream library team things they are passing things over a wall (npm) to a consumer. Dogfood it by building the product alongside the teams.

Really happy with Projection Lab in this space. Although it's not open source, it is self-hostable if you pay for their lifetime access. The developer continues to update it, and has pretty much all the features I want for managing retirement projections.

> Even prior to the bill being passed into law, DraftKings and FanDuel issued a warning to the government, essentially promising to rig the spreads even further for Illinois residents, hiking their vigs and offering less appealing odds.

This is the real scary bit in this article and the crazy spiral. Yes, we can legalize gambling. Yes we can tax it (and keep increasing the taxes). But if we both make it very legal, and tax it a lot, the businesses who run the gambling will need to adjust their odds to make a profit, making the end situation a very easy way to gamble in "safe" ways that unfortunately are much less likely to return money to the gambler.

This is a complicated issue beyond just saying "gambling should be legal". As soon as taxing is involved, there's a scary tornado of nobody winning in these situations and it feeling like a wink-wink grift.

I work as a Web designer in Linux. I'm not sure that I could completely get away with it if I wasn't already pretty code / frontend focused. I reach quite a bit to web-based tools (Figma, Whimsical) when I need to do prototyping, and find things like Krita and Inkscape more than competent for actual pixel pushing.

Where things fall apart is when you're in larger teams where everyone uses the more common tools on the more common OSes. Collaboration becomes much harder, and there are certain walls you can't cross. The other weak spot is with video editing. There are options, but none of them are as easy to use as the ones you'll find on OSX.

Design requires A LOT of screenshotting, and for that I resorted to building my own workflows [0]. That sort of brings up the major benefit of Linux as a designer. You really do get to build out your "dream" setup, and my Desktop over the years is really customized to the way I work, not the way others work. That's part of the joy of design for me, and while it certainly will limit me to working with Startups or companies that are OK with individuality in workflows, it's provided a level of happiness I wouldn't trade. If anyone is interested, I wrote about my thoughts about using Linux as a designer over here [1].

[0]: https://www.davesnider.com/posts/screenshot-app

[1]: https://www.davesnider.com/posts/im-a-linux

Reading, to me, is the best method to learn empathy. We all read differently, in our own headspace, but then need to distill that view through the godhead of a fictional character. Movies and TV can't touch that slow drip of mindcopy a book provides. TV we witness, books we live alongside. Often I'm stuck in the personality of a book for weeks at a time, and it's impossible for the experience not to leave a footprint.

Happiness I've found easiest to achieve with that empathy. Understand those around you and know your place in the world and what is and is not possible to change. Being malleable in a group while still retaining a sense of self provides a way to travel and adapt in whatever situation you find. Only books provided me with enough experience to "know" myself and how I'd react in certain scenarios.

I don't think it matters much what you read. Whatever challenges you and gets you to see the world slightly askew.

I feel seen!

I'm one of these codey designers. The madness that exists in modern design teams (I used to manage a team of 50!) is insane. There's a lot of time spent on "design systems" in Figma. Very generally Figma is not the website, and the effeciency additions of building tools there is a lost cause.

Modern CSS and your JS frontend of choice is a lot quicker and more powerful for component building and general design work. There's way too much to do with media break points and tokenization there. There's a misguided group of designers that are learning a lot of esoteric Figma features that don't translate into something users will ever touch.

10 and 15 years ago designers needed to learn the code part too. Somewhere along the way we put them in a corner and made learn these prototype tools.

Also have a fierce loyalty to AmEx as a customer. I use it as often as I can to pay for things. Their customer services is phenomenal, and its nice to have an arbiter between you and a merchant when things come up. Anytime I've had an issue with a merchant, I try to work with them first, and then jump to Amex if they aren't willing to work with me. In every instance Amex has been able to fix the problem, typically by refusing payment to the vendor after an investigation. It's like having insurance for your purchases.

I say this as a generic green card member of 25 years. I know a lot of people pay for higher tiers for travel benefits, but the base service has been excellent for my needs.

This is about to get super normal.

Xata employee here. The clarification would be "platform" vs. "host". You get a lot with Xata beyond the core Postgres offering. We automatically replicate to OpenSearch for a great, fast search experience, provide file attachments through the DB itself (with image transformations), provide a pretty cool editor, and are now starting to think heavily towards how migrations could be better (more on this next week). No knock against Neon, who build cool stuff too.

I agree "only" is likely a little aggressive, but marketing is tricky and sometimes the A/B gods appear. We've switched this one-liner a few times in the past year. I'll provide that feedback to the team in any case.

How this doesn't have a picture included of Steely Dan's Aja, which is an iconic cover he did, baffles me.

Right now Linux on Desktop offers:

- The best developer experience with the most hackable toolkit

- A great gaming experience that plays the vast majority of titles on Steam

- A "dumb by default" non-cloud enabled workstation

- IMHO the most well-design, does most things "vanilla" desktop environment with GNOME.

The tradeoff is

- You will need to learn to update your system and learn some new things. Things will seem difficult till you learn how they work.

- There are gaps in third-party applications (primary, video editing is sub par). The smaller apps you pay for now, you'll end up making scripts or small pieces of software to replace. Eventually this will be freeing, but it's a learning curve and you'll initially miss some things (Alfred, Screenshot tools...etc).

- Customization comes with a larger maintenance cost.

- Your phone is not really connected to your PC, and syncing systems is all manual. If it's not web-based, that app you like doesn't probably doesn't work.

I switched 3 or so years ago and it's been a revelation. Although I'd been using computers since the 80s I never really understood how an OS works. While you could argue I never needed to, I find myself much more digitally literate now. After a hump year, I mostly tailor the OS to what I need it to do, and it feels like an extension of me.

I wrote a blog post about this more generally here. https://www.davesnider.com/posts/im-a-linux

My first thought was how this is a common method for making money to buy drugs on various movies / tv shows. I guess it makes sense. If it's valuable and has a market at that level, it has a large value generically, similar to aluminum cans.

Unfortunately this is one of the places where Linux really doesn't have any good options. While there are definitely raw capture options for Linux, there isn't anything as nice as Screen Studio or Screen Flow or Camtasia for quick, short videos with basic editing.

Only briefly. I did enough to realize Solid felt like a flavor of what I'd already been doing in React. Svelte felt more like some extras I could throw on JavaScript itself.

Honestly, the biggest thing with all of these systems is what library support do they have beyond the core? I specifically need a good component library, and want to do things with Three JS. Svelte had that covered.

I'm the person that's been using React for 10 years and suddenly thought... I wonder what the big deal with Svelte is? I built a non-trivial project in Svelte for my personal site and something weird happened. I was having fun again. Svelte feels pretty close to vanilla and I like that the code I'm writing feels a lot more similar to how I wrote code before I ended up in React. Style tags, script tags, easy assignment of variables, no useEffect head-scratching. You declare things, you change them, and it mostly just works. The code looks pretty similar to a regular old webpage.

My favorite thing about learning Svelte was that it has my favorite "documentation" of any library. It's just a list of code samples showing various different scenarios [0]. This made it dead easy for me to understand its way of doing things without needing to get too deep into the methodology.

[0]: https://svelte.dev/examples/hello-world