Podcasts about Unix

.NET on FreeBSD 15, Klara and TrueNAS fixing dedup, dhcpcd and unbound in FreeBSD Jails, and more... NOTES This episode of BSDNow is brought to you by Tarsnap and the BSDNow Patreon Headlines Running .NET 10.0 on FreeBSD 15.0 How Klara and TrueNAS collaborated to fix one of ZFS's longest standing limitations News Roundup Back to FreeBSD: Part 1 dhcpd and unbound in FreeBSD jails How our environment still needs the security boundary of Unix logins Increasing a bhyve vm disk Tarsnap This weeks episode of BSDNow was sponsored by our friends at Tarsnap, the only secure online backup you can trust your data to. Even paranoids need backups. Feedback/Questions Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv Join us and other BSD Fans in our BSD Now Telegram channel

Eén op de drie kinderen praat online met vreemden. Op straat zou je in paniek raken, online haalt iedereen z’n schouders op. Astrid Oosenbrug zit aan tafel, en ze draagt een complete garderobe aan petten: medeoprichter van DIVD, CEO van DIVD Academy, interim-directeur bij HackShield en Public Affairs & CSR Officer bij ESET. We beginnen bij HackShield, de gratis game die kinderen van 8 tot 12 tot Cyber Hero opleidt, en belanden al snel bij Roblox. Randal bekent dat hij zichzelf binnen een half uur betrapte terwijl hij stiekem naar zolder liep om zijn eigen poppetje op de loopband te laten farmen. Hoe houd je jong hackerstalent op het goede pad? Bij de DIVD Academy gaat dat over ethiek: je kunt aantonen dat je in een systeem zit, maar je past geen cijfers aan. Astrid legt uit waarom Victor met maga2020! wel mocht inloggen maar verder niets aanraakte, hoe moneymuling werkt, en waarom het datalek bij Clinical Diagnostics voor sommige vrouwen letterlijk levensbedreigend is. Plus: meidenhuizen, dark patterns en het eindeloze kat-en-muis-spel om schermtijd. Over Astrid Oosenbrug Astrid Oosenbrug is medeoprichter van DIVD (Dutch Institute for Vulnerability Disclosure, bekend van onder meer de Kaseya-zaak in 2021) en medeoprichter en CEO van DIVD Academy. Ze is interim-directeur bij HackShield en doet Public Affairs & CSR bij antivirusbedrijf ESET. Van 2012 tot 2017 was ze Tweede Kamerlid voor de PvdA en gold ze als het meest digitale Kamerlid; tot juni 2025 was ze bijna zeven jaar voorzitter van COC Nederland. Ze keert in deze aflevering terug om twee lijnen te verbinden: kinderen veilig en ethisch leren omgaan met internet, en de strijd voor een veiliger en eerlijker net. LinkedIn: https://www.linkedin.com/in/astridoosenbrug/ Website: https://www.divd.nl/who-we-are/team/people/astrid-oosenbrug/ Sponsor: Red de AI Wet Kim van Sparrentak neemt het op tegen de techbro’s om duidelijke regels te maken voor kunstmatige intelligentie. Red de AI Wet besluiter je hier.In deze aflevering 0:00:00 Het meest digitale Kamerlid en een waslijst aan petten0:02:18 HackShield uitgelegd: gamen om Cyber Hero te worden (8-12 jaar)0:05:48 Roblox als verslavingsmachine, en Randal die zichzelf betrapt0:09:06 Dark patterns: waarom zelfs het klikgeluid is uitgedacht0:11:14 Meidenhuizen: gezellig, met een zieke wereld eronder0:13:39 Eén op de drie kinderen praat online met vreemden0:17:26 Kat-en-muis met schermtijd: de Word-truc en de Unix-computer0:25:32 Interim-directeur bij HackShield: governance en de stekker eruit0:28:46 Een onbetrouwbare overheid en de preventieparadox0:32:13 Gedrogeerd en gefilmd: 80.000 Nederlandse IP-adressen0:35:21 Waar meld je het als je per ongeluk klikt?0:46:31 DIVD Academy: van digitaal belletje trekken tot ethisch hacken0:58:39 Rebootcamp met de politie en ronselen via Discord0:59:55 Werkt een social-mediaverbod voor jongeren?1:06:33 Trumps wachtwoord en de grens van responsible disclosure1:08:09 Vraag Arnoud Wokker: moet programmeren en AI een schoolvak worden?1:13:28 Moneymuling: hoe kinderen ongemerkt witwassers worden1:21:02 Clinical Diagnostics: als een datalek levensbedreigend wordt Genoemd in deze aflevering HackShield Future Cyber Heroes, gratis game cyberweerbaarheid voor 8-12 jaar DIVD, vrijwilligers die kwetsbaarheden opsporen en melden DIVD Academy: The Ethical Hacker, gratis online hackcursus Offlimits, meldpunt online misbruik (voorheen Helpwanted) ATKM, autoriteit om kinderporno en terreurmateriaal te melden Stichting Cyberbrein, Henk van Ee begeleidt jonge cyberbreinen Effectevaluatie HackShield (Saxion), onafhankelijk onderzoek naar het lespakket Datalek Clinical Diagnostics, achtergrond bij het bevolkingsonderzoek-lek Tips van de tafel Astrid Oosenbrug: zet bij games als Roblox de chatfunctie uit; kies waar mogelijk voor “alleen mensen die je kent”. Astrid Oosenbrug: per ongeluk op iets verkeerds geklikt? Meld het laagdrempelig bij Offlimits of de ATKM in plaats van het weg te klikken. Randal Peelen: maak schermtijdafspraken samen mét je kind en leg uit waaróm, in plaats van alleen te verbieden, want een verbod lossen ze creatief op. Jurian Ubachs: spreek elkaar aan op gedrag dat niet oké is, ook bij een grap; wacht niet tot het slachtoffer dat zelf moet doen.See omnystudio.com/listener for privacy information.

This show has been flagged as Clean by the host. This series is dedicated to exploring little-known—and occasionally useful—trinkets lurking in the dusty corners of UNIX-like operating systems. Most users of UNIX-like systems are probably familiar with the diff utility. It is widely used with source code to compare two files and see what the differences are between them. Non-programmers, like me, also use it to examine what has changed in different versions of scripts or configuration files. Quite a few pieces of newer software can compare different versions of data and express changes in a format either identical to or similar to diff output. However, there are two other long-standing tools for this purpose that are far less known and deserve in my view to be termed UNIX Curios. The first of these is cmp 1 . While diff is primarily intended to be used on text files and compares them line by line, cmp compares files byte by byte. In my experience, its main use is to see whether two binary files are in fact identical—if they are, cmp outputs nothing and returns an exit status of 0. Back when methods of transferring files were not as reliable as they are today, this was a tool I would reach for sometimes. For example, you could use it to confirm that the data on a CD-ROM you burned was the same as the original. If there is a difference between the files, cmp will return an exit status of 1. By default, it will also print the location (byte and line number) of the first differing byte. When used with the -l option, it will print the location and value of every byte that differs. There is one exception to these: if the files are the same except that one is shorter than the other, it will print a message to that effect. The exit status will still be 1 in that case. Using the -s option with cmp will cause it to be totally silent and output nothing. Only the exit status will indicate whether the files are the same, different, or if the exit status is greater than 1, that an error occurred. This makes it useful for scripting, for example in case you wanted to confirm that a file copied to another location arrived fully intact. It is worth noting that diff is also capable of comparing binary files—however, it is not required by POSIX to report what is actually different or where differences occur. The same exit status as in cmp is returned: 0 if the files are the same, 1 if they are different, or greater than 1 if an error occurred. While many implementations offer an option to suppress the output, this is not in the standard 2 so the most portable method would be to instead redirect output to /dev/null . On my system the diff utility is three times the size of cmp , so if you don't need its extra capabilities, it is a less efficient way of doing the job. The other UNIX Curio for today is comm , and this utility 3 is also intended to compare two files to see what is common between them. Ken Fallon briefly talked about it a few years ago in HPR episode 3889 . Compared to the others, it has a much more specific use case. The two files are expected to be text files that are already sorted. What comm will do is print a tab-separated list of all the lines appearing in either or both files. Lines only in the first file will appear in the first column, lines only in the second file will be in the second column, and lines in both files will be in the third column. Any combination of the options -1 , -2 , and -3 can be used with comm to suppress printing of the first, second, or third column respectively. Using all three options at the same time is supported but it results in no output, so that isn't very useful. Unlike the other utilities, the exit status of comm doesn't tell you anything about the two files. It will be 0 if the program ran successfully, and greater than 0 if it didn't. I'm not sure if I have ever actually used comm for anything practical. I find its default output a bit difficult to meaningfully interpret, plus you need to ensure the two files are already sorted. It seems to be best suited to comparing lists, and one use case that Ken Fallon mentioned would be comparing two lists of files to see if any are missing. The command comm -3 listA listB would print files that only appear in listA in the first column and those only in listB in the second column. This would let you ignore all the filenames that appear in both and focus on those that were absent from one or the other. If on the other hand you only wanted to see the filenames that are on both lists, comm -12 listA listB would give you that. Some more frivolous potential uses also come to mind. If for some reason the cat utility is broken on your system, you could use comm listA /dev/null to print the file listA instead. If you want to insert tab characters before every line of a file but have an aversion to using sed or awk , then comm /dev/null listA would output listA with one tab before each line, and comm listA listA would insert two tabs. A bit silly, but it would work. The GNU implementation of comm even lets you choose something other than a tab to separate the columns 4 , so you could go wild with that. According to the POSIX specifications for cmp and comm , one of the two filenames given as arguments, but not both, can be a " - ", in which case standard input will be used for that "file" in the comparison. Also, the results are undefined if both arguments are the same FIFO special, character special, or block special file. Some implementations might not have these limitations, but you shouldn't rely on that everywhere. All three of these were developed quite early. The cmp utility appeared in 1971's First Edition UNIX 5 , while comm and diff seem to have made their debut in Fourth Edition UNIX 6,7 from 1973. The original versions might not have behaved exactly like their modern counterparts, and newer implementations (especially of the diff utility) have acquired additional options and capabilities, but the basic operation of each has stayed the same. The next time you need to compare files against each other, consider whether cmp or comm might be appropriate before automatically reaching for diff . They all have their uses in different situations. References: Cmp specification https://pubs.opengroup.org/onlinepubs/009695399/utilities/cmp.html Diff specification https://pubs.opengroup.org/onlinepubs/009695399/utilities/diff.html Comm specification https://pubs.opengroup.org/onlinepubs/009695399/utilities/comm.html GNU coreutils manual: comm https://www.gnu.org/software/coreutils/manual/html_node/comm-invocation.html First Edition UNIX cmp manual page http://man.cat-v.org/unix-1st/1/cmp Fourth Edition UNIX comm manual page https://www.tuhs.org/cgi-bin/utree.pl?file=V4/usr/man/man1/comm.1 Fourth Edition UNIX diff source https://www.tuhs.org/cgi-bin/utree.pl?file=V4/usr/source/s1/diff1.c Provide feedback on this episode.

OpenBSD 7.9, Critical Infrastructure in FreeBSD, GhostBSD Finance report, Solaris 11.4 updates, and more... NOTES This episode of BSDNow is brought to you by Tarsnap and the BSDNow Patreon Headlines OpenBSD 7.9 60th Edition has been released and Reported over on Undeadly Cleaning Up Critical Infrastructure in FreeBSD News Roundup Apple Wants to Kill Your Time Capsule but They Run NetBSD So They Can Not Oracle To Reduce The Frequency Of Solaris 11.4 Updates FreeBSD on a Thinkpad T14 Gen 2 Intel January 2026 Finance Report Beastie Bits The DragonFly site has a recently-updated page describing how DPorts is assembled and the process to contribute. TUHS - Unix use of VAX protection modes Origin of the rule that swap size should be 2x of the physical memory - The Duke and the Beastie - Improving OpenJDK support for FreeBSD Tarsnap This weeks episode of BSDNow was sponsored by our friends at Tarsnap, the only secure online backup you can trust your data to. Even paranoids need backups. Feedback/Questions Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv Join us and other BSD Fans in our BSD Now Telegram channel

This show has been flagged as Clean by the host. This series is dedicated to exploring little-known—and occasionally useful—trinkets lurking in the dusty corners of UNIX-like operating systems. In UNIX Curio #4 ( HPR episode 4617 ), I teased the subject of file compression. Today I'm circling back to that. The history of data compression goes back at least to the 1970s, and in contexts outside UNIX and computers, probably even earlier. Somehow, it is refreshing to learn that humans have always struggled to have enough storage space to keep all the data they want to hang on to. One way around this limitation is to use some form of compression. I am only going to dive into lossless compression for this episode—that is, a compression method that can be reversed and will spit out the original data bit for bit. Lossy compression methods also have their places: you might be familiar with their use for audio (such as Ogg Vorbis or MP3); it's also used for images (such as JPEG). Lossy compression allows some of the original data to be thrown away, resulting in a smaller file than is possible with lossless compression, but the intent is for the result to still sound or look "good enough" to a human observer. Also, I am going to limit my discussion to generic methods used for many types of data; while FLAC does lossless compression, it is specifically designed just for audio. I should make clear that I have never studied computer science or information theory, so this episode will not get into the science behind various types of compression algorithms and how they differ. But in general, these methods take advantage of the fact that many types of data have recurring patterns. English text mostly consists of words that often re-appear many times—source code similarly has keywords and variable names that recur. Compression is accomplished by representing a piece of data that occurs multiple times with a symbol that is shorter in length. The first compression program in the UNIX world I could find is called pack , from 1978 1 . It was shortly followed in 1979 by a similar program called compact 2 . Both of these used a technique called Huffman coding, but with some differences between them. Files compressed with pack were given a .z extension and compact gave filenames a .C extension. Roughly every five or ten years after this, a new program would come along and achieve lasting popularity. There were, and still are, two opposing forces facing any new form of compression. Working in favor was the advantages it provided—first among these was achieving a better compression ratio, but performance improvements such as speed or reduced memory usage could also be compelling. The force against any new method was the fact that it was not yet widely supported—it doesn't much help to have a smaller file if the people you share it with cannot decompress it. The next major advance in compression arose out of three scientific papers: two in 1977 and 1978 by Abraham Lempel and Jacob Ziv (called LZ77 and LZ78), and one by Terry Welch in 1984 which built on LZ78. This last method is typically referred to as LZW. Our UNIX Curio for today is a program called compress 3 that implements the LZW method. Files compressed this way are named with the extension .Z . I had always assumed that this was to honor Jacob Ziv, but now that I've researched the history, it seems more likely to be a follow-on from how files compressed by pack were named. Since pack did not use any of the Lempel-Ziv methods, I would guess that it used .z because that wasn't already taken by anything else, but that's pure speculation. I do recall encountering .Z files in the wild, but feel certain that hasn't happened in the last 25 years, maybe longer. If you need to expand one of these, uncompress 4 is the program to use ( GNU's gunzip can also handle them 5 ). However, there was a serious problem that arose with the LZ78 and LZW compression methods. Both of them were patented, and the owner became aggressive in seeking payment from developers and users. The compress utility was developed within two months of the publication of Welch's 1984 paper and was included in Bell Laboratories' Eighth Edition UNIX before these shakedowns started. The paper did not disclose that a patent had been filed, and apparently Spencer Thomas and the other developers of compress were unaware of it. The utility became popular for a while, and was even standardized by POSIX, but people moved away from LZW once the legal threats started. Another important advance came in 1991 and was called the DEFLATE compression method. It combined the un-patented LZ77 method with Huffman coding to achieve a similar level of compression as LZW (actually, often better) without the legal trouble. DEFLATE was developed for PKZIP and was soon adopted by the GNU project's gzip compressor. While Phil Katz (the "PK" in PKZIP ) patented one way of implementing the DEFLATE method, it was possible to write a compressor and decompressor without infringing 6 ; also, he apparently never tried to enforce the patent 7 . As I mentioned in UNIX Curio #4, .zip is both an archive and a compression format. Each archive member can be compressed with one of several possible methods (or stored without compression). Unlike a tar file where compression can be applied to the entire archive, in .zip each archive member is compressed individually. This often means a .zip file will be slightly bigger than a tar file with the same contents compressed with gzip , because the .zip format cannot take advantage of duplication that occurs among more than one member of the archive. The vast majority of .zip files use only the DEFLATE and uncompressed storage methods and these are the only options if you want to follow the profile standardized in ISO/IEC 21320-1. Actually, since they both use DEFLATE, gzip is able to extract a .zip file in the special case where it only holds one member compressed with that method. From the 1990s onward, people paid significant attention to avoiding patent landmines, so only methods that didn't have that problem became broadly popular. While the patents on LZ78 and LZW have since expired, I feel like their most successful legacy was in discouraging people from using those methods, leading to DEFLATE taking the popularity crown. The next step came in 1996 and 1997 with the development of bzip and bzip2 by Julian Seward. The original method was quickly followed by bzip2 , which was the version that achieved true popularity. They use the Burrows-Wheeler transform, which does not itself compress data but re-arranges it to make it more compressible; this is combined with other techniques 8 . (At least, that's my understanding. I told you, I'm not up on information theory.) This provides a significant reduction in the compressed size of the data compared to earlier methods—however, it is slower than DEFLATE both during compression and decompression. Separate projects have developed parallel versions of gzip and bzip2 that can take advantage of multi-processor machines, but the original utilities run single-threaded. Another five years later, in 2001, Igor Pavlov added the Lempel-Ziv-Markov chain algorithm (LZMA), an enhancement to LZ77, to his 7-Zip compression tool. This was followed a few years later by LZMA2, a container format that allowed for LZMA compression to be split between multiple threads. Broad LZMA2 support came to the UNIX world in 2009 with the xz utility 9 . It offers roughly similar compression ratios to bzip2 , though it can be better or worse depending on the data to be compressed. While compression generally takes even longer than bzip2 , decompression is significantly faster (though still not as fast as gzip ). The Linux kernel relatively quickly supported booting from xz-compressed images 10 because it was a good match for that use case—compression, the time-consuming activity, only has to be done once while the more frequent decompression during boot happens relatively fast. The last method I will cover is Zstandard 11 , often written as zstd . This came about in 2015, and is another variation on LZ77 that uses finite-state entropy (which means nothing to me, but you might understand it). It performs about as well as DEFLATE in terms of compression ratios, but is much faster both when compressing and decompressing data. I should say that these statements are true with the typical default settings—depending on the compression level selected, it can compress more slowly, but compress the data smaller. However, decompression is always speedier than DEFLATE. This makes it attractive for some uses, and it is heavily promoted by Meta/Facebook, where Yann Collet developed it. For example, shipping large amounts of actively-used data between machines in a data center can go more quickly when the size is reduced; however, if the compression and decompression steps take too long that benefit is lost. A speedy method can be valuable even if it doesn't result in the greatest reduction in size. This use case stands in contrast to, say, a compressed backup file which might only be accessed in a disaster recovery scenario or never accessed at all, making size more important than speed. Both the xz and zstd utilities have some built-in support for multi-threading, but the default is to run in a single thread. While xz can use multiple threads for decompression (but only if the file was compressed in multi-thread mode), the reference zstd utility can only use more than one thread for compression, not decompression. There are many other methods of lossless compression that have been developed over the decades, but I believe these are the ones you are most likely to encounter in the world of UNIX-like systems. This is a personal opinion, and others might choose a different set. As mentioned, it can be tough for a new method to gain popularity and 35-year-old DEFLATE is still probably the most commonly used despite not being the fastest or offering the greatest reduction in size. Even systems like FreeBSD, NetBSD, and OpenBSD that do not like to include GNU tools supported it by developing their own version of gzip based on the permissively-licensed zlib library. Technically, the LZW method used by the compress utility is still standardized by POSIX, so one might expect it to have the widest support. However, aggressive patent enforcement discouraged adoption, especially by Free and Open Source Software systems—even though the patent has expired, it is still out of favor compared to DEFLATE. For this reason, I feel justified in calling it a curio. References: Eighth Edition UNIX pack.c https://www.tuhs.org/cgi-bin/utree.pl?file=V8/usr/src/cmd/pack/pack.c 2.9BSD compact.c https://www.tuhs.org/cgi-bin/utree.pl?file=2.9BSD/usr/src/ucb/compact/compact.c Compress specification https://pubs.opengroup.org/onlinepubs/009695399/utilities/compress.html Uncompress specification https://pubs.opengroup.org/onlinepubs/009695399/utilities/uncompress.html GNU Gzip manual https://www.gnu.org/software/gzip/manual/gzip.html RFC 1951: DEFLATE Compressed Data Format Specification version 1.3 https://tools.ietf.org/html/rfc1951 History of Lossless Data Compression Algorithms: The Rise of Deflate https://ethw.org/History_of_Lossless_Data_Compression_Algorithms#The_Rise_of_Deflate bzip2 https://en.wikipedia.org/wiki/Bzip2 XZ Utils https://en.wikipedia.org/wiki/XZ_Utils 2.6.38 merge window part 2 https://lwn.net/Articles/423541/ zstd https://en.wikipedia.org/wiki/Zstd Appendix The table below demonstrates the results of compressing different types of data using tools described in this episode. While not totally rigorous, I did run each compression and decompression multiple times to ensure I was getting consistent results. The laptop I used has an Intel Core i5-6200U CPU running at 2.30GHz, and the system had at least 5 GB of free memory for each run. While this processor has two cores and can run four simultaneous threads, all utilities were run single-threaded. The term "best" means the highest level of compression available (the exact level used is shown). For bzip2 , the default is the best. For zstd , "best" is -19, which is the highest "normal" level, but "ultra" levels that are even higher also exist. Ratios are the percentage of the original size that the file was reduced to (other sources might instead express the compression ratio as the reduction in size achieved). In all results, smaller numbers are better. ┌────────────────────────────┬─────────────┬─────────────┬─────────────┬─────────────┬─────────────┬─────────────┬─────────────┐ │ │ gzip │ gzip │ bzip2 │ xz │ xz │ zstd │ zstd │ │ │(default -6) │ (best -9) │ (-9) │(default -6) │ (best -9) │(default -3) │ (best -19) │ ├──────────────┬─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┤ │ │Size (ratio) │ 22,036,508 │ 21,891,623 │ 15,795,698 │ 13,487,768 │ 12,938,464 │ 20,454,657 │ 13,709,078 │ │ │ │ (24%) │ (24%) │ (17%) │ (15%) │ (14%) │ (23%) │ (15%) │ │English Text ├─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┤ │(90,532,092 │Compression │ 4.8s │ 7.6s │ 8.5s │ 49.8s │ 58.8s │ 0.6s │ 65.2s │ │bytes │time │ │ │ │ │ │ │ │ │uncompressed) ├─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┤ │ │Decompression│ 0.7s │ 0.8s │ 3.7s │ 1.2s │ 1.2s │ 0.4s │ 0.4s │ │ │time │ │ │ │ │ │ │ │ ├──────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┤ │ │Size (ratio) │ 125,291,122 │ 124,189,544 │ 98,016,512 │ 84,882,492 │ 81,954,344 │ 120,604,855 │ 87,298,645 │ │ │ │ (21%) │ (21%) │ (17%) │ (14%) │ (14%) │ (20%) │ (15%) │ │Source Code ├─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┤ │(590,008,320 │Compression │ 22.0s │ 39.3s │ 54.8s │ 241s │ 298s │ 3.7s │ 348s │ │bytes │time │ │ │ │ │ │ │ │ │uncompressed) ├─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┤ │ │Decompression│ 5.1s │ 5.1s │ 20.3s │ 8.1s │ 7.8s │ 2.4s │ 2.4s │ │ │time │ │ │ │ │ │ │ │ ├──────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┤ │ │Size (ratio) │ 32,830,905 │ 32,371,241 │ 26,856,579 │ 20,717,288 │ 20,352,880 │ 28,538,810 │ 23,154,582 │ │ │ │ (19%) │ (19%) │ (16%) │ (12%) │ (12%) │ (17%) │ (13%) │ │Binary Program├─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┤ │(171,972,264 │Compression │ 6.4s │ 22.4s │ 18.6s │ 62.2s │ 67.8s │ 0.8s │ 111s │ │bytes │time │ │ │ │ │ │ │ │ │uncompressed) ├─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┤ │ │Decompression│ 1.5s │ 1.5s │ 5.6s │ 2.3s │ 2.3s │ 0.7s │ 0.7s │ │ │time │ │ │ │ │ │ │ │ ├──────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┤ │ │Size (ratio) │ 146,397,772 │ 146,397,757 │ 144,485,451 │ 131,950,232 │ 130,926,780 │ 147,154,979 │ 145,703,840 │ │ │ │ (89%) │ (89%) │ (88%) │ (80%) │ (80%) │ (90%) │ (89%) │ │WAVE Audio ├─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┤ │(164,396,302 │Compression │ 9.2s │ 9.2s │ 25.1s │ 70.4s │ 97.7s │ 0.7s │ 58.3s │ │bytes │time │ │ │ │ │ │ │ │ │uncompressed) ├─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┤ │ │Decompression│ 2.0s │ 2.0s │ 13.5s │ 12.2s │ 12.1s │ 0.6s │ 0.8s │ │ │time │ │ │ │ │ │ │ │ ├──────────────┴─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┤ │ │ gzip │ gzip │ bzip2 │ xz │ xz │ zstd │ zstd │ │ │(default -6) │ (best -9) │ (-9) │(default -6) │ (best -9) │(default -3) │ (best -19) │ └────────────────────────────┴─────────────┴─────────────┴─────────────┴─────────────┴─────────────┴─────────────┴─────────────┘ English text consists of Titles 1 through 10 of the 2020 U.S. Code of Federal Regulations . Source code consists of a tar file containing the Linux kernel source, version 4.0. Binary program consists of an ELF-format executable of the pandoc application, version 2.17.1.1 found on Debian 12. Audio consists of a 24-bit Signed Integer PCM WAVE file with 2 channels at 44.1kHz, about 10:21 in length. For comparison, the audio-specific flac lossless compression utility reduced this file to 97,962,711 bytes (60%) in 2.6 seconds at the default (-5) level and to 97,714,876 bytes (59%) in 5.4 seconds at the highest (-8) level. Provide feedback on this episode.

The NetBSD/FreeBSD Merge announcement, the rise and fall of SPARC, GhoseBSD 26.2 and more... NOTES This episode of BSDNow is brought to you by Tarsnap and the BSDNow Patreon Headlines NetBSD/FreeBSD will not merge, November 1993 announcement Rise and Fall of SPARC: Why No One Misses It News Roundup Help needed testing GhostBSD 26.2 Redundant DHCP server and DNS Resolver using OpenBSD and FreeBSD Universities And In house Tech Beating my head on OpenVPN Tarsnap This weeks episode of BSDNow was sponsored by our friends at Tarsnap, the only secure online backup you can trust your data to. Even paranoids need backups. Feedback/Questions Paul - Feedback Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv Join us and other BSD Fans in our BSD Now Telegram channel

