Contracts are the backbone of business agreements, ensuring clarity, accountability, and legal protection. But do you know the role of a **contracting party** and how to manage contracts effectively?

Contracting Party: A Comprehensive Guide to Understanding and Managing Contracts

This overview clarifies the nature of Clickwrap agreement vs. Browsewrap agreement types, highlights their differences, and explains why understanding these differences is important. A clear understanding of Clickwrap vs. Browsewrap agreement is essential.

Clickwrap vs. Browsewrap Agreement: Understanding the Key Differences

<https://twitter.com/elonmusk/status/1683656350046232578>

From Elon Musk:

*"Twitter was acquired by X Corp both to ensure freedom of speech and as an accelerant for X, the everything app. This is not simply a company renaming itself, but doing the same thing.*

*The Twitter name made sense when it was just 140 character messages going back and forth – like birds tweeting – but now you can post almost anything, including several hours of video.*

*In the months to come, we will add comprehensive communications and the ability to conduct your entire financial world. The Twitter name does not make sense in that context, so we must bid adieu to the bird."*

Twitter has officially changed its logo to ‘X’

Trump's Truth Social has lost $73 million in less than 2 years, new filing says                

MetaGPT takes a one line requirement as input and outputs user stories / competitive analysis / requirements / data structures / APIs / documents, etc.

Internally, MetaGPT includes product managers / architects / project managers / engineers. It provides the entire process of a software company along with carefully orchestrated SOPs.

MetaGPT - Given one line Requirement, return PRD, Design, Tasks, Repo

Hi I'm Jeremy. I'm building this site because I'm not satisfied with other online community type websites and their lack of innovation (see the /about page). The goal is to make a superior, more open, and more decentralized online community.

