Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
kvark
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
14 ms
·
121.
▲
by
kvark
5y ago
I definitely need to check it out. Thanks for the link!
122.
▲
by
kvark
5y ago
I’ve been steering into “just write” territory as well. And for me it’s Markdown instead of Latex. Easy to write, simple rules, sufficient formatting. Would be interesting to imagine a parallel universe where the web is a bunch of Markdown
123.
▲
by
kvark
5y ago
> Vulkan is defined in terms of the SPIR-V intermediate representation, so presumably can run anything that compiles to that “Presumably” doesn’t hold here, unfortunately. We are seeing issues in spirv processing by drivers if it doesn’t
124.
▲
by
kvark
5y ago
Exactly this line of reasoning brought me to Obsidian tool, which manages files you already own. It could be a minority of users, but we love that attitude!
125.
▲
by
kvark
5y ago
It could be a different kind of farm, like an automated testing farm.
126.
▲
by
kvark
5y ago
Rust ecosystem uses a slightly modified semver: https://doc.rust-lang.org/cargo/reference/resolver.html#semv... In this scheme, 0.x.y is compatible with 0.x.z, so developing pre-1.0 software is as strict for break
127.
▲
by
kvark
5y ago
I'm surprised to hear your poor experience with Metal tooling. In my book, it was always superior to RenderDoc. For example, it got able to debug shaders way before RenderDoc started supporting this on Vulkan. It also goes above and be
128.
▲
by
kvark
5y ago
See also the relevant discussion here about the “Point of WebGPU on Native”: https://news.ycombinator.com/item?id=23079200
129.
▲
by
kvark
5y ago
Right, SPIRV is a good format as the destination of your shader pipeline. But it can only be that on Vulkan. With other backends, SPIRV doesn’t help, and instead stands in the way. https://kvark.github.io/spirv/2021
130.
▲
by
kvark
5y ago
Even if SPIRV input becomes available as an extension at some point, don’t expect it to be any kind of optimization. Both Tint and Naga’s IRs are close to WGSL, so parsing it is really easy and fast. Processing SPIRV’s control flow graph, i
131.
▲
by
kvark
5y ago
It’s only talking about one way: WGSL->SPIRV, not the reverse. It also has to be trivially convertible to MSL and HLSL. So WGSL is a separate language now, most ties to SPIRV are cut off.
132.
▲
by
kvark
5y ago
That’s what confuses me. What does he expect from Mark, understanding the technical details of VR and such? Or not trusting Carmack to do his job well in getting the details right?
133.
▲
by
kvark
5y ago
Adding “architecture astronaut “ to my dictionary, such a nice term! Unfortunately, Carmack’s explanation of why this is a concern for Meta is unclear to me.
134.
▲
by
kvark
5y ago
That's not my experience in W3C. Having an implementation gives us a strong voice.
135.
▲
by
kvark
5y ago
Engineers are actively rewriting the debts and throwing the old stuff away. The old graphics layering system was just removed upon completely moving to WebRender, for example.
136.
▲
by
kvark
5y ago
Rooting for (3) but it doesn't seem to be happening. Quite the opposite - more and more apps just wrap the browsers.
137.
▲
by
kvark
5y ago
I'll remove this line. Appeared to be shorter than I expected. Estimates, d'oh.
138.
▲
Processing Shaders with Rust
(vimeo.com)
3 points
by
kvark
5y ago
|
0 comments
139.
▲
NixOS on Framework Laptop
(kvark.github.io)
358 points
by
kvark
5y ago
|
245 comments
140.
▲
by
kvark
5y ago
Rust has ways to deal with mutability. Three-rs [1] uses a classic scene graph tree, like ThreeJS. It's based on Froggy [2], which is a general low level primitive for building a "traditional" topology of the classes. [1] ht
141.
▲
by
kvark
5y ago
I just received my DYI edition. I'm in Canada, and it was shipped 2 days ago. No extra charges. Best logistics experience I had in a while :)
142.
▲
by
kvark
5y ago
Doesn't give them anything. Even adds some risks that people sue them for copyright infringement. E.g. from using GPL projects.
143.
▲
by
kvark
5y ago
Wait, isn't a point of NixOS is that your updates are guaranteed to be smooth? I haven't used it, but your story now worries me. I don't want to be back at "just reinstall the OS" days, even if configuration is port
144.
▲
by
kvark
5y ago
Computers 40 years ago, as understood by most people, would be giant calculators. Who cares about sound, graphics, portability, aside from a few nerds? It turns out, people will care, once they discover the new ways.
145.
▲
by
kvark
5y ago
I wonder about the detail at which W3C specifies the behavior of copying a link. Is it outside of the web spec, and thus could be non-portable?
146.
▲
by
kvark
5y ago
They must be thinking about X1 Extreme, I assume. I've been using one, and it's giant.
147.
▲
by
kvark
5y ago
NVidia in particular has been painful to update on my laptop, and it doesn't work well with the rest of the system.
148.
▲
by
kvark
5y ago
That's the problem. The system is very centralized. Drivers have to be constantly upstreamed to the kernel. Any other way introduces a ton of pain for all involved, since Linux has no binary compatibility guarantees. Compare it to Wind
149.
▲
by
kvark
5y ago
That's an interesting analogy! I think it's going to be history as well, just in a much longer term. Apple has jumped the ship already.
150.
▲
by
kvark
5y ago
I don't want to grow a kernel. Linux grows by 2M LOC a year, as reported by the author of the video. That's just what happens.
More ›