Take the 2026 AI Engineering Survey and get >$2k in credits and AIE WF tickets!On the product side, everyone is getting Computer - Perplexity, Manus, Cursor, and so on. Meanwhile on the research side, agentic evals like TerminalBench and GDPVal are also assuming computer (Harbor). On both ends, the consolidating LLM OS stack has become a standard toolkit, and Daytona is one of a small set of AI Infra companies that are booming because of it.“The end of localhost” has been Ivan Burazin's obsession for more than a decade.Something that is all too familiar…Long before agents became the default way people talked about software development, Ivan was already chasing the idea that development should not depend on a fragile local machine. CodeAnywhere, one of the first browser-based IDEs, was an early attempt at that future: move the development environment into the cloud, make setup reproducible, and free developers from the endless “works on my machine” tax.The thesis was directionally right, but the market wasn't ready yet.However, agents changed that. They do not care about a laptop, desk setup, or favorite editor. They need a computer they can access through an API: something stateful enough to keep working, fast enough to spin up instantly, flexible enough to resize, isolated enough to be safe, and composable enough to run the messy real-world workflows that real software engineering actually requires.Daytona isn't just selling “sandboxes” in the narrow code-execution sense. It is the latest version of Ivan's original localhost thesis.In this episode, Daytona's CEO joins swyx to explain why AI agents need more than code execution boxes: they need composable computers, stateful sandboxes, instant startup, dynamic resources, and infrastructure that can survive workloads going from zero to 100,000 CPUs.We go deep on the new agent compute market: Daytona's hard pivot from human dev environments to AI sandboxes, the New Year's Eve MVP that customers begged for, why Daytona runs on bare metal with its own scheduler, how one customer runs almost 850,000 sandboxes a day, and why RL/eval workloads went from 0% to roughly 50% of usage in just months. Ivan also explains why agents need Windows and macOS machines, why CLI may matter more than MCP, why Kubernetes is painful for this workload, and why the future AI cloud may look more like Stripe than AWS.We discuss:* How Daytona grew out of CodeAnywhere, Shift, and the “end of localhost” thesis* Why Daytona pivoted from human dev environments to AI sandboxes* Why agents need composable computers instead of disposable code execution boxes* The New Year's Eve MVP that customers chased API keys for* Why Daytona chose bare metal, stateful snapshots, and its own scheduler* How Daytona spins up one sandbox in ~60ms and 50,000 sandboxes in ~75 seconds* Why Daytona's biggest customer runs ~850,000 sandboxes a day* How RL/eval workloads create zero-to-100,000 CPU spikes* Why RL workloads went from 0% to roughly 50% of Daytona usage* Why customers compare Daytona against EKS/GKS and say they're “never going back”* Why every AI agent may need a computer, including Windows and macOS environments* The Apple licensing constraints that make macOS sandboxes hard* Why CLI gives agents more power than MCP* How open source helps agents integrate Daytona* Why agent-generated PRs may break today's CI/CD assumptions* Why AI SaaS companies reselling tokens may face a cold shower* Why the AI cloud may look more like Stripe than AWSIvan Burazin* LinkedIn: https://www.linkedin.com/in/ivanburazin* X: https://x.com/ivanburazinDaytona* Website: https://www.daytona.io* X: https://x.com/daytonaioTimestamps* 00:00:00 Hook* 00:01:12 Introduction* 00:03:15 CodeAnywhere, Shift, and the end of localhost* 00:05:58 What Daytona is: composable computers for AI agents* 00:08:07 The pivot from dev environments to AI sandboxes* 00:10:17 The New Year's Eve MVP and customers begging for API keys* 00:12:56 Bare metal, stateful sandboxes, and Daytona's scheduler* 00:17:28 60ms startup, 50,000 sandboxes, and 850K daily runs* 00:21:53 Spiky RL/eval workloads and the new agent infra problem* 00:28:12 RL workloads, Kubernetes pain, and dynamic resizing* 00:33:31 Why every AI agent needs a computer* 00:38:48 macOS sandboxes and Apple's licensing problem* 00:44:28 Why CLI may matter more than MCP* 00:48:11 Open source, GitHub stars, and agent integration* 00:53:11 Git, CI/CD, and agent collaboration bottlenecks* 00:58:15 Founder life and building a 25-person infra company* 01:02:44 AI SaaS, token resale, and API-first business models* 01:06:10 GPU sandboxes, data centers, and compute growth* 01:09:48 Why the AI cloud may look more like Stripe than AWS* 01:11:26 Closing thoughtsTranscriptIntroduction: Daytona, CodeAnywhere, and the End of LocalhostSwyx [00:00:02]: Okay, we're in the studio with Ivan Burazin, CEO of Daytona. Welcome.Ivan [00:00:07]: Thanks for having me, man.Swyx [00:00:08]: Ivan, you and I go back.Ivan [00:00:10]: Way back.Swyx [00:00:11]: How I don't even know how, you found, did you reach out or, for Shift.Ivan [00:00:17]: I reached out to you. The reason was you - we were just - we were thinking about I was one of the co-founders of CodeAnywhere, the first browser-based IDE, and so we were thinking a long time of, localhost should die. And you had this article.Swyx [00:00:29]: End of localhost.Ivan [00:00:30]: Then I reached out to you because of that, and then we talked, and I was actually at a different job and learning about I was the head of, developer experience, and you were quite well-versed in that, and I actually reached out to you, among other people, how do we go about that? What are the key things and whatnot at this point in time? And you were nice enough to take the call, and I remember I was late on your call with you.Swyx [00:00:51]: I don't remember.Ivan [00:00:52]: I remember because I was with my then I'm thinking of a girlfriend or wife at that point in time, I'm not sure. It's the same person, so that's great, and I was late ‘cause we were, in, Italy on, vacation, and then I was late for something. I felt so bad, and you were so nice to be, good about.Swyx [00:01:10]: The reason I'm nice is because I'm also late to other people, so it's like, who's, who's without sin here, yeah, so I have to, for those who don't know, InfoBip Shift, there's this whole thing that, you did in the past, and, and that was basically one of the inspirations for me starting AI Engineer, which is like, I have to thank you for giving me that push to be like, “Oh, you can, you can build and sell conferences?”Ivan [00:01:34]: I remember you asked you asked me at the beginning to give me advisory shares, and I was so focused on what we were doing, I said no, and I should've took the advisory shares. So I'm sorry, dude. But anyway.Swyx [00:01:43]: We're not, we're not venture backed.Ivan [00:01:44]: No, it doesn't matter.Swyx [00:01:45]: It's Yeah, anyway, so I think what's impressive about you is that CodeAnywhere is the thing that you've been trying to build, and, you kind of put it on hold and then came back after InfoBip. Just give us the story, do you - the story and the origin story, going into Daytona.From CodeAnywhere and Shift to DaytonaIvan [00:02:05]: Sure. Like, really way back, me and my co-founder have been together. I say this, I've said this multiple times, it's like we were married and divorced and married. Some people actually ask me is my co-founder my partner. they thought it literally. It's not literally, but we have done multiple companies together, and to your point, we had this shift where we went from the CodeAnywhere to the conference called Shift, and then back to, Daytona. We originally started stacking servers, doing like virtualization in the early 2000s and, routers and doing basically all these things, at a foundational level, and that was a services company which we sold to focus on what my co-founder actually invented, which was the very first browser-based IDE, right, I say the first. Before us was actually Heroku. They did it for a very short time until they became Heroku. But outside of them, we were the only one, and it was called.Swyx [00:02:55]: There was Cloud9.Ivan [00:02:57]: Cloud9 came out slightly after us. There was Replit, which came out when we stopped doing it, Replit came out, and they have been successful since then, which is great. There was Nitrous.io. There was quite a few that existed at the time, but it was like too early. But the interesting part is that we, at that point in time, because there was no VS Code, there was no Kubernetes, and Docker had just started when we Or I'm not sure if it was even public at that point in time. And so we had to build everything to the whole stack ourselves and that was the key learning that we brought into and that we've been using in Daytona today. So it was super early. There's about 3 million people used CodeAnywhere. It was slightly, it was angel-backed more than venture-backed. We ended up paying everyone back because it didn't have that sort of scale. But, three years ago, we started something similar with Daytona, which is not what we are today, but it was automating dev environments for human engineers, the basically the underlying stack of CodeAnywhere. And then we did a hard pivot last January to sandboxes. And so here we are.Swyx [00:04:01]: Historic pivot, yeah, and, it's one of those things where, I had independently invested in CodeAnywhere, but also in E2B, and then both of you pivoted into the same thing, and I'm like, “F**k.”Ivan [00:04:12]: You invested, you invested in Daytona. You invested in Daytona. But you were the first If we had not got your check, we wouldn't have done it.Swyx [00:04:18]: No way.Ivan [00:04:19]: No, it was like, “We have to get him on board first,” and you were that kicker that we, that got us off the ground.Swyx [00:04:23]: No, because you were putting me on your pitch deck, man. I was like, “Man, this is like a good trip if I don't invest.”Ivan [00:04:29]: That's because it was your quote. It's like we.Swyx [00:04:30]: Yeah. It's the end of localhost.Ivan [00:04:31]: Did a bunch of research about end of localhost and who was interested in that,.Swyx [00:04:34]: No, that's like, I put, I wrote that blog post, and every single company in that field reached out to me, and then every VC who was receiving those pitches then also had to call me and, talk it, talk through it with me.Ivan [00:04:47]: It's finally happening though.Swyx [00:04:48]: It was really super interesting.Ivan [00:04:48]: It's finally happening.Swyx [00:04:49]: It's finally happening.Ivan [00:04:49]: Yeah, it's finally.Swyx [00:04:49]: It's finally happening, with maybe sort of non-human users. Yeah, so what is Daytona today? Let's get like a quick description. I'm wearing the shirt.What Daytona Is Today: Composable Computers for AI AgentsIvan [00:04:58]: You're wearing the shirt. Yes,.Swyx [00:04:59]: It says, I think your branding is very good. Like, it's very consistent. It runs AI code. Like, it cannot be simpler.Ivan [00:05:05]: Exactly, but we're gonna probably have to change that.Swyx [00:05:07]: Oh, s**t.Ivan [00:05:07]: It's also a subset of what we do. Unfortunately, we really love this, Run AI Code is super simple. People interpret it different ways. I think we've given out 5,000, 6,000 of these shirts. People wear them with pride because it doesn't really market about us.Swyx [00:05:21]: Yeah, Daytona's on the back.Ivan [00:05:22]: It markets the back. It markets to the person itself, so I think we did a really good job on that one. But it is also a subset of what we do, because people, when they think about Run AI Code, they just think about these small, let's call it isolates, code execution boxes that, you send some code, you get an output. Whereas what Daytona is today is essentially composable computers for AI agents. It is, the market calls them sandboxes which can be misleading.Swyx [00:05:44]: All these things. All these things on.Ivan [00:05:45]: Yeah, exactly, ‘cause it can be misleading ‘cause people usually think about sandboxes as a demo or a test environment versus a production-grade environment. But what Daytona does, if you think of the laptop that you have in front of you or the computer that's over there, or, my wife is an architect, so she has like a Windows with a 3D graphics card inside to do 3D rendering. Like, as humans, we have different computers or different compositions of computers. And our belief is strongly that agents today and going forward will need all these different compositions of computers to do different types of tasks. And so we offer that basically through an API.Swyx [00:06:19]: Yeah, to give people - I'm trying to sort of front-load all the aha moments or the wow moments so that people can, stay engaged and click like and subscribe. the market is exploding, right? Like, you have been reporting 74% month-on-month growth, and it also, it's just been growing for a while. Like, it's been going like this. And every single - It's not just you guys. It's every single.Ivan [00:06:41]: Everyone, yeah.Swyx [00:06:42]: Sort of, compute provider. I don't know if you agree with me saying compute provider or not.Ivan [00:06:48]: It's fine.Swyx [00:06:48]: Yeah. So like organically PLG-driven growth, but also enterprise is doing super well, I think I wanna rewind to January of last year when you did the pivot. Like, so you obviously called this market early, and you were positioned for it, and you are now one of the market leaders. But what was the insight that made you do the pivot?The Pivot: From Human Dev Environments to Agent SandboxesIvan [00:07:06]: The insight that made us do this pivot is the quarter before that, so end of 2024, when we had - Basically, we did a demo with - I don't I think we discussed this as well, Devin was not public. You actually gave me access to Devin at that time. So Devin.Swyx [00:07:25]: I did?Ivan [00:07:26]: Yeah, you gave me access.Swyx [00:07:26]: I don't think I was supposed.Ivan [00:07:27]: Yeah, exactly.Swyx [00:07:28]: Yeah, I.Ivan [00:07:28]: So it doesn't matter. You.Swyx [00:07:29]: Yeah. I gave like three friends access.Ivan [00:07:31]: Yeah, or it was a call and you showed it to me. It doesn't matter. but OpenDevin was available, which is now called OpenHands. And so we're like, “Oh, this seems to be a thing. This is not public. Let's take our for human automation of dev environments and take, OpenDevin and launch that as a SaaS.” And we did that. Not very many people signed up and used it, but a lot of people reached out that were building agents, and they were like, “Hey, my agent needs a compute sandbox runtime,” whatever you wanna call it. I forgot what it was called at that point. And then we were like, “Oh, amazing. This is a new market. Here is our infrastructure. Here's our product, and go.” And what we found really fast, soon, was that people did not like what we had built. It didn't work. And I remember talking to people at the beginning when we're doing this, the sandbox we're building for agents. People were like, “Oh, why is it different? It's the same thing. We have like EC2, we have VMs, we have all these things.” But we saw that everyone we gave it to, it was like 20, 30 people, they all said, “No.” Like, “This is not what we need. This sort of breaks.” And basically, me and my co-founder not knowing a lot about - ‘cause we're infra people. We're not AI people. So I basically took it upon myself to like watch every single podcast that exists, including all of, all of these and all that, and sort of get up to date, read all the blogs, like get, understand what's going on.Swyx [00:08:45]: Do you wanna shout out who else was useful, just in case people are also looking.Ivan [00:08:49]: Generally we -, I looked at There's a few of podcast, different segments and different types. So there's you guys, No Priors, Bill Gurley's was great while.Swyx [00:09:04]: VG2, yeah.Ivan [00:09:05]: Yeah, while it was around. So there's a few. 20VC is interesting from a different dynamic, and some are different dynamic. But there was, also Red Points.Swyx [00:09:14]: We're not really about the compute market.Ivan [00:09:15]: It was also already - Sorry?Swyx [00:09:16]: You're, you want - You're looking at the agent infra market.Ivan [00:09:19]: I was looking at the agent market and the AI market in general and sort of understanding who are the players, what the perception, and how that goes. And like obviously you complement this with like going to conferences, going to events, going to meetups, reading white papers, like doing all the things that you have to do to understand what's happening. And so when we figured, when we sort of had an idea of what we had to build, literally over the New Year's Eve, literally on New Year's Eve, I half vibe coded the first MVP, first minimal viable product of what Daytona is today. And I went to sleep at like 3:00 AM or something like that. I was doing - I just put my like baby daughter and wife to sleep and, Happy New Year's, and go back to just, doing this. And I sent it to my co-founder, my CTO, and he saw it in the morning. He's like, “This is absolute garbage.” “Do not show this to anybody at all, but the idea is good.” And so he took two weeks, and he rebuilt it.Swyx [00:10:09]: Did it like look like that? Listen, I - It was rough idea.Ivan [00:10:12]: Oh, not even, not even close. Like it was it was way worse. But it was like a very - It was a simplistic view of what it should be. Like, it worked, but it was not ideal. And so he went, we went down the whole, which is his job as CTO, to go, and he came back with this version. We then called all the people that had said like, “This is garbage,” a quarter ago. And we set up these calls, and we gave it to - We just demoed it to everyone. And all the calls went long, every single one. They were 15-minute calls, and they all went to like 25, 30 minutes or whatnot. And everyone said, “We need, we want access.” There was no login, just an API key, ‘cause it was just a beta or an alpha. And they said, “Oh, we want access.” And we're like, “Sure, yeah. Okay, thank you very much.” But after like the next day, if we'd not send it, every single one, like every call that we did, everyone came back, “Where is my API key?” Like everyone wanted it. We're like, “S**t.” Like this is it. Like I've never felt So one, the understanding to your point was like most people thought it was the same infrastructure for humans and agents. We understood a quarter ago it's not. We just didn't know what was the right primitive. And then when we came, and we can talk about what that is, and we gave it to these people, I've never seen, I've never experienced - I've done multiple companies in my life. I've never experienced this, that people literally call you if you do not give them access. Like they want access right now. And so it's like, okay, they don't want this. the thing that they want doesn't seem to exist, or they have not found it, and they really want what we want. And then when we understood that we're onto something, and then when you think about the size of the market, like the market for human engineers and enterprise is a very large market, so think GitLab or whatnot. But the market for every single agent that will exist ever in the future is just like, what is that market? How big is that? And we're like, “We are all in on this.” And so that is where we made sort of the cut between the old product and the new one.Bare Metal, Stateful Sandboxes, and the Lambda + EC2 ModelSwyx [00:12:02]: Yeah. But it wasn't composable at the time?Ivan [00:12:05]: It was very - It was basically just a Linux box that you could change, that you could define number of CPUs, disk, and RAM. Like that is what you could do, but you couldn't have multiple operating systems, you couldn't resize it on the fly, you couldn't add a GPU, you couldn't do like all the things. It was just the, just the first sort of variation of that, yeah.Swyx [00:12:22]: Was it bare metal from the start?Ivan [00:12:24]: It was bare metal from the start. And so the interesting thing that we thought about right away, so our.Swyx [00:12:29]: Which, give people the background, what is the normal path?Ivan [00:12:32]: Yeah, so, basically most providers run this on top of VMs. And also.Swyx [00:12:37]: Firecracker.Ivan [00:12:38]: Yeah, they run on Firecracker and VM. And so we also fire - We can get - We have multiple isolation layers and we can do that. But the common way to do it is that they, one, that the state of the machine, or the hard disk is not part of the sandbox itself. And the other thing is they're not meant to last forever. So most of them are preemptible, like they can There's a time that they can live. And so our thought was when we were going into this is, agents will be like humans in the sense of you don't want your laptop to be shut down until you're done with work. Like, and you want to close the lid and open the lid, it's the same state. So you - Agents would want that, like the pause and come back. They want those two things. But also agents really want speed, right? Can they get it? So when we thought about it's like we need something insanely fast, how to make it fast, how to make it long-running, and stateful. And so those two things, it's like combining a Lambda and an EC2, right? Those two things together. And so we didn't have an idea how others did it, ‘cause we didn't know too that there was a market around this. It was more like, okay, this is what we need, what they need. And we looked at Kubernetes, it wasn't wasn't good enough for that. We looked at Nomad, it didn't enable that. And so our history in rewriting our own scheduler at CodeAnywhere is basically what my CTO came up with. Like, he's like, “Oh, the learnings from there,” and he brought it. And the funny thing is, our third co-founder, when he saw it, he's like, “Dude, what is this? This is like 2008.” Like, we went back in time, and he's like, “Exactly.” And so the reason why Daytona is like super fast, and you see this on benchmarks, is we essentially, we run on bare metal. We have our own scheduler, we use the underlying, disk, CPU, and RAM of the underlying machine, which means your IOPS are insanely fast because there's no, there's no network between an EBS or something like that. But also the snapshot, the point in time, the templates, are also preloaded on the bare metal machines. So when you fire off a sandbox from a template or a snapshot, you're essentially directed to the bare metal machine where that snapshot is based on that NVMe drive, and then it literally just turns on that machine, and it's local. There's no network latency, anything on there. And so that is sort of the specificities that we, when we're thinking from first principles, what a computer would look like for an agent, that is what we came up with, and that's what we created.Benchmarks, 60ms Startup, and 50,000 SandboxesSwyx [00:15:02]: Yeah. I should maybe, I don't know if you endorse this, but there's someone that does compute SDK, you guys do very well on there, with like the TTI, right? I. is this a, is this a is this a relevant benchmark for you guys? I don't know.Ivan [00:15:16]: I don't know, and it changes every day. So today RKL is.Swyx [00:15:18]: I don't know what RKL is. Never heard of it.Ivan [00:15:20]: Yeah. RK, yeah, so it is there.Swyx [00:15:22]: You are, at least a third of the next tier of performance, and then, there's a lot of other better-known names that are very slow to start.Ivan [00:15:31]: Yeah. We've been the number one by far for a long time, and now there's different, there's different definitions also of sandboxes, different isolation patterns, different other things. So RKL runs it literally on the S3, the data, so it's very different, and they spin up a sandbox, spin up a container for that, so it's a different type of thing. So the definition of a sandbox is something that we can all, we all need to get along with. But yeah, we're insanely fast on getting these things, up and running. And so you can see even there that it's a zero point 0.10 to 0.11, so.Swyx [00:16:03]: Close enough. Yeah. what else do you need, right?Ivan [00:16:05]: Yeah. So the benchmarks itself, so, in this, in I don't think the benchmarks equate to market ownership or revenue or anything like that. and I've seen this with multiple benchmarks, not just in sandboxes, but in general benchmarks around.Swyx [00:16:20]: It's table stakes. It's just like.Ivan [00:16:21]: Exactly. But it doesn't hurt.Swyx [00:16:22]: Just roughly check.Ivan [00:16:22]: Like you definitely have to be up there and you have to be competing so that people know that, oh, this is definitely one of the top. Because this is only one dimension of what customers look for. There's other things like how many can you spin up consecutively? There's a feature set, there's support, there's like all different things that people look at, but you definitely have to be there, on the benchmarks.Swyx [00:16:40]: How many people do people spin up consecutively?Ivan [00:16:43]: So we have.Swyx [00:16:43]: Or concurrently, is the Concurrency, right?Ivan [00:16:45]: There's three metrics that we look at. And so one is like time to spin up one, and so our time to spin up one is 60 milliseconds with network latency. So request, spin up, reply, 60, the whole thing, 60 milliseconds. That is one. But if you wanna spin up 50,000 at once, we are now at about 75 seconds. So it takes about 75 seconds to spin up concurrently 50,000. Some others, there's public data around this, like take 2,000 seconds, which is 30 minutes. Like there's different variations of that. And then there is the so it is speed of one, speed of like multiple, and then how many can you consistently have up and running. And so we basically have right now no limit to how much we can add because we basically own our own metal. But the biggest customer of ours does like about 850,000 every single day is sort of where they're, where they're just shy of a million every single day that they're running, we do have a request for half a million concurrent, which is literally half a million CPUs somewhere running. So that's an interesting.Swyx [00:17:44]: They pay by like vCPU seconds.Ivan [00:17:47]: By seconds, yeah.Swyx [00:17:47]: Or whatever. Yeah. Okay, and so and then, and the other thing is, the sleeping and the resuming, ‘cause it's all the stateful resumption of all these things, how, what kind of workload are people putting through this, right? Like how is it Do we measure by gigabytes in memory, gigabytes in storage? I don't In like network attached storage. I, what are the costly ones of, out of all these features?Workload Economics: CPU, RAM, Network, and StorageIvan [00:18:15]: The most expensive thing are CPU.Swyx [00:18:18]: Okay. Yeah, of course.Ivan [00:18:18]: The second one, yeah Then it's RAM, then it's disk. We actually don't charge.Swyx [00:18:22]: Which is snapshotting, right?Ivan [00:18:23]: No, it's actually the, snapshotting's part of it, but basically the size of your hard disk, of your machine. So do you have 10 gigabytes, do you have 20, do you have 50, do you have whatever? And then the transference of that. Right now, currently we don't charge for, network at all at Polychron.Swyx [00:18:37]: Oh, you gotta, yeah, you gotta fix.Ivan [00:18:38]: Yeah. It is very much a it's a larger and larger part of our bill, so we're working around, that part there. Obviously, that is the least, expensive, so the hard disk is the least expensive, so it's basically CPU, RAM, for us network, ‘cause we don't charge the customer, and then hard disk, is how it's split up. But there's also different types of workloads, so we basically split it up into two types of workloads in Daytona. One is what we call background agents or long-running agents. and the other is, basically RLs and evals, which I put sort of together. And so they have very different patterns of usage, and if you look at the usage of a background And I'll just name names of companies, not specifically.Background Agents vs. RL/Evals: Two Usage ShapesSwyx [00:19:21]: Yeah, open, all hands.Ivan [00:19:23]: Yeah. So like a background agent's a Cognition, a Lovable, a like all these things are Harvey. These are all long-running, background agents. And so if you look at their usage patterns, their usage patterns are similar to human, which is like follow the sun. Basically, the usage patterns of that is like noon is probably the highest, and the midnight is the lowest, and then weekends are lower. weekday is higher.Swyx [00:19:42]: Yeah, that's a fun question. How global is it? Is it very US-centric or?Ivan [00:19:46]: The US is a large part, but we have currently, we have Asia, Europe, and the US regions.Swyx [00:19:52]: So it's quite global.Ivan [00:19:53]: Yeah, it's quite global. We have it all over. It's interesting that our I talked to you a bit about this. Our number one city by user.Swyx [00:20:01]: Hmm.Ivan [00:20:02]: Is Singapore.Swyx [00:20:04]: Oh, wow. Amazing.Ivan [00:20:05]: Which is an interesting one, right? Not by revenue, just by just like by individual head count.Swyx [00:20:09]: Really?Ivan [00:20:09]: Just like an interesting thing.Swyx [00:20:10]: Singapore is, Singapore is weirdly high in the adoption charts of AI for the population. It's like an, seven, eight million population. And it's like keeps showing up.Ivan [00:20:20]: No, it's quite interesting. We were quite shocked, and I was like, “Oh, this is interesting.” And also one that's up there.Swyx [00:20:24]: There's a reason I'm doing AI using Singapore. it's because I'm from there.Ivan [00:20:27]: We're there. We're gonna, we're gonna be there as well. and it's interesting that Japan is in the top or like Tokyo's in the top, which is in all the tech cycles it has never been. It has never been, so it's quite interesting that they're.Swyx [00:20:39]: I think the Japanese just love AI. Yeah. It's that, and then it's Brazil. That's it.Ivan [00:20:44]: Brazil has always been in.Swyx [00:20:45]: I think.Ivan [00:20:46]: Even when I look, if you look at like GitHub's data and ask historically with CodeAnywhere, it was always like US, Western Europe, and then you'd have like India, Brazil, China, like that would be there. But like Singapore was not in, specifically Japan was never in sort of that top, that top.Swyx [00:21:01]: Yeah. Weird pockets.Ivan [00:21:01]: Weird. Yeah, so it's very global.Swyx [00:21:02]: Okay, so actually that, but that's helps you to distribute your load through, all time?Ivan [00:21:08]: The interesting thing is like we have those kind of loads, but if you look at the researcher loads, they're quite different. So what they are is like if you give them concurrency of 10,000 or 50,000 or 100,000 CPUs at ARMb, when they fire off a run, it's just 100%. And then it just runs, and then it stops. So it's very, the usage pattern is squares basically, right? And it's also not follow the sun, because people will fire it off at midnight before they go to sleep but then wake up and so it's very unpredictable, so you don't know where that is. So the shapes of the usage are quite different than we have had before. And also what's interesting is when it's sort of a follow the sun, even if you have a high growth company, you can sort of predict your usage patterns and have enough capacity for that, because it's sort of, it grows in a, in a way you can project. When you have companies doing sort of like evals and RL, they're super spiky. So they're gonna come in, it's like, “We're gonna use nothing, then can we have 100,000?” Right? And then go back down. And then 100,000, go back down. So it's very different, right? And.Swyx [00:22:09]: Do you want to lock them into commits so.Ivan [00:22:11]: Yeah, we do.Swyx [00:22:12]: Yeah, okay.Ivan [00:22:12]: We so we have to lock them into some sort of commits to have that capacity, because we have to have, basically we have to have the capacity for peak. Right? And so right now, Daytona's mean utilization is 15%, 1-5.Swyx [00:22:25]: Oh my God.Ivan [00:22:26]: So it's very low.Swyx [00:22:27]: Because it's very spiky.Ivan [00:22:27]: It's very spiky, but we get up to 90%. so we have these things. And so what we're, what we're looking at right now as a company is similar to Cloudflare where you can like geo move things around, but that works really well for basically the background agent where it's follow the sun. But this, it's not. Like it's a very different shape. Obviously with scale you figure these things out, but that's an interesting new problem that we have, as a compute provider in the agent space. And when we were doing the conference recently, and so we talked to like Nikita from Neon and.Swyx [00:22:57]: I should bring it up.Ivan [00:22:58]: Parag from Parallel and whatnot, everyone has the same problem. Whereas the usage is super spiky, and this is something that has not happened before, that you have these types of like it was always, it the amplitudes were not this high, right? So it's quite interesting use case and problem solve.Compute Conference and Spiky Agent InfrastructureSwyx [00:23:12]: Yeah, I don't know if we're gonna bring this up again, but let's just talk about the conference, you had like 1,000 something people at the Warriors game, at the Sorry, where is it? What's.Ivan [00:23:22]: Chase Center.Swyx [00:23:23]: Chase Center.Ivan [00:23:23]: Chase Center.Swyx [00:23:24]: I went. It was, it was very impressive. Obviously, you can, how to throw a conference, what did you learn? you put, you pulled together all these impressive names.Ivan [00:23:33]: What I.Swyx [00:23:34]: What were you looking for?Ivan [00:23:35]: My thesis behind the Compute Conference was let's bring together people that are building infrastructure for AI agents. Because when I think of what we're building, it is the agent is the primary user, what are the ergonomics and usage patterns of agents, and so we can do that. And what I found, this was a theory, it wasn't proven, is that we all have these problems, as I touched onto. And I was, as I was talking on stage, it was like we all have the same underlying infra problems, which is this spiky workloads, unpredictable workloads that we've never had before, in human, compute or human infrastructure. And it's, again, it's the same when I was talking to Parag or when I was talking.Swyx [00:24:20]: Lynn. Nikita.Ivan [00:24:21]: Lynn, Nikita. Lynn especially, I was talking to her the other day as well. Like the It is a very interesting type of problem to solve because I can touch on Cloudflare because there's a lot of like talk about that recently as to how they solve that, which is they have a bunch of geos, and basically, as users work in different places, and depending on your tier, they can move you around the geos. And so that how, that's how they get the higher utilization. But you can sort of predict these, and it's If it's something in You'll rarely get a spike that is 10 orders of magnitude. Like you'll get a like let's say one of your customers has some like an exponential curve. What is that to I'm using Cloudflare as an example. 10%, 20%, whatever it is. I don't, I don't have this data, I'm just assessing. It's surely not 10x, right? It's surely not something there. And so how do you go out and solve this problem? And we're all solving this in different ways. So we have.Swyx [00:25:11]: She also has the same thing.Ivan [00:25:12]: Yeah, I know specifically that like Neon had that issue as well. Like how are we solving these spiky loads and things like that ‘cause we talked about it. And so the interesting thing for me to actually internalize was, yes, everyone that's building for agents first is going through this, and we're all solving similar problems, which is quite.Swyx [00:25:28]: Let me let me double-click on this. Okay. So for example, Neon, I happen to know that they're very sort of S3 oriented, right? so they're just like fully bet on S3. And you get to benefit from S3's distribution and infrastructure. So I would imagine that Neon doesn't have to care, whereas Lynn maybe has to care a bit more because obviously she's doing GPU inference. And, for listeners, we did an episode with her, one and a half years ago. And you have to care. But like, right?Ivan [00:25:54]: Parag cares for sure, and Nikita.Swyx [00:25:58]: And Parag is C of, Parallel.Ivan [00:25:59]: Parallel, yeah.Swyx [00:26:00]: Former CTO of Twitter.Ivan [00:26:01]: Twitter, yeah.Swyx [00:26:02]: They are the search.Ivan [00:26:03]: Yeah, they're search, yeah.Swyx [00:26:03]: I You and I know but the listeners don't know.Ivan [00:26:08]: Yeah, we can put it down in the screen, and so ‘cause we, when we were talking.Swyx [00:26:11]: I'll put it up on the, on the screen.Ivan [00:26:12]: Yeah, right.Swyx [00:26:12]: People can look it up if they need.Ivan [00:26:14]: Look it up. And, yes, but they still have CPU and RAM, allocation that you have to have up and running. And so CPU and RAM, you have to allocate that and have that ready. And so there's basically two ways to do it. One is you either over-provision and you can handle the bursts, or two, you basically have, I don't know if this is a term, just-in-time compute, which is like as your load becomes, as your usage comes in, you can fire off requests for VMs or bare metals at other cloud providers and then get them up and running.Swyx [00:26:43]: This is if you go above 100%, right?Ivan [00:26:45]: Yeah, this is.Swyx [00:26:46]: Like your overflow.Ivan [00:26:46]: If your overflow, like spillage or whatever you do.Swyx [00:26:48]: You probably lose money on it, but it doesn't matter, right?Ivan [00:26:50]: It, not Well, you might, you might not That is a more cost-effective way to do it but it's a slower way to do it. Because basically what you have to do is you have to like queue your requests, spin up these just-in-time compute, get it all ready, provision it, and then get your workload there. And so if the time isn't important that much, that's fine, and you can do that. But if your customer, and especially for, let's say, the RL training runs, the reason why a lot of people come to us is because GPUs are more expensive than CPUs, right? So you want your GPU running at, what, 100% the entire time. And so when you're running runs on CPUs, when the when the CPU cycle is like down and spinning up the next one, you want that to be instantaneous so that your GPU doesn't go down, right? And if you then have to like go out and provision machines, you're essentially telling the GPU that it has to wait, and that's incurring our cost. So there's things that you have to try to solve for there.RL Workloads, Declarative Images, and Kubernetes ReplacementSwyx [00:27:43]: Yeah, let's talk about the different workload, right? You said that, what was it? A few months ago, you had zero RL workload and now it's 50%.Ivan [00:27:52]: It will be this one, 50%, yeah.Swyx [00:27:54]: Let's talk about how different it is, right? Like I imagine, for example, a lot less dynamic code generation of like arbitrary code. Like here, it's probably all the same code. You're just doing parallel runs or something, I don't know.Ivan [00:28:05]: Yeah. So you'll have multiple Depends on the like for each run, you'll have a snapshot. And they, for the most part, they actually do use our declarative image builder, which is like, “Oh, we, the agent wants these dependencies, these env vars.”Swyx [00:28:17]: These ones, yeah.Ivan [00:28:18]: Yeah, the declarative image builder, it.Swyx [00:28:20]: Which is a very modal like thing that they.Ivan [00:28:22]: Yeah. And so we build it on the fly and then we propagate that snapshot, and you can spin up as many sandboxes as you want against that snapshot. And then if you have to do changes, the model can, or like it could be also be automated. It's like, “Oh, now for the next run, we need to install these things or remove these things or whatever to get, a task done,” and then it goes off and runs that. So yes, that is something that it seems that they prefer. The number one reason I found, or should I say, let's take a step back. What we are competing against in that environment is essentially managed Kubernetes. So EKS, GKE, whatever. That is what the vast majority run on. And anyone that has tried Daytona versus GKE, EKS is like, “I'm never going back.” That has always been. There's a few reasons. One is the ergonomics. So if you have, if you're using Kubernetes to spin that up, you have to essentially manage the interface interactions with that. Daytona, although as a compute provider, it's more akin to a Twilio and Stripe from a consumption perspective than it is an AWS. Like you have an API, an SDK, it's quite like easy and seamless to get these things up and running, that's one. The other is the speed to which we spin up, which we mentioned earlier, which is much faster, and the scale to which we can go to. We haven't got into features, but an interesting feature is that it's very hard to OOM, or out of memory, our sandboxes, because we can dynamically on the fly.Swyx [00:29:48]: Resize.Ivan [00:29:49]: Resize, which is like impossible on almost any other thing. There are some technologies that enable you to do that, but it's like a very hard thing. And so we actually saw this when, the Terminal Revenge team is, brought us actually. So thank you, Alex and the team, that brought us into this whole space.Swyx [00:30:05]: It's just very rare that, a framework would just say, “Guys, just use Daytona.”Ivan [00:30:11]: Yeah, I think it says it somewhere. Yeah.Swyx [00:30:13]: Yeah. I was like, “What is this?”Ivan [00:30:15]: There's all, there's multiple there, but they also mention a few other places. and so Daytona specifically-We have, the, just jumping on themes here We, I don't know where it says Data Center.Swyx [00:30:27]: I, there.Ivan [00:30:27]: Doesn't matter.Swyx [00:30:28]: There's a very strong recommendation, which is, very unusual. Which is, it's.Ivan [00:30:33]: We do not pay them for this, just.Swyx [00:30:34]: I know, yeah. They just like you.Ivan [00:30:35]: Yeah, they like us. yeah, and also a thing, so, Data Center has multiple isolation sets underneath. The customer doesn't have to know what they are. But basically we have Docker, which is a container, that's hardened with Sysbox. So it's Docker's, isolation that is a security equivalent to a VM, but it's still a container. And that is the default, and they, especially in these training workloads, really like that as an interface to be able to use just a basic Docker container, and we enable Docker and Docker. Which for these RL runs, if you need to do a Docker compose or Kubernetes, you can spin up a K3S inside of these things, which unlocks a huge amount of workloads that you can do that you cannot do on other providers. So just on that part is much more interesting. And so we went that, through that. We showed them that we could do that, and they enjoyed that quite a bit. They being the general venture people.Swyx [00:31:28]: Those people, yeah.Ivan [00:31:29]: And Harbor people.Swyx [00:31:29]: Harbor people, do are they, are they a company yet?Ivan [00:31:33]: As far, I do not know.Customer Pull, Slack Connect, and the Computer Use BetSwyx [00:31:35]: Okay. All right. Yeah. It's like super obvious that like, there's a lot of excitement and success around these things, okay, so yeah, tell us more, right? Like, this is an exploding workload, Harbor adopted you, which helped speed things along. But what are you learning as this new workload comes online?Ivan [00:31:53]: There's a couple things that we learned, which we chat about in the beginning. We, and this has led our story, as we mentioned, we like talked to a lot of customers along the way, and we add more features and more tool sets as we talk to customers. And it's interesting that And I think it's that the ecosystem is so small and/or the models get smarter, where when we see one user come with a request, we know it goes on a roadmap if like three to five customers come with the same request in that week. It's like very bizarre. It happens so many times, which is.Swyx [00:32:27]: Because they're all friends.Ivan [00:32:28]: Sorry?Swyx [00:32:28]: They all, they're all friends. They're all in the same group chat.Ivan [00:32:30]: Yeah, probably, yeah. ‘Cause and they're like, “Oh, can you do this?” And I'm like, “Okay, this is interesting. We'll put it on a feature request.” And then the next one's like, “Oh, can you do this?” “Okay.” It's all the same, right? It's always the same. And so what we try to do, and I personally try to do, I try to be on as many call, quote-unquote “sales calls” I can. I'm in every Slack channel. We literally have about 1,000 Slack Connect channels, something like that. It's an interesting, there's so many interesting things you find out when you have all the Slack channels. You can also see where people, transfer between companies. You see leave Slack channel, enter Slack channel. It's an interesting thing. Also, just I digress, I feel that Slack Connect is literally LinkedIn what it should be. You have a list.Swyx [00:33:08]: LinkedIn charges you to, use your own connections, but Slack doesn't, right? Slack is like, do it for free. It's more lock-in. It's great.Ivan [00:33:15]: Yeah. It's amazing. Yeah. It's one of the reasons.Swyx [00:33:17]: You're gonna pay Slack for life.Ivan [00:33:18]: Exactly. You're there for life. So that's interesting. And so one of the things, the newer things we were talking about earlier is we made a big bet and put a lot of investment on computer use. that is not seen publicly the light of day. We haven't GA'd that yet, but we have.Swyx [00:33:32]: Is there a thing I can pull up?Ivan [00:33:33]: There is computer use there. It's right up a bit.Swyx [00:33:36]: Oh, yeah. Okay.Ivan [00:33:38]: What we have, what we talked about and what we've seen publicly is there's this theme now about, the human emulator where And Elon from XAI has talked about this publicly, and if you think about the models today, they're actually quite sophisticated and they can do a lot of work, but they still don't have access to all the tools. Like, I'm a strong believer that the most efficient way for an agent to work is essentially headless or through, terminal or whatnot. But if we, if we look at knowledge work in general, there's about 100 million knowledge workers in the US, about a billion in the world, and knowledge workers, and the salaries of them aggregate to 10 trillion in the US 50 trillion worldwide.Swyx [00:34:24]: Wow.Ivan [00:34:25]: Something like that. And if we look at, the five most important sectors of that, so like healthcare and government and financial services and whatnot, that's about 56% of that. So let's say it's about half of that. So in the US it's about 25 trillion, and most of them, most of that work is actually still locked into legacy apps inside of Windows, which is not going anywhere for a very long time. Like, people just won't invest in that. How much of it? our assumption is the following: if, in the RPA market, which is similar market, well, not the same 25% of, these white collar, workers', work is automated. If an agent is more sophisticated, can go through more runs, figure stuff out, let's say it's, 40%, right? And so if you take 40% of that, you get to essentially, $10 trillion a year.Swyx [00:35:17]: That's a TAM.Ivan [00:35:18]: That is a that is a TAM. So that's the TAM of the models, right? That's not our, essentially ours. But you get to that size, and to be able to do that, you essentially have to give agents these computers with the legacy. So computer use, either Mac or Windows or Linux. Linux we also obviously have and others have. But Windows specifically is something very new, and the only option right now is an EC2 with, Windows or on Azure. Both of them take anywhere from three to five minutes to spin up. We've created an actual sandbox, so it's a second instead of milliseconds, but you have, point in time snapshots, you have, forking, you have all the things that you have from a sandbox, but essentially enables you to hopefully unlock all this value. And so that's been our big push and bet, but we've sort of, kept our ear to the ground. What is sort of the next things in the market?RPA Returns: Why Agents Still Need ComputersSwyx [00:36:06]: Yeah, knowledge work, and building, and sort of RPA, the next wave of RPA. I got very excited about RPA kind of during COVID times. The UI path was IPO-ing. And it was, a very hot Isn't it, Eastern European?Ivan [00:36:20]: It is, Romanian.Swyx [00:36:21]: Romanian?Yeah, it might be the only Romanian, big unicorn okay, yeah. This I don't I don't, I don't have like a I think there's, I think there's a stage being set for the resurgence of RPA, ‘cause everyone understands that, yeah, no one wants to deal with these shitty apps and no one's gonna rewrite them. Like, you just have to do, a remote operation and programmatic operation of them.Ivan [00:36:45]: If you wanna unlock it, my own setup was basically the following. So I was doing a board deck recently, last month, whatever, and I'm like, “Okay, let's just, let's just do automated.” So, all our data's in, ClickHouse and PostHog and QuickBooks, where everyone else's is, and I'm basically, connected that all to, my Cloud code, like go off and go Cloud code whatever. Go off and, here's the integrations, go do that. It pulled out the first report, which was great. It connected to Brex and all these things, pulled it, which was great, and then I say, “Okay, now pull out this, and this,” and I kept getting, really well McKinsey-style design reports, but the data said partial data. all the missing data, partial data. Like, it can't access all the things, and I got so frustrated, and so I got, I got, my Mac Mini virtual sandbox with OpenClaw. I gave it its own account in our company, and then I went to all these services and created a read-only account, so literally like an intern in your company. And so I would say, “Now go and do this report,” and it would get the same, or like, “I can't via the MCP or the API or whatever. I can't get all the information.” I'm like, “Go log in.” And it will log into the website, then go in, export the data. It'll export the data and do the thing end to end. So even for things that have today APIs, not all of it is exposed, and I to get value, I get immense value right now, but it has to be a computer usage, unfortunately, and so I spend a bunch of tokens just on that, but I get the job done. And so if even a startup like ours, and using all the hottest tools, still needs a computer agent what hope does, Goldman have to have a headless, right?Swyx [00:38:22]: Yeah, what a - Why isn't Microsoft doing this?Ivan [00:38:27]: I'm pretty sure, Satya had a post yesterday.Swyx [00:38:29]: Oh, okay. I see.Ivan [00:38:29]: Which was like, “Every agent needs a computer.”Swyx [00:38:31]: I see, I see.Ivan [00:38:32]: So they have launched something recently.Swyx [00:38:34]: Yeah, they have Microsoft Power Automate, I'm sure, I'm sure, they're gonna have their version.macOS Sandboxes, Apple Constraints, and the Windows OpportunityIvan [00:38:39]: Version of that, yeah.Swyx [00:38:39]: You're gonna try to do yours, and it - I always know there's always demand for Mac, but I know it's, tricky to host, macOS sandboxes.Ivan [00:38:49]: We will have macOS sandboxes fairly soon. The problem with macOS, OS sandboxes is, I'm deep in this, I don't know how much interesting is.Swyx [00:38:55]: No, it's.Ivan [00:38:56]: MacOS has this problem.Swyx [00:38:57]: It's a licensing thing, right?Ivan [00:38:58]: Licensing thing. So one, you're allowed to run only two parallel VMs per machine, so that's one. Two, you can only license to a different user every 24 hours. So if you come in and theoretically, if I wanna charge you per second and I charge you one second, I have to have it idle for the rest of the day. I can't have anyone else doing that. So the pricing will be different in the sense that I will have to - we would have to charge for 24 hours, and that's not even, that's not even the most difficult thing. But the, thing above that is, from a security perspective, they enable you to do memory snapshot, pause, resume, but only on the same physical drive, physical machine. And so what you can do in, Windows world or Linux world is that I can move in the background, your snapshot from one to the other and manage load, right? Here, if you wanna do that, you essentially have to have your.Swyx [00:39:49]: Yeah, snapshots. Yeah.Ivan [00:39:50]: Your.Swyx [00:39:51]: It's like.Ivan [00:39:51]: Physical machine.Swyx [00:39:52]: You can't break it up.Ivan [00:39:53]: You can't, you can't move things around that, and all of that is, that part is, from a security standpoint, if it is written. Like, I understand the security aspect of that, but it disables you from doing these agentic, like really scalable agentic workloads.Swyx [00:40:08]: You need to do a vibe-coded, clean room implementation on macOS that you can then - That's like Clean OS or something. I don't know.Ivan [00:40:17]: So. We have.Swyx [00:40:18]: ‘cause like Linux was originally like a clean room rewrite of Unix.Ivan [00:40:21]: Okay. Yeah.Swyx [00:40:21]: Or something like that, right? Like same thing to macOS. Someone needs to do it.Ivan [00:40:25]: Someone will do that, and someone will have some long-running agents for a few days to figure this stuff out. But yeah. So definitely we - we're really close to offering something ‘cause people do want it, but the pricing will be different, and the feature set will be sort of stringent.Swyx [00:40:38]: Yeah, nobody's gonna use this. like, the labs, the labs will because they want to automate macOS.Ivan [00:40:42]: They have to do RL. They have to do RL again. But even if you The - So the point is with the RL part, if you, if you do RL on macOS, then the next iteration of the model comes out, it will be able to use these tools significantly. Then you actually need to run those, that somewhere. So you're gonna have to have that, later on. And from, if anyone at Apple is listening, I very much feel that they are shooting themselves in the foot of the scale of the revenue of compute or licensing they could get if they would just enable a concurrency model similar to what you can get on a Windows and a, and Linux.Swyx [00:41:17]: Yeah. Yeah. And I'm sure they've heard this before. They just don't care. Yeah, it's And maybe they will change their mind with the new CEO.Ivan [00:41:24]: Yeah. We'll see.Swyx [00:41:25]: We'll see.Ivan [00:41:25]: High hopes.Swyx [00:41:26]: High hopes.Ivan [00:41:26]: High hopes.Swyx [00:41:27]: Okay. But I, it's very clear the market opportunity is huge in Windows, and you can go for a long time on just Windows, but your customers are gonna want both. and I think, it is interesting to me that, this is the sort of God application of agents, right? Like, I don't It was - How big was OpenClaw for you guys? Like, was it, was there, a significant bump.OpenClaw, Agent Labs, and the B2B2C Sandbox MarketIvan [00:41:54]: Not for us because we.Swyx [00:41:54]: Because you already.Ivan [00:41:55]: We're kind of positioned differently. Whereas although it's completely PLG and we have individual developers that use it, most of the users that use Daytona are sort of a B2B2C. Sort of it's either B2B or B2B2C. So, in the researcher world, it's B2B, so you're selling to, labs and neo labs and things like that. But on the long-running agents, it's mostly, from a scale revenue perspective, it's mostly B2B2C, where you have a app layer agent that uses you at a big scale.Swyx [00:42:26]: Like a Manus. Yeah.Ivan [00:42:28]: Like a Manus Lovable type of thing.Swyx [00:42:31]: Yeah. I think that's the question of, well how, um-Uh, yeah, B2B to C is basically to me what I've been calling an agent lab, which is kind of like you're not in a model lab, but you're making a very good wrapper that is a platform that other people can sign up so they don't have to code those things. Yeah, it sound, it sounds like a much better market than the direct OpenClaw market.Ivan [00:42:56]: I've like - We I've done multiple things. So the CodeAnywhere's part of our career path R in the calendar, was very much an end user developer product. And so that is great. It You can get a lot of developer love, and I feel that we do as a company have a bunch of developer love. But it's a different type, where it's people building these things. Again, it's more akin to a Twilio because you don't really run - As a person, you wouldn't run Twilio. I don't know how many people remember. It was like ask your developer billboard and whatnot. And people really love Twilio, but they only used it inside of like, “Oh, I'm building this app or service for thing.” And so we're very much directly to that. And you also know that I used to work for a competitor for Twilio, so it's kind of ingrained, in my DNA.Swyx [00:43:35]: People don't know InfoBip is that big.Ivan [00:43:38]: Yeah, it's.Swyx [00:43:39]: Because.Ivan [00:43:40]: It's a billion euro.Swyx [00:43:40]: They're all American. They're like, “Whatever's in Europe doesn't matter to me.” But like it's the, it's the same size or bigger? Same size?Ivan [00:43:46]: It's about half the size.Swyx [00:43:47]: Half the size?Ivan [00:43:48]: Yeah, about half the size.Swyx [00:43:48]: It's like, yeah.Ivan [00:43:48]: Still huge. Multiple billions a year. Yes.Swyx [00:43:51]: That's crazy.Ivan [00:43:51]: Exactly, and so that - These are like really interesting and large revenue-generating, very sticky businesses. Whereas when you're selling to the - When your focus is the end developer, it is a very hard sell because they're very price sensitive, very price conscious, very around that. And there's very It's very hard to scale. Your cap is the number of people that are willing to spin up - First of all, wanna spin that up, and then spin up multiple of these. Whereas if you're in the enterprise one, like we know everyone's talking about like how many tokens they're spending, I'm spending. Like a lot of companies today are like, “If this is our company, spend as much as you can.” Like basically that is where we're going. And so if you think about that paradigm, where you're selling to companies that say, “Spend as much as you can to generate, productivity,” versus, “Oh, I'm a single person. I have this much budget, and I'm doing this thing because it's fun or it's helping me out or whatever.” Like it is a different, it's a different go-to-market, I think, strategy.MCP, CLIs, and Sandboxes as the Agent RuntimeSwyx [00:44:50]: Yeah, there's a lot of discussion. I'm just kind of going through like the mental list of things that are in your favor, which is, for example, MCP versus CLI. Like obviously you want CLI. It's been very good for you. I feel like it's maybe a drop in the bucket or maybe it's huge. I'm just checking whether it's like these are big trends.Ivan [00:45:10]: Those things you - work well in our favor, to your point just because every.Swyx [00:45:13]: They're kind of drop in the bucket, right?Ivan [00:45:15]: I think it's like sort of all the things come together. And so there's so many things that impact that. To your point, like OpenClaw wasn't huge for us, but like having the agent SDK, from Anthropic, so or Cloud Claude Code was very interesting. The reason why it was interesting is that a lot of, let's call them app I don't know what to call them, app layer agent companies, essentially they are like, “Oh, I can create this new app, this new agent. All I need, I just use Claude Code, and I throw it into a sandbox, and then I have my interface to the human to that.” And so that enabled so many more companies to actually offer this, and then they would pull on sandbox. So that was, that was interesting. And to your point, like MCP, versus the CLI, the MCP is an interface against an API, whereas the CLI is like you can actually go do things. Like this is it. The difference between integrations and actually running scripts or data or analysis against a thing. So being able to use a CLI very well enables the agent to do more things, and it's because that people will invoke a sandbox, they'll run it in the CLI, and but it'll do anal-analysis on that data and then give you an actual result versus just, pulling data from an API source.Swyx [00:46:29]: Yeah, it's a layer of indirection basically, it's the same thing as agentic search versus RAG, which where you're.Ivan [00:46:34]: Exactly, yeah.Swyx [00:46:34]: Just like you just win whenever people put more agents into their workflow. And so like it doesn't really matter, but I'm just kinda teasing out like what else have people heard about that like it's sort of, “Oh yeah, this is another sandbox use case. Oh yeah, that's another one.” Am I, am I missing any big ones?Ivan [00:46:51]: The thing, the thing that people, which is the computer use stuff, which I think is probably the most interesting one, is, and to your point, we've talked to so many people over the last year. It's like, “Oh, like why do you need a sandbox? Why do you need this? Why this?” And to your point, it's like, “Oh, I need sandbox for this. I need sandbox for that. I need sandbox-” It's like, “Oh, I need it for every single thing.” And so basically what I, what I - and it sounds like a broken record, it's like you use a laptop every single day, right? And you are n of one. It's just you. But now imagine how And by the way, the laptop, the computer PC market, the PC market is about equal to the cloud market in total. So it's about 150, 180 billion a year. Something like that. It's about roughly the three cloud hyperscalers is about equal to like Apple, HP, Lenovo, whatever, It's a little bit less, but it's sort of like that. And now imagine And that's just like, so how big is the addressable market? What, how many people are there in the world now? What's the last data?Swyx [00:47:45]: Let's call it eight billion.Ivan [00:47:46]: Eight billion. And so let's say you can have two computer, like you have one personal and one business, whatever. Like so it's double that, right? and so that's 16 billion, right? How many agents are gonna be running in two years, in 10 years, in 100 years? Like And for every single task, they will need one of these. And so how big is that? That market is essentially quote unquote “infinite”. You will get to the point, and Dylan Patel was at the conference talking about, from SemiAnalysis, that talks usually about GPUs, was also talking about how CPUs will now be a bottleneck because it will be the constraint. You won't be able to grow, or we won't be able to have enough of these because there won't be enough CPUs to basically do.Swyx [00:48:23]: Yeah. Well, I actually had a really good podcast with Doug Oliphant, who, which was his president at SemiAnalysis, where they've basically been like, yeah, it's been a GPU shortage first, but then it's cascaded down to memory and now to CPUs.Ivan [00:48:35]: CPU, yeah.Swyx [00:48:35]: It-What's next? So networking. So, networking actually has been in shortage for a while if you're looking at, just GPU networking. But, yeah, it's really crazy the amount of computer use that's going on, yeah, cool. I, other questions are, just the one very big part is the open sourceness which you didn't have to do, your competitors don't do, like it's not, a lot of people are worried about keeping their projects open source because some competitor can just slot fork it. I don't know if there's any reflections on just being an open source company.Open Source, Trust, and Enterprise ProcurementIvan [00:49:15]: Yeah. There's a bunch. So we the original product that we did was open source.Swyx [00:49:19]: Yeah. CodeAnywhere.Ivan [00:49:20]: So doing that was actually very good for us. There's basically a saying of, What's the saying? Like, companies that are, that are doing really well, measure themselves against, free cashflow, that are kinda okay, it's EBITDA, then, it's, it goes all the way down.Swyx [00:49:36]: The worst is like GitHub stars.Ivan [00:49:37]: GitHub stars. GitHub stars are the worst, yeah. So you go all the way down to GitHub stars. And so our original one was GitHub stars. That's what we talked about, we're at the point we're talking about revenue, so we're we've gone up the stack on that. And so we started.Swyx [00:49:47]: No, profit.Ivan [00:49:48]: Yeah. We haven't, we're, we'll get there. We'll get there. But basically at that point we did stars and GitHub and it was useful, and the original variation that we did, it we split the core into its own repo and it was Apache 2.0, so very, permissive. And then we basically would bundl