The site is still in early stages in active development (see the dev masterthread here: https://zsync.xyz/p/zsync-dev-update-masterthread)

Join us if this sounds interesting! Feel free to send me any feedback or reach out directly!

[Fable](https://venturebeat.com/games/fables-the-simulation-lets-you-build-a-society-of-ais-based-on-character-nfts/), a San Francisco startup running a big project dubbed [The Simulation](https://venturebeat.com/games/the-simulation-by-fable-makes-everyone-robert-ford/), has released Showrunner AI technology, dubbed SHOW-1, which can generate new episodes of TV shows

Paper: <https://fablestudio.github.io/showrunner-agents/>

AI-Generated South Park Episodes (by Fable)

Solid thread by Sam Hogan <https://twitter.com/0xSamHogan>

6 months ago it looked like AI / LLMs were going to bring a much needed revival to the venture startup ecosystem after a few tough years. 

With companies like Jasper starting to slow down, it’s looking like this may not be the case. 

Right now there are 2 clear winners, a handful of losers, and a small group of moonshots that seem promising. 

Let’s start with the losers. 

Companies like Jasper and the VCs that back them are the biggest losers right now. Jasper raised &gt;$100M at a 10-figure valuation for what is essentially a generic, thin wrapper around OpenAI. Their UX and brand are good, but not great, and competition from companies building differentiated products specifically for high-value niches are making it very hard to grow with such a generic product. I’m not sure how this pans out but VC’s will likely lose their money. 

The other category of losers are the VC-backed teams building at the application layer that raised $250K-25M in Dec - March on the back of the chatbot craze with the expectation that they would be able to sell to later-stage and enterprise companies. These startups typically have products that are more focused than something very generic like Jasper, but still don't have a real technology moat; the products are easy to copy. 

Executives at enterprise companies are excited about AI, and have been vocal about this from the beginning. This led a lot of founders and VC's to believe these companies would make good first customers. What the startups building for these companies failed to realize is just how aligned and savvy executives and the engineers they manage would be at quickly getting AI into production using open-source tools. An engineering leader would rather spin up their own 
@LangChainAI
 and 
@trychroma
 infrastructure for free and build tech themselves than buy something from a new, unproven startup (and maybe pick up a promotion along the way). 

In short, large companies are opting to write their own AI success stories rather than being a part of the growth metrics a new AI startup needs to raise their next round. 

(This is part of an ongoing shift in the way technology is adopted; I'll discuss this in a post next week.)

This brings us to our first group of winners — established companies and market incumbents. Most of them had little trouble adding AI into their products or hacking together some sort of "chat-your-docs" application internally for employee use. This came as a surprise to me. Most of these companies seemed to be asleep at the wheel for years. They somehow woke up and have been able to successfully navigate the LLM craze with ample dexterity. 

There are two causes for this:
1\. Getting AI right is a life or death proposition for many of these companies and their executives; failure here would mean a slow death over the next several years. They can't risk putting their future in the hands of a new startup that could fail and would rather lead projects internally to make absolutely sure things go as intended.
2\. There is a certain amount of kick-ass wafting through halls of the C-Suite right now. Ambitious projects are being green-lit and supported in ways they weren't a few years ago. I think we owe this in part to 
@elonmusk
 reminding us of what is possible when a small group of smart people are highly motivated to get things done. Reduce red-tape, increase personal responsibility, and watch the magic happen.

Our second group of winners live on the opposite side of this spectrum; indie devs and solopreneurs. These small, often one-man outfits do not raise outside capital or build big teams. They're advantage is their small size and ability to move very quickly with low overhead. They build niche products for niche markets, which they often dominate. The goal is build a saas product (or multiple) that generates \~$10k/mo in relatively passive income. This is sometimes called "mirco-saas."

These are the 
@levelsio
's and 
@dannypostmaa
's of the world. They are part software devs, part content marketers, and full-time modern internet businessmen. They answer to no one except the markets and their own intuition.

This is the biggest group of winners right now. Unconstrained by the need for a $1B+ exit or the goal of $100MM ARR, they build and launch products in rapid-fire fashion, iterating until PMF and cashflow, and moving on to the next. They ruthlessly shutdown products that are not performing. 

LLMs and text-to-image models a la Stable Diffusion have been a boon for these entrepreneurs, and I personally know of dozens of successful (keeping in mind their definition of successful) apps that were started less than 6 months ago. The lifestyle and freedom these endeavors afford to those that perform well is also quite enticing. 

I think we will continue to see the number of successful micro-saas AI apps grow in the next 12 months. This could possibly become one of the biggest cohorts creating real value with this technology. 

The last group I want to talk about are the AI Moonshots — companies that are fundamentally re-imagining an entire industry from the ground up. Generally, these companies are VC-backed and building products that have the potential to redefine how a small group of highly-skilled humans interact with and are assisted by technology. It's too early to tell if they'll be successful or not; early prototypes have been compelling. This is certainly the most exciting segment to watch. 

A few companies I would put in this group are:
1\. https://cursor.so - an AI-first code editor that could very well change how software is written.
2\. https://harvey.ai - AI for legal practices
3\. https://runwayml.com - an AI-powered video editor

This is an incomplete list, but overall I think the Moonshot category needs to grow massively if we're going to see the AI-powered future we've all been hoping for.

If you're a founder in the $250K-25M raised category and are having a hard time finding PMF for your chatbot or LLMOps company, it may be time to consider pivoting to something more ambitious.

Lets recap:
1\. VC-backed companies are having a hard time. The more money a company raised, the more pain they're feeling.
2\. Incumbents and market leaders are quickly become adept at deploying cutting-edge AI using internal teams and open-source, off-the-shelf technology, cutting out what seemed to be good opportunities for VC-backed startups.
3\. Indie devs are building small, cash-flowing businesses by quickly shipping niche AI-powered products in niche markets.
4\. A small number of promising Moonshot companies with unproven technology hold the most potential for VC-sized returns.

It's still early. This landscape will continue to change as new foundational models are released and toolchains improve. I'm sure you can find counter examples to everything I've written about here. Put them in the comments for others to see.

And just to be upfront about this, I fall squarely into the "raised $250K-25M without PMF" category. If you're a founder in the same boat, I'd love to talk. My DMs are open.

If you enjoyed this post, don't forget to follow me, Sam Hogan. I share one long-form post per week covering AI, startups, open-source, and more. 

That's all folks! Thanks for reading. See you next week.

```markdown
```

AI Startup Market Outlook

&gt; "There will be no programmers in five years.” -Emad Mostaque, founder and CEO of Stability AI (Stable Diffusion)

I agree with this, except I’d put the timeframe more conservatively around 10 years.

I think in 5 years, most software development will be done by computers. Humans will prompt AIs that generate the code. AI at that point will be able to work within existing codebases and implement trivial feature requests on its own, detect and fix bugs, and debug itself.

In 10 years, AI will unquestionably be superior to humans in software development – just like AI is already better than humans at chess and Go. Handwritten code will not only be considered useless, but writing code by hand will be considered bad practice because humans will be considered less reliable and more error-prone than the machine.

A “software engineer” in 2033 will be more of a CTO-like managerial position where that person is in charge of the tech of an organization, but they’re delegating the tasks to AIs. Companies will need less and less software engineers as the AI advances and ultimately displaces humans. Of course there will be engineers building and maintaining the AI, researching, and working at the bleeding edge, but overall there will be significantly less demand for human engineers. What few jobs remain will be higher demanding since AI will only improve – and a human has to be able to do what an AI can’t in order to be useful – a bar that will only get higher and higher until it is eventually unattainable.

With humans rendered economically obsolete to machines, governments will have no choice but to implement a universal basic income in order to prevent mass poverty and chaos. Unfortunately a lot of workers will be displaced and people will suffer before governments implement UBI due to the enormous capitalistic brainwashing against UBI.

### Why this time is different

The reason technological advancement will actually result in net job destruction this time is because technology is getting better than humans and approaching Artificial General Intelligence (AGI). Large Language Models (LLMs) like ChatGPT can reason, and thus solve problems it hasn’t specifically been programmed to. In the past, technology had to be built to solve a specific problem in order for the human to be rendered obsolete (eg. the loom), but AGI can solve any problem. As we approach AGI, the only value that humans can provide will be that which AGI is not yet capable of solving. There is no upper bound on how smart AIs can get, but humans have a clear biological ceiling.

### AI will beat humans at software development

Just like AI is superior to humans at games like chess and Go, there’s no reason that AI won’t reign supreme when it comes to programming. AI can already pass Google’s coding interview, the bar exam, MCAT, etc. at a speed that no human could even come close to – like a flashlight competing with a sloth.

Humans look at ChatGPT now and laugh at its often nonsensical answers and hallucinations. Yes, but you’re looking at the equivalent of one of the first computers in the 1950s, or dialup internet in the 90s, a floppy disk with 1MB capacity, or mobile in 2007. Remember, ChatGPT was only released November 30, 2022. OpenAI’s Code Interpreter was released in beta last week to ChatGPT Plus users, an AI that can execute Python code and that you can upload files to. We’re in the first inning of an AI arms race, and at the speed at which things are progressing, it’s pretty clear that AI will be drastically more developed even just another 6 months from now.

As a software engineer, I have full awareness that most of what I know that makes me valuable will be obsolete within a decade because AI will be able to do it faster, cheaper, and better.

The stages of AI progress in software engineering look something like this:

1. Chatbots tell you the answer, for example by giving you code, which you then need to copy & paste in the right files – adjusting to fit within your codebase.
2. AI assistants write the code directly inside your codebase (eg. like “autocomplete” except with a task more complex than simply predicting the end of the word you’re typing)
3. AI assistants/agents execute the code, and debug itself to correct any errors

The reality is that the vast majority of dev work has already been done before, and thus is very trivial to replace with AI.

Humans basically get paid by arbitraging knowledge and producing some output. Software engineers have knowledge of tools, libraries, frameworks, commands, version control, infrastructure, data structures & algorithms, networking, APIs, etc. and use this to write computer programs and create software.

Search engines, Stackoverflow, open source, internet forums, tutorials, Youtube, books, etc. democratized much of this knowledge – but still require a human to research and utilize this information to create software by writing computer code.

AI can do all of this far superior to humans because AI has all of the world’s knowledge, and can execute at the speed of light.

Even if AI code were to be inferior to human code – which by the end of the decade certainly won’t be the case (just like AI beats humanity’s best chess and Go players), humans are still going to be rendered mostly obsolete. Businesses don’t care about code, they want solutions that improve their bottom line. If an AI can solve the problem with half the performance and code quality in a couple minutes, is available 24/7, and only costs pennies/dollars, vs. a team of engineers with $200k/yr salaries taking a month, only available during business hours, and with vacation time, maternity/paternity leave, and other liabilities – who do you think is going to win out? Remember the AI is only going to get better, faster, and more knowledgeable, while humans are biologically limited in work output, and there will be a point where humans no longer have the edge.

I think it’s fairly obvious at this point that AI will supplant humans, but **most people are drastically underestimating how quickly this is all going to happen because most humans struggle to understand exponential growth.**

I don’t have a crystal ball, but here are some rough conservative predictions I’ll make off the top of my head:

- 2024-07-14 – AI agents can create codebases, write code in existing codebases directed by prompts (eg. “add this feature”, “create this API endpoint that does this”), and debug itself (eg. detect compilation/runtime errors and patch them). The tech will be slow and awful at first so engineers will initially laugh at it claiming they’re not worried about their jobs.
- 2025-7-14 (2 years from now) – These AI agents will start becoming reasonable enough to where they’ll automate the more mundane / trivial work. People will still have to know what to prompt to get the right results, and modify and fine tune the resulting AI-generated code, but AI will start to take the driver’s seat. Instead of the default being for the human to start tackling the problem and ask the AI for help when in need of assistance, it’ll start to become expected to let the AI tackle the problem, and bring in a human when that fails.
- 2026-7-14 (3 years from now) – AI agents start becoming competent enough to where their belonging is no longer questioned. Everyone is using them in some capacity. AI is the driver, but humans are still necessary to direct them and handle the edge cases where they fail. Typical dev work like building trivial web apps and APIs is a commodity at this point and nobody is doing that by hand.
- 2027-7-14 (4 years from now) – AI is the norm. At this point as an engineer you’re either working on building the AI itself, or you’re using the AI. The job of an engineer has evolved from less hand-writing code, to more of a managerial CTO type position, except instead of delegating to other managers and engineers, one is delegating to AI agents.
- 2028-7-14 (5 years from now) – So much human work has been made obsolete by AI that all governments in the modern world have implemented universal basic income.

### How to position yourself

Tech was always a rapidly evolving field that required constantly staying on top of the latest advancements, but that’s only going to exponentially increase.

- Stay ahead of the curve on AI advancement. Ensure you’re leveraging the most advanced tools.
- Don’t be overly married or emotionally invested in any one programming language, library, framework, or technology. Assume it will get displaced sooner than you think.
- Learn architecture and systems design. As we move up the ladder of abstraction, an engineer’s focus and responsibility will be more on deciding *what* to implement, rather than actually implementing the thing. Individual contributors (ICs) will become more like managers directing AIs.
- Stay humble. Assume that everything you know will be irrelevant in a few years.
- Either seek to become more of a CTO-like generalist, entrepreneur, or pick a specialty/niche (eg. machine learning, distributed systems, product, etc.) to stay at the forefront of. If you specialize, realize that you’re competing with AI.
- Get your government representatives to implement a universal basic income so that AI advancement can become unquestionably a good thing for society, instead of the current system where it results in the masses losing their livelihoods and an arms race for an ever-dwindling pot of human jobs as robots overtake us. This can either result in the freedom and leisure utopia that Keynes envisioned, or mass poverty coupled with enormous wealth inequality – and inaction will lead to the latter.

Human Programmers Will be Mostly Obsolete in 5 Years

Ok so I've officially migrated the site off of GraphQL, to now just a plain boring REST API, and react-query. (backend in Node.js + express.js). Took way longer than I anticipated. Still some work left so some things on the site are currently broken.

I'd initially built this site a year ago using GraphQL and Apollo just because it was what I was most familiar with having used it at my last job.

Why did I migrate off GraphQL? A few reasons:

- N+1 problem, or multiple SQL calls getting made instead of just one. Maybe there's a way to solve this with GraphQL, but honestly I'm not sure how to do this, and it's certainly more complicated than with a REST API
- REST API is simpler, and more people are familiar with it. The API is public and I'm planning to open source it, so I want it to be accessible
- Tooling and resources more limited than REST APIs. Standards less defined
- Too much lock-in with apollo. I don't like to be dependent on anybody. Sure there are alternatives, but not really. Apollo also updates a lot, and old code gets deprecated.
- My frustration with dealing with Apollo's cache on the frontend
- Having to type the entire schema is actually time-consuming. I'm trying to optimize for developer speed here since this is a startup / side project and I'm the sole developer at the moment. Also I don't love decorators (funny since I'm using TypeORM and TypeGraphQL)
- Wanting to personally get better with REST APIs. Since my previous employment had been with GraphQL, I wanted to improve my REST API skills, as well as try out react-query.

For the record, the thinking was that I'd eventually back in the GraphQL API. The way the code is setup, that should be fairly easy on the backend, could maybe even write some code to automate that. The frontend of course is a different beast.

Also I like and probably prefer the concept of GraphQL. It makes more sense for a client to specify just the data they want. The problem is just the tooling on the backend is pretty immature, and with GraphQL it's more difficult to optimize the SQL queries (or someone please tell me if there's an effective way to do this that I'm not aware of, ideally pointing me to an example GitHub repository)

Ok now that the site is migrated, was it the promise land I was hoping for?

No. I've realized that react-query's cache control is way worse than Apollo's, and right now it looks like I'll be moving off

The API does seem to be faster as it should, but not as much as I expected - though I admit I didn't test this very rigorously.

### React-query caching kinda sucks

There doesn't seem to be a nice simple way to set and retrieve items in the cache: <https://stackoverflow.com/questions/76563755/how-to-normalize-react-query-cache-to-only-use-a-single-key-when-there-are-multi>

Apollo's caching is far superior because you can use cache.identify() to directly modify any entity in the cache (btw Apollo's documentation never mentioned that for whatever reason, wasting a lot of my time before I discovered that). React-query doesn't seem to have an equivalent. The only way to update the cache seems to be to manually do it for each API endpoint utilizing the data, using the exact same inputs that were used to call each API endpoint. What a pain in the ass.

Upvoting/downvoting doesn't live reflect anymore on this site, and I'm not sure how to even fix it with react-query without making the code incredibly convoluted.

Thus my plan is to get rid of react-query and handle the caching myself - or maybe make something similar to react-query, but with the control over the cache that I desire.

Anyways don't get me wrong react-query is great for simple sites, but for anything more complex I'm going to pass going forward. Or maybe I'm missing some information, but I don't see any explanation in the docs or online, and never got any real responses on StackOverflow, GitHub discussions, or tweeting at the tanner guy on Twitter.

All that being said, I'm happy the codebase migration is finished, and CI/CD is setup (I do that on all my projects now, but back when I made this I was still fairly new to Google Cloud Run and manually deploying like a caveman) so I can start developing on this site again! Maybe no one's noticed, but the last few weeks I haven't actually updated anything on this site because none of that stuff was setup, and I didn't want to touch the codebase as it was anyways.

But now I'm ready to pump out a ton of features on Zsync. Just need to undo this react-query monstrosity.

Migrated Zsync from Apollo GraphQL to REST API + react-query, not liking react-query

Here's the tech stack I used to build this site (if anyone cares). Using Typescript on the frontend and backend

- Frontend - Next.js, TailwindCSS, Apollo

- Backend - Node.js, Express, Apollo (GraphQL), TypeORM, TypeGraphQL. Database is PostgreSQL. Redis used for sessions.

- Servers are hosted on Google Cloud Run, and PostgreSQL database hosted on Digital Ocean (a lot cheaper than Google Cloud). GitHub actions for CI/CD, and pnpm workspaces for the monorepo (actually I didn't set up the last two for this project yet, but I did for my more recent projects so definitely will implement).

I've got mixed feelings on GraphQL to be honest. I like that the schema is built into it, but I'm not a big fan of Apollo, and the tooling is more immature than REST APIs.

These days I'm just using traditional REST APIs for my projects as it's simpler (eg. for [mindgarden.app](http://mindgarden.app) which is a Notion clone I've been building). I built zsync last year though when I was more comfortable with GraphQL. I guess we'll see which makes more sense. Beauty of using TypeGraphQL/TypeORM is that it makes it relatively simple to implement both. With a public API, I think it makes sense to offer both a REST API and a GraphQL API.

I also want to add websockets support so that posts update in real-time. Honestly there should just be a good backend abstraction that offers the REST API, GraphQL, and websockets (eg. feathersjs does this). If there's a good abstraction for this please post in the comments. Otherwise maybe I'll end up making my own, admittedly for the fun of it.

That's the challenge with building stuff as an engineer though - so easy to get lost in technical rabbit holes when users don't give a f about your tech stack as long as your product has the right features and works.

How I Built Zsync - The Tech Stack

October 1, 2003 reading text on my Nokia 3390

Apple is cutting off social media support!

I've been building a Notion clone + publishing tool. Here I'll post dev updates (as well as on [Twitter](https://twitter.com/jeremybernier)).

Site: <http://mindgarden.app>

**2023-08-08** Just added Stripe payments and created landing page for <http://mindgarden.app>, my Notion clone (note-taking app) + publishing tool

Next I will prob make a video for the landing page showing what this is + how to use it b/c I don't think it's very clear. Then will try to get it in front of people to get feedback to validate the idea and/or refine the product/marketing.

I know the landing page is ugly because it's not a separate page, but a file directly in the app. I thought it'd be cool to immediately load the app and allow people to instantly start using the product (also I personally hate landing pages, but maybe I need to get over that). This makes it tough to style this page, but perhaps can figure something out later.

I'm building out some sites using <http://mindgarden.app>. Currently <http://codefire.dev> (built a couple days ago) and <http://jbernier.com> use the MindGarden API, and planning to build out those sites + more to show what it's capable of.

Will this succeed? Who knows. In any case I use the product myself, so at least there's one happy customer. We'll see if I can turn this into something useful for others as well.

Let me know what you think / open to feedback. I'm new to the whole entrepreneurship thing - this is actually my first time adding payments to anything I've made (wish I'd done this sooner).

<http://mindgarden.app>

<https://twitter.com/jeremybernier/status/1688814645598208000>

Build In Public - MindGarden

Built this today: <https://codefire.dev> (work in progress)

Plan is for it to be a no-BS site for useful code snippets, boilerplates, and dev resources. No unnecessarily long-winded tutorials and SEO whoring, just straight to the point.

Backend API will be powered by my other app <http://mindgarden.app>, so it's simultaneously an excuse for me to battle test my own product + serve as a demo.

Currently just my content, but down the line will be publicly editable (eg. like Wikipedia) 

Tech stack: Next.js, Tailwind, MindGarden (API), Cloudflare Pages

Will post updates here

Build In Public - CodeFire.dev

Threads users down by more than half

Show HN: <https://news.ycombinator.com/item?id=36813086>

GitHub: <https://github.com/primocms/primo>

Primo - Visual CMS with Svelte blocks, code editor, and SSG (open source)

TypeChat uses the type definitions in your codebase to retrieve structured AI responses that are type-safe.

TypeChat

Being a software engineer in 2023 is knowing that 95% of everything you're doing now will be obsolete in 5 years. By 2028 app creation will be a commodity &amp; coding will be writing prompts that update themselves Tech was always fast-changing, now we're supercharging exponentiallyHumans cannot compete with AI in the long run. Now is one of the last moments in time where as a human you can still have an edge. In a decade, that will mostly be gone. Human labor being obsolete to AI would be something to celebrate if we had a UBI (basic income), but we don't10 years ago I thought it was obvious that implementing UBI would be an enormous net-positive for society, especially since it was obvious AI was automating labor. Now you'd have to be an idiot to not see the writing on the wall, yet I don't see much talk of UBI.Anyways, the golden age of human labor is coming to an end. We can embrace &amp; applaud this, implementing a UBI, freeing the wagcucks, etc. Or we can cry &amp; deny it while desperately clinging on to the last remains of our own waning relevance like luddites &amp; boomer politicians

Being a Software Engineer in 2023 is knowing that 95% of everything you're doing now will be obsolete in 5 years

Just recently I was using ZPaq to perform a daily backup of my home folder (which is around 40GB decompressed). ZPaq uses the Paq compression algorithm [1] which is one of the best ones. While <code>xz -9e</code> compressed my homepage into 17 GB (around 40%), ZPaq got it to like 11 GB!!. And it also has archiving capabilities, so if you run it every day, it will only add missing files and remove files that are not there anymore. It has "snapshot" capabilities, so you can uncompress the files at a specific version, to restore deleted files. I combined ZPaq with Par2 to add 15% of redundancy (to recover the zpaq file in case of corruption). Everything looks great.<pre><code>cat ~/.local/bin/homebackup.sh
#!/bin/bash
FILENAME="/media/myname/TimeShift Backup/backups/home_myname.zpaq"
DIRNAME=$(dirname "$FILENAME")

if [ ! -f "$FILENAME" ]
then
 mkdir -p "$DIRNAME"
 pushd "$DIRNAME"
 zpaq add "$FILENAME" /home/mhname/ -m4
 nice -n 15 par2 c -r15 "$FILENAME"
 popd
fi
</code></pre>[1] <a target="_blank" rel="noopener noreferrer nofollow" href="https://en.wikipedia.org/wiki/PAQ">https://en.wikipedia.org/wiki/PAQ</a>

ZPaq: Incremental Journaling Backup Utility and Archiver

*"This is a 1 hour general-audience introduction to Large Language Models: the core technical component behind systems like ChatGPT, Claude, and Bard. What they are, where they are headed, comparisons and analogies to present-day operating systems, and some of the security-related challenges of this new computing paradigm."*

Tech

t/tech