20 Hacker News comments link this video. Each one links back to its thread.
ropeadopepopeMay 2018Strongly recommends
This may be a little off topic, but has anybody watched Casey Muratori's proposal on SoC ISAs[0]? The video is long, but it's worth watching all of it. It sounds to me like a SoC ISA could make docker obsolete. If it ever happens, anyway. [0]: ▶ this video
in “Docker is a dangerous gamble” · View on HN
drivers99Mar 2023Recommends
I would say just look around, but it's probably because of some of the information I've seen that opened my eyes to it, so I'll point you to these two talks: ▶ this video Preventing the Collapse of Civilization / Jonathan Blow [link] The Thirty Million Line Problem / Casey Muratori
in “I wanted a beautiful computer and couldn't find one, so I made my own” · View on HN
JamesSwiftApr 2021Recommends
That might be what OS'es currently _are_, but I disagree that it is what an OS _is_. I think fundamentally an OS is as the OP uses it, a set of code that interfaces with all your hardware to make the computer function. Heres a good talk I came across in a HN comment a little while back [1] about how games used to be developed vs how they are today. [1] - ▶ this video
in “Tetris-OS: An operating system that only plays Tetris” · View on HN
Show 14 more comments
stephc_int13May 2020Recommends
A quite well-known rant from Casey Muratori about a very similar issue: ▶ this video (For those who never saw it)
in “Ask HN: Is there still a place for native desktop apps?” · View on HN
scrupleJan 2020Recommends
There is a related Jonathan Blow talk titled "Preventing the Collapse of Civilization" [0] that I came across recently from a HN post. You might be interested in watching it. Also, Casey Muratori's talk titled "The Thirty Million Line Problem" [1]. [0]: [link] [1]: ▶ this video
in “Anti-patterns and malpractices in modern software development (2015)” · View on HN
dsegoOct 2019Recommends
Have you seen the 30 million line problem* by Casey Muratori (of Handmade Hero fame)? There is an argument that a lot of today's complexity in software is an (unnecessary) byproduct of changes in hardware design. * ▶ this video
in “Software Is Hard (2007)” · View on HN
worldsayshiMay 2019Recommends
If you'd like to venture further into this rabbit hole I can recommend "Preventing the Collapse of Civilization": [link] And "The Thirty Million Line Problem": ▶ this video
in “Docker is vulnerable to a symlink-race attack” · View on HN
meukOct 2018Recommends
I think the problem is that current OSes are too complicated. What does a common user really want? I'd say text editing, making presentations, multimedia, and browsing. While these sound like simple things, text editing usually happens in a Word-like format, which - from what I've heard - is ridiculously complex. The same thing holds for browsing (simple browsers don't exist anymore, and many use the same back-end for rendering). For multimedia, USB is very important, which is a very complicated format to use correctly. Then, there are tens of codecs and formats for multimedia, each with their own idiosyncrasies and ambiguities in the specs (or deviations from the spec that are so common that they are expected nowadays). The case is even worse when your OS is supposed to run on different hardware. I think this is the main reason that Apple, in general, has a much better UX: They only have to support a limited set of hardware. Casey Murati has a great rant about this: ▶ this video
in “Systems Software Research is Irrelevant (2000) [pdf]” · View on HN
datadeftNov 2023Cites it
> I'm really sold on the idea: Instead of a full-blown OS, You mean you are sold on the idea of going back to the 80s. We used to have an operating system with every game released[1]. 1. ▶ this video
in “Mirage – A programming framework for building type-safe, modular systems” · View on HN
fractallyteJun 2023Cites it
It's "abstractions" that led to this: ▶ this video [The Thirty Million Line Problem] And Apple is one of the companies directly responsible for the explosion in complexity - and insanity - in modern computing. It's all so deeply entrenched - the hardware, abstraction layers, languages, culture - that it's difficult to imagine ever being able to extricate ourselves from this mess. We need another 'quantum leap' in technology, or some new paradigm...
in “A love letter to Objective-C” · View on HN
cellularmitosisMar 2023Cites it
Casey Muratori proposes going back to the memory-mapped-io-as-universal-hardware-api in "The Thirty Million Line Problem" ▶ this video
in “Learning BASIC Like It's 1983 (2018)” · View on HN
YoofieOct 2022Cites it
Reminds me of these videos from Casey Muratori: 30 million line problem - ▶ this video Twitter and Visual Studio Rant - [link]
in “Ask HN: What is your fav “I can't believe in 2022 this still doesn't work right”” · View on HN
modernerdApr 2021Cites it
“In the 1980s with things like the Amiga computer, for example, every game was a boot disk. It booted into its own customized version of an operating system that ran what it needed to run to make its game work well and be performant and reliable. … We know that in the past, hardware that was very capable and very interesting made it so easy to create an operating system that literally everybody did it. Not a few people. Not even most people. But literally everybody.” – Casey Muratori in “The Thirty Million Line Problem” ▶ this video
in “Tetris-OS: An operating system that only plays Tetris” · View on HN
chenglouJan 2021Cites it
I happened to have read many of VPRI’s papers and some domain expertise in a few of their topics, or know close friends with such domain expertise. Btw, my collection of their links are at [link] The goal is a noble one; though it's unclear to me if their research is the right way to go. Alan Kay's gang's research's end result are often great, but their implementations are usually more geared toward prototyping rather than production. For example, the GUI innovation is great, whereas its implementation using Smalltalk is clearly geared toward faster iteration and not meant to be as competitive as a production language (let's not enter into this debate as this is another rabbit hole. Plenty of other HN threads on this). But I think so far these implementations have gotten a pass because the end result is futuristic enough for someone else to come along and implement e.g. the GUI in more production-oriented languages. In the context of VPRI, however, the goal wasn't to create more futuristic end results, but to recreate existing result using hopefully drastically more concise paradigms and DSLs. In this case, the implementation itself is the thing we should examine, and imo they kinda fall short. For example: - Yes, it's very appealing that Nile can reduce the antialiasing logic by so much. Is it resilient to real world requirement changes though? Unclear (and the Nile paper still isn't out as the author seems busy with some startup). - The OMeta parser tool is cool until you e
in “Code Budgets” · View on HN
frou_dhOct 2018Cites it
> I think it was Casey Muratori who made the argument that we could return to having nice ABIs that are canonical APIs Here's the video I think you're referencing: ▶ this video IIRC he mentions that he actually presented the same content in person to staff at Intel, and discusses how it's very hard to get any buy-in even if the engineers consider the approach to make sense.
in “One Windows Kernel” · View on HN
AnIdiotOnTheNetAug 2018Cites it
I feel like you intended to link this [0]? [0] The 30 Million Line Problem: ▶ this video The article is about Casey's work verifying collision geometry and movement code in Jonathan Blow's The Witness, to ensure that the player can't get stuck anywhere or fall through the ground or anything like that.
in “Walk Monster (2012)” · View on HN
loup-vaillantJun 2018Cites it
So now not only projects have to be maintained, we also have to maintain changes ? I'm seriously getting sick at the notion that nothing can ever be finished. Bugs? That will be those introduced by the change, nothing more. If there is any bug left, that's only because nobody discovered them yet. Having a maintainer won't change that, only usage reveals bugs. (Unless of course the "maintainer" is instead tasked with finding bugs in the first place). Bit rot? That's only an issue when the environment around the code changes. Clang is a compiler , there's not much it cares about its environment. And if you're talking about changes within Clang that could have an effect, and those are well within the maintainer's control. We shouldn't need a maintainer for every patch. This change in particular doesn't seem to introduce any new feature. I'm guessing it only allows Clang to run faster. The new code path replaces the old, so it shouldn't require much more maintenance. --- More generally, we should do away with the notion that everything should be maintained, forever. We should be able to code correct programs. We should have environments stable enough to preserve that correctness. And we should stop believing we need so much code in the first place. Let's not kid ourselves, programs "require maintenance" (euphemism for "aren't finished"), mainly because they're so damn big. We can do better, really. [link] [link] ▶ this video
in “Zapcc – A caching C++ compiler based on clang” · View on HN