This show has been flagged as Clean by the host. Hi this is your host, Archer72 for Hacker Public Radio. In this episode I share some of my findings about a problem with the Newsboat naming of the HPR feeds, which was brought up in comments about my Newsboat show, HPR4424. hpr4424: How I use Newsboat for Podcasts: comment #6 : download-filename-format for HPR podcasts Ken already had some findings of his own about the ccdn.php extension in the feed. hpr4424: comment #10 : Summary of findings I thought that this might be able to be fixed on an invididual basis, and set out to ask Claude.ai a few questions. But first, some colaboration from Dave Morriss about a good renaming format. This was definitely more on Dave's side than mine, but came up with this. You can tell Dave's handywork from the short variable names, which stems from his extensive experience on Unix type machines in the University days. exif-rename-hpr-dave.sh #!/bin/bash URL="$(cat /tmp/hpr-url.txt)" echo "DEBUG URL: $URL" >> /tmp/hpr-debug.log AUDIO_URL="$(curl -s "$URL" | grep -Eo 'https?://[^"]*.(ogg|mp3)' | head -1)" echo "DEBUG AUDIO: $AUDIO_URL" >> /tmp/hpr-debug.log if [[ -z "$AUDIO_URL" ]]; then echo "ERROR: Could not find audio URL from: $URL" >> /tmp/hpr-debug.log exit 1 fi # Changed destination to HPR-queue DEST=~/podcasts/hub.hackerpublicradio.org/HPR-queue/ # Record files present before download BEFORE="$(ls "$DEST"*.{ogg,mp3} 2>/dev/null | sort)" wget -nc --content-disposition -P "$DEST" "$AUDIO_URL" cd "$DEST" # Record filename just downloaded (new file not in BEFORE) AFTER="$(ls "$DEST"*.{ogg,mp3} 2>/dev/null | sort)" DOWNLOADED="$(comm -13 /dev/null | sort)" RENAMED="$(comm -13 /tmp/hpr-url.txt && ~/bin/download-and-rename-hpr.sh"; open-in-browser ; set browser "your-normal-browser" A few Claude questions later… After asking to add a function to the macro in order to add the resulting downloaded file to the queue, the file name hpr1234.ogg was being added to the queue instead of the renamed file. Two things to fix: The renamed file isn't being found because ls -t runs before the rename has fully settled, or the glob isn't matching the new filename format (which includes spaces and semicolons) The existing queue entries show the correct format: "url" "path" downloaded — we need to match that, with downloaded status and the full renamed path including extension Exif rename script #!/bin/bash # ~/bin/download-and-rename-hpr.sh URL="$(cat /tmp/hpr-url.txt)" echo "DEBUG URL: $URL" >> /tmp/hpr-debug.log AUDIO_URL="$(curl -s "$URL" | grep -Eo 'https?://[^"]*.(ogg|mp3)' | head -1)" echo "DEBUG AUDIO: $AUDIO_URL" >> /tmp/hpr-debug.log if [[ -z "$AUDIO_URL" ]]; then echo "ERROR: Could not find audio URL from: $URL" >> /tmp/hpr-debug.log exit 1 fi DEST=~/podcasts/hub.hackerpublicradio.org/HPR-newsboat-test/ # Record files present before download BEFORE="$(ls "$DEST"*.{ogg,mp3} 2>/dev/null | sort)" wget -nc --content-disposition -P "$DEST" "$AUDIO_URL" cd "$DEST" # Record filename just downloaded (new file not in BEFORE) AFTER="$(ls "$DEST"*.{ogg,mp3} 2>/dev/null | sort)" DOWNLOADED="$(comm -13 /dev/null | sort)" RENAMED="$(comm -13 /tmp/hpr-url.txt && ~/bin/download-and-rename-hpr.sh"; open-in-browser ; set browser lynx Provide feedback on this episode.

Jim talks with Peter Wang—chief AI officer, cofounder and CEO of Anaconda, board member of the Center for Humane Technology, and founder of the Austin STEM Center—about Robert Pirsig's metaphysics of quality, how modernity encourages defection, and a secular conception of the sacred. They discuss: Peter's self-description as "the music in a violin that can kind of hear itself" The "Peter Wang-shaped hole in the universe" thought experiment Subject-object Cartesian dualism as a false alienation Minimum viable metaphysics & atheistic agnosticism Religion as an evolutionary emergent coherence mechanism for human collectives Figure and ground as a metaphysical lens—the anonymous soil that allows religion to sprout The Unix fortune "Man was invented by water to carry itself uphill" & Peter's teleology origin story Process metaphysics & presentism—"we're not going anywhere, we're becoming someone" Pirsig's metaphysics of quality & the four strata of static patterns of value The intellectual plane vs. the social plane & Ken Wilber's pre-trans fallacy Defection within collaborative groups as the dynamic all human social systems try to constrain "Death from a Distance"—throwing, beta coalitions & the emergence of a middle class of power Modernity's shrinking locus of care & the collapse of embedded social context The agglomeration of defectors & how fluid capital enables sociopathic hoarding Money-on-money return as today's dominant pruning rule Joint attention as a scarce collective resource & social media's perforation of shared intersubjective infrastructure Human agency & "micro-abdications" as the aggregate source of Moloch / Game A The augmented currency thought experiment—metering human thriving alongside financial returns Broken collective sense-making & the search for dynamic, adaptable values Peter's secular conception of the sacred—the "eternal golden braid of humanity" "Ofness"—holding both distinctness and belonging to the world ... and much more. Links: Episode Transcript JRS EP 278 Peter Wang on AI, Copyright, and the Future of Intelligence JRS Currents 092: Peter Wang on The Meaning Crisis and Consequentiality JRS EP 16 Anaconda CTO Peter Wang on The Distributed Internet "The Silent Sky and the Test Ahead," by Jim Rutt "A Minimum Viable Metaphysics," by Jim Rutt Zen and the Art of Motorcycle Maintenance, by Robert M. Pirsig Lila: An Inquiry into Morals, by Robert M. Pirsig Chaos: Making a New Science, by James Gleick Death from a Distance and the Birth of a Humane Universe, by Paul M. Bingham and Joanne Souza The Selfish Gene, by Richard Dawkins Center for Humane Technology Peter Wang is the Chief AI and Innovation Officer and Co-founder of Anaconda. Peter leads Anaconda's AI Incubator, which focuses on advancing core Python technologies and developing new frontiers in open-source AI and machine learning, especially in the areas of edge computing, data privacy, and decentralized computing.

Switching from Proxmox to Sylve, FreeBSD Quarterly report, FreeBSD's laptop program, Migrating ZFS, Haiku and OpenSSL news, and more... NOTES This episode of BSDNow is brought to you by Tarsnap and the BSDNow Patreon Headlines I Switched from Proxmox to Its FreeBSD Counterpart on My Home Server – Here is How it Went FreeBSD Quarterly Report The FreeBSD Foundation's Laptop Support Project News Roundup Migrating ZFS filesystems from one zpool to another – same host Haiku Isn't Just For X86 Anymore, Boots On ARM In QEMU OpneSSL 4.0 Other schedulers? Illumos? Tarsnap This weeks episode of BSDNow was sponsored by our friends at Tarsnap, the only secure online backup you can trust your data to. Even paranoids need backups. Feedback/Questions Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv Join us and other BSD Fans in our BSD Now Telegram channel

Neste episódio do podcast Professor Adolfo Neto, da Rede Emílias de Podcasts, Adolfo conversa com o professor Luiz Nacamura Junior sobre sua trajetória na UTFPR, desde a gestão de redes Unix nos anos 90 até se tornar o primeiro pró-reitor de pesquisa da instituição. Neste ano de 2026 Nacamura foi condecorado com o título de Mérito Universitário. Ele revela bastidores da criação do doutorado no CPGEI e as estratégias para aprovação de mestrados profissionais na UTFPR.O professor também discute sua metodologia de ensino para iniciantes em computação, defendendo que o aprendizado de estruturas de repetição e manipulação de memória deve vir antes de comandos como "printf". Por fim, destaca a importância do método científico em todas as áreas, inclusive em seu hobby de criação de cavalos, onde aplica o rigor acadêmico para obter melhores resultados em genética e veterinária.Notícia no site do PPGCA sobre o prêmio recebido por Nacamura https://www.utfpr.edu.br/cursos/coordenacoes/stricto-sensu/ppgca-ct/destaques/professor-luiz-nacamura-jr-recebe-o-titulo-de-merito-universitario-da-utfprPágina do DAINF: https://utfpr.curitiba.br/dainf/Página do PPGCA: https://www.utfpr.edu.br/cursos/coordenacoes/stricto-sensu/ppgca-ctPágina do CPGEI: https://www.utfpr.edu.br/cursos/coordenacoes/stricto-sensu/cpgei-ctNo YouTube em https://youtu.be/4v249rKcC80

This show has been flagged as Clean by the host. This series is dedicated to exploring little-known—and occasionally useful—trinkets lurking in the dusty corners of UNIX-like operating systems. I would imagine that most users of UNIX-like systems have heard of cron —certainly any system administrator should have. Briefly, cron is a way of running a job repeatedly based on the time and date; for example, a job could run every hour, at 5:00am every Tuesday, or the 3rd of every month. It is commonly used for administrative or maintenance tasks that should be done on a regular schedule, such as checking for software updates, rotating log files, or updating the database for the locate command. As well-known as cron is, there is a similar utility that very few seem to be aware of: at . This is the word "at", and has nothing to do with the at symbol "@". An at job is very much like a cron job, except that an at job only runs one time. A job is submitted by running at timespec 1 , where timespec is the time and date the job is to be run. The linked POSIX specification page describes acceptable formats for timespec ; some examples are " now ", " 14:00 ", " noon tomorrow ", " 14:00 + 3 months ", and " 14:00 January 19, 2038 ". The utility then waits on standard input for you to enter a set of commands to be run in the job. You end input by typing Control-D to mark the end of text. (As an alternative to typing in the job, you could instead use the "

When every networking engineer in Silicon Valley said TCP/IP was wrong for Ethernet, one IIT graduate from India ignored the consensus, built the internet's physical backbone, and still got passed over for CEO twice because of his ethnicity. Kanwal Rekhi, co-founder of TiE and the first Indian founder to list a venture-backed company on NASDAQ, joins host Akshay Datt to unpack the contrarian bets, the ruthless founder-evaluation framework, and his central provocation for the Indian startup ecosystem: India does not need more unicorns, it needs 10 million entrepreneurs. Born in what is now Pakistan in 1945, Kanwal Rekhi arrived in the US in 1967 as part of India's first IIT emigrant wave, survived three layoffs, and co-founded Excelan, the first company to commercialise Ethernet and TCP/IP, taking it public on NASDAQ in 1987 with $22M in revenue and 70-90% gross margins. He later served as EVP and CTO at Novell when it reached $12 billion in market cap as the world's second-largest software company, before co-founding TiE, today the world's largest entrepreneur network. In this conversation with host Akshay Datt, Rekhi reveals why he ignores TAM entirely when evaluating founders, how one pricing decision transformed Excelan from a near-failing startup into a near-90% gross margin business, and why the Indian startup ecosystem is building for the wrong 40% of the country. He also traces how his decision to open-source Unix at Novell seeded the ecosystem that scaled Infosys, TCS, and Wipro, and describes how Silicon Valley Quad backs first-time founders with $3M seed rounds and deep mentorship.

In this episode of the Crazy Wisdom Podcast, host Stewart Alsop sits down with Tyler Cloutier, founder of Clockwork Labs and creator of SpaceTimeDB. They explore how SpaceTimeDB functions as more than just a database—it's essentially a distributed operating system that merges server logic with data storage, enabling real-time applications and time-travel capabilities. The conversation ranges from the technical architecture of databases and operating systems to the philosophy of distributed systems, touching on everything from Unix and Linux to how SpaceTimeDB could revolutionize AI-generated software deployment. Tyler explains how their system reduces the complexity of building real-time applications, makes deployment simpler for both humans and AI agents, and why games like their MMORPG BitCraft Online drove them to create this new infrastructure. They also discuss the future of the internet, the role of bots in gaming, and how SpaceTimeDB fits into the broader landscape of cloud computing alongside tools like Cloudflare, Vercel, and Docker. For more information, visit spacetimedb.com or check out Clockwork Labs on GitHub and Twitter.Timestamps00:00 Stewart introduces Tyler Cloutier, founder of Clockwork Labs, discussing the origin of SpaceTimeDB's name inspired by Einstein's theory and its time travel capabilities that store all operations indefinitely05:00 Tyler explains SpaceTimeDB as more of an operating system than a database, using tables instead of file systems while running code in a sandboxed environment with full atomic properties10:00 Discussion of how SpaceTimeDB replaces both Node.js and Postgres by merging web server and database functionality, eliminating separate deployment concerns15:00 Tyler explains JavaScript execution through Chrome's V8 engine and JIT compiling, leading to Node.js creation for server-side JavaScript development20:00 Explanation of stateless web servers versus stateful game servers, and why games require in-memory state management for real-time performance25:00 Tyler introduces reducers and real-time subscriptions, questioning why more applications aren't real-time when state changes should update immediately30:00 Discussion of Facebook as essentially a text-based MMO, comparing social media architecture to game server requirements and the need for unified systems35:00 Tyler explains ACID properties in databases: atomic, consistent, isolated, and durable, using game item trading examples40:00 Comparing SpaceTimeDB to smart contract systems without cryptocurrency or global consensus, positioning it as a smart database with centralized trust45:00 Tyler reveals SpaceTimeDB uses 43% fewer tokens than Postgres for AI-generated applications, making it valuable for vibe coding platforms50:00 Conversation shifts to bots in games and proof-of-human concepts, with Tyler proposing biometric systems and discussing potential in-person gaming applications55:00 Closing discussion about tracking AI-driven traffic through UTM parameters and finding SpaceTimeDB at spacetimedb.comKey Insights1. SpaceTimeDB is fundamentally a database that runs application code directly inside it, combining what traditionally required separate systems like Postgres and Node.js. Users compile their application logic into WebAssembly or JavaScript and upload it to run within the database itself. This architecture provides high performance because the entire server backend operates inside the database environment. The system also features time travel capabilities, storing every operation and change to data persistently and indefinitely, allowing users to set application state back to any earlier point in time. This makes SpaceTimeDB more accurately described as an operating system rather than just a database, where the abstraction is that everything is a table rather than a file.2. The inspiration for SpaceTimeDB came from building BitCraft Online, an MMORPG where all players exist in a single persistent world and rebuild civilization together. Traditional MMO backends required complex custom solutions to handle real-time state, with game servers storing state in memory and periodically writing to databases. This complexity existed because games cannot afford the latency of constantly delegating to distant databases like traditional web applications can. SpaceTimeDB solved this by making the database fast enough to handle real-time requirements directly, eliminating the need for separate game servers. This same performance advantage that benefits games also applies to web applications, which is why SpaceTimeDB evolved from a game-specific tool to a general-purpose platform.3. SpaceTimeDB functions as a distributed operating system where each database acts like a process in an actor model system, similar to Erlang or Scala Akka. Databases can send messages to other databases and be spawned across a cluster for horizontal scaling. This represents an overlay operating system running on top of Linux rather than competing with it, providing a distributed abstraction across many machines while Linux handles device drivers and hardware support. The vision is for the cloud to function as a single enormous computer running one operating system, where developers simply publish their programs without managing separate services, deployment, routing, networking, or persistence infrastructure.4. The real-time capabilities of SpaceTimeDB address a fundamental limitation in how most web applications work today. Traditional web servers are stateless, delegating all state to databases and accepting network round-trip latency for each request, which is why users often must refresh pages to see updates. SpaceTimeDB allows queries to be subscribed to, maintaining open connections that stream changes whenever query results update. This makes applications like Discord, Facebook, or banking systems naturally real-time without requiring page refreshes. The historical accident that more things are not real-time represents a problem SpaceTimeDB solves by unifying the web world with the game world's real-time requirements.5. SpaceTimeDB implements ACID properties—Atomic, Consistent, Isolated, and Durable—ensuring database operations are reliable and safe. Atomic means operations either fully happen or not at all, preventing issues like item duplication in games when trading between players. Consistent means declared invariants like unique usernames are always enforced. Isolated means concurrent operations do not interfere with each other. Durable means changes persist even if computers restart, with varying levels from in-memory on one machine to disk storage across multiple geographic locations. These properties are managed through reducers, functions inspired by React Redux that fold changes into application state incrementally.6. For AI and large language models, SpaceTimeDB offers significant advantages in building and deploying applications. Testing showed that creating applications with SpaceTimeDB uses 43% fewer tokens compared to Postgres implementations, costs less, has fewer bugs, and is easier to extend. This matters because the primary cost for vibe coding platforms is tokens. As more software gets written in the next twelve months than ever before, there is insufficient focus on infrastructure required to run all this AI-generated software. SpaceTimeDB positions itself as ideal for LLMs to target because of its simplified deployment model where developers just publish code and the system handles everything behind the scenes.7. SpaceTimeDB can be understood as a smart contract system without cryptocurrency or global decentralized consensus. Like blockchain smart contracts, it executes code with atomic, consistent, isolated, and durable properties, but avoids the expense and slowness of requiring all computers worldwide to agree on everything. Instead, it offers centralized trust where users trust Clockwork Labs not to modify deployed contracts, rather than the trustless but extremely costly blockchain approach. This makes it functionally similar to Cloudflare's durable objects but with full relational database capabilities. The system exists before the networking layer where Cloudflare operates, handling deployment, server, and database functions while Cloudflare could provide DDoS protection in front of it.

This interview was recorded for the GOTO Book Club.http://gotopia.tech/bookclubIan F. Darwin - Java, Android & Unix Developer, Trainer, Mentor & Author of "Java Cookbook"Jeanne Boyarsky - Oracle Java Champion, Co-Author of "Real-World Java" & "OCP 21 Java Cert Book"Check out more here:https://gotopia.tech/episodes/438RESOURCESIanhttps://fosstodon.org/@IanDarwinhttps://x.com/Ian_Darwinhttps://github.com/IanDarwinhttps://www.linkedin.com/in/idarwinhttps://www.darwinsys.comJeannehttps://bsky.app/profile/jeanneboyarsky.bsky.socialhttps://mastodon.social/@jeanneboyarskyhttps://x.com/jeanneboyarskyhttps://github.com/boyarskyhttps://www.linkedin.com/in/jeanne-boyarskyhttps://sites.google.com/view/jeanneboyarskyhttps://www.selikoff.netLinkshttps://javacookbook.orghttps://dev.java/community/jcsDESCRIPTIONIn this GOTO Book Club, Java Champion Jeanne Boyarsky interviews Ian F. Darwin — author of one of Java's most enduring reference books, Java Cookbook, now in its fifth edition covering up to Java 25. The conversation traces Ian's extraordinary journey: from writing Java's first commercial training course outside of Sun Microsystems, to meeting Tim O'Reilly at a Unix conference and handing him a chapter on lint, to delivering a class in Houston where the entire room had just been laid off and were using the course as their golden handshake into a new career. Ian talks about the philosophy behind the book — culling a peak 900-page beast down to a tight 600 pages, anchoring tool choices on proven, battle-tested picks like JUnit, Mockito, and logging — and shares his three favourite chapters: Regular Expressions, Object-Oriented Techniques, and Reflection.The conversation gets sharply honest about AI and the future of the industry. Ian — who uses Claude as his coding assistant and does vibe code — warns that his greatest fear isn't AI taking over the world, but something subtler and more dangerous: companies stopping junior hires because AI can do the work, leaving no one to grow into the deep expertise that retires with the current generation. The parallel risk for books is equally candid: AI was trained on older editions, so the fifth edition is genuinely new and un-scraped territory.His advice for anyone who has learned the basics of Java?Don't ask an AI — buy the cookbook, save yourself years of trial and error, and for goodness' sake, read the code before you deploy it. "It's like building an airplane and putting passengers on it without flight testing."RECOMMENDED BOOKSIan F. Darwin • Java Cookbook 5th ed. • https://amzn.to/3QH0NZyIan F. Darwin • Java Cookbook 1st ed. • https://amzn.to/4sUpPlLIan F. Darwin • Checking C Programs with Lint • https://amzn.to/3Q2C69YVictor Grazi & Jeanne Boyarsky • Real-World Java • https://amzn.to/4oCEeBRJeanne Boyarsky & Scott Selikoff • OCP 21 Java Cert Book • https://amzn.to/4lF8OICBlueskyInstagramLinkedInFacebookCHANNEL MEMBERSHIP BONUSJoin this channel to get early access to videos & other perks:https://www.youtube.com/channel/UCs_tLP3AiwYKwdUHpltJPuA/joinLooking for a unique learning experience?Attend the next GOTO conference near you! Get your ticket: gotopia.techSUBSCRIBE TO OUR YOUTUBE CHANNEL - new videos posted daily!

Cybersecurity Looks Like Proof of Work Now, Compensating for RAM Constraints with L2ARC on ZFS, GhostBSD 26.1, and more... NOTES This episode of BSDNow is brought to you by Tarsnap and the BSDNow Patreon Headlines Cybersecurity Looks Like Proof of Work Now Compensating for RAM Constraints with L2ARC on ZFS GhostBSD 26.1 News Roundup I connected a phone to my FreeBSD server My Journey to the BSDs The unseen hero of OpenBSD Beastie Bits BSD Can Schedule up OpenBSD Campaign 2025 OpenBSD Campaign 2026 Tarsnap This weeks episode of BSDNow was sponsored by our friends at Tarsnap, the only secure online backup you can trust your data to. Even paranoids need backups. Feedback/Questions Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv Join us and other BSD Fans in our BSD Now Telegram channel

Trimestre récord, adiós parcial de Tim Cook y un Mac que se prepara para los agentes de IA Apple acaba de firmar un trimestre récord de 111.200 millones de dólares, con casi 30.000 millones de beneficio neto, y en el garaje desmenuzamos qué hay detrás del titular: un iPhone que sigue siendo una máquina de hacer caja, unos servicios al alza y un Mac en su mejor momento.Joaquín, Guaica y Juankyrepasan el rumor de un iPhone sin imanes MagSafe que obligaría a comprar funda aparte, la transición silenciosa de Tim Cook, el aumento histórico del gasto en I+D enfocado a inteligencia artificial y el pulso de Apple con el regulador indio en un mercado clave para su futuro. Hablamos también de la subida del Mac mini de entrada a 512 GB, de cómo Perplexity sitúa al Mac como plataforma natural para agentes de IA locales gracias a su base Unix, y de herramientas como LM Studio para correr modelos en casa. Cierre con una anécdota épica restaurando un Intel i7 de 2014 con Time Machine. Versión breve: Apple firma un trimestre récord y dispara su gasto en IA mientras Tim Cook inicia una retirada parcial. Hablamos del nuevo Mac mini, del pulso con India, del rumor del iPhone sin imanes MagSafe y del Mac como plataforma para agentes de IA.Únete a TELEGRAMConviértete en un supporter de este podcast: https://www.spreaker.com/podcast/el-garaje-de-cupertino--3153796/support.

Breaking up Big Tech, Porting MacOS to the Nintendo Wii, OpenBSD on the Pomera DM250, Postgres is your friend and more... NOTES This episode of BSDNow is brought to you by Tarsnap and the BSDNow Patreon Headlines Breaking up with Big Tech Porting MacOS to the Nintendo Wii News Roundup Installing OpenBSD on the Pomera DM250 Postgres is Your Friend. ORM is Not Java Sun SPOTs I like to use Soviet control panels as a starting point Beastie Bits OSHintosh - an open source 68000 Macintosh Time to update 2.11BSD: biggest patch ever landed before 35th anniversary A quick and easy Guide to Tmux Tarsnap This weeks episode of BSDNow was sponsored by our friends at Tarsnap, the only secure online backup you can trust your data to. Even paranoids need backups. Feedback/Questions Producer Note, If you have emailed in and you havent heard back and we havent covered your message, email again. Our email is flooded with spam and I might have missed your message. Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv Join us and other BSD Fans in our BSD Now Telegram channel

While working with a customer recently, I heard this sentence: a tool is better than a script. The reference was that this customer preferred a known, tested, approved tool for most of their staff rather than a script built, lightly tested, and perhaps changeable by anyone in their organization. I was surprised, because in many ways, I've depended way more on scripts, more often, than "tools" in my career. Often I struggled to find tools that actually worked in the way I wanted them to and built them myself with Unix shell utilities, VB Script, PowerShell, or some combination of those or other technologies. Read the rest of A Tool is Better than a Script

This show has been flagged as Clean by the host. This series is dedicated to exploring little-known—and occasionally useful—trinkets lurking in the dusty corners of UNIX-like operating systems. Let me start by admitting that I've never actually seen the film referenced in the episode title, but I couldn't resist using it anyway. If you've used the UNIX command line to any extent, chances are good that you are familiar with the kill command. A common use is to terminate a misbehaving program. But there is more behind how kill works, including a curio you might not know about. The kill utility works by sending a "signal" to the targeted process. This signal is selected from a pre-defined list, and triggers the process to interrupt its normal flow and handle the signal before potentially returning back to its work. This "signal handler" can do whatever activities are written in its code, but typically it will take actions connected to the purpose of the specific signal received. One option is for the process not to have a signal handler at all; in that case, there is a default action that the operating system will take on behalf of the process, depending on what the signal is. The possible default actions are to terminate the process, take some implementation-defined action (usually writing a core file to disk) and then terminate the process, stop (pause) execution of the process, continue execution of a stopped process, or ignore the signal. By default, kill sends the TERM signal to the process, an indicator that it should terminate. Each signal has a name and a number assigned to it; SIGTERM is the name of the "terminate" signal. You can use the -s option with the name to choose which signal to send. The 'kill' command is specified to take these names without the SIG prefix, though some implementations will accept them either way. Also, kill is supposed to be case-insensitive when it comes to these names, but the convention is to write them in all upper case. The assigned numbers for signals can vary depending on the operating system, and on Linux, depending on what processor architecture you're on. However, there is a short list of signals 1 that have a stable number assigned to them. Despite this, I recommend using the signal name in your scripts to make them clearer and to ensure maximum portability to different systems. Well-behaved programs will have a signal handler that responds to the TERM signal by stopping what they are doing, cleaning up any open resources like temporary files, and promptly exiting. However, not every program behaves well, so sometimes it becomes necessary to send them the KILL signal. This one is special and cannot be handled or ignored by the program 2 ; the operating system will immediately terminate the program, possibly leaving a mess behind. Two other signals that can come in handy sometimes are STOP and CONT. As you might expect, STOP forces a process to pause in the middle of whatever it was doing. Its counterpart, CONT (short for "continue"), causes it to resume execution. This can be useful if a program consumes CPU time when not actually doing anything worthwhile—sending it the STOP signal will end that, and when you're ready to use it again, CONT will cause it to pick up right where it left off. Like the KILL signal, STOP cannot be handled or ignored by the program. I have used this to pause the game FreeCiv when I wanted to break away to do something else, but didn't want to have to deal with exiting my current game and having to reload it later. Take note, though, that the program might get confused if it expects the system clock not to suddenly jump forward, as that is exactly how the situation will appear to it. Network connections or other resources the process is using that change while it is stopped are other potential trouble spots. Also be aware that a stopped graphical program will not update its window, so I find it best to minimize the window before stopping it and then continuing the process before trying to raise the window again. Programs are not necessarily required to interpret signals in the way they are described. For example, the HUP signal was originally intended to be sent when a modem or serial connection hang-up occurred. Today, some daemons use it for other purposes and take a specific action in response. For example, the Apache web server will restart 3 , and NetworkManager will reload its configuration 4 . These uses of signals are usually described in the daemon's manual page, often in a separate section dedicated to signals. While all this background might be interesting (or maybe not), it's pretty commonly known, so isn't really a curio. Our UNIX Curio for today is the "0" signal. This is actually not a signal at all; instead, it tells the kill utility to just check for the existence of a process. If the process exists, kill will exit with a status of 0. If it doesn't exist, the exit status will be greater than 0. This provides a handy way to check whether a particular process is still around. A shell command can use this exit status with its control structures like if to take a particular action depending on whether a particular process exists. Somewhat oddly, "0" is both the number and the name of this pseudo-signal. Why would you want to do this? I have used it for a script to analyze log files that runs daily on a web server. Depending on how much traffic the site is getting, the log files can grow to the point where it takes longer than a day for the script to get through them. If a second instance of the script is started while one is still running, it will slow down both and if more keep being added, eventually the machine will run out of memory. My solution was to create a .pid file containing the process ID number of the running script. You might see examples of these if you look in /run or /var/run on your system. The script creates a file named something like "myscript.pid" in this directory containing its own process ID, which can be accessed in the shell with the variable $$ . When my script starts, it checks to see whether this file exists. If so, it uses kill -s 0 $(cat /run/myscript.pid) to see if the previous process still exists. If the process is no longer around, that's a sign that it exited abnormally before it had the chance to delete the .pid file, so the script removes the abandoned .pid file, replaces it with a new one containing the current process ID, and continues with its work. If the previous process is still around, my script exits with a message to that effect. This way, I can be sure that only one instance of the script will ever be running at one time. Be aware that the kill utility might also return a non-zero exit status if the user running it does not have privileges to send a signal to the process with the specified ID. This is not a concern if you are running a script as the root user, but could be if you are not. This can occur even if you aren't actually sending a signal, just using the "0" pseudo-signal to check if a process exists. There is a weakness in this method. UNIX-like systems generally have a limit to the quantity of process ID numbers that can be issued, so they are reused over time. (However, there will never be two processes with the same ID number running at the same time.) Typically, the first process that is run on start-up will be given the ID number 1, and each subsequent process will get the next higher number. Once the maximum is reached, the system starts again at the beginning with the lowest number not in use. It is possible for the script to crash and leave behind the .pid file, then the same process ID could be recycled and actively used for another program, causing a new instance of the script to give up. The chances of this are small enough that for my purposes, it's not worth worrying about. But you should be aware that it could happen. I should also note that it's not strictly necessary to use kill for the purpose I described. The ps utility can also be given a process ID with the -p option; if the process exists, the exit status will be 0, otherwise it will be greater than 0. In this case, you could also use the output to check that the name of the command matches what you expect, helping avoid the problem of a recycled process ID. In addition, ps doesn't concern itself with permissions for sending signals, so it will report on the existence of a process no matter what user you are running it as. From an efficiency standpoint, kill generally requires fewer resources to run (in fact, it is built in to some shells), but functionally ps can also do the job. So keep in mind that kill is capable of doing more than just killing off programs—maybe you can put it to one of these uses for your needs. References: Kill specification https://pubs.opengroup.org/onlinepubs/009695399/utilities/kill.html signal.h specification https://pubs.opengroup.org/onlinepubs/009695399/basedefs/signal.h.html Stopping and Restarting Apache HTTP Server https://httpd.apache.org/docs/2.4/stopping.html#hup NetworkManager: Signals https://networkmanager.dev/docs/api/latest/NetworkManager.html#id-1.2.2.9 Appendix 1 - example script: #!/bin/sh # Use your own unique name here - be sure you can write to this location pidfile="/var/run/myscript.pid" # Exit if previous run hasn't completed yet if [ -f "$pidfile" ] ; then oldpid=$(cat "$pidfile") if kill -s 0 $oldpid ; then echo "${0}: Not running script, older process $oldpid still active" exit 1 else echo "${0}: Removing old pidfile from nonexistent process $oldpid" rm -f "$pidfile" fi fi # Create pidfile echo $$ > "$pidfile" ## Insert commands to do the actual work of the script here # Remove pidfile rm -f "$pidfile" Appendix 2 - another version of the script using ps instead of kill , checking that an existing process ID is actually the same command, and with extra validation of the contents of the pidfile; perhaps better for use by a non-root user: #!/bin/sh # Use your own unique name here - be sure you can write to this location pidfile="$HOME/myscript.pid" # Exit if previous run hasn't completed yet if [ -f "$pidfile" ] ; then oldpid=$(( 1 * $(cat "$pidfile") )) if [ -n "$oldpid" ] && [ "$oldpid" -gt 1 ] ; then : else echo "${0}: Not running script, $pidfile contents invalid" exit 1 fi # Test if old process ID exists if oldcmd="$( ps -o comm= -p $oldpid )" && # Also test if command name of old process is same as current script [ "$oldcmd" = "${0##*/}" ] ; then echo "${0}: Not running script, older process $oldpid still active" exit 1 else echo "${0}: Removing old pidfile from nonexistent process $oldpid" rm -f "$pidfile" fi fi # Create pidfile echo $$ > "$pidfile" ## Insert commands to do the actual work of the script here # Remove pidfile rm -f "$pidfile" Provide feedback on this episode.

Proxmox to FreeBSD, Hidden values of CPU-Intensive Compression, Cells for NetBSD, OpenBSD 7.8 on RPIs, and more... NOTES This episode of BSDNow is brought to you by Tarsnap and the BSDNow Patreon Headlines From Proxmox to FreeBSD and Sylve in Our Office Lab The Hidden Value of CPU-Intensive Compression on Modern Hardware News Roundup Cells for NetBSD – Kernel Enforced Jail Like Isolation with User Friendly Operations OpenBSD 7.8 on Raspberry Pi Zero 2W OpenSSH 10.3/10.3p1 released I'm just the Barista Tarsnap This weeks episode of BSDNow was sponsored by our friends at Tarsnap, the only secure online backup you can trust your data to. Even paranoids need backups. Feedback/Questions Tim - Are OCI Images useful for Freebsd.md Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv Join us and other BSD Fans in our BSD Now Telegram channel

professorjrod@gmail.comIn this episode of Technology Tap: CompTIA Study Guide, we dive into essential Linux troubleshooting techniques vital for IT skills development and tech exam prep. Understanding how to diagnose system issues is crucial when preparing for your CompTIA exams and enhancing your practical IT abilities. We explore how to view the system as a dynamic set of processes, using tools like ps and top to monitor CPU and memory usage in real-time. Learn why process IDs (PIDs) matter and how to effectively manage problematic processes with commands like kill and kill -9. We also cover managing system services properly with systemctl to check statuses, start stopped services, and halt errant processes. Whether you're studying alone or in a study group, these insights serve as a valuable part of your CompTIA study guide, equipping you with hands-on knowledge for technology education and IT certification success.Then we zoom out to the tools that keep Linux stable in the real world: package managers like apt and dnf/yum for verified software installs, plus network troubleshooting with ping for connectivity and dig for DNS resolution. We also talk about cron automation, because scheduled tasks can be your best friend or the hidden cause of recurring issues.To round it out, we compare Linux's exposed control with macOS design choices: Finder, Dock, and Spotlight for speed, while still keeping a Unix foundation underneath. We hit key macOS security and recovery features like FileVault, Keychain, and Time Machine, and we close with CompTIA-style practice questions to lock in the concepts. Subscribe, share this with a friend studying A+, and leave a review with the command you want us to cover next.Support the showArt By Sarah/DesmondMusic by Joakim KarudLittle chacha ProductionsJuan Rodriguez can be reached atTikTok @ProfessorJrodProfessorJRod@gmail.com@Prof_JRodInstagram ProfessorJRod

La filosofía UNIX propone usar herramientas simples y especializadas que, combinadas, crean sistemas más potentes y eficaces. Enlace al post: https://www.aprendiendogtd.com/podcast-productividad/la-filosofia-unix-aplicada-a-todos-los-aspectos-de-la-vida Enlaces de interés: Ben Vallack - I Applied the Unix Philosophy to My WHOLE LIFE https://www.youtube.com/watch?v=h0s2sUu5zW0 Wikipedia - Filosofía de Unix https://es.wikipedia.org/wiki/Filosof%C3%ADa_de_Unix 6 Apps para tu sistema de productividad https://www.aprendiendogtd.com/podcast-productividad/027-6-apps-para-tu-sistema-de-productividad/ https://www.aprendiendogtd.com https://www.aprendiendogtd.com/productividad-solidaria/ Grupo Telegram: https://telegram.me/AprendiendoGTD Canal de YouTube: https://www.aprendiendogtd.com/youtube Email: info@aprendiendogtd.com Feed: https://www.ivoox.com/aprendiendo-gtd-podcast_fg_f1286811_filtro_1.xml iTunes: https://itunes.apple.com/es/podcast/aprendiendo-gtd-podcast/id1112186543?mt=2 Manolo @manolo_molero Luis @lsblasco Sergio @spantigaramos Pablo @paredes94 David @dasanru Podcast @aprendiendoGTD Sintonía: "All the Fixings" de Zachariah Hickman

Wayland setting back Linux, Dr Callahan's semi retirement, holding onto your hardware, PF queues breaking the 4gbps barrier, and mroe... NOTES This episode of BSDNow is brought to you by Tarsnap and the BSDNow Patreon Headlines Wayland set the Linux Desktop back by 10 years Semi-retirement, or, really, changing my relationship with the BSDs [Hold on to Your Hardware](https://マリウス.com/hold-on-to-your-hardware/) News Roundup PF queues break the 4 Gbps barrier Nobody said there was math on this exam! The web is bearable with RSS The Pipe Tarsnap This weeks episode of BSDNow was sponsored by our friends at Tarsnap, the only secure online backup you can trust your data to. Even paranoids need backups. Feedback/Questions Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv Join us and other BSD Fans in our BSD Now Telegram channel

This show has been flagged as Clean by the host. This series is dedicated to exploring little-known—and occasionally useful—trinkets lurking in the dusty corners of UNIX-like operating systems. When you think about creating and managing archives on a UNIX system, tar is probably the utility that comes to mind. But this was not the first archiving program; ar was in First Edition UNIX 1 and cpio also pre-dates it, sort of 2 . According to the NetBSD manual page, cpio was developed within AT&T before tar , but did not get widely released until System III UNIX after tar was already well known from the earlier release of Seventh Edition UNIX (a.k.a. Version 7). You might think that ar and cpio are old and irrelevant these days, but these formats do live on. Each Debian package file 3 is an ar archive which in turn contains two tar files. On Red Hat, Fedora, SUSE, and some other distributions, each .rpm package file 4 contains a cpio payload. So these may very well still be in use on your modern Linux system. But let's get back to the subject of what you might want to use to create archives today. The tar utility has persisted in its popularity over the decades, and you most probably have a version installed on your UNIX-like systems. One of the problems with tar , however, is that it has not kept a consistent file format. Also, different implementations have used differing syntax at times. There are excellent reasons for the file format changing 5 . The names people give files have gotten longer over time, and the original Seventh Edition tar format could only handle a total pathname length of 100 bytes for each archive member. In addition, filenames were in ASCII format, and modern filesystems now accommodate richer encodings with characters that aren't in ASCII. The size of each archive member was limited to 8 gigabytes—unthinkably large back then, but not so big these days. User and group ownership could only be specified by numeric ID, which can vary from one system to another. Many other types of files and information simply couldn't be stored: block and character device nodes, FIFOs, sockets, extended attributes, access control lists, and SELinux contexts. As a result, the tar format had to evolve over the years. One important version was the ustar format, created for the 1988 POSIX standard. The POSIX committee wanted to try standardizing both the file format and syntax for the tar command. While the ustar format addressed some shortcomings, progress marched on. Filesystems started allowing filenames in different character sets and more types of information to be attached to files, so for the 2001 revision of POSIX they gave up on standardizing the tar utility and came up with a new format and utility, which is our actual UNIX Curio for this episode: pax 6 . Since the pax program didn't have historical baggage, they could specify its options, behavior, and file format and be sure everyone's implementation would match. Developers of different tar implementations had been reluctant to change away from their historical option syntax to the standard. The pax utility was also an attempt to avoid taking sides between those who advocated for tar and fans of cpio . The pax file format was an extension of ustar with the ability to add arbitrary new attributes tied to each archive member as UTF-8 Unicode. Some of these attribute names were standardized, but implementers could also define their own, making the format more future-proof. Older versions of tar that could handle the ustar format should still be able to process pax archives, but might not know what to do with the extra attributes. GNU tar developed its current archive format 7 alongside the standardization of the ustar format. The GNU format was based on an early draft which later underwent incompatible changes, so the two unfortunately are not interchangable. Unlike ustar , the GNU format has no limits on the size of files or the length of their names. In addition to its own format, GNU tar is able to detect and correctly process both ustar and pax archives. In situations where its native format can't store necessary information about a file (such as POSIX access control lists or extended attributes), GNU tar will automatically output the pax format instead (called "posix" in documentation). However, it still uses the GNU format by default, though the documentation has been threatening to move to the POSIX format for at least 20 years 8 . The good news is that the ustar , pax , GNU tar , and Seventh Edition tar formats are well documented and utilities across many UNIX-like systems 2,7,9,10,11 are able to handle these, depending on which formats existed when the utility was developed. While your system may not have pax itself installed, there are other archiving utilities that can read the file format, including GNU tar . (Somewhat amusingly, Debian and some other Free Software operating systems package a pax utility developed by MirBSD 12 which largely follows the POSIX-specified interface, but doesn't support reading or writing archives in pax format!) Look at the manual page for the tar , cpio , or pax utilities on your system to see if they can handle pax archives. Perhaps one aspect that has worked in favor of tar and other UNIX archive formats is that they only concern themselves with storing files and make no attempt at compression. Instead, it is common for a complete archive file to be compressed after creation; many utilities can be told to do this step for you, but it is not typically the default behavior. Therefore, if a better compression method comes along, the archive format doesn't need to change. If you do use compression, be careful to choose a method that is available on the destination system. Compressing files is a big enough subject to deserve its own episode, so we won't talk more about it here. So which format should you use when creating an archive? Unfortunately, there is no single answer that applies in all circumstances. The pax format is supported among modern UNIX-like systems and can represent all types of files and metadata. While other systems, their filesystems, and archive utilities might not be able to properly make use of all the metadata, they should at least be able to extract the data contained in files and, if Unicode is supported, give them appropriate filenames. If you intend to unpack the archive on an older system, more research might be needed to figure out what formats it is able to handle. The Seventh Edition tar format (often called "v7") is widely supported, including by older systems, but has limitations in what it can contain as described earlier. Moving beyond the UNIX world, things get even more complicated. Apple's macOS, with its FreeBSD underpinnings, easily handles tar files. However, when it comes to MS-DOS and Windows, it's a bit different. There, a multitude of archiving programs and formats arose, usually combining archiving with compression. PKZIP was probably the most popular of these and its .zip format became common in many places, helped by the fact that PKWARE openly published the specification. While there is only a single .zip format, it has many options, some proprietary, and different implementations have diverged in the way some aspects are handled (or not handled). An ISO/IEC standard for .zip 13 was published in 2015 giving a baseline profile, and sticking to it produces files that can be widely extracted successfully. Other file formats like OpenDocument use the .zip format and typically hew to the standardized profile. Windows' File Explorer, starting with Windows XP, can natively extract .zip files 14 . The Info-ZIP program 15 is a Free Software implementation for a wide variety of systems (even rather obscure ones); while it might not be installed on yours, if you're copying the archive file over, you can probably copy over its unzip utility at the same time to unpack it. So .zip probably has the broadest support, although it might not already be present on every system. However, as Klaatu points out in Hacker Public Radio episode 4557 16 , .zip files and applications handling them aren't always great at maintaining metadata about files. The .zip format doesn't seem to have any way to represent UNIX file permissions, and user/group ownership can only be included as numeric IDs. Other types of metadata on UNIX-like systems are not saved at all. This is probably not a problem in some cases, such as with a collection of photos, but for others it might be a concern. While pax as a utility does not seem to have gained much popularity or support, except on commercial UNIX systems where including it was required to conform to the POSIX standard, its file format has persisted. Free Software systems have generally avoided the pax interface, preferring to stick with the tar utility on the command line, but usually have good support for archive files in the pax format. Outside of UNIX-like systems, .zip seems to have become the most common file format, and support for it is also good in the UNIX world, though it might not be built in. References: Archive (library) file format https://man.cat-v.org/unix-1st/5/archive NetBSD 10.0 cpio manual page https://man.netbsd.org/NetBSD-10.0/cpio.1 Debian binary package format https://manpages.debian.org/trixie/dpkg-dev/deb.5.en.html RPM V6 Package format https://rpm.org/docs/6.0.x/manual/format_v6.html NetBSD 10.0 libarchive-formats manual page https://man.netbsd.org/NetBSD-10.0/libarchive-formats.5 Pax specification https://pubs.opengroup.org/onlinepubs/009695399/utilities/pax.html GNU tar manual https://www.gnu.org/software/tar/manual/tar.html GNU tar manual for version 1.15.90 https://web.cvs.savannah.gnu.org/viewvc/*checkout*/tar/tar/manual/tar.html?revision=1.3 FreeBSD 15.0 libarchive-formats manual page https://man.freebsd.org/cgi/man.cgi?query=libarchive-formats&sektion=5&apropos=0&manpath=FreeBSD+15.0-RELEASE+and+Ports OpenBSD 7.8 tar manual page https://man.openbsd.org/OpenBSD-7.8/tar HP-UX Reference (11i v3 07/02) - 1 User Commands N-Z (vol 2) https://support.hpe.com/hpesc/public/docDisplay?docId=c01922474&docLocale=en_US MirBSD pax(1) manual page http://www.mirbsd.org/htman/i386/man1/pax.htm#Sh.STANDARDS ISO/IEC 21320-1:2015 Information technology - Document Container File Part 1: Core https://www.iso.org/standard/60101.html Mastering File Compression on Windows https://windowsforum.com/threads/mastering-file-compression-on-windows-how-to-zip-and-unzip-files-effortlessly.369235/ About Info-ZIP https://infozip.sourceforge.net/ HPR4557::Why I prefer tar to zip https://hackerpublicradio.org/eps/hpr4557/index.html Provide feedback on this episode.

FreeBSD and OpenZFS in the Quest for Technical Independence, Reviews make you 10x slower, OpenBSD on a Motorola 88000, Jailrun, and more. NOTES This episode of BSDNow is brought to you by Tarsnap and the BSDNow Patreon Headlines FreeBSD and OpenZFS in the Quest for Technical Independence: A Storage Architect's View Every layer of review makes you 10x slower News Roundup The story of OpenBSD on Motorola 88000 series processors Jailrun + jailrun github FreeBSD Users: We Need to Talk About Claude Code Vibe-coded ext4 for OpenBSD Tarsnap This weeks episode of BSDNow was sponsored by our friends at Tarsnap, the only secure online backup you can trust your data to. Even paranoids need backups. Feedback/Questions Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv Join us and other BSD Fans in our BSD Now Telegram channel

Northern Ireland is a launchpad for thriving startups, and one startup that has done very well is Belfast based Cloudsmith. Back in March they had an oversubscribed Series B which raised £18m from key investors. To find out more about Cloudsmith and the startup scene in Belfast I caught up with Glenn Weinstein the CEO of Cloudsmith.Glenn talks about his background, what Cloudsmith does, Belfast, Unix, open source libraries and more.More about Cloudsmith:Made with love in Belfast and trusted around the world. Cloudsmith is the fully-managed solution for controlling, securing, and distributing software artifacts. Led by industry veterans united by a common passion to make it easier for software teams to do their jobs well. They are building the future of the software supply chain. 

A version of this essay has been published by firstpost.com at https://www.firstpost.com/opinion/shadow-warrior-drones-are-the-new-tanks-time-for-india-to-catch-up-13998019.htmlThe most important lesson (of many) from Gulf War 3 may have been foreshadowed by the Ukraine War and other conflicts: that a combination of a step-change in warfare (military strategy) and disruptive innovation (business strategy) could rewrite the rules. If so, we may need to rethink the value of much expensive hardware. Moreover, nations such as India may need to seriously revamp their arms procurement: to small, cheap, local maybe?The most disturbing aspect of this scenario is that it reduces the human factor, and human control, over warfare. It leads to the specter of robot warfare, of Skynet, of 2001: A Space Odyssey, where autonomous intelligences may take rational decisions that have grave consequences for humans, inflicting collateral damage on innocent bystanders in ways that nobody quite understands. We need a real-life version of Isaac Asimov's “Three Laws of Robotics”. But then humans too inflict unthinking collateral damage..Step-change in warfare, and disruptive innovationThere have been numerous instances where a settled and standardized war tactic was suddenly overturned by a new invention, rendering old military assets impotent. One or two examples will suffice: one was the eclipse of heavy cavalry after the invention of massed archers using longbow volleys to mow them down with thousands of synchronized arrows raining down, also inducing panic in their horses in mid-charge.Another example is how battle tanks overwhelmed the previous model of trench warfare. (Ironically, in turn, tanks are now being rendered sitting ducks by drones.)In both cases, long-held assumptions had to be rewritten practically overnight, and entirely new mechanisms had to be put in place. It is a good question (on which reasonable people may differ) as to whether the arrival of drone-and-missile-based warfare is rendering air power, including fighters, bombers and aircraft carriers, essentially obsolescent.Clayton Christensen articulated the theory of disruptive innovation in business, where an entrenched incumbent can be overthrown in short order by an insurgent attacking them from an unexpected direction, often based on lower-cost options. One example is that of Kodak and the film-camera business. Cheap and convenient digital photography dislocated Kodak et al practically overnight.I personally experienced this disruption in the 1990s when I had a key role in operating system strategy for Sun Microsystems, the runaway leader in engineering workstations and servers, which used the Unix operating system. Despite our best efforts, Microsoft+Intel coming in from the low end (as Windows systems became more capable) rapidly captured the key resource, which is third-party software vendors. This caused end users to desert in droves.There were other reasons, too: internecine warfare among firms using Unix, such as IBM, HP, Sun, AT&T, Toshiba, et al. While they bickered, Windows systems became more powerful. Lesson: the ecosystem has to be managed carefully, including supply chains.Putting these three together (step-change, disruptive innovation, and the ground realities of the Gulf War 3) one can speculate that future military doctrine will be vastly different. Here is Iran's military doctrine, for reference, from the substack NotesonGeopolitics (Disclaimer: I am neither endorsing it or criticizing it, just offering it as an example).The US is adjusting to this reality. There is a book titled “Project Maven”, based on 200+ interviews chronicling the US military's shift to AI-driven warfare, starting with a 2017 Pentagon project to automate drone footage analysis amid overwhelming data volumes.Project Maven evolved from error-prone early tools (such as misidentifying school buses as threats) to supporting autonomous systems like Goalkeeper drones and Whiplash naval units, now used in conflicts from Ukraine to the Caribbean by 25,000 personnel across 32 companies.Speaking of disruptive innovation, it is ironic to see the US reverse-engineering Iranian Shahed drones, and the Russians doing the same to Ukrainian drones: incumbents learning from insurgents.This is only the beginning, of course. There is a nightmare scenario: murmurating, autonomous drone swarms with a hive mind. A flock of starlings flying in perfect synchrony is a thing of beauty: they do not collide with each other, the entire swarm changes direction instantaneously, and there is emergent intelligence in the swarm, much greater than the intelligence of the individual bird. The same is true of beehives and ant colonies, too.A company called ShieldAI in fact has a product named Hivemind that does precisely this.Imagine a murmurating drone swarm of 1,000 or even 10,000: and since they cost so little make, this is not unrealistic. The enemy may shoot down 90% of them, but the 10% that gets through, especially if they are kamikaze drones fitted with explosives, can cause real damage. There is the old joke about quantity: “What do you do when you invade China? First day, you take 10,000 prisoners. Second day, you take 100,000 prisoners. Third day, you surrender!”But we don't have to go that far: just take two instances where inexpensive drones were able to penetrate the defenses of heavily secured military airports. The first was in Russia in June 2025. Using 117 low-cost drones, Ukrainians struck several airbases at once. There is video footage of FPV drones landing on Tu-95 bombers, destroying them. These are strategic long-range nuclear bombers from the Cold War era, and will be difficult to replace.And then, just last month: at Barksdale Air Force Base in the US, where B-52 nuclear bombers are deployed, there were repeated drone swarm overflights (of 12-15 drones) between March 9th and March 15th, 2026. They couldn't be jammed, and displayed “non-commercial signal characteristics”, although they did not actually attack the planes. Reconnaissance, it must be assumed. Superpower militaries are unable to contain them.Electronic warfare like jamming may be ineffective anyway as swarms self-repair. But it is true that there are air defense weapons that can shoot down the majority of drones. There are interceptors (but they are much more expensive than the drones themselves). Then new Directed Energy Weapons (including both lasers and high-powered microwaves) are in development. Rail guns, I understand, are overkill for them.Where is India in this arms race?India finds itself left behind in this transition, and remains committed to legacy platforms such as tanks, fighters, and other imported systems. It is true that there were battlefield successes in Operation Sindoor, where X-25 drones (towed on a 100 meter optical cable) emitted the radar signatures of Rafale fighter jets, thus drawing enemy missiles to themselves, without harming the planes. But these were Israeli products; also British-origin Banshee drones were used for spoofing Su-31 and Mig-29 signatures..Indigenous drone efforts lag China by 3-5 years in scale, AI integration, and mass production; reliance on Chinese components persists despite bans. It does not have to be this way: India should create Production Linked Incentives for drones and missiles, and harness Machine Learning and Artificial Intelligence at scale.India needs to promote this as a cottage industry, so that many individuals will get involved, as in the following post by a Ukrainian drone-maker, with a hashtag #MadebyHousewives. That country produces as many as 4.5 million cheap drones a year, often using 3d printing.While Ukraine and Iran improvise hive-mind swarms under fire, India's northeast and border regions face asymmetric threats from low-cost systems. The recent mercenary scandal in the Northeast illustrates the peril. Mercenaries, the Northeast and a new Christian enclave?The March 2026 arrests by India's National Investigation Agency (NIA) expose how this drone proliferation directly endangers the Seven Sisters. Six Ukrainians and American mercenary Matthew Aaron Van Dyke were detained across Indian airports. They had repeatedly crossed from restricted Mizoram into Myanmar since 2024, training ethnic insurgent groups in drone assembly, operation, jamming, and electronic warfare.They smuggled European drone consignments through India for insurgent networks, some linked to proscribed Indian groups operating in the northeast. This is no abstract threat: drones enable precision strikes on security forces, surveillance of remote terrain, and supply drops. These capabilities could ignite or sustain insurgencies in India's volatile borderlands.In the background is former Bangladesh Prime Minister Sheikh Hasina's explosive 2024 warning. Hasina alleged a “white man's” conspiracy to carve out a new “Christian nation” (akin to East Timor or South Sudan) from Bangladesh's Chittagong Hill Tracts, Myanmar's Rakhine and Chin regions, and India's Northeast. She cited foreign eyes on the Bay of Bengal and ethnic fault lines.Hasina's claim was dismissed as paranoia then; today, Ukrainian-American actors arming Myanmar's rebel groups lend credence to a broader destabilization playbook. A hive-mind-enabled drone campaign could empower separatists and create a Christian-majority enclave, exploiting Christian tribal demographics and porous borders. This is hybrid warfare at its most insidious: mercenaries as force multipliers for great-power proxies.If these insurgents can leverage drone swarms to close the Siliguri Corridor or target regional infrastructure, they can create a fait accompli on the ground for India.ConclusionThe drone-missile age demands urgent adaptation. Nations must invest in AI swarm doctrine, resilient EW, decentralized deployment, and indigenous mass production ecosystems. For India, the wake-up call is clear: clinging to legacy investments while insurgents import hive-mind precursors risks not just military irrelevance but territorial integrity. The Tu-95 pyres and B-52 overflights are warnings. The northeast drone pipeline is a direct threat. Warfare has changed; those who fail to swarm will be overrun.Here is the AI-generated audio podcast about this essay:1570 words, Apr 3, 2026 This is a public episode. If you'd like to discuss this with other subscribers or get access to bonus episodes, visit rajeevsrinivasan.substack.com/subscribe

This episode originally aired on the Latent Space Podcast. swyx and Alessio Fanelli speak with Marc Andreessen about the arc of AI from its origins in 1943 to today's breakthroughs in reasoning, coding agents, and self-improvement. They cover the parallels between AI scaling laws and Moore's Law, the architectural insight behind Claude Code and the Unix shell, the coming supply crunch in compute, and why the messy reality of 8 billion people means both AI utopians and doomers are too optimistic about the pace of change. Follow Marc Andreessen on X: https://twitter.com/pmarca Follow Shawn "swyx" Wang on X:  https://twitter.com/swyx Follow Alessio Fanelli on X: https://twitter.com/FanaHOVA Listen to Latent Space. Stay Updated:Find a16z on YouTube: YouTubeFind a16z on XFind a16z on LinkedInListen to the a16z Show on SpotifyListen to the a16z Show on Apple PodcastsFollow our host: https://twitter.com/eriktorenberg Please note that the content here is for informational purposes only; should NOT be taken as legal, business, tax, or investment advice or be used to evaluate any investment or security; and is not directed at any investors or potential investors in any a16z fund. a16z and its affiliates may maintain investments in the companies discussed. For more details please see a16z.com/disclosures. Hosted by Simplecast, an AdsWizz company. See pcm.adswizz.com for information about our collection and use of personal data for advertising.

Fresh off raising a monster $15B, Marc Andreessen has lived through multiple computing platform shifts firsthand, from Mosaic and Netscape to cofounding A16z. In this episode, Marc joins swyx and Alessio in a16z's legendary Sand Hill Road office to argue that AI is not just another hype cycle, but the payoff of an “80-year overnight success”: from neural nets and expert systems to transformers, reasoning models, coding, agents, and recursive self-improvement. He lays out why he thinks this moment is different, why AI is finally escaping the old boom-bust pattern, and why the real bottleneck may be less about models than about the messy institutions, incentives, and social systems that struggle to absorb technological change.This episode was a dream come true for us, and many thanks to Erik Torenberg for the assist in setting this up. Full episode on YouTube!We discuss:* Marc's long view on AI: from the 1980s AI boom and expert systems to AlexNet, transformers, and why he sees today's moment as the culmination of decades of compounding technical progress* Why “this time is different”: the jump from LLMs to reasoning, coding, agents, and recursive self-improvement, and why Marc thinks these breakthroughs make AI real in a way prior cycles were not* AI winters vs. “80-year overnight success”: why the field repeatedly swings between utopianism and doom, and why Marc thinks the underlying researchers were mostly right even when the timelines were wrong* Scaling laws, Moore's Law, and what to build: why he believes AI scaling laws will continue, why the outside world is messier than lab purists assume, and how startups can still create durable value on top of rapidly improving models* The dot-com crash and AI infrastructure risk: Marc's comparison between today's AI capex boom and the fiber/data-center overbuild of 2000, plus why he thinks this cycle is different because the buyers are huge cash-rich incumbents and demand is already here* Why old NVIDIA chips may be getting more valuable: the pace of software progress, chronic capacity shortages, and the idea that even current models are “sandbagged” by supply constraints* Open source, edge inference, and the chip bottleneck: why Marc thinks local models, Apple Silicon, privacy, trust, and economics all point toward a major role for edge AI* American vs. Chinese open source AI: DeepSeek as a “gift to the world,” why open models matter not just because they're free but because they teach the world how things work, and how open source strategies may shift as the market consolidates* Why Pi and OpenClaw matter so much: Marc's claim that the combination of LLM + shell + filesystem + markdown + cron loop is one of the biggest software architecture breakthroughs in decades* Agents as the new “Unix”: how agent state living in files allows portability across models and runtimes, and why self-modifying agents that can extend themselves may redefine what software even is* The future of coding and programming languages: why Marc thinks software becomes abundant, why bots may translate freely across languages, and why “programming language” itself may stop being a salient concept* Browsers, protocols, and human readability: lessons from Mosaic and the web, why text protocols and “view source” mattered, and how similar principles may shape AI-native systems* Real-world OpenClaw use: health dashboards, sleep monitoring, smart homes, rewriting firmware on robot dogs, and why the most aggressive users are discovering both the power and danger of agents first* Proof of human vs. proof of bot: why Marc thinks the internet's bot problem is now unsolvable via detection alone, and why biometric + cryptographic proof of human becomes necessaryTimestamps* 00:00 Marc on AI's “80-Year Overnight Success”* 00:01 A Quick Message From swyx* 01:44 Inside a16z With Marc Andreessen* 02:13 The Truth About a16z's AI Pivot* 03:29 Why This AI Boom Is Not Like 2016* 06:33 Marc on AI Winters, Hype Cycles, and What's Different Now* 10:09 Reasoning, Coding, Agents, and the New AI Breakthroughs* 12:13 What Founders Should Build as Models Keep Improving* 16:33 AI Capex, GPU Shortages, and the Dot-Com Crash Analogy* 24:54 Open Source AI, Edge Inference, and Why It Matters* 33:03 Why OpenClaw and PI Could Change Software Forever* 41:37 Agents, the End of Interfaces, and Software for Bots* 46:47 Do Programming Languages Even Have a Future?* 54:19 AI Agents Need Money: Payments, Crypto, and Stablecoins* 56:59 Proof of Human, Internet Bots, and the Drone Problem* 01:06:12 AI, Management, and the Return of Founder-Led Companies* 01:12:23 Why the Real Economy May Resist AI Longer Than Expected* 01:15:53 Closing ThoughtsTranscriptMarc: Something about AI that causes the people in the field, I would say, to become both excessively utopian and excessively apocalyptic. Having said that, I think what's actually happened is an enormous amount of technical progress that built up over time. And like for, for example, we now know that neural network is the correct architecture.And I, I will tell you like there was a 60 year run where that was like a, you know, or even 70 years where that was controversial. And so, so the way I think about what's happening is basically, I think, I think about basically the, the, the period we're in right now is it's, I call it 80 year overnight success, right?Which is like, it's an overnight success ‘cause it's like bam, you know, chat GPT hits and then, and then oh one hits, and then, you know, open claw hits and like, you know, these are open, these are, these are like overnight, like radical, overnight transformative successes, but they're drawing on an 80 year sort of wellspring backlog, you know, of, of, of, of ideas and thinking it's not just that it's all brand new, it's that it's an unlock of all of these decades of like very serious, hardcore research.If I were 18, like this is a hundred, this is what I would be spending all of my time on. This is like such an incredible conceptual breakthrough.swyx: Before we get into today's episode, I just have a small message for listeners. Thank you. We will not be able to bring you the ai, engineering, science, and entertainment contents that you so clearly want if you didn't choose to also click in and tune into our content.We've been approached by sponsors on an almost daily basis, but fortunately enough of you actually subscribed to us to keep all this sustainable without ads, and we wanna keep it that way. But I just have one favor to ask all of you. The single, most powerful, completely free thing you can do is to click that subscribe button.It's the only thing I'll ever ask of you, and it means absolutely everything to me and my team that works so hard to bring the in space to you each and every week. If you do it, I promise you will never stop working to make the show even better. Now, let's get into it.Alessio: Hey everyone, welcome to the Lidian Space Pockets. This is CIO, founder Kernel Labs, and I'm joined by s Swix, editor of Lidian Space.swyx: Hello. And we're in a 16 Z with a, uh, mark G and welcome.Marc: Yes, yes. A and what, half of 16? Something like that. A one. Exactly,swyx: exactly. Uh, apparently this is the, the final few days in your, your current office.You're moving across the road.Marc: Uh, we're, yeah. We have a, we have some, we have some projects underway, but yeah, this is actually, oh, this is the original. We're in actually the original office. We're in the, we're in the, we're, we're in the whole thing.swyx: It's beautiful. Yeah. Great.Marc: Thank you.swyx: So I have to come out, uh, this is a, you know, I wanted to pick a spicy start in October, 2022.I just made friends with Roone and, uh, I wanted to give him something to sort of be spicy about. And I said, uh. Uh, it'll never not be funny. The A 16 Z was constantly going. The future is where the smart people choose to spend their time and then going deep into crypto and not in ai. And that was in October 22nd, 2022.And Ruen says there was an internal meeting in a 16 Z to reorient around Gen ai. Obviously you have, but was there a meeting? What, what was that?Marc: I mean, I don't, look, I've been doing AI since the late eighties.swyx: Yeah.Marc: So I, I don't know, like all that, as far as I'm concerned, this stuff is all Johnny cum lately.Yeah. You, I mean, look, we've been doing ar entire existence. I mean, we've been doing AI machine learning deep, you know, deeply. We've been doing this stuff way from the beginning. Obviously a AI is just core to computer science. I, I, I actually view them as like quite, uh, quite continuous. Um, you know, Ben and I both have computer science degrees.Um, you know, we, we both, Ben, Ben and I actually both are world enough to remember the actual AI boom in the 1980s. Yeah. There was like a, there was a big AI boom at the time. Um, and there was a, was names like expert systems. Um, and they of like lisp and lisp machines. Uh, I, I coded in lisp. I was coding a lisp in 1989.When that was the, the language of the AI future. Um, yeah. So this is something that we're like completely, you completely comfortable with. I've been doing the whole time and are very enthusiastic aboutswyx: is there a strong, like this time is different because, uh, my closest analog was 20 16 17. It was an AI boom.Mm-hmm. And it petered out very, very quickly. Um, we, it just, it just in terms of investingMarc: sort of, sort of,swyx: yeah. Investment, investment excitement.Marc: Although that's really when the, the, the Nvidia phenomenon really, it was, I would say it was in that period when it was very clear that at, at the time it, the vocabulary was more machine learning, but it, it was very clear at that time that machine learning was hitting some sort of takeoff point.Alessio: Yeah.Marc: Well, and as you guys, you guys have talked about this at length on, on your thing, but, you know, if you really track what happened, I think the real story is, it was, it was the Alex net, uh, basically breakthrough in like 2013. That was the, that was the real knee in the curve. Um, and then it was obviously the transformer breakthrough in 17.Alessio: Yeah.Marc: Um, and then everything that followed. But, but, you know, look, machine learning, you know, there were, you know, look, uh, I mean look, I've been working, you know, I've been working with, uh, one of my, you know, kind of projects working with Facebook since 2004. Um, and on the board since 2007, and of course, you know, they, they started using machine learning very early, um, and, you know, have used it basically, you know, for like 20 years for, you know, content, you know, feed optimization and advertising optimization.And obviously many, you know, financial services. You know, many, many, many companies, many different sectors have been doing this. And so it's like one of these things, it's like, it's not a, it's not a single thing. Like it's, it's like, it's like layers, right? Yeah. Um, and, and the layers arrive at different paces and, but they kind of build up.swyx: Yeah.Marc: Uh, they kind of build up over time and then, and then, yeah. And then look, in retrospect, it was 2017 was kind of the, you know, the key, the key point with the trans transformer and then. And then as you guys know, there was this really weird like four year period where it's like the, the transformer existed and then it was just like,swyx: let's go.Yeah.Marc: Well, but, but it was just, but, but between 2020, but between 2017 and 2021, I mean, that was the era of which like companies like Google had internal chat Botts, but they weren't letting anybody use them.swyx: Yeah.Marc: Right. And then, you know, and then OpenAI developed Chat GT or GPT two, and then they told everybody, this is way too dangerous to deploy.Right. Yeah. You know, we can't possibly let normal people, normal people use this thing. And then you, you guys, I'm sure remember AI Dungeon, um mm-hmm. So the o for, there was like a year where like the only way for a normal person to use GP T three was in, in AI dungeon.Alessio: Yeah.Marc: And so you, you, we would do this, you'd go in there and you'd pretend to play Dungeons and Dragons.In reality, you're just trying to talk to talk to GPT. And so there was this, you know, there was this long, you know, and I, you know, the big, big companies, you know, big companies are cautious and, you know, the big companies were cautious. It, it, by the way, it took open ai. You know, they, they, they talk about this, it took open AI time to actually adjust, you know, kind of re redirect their researchswyx: path.I, I think, uh, let say Rosewood, right? Uh, the, the dinner that founded OpenAI was right there.Marc: Right, right. But that, that dinner would've taken place in 20swyx: 18Marc: 19. The formation of OpenAI Uhhuh as late as 2018.swyx: Uh, uh, sorry. Uh, no, I'm, I'm, I'm, I'm wrong. Probably It should be 20. Yeah. They just celebrated a 10 year anniversary, so it it is 2025.Yeah, so, so 2015?Marc: Yeah. 2015. Yeah. 2015. But then, uh, um, Alec Radford did G PT one in what, probablyswyx: mm-hmm. 17, 18,Marc: yeah. 17, 18. So it, yeah. For, and then, and then they didn't really, and then GPT three was what? 2020? 2020.swyx: 2020.Marc: Because that became copilot immediately. Even open ai, which has been, you know, the leader of, of this thing in the last decade, you know, e even they had to adapt and, and, and lean into the new thing.And so. Um, yeah, I, I think it's just this process of basically sort of wave after wave layer after layer, you know, building on itself. And then you kind of get these catalytic moments where, where the whole thing pops and, and obviously that's what's happening now.swyx: Is it useful to think about will there be any ai, winter?‘cause there's always these patterns. Like, is this, in the summer is something I constantly think about because do I get, do I just like. Just get endlessly hyped and just trust that I will only be early and never wrong or right. Well, are we, will there be a winter?Marc: So there's something about, say the following.There's something about AI that has led to this repeated pattern. Um, and, and, and you guys know this,swyx: it's summer, winter, summer,Marc: winter, summer, winter, summer, winter. And it goes back 80 years. Yeah. 80 years. Uh, so the original neural network paper was 1943. Right. Which is, which is amazing. Uh, that it was, it was far back that long.And then there was you, if you guys have ever talked about this on your show, but there was this, uh, there was a big, uh, there was an a GI conference at Dartmouth University in 1950. 55. 55, yeah. And they got a NSF grant to, uh, for the, all the AI experts at the time to spend the summer together. And they figured if they had 10 weeks together, they could get a GI, uh, at the other end.And they got their, by the way, they got the grant, they got the 10 weeks and then, you know, 1955, you know. No, no. A GI. And like I said, I, I lived through the eighties version of this where there was a big, a big boom and a crash. And so, so there is this thing, and there, there is something about AI that causes the people in the field, I would say, to become both excessively utopian and excessively apocalyptic.Um, and, and it's probably on both sides of like the, the, the boom bus cycle. You, you kind of see that play out. Having said that, I think what's actually happened is like just, and you know, and we now know in retrospect like an enormous amount of technical progress that built up over time. And like for, for example, we now know that neural network is the correct architecture.And I, I will tell you like there was a 60 year run where that was like a, you know, or even 70 years or that was controversial. And, and we now know that that's the case. And so we, we now, you know, everything we're building on today just sort of derives from the original idea in 1943. And so, so in retrospect, we, we now know that like, these, these guys are right.They, they, you know, they would get the timing wrong and they thought, you know, capabilities would arrive faster, or they were, it could be turned into businesses sooner or whatever, but like, they were fundamentally, the, the scientists who worked on this over the course of decades were fundamentally correct about what they were doing.And, and the, and the payoff from, from, from all their work is happening now. And so, so the way I think about what's happening is basically, I think, I think about basically the, the, the period we're in right now is it's, I call it 80 year overnight success, right? Which is like, it's an overnight success.‘cause it's like bam, you know, chat, GPT hits and then, and then oh one hits, and then, you know, open claw hits and like, you know, these are open, these are, these are like overnight, like radical, overnight transformative successes, but they're drawing on an 80 year sort of wellspring backlog, you know, of, of, of, of ideas and thinking it's not just that it's all brand new, it's that it's an unlock of all of these decades of like very serious, hardcore research.Um, and thinking, and look, there were AI researchers who spent their entire lives. They got their PhD. They, they worked for, they've researched for 40 years. They retired in a lot of cases, they passed away and they never actually saw it work.swyx: Yeah. It's all sad.Marc: It is. It is sad. It's sad. Knewswyx: Jeff Hinton was like the last guy.Marc: Yeah. Yeah. Well, there were the guys, uh, was a guy, Alan Newell. I mean, there's tons of John McCarthy. You know, John McCarthy was like one of the inventors in the field. He's one of the guys who organized the Dartmouth Conference and you know, he taught at Stanford for 40 years. Wow. And passed, you know, passed away, I don't know, whatever, 10, 10 years ago or something.Never, never actually go. Got to see it happen. But like, it is amazing in retrospect, like, these guys were incredibly smart and they worked really hard and they were correct. So anyway, so then it's like, okay, you know, say history doesn't repeat, but it rhymes. It's like, okay, does that mean that there's gonna be another, like, you know, basically boom buzz cycle.And I, I will tell you, like, let, like in a sense, like yes, everything goes through cycles and, you know, people get overly enthusiastic and overly depressed and there's, there's a time, there's a timelessness to that. Having said that, there's just no question. Um, so the form, the foremost dangerous words in investing this time are, this time is different.Do you know the 12 most dangerous words investing? No. The four most d foremost dangerous words in investing are this time is different. Yeah. Um, the 12 most dangerous words. And so like, I'll tell you what's different. Like now it's working like, like there's just no, I mean, look, there's just no question.And by the way, I, I'll just give you guys my take. Like L LLMs, like from, from basically the Chad G PT moment through to spring of 25. I think you could still, I think well intention, well, and of. Form skeptics could still say, oh, this is just pattern completion. And oh, these things don't really understand what they're doing.And you know, the hall hallucination rates are way too high. And, you know, this is gonna be great for creative writing and creating, you know, Shakespeare and so sonnets and, you know, as, as rap lyrics or whatever, like, it's gonna be great and all that stuff, but we're not gonna be able to harness this to make this relevant in, you know, coding or in medicine or in law or in, you know, you know, kind of feels that, you know, kind of really, really matter.And I think basically it was the reasoning breakthrough. It, it was oh one and then R one that basically answered that question basically said, oh no, we're gonna be able to actually turn this into something that's gonna work in the real world. And, and then obviously the coding breakthrough over the, over basically the coding breakthrough that kind of catalyzed over the holiday break was kind of the third step in that.Mm-hmm. Where you're just like, alright, if, if, you know, if Linus Tova is saying that the AI coding is no better than he is like. Like, that's, that's never happened before. That's theswyx: benchmark.Marc: Yeah. That's never happened before. And so now we know that it's, it's gonna sweep through coding and, and then, and then we, we know, you know, we know that if it's gonna work in coding, it's gonna work in everything else.Right. It's just then, because that's, that's like, that's like, that's like the hardest in many ways. That's the hardest example. And how everything else is gonna be a, a derivative of that. And then on top of that, we just got the agent breakthrough, you know, with Open Claw, which is fantastic. Which is amazing and incredibly powerful.And then we just got the, the, um, the auto research, uh, you know, the, the self-improvement. You know, we're now into the self-improvement breakthrough. And so the, so the way I think about it is we've had four fundamental breakthroughs in functionality, l OMS reasoning, uh, agents, um, and then, uh, and, and then now RSI, um, and, and they're all actually working.Um, and so I'm, I'm just, as you like, you can tell I'm jumping outta my shoes. Like, like this is, like this is it like this, this is the culmination of 80 years worth of worth of work, and this is the time it's becoming real.Alessio: Yeah.Marc: I, I'm completely convinced.Alessio: I think the anxiety that people feel is like during the transistor era, yet Mors law, and it's like, all right, we understand why these things are getting better.We understand the physics of it. Yeah. With ai, it's. It's so jagged in like the jumps where like, like you said, it's like in three months you have like this huge jump like, and people are like, well this can keep happening. Right? But then it keeps happening,Marc: it'll keep happening.Alessio: And so like how do you think about also timelines of like what's we're building?I think we always have this question with guests, which is like, you know, should you spend time building harness for a model versus like the next model just gonna do it one shot in the lead space. Right. And how does that inform, like how you think about the shape of the technology? You know, you talk about how it's a new computing platform.If you have a computing platform, then like every six months it like drastically changes in what it looks like. It's hard to build companies on top of it.Marc: Yeah. So, so a couple things. So one is like, look, the, the Moore's law was what we now call a scaling law. Like Moore's Law was a scaling law and for your younger viewers, more Moore's Law was every chip chip chips either get twice as powerful or twice as cheap every, every 18 months.And that, and that and that, you know, that it's gotten more complicated in the last few years. But like that, that was like the 50 year trajectory of, of, of the computer industry. And then, and then by the way, and that's what took the mainframe computer from a $25 million current dollar thing into, you know, the phone in your pocket being, you know, a million times more powerful than that.Like that, you know, for, for 500 bucks. And so that, that was a scaling law. And then, and then, and then key to any scaling law, including Moore's Law and the AI scaling laws is, you know, they're not really laws, right? They're, they're, they're, they're predictions, but when they work, they become self-fulfilling predictions because they, they, they, they, they set a benchmark and, and then the entire industry, right?All the smart people in the industry kind of work to make sure that, that, that actually happens. And so they, they kind of motivate the breakthroughs that are required to, to keep that going. And, and in and in chips, that was a 50 year, that was a 50 year run. Right. And it, it was amazing. And it's still happening in, in some areas of, of chips.I think the same thing is happening with the, the core scaling laws. The core scaling laws. In, in, in ai, you know, they're, they're not really laws, but like they, they are basically. There are predictions and then they're motivating catalysts for the research work that is required to be. And, and, and, and by the way, also the investment, uh, dollars, um, uh, you know, required to basically keep, you know, keep the curves going and, and look, it, it is, it's gonna be complicated and it's gonna be variable and they're, you know, there're gonna be walls that are gonna look like they're fast approaching, and then they're gonna be, you know, engineers are gonna get to work and they're gonna figure out a way to punch through the walls.And obviously that's, you know, that's been happening a lot, you know, and then look, there's gonna be times when it looks like the walls have, you know, the, the, the laws have petered out and then they're gonna, they're gonna pick up again and surge and then, and then, and then it, it appears what's happening to the eyes is there's not multiple, you know, multiple scaling laws.Um, there's multiple areas of improvement. And, and I think, you know, I don't know how many more there are already yet to be discovered, but there are probably some more that we don't know about yet. You know, they, like, for example, there's probably some scaling law around, um, world models and robotics that we don't fully understand, you know, kind of acquisition of data at scale in the real world that we don't fully understand yet.So that, that, that one will probably kick in at some point here. There's a bunch of really smart people working on that. Um, and so, yeah, I, I think the expectation is that, that, you know, the, the scaling laws generally are gonna continue. Yeah. The, the pace of improvement will continue to move really fast.Um. To your question on like what to build. So, uh, I'm a complete believer the scaling laws are gonna continue. I'm a complete believer the capabilities are gonna keep getting amazing, um, you know, leaps and bounds. Uh, the part where I kind of part ways a little bit with how, what I would describe as the AI purists, um, you know, which is, which I would characterize as like the people who are.In many ways, the smartest people in the field, but also the people who spend their entire life, like at a lab, um, and have, have, I would say, have very little experience in the outside world. Um, the, the, the nuance I would offer is the outside world of 8 billion people and institutions and governments and companies and economic systems and social systems is really complicated.Um, and, um, and doesn't, you know, it it 8 billion people making collective decisions on planet Earth is not a simple process of like, just like you see this happening now. It's like a bunch of AI CEOs have this thing, which is just like, well, there's just this, they just all have this kind of thing when they talk in public where they're just like, well, there's these, these obvious set of things that so society to do.Alessio: Mm-hmm.Marc: And then they're like, society's not doing any of those things. Right. And it's like, how can society not, you know, what, whatever their theory is, how can society not see x, y, Z? Mm-hmm. And the answer is, well, society is number one. There's no single society, it's like 8 billion people. And they like all have a voice, and they all have a vote, like at the end of the day of how they, they react to change.And then, you know, it just like, it's just human reality is just really complicated and messy. Um, and, and, and so the specific answer to your question is like, as usual, it depends. Um, you know, it, it depends. Look, pe there's no question people are gonna, like, there's no question they're gonna be companies.It's already happening. There are companies that think that they're building value on top of the models and then they're just gonna get blissed by the, by the next model. There's no question that's happening. But I think there's no question also that just the process of adaptation of any technology into the real and into the real messy world of humanity is, is just going to be messy and complicated.It's, it's not going to be simple and straightforward. It's gonna be messy and complicated. And there are gonna be a lot of companies and a lot of products, um, uh, and in, in fact entire industries that are gonna get built to, to, to basically actually help all of this technology actually reach real people.Alessio: The amount of capital going into these companies, I mean, Dario talked about it on the Door Cash podcast and Door Cash was like, why don't you just buy 10 x more GPUs? And he is like, because I'm gonna go bankrupt if the model doesn't exactly hit the, the performance level. How do you think about that?Also as a risk on, you know, you guys are investors, open AI and thinking machines and world apps. It seems like we're leveraging the scaling loss at a pretty high rate, right? Like how comfortable, I guess, do you feel with the downside scenario, like, and say like things Peter out, you think you can kind of like restructure uh, these build outs and uh, you know, capital investments.Marc: Yeah. So should start by saying, so I live through the.com crash, um, and I can tell you stories for hours about the.com crash and it was horrible. No, it was awful. It was, it was, it was apocalyptic by the way. The, a lot of the.com crash was actually at the time, it was actually a telecom crash. It was a bandwidth crash.Like the, the thing that actually crashed, that wiped out all the money with the tele, the telecom companies.swyx: GlobalMarc: crossing. Global, global, yeah.swyx: I'm from Singapore and they, they laid so much cable o over over our oceans.Marc: Actually there was a scaling law in the.com. Era. And it was literally the, the US Commerce Department put out a report in 1996 and they said internet traffic was doubling every quarter.Um, and, and actually in 1995 and 1996, internet traffic actually did double every quarter. And so that became the scaling law. And so what all these telecom entrepreneurs did was they went out and they raised money to build fiber, anticipating that the demand for bandwidth is gonna keep doubling every quarter.Doubling every quarter though is like, you know, grains of chess and the chessboard, like at some point the numbers become extremely large. Right. And, and, and it really, and really what happened was the internet. The internet by the way, continuously kept growing basically since inception. And it's, you know, it's, it's continuously grown.It's never shrunk. And it's grown really fast compared to anything else. Mm-hmm. You know, in, in, in human history. But it wasn't doubling every quarter as of 19 98, 19 99. And so there was this gap in the expectation of what they thought was a scaling law versus reality. And that's actually what caused the.com crash, which was the, it they, they way over companies like global crossing way overbuilt fiber, which is sort of the, and by the way, fiber, telecom equipment, you know, so all the, all the networking gear, you know, and then, and then by the way, the actual physical data centers, like that was the beginning of the, of the, of the data center build and then, and the data center overbuild.And so you had that, but it was, it was literally, I think it was like $2 trillion got wiped out, right? It was like Jesus, it was like a big, it was. And by the way, the other, the other subtlety in it was the internet companies themselves never really had any debt. ‘cause tech, tech companies generally don't run on debt, but the telecom companies run on debt.Physical infrastructure companies run on debt. And so the companies like Global Crossing not just raise a lot of equity, they also raise a lot of debt. So they're highly levered. And so then you just do the thing. It's just like, okay, you have a highly levered thing where you're, you're just over, you're overbuilding capacity.Demand is growing, but not as fast as you hoped. And then boom, bankrupt. Right. And, and then it, and then it's like they say about the hotel industry, which is, it's always the third owner of a hotel that makes money. It has to go bankrupt twice, right? You have to wash out all of the over optimistic exuberance before it gets to actually a stable state.And then it makes money. So by the way, all of those data centers and all of those, all the fiber that they're in use, it's all in use today. Yeah. But 25 years later. But it, it, it took, and actually the elapsed time was, it took 15 years. It took 15 years from 2000 to 2015 to actually fill, fill up all that capacity.The cautionary warning is the, the overbuild can happen. Um, and, and, and, and, you know, you, you get into this thing where basically everybody, everybody who basically has any sort of institutional capital, it's like, wow. It's just, I, I don't know how to invest in these crazy software things. For sure I can put build data centers and for sure I can buy GPUs that I can deploy, you know, compute grids and, and all these things.Um, and so, you know, if you're a pessimist, you could look at this and you could say, wow, this is like really set up to be able to basically replicate, you know, what we went through, what we went through in 2000. Obviously that would be bad. The counter argument, which is the one I I agree with, which is the counter on, on the other side is a couple things.One is the companies that are investing all the, the companies that are investing the money are like the bluest chip of companies. And so back, back, back in the, in the do, like Global Crossing was like a, it was like an entrepreneur. It was like a, a new venture, but like the money that's being deployed now at scale is Microsoft, and, you know, and Amazon and Google, Facebook and Facebook and Nvidia and, you know, these, these, these, and, and now you know, by the way, open ai philanthropic, which are now at like, you know, really serious size, um, you know, as companies with, you know, very serious revenue.These are very large scale companies with like, lots, lots of cash, lots of debt capacity that they've, they've never used. And so th this is institutional in a way that, that really wasn't at the time. And then the other is, at least for now, every dollar that's being put into anything that results in a running GPU is being turned into revenue right away.Like so, and you guys know this, like everybody's starved for capacity, everybody's starved for compute capacity and then, you know, all the associated things, memory and, and, and interconnected and everything else. Um, data center space. And so e every dollar right now that's being put into the ground is turning into revenue.And, and it, and in fact, I actually think there's an interesting thing happening, which is because everybody starve for capacity, the models that we actually have that we can use today are inferior versions of what we would have if not for the supply constraints. That's true. Um, if Right pose a hypothetical universe in which GPUs were 10 times cheaper and 10 times more plentiful mm-hmm.The models would be much better. ‘cause you would just allocate a lot more money to training and you'd just build better models and they would be better. Um, and so we're, we're actually getting the sandbag version of the technology.swyx: Yeah. No. Everything we use is quantized because the, the labs have to keep the, the full versions,Marc: right?swyx: LikeMarc: we're not even getting the good stuff.swyx: Yeah.Marc: But, but getting the good stuff, it's, it's just, even if technical progress stops. Once there's like a much bigger build of like GPU manufacturing capacity and memory, you know, all, all the things that have to happen in the course of the next five or 10 years.Once it happens, even the current technology is gonna get, gonna get much better. And then as you know, like there's just like a million ways to use this stuff. Like there's just like a million use cases for this. Mm-hmm. Like, it, it, you know, this isn't just sending packets across a, a thing, whatever, and hoping that people find something to do with it.This is just like, oh, we apply intelligence into every domain of human activity. And then it works like incredibly well. Yeah. Um. Here's what I know, here's what I know. Um, in the next three or four year, it's like somewhere between three or four years out, basically everything is selling out. So like the, the entire supply chain is, is, is, is sold out or, or, or selling out.And so there, there's no, like, we're just gonna have like chronic supply shortage for, you know, for years to come. Um, there's going to be a response from the market that's gonna result in an enormous, you know, it's happening now. An enormous flood of investment in a new fab capacity and ev you know, every, everything else to be able to do that, at some point the supply chain constraints will unlock, you know, at least to some degree that will be another accelerant to industry growth when that happens.‘cause the products will get better and everything will get cheaper. Um, and so, so I know that's gonna happen. I know that, you know, the deployments, you know, the, the actual use cases are like really compelling. And then, like I said, you know, with reasoning and agents and so forth, like, I know they're just gonna get like much, much better from here.And so I, I, I know the capabilities are like really real and serious. I also know that the technical progress is not going to stop. It. It, it is excel. It is, is accelerating. Like the, the breakthroughs are are tremendous. I mean, even just month over month, the breakthroughs are really dramatic. And so, you know, I think if you were a cynic and there, there are cynics, you can look at 2000, you can find echoes.But I can't even imagine betting it that this is gonna like somehow disappoint and, you know, at least for years to come, I think it would be essentially suicidal to make that bet. Yeah. Um, it was that Michael Burry, uh, uh, that'sswyx: anMarc: interesting guy, huh? We'll pick on a guy. We'll pick, let's pick on one guy.We'll pick. Well ‘cause he did, he he came out with, it was, it was the, heswyx: doesn't mind.Marc: It was the Nvidia short. Right. He came with the Nvidia short. And then if you guys probably talked about this, which is the, the analysis now that like the current models are getting better faster at such a rate that if you are running an Nvidia, if you're running an Nvidia inference chip today, that's three years old, you're making more money on it today than you did three years ago because the pace of improvement of the software is, is faster than the, the, the depreciation cycle, the chip.And then my understanding is Google is running. I don't if they've, I don't know exactly what, uh, these are rumors that I've heard or maybe it's public, but, um, I think Google's running very old TPUs, very profitably. Ference. Yeah. And very profit and very profitably. Yeah. Um, and so, so it actually turns out, as far as I can tell, it's actually the opposite of the Beery thesis is actually.He was actually 180 degrees wrong. It's actually the, the, the, the old Nvidia chips are getting more valuable, which is something that's like literally never happened before. Like it's never been the case that you have an older model chip that becomes more valuable, not less valuable. And that, and again, that's an expression of the just ferocious pace of software progress.Ferocious pace of capability payoff. Yeah. Uh, that you're getting on the other side of this. And so I just, the idea of betting against that, like.swyx: Yeah. Yeah. Well, one ofMarc: my, it seems like an invitation to get your face ripped up.swyx: One of my early hits was like modeling the lifespan of the H 100 and h two hundreds and, and going like, you know, usually they advise like four to seven years and it was, you know, maybe you sort of realistically haircut cut it down to two to three.Yeah. But actually it's going up and not down. Yeah. And, and uh, that's, I mean that's, I think that's the dream. Uh, we are finding utilization and I think utilization solves all problems. Like, you can, you can find use, use cases for even like the poor, like even memory, we're having a shortage. Right. And, and even like the, the shittier versions of, of memory that we do have, we are finding use cases for it.So like That's great.Marc: Yeah.Alessio: How, how important is open source AI and kinda like edge inference in a world in which you have three years of supply crunch. Like, do you think in the, like, you know, if you fast forward like five years, like how do you think about inference, uh, in the data center versus at the edge?Marc: Well, so just to start, yeah. So I think, I think open source is very important for a bunch of reasons. I think edge, edge inference is very important for a bunch of reasons. I, I think just practically speaking, if we're just gonna have fundamental construc, supply crunches for the next, I mean, you, you guys know if you just project forward demand over the next three years, right?Yeah. Relative to supply, one of the, its main predictions you can do is what's gonna, what, what's gonna happen to the cost of, of inference in the core, uh, over the next three years? And like, it may rise dramatically, right? Like, so, so what is, and then is, is, you know, like the, the, the big model competition are subsidizing heavily right now.Right? Right. And so, so what's the, what will be the average person's, you know, per day, per month token cost, you know, three years from now to do all the things that they want to do. And I, I don't know, it's gonna. I mean, I have, you guys probably have friends, I have friends today who are paying a thousand dollars a day for open claw, for claw tokens to run open claw.Right? And so, okay. $30,000 a month. Right? And, and by the way, those, those friends have like a thousand more ideas of the things that they want their claw to do, right? Yeah. And so you, you could imagine there, there's like latent demand of up to, I don't know, five or $10,000 a day of, of, of tokens for a fully deployed, you know, per personal agent.Uh, and obviously consumers can't pay that, right? And so, so, but it gives you a sense of the fu of the fu of the future scope of demand, right? And so, so even, even if there's a 10 x improvement in price performance, that still, you know, goes to a hundred dollars a day, which is still way beyond what people can pay.Mm-hmm. So there's just gonna be like. Ferocious to me, by the way. The agent thing, the other interesting thing is I think the agent thing, so up until now, a lot of the constraints of GGPU constraints, I think the agent thing now also translates into CPU constraints. Mm-hmm. Right?swyx: CPU memory.Marc: Yes. CPU memory, right?And so, like the entire chip ecosystem is just gonna get wait,swyx: wait for network constraints, that that will be the killer.Marc: It's all bottleneck potentially for years. And so, so I, I think that Brad, and, and I think it's actually possible, I mean, generally inference costs are gonna keep coming down, but I think the, let's put it this way, the rate of decline, I think may level out here for a bit because of these supply constraints.And then at some point, maybe the lab stops subsidizing so much and that, that, that again, will be, be an issue. And so there's just gonna be so much more demand for inference than, than can be satisfied. Um, you know, kind of with the centralized model. And then, and then, you know, you guys know this, but like all the, just the dramatic, I mean just the dramatic innovations that have happened in the Apple silicon to be able to do, uh, inferences, it's quite amazing the level of effort being put.Like the open source guys are putting incredible effort into getting, you know, this recurring pattern where the big model will never run on a pc, and then six months later mm-hmm. Oh, it runs in a pc, right? It's like amazing. And there's very smart people working on that. So there's all that. And then look, there's also, you know.There's also like other, there's other motivators. There's other motivators which is just like, okay, how much trust are the big centralized model providers? You know, how much trust are they building in the market versus, you know, how much are, you know, at least for, in certain cases with some people, for certain use cases, people being like, well, I'm not willing to just like, turn everything over.So there, there, there's all the trust issues. Um, by the way, there's also just like straight up price optimization. There's many uses of AI where you don't need Einstein in the cloud. You just need like a, a a, a smart local model. There's also performance issues where you want, you know, you want, you know, you're gonna want your doorknob to have an AI model in it.Right. You know, to be able to, you know, do, um, you know, to be able to do access control. Um, obviously like everything with a chip is gonna have an AI model in it. Mm-hmm. And it, a lot of those are gonna be local. Um, and so, yeah. No, like I think, I think you're gonna have ti and then you're gonna, by the way, also wearable devices, you know, you don't wanna do a complete round trip.You want, you know, you, whatever your smart devices are, you want it to be like super low latency. Yeah.swyx: The question, do we care who makes it? Yeah. One of the biggest news this week was the collapse of AI two, the Allen Institute. Mm-hmm. One of the actual American open source model labs. Yeah. Um, and, uh, I'm not that optimistic on, on American open source.Yeah. Like you, you guys invested in MIS trial and MIS trial's doing extremely well outside of China. That's about it.Marc: Yeah. We'll see. We'll see. I look, I, number one, I do think we care. Uh, I do think we, I do think we care who makes it. Um, I would say this, the, the, the, the previous presidential administration wanted to kill it in the us Oh yeah.They wanted to drown in the bathtub. Um, and so they wanted to kill it. So at least we have a government now that actually like, actually wants it wants it to happen. And youswyx: earned to councilMarc: and Yeah. And the new and the P pcast. Yeah. So the, the, you know, this admin for whatever other political issues people have, which are many, you know, this administration has, I think a very enlightened view and in particular an enlightened view on AI and in particular on open source ai.Uh, and so they're very supportive. Um, my read is the Chi. The Chinese have a very, the various Chinese companies have a very specific reason to do open source, which is, they, they, they don't fundamentally, they don't think they can sell commercial, uh, AI outside of China right now. And or at least specifically not, not in the US for a combination of reasons.And so they, they kind of view, I think, open source AI as a bit of a loss leader against basically domestic, uh, you know, paid, paid services. And then kind of an, you know, kind of an ancillary products. You know, they're, they're very excited about it, by the way. I think it's great. I think it's great that they're doing it.Um, you know, I think Deeps seek was like a gift to the world. Um, I think. The great thing about open source, open source, the, the, the impact of open source is felt two ways. One is you, you get the software for free, but the other is you get to learn how it works, right? And so like the paper, the paper, the paper and, and the code, right?And the code. And so, like, for example, I thought this was amazing. So open comes out with L one and it's an amazing technical breakthrough, and it's just like, absolutely fantastic. But of course they don't explain how it works in detail. And then of course they hide the, they hide the reasoning traces, right?And, and then, and then, and then everybody's like, okay, this is great, but like, who's gonna be able to replicate this? Are other people gonna be able to do this? You know, is their secret sauce in there? And then our one comes out and it's just like, there's the code and there's the paper, and now the whole world knows how to do it.And then, you know, three months later, every other AI model is, is adding reasoning. And so, so you get this kind of double, like even if the Chinese models themselves are not the models that get used, the education that's taken place to the rest of the world, the information diffusion, you know, is incredibly powerful.So that happens and then, I don't know. We'll, we'll see. You know, there are a bunch of American, you know, open source, you know, ai, uh, model companies. I mean, look, there's gonna be tremendous, you know, there already is. There's, you know, there's gonna be tre there's tremendous competition, uh, among the primary model companies.You know, there's, depending on how you count, there's like four or five, you know, big co model companies now that are, you know, kind of neck and neck, uh, in different ways. Um, uh, you know, and, and, and, um, you know, and then obviously Bo Bo both X and then MetAware involved are, you know, both have huge, you know, huge attempts to, you know, kind of, to kind of leapfrog underway.And then you've got, you know, a whole fleet of startups, new companies, including a whole bunch that we're backing, that are, you know, trying to come out with different approaches. And then you've got whatever it is. I don't know how, how many, how many, like main line foundation model companies are there in China at this point?It's probably six. It'sswyx: five Tigers is what they call it. Yeah. Uh, Quinn is in questionable because there's change in leadership,Marc: right?swyx: Yeah.Marc: But that, does that include, that includes like Moonshot,swyx: yes. Can deep seek, uh, uh, ZI, um, Quinn oh one is in there.Marc: Right. And then, um, and by dance and, and then you see,swyx: ance would be like the next tier ance.They weren't as prominent. They weren't, didn't haveMarc: a leading. Yeah. But they, you at least, you know, ance is very inspiring and presumably they have more stuff coming and Tencent probably has more stuff coming and, and so forth. And so, so, so like, look, here, here would be a thing you can anticipate, which is there are not these markets, there are not going to be between the US and China right now, there's like a dozen primary foundation model companies that are like at scale, at, at some level of a critical mass.It's not gonna be a dozen in three years, right? Like, it just because these industries don't bear a dozen, it's, it's gonna be three or you know, there's gonna be three or four big winners or maybe one or two big winners. And so there's gonna be like a whole bunch of those guys that are gonna have to figure out alternate strategies.Um, and I think like open source is one of those strategies. And so I, I think you could see like a whole, i, I, I think the questions like, who's gonna do open source? I think that could change really fast. I, I think that, that, that's a very dynamic thing. I think it's very hard to predict what happens. And, and I think it's very important.swyx: NVIDIA's doing a lot.Marc: Well, I was gonna say. Well, exactly. And then you're got Nvidia and then, and then, you know, just to, again, indu, there's an old thing in business strategy, which is called, uh, commoditize Compliments. Commoditize the compliment. That's right. And so if your Jensen is just kind of obvious, of course, you wanna commoditize the software.Yeah. And he's, and to his enormous credit, he's putting enormous resources behind that. And so maybe it, maybe it's literally Nvidia and I think that would be great.Alessio: Yeah. Uh, narrative violation to European projects, uh, in the, uh, damn.swyx: I'm hosting my, uh, Europe, uh, conference soon. And I got both of them.Alessio: They got us.They got us. MarkMarc: finished. They got us, us. Well, wait a minute. Where was Peter? So where was Steinberger when he did? In AustriaAlessio: was, yeah, yeah, yeah.Marc: He was in what? He was in Vienna. Oh, he was in Vienna. And then where is he now?swyx: Uh, he's moving to sf.Marc: Okay. Okay. Alright. Okay, there we go. And then, yeah, the PI guy, right?The PI guys are European.swyx: Yeah, they're also, they're buddies inAlessio: Australia. Mario's also there. Yeah.Marc: Right. And are they, yeah, they haven't announced yet. Any sort of change changed or have theyAlessio: No, they're, they have a company there.Marc: Okay. Got, okay. Good.Alessio: Good, good,good.Alessio: Um,Marc: yeah, good.swyx: Anyways, I think pie and open cloud very important software things and, and I just wanted you to just go off on what you think.Marc: Yeah. So I think in co the, the combination of the two of them I think is one of the 10 most important softwares. Openswyx: Claw got all the attention, but Right. Talk about pie,Marc: pi pie's, kind of the Yeah. PI's, PI's kind of the architectural breakthrough for those of us who are older. There was this whole thing that was very important in the world of software basically from like 1970 to, I don't know, it still is very important, but like 19, from 1973 to like basically the creation of Linux, which is basically this, this thing used to call like the Unix mindset.Like so, so, ‘cause there were all these different, you know, theories. There are all these different operating systems and mainframes and, and then you know, all these windows and Mac and all these things. And then there was this, but kind of behind it all was this idea of kind of the Unix mindset. And the Unix mindset was this thing where basically you don't have these, like, like in the old days, like, like the operating system that like made the computer industry really work, like in the 1960s mm-hmm.Was this thing called o os 360, which was this big operating system that IBM developed that was supposed to basically run everything. And it was this like giant monolithic architecture in the sky. It was like a, you know, it was like a giant castle. Um, of software. And, and by the way, it worked really well and they were very successful with it.But like, it was this huge castle in the sky, but it was this thing, it was almost unapproachable, which is like, you had to be kind of inside IBM or very close to IBM. And you had to really understand every aspect, how the system worked. And then the, the Unix sky is originally out of at and t and then out out of Berkeley, um, you know, came out and they said, no, let's have a completely different architecture.And the way architecture's gonna work is we're gonna have, we're gonna have a, a prompt and, and a, and a shell. And then, and then we're gonna, all, all the functionality is gonna be in the form of these discreet modules, and then you're gonna be able to chain the modules together. Mm-hmm. Yeah. And so like the, the, the op, it's almost like the operating, operating system itself is gonna be a programming language.Um, and then that led led to the, the, the sort of centrality of the shell. Um, and then that led to sort of, uh, you know, basically chaining together Unix tools. And then that led to the emergence of these, these scripting languages like Pearl, where you, you could basically kind of very easily do this, and then the shells got more sophisticated and then, and then, and then look like, you know, that, that, that number one, that worked and that, that was the world I grew up in.Like I was, I was a Unix guy. You know, sort of from, call it 1988 to, you know, kind of all, all the way through my work and it worked really well. It, it's in the background, um, you know, nor normal people don't need to, didn't need to necessarily know about it, but like, if you were doing like system architecture, application development, you, you, you knew all about it.Um, and then, you know, it's been in the background ever since. And, you know, look, your Mac still has a Unix shell, you know, kind of in there, and your iPhone still has a Unix shell kind of buried in there somewhere. So they're kind of in there. And then, you know, the Windows shell is kind of a, you know, sort of a weird derivative of that.But, um, you know, but look, the inter, the internet runs on Unix, um, and that smartphones, actually, both iOS and Android are Unix derivatives. And so, you know, kind of Unix did end up winning. But, but anyway, and then we just started taking that for granted. And then, and then so, so basically the, the way I think about what happened with Pie and then with Open Claw is basically what those guys figured out is, I always say the, the great breakthroughs are obvious in retrospect, right?Which is the best kind, the best kind. They weren't obvious at the time or somebody else would've done them already. Um, and so there is a, like a real conceptual leap, but then you look at it sort of the backwards looking and you're just like, oh, of course. Mm-hmm. Like the, the, to me those are always the best breakthroughs.Well, actually language models themselves are like that. It's just like, oh, next token completion. Oh, of course.swyx: Yeah. What other objective mattered?Marc: Yeah, exactly. But, but like it, right. But she's even saying it wasn't obvious until somebody actually did it. Right. And so the conceptual breakthrough is real and deep and powerful and, and very important.And so the way I think about pie and olaw is it's basically marrying the, the language model mindset to the un to the Unix, basically shell prompt mindset. And so it's, it's basically this idea that what, what, so what is an agent, right? And as, as, and as you know, like many smart people who have been trying to figure out what an agent is for, for, for decades, and they've had many architectures to build agents and the whole thing.And it turns out what is an agent. So it turns out what we now know is an agent is the following. It's, so it's a language model. And then above that, it's a ba, it's a bash shell. Um, so it's a, it's a Unix shell, and then it's, and then the agent has access, uh, has access to, to the shell. And, you know, hopeful, hopefully in a sandbox, maybe in, maybe in a sandbox.So it's, it's the model. Um, it's the shell. Um, and then it's a fi, it's a file system. Um, and then the state is stored in files. And then, you know, there's the markdown format for the, you know, for, for the files themselves. And then, and then there's basically what in Unix is called Aron job. There's a loop and then there's a heartbeat for the, there's heartbeat and, and the thing basically Wake Wakes up.Wakes up. So it's basically LLM plus shell, plus file system, plus markdown, plus kron. And it turns out that's an agent. And, and, and every part of that, other than the model is something that we already completely know and understand. And in fact, it turns out that like the latent power of the Unix shell is like extraordinary because basically like all, like, there's just like an, there's just enormous latent power in the shell.There's enormous numbers of Unix commands, there's enormous number of command line interfaces into all kinds of things already in the, you know, your entire, I mean your entire, just to start with, your computer runs on a shell. If you're running a Mac or a, or, or a phone, your computer, your computer's running on a shell, uh, already.And so like the full power of your computer is available at the command line level. Um, and then it turns out it's really easy to expose other functions as a command line interface. And so like this whole idea where we need like MCP and these like product mm-hmm. Fancy protocols, whatever, it's like, no, we don't, we just need like a command, command line thing.So that's the architecture. And then it turns out what is your agent? Your agent has a bunch of files starting a file system. And then there's the thing that just like completely blew my mind when I write my head around it as a result of this, which is like, okay. This means your agent is now actually independent of the model that it's running on.Because you can actually swap out a different LLM underneath your agent and your, your agent will change personality somewhat. ‘cause the model is different, but all of the state stored in the files will be retained.swyx: Yeah. Different instruction set, but you just compiledit.Marc: Right, exactly. And it's all right.It's like right. Swapping out a ship and recompiling, but it's, it's still, it's still your agent with all of its memories. Um, and with all of its capabilities. And then by the way, you can also swap out the shell, uh, so you can move it to a different execution environment that is also, is also a b shell, by the way, you can also switch out the file system, right.Uh, and you can, and you can, and you can swap out the, the, the heartbeat for the, the crown framework, the, the loop that the agent framework itself. And so your agent basically is ba basically at the end of the day, it's just. It's just, its files. Um, and then, and then there's of course it a openswyx: call.Marc: Yeah, it's, it's basically, it's, it's just the files.Um, and then by the way, as a consequence of that, the agent and then the agent itself, it turns out a couple important things. So one is it, it's, it, it can migrate itself, right? And so you're, you can instruct your agent, migrate yourself to a different, uh, runtime environment, migrate yourself to a different file system, migrate yourself to a different, you know, swap out the language model.Your agent will do all that stuff for you. And then there's the final thing, which is just amazing, which is the agent is the agent actually has full introspection. It actually, it actually knows about its own files and it could rewrite its own files. Right. Which by the way, is basically no widely deployed software system in history where the, the, the thing that you're using actually has full introspective knowledge of how it itself works and is able to modify itself.Like that, that, I mean, there have been toy systems that have had that, but there, there's never been a widely deployed system that has that capability and then that leads you to the capability. That just like completely blew my mind when I wrap my head around it, which is you can tell the agent to add new functions and features to itself and it can do that.Extend yourself. Yeah. Right? Extend, extend yourself. Like extend yourself. Give yourself a new capability. Right? And so, and so literally it's just like you run into somebody at a party and they're like, oh, I have my open claw, do whatever, connect to my eat, sleep bed, and it gives me better advice and sleep.And you go home at night and you tell your claw, or if they're at the party, by the way, you tell your claw, oh, add this capability to yourself. And your claw will say, oh, okay, no problem. And it'll go out on the internet and it'll figure out whatever it needs and then it'll go out to claw code or whatever.It'll write whatever it needs. And then the next thing you know, it has this new capability. And so you don't even have to, like, you can have it upgrade itself without even having to, without having to do anything other than tell it that you want it to do that. And so anyway, so the, the combination of all this is just, I mean, this is just like a massive, incredible, I mean, it's just incredible.Like if I, if I were, if I were 18, like this is a hundred, this is what I would be spending all of my time on. This is like such an incredible conceptual breakthrough. Yeah. And again, pe people are gonna look at it and they already get this response. People are gonna look at it and they're gonna say, oh, well, where's the breakthrough?‘cause these, the, all of these components were already known before. Mm-hmm. But, but this is the key, the key to the breakthrough was by using all these components that were known before, you get all of the underlying capability of that's buried in there. And so all, and so for example, computer use all of a sudden just kind of falls, trivi, trivial.Of course it's gonna be able to use your computer. It has full access to the shell. Right. And then, and then you just, you, you give it access to a browser, and then you've got the computer and the browser and, and often away it goes. And, and then you've got all the abilities of the browser also. Um, yeah.And so, and so the capability unlock here is profound. My friends who are, you know, deepest into this, are having their claw do like a, like, literally like a thousand things in their lives. They have new ideas every day. They're just like constantly throwing new challenges at the thing. And by the way, it's early and, you know, these are, you know, these are prototypes and there are, you know, as you guys know, there's security issues.Yeah. And, and so, you know, there's a bunch of stuff to be ironed out, but the, the unlock of capability is just incredible.swyx: Yeah.Marc: And I, I have absolutely no doubt that everybody in the world is gonna, is gonna have at least, you know, an agent like this, if not an entire family of agents. And w

The Real Cost of Technology Dependence, FreeBSD 15 Linuxator with CUDA, Bidirectional OPNsense/pfSense, Netbase, a SYN attack, and more... NOTES This episode of BSDNow is brought to you by Tarsnap and the BSDNow Patreon Headlines The Real Cost of Technology Dependence: Building Independence with Open-Source Storage News Roundup Building Hierarchical Jails (Podman x Native Jail) on FreeBSD 15 FreeBSD 15.0 Linuxulator with CUDA Setup Bidirectional OPNsense/pfSense Firewall Configuration Migration/Conversion CLI SYN attack Syn attack follow up Netbase is Port of NetBSD Utilities to Another UNIX Like Operating Systems Beastie Bits OpenBSD -current moves to 7.9-beta - Delayed hibernation comes to OpenBSD/amd64 laptops Tarsnap This weeks episode of BSDNow was sponsored by our friends at Tarsnap, the only secure online backup you can trust your data to. Even paranoids need backups. Feedback/Questions Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv Join us and other BSD Fans in our BSD Now Telegram channel

Christopher und Sylvester haben viel Feedback zur Podcastfolge über GrapheneOS bekommen und eröffnen diese Episode mit den diversen Kommentaren und Tipps ihrer Hörer und Hörerinnen. Anschließend geht es unter anderem um Bugs in aktuellen Mailclients, Bugs in sehr alten Betriebssystemen, Bugs, bei denen die Polizei kommt, und solche, bei denen sie es nicht tut. Die Hosts sehen sich außerdem Post-Quantum- Pläne von Google an (dort drängt offenbar die Zeit) und gleich zwei Exploit-Kits gegen recht aktuelle iPhones, die kürzlich bekannt wurden.

Most technical people get promoted because they're the best at the job. Then they spend the next 18 months quietly struggling. Nobody told them it is a completely different job. Malcolm Murphy has spent his career in technical pre-sales, leading solutions consultant teams across major vendor organisations. His view is blunt: the skills that got you promoted will actively hold you back as a manager. What you'll learn: Identify the three distinct buckets every new tech leader must manage from day one Build a proactive hiring bench before you even have a role to fill Set clear performance expectations without fearing the conversation Delegate outcomes instead of activities to unlock your team's performance Develop your people in a way that drives retention more than any salary increase About Malcolm Murphy: Malcolm Murphy has spent the majority of his career in technical pre-sales, moving from UNIX engineer to leading solutions consultant teams across major vendor organisations. He currently specialises in insider risk and human risk management at Mimecast and runs the Pre-Sales Leaders Forum community in the UK. Episode highlights: [approx. 5 min mark] Malcolm breaks down the three buckets every new manager must own: people, business, and company leadership [approx. 17 min mark] Why hiring is not something you do alongside your job. It is your job. How to build a proactive bench before headcount opens up [approx. 36 min mark] The micromanagement trap and why your personal blueprint for success might be the worst thing you impose on your team Connect with Malcolm: LinkedIn: linkedin.com/in/Malcolm-Murphy Enjoyed this episode? Here's what to do next:

Designing OpenZFS Storage for Independence, The day Telnet died, PiDP 11/70, OpenBSD on SGI and more... NOTES This episode of BSDNow is brought to you by Tarsnap and the BSDNow Patreon Headlines Designing OpenZFS Storage for Independence: Pool Architecture, Failure Domains, and Migration Paths 2026-01-14: The Day the telnet Died Reports of Telnet's Death Have Been Greatly Exaggerated News Roundup PiDP-11/70 Build Workshop OpenBSD on SGI: a rollercoaster story Terminals Should Generate 256 Color Palette FreeBSD tribal knowledge: Changes to snapshot strategy Beastie Bits BSDCan reg is now open An Oral History of Unix Major update to drm(4) code in OpenBSD-current (to linux 6.18.16) Patched FreeBSD AMIs Tarsnap This weeks episode of BSDNow was sponsored by our friends at Tarsnap, the only secure online backup you can trust your data to. Even paranoids need backups. Feedback/Questions Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv Join us and other BSD Fans in our BSD Now Telegram channel

Jails for NetBSD, ARC and L2ARC sizing for Proxmox, Anatomy of bsd.rd, Docker Containers on FreeBSD, Running Time Machine inside a FreeBSD Jail, and more... NOTES This episode of BSDNow is brought to you by Tarsnap and the BSDNow Patreon Headlines Jails for NetBSD ARC and L2ARC Sizing on Proxmox News Roundup Lab: Anatomy of bsd.rd — No Reboot Required Exploring Docker containers on FreeBSD Time Machine inside a FreeBSD jail After decades on Linux, FreeBSD finally gave me a reason to switch operating systems Beastie Bits - - Tarsnap This weeks episode of BSDNow was sponsored by our friends at Tarsnap, the only secure online backup you can trust your data to. Even paranoids need backups. Feedback/Questions Emelio - openbsd Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv Join us and other BSD Fans in our BSD Now Telegram channel

This show has been flagged as Clean by the host. This series is dedicated to exploring little-known—and occasionally useful—trinkets lurking in the dusty corners of UNIX-like operating systems. Imagine, if you will, a Jane Austen novel about three sisters. The first is well-known and celebrated by everyone; the second, while slightly smarter and more capable, is significantly less popular; and the third languishes in near-total isolation and obscurity. These three sisters live on any UNIX-like system, and their names are grep , egrep , and fgrep . We will assume you are already familiar with grep — egrep works pretty much the same, except she handles e xtended regular expression syntax. (When writing shell scripts intended to be portable, be careful to call egrep if your expression uses + , ? , | , or braces as metacharacters. Some versions of GNU grep make no distinction between basic and extended regular expressions, so you may be surprised when your script works on one system but not another.) But our subject for today is poor, unnoticed fgrep . While the plainest sister of the three, she really doesn't deserve to be ignored. The "f" in her name stands either for f ixed-string or f ast, depending on who you ask. She does not handle regular expressions at all; the pattern she is given is taken literally. This is a great advantage when what you are searching for contains characters having special meaning in a regular expression. Suppose you have a directory full of PHP scripts and want to find references to an array element called $tokens[0] . You can try grep (note that the single quotes are necessary to prevent the shell from interpreting $tokens as a shell variable): $ grep '$tokens[0]' *.php But there is no output. The reason is that the brackets have special significance to grep ; [0] is interpreted as a character class containing only 0. Therefore, this command looks for the string $tokens0 , which is not what we want. We would have to escape the brackets with backslashes to get the correct match (some implementations may require you to escape the dollar sign also): $ grep '$tokens[0]' *.php parser.php: $outside[] = $tokens[0]; Instead of fooling with all that escaping (which might get tedious if our pattern contains many special characters), we can just use fgrep instead: $ fgrep '$tokens[0]' *.php parser.php: $outside[] = $tokens[0]; One place where fgrep can be particularly handy is when searching through log files for IP addresses. With ordinary grep , the pattern 43.2.1.0 would match 43.221.0.123, 43.2.110.123, and a bunch of other IP addresses you're not interested in because the dot metacharacter will match any character. To make sure you only matched a literal dot you'd have to escape each one with a backslash or, better yet, use fgrep . But what about the claim that fgrep is fast? On GNU systems, there is usually one single binary that changes its behavior depending on whether it is called as grep , egrep , or fgrep . (Actually, this is in line with the POSIX standard 1 , which deprecates egrep and fgrep in favor of a single grep command taking the -E option for using extended regular expressions and the -F option for doing fixed-string searches.) In testing, we found that when specifying a single pattern on the command line, fgrep wasn't really any faster than grep . However, when using the -f option to specify a file containing a list of a couple dozen patterns, fgrep could consistently produce a 20% time savings. On systems where grep and fgrep are different binaries, there can potentially be a more dramatic difference in speed and even memory usage. In our hypothetical Austen novel, the neglected sister would probably be driven to a bad end, to be only spoken of afterward in hushed whispers. Don't let that happen! Whenever you need to search for a string, but don't require the power of regular expressions, get into the habit of calling on fgrep . She can be very helpful and deserves more attention than she gets. You'll save yourself the trouble of worrying about metacharacters and maybe some running time as well. References: Grep specification https://pubs.opengroup.org/onlinepubs/009695399/utilities/grep.html#tag_04_63_18 This article was originally written in June 2010. The podcast episode was recorded in February 2026. Provide feedback on this episode.

In this episode, Todd Ogasawara and Dr. Jon Westfall dive into weathering long  power outages, hands-on impressions of new tech hardware, and the magic of modern software development workflows. Surviving the Hawaii Storms and Tech Infrastructure Failures Todd shared his experience dealing with a severe storm system that swept through Hawaii, knocking out power for roughly 138,000 customers. The 36-hour outage put local infrastructure to the test. The Good: Hawaiian Electric (HECO) deserves credit for vastly improved communication during the crisis, providing necessary updates. The Bad: The cell phone providers struggled. T-Mobile (and consequently Google Fi) went down within 10 to 14 hours, and AT&T followed shortly after. This highlights an ongoing issue with insufficient battery backups at cell sites. The Workaround: To keep lifeline devices running, Todd relied on multi-function devices with large batteries built into devices like portable fans and tire inflators. Drone Regulations and Video Editing Hacks Thanks to some expert advice from previous guest Sven Johansson regarding weight limits and non-commercial trust certificates, Jon is flying his new DJI Neo 2 legally. A standout feature for travelers is that the Neo 2's three-battery charging station can act as a reverse charger for other devices. On the production side: Apple Creative Suite: Jon noted that educators and students can get the Apple Creative Suite (including Final Cut Pro and Logic) for just $30 a year. He used Final Cut to successfully reduce background noise on drone footage. Adobe Podcasts: Todd discussed Adobe Podcasts' new video recording feature. It records individual video and audio tracks locally for each participant, allowing for much easier syncing and enhancement compared to traditional methods. Hands-On with the MacBook Neo Todd provided his initial thoughts on his new Apple MacBook Neo. He opted for the $699 model in Indigo, which includes a 512GB SSD and a fingerprint sensor. Note: All aspects of this podcast including recording, editing, and publishing was performed using the MacBook Neo. The "iPhone Companion": Reminiscent of the old Windows CE "PC companion" devices, the MacBook Neo serves as an excellent companion to the iPhone for those integrated into the Apple ecosystem. Hardware Impressions: Despite a lack of a fan, the aluminum unibody device runs incredibly cool under everyday loads, contrasting sharply with older Intel-based Macs. It also features a solid keyboard and a highly responsive fingerprint reader. The Verdict: It successfully replaces both an aging Chromebook and a 2019 Intel MacBook Pro as a reliable, everyday lower-end access device. While tech power-users might complain about its limitations, it is perfect for its target audience. Modern Coding & WWDC Wishlists Jon has been exploring modern AI coding methods using OpenAI's Codex tool, Git version control, and Apple's Xcode Cloud for immediate compiling. For veterans who started programming in assembly language or Unix, today's continuous deployment pipelines feel like absolute magic. Looking ahead to Apple's WWDC in June, Jon shared his primary wish: an "all-you-can-read" subscription service for Apple Books and Audiobooks. Additionally, early signs point to iOS 27 being a refinement-focused update, similar to the legendary Mac OS X Snow Leopard release.

Pool and Vdev topology for promox, KDE Plasma is not forcing systemd, Running a 2.11 BSD system, Booting NetBSD from a wedge and more... NOTES This episode of BSDNow is brought to you by Tarsnap and the BSDNow Patreon Headlines Pool and VDEV Topology for Proxmox Workloads News Roundup KDE Plasma 6.6 is Not Forcing systemd(1) but Arguments Rage On. An old article with covering : Running and administrating a 2.11 BSD system Booting NetBSD from a wedge, the hard way Beastie Bits The NetBSD Foundation will participate in Google Summer of Code 2026! Solaris 11.4 SRU90: Preserve Boot Environments zfs-2.4.1 Hardening OPNsense: Using Q-Feeds to Block Malicious Traffic Tarsnap This weeks episode of BSDNow was sponsored by our friends at Tarsnap, the only secure online backup you can trust your data to. Even paranoids need backups. Feedback/Questions Gary - A nice blog Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv Join us and other BSD Fans in our BSD Now Telegram channel

An airhacks.fm conversation with Daniel Terhorst-North (@tastapod.com) about: first computer experience with the ZX81 and its 1K memory, the 1K chess game on ZX81, the ZX Spectrum with 16K and later 48K memory, the Amstrad 128K, typing in game listings from computer magazines, Dan's brother John hacking ZX spectrum games using a hardware freeze device and memory peeking/poking, cracking game encryption and copy protection on 8-bit tape cassette games, the arms race between game publishers and hackers, cracking the Star Wars game security before its release, ZX Spectrum fan sites and retro gaming communities, classic games including 3D Monster Maze and Manic Miner and Jet Set Willy, sprite graphics innovation on the Z80 chip, first internship at Domark publishing Empire Strikes Back on ZX Spectrum and Commodore 64, second internship at IBM Hursley Park working on CICS in PL/1 and Rexx, the contrast between casual game studio culture and IBM corporate culture in the 1980s, IBM's role as a founding partner of J2EE Enterprise Java, JMS wrapping MQ Series, the reliability of MQ Series compared to later messaging technologies, finding and reporting a concurrency bug in MQ Series with JUnit tests and IBM's rapid response with an emergency patch, IBM alphaWorks portal and experimental technologies, IBM Aglets mobile Java agent framework compared to modern A2A agent protocols, Jini and JavaSpaces from Sun Microsystems with leasing and self-healing, JXTA peer-to-peer technology, IBM Jikes Compiler performance compared to javac, IBM's own JVM, JVM running on Palm Pilot around 1999, VisualAge for Java as a port of VisualAge for SmallTalk with its image-based architecture and no file system exposure, Java's coupling of class and package names to files and directories as a design weakness, the difficulty of refactoring without IDE support, Eclipse as the first IDE with proper refactoring, NetBeans IDE performance compared to Visual Studio Code, third internship writing X-ray machine control software in Turbo Pascal doing digital image processing, the pace of technological innovation slowing from kaikaku (abrupt change) to kaizen (continuous improvement), Douglas Adams quote about technology perception by age, DEC Alpha 64-bit Unix performance, commodity Linux hardware replacing exotic RISC machines, Apple M series chips rediscovering RISC Architecture and system-on-chip design, innovation fatigue and signal-to-noise ratio in modern tech, LLMs and the trillion-dollar bet on the wrong technology, electric cars as an example of ongoing innovation, Tailwind CSS shutting down due to AI-generated code replacing paid expertise, Stack Overflow in trouble due to AI summarization, open source innovation continuing with tools like Astral's uv replacing the python toolchain, cross-community collaboration between rust and Python and Ruby ecosystems, first graduate job at Crossfield (Fuji/DuPont joint venture) doing electronic pre-press and color transformation through 4D CMYK color cubes, writing a TIFF decoder from scratch in C, Raster Image Processor technology and its connection to Adobe, transition from C++ to Java feeling quirky, joining ThoughtWorks in 2002 for enterprise Java work Daniel Terhorst-North on twitter: @tastapod.com

NOTES This episode of BSDNow is brought to you by Tarsnap and the BSDNow Patreon Headlines ZFS vs BTRFS Architects features and stability RHEL on ZFS Root: An Unholy Experiment News Roundup Slackware on Encrypted ZFS Root. https://tumfatig.net/2026/slackware-on-encrypted-zfs-root/ OpenIndiana Is Porting Solaris' IPS Package Management To Rust FreeBSD Jail Memory Metrics Tcl: The Most Underrated, But The Most Productive Programming Language How to Setup WireGuard on OpenBSD: The Ultimate Self-Hosted VPN Guide (2026) Tarsnap This weeks episode of BSDNow was sponsored by our friends at Tarsnap, the only secure online backup you can trust your data to. Even paranoids need backups. Feedback/Questions Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv Join us and other BSD Fans in our BSD Now Telegram channel

This show has been flagged as Clean by the host. This is the first column in a series dedicated to exploring little-known—and occasionally useful—trinkets lurking in the dusty corners of UNIX-like operating systems. This month's column was inspired by an article on the Linux Journal web site 1 describing a custom-built script that would contain a binary tar archive and, when run, would extract the contents onto the user's system. Upon reading this, memories immediately came rushing back of the days of Usenet, before MIME-encoded e-mail made sending file attachments standard 2 , and where we walked ten miles each way to school (uphill both ways!) in three feet of snow. Yes, at that time, you had to put everything into the body of your message. But what if you needed to send a bunch of files to someone? There was tar , but the format differed between systems, and e-mail and Usenet could only reliably handle 7-bit plain-text ASCII anyhow. You could send separate e-mail messages (but what if one goes missing?) or put "CUT HERE" lines to designate where one file ends and another one begins (tedious for the recipient). The solution was a shell archive created by the shar program. This wraps all your files in a neat shell script that the recipient can just run and have the files magically pop out. All he needs is the Bourne shell and the sed utility, both standard on any UNIX-like system. Suppose you had a directory named "foo" containing the files bar.c, bar.h, and bar.txt, and wanted to send these. All you'd need to do is run the following command, and your archive is on its way. $ shar foo foo/* | mail -s "Foo 1.0 files" bob@example.com When the recipient runs the resulting script, it will create the foo directory and copy out the files onto his system. You can also pick and choose files; if you wanted to leave out bar.txt, you could do shar foo foo/bar.c foo/bar.h or, more simply, shar foo foo/bar.? . Different versions of shar have varying capabilities. For example, the BSD 3 and OS X 4 editions can only really manage plain-text files. If you had a binary object file bar.o, it'd likely get mangled somewhere along the way if you tried to include it in an archive. They also require, as in the examples above, that you name a directory before naming any files inside it (the typical way is to let the find command do the work for you; it produces a list in the right order). The GNU implementation is more flexible and can take just a directory name, automatically including everything underneath. It can also handle binary files by using uuencode—a method for encoding data as ASCII that predated the current base64 MIME standard. GNU shar rather nicely auto-detects whether the input file is text or binary and acts accordingly, and can even compress files if asked. However, unpacking encoded or compressed files from such an archive requires the recipient to have the corresponding decode/uncompress utility, and the documentation is littered with (now somewhat anachronistic) warnings about this 5 . Looking at other UNIX systems, the HP-UX version 6 also can uuencode binary files, and as a special bonus adds logic to the script that will compile and use a simple uudecode tool if the recipient doesn't already have one. It will even handle device files and put the corresponding mknod commands into the script, probably making it the most full-featured implementation of all. IBM's AIX doesn't appear to come with shar . Neither do SunOS and Solaris, which seems quite odd as original development of the program is credited to James Gosling 5 ! And so we bid farewell to shar . Next time you're considering rolling your own script for a particular purpose, consider whether such a tool might already exist, just waiting on your system for you to use it. References: Add a Binary Payload to your Shell Scripts https://www.linuxjournal.com/content/add-binary-payload-your-shell-scripts MIME (Multipurpose Internet Mail Extensions) Part One https://datatracker.ietf.org/doc/html/rfc1521 BSD shar manual page https://man.freebsd.org/cgi/man.cgi?query=shar&sektion=1&manpath=4.4BSD+Lite2 macOS 26.2 shar manual page https://man.freebsd.org/cgi/man.cgi?query=shar&sektion=1&manpath=macOS+26.2 GNU shar utilities manual https://www.gnu.org/software/sharutils/manual/sharutils.html HP-UX Reference (11i v3 07/02) - 1 User Commands N-Z (vol 2) https://support.hpe.com/hpesc/public/docDisplay?docId=c01922474&docLocale=en_US This article was originally written in May 2010. The podcast episode was recorded in February 2026. Provide feedback on this episode.

It's another glorious bounty of listener questions for the monthly Q&A, touching on a bunch of subjects like modern HDMI switchers, enormous turn-of-the-century TVs, MikroTik network gear, Pluribus, why the PCIe retaining clip exists (and how to defeat it), Unix on the desktop, our wishlist ESP32 projects, and the exact moment when cell phones became widespread -- and whether phone numbers are increasingly useless, at least in the US. Support the Pod! Contribute to the Tech Pod Patreon and get access to our booming Discord, a monthly bonus episode, your name in the credits, and other great benefits! You can support the show at: https://patreon.com/techpod

OpenZFS monitoring, hellosystems 0.8, GhostBSD and XLibre, Bhyve Exporters and 30 year old LibC issues. NOTES This episode of BSDNow is brought to you by Tarsnap and the BSDNow Patreon Headlines OpenZFS Monitoring and Observability: What to Track and Why It Matters helloSystem 0.8 Released FreeBSD Based OS Inspired by macOS. https://itsfoss.gitlab.io/post/hellosystem-08-released-freebsd-based-os-inspired-by-macos/ News Roundup [Default GhostBSD to XLibre](https://github.com/ghostbsd/ghostbsd-build/pull/259] Addressing XLibre Change and GhostBSD Future Bhyve Prometheus Exporter for Sylve on FreeBSD. Linux GNU C Library Fixes Security Issue Present Since 1996 Beastie Bits NetBSD 11.0 RC1 available! The Book of PF, 4th Edition is now available December 2025 Finance Report LLDB improvements on FreeBSD Any desire for OnmiOS/Illumos Support : Now's your chance to convince me Tarsnap This weeks episode of BSDNow was sponsored by our friends at Tarsnap, the only secure online backup you can trust your data to. Even paranoids need backups. Feedback/Questions Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv Join us and other BSD Fans in our BSD Now Telegram channel

In this episode of the Crazy Wisdom Podcast, host Stewart Alsop sits down with Jake Hamilton, founder of Groundwire and Nockbox, to explore zero-knowledge proofs, Bitcoin identity systems, and the intersection of privacy-preserving cryptography with AI and blockchain technology. They discuss how ZK proofs could offer an alternative to invasive identity verification systems being rolled out by governments worldwide, the potential for continual learning AI models to shift the balance between centralized and open-source development, and why building secure, auditable computing infrastructure on platforms like Urbit matters more than ever as we face an explosion of AI agents and automated systems. Jake also explains Nockchain's approach to creating a global repository of cryptographically verified facts that can power trustless programmable systems, and how these technologies might converge to solve problems around supply chain security, personal data sovereignty, and resistance to censorship.Timestamps00:00 Introduction to Groundwire and Knockbox02:48 Understanding Zero-Knowledge Proofs06:04 Government Adoption of ZK Proofs08:55 The Future of Identity Verification11:52 AI and ZK Proofs: A New Era14:54 The Role of Urbit in Technology18:03 The Impact of COVID on Trust20:51 The Evolution of AI and Data Privacy23:47 The Future of AI Models26:54 The Need for Local AI Solutions29:51 Interoperability of Knockchain and BitcoinKey Insights1. Zero-Knowledge Proofs Enable Privacy-Preserving Verification: Jake explains that ZK proofs allow you to prove computational outcomes without revealing the underlying data. For example, you could prove you're over 18 without exposing your full identity or driver's license information. The proof demonstrates that a specific program ran through certain steps and reached a particular conclusion, and validating this proof is fast and compact. This technology has profound implications for age verification, identity systems, and protecting privacy while maintaining necessary compliance, potentially offering a middle path between surveillance states and complete anonymity.2. Government Adoption of Privacy Technology Remains Uncertain: There are three competing motivations driving government identity verification systems: genuine surveillance desires, bureaucratic efficiency seeking, and legitimate child protection concerns. Jake believes these groups can be separated, with some officials potentially supporting ZK-based solutions if positioned correctly. He notes the EU is exploring ZK identity verification, and UK officials have shown interest. The key is framing privacy-preserving technology as protection against "the swamp" rather than just abstract privacy benefits, which could resonate with certain political constituencies.3. The COVID Era Destroyed Institutional Trust at Unprecedented Scale: The conversation identifies COVID as potentially the largest institutional trust-burning event in human history, with numerous institutions simultaneously losing credibility with large portions of the population. This represents a dramatic shift from the boomer generation's default trust in authority figures and mainstream media. This collapse is compounded by the incoming AI revolution, creating a perfect storm where established bureaucracies cannot adapt quickly enough to manage rapidly evolving technology, leaving society in fundamentally unmanageable territory.4. Centralized AI Models Create Dangerous Dependencies: Both speakers acknowledge growing dependence on centralized AI services like Claude, with some users spending thousands monthly on tokens. This dependency creates vulnerability to price increases and service disruptions. Jake advocates for local AI deployment using models like DeepSeek R1, running on personal hardware to maintain control and privacy. The shift toward continuous learning models will fundamentally change the AI landscape, making personal data harvesting even more valuable and raising urgent questions about compensation and consent for training data contribution.5. High-Quality Training Data Is Becoming the Primary AI Bottleneck: Stewart argues that AI development is now limited more by high-quality training data than by compute power. The industry has exhausted easily accessible internet data and body-shop-style data labeling. Companies are now using specialized boutique services with techniques like head-mounted cameras for live-streaming world model training. This scarcity is subtly driving price increases across AI services and will fundamentally reshape the economics of AI development, with implications for who controls these increasingly powerful systems.6. Urbit Offers a Foundation for Trustworthy Computing: Jake positions Urbit as essential infrastructure for the AI age because its 30,000-line codebase (versus Unix's three million lines) can be understood by individual humans. Its deterministic, purely functional, and strictly typed design aims for eventual ossification—software that doesn't require constant security patches. This "tiny and diamond perfect" approach addresses the fundamental insecurity of systems requiring monthly vulnerability patches. In an era of AI agents and potential prompt injection attacks, having verifiable, comprehensible computing infrastructure becomes existentially important rather than merely desirable.7. Nockchain Creates a Global Repository of Provable Truth: Jake's vision for Nockchain combines ZK proofs with blockchain technology to create a globally available "truth repository" where verified facts can be programmatically accessed together. This enables smart contracts or programs gated on combinations of proven facts—such as temperature readings from secure devices, supply chain events, and payment confirmations. By using Nock's abstract, simple design optimized for ZK proof generation, the system can validate complex real-world conditions without exposing underlying data, creating infrastructure for coordinating action based on verifiable private information at global scale.

Who wants to hear me make incorrect assumptions about old software? RSX is a system that, from the outside, can sound like it has a similar story to that of UNIX. First developed for the PDP-15 in 1969, RSX becomes much more well known when it migrates to the PDP-11. It becomes a multitasking and multiuser system. A key difference is niche. While UNIX is a very general purpose system RSX is built for real time. That leads to something very unique.

GeoIP PF FreeBSD, ZFs in production, linuxulator feels like magic, XFCE is great, the scariest boot code, and more... NOTES This episode of BSDNow is brought to you by Tarsnap and the BSDNow Patreon Headlines GeoIP-Aware Firewalling with PF on FreeBSD ZFS in Production: Real-World Deployment Patterns and Pitfalls News Roundup Xfce is great Linuxulator on FreeBSD Feels Like Magic The scariest boot loader code OpenBSD-current now runs as guest under Apple Hypervisor Tarsnap This weeks episode of BSDNow was sponsored by our friends at Tarsnap, the only secure online backup you can trust your data to. Even paranoids need backups. Feedback/Questions Matt - Audio Levels Interviews can be troublesome because there's only so much we can do with multiple guests with multiple feeds, and mulitple audio conditions. We can try to normalize but sometimes it's just not easy to do without editing taking an entire day.. Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv Join us and other BSD Fans in our BSD Now Telegram channel

AT&T's $2000 shell, ZFS Scrubs and Data Integrity, FFS Backups, FreeBSD Home Nas, and more. NOTES This episode of BSDNow is brought to you by Tarsnap and the BSDNow Patreon Headlines One too many words on AT&T's $2,000 Korn shell and other Usenet topics Understanding ZFS Scrubs and Data Integrity News Roundup FFS Backup FreeBSD: Home NAS, part 1 – configuring ZFS mirror (RAID1) 8 more parts! Beastie Bits The BSD Proposal UNIX Magic Poster Haiku OS Pulls In Updated Drivers From FreeBSD 15 FreeBSD 15.0 VNET Jails Call for NetBSD testing Tarsnap This weeks episode of BSDNow was sponsored by our friends at Tarsnap, the only secure online backup you can trust your data to. Even paranoids need backups. Feedback/Questions Gary - Links Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv Join us and other BSD Fans in our BSD Now Telegram channel

农历新年将至。本期节目，在近期新闻播报之后，我们将久违地与大家分享几则听众留言。 参考链接 TDC27 正在征稿中，最终截止日期为 2 月 27 日 汉仪第六届字体之星设计大赛获奖名单公布 Seoul Arim，全新设计的韩国首尔地铁导示字体，由 July Type 及 Tlab 合作设计 Frutiger字体原名 Roissy，原型是为法国巴黎戴高乐机场所定制的导示字体 “It's hard to justify Tahoe icons”，Nikita Prokopov 撰文批评 macOS Tahoe 的图标设计，另有 Nullpinter 及少数派翻译的中文版 SF Symbols，Apple 推出的图标系统 字谈字畅 274：鞋合不合脚要穿一下才知道 字谈字畅 273：寻找中文的字体排印师 字谈字畅 272：「我确实觉得这个字体不太庄重」 “We can all be friends: Times New Roman vs Calibri”，Si Daniels 在 Microsoft Design 发布的文章 “From paper to pixels: The evolution of ClearType and onscreen reading”，Tracy Jones 在 Microsoft Design 发布的文章 alias，类 Unix 系统中的 shell 命令之一 字谈字畅 270：「这个奖可以推着我」 《陀飞轮》，陈奕迅演唱的粤语歌曲，黄伟文作词 主播 Eric：字体排印研究者、译者，The Type 执行编辑 蒸鱼：设计师，The Type 编辑 欢迎与我们交流或反馈，来信请致 podcast@thetype.com​。如果你喜爱本期节目，也欢迎用支付宝向我们捐赠：hello@thetype.com​。

UNIX is beloved by many. It's the classic minicomputer operating system. It's big, it's powerful, it's multitasking, and it has some very specific memory requirements. So what happens when you try and get UNIX to run on a microcomputer? Hilarity ensues. Today we are looking at 3 small versions of UNIX: OMNIX, LSX, and CROMIX. And, I'll tell you, one of these is closer to vaporware than the others.

ZFS Scrubs and Data integrity, Propolice, FreeBSD vs Slackware and more. NOTES This episode of BSDNow is brought to you by Tarsnap and the BSDNow Patreon Headlines Understanding ZFS Scrubs and Data Integrity The story of Propolice Desk reviews describe comment ask questions No reponses, no justications. [Tj's Desk](media/bsdnow649-tjs-desk.jpg) [Ruben's Desk](media/bsdnow649-rubens-desk.jpg) News Roundup FreeBSD vs. Slackware: Which super stable OS is right for you? Prometheus, Let's Encrypt, and making sure all our TLS certificates are monitored Wait, a repairable ThinkPad!? Tarsnap This weeks episode of BSDNow was sponsored by our friends at Tarsnap, the only secure online backup you can trust your data to. Even paranoids need backups. Feedback/Questions Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv Join us and other BSD Fans in our BSD Now Telegram channel